Мы используем куки и предполагаем, что вы согласны, если продолжите пользоваться сайтом
Понимаю и согласен
Close
Заявка на обратный звонок
Свяжемся с вами в течение рабочего дня
Нажимая кнопку, вы соглашаетесь на обработку ваших персональных данных согласно нашей политике конфиденциальности.
Блог Southbridge

7 типичных ошибок при разворачивании кластера

Разберём 7 основных ошибок, которые часто допускают при внедрении отказоустойчивого кластера. Содержание статьи не направлено на конкретную технологию и подойдёт под любой стек.

Ошибки при разворачивании кластера

Мы обсудим следующие проблемы:
  1. Кластер ради кластера.
  2. Единые точки отказа.
  3. Нарушение принципов majority.
  4. Несимметричный кластер.
  5. Перегруженный кластер.
  6. Непротестированный кластер.
  7. Беспризорный кластер (без обслуживания и мониторинга).

Для подготовки материала мы использовали вебинар «10 типичных ошибок при разворачивании кластера». В выступлении спикер разобрал ещё три проблемы, а также ответил на вопросы зрителей. Если интересно, можно посмотреть вебинар, кликнув на его название.

1. Кластер ради кластера

Распространённая ошибка — разворачивать кластер тогда, когда он… Не нужен.

Считается, что кластер — универсальный инструмент, который обеспечивает надёжность и отказоустойчивость системы. Отказоустойчивость в «айтишном» мире измеряют девятками:
  • Одна девятка = доступность 90%. Это означает, что сервис может не работать 36 дней и 12 часов в год.
  • Две девятки = доступность 99%. Сервис может не работать 87 часов и 46 минут в год.
  • Три девятки = доступность 99.9%. Сервис может не работать 8 часов и 46 минут в год.
  • Четыре девятки = доступность 99.99%. Сервис может не работать 52 минуты и 33 секунды в год.
  • Пять девяток = доступность 99.999%. Сервис может не работать 5 минут и 35 секунд в год.
  • Шесть девяток = доступность 99.9999%. Сервис может не работать всего 31,5 секунды в год.


Большинству бизнесов для стабильной работы сервиса хватит трёх девяток. Чтобы их достичь, можно:
  • Использовать Industry standard server, у которых дублируются жёсткие диски, сетевые карты, источники питания.
  • Правильно его обслуживать: мониторить и принимать меры, когда сервер выходит из строя.
  • Обеспечить отказоустойчивость дополнительными средствами. Например, подключить два источника питания от разных подов в дата-центре; подсоединить серверы к разным свитчам разными линками; делать агрегацию; сделать виртуализацию — она позволит абстрагироваться от проблем с железом.

Ни один сервер не обеспечит отказоустойчивость больше трёх девяток. Для такой доступности приложения нужно разворачивать кластер. Однако часто не учитывают, что это дорогое и сложное решение, для которого требуются:
  • Дополнительные траты на покупку или аренду железа и ПО. Высокая отказоустойчивость нуждается в избыточности ресурсов — в нескольких серверах, виртуальных машинах и т. д.
  • Больше операционных затрат. Дублируются траты на обслуживание ресурсов — необходимо обновлять две ОС, защищать два сервера с двумя приложениями и т. д.
  • Специалисты достаточно высокого уровня для поддержки кластера. Рядовой сисадмин с этим вряд ли справится.

Прежде чем внедрять кластер, следует:
  • Понять, какая отказоустойчивость приложения необходима для вашего бизнеса.
  • Посчитать, сколько денег вы теряете в случае простоя.
  • Сопоставить траты на внедрение и содержание кластера с суммой, которую вы теряете при простое системы.

Если кластер стоит дороже времени простоя, то разворачивать его нерентабельно. Можно обойтись тремя девятками, укрепив отказоустойчивость средствами, о которых мы рассказали выше.

2. Единые точки отказа

