Failover cluster что это

Отказоустойчивый кластер для балансировки нагрузки

Поговорим о горизонтальном масштабировании. Допустим, ваш проект вырос до размеров, когда один сервер не справляется с нагрузкой, а возможностей для вертикального роста ресурсов уже нет.

В этом случае дальнейшее развитие инфраструктуры проекта обычно происходит за счет увеличения числа однотипных серверов с распределением нагрузки между ними. Такой подход не только позволяет решить проблему с ресурсами, но и добавляет надежности проекту — при выходе из строя одного или нескольких компонентов его работоспособность в целом не будет нарушена.

Большую роль в этой схеме играет балансировщик — система, которая занимается распределением запросов/трафика. На этапе ее проектирования важно предусмотреть следующие ключевые требования:

Фактически, это описание кластера, узлами которого являются серверы-балансеры.

В этой статье мы хотим поделиться рецептом подобного кластера, простого и неприхотливого к ресурсам, концепцию которого успешно применяем в собственной инфраструктуре для балансировки запросов к серверам нашей панели управления, внутреннему DNS серверу, кластеру Galera и разнообразными микросервисам.

Договоримся о терминах:

— Серверы, входящие в состав кластера, будем называть узлами или балансерами.
— Конечными серверами будем называть хосты, на которые проксируется трафик через кластер.
— Виртуальным IP будем называть адрес, “плавающий” между всеми узлами, и на который должны указывать имена сервисов в DNS.

Что потребуется:

— Для настройки кластера потребуется как минимум два сервера (или вирт.машины) с двумя сетевыми интерфейсами на каждом.
— Первый интерфейс будет использоваться для связи с внешним миром. Здесь будут настроены реальный и виртуальный IP адреса.
— Второй интерфейс будет использоваться под служебный трафик, для общения узлов друг с другом. Здесь будет настроен адрес из приватной (“серой”) сети 172.16.0.0/24.
Вторые интерфейсы каждого из узлов должны находиться в одном сегменте сети.

Используемые технологии:

VRRP, Virtual Router Redundancy Protocol — в контексте этой статьи, реализация «плавающего» между узлами кластера виртуального IP адреса. В один момент времени такой адрес может быть поднят на каком-то одном узле, именуемом MASTER. Второй узел называется BACKUP. Оба узла постоянно обмениваются специальными heartbeat сообщениями. Получение или неполучение таких сообщений в рамках заданных промежутков дает основания для переназначения виртуального IP на “живой” сервер. Более подробно о протоколе можно прочитать здесь.

LVS, Linux Virtual Server — механизм балансировки на транспортном/сеансовом уровне, встроенный в ядро Linux в виде модуля IPVS. Хорошее описание возможностей LVS можно найти здесь и здесь.
Суть работы сводится к указанию того, что есть определенная пара “IP + порт” и она является виртуальным сервером. Для этой пары назначаются адреса реальных серверов, ответственных за обработку запросов, задается алгоритм балансировки, а также режим перенаправления запросов.

В нашей системе мы будем использовать Nginx как промежуточное звено между LVS и конечными серверами, на которые нужно проксировать трафик. Nginx будет присутствовать на каждом узле.

Для настроек VRRP и взаимодействия с IPVS будем использовать демон Keepalived, написанный в рамках проекта Linux Virtual Server.

КОНЦЕПЦИЯ

Система будет представлять собой связку из двух независимых друг от друга равнозначных узлов-балансеров, объединенных в кластер средствами технологии LVS и протокола VRRP.

Точкой входа для трафика будет являться виртуальный IP адрес, поднятый либо на одном, либо на втором узле.

Поступающие запросы LVS перенаправляет к одному из запущенных экземпляров Nginx — локальному или на соседнем узле. Такой подход позволяет равномерно размазывать запросы между всеми узлами кластера, т.е. более оптимально использовать ресурсы каждого балансера.

Работа Nginx заключается в проксировании запросов на конечные сервера. Начиная с версии 1.9.13 доступны функции проксирования на уровне транспортных протоколов tcp и udp.

Каждый vhost/stream будет настроен принимать запросы как через служебный интерфейс с соседнего балансера так и поступающие на виртуальный IP. Причем даже в том случае, если виртуальный IP адрес физически не поднят на данном балансере (Keepalived назначил серверу роль BACKUP).

