Главная Virtualization, Без рубрики, Новое Microsoft Hyper-V Server 2008 R2: строим кластер
  • Microsoft Hyper-V Server 2008 R2: строим кластер

    hvserver Одной из самых интересных новых возможностей бесплатной платформы для серверной виртуализации Microsoft Hyper-V Server 2008 R2 является возможность работать в failover-кластере. В этой статье будет рассмотрен процесс создания кластера, а так же failover и Live Migration виртуальных машин внутри него.

    Некоторые из читателей наверняка слышали о появлении у Microsoft бесплатного продукта для виртуализации серверов под названием Hyper-V Server. Представляет этот продукт из себя всего-навсего до максимума урезанную ОС Microsoft Windows Server 2008. В ней доступна всего лишь одна роль: Hyper-V, и отсутствует графический интерфейс – как в режиме установки Server Core. Управлять им можно через встроенную утилиту sconfig, через командную строку и удаленно через MMC. Недавно вышла новая версия этого замечательного продукта: Microsoft Windows Server 2008 R2. Что же в ней нового?

    Во-первых, Hyper-V Server 2008 R2 поддерживает уже 8 процессоров и до 2Тб оперативной памяти, тогда как предыдущая версия поддерживала только до 4 процессоров и до 32Гб памяти. Во-вторых, новая версия поддерживает работу в составе Failover-кластера, и, соответственно – все вытекающие из этого возможности R2: Cluster Shared Volumes и Live Migration. Так же поддерживаются и другие новые возможности платформы R2, как VMQ, Core Parking и т.д. В-третьих – утилита конфигурации sconfig была во многом доработана, и теперь благодаря ней можно сделать все первоначальные настройки, такие, как сетевые настройки, ввод в домен, включение удаленного управления – прямо в sconfig, без использования командной строки.

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

    Тем не менее, здесь у Windows Server есть одно важное преимущество: при покупке Windows Server 2008 предоставляется право бесплатного запуска (без покупки серверной лицензии) определенного числа гостевых ОС Windows Server в пределах одного физического хоста: одной – для версии Standard, до четырех – для Enterprisre и не ограниченное число гостевых Windows Server в версии Datacenter. В случае же с Hyper-V Server таких прав не предоставляется, и каждая гостевая ОС должна иметь лицензию. Поэтому Hyper-V Server совсем не обязательно может стать самым выгодным решением. К примеру, при миграции уже существующей инфраструктуры, когда на все серверные ОС уже куплены лицензии – бесплатный Hyper-V Server будет очень даже выгодным решением. Если же планируется развертывание инфраструктуры «с нуля» – то может оказаться выгоднее купить Windows Server 2008 EE или даже Datacenter в случае, если виртуальных машин будет достаточно много.

    Системные требования для Hyper-V Server такие же, как и для Windows Server 2008 с поддержкой Hyper-V. Первое, о чем необходимо помнить – процессор должен быть 64-битной архитектуры, а так же поддерживать технологию аппаратной виртуализации (Intel VT или AMD-V) и аппаратную же Data Execution Prevention (у Intel это называется Execute Disable, XD-bit, а у AMD – No-Execute, NX-bit). Так же необходимо помнить, что обе эти возможности должны быть включены в BIOS Setup, в этом нужно убедиться перед установкой ОС. Если планируется работа в кластере – процессоры на всех узлах желательно должны быть одной модели. Или хотя бы одного производителя, в противном случае перенос виртуальных машин между узлами будет невозможен. Что касается оперативной памяти – тут все считается по достаточно простой формуле: суммарный объем памяти всех виртуальных машин, которые планируется запускать плюс 1 Гбайт для самой ОС. Если же планируем использование кластеров – то надо предусмотреть запас по объему памяти для запуска виртуальных машин, которые, возможно, будут перемещаться с одного узла на другой. Для работы Hyper-V Server 2008 R2 достаточно 8Gb свободного дискового пространства, поддерживается так же запуск с флэш-накопителей. Разумеется, понадобится некий объем дискового пространства для хранения файлов виртуальных машин. Если же планируется работа в кластере – то не обойтись без внешней системы хранения данных, работающей по протоколам FC, SAS или хотя бы iSCSI.

    Официально поддерживаются в качестве гостевых следующие ОС:

    · Разумеется – вся линейка ОС от Microsoft: от Windows 2000 Server до Windows Server 2008 R2, и от Windows XP до Windows 7

    · Novell SUSE Linux Enterprise Server версий 10 и 11 с SP1/SP2

    · Red Hat Enterprise Linux 5.2 и 5.3 с одним допущением: не будут поддерживаться компоненты интеграции, и соответственно – синтетические устройства, к примеру – улучшенная поддержка мыши или виртуальный Ethernet-адаптер 10Gbit.

    Все остальные ОС, вполне возможно, что и запустятся в виртуальной среде, но только на ваш собственный страх и риск: официально со стороны Microsoft поддержки не будет. Если кому-нибудь удастся запустить на Hyper-V, к примеру, FreeBSD или Solaris – буду рад, если поделитесь опытом J

    Статью можно разделить на три главы. В первой главе под названием «Прежде, чем двинуться дальше…» идет сухая теория: что такое «кластер» и с чем его едят, что есть Quick и Live Migration, что такое Cluster Shared Volumes. Если вы уже знаете все это – то можете переходить сразу ко второй главе – «От теории – к практике». И наконец, в третьей главе «Проверим» – описано, как сделать Live Migration и как происходит Failover запущенных виртуальных машин на другой узел.

    Прежде, чем двинуться дальше…

    …давайте вспомним, что же такое «кластер»

    В терминологии Microsoft различают три вида кластеров: отказоустойчивый – failover, кластер балансировки сетевой нагрузки – NLB-cluster и кластер для высокопроизводительных вычислений – high-performance cluster, он же HPC. В настоящей статье речь будет идти об отказоустойчивых кластерах.

    Для чего нужен отказоустойчивый кластер? Как ясно из названия – для повышения отказоустойчивости бизнес-критичных приложений. Например – базы данных. Или, в нашем случае – целой виртуальной машины. При использовании технологий отказоустойчивой кластеризации выход из строя одного физического сервера не приведет к отказу критичного приложения: приложение будет мгновенно, или же с небольшим простоем (до нескольких минут) перезапущено на другом сервере. Тем не менее, использование такой технологии приводит к сильному удорожанию системы: во-первых – из-за необходимости использовать два и более сервера там, где хватило бы и одного, во-вторых – из-за того, что для работы кластера необходима внешняя система хранения данных, которую придется приобрести, если таковых еще нет, и в-третьих – вполне возможно, что для использования технологий кластеризации придется приобрести более дорогие версии ПО (к Hyper-V Server не относится ;).

    Итак, отказоустойчивый кластер состоит как минимум из двух серверов, которые именуются узлами кластера (nodes). Узлы кластера периодически обмениваются между собой особыми пакетами информации, именуемыми heartbeat. Если один из узлов выходит из строя – он перестает отсылать сигналы heartbeat, и кластер отмечает узел как «сбойный». При этом, если на сбойном узле были запущены критичные сервисы – то произойдет их автоматический перезапуск на одном из работающих узлов. В зависимости от сервиса, это может произойти вообще без простоя или же с минимальным простоем в несколько минут – что все равно лучше, чем тратить несколько часов на восстановление сервера.

    Все узлы кластера используют общую систему хранения данных, на которой хранятся общие данные, необходимые для работы самого кластера (так называемый «кворум») и данные, необходимые для функционирования критичных сервисов (файлы БД, виртуальных машин, и т.д.). Хотя фактически кластер состоит из нескольких физических серверов – в сети он представляется как один виртуальный сервер, имеющий свое собственное сетевое имя и IP-адрес. Обращение к кластеризованному сервису производится с использованием собственного имени и IP-адреса кластера, и до тех пор, пока кластер функционирует – к сервисам можно обращаться по одному и тому же имени, вне зависимости от того, на каком из физических серверов запущены сервисы в данный момент времени.

    Как уже было сказано – технологии кластеризации должны поддерживаться на уровне ПО: как самой ОС (Windows Server 2008 Enterprise / Datacenter, Hyper-V Server 2008 R2), так и на уровне прикладного ПО (например – Microsoft SQL Server).

    Таки где же профит?

    Что же даст использование отказоустойчивых кластеров при виртуализации? Разумеется, это повысит отказоустойчивость виртуальных машин: в случае выхода из строя одного из серверов все запущенные на нем виртуальные машины автоматически перезапустятся на другом узле, для гостевых ОС это будет выглядеть как некорректная перезагрузка. То есть 100%-й защиты от сбоев кластер не даст, простой в несколько минут все же произойдет, и несохраненные данные, если таковые имелись – будут потеряны, но все же это значительно быстрее, чем замена неисправного сервера с переносом виртуальных машин.

    Quick and Live Migration

    Кроме этого, использование отказоустойчивой кластеризации позволит переносить виртуальные машины с одного сервера на другой намного быстрее за счет технологий Quick Migration и Live Migration.

    Технология Quick Migration работает следующим образом:

    1. Перемещаемая виртуальная машина переводится в состояние Save State.

    2. На сервере, куда планируется перемещать виртуальную машину – создается новая виртуальная машина с таким же именем и с такой же конфигурацией.

    3. К созданной виртуальной машине монтируются все необходимые виртуальные диски.

    4. Старая виртуальная машина удаляется.

    5. Новая виртуальная машина запускается с восстановлением из Save State.

    Этот способ перемещения имеет один серьезный недостаток: процесс перехода виртуальной машины в Save State и последующее восстановление занимает определенное время, в течение которого виртуальная машина остается недоступной. И, к примеру, если к ней подключались пользователи по RDP – произойдет обрыв сессии, что в принципе неприятно, но и не смертельно.

    В Windows Server 2008 R2 появился новый способ перемещения под названием Live Migration. Происходит это следующим образом:

    1. На сервере, куда планируется перемещать виртуальную машину – создается новая виртуальная машина с таким же именем и с такой же конфигурацией

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

    3. Как только содержимое памяти на обеих виртуальных машинах будет полностью совпадать – происходит перемонтирование всех виртуальных дисков к новой виртуальной машине.

    4. Новая виртуальная машина теперь работает, а старая – удаляется.

    Поскольку при Live Migration содержимое памяти копируется «на лету», без останова виртуальной машины – то время простоя фактически равно нулю. Небольшой, размером в малые доли секунды, простой будет на этапе перемонтирования виртуальных дисков, но он будет незаметен для пользователя, так как TCP-сессии за этот момент не успеют оборваться по тайм-ауту. Тем не менее, здесь имеется небольшой нюанс: копирование содержимого памяти осуществляется по сети, и длительность процесса зависит от нагруженности сети. Поэтому, если сеть достаточно сильно загружена – рекомендуется добавить на серверах дополнительные сетевые интерфейсы и создать отдельную сеть исключительно для трафика при миграции. Так же надо помнить, что существует ограничение в 10 циклов при копировании содержимого памяти. То есть, если содержимое памяти очень часто и очень сильно меняется (к примеру – база данных с очень большим количеством транзакций в секунду), и/или из-за загруженности сети копирование происходит достаточно медленно – миграция может не произойти вообще.

    Cluster Shared Volumes

    Прежде, чем перейти к практике – нужно сказать еще об одной новой возможности в Windows Server 2008 R2: кластерной файловой системе, Cluster Shared Volumes (CSV).

    Без использования кластерных ФС два узла кластера не могут обращаться одновременно к одному и тому же дисковому устройству: при обращении к нему с одного из серверов на другом устройство переходит в состояние Offline. Поэтому до появления CSV было очень сложно запускать одновременно несколько виртуальных машин на разных узлах кластера: для этого приходилось для каждой виртуальной машины создавать свой отдельный LUN, что создавало дополнительные сложности. С использованием же CSV эта проблема решается: CSV позволяет осуществлять одновременный доступ к данным на одном дисковом устройстве с нескольких серверов.

    Тома CSV не имеют в системе своих букв. Вместо этого, они на манер UNIX-like монтируются как папки в системном разделе. При использовании CSV на системном диске (как правило, это диск C: ) создается папка ClusterStorage, и все дисковые устройства, используемые как CSV, монтируются в ней как подпапки в виде C:\ClusterStorage\volume1, C:\ClusterStorage\volume2, …, C:\ClusterStorage\volumeN. В связи с этим необходимо учитывать, что на всех узлах кластера системный раздел должен иметь одинаковую букву. Так же необходимо учитывать, что CSV в настоящий момент официально поддерживаются только в качестве хранилища данных для виртуальных машин Hyper-V.

    От теории – к практике

    Вы все еще не устали читать? Поздравляю. Теперь мы посмотрим, как это все работает на «реальном железе».

    Итак, для демонстрации работы кластера на Hyper-V Server 2008 R2 была создана тестовая инфраструктура, состоящая из трех физических машин:

    · Node1 – будет использоваться в качестве первого узла кластера

    · Node2 – будет использоваться в качестве второго узла кластера

    · Server – хост для запуска виртуальной машины DC

    Как нетрудно догадаться, на Node1 и Node2 установлен Hyper-V Server 2008 R2, а на Server – Windows Server 2008 R2 с ролью Hyper-V. Виртуальная машина DC, запущенная на Server, используется во-первых – в качестве контроллера домена TEST.LOCAL, а во-вторых – в качестве системы хранения данных. Для этого на ней установлено ПО Starwind iSCSI Target в бесплатной версии. Бесплатная версия позволяет создавать iSCSI targets объемом до 2Tb, но надо помнить, что использовать в продакшене ее нельзя. Для нашей демонстрации было создано два виртуальных дисковых устройства: объемом 0,5Gb и 20Gb, впоследствии подключенные к Node1 и Node2 с использованием iSCSI. Устройство меньшего объема будет использоваться в качестве кворумного ресурса для работы кластера, а большего – для хранения данных виртуальных машин.

    Все сервера объединены сетью Gigabit Ethernet, Node1 и Node2 являются членами домена TEST.LOCAL.

    Схема нашей тестовой инфраструктуры выглядит следующим образом:

    infrastructure

    Поехали!(с) Ю.А.Гагарин

    Вначале – создадим на наших узлах виртуальные сети. Дело в том, что при установке роли Hyper-V в Windows Server 2008 прямо в самом мастере установки ролей будет предложено создать одну или несколько виртуальных сетей, в Hyper-V Server же этого нет, сети нужно создавать уже после установки через Hyper-V Manager. Разумеется, на только что на свежеустановленном Hyper-V Server надо предварительно разрешить удаленный доступ через MMC. Как это сделать – я описывал в статьях немного ранее, поэтому останавливаться на этом не буду. Итак, удаленно (в нашем случае – из интерфейса DC) подключаемся через консоль Hyper-V Manager к нашим узлам, затем на обоих узлах через Virtual Network Manager создаем новую виртуальную сеть типа External:

    vnet

    При нажатии ОК нас предупредят, что связь с сервером может на какое-то время прерваться. Соглашаемся с этим, и повторяем те же действия на другом узле.

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

    Теперь нужно подключить к нашим будущим узлам кластера iSCSI-диски и установить компоненту Failover Clusteing. Заходим непосредственно на консоль Node1.

    Компонента Failover Clustering устанавливается с помощью пункта меню 11 в утилите sconfig:

    sconfig

    Теперь нам осталось подключить iSCSI-диски. Кто-то спрашивал, зачем в режиме Server Core нужна мышка? Переходим в командную строку и запускаем Microsoft iSCSI Initiator командой iscsicpl. Соглашаемся с запуском сервиса iSCSI и видим окно инициатора:

    iscsi

    Добавляем наш DC в Discovery Portal. Для этого на закладке Discovery нажимаем кнопку, как не трудно догадаться, Discovery Portal, и вбиваем сетевое имя нашего iSCSI-сервера, в нашем случае – DC.

    Сразу после этого на закладке Targets должны появиться iSCSI-устройства, доступные на сервере. В нашем случае их будет целых два:

    iscsi1

    Их необходимо подключить кнопкой Connect, а затем перейти на закладку Volumes and Devices и выбрать Auto Configure.

    Вроде как все. Но не совсем. Дело в том, что дальше нам придется подключаться к узлу через консоль MMC, но нас будет ждать облом? Кто угадает почему – может взять с полочки пирожок.

    Все дело в том, что когда мы создавали виртуальную сеть – был создан новый сетевой адаптер, и на него были перенесены все сетевые настройки. Включая и настройки фаерволла. Поэтому нам необходимо повторить ( в меню sconfig пункт 4, затем 1 и 3).

    Вот теперь все. Можно разлогиниться.

    Мы находимся в интерфейсе виртуальной машины DC. Открываем консоль Server Manager, подключаемся к Node1 и идем Storage – Disk Management. Нам тут же предлагают проинициализировать наши два новых диска, что мы и делаем. После инициализации на каждом из дисков создаем раздел объемом на весь диск и форматируем. Файловая система, разумеется, NTFS. Размер кластера я для тестовой среды оставил дефолтным. 0,5Gb-диску я присвоил букву Q: и метку Quorum, а другому, соответственно – S: и Storage. Хотя это и не существенно, можно выбирать любые. После форматирования выглядело все вот так:

    disks

    Теперь можно и нужно подготовить второй узел: заходим на Node2, устанавливаем компоненту Failover Clustering, подключаем iSCSI-диски и включаем удаленное управление еще раз – по аналогии с действиями на Node1.

    Проверяем Server Manager’ом подключение iSCSI-дисков на Node2. Диски подключились, правда буквы им были выданы другие – D: и F:. Можно для проформы поменять их на Q: и S:, можно этого и не делать.

    Собираем кластер

    Наконец-то мы добрались собственно до сборки кластера. Все операции с кластером будут осуществляться через консоль Failover Cluster Managemer (далее – FCM).

    Итак, мы открыли FCM. Первое, что нам необходимо сделать – это проверить, «взлетит или не взлетит», то есть соберется ли кластер из наших узлов или нет. Для этого используется мастер проверки конфигурации (Validate Configuration):

    valid

    Все, что здесь необходимо сделать – это выбрать сервера, которые будут входить в кластер, и выбрать тесты из списка. Тестов много, и я рекомендую провести их все – потому что только в случае успешного прохождения всех тестов решение будет поддерживаемым. Если все прошло успешно – то будет примерно такая картинка (Testing has completed successfully):

    valid1

    В моем случае был один варнинг по причине того, что между серверами был всего лишь один сетевой линк, а рекомендуется – два и более. Но это в принципе не критично для тестовой инфраструктуры, поэтому будем считать тест пройденным успешно.

    Вы все еще не уснули? Тогда переходим непосредственно к сборке кластера. Запускаем мастер сборки (Create a Cluster). Мастер этот похож на предыдущий, так же будет необходимо выбрать наши узлы Node1 и Node2, а затем – задать сетевое имя и IP-адрес для самого кластера:

    create

    После окончания процесса сборки наш кластер появится в дереве FCM:

    fcm

    Разных опций и настроек у нас много. Вначале нужно посмотреть на раздел Nodes, проверить, что оба узла в состоянии Up (работают), а в разделе Storage – убедиться, что диск Q: назначен кворумом, а 20Gb-диск появился в Available Storage:

    storage

    Создаем CSV

    Теперь попробуем создать Cluster Shared Volume, на котором будем хранить наши виртуальные машины. Для этого заходим в корень консоли FCM и выбираем Enable Cluster Shared Volumes. Нас предупредят, что CSV разрешается использовать только для хранения файлов виртуальных машин Hyper-V, все остальное – unsupported solution:

    csv

    После согласия с этим предупреждением в дереве настроек нашего кластера появится новый раздел с названием… ни за что не угадаете… Cluster Shared Volumes! Заходим туда и добавляем (Add Storage) наш диск S: объемом 20Gb в CSV:

    csv1

    Создаем виртуальную машину как сервис кластера

    Кластер готов, теперь можно перейти к экспериментам. Для этого создадим виртуальную машину. Это можно сделать через оснастку Hyper-V Manager, но проще сделать через FCM – тем более, что туда все равно придется вернуться, чтобы сделать нашу виртуальную машину ресурсом кластера. В разделе Services and applications есть опция Virtual Machines, через которую мы и создаем нашу тестовую виртуальную машину, например, на узле Node1:

    vm

    Запускается стандартный мастер создания виртуальной машины, такой же, как и в Hyper-V Manager. Мы будем хранить наши виртуальные машины на CSV, и поэтому надо указать соответствующий путь (C:\ClusterStorage\volume1):

    vm1

    В остальном – все полностью аналогично созданию виртуальной машины в Hyper-V Manager. Отмечу лишь, что назвали мы нашу машину TestVM, дали ей 512Mb памяти и диск фиксированного объема 15Gb.

    Запускаем виртуальную машину, устанавливаем ОС. Отсюда же, из FCM, подключаемся к ее консоли (Connect to virtual machines) и проходим процесс установки ОС и ее настройки (сетевые настройки, ввод в домен, etc.)

    Проверим?

    Давайте теперь проверим, как работает Live Migration. Для этого на нашей тестовой виртуальной машине создадим расшаренную папку и начнем копировать в нее некий файл большого объема (к примеру – тот самый ISO-образ, с которого была установлена ОС). В процессе копирования переместим виртуальную машину с узла Node1 на Node2 с помощью Live Migration:

    lm

    Как мы видим – процесс миграции занимает несколько секунд, а копирование файла при этом не прерывается.

    Для проверки Failover можно, например, выдернуть сетевой кабель из одного из серверов кластера. В течении нескольких минут кластер «заметит», что узел «вышел из строя» (то есть перестал отправлять сигналы heartbeat) и если на нем были запущены виртуальные машины – перезапустит их на другом узле. Для гостевых ОС на перезапущенных виртуальных машинах это будет выглядеть как неожиданное выключение:

    unexp

    Таким образом, полной отказоустойчивости использование Failover Clustering обеспечить не может, но тем не менее failover в течение нескольких минут – это все же лучше, чем ручная замена сервера и перенос виртуальных машин в течение нескольких часов.

    Заключение

    Как мы убедились в этой статье, Hyper-V Server 2008 R2 вполне подходит для промышленного применения: он поддерживает все возможности Hyper-V R2 и может работать в составе отказоустойчивого кластера. Здесь мы на практике ознакомились с процессом развертывания failover-кластера на базе Hyper-V Server и проверили работу Live Migration и Failover. На вопрос что же лучше использовать в качестве среды для виртуализации – Windows Server или Hyper-V Server – однозначный ответ дать невозможно. Windows Server поддерживает работу в составе кластера только в версиях Enterprise и Datacenter, которые стоят не дешево, зато они дают право на бесплатное использование определенного числа гостевых ОС. Hyper-V Server сам по себе бесплатен, но все гостевые ОС должны иметь лицензии. Разумеется, речь идет только об ОС Microsoft. Из этого следует, что Hyper-V Server больше всего подходит для виртуализации уже действующей структуры, когда все лицензии уже куплены. Если же планируется развертывание инфраструктуры «с нуля», то Windows Server EE/DC может оказаться предпочтительнее по суммарной стоимости лицензий. Сравнивать с решениями VMWare я не возьмусь, поскольку плохо разбираюсь в их лицензировании. Тем не менее, бесплатный Hyper-V Server не требует покупки дополнительных лицензий на каждую фичу типа Live Migration или бэкапа виртуальных машин «на лету».

    На этом хотелось бы закончить – статья и так получилась слишком большой, свое мнение просьба высказывать в комментариях. Спасибо за внимание!

