Увертюра
Жил да был один Банк. В Банке была хорошая профессиональная команда ИТ-служб, но, как это часто бывает, эксплуатационных задач было больше, чем ресурсов для их решения. В результате вычислительная и сетевая инфраструктуры Банка развивались достаточно стихийно, реагируя на запросы бизнеса «здесь и сейчас».
В какой-то момент в Банке осознали, что риски растут, и обратились к одному из Интеграторов (не к нам) с вопросом: «А что же, собственно, делать?». «А вы знаете, что есть технология Cisco ACI? – ответил Интегратор. – Давайте модернизируем вашу сеть с ее использованием!».
Банк согласился. Интегратор выставил счет на оборудование и лицензии, быстро (дело было еще до начала кризиса полупроводников) поставил обещанные коробки и затих. «А внедрять?» – спросил Банк. «А это уже сами!» – ответил Интегратор и удалился в туман, помахивая маржой.
Банку взгрустнулось, потому что эксплуатационных задач меньше не становилось и запускать самостоятельно совершенно новую для них технологию было бы, мягко скажем, непросто. Но он вовремя вспомнил, что интеграторы всё-таки бывают разные – и обратился в STEP LOGIC.
Акт первый. На белом коне
Если кто не в курсе, классический системный интегратор – это большой шевелящийся аккумулятор экспертизы. В отличие от эксплуатационных служб, целью которых в большинстве случаев является доведение до совершенства одной конкретной инфраструктуры, находящейся в зоне ответственности эксплуатации, специалисты интегратора умеют быстро решить любую задачу из их области знаний «здесь и сейчас» и отдать получившееся той самой эксплуатации. Поэтому если вы не знаете, как именно решить вашу задачу, скорее всего интегратор сможет помочь вам с ее решением, если это, конечно, будет ему экономически выгодно. И даже если знаете как, но рук не хватает – это тоже случай, когда нужно звать интегратора.
До этого случая мы имели опыт с Cisco ACI на нескольких пилотных внедрениях и поэтому с удовольствием взялись за задачу. Но для начала нужно было разобраться в том, как устроена сетевая инфраструктура Банка до модернизации.
Результат стихийного развития действительно несколько обескураживал, и специалисты Банка совершенно справедливо решили, что так дальше жить нельзя. Весь ЦОД располагался в цокольном этаже одного здания, ядром служила VSS-пара коммутаторов Cisco Catalyst 6500, давно находящихся в End-of-Life статусе и далеко не факт, что способных загрузиться после пропадания электропитания. Поскольку вычислительная инфраструктура росла вслед за требованиями бизнеса, а сетевая за ней не успевала, то серверы включались в свободные порты разных уровней, так что говорить о выделенном модуле серверной фермы было нельзя.
Так что не только катастрофоустойчивости, но и отказоустойчивости сетевой инфраструктуры, по сути, не было.
Совместно со специалистами Банка наши инженеры определили основную задачу проекта как построение телекоммуникационной и вычислительной инфраструктуры Банка в двух географически разнесенных дата-центрах и разнесение между этими дата-центрами IT-сервисов для обеспечения катастрофоустойчивости инфраструктуры.
Наши коллеги из департамента вычислительных систем погрузились в анализ и проектирование серверной инфраструктуры (что было ничуть не менее сложной задачей, но про нее они, возможно, расскажут отдельно), а мы дружно накинулись на наш проект внедрения технологии Cisco ACI.
Антракт. Технология Cisco ACI
На хабре есть несколько статей, рассказывающих о том, что такое ACI, куда его едят и какие компоненты лежат в его основе. Чтобы не делать текст «еще одной статьей про технологию», расскажу коротенько об основных моментах, а более подробно и достоверно технически можно почитать, например, здесь.
Итак. Представьте себе сеть ЦОДа. В далеком прошлом, ближе к динозаврам, трафик ЦОДа гулял в направлении «Север-Юг», т.е. общение между серверами внутри ЦОДа было гораздо менее активным, чем между серверами и внешним относительно ЦОДа миром. Для такого общения прекрасно подходила классическая трехуровневая архитектура «ядро-распределение-доступ». Но мир пришел к микросервисам, где один запрос из внешнего мира может породить десятки-сотни запросов между разными контейнерами, т.е. основной трафик перешел в горизонтальное направление «Запад-Восток». Причем, равномерное распределение виртуальных контейнеров по физическим серверам фактически приводит к непредсказуемости того, в какой из серверов данный конкретный запрос полетит. Для такой схемы нам важно, чтобы задержка сетевого обмена между любыми двумя серверами была одинаковой, чего трехуровневая архитектура обеспечить не в состоянии.
Сетевики – люди не гордые, они аккуратно сдули пыль с архитектуры середины 20 века, придуманной Чарльзом Клозом для неблокирующих телефонных коммутаторов, назвали ее Leaf-Spine и выдали за самое новое изобретение для ЦОДов. И, знаете, сработало. Теперь у нас на аппаратном уровне была сеть Клоза, над ней underlay-сеть, обеспечивающая L3 ECMP взаимодействие между любыми двумя Leaf-коммутаторами через одинаковое количество хопов, а сверху на это были натянуты технологии VxLAN/EVPN, обеспечивающие работу наложенной сети для обмена трафиком непосредственно между хостами. Такая архитектура сильно облегчила горизонтальное масштабирование. Нужно больше портов – добавили Leaf-коммутатор, подключили ко всем Spine, заработало. Нужно больше производительности коммутации – добавили Spine-коммутатор, подключили к нему все Leaf, заработало.
И вроде всё было хорошо – но вмешался человеческий фактор. Дело в том, что эта архитектура крайне требовательна к консистентности настроек всего сетевого оборудования в ЦОДе. Если новый VLAN – то прописать его необходимо на всех устройствах (иначе, по закону подлости, именно за тот коммутатор, на котором этот VLAN прописать забыли, нуждающаяся в этом VLAN виртуальная машина и мигрирует). Если что-то поменять – то тоже на всех устройствах. И когда у вас этих коммутаторов 5-6, путем небольшого напряжения внимания эту задачу решить можно. А когда 20? А когда 100?.. Стало понятно, что пора автоматизировать решение.
Тут и появляется на сцене Cisco Application-Centric Infrastructure (ACI), о которой у нас сегодня речь. По сути, компания Cisco создала контроллер программно-управляемой сети (называется APIC – Application Policy Infrastructure Controller) и сделала так, что все коммутаторы Nexus 9300/9500, составляющие в решении коммутационное поле, управляются с кластера таких контроллеров.
С некоторой долей упрощения можно представлять себе ACI фабрику как один большой размазанный в пространстве шассийный коммутатор, где коммутаторы Leaf-уровня играют роль линейных карт шассийного коммутатора, коммутаторы Spine-уровня – роль коммутационной фабрики, а кластер контроллеров APIC – роль супервизоров.
Ну и раз мы перешли к централизованному управлению, нам стало гораздо проще отказаться от сетевых критериев для правил взаимодействия и перейти к критериям приложений. Почему это и называется Application-Centric – вместо того, чтобы фильтровать по IP-адресам и прочим сетевым идентификаторам, мы пишем контракты (так называются правила взаимодействия в ACI) о взаимодействии приложений (они же EPG – End-Point Group, например «сервера MS Exchange могут обращаться к серверам MS SQL»), а в настройки сетевого оборудования APIC превращает это всё самостоятельно. Попутно мы радуем специалистов по информационной безопасности, потому что такая схема существенно облегчает внедрение Zero Trust Policy – «запрещено всё, что не разрешено явно». Ну и, разумеется, нас ничто не заставляет останавливаться только на уровне физических коммутаторов, поэтому мы легко опускаемся внутрь ферм виртуализации и элементами политик в ACI становятся виртуальные машины и контейнеры, что существенно упрощает сетевую часть для CI/CD и радует DevOps’ов.
Впрочем, сетевые инженеры классической школы не настолько рады, так как переход к логике приложений действительно переворачивает большую часть методов работы с сетью. Чтобы подсластить пилюлю и сделать переход более плавным, в Cisco ACI есть режим Network-Centric, который позволяет внутри политик оперировать привычными VLANами и IP-адресами. Но даже при этом изменения в логике работы сети достаточно сильны, чтобы вызвать у сотрудников некое первичное отторжение.
Внутри Cisco ACI могут использоваться три основных архитектуры:
Single PoD (Point of Delivery). Самый первый вариант архитектуры, в котором все оборудование и серверы APIC-кластера находятся на одной площадке.
Multi-PoD. В этой архитектуре мы, разделяя оборудование физически и организуя на каждой площадке свою Leaf-Spine сеть, все еще управляем всем через один APIC-кластер, который при этом тоже разносится на разные площадки. В этом случае мы получаем так называемую «растянутую» фабрику (stretched fabric), для качественной работы которой жизненно важно обеспечить низкую задержку в канале связи между площадками (требования производителя – не более 50 ms RTT).
Multi-Site. В этой архитектуре каждая из площадок имеет собственный APIC-кластер, синхронизация конфигураций которых производится внешним оркестратором (MSO, Multi-Site Orchestrator). Архитектура позволяет объединять сколь угодно далекие друг от друга площадки, но, очевидно, и дороже, и сложнее в управлении.
Акт второй. Операция на открытом сердце бизнеса.
Эпиграф
Мастер, вытирая руки, сдает клиенту машину и попутно болтает:
- А вот вы кем работаете?
- Кардиохирургом, операции на сердце провожу.
- И много платят?
- 20000 долларов за операцию.
- Ого... А ведь, по сути, одним и тем же занимаемся, движки перебираем, а мне всего 300 долларов платят...
- Хочешь так же, как я, заработать?
- Хочу...
Хирург достаёт из кармана пачку баксов, заводит двигатель:
- Перебирай!
В целом на бумаге ничего волшебно сложного в этой задаче нет, но на практике всегда возникают нюансы.
Одним из них была необходимость сохранить архитектуру модулей фильтрации трафика, поскольку Банк не был готов сразу заниматься еще и перестроением схемы безопасности. Т.е. трафик между разными контекстами безопасности должен был проходить через существующие МСЭ в L2-режиме.
Также Банк решил не пытаться объять необъятное и на первом этапе сохранить сетевую логику модели построения (привязку существующих серверов к VLAN), поэтому была выбрана модель Network-Centric.
Но, пожалуй, самым важным требованием было выполнение работ с обеспечением непрерывности всех бизнес-процессов. Вычислительная инфраструктура Банка, очевидно, не может произвольно останавливаться с формулировкой «Уважаемые клиенты, погуляйте там пару дней без процессинга, пока мы новую сеть настроим». Поэтому какие-то кратковременные плановые остановки были допустимы только в заранее согласованные окна, а в целом работы планировались так, чтобы доступность сервисов Банка не прерывалась.
Для этого нашими инженерами был разработан план внедрения из 65 этапов, каждый из которых был заранее проверен на стенде, обложен механизмами тестирования корректности функционирования и планами отката на исходное состояние в случае, если что-то пойдет не так.
Столь тщательная подготовка принесла свои плоды – несмотря на то, что окна иногда согласовывались неделями, а инженеры с хотя и оплачиваемыми, но всё же тяжелыми ночными переработками стали напоминать сов, внедрение прошло без единого нарушения банковских процессов.
Итак, что же получилось в итоге?
Банк получил современную распределенную на две площадки дата-центровую сеть, построенную по технологии Cisco ACI Multi-PoD и сегментированную на следующие модули:
модуль серверной фермы
модуль ядра
модуль внутренней фильтрации
модуль внешней фильтрации
модуль внешних подключений
модуль транспортной сети
Для каждого из модулей мы реализовали глобальную отказоустойчивость (она же катастрофоустойчивость) через разнесение равноценных элементов модуля между дата-центрами. Для всех модулей, кроме модулей фильтрации, также была реализована и локальная отказоустойчивость (внутри дата-центра). Модули фильтрации, как мы помним, пока что унаследованы из старой сети и будут модернизироваться Банком в следующий подход.
Модуль транспортной сети был организован на базе технологии DWDM над парой независимых оптоволоконных трасс между площадками. Выбор такой архитектуры во многом опирался на желание построить Multi-PoD и, как следствие, жесткое ограничение по RTT между компонентами фабрики.
Модули ядра и серверной фермы построены с использованием закупленных Банком ранее коммутаторов Cisco Nexus 9300/9500.
Финал. Зачем?
Конечно, выбор технологии Cisco ACI не столь однозначен, чтобы сразу и безоговорочно рекомендовать ее для сети любого дата-центра. Но у этого решения в нашем случае есть очевидные плюсы.
Прежде всего, сеть в современном дата-центре – это фундамент, на котором строится вся информационная инфраструктура. Внедряя Cisco ACI, Банк подготовился к планируемому росту количества сервисов и объема трафика так, что сеть не потребует никаких концептуальных изменений при этом росте – только приобретения и инсталляции новых коммутаторов для обеспечения необходимого количества портов.
Возможности внедрения Zero Trust Policy и управления взаимодействием напрямую между виртуальными машинами и контейнерами вызвали интерес соответствующих смежных подразделений и при надлежащем освоении дадут синергический эффект.
А мы, как исполнители проекта, горды тем, что осуществили одно из первых внедрений Cisco ACI в архитектуре Multi-PoD в России и при этом смогли соблюсти все требования заказчика, в том числе обеспечить непрерывность бизнес-процессов Банка во время внедрения. Покупайте наших слонов!
