«Замена колес на ходу». Как мы перенесли продуктив на новую сетевую инфраструктуру и при этом ничего не уронили

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

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

Перемен! — требуют наши сердца

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

Сетевая инфраструктура вполне удовлетворяла текущим потребностям, и все же масштабы планируемого развития бизнеса предполагали не только значительное увеличение трафика, но и, в результате роста числа единиц оборудования, предъявляли качественно новые требования к автоматизации процессов управления и мониторинга.

С архитектурной точки зрения мы имели растянутую L2-фабрику c классическим разделением на уровни Core, Distribution и Access. Шлюз по — умолчанию для серверных подсетей терминировался на устройствах Catalyst 3850.  Для резервирования виртуального адреса GW на L3-интерфейсах SVI и обеспечения резервируемого подключения пар коммутаторов друг к другу использовалась технология Cisco Stack, а для защиты от L2-петель — протокол RPVST+. Внешняя маршрутизация реализовывалась с помощью выделенного VLAN SVI с маршрутом по умолчанию в сторону кластера межсетевого экранирования.

Анализ показал, что для обеспечения возможности развития сервисов нам потребуется:

1. Увеличить пропускную способность сети в целом, а также производительность ядра;

2. Обеспечить широкие возможности масштабирования сетевой инфраструктуры на всех уровнях;

3. Реализовать централизованную систему управления, мониторинга и автоматизации.

Словом, жизнь не стояла на месте, бизнес рос, а с ним — требования к ИТ-инфраструктуре и наша сеть, в том числе, требовала масштабной модернизации.

Выбери меня, Выбери меня, Птица счастья завтрашнего дня

Ноябрь 2020 года.

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

• соответствие современным требованиям производительности;

• использование открытых стандартов реализации;

• возможность бесшовной миграции на новую инфраструктуру;

• интегрированная система управления и мониторинга;

• программно-определяемая решение (SDN) и широкие возможности по его автоматизации;

• надежность и предсказуемость;

• поддержка VXLAN.

После первых исследований нескольких решений стало очевидно, что в части «железа» платформы различных вендоров имеют много общего: количество портов, их результирующая стоимость, число основных таблиц коммутации, маршрутизации и даже показатели производительности. Законы физики и математики едины для всех, и получить ощутимую выгоду, базируя свои критерии только в области hardware, практически невозможно. Зато, полет мысли разработчиков программного обеспечения, как в части операционных систем для сетевого оборудования, так и в области централизованных решений для управления им, создает масштабное поле для конкуренции. Например, серьезное преимущество имеют продукты с единой операционной системой среди различных семейств сетевого оборудования, а также наличие централизованного решения от вендора для построения и управления программно-определяемыми сетями и использованием концепции Infrastructure as a Code (IaaC).

Реализация этой концепции так же требует строгого соответствия открытым стандартам протоколов, но дело не только в этом. Аккуратность производителя в данном вопросе – залог вашего спокойствия при использовании мультивендорной (например, в процессе миграции) инфраструктуры. Страховка от того, что вы не будете рвать на себе волосы, когда без объявления войны и по непонятным причинам развалится ваш BGP EVPN просто потому, что его конкретную реализацию писали разработчики разных вендоров.

Внедрение «Infrastructure as Code» не является самоцелью. Выгода от наличия унифицированной системы управления для нас лежала, прежде всего, в области в автоматизации процессов, скорости развертывания решения и контроля состояния сети. Когда вы мигрируете «боевые» сервисы на новую инфраструктуру критически важным является мгновенное понимание того, что «что-то пошло не так». Наличие же инструмента позволяющего получить данные телеметрии и в режиме стриминга транслирующего вам информацию не только об ошибках и нагрузке, но и состояние таблицы маршрутизации, аппаратных таблиц коммутатора — позволяет быстро локализовать проблему и в кратчайшие сроки ее решить. Все это не умаляет необходимости автоматизации. Чем крупнее проект, тем острее стоит этот вопрос. Возможность автоматизированного конфигурирования и контроля изменений становится необходимостью, когда счет оборудования идет на сотни единиц. Безусловно, на рынке достаточно систем управления, позволяющих получить практически тот же функционал, что предлагают ведущие производители оборудования, но при этом, зачастую требуют колоссальных ресурсов прежде всего ваших специалистов для развертывания и внедрения.

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

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

Ставки сделаны. Ставок больше нет

