Что такое отказоустойчивый кластер

Записки IT специалиста

Технический блог специалистов ООО»Интерфейс»

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

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

Во-первых это служебная сеть кластера для передачи сигнала «пульса» (heartbeat), по которому кластер следит за состоянием своих узлов (на схеме показана красным), сеть хранения данных (SAN, синяя), в недорогих решениях это чаще всего iSCSI через отдельную Ethernet-сеть, но это может быть также и FibreChanell или иные технологии. Для обслуживания клиентов кластер включается в существующую локальную сеть.

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

Нельзя не упомянуть и про программные решения, позволяющие создать отказоустойчивый кластер только на двух нодах, используя в качестве SAN виртуальное хранилище. Например, StarWind Virtual SAN, который создает виртуальное iSCSI хранилище на базе локальных дисков каждого из узлов. Это позволяет снизить затраты на создание и размещение отказоустойчивого хранилища, но в тоже время повышает требование к производительности сети между узлами кластера, так как при записи на диск все изменения тут-же синхронизируются между узлами.

После того, как вы создадите кластер, он появится в сетевом окружении как еще один хост со своим именем и IP-адресом. После чего нам потребуется развернуть на нем высокодоступные роли. Это могут быть файловые сервера, SQL или Exchange, а также иные, поддерживающие кластеризацию, приложения. Каждая отказоустойчивая роль кластера также появляется в сети в виде отдельного хоста, к которому происходит обращение клиентов. При этом клиент понятия не имеет, какой именно узел выполняет его запрос, в случае отказа, например, из-за выхода из строя одного из узлов, ему потребуется всего лишь повторить запрос к сервису.

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

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

В наших следующих материалах мы рассмотрим практическую реализацию отказоустойчивого кластера на базе Hyper-V.

Источник

Обзор вариантов реализации отказоустойчивых кластеров: Stratus, VMware, VMmanager Cloud

Есть разновидности бизнеса, где перерывы в предоставлении сервиса недопустимы. Например, если у сотового оператора из-за поломки сервера остановится биллинговая система, абоненты останутся без связи. От осознания возможных последствий этого события возникает резонное желание подстраховаться.

Мы расскажем какие есть способы защиты от сбоев серверов и какие архитектуры используют при внедрении VMmanager Cloud: продукта, который предназначен для создания кластера высокой доступности.

Предисловие

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

На первый взгляд самый привлекательный вариант для бизнеса тот, когда в случае сбоя обслуживание пользователей не прерывается, то есть кластер непрерывной доступности. Без КНД никак не обойтись как минимум в задачах уже упомянутого биллинга абонентов и при автоматизации непрерывных производственных процессов. Однако наряду с положительными чертами такого подхода есть и “подводные камни”. О них следующий раздел статьи.

Continuous availability / непрерывная доступность

Бесперебойное обслуживание клиента возможно только в случае наличия в любой момент времени точной копии сервера (физического или виртуального), на котором запущен сервис. Если создавать копию уже после отказа оборудования, то на это потребуется время, а значит, будет перебой в предоставлении услуги. Кроме этого, после поломки невозможно будет получить содержимое оперативной памяти с проблемной машины, а значит находившаяся там информация будет потеряна.
Для реализации CA существует два способа: аппаратный и программный. Расскажем о каждом из них чуть подробнее.

Программный способ.
На момент написания статьи самый популярный инструмент для развёртывания кластера непрерывной доступности — vSphere от VMware. Технология обеспечения Continuous Availability в этом продукте имеет название “Fault Tolerance”.

В отличие от аппаратного способа данный вариант имеет ограничения в использовании. Перечислим основные:

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

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

Есть Remus на базе Xen, бесплатное решение с открытым исходным кодом. Проект использует технологию микроснэпшотов. К сожалению, документация давно не обновлялась; например, установка описана для Ubuntu 12.10, поддержка которой прекращена в 2014 году. И как ни странно, даже Гугл не нашёл ни одной компании, применившей Remus в своей деятельности.

Предпринимались попытки доработки QEMU с целью добавить возможность создания continuous availability кластера. На момент написания статьи существует два таких проекта.

Первый — Kemari, продукт с открытым исходным кодом, которым руководит Yoshiaki Tamura. Предполагается использовать механизмы живой миграции QEMU. Однако тот факт, что последний коммит был сделан в феврале 2011 года говорит о том, что скорее всего разработка зашла в тупик и не возобновится.

Второй — Micro Checkpointing, основанный Michael Hines, тоже open source. К сожалению, уже год в репозитории нет никакой активности. Похоже, что ситуация сложилась аналогично проекту Kemari.

Таким образом, реализации continuous availability на базе виртуализации KVM в данный момент нет.

