выполняется слияние hyper v что это значит
Выполняется слияние hyper v что это значит
Вопрос
Есть виртуальная машина на Windows Server 2012, роль Hyper-V. Состоит из 1-го vhd диска динамического с максимальным объемом 1 Тб и реальным 70 Гб и набором снапшотов avhd с суммарным объемом примерно 1,1 Тб (600 Гб +500 Гб)
Появилась необходимость уменьшить пространство занимаемое виртуалкой, потому как внутреннее хранилище виртуального сервера уменьшилось значительно. Если удалить снапшоты, начнется слияние с родительским диском и есть опасение, что суммарный объем диска VHD станет более 1ТБ, что нельзя.
Ответы
Все ответы
Удалять все снимки по очереди, начиная с самого последнего. Дожидаетесь пока сольется, потом удаляете следующий.
Либо экспортируйте виртуалку на другой сервер с достаточным объемом диска
Смотрите. максимально возможный объем диска VHD установлен в 1 Тб. Снапшоты суммарно больше 1 Тб. Я боюсь что при слиянии снапшотов c VHD конечный, VHD может стать более 1 Тб, что недопустимо настройками.
Смотрите. максимально возможный объем диска VHD установлен в 1 Тб. Снапшоты суммарно больше 1 Тб. Я боюсь что при слиянии снапшотов c VHD конечный, VHD может стать более 1 Тб, что недопустимо настройками.
The opinion expressed by me is not an official position of Microsoft
Хотелось бы подробнее. В настройках стоит максимум для динамического диска 1Тб. Снапшоты сливаются и получается суммарно больше 1 ТБ. Как это не может быть проблемой?
Этого не будет. Это в принципе невозможно. Если максимальный размер динамики у вас 1ТБ, то после слияния всех дисков максималка в 1ТБ и останется. Сейчас у вас суммарный объем данных разностных дисков больше 1ТБ потом что одни и те же данные могут частично или полностью храниться на нескольких дисках.
Например у вас была системная dll’ка на начальном диске и вы сделали снимок. После этого библиотека обновилась вместе с обновами винды и её последняя измененная версия теперь физически хранится на разностном диске снимка. Потом вы снова сделали снимок (уже второй) и снова позже библиотека обновилась. Теперь её актуальная «копия» будет храниться уже на диске последнего снимка.
В реальности конечно все сложнее, но для понимания должно хватить.
Единственный момент: при слиянии все данные последнего разностного диска будут закачиваться в предыдущий и на каком-то моменте перед удалением разностного диска удаляемого снимка у вас суммарный объем может быть сильно больше, чем до процесса удаления снимка.
Выполняется слияние hyper v что это
Правильное объединение снимков осуществляется через их удаление в консоли управления Hyper-V от самого старого к самому новому и перезагрузкой виртуальной машины. Если по каким-то причинам сделать это не возможно, то потребуется объединять снимки вручную.
Перед тем как приступать к каким-либо действиям, сделайте резервную копию виртуальной машины.
Если снимков несколько – повторите теже самые действия.
Авторские права © защищены и принадлежат Компании «Sky»
SKY – IT-решения для бизнеса, 2012–2019 г.
В настоящее время я сталкиваюсь с проблемой нехватки дискового пространства на выделенном сервере и могу с некоторой помощью справиться. Ситуация такова:
Как я могу выйти из этой ситуации?
Есть ли способ сказать Hyper-V, чтобы не объединить моментальный снимок, поэтому я могу перемещать файлы вокруг? например Я мог бы перемещать файл vhd в другое место, поэтому есть больше места (либо путем очистки пространства на C: либо отключением RAID и созданием нового F: с 250 ГБ). Если бы мне пришлось перемещать файл vhd, это было бы нормально или это моментальный снимок каким-то образом связан с текущим местоположением файла?
Есть ли способ удалить снимок, чтобы я мог отключить SVR03, а затем переместить vhd?
4 ответа
Вот как я это решил:
Компания Microsoft проделала большую работу, направленную на облегчение использования Hyper-V. Уже нет необходимости обладать какими-то специальными навыками для того чтобы создать виртуальную машину и запустить ее в работу. В процессе установки и настройки Hyper-V, используется множество мастеров, помогающих создать виртуальную среду в соответствии с лучшими практиками. Однако, несмотря на все улучшения, существует еще много мест, которые могут вызвать ошибки, из-за чего ИТ специалисты подвергают большому риску свои виртуальные среды и даже не подозревают об этом.
Ниже описаны наиболее распространенные ошибки при развертывании Microsoft Hyper-V и способы, позволяющие их избежать.
Игнорирование сети управления
При развертывании роли Microsoft Hyper-V необходимо выделить отдельную сетевую карту для управления. Однако, многие не желают терять сетевой интерфейс, используя его только для управления. Многие специалисты считают, зачем выделять отдельный сетевой интерфейс на управление когда и так все работает. Зачем же нужен отдельный порт управления?
На хосте Hyper-V может выполняться несколько виртуальных машин. В случае, если через сетевой интерфейс управления работают виртуальные машины, существует возможность получить доступ к виртуальным машинам, их жестким дискам и данным. Поэтому хост Hyper-V должен управляться через отдельный сетевой интерфейс в специально выделенной для администрирования сети. Без соблюдения этого правила, вы подвергаетесь значительным рискам.
Использование неверного вида диска
При создании виртуальной машины, создается виртуальный жесткий диск. Это динамически расширяющийся диск, представляющий собой файл в системе хранения хоста. При установке задается объем жесткого диска виртуальной машины, первоначально этот объем не занимает все место на жестком диске хоста, происходит постепенный рост виртуального жесткого диска по мере необходимости. Пример, если при создании новой виртуальной машины вы указали размер жесткого диска 150 Гб, установили ОС объемом 7 Гб, файл жесткого диска виртуальной машины будет размером 7 Гб.
Такое динамическое изменение размеров жесткого диска обладает не только плюсами, но вызывает проблемы производительности. Поскольку при добавлении необходимого места расходуется мощность хоста, особенно это заметно при добавлении в виртуальную машину файлов большого размера.
Еще одной проблемой, вызванной динамическими дисками, может служить сложность отслеживания необходимого объема на жестком диске хоста. Возможны ситуации, когда динамический диск должен расти, а свободного места на жестком диске хоста нет.
Избежать подобные ситуации позволяют диски фиксированного объема (fixed disks).С fixed disks при создании виртуальной машины, сразу создается файл VHD необходимого объема. Кроме этого, диски с фиксированным объемом не создают проблем производительности.
Некорректное использование Snapshot
Одной из главных причин, из-за которой системные администраторы используют Microsoft Hyper-V, является возможность создания снимков системы (Snapshot). Это простой способ возвратиться в исходное состояние в случае возникновения непредвиденных обстоятельств. Однако, существует несколько проблем, связанных с использованием снимков.
Первое, и самое важное, следует помнить, что создание Snapshot не заменяет необходимость делать резервные копии систем. Создание снимков не позволяет выполнить пофайловое восстановление в случае необходимости, и не решит возможных проблем в случае сбоя сервера Hyper-V.
Второе, необходимость перерыва в работе виртуальных машин. По умолчанию Snapshot файлы сохраняются там же, где находится VHD файл, поэтому они могут служить причиной нехватки места для VHD файлов. В случае нехватки места, первым порывом, для обеспечения необходимого места, может стать удаление Snapshot файлов, используя Hyper-V Manager. Файлы будут помечены для слияния с родительским образом, а само слияние произойдет только после завершения работы виртуальной машины. В случае большого количества снимков, слияние может занять продолжительное время.
Большое количество CPU
Использование многоядерных процессоров стало обыденным явлением, средний современный типичный сервер содержит 8 ядер и это становится нормой. Не без основания считается, что большое количество ядер повышает производительность. Microsoft Hyper-V позволяет использовать до четырех (в случае версии Hyper-V R2 до 32 процессоров) на виртуальную машину.
При использовании виртуальных серверов необходимо соблюдать пропорцию 2 виртуальных процессора на одно физическое ядро. В случае четырех ядерных процессоров это означает, что вы не должны использовать больше восьми виртуальных процессоров для увеличения производительности. Кроме того, виртуальная машина не может использовать отдельное ядро, в случае выделения ей четырех ядерного процессора. Вы должны иметь серьезную причину, что бы использовать в вашей виртуальной машине многопроцессорную конфигурация, такой причиной может служить использование большой базы данных.
Неполное использование возможностей виртуальной сети
Виртуальные свитчи расширяют вашу сетевую топологию. Сетевые администраторы настраивают виртуальные сети, или VLAN, используют 802.1Q транкинги, что бы сделать сеть более эффективной и легкой в управлении.
При подключении к порту свитча, мы все еще считаем, что наш хост является конечной точкой этого сетевого подключения, однако это уже не так. При использовании VLAN, существует возможность расширить функциональность до ваших виртуальных машин. Используя VLAN и транкинг, у вас отпадает необходимость в конфигурировании отдельной сетевой карты для каждой подсети. Вы можете подключать виртуальные машины к различным сетям, используя меньшее количество сетевых портов. Это особенно ценно в случае, когда вы ограниченны количеством сетевых портов, например при использовании blade серверов.
Microsoft Hyper-V позволяет администраторам использовать виртуализацию без необходимости дополнительного специального обучения. Однако, легкость установки Hyper-V сервера еще не говорит о том, что нет особых моментов, которые необходимо учитывать. Использование виртуализации дает множество положительных результатов, которые позволяют забыть все недостатки, но, только до того момента, когда произойдет сбой. Чтобы избежать этого сценария, принимайте правильные решения на начальном этапе создания виртуальной среды.
Что такое слияние Hyper V?
Новая функция, представленная Microsoft в Windows Server 2012 R2, — это слияние виртуальных дисков в реальном времени, которое позволяет объединять моментальные снимки Hyper-V (теперь называемые контрольными точками) в живую виртуальную машину. … Когда один удаляется, он объединяется либо с родительским VHD, либо с другим разностным диском.
Сколько времени занимает слияние Hyper-V?
Все слияние заняло 15 минут от начала до конца.
Что такое Hyper-V и зачем его использовать?
Для начала приведем базовое определение Hyper-V: Hyper-V — это технология Microsoft, которая позволяет пользователям создавать виртуальные компьютерные среды, а также запускать и управлять несколькими операционными системами на одном физическом сервере.
Могу ли я удалить файл Avhdx?
avhdx будет удален из файловой системы. Вы не должны удалять. avhdx файлы напрямую.
Как мне объединить VHDX и Avhdx?
Чтобы объединить файлы вручную:
Как вручную объединить контрольные точки в Hyper-V?
Чтобы объединить моментальные снимки Hyper-V, сделайте следующее:
Как работают контрольные точки в Hyper-V?
Контрольные точки Hyper-V позволяют ИТ-администраторам легко сохранять существующее состояние виртуальной машины до внесения каких-либо изменений, чтобы в случае возникновения проблемы из-за изменений виртуальная машина могла вернуться в свое предыдущее состояние.
Каковы преимущества Hyper-V?
Виртуализация обеспечивает огромную гибкость и упрощает жизнь. Windows Hyper-V упростила динамическую миграцию работающих виртуальных машин с одного хоста на другой. Новая функция миграции хранилища позволяет переносить виртуальное хранилище работающей виртуальной машины из одного репозитория хранилища виртуальных машин в другой.
Зачем нам нужен Hyper-V?
Hyper-V 2012 R2 — это платформа виртуализации Microsoft, или «гипервизор», которая позволяет администраторам лучше использовать свое оборудование за счет виртуализации нескольких операционных систем для одновременной работы на одном физическом сервере.
Что лучше Hyper-V или VMware?
Если вам требуется более широкая поддержка, особенно для старых операционных систем, VMware — хороший выбор. Если вы работаете в основном с виртуальными машинами Windows, Hyper-V — подходящая альтернатива. … Например, в то время как VMware может использовать больше логических ЦП и виртуальных ЦП на узел, Hyper-V может разместить больше физической памяти на узел и виртуальную машину.
Безопасно ли удалять контрольную точку Hyper-V?
Удаление контрольных точек
vhdx для виртуальной машины. Когда вы удаляете контрольную точку, Hyper-V объединяет. … файл avhdx будет удален из файловой системы. Вы не должны удалять.
Могу ли я удалить моментальные снимки Hyper-V?
Чтобы удалить снимок, с помощью диспетчера Hyper-V выберите виртуальную машину, перейдите в окно «Снимки» и выберите снимок для удаления. Затем щелкните правой кнопкой мыши, чтобы выбрать или выбрать «Удалить снимок…» в правой части диспетчера Hyper-V, где отображаются сведения о виртуальной машине.
Что такое файлы AVHD в Hyper-V?
Файл AVHD — это файл, созданный Hyper-V, программой виртуализации, входящей в состав Microsoft Windows Server. Он сохраняет моментальный снимок экземпляров виртуальной машины и позволяет восстановить состояние виртуальной машины. Файлы AVHD могут быть очень большого размера. Файлы AVHD являются дополнениями к файлам.
Как объединить контрольно-пропускные пункты?
Чтобы объединить контрольные точки:
Как преобразовать Avhdx в VHD?
Что такое автовосстановление Avhdx?
В Hyper-V этот процесс фазы автоматического восстановления выполняется в Hyper-V путем «горячего» добавления в виртуальную машину специального виртуального жесткого диска моментального снимка (autorecovery. Avhdx). … При просмотре данных резервного копирования или согласованных снимков состояния интегрированного приложения VSS вы их увидите.
Детектив с Кластером Hyper-V: шаг за шагом ищем решение проблемы
Дисклеймер: я привожу пример того, как я анализирую логи. Жесткого стандарта нет, и действия других инженеров техподдержки Veeam могут (и будут) отличаться. Скриншоты и логи взяты из моей лабы, так как логи клиентов никогда не публикуются и удаляются при закрытии кейса.
Зная это, мы понимаем, что имеем дело с Hyper-V инфраструктурой. (Далее надо будет понять, кластер это или же одна нода). А проблема связана с WMI запросом, который вернул пустое значение. (Empty result)
1. Приступаем к сбору логов
2. Анализ собранной информации
Итак, распаковали архив и видим следующее:
Хммм, с чего же начать…..
2.1 Отчет задания, и зачем его смотреть
Смотреть отчет очень удобно, чтобы представить общую картину и определиться с дальнейшими шагами. В нём мы пытаемся найти закономерности, такие, как данные по определенной проблемной машине или по нескольким определенным машинам, либо же даты выполнения задания. В общем, пытаемся прицепиться к чему-то, чтобы дальше проверять, связано ли это с конкретной машиной, конкретным хостом, конкретным хранилищем или конкретным временем.
Что же мы видим в отчете?
Сервер FS4 падает с ошибкой;
Во время следующего штатного выполнения задания серверы FS2 и FS3 падают с этой же WMI-ошибкой
Вывод по анализу отчета: Из нашего списка машин при штатном выполнении задания некоторые падают, но обязательно отрабатывают с ретрая буквально через несколько минут. Установить закономерность падения машин невозможно, они падают рандомно. Также бывают абсолютно успешные штатные выполнения задания для всех машин.
есть проблемная машина или ряд проблемных машин;
есть проблемная Hyper-V нода ;
отпадают, так как почти все машины из списка хоть раз да падали. После анализа отчета, не имея чёткой теории, что именно надо проверять дальше, я иду смотреть полный стек ошибки, так как в репорт выведена только одна строка, и необходимо увидеть контекст, в котором она появилась.
2.2 Логи задания: ищем стэк ошибки
В этой папке для задания резервного копирования можно встретить 3 типа логов:
А дальше нужно смотреть логи компонента, отвечающего за запросы, анализировать их, чтобы наконец построить теорию.
2.3 Логи WMI запросов на Hyper-V ноду с сервера Veeam
Нам нужны логи Veeam компонента, который отправляет WMI запросы на Hyper-V ноде.
Подсказка: его мы видим в стеке с ошибкой который я показал выше :
Идем в папку, собранную с интересующей нас Hyper-V ноды 19node1
Здесь мы находим уже весь запрос: SELECT Name, ElementName, __RELPATH FROM Msvm_ComputerSystem WHERE Name = «6fb62d8a-4612-4106-a8e7-8030de27119e»
И тут мы можем видеть, что он вернул пустой результат (Empty result). А что вообще он должен возвращать-то? Вопрос хороший, давайте посмотрим, как отработал успешный запрос для другой машины.
Видим, что результатом запроса был конфигурационный файл виртуальной машины. Возникает вопрос: почему же для одной машины файл был успешно найден, а для другой нет? Мы знаем, что через несколько минут на ретрае проблемная машина была все же обработана. Идем анализировать ретрай…. (смотрим лог подзадания Task):
Мы видим, что в этот раз запрос на получение конфигурационного файла машины уже шёл через другую Hyper-V ноду 19node2. Открываем лог HvWmiProxy со второй Hyper-V ноды и видим, что там WMI запрос отработал успешно.
Подводим промежуточные итоги анализа:
Запрос валится с пустым значением, когда выполняется на одной Hyper-V ноде, и через несколько минут отрабатывает корректно, когда выполняется на другой Hyper-V ноде.
Напрашивается резонный вопрос – почему на ретрае запрос стал выполняться на второй Hyper-V ноде? Как Veeam определяет, какая нода должна обрабатывать машину? Для обработки машины (создание снапшота и тд.) Veeam выбирает ту ноду, на которой находится машина (owner). В один момент времени у машины может быть только один владелец (owner). Получается, что в момент штатного выполнения машина числилась на одной ноде, а в момент ретрая уже на другой.
А такое вообще возможно?
Дело в том, что если Hyper-V ноды подключены к кластеру, то машины на них могут мигрировать с ноды на ноду в рамках кластера. Происходить это может по абсолютно разным причинам. Здесь можно выдвинуть предположение, что миграция машины с одной Hyper-V ноды на другую служила причиной такого поведения.
Эту теорию о миграции надо проверять….
2.5 Проверка теории
Идем смотреть лог самого задания, он же Job лог. Там находим таблицу, в которой прописан список Tasks (подзаданий) для каждой машины:
В таблице ясно видно на какой ноде находилась VM во время начала задания. Здесь мы видим, что FS4 была на первой ноде. Смотрим таблицу во время ретрая:
Вуа-ля! Мы подтвердили, что машина мигрировала (смена ноды для машины и есть миграция). В случае необходимости можно запросить и глянуть Windows Events с ноды. Нужные события находятся в ветке Hyper-V-VMMS > Admin.
Элементарно, Ватсон!
Следовательно, такую, казалось бы, мистическую ситуацию можно объяснить достаточно просто – во время начала задания Veeam строит список машин, которые нужно будет обработать, и определяет на какой Hyper-V ноде какая машина находится. Когда дело доходит до машины, то обрабатывается именно та Hyper-V нода, на которой она была в момент начала задания.
В ситуации, когда в задании много машин, и некоторые ждут своей очереди несколько часов, вполне реальна ситуация, что машина мигрирует на другую ноду, и возникнет такая ошибка. На ретрае Veeam опять определяет Hyper-V ноду для машины, и все отрабатывает штатно. Это одна из причин, почему десять мелких бекапных заданий будут лучше, чем одно большое.
Возникает законный вопрос – почему бы не определять Hyper-V ноду для машины прямо перед началом её обработки, чтобы учесть возможность миграции? Дело в том, что такие ограничения связаны с шаренными снапшотами и оптимизациями для параллельной обработки виртуальных машин.
Подробнее о том, зачем используется теневая копия (VSS) во время бэкапа, можно почитать здесь.
Кроме того, миграция машины может произойти в момент подготовки снапшота, то есть когда ресурсы уже запланированы и определился список машин для снапшота. От этого сложно застраховаться, разве что изменить кластерную политику на распределение машин по хостам. Но, возможно, в один прекрасный день наши крутые разработчики найдут решение и для этого нюанса удивительного мира виртуальных машин.
Автор: Никита Шашков (Veeam), Customer Support Engineer.
Как я перестал беспокоиться и полюбил репликацию Hyper-V
Возможно, это странно, но в первые дни на работе после новогодних каникул, когда все упавшее за праздники уже успешно возвращено к жизни, у многих возникает желание как-то упорядочить информацию в своей голове, дабы привести её к систематизированному виду. Хорошим катализатором для этого процесса является осознание факта, что вроде и обладаешь багажом знаний, но бабушке с улицы или шестилетнему ребёнку в простых словах этот багаж ну никак не получится объяснить. Ибо, как гласит народная мудрость, не смог объяснить ребёнку – значит, сам не знаешь. Да и вообще, дефрагментация информации ещё никому не вредила.
Но у нас не курс прикладной психологии, поэтому сегодня я просто изложу в систематизированном виде набора пикселей максимальное количество полезной информации о функции репликации виртуальных машин в среде гипервизора Hyper-V на примере текущей версии Windows Server 2012 R2.
Акт первый. Обзорный.
Значение термина “репликация виртуальных машин” ничем не отличается от общепринятого в IT значения слова “репликация”: на стороннем хосте создаётся и поддерживается копия ВМ с основного хоста.
Давайте сразу договоримся: репликация — это не бекап! Как снапшоты не бекап, рейды не бекап, и вообще ничего не бекап кроме бекапа, ибо если бы дедушка был бабушкой…
Как было оговорено в самом начале, мы будем рассматривать только первый пункт — а именно репликацию Hyper-V машин встроенными средствами Windows Server 2012 R2. Позволю себе заметить, что именно R2 т.к. между первым и вторым релизом лежит функциональная пропасть, и использовать не R2 версию гипервизора в продакшн среде практически моветон.
Чек-лист, пока не стало поздно
Считаю, что так же справедливо будет упомянуть инструмент от Microsoft, позволяющий с определённой долей погрешности подсчитать необходимые для репликации отдельно взятой виртуальной машины ресурсы. Называется он Capacity Planner for Hyper-V Replica Конечно, вы не получите точное количество IOPS, нагрузку на сеть и процессор, но как оценочный инструмент он весьма неплох и позволит проанализировать вашу инфраструктуру заранее.
При запуске вас попросят указать основной сервер, сервер для репликации, машины, которые предстоит обрабатывать и время проведения измерений. Рекомендую изменить установленные по умолчанию 30 минут в сторону увеличения до часа. И, конечно, оптимальное время для запуска — это самый разгар рабочего дня. Собранными данными можно очень здорово пугать начальство и просить денег на новые игруш…железки.
Акт второй. Настроечный.
И вот настал ответственный момент! Сертификаты есть, сеть настроена, везде работает Hyper-V роль, не забыты инструменты управления, и мы можем приступать.
Первым делом надо разрешить нашему хосту выступать в качестве сервера репликации и принимать машины на борт. Делается это через окно стандартных настроек Hyper-V:
Все настройки прозрачные, но я хочу немного заострить внимание на нижней секции Authorization and storage. Это не критично, но очень рекомендую разрешать репликацию только с определёнными хостами или группами хостов. Не часто, но бывают случаи, когда по ошибке или от незнания запускается ошибочная репликация — и хорошо, если это запасной хост, а может случиться забивание хранилища боевого со всеми последующими развлечениями. Разрешать всё подряд — удел лабораторий для тестировщиков и разработчиков. Ну или просто смелых людей =)
Зовём брокера
Поскольку в самом начале мы договорились, что инфраструктура у нас как у взрослых (т.е. настроен и успешно работает кластер), то нам необходимо включить роль брокера реплик Hyper-V. Если же кластера у вас нет, то можете смело пропускать этот параграф.
Процедура активации проста и включает в себя 5 кнопок Next и одну Finish. Объяснять тут нечего, поэтому просто идём в мастер управления кластером, выбираем Configure Role и проходим мастера, не забыв дать NETBIOS совместимое имя и указать IP.
Небольшой хинт для тех, кто сначала читает документацию, а потом делает, хотя настоящие инженеры так не поступают, — всё описанное в предыдущем параграфе можно сделать непосредственно из брокера лишь с той разницей, что настройки будут применены сразу на весь кластер и не придётся вручную разрешать репликацию на каждом сервере. Как видите, выглядит всё точно так же:
Первый пошёл
Теперь наконец-то мы действительно готовы реплицировать нашу самую первую машину. Как и всё в Windows, делать это мы будем через правую кнопку мыши:
Дальше открывается довольно стандартный мастер настроек, где на первых шагах нас спрашивают имя сервера (куда будет реплицирована машина) и просят уточнить настройки подключения. Вернее, если хосты находятся в одном домене, то всё будет заполнено без нашего участия, а вот если сервера не знакомы, да ещё надо зашифровать трафик, то придётся все параметры указать вручную. Единственная галочка, заслуживающая внимания на этом шаге — “сжимать передаваемые данные”. Тут мы обращаемся к стадии планирования и смотрим, что нам важнее: сжимать информацию и скорее закончить передачу данных (что неизбежно вызовет дополнительную нагрузку на хосты), или нам не важен объём и длительность передачи, т.к. в приоритете производительность хоста. Два скучных скриншота:
На следующем шаге необходимо выбрать диски, которые будут участвовать в репликации. В конце статьи, когда пойдёт речь про общую оптимизацию, я приведу несколько советов, а пока стоит запомнить одну деталь – диск, не отмеченный для репликации, будет полностью отсутствовать на принимающей стороне, т.е. он исключается из конфигурации виртуальной машины. Если без этого диска машина не может функционировать, но на нём хранится нечто неважное (вроде временных файлов), то просто создайте заново этот диск на реплицированной машине.
Затем снова обращаемся к этапу планирования и выставляем выбранный период репликации. Если по недоразумению вы всё ещё используете Server 2012, то вас даже не спросят, а просто выставят значение в 5 минут. Со временем Microsoft пришли к выводу, что такое поведение не совсем правильное, и в Server 2012 R2 добавили возможность выбора из 30 секунд, 5 и 15 минут. Не фонтан, конечно, но лучше, чем ничего.
И будьте очень осторожны, выбирая 30-ти секундный интервал — вам понадобится действительно очень сильный хост, с очень быстрой сетью и очень быстрым хранилищем.
Следующий ответственный шаг – указываем, сколько точек восстановления мы будем хранить. Здесь же указываем, с какой периодичностью будут создаваться VSS снапшоты. В принципе, можно прекрасно обходиться и без них, но тогда никто не сможет вам гарантировать консистентность данных со всеми вытекающим последствиями, особенно если речь идёт о приложениях, для которых она критична.
Пример на скриншоте можно интерпретировать на русский таким образом — нам необходимо создавать точку восстановления каждый час, хранить её 24 часа (это максимальное значение) и раз в 4 часа создавать VSS снапшот. Соглашусь с тем, что не самая прозрачная и удобная для понимания конструкция, но, что есть — с тем и работаем.
Затем нам предложат окинуть взглядом все введенные настройки и подтвердить своё желание кнопкой Finish. Нам скажут, что всё прошло хорошо, и предложат изменить сетевые настройки для реплик, т.к. по умолчанию они не подключены ни к одной сети (согласен, что это очень неожиданное место для такого предложения), но мне кажется, что лучше вопросы сети объяснить на практических примерах, которые будут дальше, а пока перейдём к расширенной репликации Hyper-V машин.
Расширяем широту наших глубин
Как и многие другие интересные функции, расширенная репликация виртуальных машин появилась только в Windows Server 2012 R2. Расширенная репликация позволяет настраивать репликацию не только по принципу «точка-точка», но и выстраивать целые цепочки, когда после прохода репликации с главного сервера (назовём это основной репликой), запускается процесс репликации реплики (масло масляное, но лучше не скажешь) на третий хост.
И, если многим не совсем ясно, зачем вообще нужна репликация, то наличие возможности создания цепочки репликации, вероятно, способно окончательно запутать даже самых стойких. Однако предлагаю на ваш суд вот такой, не выдуманный пример. Предположим, что у вас достаточно большая компания, с несколькими серверными в одном здании, и вы настраиваете реплицирование каждые 30 секунд, чтобы в случае прорыва канализации и затопления серверов иметь возможность быстро включить копии ваших виртуальных машин с минимальными потерями данных. Это отличная схема, но, к сожалению, она никак не защищает от полного обесточивания здания или трактора, перегрызающего оптические каналы, подходящие к зданию. На такой случай очень хочется иметь копии машин где-то на стороне, обновляемые, пусть и не каждые 30 секунд, но хотя бы раз в 15 минут, чтобы не позволить вам упасть в грязь лицом.
Мастер настройки расширенной репликации вызывается традиционно правым кликом по реплицированной машине и выбором пункта Extend Replication. Дальнейшая настройка происходит точь-в-точь как в случае с обычной, поэтому рассматривать её отдельно смысла нет.
И вот мы всё успешно настроили, запустили и проверили, поэтому предлагаю перейти к рассмотрению поведения в случае аварии сделав небольшую остановку около сетей.
Немного о сетях
Доподлинно не известно, излишняя это паранойя или нет, но принято все реплики подключать к изолированной сети, которая никак не пересекается с производственной. А зачастую у администратора и вовсе нет выбора, т.к. в дата центре на принимающей стороне используются другие подсети, и у реплики должны быть абсолютно другие сетевые настройки.
И, как мы можем видеть на скриншоте ниже, Hyper-V предоставляет нам возможность указать точные настройки каждого сетевого адаптера на случай аварийного включения. Которое, кстати называется failover, и мы поговорим про него прямо сейчас.
Страшное слово Фейловер
Начну с объяснения термина Failover, т.к. адекватного перевода на язык Пушкина и Толстого ещё не придумали. Фейловером называется процесс правильного (читай управляемого) включения, оперирования и выключения реплицированной машины. Пример неправильного поведения: из панели управления хостом или кластером машина включается по кнопке Start. В этом случае мы получаем гарантированный крах репликации, с последующей настройкой заново, и весь набор весёлых проблем, свойственных наличию двух одинаковых машин в одной инфраструктуре.
Плановый фелойвер
Использование запланированного фейловера, подразумевает, что заранее известно о возможных проблемах с основным хостом. Например, будут проводиться работы с сетями питания, на вас движется ураган, необходимо выключить хост для обслуживания или рабочие поутру решили поковыряться в земле в опасной близости от подводящих кабельных трасс.
В данном варианте присутствует небольшой простой сервисов, равный времени выключения основной машины и загрузке реплики, но то, что переключение производится планово, дает возможность подобрать наиболее удобное для всех время.
Запускаем процесс фейловера и проверяем сетевую доступность поднятой машины для пользователей. Здесь самые частые ошибки — это неверно указанный VLAN и отсутствие соответствующей DNS записи. Ни то, ни другое мастер фейловера не проверяет, оставляя это на откуп администратору.
Самое забавное в этой ситуации — это то, как происходит обратное переключение: нам надо повторить фейловер, но на этот раз со стороны второго хоста, т.е. надо выключить на нём реплику и произвести её плановый фейловер. Решение более чем странное, но что есть — то есть.
Тестовый фейловер
Именно тот случай, когда название соответствует функционалу. Реплики, как и бекапы, хочется проверять, чтобы спать чуть более спокойно. А лучший способ проверить реплику — это включить её. На первый взгляд может показаться, что это другое название запланированного фейловера, однако это не так.
При выполнении тестового фейловера на стороне реплики создаётся временная машина, на которой можно выполнять разнообразные тесты. Например, проверить телнетом набор портов, и в случае утвердительного ответа быть уверенным, что сервисы на этих портах запущены успешно. Один нюанс — по умолчанию виртуальная машина в тестовом фейловере запускается не подключенной к сети. Поэтому первым шагом указываем общие сетевые настройки на случай фейловера, пере-открываем мастер и видим новый пункт меню:
Или более интересный вариант: посмотреть, как поведёт себя критичное для бизнес процессов приложение после установки нового патча, не забыв вывести машину в специально подготовленную изолированную сеть.
Само собой, тестовый фейловер надо запускать на стороне реплики. Процесс полностью повторяет плановый фейловер, с той лишь разницей, что после выполнения всех необходимых процедур его необходимо остановить. Иначе машина так и будет работать, пока рано или поздно не разрастётся на весь диск.
Аварийный фейловер
Здесь есть только одно золотое правило — никогда не запускать этот фейловер, кроме тех случаев, когда это действительно необходимо, т.е. если нет аварийной ситуации — пользуйтесь исключительно тестовым и плановым вариантами. Если необходимо просто посмотреть, как это работает, написать документацию для инженеров и т.п., то проделайте все шаги исключительно в тестовой среде.
При выполнении фейловера единственная опция, которая будет вам доступна — это выбор необходимой точки восстановления. Дальше машина будет запущена несмотря ни на что. Если при выполнении планового фейловера мастер не даст вам выстрелить в ногу и включить две одинаковых машины (т.е. он будет ждать момента полного выключения основной машины), то в этом случае вы получите всего лишь очень чёткое, но ненавязчивое предупреждение.
В качестве последнего барьера перед точкой невозврата вам необходимо будет подтвердить завершение фейловера с помощью Complete-VMFailover командлета PowerShell. Все дополнительные точки восстановления будут удалены, а процесс фейловера логически завершён.
Best Practice
Прежде чем перейти к общим советам, я хочу затронуть тему частной оптимизации для конкретной инфраструктуры. Единственным источником информации, на основе которой можно будет делать далеко идущие выводы, само собой, служит всеобъемлющий мониторинг. Можно спорить, лучшим или нет является Operation Manager из пакета System Center. Но, поскольку в начале мы договорились не рассматривать сторонний софт, да ещё за немалые деньги, этот инструмент мы пропустим.
Итак, первое средство из коробки, которое встречает нас при каждой загрузке Windows Server, носит невзрачное название Best Practice Analyzer (оно находится в самом низу Server Manager консоли).
Запуская время от времени BPA, можно получить действительно ценные советы относительно настроек хоста, которые делаются на основе накопленных событий и мониторинга производительности различных подсистем вашего конкретного хоста и информации накопленной самой Microsoft.
По неизвестным мне причинам события для Hyper-V Replica не вынесены в отдельную подгруппу и, хотя и имеют свои уникальные номера, но идут под грифом Hyper-V. Правила, относящиеся к репликам, идут под номерами от 37 до 54 включительно.
Следующим по порядку идёт непосредственно консоль Hyper-V Manager. Стоит добавить в стандартное окно со списком машин дополнительную колонку Replication Health. Как нетрудно догадаться, в этой колонке будет отображено текущее состояние репликации.
И через меню Replication можно вызвать весьма подробную справку о состоянии машины: