У одного клиента был
очень конкретный сценарий:
· У них была группа доступности Always On с отказоустойчивым кластером Windows Server.· Каждый узел имел собственные диски, поэтому кворум был с использованием сетевой «шары».· Один узел находился в облаке, а другой был обычным сервером.· Сеть была нестабильной, что подтверждал агент мониторинга, который обнаружил потери связи, даже когда провайдер заверял, что проблем нет.· Некоторые сбои в работе сети привели к переходу кластера в состояние «resolving» с недоступностью баз, которая длилась до тех пор, пока не восстанавливалось соединение между узлами.
Однажды эти проблемы привели к повреждению операционки, когда на одном узле перестала запускаться служба кластера, а другой узел не смог принять на себя роль ведущего, потому что кластер был неисправен.
Поэтому они захотели
себе такую группу доступности, которая не зависела бы от сети или работоспособности
службы кластера. Им не нужна автоматическая реакция на отказы, поскольку сбои в
работе сети были кратковременны и не заслуживали простоя. Кроме того, они теряли
транзакции при отказе (ИТ-шники могут повторить все операции, во время которых случился
сбой, и вручную исправить записи при необходимости). Кроме того, им было нужно облегчить
обслуживание и выполнять миграции с минимальным вмешательством «руками».
В данном случае идеально
подошла бы распределенная группа доступности без кластера, но по этому поводу
нет никакой документации: везде указано, что для этого требуется кластер, в
противном случае ничего не выйдет.
Если бы в природе
существовала группа доступности без кластера, вот что стало бы возможным:
· Снижение сложности: вам не потребуется распределять ресурсы между экземплярами и не нужен дополнительный функционал, поэтому будет меньше возможных точек отказа.
· Отсутствие зависимости от сети: кластерная технология во многом зависит от сети, и когда она нестабильна или не надежна на 100%, это приводит к простоям.
· Меньше зависимостей: упростив конфигурацию, можно сразу приступить к настройке и эксплуатации без дополнительных специальных знаний или требований.
· Меньше ошибок: поскольку используется меньше компонент, которые могут выйти из строя, простоев будет меньше, и устранение неисправностей станет проще.
· Меньше накладных расходов: кластерная технология потребляет ресурсы (процессоры и сеть), проверяя кворум, обмениваясь сигналами жизни и выясняя статусы узлов, проверяя доступность ресурсов, связи и синхронизацию.
· Нет необходимости в общем диске для кворума: решение работает в гетерогенных средах, и вам не нужно тратить дополнительные деньги на его настройку.
А вот какие
преимущества даёт распределенная группа доступности:
· Независимость: физически разные площадки, разные ОС, разные версии SQL Server, разные домены и разные поставщики облачных услуг – это позволяет создать более гибкое решение для восстановления в случае аварии.
· Автоматическая раздача (seeding): упрощает первоначальную синхронизацию данных; нет необходимости в ручном резервном копировании и восстановлении.
· Географическое распределение: допускается размещение ЦОД в разных географических зонах.
· Работает при низкой пропускной способности сети: сетевой трафик меньше и проще.
· Простая миграция: на другое железо, ОС, версию SQL Server и т. д.
Но учтите, есть и
недостатки, о которых вам следует знать:
· Поскольку нет кластера, это решение не обеспечивает высокую доступность: не контролируется работоспособность системы, поэтому копии не будут считаться синхронными (такое решение не рекомендуется для критически важных систем или в случаях, когда транзакции невозможно как-то повторить).
· Эта конфигурация не поддерживается Microsoft, и вы наверняка столкнётесь с какими-нибудь ошибками. Однако мы ожидаем, что в будущем будет обеспечена его полная поддержка, поскольку это работает.
· Контейнерные группы доступности не работают в варианте со вторичным ЦОД (но можно будет заставить их работать в SQL Server 2025 с помощью AUTOSEEDING_SYSTEM_DATABASES). Основной ЦОД может содержать контейнерную группу доступности, но системные базы данных master/msdb не будут синхронизироваться на вторичных ЦОД.
В целях демонстрации я
создал две группы доступности для чтения и масштабирования, следуя инструкциям Edwin Sarmiento по следующей ссылке: SQL Server Read-Scale Always On Availability Groups
Получилась следующая конфигурация:
Avail. Group
SQLPRODAG SQLPREMAG
Primary CLOUD1 ONPREMISE1
Secondary CLOUDDR2 ONPREMISEDR2
Затем я создал прослушиватель
в соответствии с инструкциями: Read-Scale Always On Availability Group to Offloading Reporting
Нужно уточнить, что тут
в список маршрутизации чтения добавляется только вторичный узел; это означает,
что для узла CLOUD1 в списке маршрутизации чтения будет только CLOUDDR2 и
наоборот, а не оба узла.
Теперь конфигурация
стала такой:
Avail. Group SQLPRODAG
SQLPREMAG
Primary CLOUD1 ONPREMISE1
Secondary CLOUDDR2 ONPREMISEDR2
Listener SQLPROD SQLPREM
Далее, давайте воспользуемся
еще одним советом из другой статьи, но будет несколько отличий: Distributed Availability Groups for SQL Server Disaster Recovery
Сначала нужно
обеспечить, чтобы SQLPREMAG имела только один узел, поэтому удалим из неё
ONPREMISEDR2. На узле OPREMISEDR2 удалим все оставшиеся объекты группы
доступности. Также из ONPREMISE1 удалим базу данных, использованную при
первоначальной настройке, не оставив ни одной базы данных.
Теперь на основном
узле SQLPROD создадим распределенную группу доступности:
CREATE AVAILABILITY GROUP [DIST_SQLPROD]
WITH (DISTRIBUTED) AVAILABILITY GROUP ON
'SQLPRODAG' WITH (
LISTENER_URL = 'TCP://SQLPROD.testdomain.com:5022',
AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
FAILOVER_MODE = MANUAL,
SEEDING_MODE = AUTOMATIC),
'SQLPREMAG' WITH (
LISTENER_URL = 'TCP://SQLPREM.testdomain.com:5022',
AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
FAILOVER_MODE = MANUAL,
SEEDING_MODE = AUTOMATIC);
ALTER AVAILABILITY GROUP [DIST_SQLPROD] JOIN AVAILABILITY GROUP ON
'SQLPRODAG' WITH (
LISTENER_URL = 'TCP://SQLPROD.testdomain.com:5022',
AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
FAILOVER_MODE = MANUAL,
SEEDING_MODE = AUTOMATIC),
'SQLPREMAG' WITH (
LISTENER_URL = 'TCP://SQLPREM.testdomain.com:5022',
AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
FAILOVER_MODE = MANUAL,
SEEDING_MODE = AUTOMATIC);
После этого вы увидите распределенную группу доступности на SQLPROD:
И на SQLPREM тоже:
Вы должны увидеть, что базы данных на SQLPREM начнут синхронизироваться. Однако после завершения синхронизации распределённая группа доступности по-прежнему будет отображаться как NOT_HELTHY:
Вот некоторые моменты, которые стоит учитывать:
1. Синхронизация займёт больше времени. Добавление узла в SQLPROD заняло пару часов для синхронизации 2 ТБ данных, а добавление узла в SQLPREM заняло около 10 часов.
2. Если вы не удалите все базы данных на вторичном ЦОД, это не позволит создать распределенную группу доступности.
3. Если не удалить вторичный узел на SQLPREM, это вызовет несколько ошибок синхронизации и, скорее всего, она не завершится успешно даже за 12 часов.
4. Если синхронизация займет больше 12 часов, не получится синхронизировать оставшиеся базы данных, что означает, что этот вариант не подойдёт.
5. На первичной реплике основного ЦОД будет по-прежнему ошибка: Failed to update Replica status due to exception 35222.
Несмотря на это, базы
данных реплицируются на второй ЦОД.
Теперь можно вернуть
обратно в группу доступности SQLPREMAG вторичный узел (и любой другой узел), запустив
команду ниже на ONPREMISE1, без необходимости обеспечения дополнительной
пропускной способности, поскольку все данные загрузятся с первичной реплики:
ALTER AVAILABILITY GROUP [SQLPREMAG] ADD REPLICA ON 'ONPREMISEDR2' WITH (
ENDPOINT_URL = 'TCP://ONPREMISEDR2.testdomain.com:5022',
AVAILABILITY_MODE = ASYNCHRONOUS_COMMIT,
FAILOVER_MODE = MANUAL,
BACKUP_PRIORITY = 50,
SEEDING_MODE = AUTOMATIC,
SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL));
ALTER AVAILABILITY GROUP [SQLPREMAG] MODIFY REPLICA ON N'ONPREMISE1' WITH (SECONDARY_ROLE(ALLOW_CONNECTIONS = ALL));
После этого, оставаясь на первичной реплике ONPREMISE1, раскройте в студии узел «Availability Replicas», выберите «ONPREMISEDR2», и нажав на «Join to Availability Group», подключитесь к серверу, а потом ответьте на продолжения нажатием «ОК».
После этого, на вторичной
реплике «ONPREMISEDR2» выполните следующую команду:
ALTER AVAILABILITY GROUP [SQLPREMAG] GRANT CREATE ANY DATABASE;
Включение этой настройки позволит протестировать отказоустойчивость между экземплярами и между ЦОД.
Комментариев нет:
Отправить комментарий