3 технологии высокой доступности Greenplum для администратора Big Data кластера

Автор Категория ,
3 технологии высокой доступности Greenplum для администратора Big Data кластера

Продолжая рассказывать про наш новый курс «Greenplum для инженеров данных», сегодня рассмотрим некоторые особенности хранения данных в этой MPP-СУБД, а также разберем связанные с ними лучшие практики ее администрирования. Читайте далее про важность RAID-массивов, механизмы дублирования кластеров, утилиты резервного копирования и восстановления данных в Greenplum.

RAID-массивы и зеркалирование жестких дисков Greenplum

Greenplum позиционируется как надежная СУБД для хранения и быстрой аналитики огромных объемов данных, обеспечивающая высокую доступность построенных на ней Big Data систем за счет массивно-параллельной архитектуры и резервирования ключевых компонентов. Согласно концепции без разделения ресурсов (Share Nothing), в кластере Greenplum каждый мастер-хост и хост-сегмент имеют собственную выделенную память и дисковое хранилище, а любой экземпляр СУБД – свой независимый каталог данных. Для надежности и высокой производительности рекомендуется аппаратное решение для хранения данных на основе RAID с 8-24 дисками [1].

Напомним, RAID (Redundant Array of Independent Disks — избыточный массив независимых дисков) — это технология виртуализации данных для объединения нескольких физических жестких дисков в один логический модуль, чтобы повысить отказоустойчивость и производительность всей системы. Большее количество дисков увеличивает пропускную способность ввода-вывода при использовании уровней RAID 5 или 6, т.к. чередование увеличивает объем параллельного дискового ввода-вывода. Широко распространенные сегодня уровни RAID-массивов 5 и 6 отличаются повышенным уровнем надежности, обеспечивают высокую скорость чтения и экономичны в эксплуатации, однако их производительность снижается при операциях записи в произвольном порядке [2]. Но этот сценарий не слишком характерен для Greenplum.

Впрочем, для Greenplum можно применять и другие уровни RAID-массивов, даже RAID 1, суть которого в простом зеркалировании данных на разные дисковые массивы. В случае RAID 5 каждый ввод-вывод данных на отказавшем элементе Greenplum будет восстанавливаться из данных на оставшихся активных дисках, что приведет к временному снижению производительности. Чтобы избежать этой просадки, рекомендуется переключить все затронутые сбоем экземпляры Greenplum на их зеркала на период восстановления.

Несмотря на заявления о надежности, дисковый массив RAID может оставаться единственной точкой отказа, если из строя выйдет весь том RAID. Защититься от этого на аппаратном уровне можно с помощью зеркального копирования массива, используя зеркалирование операционной системы хоста или контроллера RAID, если оно поддерживается.

При этом важно регулярно контролировать доступное дисковое пространство на каждом хост-сегменте. Для этого администратору Greenplum пригодится утилита gptoolkit, с помощью которой можно просмотреть внешнюю таблицу gp_disk_free, показывающую дисковое пространство, доступное для сегментов. Это представление запускает команду Linux df, отображающую список всех файловых систем по именам устройств с их размером, занятым и свободным пространство, а также точки монтирования. Рекомендуется всегда пользоваться этим инструментом перед выполнением операций, которые занимают много места на диске, например, копирование большой таблицы. Кроме этого совета, можно выделить еще несколько лучших практик, связанных с жесткими дисками на узлах кластера Greenplum [1]:

  • использование аппаратных решений для хранения RAID с уровнями 1, 5 или 6 на 8–24 жестких дисках, чтобы дисковый массив мог выдержать отказ диска;
  • настройка горячего резервирования в дисковом массиве, чтобы восстановление начиналось автоматически при обнаружении сбоя;
  • зеркалирование томов RAID, чтобы защитить от сбоя весь дисковый массив и деградации во время его восстановления;
  • добавление дополнительного дискового пространства в случае необходимости;
  • отслеживание неравномерного распределения (перекосов) данных по сегментам, чтобы гарантировать равномерное использование хранилища во всех частях кластера.

Резервное копирование и восстановление данных

Поскольку кластер Greenplum уже предполагает некоторую избыточность в хранении данных, то регулярное создание дополнительных резервных копий рекомендуется, если только информация в СУБД не может быть легко и чисто восстановлена из исходных в случае сбоя. Так резервные копии (бэкапы) защитят от операционных, программных или аппаратных ошибок. Для создания таких бэкапов в Greenplum есть специальная утилита gpbackup, которая создает резервные копии параллельно по сегментам, масштабируя их по мере увеличения размера оборудования кластера. Утилита gpbackup устанавливает блокировки общего доступа (SHARED ACCESS) на набор таблиц для резервного копирования. Резервные копии с меньшим количеством таблиц более эффективны для выборочного восстановления схем и таблиц, т.к. утилите gprestore не нужно выполнять поиск по всей базе данных.

Стратегия резервного копирования должна учитывать, куда будут записываться резервные копии и где они будут храниться. Резервные копии можно делать на локальные диски рабочего кластера Greenplum, но они не должны храниться там постоянно, т.к. при глобальной аварии в одном хранилище данные могут быть потеряны одновременно. Поэтому по завершении локального резервного копирования файлы бэкапа рекомендуется перенести в безопасное место вне рабочего кластера GP.

Альтернативой является резервное копирование непосредственно на устройства сетевой файловой системы (NFS, Network File System). Бэкапы в горизонтально масштабируемом NFS-решении не ограничивают пропускную способность ввода-вывода устройства NFS. Примером такого NFS-решения является высоконадежное сетевое файловое хранилище Dell EMC Isilon, которое может масштабироваться вместе с кластером Greenplum. А благодаря встроенной интеграции API, Greenplum может передавать бэкапы напрямую на корпоративную платформу резервного копирования Dell EMC Data Domain.

Подчеркнем, что создание бэкапов не стоит путать с обеспечением дополнительной избыточности за счет дублирования кластеров Greenplum, в которых синхронно хранятся одни и те же данные. Реализовать это можно с помощью двойного ETL, когда все процессы Extract-Transform-Load выполняются дважды, параллельно в каждом кластере с последующей проверкой. Двойной ETL обеспечивает полный резервный кластер с дублированными данными и позволяет запрашивать данные в обоих кластерах, удваивая производительность обработки. Приложение может использовать преимущества обоих кластеров по мере необходимости, обеспечивая успешную работу ETL и проверку на обеих сторонах.

Резервное копирование и восстановление тоже можно рассматривать как механизм реализации двойных кластеров: бэкап выполняется в основном кластере, затем резервная копия реплицируется и восстанавливается во втором кластере. Механизм резервного копирования и восстановления имеет большую задержку, чем двойной ETL, но менее требователен к разработке логики приложения. Резервное копирование и восстановление идеально подходят для сценариев, когда изменения данных и ETL выполняются раз в день или реже [1]. Читайте в нашей новой статье о том. как обеспечить информационную безопасность кластера GP и сохранить данные в этой MPP-СУБД.

Узнайте больше про администрирование и эксплуатацию Greenplum для эффективного хранения и аналитики больших данных на авторском курсе «Greenplum для инженеров данных» в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве.

Источники

  1. https://gpdb.docs.pivotal.io/6-16/best_practices/ha.html
  2. https://ru.wikipedia.org/wiki/RAID