ФІАС для адміністратора мережі

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

Міркування на тему а навіщо це все треба.

Завдання, які ми вирішуємо в процесі експлуатації мережі:
1. Утримання мережі в працездатному стані;
  • Моніторинг встановленого обладнання;
  • Дистанційна діагностика проблем на обладнанні;
  • Налаштування обладнання на заміну вийшов з ладу;
2. Координування технічної підтримки в разі падіння будь-якого вузла;
  • Вказати точне місце відмови;
  • Ефективне управління переміщенням технічної підтримки, для максимально швидкого відновлення;
3. Інші завдання
  • Тут кожен адміністратор мережі напише своє, я до прикладу займаюся розробкою архітектурних і телекомунікаційних рішень у процесі проектування нових сегментів мережі, як наслідок мені потрібна інформація про географічну прив'язку об'єктів.

Наведений вище список завдань підказує що адміністратор мережі є кризис-менеджером, тобто як щось зламається то починається авральний режим. Напруженість роботи в авральному режимі прямо залежить від того наскільки актуальна інформація про стан мережі і регламент відновлення працездатності. Звідси наслідок — потрібна якась «іграшка», яка здатна генерувати конфігурацію на підставі актуальних даних для комутаторів і системи моніторингу, це дозволить уникнути помилок в авральному режимі, а якщо вони виникли, то виявити їх на підставі патерну в процесі автоматичного інспектування мережі за алгоритмом запропонованим нижче.
image

Збір необхідної інформації для розробки

Ввідні дані
Мережа розподілена на кілька міст
Кожне місто є відокремленим підрозділом з єдиним контакт-центром і системою авторизації користувачів, при цьому взаємодія між містами відбувається за L3 а міська мережа побудована на L2.
Архітектурна інфраструктура мережі побудована відповідно до ГОСТ Р 53246-2008 СКС і включає в себе три підсистеми.
image
(лінійна структура універсальної кабельної системи)
image
(деревоподібна структура універсальної кабельної системи)
Як видно з малюнка вище є ділянка кабелю(товста лінія) у якому об'єднано кілька кабелів(волокон), і в точці консолідації вони розходяться на окремо розташовані будівлі. Життя це не ГОСТ і часто буває так:
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, і тому немає потреби повторюватись. Розберемося тільки в тому що нам потрібно.
  • Потрібна ідентифікація об'єкта. ФІАС містить унікальне значення до кожного діючого адресного об'єкта на відміну від КЛАДРа
  • Потрібно своєчасне оновлення найменування об'єктів (наприклад у мене є ряд об'єктів, які за час обслуговування декілька разів змінювали назву) ФІАС містить статус актуальності і статус дії;
  • Готова архітектура бази даних для зберігання адрес(ми тільки доповнимо її своїми даними).
Тепер чого не вистачає в системі ФІАС.
  • Відсутні координати будівлі(важливо для проектування та координації переміщення фахівців тех. підтримки);
  • Відсутня характеристики об'єкта (Поверховість, подъездность, кількість квартир/офісів, важливо для проектування та менеджерів з продажу).
З описаного вище стає зрозуміло, що використовувати ФІАС у вихідному стані позбавлене сенсу, однак ФІАС буде відмінним підставою для нашої системи генерації конфігурацій обладнання та моніторингу.

Продовження буде!
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.