Если заранее не продумать архитектуру так, чтобы в ней не было единых точек отказа сервиса, расходы на кластер будут напрасными. Единые точки отказа — это узлы системы, выход из строя которых может привести к недоступности приложения:
  • Один источник питания на все серверные стойки.
  • Единое для всех серверов хранилище.
  • Firewall и устройства, которые находятся в пограничной зоне между пользователями и кластером.
  • Сетевое оборудование: свитчи, роутеры.
  • Load balancers.
  • Серверы. Если все виртуальные машины находятся на одном сервере, при его отказе приложение тоже упадёт.

На Рис. 1 — не лучший пример отказоустойчивой архитектуры. Мы видим приложение с кластеризованными бэкендом и базой данных, а также Load balancer, выполняющим роль фронтенда. В этой схеме Load balancer — единая точка отказа. Если он сломается, пользователь не получит доступ к сервису, хотя серверы работают, а база данных отдаёт данные по запросу.

Кластер, где Load balancer — единая точка отказа
Рис. 1. Не лучший пример отказоустойчивой архитектуры

На Рис. 2 — кластер с высоким уровнем доступности. Здесь нет видимых точек отказа. IP-адрес плавает между Load balancers. Есть сервер приложения и кластеризованный сервер базы данных. Другие точки отказа на уровне инфраструктуры закрывает дата-центр.

Отказоустойчивый кластер
Рис. 2. Кластер с высоким уровнем доступности. Источник: digitalocean.com

3. Нарушение принципов majority

Чтобы кластер автоматически отработал отказ узла, ему необходимо понять, что произошло. Нода упала или стала изолированной? Порвалась сеть? Чтобы это определить, большинство кластеров используют принцип majority. У каждой ноды есть «голос». Работать останется та часть кластера, у которой больше голосов.

На Рис. 3 — кластер из трёх нод, распределённых по двум зонам отказа. В Зоне 1 — две ноды, следовательно, у этой зоны два «голоса». В Зоне 2 — одна нода и один «голос». Если вторая зона откажет, то кластер продолжит обслуживать Зона 1.

Кластер с нарушением принципа majority
Рис. 3. Кластер с нарушением принципов majority

Кажется, что такая архитектура хорошо работает. Это не так — здесь нарушен принцип majority. Потеряв соединение с Зоной 1, Зона 2 не получит majority, посчитает себя изолированной от кластера и отключит сервис — приложение станет недоступным. Включать его придётся вручную, а на это потребуется время.

Если кластер состоит из чётного количества узлов, которые распределены в две зоны отказа, то разрыв соединения между ними приведёт к сплит-брейну (Split Brain). Кластер посчитает, что всё нормально и обе его части работают корректно, хотя это не так и зоны не «общаются» друг с другом.

Split Brain на кластере
Рис. 4. Кластер, на котором может случиться сплит-брейн

Сплит-брейн легко устраняется восстановлением соединения и не приводит к серьёзным последствиям при условии, что он произошёл не на кластере базы данных. В противном случае при обрыве сети кластер продолжает параллельно сохранять данные в обеих зонах и, когда между узлами снова появляется связь, начинается путаница — приходится долго разбираться, что записалось, а что потерялось; какие данные нужно удалить, а какие совместить. В связи с этим кластеры, особенно те, что хранят данные, рекомендуется дробить на нечётное количество зон отказа.

На Рис. 5 — кластер, в котором соблюдается принцип majority. Он состоит из 5 нод, распределённых по трём зонам отказа. Если первая зона отключится, Зона 2 продолжит видеть Зону 3 и наоборот, и кластер будет работать.

Кластер, в котором соблюдается принцип majority
Рис. 5. Кластер, в котором соблюдается принцип majority

4. Несимметричный кластер

При внедрении кластера нужно позаботиться о его симметричности и выделить каждой ноде одинаковое количество ресурсов: ЦПУ, дисков, памяти и т. д. Так будет гораздо легче обеспечить отказоустойчивость и не загрузить кластер на 100% при отказе одной или нескольких нод. Приложение на 100% загруженном кластере работает так себе — в лучшем случае оно подтормаживает. В худшем — вообще не загружается.