Если взглянуть на квадрант Гартнера на протяжении последних 5 лет, то станет очевидным, что с учетом наших требований, выбирали мы между решениями Cisco и Arista.

Решения обоих производителей очень похожи и каждое из них имеет свои плюсы. В нашем случае одной из основных причин сделанного в итоге выбора выступил функционал системы автоматизации Arista CloudVision Portal (CVP). Высокая степень унификации системы, дружелюбности и информативности интерфейса, а также возможности автоматизации и интеграции с нашей инфраструктурой перевесили чашу весов в пользу решения от Arista.

Разумеется, система управления — это еще не вся сеть, но и сетевое оборудование Arista не только поддерживало все необходимые открытые стандарты, но еще имело простой и надежный hardware-дизайн.

Немаловажным фактором при принятии решения о выборе платформы было и мнение наших коллег из других компаний, которые уже имели продолжительный опыт работы с оборудованием от Arista Networks. Несмотря, на то, что вендор не так широко известен, как Cisco, их отзывы в отношении Arista были весьма лестными и свидетельствовали о достаточной зрелости и качестве продукта. Хотя на этапе внедрения они и испытывали сложности просто потому, что, по их же словам, он не так широко распространен.

Словом, взвесив все «за» и «против», подсчитав бюджеты и необходимое количество успокоительного мы приняли решение о развёртывании нашей новенькой, сверкающей сетевой инфраструктуры на базе оборудования Arista.

На референсы надейся, но решения пилотируй

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

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

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

Amat victoria curam (лат.) — Победа любит подготовку

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

• Использование архитектуры на основе сетей Clos fabric, известное также как архитектура Leaf-Spine, с применением технологии VXLAN EVPN;

• Использование распределенной маршрутизации на коммутаторах уровня Leaf с использованием технологии Anycast Gateway;

• Общие требования по отказоустойчивости решения на уровне каждого архитектурного элемента ЦОД с целевыми значениями сходимости решения после отказа в пределах 1 секунды;

• Обеспечение сегментации с помощью наложенных (Overlay) L2/L3 сетей, растянутых как внутри ЦОД, так и между двух ЦОД;

• Использование решения, обеспечивающего возможность масштабирования ЦОД по количеству коммутаторов и общей пропускной способности ЦОД в направлении East-West (взаимодействие между серверами в ЦОД);

• Обеспечение надёжности работы и удобства в обслуживании оборудования ЦОД;

• Поддержка балансировки данных на каждом уровне оборудования и оптимальное прохождение трафика в ЦОД;

• Гибкость подключения сервисов в ЦОД и возможности по использованию средств автоматизации;

• Использование системы управления для мониторинга со сбором данных телеметрии и эксплуатации оборудования в обоих ЦОД.

Роли оборудования в нашем проекте:

Все описанные выше требования вылились в следующие основные элементы дизайна ЦОД:

• 3-stage Clos фабрика даже в ЦОД с 80 стойками, используя только single-chip коммутаторы;

• EBGP over EBGP EVPN-VXLAN согласно Arista EVPN Deployment guide;

• Единый EVPN Symmetric IRB домен с Anycast GW распределенного на уровне Leaf;

• L2-сегменты изолированы в рамках одного ЦОД, связность между ЦОД по EVPN Type5;

• EVPN Multihoming All-Active для Dual-homing подключений серверов, межсетевых экранов и L2-коммутаторов старой сетевой инфраструктуры;

• Низкоскоростные медные коммутаторы (10/100/1000 BASE-T) агрегируются с помощью выделенной пары EVPN-коммутаторов;

• Использование выделенной сети внеполосного управления (Out-of-Band Management) максимально независящей от основной сетевой инфраструктуры ЦОД;

Типовой дизайн пары стоек нашего ЦОД выглядел следующим образом:

• 2 x 7050TX3-48C8-R – для презервируемого подключения 10GE-серверов;

• 1 x 7010T-48 – для подключения iDRAC интерфейсов серверов;

В пилотном ЦОД мы использовали 2 коммутатора на уровне Spine. Каждый 10/25GE Leaf коммутатор подключался с помощью 2x100GE аплинков. В основном ЦОДе в последствии были использованы 4 Spine и, соответственно, 4x100GE аплинков. Таким образом уровень переподписки внутри фабрики составил:

• Leaf Copper/AGG – Spine — 1:1.2 (4 x 100G : 48 x 10G);

