Результаты теста репликации виртуальных машин Hyper-V в облаках VMM на дополнительный сайт

В этой статье содержатся результаты тестирования производительности при репликации виртуальных машин Hyper-V в облаках System Center Virtual Machine Manager (VMM) в дополнительный центр обработки данных.

Цели тестирования

Цель тестирования — проверить, как ведет себя Site Recovery при репликации устойчивого состояния.

• Репликация устойчивого состояния происходит, когда виртуальные машины завершили начальную репликацию и выполняют синхронизацию небольших изменений.
• Производительность важно измерять с помощью устойчивого состояния, так как это как раз то состояние, в котором большинство виртуальных машин остается до тех пор, пока не возникает непредвиденный простой.
• Тестовое развертывание включает два локальных сайта, на каждом из которых имеется сервер VMM. Такое тестовое развертывание является типичным для развертывания головного офиса и филиала, в котором первый выступает в качестве основного сайта, а филиал — как дополнительный сайт или сайт восстановления.

Результат

Вот что мы сделали в ходе теста:

1. Создали виртуальные машины, использующие шаблоны VMM.
2. Запустили виртуальные машины и отслеживали базовые показатели производительности каждые 12 часов.
3. Создали облака на основном сервере VMM и сервере восстановления VMM.
4. Настроили защиту облака в Azure Site Recovery, включая сопоставление исходного облака и облака восстановления.
5. Включили защиту для виртуальных машин и предоставили им разрешения на выполнение начальной репликации.
6. Ожидание стабилизации системы в течение нескольких часов.
7. Собрали метрики производительности за каждые 12 часов, чтобы проверить, что в течение этого времени все виртуальные машины остаются в ожидаемом состоянии репликации.
8. Определили разницу между базовыми метриками производительности и метриками производительности репликации.

Производительность основного сервера

Реплика Hyper-V (используемая Site Recovery) асинхронно отслеживает изменения в файле журнала с минимальным задействованием ресурсов хранилища на основном сервере.

Реплика Hyper-V использует самоподдерживающий кэш памяти, чтобы свести к минимуму временные затраты на выполнение операций ввода-вывода в секунду для отслеживания. Она сохраняет операции записи в VHDX в памяти и записывает их в файл журнала перед отправкой журнала на сайт восстановления. Окончательная запись данных на диск также происходит в случае, если операции записи сталкиваются с предопределенным ограничением.

На диаграмме ниже показаны временные затраты на выполнение операций ввода-вывода в секунду для репликации. Мы видим, что временные затраты на выполнение операций ввода-вывода в секунду для репликации составляют приблизительно 5%, что довольно мало.

Реплика Hyper-V использует память на основном сервере для оптимизации производительности диска. Как показано на следующей диаграмме, временные затраты на использование памяти на всех серверах в основном кластере являются граничными. Временные затраты на использование памяти представлены в виде процента памяти, используемого репликацией, по отношению к общему объему памяти, который имеется на сервере Hyper-V.

Временные затраты на использование ресурсов ЦП репликой Hyper-V являются минимальными. Как показано на диаграмме ниже, временные затраты на репликацию находятся в диапазоне 2–3 %.

Производительность сервера-получателя

Реплика Hyper-V использует небольшой объем памяти на сервере восстановления, чтобы оптимизировать число операций сохранения. На диаграмме ниже представлены обобщенные данные об использовании памяти на сервере восстановления. Временные затраты на использование памяти представлены в виде процента памяти, используемого репликацией, по отношению к общему объему памяти, который имеется на сервере Hyper-V.

Объем операций ввода-вывода на сайте восстановления зависит от количества операций записи на основном сайте. Рассмотрим общее количество операций ввода-вывода на сайте восстановления по сравнению с общим количеством операций ввода-вывода и операций записи на основном сайте. На диаграмме показано, что итоговое количество операций ввода-вывода в секунду на сайте восстановления:

• приблизительно в 1,5 раза больше количества операций записи на основном сайте;
• составляет приблизительно 37 % от общего количества операций ввода-вывода в секунду на основном сайте.

Влияние на использование сети

Пропускная способность сети между основным узлом и узлом восстановления в среднем составила 275 МБ/с (с включенным сжатием данных) по отношению к имеющейся пропускной способности сети в 5 ГБ/с.

Влияние на производительность виртуальной машины

