Отказоустойчивость
Для достижения отказоустойчивости StarVault работает в режиме высокой доступности (HA), запуская несколько серверов StarVault.
1. Обзор решения
Высокая доступность (HA) минимизирует время простоя, без ущерба для горизонтальной масштабируемости. StarVault ограничен лимитами ввода-вывода бэкенда хранения, а не требованиями к вычислительным ресурсам. Ограничение лимитами ввода-вывода упрощает подход к отказоустойчивости и координации.
Бэкенды хранения, такие как Integrated Storage, предоставляют дополнительные функции координации, позволяют StarVault работать в режиме высокой доступности. Если поддержан бэкенда хранения, то StarVault автоматически запускается в режиме высокой доступности без дополнительной настройки.
Узлы StarVault при работе в режиме высокой доступности находятся в двух состояниях: ожидание или активное. Для нескольких узлов StarVault, использующих общее хранилище, в любой момент времени активен только один узел. Узлы в состоянии ожидания помещаются в горячий резерв.
Только активный узел обрабатывает запросы; резервный узел перенаправляет запросы на активный узел StarVault.
В то же время, если активный узел запечатан, выходит из строя или теряет сетевое подключение, то один из резервных узлов StarVault становится активным.
Обратите внимание, что только распечатанные узлы StarVault действуют как резервные. Если узел запечатан, то он не выступает в качестве резервного. Узлы в запечатанном состоянии не обрабатывают запросы, если активный узел выходит из строя.
2. Особенность работы в отказоустойчивом режиме
StarVault поддерживает многосерверный режим, который обеспечивает высокую доступность и защиту от сбоев. Режим высокой доступности включается автоматически при использовании хранилища данных, которое его поддерживает.
Чтобы узнать, поддерживает ли хранилище данных режим высокой доступности (HA), запустите сервер и посмотрите, отображается ли сообщение (HA available) рядом с информацией о хранилище данных. Если да, то StarVault будет использовать режим автоматически. Эта информация также доступна на странице Конфигурирование.
Для поддержки высокой доступности один из серверных узлов StarVault выполняет блокировку хранилища данных. Такой серверный узел затем становится активным узлом, а остальные узлы – резервными. Если в этот момент резервные узлы получат запрос, то в зависимости от текущей конфигурации и состояния кластера либо переадресуют запрос, либо перенаправят клиента. Подробности см. в разделах ниже.
В силу такой архитектуры, HA не улучшает масштабируемость. Узкое место StarVault - само хранилище данных, а не ядро.
Некоторые бэкенды хранения поддерживают режим высокой доступности, что позволяет им хранить не только значение блокировки HA, но и информацию StarVault. Однако StarVault также поддерживает режим "разделения данных/высокой доступности", в котором значение блокировки и остальные данные хранятся раздельно.
Для этого укажите в конфигурационном файле строкам конфигурации storage и ha_storage разные бэкенды. Например, кластер StarVault настроить на использование PostgreSQL в качестве ha_storage для управления блокировкой, а file в качестве storage для остальных сохраняемых данных.
В разделах ниже подробно описываются шаблоны взаимодействия с сервером и каждый тип обработки запросов. Для работы кластера высокой доступности должны выполнены минимальные требования к режиму перенаправления.
2.1. Взаимодействие сервер-сервер
Методы для взаимодействия сервер-сервер: перенаправления клиента, переадресации запросов серверам.
Оба метода обработки запросов основаны на том, что активный узел объявляет информацию о себе другим узлам. Это взаимодействие протекает не по сети, а выполняется внутри зашифрованного хранилища StarVault; активный узел записывает эту информацию, а незапечатанные резервные узлы StarVault могут ее прочитать.
В случае метода перенаправления клиента между серверами нет прямого взаимодействия, и только зашифрованные записи в хранилище данных используются для передачи состояния.
В случае метода переадресации запросов серверам необходимо прямое взаимодействие друг с другом. Чтобы сделать это безопасно, активный узел также объявляет через зашифрованную запись хранилища данных только что сгенерированный закрытый ключ (ECDSA-P521) и только что сгенерированный самоподписанный сертификат, предназначенный для аутентификации клиента и сервера. Каждый резервный узел использует закрытый ключ и сертификат для открытия взаимно аутентифицированного соединения TLS 1.2 с активным узлом через объявленный адрес кластера. Клиентских запросы при поступлении сериализуются, отправляются по защищенному TLS каналу связи и обрабатываются активным узлом. Затем активный узел возвращает ответ резервному узлу, который отправляет ответ обратно запрашивающему клиенту.
2.2. Переадресация запросов
Если переадресация запросов включена (по умолчанию включена), то при необходимости клиенты по-прежнему могут принудительно использовать более старую процедуру перенаправления как резервный вариант (см. ниже), установив заголовок X-StarVault-No-Request-Forwarding в любое непустое значение.
Для настройки кластера требуется несколько параметров конфигурации, хотя некоторые из них могут быть определены автоматически.
2.3. Перенаправление клиента
Если заголовок X-StarVault-No-Request-Forwarding в запросе установлен в непустое значение, то резервные узлы будут, используя код статуса 307, перенаправлять клиента на адрес перенаправления активного узла.
Это тоже резервный метод, который используется, если переадресация запросов отключена или если при переадресации произошла ошибка. Таким образом, для настроек высокой доступности всегда требуется адрес перенаправления.
Некоторые драйверы хранилищ данных высокой доступности могут автоматически определять адрес перенаправления. Часто требуется настраивать адрес перенаправления вручную с помощью значения верхнего уровня в файле конфигурации. Ключ для этого значения — api_addr. Так же значение настраивается при помощи переменной окружения VAULT_API_ADDR. Переменная окружения VAULT_API_ADDR приоритетнее ключа api_addr.
Значение для api_addr, зависит от того, как настроен StarVault. Два частых сценария:
-
серверы StarVault, к которым клиенты обращаются напрямую;
-
серверы StarVault, обращение к которым происходит через балансировщик нагрузки.
В обоих случаях api_addr представляет полный URL-адрес, включая схему (http/https), а не просто IP-адрес и порт.
2.3.1. Прямой доступ
Когда клиенты обращаются к StarVault напрямую, api_addr для каждого узла представляет собой адрес этого узла. Например, есть два узла StarVault:
-
A, доступный через
https://a.starvault.mycompany.com:8200 -
B, доступный через
https://b.starvault.mycompany.com:8200
Тогда узел A установит свой api_addr в значение https://a.starvault.mycompany.com:8200, а узел B установит свой api_addr в значение https://b.starvault.mycompany.com:8200.
Когда узел A активный, то любые запросы, получаемые узлом B, будут перенаправлены на api_addr узла A по адресу https://a.starvault.mycompany.com, и наоборот.
2.3.2. Доступ через балансировщики нагрузки
Иногда клиенты используют балансировщики нагрузки в качестве первичного метода доступа к одному из серверов StarVault, но при этом сохраняют прямой доступ к каждому узлу StarVault. В этой конфигурации узлы StarVault следует настраивать так же, как описано в предыдущем разделе, поскольку механизмы перенаправления будут работать корректно: клиент имеет возможность связаться с целевым узлом напрямую.
Однако если единственный способ доступа к серверам StarVault — через балансировщик нагрузки, то каждый узел должен использовать одинаковый api_addr: адрес самого балансировщика нагрузки. В этом случае, если запрос попадает на резервный узел, он будет перенаправлен обратно на балансировщик. При обновлении конфигурации балансировщика нагрузки или при смене ведущего узла может возникнуть замкнутый цикл перенаправлений. Поэтому использовать балансировщик нагрузки как единственный входной точку к StarVault не рекомендуется.
|
Основная рекомендация — использовать балансировщик нагрузки уровня L7 (HTTP/HTTPS) или применять подход с разделением трафика, например:
Такой подход обеспечивает предсказуемую работу механизмов перенаправления и избегает замкнутых циклов. |
2.3.3. Адреса обработчиков на каждом узле кластера
Каждый блок listener в конфигурационном файле StarVault содержит значение address, на котором StarVault прослушивает запросы. Аналогично, каждый блок listener может содержать cluster_address, на котором StarVault прослушивает запросы между серверами кластера. Если это значение не задано, то IP-адрес будет автоматически установлен в значение, равное значению address, а порт будет автоматически установлен в значение, равное значению address плюс один (по умолчанию – порт 8201).
Обратите внимание, что только у активных узлов имеются активные обработчики. Когда узел становится активным, то запускает обработчики в кластере, а когда становится резервным, останавливает их.
2.3.4. Адрес каждого узла в кластере
Как и api_addr, cluster_addr – это значение, которое каждый активный узел объявляет резервным узлам, для использования во взаимодействии сервер-сервер. В конфигурационном файле cluster_addr - значение верхнего уровня.
На каждом узле должны быть имя хоста или IP-адрес, который резервный узел может использовать для связи с одним из значений cluster_address этого узла, установленных в блоках слушателей, включая порт. (Обратите внимание, что этот порт будет принудительно установлен на https, поскольку между серверами используются только TLS-соединения).
Это значение также можно указать с помощью переменной окружения VAULT_CLUSTER_ADDR, которая имеет приоритет.