Инструменты управления ====================== .. _check_cluster: Проверка состояния кластера ---------------------------- Проверка состояния кластера **ADB** запускает утилиту **gpstate utility** и выполняет распределенный запрос по базе данных. Для проверки результатов действий над кластером необходимо: 1. Открыть кластер *adb* в ADCM и нажать кнопку "Check" (:numref:`Рис.%s `). .. _img_39: .. figure:: ../install/adcm/images/img_39.png :align: center Запуск проверки состояния кластера 2. Подтвердить действие в открывшемся диалоговом окне (:numref:`Рис.%s `). .. _img_40: .. figure:: ../install/adcm/images/img_40.png :align: center Запрос на подтверждение действия 3. Открыть вкладку "JOBS" (:numref:`Рис.%s `). .. _img_41: .. figure:: ../install/adcm/images/img_41.png :align: center Вкладка "JOBS" 4. Выбрать последнее действие над кластером *adb* и в открывшемся окне проверить результаты (:numref:`Рис.%s `). .. _img_42: .. figure:: ../install/adcm/images/img_42.png :align: center Проверка состояния кластера Запуск и остановка ADB ------------------------ Существует возможность запуска и остановки кластера **ADB** не только посредством консоли, но и через **ADCM**. .. _stop_cluster: Для остановки кластера необходимо: 1. Перейти на любую вкладку кластера adb (в примере "Services") и нажать кнопку "Stop" на верхней панели (:numref:`Рис.%s `). .. _img_43: .. figure:: ../install/adcm/images/img_43.png :align: center Остановка кластера 2. Выбрать режим остановки ADB. В режиме *smart* остановка производится только в том случае, если отсутствуют клиентские соединения к базе данных, иначе процесс завершается с ошибкой. Чтобы прервать выполняющиеся транзакции, закрыть открытые соединения и принудительно остановить работу кластера необходимо использлвать режим *fast*. В режиме *immediate* принудительно завершаются процессы postgres, не давая корректно обработать транзакции кластеру. Этот режим не рекомендуется, так как в некоторых случаях может привести к повреждению базы данных. Для подтверждения действия необходимо нажать кнопку *Run* (:numref:`Рис.%s `). .. _img_44: .. figure:: ../install/adcm/images/img_44.png :align: center Выбор режима остановки кластера 3. В результате успешной остановки кластера после обновления страницы пиктограммы статусов сервисов меняют цвет на оранжевый (:numref:`Рис.%s `), а кластер меняет состояние с *running* на *stopped* (:numref:`Рис.%s `). .. _img_58: .. figure:: ../install/adcm/images/img_56.png :align: center Статусы сервисов .. _img_53: .. figure:: ../install/adcm/images/img_52.png :align: center Состояние кластера .. important:: В результате того или иного действия состояния сервисов не меняются на *stopped*, а сохраняют то же значение, что и после инсталляции. Это связано с опасениями инвалидации состояния в случаях, когда кластер *ADB* управляется через консоль в обход *ADCM* Для запуска кластера необходимо: 1. Перейти на любую вкладку кластера adb и нажать кнопку "Start" на верхней панели. 2. Подтвердить действие в открывшемся диалоговом окне. 3. В результате успешного запуска кластера после обновления страницы пиктограммы статусов сервисов меняют цвет на зеленый, кластер меняет состояние с *stopped* на *running*. Управление файловыми пространствами ------------------------------------- *Доступно с версии 5.19.0_arenadata4_b1* Для управления файловыми пространствами средствами ADCM может быть использовано действие "Manage filespace". Действие доступно для проинициализированного кластера ADB: * В выпадающем списке действий на странице со списком сервисов "Services" для сервиса *ADB*; * В виде кнопки в верхней панели на страницы сервиса *ADB*. Действие вызывает диалоговое окно управления файловым пространством (:numref:`Рис.%s `). .. _img_fs_config: .. figure:: ../install/adcm/images/img_68.png :align: center Диалоговое окно управления файловым пространством В диалоговом окне доступны следующие поля: * **Name** -- имя файлового пространства. Может быть указано имя уже существующего файлового пространства для совершения операций над ним; * **Path** -- путь, по которому должно быть расположено файловое пространство. Если не указано устройство, на котором должно быть расположено файловое пространство, путь должен существовать на всех хостах кластера и быть доступным на запись системному пользователю ADB; * **Storage device** -- имя устройства, которое необходимо использовать для создания файлового пространства (например, sdc). Для использования этой опции имя устройства должно совпадать на всех серверах кластера. На устройстве в процессе инициализации создается файловая система XFS, устройство монтируется в указанный в предыдущем параметре путь; * **Location of temporary files** -- переместить временные файлы в указанное файловое пространство; * **Location of transaction files** -- переместить файлы транзакций в указанное файловое пространство. .. important:: Опции перемещения временных файлов и файлов транзакций в другое файловое пространство требуют остановки кластера. Активные соединения пользователей прерываются Установа и удаление gpperfmon ----------------------------- Перед установкой кластера доступна возможность управления фактом установки на нем системы мониторинга gpperfmon при помощи соответствующего флажка в конфигурации сервиса *ADB*. После установки данный флажок недоступен для изменения, однако для сервиса *ADB* доступны два действия: + Install GPperfmon -- устанавливает необходимые пакеты на мастер и сегментные серверы, создает пользователя gpmon и предоставляет ему доступ к кластеру, генерирует конфигурационный файл и инициализирует gpperfmon. + Uninstall GPperfmon -- выполняет удаление gpperfmon из кластера, включая пользователя gpmon, базу данных gpperfmon и файлы журналов, расположенные в дата-каталогах в каталоге gpperfmon. Также удаляется соответствующий пакет из системы. Расширение кластера без ADCM ------------------------------ Увеличить производительность и емкость хранилища можно, развернув кластер **Arenadata DB**, добавив новые сегмент-сервера в массив. Хранилища данных обычно растут по мере сбора дополнительных данных и увеличения сроков хранения существующих. Время от времени необходимо увеличивать емкость кластера для консолидации разных хранилищ в одной базе данных. Также может потребоваться дополнительная вычислительная мощность процессора для размещения недавно добавленных проектов аналитики. Хотя было бы разумно обеспечить потенциал для роста при изначальном определении системы, но, как правило, невозможно инвестировать в ресурсы задолго до того, как они потребуются. Поэтому следует периодически выполнять расширение базы данных. При добавлении ресурсов в **ADB** по причине MPP-архитектуры ее емкость и производительность такие, как если бы система была первоначально реализована с добавленными ресурсами. В отличие от хранилищ данных, требующих значительного простоя для сброса и восстановления данных, в **ADB** этот показатель минимальный за счет поэтапного процесса расширения. Регулярные и специальные рабочие нагрузки могут продолжаться в ходе перераспределения данных с сохранением последовательности транзакций. Администратор может назначить активность распределения в соответствии с текущими операциями и при необходимости приостановить и возобновить его. А таблицы можно ранжировать таким образом, чтобы наборы данных перераспределялись в приоритетном порядке для скорейшего использования полученного расширенного объема критическими рабочими нагрузками или для освобождения необходимого дискового пространства для перераспределения очень больших таблиц. В процессе расширения используются стандартные операции базы данных **ADB**. Зеркалирование сегментов и все механизмы репликации остаются активными, поэтому отказоустойчивость бескомпромиссна, а меры аварийного восстановления эффективны. + `Планирование расширения кластера`_ + `Подготовка и добавление узлов`_ + `Добавление новых сегмент-серверов`_ + `Перераспределение таблиц`_ + `Удаление временной схемы расширения`_ При расширении базы данных **ADB** следует ожидать следующие особенности: + Масштабируемость и производительность -- при добавлении ресурсов емкость и производительность кластера такие, как если бы система была первоначально реализована с добавленными ресурсами; + Бесперебойная работа при расширении -- регулярные рабочие нагрузки, как запланированные, так и специальные, не прерываются. Для инициализации новых сегмент-серверов требуется короткий запланированный период времени простоя, аналогичный необходимому для перезапуска системы. Продолжительность простоя не связана с размером кластера до или после расширения; + Согласованность транзакций; + Отказоустойчивость -- во время расширения стандартные механизмы отказоустойчивости, такие как зеркальное отображение сегментов, остаются активными, последовательными и эффективными; + Репликация и аварийное восстановление -- все существующие механизмы репликации продолжают функционировать во время расширения. Необходимые в случае сбоя или аварии механизмы восстановления остаются эффективными; + Прозрачность процесса -- в процессе расширения используются стандартные механизмы, поэтому администраторы могут диагностировать и устранять любые проблемы; + Настраиваемый процесс -- расширение может быть длительным процессом, но его можно вписать в график текущих операций. Таблицы схемы расширения позволяют администраторам устанавливать приоритет порядка перераспределения таблиц, а активность расширения может быть приостановлена и возобновлена. Планирование и физические аспекты проекта по расширению кластера составляют большую часть работы, чем само расширение. Для планирования и выполнения требуется многопрофильная команда -- для локальных установок необходимо получить и подготовить пространство для новых сегмент-серверов; сервера должны быть выбраны, приобретены, установлены, подключены, настроены и протестированы. Для облачных развертываний должны быть сделаны аналогичные работы. После подготовки новых платформ и конфигурации их сетей необходимо настроить операционные системы и выполнить тесты на производительность с помощью утилит **ADB**. ПО кластера включает утилиты, которые полезны для тестирования и записи новых сегмент-серверов перед началом расширения. Сразу после установки и тестирования новых сегмент-серверов начинается программная фаза процесса расширения, спроектированная минимально разрушительной, транзакционно последовательной, надежной и гибкой. Во время инициализации хостов новых сегмент-серверов и подготовки системы к процессу расширения есть короткий интервал простоя. Это время может быть запланировано на период низкой активности во избежание нарушения текущих бизнес-операций. В течение инициализации выполняются задачи: + Устанавливается ПО; + Создается база данных с объектами на хостах нового сегмент-сервера; + Создается схема расширения в базе данных master для управления процессом расширения; + Изменяется политика распределения на *DISTRIBUTED RANDOMLY* для каждой таблицы. Затем система перезапускается, и приложения возобновляются: + Добавленные сегмент-сервера сразу становятся доступными и участвуют в новых запросах и загрузке данных. Однако существующие данные искажаются, так как они сконцентрированы на исходных сегментах и должны быть перераспределены по их новому общему числу; + По причине того, что таблицы теперь имеют рандомную политику распределения, оптимизатор создает планы запросов, которые не зависят от ключей распределения. Некоторые запросы становятся менее эффективными, поскольку необходимы дополнительные операторы данных. Таблицы и партиции перераспределяются, используя таблицы контроля расширения (expansion control) в качестве инструкции, при этом: + Для изменения политики распределения обратно к исходной используется оператор *ALTER TABLE* с параметром *REORGANIZE=TRUE*, в результате данные распределяются по всем серверам, старым и новым, в соответствии с первоначальной политикой; + Статус таблиц обновляется в таблицах expansion control; + Оптимизатор запросов создает более эффективные планы выполнения, опираясь на ключи распределения. Расширение кластера **ADB** завершается по окончанию перераспределения всех таблиц. Перераспределение данных -- это длительный процесс, создающий большую сетевую и дисковую активность. Перераспределение некоторых очень больших баз данных может занять несколько дней. С целью свести к минимуму последствия повышенной активности для бизнес-операций системные администраторы могут приостанавливать и возобновлять деятельность по расширению кластера на разовой основе или в соответствии с заранее заданным графиком. Наборам данных можно установить приоритетность для того, чтобы критически важные приложения в первую очередь получили пользу от расширения. За весь процесс расширения утилита **gpexpand** запускается четыре раза с различными параметрами: 1. При создании настроечного файла: :command:`gpexpand -f hosts_file` 2. При инициализации сегмент-серверов и создании схемы расширения: :command:`gpexpand -i input_file -D database_name` Утилита **gpexpand** создает каталог данных, копирует пользовательские таблицы из всех существующих баз данных в новые сегмент-сервера и записывает метаданные для каждой таблицы в схему расширения для отслеживания статуса. По завершении процесса операция расширения фиксируется и является необратимой. 3. При перераспределении таблиц: :command:`gpexpand -d duration` При инициализации **gpexpand** аннулирует политики распределения хеша в таблицах во всех существующих базах данных, за исключением родительских в секционированной таблице, и устанавливает рандомную политику распределения для всех таблиц. Для завершения процесса расширения системы необходимо запустить утилиту **gpexpand** для перераспределения таблиц данных по добавленным сегмент-серверам. В зависимости от размера и масштаба системы перераспределение может быть выполнено за одну сессию или его можно разделить по этапам, но в течение более продолжительного периода. В процессе перераспределения таблицы и партиции недоступны для операций чтения и записи. Поскольку каждая таблица перераспределяется по новым сегмент-серверам, производительность базы данных постепенно улучшается и в итоге превышает тот уровень, который был до расширения. В крупномасштабных системах, требующих нескольких сеансов перераспределения, может потребоваться неоднократный запуск **gpexpand**. Утилита может быть полезна при явном ранжировании перераспределенной таблицы. По завершению инициализации и возвращению системы в оперативный режим пользователи получают доступ к базе данных, но возможно ухудшение производительности систем, которые в значительной степени зависят от хеш-распределения таблиц. Обычные операции, такие как задания ETL, пользовательские запросы и отчеты, продолжаются, хотя пользователи могут отмечать более медленное время отклика. Когда таблица имеет рандомную политику распределения, база данных **ADB** не может применять уникальные ограничения (например, PRIMARY KEY), поскольку повторяющиеся строки не выдают ошибку "constraint violation". Это может повлиять на ETL и процессы загрузки до тех пор, пока не завершится перераспределение таблицы. 4. При удалении схемы расширения: :command:`gpexpand -c` Планирование расширения кластера ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Тщательное планирование обеспечивает успех проекта по расширению кластера **ADB**. Темы данного раздела помогают убедиться в готовности к процессу расширения системы: + `Контрольный список расширения`_ + `Планирование нового аппаратного оборудования`_ + `Планирование инициализации нового сегмент-сервера`_ + `Планирование таблицы перераспределения`_ Контрольный список расширения ****************************** Контрольный список расширения -- это список, включающий задачи для подготовки и выполнения процесса расширения базы данных **ADB**. **Онлайн-задачи перед процессом расширения** (система работает и доступна): + Разработать и выполнить план заказа, создания и подключения новых аппаратных платформ или подготовить облачные ресурсы; + Разработать план расширения базы данных. Сопоставить количество сегментов на одном хосте, запланировать период простоя для тестирования производительности и создания схемы расширения, назначить интервалы для перераспределения таблиц; + Выполнить полный сброс схемы; + Установить двоичные файлы базы данных на новые хосты; + Скопировать SSH-ключи на новые хосты (**gpssh-exkeys**); + Проверить работоспособность операционной системы нового оборудования или облачных ресурсов (**gpcheck**); + Проверить дисковый ввод-вывод и пропускную способность памяти нового оборудования или облачных ресурсов (**gpcheckperf**); + Проверить, что в каталоге master data нет чрезвычайно больших файлов в директориях *pg_log* и *gpperfmon/data*; + Проверить, что нет проблем с каталогом (**gpcheckcat**); + Подготовить настроечный файл для расширения (**gpexpand**). **Офлайн-задачи расширения** (система заблокирована и недоступна для всех действий пользователя во время данного процесса): + Проверить среду операционной системы для объединения существующих и новых аппаратных платформ или облачных ресурсов (**gpcheck**); + Проверить дисковый ввод-вывод и пропускную способность памяти для объединения существующих и новых аппаратных платформ или облачных ресурсов (**gpcheckperf**); + Инициализировать новые сегмент-сервера в массиве и создать схему расширения (**gpexpand-i** *input_file*). **Онлайн-расширение и перераспределение таблиц** (система работает и доступна): + Остановить любые автоматизированные процессы создания снапшотов или другие процессы, занимающие дисковое пространство, перед началом перераспределения таблиц; + Перераспределить таблицы с помощью расширенной системы (**gpexpand**); + Удалить схему расширения (**gpexpand-c**); + Запустить **analyze** для обновления статистики распределения. Во время расширения использовать **gpexpand -a**, после расширения -- **analyze**. Планирование нового аппаратного оборудования ********************************************** Продуманный и тщательный подход к разворачиванию совместимого оборудования значительно сокращает возможные риски процесса расширения. Аппаратные ресурсы и конфигурации для новых сегмент-серверов должны соответствовать ресурсам существующих хостов. Шаги по планированию и настройке новых аппаратных платформ различаются для каждого разворачивания. Некоторые общие рекомендации: + Подготовить физическое пространство для нового оборудования, учесть охлаждение, источник питания и другие физические факторы; + Определить физическую сеть и кабели для подключения нового и существующего оборудования; + Сопоставить существующее пространство IP-адресов и разработать сетевой план для расширенной системы; + Узнать конфигурацию системы (пользователи, профили, сетевые карты и т.д.) по существующему оборудованию для использования в качестве подробного списка для нового оборудования; + Создать план кастомной сборки для разворачивания аппаратного обеспечения с требуемой конфигурацией на конкретном месте и в конкретной среде. После выбора и добавления нового аппаратного оборудования в сетевую среду убедиться, что успешно выполняются burn-in tasks. Планирование инициализации нового сегмент-сервера *************************************************** Расширение **ADB** требует ограниченного периода простоя системы. В течение этого времени необходимо запустить **gpexpand** для инициализации новых сегмент-серверов в массиве и создать схему расширения. Период простоя системы зависит от количества объектов схемы в **ADB** и от других факторов, связанных с производительностью оборудования. В большинстве сред инициализация новых сегмент-серверов занимает менее тридцати минут в автономном режиме. .. important:: После начала инициализации новых сегмент-серверов восстановление системы с помощью резервных файлов, созданных перед расширением, невозможно. При успешной инициализации расширение фиксируется и не может быть отменено При наличии у массива зеркальных сегментов необходимо, чтобы новые сегмент-сервера имели сконфигурированное зеркалирование, иначе добавление зеркал к новым хостам с помощью утилиты **gpexpand** невозможно. Также необходимо убедиться, что добавлено достаточно новых хост-машин для размещения новых зеркальных сегментов. Количество новых хостов зависит от используемой стратегии зеркалирования: + Spread Mirroring -- добавить в массив хотя бы на один новый хост больше, чем количество сегментов на хост. Для обеспечения равномерного распределения количество отдельных хостов должно быть больше, чем количество инстансов сегмента на хост; + Grouped Mirroring -- добавить в массив не менее двух новых хостов, чтобы зеркала для первого хоста могли находиться на втором, а зеркала для второго хоста -- на первом. По умолчанию новые хосты инициализируются с таким же количеством основных сегментов, что и у существующих хостов. При этом есть возможность увеличить количество сегментов на хост или добавить новые сегмент-сервера к существующим хостам. Например, если существующие хосты в настоящее время имеют два сегмента на хост, можно использовать **gpexpand** для инициализации двух дополнительных сегментов на существующие хосты и в итоге получить четыре сегмента и по четыре новых сегмент-сервера на новых хостах. Интерактивный процесс создания настроечного файла для расширения запрашивает данную опцию, директории новых сегмент-серверов можно вручную указать в файле конфигурации (`Создание настроечного файла для расширения кластера`_). При инициализации утилита **gpexpand** создает схему расширения. При этом если база данных не задана (**gpexpand -D**), то схема создается в БД, указанной в переменной среде *PGDATABASE*. Схема расширения хранит метаданные для каждой таблицы в системе, поэтому ее статус можно отслеживать на протяжении всего процесса. Схема состоит из двух таблиц и представления для отслеживания хода выполнения операции расширения: + *gpexpand.status* + *gpexpand.status_detail* + *gpexpand.expansion_progress* Процессом расширения можно управлять в *gpexpand.status_detail*. Например, удаление записи из этой таблицы не позволяет системе развернуть таблицу по новым сегмент-серверам. Также можно задать порядок перераспределения таблиц путем назначения им ранга. Планирование таблицы перераспределения **************************************** Перераспределение таблицы выполняется во время работы системы, и во многих случаях оно осуществляется за одну сессию **gpexpand** в период низкого использования. Но для крупных систем может потребоваться несколько сеансов работы утилиты и настройка порядка перераспределения таблицы для минимизации влияния на производительность. .. important:: Для перераспределения таблиц на хостах сегмента должно быть достаточно места на диске для временного хранения копии самой большой таблицы. Все таблицы недоступны для операций чтения и записи во время перераспределения Эффективность перераспределения таблицы зависит от ее размера, типа хранилища и структуры партицирования. Перераспределение любой таблицы с помощью **gpexpand** занимает столько же времени, сколько и операция *CREATE TABLE AS SELECT*. В случае перераспределения таблицы фактов терабайтного масштаба утилита расширения может использовать большую часть доступных системных ресурсов, что может повлиять на производительность запросов или другие рабочие нагрузки базы данных. При наличии большого объема свободного места на диске есть возможность как можно скорее сосредоточиться на восстановлении оптимальной производительности запроса, перераспределив сначала самые важные таблицы. Для этого необходимо им назначить наивысший рейтинг и запланировать операции перераспределения на период низкого использования системы. После чего запустить процесс перераспределения таблицы. Если существующие узлы имеют ограниченное дисковое пространство, то следует сначала перераспределить меньшие таблицы (например, таблицы измерений) с целью освобождения места на диске для хранения копии самой большой таблицы. Доступное дисковое пространство на исходных сегментах увеличивается по мере перераспределения каждой таблицы по расширенному массиву. Утилита **gpexpand** перераспределяет таблицы типа append-optimized и compressed append-optimized с отличной скоростью от перераспределения таблицы heap. Необходимый для сжатия и распаковки данных объем процессора имеет тенденцию увеличивать влияние на производительность системы. Поэтому для таблиц аналогичных по размеру и данным можно найти общие различия, например: + Несжатые таблицы типа append-optimized расширяются на *10%* быстрее, чем heap таблицы. + zlib-сжатые таблицы типа append-optimized расширяются значительно медленнее, чем аналогичные несжатые (примерно на *80%*). + Системы с сжатием данных, такие как **ZFS**/**LZJB**, требуют больше времени для перераспределения. В период времени между инициализацией новых сегмент-серверов и успешным перераспределением таблицы ограничения первичного ключа не могут быть применены. Повторяющиеся данные, добавленные в таблицы в течение этого периода, не позволяют утилите расширения перераспределить затронутые таблицы. После перераспределения таблицы ограничение первичного ключа снова применяется надлежащим образом. В случае если процесс расширения нарушает ограничения, утилита регистрирует ошибки и отображает предупреждения. Для исправления нарушений ограничений следует выполнить одно из следующих действий: + Очистить повторяющиеся данные в столбцах первичного ключа и повторно запустить **gpexpand**; + Удалить ограничения первичного ключа и повторно запустить **gpexpand**. Для перераспределения таблицы, содержащей столбцы пользовательских типов данных на удаление, необходимо сначала заново создать таблицу, используя *CREATE TABLE AS SELECT*. А после того, как процесс исключит столбцы, перераспределить таблицу с помощью **gpexpand**. Поскольку утилита расширения может обрабатывать каждую отдельную партицию в большой таблице, эффективная конструкция партиций снижает влияние перераспределения таблиц на производительность. Политика случайного распределения применяется только к дочерним таблицам партицированной таблицы, и блокировка операций чтения и записи единовременно применяется для перераспределения только к одной дочерней таблице. Системы с интенсивным индексированием имеют значительно более медленные темпы перераспределения таблиц, так как утилита **gpexpand** повторно индексирует каждую таблицу после ее перераспределения. Подготовка и добавление узлов ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Важно убедиться, что новые узлы готовы к интеграции в существующую систему **ADB**. Для подготовки новых системных узлов к расширению следует установить двоичные файлы программного обеспечения базы данных **ADB**, заменить необходимые SSH-ключи и выполнить тесты на производительность. Тесты необходимо выполнять сначала только на новых узлах, а затем на всех. Тесты на всех узлах важно проводить с системой в автономном режиме, чтобы активность пользователя не искажала результаты. Как правило, тесты на производительность следует выполнять, когда администратор изменяет сеть узлов или другие особые условия в системе. Например, если система работает на двух сетевых кластерах, тесты выполняются на каждом из них. Обмен ключами SSH ******************* Новые узлы должны обмениваться ключами SSH с существующими узлами, чтобы административные утилиты **ADB** могли подключаться ко всем сегментам без запроса пароля. Процесс обмена ключами необходимо выполнить дважды -- сначала от *root* (для удобства администрирования), а затем в качестве пользователя *gpadmin* (для служебных программ управления). Следует выполнить следующие задачи по порядку: + Обмен ключами SSH от root; + Создание пользователя gpadmin; + Обмен ключами SSH в качестве пользователя gpadmin. Для обмена ключами SSH от пользователя *root* необходимо выполнить следующие действия: 1. Создать файл *host file* с существующими именами хостов в массиве и отдельный файл с именами новых хостов. Для существующих узлов можно использовать файл настройки SSH-ключей в системе. В файлах должны быть перечислены все хосты (мастер, резервный мастер и сегмент-сервер) с одним именем в строке и без дополнительных строк или пробелов. Обмен SSH-ключами при конфигурации с несколькими NIC использует настроенные имена хостов. В примере *mdw* сконфигурирован с одним NIC, а *sdw1*, *sdw2* и *sdw3* сконфигурированы с четырьмя сетевыми адаптерами: :: mdw sdw1-1 sdw1-2 sdw1-3 sdw1-4 sdw2-1 sdw2-2 sdw2-3 sdw2-4 sdw3-1 sdw3-2 sdw3-3 sdw3-4 2. Войти в систему как *root* на master-хосте и отправить файл *greenplum_path.sh* из инсталяции **ADB**: :: $ su - # source /usr/local/greenplum-db/greenplum_path.sh 3. Запустить утилиту **gpssh-exkeys**, ссылающуюся на файл списка хостов. Например: :: # gpssh-exkeys -e /home/gpadmin/existing_hosts_file -x /home/gpadmin/new_hosts_file 4. Утилита **gpssh-exkeys** проверяет удаленные хосты и выполняет обмен ключами между всеми узлами. При появлении запроса ввести пароль пользователя *root*. :: ***Enter password for root@hostname: Для создания пользователя *gpadmin* необходимо выполнить следующие действия: 1. Применить утилиту **gpssh** для создания пользователя *gpadmin* на всех хостах нового сегмент-сервера, используя созданный для обмена ключами список новых хостов. Например: :: # gpssh -f new_hosts_file '/usr/sbin/useradd gpadmin -d /home/gpadmin -s /bin/bash' 2. Задать пароль для нового пользователя *gpadmin*. В **Linux** это можно сделать на всех сегментах одновременно с помощью утилиты **gpssh**. Например: :: # gpssh -f new_hosts_file 'echo gpadmin_password | passwd gpadmin --stdin' 3. Путем поиска домашней директории убедиться, что пользователь *gpadmin* создан: :: # gpssh -f new_hosts_file ls -l /home Для обмена ключами SSH в качестве пользователя *gpadmin* необходимо выполнить следующие действия: 1. Войти в систему как *gpadmin* и запустить утилиту **gpssh-exkeys**, ссылаясь на файл списка хостов: :: # gpssh-exkeys -e /home/gpadmin/existing_hosts_file -x /home/gpadmin/new_hosts_file 2. Утилита **gpssh-exkeys** проверяет удаленные хосты и выполняет обмен ключами между всеми узлами. При появлении запроса ввести пароль пользователя *gpadmin*. :: ***Enter password for gpadmin@hostname: Проверка настроек ОС ********************* Утилита **gpcheck** проверяет, что все новые хосты имеют правильные настройки ОС для запуска программного обеспечения базы данных **ADB**. Для запуска утилиты необходимо: 1. Войти на master-хост в качестве пользователя, который в дальнейшем будет запускать систему **ADB** (например, *gpadmin*): :: $ su - gpadmin 2. Запустить утилиту **gpcheck** с помощью файла хоста для новых узлов. Например: :: $ gpcheck -f new_hosts_file Проверка дискового ввода-вывода и пропускной способности памяти ***************************************************************** Для проверки дискового ввода-вывода и пропускной способности памяти системы **ADB** используется утилита **gpcheckperf**: 1. Запустить утилиту **gpcheckperf**, используя файл хоста для новых узлов. Для указания файловых систем, которые следует протестировать на каждом хосте, применяется параметр *-d*. При этом должен быть доступ на запись к данным каталогам. :: $ gpcheckperf -f new_hosts_file -d /data1 -d /data2 -v 2. Утилита может занять много времени для выполнения тестов, так как она копирует очень большие файлы между хостами. При завершении процесса отображаются итоговые результаты тестов *Disk Write*, *Disk Read* и *Stream*. Для сети, разделенной на подсети, необходимо повторить процедуру с отдельным файлом хоста для каждой подсети. Добавление новых сегмент-серверов ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Для инициализации новых сегмент-серверов, создания схемы расширения и установки общесистемной политики случайного распределения используется утилита **gpexpand**. При первом запуске утилиты **gpexpand** с настроечным файлом она создает схему расширения и устанавливает политику распределения для всех таблиц в *DISTRIBUTED RANDOMLY*. Затем при последующем запуске **gpexpand** определяет, была ли создана схема расширения и, если да, выполняет перераспределение таблиц. + `Создание настроечного файла для расширения кластера`_ + `Запуск gpexpand для инициализации новых сегмент-серверов`_ + `Откат неудачной установки`_ Создание настроечного файла для расширения кластера ***************************************************** Утилите **gpexpand** требуется настроечный файл с информацией о новых сегментах и хостах. При запуске **gpexpand** без указания настроечного файла утилита отображает интерактивное интервью, которое собирает необходимую информацию и автоматически создает настроечный файл. В таком случае можно указать файл со списком хостов расширения. Создание настроечного файла в интерактивном режиме ```````````````````````````````````````````````````` Для создания настроечного файла в интерактивном режиме необходимо перед запуском **gpexpand** убедиться, что известно: + Количество новых хостов (или файл *hosts*); + Новые имена хостов (или файл *hosts*); + Стратегия зеркалирования, используемая в существующих хостах (если имеется); + Количество сегмент-серверов для добавления на хост (если имеются). Утилита автоматически создает настроечный файл на основе указанной информации, *dbid*, *content ID* и каталога данных, хранящихся в *gp_segment_configuration*, и сохраняет файл в текущем каталоге. Создание настроечного файла в интерактивном режиме: 1. Выполнить вход на мастер хост базы данных пользователем, который будет запускать **ADB**, например, *gpadmin*. 2. Запустить **gpexpand**. Утилита отображает сообщение о том, как подготовиться к операции расширения, и предлагает выйти или продолжить. При необходимости указать файл *hosts*, содержащий перечень новых хостов, с помощью опции *-f*. Например: :: $ gpexpand -f /home/gpadmin/new_hosts_file 3. Для продолжения в командной строке выбрать *Y*. 4. Если на втором шаге файл *hosts* не был указан, то необходимо ввести список имен хостов новых расширений, разделяя их запятыми и не включая имена дополнительных хостов. Например: :: > sdw4, sdw5, sdw6, sdw7 Для добавления логических сегментов только на существующих серверах (без добавления новых серверов) ввести пустую строку в запрос, не указывая *localhost* и имени действующего узла. 5. Ввести стратегию зеркалирования, используемую в кластере (если имеется), с параметром *spread*, *grouped* или *none*. Значение по умолчанию *spread*. И убедиться, что имеется достаточно хостов для выбранной стратегии. 6. Ввести количество добавляемых основных сегментов (если они есть). По умолчанию новые хосты инициализируются с таким же количеством основных сегментов, что и существующие хосты. Можно увеличить количество сегментов на каждом хосте. Указанное число будет количеством дополнительных сегментов, инициализированных на всех хостах. Например, если существующие хосты в настоящее время имеют по два сегмента каждый, ввод значения *2* инициализирует еще два сегмента на существующих хостах и четыре сегмента на новых хостах. 7. При добавлении новых основных сегментов ввести новый корневой каталог первичных данных для новых сегментов. Не указывать фактическое имя каталога данных, оно создается автоматически с помощью **gpexpand** на основе существующих имен каталога данных. Например, если существующие каталоги данных выглядят следующим образом: :: /gpdata/primary/gp0 /gpdata/primary/gp1 тогда, чтобы указать каталоги данных для двух новых основных сегментов, ввести следующее (по одному в каждом запросе): :: /gpdata/primary /gpdata/primary При запуске инициализации утилита создает новые каталоги *gp2* и *gp3* в каталоге */gpdata/primary*. 8. При добавлении новых зеркальных сегментов ввести новый корневой каталог зеркальных данных для новых сегментов. Не указывать имя каталога данных, он создается автоматически с помощью **gpexpand** на основе существующих имен каталога данных. Например, если существующие каталоги данных выглядят следующим образом: :: /gpdata/mirror/gp0 /gpdata/mirror/gp1 тогда, чтобы указать каталоги данных для двух новых зеркальных сегментов, ввести следующее (по одному в каждом запросе): :: /gpdata/mirror /gpdata/mirror При запуске инициализации утилита создает новые каталоги *gp2* и *gp3* в каталоге */gpdata/mirror*. Основные и зеркальные каталоги для новых сегмент-серверов должны существовать на хостах, а пользователь, запускающий **gpexpand**, должен иметь разрешения на создание каталогов в них. После ввода всей необходимой информации утилита генерирует настроечный файл и сохраняет его в текущем каталоге. Например: :: gpexpand_inputfile_yyyymmdd_145134 Формат настроечного файла расширения ````````````````````````````````````` Следует использовать интерактивный режим для создания собственного настроечного файла, если сценарий расширения не имеет нетипичных потребностей. Формат настроечных файлов расширения: :: hostname:address:port:fselocation:dbid:content:preferred_role:replication_port Например: :: sdw5:sdw5-1:50011:/gpdata/primary/gp9:11:9:p:53011 sdw5:sdw5-2:50012:/gpdata/primary/gp10:12:10:p:53011 sdw5:sdw5-2:60011:/gpdata/mirror/gp9:13:9:m:63011 sdw5:sdw5-1:60012:/gpdata/mirror/gp10:14:10:m:63011 Для каждого нового сегмент-сервера требуется формат настроечного файла расширения с параметрами, приведенными в таблице. .. csv-table:: Данные для файла конфигурации расширения :header: "Параметр", "Допустимые значения", "Описание" :widths: 30, 30, 40 "hostname", "Hostname", "Имя хоста для хоста сегмент-сервера" "port", "Номер порта", "Прослушивающий порт базы данных для сегмент-сервера, увеличенный на количество существующих сегментов базового порта" "fselocation", "Имя каталога", "Каталог данных (файловое пространство) для сегмент-сервера в соответствии с системным каталогом *pg_filespace_entry*" "dbid", "Целое число (Integer). Не должен конфликтовать с существующими значениями *dbid*", "Идентификатор базы данных для сегмент-сервера. Вводимые значения должны последовательно увеличиваться из существующих значений *dbid*, указанных в системном каталоге *gp_segment_configuration*. Например, чтобы добавить четыре узла к существующему массиву из десяти сегментов со значениями *dbid 1-10*, перечислить новые значения *dbid 11*, *12*, *13* и *14*" "content", "Целое число (Integer). Не должен конфликтовать с существующими значениями *content*", "content ID сегмент-сервера. Основной сегмент и его зеркало должны иметь один и тот же идентификатор *content*, последовательно увеличиваемый от существующих значений" "preferred_role", "*p* | *m*", "Определяет, является сегмент основным или зеркальным: *p* -- основной, *m* -- зеркальный" "replication_port", "Номер порта", "Порт репликации файлов для сегмент-сервера, увеличенный на существующий базовый номер сегмента *replication_port*" Запуск gpexpand для инициализации новых сегмент-серверов ********************************************************* После создания настроечного файла необходимо запустить **gpexpand**. Утилита автоматически останавливает инициализацию сегмент-серверов базы данных **ADB** и перезапускает систему после завершения процесса. Запуск **gpexpand** с настроечным файлом: 1. Выполнить вход на мастер хост базы данных пользователем, который будет запускать **ADB**, например, *gpadmin*. 2. Запустить утилиту **gpexpand**, указав настроечный файл с опцией *-i*. Для указания базы данных, в которой будет создана схема расширения, использовать *-D*. Например: :: $ gpexpand -i input_file -D database1 Утилита определяет наличие схемы расширения для кластера **ADB**. Если схема существует, необходимо удалить ее с помощью опции *-c* перед началом новой операции расширения (`Удаление временной схемы расширения`_). 3. Утилита выводит сообщение об успешном завершении инициализации новых сегмент-серверов и создании схемы расширения и завершает работу. После завершения процесса инициализации можно подключиться к **ADB** и увидеть схему расширения. Она находится в базе данных, указанной при помощи опции *-D* или переменной среды *PGDATABASE*. Откат неудачной установки *************************** Откат операции настройки расширения возможен только в случае сбоя операции. В случае если на этапе инициализации происходит сбой расширения, а база данных не работает, необходимо сначала перезапустить базу данных в режиме master-only, выполнив команду *gpstart -m*. Откат неудачного расширения выполняется с помощью следующей команды с указанием базы данных, содержащей схему расширения: :command:`gpexpand --rollback -D database_name` Перераспределение таблиц ^^^^^^^^^^^^^^^^^^^^^^^^^^ Перераспределение таблиц проводится для балансировки существующих данных по недавно расширенному кластеру. После создания схемы расширения можно привести базу данных **ADB** в онлайн и перераспределить таблицы по всему массиву с помощью **gpexpand**. Рекомендуется запускать утилиту в период низкой нагрузки на базу, когда использование центрального процессора и блокировки таблиц имеют минимальное влияние на операции в кластере. При этом рекомендуется ранжировать таблицы для первоочередного перераспределения крупнейших и наиболее важных элементов. .. important:: При перераспределении данных ADB должна работать в продуктивном режиме. Она не должна быть ограничена или находиться в режиме master. Опции *-R* или *-m* команды *gpstart* не могут быть указаны для запуска базы данных В процессе перераспределения таблиц любые новые созданные таблицы или секции распределяются по всем сегментам точно так же, как и при нормальных условиях работы. Запросы могут обращаться ко всем сегментам до того момента, как соответствующие данные будут перераспределены в таблицы в новых сегмент-серверах. Во время перераспределения таблица или раздел блокируются и недоступны для операций чтения и записи. По завершению перераспределения возможность операций возобновляется. + `Ранжирование таблиц для перераспределения`_ + `Перераспределение таблиц с помощью gpexpand`_ + `Мониторинг перераспределения таблиц`_ .. _expand_ranking_tables: Ранжирование таблиц для перераспределения ******************************************* Порядком перераспределения таблиц можно управлять. Для этого необходимо скорректировать значения рангов таблиц в схеме расширения для определения приоритетов часто используемых таблиц и минимизации влияния на производительность. Доступное свободное место на диске может сказываться на ранжировании таблиц. Для ранжирования таблиц с целью их последующего перераспределения необходимо подключиться к базе данных **ADB** с помощью **psql** или другого поддерживаемого клиента и обновить файл *gpexpand.status_detail* с помощью следующих команд: :: => UPDATE gpexpand.status_detail SET rank=10; => UPDATE gpexpand.status_detail SET rank=1 WHERE fq_name = 'public.lineitem'; => UPDATE gpexpand.status_detail SET rank=2 WHERE fq_name = 'public.orders'; В примере команды понижают приоритет всех таблиц до *10*, а затем присваивают ранг *1* для *lineitem* и ранг *2* для *orders*. В результате сначала перераспределяется *lineitem*, затем *orders*, а далее все другие таблицы из файла *gpexpand.status_detail*. Для исключения таблицы из перераспределения следует удалить ее из файла *gpexpand.status_detail*. Перераспределение таблиц с помощью gpexpand ********************************************* Перераспределение таблиц с помощью утилиты **gpexpand** осуществляется следующим образом: 1. Выполнить вход на мастер хост базы данных пользователем, который будет запускать **ADB**, например, *gpadmin*. 2. Запустить утилиту **gpexpand**. Можно использовать опцию *-d* или *-e* для определения периода времени сеанса расширения. Например, для запуска утилиты на срок до *60* часов: :: $ gpexpand -d 60:00:00 Утилита перераспределяет таблицы до тех пор, пока последняя таблица в схеме не завершится, или пока не будет достигнут период указанной длительности (или не будет достигнуто установленное время окончания). Утилита **gpexpand** обновляет статус и время сессии в файле *gpexpand.status* при запуске и завершении перераспределения. Мониторинг перераспределения таблиц ************************************* Во время процесса перераспределения таблицы можно запросить схему расширения. В представлении *gpexpand.expansion_progress* содержится текущая сводка хода выполнения, включая предполагаемую скорость перераспределения таблицы и расчетное время до завершения операции. Для информации о статусе таблицы необходимо запросить *gpexpand.status_detail*. После завершения перераспределения первой таблицы *gpexpand.expansion_progress* выполняет предварительный подсчет и обновляет оценку по скорости перераспределения всех таблиц. Расчеты перезапускаются каждый раз при инициализации сеанса перераспределения таблицы с помощью **gpexpand**. Для мониторинга прогресса необходимо подключиться к базе данных **ADB** с помощью **psql** или другого поддерживаемого клиента и выполнить запрос *gpexpand.expansion_progress* с помощью следующей команды: :: =# SELECT * FROM gpexpand.expansion_progress; name | value ------------------------------+----------------------- Bytes Left | 5534842880 Bytes Done | 142475264 Estimated Expansion Rate | 680.75667095996092 MB/s Estimated Time to Completion | 00:01:01.008047 Tables Expanded | 4 Tables Left | 4 (6 rows) В таблице *gpexpand.status_detail* хранится информация о каждой таблице в схеме: статусы, время последнего обновления и дополнительные сведения. Для просмотра статуса таблицы необходимо подключиться к базе данных **ADB** с помощью **psql** или другого поддерживаемого клиента и выполнить запрос *gpexpand.status_detail*: :: => SELECT status, expansion_started, source_bytes FROM gpexpand.status_detail WHERE fq_name = 'public.sales'; status | expansion_started | source_bytes -----------+----------------------------+-------------- COMPLETED | 2017-02-20 10:54:10.043869 | 4929748992 (1 row) Удаление временной схемы расширения ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ .. important:: Для выполнения очередной операции расширения в системе ADB сначала необходимо удалить существующую схему расширения После завершения и проверки операции расширения схему расширения можно безопасно удалить. Для этого необходимо выполнить следующий порядок действий: 1. Выполнить вход на мастер хост базы данных пользователем, который будет запускать **ADB**, например, *gpadmin*. 2. Запустить утилиту **gpexpand** с параметром *-c*. Например: :: $ gpexpand -c $ При этом в некоторых системах требуется дважды нажать клавишу *Enter*. Расширение кластера средствами ADCM ------------------------------------- *Доступно с версии 5.19.0_arenadata4_b2* Если кластер **ADB** разворачивается с помощью **ADCM**, часть действий по расширению кластера выполняется автоматически. После выполнения планирования нового аппаратного обеспечения необходимо добавить записи для новых хостов в выбранный кластер в интерфейсе **ADCM**, используя кнопку *Add hosts* на вкладке "Hosts". Кроме того, необходимо выполнить инициализацию каждого хоста, если того требует провайдер хостов. Когда хосты будут доступны для подключения по ssh для менеджера кластеров, необходимо запустить действие *Expand* кластера. В появившемся диалоге (:numref:`Рис.%s `) необходимо указать следующие параметры: * *Reboot new servers after installation* -- возможна ли перезагрузка серверов, на которые добавляются новые компоненты. Перезагрузка требуется для применения значения некоторых параметров, изменяемых в процессе установки. Сервера будет необходимо перезагрузить позднее вручную, если это невозможно сделать в процессе расширения; * *Additional primary segments count* -- количество сегментов, которые необходимо добавить на хосты в кластере. Например, если в исходной конфигурации указано два сегмента на хост и в этом поле задано два дополнительных сегмента, в результате на уже существующие в кластере хосты будет добавлено по два сегмента, на новые -- четыре. Если увеличение количества сегментов не требуется, оставьте значение по умолчанию -- *0*. .. _img_70: .. figure:: ../install/adcm/images/img_70.png :align: center Параметры расширения кластера Для перехода к следующей странице конфигурации нажать кнопку *Next* и распределить компонент *ADB Segment* сервиса *ADB* по добавляемым хостам (:numref:`Рис.%s `). Если используются сервисы *PXF*, *Chrony*, *Monitoring Clinets*, их компоненты также необходимо разместить на добавляемых хостах для корректного функционирования. Затем необходимо запустить расширение кластера кнопкой *Run*. .. _img_71: .. figure:: ../install/adcm/images/img_71.png :align: center Распределение компонентов сервиса *ADB* по новым хостам .. important:: В процессе расширения кластера новые хосты инициализируются в соответствии с настройками сервиса ADB аналогично уже существующим хостам. Если при создании кластера запрашивается монтирование блочных устройств для создания каталогов с данными, на хостах должны присутствовать дисковые устройства с такими же именами На первом шаге между новыми узлами и уже существующими производится обмен ключами ssh, на добавленные хосты устанавливаются необходимые пакеты и производится их настройка. Затем генерируется схема для расширения кластера в зависимости от количества добавляемых хостов и использования зеркалирования. Если количество новых хостов в кластере больше числа сегментов на хост в используемой конфигурации, применяется *spread*-зеркалирование, иначе -- *group*. На основе созданного файла схемы производится подготовка кластера к расширению. В случае успешного завершения подготовки, кластер переводится в состояние *expanding*, и возврат предыдущей конфигурации становится невозможен. На этом этапе возможна настройка порядка перераспределения таблиц, как указано в разделе :ref:`expand_ranking_tables`. В состоянии *expanding* для кластера становится доступно действие *Redistribute*, в процессе выполнения которого производится перераспределение таблиц. Для действия необходимо указать длительность сеанса в формате *ЧЧ:ММ:СС*. В случае если перераспределение успешно завершается до истечения указанного времени, схема расширения очищается и кластер переводится в состоянии *running*. Иначе становится доступен повторный запуск действия *Redistribute* для продолжения прерванного процесса. Добавление и удаление резервного мастера ------------------------------------------- *Доступно с версии 5.19.0_arenadata4_b2* Для добавления или удаления резервного мастера предназначено действие *Init Standby Master* кластера *ADB*. Аналогично процессу расширения кластера необходимо указать, перезагружать ли добавляемый в кластер хост в процессе инициализации. Затем необходимо разместить компонент резервного мастера на хосте для его инициализации или убрать для удаления. Для запуска действия необходимо нажать кнопку *Run*. Активация Standby Master ------------------------- *Доступно с версии 6.15.0_arenadata16* Для переключения на резервный мастер предназначено действие *Activate Standby* кластера *ADB*. .. important:: Активация резервного мастера возможна только при неработающем мастере .. important:: Для переключения мастера по желанию (не во время сбоя) необходимо сначала остановить сервис *ADB* Доступны следующие опции: * *force activate* -- для принудительного переключения, когда хост действующего мастера доступен, но процесс мастера внутри операционной системы остановлен; * *run analyze* -- для запуска analyze после переключения на всех базах кроме ``template0``, ``template1`` и ``postgres``. Для запуска действия необходимо нажать *Run*. После переключения мастера на резервный мастер старый мастер перестает участвовать в работе кластера *ADB*. При этом резервного мастера больше нет, так как он стал основным. Для создания резервного мастера необходимо воспользоваться *Init Standby Master*. После включения хоста старого мастера (или сразу после переключения, если хост остается доступен) на нем необходимо: * удалить задачи cron из под администратора ADB (gpadmin по умолчанию) для того, чтобы: * не было попыток обращений к незапущенному процессу устаревшего мастера; * не отсылать ложные метрики в мониторинг; * переименовать (или удалить) каталог мастера (*/data1/master* по умолчанию) для того, чтобы: * случайно не запустить устаревший мастер; * иметь возможность расположить на этом хосте новый резервный мастер. Управление сервисом *ADCC* --------------------------- Для установленного сервиса *ADCC* доступны следующие действия: * *Uninstall* -- удалить компоненты *ADCC* из кластера *ADB*. Для удаления необходимо установить в диалоговом окне флаг *Erase data*. Позволяет удалить с файловой системы логи и исторические данные, хранящиеся в базе данных *ADCC*; * *Start* -- запустить web-сервер *ADCC*; * *Stop* -- остановить web-сервер *ADCC*; * *Reconfigure & Restart* -- сгенерировать конфигурационные файлы и перезапустить компоненты *ADCC*. Действие необходимо выполнить для применения изменений, внесенных в конфигурацию сервиса в интерфейсе *ADCM*. Управление сервисом *Monitoring Clients* --------------------------- Для не установленного сервиса *Monitoring Clients* доступны следующие действия: * *Install* -- установить *Monitoring Clients* на кластер *ADB*. Перед установкой необходимо импортировать адрес graphite и grafana в меню кластера *ADB* разел *Import*; * *Delete* -- удалить *Monitoring Clients* из кластера *ADB*, без установки; Для установленного сервиса *Monitoring Clients* доступны следующие действия: * *Uninstall* -- удалить сервис *Monitoring Clients* из кластера *ADB*; * *Reinstall* -- переустановить сервис *Monitoring Clients* на кластере *ADB*;