none
Виртуализация и кластеризация RRS feed

  • Вопрос

  • Здравствуйте.

    Имеются 2 сервера Sun X4600 M2, а также СХД EMC cx3-10c, каждый из серверов подключен к СХД с помощью 4Гбитной оптики.
    Собираемся покупать для них два Windows Server 2008 R2 Enterprise.
    Пока не купили лицензии, будем всё разворачивать на триале.

    Собираемся развернуть на каждом из серверов Hyper-V и поднять Failover Cluster.

    Вопросы:
    1. В рамках лицензирования Win Server 2k8r2 Ent сколько ОС в виртуальной среде мы имеем право поднять с учетом того, что сервера будут кластеризованы?
    2. В каждом из серверов имеется по четыре гигабитных сетевых адаптера, сначала планировалось все агрегировать в один 4Гбитный канал, но покурив мануалы по Failover Clustering оказывается, что желательно (обязательно?) выделять отдельный адаптер на каждом сервере для Heartbeat, кроме того, в мануалах по hyper-v говорится, что не желательно смешивать (использовать) сетевые интерфейсы хостовой и гостевых ОС. Все это приводит в некоторое замешательство...
    Как же в итоге правильно организовать сетевые подключения применительно к вышеописанной конфигурации? (iSCSI использовать не собираемся, есть FC).
    3. Как правильно организовать (подключать) диски к системе:
    • Создать один RAID массив и один LUN, который будет подключен к обоим хостовым ОС, и на котором будут располагаться файлы VHD;
    • Создать один RAID массив и множество LUN`ов, которые будут подключены к обоим хостовым ОС, по одному для каждой гостевой ОС, где также будут располагаться файлы VHD;
    • Создать одни RAID массив и множество LUN, которые будут подключены только к гостевым ОС, т.е. установка будет производиться именно на них без создания VHD - файлов;
    • Ваш правильный вариант?

    Спасибо.

    18 октября 2009 г. 10:37

Ответы

  • По поводу лицензирования в кластере Дмитрий Алифатов довольно развернуто ответил здесь - http://social.technet.microsoft.com/Forums/ru-RU/licenseru/thread/9ee51492-65fd-4333-88a9-a18a785d4746



    По поводу сетевых интерфейсов. В любом случае live migration нужно вешать на отдельный интерфейс - для минимизации времени "перехода" ВМ с хоста на хост.

    • Помечено в качестве ответа kdesys 18 октября 2009 г. 14:25
    18 октября 2009 г. 14:01
    Модератор
  • к сожалению, dynamic memory management так и остался на уровне "закрытых" бета версий.
    посмотреть на него можно в одном из докладов а. Кибкало на Hyper-v.ru
    в живой системе(RTM build 7600) такой фичи нет.
    2х узловой кластер требует резервирования 1/2 ОЗУ
    3х узловой - 1/3
    ситуация аналогична потерям полезного дискового пространства в RAID5 - чем больше дисков - тем меньше потери.


    Заходите в "гости" на http://kupchinetsky.spaces.live.com
    • Помечено в качестве ответа kdesys 19 октября 2009 г. 14:54
    19 октября 2009 г. 14:51
    Отвечающий

Все ответы

  • Лицезирование кластеризированных ОС, насколько я в курсе, ничем не отличается от, соответственно, от одиночного Windows Server. Т.е. Вашем случае Вы можете поднять 8 виртуальных машин.

    По второму пункту - в идеале Вам необходимо три сетевых адаптера - хёртбит, интерфейс для управления ВМ и интерфейс для сетей виртуальных машин.

    3. Все будет зависеть от того, какой способ кластеризации Вы выберете http://blogs.technet.com/josebda/archive/2008/06/17/windows-server-2008-hyper-v-failover-clustering-options.aspx

    http://technet.microsoft.com/en-us/library/cc732181(WS.10).aspx
    18 октября 2009 г. 11:34
    Модератор
  • Лицезирование кластеризированных ОС, насколько я в курсе, ничем не отличается от, соответственно, от одиночного Windows Server. Т.е. Вашем случае Вы можете поднять 8 виртуальных машин.
    Прежде всего, спасибо за Ваш ответ.
    Меня беспокоит вот что: раз это отказоустойчивый кластер, значит в случае выхода из строя одной из нод (сервера), его виртуальные машины будет обслуживать другая нода.
    Таким образом на одном физическом сервере будет обслуживаться 8 виртуальных машин.
    И это разрешено с точки зрения лицензирования?
    По второму пункту - в идеале Вам необходимо три сетевых адаптера - хёртбит, интерфейс для управления ВМ и интерфейс для сетей виртуальных машин.
    Как бы Вы реализовали это решение применительно к нашей конфигурации?
    NIC 1 - heartbeat + live migration
    NIC 2 - LAN for host
    NIC 3 + 4 = 2Gbit/s LAN for guests
    Так я понимаю?
    3. Все будет зависеть от того, какой способ кластеризации Вы выберете http://blogs.technet.com/josebda/archive/2008/06/17/windows-server-2008-hyper-v-failover-clustering-options.aspx

    http://technet.microsoft.com/en-us/library/cc732181(WS.10).aspx
    Если рассматривать варианты приведенные по первой ссылке, то конечно вариант 1.
    Но что-то мне не очень нравится вариант собственно VHD, хотя для live migration как я понимаю, только он и подходит.
    18 октября 2009 г. 13:11
  • По поводу лицензирования в кластере Дмитрий Алифатов довольно развернуто ответил здесь - http://social.technet.microsoft.com/Forums/ru-RU/licenseru/thread/9ee51492-65fd-4333-88a9-a18a785d4746



    По поводу сетевых интерфейсов. В любом случае live migration нужно вешать на отдельный интерфейс - для минимизации времени "перехода" ВМ с хоста на хост.

    • Помечено в качестве ответа kdesys 18 октября 2009 г. 14:25
    18 октября 2009 г. 14:01
    Модератор
  • С лицензированием, сетями и хранилищем вроде разобрался.
    Теперь интересует как Failover Cluster + Hyper-V использует оперативную память при своей работе?
    Например, на одном из серверов поднята одна виртуальная машина и её выделено 30Гбайт ОЗУ, а на втором подняты три виртуальные машины, на которые поровну распределены те же 30Гбайт ОЗУ.
    Вопросы:
    1. Как поведет себя Failover Cluster + Hyper-V если мы захотим осуществить, скажем, Live Migration одной из виртуальных машин с одного сервера на другой? 
    2. Будет ли каким-то образом распределена ОЗУ между всеми виртуальными машинами или миграция просто не осуществима?
    3. Надо ли оставлять резерв ОЗУ на обоих серверах для запланированной миграции или миграции в случае отказа одного из серверов? (в таком случае получается, что придется использовать всего-лишь половину ОЗУ на каждом сервере, а другая половина будет все время простаивать)...

    • Изменено kdesys 19 октября 2009 г. 7:47
    19 октября 2009 г. 7:44
  • чудес не бывает. нужно резервировать
    19 октября 2009 г. 7:47
  • То есть 32 Гбайта из 64х будут простаивать... Грустно...
    19 октября 2009 г. 7:50
  • это расплата за отказоустойчивость.

    хотя читал что, в версии Hyper-V2 , можно во включенной VM изменять оперативную память, это если гостевые системы w7 и w2k8r2 , ну чтобы они поддерживали хотсвап по памяти, тогда при миграции вначале можно можно уменьшить им память и потом тока мигрировать... но это тока в теории :)
    • Предложено в качестве ответа Dmitry Rudykh 19 октября 2009 г. 8:28
    19 октября 2009 г. 7:54
  • хотя читал что, в версии Hyper-V2 , можно во включенной VM изменять оперативную память, это если гостевые системы w7 и w2k8r2
    О_о, это очень интересно, может и правда работает уже сейчас? Где вы это читали, дайте ссылку пожалуйста.
    19 октября 2009 г. 8:17
  • Во время работы виртуальной машины можно также управлять и выделением ей памяти. Можно задать minimum и maximum memory из общего пула памяти хоста Hyper-V. По аналогии с VMware ESX, в гостевой ОС работает balloon driver.

    http://www.vmgu.ru/articles/hyper-v-r2
    19 октября 2009 г. 14:31
  • к сожалению, dynamic memory management так и остался на уровне "закрытых" бета версий.
    посмотреть на него можно в одном из докладов а. Кибкало на Hyper-v.ru
    в живой системе(RTM build 7600) такой фичи нет.
    2х узловой кластер требует резервирования 1/2 ОЗУ
    3х узловой - 1/3
    ситуация аналогична потерям полезного дискового пространства в RAID5 - чем больше дисков - тем меньше потери.


    Заходите в "гости" на http://kupchinetsky.spaces.live.com
    • Помечено в качестве ответа kdesys 19 октября 2009 г. 14:54
    19 октября 2009 г. 14:51
    Отвечающий
  • ах как жаль. на презентация Hyper-V 2 так этим гордились :) я думал что реализовали...
    19 октября 2009 г. 17:40