На балансе 120 коммутаторов. В сети видно 97. Расхождение складывается из мелочей: часть железа списали и забыли отметить, часть стоит в филиале, который заводили подрядчики, часть попала в Excel под другим именем. Чтобы понять, какие именно 23 штуки разошлись, придется поднять выгрузку из 1С, опросить двух инженеров и сходить проверить две стойки.
Причина в том, что данные о сети хранятся в местах, которые между собой не сверяются. Часть адресов записана в Excel, а часть знает только тот инженер, который их когда-то выдавал. Топология нарисована в Visio, и этот файл последний раз открывали полгода назад. DHCP настроили, когда поднимали филиал, и с учетом с тех пор почти не сверяли. В Zabbix половина хостов заведена не так, как устройства стоят в реальности: имена другие, группы другие, а часть железа туда вообще не попала. Серийники, гарантии и закупки ведет бухгалтерия, и к стойке они не привязаны. Виртуальные машины работают в средствах виртуализации, а в сетевом учете их нет.
Пока сеть маленькая, с этим мирятся. Потом появляются филиалы, приходят подрядчики, меняются люди, и кто-нибудь обязательно просит выдать адрес прямо сейчас. Вот тогда расхождения и становятся нормой. Новый свитч уже стоит в стойке, а в таблице его еще нет. Резервацию поправили на DHCP, а в IPAM забыли. Спросите, что сейчас в этой подсети, и получите три разных ответа.
Причина в том, что данные о сети хранятся в местах, которые между собой не сверяются. Часть адресов записана в Excel, а часть знает только тот инженер, который их когда-то выдавал. Топология нарисована в Visio, и этот файл последний раз открывали полгода назад. DHCP настроили, когда поднимали филиал, и с учетом с тех пор почти не сверяли. В Zabbix половина хостов заведена не так, как устройства стоят в реальности: имена другие, группы другие, а часть железа туда вообще не попала. Серийники, гарантии и закупки ведет бухгалтерия, и к стойке они не привязаны. Виртуальные машины работают в средствах виртуализации, а в сетевом учете их нет.
Пока сеть маленькая, с этим мирятся. Потом появляются филиалы, приходят подрядчики, меняются люди, и кто-нибудь обязательно просит выдать адрес прямо сейчас. Вот тогда расхождения и становятся нормой. Новый свитч уже стоит в стойке, а в таблице его еще нет. Резервацию поправили на DHCP, а в IPAM забыли. Спросите, что сейчас в этой подсети, и получите три разных ответа.
Что ОдинХаб делает и чего не делает
ОдинХаб хранит целевое состояние инфраструктуры: что должно быть учтено, как названо, кому назначены адрес и интерфейс. Внутри связаны площадки и стойки, оборудование и интерфейсы, кабели, префиксы, VLAN, IP и VPN. Есть права доступа, журнал изменений и API.
Метрики он не опрашивает, трафик через него не идет, в резолвинге он не участвует. Раздачей адресов, разрешением имен, метриками и алертами по-прежнему занимаются Kea или Windows DHCP, BIND, Zabbix и остальной привычный стек. Заменять их ОдинХаб не пытается.
С внешними системами ОдинХаб обменивается данными через плагины. Дальше пять типичных ситуаций, на которых видно, как это работает.
1. Пустой учет в филиале
Открыли офис, сеть подняли подрядчики. В Excel по этому филиалу три строки. На деле там стоит стек Cisco или Huawei, настроены VLAN и аплинки. Садиться и переписывать это вручную никто не станет.
В IPAM заводят префикс площадки, а дальше сеть сканирует Сонар. Он сканирует префикс через nmap и SNMP, а при необходимости подключается еще и по SSH. В зависимости от того, что отдает устройство, Сонар собирает hostname, модель, серийный номер, интерфейсы, MAC, VLAN и сведения о соседях по LLDP и CDP.
Потом оператор смотрит превью и подтверждает устройства списком или по одному, так что в ОдинХаб попадает не все подряд. Сделано это намеренно. Если тащить в учет все, что ответило на скан, туда попадут лишние записи, и вычищать их придется руками.
После импорта в системе есть оборудование, интерфейсы, IP-адреса и VLAN. Если сканирование собрало данные о соседях и соединениях, система строит топологию. Площадке задают координаты в модуле Атлас, и филиал становится виден на карте.
2. Резервация в двух местах
Принтеру, контроллеру СКУД или IP-телефону нужен фиксированный адрес. Резервацию заводят на DHCP-сервере, а в учет собираются дописать позже. Через месяц на сервере одно, в таблице другое, и какая из записей верная, выясняется уже по факту.
Префикс и нужный IP хранятся в IPAM вместе со статусом, DNS-именем и MAC. Оттуда данные уходят на сервер, который раздает адреса.
Если это Kea на Linux, из IPAM уходят пулы и резервации. Если Windows DHCP, с сервером синхронизируются scopes и резервации, а на карточке префикса видно привязанные scope. Модели у этих серверов расходятся, поэтому плагины работают с каждым в его собственных понятиях.
Адрес меняют один раз, в ОдинХаб, и оттуда согласованные данные уходят на DHCP-сервер.
3. Secondary отдает старое
Зоны правят вручную на сервере. Сама по себе передача зоны работает автоматически: secondary видит новый serial в SOA, забирает зону и обновляется. Ломается все тогда, когда записи поменяли, а serial поднять забыли. Secondary решает, что обновлять нечего, и продолжает раздавать старые ответы. Добавьте сюда несколько представлений зоны (views), и появится еще путаница: одно поправили, а про второе вспомнили через неделю. Эталонного содержимого зоны нет нигде, единственным источником остается конфиг самого сервера.
Зоны, записи и представления ведут в DNS ОдинХаб. Это учет и эталон по содержимому. Оттуда зоны передаются на BIND и совместимые DNS-серверы: через полную передачу зоны, каталог зон и уведомления об изменениях. Для каждого представления свой ключ TSIG.
Клиенты продолжают обращаться к DNS-серверам. Secondary получает то же содержимое, что зафиксировано в учете.
4. Гарантия заканчивается незаметно
Закупки и RMA ведутся в 1С. Где именно стоит железо, помнят инженеры. Серийники приходится искать на коробках или на самом оборудовании. О том, что оборудование вышло из покрытия, узнают обычно тогда, когда оно уже сломалось.
Оборудование в ОдинХаб уже есть, его завели вручную или через Сонар. В модуле ITAM на актив добавляют цену, гарантию, контракт и привязку к устройству или стойке. Сверка с сетью показывает, совпадает ли учет с тем, что реально видно, или есть расхождение. Те самые 120 против 97. Сроки сервиса и гарантии видны заранее.
5. Учет и мониторинг расходятся
Новый свитч уже есть в ОдинХаб. В Zabbix про него узнают через неделю, шаблон назначают приблизительно. Бывает и обратное: хост в мониторинге есть, а в учете его нет. Виртуальные машины и вовсе могут работать в средстве виртуализации, но не быть отражены ни в сетевом учете, ни в мониторинге.
Плагин импортирует их в ОдинХаб. После этого интеграция заводит устройство или ВМ в Zabbix из данных учета. Группы, шаблоны и Zabbix proxy назначаются по настройке.
Метрики и алерты по-прежнему снимает Zabbix. ОдинХаб не подменяет опрос и не становится системой мониторинга. Его задача в другом: не допустить расхождения между учетом и мониторингом.
Метрики он не опрашивает, трафик через него не идет, в резолвинге он не участвует. Раздачей адресов, разрешением имен, метриками и алертами по-прежнему занимаются Kea или Windows DHCP, BIND, Zabbix и остальной привычный стек. Заменять их ОдинХаб не пытается.
С внешними системами ОдинХаб обменивается данными через плагины. Дальше пять типичных ситуаций, на которых видно, как это работает.
1. Пустой учет в филиале
Открыли офис, сеть подняли подрядчики. В Excel по этому филиалу три строки. На деле там стоит стек Cisco или Huawei, настроены VLAN и аплинки. Садиться и переписывать это вручную никто не станет.
В IPAM заводят префикс площадки, а дальше сеть сканирует Сонар. Он сканирует префикс через nmap и SNMP, а при необходимости подключается еще и по SSH. В зависимости от того, что отдает устройство, Сонар собирает hostname, модель, серийный номер, интерфейсы, MAC, VLAN и сведения о соседях по LLDP и CDP.
Потом оператор смотрит превью и подтверждает устройства списком или по одному, так что в ОдинХаб попадает не все подряд. Сделано это намеренно. Если тащить в учет все, что ответило на скан, туда попадут лишние записи, и вычищать их придется руками.
После импорта в системе есть оборудование, интерфейсы, IP-адреса и VLAN. Если сканирование собрало данные о соседях и соединениях, система строит топологию. Площадке задают координаты в модуле Атлас, и филиал становится виден на карте.
2. Резервация в двух местах
Принтеру, контроллеру СКУД или IP-телефону нужен фиксированный адрес. Резервацию заводят на DHCP-сервере, а в учет собираются дописать позже. Через месяц на сервере одно, в таблице другое, и какая из записей верная, выясняется уже по факту.
Префикс и нужный IP хранятся в IPAM вместе со статусом, DNS-именем и MAC. Оттуда данные уходят на сервер, который раздает адреса.
Если это Kea на Linux, из IPAM уходят пулы и резервации. Если Windows DHCP, с сервером синхронизируются scopes и резервации, а на карточке префикса видно привязанные scope. Модели у этих серверов расходятся, поэтому плагины работают с каждым в его собственных понятиях.
Адрес меняют один раз, в ОдинХаб, и оттуда согласованные данные уходят на DHCP-сервер.
3. Secondary отдает старое
Зоны правят вручную на сервере. Сама по себе передача зоны работает автоматически: secondary видит новый serial в SOA, забирает зону и обновляется. Ломается все тогда, когда записи поменяли, а serial поднять забыли. Secondary решает, что обновлять нечего, и продолжает раздавать старые ответы. Добавьте сюда несколько представлений зоны (views), и появится еще путаница: одно поправили, а про второе вспомнили через неделю. Эталонного содержимого зоны нет нигде, единственным источником остается конфиг самого сервера.
Зоны, записи и представления ведут в DNS ОдинХаб. Это учет и эталон по содержимому. Оттуда зоны передаются на BIND и совместимые DNS-серверы: через полную передачу зоны, каталог зон и уведомления об изменениях. Для каждого представления свой ключ TSIG.
Клиенты продолжают обращаться к DNS-серверам. Secondary получает то же содержимое, что зафиксировано в учете.
4. Гарантия заканчивается незаметно
Закупки и RMA ведутся в 1С. Где именно стоит железо, помнят инженеры. Серийники приходится искать на коробках или на самом оборудовании. О том, что оборудование вышло из покрытия, узнают обычно тогда, когда оно уже сломалось.
Оборудование в ОдинХаб уже есть, его завели вручную или через Сонар. В модуле ITAM на актив добавляют цену, гарантию, контракт и привязку к устройству или стойке. Сверка с сетью показывает, совпадает ли учет с тем, что реально видно, или есть расхождение. Те самые 120 против 97. Сроки сервиса и гарантии видны заранее.
5. Учет и мониторинг расходятся
Новый свитч уже есть в ОдинХаб. В Zabbix про него узнают через неделю, шаблон назначают приблизительно. Бывает и обратное: хост в мониторинге есть, а в учете его нет. Виртуальные машины и вовсе могут работать в средстве виртуализации, но не быть отражены ни в сетевом учете, ни в мониторинге.
Плагин импортирует их в ОдинХаб. После этого интеграция заводит устройство или ВМ в Zabbix из данных учета. Группы, шаблоны и Zabbix proxy назначаются по настройке.
Метрики и алерты по-прежнему снимает Zabbix. ОдинХаб не подменяет опрос и не становится системой мониторинга. Его задача в другом: не допустить расхождения между учетом и мониторингом.
Что в итоге
Заменять весь стек одной системой никто не предлагает. Kea, BIND, Zabbix и 1С остаются на местах и делают ту же работу. Меняется то, что у DHCP, DNS, учета активов и мониторинга появляется общая модель сети, на которую они опираются. Excel, устаревшая схема в Visio и три несогласованных набора данных перестают быть рабочим процессом.