Итак, практика показывает, что несмотря на преимущества систем непрерывной доступности, есть немало трудностей при внедрении и эксплуатации таких решений. Однако существуют ситуации, когда отказоустойчивость требуется, но нет жёстких требований к непрерывности сервиса. В таких случаях можно применить кластеры высокой доступности, КВД.

High availability / высокая доступность

В контексте КВД отказоустойчивость обеспечивается за счёт автоматического определения отказа оборудования и последующего запуска сервиса на исправном узле кластера.

В КВД не выполняется синхронизация запущенных на нодах процессов и не всегда выполняется синхронизация локальных дисков машин. Стало быть, использующиеся узлами носители должны быть на отдельном независимом хранилище, например, на сетевом хранилище данных. Причина очевидна: в случае отказа ноды пропадёт связь с ней, а значит, не будет возможности получить доступ к информации на её накопителе. Естественно, что СХД тоже должно быть отказоустойчивым, иначе КВД не получится по определению.

Таким образом, кластер высокой доступности делится на два подкластера:

VMmanager Cloud

Наше решение VMmanager Cloud использует виртуализацию QEMU-KVM. Мы сделали выбор в пользу этой технологии, поскольку она активно разрабатывается и поддерживается, а также позволяет установить любую операционную систему на виртуальную машину. В качестве инструмента для выявления отказов в кластере используется Corosync. Если выходит из строя один из серверов, VMmanager поочерёдно распределяет работавшие на нём виртуальные машины по оставшимся нодам.

В упрощённой форме алгоритм такой:

Практика показывает, что лучше выделить одну или несколько нод под аварийные ситуации и не развёртывать на них ВМ в период штатной работы. Такой подход исключает ситуацию, когда на “живых” нодах в кластере не хватает ресурсов, чтобы разместить все виртуальные машины с “умершей”. В случае с одним запасным сервером схема резервирования носит название “N+1”.

Рассмотрим по каким схемам пользователи VMmanager Cloud реализовывали кластеры высокой доступности.

FirstByte

Компания FirstByte начала предоставлять облачный хостинг в феврале 2016 года. Изначально кластер работал под управлением OpenStack. Однако отсутствие доступных специалистов по этой системе (как по наличию так и по цене) побудило к поиску другого решения. К новому инструменту для управления КВД предъявлялись следующие требования:

Отличительные черты кластера:

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

FirstVDS

Компания FirstVDS предоставляет услуги отказоустойчивого хостинга, запуск продукта состоялся в сентябре 2015 года.

К использованию VMmanager Cloud компания пришла из следующих соображений:

В случае общего отказа Infiniband-сети связь между хранилищем дисков ВМ и вычислительными серверами выполняется через Ethernet-сеть, которая развёрнута на оборудовании Juniper. “Подхват” происходит автоматически.

Благодаря высокой скорости взаимодействия с хранилищем такой кластер подходит для размещения сайтов со сверхвысокой посещаемостью, видеохостинга с потоковым воспроизведением контента, а также для выполнения операций с большими объёмами данных.

Эпилог

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

Однако если обстоятельства позволяют подождать 5 минут пока виртуальные машины разворачиваются на резервной ноде, можно взглянуть в сторону КВД. Это даст экономию в стоимости лицензий и оборудования.

Кроме этого не можем не напомнить, что единственное средство повышения отказоустойчивости — избыточность. Обеспечив резервирование серверов, не забудьте зарезервировать линии и оборудование передачи данных, каналы доступа в Интернет, электропитание. Всё что только можно зарезервировать — резервируйте. Такие меры исключают единую точку отказа, тонкое место, из-за неисправности в котором прекращает работать вся система. Приняв все вышеописанные меры, вы получите отказоустойчивый кластер, который действительно трудно вывести из строя.

Если вы решили, что для ваших задач больше подходит схема высокой доступности и выбрали VMmanager Cloud как инструмент для её реализации, к вашим услугам инструкция по установке и документация, которая поможет подробно ознакомиться с системой. Желаем вам бесперебойной работы!

P. S. Если у вас в организации есть аппаратные CA-серверы — напишите, пожалуйста, в комментариях кто вы и для чего вы их используете. Нам действительно интересно услышать для каких проектов использование такого оборудование экономически целесообразно 🙂

Источник

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

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

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

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

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

В этой статье мы хотим поделиться рецептом подобного кластера, простого и неприхотливого к ресурсам, концепцию которого успешно применяем в собственной инфраструктуре для балансировки запросов к серверам нашей панели управления, внутреннему 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 неактивный соединений.

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

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

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

Источник

Принцип работы отказоустойчивых кластеров

