Привет.
Недавно в боевых условиях я получил полноценный краш тест сервера Vertica.
Начиналось все хорошо: для работающих серверов докупили и получили новые планки RAM, расширяющие объем оперативной памяти в два раза. Это для нас уже было критичным, так как изначально на серверах стояло не так много памяти. Операция была простой - остановить кластер, всем серверам поменять планки памяти на новые и запустить Vertica обратно. Однако, получилось не все так просто, как планировали: один из серверов после перезапуска и старта всего кластера Vertica, проработав 20 минут выдав множество сообщений в лог по аппаратным ошибкам и перестал работать. Оставшиеся сервера взяли на себя его объем работ и таким образом хранилище данных продолжило оставаться доступным.
Несмотря на то, что один из серверов теперь работал за себя и своего упавшего соседа, за счет увеличения оперативной памяти, скорость работы кластера не снизилась. Это позволило нам на сутки не подключать сбойный сервер и провести полный цикл тестирования его аппаратной части и инсталлировать последние обновления.
К сожалению, "убедить" сервер работать с новой памятью не удалось и пришлось его откатить на старые планки. После запуска со старой памятью, сервер подключился к кластеру, вошел в режим Recovery, провел полную синхронизацию данных с тем, что случилось за сутки, пока на нем не работала Vertica и через час успешно стартовал в рабочем режиме, начав принимать и обрабатывать запросы. С учетом того, что за сутки у нас пишется огромный объем информации , считаю это очень хорошим показателем восстановления сервера после краш сбоя.
Новые сервера кстати продолжили работу на новом объеме памяти, хотя раньше в Vertica утверждалось, что сервер при работе будет брать минимальные память и кол-во процессоров из рабочих серверов кластера, если они отличаются по конфигурации. Видимо за прошедший год Vertica здорово шагнула вперед и сняла это ограничение. Это означает, что для апгрейта серверов нам на самом деле даже не нужно было останавливать работу всей Vertica - было достаточно по очереди останавливать один сервер кластера, апгрейтить и запускать его обратно.
Так же я просмотрел в документации информацию по замене серверов в кластере на другие. Для замены сбойного сервера будет достаточно с любого рабочего сервера Vertica указать, на какой сервер нужно инсталлировать ПО, это будет автоматически произведено и далее будет достаточно сказать Vertica стартовать этот сервер в кластер. Автоматически при запуске будет развернута база данных на замещающем сервере и переданы на него все данные, которые ранее содержались на его предшественнике. IP адрес и имя в сети замещающего сервера не обязаны быть такими же, как и у сервера, который заменяется. Все это дает мне возможность при дополнении кластера новыми серверами, один из этих серверов указать подключить вместо сервера, который привел к сбою при работе с новой памятью. Его же можно будет отключить от кластера и отправить на полную проверку аппаратной части без каких либо затрат на его замену.
Не знаю, может это у многих MPP серверов есть такие возможности не прерывая работы базы данных заменять и апгрейтить сервера, добавлять новые или удалять с кластера существующие, но насколько легко и просто это сделано в Vertica, без требования остановок на обслуживание или замедления работы, выглядит очень приятно.
Тьфу тьфу, чтобы Vertica и дальше продолжала нас радовать такими же чудесами.
До связи!
Недавно в боевых условиях я получил полноценный краш тест сервера Vertica.
Начиналось все хорошо: для работающих серверов докупили и получили новые планки RAM, расширяющие объем оперативной памяти в два раза. Это для нас уже было критичным, так как изначально на серверах стояло не так много памяти. Операция была простой - остановить кластер, всем серверам поменять планки памяти на новые и запустить Vertica обратно. Однако, получилось не все так просто, как планировали: один из серверов после перезапуска и старта всего кластера Vertica, проработав 20 минут выдав множество сообщений в лог по аппаратным ошибкам и перестал работать. Оставшиеся сервера взяли на себя его объем работ и таким образом хранилище данных продолжило оставаться доступным.
Несмотря на то, что один из серверов теперь работал за себя и своего упавшего соседа, за счет увеличения оперативной памяти, скорость работы кластера не снизилась. Это позволило нам на сутки не подключать сбойный сервер и провести полный цикл тестирования его аппаратной части и инсталлировать последние обновления.
К сожалению, "убедить" сервер работать с новой памятью не удалось и пришлось его откатить на старые планки. После запуска со старой памятью, сервер подключился к кластеру, вошел в режим Recovery, провел полную синхронизацию данных с тем, что случилось за сутки, пока на нем не работала Vertica и через час успешно стартовал в рабочем режиме, начав принимать и обрабатывать запросы. С учетом того, что за сутки у нас пишется огромный объем информации , считаю это очень хорошим показателем восстановления сервера после краш сбоя.
Новые сервера кстати продолжили работу на новом объеме памяти, хотя раньше в Vertica утверждалось, что сервер при работе будет брать минимальные память и кол-во процессоров из рабочих серверов кластера, если они отличаются по конфигурации. Видимо за прошедший год Vertica здорово шагнула вперед и сняла это ограничение. Это означает, что для апгрейта серверов нам на самом деле даже не нужно было останавливать работу всей Vertica - было достаточно по очереди останавливать один сервер кластера, апгрейтить и запускать его обратно.
Так же я просмотрел в документации информацию по замене серверов в кластере на другие. Для замены сбойного сервера будет достаточно с любого рабочего сервера Vertica указать, на какой сервер нужно инсталлировать ПО, это будет автоматически произведено и далее будет достаточно сказать Vertica стартовать этот сервер в кластер. Автоматически при запуске будет развернута база данных на замещающем сервере и переданы на него все данные, которые ранее содержались на его предшественнике. IP адрес и имя в сети замещающего сервера не обязаны быть такими же, как и у сервера, который заменяется. Все это дает мне возможность при дополнении кластера новыми серверами, один из этих серверов указать подключить вместо сервера, который привел к сбою при работе с новой памятью. Его же можно будет отключить от кластера и отправить на полную проверку аппаратной части без каких либо затрат на его замену.
Не знаю, может это у многих MPP серверов есть такие возможности не прерывая работы базы данных заменять и апгрейтить сервера, добавлять новые или удалять с кластера существующие, но насколько легко и просто это сделано в Vertica, без требования остановок на обслуживание или замедления работы, выглядит очень приятно.
Тьфу тьфу, чтобы Vertica и дальше продолжала нас радовать такими же чудесами.
До связи!
Комментариев нет:
Отправить комментарий