В прошлой заметке я описывал, на что стоит обратить внимание при организации отказоустойчивой резервируемой системы, независимо от того, это ИБ, ИТ или телеком. Но даже при соблюдении этих правил можно испытать фиаско.
В каких случаях кластеризация не спасёт от потери сервиса.
1. Рост нагрузки.
Узким местом кластера является балансировщик, поскольку именно он принимает на себя весь трафик, обрабатывает его по своим алгоритмам, распределяя между элементами кластера, а в ряде случаев ещё и снижает нагрузку на конечные сервера (TLS offload). И при приближении к пороговому значению, а особенно его превышению, будет происходить деградация сервиса. Даже если кластер организован без использования балансировки, методом резервирования 2N, предельно допустимым значением будет пропускная способность N без умножения.
Аналогичная ситуация может произойти и при превышении нормального значения нагрузки хотя бы на одном из членов кластера.
Это может произойти как по причине некорректного проектирования, так и в результате органического роста нагрузки при популяризации сервиса либо увеличении количества пользователей.
Правильные варианты решения:
- замена/расширение балансировщика либо элементов кластера;
- перенос части либо всей нагрузки на более производительный кластер.
2. Сбой ПО.
Даже если система построена по всем правилам резервируемости сети и аппаратной платформы, но при этом существует единая точка реализации логики - возможен ее программный сбой. И независимо от того, балансировщик это или ядро системы, если резервная нода программно наследует состояние основной - нарушению сервиса быть.
Правильные варианты решения:
- наличие холодного резерва, программно не взаимосвязанного с основной системой - для переключения вручную;
- горячий резерв, реализованный на программно не взаимосвязанном решении - для автоматического переключения.
3. Исчерпание полосы пропускания.
Несмотря на все меры предосторожности, может произойти ситуация, когда полоса пропускания будет исчерпана. Это может произойти как по причине ошибки проектирования, так и в связи с DDoS-атакой.
Правильные варианты решения:
- фильтрация паразитного трафика на сети (в случае DDoS);
- оптимизация трафика на сети либо средствами логики приложения;
- расширение канала (если причиной оказался рост полезной нагрузки).
Конечно, данный перечень не является исчерпывающим, но, описывая крупными мазками довольно распространённый пласт проблем, может пригодиться специалистам.
