Как мы соединяли свой ЦОД с ЦОДом заказчика

Представьте задачу:

• Вы решили стартовать IT-проект, который требует большой вычислительной мощности.
• «Взлетит» он или нет, станет понятно через 3 месяца.
• Космически дорогое железо (несколько серверов по цене квартиры в Москве каждый) покупать не хочется, но при этом надо сразу стартовать так, чтобы потом не было сложностей с масштабированием до серьёзной highload-системы, то есть хочется эластичного «облака».
• В перспективе — необходимость быстро обрабатывать много данных и массу операций чтения-записи. То есть, потребуются тяжелые сервера-«молотилки», которые не могут горизонтально масштабироваться – такое в «облако» не запихнёшь.
• При этом надо создать единое сетевое пространство, как если бы «молотилки» вашего ЦОДа и сервера «облака» находились в соседних стойках, и настроить всё так, чтобы на уровне приложений не приходилось думать про физическое воплощение железа;
• Обеспечить адекватную техподдержку, которая способна закрыть все вопросы по проекту (сеть, сервера, прикладные системы) — и всё это без поиска новых администраторов себе в штат.
• До кучи — запуститься очень быстро;
• И всё это —в Москве, чтобы обеспечить минимальные лаги.

В начале этого года к нам пришел заказчик именно с такими задачами.

Напомню, КРОК работает с достаточно серьезными заказчиками уровня крупных банков и компаний телеком-отрасли. Для таких заказчиков у нас есть три своих дата-центра, плюс мы уже построили десятки ЦОДов различным компаниям.

Первое, что нужно для стабильности и управляемости — это связность ЦОДов и высокая доступность каналов. У нас есть оптическое кольцо между нашими ЦОДами с выходом на MSK-IX для прямого выхода в «большой Интернет». Физически это кольцо — два оптических канала в разных канализациях.

С точки зрения аварийного восстановления, даже попадание метеорита в один из дата-центров не означает отказа системы: если у банка, например, предусмотрены disaster-recovery решения, то второй ЦОД тут же подхватит упавшие сервисы.

В ЦОДах доступны услуги сollocation (размещение стоек/оборудования) и предоставление виртуальных вычислительных ресурсов на базе «облака» — машин, дисков и сетей.

Архитектура проекта имела стандартную трёхуровневую схему:

1. Веб-машины, принимающие запросы пользователей (фронтэнд).
2. Серверы приложений, обрабатывающие запросы.
3. Серверы баз данных: чтение-запись, на жаргоне – «молотилки».

Первые два пункта – это обычное облако с “иксовым” железом (x64). При необходимости облако горизонтально эластично масштабируется и даёт столько вычислительной мощности, сколько нужно. На третьем уровне в перспективе потребуется железка из категории так называемых «тяжелых» UNIX-серверов.

Допустим, сейчас третий пункт заказчика не волнует. Но когда заказчику надо будет вырасти, на третьем уровне потребуется RISC-сервер, стоящий многие миллионы. Эти штуки работают под управлением особенных операционок (AIX, HP-UX и так далее). Перечисленные ОС не работают на обычном х64 железе, на котором работают Windows или Linux ОС. Соответственно, например, AIX не получается сделать на виртуальных ресурсах x64. Решение такое: ставим тяжелую железку, подключаем к ней дисковый массив, а затем «втыкаем» всё это дело в «облако» через специальный шлюз, чтобы физические и виртуальная сеть смогли заработать в связке. Грубо говоря, миддлэнд из x64 обращается к «молотилке» как к ресурсу своей сети.

IBM Power 795: одна из «тяжелых» машин

По задаче эти затраты надо преобразовать из капитальных в операционные. И здесь начинается самое интересное: дело в том, что мы разворачиваем железо под проект, просто предлагая необходимый сервис. Для заказчика это означает, что все расходы — это аренда и поддержка.

Стартовый расклад