Отказоустойчивый кластер (кластер высокой доступности, h igh availability cluster, HA-кластер ) — группа серверов, гарантирующая минимальное время простоя виртуальных машин (ВМ). Отказоустойчивые кластеры используют, например, для поддержки серверов баз данных, хранения важной информации, работы бизнес-приложений. В случае, если один из серверов (узлов) кластера потерял связь с другими узлами или подключённым хранилищем, VMmanager запустит процесс аварийного восстановления — релокации ВМ:

Процесс релокации проходит автоматически без участия администратора.

Требования к отказоустойчивому кластеру

В текущей реализации VMmanager вы можете создать отказоустойчивый кластер при следующих условиях:

Логика работы

Используемые сервисы

Для управления отказоустойчивым кластером VMmanager использует:

Платформа запускает сервис ha-agent на каждом узле кластера. Сервисы ha-agent взаимодействуют между собой с помощью ПО Corosync. Алгоритмы Corosync назначают один из сервисов ha-agent мастером. В дальнейшем платформа взаимодействует только с этим сервисом с помощью hawatch.

Продедура выбора мастера

Выбор мастера происходит в следующих ситуациях:

При выборе мастера каждый из узлов-выборщиков с помощью специального алгоритма рассчитывает свой приоритет и сообщает его остальным участникам кластера. Мастером назначается узел с самым большим приоритетом. После назначения мастера кластер начнёт работу в режиме отказоустойчивости.

Обычно процедура выбора занимает около 15 секунд.

Статусы узлов кластера

В отказоустойчивом кластере узлы могут принимать следующие статусы:

Схема работы HA-кластера

Network storage — сетевое хранилище кластера

Management network — сеть управления узлами кластера

Case1 — пример статуса «изоляция по сети»

Case2 — пример статуса «изоляция по хранилищу»

Case3 — пример статуса «полный отказ»

Определение статуса узла

Сервис ha-agent считает узел повреждённым, если узел потерял связь с другими узлами кластера и/или подключённым хранилищем. Проверка связи проводится с помощью алгоритмов Corosync. Дополнительно узлы кластера записывают информацию о своём статусе в файл на сервере хранилища. Обновление статуса происходит один раз в три секунды. Если информация о статусе не обновлена, мастер определит узел как повреждённый.

Среднее время определения нерабочего статуса — от 15 до 60 секунд.

В настройках отказоустойчивости можно указать проверочный IP-адрес. При потере связи с кластером узел проверит доступность этого IP-адреса с помощью утилиты ping:

Если узел регулярно теряет связь по сети на срок менее 15 секунд, он получает статус «сеть нестабильна». Процедура релокации в этом случае не проводится.

Процедура аварийного восстановления

Когда узел кластера определяется как отказавший, сервис ha-agent на узле:

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

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

Чтобы создать отказоустойчивый кластер:

Настройте сетевое хранилище.

Создайте сервер метаданных (MDS) на узле Ceph:

Источник

Кластер для отказоустойчивости

Меня зовут Денис Рожков, я работаю в компании «Газинформсервис». Участвую в проекте по разработке СУБД Jatoba. Мы делаем свою реализацию СУБД на основе PostgreSQL – форк с необходимыми нам расширениями.

СУБД Jatoba появилась в результате нашего многолетнего опыта по внедрению проектов на другом программном обеспечении – у нас есть опыт работы не только с PostgreSQL и MS SQL, но и с Oracle, как с большой корпоративной СУБД, которая долгое время являлась стандартом.

PostgreSQL, как тренд последних лет, затронул нас настолько сильно, что мы начали разрабатывать на его основе свою СУБД. Мы не просто конфигурируем продукт на уровне пользователей, но и ковыряемся внутри, разрабатываем СУБД на уровне ядра и дописываем функциональность, которая нам нужна, на языке C.

Наша компания разрабатывает разные продукты, где СУБД используется как хранилище, и мы успешно реализовали ряд задач по миграции больших проектов с иностранных СУБД на PostgreSQL и отечественные СУБД. Поэтому опыт миграции у нас большой – это уже многолетняя история.

Сначала будет теория – мы вспомним и обобщим знания по кластеризации, проговорим, что мы должны знать о кластерах при выборе реализации для того или иного решения.

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

Расскажу о паре граблей, с которыми можно столкнуться в процессе настройки.

Сосредоточимся на вопросе повышения доступности СУБД

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

есть High Availability – высокая доступность;

и есть Disaster Recovery – как восстановить систему в случае сбоев. Сюда входят бэкапы, регламенты восстановления и т.д. – это более широкий термин, чем высокая доступность.

Мы сегодня не будем говорить про disaster recovery, мы обсудим только первый раздел – High Availability.

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

Виды кластеров

Начнем с того, что такое кластер и зачем он нужен?

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

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

Сами кластеры бывают разные:

отказоустойчивые кластеры – это и есть кластеры высокой доступности (High-availability clusters, HA, кластеры высокой доступности);

