Не так давно мне довелось беседовать с разработчиком, не понимавшим, почему полностью резервированная связь между ЦОДами не может гарантировать 100% доступность сервиса.
У клиента была идиллия: L3 связь между площадками с двумя маршрутизаторами ядра на каждой, с двумя каналами от разных операторов, предположительно выходящими из здания в разных точках и далее нигде не пересекающимися. И, несмотря на это, мы говорим разработчикам, что нельзя разносить компоненты критических приложений по разным локациям. Поразительно, правда?
Ну что может пойти не так при полностью резервированном дизайне?
Каждый задействованный вами компонент имеет отличную от нуля вероятность отказа. Следовательно, вероятность отказа нескольких компонентов разом тоже существует. Но если каждый компонент в достаточной мере надежен (скажем, доступность – 99,9%), значит, вероятность одновременного отказа крайне низка, верно? Неверно. Связанные друг с другом узлы имеют свойство падать одновременно.
Очевидный пример: если ПО маршрутизатора ядра уязвимо для пакета-убийцы (например, он вызывает падение и перезагрузку устройства), соседний роутер наверняка следом получит тот же самый пакет.
Был случай: в роутерах Cisco обнаружился баг, проявляющийся при обработке исключительно длинных AS Path. Тогда многие впервые поняли важность команды “bgp maxas-limit”. «Виновниками» были маршрутизаторы Mikrotik. Синтаксис их конфигурации очень похож на таковой у IOS маршрутизаторов, вот только там надо вводить не сам AS Path, а количество раз, которое локальная AS должна повторяться, чего некоторые администраторы не знали, ведь зачем читать документацию? Маршрутизаторы не выполняли проверку корректности введенных данных, и в результате принималось число в младших 8-и битах локальной AS. У кого-то это число было довольно высоким.
Менее очевидный пример. Практически все выполняют работы в пределах одного и того же окна обслуживания. Провайдер может начать профилактические работы с одним из ваших каналов связи в тот самый момент, когда вы обновляете роутер, поддерживающий второй канал (да, у меня такое было, они забыли предупредить нас об этом, потому что полагали, что у нас все резервировано).
Разработчик все еще не верил мне, так что я рассказал ему еще одну историю.
Некоторое время назад нас уведомили, что ЦОД будет отключен от внешнего энергоснабжения на пару часов в связи с профилактикой. Не проблема – есть ДГУ, есть емкие ИБП. Но когда питание отключили – дизель не завелся, и некому было его чинить посреди ночи. К счастью, оставалось достаточно времени, чтобы корректно остановить все системы, но через час наш ЦОД был мертв, несмотря на тройное резервирование.
На это разработчик ответил «теперь я понял». Затем было уже проще сойтись во мнении по поводу того, что нужно для обеспечения истинной катастрофоустойчивости их датацентров и сервисов.
Другие примеры из комментариев.
В комментариях пишите о своих авариях класса «вопреки резервированию».
У клиента была идиллия: L3 связь между площадками с двумя маршрутизаторами ядра на каждой, с двумя каналами от разных операторов, предположительно выходящими из здания в разных точках и далее нигде не пересекающимися. И, несмотря на это, мы говорим разработчикам, что нельзя разносить компоненты критических приложений по разным локациям. Поразительно, правда?
Ну что может пойти не так при полностью резервированном дизайне?
Каждый задействованный вами компонент имеет отличную от нуля вероятность отказа. Следовательно, вероятность отказа нескольких компонентов разом тоже существует. Но если каждый компонент в достаточной мере надежен (скажем, доступность – 99,9%), значит, вероятность одновременного отказа крайне низка, верно? Неверно. Связанные друг с другом узлы имеют свойство падать одновременно.
Очевидный пример: если ПО маршрутизатора ядра уязвимо для пакета-убийцы (например, он вызывает падение и перезагрузку устройства), соседний роутер наверняка следом получит тот же самый пакет.
Был случай: в роутерах Cisco обнаружился баг, проявляющийся при обработке исключительно длинных AS Path. Тогда многие впервые поняли важность команды “bgp maxas-limit”. «Виновниками» были маршрутизаторы Mikrotik. Синтаксис их конфигурации очень похож на таковой у IOS маршрутизаторов, вот только там надо вводить не сам AS Path, а количество раз, которое локальная AS должна повторяться, чего некоторые администраторы не знали, ведь зачем читать документацию? Маршрутизаторы не выполняли проверку корректности введенных данных, и в результате принималось число в младших 8-и битах локальной AS. У кого-то это число было довольно высоким.
Менее очевидный пример. Практически все выполняют работы в пределах одного и того же окна обслуживания. Провайдер может начать профилактические работы с одним из ваших каналов связи в тот самый момент, когда вы обновляете роутер, поддерживающий второй канал (да, у меня такое было, они забыли предупредить нас об этом, потому что полагали, что у нас все резервировано).
Разработчик все еще не верил мне, так что я рассказал ему еще одну историю.
Некоторое время назад нас уведомили, что ЦОД будет отключен от внешнего энергоснабжения на пару часов в связи с профилактикой. Не проблема – есть ДГУ, есть емкие ИБП. Но когда питание отключили – дизель не завелся, и некому было его чинить посреди ночи. К счастью, оставалось достаточно времени, чтобы корректно остановить все системы, но через час наш ЦОД был мертв, несмотря на тройное резервирование.
На это разработчик ответил «теперь я понял». Затем было уже проще сойтись во мнении по поводу того, что нужно для обеспечения истинной катастрофоустойчивости их датацентров и сервисов.
Другие примеры из комментариев.
Вот вам еще одна история про отказоустойчивость. Все внешние каналы одной крупной площадки были сосредоточены в одном здании. Было предусмотрено полное резервирование. Два внутренних маршрутизатора, два внешних, два VPNа, дублированное энергоснабжение с ДГУ. Каналы DS3 терминировались каждый на своем внешнем роутере, использовали раздельные медиаконвертеры, и выходили из здания с разных сторон.
Оптика обходила здание и в конце концов сходилась на площадке провайдера. Там она была воткнута в два медиаконвертера, которые превращали ее обратно в DS3. Оба медиаконвертера лежали на полке, воткнутые в обычный домашний сетевой фильтр, в свою очередь подключенный в одну розетку.
Еще одна история с генератором. У одного ЦОДа обесточились вводы, и дизели завелись. Но кто-то оставил на одном из них кучу деревянных досок, и через час дизель воспламенился.
Еще про дизели, было это лет 12-13 назад. Я работал в крупном британском провайдере (не BT), и одним жарким днем (да, такое у нас бывает) я проводил кое-какие работы в одном из наших крупных ЦОДов. Я приехал рано, и застал доставку огромного контейнера. Когда я спросил, что это, мне сказали, что это – генератор, который даст немного лишней энергии – системы охлаждения работали на пределе, и питания не хватало. Я подумал «круто» и приступил к своей работе.
Позднее утром сработала пожарная тревога, и весь ЦОД обесточило, осталось работать только аварийное освещение. Я вышел наружу и понял, в чем дело: новый генератор установили вплотную к воздухозаборникам центральной системы вентиляции, и когда дизель завели, тот выплюнул огромное облако дыма, которое всосало в вентиляцию, на что среагировали датчики задымления внутри здания
Когда я приехал туда на следующий день, на выхлоп дизеля установили огромную трубу, которая отводила дым далеко в сторону от здания ЦОДа.
У той площадки было много отказоустойчивости, но в итоге ничто не помогло…
У нас в EDU все было резервировано. Но вот одно мы исправить не могли. Машинный зал находился прямо под туалетом художественного отдела. В общем, однажды нас натурально затопило говном. А вы знали, что можно заказать у Sun Microsystems выезд их бойцов для протирки оборудования СХД ватными тампонами со спиртом?
У одного из университетов моего города главный ЦОД расположен в подвале одного из их центральных корпусов. Они как раз завершили постройку соседнего здания, и им потребовалось проверить систему водоснабжения. На период испытаний они открыли слив снаружи корпуса, но забыли его закрыть на ночь. В конце концов вся вода стеклась ко входу в подвал. Весь подвал залило водой на 30 сантиметров.
Однажды клиент собирался переместить часть серверного оборудования в другое здание – чтобы освободить пространство и добавить немного отказоустойчивости. Связь заводилась по двум OC-3 от одного ОПМ, но зато по двум независимым трассам. У нас был детально проработан план переезда, предусмотрена каждая мелочь, и когда наступило время Ч – я заглушил порты, оборудование отключили и начали переносить в другое здание. Инженер был готов выдернуть оптику, провайдеру дали зеленый свет на перерезание теперь уже неиспользуемого канала. Разве что… Кто-то где-то когда-то давным-давно, когда схема еще только вводилась в эксплуатацию, перепутал местами идентификаторы каналов. Так что половина нашего ЦОДа была в процессе перевоза с места на место, а у второй половины перерезали единственный внешний канал связи. Не очень приятно.
Несколько лет назад (в районе 2005-2007гг) одна из крупных магистралей, соединяющая штат Queensland с остальной частью Австралии (да на тот момент и со всем миром), сломалась. Если я правильно помню последовательность событий, дело было так.
Магистраль шла двумя различными путями, один по побережью, другой через материк. Около 3-х часов ночи линейная карта, терминировавшая побережную оптику, начала сыпать ошибками, а потом совсем упала. Не проблема – весь трафик перемаршрутизировало через материк. Инженерам велели прибыть на место в 9 утра для замены платы… Но около 6 утра экскаватор перерубил шедшую через континент оптику.
Лет 10 назад (надеюсь, с тех пор разработчики железа поумнели) я потерял массив RAID5. На десять дисков. Началось все с того, что диск под номером «3» вылетел. Инженер идет к массиву, вынимает диск три – и массив падает. Оказалось, что управляющий интерфейс нумеровал диски с 0 по 9, а маркировка на передней панели – от 1 до 10, так что инженер вынул исправный диск.
Крупный логистический центр со всеми видами резервирования, ИБП (батареи и дизель) и все прочее. Однажды у всего квартала отключается энергоснабжение. Не беда – батареи перехватывают нагрузку, дизели заводятся, контора продолжает работать.
Питание восстанавливается. Квартал зажигается всеми огнями, контора обесточивается.
Как полагается по законам Мерфи, дизель корректно заглушили, но вот только реле, переключающее питание с дизеля на городские вводы, не сработало…
ЦОД, в котором я раньше работал, имел городские вводы электроснабжения и ИБП. ИБП брали с расчетом на 6 часов работы. В случае аварии предполагалось мигрировать виртуальные сервера на другую площадку. Не лучшее решение, но вроде сойдет.
Однажды наш ЦОД действительно потерял внешнее питание, и мы узнали, что кондиционеры не были подключены к ИБП. Машзалы мгновенно перегрелись, и через полчаса все системы начали отключаться.
В одной из стран третьего мира произошел еще один случай. При обесточивании здания дизели не завелись. Оказалось, что у них слили солярку.
Мы – клиенты крупного ЦОДа, все резервировано – питание от батарей, дизели, дублированная оптика с разными трассами – идиллия. Машинные залы расширяли, и бравые парни выломали пару стен, предварительно отгородив оборудование от пыли. Потом этим двум клоунам пришла в голову гениальная идея помыть пол в зале. К несчастью, они выбрали ведро с водой и тряпку как в старые добрые времена. Разумеется, один из них нечаянно перевернул ведро.
В комментариях пишите о своих авариях класса «вопреки резервированию».