Фильм «День сурка» как отражение проблемы доступности приложений

Недавно со мной поделились историей. Фабула такая. Дело происходило в заключительный рабочий день месяца. Во многих организациях, как и в той, в которой работал рассказчик, – это день, когда сводят итоги работы за отчетный период. И тут, в полном соответствии с одним из законов Мерфи, отказывает самая нужная прикладная система. Работоспособность системы удалось восстановить примерно через 4 часа вместо предполагаемых нескольких минут.

Что же произошло? История обычная – отказ гипервизора. Как раз эту-то ситуацию HA-агент детектировал и инициировал процедуру перезапуска VM с критически важным приложением на работоспособном гипервизоре. Однако процедура перезапуска VM завершилась неудачей, поскольку файл образа VM был заблокирован исходным гипервизором – это известная ситуация, она описана в документации и время от времени случается. Тогда уже администратору пришлось вмешиваться и запускать VM с использованием резервной копии файла образа, созданной по окончании предыдущего рабочего дня. Ну и далее нужно было, может быть, и не долго – примерно 4 часа, но мучительно приводить набор данных, с которым работало приложение, в актуальное состояние.

И все-таки, могла бы эта история иметь другой сценарий и, соответственно, другой, более счастливый, финал? Да. Гипотетически, да. Представим себе, что приложение соответствовало бы, по крайней мере, двум условиям:
•   могло бы функционировать более одного экземпляра приложения одновременно (иначе говоря, приложение обладала бы горизонтально масштабируемой архитектурой);
•   обращение к приложению осуществлялось бы по имени (FQDN) с помощью сервиса DNS, а не по жестко заданному IP-адресу (hardcoded IP).

В этом случае представилась бы возможность иметь несколько функционирующих одновременно экземпляров приложения, размещенных на разных площадках (т.е., в разных подсетях), установление соединений к которым осуществлялось бы с помощью DNS (или более изящно, через GSLB и SLB). Просто и надежно. Именно то, что нужно для работы критически важных приложений, если они действительно критически важные (иногда можно встретить другой подход, когда полагают, что приложение становится критически важным, т. е. способным обеспечивать непрерывное ведение операций, просто по факту навешивания на него ярлыка «критически важное»).

Правда, надо помнить об одном нюансе: в кэше пользовательской OS и, возможно, в кэше клиентской части приложения сохраняется результат запроса в службу DNS на предмет разрешения имени приложения (FQDN) – IP-адрес – в течение времени, заданного значением параметра TTL. Однако, в А-записях DNS-сервера значение TTL может быть задано таким, чтобы переустановить пострадавшие соединения, но уже  с работоспособными экземплярами приложения, настолько быстро, насколько возможно, и при этом не перегрузить DNS-сервер (полагаю, что для процедуры восстановления операций несколько минут может быть вполне приемлемым значением).

Приложения, имеющие горизонтально масштабируемую архитектуру и поддерживающие сервис DNS, не являются такими уж необычными. Я бы сказал, что грамотно созданное приложение именно таким требованиям и отвечает (Это, своего рода, правила хорошего поведения для воспитанных приложений). Другое дело, что в наших краях приложения, обладающие такими свойствами, – исключительное явление (наверное, такие существуют, но я их не встречал), и в таком случае следует принять неизбежное следствие – перерыв в предоставлении сервиса. Естественно, возникают, по крайней мере, два вопроса: «Кто виноват?» и «Что делать?» «До какого значения может быть уменьшена длительность перерыва?» и «Каким образом этого можно добиться?».

Фактически стандартным методом стало применение VM как среды функционирования приложения. Полагаю, что возможность перезапустить VM вместе приложением из файла-образа в среде виртуализации выглядит подкупающе простой, в особенности когда перезапуск осуществляется на соседнем физическом сервере из той же подсети. В этом случае с большой вероятностью можно надеяться на то, что длительность перерыва в выполнении операций составит несколько минут.

Сложности же появляются тогда, когда рестарт VM нужно произвести на резервной площадке. С чем связаны эти сложности? И каковы именно эти сложности? Как уже можно догадаться, ответ на первый вопрос – изъяны в архитектуре приложений. Если разработчики приложения не включили поддержку сервиса DNS в приложение, то обращение к нему происходит исключительно по IP-адресу, который задается «жестко», т.е. его или невозможно, или нельзя изменить. Соответственно, популярным способом обеспечить функционирование приложения с тем же IP-адресом на резервной площадке, – это дотянуть до нее исходный L2-сегмент. Это обстоятельство неизбежно порождает проблемы – увеличение размера широковещательного домена (эффект примерно такой, как если бы в корабле убрали бы все внутренние переборки); которая еще больше усугубляется за счет способа обработки BUM-трафика (Broadcast, Unknown Unicast and Multicast) L2-коммутаторами Ethernet; блокировка всех, кроме одного, путей между основной и резервной площадками; «эффект тромбона» для потока данных.

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

Разумеется, существуют методы, с помощью которых можно технологически «безопасно» решить задачу растяжения L2-сегмента между основной и резервной площадками – OTV, EVPN, TRILL, комбинация OTV с LISP. Однако это влечет усложнение сетевой инфраструктуры, которое имеет свои последствия (кстати, об этом и не только будет идти речь на нашем семинаре 6 ноября 2014 г.). В таких обстоятельствах вполне может сработать 4-й закон Клипштейна (более известный как один из законов Мерфи): «Система обеспечения надежности выведет из строя другие системы».

К чему я веду? За дефекты архитектуры приложения все равно придется заплатить – рано или поздно. Догадайтесь, кому?

Кстати, если разработчики приложений включат в них хотя бы поддержку сервиса DNS, простым и не имеющим побочных эффектов способом перезапуска приложения на резервной площадке является использование механизмов DHCP и Dynamic DNS.

P.S. А что насчет фильма «День сурка»? Мне он представляется хорошей метафорой. Как бы ни пытался главный герой фильма каждый раз немного по-другому реагировать на одни и те же события, до тех пор пока он не изменил свой взгляд на то, почему ситуация по-вторяется изо дня в день, ему не удавалось вырваться из замкнутого круга. С приложениями то же самое. До тех пор пока доступность приложений не будет обеспечиваться за счет архитектуры самих приложений, из череды повторяющихся ситуаций наподобие той, что описана в начале блога, не вырваться.