кластеры с балансировкой нагрузки, которые в зависимости от настроек умеют распределять входящую нагрузку (входящих клиентов) на определенные сервера (Load balancing clusters);

вычислительные кластеры (High performance computing clusters, HPC);

системы распределенных вычислений.

Два последних раздела нашей темы совсем не касаются, но в стандартной классификации они присутствуют.

Типы отказоустойчивых кластеров

Есть три варианта обеспечения отказоустойчивости, три типа отказоустойчивых кластеров:

с холодным резервом или активный/пассивный (master\slave). Активный узел выполняет запросы, а пассивный ждет его отказа и включается в работу, когда таковой произойдет. Пример – резервные сетевые соединения, в частности, алгоритм связующего дерева. Например, связка DRBD и HeartBeat /Corosync. Хотя многие говорят, что это не про отказоустойчивость, но это самый распространенный вариант. Если у вас все правильно настроено, именно master\slave-конфигурация позволяет с минимальным простоем продолжить обслуживание клиентов.

с горячим резервом или активный/активный (master\master) – когда все сервера работают в системе равнозначно, все узлы выполняют запросы, в случае отказа одного нагрузка перераспределяется между оставшимися. То есть кластер распределения нагрузки с поддержкой перераспределения запросов при отказе. Примеры – практически все кластерные технологии, например, Microsoft Cluster Server или OpenSource-проект OpenMosix. Эта конфигурация имеет свои плюсы и свои минусы, для некоторых инсталляций СУБД она вообще недоступна. Но такой вариант резервирования существует, и я потом расскажу, где конкретно в PostgreSQL его можно встретить и увидеть.

с модульной избыточностью, когда мы спускаемся на уровень RAID или реализуем избыточность на аппаратном уровне. Применяется в случае, когда простаивание системы недопустимо. Все узлы одновременно выполняют один и тот же запрос (либо части его, но так, что результат достижим и при отказе любого узла), из результатов берется любой. Необходимо гарантировать, что результаты разных узлов всегда будут одинаковы (либо различия гарантированно не повлияют на дальнейшую работу). Примеры – RAID и Triple modular redundancy. К самой СУБД это имеет опосредованное отношение, но такой вид классификации среди типов кластеров присутствует.

И последний теоретический момент, который нужно упомянуть – в разных семействах СУБД есть принципиальные различия в реализации определенных видов кластеров по распределению и использованию ресурсов.

Shared nothing – конфигурация, в которой когда каждый из серверов работает сам по себе, у каждого сервера есть собственный дисковый ресурс, где он автономно ведет все, что ему нужно. Серверы между собой ничего не делят, но они умеют между собой по определенной схеме взаимодействовать, передавая друг другу информацию и таким образом поддерживают консистентность.

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

Shared memory – конфигурация, в которой можно шарить память и процессоры. Это не очень актуально в MS SQL и PostgreSQL, но в общей классификации этот вариант кластера тоже присутствует.

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

Механизмы кластеризации в MS SQL Server

Я не буду проводить параллели, не буду устраивать битву MS SQL и PostgreSQL – я сначала напомню, какие механизмы кластеризации есть в Microsoft SQL Server и потом будем подробнее говорить про PostgreSQL.

Так или иначе, в ходе доклада мы рассмотрим обе эти системы с точки зрения основных аспектов. А параллели вы сами сможете провести. И в конце мы попробуем это обобщить.

Напомню, что основные механизмы обеспечения отказоустойчивости в кластере СУБД MS SQL – это Microsoft Windows Server Failover Clustering (WSFC) и технология AlwaysOn.

Технология AlwaysOn представляет собой интегрированное непосредственно в операционную систему гибкое решение, которое обеспечивает высокий уровень доступности и аварийного восстановления.

AlwaysOn поддерживает три основных режима доступности:

Последний режим нам совсем не интересен, потому что в нем не фигурируют данные, но асинхронная и синхронная фиксация – это про нас.

Здесь нужно понять принципиальный нюанс в реализации кластеризации: чем эти два режима отличаются между собой – причем, они примерно одинаково отличаются как в семействе MS SQL, так и в PostgreSQL.

Asynchronous-commit mode (асинхронная фиксация) – это режим, когда первичная реплика фиксирует транзакции, не ожидая подтверждения того, что вторичная реплика записала журнал на диск. При этом каждая вторичная реплика работает в режиме асинхронной фиксации – ей передается информация, и уже неважно, что происходит дальше. Вместо ожидания запись журнала сразу помещается в локальный файл первичной реплики, и клиенту отправляется подтверждение транзакции. Главное, записать данные к себе и вторично проинформировать второй сервер о том, что транзакция была выполнена. За счет этого первичная реплика минимизирует задержку транзакций в базах данных-получателях, но позволяет им не успевать за базами данных-источниками, что создает риск возможной потери данных.

