Руслан Рахметов, Security Vision
В данной статье мы хотим обсудить настройку большого парка сетевого оборудования. А именно - как нам сформировать и отслеживать правильность настройки конфигурационного файла сетевого оборудования. Задача не из простых, но мы хотим продвинуться в этом вопросе. Вначале давайте зададимся вопросом: что же такое большая сетевая инфраструктура? И о каких нагрузках идет речь?
Найти информацию по крупной сетевой инфраструктуре практически не представляется возможным. На практике ни один крупный владелец сети или ЦОД не выложит архитектуру своей сетевой инфраструктуры из соображений информационной безопасности. Но это не значит, что мы не сможем сделать предположение. Изучим краткое описание инфраструктуры сайта Однокласники (https://habr.com/ru/company/odnoklassniki/profile/ ).
Одноклассники — крупнейшая развлекательная сеть в рунете и один из самых посещаемых сайтов в мире. На сайт ежедневно заходят десятки миллионов пользователей, которые просматривают ленту и видео, слушают музыку, переписываются с родственниками и друзьями. Такая пользовательская активность создает огромную нагрузку на наши системы.
Под капотом у Одноклассников — более 10 000 серверов, мощная отказоустойчивая инфраструктура, распределенная по трем дата-центрам.
В еще одной статье мы узнаем чуть побольше о самой инфраструктуре: https://habr.com/ru/company/odnoklassniki/blog/115881/
Сеть разделена на внутреннюю и внешнюю. Сети разделены физически. Разные интерфейсы серверов подключены в разные коммутаторы и работают в разных сетях. По внешней сети WEB сервера, общаются с миром. По внутренней сети все сервера общаются между собой.
Топология внутренней сети – звезда. Сервера подключены в L2 коммутаторы (access switches). Эти коммутаторы подключены как минимум двумя гигабитными линками к agregation стеку маршрутизаторов. Каждый линк идет к отдельному коммутатору в стеке.
Agregation коммутаторы подключены 10Gb линками в корневые маршрутизаторы, которые обеспечивают как связь между датацентрами, так и связь с внешним миром.
Используются коммутаторы и маршрутизаторы от компании Cisco. Для связи с внешним миром мы имеем прямые подключения с несколькими крупнейшими операторами связи.
Исходя из этой информации, мы можем предположить, что ЦОДы Однокласников имеют стандартную сетевую архитектуру. Схема представлена ниже:
Теперь мы можем посчитать примерное количество сетевого оборудования. Мы знаем, что у Однокласников 10 000 серверов. Предположим, что в каждой стойке по 40 серверов (и в стойке хватает мощности, чтобы эти 40 серверов работали), тогда у нас получается 500 стоек. В каждой стойке сверху по 2 коммутатора TOR (top of the rack) по 48 портов. На основании этого делаем заключение, что у них 1000 коммутаторов TOR.
Дальше у нас уровень агрегации – 1000 коммутаторов TOR с двумя портами, смотрящими в 2 коммутатора агрегации. Предположим, что в коммутаторе агрегации по 40 портов, отсюда: 2000/40 = 50 коммутаторов. Получается 50 коммутаторов агрегации.
Эти 50 коммутаторов агрегации подключаются в стек маршрутизаторов, которых наверно по 2 в каждом ЦОДе. Итого 6 маршрутизаторов.
В сумме получается 1000+50+6 = 1056 единиц сетевого оборудования, и это без учета интерфейсов IPMI. То есть мы можем предположить, что у Одноклассников порядка 1000-1500 единиц сетевого оборудования.
Хорошо, понимание по размерам инфраструктуры у нас появилось. Теперь попробуем разобраться, как обеспечить правильность (в соответствии с той логикой, которая закладывалась требованиями бизнеса) и бесперебойность работы сетевой инфраструктуры. Нам нужно каким-то образом обеспечить контроль правильной настройки конфигурационного файла сетевого оборудования.
Ключевым фактором в решении этой задачи является автоматизация, но здесь есть много подводных камней. При решении этой задачи мы можем столкнуться со следующими трудностями:
-
Конфигурационный файл является неструктурированным (Конфигурационный файл роутера\коммутатора может состоять из нескольких тысяч строк текста и этот текст не является машиночитаемым, надо программе объяснить логику конфигурации).
-
Нет единой логики группировки настроек (Настройки сетевого оборудования можно разбить на сервисы, которые реализуют глобальную архитектуру всей сети, но так как текст неструктурированный и не все взаимосвязи группируются, вручную сделать сложно).
-
Нет единого подхода к настройке оборудования (Сетевое оборудование настраивалось годами, добавлялось по частям, каждый сетевой инженер по-своему понимал, как надо настраивать оборудование).
Как нам подступиться к решению этих проблем?
Рассмотрим первую проблему - Конфигурационный файл является неструктурированным. Пример представлен ниже:
Как мы видим, по тексту непонятно, что является числом, что текстом, к чему относится конкретный текст. Прежде чем приступить к анализу, необходимо будет разметить для программы конфигурационный файл, чтоб программа понимала и структурировала у себя данные. Результатом первой итерации будет структурированный текст, с которым может работать программа.
Следующей проблемой является отсутствие единой логики группировки настроек. Нам незачем сравнивать настройки сразу всего сетевого оборудования, потому что текста много, и сразу весь конфигурационный файл нам не нужен. Обычно нам нужен какой-то сервис. Предположим, мы хотим увидеть, как настроен VPN между офисами. В этом случае мы не сможем взять, например, с 5 по 10 строчку и точно понимать, что это относится к VPN. Во-первых, это будет набор строчек в разных частях конфигурационного файла. Во-вторых, этот набор строчек заранее не определен и может «двигаться» с увеличением/уменьшением размера конфига. Для решения этой задачи требуется экспертиза по сетевому оборудованию и плотное взаимодействие с разработчиком. По результатам этой итерации мы сможем выделить часть текста, которая относится к конкретному сервису VPN. Важно понимать, что даже при едином подходе к настройке VPN, настройки на разных устройствах будут не совсем одинаковые. Это тоже надо учесть.
Еще одной проблемой является отсутствие единого подхода к настройке оборудования. Это приводит к тому, что становится затруднительно выбрать эталонный подход к настройке. В данном случае мы можем проанализировать настройки всех сетевых устройств, задействованных в работе, например, того же сервиса VPN. По результатам мы понимаем, что 40% настроены первым способом, 20% - вторым способом, 15% - третьим способом, 5% - четвертым способом. По результатам мы можем выбрать первый способ как эталонный и распространить его на оставшийся парк сетевого оборудования.
По результатам мы имеем эталонный конфигурационный файл, который сможем поддерживать в актуальном состоянии, и контролировать соответствие на всей сетевой инфраструктуре. Такой подход позволит нам автоматизировать контроль правильной настройки конфигурационного файла сетевого оборудования.