• Leaf Optical – Spine – 1:3 (4x100G : 48 x 25G);

• Access – AGG — ~1:2.5 (2x10G : 48 x 1G);

Выбранное решение Arista EVPN-VXLAN позволило нам также перейти на IP MTU для серверов равное 9000.

Уровень Underlay.

Основным условием для сигнализации VXLAN-туннелей и обмена BGP EVPN-маршрутами является IP-связность между точками терминации VXLAN. Такими точками в EOS являются служебные интерфейсы Loopback0.

В качестве протокола маршрутизации Underlay Arista рекомендует использовать протокол external BGP (eBGP) по следующим причинам:

• Оптимальное распространение маршрутной информации в топологиях с плотной связностью (dense Clos topologies);

• Поддержка балансировки Equal Cost Multi Path (ECMP) для равномерной загрузки;

• Использование единственного протокола для организации Underlay и Overlay.

При внедрении протокола eBGP для Underlay рекомендуется назначать номера автономных систем (Autonomous System Number, ASN) следующим образом:

• Общая ASN на уровень Spine для сокращения генерации излишних копий маршрутов;

• Уникальные ASN на каждый EVPN-VXLAN коммутатор;

eBGP-сессии устанавливаются на point-to-point интерфейсах с маской подсети /31. Для простоты эксплуатации использовались 16-битные ASN из диапазона (65100-65500).

Уровень Overlay.

В решении Arista протокол MP-BGP переносит BGP EVPN NLRI, использующих инкапсуляцию VXLAN для data-plane. С использованием технологии VXLAN вводятся следующие термины:

• VTEP (VXLAN Termination EndPoint) – точка терминации VXLAN туннелей, располагается на L3 Leaf и Border Leaf коммутаторах. и обычно привязана к IP-адресу логического интерфейса (Loopback0 или Loopback1).

• VXLAN Segment – логический L2 сегмент (широковещательный домен) поверх Underlay сети ЦОД. Аналог VLAN в классической коммутации.

• VNI (VXLAN Network Identifier) – численный идентификатор VXLAN сегмента. Аналог VLAN ID в классической коммутации. Данный термин применяется в документе как обозначение всего VXLAN сегмента;

• BUM (Broadcast, Unknown unicast and Multicast) – аббревиатура для обозначения широковещательного трафика в L2-сегменте;

• HER (Head-End Replication) – способ распространения BUM-трафика путем репликации фрейма перед VXLAN-инкапсуляцией на входном VTEP. Количество репликации зависит от размера VXLAN flood-list;

При передаче данных через VXLAN-туннель оригинальный Ethernet-фрейм (с VLAN tag или без) инкапсулируется в VXLAN заголовок и далее в UDP заголовок длиной 8 байт. VXLAN инкапсуляцию также называют MAC-over-UDP.

Значение Destination UDP Port зарезервировано IANA под VXLAN и равно 4789. Source UDP порт высчитывается на ingress VTEP на основе hash-функции по полям Original L2 frame (в том числе L3 и L4 заголовки оригинального пакета от сервера), таким образом достигается необходимая энтропия для эффективной балансировки на уровне Underlay топологии, в которой помимо полей IP заголовка также учитывается source UDP port.

Для обмена BGP EVPN NLRI между всеми L3-коммутаторами ЦОД использовался набор Overlay BGP EVPN сессий. Под BGP EVPN сессиями далее подразумевается стандартная IPv4 BGP сессия с сигнализированным EVPN address-family (AFI/SAFI).

Топология взаимосвязей и номера ASN Overlay-уровня повторяла Underlay за исключением:

• BGP EVPN сессии строились между Loopback0 интерфейсами коммутаторов;

• Spine и Border Leaf-коммутаторы выступали в роли BGP Route-Server, используя опцию next-hop-unchanged при пересылке EVPN-маршрутов;

Arista CloudVision Portal.

Как уже упоминалось выше, для нас было важно получить целостное решение для построения программно-определяемых сетей. В решении Arista cистема CloudVision Portal является центральном звеном.

CloudVision Portal (CVP) предоставляет единое окно для управления решением Arista и позволяет выполнять типовые операции на сети посредством следующих функций: инвентаризация, управление конфигурацией, мониторинг событий. В дополнении так же обеспечивает механизмы Zero-Touch Provisioning для упрощенной процедуры запуска новых коммутаторов. Также отличительной особенностью CVP является прием, хранение и визуализация телеметрических данных с устройств под управлением Arista EOS.