Synchronous-commit mode (синхронная фиксация) – это режим, в котором прежде чем фиксировать транзакции, первичная реплика ждет, чтобы вторичная реплика подтвердила, что запись журнала на диск завершена. В этом режиме возникает ожидание, и тайминги завершения транзакций будут другими. Но после синхронизации базы данных-получателя с базой данных-источником зафиксированные транзакции будут полностью защищены.

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

Поскольку 1С – это система с высокой ценностью информации, мы, с одной стороны, рекомендуем асинхронный режим, но с другой стороны, это зависит от нагрузки и того, насколько тайминги и лаги в целом влияют на механизм работы.

При масштабировании кластера на несколько узлов у нас есть понятие «Группа доступности» – это группа баз данных, для которых отработка отказа выполняется одновременно.

Группу доступности для чтения можно использовать для масштабирования нагрузки. В этом режиме наши реплики работают на read-only, снижая нагрузку с основной мастер-базы, позволяя распределять клиентов на вторичные базы. При этом основной первичный узел – единственный, кто работает read/write.

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

Нюансы при реализации кластера отказоустойчивости в MS SQL Server

Еще раз обобщим основные нюансы, которые нужно помнить при реализации кластера отказоустойчивости в SQL Server.

Режим доступности – свойство каждой реплики. Он определяет, ждет ли первичная реплика перед фиксацией транзакции, чтобы данные на вторичной реплике записались в журнал транзакции на диск.

Группы доступности AlwaysOn поддерживают два режима: режим синхронной и асинхронной фиксации.

В этих двух режимах доступности есть следующие ограничения:

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

В синхронном commit mode переход на другой ресурс возможен как вручную, так и автоматически. При этом вы получите практически идентичный набор данных. Потеря данных здесь практически невозможна, хотя из-за некоторых технических нюансов могут быть некоторые потери транзакции на резервных серверах.

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

Механизмы кластеризации в PostgreSQL

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

Логическая репликация

В PostgreSQL есть логическая и физическая репликации.

Начнем с логической репликации.

Плюсы логической репликации:

Логическая репликация умеет копировать данные между разными версиями и архитектурами PostgreSQL. Ее можно использовать в случае, когда у вас в рамках одного комплекса используются разные версии Postgres, и вы хотите постепенно сделать апгрейд. В таких случаях логическая репликация позволяет постепенно обновлять версии и дойти до нужной.

Можно реплицировать не всю СУБД, а только отдельные объекты, которые вас интересуют. Например, иногда журналирование и какая-то отладочная информация являются для системы избыточными, их можно не реплицировать. В этих случаях вы можете ограничить логическую репликацию только теми объектами, которые вас интересуют.

Так как 1С генерирует в СУБД много динамических объектов, то логическая репликация с точки зрения 1С менее актуальна, чем физическая репликация, которая также присутствует для PostgreSQL.

Минусы логической репликации:

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

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

Из существующих решений по логической репликации можно отметить: Pglogical, Slony и менее известные – Londiste (Skytools) и Bucardo.

Физическая репликация

Физическая репликация в семействе Postgres используется более активно. Основные плюсы:

Минимальные накладные расходы на использование ресурсов.

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

Минусы этого решения:

все слейв-Standby-сервера будут работать в режиме только на чтение. Если у вас есть необходимость использовать конфигурацию с двумя read/write, то это уже другая технология.

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

Вы не сможете ограничиться отдельными объектами репликации: либо вся СУБД, либо ничего.

Схема физической репликации в PostgreSQL

Почему присутствуют эти ограничения?

В PostgreSQL у нас есть основная Primary Node – мастер-база, которая работает на read/write. Она пишет журнал предзаписи – так называемые WAL-файлы, которые содержат информацию, позволяющую СУБД восстановиться, и несут в себе журнал транзакций. Благодаря этим WAL-файлам мы можем поддерживать в актуальном состоянии все остальные слейв-базы (Standby Node)/

Standby Node на PostgreSQL получают данные из WAL-файлов, обновляя свои данные на текущее состояние, тем самым проводя актуализацию.

Механизм похожий, он используется не только в PostgreSQL, но здесь он оперирует только журналами предзаписи (WAL-файлами).

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

Варианты репликации PostgreSQL

В PostgreSQL есть следующие варианты репликации:

синхронная и асинхронная репликация;

One-directional и Bi-directional.

Bi-directional в PostgreSQL – это вариант кластеризации с горячим резервом master/master. Это немногим известно, технология не так широко распространена. Для этого есть свои причины, но так или иначе она существует.

Синхронная и асинхронная репликации знакомы почти всем.

