Редкий, но противный кейс: есть сервер на Windows — виртуальная машина на платформе VMware, у которого нужно уменьшить размер одного из дисков (и размер соответствующего vmdk файла на хранилище). До кучи — сервер нельзя выключать надолго.

Чаще всего такие ситуации случаются из-за ошибок сайзинга при развёртывании (в том числе, при прогибании на переговорах разработчиков, которым всегда нужно мильён терабайт и триллион ядер этих ваших комплюктеров, чтобы «одинэс быстро работал»), либо когда система выводится из эксплуатации, оставаясь в дремлющем режиме, и потребности в пространстве у неё снижаются, но убивать полностью её пока нельзя.

По классике эта задача решается занулением свободного пространства внутри ОС и последующей миграцией виртуалки с конвертацией в тонкие диски. Но лично у меня к тонким дискам слишком много претензий, и я стараюсь никогда эту технологию в продакшн не использовать (и никому не советую, кроме случаев совсем уж крайней нужды).

Картина неизвестного художника «Админ накидал на датастор виртуалок с тонкими дисками и ушёл в отпуск»

В операционках Windows отлично работает софтверное зеркалирование, с помощью которого задачу можно решить надёжно, достаточно быстро и без существенных перерывов в работе сервиса (а чаще всего вообще без них).

Сейчас КЭНК-мэн займётся вашими дисками, ребята

Как сжать системный диск

• Сжать раздел стандартными средствами Windows Server до необходимого
• Добавить новый виртуальный диск(и) такого размера как получившийся необходимый размер
• На разделах старого диска (100 мб и системный вместе, остальные если надо — по отдельности) правой кнопкой — добавить зеркало, указать новый диск. Диски преобразуются в динамические и начнётся синхронизация
• В свойствах компьютера установить опции загрузки с вторичного плекса и выбора операционной системы и возможности восстановления при запуске
• Дождаться полной синхронизации зеркальных томов
• Выключить виртуалку. Отключить оригинальные диски от виртуальной машины
• Загрузить сервер, отключить (поломавшееся) зеркалирование

Как сжать несистемный диск

* Сжать раздел стандартными средствами Windows Server до необходимого

• Добавить новый виртуальный диск(и) такого размера как получившийся необходимый размер
• На разделе старого диска правой кнопкой — добавить зеркало, указать новый диск. Диски преобразуются в динамические и начнётся синхронизация
• Дождаться полной синхронизации зеркальных томов
• Отключить (можно на горячую) оригинальные диски от сервера
• Отключить зеркалирование, указав что пропавшего диска в зеркале больше нет и не будет.

Детали и тонкости

Использующие раздел ИС переживают такие операции без проблем, в случае если диск не системный простой сервиса = 0

Иногда всё свободное пространство освободить не получается — диспетчер дисков Windows выдает ошибку «недостаточно свободного места» (There is not enough space available on the disk(s) to complete this operation). Проблема не в месте, а в неперемещаемых файлах, используемых в момент сжатия системой. Решается изучением логов Event Viewer Windows Logs\Application, где видно что именно мешает, и после соответствующих операций (типа временного отключения мешающего файла подкачки на разделе) раздел скорее всего удастся сжать.

Слава Роботам!
КЭНК!

Прекрасный продукт для резервного копирования в виртуальных средах Veeam Backup & Replication в бесплатной версии содержит ограничения, не позволяющие комфортно использовать его на больших инфраструктурах. Ранее возможности автоматизации были сильно урезаны, в свежих версиях они расширены, но всё равно недостаточны для масштабов, актуальных на моём текущем проекте.

При этом, где-то в районе 2016 года Veeam включил поддержку PowerCLI, тогда мне попался на одном из тематических ресурсов скрипт от сотрудника Veeam Владимира Еремина, позволяющий запускать бэкапы. Ну а там где есть скрипт или API — есть и возможность дальнейшей автоматизации.

Моя идея проста: добавить в описание ВМ теги, определяющие применённый к машине план резервного копирования. Управляющие скрипты запускаются по планировщику на сервере с Veeam Backup, находят в инфраструктуре по тегам все машины, которым требуется провести копирование в этот раз, и передают эти данные на вход запускающего рк оригинального скрипта.

Со временем управляющий скрипт и оригинал обросли обвязкой (логирование, высылка уведомлений при ошибках, возможность задания путей и целевых СРК), но главная идея не изменилась:

• программируем логику выбора виртуалок в скрипт
• храним привязку вм к планам копирования тегами в их описаниях
• задаем время старта планов копирования планировщиком задач на сервере

Достоинство решения — стандартные по КЭНК:

• оно бесплатное
• оно эффективно решает задачу максимально штатными средствами (теги хранятся в описаниях машин, расписания — в планировщике задач)
• оно гибкое — ничего не мешает завести несколько серверов с Veeam, вешать на машины несколько тегов и добавлять машины в несколько планов
• оно кастомизируемое — скрипт простой и его можно менять по своему усмотрению