На Рис. 6 — несимметричный кластер. При падении второй ноды её ресурсы распределятся между нодами 1 и 3, и это не перегрузит кластер. Если откажет нода 1, её ресурсы не поместятся в ноды 2 и 3 — из строя выйдет весь кластер.

Несимметричный кластер
Рис. 6. Несимметричный кластер

5. Перегруженный кластер

Эта ошибка связана с предыдущей. Выше мы уже говорили, что отказоустойчивый кластер требует избыточности. Это значит, что нужно не только равномерно распределить по нодам ЦПУ, диски, память и т. д., но и выделить на них некоторое количество ресурсов, которые не будут использоваться. Необязательно закладывать в два или три раза больше ресурсов. Их должно быть столько, чтобы хватило на рост нагрузки в случае отказа одной или нескольких нод и осталось ещё немного.

На Рис. 7 — кластер из пяти нод. Мы хотим обеспечить N + 2 — сделать так, чтобы при отказе двух нод кластер продолжил работать. Сейчас кластер сможет распределить нагрузку при отказе одной ноды (Рис. 8), а вот двух — уже нет (Рис. 9).

Кластер из пяти нод, на котором мы хотим обеспечить N + 2
Рис. 7. Кластер из пяти нод, на котором мы хотим обеспечить N + 2

Перегруженный кластер
Рис. 8. При отказе одной ноды кластер загружен на 75%. Он может стабильно работать

Перегруженный кластер
Рис. 9. При отказе двух нод кластер загружен на 100%. Скорее всего, он выйдет из строя

Чтобы обеспечить на таком кластере N + 2, нужно выделить столько ресурсов для каждой ноды, чтобы:
  • при отказе одной ноды нагрузка на оставшиеся четыре составила не больше 60%;
  • при отказе двух нод нагрузка на оставшиеся три составила не больше 80%.

6. Непротестированный кластер

Перед запуском следует протестировать кластер и убедиться, что он работает именно так, как мы ожидаем. В противном случае его поведение может стать неприятным сюрпризом — кластер может долго переключать сервис; падать, когда не должен; мешать решать другие задачи.

Вот список вопросов, на которые стоит ответить при тестировании кластера:
  • Сработает ли кластеризация в случае отказа?
  • Сколько времени займёт переключение сервиса?
  • Как подготовиться к плановому обслуживанию?
  • Что делать, если часть инфраструктуры станет недоступна?
  • Есть ли в серверной провод, выдернув который мы выключим весь кластер?

7. Беспризорный кластер (без обслуживания и мониторинга)

Чтобы стабильно работать и обеспечивать тот уровень отказоустойчивости, для которого он внедрялся, кластеру требуется мониторинг.
Мониторинг позволяет:
  • Выявить вышедший из строя компонент кластера раньше, чем из-за поломки сломается сам сервис.
  • Доказать бизнесу, что деньги на кластер потрачены не зря и он обеспечивает ожидаемый уровень отказоустойчивости.
  • Измерять и контролировать загрузку кластера, чтобы избежать несимметричности и перегруженности. Кластер не статичен. Со временем у него растёт загрузка, меняются версии и конфигурации.

Кроме того, перед запуском кластера в продакшн, нужно понять, каким образом его обслуживать с минимальным влиянием на доступность приложения. Если не разобраться с этим вопросом заранее, попытка закрыть баг или поднять новую версию может привести к простою системы.

Резюме

Мы прошлись по 7 основным ошибкам. На их основе можно выделить три главные вещи, которые следует сделать при внедрении кластера:
  1. Ответить на вопрос: «Действительно ли нужен кластер?» Иногда достаточный уровень отказоусточивости обеспечивается без этого инструмента.
  2. Протестировать кластер перед запуском в продакшн и понять, как система ведёт себя в разных условиях, нет ли у неё единых точек отказа и нарушений принципов majority, равномерно ли распределены ресурсы и т. д.
  3. Обеспечить кластеру мониторинг и обслуживание.
DevOps