5 принципов бесперебойной работы ИТ-инфраструктуры

Базовое условие надежности информационных систем и ИТ-сервисов в облаках – развертывание необходимой ИТ-инфрастуктуры на нескольких площадках с настроенным резервированием. Это обеспечивает стабильность работы приложений даже в случае аварий. Наличие нескольких зон доступности, т.е. дублирование приложений и сервисов в различных локациях – залог того, что система не «упадет» из-за проблем на одной площадке.

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

При выборе гибридного формата локальные ресурсы компании объединяются с облачными площадками одного провайдера, скажем, в двух разных локациях. Также можно добавить собственное оборудование в ЦОДе другого провайдера (colocation) – и ИТ-система, построенная на подобной архитектуре, будет работать ощутимо надежнее.

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

Разброс в стоимости оборудования огромный, особенно когда речь идет о системах хранения данных (СХД), поэтому в зависимости от архитектуры «падение» СХД может быть как незначительным инцидентом, так и катастрофическим, возможно с необратимой потерей данных клиента.

Программно определяемые системы хранения данных (SDS) представляют собой одно из решений, призванных снизить зависимость от отдельных физических устройств. Но даже они не являются универсальным ответом: случаи сбоев open source SDS показывают, что восстановление работоспособности – это только часть задачи. Потерянные в результате сбоя данные могут оказаться гораздо более серьезным вызовом, а их восстановление может затянуться на долгое время.

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

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

Сетевая инфраструктура не менее важна. Сейчас, когда даже домашние роутеры предлагают скорость 10 Гбит/с, облачным провайдерам требуется гораздо бОльшая пропускная способность. Например, для 30 хостов в облаке 10 Гбит/с может и хватить, но при кластере из 1500 хостов не обойтись без 100-гигабитных интерфейсов. Такая пропускная способность нужна для того, чтобы эффективно обрабатывать актуальные объемы трафика данных.

Важно также разделение сетей: если провайдер использует один и тот же физический интерфейс для передачи данных между виртуальными машинами и трафика СХД, то это может привести к коллапсу всей системы из-за перегрузки, вызванной всего лишь одной «забуксовавшей» виртуальной машиной. Для поддержания нужного уровня отказоустойчивости трафик нужно «разводить», но разделение сетей на сегменты (SAN и Ethernet, а также Infiniband) удваивает издержки.

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

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

Российские вендоры open source-решений виртуализации все еще находятся в стадии роста, поэтому у них, скорее всего, недостаточно ресурсов и опыта для устранения специфических проблем, которые могут возникнуть в конкретном ЦОДе. Значит, команда провайдера должна уметь самостоятельно справляться с трудностями, зачастую обходясь без каталога типичных ошибок и вопросов, что весьма непросто при наличии «детских болезней» у многих новых решений.

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

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

В контексте информационной безопасности важно различать, какие сервисы компания использует для собственных нужд, а какие предлагает клиентам. Несоответствие между этими двумя аспектами может свидетельствовать о потенциальных уязвимостях в облачной инфраструктуре. Многие провайдеры стремятся настроить свою инфраструктуру согласно требованиям регуляторов, что позволяет обеспечить высокий уровень защиты, в том числе с помощью систем типа IPS, SIEM и SOC. В таком случае провайдер способен устранять ИБ-проблемы клиентов так же, как свои собственные, теми же ресурсами и с такой же эффективностью.

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

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

В legacy-системах, перенесенных в облако без должной подготовки, часто возникают проблемы производительности и стабильности, так как исходно они не были «заточены» под такую эксплуатацию. Cloud native-приложения разрабатываются с учетом специфики облачной среды, что позволяет им максимально использовать ее возможности. Они основаны на микросервисной архитектуре, где приложение разделено на множество независимых сервисов, каждый из которых выполняет свою функцию. 

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

Cloud native-приложения более гибкие, их легче масштабировать, благодаря чему можно калибровать и добавлять объемы СХД, вычислительные и сетевые ресурсы по мере необходимости. Это, в свою очередь, обеспечивает высокую устойчивость к сбоям, поскольку проблемы в одном компоненте не останавливают всю систему. А автоматизация процессов разработки и развертывания позволяет производить обновления быстро и с минимальными рисками.

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

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

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

***

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

Заметили неточность или опечатку в тексте? Выделите её мышкой и нажмите: Ctrl + Enter. Спасибо!