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

Перенос группы доступности AlwaysOn SQL Server в Решение Azure VMware

  • Статья

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

Схема, на которой показана архитектура AlwaysOn SQL Server для Решение Azure VMware.

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

Необходимые компоненты

Ниже приведены предварительные требования для переноса экземпляра SQL Server в Решение Azure VMware.

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

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

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

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

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

Дополнительные рекомендации по простоям рассматриваются в следующем разделе.

Рекомендации по простою

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

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

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

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

Группы доступности AlwaysOn в Microsoft SQL Server используют отказоустойчивый кластер Windows Server, который требует механизма голосования кворума для обеспечения согласованности кластера.

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

  • Диск-свидетель
  • Файловый ресурс-свидетель
  • Облако-свидетель

Если кластер использует следящий диск, диск необходимо перенести с остальным общим хранилищем кластера, используя процедуру, описанную в этом документе.

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

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

Дополнительные сведения о настройке кворума и управлении ими см . в документации по отказоустойчивой кластеризации. Сведения о развертывании облака-свидетеля в Хранилище BLOB-объектов Azure см. в статье "Управление кворумом кластера для отказоустойчивого кластера".

Миграция группы доступности AlwaysOn SQL Server

  1. Доступ к группе доступности AlwaysOn с помощью SQL Server Management Studio с помощью учетных данных администрирования.

    • Выберите основную реплику и откройте свойства группы доступности. Схема свойств группы доступности AlwaysOn.
    • Измените режим доступности на асинхронную фиксацию только для миграции реплики.
    • Измените режим отработки отказа вручную для каждого члена группы доступности.

  2. Перейдите к локальному серверу vCenter Server и перейдите к области HCX.

  3. В разделе "Службы" выберите "Миграция миграции>".

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

  4. После завершения миграции перейдите к перенесенной реплике и проверьте подключение к остальным членам группы доступности.

  5. В SQL Server Management Studio откройте панель мониторинга группы доступности и убедитесь, что реплика отображается как Online. Схема, на которой показана панель мониторинга группы доступности AlwaysOn.

    • Состояние потери данных в столбце готовности к отработке отказа ожидается, так как реплика не синхронизируется с основным во время миграции.

  6. Измените свойства группы доступности еще раз и задайте режим доступности в синхронную фиксацию.

    • Вторичная реплика начинает синхронизировать все изменения, внесенные в первичную реплику во время миграции. Подождите, пока оно не появится в синхронизированном состоянии.

  7. На панели мониторинга группы доступности в SSMS выберите мастер запуска отработки отказа.

  8. Выберите перенесенную реплику и нажмите кнопку "Далее".

    Схема, показывающая новый выбор первичной реплики для AlwaysOn.

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

  10. Просмотрите изменения и нажмите кнопку "Готово ", чтобы запустить операцию отработки отказа.

    Схема, на которой показана проверка операции AlwaysOn группы доступности.

  11. Отслеживайте ход отработки отказа на следующем экране, нажмите кнопку "Закрыть ", когда операция завершится. Схема, показывающая, что кластер AlwaysOn SQL Server успешно завершен.

  12. Обновите представление обозреватель объектов в СРЕДЕ SQL Server Management Studio (SSMS), убедитесь, что перенесенный экземпляр теперь является основной репликой.

  13. Повторите шаги 1–6 для остальных реплик группы доступности.

    Примечание.

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

  14. После завершения миграции всех реплик получите доступ к группе доступности AlwaysOn с помощью SQL Server Management Studio.

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

    • Измените свойства группы доступности и установите режим отработки отказа автоматически во всех репликах.

      Схема, на которой показан параметр отработки отказа обратно в

Следующие шаги