В интернете бытует мнение, что котики — это вода. Они могут залезть куда угодно и даже протиснуться в вазу. Но среди них есть и Гарфилды, которым и целой квартиры мало. А если в ней появится еще один зверек, то пиши пропало. С клиентами примерно такая же история: бывают ситуации, когда им тесно на общем коммутаторе доступа и нужно организовать выделенную инсталляцию.
В этой статье рассказываем, что такое выделенные сетевые инсталляции, когда нужно съезжать с публичного пула в отдельную «коробку» и при чем здесь мультивендорность.
Текст написан по мотивам выступления экспертов Selectel на сетевом митапе.
Что такое публичный пул
По умолчанию все выделенные серверы находятся в публичном пуле. По сути, его можно представить в виде кампусной сети. Это стандартная Ethernet-фабрика, построенная по принципу агрегированных каналов — технологии объединения параллельных каналов связи в один логический.
Подключений в Ethernet-фабрике немало, поэтому резервируем линки везде, где это возможно. Кроме того, заботимся об охлаждении оборудования и бесперебойном питании.
Варианты подключения к сети
Всего есть две основные схемы подключения сервера к сети — выбор конкретной зависит от линейки арендованной машины.
На базе серверов с фиксированными конфигурациями можно организовать локальную сеть — например, для соединения с облачной базой данных через глобальный роутер. Обратная ситуация с некоторыми серверами из линейки ChipCore: у их арендаторов есть доступ только в интернет.
Больше всего вариантов подключений у серверов с произвольными конфигурациями: они одновременно могут иметь несколько подключений в коммутаторы доступа локальной и интернет-сети. Но у них есть общая черта: все серверы — ChipCore, фиксированной или произвольной конфигурации — включаются в общие коммутаторы, на которых «живут» другие клиенты.
Когда нужна выделенная инсталляция
Давайте вернемся к потребностям котиков клиентов. Когда же им нужна выделенная сетевая инсталляция? Рассмотрим несколько кейсов.
«Не хочу делить коммутатор доступа с другими клиентами»
Иногда клиенты остерегаются, что коммутатор не справится с обслуживанием серверов, когда с сервером другого клиента что-то случится. И коммутатор, например, начнет дропать трафик. Такие опасения не всегда оправданы, но для крупного бизнеса выбор выделенной инсталляции очевиден.
«Мне не нужен выход в интернет»
По умолчанию все серверы подключены к интернету. Даже если клиент не использует свою машину, аплинки смотрят вверх. Поэтому когда людям нужна только локальная сеть и отдельный коммутатор доступа, нужно поднимать выделенную инсталляцию.
«Я не такой, как все. Мне нужны нестандартные настройки, которых нет в публичном пуле»
Был случай, когда человеку нужен был RDMA между несколькими серверами. Здесь точно нужна выделенная инсталляция с изолированным соединением на уровне коммутаторов доступа, чтобы не затронуть других клиентов.
«Хочу полностью управлять коммутатором, в который включены мои серверы»
Есть клиенты, которым по внутренней политике нужна точка, например, для полного доступа и управления коммутаторами. Так как в публичном пуле на коммутаторах «живут» разные клиенты, для получения таких «привилегий» также нужно поднять выделенную инсталляцию.
«У меня специфические требования по безопасности»
Еще один распространенный кейс — когда клиенту нужен контроль и особенно высокий уровень безопасности, чтобы каждая система была аттестована в соответствии с приказами ФСТЭК. Для этого нужна уже не обычная выделенная инсталляция, а полноценный аттестованный сегмент ЦОД (А-ЦОД).
Чтобы ограничить доступ к серверным шкафам А-ЦОД, в дополнение к физическим замкам мы поставили на стойки со стороны «горячего» и «холодного» коридоров электронные замки СКУД. Никто из посторонних не может получить доступ к оборудованию. Он есть только у некоторых сотрудников инженерно-технического отдела, которые прошли внутреннее обучение по работе с аттестованными системами.
В А-ЦОД клиент может разместить выделенные серверы любой конфигурации. И даже оборудование, которое мы не предоставляем, — например, СХД и криптошлюзы для организации шифрованного канала до площадки клиента или подключения к государственным ИС. С нашей стороны — работа по установке и подключению оборудования: межсетевого экрана, коммутатора, серверов.
Минимальная выделенная инсталляция
Котиков много, причин для построения выделенных инсталляция тоже. Чтобы они были довольны, мы можем поставить один или несколько коммутаторов доступа — это можно сделать несколькими способами.
- Схема с одним коммутатором. Если у клиента нет особых требований к отказоустойчивости, серверы просто включаются в один коммутатор доступа. Далее, если клиент хочет связать свою инсталляцию с другими продуктами, можно построить локальную сеть на базе глобального роутера. Если нужно соединение с внешней инфраструктурой — организовать выделенное соединение Selectel Connect. Подробнее рассказали в статье.
- Отказоустойчивая схема. Иногда клиенты запрашивают резервированное соединение. В таком случае мы подключаем дополнительные коммутаторы доступа (синхронизированные через Stack или MLAG), физически разные линки и агрегированный сетевой интерфейс на стороне серверов. Кроме того, если клиенту нужен менеджмент- или IPMI-сегмент, под это тоже можем предоставить коммутатор.
- Схема с «прослойкой». Если инсталляцию заказывает клиент с высокими требованиями по безопасности, можем организовать «прослойку» между серверами и внешней сетью — добавить маршрутизаторы или файрволы для фильтрации трафика.
Выделенная инсталляция — это конструктор, с которым можно поиграться. Например, поставить несколько коммутаторов, объединить их по MLAG или настроить L3-связность с внешними операторами — зависит от задач клиента.
Кирилл Сизов, ведущий архитектор сетевых решений
При чем здесь мультивендорность
Мы уже много раз упоминали коммутаторы доступа — устройства первого уровня сетевой фабрики, расположенные до агрегации и суперагрегации, — и другое оборудование. Но с железками не все так просто: вендоров много, линеек коммутаторов и маршрутизаторов еще больше. Так что мы используем в выделенных инсталляциях?
Оборудование для выделенных инсталляций
Коммутаторы доступа
В публичном пуле мы используем коммутаторы доступа от многих вендоров, разных линеек. Начинали строить сети на базе EX4300, постепенно перешли на EX3400 и сейчас также предлагаем Huawei, H3C и Eltex.
Если клиенту достаточно схемы с одним коммутатором доступа, он может выбрать любую железку из списка. Если инсталляция должна быть отказоустойчивой, предлагаем взять коммутаторы Huawei CE5855, H3C S5560X — все, кроме Eltex MES3348 и Juniper. С последним дело в том, что EX4300 и EX3400 можно объединять только с помощью Stack (Virtual Chassis, Logical Chassis, iStack, IRF). Это менее надежная технология в сравнении с MLAG, которую поддерживают другие коммутаторы.
Еще немного коммутаторов
«Мир развивается, скорости растут, 10 Гб — это уже реальность». С высокоскоростными железками у нас также большой опыт. Мы строили выделенные инсталляции на базе Huawei CE6855, H3C S6850, Cisco Nexus N3K, Juniper QFX5120 и даже Arista DCS-7050SX3.
Маршрутизаторы доступа
Вернемся к схеме с «прослойкой», по которой клиент может установить файрвол или маршрутизатор между коммутаторами доступа и агрегации. В таком случае мы также можем порекомендовать железки от разных вендоров. В частности, Juniper MX, Extreme SLX и для любителей Cisco — ASR.
Почему именно это оборудование?
Все просто: все оборудование выше уже изучено и протестировано в публичных пулах, где вероятность «поломки» гораздо выше. В выделенных инсталляциях железо работает максимально стабильно, потому что нагрузка и частота конфигурирования меньше.
Исключение — Cisco Nexus N3K-C3064
Единственная железка, которая выбивается из нашего «пайплайна», — коммутатор Nexus N3K-C3064. Мы его тестировали и заметили, что время сходимости при работе с большим количеством VLAN слишком высокое. А вот в выделенных инсталляциях, где соединений мало, все работает как часы. Поэтому устанавливаем этот коммутатор только в выделенных инсталляциях — это довольно популярное решение для наших клиентов.
Примеры выделенных инсталляций
Мы уже рассмотрели основные схемы в минимальной выделенной инсталляции, но на практике их гораздо больше. Например, можно построить сеть, чтобы объединить серверы в А-ЦОД и виртуальное приватное облако. Если вам интересно, как это устроено изнутри и какие еще встречаются кейсы, погружайтесь в видео.
