none
Диспетчер отказоустойчивости кластеров и Диспетчер Hyper-V RRS feed

  • Вопрос

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

    Есть вопрос, касающийся взаимодействия двух диспетчеров, вынесенных в заголовок."Документация Microsoft указывает, что для конфигурирования предпочтительно использовать "Диспетчер отказоустойчивости серверов".

    Представим ситуацию. Есть кластер Hyper-V из двух хостов. На нем крутятся виртуальные машины. В Диспетчере отказоустойчивости серверов настроен перенос виртуальных машин в случае отказа. В Диспетчере Hyper-V настроено выключение виртуальной машины (или создание снимка, думаю, в контексте вопроса это не принципиально) при выключении сервера. Оба сервера одновременно уходят в корректный shutdown.

    Вопрос. Задачи какого диспетчера начнут выполнятся в первую очередь?

    Мой вариант: машины начнут одновременно перемещаться между хостами кластера и пытаться выключиться (сохраниться). Не уверен, что в итоге виртуальным машинам это пойдет на пользу.

    19 августа 2011 г. 5:51

Ответы

  • Сергей, надо понять простую вещь: кластер - это в первую избыточность, которая позволяет работать вашей инфраструктуре штатно. Если у Вас нет возможности с очень большой долей вероятности обеспечивать Ваше железо электропитанием на постоянной основе, то и кластер совершенно бессмыслено затевать - гораздо проще и разумнее иметь просто хосты виртуализации. То же самое касается сети, оперативной памяти, дисковых ресурсов - кластер разумно иметь тогда, когда у вас достаточно ресурсов, чтобы обеспечивать его работу. Разумеется возникает вопрос - а зачем же тогда кластер? А кластер затем, что Вы можете выводить часть ресурсов из работыт ШТАТНО. Вот Вы строите кластер, допустим, на три хоста и рассчитываете, что один хост Вы можете потерять или вывести из работы без ущерба для инфраструктуры - то есть у вас достаточно будет памяти, процессорной мощности двух других узлов, чтобы они продолжили обслуживать инфраструтура пока Вы ремонтируете/апгрейдите/осуществляете профилактику на выведенном из работы узле кластера.

    ВСЕ ОСТАЛЬНОЕ - ЭТО НЕШТАТНЫЙ, НЕПЛАНИРУЕМЫЙ, НЕ ОБЕСПЕЧЕННЫЙ РЕСУРСАМИ РЕЖИМ РАБОТЫ. Он в лучшем случае пройдет без особых потерь, если Вы правильно разработали схему как Вам действовать в этой ситуации. Кластер - это не чудо, которое спасет Вас, кластер всего лишь позволяет вам чуть больше - но только пока есть ресурсы.

    Что касается конктретно ситуации, которую Вы описали, то в основном все нормально проходит в случае, если у Вас достаточно ресурсов на обоих хостах для Вашей схемы миграции/восстановления виртуальных машин. Пример:

    Узел 1: ВМ1 2Гб оперативки - строго сидит на Узле 1, не мигрирует; ВМ2 4Гб оперативки, мигрирует в случае падения Узла 1 на Узел 2, после восстановления Узла 1 - возвращается; ВМ3 4 Гб памяти, мигрирует в случае падения Узла 1 на Узел 2, после восстановления Узла 1 - возвращается. Итого 10Гб

    Узел 2: ВМ4 4Гб памяти, мигрирует в случае падения Узла 2 на Узел 1, после восстановления Узла 2 - возвращается; ВМ5 4Гб памяти, мигрирует в случае падения Узла 2 на Узел 1, после восстановления Узла 2 - возвращается. Итого 8Гб

    Что получается - у Вас на Узле 1 должно быть не менее 18Гб памяти, чтобы он мог обеспечивать запланированную Вами работу машиной ВМ2, ВМ3, ВМ4, ВМ5, машиной ВМ1 Вы согласны пожертвовать на случай отключения Узла 1 - она, допустим, тестовая, но память то она будет потреблять, если упадет Узел 2

    Узел два должен иметь не менее 16Гб памяти для ВМ2, ВМ3, ВМ4, ВМ5 на случай падения Узла 1.

    Если это так, то как бы узлы не выбывали, машины на них при включении поднимутся и перейдут на хозяина. Само выключение во избежание накладок лучше проводить последовательно - то есть сначала один узел, потом второй - и не важно какой первый, а какой второй, но ПОСЛЕДОВАТЕЛЬНО. Включать лучше тоже последовательно, еще лучше - в обратном порядке.

    ПАДАТЬ ОДНОВРЕМЕННО ОБА УЗЛА НЕ ДОЛЖНЫ, ПОТОМУ ЧТО ВАШ КЛАСТЕР СПРОЕКТИРОВАН НА ПОТЕРЮ ОДНОГО УЗЛА, А ВЫБЫТИЕ ВТОРОГО - ЭТО УЖЕ НЕ КЛАСТЕРНАЯ ОПЕРАЦИЯ, ЭТО ПРОБЛЕМА. В Вашем примере - проблема с недостаточностью резервного питания и отсутсвием схемы обслуживания этой ситуации обслуживающим персоналом или скриптами управления.

    Всё. Никаких чудес - просто понимание где Вы "право имеете", а где надо Ваш кластер аккуратно положить в спячку.

    • Предложено в качестве ответа Konstantin Oparin 24 августа 2011 г. 11:33
    • Помечено в качестве ответа Sergey Shl 24 августа 2011 г. 12:25
    24 августа 2011 г. 11:00