• Заказчик— крупная финансовая организация. У него есть перспективный проект, который требует больших вычислительных ресурсов и работы с большой базой. При этом он считается «стартапом» внутри компании, то есть, есть шанс, что «взлёт» не состоится, и потому покупать железо и выделять отдельную команду просто нецелесообразно.
• Нужно быстро стартовать, при том что в ИТ-команде со стороны заказчика – только 2 человека: ИТ-руководитель проекта и его заместитель, без инженеров (потому что пробный проект).
• Работает тяжеленный Oracle Siebel CRM, что сразу поднимает сложность проекта от обычной до крайне высокой (с учётом требований по защите информации, масштабируемости и доступности).
• Нужно минимизировать расходы на случай, если проект «не взлетит».
• Есть две площадки, наш ЦОД и ЦОД заказчика, тоже в Москве. У нас — публичное облако, внутри которого развёрнуто VPC (Virtual Private Cloud). В VPC есть виртуальные сети, в сетях виртуальные серверы. ЦОД заказчика подключается к изолированному куску (VPC) облака.

Задачи и решения

1. Полное управление сетевой средой в облаке КРОК как в своём ЦОД
В публичном облаке все сети имеют заранее заданную внутреннюю адресацию. Если эта адресация пересекается с адресацией ЦОД заказчика, наступает натуральный взрыв мозга. Проблема сложнее, чем может показаться на первый взгляд: нужно убедиться в том, что таких пересечений нет на старте проекта, плюс в том, что их не будет архитектурно в принципе, как бы проект дальше ни шел. Вот зачем понадобился VPC: эта штука позволяет заказчику самому контролировать адресацию и прочие настройки облачной сети из портала самообслуживания.

2. Безопасный доступ и полный контроль
Сети внутри ЦОДа заказчика должны напрямую соединяться с сетями в нашем облаке. Грубо говоря, нужно сделать так, чтобы внутренние администраторы даже не понимали, где они находятся, в своем ЦОДе или в виртуальном. Это гибридное облако: у заказчика есть свои ресурсы (не очень много физического железа), плюс есть наша облачная платформа, которая может отдавать столько мощности, сколько нужно. На жаргоне — эластичная пристежка к своему ЦОДу под полным контролем администраторов заказчика.

Используются каналы связи точка-точка, когда в обмене между ЦОДами никто, кроме заказчика, не участвует. На физическом уровне это два канала независимых провайдеров. Они работают в режиме — active-active с балансировкой нагрузки и автоматическим переключением в случае падения одного из них. В ЦОДе у нас и у заказчика стоит каналообразующее оборудование — маршрутизаторы Cisco — раздающее данные по сетям дальше. В общем, мы научились шлюзовать прямые линки от заказчиков в «облако», так пока никто не умеет. Скажите любому провайдеру облаков: «А можно, мы к вам в облачко свою дырочку просверлим, а то ваш интернет-канал общий нам не особо приглянулся? А две дырочки? А оборудование свое в ваше облако можно?» Ответ предсказуем. А решение, если оно вообще есть, не будет отличаться гибкостью.

3. Нужен был сервер для записи разговоров call-центра
Использование облачной платформы здесь не совсем подходит, поскольку специфика подразумевает запись большого объёма данных, которые пришлось бы гонять по сети из ЦОДа в ЦОД. Это не совсем правильно: есть риск «забить» каналы. Оптимальный вариант — железо на стороне заказчика. Учитывая требования минимизации капитальных затрат, мы предоставили оборудование в аренду заказчику и поставили на его стороне.

4. Полная поддержка
Естественно, заказчику нужна была полная техподдержка облачной платформы, сетевого оборудования, прикладного ПО, информационной безопасности, бэкапов (EMC AVamar). Обеспечили, настроили. Задачи стандартные для больших проектов, всё же это специфика интеграторов.

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

Итог

ЦОД — в аренде. Облако — в аренде, сервер для call-центра и всё сетевое оборудование — тоже в аренде. Техподдержка оплачивается помесячно. Заказчику не потребовалась новая IT-команда. При необходимости добавить ещё вычислительной мощности, это делается два клика в портале самообслуживания облака.

Если проект «не выходит» — аренда прекращается, риски минимальны.

Если «взлетает» — продолжается комфортная работа. При увеличении потребности в ресурсах заказчик просто запускает их, система легко масштабируется: никуда переезжать не надо, и архитектура не меняется. За безопасность, масштабирование, поддержку, доступность и другие вопросы отвечает очень сильная сработанная команда. С точки зрения IT-отдела заказчика — есть один контактный менеджер, который всё решает.

P.S. Конкретно этот проект «взлетел».

Автор: MBerezin