Когда стоит задуматься о высокой доступности?

“High Availability isn’t something you buy, it’s something that you do.” – John Nicholson

Мало что в ИТ пользуется столь всеобщим спросом, как решения высокой доступности (HA). Право же, скажите эти слова вслух, и любой ИТ-специалист мгновенно ответит, что хочет именно этого. HA для серверов, приложений, хранилищ и, конечно, даже рабочих станций. Если бы рядом с любой системой был флажок с надписью «HA», почему бы нам его не поставить? Конечно, поставили бы. Никто добровольно не хочет систему, которая часто падает. Отказы — плохо, работоспособность — хорошо.

Однако для начала необходимо определить понятие HA. HA может означать многое. Как минимум, HA должна означать, что доступность рассматриваемой системы выше «нормальной». Что является нормой? Уже само по себе это непросто определить. HA — понятие весьма расплывчатое. Тем не менее в контексте наиболее распространённого применения этого термина — для обычных приложений, работающих на стандартном корпоративном оборудовании, — я бы предложил следующую отправную точку для обсуждения HA:

Нормальная, или стандартная, доступность (SA) определялась бы как доступность стандартного серверного сервера под управлением распространённой корпоративной операционной системы с запущенным типовым корпоративным приложением в среде, соответствующей лучшим практикам, при наличии корпоративной поддержки. Хорошими примерами могут служить: Exchange, работающий на Windows Server на HP Proliant DL380 (наиболее распространённый массовый сервер корпоративного класса); или BIND (DNS-сервер) на Red Hat Enterprise Linux на Dell PowerEdge R730. Это лишь примеры для формирования приблизительного базового уровня. Измерить его точно затруднительно, но при наличии хорошего контракта на поддержку и быстрого ремонта или замены в реальных условиях надёжность системы такого типа оценивается в диапазоне от четырёх до пяти девяток (99,99% времени безотказной работы и выше), если не принимать во внимание человеческий фактор.

Высокая доступность (HA) в общем смысле должна определяться как доступность, существенно превышающая стандартную. «Существенно выше» — это как минимум на один порядок. То есть не менее пяти девяток надёжности, а скорее шесть девяток (99,9999% времени безотказной работы).

Низкая доступность (LA) в общем смысле определялась бы как доступность, существенно ниже стандартной, где «существенно» снова означает не менее одного порядка. Таким образом, LA, как правило, составляет от 99% до 99,9% или ниже.

Измерения в данном случае крайне затруднены, поскольку человеческий фактор, окружающая среда и другие условия играют колоссальную роль в определении времени безотказной работы при различных конфигурациях. Одно и то же оборудование, используемое в разных ролях, может достигать пяти девяток в одном случае и не добираться даже до одной в другом. Качество дата-центра, квалификация персонала поддержки, скорость замены комплектующих, степень детализации мониторинга и множество других факторов существенно влияют на общую надёжность. Однако это не обязательно является проблемой для нас. В большинстве случаев мы можем оценить те части системного дизайна, которые находятся под нашим контролем, таким образом, чтобы определить относительную надёжность и, как минимум, показать, что один подход будет превосходить другой. Это позволяет принимать обоснованные решения, даже если точные модели частоты отказов построить нелегко.

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

Разумеется, HA можно определять на каждом уровне. Мы можем иметь платформы или ОС с HA, но с нестабильными приложениями поверх. Поэтому крайне важно понимать, о каком уровне мы говорим в каждый конкретный момент. В конечном счёте бизнес будет заботиться только о высокой доступности предоставляемых сервисов — вне зависимости от того, как и где это достигается. Важен конечный результат, а не «подкапотные» детали того, как он был получен, или, как всегда, цель оправдывает средства.

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

В реальности, однако, HA не всегда является вариантом, и когда она доступна, она обходится дорого. Эта цена почти всегда выражается в деньгах и, как правило, сопровождается дополнительной сложностью. А как нам хорошо известно, любая сложность несёт в себе дополнительный риск, и этот риск, если не проявить осторожность, может привести к тому, что попытка достичь HA фактически провалится и мы в итоге получим LA, то есть низкую доступность.

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