Каскадная репликация – это когда вы с одной реплики можете сделать еще одну и так далее. Часто на мастер в высоконагруженных системах нельзя подключать несколько слейвов, которые могут вам позволить обслуживать нагрузку read-only, потому что от канал мастер-базы к многим слейвам будет перегружаться из-за дублирования передачи информации для каждого слейва.

Поэтому иногда в высоконагруженных системах целесообразно сделать первый слейв, а с него – что-то другое. Здесь есть определенные задержки при передаче и актуализации информации, надо это понимать и помнить, слейв со слейва не будет так же актуален, как первый слейв, но это позволяет разгружать каналы и основной мастер, потому что факт передачи нагружает не только каналы, но и другие ресурсы – выделение памяти и т.д., что негативно влияет на работу продуктива.

Создание кластера master/slave на PostgreSQL

Что делать в семействе баз данных PostgreSQL, чтобы получить конфигурацию master/slave – кластер, который может использоваться для отказоустойчивости.

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

Для получения слейва вам нужно создать полную бэкап-копию текущего мастера. Это отдельная процедура, она на продуктиве всегда не очень приятна. В любом случае, вторым шагом после настройки мастера вам придется делать слейв-копию.

Потом эту слейв-standby-копию нужно доконфигуровать.

В результате правильной настройки, если вы запускаете слейв-базу, то процедура донаката WAL-файлов должна идти стандартно.

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

Конфигурация MASTER server

Для конфигурирования мастер-сервера в обязательном порядке нужно:

Создать отдельного пользователя с определенными параметрами аутентификации, чтобы передавать через него файлы на резервную копию. Это можно сделать запросом:
CREATE ROLE replica WITH LOGIN REPLICATION PASSWORD ‘…’;
Несмотря на то, что этот шаг я назвал обязательным, его можно не делать, можно использовать стандартного пользователя PostgreSQL. Но я считаю, что нужно вводить отдельную аутентификацию, делать отдельный пароль, потому что здесь идет речь о передаче между двумя СУБД. Чтобы контролировать этого пользователя, нужно настраивать параметры для его доступа отдельно, не используя внутреннего, предустановленного в PostgreSQL пользователя, который в СУБД всегда присутствует. Мои рекомендации – создавайте пользователя для конфигурирования резервных серверов.

В postgresql.conf указать необходимый уровень wal_level и количество процессов отправки max_wal_senders:
wal_level=hot_standby
max_wal_senders > 0

В pg_hba.conf указать параметры аутентификации для пользователя, которого мы отдельно создали, в формате:
host replication username client_addr/mask authtype
В качестве метода аутентификации лучше указать md5:
host replication replica 192.168.1.0/32 md5
Нельзя использовать метод аутентификации trust, хоть это и упрощает работу. Поскольку слейв-сервер – это второй сервер, для него будет сетевое взаимодействие, поэтому даже если серверы у вас в отдельном сегменте сети, все-таки целесообразно указывать отдельную аутентификацию.

Создание копии БД

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

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

Например, можно добавлять архивацию, можно использовать отдельное копирование самого файла и другие приемы – для этого могут быть полезны следующие утилиты из операционных систем Linux:

Lbzip2 – bzip2-сжатие, которое позволит архивировать в несколько потоков с использованием нескольких ядер, если нужно запаковать быстрее (аналоги: pbzip2, pigz);

Ionice – регулировка класса и приоритета для планировщика ввода-вывода (также можно использовать nice для регулировки приоритета процессов для CPU планировщика);

pv – контролируем объем передаваемых данных через pipe и т.о. используем для ограничения объема передаваемых данных в единицу времени (аналог — throttle);

tar – утилита архивирования, нужна для вспомогательных целей когда не используется сжатие bzip2/gzip;

tee – чтение с stdin c записью в stdout и другие файлы (является частью coreutils);

gpg – позволит обеспечить шифрование при передаче бэкапа на слейв-сервера.

Те, кто знаком с Linux, эти утилиты хорошо знают. В семействе Windows этот набор ограничивается, но можно найти и применить альтернативные решения – все зависит от того, в каком контексте вы хотите их использовать.

Грабли при использовании стандартной утилиты pg_basebackup.

Не забывайте включать в конфигурационном файле postgresql.conf параметры, о которых я рассказывал:
wal_level=hot_standby
max_wal_senders > 0

Операция создания бэкапа может быть очень продолжительной.

Ни в коем случае не ставьте в продуктиве на Linux для ускорения работы PostgreSQL в настройках fsync = off. Это известные грабли, которые не имеют отношения к pg_basebackup, но люди иногда меняют этот параметр, потом в продуктиве может возникнуть очень неприятная проблема, потому что консистентность базы в режиме бэкапа – отдельная история.

