sql always on что это
Экземпляры отказоустойчивого кластера AlwaysOn (SQL Server)
Экземпляр отказоустойчивого кластера (FCI) может эффективно использовать группы доступности для удаленного аварийного восстановления на уровне базы данных. Дополнительные сведения см. в статье Failover Clustering and Always On Availability Groups (SQL Server) (Отказоустойчивая кластеризация и группы доступности AlwaysOn (SQL Server)).
В версии Windows Server 2016 Datacenter добавлена поддержка локальных дисковых пространств (S2D). Экземпляры отказоустойчивого кластера SQL Server поддерживают S2D для ресурсов хранилища кластера. Дополнительные сведения можно найти в статье о локальных дисковых пространствах в Windows Server.
Также экземпляры отказоустойчивого кластера поддерживают кластеризованные общие тома (CSV). Дополнительные сведения см. в разделе Основные сведения о кластерных общих томах в отказоустойчивом кластере.
В этой статье вы найдете:
Преимущества экземпляра отказоустойчивого кластера
При сбое оборудования или программного обеспечения сервера приложения или клиенты, связывающиеся с сервером, будут простаивать. Если экземпляр SQL Server настроен как отказоустойчивый кластер (а не как независимый экземпляр), высокий уровень доступности такого экземпляра SQL Server защищен наличием избыточных узлов в отказоустойчивом кластере. Только один из узлов в FCI принадлежит группе ресурсов WSFC одновременно. В случае сбоя (отказа оборудования, сбоя операционной системы, приложений или служб) либо при выполнении запланированного обновления группа передается во владение другому узлу отказоустойчивого кластера. Данный процесс не заметен для клиента или приложения, соединяющегося с SQL Server, и сводит к минимуму время ожидания приложения или клиента во время сбоя. Ниже перечислены некоторые ключевые преимущества, которые обеспечивают экземпляры отказоустойчивого кластера SQL Server :
Защита на уровне экземпляра через избыточность
Автоматический переход на другой ресурс в случае сбоя (отказа оборудования, сбоя операционной системы, приложений или служб)
Поддержка широкого массива решения хранения, включая диски кластеров WSFC (iSCSI, Fiber Channel и т. д.) и общие папки протокола SMB.
Решения аварийного восстановления с использованием нескольких подсетей FCI или запуска базы данных на FCI внутри группы доступности. Благодаря новой поддержке большого числа подсетей в среде MicrosoftSQL Server 2012 (11.x)кластеру FCI с большим количеством подсетей больше не нужна виртуальная локальная сеть, что повышает управляемость и безопасность кластера FCI с большим числом подсетей.
Нулевая реконфигурация приложений и клиентов при сбое
Гибкая политика отработки отказа для гранулированных событий триггера для автоматической отработки отказа
Надежная отработка отказа посредством периодического подробного отслеживания исправности системы с помощью выделенных и постоянных соединений
Возможность настройки и предсказуемость во время отработки отказа посредством косвенных контрольных точек
Использование регулируемых ресурсов при отработке отказа
Рекомендации
В рабочей среде рекомендуется использовать статические IP-адреса в сочетании с виртуальным IP-адресом экземпляра отказоустойчивого кластера. Не рекомендуется использовать протокол DHCP в рабочей среде. В случае простоя, если время действия IP-адреса протокола DHCP истекло, на регистрацию нового сетевого IP-адреса протокола DHCP, связанного с DNS-именем, уйдет дополнительное время.
Общие сведения об экземпляре отказоустойчивого кластера
FCI работает в группе ресурсов WSFC вместе с одним или несколькими узлами WSFC. Когда экземпляр FCI запускается, один из узлов принимает владение группой ресурсов и выводит свой экземпляр SQL Server в сеть. Ресурсы, принадлежащие данному узлу включают в себя:
SQL Server Служба компонента Database Engine
SQL Server Служба агента
SQL Server Analysis Services, если эти служб установлены
Один файловый ресурс общего доступа, если установлен компонент FILESTREAM
В любое время только владелец группы ресурсов (и никакой другой узел в FCI) запускает соответствующие службы SQL Server в группе ресурсов. При автоматическом или запланированном переходе на другой ресурс происходит следующая последовательность событий.
Если событие не является сбоем оборудования или системы, все «грязные» страницы в буферном кэше записываются на диск.
Все соответствующие службы SQL Server в группе ресурсов останавливаются на активном узле.
Права владения группой ресурсов переносятся на другой узел в FCI.
Клиентские запросы на подключение приложения автоматически перенаправляются на новый активный узел, используя то же имя виртуальной сети (VNN).
FCI находится в сети, если его базовый кластер WSFC находится в исправном состоянии (большая часть узлов кворума WSFC доступны в качестве целей автоматического перехода на другой ресурс). Когда кластер WSFC теряет кворум из-за сбоя аппаратной части, программного обеспечения, сети или неверной настройки кворума, весь кластер WSFC вместе с FCI выводится из сети. Для этого незапланированного сценария отработки отказа требуется вмешательство пользователя, который должен переустановить кворум для оставшихся доступных узлов, чтобы вернуть кластер WSFC и FCI обратно в сеть. Дополнительные сведения см. в статье Режимы кворума и конфигурация голосования WSFC (SQL Server).
Прогнозируемое время отработки отказа
В зависимости от того, когда экземпляр SQL Server в последний раз выполнял операцию контрольной точки, в буферном кэше может быть достаточное количество «грязных» страниц. Последующая отработка отказа длится столько, сколько потребуется времени для записи оставшихся «грязных» страниц на диск, что может увеличить время отработки отказа непредсказуемым образом. Начиная с MicrosoftSQL Server 2012 (11.x) FCI может использовать косвенные контрольные точки для регулирования числа «грязных» страниц, хранимых в буферном кэше. Несмотря на то что это занимает дополнительные ресурсы при нормальной рабочей нагрузке, время отработки отказа становится более прогнозируемым и регулируемым. Это очень полезно, когда в соглашении об уровне обслуживания в организации указана цель времени восстановления (RTO) для решения высокого уровня доступности. Дополнительные сведения о косвенных контрольных точках см. в разделе Indirect Checkpoints.
Надежный мониторинг исправности и гибкая политика отработки отказа
Выделенное соединение с экземпляром SQL Server позволяет получать надежную диагностику компонентов в любое время, даже когда FCI испытывает перегрузку. В результате можно выделить систему, испытывающую большую нагрузку, и систему, которая находится на грани отработки отказа, позволяя избежать проблем, связанных с ложной отработкой отказа.
Подробная диагностика компонентов позволяет настроить более гибкую политику отработки отказа, с помощью которой вы можете выбрать, какие условия отказа запускают отработку отказа, а какие нет.
Элементы экземпляра отказоустойчивого кластера
Группа ресурсов WSFC
FCI SQL Server работает в группе ресурсов WSFC. Каждый узел в группе ресурсов поддерживает синхронизированную копию параметров конфигурации и разделов реестра для того, чтобы сохранить полную функциональность FCI после отработки отказа, при этом только один узел в кластере владеет группой ресурсов одновременно (активный узел). Служба WSFC управляет кластером сервера, конфигурацией кворума, политикой и операциями отработки отказа, а также именем виртуальной сети и виртуальными IP-адресами для FCI. В случае сбоя (сбоев оборудования, сбоев операционной системы, приложений или служб) либо при выполнении запланированного обновления группа ресурсов передается во владение другому узлу в FCI. Количество узлов, поддерживаемых в группе ресурсов WSFC, зависит от выпуска SQL Server. Также один кластер WSFC может запускать несколько FCI (множественные группы ресурсов), в зависимости от возможностей оборудования, например ЦП, памяти и числа дисков.
Память
В отличие от группы доступности, на всех узлах FCI должно использоваться общее хранилище для базы данных и журналов. Это общее хранилище может быть организовано в форме дисков кластера WSFC, дисков в сети хранения данных (SAN), локальных дисковых пространств (S2D) или общих папок SMB. Таким образом, все узлы в FCI имеют одинаковое представление данных экземпляра всегда, когда происходит отработка отказа. Однако в этом случае общее хранилище может стать единственной точкой сбоя, в то время как FCI зависит от базового решения хранилища для обеспечения защиты данных.
Сетевое имя
VNN для FCI предоставляет единую точку соединения для FCI. Это позволяет приложениям подключаться к VNN без необходимости знать текущий активный узел. Когда происходит отработка отказа, VNN регистрируется на новом активном узле после его запуска. Данный процесс не заметен для клиента или приложения, соединяющегося с SQL Server, и сводит к минимуму время ожидания приложения или клиента во время сбоя.
Виртуальные IP-адреса
В случае многоподсетевого кластера FCI виртуальный IP-адрес присваивается каждой подсети FCI. В ходе отработки отказа VNN-имя DNS-сервера обновляется и указывает на виртуальный IP-адрес соответствующей подсети. Приложения и клиенты могут подключиться к FCI, используя то же самое имя VNN после многоподсетевой отработки отказа.
Масштабирование базы данных. Microsoft AlwaysOn
Привет. Меня зовут Тигран Петросян, я ведущий инженер по технической поддержке Docsvision, и сегодня расскажу о применении технологии MS SQL AlwaysOn. Это вторая статья из мини-серии «Масштабируемость системы ECM на предприятии», в которой первая статья моего коллеги была посвящена технологии масштабирования поиска Elasticsearch.
Оба материала могут быть интересны не только тем, кто работает с Docsvision, но и всем, интересующимся технологиями масштабирования.
Пара слов о том, почему мы об этом говорим
Последняя версия СЭД/ECM платформы Docsvision, разработкой которой мы занимаемся, отличается принципиально от предыдущих версий своей модульной архитектурой. Было важно обеспечить возможность масштабировать систему (причём практически неограниченно) с сохранением скорости работы. Одна из технологий, положенных в основу новых возможностей платформы, — MS SQL AlwaysOn.
Мои коллеги уже рассказывали о технологиях масштабирования, положенных в основу новых возможностей платформы: есть серия из 4-х мини-вебинаров на YouTube, серия из 3-х статей на Medium (статья №1, статья 2, а статья №3 как раз посвящена теме масштабирования БД). В этих материалах более чётко обозначено, какие проблемы мы решали и чего достигли в их решении.
Я же рассмотрю одну конкретную функцию MS SQL AlwaysOn, повышающую надёжность и производительность сервера БД.
Рис. 1. Сегодня архитектура платформы Docsvision выглядит так.
Масштабирование сервиса баз данных. MS SQL AlwaysOn
В инструменты повышения производительности и масштабирования сервиса базы данных нашей платформы Docsvision вошла возможность создания кластеров серверов БД. Эту возможность обеспечивает технология MS SQL AlwaysOn.
Группы доступности AlwaysOn в рамках БД Docsvision может выполнять сразу две задачи:
Как видно на схеме, мы распределяем именно нагрузку на чтение, поскольку подавляющая часть операций пользователей в системе — это операции чтения (поиск, отчёты, открытие документов).
В ходе тестирования изначально master-сервер у нас был мощнее, чем slave-сервер. Однако, при преодолении цифры примерно в 40 тысяч пользователей, мы увидели, что slave-сервера не справляются, а master, наоборот, недогружен. Это было практическим подтверждением того, что запросов на чтение больше, нагрузки они генерят больше, поэтому в первую очередь мы распределяем её между узлами.
При работе режима Always On различают несколько видов запросов пользователей:
Настройка групп доступности Always On в SQL Server
В этой статье мы рассмотрим пошаговую установку и настройку групп доступности Always On в SQL Server в Windows Server 2019, рассмотрим сценарии отработки отказов и ряд других смежных вопросов.
“Always On Availability Groups” или “Группы доступности Always On” это технология для обеспечения высокой доступности в SQL Server. Always On появились в релизе Microsoft SQL Server 2012.
Особенности групп доступности Always On в SQL Server
Для чего могут использоваться группы доступности SQL Server?
Always On работает на платформе Windows Server Failover Cluster (WSFC). WSFC обеспечивает мониторинг узлов участвующих в группе доступности и может осуществлять автоматическую отработку отказа посредством голосования между узлами. Начиная с MS SQL Server 2017 появилась возможность использовать Always On без WSFC, в том числе на Linux системах. При построении кластера на Linux можно использовать Pacemaker как альтернативу WSFC.
Always On доступен в Standard редакции, но с некоторыми ограничениями:
В редакции Enterprise ограничений нет.
Разберемся в терминологии:
В основе Always On лежит WSFC. Каждый узел группы доступности должен быть членом отказоустойчивого кластера Windows. Каждый экземпляр SQL Server может иметь несколько групп доступности. В каждой группе доступности может быть до 8 вторичных реплик.
При отказе основой реплики, кластер проголосует за новую основную реплику и Always On переведёт одну из вторичных реплик в статус основной. Так как при работе с Always On пользователи соединяются с прослушивателем кластера (или Listener, то есть специальный IP адрес кластера и соответствующее ему DNS имя), то возможность выполнять write запросы полностью восстановится. Прослушиватель также отвечает за балансировку select запросов между вторичными репликами.
Настройка Windows Server Failover Cluster для Always On
Прежде всего нам нужно настроить отказоустойчивый кластер на всех узлах, которые будут участвовать в Always On.
В Server Manager добавляем роль Failover Clustering, или установите компонент с помощью PowerShell:
Install-WindowsFeature –Name Failover-Clustering –IncludeManagementTools
Установка автоматическая, ничего настраивать пока не нужно. После окончания установки запустите оснастку Failover Cluster Manager (FailoverClusters.SnapInHelper.msc).
Создаём новый кластер.
Добавляем имена серверов, которые будут участвовать в кластере.
Дальше мастер предлагает пройти тесты. Не отказываемся, выбираем первый пункт.
Указываем имя кластера, выбираем сеть и IP адрес кластера. Имя кластера автоматически появится в DNS, прописывать его специально не нужно. В моём случае имя кластера – ClusterAG.
Убираем чебокс “Add all eligible storage to the cluster”, так как диски мы сможем добавить позже.
Выберите тип кворума со свидетелем (quorum witness).
Затем выбираем тип свидетеля – сетевая папка (file share witness).
Укажите UNC путь к сетевой папке. Эту директорию нужно создать самостоятельно, и она обязательно должна быть на сервере, который не участвует в кластере.
При настройке кластера вы можете получить ошибку:
Скорее всего это значит, что у пользователя из-под которого работает кластер нет прав на эту сетевую папку. По-умолчанию кластер работает из-под локального пользователя. Вы можете дать права на эту папку всем компьютерам кластера, либо сменить аккаунт для службы кластера и раздать права ему.
На этом базовая конфигурация кластера закончена. Убедимся, что DNS кластера прописан и отдаёт правильный IP
Настройка Always On в MS SQL Server
После стандартной установки экземпляра SQL Server вы можете включить и настроить группы доступности Always On. Их нужно включить в SQL Server Configuration Manager в свойствах экземпляра. Как видно на скриншоте, SQL Server уже определил, что он является участником кластера WSFC. Поставьте чекбокс “Enable Always On Availability Groups” и перезагрузите службу экземпляра MSSQL. Выполните те же действия на втором экземпляре.
В SQL Server Management Studio щелкните по узлу “Always On High Availability” и запустите мастер настройки группы доступности (New Availability Group Wizard).
Укажите имя группы доступности Always On и выберите опцию “Database Level Health Detection”. С этой опцией Always On сможет определять, когда база данных находится в нездоровом состоянии.
Выберите базы данных SQL Server, которые будут участвовать в группе доступности Always On.
Нажмите “Add Replica…” и подключитесь к второму серверу SQL. Таким образом можно добавить до 8 серверов.
Вкладку Endpoints не трогаем.
На вкладке Backup Preferences можно выбрать откуда будут делаться бекапы. Оставляем всё по умолчанию – Prefer Secondary.
Указываем имя слушателя группы доступности (availability group listener), порт и IP адрес.
Вкладку Read-Only Routing оставляем без изменений.
Выбираем каким образом будут синхронизироваться реплики. Я оставляю первый пункт – автоматическую синхронизацию (Automatic seeding).
После этого ваши настройки должны пройти валидацию. Если ошибок нет, нажмите Finish для применения изменений.
В моём случае все тесты прошли успешно, но после установки на шаге Results, мастер сообщил об ошибке при создании слушателя группы доступности. В логах кластера была такая ошибка:
Это означает, что у кластера недостаточно прав для создания слушателя. В документации написано, что достаточно дать разрешение на создание объектов типа “компьютер” объекту вашего кластера. Проще всего это сделать через делегирование полномочий в AD (или, быстрый но плохой вариант — временно добавить объект CLUSTERAG$ в группу Domain Admins).
Так как группа доступности у меня создалась, а слушатель нет, я добавил его вручную. Вызываем контекстное меню на группе доступности и жмем Add Listener…
Укажите IP адрес, порт и DNS имя слушателя.
Проверьте, что Listener появился во разделе доступных слушателей группы Always On.
На этом базовая настройка группы доступности Always On закончена.
Always On: проверка работы, автоматическая отработка отказа
Посмотрим на панель мониторинга групп доступности (Show Dashboard).
Все OK, группа доступности создана и работает.
Попробуем перевести основную роль на экземпляр node2 в ручном режиме. Щелкните ПКМ по группе доступности и выберите Failover.
Стоит обратить внимание на пункт Failover Readiness. Значение No data loss значит, что потеря данных при переходе исключена.
Соединяемся с node2.
Проверяем, что node2 стал основной репликой в группе доступности (Primary Instance).
Убедимся, что слушатель работает как надо. В SSMS укажите DNS имя слушателе и порт через запятую: ag1-listener-1,1445
Сделаем простые insert, select и update запросы в нашу базу SQL Server.
Теперь проверим автоматическую отработку отказа основной реплики. Просто завершите процесс sqlservr.exe на TESTNODE2.
Проверяем состояние группы доступности на оставшемся узле – TESTNODE1\NODE1.
Кластер автоматически перевёл статус реплики testnode1\node1 в primary, так как testnode2\node2 стал недоступен.
Проверим состояние слушателя, потому что соединения клиентов будут поступать именно на него.
В моём случае я успешно соединился со слушателем, но при доступе к базе данных появилась ошибка
Эта ошибка возникла из-за параметра “Required synchronized secondaries to commit”. Так как при настройке мы выставляли это значение в 1, Always On не даёт подключиться к базе данных, потому что у нас осталась всего одна primary реплика.
Установим это значение в 0 и попробуем снова.
Включаем testnode2 и проверяем статус группы.
Статус Primary реплики остался у testnode1, а testnode2 стал вторичной репликой. Данные, которые мы меняли на testnode1 при выключенной testnode2 успешно синхронизировались после включения машины.
На этом тестирование закончено. Мы убедились всё работает корректно и при критическом сбое данные останутся доступны для read/write доступа.
Группы доступности Always On достаточно просты в настройке. Если перед вами стоит задача построить отказоустойчивое решение на базе SQL Server, то группы доступности отлично справятся с этой задачей.
С выпуском SQL Server 2017 и SQL Server 2019 в SQL Server Management Studio 18.x появились настройки Always On, которые раньше были доступны только через T-SQL, поэтому рекомендуется пользоваться последней версией SSMS.