3 совета администратору Greenplum: лучшие практики настройки кластера

Автор Категория ,
3 совета администратору Greenplum: лучшие практики настройки кластера

Хотя наши практические курсы по Greenplum и Arenadata DB больше ориентированы на аналитиков и дата-инженеров, чем на администраторов, в программы обучения также включены важные сведения по настройке этих MPP-СУБД. В этой статье мы собрали лучшие практики системного конфигурирования кластера Greenplum, которые помогут повысить эффективность аналитики больших данных в этой Big Data системе.

Настройка часового пояса и другие важные операция администрирования Greenplum

Прежде всего отметим, что настройка кластера СУБД Greenplum обычно выполняется от имени пользователя root, обладающего максимальными привилегиями – возможностями выполнять любую операцию [1]. Далее рассмотрим действия администратора кластера Greenplum по конфигурированию следующих настроек:

  • часовой пояс;
  • файловая система;
  • операционная система;
  • количество сегментов на хост.

Будучи основана на PostgreSQL, о чем мы подробно писали здесь, Greenplum выбирает часовой пояс из набора внутренних часовых поясов этой ORM-СУБД. Доступные часовые пояса PostgreSQL берутся из базы данных часовых поясов IANA-администрации (Internet Assigned Numbers Authority), которая исполняется компанией Public Technical Identifiers под контролем ICANN – международной независимой корпорации по управлению доменными именами и IP-адресами (Internet Corporation for Assigned Names and Numbers). IANA выполняет функцию управления пространствами IP-адресов, доменов верхнего уровня, а также регистрирующая типы данных MIME и параметры прочих протоколов Интернета, включая ведение базы часовых поясов. При изменении базы данных часовых поясов IANA для PostgreSQL список доступных часовых поясов обновляется и в Greenplum.

Greenplum выбирает часовой пояс, сопоставляя часовой пояс PostgreSQL с указанным пользователем часовым поясом или с часовым поясом хост-системы. Например, при выборе часового пояса по умолчанию Greenplum использует алгоритм выбора часового пояса PostgreSQL на основе файлов часовых поясов хост-системы. Если системный часовой пояс включает информацию о секундах координации, Greenplum не может сопоставить системный часовой пояс с часовым поясом PostgreSQL. В этом случае Greenplum выбирает наиболее близкое совпадение с часовым поясом PostgreSQL на основе информации от хост-системы.

Рекомендуется настроить Greenplum и хост-систему на известный часовой пояс, чтобы установить настройки времени для главного экземпляра MPP-СУБД и экземпляров сегментов, а также избежать пересчета часов при каждом перезапуске кластера. Для отображения и установки часового пояса Greenplum администратор кластера использует утилиту gpconfig. Например, следующая команда покажет часовой пояс Greenplum: # gpconfig –s TimeZone

А добавление к ней параметров установит время нужного региона, например, так можно установить часовой пояс Москвы в Европейском регионе (GMT+3):

# gpconfig -c TimeZone -v ‘Europe/Moscow’

После изменения часового пояса следует перезапустить Greenplum командой gpstop -ra. Представление каталога pg_timezone_names предоставляет информацию о часовом поясе Greenplum [1].

Также следует использовать сетевой протокол времени NTP (Network Time Protocol) для синхронизации системных часов на всех хостах СУБД. NTP на хостах сегментов должен быть настроен на использование главного хоста в качестве основного источника времени и резервного главного устройства в качестве вторичного источника времени. На главном и резервном главном хостах нужно настроить настройте NTP так, чтобы он указывал на предпочтительный сервер времени [2].

Монтирование томов файловой системы XFS

Для каталогов Greenplum использует XFS – высокопроизводительную 64-битную журналируемую файловую систему корпорации Silicon Graphics, изначально созданную для операционной системы IRIX. 1 мая 2001 года Silicon Graphics выпустила XFS под публичной лицензией GNU GPL. В отличие от многих других файловых систем, XFS с самого начала рассчитана для использования на дисках большого объёма (более 2 терабайт), таких как RAID-массивы. Обладая малыми накладными расходами на хранение служебных структур данных и минимальной фрагментацией файлов благодаря отложенному выделению места (Delayed allocation), XFS имеет ряд специфических недостатков. В частности, нельзя уменьшить размер существующей файловой системы, сложно восстановить удаленные файлы и возможны потери данных во время записи при сбое питания из-за их буферизации в оперативной памяти [3].

