В этом случае необходимо, чтобы диски ВМ находились в режиме multi-writer, то есть позволяли производить запись в файл VMDK одновременно с нескольких хостов ESXi (можно также организовать и запись от нескольких ВМ на одном хосте). Этот режим со стороны VMware поддерживается только для некоторых кластерных решений, таких как Oracle RAC, и для технологии Fault Tolerance, у которой техника vLockstep требует одновременного доступа к диску с обоих хостов ESXi.
В статье, на которую мы сослались выше, хоть и неявно, но было указано, что режим "Multi-writer" используется и для кластеров Microsoft Windows Server Failover Clustering (WSFC, ранее они назывались Microsoft Cluster Service, MSCS), однако это была неверная информация - он никогда не поддерживался для кластеров Microsoft.
Мало того, использовать режим "Multi-writer" для WSFC не только не рекомендуется, но и опасно - это может привести к потере данных. Кроме того, возможности поддержки VMware в этом случае будут очень ограничены.
Информация о поддержке "Multi-writer" и общих дисков VMDK
Использование файлов VMDK в качестве общих дисков для виртуальных машин Windows в среде vSphere возможно, но только когда файлы VMDK хранятся в кластеризованном хранилище данных с включенной поддержкой Clustered VMDK, как описано в статье Clustered VMDK support for WSFC, или ниже в этой статье.
Сначала предупреждения и предостережения - прежде чем предпринимать любые из описанных в этой статье шагов, администратору очень важно понять и принять, что VMware не гарантирует, что эти конфигурации не приведут к потере данных или их повреждению.
Итак, какие варианты предлагает VMware, если вы уже используете кластеры WSFC в режиме multi-writer:
Переконфигурирование общих дисков на основе файлов VMDK для кластеризованных виртуальных машин Windows, которые были настроены с использованием опции флага multi-writer.
Перемещение файлов VMDK в одно или несколько официально поддерживаемых хранилищ данных с поддержкой Clustered VMDK.
Представление файлов VMDK обратно виртуальным машинам таким образом, чтобы минимизировать или избежать необходимости перенастройки внутри гостевой операционной системы или на уровне приложений.
VMware настоятельно рекомендует клиентам, выполняющим эти задачи, убедиться в наличии проверенного и повторяемого плана отката в случае сбоя во время выполнения этих операций. Предполагается и ожидается, что у клиентов имеются проверенные резервные копии всех данных и информации о конфигурации всех виртуальных машин, которые будут участвовать в этом процессе переконфигурации.
Как минимум, клиенты должны выполнить (или отметить) следующее перед началом этих процедур:
Имена и расположение файлов для КАЖДОГО диска VMDK.
Номер SCSI и SCSI ID, к которому подключен КАЖДЫЙ диск. Мы должны присоединить диск к ТОМУ ЖЕ SCSI ID при повторном подключении.
В Windows - текущий владелец ресурсов диска (проверить это можно в конфигурации WSFC).
Если владение ресурсами WSFC разделено между узлами, ПЕРЕКЛЮЧИТЕ ВСЕ РЕСУРСЫ на один узел. Это упрощает процесс реконфигурации и очень полезно, чтобы избежать путаницы. Выключите все пассивные узлы ПЕРЕД выключением активного узла. После завершения настройки необходимо включить сначала активный узел, а затем остальные узлы.
Переконфигурация кластера WSFC с Multi-Writer на режим Clustered VMDK
Давайте начнем с рассмотрения нашей текущей конфигурации, посмотрим на узлы (кликабельно):
И на диски:
Протестируем WSFC путем переключения ресурсов диска - в данном случае мы выключаем активный узел и наблюдаем, как кластерные ресурсы становятся доступными на пассивном узле. Этот тест очень важен для проверки работоспособности WSFC перед внесением изменений.
Текущая конфигурация общих дисков (отображение распространенной неправильной конфигурации с включенным multi-writer, где общие диски принадлежат выключенной третьей виртуальной машине).
Вот узел WSFC Node-1 и его расшаренные диски (флаг Multi-Writer установлен в Enabled):
Та же самая ситуация и с узлом WSFC Node-2:
Обзор общих дисков в Windows. Обратите внимание, что диски АКТИВНЫ и видны ТОЛЬКО на одном узле (FC2):
Обзор общих дисков в Windows. Мы создали тестовые папки. По завершении переконфигурации мы проверим наличие этих папок, чтобы продемонстрировать/проверить отсутствие потери данных после внесенных изменений. В идеале, нужно протестировать рабочие нагрузки (например, базы данных).
Представление общих дисков в Менеджере дисков Windows. Обратите внимание, что диск 1 и 2 находятся в режиме ОНЛАЙН только на FC02. Мы проверили работоспособность наших кластерных ресурсов (дисков):
Теперь мы готовы к перенастройке дисков в vCenter. Нужно выключить виртуальные машины ДО начала следующих шагов по миграции дисков:
Если вы задаетесь вопросом, почему мы не можем просто выполнить операцию перемещения хранилища (Storage vMotion) для дисков, то ответ заключается в том, что процесс завершится неудачей из-за того, что мы используем общие диски.
Например, выберем опцию миграции хранилища:
Нам будет выдано предупреждение о совместимости:
В разделе Compatibility Issue нам объясняют, почему миграция невозможна:
Таким образом, мы ОТСОЕДИНЯЕМ (НЕ УДАЛЯЕМ) диски от виртуальных машин узлов WSFC:
Делаем то же самое и на втором узле (не удаляем, а делаем Detach):
Далее в свойствах виртуальной машины, где находятся эти диски, мы удаляем флаг Multi-writer в разделе Sharing:
Далее устанавливаем SCSI Bus Sharing для контроллера в значение None:
Теперь мы можем смигрировать диски:
Переносим хранилище:
Далее выбираем "Configure Per Dis", выбираем общие диски и нажимаем "Configure":
Выберите целевое хранилище данных для Clustered VMDK, выберите желаемую политику хранения, установите формат диска в «Thick Provision Eager Zeroed», затем нажмите "Confirm" и завершите конфигурацию.
У нас все еще есть диск операционной системы виртуальной машины в его исходном местоположении, но общие диски теперь расположены в общем хранилище данных для Clustered VMDK.
Вот общие диски в новом местоположении:
Теперь мы готовы перепривязать диски к узлам - членам кластера WSFC. Сначала убедитесь, что диски настроены следующим образом на виртуальной машине, которой они принадлежат. А именно:
Sharing: No sharing
Disk Mode: Independent Persistent
Посмотрите на соответствующие Virtual Device Node SCSI ID
SCSI Bus Sharing: Physical
Эти настройки должны быть идентичны на всех узлах
Далее на узле WSFC добавьте существующий диск:
Откройте датастор для Clustered VMDK и выберите нужный файл:
Повторите эти шаги для всех общих дисков:
Убедитесь в идентичности их параметров:
Устанавливаем режим работы диска - Independent - Persistent:
На этом все - теперь мы включаем виртуальную машину, которая ранее была активным узлом. Затем мы входим в Windows и ждем, пока все запустится. Затем вы можете включить и другие узлы.
Проверяем, что все в порядке в Windows Disk Manager:
И затем в Failover Cluster Manager:
Смотрим, не потерялись ли данные (наши тестовые папки):
Смотрим это на всех узлах:
На этом все - мы избавились от неподдерживаемой опции Multi-Writer для кластеров WSFC и переключились на поддерживаемую конфигурацию "Clustered VMDK".
RSS
