| Импортозамещение > Инсталляция > Дополнительные возможности [●] | « пред. | след. » |
Такие компоненты АСР, как коллекторы (сборщики CDR), web-сервер (REST API, web-интерфейс) можно совместить достаточно легко посредством простого распределения запросов на несколько машин (реализуется на уровне). Балансировку нагрузки можно настроить любыми средствами, например, можно использовать HAProxy. В данном разделе документации речь пойдет о сервере СУБД, так как большинство серверов баз данных получают смешанные запросы на чтение/запись, а запись на любой из серверов должна распространиться на все остальные серверы, чтобы будущие запросы на чтение возвращали согласованные результаты.
Постоянная архивация может использоваться для создания кластерной конфигурации высокой степени доступности (HA) с одним или несколькими резервными серверами, способными заменить ведущий сервер в случае выхода его из строя.
Ведущий и резервный серверы работают совместно для обеспечения этой возможности, при этом они связаны опосредованно. Ведущий сервер работает в режиме постоянной архивации изменений, в то время как каждый резервный сервер работает в режиме постоянного приёма архивных изменений, получая файлы WAL от ведущего. Для обеспечения этой возможности не требуется вносить изменения в таблицы БД, поэтому администрировать данное решение репликации проще, чем ряд других. Так же такая конфигурация относительно слабо влияет на производительность ведущего сервера.
Непосредственную передачу записей WAL с одного сервера БД на другой обычно называют трансляцией журналов (или доставкой журналов). PostgreSQL реализует трансляцию журналов на уровне файлов, передавая записи WAL по одному файлу (сегменту WAL) единовременно. Файлы WAL (размером 16 МБ) можно легко и эффективно передать на любое расстояние, будь то соседний сервер, другая система в местной сети или сервер на другом краю света. Требуемая пропускная способность при таком подходе определяется скоростью записи транзакций на ведущем сервере. Трансляция журналов на уровне записей более фрагментарная операция, при которой изменения WAL передаются последовательно через сетевое соединение.
Следует отметить, что трансляция журналов асинхронна, то есть записи WAL доставляются после завершения транзакции. В результате образуется окно, когда возможна потеря данных при отказе сервера: будут утеряны ещё не переданные транзакции. Размер этого окна при трансляции файлов журналов может быть ограничен параметром archive_timeout, который может принимать значение меньше нескольких секунд. Тем не менее подобные заниженные значения могут потребовать существенного увеличения пропускной способности, необходимой для трансляции файлов.
Скорость восстановления достаточно высока, обычно резервный сервер становится полностью доступным через мгновение после активации. В результате такое решение называется тёплым резервом, что обеспечивает отличную отказоустойчивость. Восстановление сервера из архивной копии базы и применение изменений обычно происходит существенно дольше. Поэтому такие действия обычно требуются при восстановлении после аварии, не для отказоустойчивости. Так же резервный сервер может обрабатывать читающие запросы. В этом случае он называется сервером горячего резерва.
Более подробную информацию о настройки HA можно найти в официальной документации PostgreSQL: https://postgrespro.ru/docs/postgresql/10/high-availability
При инсталляции АСР на СУБД Postgres Pro есть возможность воспользоваться утилитой pg_integrity_check, которая предоставляет следующие возможности для проверки целостности:
•Подсчёт и проверка контрольных сумм по требованию
•Встроенная проверка контрольных сумм при запуске сервера
pg_integrity_check может отслеживать контрольные суммы неизменяемых и дополнительных файлов, а также таблиц системных каталогов.
К отслеживаемым неизменяемым файлам относятся исполняемые файлы, библиотеки и другие файлы, которые никогда не должны изменяться. Контрольные суммы таких файлов определяются в файле конфигурации /opt/pgpro/std-14/share/security/system.conf.
Файл system.conf включён в состав дистрибутива Postgres Pro Standard. Для каждого экземпляра Postgres Pro Standard существует один отдельный файл system.conf. Каждая строка в system.conf соответствует одному отслеживаемому объекту и содержит два поля: контрольную сумму, состоящую из 40 шестнадцатеричных цифр, и относительный путь к файлу. Эти значения разделяются тремя символами: пробел, минус, пробел. Контрольные суммы вычисляются и записываются в этот файл во время установки Postgres Pro Standard. При их расчёте учитывается и содержимое файла, и его атрибуты. Поэтому, например, при изменении прав доступа к файлу его контрольная сумма изменится.
Более подробно о настройке механизма можно прочитать в официальной документации вендора: https://postgrespro.ru/docs/postgrespro/14/integrity-checks
Контроль целостности конфигурационных файлов системы и компонентов АСР может осуществляться внешними инструментами, например, Tripwire.
Для аутентификации в рамках этого метода используется клиентский сертификат SSL, поэтому данный способ применим только для SSL-подключений. Когда используется этот метод, сервер потребует от клиента предъявления действительного и доверенного сертификата. Пароль у клиента не запрашивается. Атрибут cn (Обычное имя) сертификата сравнивается с запрашиваемым именем пользователя базы данных, и если они соответствуют, вход разрешается. Если cn отличается от имени пользователя базы данных, то может быть использовано сопоставление имён пользователей.
Для аутентификации по SSL сертификату доступны следующие параметры конфигурации: map (позволяет сопоставить имена пользователей системы и базы данных).
Для сопоставления необходимо настроить файл pg_ident.conf (пример):
# MAPNAME SYSTEM-USERNAME PG-USERNAME omicron bryanh bryanh omicron ann ann # на этих машинах у пользователя bob имя robert omicron robert bob # bryanh также может подключаться как guest1 omicron bryanh guest1 |
В записи pg_hba.conf, описывающей аутентификацию по сертификату, параметр clientcert предполагается равным 1, и его нельзя отключить, так как для этого метода клиентский сертификат является обязательным. Метод cert отличается от простой проверки пригодности сертификата clientcert только тем, что также проверяет, соответствует ли атрибут cn имени пользователя базы данных.
Более подробно о настройке аутентификации можно прочитать: https://postgrespro.ru/docs/postgresql/14/auth-methods