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

Выбор технического решения: заповедник мутантов

Порядок работы над сложной автоматизированной системой пока лучше всего описан в ГОСТ 34.601-90 «Автоматизированные системы. Стадии создания», поэтому мы работали по нему. И уже на стадиях формирования требований и разработки концепции мы столкнулись с первыми трудностями. Организациям разного профиля — банкам, страховым компаниям, разработчикам софта и т. п. — под их задачи и стандарты нужны определённые типы сетей, специфика которых понятна и стандартизирована. Однако с нами такое не прокатит.

Почему?

«Инфосистемы Джет» — крупная многопрофильная ИТ-компания. При этом отдел внутренней поддержки у нас небольшой (но гордый), он обеспечивает работоспособность базовых сервисов и систем. Компания содержит в себе множество подразделений, выполняющих разные функции: это и несколько мощнейших аутсорс-команд, и собственные разработчики бизнес-систем, и информбезопасность, и архитекторы вычислительных комплексов, — в общем, кто только не. Соответственно, задачи, системы и политики безопасности у них тоже разные. Что ожидаемо создало сложности в процессе анализа потребностей и их стандартизации.

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

Или вот еще пример. Периодически внутри какого-либо подразделения заводится тестовый стенд. Так было с Jira и Confluence, которые ограниченно использовались Центром программной разработки в некоторых проектах. Через некоторое время об этих полезных ресурсах узнали в других подразделениях, оценили, и в конце 2018 года Jira и Confluence перешли из статуса «локальная игрушка программистов» в статус «ресурсы компании». Теперь за этими системами должен быть закреплен владелец, должны быть определены SLA, политики доступа/ИБ, политика резервного копирования, мониторинга, правила маршрутизации заявок на устранение проблем, — в общем, должны присутствовать все атрибуты полноценной информационной системы.
Каждое наше подразделение — это еще и инкубатор, выращивающий собственные продукты. Некоторые из них погибают на стадии разработки, какие-то мы используем в период работы над проектами, другие же приживаются и становятся тиражируемыми решениями, которые мы начинаем применять сами и продавать клиентам. Для каждой подобной системы желательно иметь собственную сетевую среду, где она будет развиваться, не мешая другим системам, и в какой-то момент сможет быть интегрирована в инфраструктуру компании.

Помимо разработки, у нас есть очень большой Сервисный центр с более чем 500 сотрудниками, сформированными в команды под каждого заказчика. Они занимаются обслуживанием сетей и других систем, удаленным мониторингом, урегулированием заявок, и так далее. То есть инфраструктура СЦ — это, по сути, инфраструктура того заказчика, с которым они сейчас работают. Особенность работы с этим участком сети заключается в том, что их рабочие станции для нашей компании являются частично внешними, а частично — внутренними. Поэтому для СЦ мы реализовали следующий подход — компания предоставляет соответствующему подразделению сетевые и другие ресурсы, рассматривая рабочие станции этих подразделений как внешние подключения (по аналогии с филиалами и удаленными пользователями).

Проектирование магистрали: мы — оператор (сюрприз)

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

Создали опорную сеть, при помощи которой любому внутреннему, а в перспективе и внешнему потребителю предоставляется требуемый сервис: L2 VPN, L3 VPN или обычная маршрутизация L3. Одним подразделениям нужен безопасный доступ в интернет, другим — чистый доступ без межсетевых экранов, но при этом с защитой наших корпоративных ресурсов и опорной сети от их трафика.

С каждым подразделением мы неформально «заключили SLA». В соответствии с ним все возникающие инциденты должны устраняться за определенный, заранее согласованный промежуток времени. Требования к своей сети у компании оказались жёсткими. Максимальное время реагирования на инцидент при сбоях телефонной связи и электронной почты составило 5 минут. Время восстановления работоспособности сети при типовых отказах — не больше минуты.

Поскольку у нас сеть операторского класса, к ней можно подключаться только в строгом соответствии с правилами. Обслуживающие подразделения устанавливают политики и предоставляют сервисы. Им даже не нужна информация о подключениях конкретных серверов, виртуальных машин и рабочих станций. Но при этом нужны механизмы защиты, потому что ни одно подключение не должно выводить сеть из строя. При случайном создании петли другие пользователи не должны этого замечать, то есть необходима адекватная реакция сети. Любой оператор связи постоянно решает подобные, казалось бы, сложные, задачи внутри своей опорной сети. Он предоставляет сервис множеству клиентов с различными потребностями и трафиком. При этом разные абоненты не должны испытывать неудобства от трафика других.
У себя мы решили эту задачу следующим образом: построили опорную L3-сеть с полным резервированием, с использованием протокола IS-IS. Поверх опорной построили наложенную сеть на основе технологии EVPN/VXLAN, с использованием протокола маршрутизации MP-BGP. Для ускорения сходимости протоколов маршрутизации применили технологию BFD.


Структура сети

На испытаниях такая схема показала себя отлично — при отключении любого канала или коммутатора время сходимости не более 0.1-0.2 с, теряется минимум пакетов (часто — ни одного), TCP-сессии не рвутся, телефонные разговоры не прерываются.


Уровень Underlay — маршрутизация


Уровень Overlay — маршрутизация