Концептуально все системы несут риск простоя, и ничто не может быть доступно постоянно — это невозможно. Надёжность, как правило, стоит денег, при прочих равных условиях. Поэтому, чтобы определить, какой уровень доступности наиболее подходит для данной рабочей нагрузки, мы должны определить стоимость снижения рисков (сколько денег требуется, чтобы изменить среднее время простоя) и сопоставить её со стоимостью самого простоя.

Это непросто и требует тщательного анализа, поскольку определить стоимость простоя само по себе достаточно трудно, а определить риск простоя — ещё сложнее. Во многих случаях стоимость простоя — не фиксированная величина, хотя может быть и таковой. Эта стоимость может выражаться как 5 долларов в минуту, или 20 000 долларов в день, или аналогичным образом. Но ещё более полезным инструментом была бы «кривая потерь», показывающая, как деньги теряются с течением времени (в пределах разумного интервала).

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

Иногда всё зависит от людей, работающих в компании. Согласятся ли они все охотно сделать перерыв на туалет, кофе, перекус или обед в момент отказа системы, чтобы вернуться к работе после её восстановления? Уйдут ли люди домой пораньше и придут ли пораньше завтра, чтобы компенсировать крупный сбой? Будет ли простаивать оборудование? Пострадает ли способность реагировать на запросы клиентов? Выйдут ли из строя системы жизнеобеспечения? Существует бесчисленное множество потенциальных последствий и столь же бесчисленное множество возможных способов нивелировать различные типы отказов. Всё это необходимо принимать во внимание. Стоимость простоя может составлять долю корпоративной выручки в расчёте на минуту, а может повлечь потерю клиентов или репутации, что окажется более ощутимым ударом, чем выручка, генерируемая поминутно.

Как только у нас появятся хотя бы приблизительные цифры потерь, мы получим отправную точку. Даже если мы знаем лишь, что выручка составляет ~10 долларов в минуту, а потери ожидаются на уровне ~5 долларов в минуту, — это уже какой-то ориентир. Если есть полная кривая или исследование с более детальными цифрами — тем лучше. Теперь нужно примерно определить наш базовый уровень. Хорошо обслуживаемый сервер, работающий на площадке клиента, с хорошим контрактом на поддержку и отработанными процедурами резервного копирования и восстановления вполне способен обеспечить четыре девятки надёжности. Это означает около пяти часов простоя каждые пять лет. На самом деле это меньше, чем ожидаемый уровень простоя для SA в большинстве сред, и потенциально значительно меньше, чем в отличных средах, таких как высококлассные дата-центры с быстрой заменой комплектующих и сервисом.

Итак, исходя из нашего базового примера — около пяти часов каждые пять лет — мы можем оценить потенциальный риск. Если наши потери составляют ~5 долларов в минуту и мы ожидаем примерно 300 минут простоя за пять лет, потенциальные потери составят 1 500 долларов за полдесятилетия.

Это означает, что в самом крайнем случае мы никогда не должны тратить 1 500 долларов на снижение этого риска — это финансово бессмысленно. Это происходит по нескольким причинам. Одна из главных состоит в том, что речь идёт лишь о риске: тратить 1 500 долларов ради защиты от потери 1 500 долларов — малый смысл, хотя это крайне распространённая ошибка, когда люди не анализируют цифры тщательно.

Главный фактор заключается в том, что ни одна мера по снижению рисков не является полностью эффективной. Если нам удастся перевести систему с четырёх девяток на пять девяток, мы сократим лишь 90% среднего времени простоя, снизив потери с 1 500 долларов до 150 долларов. Если при этом потратить 1 500 долларов на такое сокращение, общие «потери» всё равно составят 1 650 долларов (стоимость защиты — это тоже форма финансовых потерь). Совокупные затраты на снижение риска и ожидаемый остаточный ущерб вместе должны оставаться меньше ожидаемых потерь от риска без снижения, иначе само снижение риска бессмысленно или даже вредно.