Важным аспектом является влияние репликации на выполнение рабочей нагрузки, назначенной виртуальным машинам. Если основной сайт правильно подготовлен для репликации, то не должно быть никакого влияния на рабочую нагрузку. Упрощенный механизм отслеживания реплики Hyper-V гарантирует, что рабочие нагрузки, выполняющиеся на виртуальных машинах, не будут затронуты репликацией устойчивого состояния. Это как раз иллюстрируется на следующих диаграммах.

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

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

Заключение

Результаты ясно показывают, что масштабирование Site Recovery в сочетании с репликой Hyper-V выполняется с минимальными временными затратами для большого кластера. Site Recovery обеспечивает простоту развертывания, репликации, управления и мониторинга. Реплика Hyper-V предоставляет необходимую инфраструктуру для успешного масштабирования репликации.

Сведения о тестовой среде

• Основной сайт включает кластер, содержащий пять серверов Hyper-V, на которых выполняются 470 виртуальных машин.
• Виртуальные машины выполняют разную рабочую нагрузку и на них на всех включена защита Site Recovery.
• Хранилище для узла кластера предоставляется сетью хранения данных iSCSI. Модель — Hitachi HUS130.
• Каждый сервер кластера оборудован четырьмя сетевыми картами (NIC) со скоростью передачи данных 1 Гбит/с.
• Две из которых подключены к частной сети iSCSI, а другие две — к внешней корпоративной сети. Одна из внешних сетей зарезервирована исключительно для кластерных взаимодействий.

Сервер ОЗУ Моделирование Процессор Количество процессоров Сетевая карта Программное обеспечение Серверы Hyper-V в кластере: ESTLAB-HOST11ESTLAB-HOST12ESTLAB-HOST13ESTLAB-HOST14ESTLAB-HOST25 128ESTLAB-HOST25 имеет 256 Dell ™ PowerEdge ™ R820 Intel(R) Xeon(R) CPU E5-4620 0 @ 2.20GHz 4 1 Гбит/с х 4 Windows Server Datacenter 2012 R2 (64-разрядная версия) + роль Hyper-V Сервер VMM 2 2 1 Гбит/с Windows Server Database 2012 R2 (64-разрядная версия) + VMM 2012 R2

• Дополнительный сайт включает отказоустойчивый кластер с шестью узлами.
• Хранилище для узла кластера предоставляется сетью хранения данных iSCSI. Модель — Hitachi HUS130.

Сервер ОЗУ Моделирование Процессор Количество процессоров Сетевая карта Программное обеспечение Серверы Hyper-V в кластере: ESTLAB-HOST07ESTLAB-HOST08ESTLAB-HOST09ESTLAB-HOST10 96 Dell ™ PowerEdge ™ R720 Intel(R) Xeon(R) CPU E5-2630 0 @ 2.30GHz 2 1 Гбит/с х 4 Windows Server Datacenter 2012 R2 (64-разрядная версия) + роль Hyper-V ESTLAB HOST17 128 Dell ™ PowerEdge ™ R820 Intel(R) Xeon(R) CPU E5-4620 0 @ 2.20GHz 4 Windows Server Datacenter 2012 R2 (64-разрядная версия) + роль Hyper-V ESTLAB HOST24 256 Dell ™ PowerEdge ™ R820 Intel(R) Xeon(R) CPU E5-4620 0 @ 2.20GHz 2 Windows Server Datacenter 2012 R2 (64-разрядная версия) + роль Hyper-V Сервер VMM 2 2 1 Гбит/с Windows Server Database 2012 R2 (64-разрядная версия) + VMM 2012 R2

• Для целей тестирования мы выбрали рабочие нагрузки, которые обычно используются в сценариях корпоративных клиентов.
• Мы используем IOMeter со сводной таблицей характеристик рабочей нагрузки для моделирования.
• Все профили IOMeter настроены на запись случайных байтов, чтобы смоделировать худшие варианты моделей записи для рабочих нагрузок.

• 470 виртуальных машин в основном кластере.
• Все виртуальные машины с диском VHDX.
• В таблице представлены сводные сведения о виртуальных машинах, выполняющих рабочие нагрузки. Все они созданы с помощью шаблонов VMM.

• Site Recovery был настроен на защиту типа "локальная среда — локальная среда".
• На сервере VMM имеется четыре облака, в которых находятся серверы кластера Hyper-V и их виртуальные машины.

В таблице ниже перечислены метрики производительности и счетчики, которые оценивались в развертывании.