Назад | Перейти на главную страницу

Несколько вопросов о виртуальных машинах Hyper-V и кластеризации

Я уже некоторое время использую технологию Microsoft Hyper-V, но сейчас я только начинаю заниматься кластеризацией.

В частности, я пытаюсь реализовать отказоустойчивую базу данных SQL. Это включает в себя настройку двух виртуальных машин, их кластеризацию с помощью отказоустойчивого кластера, а затем каким-либо образом установить SQL Server. У меня есть две физические машины - одна высокопроизводительная и довольно мощная «тяжеловесная машина» для размещения большинства виртуальных машин, а другая «резервная копия» (перепрофилированный рабочий стол) для хранения необходимого «вторичного» (или аварийного) AD-DC, Виртуальные машины SQL и FS.

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

Мой первый вопрос касается самого SQL Server. Если у меня есть кластер между двумя виртуальными машинами, имеет ли смысл устанавливать SQL Server в конфигурации отказоустойчивого кластера или я должен просто установить его в автономной конфигурации и зеркалировать базы данных? Например, эта почта предлагает просто зеркалировать базы данных, но могу ли я просто зеркалировать автономные базы данных на автономных виртуальных машинах, или я могу получить преимущества сети и аварийного переключения кластерных виртуальных машин, по-прежнему используя (на каждой кластеризованной виртуальной машине) автономные базы данных, которые были зеркалированы между собой?

Кроме того, я столкнулся с большим количеством документации о кластеризации SQL, но большинство предполагает, что количество (#> 2) физических машин содержит не только фактические виртуальные машины SQL, но также хранилища кворума и свидетеля. Я не смогу собрать больше двух физических машин. Таким образом, мне придется довольствоваться кластером виртуальных машин, который не превышает двух виртуальных машин (по одной для каждой физической машины).

Другая проблема связана с MSDTC - координатором распределенных транзакций. При попытке установить отказоустойчивый кластер SQL (по этой причине я так и не завершил его) он с трудом подбирался, потому что MSDTC не был кластеризован. Как бы я ни искал, я пока не нашел способа сделать это в Windows Server 2012 R2. я нашел множество документов для Windows 2008 и 2008 R2, но эти инструкции не соответствуют 2012 R2 (по крайней мере, не таким образом, который позволяет мне успешно кластеризовать MSDTC). Плюс, некоторые инструкции что я обнаружил для установки отказоустойчивого кластера SQL Server, предполагает, что третье «сетевое устройство» - общее сетевое хранилище (SAN) - требуется для самой БД (и других функций). У меня этого нет и не будет. Большая часть моего хранилища находится на «тяжелом подъемнике», который был разработан для всех «основных» виртуальных машин. Если эта физическая машина выходит из строя, то же самое и хранилище. У вторичного сервера достаточно ресурсов для сервера AD-DC, сервера SQL и файлового сервера, поэтому он будет обрабатывать «вторичные» версии отработки отказа этих виртуальных машин (кластеризованные или нет).

Мой последний вопрос касается файловых серверов. Если я кластеризирую файловые серверы между двумя виртуальными машинами (одна на моем «тяжелом подъемнике», а другая на моей «резервной копии», как мне отразить данные между ними? Кластеризация виртуальных машин обеспечивает только одну точку доступа в сети для ресурса, это точно не реплицирует данные между ними - это остается на усмотрение служб, обслуживающих эти данные. Я не уверен, как я могу гарантировать, что данные файлового сервера между двумя виртуальными машинами кластерного файлового сервера могут быть должным образом отражены. Помните, у меня только две устройства, которые будут использоваться здесь - моя основная машина и резервная вторичная. У меня нет шансов получить SAN или какой-либо другой тип сетевого хранилища. То, что существует на машинах, должно выступать в качестве хранилища.

Спасибо заранее за любые предложения.

Один из «низкотехнологичных» вариантов - реализовать реплику Hyper-V между двумя хостами. Если у вас нет общего хранилища для них и вы не можете настроить (или профинансировать) общее хранилище и отработку отказа на уровне приложений (SQL Server Enterprise Edition для AOAG), то реплика Hyper-V может использоваться для репликации виртуальной машины из источника. хост к целевому хосту и синхронизировать две виртуальные машины. Вы можете включить согласованную репликацию приложений, используя опцию VSS в Hyper-V Replica.

Недостатками реплики Hyper-V является то, что ее нельзя использовать между узлами в одном отказоустойчивом кластере, и нет автоматического переключения на другой ресурс.

Возможно, вы захотите разбить это на серию более конкретных вопросов.

  1. Если вы ищете бесшовное, прозрачное для приложений аварийное переключение, вам необходимо использовать либо отказоустойчивую кластеризацию, либо группы доступности AlwaysOn. AOAG будет вариантом, только если вы используете SQL 2012 Enterprise. Зеркалирование предоставит вам простой (ручной) переход на другой ресурс; если вы хотите автоматическое переключение при отказе, вам придется добавить в смесь следящий сервер, но даже в этом случае ваше приложение должно будет поддерживать аварийное переключение, потому что ему потребуется использовать новый IP / имя для подключения к вторичному серверу, в отличие от отказоустойчивый кластер / AOAG. Фактически, Microsoft намеревается, что группы доступности в будущем заменят традиционное зеркалирование, поэтому в целях обеспечения перспектив я рекомендую по возможности не использовать зеркалирование для новых развертываний.

  2. SQL Server 2012 в Windows 2012 не абсолютно требуется кластерный MSDTC, но если он вам нужен, это так же просто, как добавить кластеризованную роль DTC:

  3. Для отказоустойчивого кластера вам понадобится какое-то внешнее хранилище для БД. Это может быть SAN, DAS или (если у вас SQL 2012) NAS. Если вы не собираетесь использовать внешнее хранилище, вам следует использовать группы доступности AlwaysOn поскольку он будет реплицировать ваши данные, обеспечивая при этом возможности отказоустойчивого кластера. Для этого по-прежнему требуется кластер Windows, но сам SQL не будет кластеризован.

  4. Кластерные файловые серверы предназначены для работы с общим хранилищем на внутренней стороне, во многом как кластерные экземпляры SQL. Другой вариант - использовать Репликация DFS с пространствами имен DFS для предоставления файлового ресурса высокой доступности без кластеризации.