Поделиться через

Перенос экземпляра отказоустойчивого кластера SQL Server AlwaysOn в Решение Azure VMware

  • Статья

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

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

На схеме показана архитектура отработки отказа SQL Server для Решение Azure VMware.

Примечание.

Для этой процедуры требуется полное завершение работы кластера. Так как служба 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, на котором выполняются перенесенные рабочие нагрузки. Дополнительные сведения об установке VMware HCX см. в Решение Azure VMware документации.
  • Убедитесь, что все сегменты сети, используемые 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 частном облаке.
    • Разверните облако-свидетель, работающий в Хранилище BLOB-объектов Azure в том же регионе, что и частное облако Решение Azure VMware.
  • Аварийное восстановление и непрерывность бизнес-процессов. Для сценария аварийного восстановления лучший и самый надежный вариант — создать облачный свидетель, работающий в служба хранилища Azure.
  • Модернизация приложений. Для этого варианта лучше всего развернуть облачный свидетель.

Дополнительные сведения о конфигурации кворума и управлении см . в документации по отказоустойчивой кластеризации. Дополнительные сведения о развертывании облака-свидетеля в Хранилище BLOB-объектов 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 из физическогов none на виртуальных контроллерах SCSI, используемых для общего хранилища. Обычно эти контроллеры имеют тип VMware Paravirtual.

  5. Измените параметры виртуальной машины первого узла. Задайте общий доступ к шине SCSI из физическогов none на контроллерах SCSI.

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

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

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

  8. Доступ к Решение Azure VMware клиенту 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 из других систем и приложений в вашей инфраструктуре. Убедитесь, что все приложения, использующие базу данных или базы данных, по-прежнему могут получить к ним доступ.

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