Поэтому если потеря данных неприемлема, для кластера Greenplum рекомендуется использовать мастер-сервер и зеркальное отображение сегментов. Если зеркалирование не включено, Greenplum хранит только одну копию данных, где основной носитель обеспечивает единственную гарантию доступности и правильности данных в случае отказа оборудования. При использовании технологий контейнеризации, Kubernetes обеспечивает быстрое восстановление после сбоев пода и хоста, а службы хранения гарантируют высокий уровень доступности. Но контейнерная виртуализация затрудняет обеспечение гарантий для зеркалирования Greenplum, поэтому для развертывания этой СУБД на Kubernetes зеркалирование используется редко [3].

В операционных системах Red Hat Enterprise Linux или CentOS монтировать тома XFS рекомендуется со следующими параметрами [1, 4]:

  • rw – поддержка чтения и записи данных;
  • nodev – без блокировки устройств;
  • noatime – метки времени доступа не обновляются при чтении файла.
  • nobarrier – без барьеров записи, которые обеспечивают упорядочение фиксаций логов на диске, делая использование кэшей безопасным при снижении производительности. Если диски имеют резервное питание от батареи, отключение барьеров (nobarrier) может повысить производительность. Эта опция не поддерживается в системах Ubuntu.
  • inode64 – разрешение XFS создавать индексные дескрипторы в любом месте файловой системы, включая те, номера которых занимают более 32 бита значимости. Это предусмотрено для обратной совместимости, но вызывает проблемы для приложений резервного копирования, которые не могут обрабатывать большие номера inode.

Количество сегментов на хост и настройка операционной системы

Для всех хост-систем Greenplum, работающих под управлением Red Hat Enterprise Linux или CentOS, SELinux должен быть отключен или настроен на неограниченный доступ пользователя gpadmin к процессам и каталогам этой MPP-СУБД. Также необходимо задать некоторые специальные операционной системы (ОС) Linux на всех хостах, т.е. на мастере и сегментах Greenplum. Обычно требуется изменить следующие категории параметров системы [2]:

  • общая память – экземпляр Greenplum не будет работать, если сегмент общей памяти для ядра не имеет нужного размера. Большинство установок ОС по умолчанию имеют слишком низкие значения разделяемой памяти для базы данных Greenplum. В системах Linux также следует отключить OOM-киллер.
  • пользовательские ограничения, которые контролируют ресурсы, доступные процессам, запускаемым оболочкой пользователя. Greenplum требует ограничения на допустимое количество файловых дескрипторов, которые может открыть один процесс. Настройки по умолчанию могут привести к сбою некоторых SQL-запросов, если в них закончатся файловые дескрипторы, необходимые для обработки.

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

В заключение отметим, что определение количества сегментов для запуска на каждом узле кластера сильно влияет на производительность всей базы данных. При том, что Greenplum реализует концепцию без разделения ресурсов (share nothing), сегменты этой СУБД, запущенные на одном хосте, совместно используют имеющиеся на этом узле кластера ядра ЦП, память и сетевые карты, конкурируя друг с другом и с другими процессами, запущенными там же. Превышение количества сегментов, которые может вместить один сервер, – частая причина неоптимальной производительности. Поэтому при выборе количества сегментов GP для запуска на одном узле кластера, нужно учитывать его параметры [1]:

  • количество ядер ЦП;
  • количество физической оперативной памяти;
  • количество сетевых карт;
  • объем постоянного хранилища;
  • комбинация первичного и зеркального сегментов;
  • ETL-процессы, которые будут выполняться на хостах;
  • запущенные процессы, не относящиеся к Greenplum.

Важно, что добавление узлов сегмента в кластер не поможет при ошибках нехватки памяти, если не используются дополнительные узлы, чтобы снизить количество сегментов на узел. О некоторых проблемах нехватки памяти и способах их решения в Greenplum мы рассказывали здесь и здесь. Однако, причиной отдельных неполадок является настройка памяти на уровне операционной системы, что мы рассмотрим в следующей статье. А узнать все тонкости администрирования и эксплуатации этой MPP-СУБД на примере Arenadata DB или в виде отдельного продукта для эффективного хранения и аналитики больших данных вам помогут наши специализированные курсы в лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:

Источники

  1. https://gpdb.docs.pivotal.io/6-17/best_practices/sysconfig.html
  2. https://gpdb.docs.pivotal.io/6-17/install_guide/prep_os.html
  3. https://ru.wikipedia.org/wiki/XFS
  4. https://linux.die.net/man/8/mount