`

СПЕЦИАЛЬНЫЕ
ПАРТНЕРЫ
ПРОЕКТА

Архив номеров

Как изменилось финансирование ИТ-направления в вашей организации?

Best CIO

Определение наиболее профессиональных ИТ-управленцев, лидеров и экспертов в своих отраслях

Человек года

Кто внес наибольший вклад в развитие украинского ИТ-рынка.

Продукт года

Награды «Продукт года» еженедельника «Компьютерное обозрение» за наиболее выдающиеся ИТ-товары

 

Игорь Шаститко

Как было сделано демо Windows Server 2008 на запуске в Киеве, ч.1

+24
голоса

После мероприятия, которое прошло в Киеве 3 апреля 2008, и на котором я демонстрировал технологию Quick Migration для виртуальных машин под управлением Hyper-V в Windows Server 2008, я получил массу вопросов – как устных (на самом мероприятии), так и письменных (по почте, через блог, Live Messenger)…  Основные вопросы, собственно – «А это не хитрое постановочное демо?», «А как это было сделано?», «Какое оборудование и софт необходим?», «Для каких сценариев, кроме продемонстрированного потокового видео, данная технология применима?», «Что делать с реальной нагрузкой, каковы вероятные задержки в реальной жизни?»… В данном посте попробую вкратце ответить на эти (и некоторые другие) вопросы…

Сценарий.
Итак, напомню краткий сценарий работы демо – на одном из физических серверов запускается виртуальная машина под управлением Windows Server 2008 Hyper-V, на которой установлены сервисы Windows Media, обеспечивающие широкое вещание видео потока. Клиентский ПК запускает Windows MediaPlayer, и принимает с виртуального сервера данный видео поток. Работающая виртуальная машина посредством технологии Quick Migration перемещается с одного физического сервера на другой с простоем примерно 20 сек и кратковременной остановкой видео на клиенте, которое тут же восстанавливается и продолжает воспроизводиться с точки останова. Аналогичная ситуация наблюдается и при «пинговании» виртуальной машины с клиента – теряются 3-5 пакетов, отправленных на адрес виртуальной машины, после чего пинги восстанавливаются.

Теория.
Одна из задач виртуализации – изоляция на одном физическом сервере (хосте) ролей сервера с целью большей безопасности, надежности и совместимости, гарантированного распределения аппаратных ресурсов. Но узким место такого решения является устойчивость и доступность физического хоста, на котором будут выполняться виртуальные машины с разными ролями. Задача высокой доступности физического сервера решалась и решается путем отказоустойчивой кластеризации (Windows Server Failover Clustering), при которой выполняемые на том или ином физическом сервер (узле кластера) сервисы «передаются» на другой узел. Целостность данных достигается наличием общего для всех узлов дискового хранилища, на котором и сохраняются данные сервиса, и что обеспечивает доступность данных, не зависимо от того, на каком именно узле сервис выполняется. Виртуальная машина с точки зрения кластеризации является обычным сервисом, который следует остановить на одном узле, сохранив его данные на общем хранилище, и запустить на другом узле. При этом виртуальная машина не просто сохраняет данные (собственно, ее основные данные – виртуальный диск – и так находятся на общем хранилище кластера), а сервис вирутализации приостанавливает работу переносимой виртуальной машины и сохраняет состояние ее оперативной памяти в виде файла на диске. Далее, этот файл восстанавливается на другом узле как память запускаемой там ранее остановленной виртуальной машины. Вот и все – мы получаем виртуальную машины, для которой, собственно, ничего не произошло, все ее состояние идентично моменту останова. Собственно, именно такой процесс и называется Quick Migration. Его эффективность (время простоя виртуальной машины при передаче) в большей степени зависит от скорости работы дисковой или сетевой подсистемы (в зависимости от используемого типа) общего хранилища кластера, на который будет сохраняться оперативная память виртуальной машины и, собственно, от объема этой самой памяти (согласитесь, записать/считать 512МБ – это не тоже самое по времени, что и 8ГБ). Также на время простоя виртуальной машины незначительно влияет эффективность работы самого кластера – время размонтирования на одном узле и монтирования на другом узле кластера диска общего хранилища с данными переносимой виртуальной машины, а также – время публикации сетевого интерфейса виртуальной машины в публичной сети кластера.

Практика.
Для построения демонстрационного примера по Quick Migration, подобного продемонстрированному на запуске, требуется:
2 ПК, выступающие в роли узлов кластера, поскольку речь идет о работе с виртуализацией под управлением Microsoft Hyper-V – обязательна поддержка процессором режимов х64, аппаратной виртуализации от Intel (I-VT) или AMD (AMD-V), запрета исполнения NX/XD, и достаточно памяти для выполнения собственно виртуальных машин. Желательно также наличие нескольких – 2х или более – сетевых  интерфейсов для разделения сетей кластера – публичной, внутренней, хранилища. В реальном примере это роль играли лезвия от HP BladeSystem c3000, в которых было установлено по 2 Intel Xeon (4 core) и 8ГБ ОЗУ.
1 ПК, выступающий в роли контроллера домена Active Directory: FC-кластеризация Windows Server 2008 обязательно требует участия узлов кластера в домене. В примере – также лезвие BladeSystem.
Общий дисковый массив, хранилище. Поскольку под рукой не оказалось ничего из аппаратных средств, что могло бы хоть как-то реализовать данную задачу (хотя лезвия c3000 были оснащены всем необходимым – FiberChannel контроллерами), то было принято простое решение – реализовать общее хранилище посредством iSCSI.
Здесь следует сказать пару слов – iSCSI – протокол, который обеспечивает передачу пакетов SCSI по сетям TCP/IP, т.е. позволяет представить ПК сетевые дисковые ресурсы как локальные дисковые устройства SCSI, и тем самым обеспечивает необходимые требования для реализации общего хранилища кластера. Для функционирования iSCSI требуется 2 основных компонента – сервер iSCSI (iSCSI Target) и клиент iSCSI (iSCSI Initiator). iSCSI Target – это аппаратное устройство или программное обеспечение, которое обеспечивает предоставление доступа к установленным локальным дискам клиентам iSCSI. iSCSI Initiator – клиент, являющийся программным модулем, обычно – драйвером дискового контроллера ОС (но может быть реализованным и аппаратно), обеспечивающий соединение с iSCSI Target и представляющий ОС диски iSCSI Target как локальные физические через точки подключения (target). Эффективность работы iSCSI напрямую зависит от пропускной способности сети, благо, в используемом решении HP BladeSystem c3000 с этим никаких проблем не наблюдается, особенно – между лезвиями.

Как было сделано демо Windows Server 2008 на запуске в Киеве, ч.2

Эта запись опубликована в блоге http://blogs.technet.com/iwalker/

 

+24
голоса

Напечатать Отправить другу

Читайте также

 
 
IDC
Реклама

  •  Home  •  Рынок  •  ИТ-директор  •  CloudComputing  •  Hard  •  Soft  •  Сети  •  Безопасность  •  Наука  •  IoT