Таким образом, схема хождения трафика в зависимости от состояния балансера (MASTER или BACKUP) выглядит так:

РЕАЛИЗАЦИЯ:

В качестве операционной системы будем использовать Debian Jessie с подключенными backports репозиториями.

Установим на каждый узел-балансер пакеты с необходимым для работы кластера ПО и сделаем несколько общесистемных настроек:

На интерфейсе eth1 настроим адреса из серой сети 172.16.0.0/24 :

Виртуальный IP адрес прописывать на интерфейсе eth0 не нужно. Это сделает Keepalived.

В файл /etc/sysctl.d/local.conf добавим следующие директивы:

Первая включает возможность слушать IP, которые не подняты локально (это нужно для работы Nginx). Вторая включает автоматическую защиту от DDoS на уровне балансировщика IPVS (при нехватке памяти под таблицу сессий начнётся автоматическое вычищение некоторых записей). Третья увеличивает размер conntrack таблицы.

В /etc/modules включаем загрузку модуля IPVS при старте системы:

Параметр conn_tab_bits определяет размер таблицы с соединениями. Его значение является степенью двойки. Максимально допустимое значение — 20.

Кстати, если модуль не будет загружен до старта Keepalived, последний начинает сегфолтиться.

Теперь перезагрузим оба узла-балансера. Так мы убедимся, что при старте вся конфигурация корректно поднимется.

Общие настройки выполнены. Дальнейшие действия будем выполнять в контексте двух задач:

Вводные данные:

Начнем с конфигурации Nginx.

Добавим описание секции stream в /etc/nginx/nginx.conf :

И создадим соответствующий каталог:

Настройки для веб-серверов добавим в файл /etc/nginx/sites-enabled/web_servers.conf

Настройки для DNS-серверов добавим в файл /etc/nginx/stream-enabled/dns_servers.conf

Далее остается сконфигурировать Keepalived (VRRP + LVS). Это немного сложнее, поскольку нам потребуется написать специальный скрипт, который будет запускаться при переходе узла-балансера между состояниями MASTER/BACKUP.

При переходе в состояние MASTER, скрипт удаляет это правило.

Настройки LVS для группы веб-серверов:

Настройки LVS для группы DNS-серверов:

В завершении перезагрузим конфигурацию Nginx и Keepalived:

ТЕСТИРОВАНИЕ:

Посмотрим как балансировщик распределяет запросы к конечным серверам. Для этого на каждом из веб-серверов создадим index.php с каким-нибудь простым содержимым:

И сделаем несколько запросов по http к виртуальному IP 192.168.0.100 :

Если в процессе выполнения этого цикла посмотреть на статистику работы LVS (на MASTER узле), то мы можем увидеть следующую картину:

Здесь видно как происходит распределение запросов между узлами кластера: есть два активных соединения, которые обрабатываются в данный момент и 6 уже обработанных соединений.

Статистику по все соединениям, проходящим через LVS, можно посмотреть так:

Здесь, соответственно, видим то же самое: 2 активных и 6 неактивный соединений.

ПОСЛЕСЛОВИЕ:

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

Если у вас возникли вопросы по статье или что-то показалось спорным — пожалуйста, оставляйте свои комментарии, будем рады обсудить.

Источник

Создание группы доступности AlwaysON на основе кластера Failover

Коротко о главном: каждый узел группы доступности должен быть членом отказоустойчивого кластера Windows. Каждый экземпляр SQL Server может иметь несколько групп доступности. В каждой группе доступности может быть до 8 вторичных реплик.

Что это и зачем требуется

Группы доступности AlwaysOn — это решение высокой доступности и аварийного восстановления, является альтернативой зеркальному отображению баз данных на уровне предприятия. Если БД не справляется с потоком запросов или есть опасения, что при сбое на сервере пропадут ценные данные, есть смысл использовать это решение. Группы доступности AlwaysOn могут отвечать за выполнение сразу двух задачи: высокий уровень доступности обеспечивает бесперебойную работу системы, а нагрузка по чтению из БД частично выполняется на репликах.

Создание группы доступности может понадобиться, если вам необходимо:

Создать избыточную доступность баз данных (в этом случае рекомендуем располагать ноды в геоудалённых дата-центрах, т.к. избыточная доступность предполагает доступность БД при любых технических неполадках на любой из нод);

Увеличить быстродействие ответов баз данных по принципу горизонтального расширения (в этом случае одна нода в кластере является мастером, осуществляющей операции записи и чтения, остальные ноды работают в режиме слушателей и позволяют считывать данные при запросах обращения)

При отказе основой реплики, кластер проголосует за новую основную реплику и Always On переведёт одну из вторичных реплик в статус основной. Так как при работе с Always On пользователи соединяются с прослушивателем кластера (или Listener, то есть специальный IP-адрес кластера и соответствующее ему DNS-имя), то возможность выполнять write-запросы полностью восстановится. Прослушиватель также отвечает за балансировку select-запросов между вторичными репликами.

Подготовка инфраструктуры

Сначала необходимо создать виртуальную машину и пользователей. В VDC создаем 3 ВМ, даём имена согласно ролей, выполняем настройки кастомизации.

После этого переходим к этапу настройки контроллера домена. Устанавливаем роли AD, DNS, Failover Cluster.

Устанавливаем роль контроллера домена

Создаём в AD компьютеры ND01 и ND02.

На ВМ ND01 и ND02 ставим компонент Failover Cluster

Теперь переходим к созданию кластера отказоустойчивости. На контроллере домена DC01 создаём кластер отказоустойчивости и добавляем в него наши ноды.

При создании кластера снимаем галочку с добавления массивов в каталог. Эту настройку можно сделать позже.

Создание кластера завершено.

Создание свидетеля (Quorum Witness Share)

Переходим к настройке кворума. Для этого выбираем пункты, которые указаны на скриншоте.

В конфигурации свидетеля кворума указываем file share.

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

Если после создания свидетеля у вас возникнет ошибка как на примере ниже,

…то в этом случае необходимо проверить настройки прав доступа к сетевой директории, указанной в настройках свидетеля.

Переходим к установке MS SQL 2015 Enterprise на ноды в кластере. Перед установкой модуля необходимо отключить брандмауэр на работу в доменной сети на всех ВМ, участвующих в кластере.

Устанавливаем MS SQL в standalone режиме, без дополнительных модулей. При выборе пользователя для примера берём Администратора доменной сети. Для боевых серверов рекомендуем сделать отдельного пользователя. Наверное, не нужно объяснять, почему это важно.

Затем необходимо установить SQL Management Studio на обе ноды в кластере.

Добавление тестовой базы данных в MSSQL

На ноде ND01 устанавливаем тестовый образец базы данных. Имя тестовой БД будет Bike-Store. Тестовая БД взята отсюда.

После установки БД выделяем созданную базу данных, после чего выбираем файл БД при помощи комбинации Ctrl+O.

После открытия файла нажимаем «Выполнить»

Важно! Перед развертыванием группы доступности обязательно делаем резервную копию БД, в противном случае не получится создать группу доступности

Настройка Always On в MS SQL Server

Для каждой ноды необходимо включить поддержку схемы AlwaysON в SQL Server Configuration Manager в свойствах экземпляра.

На ноде ND01 В SQL Server Management Studio выберите узел «Always On High Availability» и запустите мастер настройки группы доступности (New Availability Group Wizard).

Присваиваем имя нашей группе доступности: BikeStores-AG

Нажмите «Добавить реплику» и подключитесь к второму серверу SQL. Таким образом можно добавить до 8 серверов.

Ключевые параметры

Исходная роль – роль реплики на момент создания группы. Может быть Primary и Secondary;

Автоматический переход – если база данных станет недоступна, Always On переведёт primary роль на другую реплику. Отмечаем чекбокс;

Режим доступности – возможно выбрать Synchronous Commit или Asynchronous Commit. При выборе синхронного режима транзакции, поступающие на primary реплику, будут отправлены на все остальные вторичные реплики с синхронным режимом. Primary реплика завершит транзакцию только после того, как реплики запишут транзакцию на диск. Таким образом исключается возможность потери данных при сбое primary реплики. При асинхронном режиме основная реплика сразу записывает изменения, не дожидаясь ответа от вторичных реплик;