Все мы знаем, что pg_basebackup работает не особенно быстро. Ее плюс в том, что она входит в дистрибутив PostgreSQL и развивается одновременно с базой данных – все новшества, которые появляются в СУБД, также поддерживаются в pg_basebackup. По этой причине, она наиболее качественно протестирована для соответствия новым возможностям PostgreSQL. Но поскольку она уже не очень новая, отсюда ее минусы в производительности.

Для создания слейва и бэкапа можно использовать не только утилиту pg_basebackup, есть и совсем простой вариант:

затем перенести файлы на резервную копию на уровне ОС;

потом сделать pg_stop_backup();

и донакатить те WAL-файлы, которые были созданы в процессе.

Подчеркну, что вам просто нужно создать слейв-базу, каким образом вы это сделаете – это ваше решение.

Кроме утилиты pg_basebackup для создания бэкапов есть утилиты pg_probackup, wal-g (ext wal-e), barman, PGBACKREST.

Многие знают утилиту pg_probackup – ее поддерживают и выпускают наши отечественные коллеги из Postgres Professional.

Утилита wal-g сложнее, она умеет работать с облачными решениями – там другой технологический стек. Предшественником этой утилиты была утилита wal-e, ее развитие подхватили наши отечественные коллеги из Яндекса и сделали новое решение.

Есть еще PGBACKREST.

И есть barman – утилита со своим синтаксисом, плюсами и минусами.

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

Как только вы начинаете работать с Postgre, вы понимаете, что pg_basebackup вас не устраивает, вам нужно что-то большее. Можете погуглить, поизучать альтернативные утилиты для бэкапов.

Донастройка STANDBY

Последний этап – донастройка STANDBY-базы. Вам необходимо убедиться, что параметры конфигурирования в мастере и на слейве совпадают.

В мастере должно быть включено то, что показывает, что у вас есть стендбай сервер:
hot_standby = on

На слейве должен быть включен standby_mode:
standby_mode = on

Параметр wal_receiver_timeout влияет на то, через какой период времени база данных будет понимать, что таймаут для приема WAL-файлов уже истек.

В документации Postgre эти параметры хорошо расписаны, обязательные и самые интересные я указал на слайде.

Проверки

Как проверить, что слейв работает?

К сожалению, в PostgreSQL нет инструментов с графическим интерфейсом по определению состояния кластера, но вы можете выполнить команды в командной и посмотреть:

в том ли у вас режиме восстановления находится база:
select pg_is_in_recovery();

посмотреть статистику со standby через вьюху pg_stat_replication:
select * from pg_stat_replication ;

посмотреть наличие процессов wal sender и wal receiver в Linux – эти процессы должны присутствовать на мастере и слейве, чтобы обеспечить донакат WAL-файлов, о которых я говорил:
ps auxf

Это минимальный диагностический механизм, чтобы проверить, что слейв работает корректно.

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

Как автоматизировать поднятие кластера

Все сложно, куча непонятных команд – зачем это знать и проверять руками? Неужели нет решений, которые обеспечат обычный FAILOVER, чтобы реализовывать стандартную отказоустойчивость – автоматически поднять резервную базу, чтобы она стала мастером. Не думать о том, что что-то случилось, чтобы клиенты в случае неполадок могли спокойно продолжать работу.

В коробочном решении PostgreSQL такого механизма переключения нет, но есть отдельные проекты, которые позволяет это реализовывать.

FAILOVER – это стандартная процедура, которая в PostgreSQL закрывается не одним и не двумя разными распространенными решениями, по которым мы сейчас пробежимся.

Большинство решений идут для Linux-like, поэтому проверяйте, работает ли это на Windows и сможете ли вы это использовать в своей инфраструктуре.

Ситуация со SPLITBRAIN также может быть неочевидной, может некорректно обрабатываться некоторыми утилитами, поэтому неплохо бы смотреть документацию, насколько там все хорошо проработано.

Давайте посмотрим, какие решения у нас присутствуют.

PGPOOL-II

Начну не с самого очевидного и популярного – скажу про PGPOOL-II.

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

Этот инструмент может выполнять следующие роли:

Connection Pooling – забирать весь входящий трафик, при этом не контролируется количество соединений на СУБД.

Replication – он контролирует и помогает настраивать репликацию. То, что я вам рассказывал про команды создания вручную в PostgreSQL, он умеет настраивать сам и преднастроенные скрипты для выполнения у него есть.

Load Balancing – может выполнять балансировку нагрузки на read-only узлах. Если вы знаете, что для определенных отчетов определенные SQL-команды должны уходить на узлы read-only, можно в конфиг-файле настроить и использовать. Хотя для 1С это будет очень непросто, но такая функция у него есть.

Limiting Exceeding Connections – позволяет ограничивать использование памяти, предполагая использование кэша.

