Ответ один – простой в оказании сервиса, что сказывается на прибыли. Что делать? Ну конечно – построить ИТ-инфраструктуру с использованием виртуализации и географически распределенного кластера
. О чем речь?
В самом простом варианте: два географически разнесенных сервера виртуализации и две географически разнесенных системы хранения данных с синхронной репликацией, которые видятся серверам как одна система хранения.
Итак: платформа виртуализации – Microsoft Windows Server 2008 R2 с ролью Hyper-V. Создаем кластер высокой доступности на базе компонента Windows Server 2008 R2 Failover Cluster, включаем функционал Cluster Shared Volumes и далее создаем виртуальные серверы с указанием Highly Available. Вуаля – у вас есть решение, которое дает следующие преимущества:
1. Функционал Live Migration, позволяющий перемещать виртуальные серверы с одного хоста на другой БЕЗ потери TCP-коннекта
2. Вытекает из первого – нулевой простой в оказании сервиса конечным пользователям при необходимости обслуживания площадки А за счет перемещения всех виртуальных серверов на площадку В
3. Динамическая балансировка нагрузки на площадку за счет возможности перемещения виртуальных серверов между площадками без потери коннекта
4. В случае катастрофы на площадке А (например, серверную залило водой) виртуальные серверы автоматически запустятся на площадке В
5. Простота управления Live Migration с помощью Failover Cluster GUI, Microsoft System Center Virtual Machine Manager или PowerShell скриптов.
Одно НО – как сделать так, чтобы виртуальные серверы на СХД разных площадок были одинаковые и LUN на площадках виделись как одно целое?
На сегодняшний день существуют аппаратно-программные решения от вендоров, специально предназначенные для задач такого типа.
В следующем посте я расскажу о нескольких присутствующих на рынке решениях, 100% совместимых с технологией Hyper-V Live Migration.