Вторичная реплика для чтения – параметр, задающий возможность делать select-запросы к вторичным репликам. При значении yes, клиенты даже при соединении без ApplicationIntent=readonly смогут получить read-only доступ;

Для фиксации требуются синхронизированные получатели – число синхронизированных вторичных реплик для завершения транзакции. Нужно выставлять в зависимости от количества реплик. Имейте в виду, что, если вторичных синхронизированных реплик станет меньше указанного числа (например, при аварии), базы данных группы доступности станут недоступны даже для чтения.

На вкладке Параметры резервного копирования можно выбрать откуда будут делаться бекапы. Оставляем всё по умолчанию – Предпочитать вторичную.

Указываем имя слушателя группы доступности, порт и IP-адрес.

Если все тесты во время окончания прошли успешно, то нажимаем кнопку «Далее».

На этом первичная настройка группы доступности AlwaysON завершена. Вы можете провести тесты отказоустойчивости, попеременно отключая каждую ноду в кластере, а также давая простые запросы select, insert.

Надеемся, наша инструкция по создании групп доступности поможет вам обеспечить надлежащий уровень работоспособности вашей ИТ-инфраструктуры. В дальнейшем мы планируем выпустить и другие варианты сценариев. Если вам интересны какие-то нюансы – напишите о них в комментариях. Спасибо за внимание!

В России стартовала распродажа «Киберпонедельник-2021». Мы тоже решили принять участие в этой акции, и на три дня открыли бесплатный доступ к видеокурсу «Управление виртуальным дата центром и сетями в vCloud Director (VMware)» специально для тех, кто хочет разобраться в этой теме и научиться управлять облачной инфраструктурой.

В результате вы и ваши сотрудники сможете эффективнее использовать облачные платформы и больше не будете не путаться при работе с виртуальными машинами.

Курс уже получил 91 оценок от 366 студентов, средняя оценка — 4,5. Сейчас он снова бесплатно доступен на Udemy! Регистрируйтесь и учитесь!

Что ещё интересного есть в блоге Cloud4Y

Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью. Пишем не чаще двух раз в неделю и только по делу.

Источник

Отказоустойчивая кластеризация и группы доступности AlwaysOn (SQL Server)

Сведения о концепциях Группы доступности AlwaysOn см. в разделе Обзор групп доступности AlwaysOn (SQL Server).

Кластер WSFC и группы доступности

Для развертывания Группы доступности AlwaysOn требуется кластер WSFC. Чтобы экземпляр Группы доступности AlwaysOnможно было использовать в SQL Server, необходимо, чтобы он размещался на узле WSFC, а кластер WSFC и узел были работоспособны. Также все реплики доступности в заданной группе доступности должны располагаться на разных узлах одного кластера WSFC. Единственное исключение состоит в том, что при переносе в другой кластер WSFC группа доступности может временно находиться в двух кластерах.

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

Кворум для Группы доступности AlwaysOn рассчитывается на всех узлах в кластере WSFC вне зависимости от того, хранится ли на данном узле кластера какая-либо реплика доступности. В отличие от процесса зеркального отображения базы данных, в Группы доступности AlwaysOn нет роли следящего объекта.

Общая работоспособность кластера WSFC определяется голосами на кворуме узлов в кластере. Если кластер WSFC перешел в автономный режим в результате непредвиденной аварийной ситуации, постоянно возникающего сбоя в оборудовании или ошибки связи, то требуется вмешательство администратора. Администратор кластера Windows Server или WSFC должен будет создать принудительный кворум, а затем перевести работоспособные узлы кластера обратно в автономный режим в неотказоустойчивой конфигурации.

Группы доступности AlwaysOn — это подразделы кластера WSFC. При удалении и повторном создании кластера WSFC необходимо отключить и повторно включить функцию Группы доступности AlwaysOn в каждом экземпляре SQL Server, где была размещена реплика доступности в исходном кластере WSFC.

Дополнительные сведения о запуске SQL Server в узлах кластера WSFC и кворуме WSFC см. в разделе Отказоустойчивая кластеризация Windows Server (WSFC) с SQL Server.

SQL Server Экземпляры отказоустойчивого кластера (FCI) и группы доступности