Основной принципиальный недостаток реализованного решения — задачи резервного копирования из скрипта стартуют по очереди (при том что и сам Veeam и мощности инфраструктуры позволяют пережевать несколько одновременных потоков). Впрочем, даже с таким подходом в окно обслуживания удается уложиться без проблем, а значит усложнять решение незачем, по крайней мере пока.

велосипед на гитхабе: https://github.com/alexbatishchev/kenk-backuppo-veeam

КЭНК!
Слава роботам!

TL;DR на лету подсовываем скриптом жесткие диски виртуалкам на Windows

Архитектура одной из систем на проекте подразумевает полную сетевую изоляцию — компьютеры пользователей и сервера расположены в отдельной сети и не имеют связи с внешним миром. При этом пользователи обладают низкой компьютерной культурой и активно приносят данные в систему на флешках — а значит мы имеем ненулевую вероятность поймать вредонос, например шифровальщик. В общем, налицо необходимость регулярной доставки обновлений антивируса в систему, и стойкое нежелание делать это вручную. Твой выход, КЭНК-мен!

Кстати про супергероев. 12 лет назад я работал в классной дружной команде: мы фигачили с такой вовлечённостью и нацеленностью на результат, что совершенно естественным стало желание сдизайнить и заказать для айтишной группы плакаты и магниты на холодильник. Именно с таким ощущением мне с тех пор особенно сильно нравится работать:

После лирического отступления, возвращаемся к подменятору дисков. Так как и в основной и в изолированной системе работают центры администрирования Касперского, строим из подручных средств такой велосипед:

• добавляем по одному дополнительному vmdk диску к каждому серверу с KSC
• включаем опцию на основном сервере KSC, копирующую дубль обновлений на подменный диск
• делаем регулярную задачу на vCenter, стартующую скрипт PowerCLI, который меняет местами эти подменные диски между основным и изолированным KSC
• настраиваем изолированный KSC на забирание обновлений баз из папки на подменном диске
• заодно настраиваем регулярную выгрузки в папку на подменном диске статистики работы и мониторинга ИС

В итоге: требование сетевой изоляции соблюдено, базы антивируса с задержкой на 1-2 часа от внешнего мира обновляются автоматически, в мониторинг основой инфраструктуры попадают сведения из изолированной (с допустимым по SLA временем реакции).

Система вышла уязвимой к снапшотам, так как конфигурацию дисков на ВМ со снимками менять нельзя. Поэтому во время создания резервных копий серверов KSC подмены дисков не происходит. Впрочем накладка этих событий случается достаточно редко и сильно на работу системы не влияет — ничего страшного, переключатся в следующую итерацию.

Самое сложное в этом велосипеде — подобрать период переключения и времена стартов соответствующих задач на KSC, так как скачивание баз с репозиториев в интернетах происходит далеко не мгновенно (но это отдельная печальная песня). В нашем случае диски меняются местами раз в три часа.

Пока не решил, стоит ли тут заливать код скрипта на гитхаб, всё же ценность этого кэнк-решения в идее, а реализация довольно тривиальна. Но может заодно с другими выложу как-нибудь.

КЭНК!
Слава Роботам!

Возникла необходимость проверить кое-что в среде MacOS (тестовый режим, никакого нарушения лицензионного соглашения). Оригинальной железки или просто свободного компа для развёртывания не нашлось, зато были мощности в виртуальной среде и немного изобретательности.

В итоге работает такая схема:

• Вот блейд-сервер железный могучий многолезвийный в ЦОДе
• Вот на одном из лезвий vSphere красивая да отказоустойчивая
• Вот в той висфере виртуалка, а в ней винда десятая до последней версии проапдейченная
• Вот в той виртуалке VMware Workstation триальная тридцатидневная
• Вот в том воркстейшене ещё одна виртуалка, а в ней MacOS Catalina тёмнотемная

Ставить макось напрямую в vSphere было нельзя, так как это потребовало бы патча виртуальной среды сторонним софтом. Производительность решения не была важна, а весь основной функционал ОС в таком варианте завёлся и работает, так что метод можно считать успешным.

По развёртыванию мака в VMware Workstation много статей в интернетах, я опирался на эти:

• как скачать образ системы и сделать из него загрузочный ISO
• как настроить виртуальную машину и поставить в неё MacOS
• патчик для VMware Workstation

Взяли в отдел админа — фаната футурамы. Теперь у нас есть висфера с автодеплоем и дистрибьютед-свитчами.

Приехала книжечка, новенькая, с пылу с жару. Щас узнаем, чего там буржуины напихали в новую версию.

Болотниковская ул.

оригинальный пост сопровождён геометкой