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

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

## Эксплуатация и мониторинг {: #production }

### Настройка службы времени {: #time }

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

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

### Настройка DNS {: #dns }

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

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

### Настройка журналирования {: #logs }

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

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

### Настройка SELinux {: #selinux }

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

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

### Настройка мониторинга {: #monitoring }

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

**Рекомендация:** настроить [мониторинг в
Grafana](grafana_monitoring.md) — это позволит находить проблемы в
работе кластера и своевременно на них реагировать — а также мониторинг
метрик самих серверов, как минимум, CPU, RAM, HDD.

### Настройка доступности портов {: #ports }

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

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

### Настройка сохранения дампов памяти при сбоях {: #coredump }

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

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

??? example "Пример включения coredump"
    добавить строку в файл `/etc/security/limits.conf`:
    ```shell
    *             soft    core            unlimited
    ```
    добавить в файл `/etc/sysctl.conf` строки:
    ```shell
    kernel.core_pattern = /tmp/core.%s.%e.%p.%h.%t
    fs.suid_dumpable = 2
    ```

### Настройка лимитов для ресурсов {: #limits }

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

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

```shell
picodata        soft    nofile          65535
picodata        hard    nofile          65535
picodata        soft    core            unlimited
picodata        hard    core            unlimited
```

### Настройка Journald {: #journald }

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

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

## Безопасность {: #security }

### Настройка пользователей {: #users }

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

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

### Настройка аудита {: #audit }

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

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

## Производительность {: #performance }

### Настройка дисковой подсистемы {: #drives }

В некоторые моменты времени, например при сбоях, в файлы журналов может
записываться большое количество информации, что негативно скажется на
других операциях кластера: WAL-журналы, снэпшоты, данные БД при
использовании [движка](../overview/glossary.md#db_engine) Vinyl.
Несмотря на то, что современные диски быстрые, для получения
максимальной производительности системы ввода-вывода стоит разнести
файлы журналов и данные по разным дисковым устройствам.

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

### Настройка `swap` {: #swap }

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

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

## Установка Picodata {: #picodata }

### Выбор версии {: #versioning }

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

**Рекомендация:** использовать Picodata из предоставляемых на
официальной [странице загрузки](https://picodata.io/download) пакетов.

### Выбор топологии {: #topology }

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

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

[Raft и отказоустойчивость]: ../architecture/raft_failover.md/#tier_based_failover

### Предоставление данных {: #info_provisioning }

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

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

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

См. также:

- [Устранение неполадок](troubleshooting.md)
