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

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

Рекомендация: создать файла/etc/security/limits.d/99-picodata.conf со следующим содержанием (для пользователя picodata):

picodata        soft    nofile          65535
picodata        hard    nofile          65535
picodata        soft    core            unlimited
picodata        hard    core            unlimited

Настройка Journald

При регистрации системных событий ОС с помощью службы Journald (используется по умолчанию в Systemd) может возникнуть ситуация, когда журналы службы хранятся только в ОЗУ (/run/log/journal) и из-за этого со временем становятся недоступны.

Рекомендация: настроить Journald так, чтобы журналы явно сохранялись на диске. Для этого добавьте в файл /etc/systemd/journald.conf строку Storage=persistent.

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

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

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

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

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

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

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

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

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

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

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

Настройка swap

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

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

Установка Picodata

Выбор версии

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

Рекомендация: использовать Picodata из предоставляемых на официальной странице загрузки пакетов.

Выбор топологии

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

Рекомендация: выделить отдельный тир-арбитр с параметрами replication_factor=1 и can_vote: true и назначить ему 5 репликасетов c размещением в разных физических локациях. Для остальных тиров использовать параметр can_vote: false.

Предоставление данных

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

Рекомендация: предоставить разработчику следующий набор сведений:

• версия ОС, версия Picodata, версии всех установленных плагинов
• карта инсталляции кластера:
  • в случае развертывания через Ansible достаточно предоставить плейбук и инвентарный файл
  • в случае развертывания через Helm Chart предоставьте версия Chart, а также использованные параметры (values)
  • в случае ручного развертывания предоставьте список узлов, топологию (физическую, виртуальную, контейнерную), список настроек каждого узла (data dir, log dir, config dir), порты, на которых подняты интерфейсы IPROTO, PostgreSQL и HTTP
• расположение coredump-файлов

См. также:

• Устранение неполадок