Первая статья из цикла «Конструктивная админская лень или как я конфиг автоматизировал»

Размышлизмы на тему а зачем это всё надо.

Задачи которые мы решаем в процессе эксплуатации сети:
1. Содержание сети в работоспособном состоянии;

• Мониторинг установленного оборудования;
• Удалённая диагностика проблем на оборудовании;
• Настройка оборудования на замену вышедшего из строя;

2. Координирование технической поддержки в случае падения какого либо узла;

• Указать точное место отказа;
• Эффективное управление перемещением технической поддержки, для максимально быстрого восстановления;

3. Другие задачи

• Тут каждый администратор сети напишет своё, я к примеру занимаюсь разработкой архитектурных и телекоммуникационных решений в процессе проектирования новых сегментов сети, как следствие мне требуется информация о географической привязке объектов.

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

Сбор необходимой информации для разработки

Вводные данные

Сеть распределена на несколько городов
Каждый город является обособленным подразделением с единым контакт-центром и системой авторизации пользователей, при этом взаимодействие между городами происходит по L3 а городская сеть построена на L2.
Архитектурная инфраструктура сети построена согласно ГОСТ Р 53246-2008 СКС и включает в себя три подсистемы.

(линейная структура универсальной кабельной системы)

(древовидная структура универсальной кабельной системы)
Как видно из рисунка выше есть участок кабеля(толстая линия) в котором объединены несколько кабелей(волокон), и в точке консолидации они расходятся на отдельно стоящие здания. Жизнь это не ГОСТ и часто бывает так:
MC-IC-HC-HC-HC, или так MC-IC-mIC-HC-HC а ещё кабельные сегменты содержат более одного волокна, и далеко не всегда все волокна имеет смысл вываривать в кросс, то есть в любом кроссе могут быть сваренные транзитом волокна.
Как видно из приведённых выше строк тире показывает связь между узлами и визуально мы имеем возможность оценить что произойдёт с конечным узлом в случае падения мастер-узла. Тире это самое волокно каким то образом приходящее в кросс от другого кросса, а это значит что в наших изысканиях необходимо учитывать волокна для автоматизации проверки иерархии активного оборудования.
Архитектурная часть является основанием для разработки телекоммуникационной инфраструктуры. Телекоммуникационная инфраструктура построена согласно иерархической модели построения сети коммутации.
Выделено три уровня:

• уровень доступа (access layer);
• уровень агрегации (distibution layer);
• уровень ядра (core layer).

Такое деление на уровни позволяет добиться:

• легкости в обращении с сетью;
• упрощается мастшабируемость сети;
• легче настраивать устройства;
• легче вводить избыточность;
• лёгкости проектирования сети.

Каждый коммутатор в городе имеет минимум два vlan manager_vlan и user_vlan_n, где n = идентификатор дома.

Разработка стандарта маркировки

Необходим унифицированный маркер, который содержит информацию о местоположении установленного оборудования и иерархии объектов. Желательно, чтоб маркер можно было понять не влезая в справку (пример плохого маркера: 23-sa-344-11).

Привязка к местности

Требуется унифицированный маркер, который однозначно подскажет местоположение объекта капитального строительства, на котором установлено наше оборудование. Основная проблема неоднозначность данных вводимых в адрес каждого объекта и это не только наша проблема, в статье ФИАС или КЛАДР: выбираем справочник адресов описано очень подробно как КЛАДР наступил на эти грабли.
Как следствие в координации работы, проектировании сети, а так же в случае интеграции с внешними сервисами возникнут проблемы. Думаю приведённых доводов достаточно, чтоб задуматься о использовании справочника адресов и при этом избежать путешествия по граблям в изобретении велосипедов.
Внутренняя архитектура ФИАС хорошо описана на GISLAB, и потому нет нужды повторяться. Разберёмся только в том что нам нужно.

• Требуется идентификация объекта. ФИАС содержит уникальное значение к каждому действующему адресному объекту в отличии от КЛАДРа
• Требуется своевременное обновление наименования объектов (к примеру у меня есть ряд объектов, которые за время обслуживания несколько раз меняли название) ФИАС содержит статус актуальности и статус действия;
• Готовая архитектура базы данных для хранения адресов(мы только дополним её своими данными).

Теперь чего не хватает в системе ФИАС.

• Отсутствуют координаты здания(важно для проектирования и координации перемещения специалистов тех. поддержки);
• Отсутствует характеристики объекта (Этажность, подъездность, количество квартир/офисов, важно для проектирования и менеджеров по продажам).

Из описанного выше становится понятно что использовать ФИАС в исходном состоянии лишено смысла, однако ФИАС будет отличным основанием для нашей системы генерации конфигураций оборудования и мониторинга.

Продолжение следует!