Многие могут задаться вопросом: почему совокупные затраты на снижение рисков должны быть именно меньше, а не равны — ведь при равенстве мы находились бы в «точке безубыточности по рискам»? На поверхности это кажется верным, но поскольку мы имеем дело с рисками, это не так. Снижение рисков — это определённые затраты, финансовый урон, который мы несём авансом в надежде сократить потери в будущем. Но риск на завтра — это предположение, пусть и хорошо обоснованное, однако лишь предположение. Сегодняшние затраты — это определённость. Нести определённый ущерб сегодня в надежде сократить возможный ущерб завтра имеет смысл лишь тогда, когда сегодняшний ущерб невелик, а ожидаемый или возможный ущерб завтра весьма значителен и эффективность снижения рисков существенна.

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

В наиболее драматических случаях мы иногда наблюдаем, как ИТ-отделы требуют потратить десятки или сотни тысяч долларов авансом, чтобы избежать потери нескольких тысяч долларов — может быть, когда-нибудь, возможно, через много лет. Эту стратегию можно охарактеризовать как «выстрелить себе в голову сегодня, чтобы, возможно, избежать головной боли завтра».

Это включено в концепцию оценки снижения риска, но об этом стоит упомянуть отдельно: применительно к ИТ-оборудованию существует немало примеров попыток снижения рисков, которые на деле могут оказаться не столь эффективными, какими считаются. Например, наличие двух серверов, стоящих в одной стойке, потенциально весьма эффективно для снижения риска отказа серверного оборудования, но не защищает от стихийных бедствий, потери площадки, пожара, большинства случаев воздействия электрическим разрядом, срабатывания системы пожаротушения, сетевых сбоев, большинства отказов приложений, атак ransomware или других достаточно вероятных катастроф.

Устройства хранения данных нередко оснащаются «двойными контроллерами», что создаёт сильное ощущение высокой надёжности, однако, как правило, эти контроллеры находятся внутри единого шасси с общими компонентами, и даже если компоненты не разделены, прошивка зачастую общая, а взаимодействие между компонентами сложное. Это нередко приводит к сбоям, при которых отказ одного компонента провоцирует отказ другого, — в результате такие устройства довольно часто оказываются LA, а не SA или ожидаемой при покупке HA. Поэтому крайне важно учитывать, какие именно риски снижает та или иная стратегия и насколько методика снижения, вероятно, будет эффективной. Ни одна методика не является полностью эффективной: вероятность отказа всегда существует, но одни стратегии и методики имеют более широкое применение, тогда как другие просто вводят в заблуждение или контрпродуктивны. Если не проявлять осторожность, можно внедрить дорогостоящие продукты или методики, которые активно подрывают наши цели.

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

Для многих компаний и, особенно, для ИТ-специалистов, которые редко занимаются финансовым анализом рисков и которым постоянно внушают, что HA является необходимостью для любого бизнеса и что покупка последних HA-продуктов — это то, на что должны тратиться их бюджеты, — настоящим сюрпризом, почти шоком, становится то, что при тщательном подсчёте цифр и реальной оценке затрат и эффективности стратегий снижения рисков оказывается: высокой доступности практически нет места ни в одной организации, особенно в малых предприятиях или организациях с сильно разнородными рабочими нагрузками. На рынке малого и среднего бизнеса практически повсеместно обнаруживается, что затраты и сложность (которая, в свою очередь, несёт риск — преимущественно в виде недостаточного опыта в применении методик и оценке рисков) подходов к высокой доступности слишком высоки, чтобы когда-либо компенсировать потенциальный ущерб от простоя, от которого и надеются защититься. Исключения, конечно, есть, и существует немало предприятий, для которых решения HA абсолютно оправданы, — но это именно исключения, а никак не правило.

Также имеет смысл рассматривать потребность в высокой доступности применительно к каждой отдельной рабочей нагрузке, а не в масштабах отдела, компании или технологии. В малом бизнесе часто все рабочие нагрузки используют единую платформу, и потребность одной рабочей нагрузки в HA может «потянуть» за собой другие, менее критичные. Это вполне нормально и является отличным способом компенсировать затраты на снижение рисков критической рабочей нагрузки за счёт попутной пользы для менее критичных. В крупной организации, где для разных рабочих нагрузок используется множество различных платформенных подходов, как правило, только определённые рабочие нагрузки — как критически важные (с точки зрения последствий простоя), так и те, риски которых реально поддаются снижению (возможность снижения рисков для разных типов рабочих нагрузок варьируется весьма существенно), — получают HA, тогда как другие рабочие нагрузки оставляются на стандартных методах.