Все ответы

  • Забыл указать. Речь идет о Hyper-V на Windows Server 2008 R2 SP1 Core со всеми обновлениями.
    19 августа 2011 г. 6:11
  • Сами по себе машины никуда перемещаться не будут, они храняться на общем хранилище. А после загрузки узлов машины поднимутся на том, который был последним владельцем сервиса.

    19 августа 2011 г. 10:54
  • "Сами по себе машины никуда перемещаться не будут, они храняться на общем хранилище."

    Согласен, выразился неправильно, виртуальные машины будут пытаться поменять владельца.

    Как раз и интересует:

    1. Не будет ли это мешать созданию снимков виртуальных машин (настройки Диспетчера Hyper-V)?

    2. Что произойдет, если в момент смена владельца оба хоста кластера выключатся?

    19 августа 2011 г. 12:21
  • Если выключение корректное, то сервер не выключится пока не завершит все необходимые операции с машинами.

    19 августа 2011 г. 12:41
  • Спасибо за ответ. Это логично было предположить.

    И все-же, касательно взаимодейчствия задач двух диспетчеров. Не будет ли мешать операция смены владельца сервиса выключению (созданию снимка) виртуальной машины?


    23 августа 2011 г. 7:55
  • На кворуме хосты кластера договариваются кто выбыл, так что сбоев не должно быть.

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

    24 августа 2011 г. 7:50
  • сейчас поднимаю кластер и какраз эксперементирую с падениями и сбоями в работе

    на данный момент вот что выяснил

    1) не рекомендую одновременно выключать все сервера - процесс загрузки после этого будет в несколько раз дольше, пока они между собой всё согласуют

    2) если выключить сервер в момент миграции ВМ, она может упасть или вызвать конфликты, вплоть до полного выпадания кластера, и в дальнейшем её будет очень сложно удалить из кластера, а с ней кластер не поднимается

    3) также при обрыве сети, и при изменениях сетевой конфигурации при работе кластера могут возникнуть "раздвоение личности" у кластера - тоесть он будет враоде как и работать, но на одном из серверов, а на другом будет висеть что он работает и что недоступен одновременно (после этого мне пришлось систему переставлять на обоих серверах :( )

    ------------

    в общем мой вердикт - кластеризация в плане сетевой защищенности и отказоустойчивости вообще не развита!

    24 августа 2011 г. 8:54
  • Первое - проблема состоит в миграции виртуальных машин, то есть если настроено восстановление на хост-хозяин после его появления в кластере, то те машины, которые при выключении покинули хозяина могут начать грузиться на текущем хосте, а потом мигрировать на хозяина и это дейтсивтельно отнимает время, особенно, если ресурсы несогласованы - то есть их попросту не хватает на все поднимаемые виртуальные машины на текущем хосте. Решение состоит в том, чтобы согласовывать ресурсы, либо запретить миграцию виртуальных машин. В любом случае следует выключать и включать хосты последовательно. На практике такая операция может потребоваться при физическом переносе всей инфраструктуры в другую локацию, когда ничего другого, кроме как остановить ее полностью не остается, в этом случае я настоятельно рекомендую запретить миграцию машин, после чего можно спокойно выключать хосты - даже массово и так же массово потом их включать, после чего уже вновь настроить динамическую миграцию виртуальных машин в кластере. Это будет и проще и надежнее. Если же у вас по каким-то причинам кластер падает, то надо бы заняться в первую очередь разумной организацией кластера, потому как на то он и кластер, чтобы не падать.

    Второе - опять же для чего? А что, если на мерседесе разогнаться до пары сотен километров в час, а потом ручник дернуть? Управлять этим мерседесом будет сложно и вряд ли из этого получится что-либо хорошее. Говорит ли это о том, что мерседес - дрянная, неуправляемая машина?

    Третье - здесь действительно наблюдаются нехорошие эффекты, вообще я заметил, что если в кластере произошли какие-то серьезные сбои, то его узлы лучше перезапустить - в процессе нормализуются связи в кластере и он приходит в себя. Естественно в кластере у хостов должно хватать ресурсов на миграции, если они предполагаются. Кроме того, ошибки могут быть ошибками отображения - то есть фактически с кластером дела могут идти не совсем так, как это отображается в консолях. Я заметил, что консоль Диспетчера Hyper-V наиболее достоверно отображает информацию о виртуальных машинах, консоль кластера я использую для настройки машин, а консоль VMM для штатных действий - она по моим наблюдения наиболее тормознутая и подходит для хорошо спланированных и надежных действий - тогда она действительно удобна.

    Кластер от Микрософта далеко не чудо кибернетики, но в целом вполне удобоваримое решение, если его правильно готовить, а не ждать от него чудес.

    24 августа 2011 г. 9:57
  • На кворуме хосты кластера договариваются кто выбыл, так что сбоев не должно быть.

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


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

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

    Как я понял, в описанном случае, средствами кластера не стоит управлять виртуальными машинами. Сначала средствами операционной системы выключаем виртуальные машины, а потом уже сервера кластера (тот же shutdown с разными параметрами задержки выполнения).

    24 августа 2011 г. 10:04
  • Сергей, надо понять простую вещь: кластер - это в первую избыточность, которая позволяет работать вашей инфраструктуре штатно. Если у Вас нет возможности с очень большой долей вероятности обеспечивать Ваше железо электропитанием на постоянной основе, то и кластер совершенно бессмыслено затевать - гораздо проще и разумнее иметь просто хосты виртуализации. То же самое касается сети, оперативной памяти, дисковых ресурсов - кластер разумно иметь тогда, когда у вас достаточно ресурсов, чтобы обеспечивать его работу. Разумеется возникает вопрос - а зачем же тогда кластер? А кластер затем, что Вы можете выводить часть ресурсов из работыт ШТАТНО. Вот Вы строите кластер, допустим, на три хоста и рассчитываете, что один хост Вы можете потерять или вывести из работы без ущерба для инфраструктуры - то есть у вас достаточно будет памяти, процессорной мощности двух других узлов, чтобы они продолжили обслуживать инфраструтура пока Вы ремонтируете/апгрейдите/осуществляете профилактику на выведенном из работы узле кластера.

    ВСЕ ОСТАЛЬНОЕ - ЭТО НЕШТАТНЫЙ, НЕПЛАНИРУЕМЫЙ, НЕ ОБЕСПЕЧЕННЫЙ РЕСУРСАМИ РЕЖИМ РАБОТЫ. Он в лучшем случае пройдет без особых потерь, если Вы правильно разработали схему как Вам действовать в этой ситуации. Кластер - это не чудо, которое спасет Вас, кластер всего лишь позволяет вам чуть больше - но только пока есть ресурсы.

    Что касается конктретно ситуации, которую Вы описали, то в основном все нормально проходит в случае, если у Вас достаточно ресурсов на обоих хостах для Вашей схемы миграции/восстановления виртуальных машин. Пример:

    Узел 1: ВМ1 2Гб оперативки - строго сидит на Узле 1, не мигрирует; ВМ2 4Гб оперативки, мигрирует в случае падения Узла 1 на Узел 2, после восстановления Узла 1 - возвращается; ВМ3 4 Гб памяти, мигрирует в случае падения Узла 1 на Узел 2, после восстановления Узла 1 - возвращается. Итого 10Гб

    Узел 2: ВМ4 4Гб памяти, мигрирует в случае падения Узла 2 на Узел 1, после восстановления Узла 2 - возвращается; ВМ5 4Гб памяти, мигрирует в случае падения Узла 2 на Узел 1, после восстановления Узла 2 - возвращается. Итого 8Гб

    Что получается - у Вас на Узле 1 должно быть не менее 18Гб памяти, чтобы он мог обеспечивать запланированную Вами работу машиной ВМ2, ВМ3, ВМ4, ВМ5, машиной ВМ1 Вы согласны пожертвовать на случай отключения Узла 1 - она, допустим, тестовая, но память то она будет потреблять, если упадет Узел 2

    Узел два должен иметь не менее 16Гб памяти для ВМ2, ВМ3, ВМ4, ВМ5 на случай падения Узла 1.

    Если это так, то как бы узлы не выбывали, машины на них при включении поднимутся и перейдут на хозяина. Само выключение во избежание накладок лучше проводить последовательно - то есть сначала один узел, потом второй - и не важно какой первый, а какой второй, но ПОСЛЕДОВАТЕЛЬНО. Включать лучше тоже последовательно, еще лучше - в обратном порядке.

    ПАДАТЬ ОДНОВРЕМЕННО ОБА УЗЛА НЕ ДОЛЖНЫ, ПОТОМУ ЧТО ВАШ КЛАСТЕР СПРОЕКТИРОВАН НА ПОТЕРЮ ОДНОГО УЗЛА, А ВЫБЫТИЕ ВТОРОГО - ЭТО УЖЕ НЕ КЛАСТЕРНАЯ ОПЕРАЦИЯ, ЭТО ПРОБЛЕМА. В Вашем примере - проблема с недостаточностью резервного питания и отсутсвием схемы обслуживания этой ситуации обслуживающим персоналом или скриптами управления.

    Всё. Никаких чудес - просто понимание где Вы "право имеете", а где надо Ваш кластер аккуратно положить в спячку.

    • Предложено в качестве ответа Konstantin Oparin 24 августа 2011 г. 11:33
    • Помечено в качестве ответа Sergey Shl 24 августа 2011 г. 12:25
    24 августа 2011 г. 11:00
  • ПАДАТЬ ОДНОВРЕМЕННО ОБА УЗЛА НЕ ДОЛЖНЫ, ПОТОМУ ЧТО ВАШ КЛАСТЕР СПРОЕКТИРОВАН НА ПОТЕРЮ ОДНОГО УЗЛА, А ВЫБЫТИЕ ВТОРОГО - ЭТО УЖЕ НЕ КЛАСТЕРНАЯ ОПЕРАЦИЯ, ЭТО ПРОБЛЕМА. В Вашем примере - проблема с недостаточностью резервного питания и отсутсвием схемы обслуживания этой ситуации обслуживающим персоналом или скриптами управления.

    Вот это очень важный комментрарий.

    Андрей, спасибо за развернутый ответ.

    24 августа 2011 г. 12:25
  • ну в таком варианте более целесообразно отключать все сервера кластера, кроме последнего

    а после их завершения (ну и миграции всех машин на последний) - завершать работу последнего

    тогда он корректно сохранит все виртуалки сам

    --

    ну и соответственно включать начинать с него

    24 августа 2011 г. 12:38
  • Пожалуйста!

    Кстати сказать, отключение одного узла (или, говоря для общего случая - допустимого числа узлов) кластера может стать компонентом Вашей стратегии борьбы с ограниченным резервом электропитания. Еще до использования кластеров я использовал схему отключения серверов по степени критичности. То есть я разделил сервера на уровни по важности и после прекращения подачи энергии из сети начинал отключать сервера через намеченное время уровень за уровнем. Например, работая в банке, я вначале отключал резервные сервера - stand-by базы данных, резервный контроллер. Если энергоснабжение не восстанавливалось - начинал отключать второстепенные сервисы: почта, файловый сервер и в общем то, что для внутреннего пользования. До последнего держал только набор серверов, обеспечивающих процессинг для клиентов и точку контакта - АТС.

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

    24 августа 2011 г. 14:16
  • Андрей, это тоже интересные мысли, но они предполагают мониторинг ситуации и непосредственный контроль специалистов.

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

     

    ELITE, да, именно об этом и идет речь.


    25 августа 2011 г. 5:41