Основные функции:

• Zero-Touch Provisioning: CVP выступает в роли ZTP server, который по заранее заданному bootfilename URL предоставляет коммутатору скрипт для генерации базовой конфигурации, с которой коммутатор регистрируется в CVP.

• Configuration management: CVP предоставлет возможность администраторам системы управлять конфигурацией устройств из CVP путем разделения конфигурации на логические части (Configlets). Общая конфигурация для группы устройств собирается в отдельные конфиглеты, которые применяются на уровне того или иного контейнера в иерархии. По итогу каждый коммутатор, находящийся в каком-либо контейнере, наследует все конфиглеты, примененные на контейнерах уровня выше. Специфичная конфигурация для этого устройства добавляется в Device-specific configlets. Использование конфиглетов в CVP позволяет нативно реализовать соответствие конфигурации заданному образцу. Любые изменения конфигурации, сделанные через CLI, автоматически детектируются в CVP и могут быть добавлены в CVP при необходимости. Автоматизация создания и обновления конфигураций обеспечивается за счет отдельного типа конфиглетов – Configlet Builders (поддерживают язык программирования Python внутри себя) или готового решения по автоматизации для Ansible – Ansible collection for Arista Validated Designs.

• Change Control: Любое изменение конфигурации устройств в соответствующих конфиглетах генерирует Task (задачу) на изменение. Одна или несколько Task должны быть объединены в единый объект Change Control, который предоставляет инструменты для анализа планируемых изменений и позволяет дополнительно проверить конфигурацию перед ее применением. Change Control в CVP отлично вписывается в концепцию Change Management ITSM, широко применяемую в индустрии.

• State Streaming Telemetry: Коммутаторы Arista, использующие EOS, отправлюет слепки своего состояния с помощью агента TerminAttr. Параметры состояний передаются автоматически при их изменении. Параметры со счетчиками (например, счетчики пакетов на интерфейсах) передаются каждые 2 секунды. Все данные телеметрии от каждого коммутатора Arista помещаются в CVP в специализированную Time-series DB (Aeris). CVP автоматически строит графики по телеметрических данным для основных параметров устройств. Отдельно надо отметить, что параметры состояний также хранятся в Time-series DB, что позволяет хранить историю их изменений во времени. Список передаваемых параметров состояний приведен в разделе ниже. Современные алгоритмы machine-learning и заложенные разработчиками сценарии в CVP генерируют события (Events) для реактивного и проактивного мониторинга аварий на сети.

• Compliance dashboard: CVP для каждого устройства отслеживает статус соответствия (compliance) по следующим параметрам: соответствие конфигурации на устройстве и в CVP, подверженность текущей версии EOS на устройствах известным программным дефектам (при обеспечении доступа в Интернет CVP к серверам Arista Networks).

Подсчет первой партии цыплят

В мае 2021 года мы подвели итоги пилотного проекта:

• Фабрика была развернута автоматически с помощью модуля в CVP Zero-Touch Provisioning;

• Пропускная способность сети полностью соответствовала нашим ожиданиям, каждый хост мог рассчитывать на 20 Гбит/с до любого своего соседа по ЦОД без переподписки

• Все тесты надежности и горячего резервирования прошли успешно

• Оборудование вело себя предсказуемо

• Централизованная система управления CVP была имплементирована в наш ИТ-ландшафт для реализации IaaC-концепции. Описание всей сетевой инфраструктуры: подключения серверов, описание VLAN/SVI, IP VRF, было выполнено в текстовом виде с использование языка YAML. Это позволило нам заложить основу для дальнейшей подготовки конфигураций оборудования Arista для миграции основного ЦОД.

Тяжело в пилоте — не легче на проде

Июнь 2021 года был ознаменован подготовкой к миграции нашего основного ЦОДа на новую сетевую инфраструктуру. Объемы, конечно, смущали: 1600 хостов, 120 коммутаторов, 140 точек маршрутизации, 4000 линков и 80 стоек оборудования. Но не только объемы, на этих хостах «жили» продуктивные сервисы, которые должны были продолжать работать без перебоев.

Требовалось не просто развернуть сетевую инфраструктуру на Arista рядом с существующей, но и интегрировать их между собой на уровне L2 и L3 для бесшовной миграции. Для этого мы «растянули» существующие VLAN между фабриками Arista и Cisco и получили возможность физически переключить сервера.