Примером рабочей нагрузки, которая может быть критичной и для которой HA эффективна, является система онлайн-заказов, где задержка, создаваемая многорегиональной репликацией, мало влияет на общую работу системы, тогда как потеря заказов в случае отказа может нанести серьёзный финансовый ущерб. Пример рабочей нагрузки, для которой HA легко реализуема, но неэффективна, — внутренний интранет-сайт с ответами на типовые вопросы HR: было бы просто нецелесообразно тратить ресурсы на предотвращение редких кратковременных простоев такой системы. Пример системы, где риски высоки, но стоимость или эффективность снижения рисков делает это нецелесообразным или даже невозможным, — финансовая база данных тиков (tick database), требующая приёма огромного объёма данных с низкой задержкой: поддержание реплики было бы не только чрезвычайно дорогостоящим, но и могло бы вносить задержки, лишающие систему возможности адекватно выполнять свои функции. Каждый бизнес и каждая рабочая нагрузка уникальны и требуют тщательной оценки.

Разумеется, методики высокой доступности можно внедрять поэтапно; это не вопрос всё или ничего. Может быть целесообразным снизить риск отказа на системном уровне, обеспечив отказоустойчивость на прикладном уровне против отказов аппаратного обеспечения хоста, платформы виртуализации или хранилища. Но для той же рабочей нагрузки может быть нецелесообразным защищаться от потери всей площадки. Если рабочая нагрузка обслуживает только конкретную площадку или просто недостаточно ценна для крупных инвестиций в обеспечение отказоустойчивости между площадками, она вполне может оказаться «где-то посередине». Весьма распространена ситуация, когда для рабочих нагрузок реализуются лишь частичные решения HA — нередко потому, что ИТ-отдел отвечает только за часть из них и не влияет на такие аспекты, как качество электроснабжения и кондиционирование, но, пожалуй, чаще всего потому, что некоторые методики HA отличаются высокой видимостью и их легко «продать» руководству, тогда как другие — например, качественное электроснабжение и кондиционирование воздуха — зачастую таковыми не являются, хотя и могут давать лучшее соотношение цены и качества. Существуют веские причины для выбора одних методик и отказа от других: они воздействуют на разные составляющие риска, а некоторые риски могут иметь различный вес применительно к конкретному бизнесу или рабочей нагрузке.

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

Во многом это связано с тем, что стандартная доступность достигла такого уровня, что рисков для снижения становится всё меньше и меньше. Технологические компоненты, используемые в бизнес-инфраструктуре, — прежде всего серверы, сетевое оборудование и системы хранения данных, — стали настолько надёжными, что объём простоев, от которых нам необходимо защищаться, весьма невелик. Большинство убеждений в необходимости «рефлекторной» высокой доступности пришло из другой эпохи, когда надёжное оборудование было недоступно по цене и даже самое дорогое считалось ненадёжным по современным меркам. Это ощущение надвигающейся катастрофы, будто любое устройство может выйти из строя в любой момент, — реликт прошлого, а не нынешнего времени. Современное оборудование, при всех существующих рисках, отличается поразительной надёжностью.

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

Как ИТ-практики, оценка преимуществ, рисков и стоимости технологических решений — это суть нашей работы. Как и всё остальное в бизнес-инфраструктуре, определение типа снижения рисков, ценности защиты и финансово обоснованного объёма вложений — наша ключевая ответственность, которую нельзя замалчивать или игнорировать. Мы никогда не должны просто предполагать, что высокая доступность необходима, равно как и то, что от неё можно легко отказаться. Именно в таком анализе ИТ приносит организациям наибольшую ценность. Именно здесь у нас есть наибольший потенциал для того, чтобы блеснуть.