Это руководство описывает настройку отказоустойчивого кластера AlwaysOn Availability Group (AG) с двумя обычными узлами, одним узлом в Azure и использованием Azure Cloud Witness для кворума. В итоге вы получите продакшн‑кластер с автоматическим переключением на локальном уровне и DR‑репликой в облаке.
До появления Windows Server 2016, кластер можно было создать только для компьютеров в одном домене. Начиная с Windows Server 2016 появилась возможность создания отказоустойчивого кластера без зависимостей от Active Directory. Таким образом, отказоустойчивые кластеры теперь можно создавать в следующих конфигурациях:
У одного клиента был
очень конкретный сценарий:
· У них была группа доступности Always On с отказоустойчивым кластером Windows Server.· Каждый узел имел собственные диски, поэтому кворум был с использованием сетевой «шары».· Один узел находился в облаке, а другой был обычным сервером.· Сеть была нестабильной, что подтверждал агент мониторинга, который обнаружил потери связи, даже когда провайдер заверял, что проблем нет.· Некоторые сбои в работе сети привели к переходу кластера в состояние «resolving» с недоступностью баз, которая длилась до тех пор, пока не восстанавливалось соединение между узлами.
Однажды эти проблемы привели к повреждению операционки, когда на одном узле перестала запускаться служба кластера, а другой узел не смог принять на себя роль ведущего, потому что кластер был неисправен.
Разрабатывая функционал прослушивателя для группы доступности, мы общались со многими клиентами, и поняли, что есть пара сценариев, в которых может потребоваться наличие нескольких прослушивателей для одной группы доступности.
Это новая концепция обеспечения идентичности ограниченного набора системных объектов и сущностей, которой до этого очень недоставало. Администраторам баз данных приходилось «вручную» синхронизировать логины, задания агента, планы обслуживания и множество других системных сущностей, которые описывались в таблицах системных баз данных master и msdb. Теперь появился способ возложить это на SQL Server 2022, но ждать этой возможности нам пришлось 10 лет…
Эта статья - вольная интерпретация рекомендаций: Microsoft, IBM, HP, Dell, QLogic, LSI, EMC, ACER, Bull, Fujitsu, Hitachi, NEC и Unisys. Некоторые рекомендуемые настройки требуют отдельного, обстоятельного разговора, и потому не включены в эту статью, а найти эти рекомендации можно в этом блоге.
Ниже представлен свободный перевод одной из глав книги.
Авторы: Майк Вайнер (Mike Weiner), Пол Бурпо (Paul Burpo), Макс Верун (Max Verun), Джозеф Сак (Joseph Sack), Джастин Эриксон
(Justin Erickson)
Соавторы: Санджай Мишра (Sanjay Mishra), Джейсон Ву (Jason Wu), Уттам Паруи (Uttam Parui)
Технические редакторы: Прем Мехра (Prem Mehra), Джеймс Подгорски (James Podgorski), Дэвид Уитни (David Whitney), Ричард Ткачук (Richard Tkachuk), Сетху Калавакур (Sethu Kalavakur), Синди Гросс (Cindy Gross), Нил Грейвз (Neal Graves), Фарзан Ратистари (Farzan Ratistari), Айяд Шаммут (Ayad Shammout, Caregroup Healthcare Systems), Дейвид П. Смит (David P. Smith, ServiceU Corporation)
Опубликовано: июнь 2009 г.
Область применения: SQL Server 2008
Краткий обзор: Данный технический документ служит дополнением к существующей документации по планированию, реализации и администрированию отказоустойчивых кластеров SQL Server 2008, входящей в состав электронной документации по Microsoft SQL Server 2008. В настоящем руководстве содержатся ссылки на существующую документацию, предназначенные в первую очередь для технических специалистов. В этом техническом документе описываются архитектура отказоустойчивых кластеров и основные связанные с ней понятия в Windows Server и SQL Server 2008; установка отказоустойчивых кластеров SQL Server 2008; обновление отказоустойчивых кластеров SQL Server 2008; обслуживание и администрирование SQL Server 2008.
