Pacemaker для групп доступности и экземпляров отказоустойчивого кластера в Linux
Область применения:
SQL Server — Linux
Начиная с SQL Server 2017 (14.x), SQL Server поддерживается как в Linux, так и в Windows. Как и развертывания SQL Server под управлением Windows, базы данных и экземпляры SQL Server должны быть высокодоступными в Linux. В этой статье рассматриваются основные сведения о Pacemaker с Corosync, а также о том, как спланировать и развернуть его для конфигураций SQL Server.
Основные сведения о расширении и надстройке для обеспечения высокого уровня доступности
Все поддерживаемые в настоящее время дистрибутивы содержат надстройку или расширение для обеспечения высокого уровня доступности, основанные на стеке кластеризации Pacemaker. Этот стек включает два ключевых компонента: Pacemaker и Corosync. Все компоненты, входящие в стек:
- Синусовый узел сердца. Основной компонент кластеризации, который координирует вещи между кластеризованными компьютерами.
- Corosync. Платформа и набор API, предоставляющий такие вещи, как кворум, возможность перезапуска неудачных процессов и т. д.
- libQB. Предоставляет такие вещи, как ведение журнала.
- Агент ресурсов. Определенные функциональные возможности, предоставляемые для интеграции приложения с Pacemaker.
- Агент ограждения. Скрипты и функции, которые помогают изолировать узлы и справиться с ними, если у них возникли проблемы.
Примечание.
В среде Linux стек кластера обычно называют Pacemaker.
Это решение в некоторой степени аналогично развертыванию кластеризованных конфигураций с помощью Windows, однако оно во многом от него отличается. В Windows форма доступности кластеризации, называемая отказоустойчивым кластером Windows Server (WSFC), встроена в операционную систему, а функция, позволяющая создавать кластер WSFC (отказоустойчивая кластеризация), по умолчанию отключена. В Windows группы управления доступом и ЦС создаются на основе WSFC, а также обеспечивают тесную интеграцию из-за конкретной библиотеки ресурсов, предоставляемой SQL Server. Это тесно связанное решение возможно и по большому счету, потому что все это от одного поставщика.
Хотя Pacemaker доступен во всех поддерживаемых дистрибутивах Linux, каждое из них может настраиваться и иметь незначительно отличающиеся реализации и версии. Некоторые отличия будут показаны в инструкциях, приведенных в этой статье. Уровень кластеризации открытый код, поэтому, несмотря на то, что он поставляется с дистрибутивами, он не тесно интегрирован таким же образом, как WSFC находится под Windows. Именно поэтому корпорация Майкрософт предоставляет mssql-server-ha, чтобы SQL Server и стек Pacemaker могли обеспечить близкое расположение, но не точно так же, как и в Windows.
Полную документацию по Pacemaker, включая более подробные и полные справочные сведения по RHEL и SLES, см. на следующих ресурсах:
В Ubuntu нет руководства по доступности.
Дополнительные сведения обо всем стеке см. на официальной странице документации Pacemaker на сайте ClusterLabs.
Основные понятия и терминология Pacemaker
В этом разделе описываются общие понятия и терминология для реализации Pacemaker.
Узел
Узел — это сервер, входящий в кластер. Кластер Pacemaker изначально поддерживает до 16 узлов. Это число может быть превышено, если Corosync не работает на дополнительных узлах, но Для SQL Server требуется Corosync. Таким образом, максимальное количество узлов кластера может иметь для любой конфигурации на основе SQL Server: 16; это ограничение Pacemaker и не имеет ничего общего с максимальными ограничениями для AGS или FCIs, введенных SQL Server.
Ресурс
Кластеры WSFC и Pacemaker поддерживают понятие ресурса. Ресурс — это специальная функциональная возможность, выполняемая в контексте кластера, например диск или IP-адрес. Например, в Pacemaker можно создать и ресурсы FCI, и ресурсы группы доступности. Это не отличается от того, что делается в WSFC, где вы видите ресурс SQL Server для ресурса FCI или группы доступности при настройке группы доступности, но не совсем так же из-за базовых различий в том, как SQL Server интегрируется с Pacemaker.
Pacemaker имеет стандартные и клонированные ресурсы. Клонированные ресурсы — это объекты, которые выполняются одновременно на всех узлах. Примером может быть IP-адрес, доступный на нескольких узлах в целях балансировки нагрузки. Любой ресурс, создаваемый для экземпляра FCI, использует стандартный ресурс, так как в определенный момент времени экземпляр FCI может размещаться только на одном узле.
Примечание.
Обмен данными без смещения
Эта статья содержит ссылки на термин slave (подчиненный), который Майкрософт считает оскорбительным при использовании в этом контексте. Термин присутствует в этой статье, так как в настоящее время он присутствует в программном обеспечении. При удалении термина из программного обеспечения мы удалим его из статьи.
Созданной группе доступности требуется особая форма клонированного ресурса, называемая ресурсом с несколькими состояниями. Хотя группа доступности имеет только одну первичную реплику, сама группа доступности работает на всех узлах, с которыми она настроена для работы, и может потенциально разрешить такие вещи, как доступ только для чтения. Так как это "динамическое" использование узла, ресурсы имеют концепцию двух состояний: "Повышено" (ранее главное) и не проимотировано (ранее раб). Дополнительные сведения см. в разделе "Ресурсы с несколькими состояниями" с несколькими режимами.
Группы и наборы ресурсов
Подобно ролям в WSFC, кластер Pacemaker поддерживает концепцию группы ресурсов. Группа ресурсов (называемая набором в SLES) представляет собой коллекцию ресурсов, которые работают вместе и могут выполнять отработку отказа с одного узла на другой как единое целое. Группы ресурсов не могут содержать ресурсы, настроенные как "Повышение " или "Непропродажи", поэтому они не могут использоваться для групп доступности. Хотя группу ресурсов можно использовать для ФКК, обычно это не рекомендуется.
Ограничения
WSFCs имеют различные параметры для ресурсов и таких зависимостей, которые сообщают WSFC отношения между двумя разными ресурсами. Зависимость — это просто правило, указывающее WSFC, какой ресурс должен быть переведен в сетевой режим первым.
Кластер Pacemaker не имеет понятия зависимостей, но есть ограничения. Существует три типа ограничений: совместное размещение, расположение и упорядочение.
- Ограничение на совместное размещение определяет, могут ли два ресурса выполняться на одном узле.
- Ограничение расположения сообщает кластеру Pacemaker, где ресурс может (или не может) выполняться.
- Ограничение на упорядочение указывает кластеру Pacemaker порядок запуска ресурсов.
Примечание.
Ограничения совместного размещения не требуются для ресурсов в группе ресурсов, так как все они рассматриваются как единая единица.
Кворум, агенты ограждения и STONITH
Кворум под Pacemaker похож на WSFC в концепции. Цель механизма кворума кластера заключается в том, чтобы обеспечить работоспособность кластера. Как надстройки WSFC, так и надстройки высокого уровня доступности для дистрибутивов Linux имеют концепцию голосования, где каждый узел подсчитывается к кворуму. Вполне очевидно, что для работы кластера требуется большая часть голосов, в противном случае кластер будет остановлен.
В отличие от WSFC, нет следящего ресурса для работы с кворумом. Как и в WSFC, требуется получить нечетное число голосов. Для групп доступности и экземпляров FCI используются разные конфигурации кворума.
WSFC отслеживает состояние узлов и обрабатывает их при возникновении проблемы. Более поздние версии WSFCs предлагают такие функции, как кварантинирование узла, который неправильно работает или недоступен (узел не включен, сетевой обмен данными и т. д.). На стороне Linux этот тип функционала предоставляется агентом ограждения. Иногда это называется ограждением. Однако эти агенты ограждения относятся к развертыванию и часто предоставляются поставщиками оборудования и некоторыми поставщиками программного обеспечения, такими как те, кто предоставляет гипервизоры. Например, VMware предоставляет агент ограждения, который можно использовать для виртуальных машин Linux, виртуализованных с помощью vSphere.
Кворум и ограждение связаны с другим понятием — STONITH (Shoot the Other Node in the Head). STONITH должен иметь поддерживаемый кластер Pacemaker во всех дистрибутивах Linux. Дополнительные сведения см. в статье об ограждении в кластере высокой доступности Red Hat (RHEL).
corosync. conf
Файл corosync.conf содержит конфигурацию кластера. Он расположен в /etc/corosync. В ходе обычных повседневных операций этот файл должен всегда оставаться без изменений, если кластер настроен правильно.
Расположение журнала кластера
Расположения журналов кластеров Pacemaker зависят от дистрибутива.
- RHEL и SLES:
/var/log/cluster/corosync.log - Ubuntu:
/var/log/corosync/corosync.log
Чтобы изменить расположение журнала по умолчанию, измените corosync.conf.
Планирование кластеров Pacemaker для SQL Server
В этом разделе рассматриваются важные вопросы планирования для кластера Pacemaker.
Виртуализация кластеров Pacemaker под управлением Linux для SQL Server
Использование виртуальных машин для развертывания развертываний SQL Server под управлением Linux для групп управления доступом и ЦС охватывается теми же правилами, что и для своих коллег на основе Windows. Существует базовый набор правил для поддержки виртуализированных развертываний SQL Server, предоставляемых корпорацией Майкрософт в политике поддержки для продуктов Microsoft SQL Server, работающих в среде виртуализации оборудования. Различные гипервизоры, такие как Hyper-V Корпорации Майкрософт и ESXi VMware, могут иметь различные дисперсии поверх этого из-за различий в самих платформах.
При виртуализации групп доступности и экземпляров FCI необходимо, чтобы в узлах кластера Pacemaker было настроено удаление сходства. При настройке высокой доступности в конфигурации группы доступности или FCI виртуальные машины, на которых размещен SQL Server, никогда не должны работать на одном узле гипервизора. Например, если развернут двухузловой FCI, потребуется по крайней мере три узла гипервизора, чтобы в одном из виртуальных машин, на которых размещен узел, идти в случае сбоя узла, особенно при использовании таких функций, как Live Migration или vMotion.
Документация по Hyper-V см. в разделе "Использование гостевой кластеризации для обеспечения высокой доступности"
Network
В отличие от WSFC, Pacemaker не требует выделенного имени или хотя бы одного выделенного IP-адреса для самого кластера Pacemaker. Для групп управления доступом и ЦС требуются IP-адреса (см. документацию по каждому из них для получения дополнительных сведений), но не имена, так как не существует ресурса сетевого имени. SLES разрешает настройку IP-адреса в целях администрирования, но не требуется, как показано в разделе "Создание кластера Pacemaker".
Как и для WSFC, для Pacemaker будет предпочтительной избыточная сеть, в которой разные сетевые карты (NIC или pNIC) имеют разные IP-адреса. С точки зрения конфигурации кластера у каждого IP-адреса будет так называемый собственный круг. Тем не менее, как и в WSFCs сегодня, многие реализации виртуализированы или в общедоступном облаке, где существует только один виртуализированный сетевой адаптер (vNIC), представленный серверу. Если все PNICs и виртуальные сетевые адаптеры подключены к одному физическому или виртуальному коммутатору, на сетевом уровне нет истинной избыточности, поэтому настройка нескольких сетевых адаптеров является немного иллюзией для виртуальной машины. Как правило, избыточность сети является неотъемлемой частью гипервизора для виртуализованных развертываний и, конечно же, общедоступного облака.
Одно из различий между несколькими сетевыми адаптерами и Pacemaker и WSFC заключается в том, что Pacemaker разрешает несколько IP-адресов в одной подсети, в то время как WSFC не поддерживает. Дополнительные сведения о нескольких подсетях и кластерах Linux см. в статье "Настройка групп доступности AlwaysOn с несколькими подсетями" и экземпляров отказоустойчивого кластера.
Кворум и STONITH
Конфигурация кворума и требования связаны с развертываниями SQL Server, зависящими от группы доступности или FCI.
STONITH требуется для поддерживаемого кластера Pacemaker. Сведения о настройке STONITH см. в документации по дистрибутиву. Пример для SLES см. в статье об ограждении на основе хранилища. Существует также агент STONITH для VMware vCenter для решений на основе ESXI. Дополнительные сведения см. в статье Stonith Plugin Agent for VMware VM VCenter SOAP Fencing (Неофициальный).
Совместимость
В этом разделе содержатся сведения о взаимодействии кластера на основе Linux с WSFC или другими дистрибутивами Linux.
WSFC
В настоящее время нет прямого способа для WSFC и кластера Pacemaker для совместной работы. Это означает, что нет способа создать группу доступности или FCI, которая работает в WSFC и Pacemaker. Однако есть два решения для взаимодействия, оба из которых предназначены для групп доступности. Единственный способ, который FCI может участвовать в кроссплатформенной конфигурации, заключается в том, что он участвует в качестве экземпляра в одном из этих двух сценариев:
- Группа доступности с типом кластера None. Дополнительные сведения см. в документации по группам доступности Windows.
- Распределенная группа доступности, которая представляет собой особый тип группы, позволяющий настраивать две разные группы доступности в качестве собственной группы доступности. Дополнительные сведения о распределенных группах доступности см. в документации по распределенным группам доступности.
Другие дистрибутивы Linux
В Linux все узлы кластера Pacemaker должны находиться в одном дистрибутиве. Например, это означает, что узел RHEL не может быть частью кластера Pacemaker с узлом SLES. Основная причина этого была ранее указана: дистрибутивы могут иметь разные версии и функциональные возможности, поэтому вещи не могли работать должным образом. Смешение дистрибутивов, как и сочетание WSFC и Linux, позволяет сделать вывод о необходимости использования групп доступности с типом None или распределенных групп доступности.