Комментарии

  1. >Сравнивать с решениями VMWare я не возьмусь, поскольку плохо разбираюсь в их лицензировании. Тем не менее, бесплатный Hyper-V Server не требует покупки дополнительных лицензий на каждую фичу типа Live Migration или бэкапа виртуальных машин «на лету».

    Не видно никаких противоречий в этих двух предложениях?

    Кстати, можно уточнить, что за “штатные возможности”, за которые надо платить?

  2. Противоречия нет – потому как в тонкостях я разбираюсь и правда не очень. Тем не менее, бесплатный ESXi уже требует обновления до полноценного ESX, если, к примеру, нужно использовать VMotion или VCB. Во всяком случае – так было в версии 3.5, как сейчас – не знаю. За Live Migration в Hyper-V Server платить не надо – это я и имел в виду.

  3. Александр, ну вот выберите позицию – или не разбираетесь и не упоминаете, или все же разбираетесь и сравниваете. А то на двух стульях как-то не очень получается.

  4. Ну так я упоминаю то, с чем столкнулся на собственном опыте. Если я не прав – прошу меня поправить. Готов даже поправить саму статью, если я сильно ошибаюсь.

  5. А можно поподробнее про бэкап Hyper-V “на лету”? Речь про бэкап всего раздела с помощью wbadmin?

  6. “Если кому-нибудь удастся запустить на Hyper-V, к примеру, FreeBSD или Solaris – буду рад, если поделитесь опытом”.
    Хе, а я наивно полагал, что ситуация обычная: не поддерживается, но ставится и нормально работает. А тут такое…….. 🙁

  7. > А можно поподробнее про бэкап Hyper-V «на лету»?
    System Center Data Protection Manager.
    И Symantec BackupExec в новой версии, кажется она называется 2010, должен поддерживать.

    > Хе, а я наивно полагал, что ситуация обычная: не поддерживается, но ставится и нормально работает.
    Не поддерживается официально. Соответственно – нет компонент интеграции, а следовательно – и синтетических устройств.
    Но я не говорил, что поставить _нельзя_. Возможно – и можно, и оно будет даже работать, просто я сам не пытался (ибо во всех операционках кроме MS разбираюсь слабо), потому и прошу написать, если кому-то это удавалось.

  8. > System Center Data Protection Manager.

    > И Symantec BackupExec в новой версии, кажется она называется 2010, должен поддерживать.

    Ну за них тоже платить надо. Это я к тому, что не стоило сравнивать с VMware.

  9. > Ну за них тоже платить надо. Это я к тому, что не стоило сравнивать с VMware.
    Насколько мне помнится, хотя сам я этого и не делал, можно делать резервную копию файлов виртуалки через VSS, хотя признаюсь честно – сам я этого не делал. В ESX версии 3.5 был VCB, за который надо платить. Вот я об этом.

  10. Бесплатно – только копию раздела целиком. И только тех виртуалок, в которых установлены компоненты.

  11. Сомнительное удовольствие Hyper-V Server (впрочем, как и очередное трололо “виртуализация MS vs VMware”)

    Вся его бесплатность хороша для “очень смолл бизнес” организаций – ибо ни нормальных инструментов управления/бэкарирования/оптимизации для него нет, не считая, конечно, продуктов SC. Хотя Powershell решает все.

  12. 11 >ибо ни нормальных инструментов управления/бэкарирования/оптимизации для него нет, не считая, конечно, продуктов SC.

    А почему же “не считая”?

    VMWare ESX тоже рулится в основном VirtualCenter’ом от самой VMWare, ну иногда еще какой-нить Veeam Backup прикрутят 😉

    Продукты System Center (VMM, DPM, etc.) – это такая же часть инфраструктуры. VMWare ESXi без VC тоже будет хорош разве что для “очень смолл бизнеса”.

  13. как я люблю темы про Hyper-VVMware… 🙂

  14. Александр, я рад, что Вы умеете читать между строк то, чего там нет. К чему Вы мне пишите про VMware?

    Суть предыдущего своего поста свежу к одной фразе: экономия на бесплатном HYper-V Server R2 сомнительна и теряется на фоне общей стоимости инфраструктуры, в которой есть описанные сами продукты семейства System Center. Экономить в таких маштабах на двух лицензиях полноценного Server 2008 Enterprise – тупость.

  15. >экономия на бесплатном HYper-V Server R2 сомнительна

    Видимо она сомнительна только вам, ибо на рынке HYper-V двигает VMware очень оптимистичными темпами.

  16. Что за манера на ИТБэнде к любой фразе о Hyper-V приплетать VMware, о котором даже речь не заводится, мной по крайней мере?

    Ок, еще раз, на этот раз для Ильи – экономить на хостовых операционках при имеющемся System Center – глупо. Не поверю, что серьезная компания, имеющая серьезную инфраструктуру, будет внедрять пресловутый бесплатный гипервизор, если опитимизировать и бэкапить его надо будет с помощью дорогостоящего SC – в чем выгода – в 4 килодолларах? В закупке лицензий на только виртуальные хосты и последующим геморроем?

    Этот продукт хорош для небольших “контор” с имеющейся и ненагруженной инфраструктурой, для консолидации и максимальной утилизации аппаратных ресурсов. Поднимать серьезный проект на Hyper-V Server – потом кусать локти. Какбэ имхо.

  17. >Что за манера на ИТБэнде к любой фразе о Hyper-V приплетать VMware

    Видимо потому что другие вендоры не имеют сколько нибудь значительного % рынка и потому что первые комменты всегда от VMware джедаев ))

  18. >Что за манера на ИТБэнде к любой фразе о Hyper-V приплетать VMware
    По моему так везде. Достаточно блог Антона почитать, как будто там нет ни слова про Hyper-V 😉

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

    Мы сейчас в виртуализации наблюдаем, то что было раньше в терминальных решениях. Был терминал от Microsoft И был аддонт от Citrix. До Windows Server 2008 пропасть между ними была огромной. Сейчас плюсов Citrix гораздо меньше, а стоят они все тот же самолет. Точно так же и с VMware будет. Пройдет релиз-два серверной ОС и разница между бесплатным Hyper-V и платным VMware будет минимальна и будет в очень-очень тонких ньюансах.

    Лично меня как тех.специалиста такая ситуация только радует. Нормальная конкуренция как бе

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

    Если кто-то считает себя истинным апологетом Hyper-V или ESXi – никто же не мешает. Только устраивать трололо из очевидных вещей…

  20. > Видимо она сомнительна только вам, ибо на рынке HYper-V двигает VMware очень оптимистичными темпами.

    “Рыночные” доводы я бы приводить не стал. Они в пользу качества продукта говорят достаточно косвенно. Видели ярлыки “лидер продаж” в эльдораде? 🙂

  21. >Видели ярлыки «лидер продаж» в эльдораде?

    Это другое, ребята хотят спихнуть товар и вешают яркий бантик. Есть обьективная реальность. Я у каждого потока спрашиваю “чем кипятите” и за последний год % говорящих, что кипятят H-V значительно вырос.

  22. > как я люблю темы про Hyper-VVMware…

    Дык кто ж их не любит… Круче только Windows/Linux наверное))

    14
    > Экономить в таких маштабах на двух лицензиях полноценного Server 2008 Enterprise — тупость.

    С одной стороны – возможно, что и тупость. С другой стороны, если от хостовой ОС ничего не требуется, кроме Hyper-V, и бесплатные лицензии на гостевые ОС не нужны – то почему бы и нет?

    > Что за манера на ИТБэнде к любой фразе о Hyper-V приплетать VMware

    Признаюсь честно: i did it for lulz. Почему-то статьи о виртуализации здесь часто сопровождаются срачем, даже вот самая безобидная статья о Live Migration – и первый же камент про VMWare. Так что здесь я, не буду таить греха, захотел помимо практической ценности статьи – еще и на вентилятор подкинуть )))

    > Не поверю, что серьезная компания, имеющая серьезную инфраструктуру, будет внедрять пресловутый бесплатный гипервизор, если опитимизировать и бэкапить его надо будет с помощью дорогостоящего SC — в чем выгода — в 4 килодолларах?

    Дело в том, что если внедрять Hyper-V на “полноценных” Windows Server – то это не избавляет от необходимости управлять и бэкапить, в частности, с помощью того же семейства SC. Так что экономия может получиться, особенно при большом количестве хостов. Кстати, SC не столь уж и дорогостоящ, особенно если сравнивать с аналогами других вендоров. И таки да, за счет экономии на WS2008EE можно вполне купить и VMM и DPM.

  23. > Это другое, ребята хотят спихнуть товар и вешают яркий бантик.

    Да нет, принцип тот же. “Дофига продали” это всего лишь “дофига продали”, и вовсе не обязательно “дофига проданный” товар лучше других.

    Много ли заказчиков используют отказоустойчивый кластер Hyper-V в продуктиве? Всем ли они довольны?

  24. Думаю скоро узнаем, кто, что и как использует: http://virt.cnews.ru/

  25. 23 >Много ли заказчиков используют отказоустойчивый кластер Hyper-V в продуктиве?

    Пока, к сожалению, не так уж много людей вообще его используют. Технология только-только выходит на рынок, и что греха таить – до версии R2 она была откровенно “сыровата”.
    Так что думаю, что когда R2 более-менее войдет в продакшн – тогда и будет и Hyper-V, и кластеры.

    Есть, кстати, еще один сдерживающий фактор – еще очень много серверов, не поддерживающих Hyper-V – с 32-битными или не поддерживающими VT процами.

  26. >«Если кому-нибудь удастся запустить на Hyper-V, к примеру, FreeBSD или Solaris – буду рад, если поделитесь опытом».
    Установлено FreeBSD 8.0 на вуртуальной машине Hyper-V, крутится почтовый сервак, за 2 месяца проблем пока никаких не возникало.

  27. 26, а можешь webcast на эту тему записать для TechDays.ru? Думаю, что Бешков (thhp://blogs.technet.com/abeshkov) даже что-нить презентует за это 😉

  28. И вдогонку: Дмитрий, я так понял, сетевой адаптер используется – Legacy?

  29. >захотел помимо практической ценности статьи — еще и на вентилятор подкинуть )))

    А VMware джедаи решили вдруг не вступать в холивор, пришлось самому изобразить видимость 🙂

  30. >26, а можешь webcast на эту тему записать для TechDays.ru? Думаю, что Бешков (thhp://blogs.technet.com/abeshkov) даже что-нить презентует за это
    Сейчас времени на запись webcast -a нет 🙁 может чуть позже.
    >И вдогонку: Дмитрий, я так понял, сетевой адаптер используется — Legacy?
    Да используется Legacy сетевой адаптер, как и написано в блоге Бешкова была проблема с перезагрузкой на Windows 2008 SP2, в R2 данной проблемы нет.

  31. Бешков сам писал статьи о том как установить FreeBSD на Hyper-V 🙂
    (http://blogs.technet.com/abeshkov/archive/2008/12/15/3169299.aspx)

  32. Сразу вопрос назрел, как обстоит с лицензированием. Когда покупается 2008 R2 Ent, а на самом деле ставится Hyper-v R2. Правильно же считать, что 4 лицензии на клиентские сервера должны работать и это не нарушение лиц.соглашения?

  33. Если хостовая ОС – WS2008R2 Ent – то можно запускать 4 гостевые ОС бесплатно. Если же хостовая ОС – Hyper-V Server – то на все гостевые ОС должны быть куплены лицензии. Так что в вашем случае, когда уже куплена Enterprise – смысла в Hyper-V Server особого нет.

  34. 2008 R2 Edition Comparison by Technical Specification
    http://www.microsoft.com/windowsserver2008/en/us/r2-compare-specs.aspx

    Смотрите строчку Virtual Image Use Rights

  35. 34 Об этом, кстати, говорилось в статье 😉

  36. Относительно бэкапа, на мой взгляд, проблема рассматривается не совсем полно. Обычно у компании (особенно у крупной) уже есть ПО для резервного копирования и если это ПО более-менее нормального уровня, то там уже есть поддержка большинства возможных систем, в том числе и hyper-v (сужу по используемому в моей компании Veritas Netbackup). Поэтому при выборе ОС для виртуализации проблема резервного копирования даже не рассматривалась.

  37. В крупных компаниях выбор платформы, и в частности платформы виртуализации, вообще редко идет на уровне тех. специалистов. Обычно это решение политическое и принимается советом директоров.

    “У нас все Microsoft!” или HP / IBM / подставить по вкусу.

  38. 37 Ну на самом деле, сами внедренцы на процесс выбора кое-какое влияние имеют, да и директора обычно к технарям стараются все же прислушиваться.
    Но конечно когда уже есть работающая инфраструктура – то тут уже стараются придерживаться “политики одного вендора” (и закупают монструозный и дорогущий OpenView/Tivoli вместо более простого и дешевого System Center 🙂

  39. Давно хотел уточнить:
    вот CSV.
    Томом владеет один сервер, остальные запросы на открытие файлов отправляют через него.
    А сами данные пишутся напрямую на диск, или через владельца тома?

  40. 39, ЕМНИП напрямую – иначе пропадает смысл в высокоскоростных SAN-сетях.

  41. я тоже так думаю, но меня убеждали и в другом варианте. Самому обращаться в первоисточники лениво, вот спросил, может тут подскажут.

  42. Больше всего опасений вызывает CSV, чисто потому, что в отличие от vmfs-дело молодое:)

  43. CSV костыль жуткий. Шутка ли, взяли некластерную файловую систему NTFS, смонтировали к нескольким хостам, при этом полноценно читает/пишет только один, остальные через ж… (Direct I/O) и дергают 1 хост (тот что полноценный) по сети по поводу изменения metadata. И честно предупредили, что не дай бог вам ребята записать что-то туда самостоятельно/случайно/троян/глюк… потеряете данные на томе. NTFS и так рушится бывает, а тут…
    Радужная перспективка…

  44. 43
    А можно подробнее раскрыть тему CSV? В частности, насчет “читает/пишет только один, остальные через ж…”? Просто мне казалось, что CSV – это как раз и есть кластерная ФС.

  45. MS если не ошибаюсь, прямо на семинарах TechNet об этом говорит. Что CSV – это такая хитрая SMB надстройка над NTFS.

  46. 43, 44:
    CSV вызывал поначалу опасения, да. И все верно, это надстройка над NTFS, но «читает/пишет только один, остальные через ж…» – совсем неправда, по несколько машин на одном CSV-томе живут вполне дружно. Поначалу это были тестовые, понятное дело страшно – сейчас уже и продуктивный SQL работает и пока полет нормальный.
    23:
    Много ли заказчиков используют отказоустойчивый кластер Hyper-V в продуктиве? Всем ли они довольны?
    10 физических хостов замечательно себя чувствуют в одном кластере, работает порядка 40 виртуалок. Да, большинство на CSV-томах и Live Migration работает. Пока всем довольны 🙂

  47. Вот только не надо утверждать что CSV заменяет кластерную файловую систему. CSV по сути грязный хак и его существование оправдано лишь нехваткой времени для реализации нормальной структуры кластера у MS (хоть бы GPFS или OCFS лицензировали на крайний случай или LustreFS).
    Опасения… хм, зависит от того насколько критична работа кластера виртуализации для бизнеса. А ну как том порушится, вероятность то далеко не нулевая?
    Вся жесть в том что том смонтирован с разрешением на запись для всех хостов кластера, но полноценно работать с томом может лишь 1 хост т.к. файловая система не умеет обрабатывать конкурентные обращения к метаданным. Хост, который полноценно монтирует том с NTFS полноценно является координатором обращения к метаданным, другой хост всегда будет обращаться к нему чтобы узнать в каких физических блоках находятся данные виртуальной машины, которая на нем запущена, а потом читать/писать блоки используя Direct I/O, т.е. прямой доступ к тому на уровне физических блоков данных без использования файловой системы. Тоже самое с блокировками, все держит хост-координатор, это логично (точной информации по структуре блокировок в CSV не нашел, подкиньте ссылку плиз). При установке CSV вас предупреждают, что если вы например захотите положить ISO файл на общий том (обычная практика для VMware к примеру), MS умывает ручки и NTFS может рухнуть. Честно говоря не рискнул еще попробовать такое, но как только завершу все манипуляции с тестовым Hyper-V и разберу все механизмы по косточкам, обязательно попробую создавать файлы на CSV. Учитывая что ходит куча троянов раскладывающих себя по всем дискам, да еще и в обход FS фильтров… жалко админа будет, он то думал что все по честному как с VMFS…
    В общем как обычно “Devil is in the detail”.

    http://www.vcritical.com/2009/09/hands-off-that-csv/

  48. Александр, немного не в тему . Не подскажите, почему при установки виртуальных машин под управлением WINDOWS 7 и WINDOWS 2008, после последней перезагрузки системы, она не стартует. Мигает курсор и все. А поставил WINDOWS XP SP3, все нормально.
    Заранее, спасибо.

  49. Spasibo vam ogromnoye za prostoy i ochen dostupniy doklad, napisanno vsyo chotko, dostupno i ponyatno. Blagodaryu Александр.

  50. “при покупке Windows Server 2008 предоставляется право бесплатного запуска (без покупки серверной лицензии) определенного числа гостевых ОС Windows Server в пределах одного физического хоста: одной – для версии Standard, ”

    Простите, а подскажите где можно прочитать “официально” про этот факт.

  51. Спасибо!
    ЗЫ
    Статья вцелом тоже полезна.

  52. 2 48: – 7 и 2008 зависают у Вассразу после установки потому, что пиратские ) Вшита кривая эмуляция БИОСа.

  53. Поставил 2008 R2 EE как HOST. Интересует как проходит лицензия VM. 4 машины должны, насколько понимаю, работать под лицензией хоста, то есть мне нужно активируя виртуальную машину ввести 25-изначный код хоста и все должно работать? Или это работает как то иначе? Нет желания сжечь лишении лицензии, это может плохо закончится для меня 🙂
    Заранее благодарен!

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

  55. А разве не должен в коробке с дистрибутивом WS 2008 идти два ключа (или серийных номера, не знаю, что правильно). Первый для физической установки, второй для виртуальной?

  56. @56
    Да не было такого. Ключ один всегда.

  57. Добрый день господа хорошие!
    Согласен что Hyper-V это предпочтительнее для рынка SMB -внедрял, все прекрасно работает.- при этом обошлось всего то … естественно при условии небольших объемов ИТ-сервисов.
    На данный момент работаю в крупной организации в СПБ где стоят SAN от HP EVA StorageWorks + Switched Fabric + VmWare VmSphere 4.1, более 40 виртуальных серверов + SQL Server 2008 R2 для vCenter Server + три полки HP. И поверьте все это стоит очень дорого, просто очень дорого, при том чего стоит только лицензия vmSphere Enterprise Plus. Такое может позволить себе только такая организация для которой 48000$ это так себе за хлебушком сходить! Реально такое решение оправдает себя только при очень большом количестве серверов и служб, при которых очевидна экономия хотя бы в части электроэнергии и уменьшении железа.

  58. Безусловно, в крупной компании, где уже развернута инфраструктура на VMware, намного легче перейти на новую версию vSphere, чем переводить это все на Hyper-V. Тут главное не оказаться однажды в положении Сбербанка, вынужденного до сих пор поддерживать древний, как навоз мамонта SCO Unix.

  59. Может получится у вас ответить на такой вопрос.
    Как сделать так, чтобы при миграции две системы, которые соединены друг с другом через Private network видели друг друга если они находятся на разных нодах кластера?

  60. В актуальной версии Hyper-V – никак. Private networks на то и private, что работают внутри хоста и не смотрят наружу. Того, что у конкурентов называется Distributed vSwitch у Hyper-V нет. Возможно появится в Windows Server 2012, но пока точно сказать не готов.

    У вас есть два варианта: либо добавить на сервера отдельные сетевушки для этой “типа-private-сети” и соединить их между собой, либо юзать VLAN’ы.

  61. К примеру, я не могу использовать решение SC, т.к. он действительно дорогое. Мне нужно только две вещи: бакап ВДС и траффик! Траффи можно считать через http://www.hoststools.com/index.php/bandwidth-meters/hyper-v-bandwidth-meter-20-released/, как сделать бакап ? VSS жутко глючная, все какие ошибки выдает, на 2Тб винтах думает до невозможности, есть ли решение ?

  62. Добрый день, у меня пару вопросов по поводу этой статьи, если кому не трудно ответье плиз:
    1)”При использовании CSV на системном диске создается папка ClusterStorage, и все дисковые устройства, используемые как CSV, монтируются в ней как подпапки в виде C:ClusterStoragevolume1″
    Это означает что по данному пути C:ClusterStorage монтируются подпапки указатели (subst’ы), т.е. физически все данные располагаются нанашем хранилище, а там просто ссылки которые юзаются потом виртиуальными машинами?
    2) Допустим есть такая схема, и поднимем виртуальную машину с exchange, и к ней подключим напрямую диск с NAS (например через iscsi) И разместим на ней storage. В этом случае при падении 1 из серверов live migration пройдёт без сбоев и виртуальная машина с exchange на другом сервере поднимется без проблем с такими же настройками?
    Я к тому, что можно использовать CSV для хранения виртуальных машин, а вот для хранения критически важных данных подключать отдельно диски напрямую с хранилища?

  63. 1. Да, это всего лишь ссылки. Примерно как симлинки в линуксе.
    2. iSCSI вообще работает софтверно внутри гостевой ОС. Поэтому если СХД будет доступна по сети с другого хоста – заведется без проблем. Единственно, что в случае падения хоста live migration не будет, а будет Failover. Для гостевой ОС это будет выглядеть, как будто ее “выдернули из розетки” а потом включили опять.

    Да, именно так. Использовать CSV для чего-то другого кроме хранения самих виртуалок MS открытым текстом запрещает. То есть это unsupported.

  64. Интересует вопрос, возможно ли создать failover-кластер из двух узлов находящихся далеко друг от друга, используя выделенную линию интернет?

  65. Можно, более того – так даже делают, и называется это “геокластер”. Единственное – канал должен быть достаточно широким, и самое главное – задержки должны быть достаточно малыми, иначе кластер будет постоянно думать что отказал то один, то другой узел и будет котовасия.

  66. Отказоустойчивость виртуальных машин и их хостов на высоте, но что вы посоветуете в плане отказоустойчивости NAS систем хранения? (что будет в случае, если ваш iscsi массив “отвалится” по какой либо причине)

  67. Отказоустойчивые SAN-решения: СХД с двумя контроллерами, репликацию на уровне СХД и Multipath IO.

  68. правильно ли я понимаю, что если у нас предположим диск с SAN по FC подключен к одной (предположим первой – узел-координатор) ноде – point-to-point, и там размещен CSV, то при миграции виртуалок на вторую ноду, запись в CSV данных и метаданных от второй ноды ВСЕГДА будет идти через первую ноду? иначе как вторая нода попадет к луну на СХД….

  69. @69. Нет. При мирации виртуалок – если речь о Live Migration – файлы физически остаются там же, где и были – LUN-то общий. Далее. Если виртуалка запущена не на узле-координаторе – то по SMB идут только метаданные. Сами данные будут идти непосредственно от ноды к СХД по SAN. И только в некоторых случаях будет включаться Redirected IO Mode, когда и данные и метаданные будут идти по SMB через ноду-координатор. Например, если у ноды пропал доступ к SAN (грубо говоря – кабели оборвали). Или когда запущен бэкап – CSV переключается в Redirected-режим (в Windows Server 8, кстати, это обещали пофиксить).

  70. Алексей, вроде понятно, что ничего не понятно %)

    да, речь идет о Live Migration.

    1) Сами данные будут идти непосредственно от ноды к СХД по SAN (c)

    через ноду-координатор? иначе как? СХД подключен тока же к ноде-кординатору точка-точка к примеру.

    2) вот например в Exchange2010 для роли сервера mailbox можно сделать DAG – используя failover cluster. и это будет работать даже когда один сервер (предположим их два) полностью выключится. потому что в этой системе к каждому серверу с ролью mailbox подключен свой Lun.
    тогда какой выигрыш по-настоящему он постройки кластера в данной статье (используя как раз CSV) если нода-координатор, к которой подключен LUN с CSV выключится например?

  71. Алексей, прочел.
    в этой статье хотел спросить про режим Direct IO, когда переместили VM2 на Node 2.
    оттуда:
    Поток данных идет так же напрямую через драйвер фильтра CSV, затем драйвер NTFS, драйвер устройств хранения и по SAN к самой СХД. (с)

    хорошо. CSV позволяет нескольким узлам осуществлять запись в один физический LUN одновременно. у меня вопрос в том физически как вы подключаете node 2 к полке? вот есть SAN ну с предположим одним контроллером на котором два оптических интерфейса. один оптический интерфейс я соединяю с оптическим HBA на node 1. На SAN я создаю дисковой ресурс, который маплю на node 1 которую я увижу на SAN после соединения SFP контроллера полки с HBA node 1. а как быть с node 2? после соединения node 2 ко второму оптическому интерфейсу на контроллере SAN мне позволительно будет разве примапить его так же к ЭТОМУ ЖЕ дисковому ресурсу, который уже используется node 1? полка ничего на это “не скжает”?

  72. Конкретно в этой статье использовалось iSCSI по той же самой сети, что и все остальное.

    А вообще – ставятся HBA в каждый узел, и подключаются через SAN-свитч к контроллерам СХД.
    Лучше всего даже – в каждый узел по 2 HBA (или по одному 2-портовому), и схема следующая:
    Node1 Port1 – Switch1 – Controller1 Port1
    Node1 Port2 – Switch2 – Controller2 Port1
    Node2 Port1 – Switch1 – Controller1 Port2
    Node2 Port2 – Switch2 – Controller2 Port2

    При такой схеме каждый узел подключен к двум разным контроллерам через два разных свитча, что дает хорошую отказоустойчивость.

    Затем, после того как создали LUN – нужно переписать WWN’ы всех портов HBA и примапить LUN ко всем WWN’ам, которые будут с ним работать.

  73. Интересная стаейска даже выполнил у себя до половины но застрял на этапе “Наконец-то мы добрались собственно до сборки кластера. Все операции с кластером будут осуществляться через консоль Failover Cluster Managemer (далее – FCM).” Вот вот тобишь чтобы собрать кластер нужно прибегнуть к помощи Windows Server Enterprise Edition потому как в Standart edition (мой контроллер домена) его нет. То есть все эти трололо по поводу бесплатности уперлись в 5косарей бакинских и имея два бесплатных hyper-v server 2008 r2 sp1 – я курю в сторонке и кластера мне не поднять?

  74. @75
    Я ставил Remote Server Administration Tools (RSAT) на обычную клиентскую Windows 7, и оттуда запускал и Failover Cluster Manager, и Hyper-V Manager.
    Насколько мне помнится, можно зайти в Add Features и добавить оснастку Failover Cluster Manager и на WS2008R2 Std. На ней нет компоненты Failover Clustering – это да, но оснастка должна быть. Увы, пока что не на чем проверить.

  75. Александр, а необходим ли диск кворума при трехнодовом кластере?
    Можно ли обойтись без него?

  76. Для трех нод пойдет модель Node Majority. Кластер переживет падение одной ноды из трех.
    http://www.osp.ru/win2000/2008/03/5270426/

  77. А пройти тест валидации на рабочем кластере потом получится? Других дисков кроме CSV в кластер не заведено.

  78. Получится, почему нет?

  79. Просто он тогда не проводит тесты дисковой системы и iscsi

  80. Александр, а почему в этом примере использовалась виртуалка DC в качестве контроллера домена и системы хранения данных? можно ли подобную отказоустойчивую систему реализовать без DС, используя для вышеперечисленных задач Server?

  81. Без AD не получится – кластер не соберется.

  82. Ну без Active Directory понятно, что не соберется) я к тому, что можно ли поднимать AD сразу на хостовой машине, а не на виртуалке, которую мы поднимаем на этом хосте?
    И вот еще один вопрос (я просто сейчас делаю диплом и за основу взял Вашу статью) –
    “Открываем консоль Server Manager, подключаемся к Node1 и идем Storage – Disk Management” – вот на этом месте Server Manager выдает знаменитую ошибку “THe RPC server is unavailable”. В чем может быть проблема? Заранее, Спасибо:)

  83. Ну без Active Directory понятно, что не соберется)
    И вот еще один вопрос (я просто сейчас делаю диплом и за основу взял Вашу статью) –
    “Открываем консоль Server Manager, подключаемся к Node1 и идем Storage – Disk Management” – вот на этом месте Server Manager выдает знаменитую ошибку “THe RPC server is unavailable”. В чем может быть проблема? Заранее, Спасибо:)

  84. Ну без Active Directory понятно, что не соберется) Я к тому, что можно ли поднять домен на хосте сразу, избегая создание виртуальной машины DC для этой цели?
    И вот еще один вопрос (я просто сейчас делаю диплом и за основу взял Вашу статью) – Подключаюсь к Server Manager – Node1 – Disk Manager, чтобы проинициализировать диски quorum и storage, но Server Manager выдает известную ошибку “The RPC server is unavailable”. В чем может быть проблема? Starwind стоит, все настроено, в гипервизоре таргеты настроены и подключены.

  85. Поднять домен на хосте – можно, в случае “полноценного” Windows Server 2008 R2. Но с точки зрения Best Practices – это не по фэнь-шую. На хосте не должно быть вообще ничего, кроме гипервизора. Ну, еще можно агента системы бэкапа поставить.
    В статье же речь идет про Hyper-V Server – это, в отличие от Windows Server – отдельный продукт, который может выполнять только одну роль – хоста виртуализации. Поэтому поднять на нем DC не получится.

    Что касается ошибки в MMC – нужно открыть порт в фаерволле для службы Virtual Disk Management. Вроде в вебкасте я это показывал: http://www.techdays.ru/videos/2313.html

  86. И, кстати, Microsoft давно сделали свой iSCSI Software Target бесплатным, можно попробовать его вместо StarWind.

  87. Я понимаю разницу между полноценным Win Server и Hyper-V Server:) и сейчас попытаюсь поднять кластер по следующей схеме (для диплома мне подойдет и эта упрощенная модель) – На хосте установлен Win Server 20008r2 sp1 enterprice, сразу поднят домен и роль Hyper-V (все без виртуальной машины DC), стоит Microsoft iSCSI Software Target. На двух узлах поднят Hyper-V Server 2008r2 sp1. Надеюсь, что все получится)
    Спасибо большое Вам за советы и эту статью!

  88. > И, кстати, Microsoft давно сделали свой iSCSI Software Target бесплатным, можно попробовать его вместо StarWind.

    Разница между ними как между велосипедом и самолётом. Для малых проектов подойдёт и чистый МС, а для всёго более-менее нагруженного – предпочтительней будет SW. Просто МС плохо грузит полосу прорускания. В среднем 25-50 процентов. SW 60-80. Вот и считайте дивиденды. А в случае HA хранилища вообще бессмысленно говорить о МС.

  89. Не знаю, мы тестили MS iSCSI Target – результаты нормальные для iSCSI. И почему для HA не подойдет? С persistent reservation оно вполне дружит. Ну а для высоконагруженных проектов, я бумаю, нужно FC юзать вместо iSCSI. iSCSI – это “SAN для бедняков”.

  90. Сделано уже откладывать читать сайт и о досуг, перейти копии швейцарских часов ролекс

  91. Сделано вон откладывать посмотреть сайт о вечеринке, тут где можно записать песню

  92. Хорошо вон обзавелся смотреть новость вечеринке… тут здесь

  93. Ваш комментарий

  94. Не понимаю, как тут комментарии читать. Половина так оформлена, половина – иначе.
    Даты пляшут

  95. “Использовать CSV для чего-то другого кроме хранения самих виртуалок MS открытым текстом запрещает. То есть это unsupported.”
    Хотелось бы развить эту тему. Насколько актуально сейчас, в 2012 R2? Можно ли смело пользоваться в энтерпрайзе этой технологией?

  96. Подскажите пожалуйста решение, вопрос про отказоустойчивую кластеризацию.
    Вобщем есть два сервака и схд. Как будет более правильнее?:
    1 Поместить роли AD и DNS на железо (на обоих серверах), а кластер с ролями (файл-сервер и DHCP) на Hyper-V (на обоих серверах)?
    2 Поместить роль кластера на обоих серваках на железо, а AD с DNS на Hyper-V?
    3 Поместить на одном из серваков AD и DNS на железо, а роль кластера на виртуалку, а у второго ровно наобот?

    Если 1 вариант правильный, то надо будет включать и выключать сервера в определенном порядке, а неправильное выключение может привести к сбою кластера?

  97. Best practice – иметь отдельный, “железный” контроллер домена. Железо может быть самое простое, вплоть до десктопа или старого, уже не используемого сервера. Последовательность запуска должна быть такова, чтобы этот контроллер домена запустился раньше, чем все остальные сервера. Официально – начиная с 2012 сервера кластер может стартовать и без AD, но все же лучше, чтобы AD было – его отсутствие может вызвать кучу “мусора” в Event Log’ах, вроде бы с Exchange могут быть проблемы, если его стартовать без доступа к AD (эксченджисты меня поправят).

    (Сорри, похоже движок глючит)

  98. Сотый комментарий для ровного счета.

  99. Добрый “что там у вас сейчас”.
    Хотел бы спросить у знатоков.
    Есть такая конфига: HP blade шасси c3000 по с двумя серверами.
    Есть хранилка HP 6300 Eva .
    Создано 4 LUna: System 1 node; System 2 Node; Quorum: CSV.
    соответственно каждой ноде презентованы Quorum и CSV и по системному Lunу.
    Установленны Hiper-V server 2012 на каждом серваке. 2 сетевые на серваке, одна для хербитов (192.168.1.0.24) другая для управления (192.168.0.0.24) .
    Короче все по мануалам. По сути.
    Запускаю виртуалку, хранится на CSV ClusterStorage/Volume1.. Все кластерные диски принадлежат ноде, при миграции, перносе, и возвожных мувах виртуалка ходит без отказно.. Все просто отлично.
    Но стоит только физически потушить ноду которая в данный момент главная. кластер разваливается..
    если выключить не главную ноду все работает, и машинка сама переезжает.
    Заметил такую особенность что кластерные диски не могут сменить владельца. Тоесть не главная нода видит примонтированный CSV и работает с него, но если главное нода ребутится сама стать главное не может.
    Есть мысли с лету, или еще конфиг по описывать?

  100. Сори за опечатки, с телефона по дороге домой писал.

  101. Так.. разобрался..
    в настройках SAN HP P6300. В профиле хоста можно выбрать либо Microsoft Windows, либо Microsoft Windows 2008. так вот у меня было первое, я поменял на второе и все стало гуд..
    Бывает же..

  102. Да что же такое то!!!!! Парни, в очередной раз выручаете! Всё доходчиво, расписано всё подробно даже для тех, кто не знаком с кластеризацией. Спасибо ещё раз!

  103. Комрады! Имееется hyper-v кластер w2012r2 и поключенным SAN по FC.
    Поясните нюанс – как при кластеризации существующей и экспортированной вм сохранить ее структуру папок :
    , внутри Snapshots, Virtual Hard Disks, Virtual Machines ну и диски настройки и снимки внутри соответственно.
    Как правильно переносить, есть опасения при ручном переносе, но подтверждений не нашел. на течнет описание кластеризации вм скудно.
    для w2008r2 https://technet.microsoft.com/ru-ru/library/dd759216.aspx
    для w2012r2 https://technet.microsoft.com/ru-ru/library/jj863389.aspx#BKMK_step7

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