Сразу скажу, что на написание мини статейки об основах документирования для наших подписчиков подтолкнул курс от уже упоминавшегося на канале Netskills. Вся основная механика у них на канале:
Курс подойдет для совсем “зеленых”, хотя и для матерых не помешает на x2 скорости пробежаться, чтобы систематизировать и обновить имеющуюся экспертизу. Я же в свою очередь хочу выдать вам основное резюме по данной теме и дополнить материал коллег полезными ништячками шаблонами для документирования.
Все еще интересно? Тогда погнали!
Итак обозначим состав рассматриваемой документации:
Структурная схема. Ее еще ласково называют структурой
Давайте рассмотрим обозначенную доку в двух контекстах:
- Проектирование/модернизация;
- Эксплуатация существующей инфраструктуры.
Проектирование/модернизация
Важен порядок разработки документации. И он таков как указано в списке выше. Т.е. идем от общего к частному — от структурной схемы к таблице кабельных соединений. На основании таблицы кабельных соединений уже составляется спецификация на закупку SFP модулей, кабеля, определяются требуемые характеристики оборудования в части количества интерфейсов, их типов и номинальных скоростей.
Эксплуатация существующей инфраструктуры
Чем отличается эксплуатация от проектирования/модернизации. Ну прежде всего эксплуатация это работа с тем что уже имеешь. По факту эксплуатация это про учет изменений. Если документации на существующую инфраструктуру нет или она косая и кривая, то стоит ее разработать с нуля. В данном случае можно пойти от частного к общему. Стоит начать с L2 схемы и пойти выше к структурной схеме. А на инженера по СКС делегировать задачу по заполнению КЖ. L2 схемы ему будет достаточно. Удобный шаблон КЖ дам вам ссылкой.
Итак, у нас есть корректная документация, как основа для дальнейшего учета. С точки зрения эксплуатации дальше просто не забывайте ее актуализировать.
- Так выглядит типовая, по дизайну современная структурная схема в draw.io (diagrams.net):
На структурную схему наносятся принципиальные моменты дающее полное, но общее представление о том:
- Cколько у нас провайдеров;
- Как у нас выстроена архитектура ЛВС: внешний периметр, ядро, уровень доступа;
- Как обстоит дело с отказоустойчивостью. Каскад устройств, как на картинке firewall и core switch, указывает на то, что используется стек. Вот какой конкретно стек: stack wise, vss с единым control plane или vPC/MCLAG домен с раздельным control plane тут не важно. Аспекты типов стекирования отражаются на схеме L2, в таблице кабельных соединений, а особенности настроек в документе под номером 6 — “Описание настроек”.
Еще раз заостряю внимание. Структурная схема — общая информация. Стеки/кластера и связанные с этим концепции укладываем на L2 схему.
2.Так выглядит типовая, по дизайну современная L3 схема в draw.io (diagrams.net):
После того как у нас есть “структурка” мы готовим (требуем от подрядчика) L3 схему.
L3 схема
На L3 схеме отображаются ключевые сегменты сети: стыки access-core, core-FW, FWs (border routers) — ISPs. Если описывается корпоративная инфраструктура, то к ключевым сегментам можно отнести сегменты в которых находятся основные корпоративные ресурсы: dns, почта, NTP, VIP пользователи, гостевой и пользовательский Wi-Fi. Если описывается инфраструктура уровня ЦОД, где может быть десятки тысяч сегментов, необходимо ограничится L3 сегментами лишь стыковых соединений. Сегмент удобно изображать в виде трубы с нанесением на нее адреса подсети и соответствующего идентификатора vlan. Целесообразно указывать default gateway. Оборудование уровня L2: L2 коммутаторы, хабы, медиаконвертеры на L3 схеме не изображаются!
3. Так выглядит типовая, по дизайну современная L2 схема в draw.io (diagrams.net):
После того как имеется структурная схема и L3 переходим к L2 схеме.
L2 схема
L2 схема это уже про частности канального, местами физического уровня. Тут мы уже делаем акцент на типе используемого кабеля: оптика или медь, стековое соединение. Указываем номер порта, тип линка: агрегированный или нет, режим: trunk или access, id vlans в транках (можно и не указывать, так как их может быть слишком много). Конкретные перечни vlan относящихся к информационным системам клиентов, пользователей и то каким транкам они принадлежат лучше всего отражать в документе “Описание настроек”. На схеме же можно/целесообразно отразить факт наличия in-band и out-of-band менеджмента. Т.е. на наличие управляющего трафика посредством основных каналов и альтернативного варианта управления инфраструктурой посредством выделенных каналов, менеджмент коммутаторов, консольных серверов.
Если оборудование установлено в стойках имеющих нумерацию, то целесообразно нанести на L2 схему имена по следующему принципу. К примеру СoreSW1 у вас находится в стойке F36, 27-й юнит в серверной №1. То целесообразно данному коммутатору дать такое имя: sr1-f36-27-core1. Т.е. sr- server room 1 и дальше логика ясна. Если оборудование разбросано по цодам, то можно заменить на dc#. Пример: dc1-k10-30-fw1 и dc2-g10-12-fw1. У вас есть межсетевые экраны в даталайне и селектеле. Вы определили, что в вашей картине мира даталайн это DC1, а селектел — DC2. Данную идею именования можно развить не только для схематичного отображения, но и по аналогии задавать FQDN этим устройствам на локальных DNS серверах.
На L2 схеме отражаются: коммутаторы, маршрутизаторы, ключевые сервера, рабочие места, аспекты стекирования.
На L2 схеме не отражаются: ip-адреса, виртуальные сущности: vdc, vrf, vds, vdom и тд. и тп.
Аспекты стекирования на L2 схеме
Traditional — два standalone коммутатора с наличием петли и работающим STP (стоит избегать таких вариантов архитектур, по возможности. Но в кампусе допускается);
StackWise Virtual-Physical/StackWise Virtual-logical — Два коммутатора представляются Access уровню как один виртуальный. Нет риска петель, не надо беспокоится о STP, нет простоя линков (must have в крупном enterprise и data center)
IP план
При проектировании IP план составляется в Excel таблице. Честно говоря это самый удобный способ так как можно использовать функционал группировок
Вот если говорить не про проект, а про эксплуатацию действующей инфраструктуры, то существует два подхода:
- Ведение такой же Exel таблицы. Просто функционально, но есть нюансы. Как правило плодится много копий и по итогу информация зачастую не 100% актуальна. Если документ ведет один человек, то это куда не шло. Если к планированию и учету IP пространства причастны >1, то целесообразно использовать специальные продукты (пункт 2).
- Система централизованного учета IP пространства. Есть один бесплатный и удобный продукт под названием phpipam, лично его использую. С этим инструментом планирование и учет IP пространства циклопически упрощается (https://phpipam.net/)
Таблица кабельных соединений aka кабельный журнал (КЖ) aka схема коммутации
В организациях наиболее часто встречается именно КЖ, как оперативный документ инженера СКС (структурированная кабельная система). В проектах же редко используется понятие кабельного журнала, чаще всего это таблица кабельных соединений или схема коммутации. Если руководствоваться моделью OSI, то это уровень L1 — физический. Редко, но можно услышать такое понятие как L1 схема. По факту это все об одном и том же
Кабельный журнал. <<скачать шаблон>>
Маркер — идентификатор связи (по аналогии с ключевым полем в БД). В продаже есть специальные принтера. Можно использовать ручные бобины.
Откуда (Ряд/Шкаф/Юнит)-Оборудование-Плата/порт
Куда\Откуда — транзитные (промежуточные) коммутации. Если оконечное оборудование, в нашем примере это блейд корзина HP C7000 подключается портом OA1 (On-board administrator) непосредственно к менеджмент коммутатору Cisco WS-C3750X-24 (Маркер 0051), то блоки Куда\Откуда пустые. А вот если взять маркер 0094, то связь между с7000 и коммутаторами ядра пролегает через промежуточную патч-панель и нетподиум (оптическая СКС);
Куда — собственно так же как и Откуда — Оборудование-Плата/порт. Обычно (в большинстве случаев) Откуда — оконечное оборудование: рабочее место, сервер. Куда — коммутатор. Но если связь отражает межкоммутаторное взаимодействие, кластерное взаимодействие, то слева отражается условный 1-й номер, а справа условный 2-й номер.
Тип разъема: RJ-45, MM/SM LC/MM SC и тд. и тп. По данному столбцу сразу понятно что у вас за физика оптика или медь, какой тип оптики мультимод или синглмод, какой тип оптического разьема.
Количество кусков (патчкордов) и их длина— тут все должно быть понятно.
Кто и когда проводил работы — тоже очень важный момент.
Описание настроек
Совершенно необходимы документ при проектировании/модернизации. В практике я встречал еще такой синоним как пусконаладочные карты. В целом, данные документы про настройки по шагам. В них описывается текущая настройка, какие вносятся изменения и для чего, какой результат ожидается. Когда будет этап пусконаладки если ожидаемый результат получен — успех, нет — разбираемся в чем проблема и уже только устранив которую идем дальше;
Дополнительные документы:
7. Расположение оборудование в стойках <<скачать шаблон>> (см. вкладку СКС-2)
8. Схемы подключения питания <<скачать шаблон>>
Очень важные схемы. Предположим у вас в стойках по два независимых луча. Подрядчик или ваш инженер взяли два одноблочных устройства отказоустойчивого кластера и подключили к одному лучу. Луч вырубился не штатно или планово на регламент и нет больше вашего клачтера — весь сегмент прилег. Если схема имеется, по ней монтировали и по нейже осуществлена приемка и испытания, то не будет вам печали. Возьмите на вооружение) “Знаем, плавали, вся жопа в ракушках”)
P.S. Ссылка на схемы в draw.io
Немного поддержу Netskills еще рекламкой:
Если материал понравился — лучшая помощь порекомендовать канал товарищу IT-шнику. Лишними знания не бывают)
Спасибо за внимание!