Настройка отказоустойчивой кластеризации для Hyper-V (часть 1)

• Настройка отказоустойчивой кластеризации для Hyper-V (часть 5)
• Настройка отказоустойчивой кластеризации для Hyper-V (часть 6)
• Настройка отказоустойчивой кластеризации для Hyper-V (часть 7)
• Настройка отказоустойчивой кластеризации для Hyper-V (часть 8)
• Настройка отказоустойчивой кластеризации для Hyper-V (часть 9)

Введение

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

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

Однако виртуальные серверы играют по другим правилам. Несколько виртуальных серверов обычно размещаются на одном хост-компьютере. Таким образом, если на узле произойдет аппаратный сбой, конечный результат будет эквивалентен сбою нескольких машин в невиртуализированной среде.

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

К счастью, Microsoft спроектировала Windows Server 2008 R2 таким образом, что Hyper-V может находиться внутри отказоустойчивого кластера. Отказоустойчивый кластер для Hyper-V может помочь решить все описанные выше проблемы.

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

Несмотря на то, что Windows Server 2008 R2 существует уже некоторое время, я должен признаться, что до недавнего времени у меня не было возможности поэкспериментировать с отказоустойчивым кластером для Hyper-V или с функцией Live Migration. Однако недавно один из моих клиентов попросил меня внедрить для них отказоустойчивый кластер, чтобы они могли воспользоваться преимуществами Live Migration. При этом я обнаружил, что, несмотря на то, что процесс установки и настройки относительно прост, есть несколько подводных камней. Я также обнаружил, что в Интернете есть несколько руководств, которые либо неточны, либо неполны. Таким образом, я хотел написать эту серию статей, чтобы предоставить ИТ-сообществу простое руководство по процессу настройки.

Аппаратное планирование

Прежде чем вы сможете даже приступить к созданию отказоустойчивого кластера, вы должны убедиться, что у вас есть надлежащее оборудование. Одна вещь, на которую я должен указать заранее, заключается в том, что Microsoft не будет поддерживать отказоустойчивую кластеризацию Hyper-V, если все используемое вами оборудование не будет сертифицировано для использования с Windows Server 2008 R2. Это не означает, что вы не можете использовать несертифицированное оборудование. Когда я впервые приступил к созданию отказоустойчивого кластера Hyper-V в лабораторной среде, я использовал низкобюджетное стандартное оборудование, которое, безусловно, не было сертифицировано для использования с Windows Server 2008 R2, и мой кластер работал нормально. Однако я бы никогда не стал мириться с использованием такого оборудования в производственной среде, потому что это приведет к тому, что ваш кластер окажется в неподдерживаемом состоянии.

Имейте в виду, что недостаточно просто приобрести серверы, сертифицированные для использования с Windows Server 2008 R2. На веб-сайте Microsoft специально указано, что «Microsoft поддерживает отказоустойчивое кластерное решение только в том случае, если все аппаратные функции помечены как сертифицированные для Windows Server 2008 R2». Далее на сайте указано, что даже используемые вами сетевые адаптеры должны быть сертифицированы для Windows Server 2008. Таким образом, вы можете непреднамеренно перевести свой кластер в неподдерживаемое состояние, если не убедитесь, что покупаете только сертифицированное оборудование. Microsoft предоставляет список сертифицированного оборудования здесь.

Имея это в виду, серверы, которые вы будете использовать в качестве узлов кластера, не обязательно должны точно совпадать, но они должны иметь схожие возможности. Как минимум, ваши серверы должны иметь 64-разрядные процессоры и поддерживать аппаратную виртуализацию. Кроме того, вы должны использовать одну и ту же архитектуру процессора для всех узлов вашего кластера (все Intel или все AMD). Используемые серверы также должны поддерживать предотвращение выполнения данных с помощью бита Intel XD или бита AMD NX.

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

Моя общая рекомендация заключалась бы в том, чтобы предоставить каждому узлу кластера три сетевых адаптера (или два сетевых адаптера и карту Fibre Channel, если вы используете хранилище на основе Fibre Channel). Один из этих сетевых адаптеров используется для связи между сервером (и виртуальными машинами, находящимися на нем) и остальной частью сети. Второй сетевой адаптер зарезервирован для обмена данными между узлами кластера. Третий сетевой адаптер предназначен для обмена данными по iSCSI с общим томом хранилища.

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

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

Вывод

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

• Настройка отказоустойчивой кластеризации для Hyper-V (часть 5)
• Настройка отказоустойчивой кластеризации для Hyper-V (часть 6)
• Настройка отказоустойчивой кластеризации для Hyper-V (часть 7)
• Настройка отказоустойчивой кластеризации для Hyper-V (часть 8)
• Настройка отказоустойчивой кластеризации для Hyper-V (часть 9)