Перенос экземпляра отказоустойчивого кластера Always On для SQL Server на платформу Azure VMware Solution

В этой статье вы узнаете, как мигрировать экземпляр отказоустойчивого кластера SQL Server в решение VMware для Azure. В настоящее время служба Azure VMware Solution не поддерживает VMware гибридный связанный режим для подключения локального сервера vCenter Server к запущенному в Azure VMware Solution. Из-за этого ограничения этот процесс требует использования VMware HCX для миграции. Дополнительные сведения о настройке HCX см. в разделе "Установка и активация VMware HCX" в Решение Azure VMware.

VMware HCX не поддерживает перенос виртуальных машин с контроллерами SCSI в режиме физического общего доступа, подключенном к виртуальной машине. Однако это ограничение можно преодолеть, выполнив действия, описанные в этой процедуре, и с помощью VMware HCX Cold Migration для перемещения различных виртуальных машин, составляющих кластер.

На схеме показана архитектура отказоустойчивости SQL Server для Azure VMware Solution.

Примечание.

Для этой процедуры требуется полное завершение работы кластера. Так как служба SQL Server будет недоступна во время миграции, планируйте соответствующим образом период простоя.

Microsoft SQL Server 2019 и 2022 были протестированы в Windows Server 2019 и 2022 Data Center с виртуальными машинами, развернутыми в локальной среде. Windows Server и SQL Server были настроены в соответствии с передовым опытом и рекомендациями корпорации Майкрософт и VMware. Локальная исходная инфраструктура была VMware vSphere 7.0 с обновлением 3 и VMware vSAN, работающей на серверах Dell PowerEdge и устройствах Ssd NVMe Intel Optane P4800X.

Предварительные условия

  • Просмотрите и запишите конфигурацию хранилища и сети каждого узла в кластере.
  • Просмотрите и запишите конфигурацию WSFC.
  • Сохраняйте резервные копии всех баз данных SQL Server.
  • Резервное копирование виртуальных машин кластера.
  • Удалите все виртуальные машины узла кластера из всех групп и правил Планировщика распределения ресурсов (DRS), в которых они участвуют.
  • VMware HCX необходимо настроить между вашим локальным центром обработки данных и частным облаком Azure VMware Solution, на котором выполняются мигрированные рабочие нагрузки. Дополнительные сведения об установке VMware HCX см. в документации Azure VMware Solution.
  • Убедитесь, что все сетевые сегменты, используемые SQL Server и связанными с ним рабочими нагрузками, расширены в ваше частное облако на платформе решения Azure VMware. Чтобы проверить этот шаг, см. раздел "Настройка расширения сети VMware HCX".

Подключение VMware HCX через VPN или ExpressRoute можно использовать в качестве конфигурации сети для миграции.

При использовании VMware HCX по VPN из-за ограниченной пропускной способности обычно подходит для рабочих нагрузок, которые могут поддерживать длительные периоды простоя (например, непроизводственные среды).

Для миграции в любом из следующих случаев рекомендуется использовать подключение ExpressRoute:

  • Рабочие среды
  • Рабочие нагрузки с большими размерами базы данных
  • Сценарии, в которых требуется свести к минимуму время простоя, рекомендуется использовать подключение ExpressRoute для миграции.

Вопросы, связанные с простоями

Время простоя во время миграции зависит от размера базы данных, который необходимо перенести, и скорости подключения частной сети к облаку Azure. Для миграции экземпляров отказоустойчивого кластера SQL Server AlwaysOn в Решение Azure VMware требуется полное время простоя базы данных и всех узлов кластера, однако следует запланировать выполнение миграции в нерабочие часы с утвержденным окном изменений.

В следующей таблице указывается предполагаемое время простоя для миграции каждой топологии SQL Server.

Сценарий Ожидаемое время простоя Примечания
Автономный экземпляр SQL Server Низкая Миграция выполняется с помощью VMware vMotion, база данных доступна во время миграции, но во время миграции не рекомендуется фиксировать критически важные данные.
Группа доступности AlwaysOn SQL Server Низкая Первичная реплика всегда будет доступна во время миграции первой вторичной реплики, а вторичная реплика станет основной после первоначального перехода на отказ в Azure.
Экземпляр отказоустойчивого кластера SQL Server AlwaysOn Высокая Все узлы кластера отключаются и переносятся с помощью холодной миграции VMware HCX. Длительность простоя зависит от размера базы данных и скорости частной сети в облако Azure.

Рекомендации по кворуму отказоустойчивого кластера Windows Server

Отказоустойчивый кластер Windows Server требует механизма кворума для поддержания работы кластера.

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

  • Диск-свидетель
  • Свидетель файловой доли
  • Облачный свидетель

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

Если кластер использует следящий файловыйресурс, работающий локально, тип следящего сервера для перенесенного кластера зависит от сценария Решение Azure VMware:

  • Расширение центра обработки данных: обслуживание файлового ресурса-свидетеля на площадке. Ваши рабочие нагрузки распределены по вашему центру обработки данных и решению Azure VMware, поэтому между ними всегда должно быть доступное подключение. В любом случае следует учитывать ограничения пропускной способности и планировать соответствующим образом.
  • Выход из центра обработки данных. Для этого сценария существует два варианта. В обоих случаях можно поддерживать следящий файловый ресурс локально во время миграции в случае необходимости отката.
    • Разверните новое файловое пространство-свидетель в частном облаке Azure VMware Solution.
    • Разверните облако-свидетель, работающий в Хранилище BLOB-объектов Azure в том же регионе, что и частное облако Решение Azure VMware.
  • Аварийное восстановление и непрерывность бизнес-процессов: Для сценария аварийного восстановления лучший и самый надежный вариант — создать облачный свидетель, работающий в службе хранилища Azure.
  • Модернизация приложений: Для этого варианта лучше всего развернуть Cloud Witness.

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

