Маркетинговые описания облаков обещают много благ: эти технологии оптимизируют расходы на ИТ, трансформируют инфраструктуру, делают ее более адаптивной. И это — чистая правда. Вот только на практике получить преимущества от облачных технологий в «кровавом Enterprise» оказывается непросто. Почему? Крупные компании при смене платформы чаще всего тянут в облака привычные им подходы и ставят перед своей ИТ-инфраструктурой те же самые задачи — надежная защита критически важных данных, обеспечение высокой производительности для информационных систем. И чаще всего мечты об облаках налетают на суровую реальность и разбиваются вдребезги. Так как же подружить современные тенденции и строгие стандарты крупных корпораций?
Самый простой и надежный способ выполнить требования бизнеса — полная репликация всех данных с созданием отказоустойчивых конфигураций. Богатые компании чаще всего создают две абсолютно симметричные инфраструктуры в разных ЦОД (или даже строят одинаковыми сами ЦОД) и поверх этой «растянутой» инфраструктуры сразу в двух дата-центрах работают приложения. Случится сбой, а бизнес не почувствует его: виртуальные машины перезапустятся, кластера баз данных переключатся на выжившую половину, и «шестеренки» продолжат крутиться.
Как именно реализовать такую инфраструктуру — понятно. Дублируй и наслаждайся. Но такие решения очень дороги. Каждый сервер, каждый гигабайт хранилища и все компоненты информационных систем должны быть задублированы. К тому же, кроме защиты от выхода дата-центра из строя, многие системы требуют еще и локального резервирования, чтобы быстро восстанавливаться после сбоев попроще. А это уже трёх- или даже четырехкратное дублирование ресурсов, а значит, еще больше денег на ИТ-инфраструктуру. Так что же делать тем, кто не может или не хочет ступать на эту дорогу?
Может не надо так сильно Active?
А откуда вообще появляется потребность в растянутой ИТ-инфраструктуре и резервировании систем в двух ЦОД по модели Active-Active?
На заре времен, когда приложения писались на уже давно забытых языках, очень мало кто задумывался о катастрофоустойчивости и масштабировании системы за пределы серверной комнаты. Но именно оттуда нам по наследству досталось множество ИТ-систем, в своих архитектурах не предполагающих каких-либо излишеств, кроме разделения на уровень Front-End (Web server, App server) и Back-End (DB server). С годами пользователей таких систем становилось все больше, росла их важность для бизнеса, а вместе с этим — и требования к их надежности. Так свет увидели отказоустойчивые кластеры, кластеры виртуализации и, наконец, решения, которые вообще могли спрятать от неповоротливых старичков (или, как их еще называют, Legacy-систем), что там находится ниже уровня операционной системы.
Потом уже многие сервисы были переписаны, появились целые классы приложений с новой архитектурой, приложения научились делиться на несколько слоев, превратились в наборы функциональных кубиков (микросервисов) и вообще, стали лучше, красивее, главное, умнее. Что, если теперь им больше не нужны все эти инфраструктурные фишки типа кластеризации, репликации на уровне СХД и т.д.?
Это в теории. Почти в каждой большой компании с историей в продуктиве есть старые Legacy-приложения и новые, причем разной степени модности. А кроме того, эти приложения реализуют разные сервисы, некоторые очень важные — так называемые «золотые коровы» (процессинг в банке, биллинг в телекоме, CRM в ритейле и т.д.) и неважные, вплоть до неиспользуемых и всеми забытых. Так вот именно здесь и кроется ответ на вопрос «А нужно ли строить дорогую ИТ-инфраструктуру?»
Место облаку
Большому кораблю — большое плавание. Эта поговорка хорошо описывает правильный подход к выбору ИТ-архитектуры для разных типов приложений. Дорогие способы организации надежности можно и нужно применять для «золотых коров», особенно если они еще и Legacy, если остановка системы приведет к проблемам в работе важного бизнес-процесса, приносящего деньги или предотвращающего убытки. Ну, или когда приложение очень требовательно к производительности и пожертвовать ею слишком рискованно.
А что же с остальными? Для них можно выбрать что-то простое, не такое дорогое и более гибкое. Требования-то ниже, и есть простор для маневра. Здесь как раз и напрашивается идея использования облаков как инструмента оптимизации расходов на ИТ-инфраструктуру.
Катастрофоустойчивость в облаке и не только
Очень часто я сталкиваюсь с мнением, что перенос ИТ-инфраструктуры в облако сам по себе решает задачу защиты систем от отказа ЦОД. Это заблуждение и опасная иллюзия. И породила ее не алчность сервис-провайдеров (они никогда такого не утверждали), а человеческая склонность к упрощению. Налицо ошибка мышления: если мы чего-то не видим, то этого и нет. В публичном облаке мы не знаем, на каком железе работают виртуальные серверы, но это не значит, что отказывать там нечему. Сервисы в облаке горят так же хорошо, как и в любом другом ЦОД, с такими же последствиями, и недавний пожар в ЦОД во Франции тому подтверждение.
Но это не значит, что облака бесполезны в вопросах создания катастрофоустойчивости. Наоборот! Причем они могут сделать это лучше, быстрее и иногда дешевле — все как в рекламе облачных провайдеров.
Как это делается? У нас есть виртуальные серверы, для которых со стороны бизнес-процессов нет требований быстрого рестарта в случае гибели ЦОД. Некритичные сервисы могут и полежать. То есть мы можем держать их в РЦОД в выключенном виде и переносить туда не синхронной репликой, а любой из возможных технологий репликации виртуальных машин на основе snapshot-ов (Snapshot shipping), и запускать по необходимости. При этом ничто не мешает держать такие «холодные» виртуалки в публичном облаке и не резервировать под них собственное железо. У многих сервис-провайдеров даже есть дешевые тарифы (модель Pay as you Go), которые предполагают использование вычислительных ресурсов не более N часов в год. Удобно ведь? РЦОД есть, а платить за него нужно «по факту». Безусловно, тут есть свои подводные камни: и организационно, и технически такое решение сложнее, чем Active-Active. Но финансовая выгода обычно такова, что игра стоит свеч.
В тоже время только ради DR городить гибридные ИТ-инфраструктуры не совсем логично и рентабельно. Вторым шагом использования облаков в Enterprise может стать возможность быстрого получения вычислительных ресурсов под разработку и тестирование новых продуктов. Далеко не каждый результат труда группы разработки увидит свет продуктив, так зачем тратить время и деньги, закупая железо, если можно получить виртуальные серверы в том же облаке, погонять новый продукт в разных конфигурациях и «схлопнуть» ресурсы в случае необходимости. Закупать железо на постоянку можно, когда на руках окажутся результаты тестов.
А что дальше?
Как получить выгоду от возможности облаков выдавать ресурсы по запросу, мы поговорили. Но современные публичные облака — это не магический куб с ресурсами, которые хорошо покупать кусочками по арендной схеме. Сервис-провайдеры предлагают целый набор различных ИТ-услуг: от банального администрирования «переехавших» в облако ОС и приложений до доступа к готовым сервисам вроде СУБД, СРК, SDN и т. д. Но могут ли они принести реальную пользу компаниям с ИТ-инфраструктурой Enterprise-уровня?
Когда мы в самом начале поста говорили про решение «для богатых», забыли упомянуть важную вещь, а именно задачу хранения резервных копий (РК). В идеологии Active-Active все резервные копии всех систем нужно не только хранить в ЦОД, где эти системы живут, но и обязательно дублировать на вторую площадку. Иначе в случае потери ЦОД с бэкапами вторая площадка окажется без защиты от логических ошибок на уровне данных, а значит, каждый день жизни в РЦОД будет грозить потерей данных в невероятных объемах.
Такой подход к хранению резервных копий правильный, но и в нем есть множество нюансов. Собственные решения для хранения РК стоят денег, их дублирование тоже, а в реальности нужны они крайне редко. Так почему бы не допустить идею, что не все бэкапы «одинаково полезны»?
Тут снова применимы облака со своими дешевыми облачными хранилищами. На ресурсах сервис-провайдера действительно можно создать огромные хранилища, стоимость хранения в которых будет очень низкой. Обычной компании такие объемы будут просто не нужны. Чаще всего такие хранилища построены на технологии S3, относительно новой, но прекрасно поддерживаемой основными решениями для резервного копирования. Все, что нужно — арендовать необходимый объем и прописать ссылку в корпоративной СРК. Многие возразят, что доступ к РК через интернет медленный, что сервис-провайдер не гарантирует скорость восстановления. Да, но речь идёт о бэкапах нужных, но неважных сервисов. Важное и срочное хранится в собственном ЦОД.
Минус полкластера
Как вы, наверное, уже заметили, вся облачная история, о которой мы тут беседуем, основывается на главном — разделении систем на критичные и некритичные. Если не понимать, как устроены системы, где и какие данные хранятся, в каких процессах участвуют и для чего служат, то внедрять облака в продуктиве сложно и порой опасно. В одной компании инженеры зарезервировали виртуальный сервер в холодном виде в облаке, а это оказался шлюз платежной системы, и без него полпроцессинга банка не работает. И всё бы ничего. Но когда, на беду, основной ЦОД оказался отключен от электропитания, и все компоненты процессинга перезапустились в РЦОД, пресловутая виртуалка со шлюзом «не включилась» и испортила всю малину.
Какие системы предстоит запустить в облака, определяет еще и финансовый фактор. На проекте для крупного ритейлера мы проанализировали инфраструктуру и выделили четыре типа систем:
Тип 1 — самые требовательные к инфраструктуре и ее надежности системы. Размещаются только на On-Premises решениях, обеспечивающих синхронную репликацию и быстрое восстановление.
Тип 2 — содержат в своей инфраструктуре требовательные компоненты (СУБД). СУБД размещается On-Premises, а сервера приложений переносятся в IaaS.
Тип 3 — целиком располагаются на виртуальных машинах и не предъявляют особых требований к надежности и доступности. Все компоненты размещаются в IaaS.
Тип 4 — Core Infrastructure Service, такие как DNS, сервисы двухфакторной аутентификации, Active Directory и пр. Они должны быть развернуты во всех средах, без вариантов. Обеспечивают базовый функционал для ИТ-систем и On-Premises, и в облаке.
В результате оказалось, что систем первого типа в инфраструктуре всего 15%, а значит, можно смело резервировать большую часть компонентов в облаке.
Когда все это разложили на виртуальные машины, в облака могли переселиться больше половины ВМ (61%). Получилось сэкономить 50% бюджета на создание Active-Active кластера между двумя ЦОД, а для остальных — построить вполне себе рабочую Active-Passive конфигурацию с холодным резервированием и скриптами для автоматизированного запуска «по кнопке».
Другой пример — снижение стоимости off-site хранения резервных копий в одном крупном банке. Как и у многих других компаний, исторически для длительного хранения (более 4-х недель) использовались дополнительные ленточные библиотеки, установленные за пределами основных дата-центров. По политикам резервного копирования отдельные резервные копии после записи в основное хранилище дублировались на отдельную площадку и записывались на ленты. С учетом объемов поддержка такой инфраструктуры хранения оборачивалась огромными затратами, так как резервные копии должны были быть доступны и их нельзя было хранить вне библиотеки. К тому же сами библиотеки требовали постоянной модернизации, а ленточные накопители — замены.
Идея использовать для решения данной задачи облачное S3-хранилище родилась сразу после обследования. В результате перевода РК в S3 удалось не только снизить стоимость хранения, но и трансформировать затраты на копии, заменив бюджеты на закупку библиотек ежемесячными платежами. Наконец-то расходы подразделений банка на хранение данных стали прозрачными.
Путь до облака
Безусловно, идеальный облачный путь — пересоздать свои ИТ-системы «с нуля» в этом самом облаке. Сразу построить их так, чтобы они изначально имели сloud-native архитектуру и основывались не на устаревших принципах, а правильно использовали доступные в облаках сервисы и технологии.
Но что же делать тем, кто не может себе этого позволить или просто не хочет затевать облачную революцию? Для них тоже есть выход.
Вот основные шаги на пути трансформации своей инфраструктуры.
Шаг 1. Провести работы для полноценной классификации информационных систем. Нужно собрать данные по всем компонентам инфраструктуры, определить реальные RTO/RPO для каждой системы, подготовить ресурсно-сервисные модели, чтобы корректно оценить количество ресурсов, необходимое для каждого класса критичности, подготовить списки оборудования, которое можно переиспользовать (например, перенести в РЦОД), а какое нужно закупить. Когда на руках появится вся необходимая информация, можно будет понять реальные возможности по использованию облачных сред и принять экономически обоснованное решение о дальнейшем развитии.
Шаг 2. Выбрать правильного поставщика услуг IaaS/PaaS/SaaS, то есть сформировать ТЗ с учетом потребности «периодического» использования арендуемых ресурсов, договориться об условиях резервирования и запуска ВМ в случае аварийного восстановления. Также важно сразу понять, какие готовые сервисы может предоставить тот или иной провайдер, и как они реализованы.
Шаг 3. Мигрировать в целевую инфраструктуру те ИС, которые по итогам обследования оказались не на своих местах. Здесь главное — подготовить планы миграции, создать Active-Active инфраструктуру для наиболее требовательных систем, максимально использовать существующее оборудование из всех ЦОД, перенести все компоненты систем на соответствующие им платформы.
Шаг 4. Продолжить развитие гибридной инфраструктуры. Когда основные сервисы будут правильно размещены и образуется тесная и надежная связь собственной инфраструктуры и облачной, можно продолжить расширять интеграцию, быстро и легко подключать новые сервисы, предоставить разработчикам больше свободы и возможностей. Не стоит бояться сложности гибридной инфраструктуры. Многие задачи эксплуатации успешно решаются при помощи систем автоматизации и управления, реализованных на базе одной из Cloud Management Platform (CMP), например Morpheus.
Автор: Сергей Терехин, ИТ-архитектор «Инфосистемы Джет»