Настройка серверов для кластера Picodata

В данном разделе приведены рекомендации по настройке ОС и системного ПО на серверах, на которых предполагается запуск инстансов Picodata. Рекомендации помогут избежать проблем, связанных с промышленной эксплуатацией и мониторингом кластера.

Эскплуатация и мониторинг

Настройка службы времени

Поскольку кластер Picodata — это распределенная система, то необходимо, чтобы все серверы кластера жили по единому времени.

Рекомендация: настроить на всех серверах службу времени NTP или Chrony, убедиться в отсутствии разбега времени.

Настройка DNS

Имя сервера более наглядно для восприятия администратором, чем IP-адрес. К тому же, при использовании DHCP или при замене сервера, IP-адрес может измениться, в отличие от DNS-имени.

Рекомендация: использовать на всех серверах имя (FQDN — fully qualified domain name) вместо IP-адреса.

Настройка журналирования

В файлах журналов содержится много полезной информации, особенно если в кластере начинают происходить непонятные сбои, поэтому за журналами нужно следить и своевременно их ротировать. В момент сбоев возможны резкие всплески количества сообщений, что может приводить к недостатку места на диске. Стоит организовать хранение журналов на выделенном дисковом разделе, отдельно от всего остального (система, данные) и обязательно следить за свободным местом на этом разделе. Рекомендуем настроить сохранение логов в journald, а не в файлы. Менеджер загрузки Systemd умеет самостоятельно проводить ротацию журналов с учетом свободного места на разделе.

Рекомендация: выделить отдельный и достаточной большой раздел диска для файлов журналов; использовать journald или самостоятельно настроить ротацию файлов журналов логов; настроить оповещения (alerts) в системе мониторинга для контроля за свободным местом на разделе.

Настройка SELinux

На данный момент Picodata не поддерживает правила SELinux.

Рекомендация: отключить SELinux (установите SELINUX=disabled в файле /etc/selinux/config и перезагрузитесь).

Настройка мониторинга

Серверы должны быть подключены к системе мониторинга — это поможет своевременно отслеживать проблемы при их эксплуатации. Следует следить как за метриками, так и за журналами инстансов. Помимо мониторинга серверов, обязательно нужно отслеживать метрики кластера Picodata.

Рекомендация: настроить мониторинг в Picodata — это позволит находить проблемы в работе кластера и своевременно на них реагировать — а также мониторинг метрик самих серверов, как минимум, CPU, RAM, HDD.

Настройка доступности портов

Picodata — это распределенный кластер, инстансы которого общаются между собой по бинарному протоколу (iproto). В то же время, клиентам необходим доступ к прикладным протоколам: клиентской консоли, совместимой с PostgreSQL, портам, необходимым плагинам для работы с данными, портам для мониторинга кластера по HTTP — важно обеспечить доступность всех этих портов с помощью настройки межсетевого экрана.

Рекомендация: обеспечить сетевую доступность серверов как между собой (по бинарному протоколу), так и доступ клиентов до нужных протоколов (HTTP, PostgreSQL, порты плагинов).

Настройка сохранения дампов памяти при сбоях

Информация из coredump-файлов поможет разработчикам Picodata решать проблемы в случае сбоя кластера.

Рекомендация: включить сборку coredump-файлов на серверах.

Пример включения coredump

добавить строку в файл /etc/security/limits.conf:

*             soft    core            unlimited

добавить в файл /etc/sysctl.conf строки:

kernel.core_pattern = /tmp/core.%s.%e.%p.%h.%t
fs.suid_dumpable = 2

Безопасность

Настройка пользователей

Инстанс Picodata можно запустить под любым пользователем, включая root, но с точки зрения безопасности это неправильно, поэтому мы рекомендуем создать отдельного пользователя с одинаковым UID и GID на всех серверах кластера, например с именем picodata, и запускать все процессы, связанные с работой Picodata, под этим пользователем.

Рекомендация: создать на всех серверах пользователя picodata с одноименной группой (picodata:picodata) или другого пользователя, под которым будут работать процессы кластера.

Настройка аудита

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

Рекомендация: включить журналы аудита при развёртывании кластера; использовать развёртывание с помощью нашей роли Ansible (в этом случае аудит будет включён по умолчанию).

Производительность

Настройка дисковой подсистемы

В некоторые моменты времени, например при сбоях, в файлы журналов может записываться большое количество информации, что негативно скажется на других операциях кластера: WAL-журналы, снэпшоты, данные БД при использовании движка Vinyl. Несмотря на то, что современные диски быстрые, для получения максимальной производительности системы ввода-вывода стоит разнести файлы журналов и данные по разным дисковым устройствам.

Рекомендация: разнести разделы с журналами и данными по разным дисковым устройствам.

Настройка swap

Большая часть информации, даже при использовании движка Vinyl, обрабатывается в ОЗУ. Если в системе включена подкачка (swap), то может сложиться ситуация, когда ОС будет пытаться сохранить страницы памяти на диск, что приведет к снижению производительности кластера.

Рекомендация: отключить подкачку (swap) на серверах.