Но в первую очередь, предстояла работа по анализу конфигураций существующего оборудования Cisco и адаптации их под Arista. Делать это вручную на такой крупной инфраструктуре значило сорвать сроки миграции. Поэтому задача была декомпозирована:

• представить конфигурационные файлы Cisco в формате Excel-таблиц с учетом того, какой сервис обслуживает каждая единица оборудования;

• реализовать скрипты для анализа таблиц и их автоматической переработки в формат YAML;

• произвести автоматическое создание конфигураций коммутаторов Arista с помощью Ansible AVD и «проливка» таких изменений в промышленную эксплуатация с учетом всех необходимых процессов по Change Management (CVP Change Control Review).

На следующем шаге пришлись к месту возможности по автоматической генерации конфигураций с помощью Ansible AVD и их применения на устройствах через CloudVision Portal. Разливка конфигурационных файлов по коммутаторам Arista стала делом техники в прямом смысле этого слова. Но риски тем не менее сохранялись. Большой объем данных, когда, при физическом переключении хостов одного сервиса, требовалось инициализировать изменения в конфигах до сорока коммутаторах одновременно, многократно увеличивал вероятность ошибки. Поэтому в работах принимали сразу несколько сетевых инженеров и прикладных администраторов, а также использовались средства контроля управления изменениями Arista CloudVision Portal (CVP Change Control Review):

Как и ожидалось, самым продолжительным, хотя и незаметным для приложений, шагом стало переключение физических линков продуктивных хостов. Оно заняло четыре месяца так как 95% объема работ, с участием инженеров вендора, было выполнено в дневное рабочее время, на случай аварийной ситуации. Методика переключений была проста:

1. Переключаем один data-link сервера;

2. Проверяем, что на коммутаторах Arista сервер виден, но Port-Channel еще не поднят, т.к. LACP system-id новый;

3. Переключаем второй data-link сервера – в этот момент bond-интерфейс на сервере быстро падает и поднимается уже с коммутатором Arista.

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

1. На коммутаторах Arista уровня Leaf настраивался SVI (EVPN IRB) для мигрирующего VLAN с IP-адресом Anycast Gateway совпадающим с существующим Cisco IP Gateway.

2. На оборудовании Cisco IP Gateway менялся на любой свободный IP-адрес этой подсети.

В такой ситуации трафик по-прежнему продолжал передаваться через оборудование Cisco, так как сервера продолжают считать, что MAC-адрес шлюза это Cisco MAC. Но все последующие за этим широковещательные ARP-запросы на серверах (по истечение ARP timeout) обрабатывались только коммутаторами Arista, которые отправляли ARP Reply уже с Arista VMAC. При этом, оборудование Cisco игнорировало такие запросы, так как IP-адрес в ARP-запросе не совпадал ни с каким из настроенных на интерфейсе IP-адресов.

Время необходимое на «переучивание» ARP-записей всеми серверами, как известно, зависит от настроек ARP refresh timeout на каждом из них. Ускорить процесс решили с помощью отправки команды ARP FLUSH на каждый сервер с помощью простого Ansible playbook.

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

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

Итоги и перспективы

Мы не просто «заменили колеса в автомобиле на ходу», но еще «перебрали подвеску и коробку передач».

Очевидные плюсы от реализации проекта бросаются в глаза даже не искушенному читателю:

1. Рост производительности сети до 100 ТБит/с на уровне ядра и гарантированная скорость доступа 20 Гбит/с для каждого хоста.

2. Возможность гибкого и почти неограниченного масштабирования сети на любом уровне в результате внедрения технологии VXLAN EVPN и дизайна Leaf-Spine.

3. Повышение надежности и отказоустойчивости сетевой инфраструктуры.

4. Первые шаги в реализации концепции «Infrastructure as a Code» в результате внедрения Ansible AVD и централизованной системы мониторинга и управления CVP.

Как вы, наверное, подозреваете, больше всего у нас чешутся руки приступить к последнему из вышеперечисленных пунктов. Например, следующим логичным шагом нам видится интеграция нашей системы IPAM Netbox и Ansible AVD для автоматической подготовки разливки серверов при их добавлении в Netbox, но это тема отдельной статьи.

Спасибо за внимание, желаем вам соблюдения всех SLA ?

Автор: Евланов Александр