Отказоустойчивость ИТ-инфраструктуры: как сделать свою систему надежнее

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

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

Что вообще такое отказоустойчивость системы?

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

Но все в мире относительно, и отказоустойчивость может быть очень разной. Чем мощнее поломка, которую может выдержать ваша инфраструктура, и чем масштабнее ремонтные работы, которые вы можете выполнять без остановки сервиса, тем он надежнее.

Самыми отказоустойчивыми являются специальные дата-центры, которые даже ранжированы по надежности. Уровни отказоустойчивости в этой системе расположены от первого, наименее надежного, до четвертого, редкого и супер-устойчивого. У нас, например, центр Tier III – это высокий уровень надежности, и требования к отказоустойчивости системы у него высокие:

• На каждый зал предусмотрена своя дизель-генераторная установка, так что электричество будет даже если свет пропадет во всем городе.
• Включено прицезионное и чиллерное охлаждение со схемой резерва 2N, т.е. кондиционеров вдвое больше, чем обычно нужно, и при поломке даже половины из них ЦОД будет работать как надо.
• Есть автоматическая противопожарная система, датчики температуры и система мониторинга, независимые электрощитовые...

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

Как сделать свою ИТ-инфраструктуру надежнее

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

Уровень сервера

Самый нижний уровень резервирования даже не всегда заметен. Это уровень отдельного устройства, каждого сервера, в котором резервироваться может практически что угодно.

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

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

Конечно, можно резервировать питание. Это происходит и на уровне сервера, который может иметь два блока питания, и на уровне серверной/центра обработки данных, в котором могут быть резервные источники питания (например, бесперебойники или даже дизельные генераторы).

Уровень кластера

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

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

Существует также возможность дублирования систем хранения данных, к которым требований еще больше, чем к серверам. У солидных СХД существует дублирование контроллеров; почти всегда используются уже упомянутые RAID-массивы и кластерные конфигурации, объединяющие СХД в кластеры.

Уровень инфраструктуры

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

Резервное копирование данных

Отдельно нужно упомянуть бэкапы. Мало будет прока от работающей инфраструктуры, если стереть с нее критически важные данные! Резервное копирование - это огромная тема, которой у нас посвящена отдельная публикация. Лучше обратиться к ней, но если взять оттуда только самые важные мысли, то они таковы:

• Бэкапы точно нужны. Бэкапы не делаются постоянно только до первой критической ситуации.
• Бэкапы должны храниться в нескольких местах. Одной из наиболее распространенных стратегий резервного копирования сайта является «система «3-2-1», которая предполагает делать бэкапы данных в трех местах одновременно.
• Бэкапы должны сниматься ежедневно. Вам также понадобится архив бэкапов глубиной в один месяц. Отдельно лучше создать дополнительный архив глубиной в квартал, в котором будут храниться недельные копии, а также по ещё одной копии на месяц за весь последний год.

Мониторинг системы

Мониторинг своей инфраструктуры - ключевой аспект управления ею. Без возможности отслеживать в реальном времени состояние всех систем об эффективной и бесперебойной системе речь не идёт. Зато правильно внедрённый мониторинг позволит повысить производительность, оптимизировать затраты и повысить уровень безопасности IT-инфраструктуры. О том, как создать грамотный мониторинг для своей компании мы писали в соответствующей статье.

Безопасность

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

Балансировка

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

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

Сценарий восстановления: disaster recovery

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

Что он должен в себя включать?

• Точки отказа и критические сервисы. Точки отказа – это слабые места инфраструктуры, без которых перестают работать необходимые, критические для работы вашего предприятия сервисы. Что это могут быть за точки? Как правило, это система электроснабжения, кондиционирования, оперативные системы серверов, почтовые приложения и коммутаторы ядра, а также внешняя DNS-зона. Это - лишь самые общие точки. Для каждой инфраструктуры существуют собственные требования к отказоустойчивости системы, и проверка точек отказа позволит их картографировать.
• Процедуры локализации. Самое худшее, что можно сделать при поломке, это искать проблему не там, где она действительно есть! Вам нужны будут собственные процедуры поиска. Нужно диагностировать как отдельные важные приложения, так и точки отказа, мониторить их, утвердить правила эскалации при возникновении проблем, иметь возможность оценить время на их локализацию.
• Корректировку аварийного восстановления по потребности бизнеса. Разные системы требуют разных ресурсов на восстановление – иногда даже ночь простоя недопустима, а иногда можно и потерпеть, пока приедет новый сервер. Стоит подготовить ресурсный резерв и инструкции для восстановления критически важных служб рядовыми сотрудниками, провести их обучение и, возможно, обучить еще одного, сменщика. Может также быть полезно договориться о возможной атусорс-поддержке в случае отказов. В конце концов, обратиться к опытным системным администраторам за помощью никогда не стыдно.

Полезно будет устраивать время от времени тестирование отказоустойчивости: прогонять время от времени разные сценарии и смотреть на результат.

Резюме

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

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