Это не простой FAILOVER. это утилита, которая позволяет работать с большим набором функций.

У утилиты PGPOOL-II есть отдельный, достаточно скромный интерфейс – это PGPOOL ADMIN.

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

Даже если PGPOOL-II принимал автоматические решения, вы можете эти результаты тут увидеть.

Плюс администрировать ее здесь можете.

Patroni

Про Patroni сегодня в отдельном докладе рассказал Семен Трошкин.

Это отличное решение под Linux, которое строится на ZooKeeper, etcd и Consul. В Windows вам будет сложно его использовать.

Помните о том, что если вы делаете кластер, то Patroni вы можете использовать только тогда, когда у вас есть серверы на Linux.

CITUSDATA

Расширение для PostgreSQL Citus Data попало в мой доклад не потому, что это рекомендуемое решение для High Availability, а потому, что с его помощью можно построить на PostgreSQL хорошее горизонтальное масштабирование – распределить нагрузку между базами, используя шардирование.

Расширение Citusdata в поставку PostgreSQL для 1С не входит, но если вам нужно использовать шардирование и распределить нагрузку между разными базами, оставив их на read/write, то помните, что такое решение в семействе PostgreSQL есть.

Pgbouncer и HaProxy

Готовые решения под названием Pgbouncer и HaProxy нужны не для того, не для обеспечения отказоустойчивости и переключения FAILOVER. Эти решения нужны, чтобы распределять нагрузку и обеспечивать экономию ресурсов на серверах PostgreSQL в связи с тем, что каждый клиент PostgreSQL – это отдельный процесс с выделенными ресурсами на сервере PostgreSQL.

Если у вас много клиентов, на сервере это становится проблемой. Когда клиентов больше 1000, реально нужно экономить и взаимодействие между этими процессами становится проблемой для самой СУБД.

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

У нас есть опыт работы с Pgbouncer и HaProxy. HaProxy замечательно работает не только с СУБД – с его помощью можно также достаточно хорошо можно перенастраивать трафик на уровне TCP.

Но эти решения опять же можно использовать только в Linux, а вот в Windows они не работают. Мы даже пробовали их пересобрать, чтобы использовать на Windows, но это оказалось слишком сложно и остановились на другом решении.

Bi-Directional Replication

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

Здесь идет использование двух-трех серверов в режиме read/write.

Выглядит это шикарно – когда у вас много серверов. они все работают на read/write, вы можете работать с любым из них.

Но здесь нужно помнить, что как и в MS SQL Server, здесь у вас будут задержки при синхронизации транзакции. Вам нужно подтвердить получение на резервном сервере, только после этого транзакция становится закоммиченной – это та многофазность транзакции, которая используется во всех решениях master/master.

В бесплатных версиях PostgreSQL поддержку Bi-Directional Replication вы можете найти только в очень древних версиях, которые вы не сможете использовать для 1С.

Но такая возможность есть в платных решениях отечественных производителей – Postgres Pro multimaster extension, Postgres XL, Postgres-XC.

В Bucardo такая возможность тоже есть. И иностранный вендор 2ndQuadrant в решении BDR тоже используют технологию Bi-Directional Replication для реализации кластерных серверов в режиме master/master.

Можно ли использовать эту технологию для серверов больше 3-5? Наш опыт показывает, что вряд ли. Мы использовали для двух серверов с хорошей нагрузкой. Лаг при подключении – минимальный, у вас будет работать практически два мастера. Но при этом будут действовать ограничения, которые есть на физической репликации.

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

Jatoba

В СУБД Jatoba нами написан отдельный агент, обеспечивающий переключение нагрузки. Он контролирует, что с ним происходит, и автоматически принимает решение, куда переключиться.

Это позволяет избавить администратора от принятия решений вручную – наши утилиты делают это автоматически.

Возможность настроить PostgreSQL для работы с WSFC

Можно ли на Windows PostgreSQL подключить к WSFC так же, как и MS SQL Server?

Да, вы можете в Windows добавить службу PostgreSQL Server так же, как обычную службу MS SQL Server.

Там есть нюанс, потому что автоматически статус подключения определяться не будет, плюс нужно будет запускать отдельные скрипты, которые будут пытаться подключиться к СУБД и активировать слейв, мастер – помогать кластеру WSFC принять решение о том, что пора мигрировать.

У нас такие скрипты есть. Если кого-то интересует, как это настроить – пишите в комментарии. Я скажу, каким образом настроить на Windows кластер WSFC с PostgreSQL любой конфигурации – даже с Postgres Pro Enterprise заработает.

Данная статья написана по итогам доклада (видео), прочитанного на онлайн-митапе «PostgreSQL VS Microsoft SQL». Больше статей можно прочитать здесь.

Источник