Привет.
Хочу поделится впечатлениями о том, как Vertica себя чувствует при проведении технических работ по замене или добавлению оборудования.
Задача 1:
Заменить один сервер работающий в кластере Vertica на другой (новый сервер).
Решение:
Много возиться нам не пришлось. На новый сервер поставили Линукс, проверили, что все пакеты установлены, которые Vertica в документации перечисляет как обязательные для работы, запустили утилиту Vertica updateVertica, указали ей новый сервер, чтобы она его прописала как свободный для размещения хост - да и все. Запустили GUI AdminTool Vertica и остановили заменяемый сервер. В кластере стало на один сервер меньше, но кластер продолжил работу, из пользователей никто этого не заметил. Там же в GUI указали, что остановленный сервер заменить на новый из доступных хостов. Vertica самостоятельно установила на него свой дистрибутив, проверила настройки Linux, подправила где что не хватало и запустила новый сервер на работу в кластере. Сервер инициализировался, вошел в статус RECOVERY, синхронизировался с другими серверами кластера, закачав на себя все данные, которые хранил его старый предшественник и включился в работу. В итоге Vertica провела замену сервера за 12 часов, переместив на него порядка 2.5 Тб данных, занимаемых на файловой системе.
Задача 2:
Добавить в кластер два новых сервера.
Решение:
Как и в первой задаче установили Linux, через утилиту добавили новые сервера как хосты. Далее в утилите добавили ставшими хостами сервера как ноды кластера. После добавления утилита предлагает на выбор автоматически сделать балансировку данных для равномерного распределения данных между новым количеством нод в кластере, создать SQL скрипт проведения балансировки для его запуска вручную или самостоятельно запустить балансировку. Я выбрал самостоятельно. Сервера добавились в кластер, включились в работу и стали принимать и обрабатывать запросы. Так как на них пока попадали только новые загружаемые данные, при выполнении запросов к данным, загруженным до добавления этих серверов, они не могли оказать помощь и всю работу с ними продолжали выполнять только сервера, уже стоявшие в кластере. Когда я был морально и по времени готов, запустить самостоятельно балансировку оказалось делом не сложным, было достаточно просто выполнить запрос: SELECT START_REBALANCE_CLASTER(). Процесс запустился в фоновом режиме и перебирая по очереди таблицы стал перемещать данные уже учитывая распределение по новому количеству нод в кластере. Для таблиц, которые создавались как несегментируемые, Vertica просто создавала их зеркальную копию на новых серверах. Для сегментируемых таблиц заново по каждой записи рассчитывался кэш ключа сегментирования и они перераспределялись по новой карте размещения на кластере на нужные ноды. Весь процесс балансировки занял порядка 1.5 суток, было перераспределено порядка 7.5 Тб данных, занимаемых на файловой системе.
Обе успешно выполненные задачи еще раз доказали сильные стороны Vertica - это легкое, практически нулевое администрирование с высоким уровнем автоматизации сложных действий и высокая доступность сервера при любых ситуациях. Будь то большие нагрузки, сбой аппаратной части или технические работы Vertica продолжает работать и обслуживать пользователей без требования проведения каких либо регламентных остановок.
Вот такие чудеса :)
Хочу поделится впечатлениями о том, как Vertica себя чувствует при проведении технических работ по замене или добавлению оборудования.
Задача 1:
Заменить один сервер работающий в кластере Vertica на другой (новый сервер).
Решение:
Много возиться нам не пришлось. На новый сервер поставили Линукс, проверили, что все пакеты установлены, которые Vertica в документации перечисляет как обязательные для работы, запустили утилиту Vertica updateVertica, указали ей новый сервер, чтобы она его прописала как свободный для размещения хост - да и все. Запустили GUI AdminTool Vertica и остановили заменяемый сервер. В кластере стало на один сервер меньше, но кластер продолжил работу, из пользователей никто этого не заметил. Там же в GUI указали, что остановленный сервер заменить на новый из доступных хостов. Vertica самостоятельно установила на него свой дистрибутив, проверила настройки Linux, подправила где что не хватало и запустила новый сервер на работу в кластере. Сервер инициализировался, вошел в статус RECOVERY, синхронизировался с другими серверами кластера, закачав на себя все данные, которые хранил его старый предшественник и включился в работу. В итоге Vertica провела замену сервера за 12 часов, переместив на него порядка 2.5 Тб данных, занимаемых на файловой системе.
Задача 2:
Добавить в кластер два новых сервера.
Решение:
Как и в первой задаче установили Linux, через утилиту добавили новые сервера как хосты. Далее в утилите добавили ставшими хостами сервера как ноды кластера. После добавления утилита предлагает на выбор автоматически сделать балансировку данных для равномерного распределения данных между новым количеством нод в кластере, создать SQL скрипт проведения балансировки для его запуска вручную или самостоятельно запустить балансировку. Я выбрал самостоятельно. Сервера добавились в кластер, включились в работу и стали принимать и обрабатывать запросы. Так как на них пока попадали только новые загружаемые данные, при выполнении запросов к данным, загруженным до добавления этих серверов, они не могли оказать помощь и всю работу с ними продолжали выполнять только сервера, уже стоявшие в кластере. Когда я был морально и по времени готов, запустить самостоятельно балансировку оказалось делом не сложным, было достаточно просто выполнить запрос: SELECT START_REBALANCE_CLASTER(). Процесс запустился в фоновом режиме и перебирая по очереди таблицы стал перемещать данные уже учитывая распределение по новому количеству нод в кластере. Для таблиц, которые создавались как несегментируемые, Vertica просто создавала их зеркальную копию на новых серверах. Для сегментируемых таблиц заново по каждой записи рассчитывался кэш ключа сегментирования и они перераспределялись по новой карте размещения на кластере на нужные ноды. Весь процесс балансировки занял порядка 1.5 суток, было перераспределено порядка 7.5 Тб данных, занимаемых на файловой системе.
Обе успешно выполненные задачи еще раз доказали сильные стороны Vertica - это легкое, практически нулевое администрирование с высоким уровнем автоматизации сложных действий и высокая доступность сервера при любых ситуациях. Будь то большие нагрузки, сбой аппаратной части или технические работы Vertica продолжает работать и обслуживать пользователей без требования проведения каких либо регламентных остановок.
Вот такие чудеса :)
Комментариев нет:
Отправить комментарий