Установка Arenadata DB 7.2 на компьютер с небольшим объемом оперативной памяти

в 11:16, , рубрики: arenadata db, mpp-базы

Установка Arenadata DB 7.2 выполняется с помощью Arenadata Cluster Manager (ADCM). Это средство предназначено для разворачивания кластера на большом числе хостов с большим объемом оперативной памяти на каждом из них. А если кластер Arenadata нужен не для производительной работы, а для проведения экспериментов или для разработки/тестирования, можно ли развернуть его на компьютере с небольшим объемом оперативной памяти, например, 32 Гб? Будет ли кластер работать стабильно? Позволит ли он выполнять тяжелые операции? Каково минимальное количество виртуальных машин, на которых можно запустить Arenadata DB 7.2?

Требования к оперативной памяти в документации Arenadata

В соответствии с документацией Arenadata DB, требуются следующие минимальные объемы оперативной памяти для серверов (виртуальных машин):

  • ADCM – 16 Гб,

  • Мастер (координатор) – 16 Гб,

  • Standby (secondary master) – 16 Гб,

  • Хост-сегмент – 32 Гб.

Для экспериментов и разработки желательно иметь хотя бы два хост-сегмента. В сумме получается 112 Гб памяти. Очень много. Столько не каждая материнская плата потянет. Да и «жаба задушит», такой объем памяти – недешевое удовольствие.

Будем пытаться впихнуть Arenadata DB в тот объем памяти, который есть – в 32 Гб.

Неудачные эксперименты по сокращению количества виртуальных машин

Хост ADCM + Мастер + Standby + 2 хост-сегмента = 5 виртуальных машин. Можно ли сократить это количество?

Поскольку ADCM требуется в основном для установки кластера Arenadata DB, то можно попробовать объединить хост ADCM с каким-нибудь другим хостом без потери производительности. Увы, не получилось. В процессе установки кластера выполняется перезагрузка хостов. Если ADCM установлен на одной виртуальной машине с каким-нибудь другим хостом, то после перезагрузки хостов установка прерывается. То есть, перезагружаются мастер, standby и хост-сегменты, а хост ADCM не должен перезагружаться при установке кластера.

При попытке объединить мастер и хост-сегмент на одной виртуальной машине сообщение об ошибке возникает в начале установки кластера.

Исключение сервера standby и зеркальных сегментов из конфигурации кластера

Сервер standby удалось исключить из конфигурации кластера вместе с зеркальными сегментами. Для этого при создании кластера:

1. Установлены следующие параметры:

  • Configuration -> Main -> Use segment mirroring: false

  • Configuration -> Advanced -> Number of segments per host: 2

2. На закладке "Mapping" не указан хост для "Standby".

Итоговая конфигурация кластера показана на рисунке 1.

Рис. 1. Конфигурация кластера

Рис. 1. Конфигурация кластера

Распределение памяти между виртуальными машинами

Первоначально я выбрал такие объемы памяти для виртуальных машин:

  • ADCM – 4 Гб,

  • Мастер – 6 Гб,

  • Сегменты – по 8 Гб.

В процессе экспериментов выяснилось, что мастеру памяти не хватает, пришлось увеличить объем до 8 Гб.

Запрос о конфигурации кластера

После установки кластера запросом была получена информация о его конфигурации:

select * from gp_segment_configuration order by dbid;

dbid

content

role

preferred_role

mode

status

port

hostname

address

datadir

1

-1

p

p

n

u

5432

master

master

/data1/master/gpseg-1

2

0

p

p

n

u

10000

segment-1

segment-1

/data1/primary/gpseg0

3

1

p

p

n

u

10001

segment-1

segment-1

/data1/primary/gpseg1

4

2

p

p

n

u

10000

segment-2

segment-2

/data1/primary/gpseg2

5

3

p

p

n

u

10001

segment-2

segment-2

/data1/primary/gpseg3

Проверка стабильности работы кластера на тяжелых запросах

Проверка работоспособности кластера выполнялась на БД «Авиаперевозки»:

https://postgrespro.ru/education/demodb

Первоначально эти данные были загружены в БД PostgreSQL, а потом перегружены в Arenadata DB с помощью PXF (Platform Extension Framework). Таблицы были распределены (distributed by) по первичным ключам.

Общий объем этой базы 22 млн строк, его вполне хватает для проверки работы кластера.

Тяжелые запросы, например, соединение нескольких больших таблиц, выполнялись на кластере не очень быстро, но стабильно.

Поломка кластера в случае использования 98-100% оперативной памяти компьютера

Если на компьютере при работающем кластере запустить слишком много программ так, что оперативная память будет использована почти на 100%, то кластер Arenadata подвисает. При попытке перезапустить кластер возникает сообщение о сетевой ошибке. Реанимировать кластер не удается.

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

Таким образом, в процессе эксплуатации кластера нужно следить за использованием оперативной памяти. При запущенном кластере не запускать слишком много программ на компьютере.

Выводы

  1. Кластер Arenadata DB 7.2 с двумя хост-сегментами удалось установить на компьютер с 32 Гб оперативной памяти. Кластер работает не очень быстро, но стабильно, успешно выполняет тяжелые запросы.

  2. Чтобы избежать поломки кластера, нельзя использовать 98-100% оперативной памяти компьютера. В процессе эксплуатации кластера я следил за тем, чтобы память не использовалась более 90%.

  3. Минимальное количество виртуальных машин, на которых можно установить Arenadata DB 7.2 с двумя сегмент-хостами – 4. После установки Arenadata DB 7.2 виртуальную машину с ADCM можно больше не запускать, управление кластером выполнять из терминала на мастере. Это позволяет сократить объем оперативной памяти, который требуется для кластера.

Автор: ibshcherbakov

Источник

* - обязательные к заполнению поля


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js