Миграция отказоустойчивого кластера

Для иллюстрации в этом документе мы используем двухузловой кластер с Windows Server 2019 Datacenter и SQL Server 2019 Enterprise. Windows Server 2022 и SQL Server 2022 также поддерживаются этой процедурой.

  1. После завершения работы клиента vSphere второй узел кластера.

  2. Перейдите к первому узлу кластера и откройте Диспетчер отказоустойчивых кластеров.

    • Убедитесь, что второй узел находится в автономном состоянии, а все кластеризованные службы и хранилище находятся под контролем первого узла. На схеме показана проверка хранилища кластера Диспетчера отказоустойчивости кластеров Windows Server.

    • Завершите работу кластера.

      Диаграмма показывает отключённый кластер, используя диспетчер отказоустойчивого кластера Windows Server.

    • Убедитесь, что все службы кластера успешно остановлены без ошибок.

  3. Завершите работу первого узла кластера.

  4. В клиенте vSphere измените параметры второго узла кластера.

    • Удалите все общие диски из конфигурации виртуальной машины.
    • Убедитесь, что флажок "Удалить файлы из хранилища данных" не выбран, так как он окончательно удаляет диск из хранилища данных. В этом случае необходимо восстановить кластер из предыдущей резервной копии.
    • Установите Общий доступ через SCSI-шину с Физического на Нет в виртуальных SCSI контроллерах, используемых для выделенного хранилища. Обычно эти контроллеры имеют тип VMware Paravirtual.

  5. Измените параметры виртуальной машины первого узла. Настройте параметр SCSI Bus Sharing с Physical на Нет в контроллерах SCSI.

  6. Из клиента vSphere перейдите в область подключаемого модуля HCX. В разделе «Службы» выберите «Миграция»>«Мигрировать».

    • Выберите вторую виртуальную машину узла.
    • Задайте кластер vSphere в удаленном частном облаке, на котором размещена перенесенная виртуальная машина SQL Server или виртуальные машины в качестве вычислительного контейнера.
    • Выберите хранилище данных vSAN в качестве удаленного хранилища.
    • Выберите папку, если вы хотите разместить виртуальные машины в определенной папке. Это не обязательно, но рекомендуется разделять различные нагрузки в вашем частном облаке Azure VMware Solution.
    • Сохраняйте тот же формат, что и источник.
    • Выберите 'Холодная миграция' в качестве профиля миграции.
    • В расширенных параметрах выберите "Перенос настраиваемых атрибутов".
    • Убедитесь, что локальные сегменты сети имеют правильный удаленный растянутый сегмент в Azure.
    • Выберите Проверить и убедитесь, что все проверки завершены успешно. Наиболее распространенная ошибка связана с конфигурацией хранилища. Повторно убедитесь, что контроллеры SCSI не настроены на физический общий доступ.
    • Выберите Go и инициируется миграция.

  7. Повторите тот же процесс для первого узла.

  8. Доступ к клиенту Azure VMware Solution vSphere и изменение параметров первого узла с возвратом к физическому совместному использованию шины SCSI контроллером или контроллерами SCSI, управляющими общими дисками.

  9. Изменение параметров узла 2 в клиенте vSphere.

    • Верните настройку общего доступа к шине SCSI на физический в контроллере SCSI, который управляет общим хранилищем.
    • Добавьте общие диски кластера в узел в качестве дополнительного хранилища. Назначьте их второму контроллеру SCSI.
    • Убедитесь, что все конфигурации хранилища совпадают с конфигурацией хранилища, записанной перед миграцией.

  10. Включите виртуальную машину первого узла.

  11. Доступ к первой виртуальной машине узла с помощью удаленной консоли VMware.

    • Проверьте конфигурацию сети виртуальной машины и убедитесь, что она может получить доступ к локальным ресурсам и ресурсам Azure.

    • Откройте Диспетчер отказоустойчивых кластеров и проверьте службы кластеров.

      На схеме показана сводка по кластеру в диспетчере отказоустойчивости кластеров.

  12. Включите виртуальную машину на втором узле.

  13. Доступ ко второй виртуальной машине узла из удаленной консоли VMware.

    • Убедитесь, что Windows Server может получить доступ к хранилищу.
    • В диспетчере отказоустойчивых кластеров проверьте, что второй узел отображается со статусом «онлайн». Схема показывает состояние узла кластера в диспетчере отказоустойчивости кластеров.

  14. Используя SQL Server Management Studio, подключитесь к сетевому имени ресурса кластера SQL Server. Убедитесь, что все базы данных в сети и доступны.

На схеме показана проверка подключения SQL Server Management Studio к перенесенной базе данных экземпляра кластера.

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

Дополнительные сведения

  • Last updated on