Современный датацентр заметно отличается от традиционной корпоративной сети. Приложения больше ориентируются на L3 коммутацию вместо предположения, что все соединения находятся в одной подсети, больше траффика идет «горизонтально» нежели «вертикально» и т.д. Несомненно, главное отличие — гигантский масштаб.
Благодаря виртуализации, количество сетевых соединений в датацентре исчисляется от десятков тысяч до миллионов, тогда как в старые добрые времена их было всего несколько тысяч. Масштаб виртуальных сетей давно вышел за возможности традиционных VLAN сетей, скорость переконфигурирования также возросла на порядки. Кроме того, количество серверов в современном ЦоД таково, что сетевого оборудования необходимо на голову больше, чем в традицонной корпоративной сети.
Эволюция сетевой инфраструктуры шла своим чередом, от монолитных псевдо-ОС через встраиваемые ОС типа QNX и VxWorks до современной стадии, когда ОС делается на основе Linux или BSD, иногда такой образ запускается в виртуальной машине обычного Linux дистрибутива. С другой стороны, способ управления эволюционировать отказывался, это по-прежнему командная строка с многоуровневой структурой. Сложностей добавляет еще и различный синтаксис у разных производителей, а часто и у одного в разных моделях.
Подытоживая — проблема лежит не в железе, а в сетевых ОС. Подходы к решению разделились, первый путь ушел к northbound и southbound API подходу (наибольшую популярность приобрел OpenFlow), второй — использовать Linux и его экосистему. Другими словами, первый вариант пытается добавить продвинутый API управления к существующим ОС, второй предлагает переключиться на ОС, которая уже обладает всеми необходимыми характеристиками.
В предыдущем материале мы рассказали о коммутаторах без предустановленной ОС
и средой для развертывания ONIE.
Самое время рассказать про одного из представителей второго подхода, который можно установить на наши платформы — Cumulus Linux.
Cumulus Linux не просто основан на Linux, как многие, это и есть Linux, поэтому работа с ним практически не отличается от обычного
Linux сервера. Совершенно стандартные приложения устанавливаются прямо на коммутатор, при необходимости новые утилиты разрабатываются
без ориентации на специфичные API, привычный инструментарий работы с сетью дополнен средствами построения CLOS фабрик и автоматизации.
Архитектура
Установка и мониторинг
Как это выглядит в развертывании? Всем привычен подход «загрузка по PXE, развертывание образа ОС», здесь аналогично.
Привычный подход
- Первая загрузка идет в ONIE, запускается процесс поиска источника образа ОС, в нем определяется нужный образ и развертывается на коммутатор.
Подготовка - Первая загрузка в Cumulus Linux, определяется наличие скриптов настройки через опцию 239 DHCP. Если в ответ получается URL адрес, то
по нему запрашивается скрипт, в нем разыскивается CUMULUS-AUTOPROVISIONING и скрипт запускается от root. Поддерживаются Bash, Ruby, Perl, Python.
Поиск скрипта - Третий шаг — нормальная загрузка в Cumulus Linux
Рабочий режим
Первая настройка завершена, прекрасно. Что дальше?
А дальше можно пользоваться все теми же инструментами, что и для серверов.
Оркестровка
Помимо существующих инструментов, можно интегрировать любые разработки, которые уже используются в компании.
Мониторинг? Ganglia, Graphite, collectd, net-SNMP, Icinga — установите на коммутатор и собирайте данные в реальном времени.
Прелести автоматизации
Linux не только обладает отличными возможностями по управлению и понятными API, но и прекрасно подходит к сетевой модели современного ЦоД. Уровень управления находится в пространстве пользователя и отделен от уровня обработки пакетов в ядре. FIB (Forwarding Information Base) находится в ядре, RIB (Routing Information Base) управляется из пользовательской среды соответствующими демонами, поддерживаются основные возможности сетевого оборудования и ряд продвинутых функций, связанных с BGP. Текущий инструментарий позволяет прямо обращаться к интерфейсам, таблицам маршрутизации, есть механизмы уведомлений об изменениях и т.д.
Такая база позволяет использовать родную консоль Linux, вместо специализированных оболочек JunOS, NX-OS и прочих. Консоль по своей природе отлично подходит для использования цепочек независимых команд и применения скриптов.
И коммутатор отлично автоматизируется!
- Управление пакетами и процессами
- Шаблоны конфигураций
- Автоматизация мониторинга
Все это помогает настроить L2/L3 и упростить жизнь администратору.
Еще один удобный инструмент — Prescriptive Topology Manager (PTM). Когда определена логическая топология ЦоД, привести кабельное хозяйство в соответствие — весьма непростая задача, съедающая немало времени и усилий. PTM позволяет проверить правильность подключения кабелей в реальном времени и указать точное место для устранения ошибки. Он использует план разводки кабелей в формате graphviz-DOT (некоторые компании и так пользуются им для создания плана) и сравнивает его информацией, полученной через LLDP, для проверки правильности подсоединения кабелей.
Проверка топологии
Сравнение с данными LLDP
Примеры интеграции
Программные решения по оверлеям ограничивают возможность контролировать аппаратную сторону сети, не позволяя автоматизировать настройку и управление, а также усложняют отслеживание неполадок. Linux поддерживает VXLAN, поэтому не составит проблемы разработать агенты для различных решений по виртуализации сети. Cumulus Linux может работать как аппаратный портал L2, позволяя обойти ограничения программных решений и сохранить высокую производительность коммутации (VXLAN tunnel endpoint (VTEP) обрабатывается на скорости канала) при использовании всех преимуществ технологии VXLAN.
Разработаны агенты для решений PLUMgrid, Nuage Networks, Midokura, VMware NSX.
Интеграция с VMware
Интеграция с Midokura
Архитектуры сети
Традиционная сеть
Традиционная архитектура сети включает уровни ядра, агрегации и доступа. Три уровня — выше задержки и имеется ряд наследственных ограничений. Такие решения не подходят для современного ЦоД с высокой плотностью серверов и значительным межсерверным трафиком. Используются протоколы STP/RSTP/PVSTP, VTP, HSRP, MLAG, LACP. В общем, «нас так учили».
- Ориентация на L2.
- Статична по природе — VLAN, плохо масштабируется при виртуализации.
- Опирается на костыли — MLAG, Trill и т.д.
- Оптимизация для трафика «север-юг».
- Низкая масштабируемость — сотни или тысячи соединений.
Современная сеть
- Она проще.
- Меньше проприетарных протоколов.
- Предсказуемые задержки.
- Горизонтальная масштабируемость.
- Ориентация на L3.
- Отлично подходит для виртуализации и облачных сред с множеством «владельцев».
- Масштабируемость до миллионов соединений.
Слабые места
Не бывает идеальных вариантов, в силу ориентации на L3 среду, у Cumulus Linux есть несколько слабых мест.
- Желание построить L2 фабрику с использованием MLAG, TRILL, Virtual Chassis, VLT, Chassis Stacking, и т.д.
- Работа с Netflow
- Коммутаторы доступа провайдеров с VRF, MPLS, VPLS и т.д.
- QinQ
- Коммутаторы доступа с Port Security, сложными QoS правилами, 802.1x, PoE
- Протоколы маршрутизации IS-IS, RIP, EIGRP.
- Авторизация по TACAS или Radius AAA (есть альтернатива LDAP).
Все, что связано с традиционным подходом к построению сети и провайдеры плохо совместимы методами для построения
сети в современном датацентре.
Подведение итогов.
Отвязка аппаратной коммутатора от операционной системы позволяет сделать следующий шаг к программно-конфигурируемому ЦоД. Возможность выбора ОС позволяет ориентироваться на те возможности, которые необходимы и выбирать из нескольких доступных вариантов оптимальный.
Система становится гораздо прозрачней, все можно проверить с помощью встроенных инструментов Linux без привязки к специфичным командам вендоров. Также становится возможным работать с роутером как с сервером, у которого множество сетевых портов, совсем как в начале становления сетевого оборудования, UNIX сервер с несколькими портами. Только в современном случае все сетевые операции осуществляются с помощью ASIC, а серверная часть осуществляет только управление.
Как обычно, у нас доступна лаборатория с Cumlus Linux на коммутаторе Eos 220 для бесчеловечных экспериментов и препарирования.
