none
SCVMM16 + Hyper-V 2016 RRS feed

  • Вопрос

  • Доброго времени суток, коллеги!

    Чейгойто запутался. Выручайте

    Имею три железки. Голые

    Имею дистрибутивы W2K16, SQL 2016 и SCVMM16

    И, чисто теоретически, имею рабочую станцию под W10

    Хочу получить инфраструктуру SCVMM16, полностью отвечающую требованиям феншуя, а именно:

    • На серверах - nano
    • VMM - в кластере
    • SQL - в кластере
    • Library - тоже в кластере
    • VMM, SQL и Library - на виртуалках

    Кто-нибудь может нарисовать последовательность действий? Хотябы в общих чертах, без подробностей

    Один из затыков: чтобы поставить тот же VMM, мне надо, чтобы кластра с SQL и Library уже были подготовлены. Но, с другой стороны, как показывает экспириенс, кластеры с vhds, созданные на голых Hyper-V не особо потом рулятся в VMM...

    11 апреля 2017 г. 13:21

Все ответы

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

    Если VMM 2016 умеет работать с SQL в режиме AlwaysOn, то этот вариант будет предпочтительнее в Вашем случае.

    11 апреля 2017 г. 13:49
  • Общая система хранения в наличии имеется, забыл указать.

    SAN, все дела

    Как и общая сетка с кучей вланов)

    О каком именно AlwaysOn идёт речь? Об Always On Failover Cluster Instances или Always On Availability Groups? И как мне это поможет в вопросе кластеризации самого VMM и Library?

    11 апреля 2017 г. 14:36
  • AlwaysOn для SQL имелся в виду. Этот метод "кластеризации" позволит обойтись без общего кластерного тома и упростить реализацию в виртуальной среде.

    Library - это просто файловый сервер, поэтому берете любое руководство по настройке кластеризованного файлового сервера и делаете по нему.

    VMM до версии 2012 работает в режиме активный/пассивный (про 2016 не в курсе).

    Если кратко, то:

    1. Поднять и настроить SQL в кластере.

    2. Поднять и настроить файловый сервер (для Library) в кластере.

    3. Установить VMM, указав на внешний SQL и Library.

    11 апреля 2017 г. 15:05
  • Они как бы оба зовутся AlwaysOn..

    Судя по описанию, речь идёт об Availability Group. Однако, на мой взгляд, если все ноды кластера и их диски расположены физически в одном SAN, то AG использовать (а) бессмысленно и (б) вредно

    И возвращаемся к тому, откуда начали: чтобы создать управляемый через VMM кластер мне надо, чтобы VMM уже был. Но, для установки VMM в отказоустойчивой конфигурации требуется, чтобы кластера с MS SQL и Library уже были подготовлены... Прямо какой-то сепультарий честное слово )

    12 апреля 2017 г. 14:42
  • Использовать Availability Group или нет дело выбора в конкретной ситуации. У решения есть свои плюсы и минусы.

    Для создания кластера Hyper-V не нужен VMM - никто не запрещает Вам поднять кластер средствами консоли MCS, в нем нужные ВМ, а потом эти ВМ и кластер подключить в консоль VMM.

    13 апреля 2017 г. 10:03
  • Кластер, поднятый средсвами консоли MSC (если мы говорим про кластер с единым сторажем), при подключении к VMM отличается от кластера, созданного через service templates. В плане управления.

    Я сам не видел, но судя по посту http://blog.tmurphy.org/2015/12/creating-hyper-v-guest-cluster-using.html в 2012r2 у созданного через MSC кластера VMM не даёт ничего менять.

    В 2016 ситуация чуть лучше (вот это я проверял): vmm даёт рулить почти всеми параметрами, однако совершенно не видит (и, соответственно не даёт менять) никакие параметры shared дисков.

    13 апреля 2017 г. 10:18
  • Самый больной вопрос - кластер SQL. Общий VHDX использовать не обязательно. Навскидку варианты:

    1. SMB

    2. Виртуальный FC

    3. iSCSI

    Очень примерная последовательность действий:

    1. Поднимаете на сервере роль Hyper-V 

    2. Разворачиваете ВМ для DC, SQL, VMM (по одной для каждой роли)

    3. Вводите хост и виртуальные машины в домен

    4. Поднимаете кластер SQL из одного узла. Базу можно временно разместить на любой шаре (потом перенесем). Library тоже временно сделайте на любой шаре.

    5. Устанавливаете SCVMM. Обязательно делайте деплой как кластера!

    6. Вводите хосты в AD и SCVMM. Настраиваете сети, кластеры.

    Все, дальше доделайте кластер SQL (перенести базы данных), Library. Тут уже надо смотреть, что у вас есть и какие предпочтения. Факт в том, что все решаемо. 

    По Library - вы еще подумайте, нужна ли отказоустойчивость. Может "и так сойдет" :)

    13 апреля 2017 г. 10:44
  • Да, еще. После того, как развернете кластер Hyper-V (через VMM), перенесите в него ваши ВМ (Live storage migration).
    13 апреля 2017 г. 10:45
  • Во!

    Что-то похожее на ответ, благодарствую!

    Однако:

    Имея шестнадцатигегабитный мегаSAN за 100500 денег смотреть в сторону SMB/vSAN/iSCSI.. я первый себя не пойму :-D

    Неувязка в предложенном алгоритме заключается в том, что я не нашёл, как средствами VMM2016 создать кластера с общими дисками "вручную". Только через сервисы. А это автоматически делает невозможным развернуть этот функционал на базе существующих виртуалок. Только "с нуля"

    На счёт "и так сойдёт", я ещё сам для себя не решил, хочу ли я всё делать настолько отказоустойчиво. Ибо, пока не уверен, что затраты и сложность в построении и обслуживании такой вот махины перевесят риски от пяти-десяти минутного простоя указанных сервисов в случаях каких-то непредвиденных ситуаций (наврядли лежащий в основе всего этого добра "железный" кластер потратит больше времени на перезапуск виртуалок). Коль скоро задача внедрения Network Conrollerов пока не сторит (а вот там, как я понимаю, SQL лучше бы был доступен 24x7), то возможны варианты. Поэтому, интерес пока больше академический )

    Пока что единственный жизненный вариант вырисовывается такой:

    1. Поднимаем роль Hyper-V, вводим в домен
    2. Разворачиваем VM для SQL и VMM (DC уже имеются)
    3. Поднимаем временный SQL в безкластерной конфигурации
    4. Поднимаем SCVMM, деплой "как кластер", Library где-нибудь (вариант - локально на SCVMM)
    5. Делаем из VMM кластер под SQL (с нуля)
    6. Делаем средствами VMM второй кластер пол Library
    7. Переносим базу с временного на кластеризованный SQL
    8. Добавляем кластеризованный Library
    9. Добавляем второй узел для VMM (этот кластер общего диска не имеет, поэтому проблем возникнуть не должно)

    Вроде всё

    Как-то IMHO заковыристо получилось.. :-D

    13 апреля 2017 г. 11:02
  • 4. При отказоустойчивом развертывании локально не получится. Потребует шару. Можете на хосте временно сделать, потом удалите эту и создадите новую.

    7. Надо будет удалить VMM без удаления базы. Затем перенести ее на новый  SQL и установить VMM снова (указать кластер как сервер БД). Просто поменять сервер БД в SCVMM нельзя. Есть, конечно, "хаки", но лучше делать правильно.

    13 апреля 2017 г. 12:04
  • 4. Кстати шару не требует... Просто ставится без библиотеки и всё. Хотя, конечно, добавить в любом случае придётся, ибо как я гостей-то ставить буду :-D

    5. В таком случае и сам vmm можно ставить на временный хост

    13 апреля 2017 г. 12:28
  • 1. До внедрения VMM и SQL собираете кластер из физических гипервизоров, с подключением к SAN,
    2. На кластере Hyper-V для нужд библиотек VMM и дисков-свидетелей разворачиваете гостевой кластер файлового сервера с использованием виртуальной Fibre Channel (у Вас же FC SAN?),
    3. На кластере Hyper-V разворачиваете гостевой кластер баз данных SQL (классический или AlwaysON — другой вопрос, в такой конфигурации не принципиально), с использованием той же виртуальной FC SAN,
    4. На кластере Hyper-V разворачиваете гостевой кластер VMM, добавляете физические узлы под его управление.

    13 апреля 2017 г. 12:29
    Модератор
  • Да, у меня FC SAN. И даже с поддержкой нпивов. Но завязвыаться на vSAN очень не хочется. Возни много, да и ограничения насколько я помню имеются. Какие не помню, но помню что когда читал мне они показались весьма существенными 

    13 апреля 2017 г. 12:48
  • С виртуальными FC адаптерами основной вопрос - миграция:

    1. Live Migration VM между хостами настроить можно, но есть особенности

    2. Про миграцию Storage забываем. А бывает надо, тогда начинается боль

    3. Требуется установка ПО вендора внутри ВМ

    13 апреля 2017 г. 12:54
  • С виртуальными FC адаптерами основной вопрос - миграция:

    1. Live Migration VM между хостами настроить можно, но есть особенности

    2. Про миграцию Storage забываем. А бывает надо, тогда начинается боль

    3. Требуется установка ПО вендора внутри ВМ

    Боюсь, Вы ошибаетесь по всем пунктам.
    1. Из особенностей — только конфигурация фабрик,
    2. С чего это Вы решили? Вы уверены в том, что хранилище виртуальной машины с FC SAN нельзя мигрировать?
    3. Какое ПО? Для чего? Кроме компонентов интеграции и MPIO ничего не нужно.
    13 апреля 2017 г. 13:06
    Модератор
  • 1. Еще есть миграция между кластерами. Поэтому ради пары ВМ придется конфигурировать все хосты.

    2. Средствами SAN - вполне может быть. А если надо на другое СХД перенести? Миграция стоража Hyper-V работает на уровне VHD(X). 

    3. Некоторые вендоры требуют установку своего ПО для корректной работы MPIO. Пример - Huawei строго рекомендует установку Ultrapath. Не проблема, но надо иметь в виду.

    Да, еще с виртуальным FC забываем про Hyper-V Replica.

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

    13 апреля 2017 г. 13:36
  • Про 2016 не нашёл. А про 2012R2 прямо сказано

    https://social.technet.microsoft.com/wiki/contents/articles/18698.hyper-v-virtual-fibre-channel-troubleshooting-guide.aspx

    The following is a list of Hyper-V features that are not compatible with virtual Fibre Channel

    • Checkpoints (formerly known as Snapshots)
    • Hyper-V Replica

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

    13 апреля 2017 г. 13:37