В качестве коммутаторов распределения использовались коммутаторы Huawei CE6870 с лицензиями VXLAN. Это устройство имеет оптимальное сочетание цена/качество, позволяет подключать абонентов на скорости 10 Гбит/с, и подключаться к магистрали на скоростях 40–100 Гбит/с, в зависимости от используемых трансиверов.


Коммутаторы Huawei CE6870

В качестве коммутаторов ядра использовались коммутаторы Huawei CE8850. Из задача — быстро и надежно передавать трафик. К ним не подключаются никакие устройства, кроме коммутаторов распределения, они ничего не знают про VXLAN, поэтому была выбрана модель с 32 портами 40/100 Гбит/с, с базовой лицензией, обеспечивающей L3-маршрутизацию и поддержку протоколов IS-IS и MP-BGP.


Самый нижний — коммутатор ядра Huawei CE8850

На этапе проектирования внутри команды разразилась дискуссия о технологиях, с помощью которых можно реализовать отказоустойчивое подключение к узлам опорной сети. Наш московский офис размещается в трёх зданиях, у нас 7 кроссовых помещений, в каждом из которых было установлено два коммутатора распределения Huawei CE6870 (ещё в нескольких кроссовых помещениях устанавливались только коммутаторы доступа). При разработке концепции сети было рассмотрено два варианта резервирования:

• Объединение коммутаторов распределения в отказоустойчивый стек в каждом кроссовом помещении. Плюсы: простота и удобство настройки. Минусы: выше вероятность выхода из строя всего стека при проявлении ошибок встроенного программного обеспечения сетевых устройств («утечки памяти» и подобные).
• Применить технологии M-LAG и Anycast gateway для подключения устройств к коммутаторам распределения.

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

Кроссовая

Коммутатор доступа, сервер или любое другое устройство, требующее отказоустойчивого подключения, включается в два коммутатора распределения. Технология M-LAG обеспечивает резервирование на канальном уровне. Предполагается, что два коммутатора распределения выглядят для подключаемого оборудования как одно устройство. Резервирование и балансировка нагрузки осуществляются по протоколу LACP.

Технология Anycast gateway обеспечивает резервирование на сетевом уровне. На каждом из коммутаторов распределения настроено достаточно большое количество VRF (каждый VRF предназначен для своих целей — отдельно для «обычных» пользователей, отдельно — для телефонии, отдельно — для различных тестовых сред и сред разработки, и т. п.), и в каждом VRF настроено несколько VLAN. В нашей сети коммутаторы распределения являются шлюзами по умолчанию для всех устройств, подключенных к ним. IP-адреса, соответствующие интерфейсам VLAN, одинаковые для обоих коммутаторов распределения. Маршрутизация трафика производится через ближайший коммутатор.

Теперь рассмотрим подключение коммутаторов распределения к ядру:
Отказоустойчивость обеспечивается на сетевом уровне, по протоколу IS-IS. Обратите внимание — между коммутаторами предусмотрена отдельная линия связи L3, на скорости 100G. Физически эта линия связи представляет собой кабель Direct Access, его можно увидеть справа на фотографии коммутаторов Huawei CE6870.

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

Нужно сказать несколько слов о том, как совместно работают технологии VXLAN и Anycast gateway. VXLAN, если не вдаваться в детали — это туннель для транспортировки кадров Ethernet внутри пакетов UDP. В качестве целевого (destination) IP-адреса VXLAN-туннеля используются loopback-интерфейсы коммутаторов распределения. В каждой кроссовой установлены два коммутатора с одинаковыми адресами loopback-интерфейсов, соответственно пакет может прийти на любой из них, и из него может быть извлечен кадр Ethernet.

Если коммутатор знает о целевом MAC-адресе извлеченного кадра, кадр будет корректно доставлен по назначению. За то, чтобы оба коммутатора распределения, установленные в одной кроссовой, имели актуальную информацию обо всех MAC-адресах, «прилетающих» с коммутаторов доступа, отвечает механизм M-LAG, предусматривающий синхронизацию таблиц MAC-адресов (а также ARP-таблиц) на обоих коммутаторах M-LAG-пары.

Балансировка трафика достигается благодаря наличию в underlay-сети нескольких маршрутов на loopback-интерфейсы коммутаторов распределения.

Вместо заключения

Как уже было сказано выше, на испытаниях и в работе сеть показала высокую надежность (время восстановления при типовых отказах не более сотен миллисекунд) и хорошую производительность — каждая кроссовая связана с ядром двумя каналами по 40 Гбит/с. Коммутаторы доступа в нашей сети объединяются в стеки и подключаются к коммутаторам распределения по LACP/M-LAG двумя каналами по 10 Гбит/с. В стеке обычно 5 коммутаторов по 48 портов в каждом, к распределению в каждой кроссовой подключаются до 10 стеков доступа. Таким образом, магистраль обеспечивает около 30 Мбит/с на пользователя даже при максимальной теоретической загрузке, что на момент написания статьи достаточно для всех наших практических применений.

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

В следующей части расскажем, как мы проводили миграцию на новую сеть. Stay tuned!

Максим Клочков
Старший консультант группы сетевого аудита и комплексных проектов
Центра сетевых решений
«Инфосистемы Джет»