Можно настроить второй уровень отказоустойчивости на уровне экземпляра сервера путем реализации FCI SQL Server совместно с кластером WSFC. Реплика доступности может размещаться либо с помощью отдельного экземпляра SQL Server или экземпляра FCI. Только партнер FCI может размещать реплику для данной группы доступности. Во время работы реплики доступности на экземплярах отказоустойчивого кластера (FCI) список возможных владельцев для группы доступности будет содержать только активный узел FCI.

Группы доступности AlwaysOn не зависит от формы общего хранилища. Однако при использовании экземпляра отказоустойчивого кластера SQL Server для размещения одной или нескольких реплик доступности для каждого из этих экземпляров потребуется общее хранилище в соответствии со стандартной установкой экземпляра отказоустойчивого кластера SQL Server.

Дополнительные сведения о других предварительных требованиях см. в подразделе «Предварительные требования и ограничения, связанные с использованием экземпляра отказоустойчивого кластера SQL Server (FCI) для размещения реплики доступности» раздела Предварительные условия и ограничения, связанные с использованием экземпляра отказоустойчивого кластера SQL Server для размещения реплики доступности (SQL Server).

Сравнение экземпляров отказоустойчивого кластера и групп доступности

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

**Параметры политики перехода на другой ресурс для группы доступности применимы ко всем репликам, независимо от того, размещаются ли они в автономном экземпляре или экземпляре FCI.

Дополнительные сведения о числе узлов в FCI и группах доступности Always On для разных выпусков SQL Server см. в разделе Функции, поддерживаемые выпусками SQL Server 2012 (https://go.microsoft.com/fwlink/?linkid=232473).

Рекомендации для размещения реплики доступности на FCI

При необходимости в размещении реплики доступности в экземпляре отказоустойчивого кластера SQL Server убедитесь, что узлы Windows Server 2008 соответствуют предварительным требованиям AlwaysOn и ограничениям для экземпляров отказоустойчивого кластера. Дополнительные сведения см. в разделе Предварительные требования, ограничения и рекомендации для групп доступности AlwaysOn (SQL Server).

SQL Server Экземпляры отказоустойчивого кластера (FCI) не поддерживают автоматический переход на другой ресурс с учетом групп доступности, поэтому любая реплика доступности, размещенная в них, должна быть настроена для перехода на другой ресурс вручную.

Может потребоваться настройка кластера WSFC для включения общих дисков, которые доступны не на всех узлах. Например, рассмотрим кластер WSFC между двумя центрами обработки данных с тремя узлами. На двух узлах размещается экземпляр отказоустойчивой кластеризации SQL Server в основном центре обработки данных; им предоставлен доступ к одним и тем же общим дискам. На третьем узле размещается автономный экземпляр SQL Server в другом центре обработки данных и отсутствует доступ к общим дискам от основного центра обработки данных. Эта конфигурация кластера WSFC поддерживает развертывание группы доступности, если на экземпляре отказоустойчивого кластера размещена первичная реплика и на автономном экземпляре находится вторичная реплика.

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

В следующем примере сценария показано, как подобная конфигурация может вызывать проблемы.

Ограничения на использование диспетчера отказоустойчивости кластеров WSFC с группами доступности

Не используйте диспетчер отказоустойчивости кластеров для управления группами доступности, например:

Нельзя добавлять или удалять ресурсы в службе, поддерживающей работу в кластере (группе ресурсов) для группы доступности.

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

Не используйте диспетчер отказоустойчивого кластера для перемещения групп доступности на другие узлы или резервные группы доступности. Диспетчер отказоустойчивого кластера не имеет сведений о состоянии синхронизации реплик доступности, и это может привести к длительному простою. Необходимо использовать Transact-SQL или среду SQL Server Management Studio.

Если с помощью диспетчера отказоустойчивости кластеров переместить экземпляр отказоустойчивого кластера с группой доступности на узел, который уже содержит реплику той же группы доступности, это может привести к потере этой реплики. Таким образом, эта реплика не будет включена на целевом узле. Один узел отказоустойчивого кластера не может содержать более одной реплики той же группы доступности. Дополнительные сведения о том, как это происходит, и шаги восстановления см. в записи блога Issue: Replica Unexpectedly Dropped in Availability Group (Проблема: неожиданное удаление реплики в группе доступности).

Источник