Хабр, и снова привет! В прошлом году я уже писал одну
статью, после этого было несколько попыток написать новую, но все не выходило. Наконец появилась более или менее сформированная мысль, которую я и постараюсь оформить в виде полноценной статьи. Речь пойдет о работе с устройствами, точнее о том, как мы смогли связать базу данных используемого оборудования, их географическое расположение с используемым биллингом. Интересующиеся — под кат.
К сожалению, не могу вспомнить, с чего все началось. На момент прихода в компанию, Quantum GIS уже использовался, и частично сеть была нанесена на карту. Познакомиться с кугисом мне пришлось в связи с поставленной задачей — нанести все используемое оборудование в купленном провайдере (как раз в том провайдере, в который я и устроился). Надо сказать, на тот момент я вообще не понимал, для чего могут использоваться карты — ну ничего, мое мнение достаточно скоро изменилось на противоположное.
В принципе все просто, 4 слоя:
- Устройства (коммутаторы, медиаконвертеры, сервера и т.д.);
- Логические связи (откуда куда идет сигнал);
- Муфты, сплайс-кассеты;
- Кабель: оптика и медь (если используется в качестве магистралей).
2 таблицы в Postgre SQL, первая для хранения точек, вторая — для линий.
Муфта это, коммутатор, или важный клиент — определялось полем type. На тот момент типов было несколько, и о возможных проблемах в будущем никто не думал.
Прошло какое-то время, устройства были нанесены. Хронологию событий передать уже не смогу, так как к каждой задаче возвращались неоднократно, каждый раз подтягивая гайки. В любом случае, нанесенные устройства не давали особо никакой полезной информации. Устройства продолжали кочевать, номера портов меняться (имею ввиду монтажников, которым по боку, в 25-ый или 28-ой порт подключать коммутатор). По большому счету, на тот момент мы смогли увидеть некоторые проблемные места — использование utp в качестве магистралей и разросшиеся сегменты (было и такое, что с одного коммутатора было подключено до 40 других, и когда пропадало электричество в этом доме, без интернета оставались до 30 домов). Уже на этом этапе ставились задачи руководителям филиалов по устранению этих косяков.
Что же касается работы с картой, то мы могли только использовать Zabbix, который тупо пинговал устройства и подкрашивал красным цветом те, что не доступны.
Как я писал в прошлой статье, параллельно шла работа над созданием новой оболочки с наращиванием функционала для UTM. Разбивая адреса абонентов по запятой с пробелом мы получали список населенных пунктов, улиц и домов. Поработав с этим списком мы получили свою собственную базу адресов. А к стандартной таблице UTM — users добавили поле house_id, по которому мы могли получить правильный адрес абонента без сокращений и опечаток вплоть до дома. В новой оболочке адрес абонента стал набором селектов вместо одного текстового инпута. Да, кстати, КЛАДР не совпадает с тем, что пишется в паспортах у абонентов, поэтому мы не стали его использовать.
Получив список используемых адресов, мы привели в порядок и адреса у устройств на карте. Таким образом мы получили определенное количество абонентов и устройств, у которых совпадал house_id. Уже что-то. Проанализировав эту информацию мы получили список домов, в которых не числится ни одного устройства, а там подключены несколько абонентов.
Совсем забыл сказать, в нашем случае доступ к Интернету обеспечивался посредством vpn-соединения, поэтому пробелы в используемом оборудовании имеют место быть, особенно в случае поглощения одним провайдером другого, когда часть штата купленного провайдера отправляется за борт.
Так вот, есть список домов без устройств и с абонентами. Каждый случай уникален, где-то медная перекидка на соседний дом, где неуправляемый коммутатор подключен и т.д и т.п. Все проблемные места выявлены и устранены. Вновь найденные медные перекидки — под замену на оптику. Далее я перейду к другой теме, а подводя итог вышесказанного, повторюсь — к этим задачам мы возвращались неоднократно и в итоге смогли достичь 100%-ного знания о состоянии сети.
Далее я думаю стоит поговорить о логической составляющей процесса. Вообще, о настройке коммутаторов наверное есть смысл набросать отдельный пост, но и в этой теме не показать некоторые аспекты нельзя — не раскрою тему иначе.
Говоря о том, что мы смогли выявить разросшиеся сегменты, я предполагаю, что мы уже определили какие-то стандарты. Да, они есть. Постараюсь кратко их перечислить, но если что-то непонятно — спрашивайте в комментариях, отвечу с удовольствием.
- Оборудование находится в сетях 192.168.x.0/24;
- Каждый коммутатор 192.168.x.1 задает столько сегментов, сколько гигабитных портов у него есть (не более 24). К примеру, D-Link DGS 3627G — 24 сегмента. x — скажем так, номер сети (растет с каждым L3);
- Каждый сегмент состоит не более чем из 10 устройств с не более чем 240 абонентскими портами;
- Каждый сегмент начинается с коммутатора, чей ip-адрес формируется по принципу: 192.168.x.y0, где y — номер порта L3, с которого сегмент подключен. Например, для коммутатора L3 с ip-адресом 192.168.37.1 куст на 19 порту начнется с коммутатора 192.168.37.190 (т.е. последнее число в адресе первого устройства всегда будет кратным 10);
- Остальные коммутаторы в сегменте (не более оставшихся 9 из 10 управляемых) получают адреса 192.168.x.y1-192.168.x.y9;
- Первый коммутатор в сегменте задает ip-адреса абонентов, подключенных в этом сегменте так: 10.x.y0.n, где n — порядковый номер абонента, растет вместе с количеством абонентов в сегменте. Мы добавили некоторое ограничение, n не может быть меньше 10 (единичка — шлюз, остальные на всякий случай держим в резерве), т.е. абонентам, подключенным от коммутаторов 192.168.37.190-192.168.37.199 — достанутся адреса 10.137.190.10-10.137.190.249;
- Вся сеть управления вынесена в отдельный vlan, на каждый абонентский сегмент также выделен vlan (к этой статье отношения не имеют, поэтому останавливаться на них не стану).
Таким образом, в каждом сегменте мы можем теоретически подключить до 240 абонентов, на практике таких количеств нет (максимальные числа колеблются в районе 50-60 абонентов).
Сейчас сеть соответствует тем требованиям, что были перечислены. Да, эти требования не лишены минусов, но тем не менее мы получаем полностью управляемую и структурированную сеть. В связи с внедрением gpon, вносятся некоторые корректировки, но на них я останавливаться не стану.
На тот момент, когда эти постулаты формировались, адреса коммутаторам назначались по щучьему велению. В самом начале был случай, когда один администратор настраивал коммутатор в одном населенном пункте, я в другом, в итоге заняли один и тот же ip-адрес. С этим надо было что-то делать.
А ведь помимо разделения по сегментам, мы должны задавать однообразную модель работы железа глобально, по всей сети. Отчетливо отложилось в памяти, как меня учили настраивать коммутаторы. Было несколько текстовых файлов с примерами конфигов для разных железок, причем на каждое конкретное устройство конфигов было несколько и в принципе идентичное железо (скажем DES 3028 и 3200-28) настраивалось по-разному. Здесь есть настройка времени, тут нет; здесь есть ACL, и здесь есть, но отличается.
В 2011 году по Тверской области прошли сильные грозы, часть портов коммутаторов по всей сети погорело, сеть процентов на 30-40 легла. Легла потому, что хоть мозги у коммутаторов не пострадали, петляющие порты сделали свое дело — 100% нагрузка на процессор и коммутатор уже не хочет с нами общаться. 2 недели бессонных ночей (без преувеличения) — монтажники не успевали возить коммутаторы в офис, поэтому приходилось ждать те моменты, когда коммутатор по месту установки все-таки оживал на какие-то мгновения, бегом в него и настройки storm control просто из буфера. Вот этот и другие примеры сделали свое дело — были сформированы и другие стандарты. Скриптами залили нужные конфиги по всей сети, проблемы исчезли. Да, в прошлом году на всех транзитных коммутаторах выставили ИБП, разницу до и после не описать. Zabbix стал названивать в разы реже. Помимо решения проблемы перебоев с электричеством решили и проблему с грозами — дешевле поменять Рапан, чем коммутатор.
С этим разобрались. Следующий логичный шаг — снимать mac-адреса на портах коммутаторов. Зная mac-адреса абонентов, смогли определить кто в какой порт включен. Снова всплыли косяки. Оказывается стоит управляемый 24-портовый коммутатор, 7 абонентов, 2-ое на 1-ом порту, 3-ое на 7-ом и несколько по портам разбросаны. Ага, опять пятипортовые хабы. Ну да, монтажники в щитке поставили, чтобы на этаж второму абоненту utp не тащить. Ликвидируем. Навели порядок. Абонентов перепривязали. Наблюдаем, точнее идем дальше. Бац! Возвращаемся назад. Оказывается, в одном из городов монтажники, которые на сделке, те, что только на подключениях, когда абонента нового включают, чтобы времени меньше тратить берут и выдергивают уже работающего абонента с порта (визуально же видно — работает) и в этот порт включают нового, а работавшего куда попало. Они за это не отвечают. У другого монтажника всплывает заявка — у абонента интернет пропал. Причина, думаю, понятна. Вставили таких люлей руководителю филиала и его остолопам, что часть этих сдельщиков ушла. Хороший урок остальным. Где-то сохранял скриншот (искать лень), за дней десть примерно — 7 абонентов в одном порту побывало (новый дом так включали). Забегая вперед, скажу — на тот момент мы уже оттестировали систему — при выборе адреса абонента предлагались только определенные коммутаторы. А выбирая коммутатор — на выбор предлагались порты с пометками (свободен/сгоревший/занят/хаб) — т.е. порт можно выбрать любой, но предупреждение будет. Как только порт выбран и если он не помечен в системе, как сгоревший — на коммутатор посылается команда включения порта. Здесь много аспектов, я не буду на них обращать ваше внимание. В-общем, в этом городе, с разрешения учредителей, мы эту систему и включили. Бегали монтажники в мыле — проверили всех абонентов, у которых пропал интернет. Да, это было скажем так, грубо, по отношению к абонентам, и я обычно ярый противник экспериментов над абонентами, которые со своей стороны обязательства по ежемесячной оплате выполняют, но все делалось для них. Так, в течении нескольких дней мы получили жесткую привязку абонентов по портам и заставили монтажников работать согласно регламента. Подводя итог темы привязки к портам, могу сказать — по всей сети привязки impb созданы, все неиспользуемые порты выключены. По каждому абоненту мы можем сказать миграцию по портам.
Прежде, чем перейти дальше, хочу вернуться к уже сказанному, обозначить достигнутое и выявить то, что еще предстоит решить.
Мы имеем:
- Таблицу устройств;
- 3 таблицы с населенными пунктами (тут же области и районы), улицами и домами (или другими объектами);
- Таблицу абонентов.
Из вышесказанных постулатов определяем, что ip-адрес железа определяет ip-адрес абонента. Отсюда следует, что в таблице абонентов мы храним устройство как ip-адрес. Но ip-адрес это всего лишь один из параметров устройства, хранимого в таблице devices. Основным идентификатором в ней всегда был gid. Но gid подразумевает изменение — устройство может быть снято, а вместо него установлено новое, с присвоением ему того же ip-адреса. Кстати, над этой задачей я работаю сейчас.
Мы помечаем порты как сгоревшие и они никогда не будут включены, точнее до тех пор, пока устройство не отдадут в ремонт и оно не вернется назад с пометкой “восстановлено”. Но отправляя устройство в ремонт, его могут удалить с карты (могли), и вся информация будет потеряна. Сегодня, сейчас, мы не знаем, какое поле и где важнее. К сожалению, не все устройства имеют серийный номер (по-моему, из ремонта даже устройства возвращались с стертым sn, имею ввиду не бумажку конечно), но mac у нужных нам устройств есть у всех. Поэтому триггерами PostgreSQL в лог пишу все события с указанием всех полей (и gid, и ip, и sn, и mac). Пометки о сгоревших портах хранятся в таблице с привязкой к mac-адресу.
Теперь о карте. Изначально нанести точку в кугисе мог любой желающий. Сегодня эта операция запрещена триггерами в БД. Вся работа с железом перенесена в веб-интерфейс. Есть понятие “склад” (их несколько, по количеству офисов-филиалов), добавление устройств позволено определенным лицам, с указанием mac-адреса, серийного номера и модели устройства. Любой чих, как я уже говорил, пишется в лог. Более того, Zabbix регулярно снимает все параметры с железа, поэтому несанкционированная замена коммутатора приводит к тому, что абоненты работать не смогут, а руководителю вставят пистон. В комментариях к прошлой статье, насколько помню, был комментарий, что невозможно такую систему построить. Возможно. Закрутили гайки, наказали виновных, и всё.
Далее, ip-адрес устройства вообще волшебная переменная. Он отслеживается в нескольких системах, в том числе и при формировании файла конфигурации. Да, мы эту работу на скрипт переложили. Скрипт по ip-адресу создает конфиг и его пока только залить остается, а в дальнейшем и заливаться автоматом будет, чтоб лишнего не видели. Так вот, если предварительно на карте не была произведена подготовка с переносом устройства в нужную точку (место будущей дислокации), конфиг сформирован не будет. Вот я и подошел к следующему пункту.
Дело в том, что изначально, все эти линии, полигоны и точки на карте не были связаны между собой никак. Была подложка OSM, были 4 слоя, о которых писал выше и на этом всё. Набросав пару триггеров на изменение геометрии точки (читай устройства) и настроив прилипание при рисовании, мы смогли приклеить линии связей к устройствам. Таким образом, при перемещении на карте устройства меняется и точка соприкосновения “линка” с устройством. Так называемые линки привязаны к оборудованию (ровно как и оптика к муфтам) по нескольким параметрам. Во-первых, геометрически — начальная или конечная точка линии должна совпадать с координатами точки-устройства. Во-вторых, есть поля dstart, dstartport, dend, dendport, которые определяют с какого устройства и порта в какое устройство и порт идет этот самый линк. С этой задачей пришлось повозиться — проверить все нарисованные линии, все устройства, проверить геометрии, введенные значения, после этого навесить триггеры и наслаждаться полученным результатом.
Картина перед изменением координат устройства:
и после:
Сейчас, анализируя mac-адреса на портах коммутатора и зная mac-адреса устройств и абонентов, мы можем видеть, какая информация в этих линках не является достоверной. Благодаря этой системе визуально можно видеть какие потоки трафика идут между коммутаторами, какие порты задействованы под магистрали, какие виланы проброшены и т.д. и т.п. Вся эта информация также используется при создании конфига устройства. Сейчас, для того, чтобы привязать к порту управляемого коммутатора второго абонента требуется указать на карте устройство, с которого будет производиться подключение и нанести линк с управляемого коммутатора в эту тупую железку. Что поделать, бывают и такие ситуации — 25-ый абонент, а портов 24, но мы должны знать об этом. В противном случае абонента будет невозможно привязать к порту, а следовательно и не будет создана impb запись и работать этот абонент не сможет.
Собственно, концом статьи это назвать никак нельзя, но что поделать — надо ехать за дочкой (сегодня в садике короткий день), а если сохраню в черновике на полуслове, то вернувшись назад в очередной раз удалю написанное.
Я уже привел несколько под-итогов, поэтому повторяться на деталях не стану. Мы смогли связать 2 совершенно не связанные системы в одну и как итог — получили автоматическую настройку оборудования (у нас есть три разных типа конфигураций для каждого коммутатора). Конечно это не все:
- Используемые типы объектов (муфты, коммутаторы и т.д.) были разделены дважды (базовые классы, и более подробные реализации каждого класса);
- По устройствам на карте вычислили id домов из OSM, расширили собственную таблицу домов, добавив туда osm_id и osm_geometry (и таким образом знаем правки интересующих нас домов);
- Нанесли часть не существующих в проекте OSM домов;
- Добавили возможность участия одного коммутатора в нескольких сегментах (это когда 2 провайдера один коммутатор используют);
- Перевели абонентов с vpn на ipoe (только с привязкой по mac-адресу).
и много-много всего другого.
Понимаю, что статья, как и в прошлый раз, получилась несколько размытой, но расписать четко все процессы, которые происходят внутри компании, не представляю возможным. Если какая-то тема требует более детального рассмотрения, обращайтесь — отвечу.
16 мая на конференции YaC/m Яндекс объявил о запуске новой поисковой платформы «Острова». Уже в первые две недели после анонса вебмастера создали около 1000 островов для своих сайтов. Но новая платформа вызывает и множество вопросов. Мы уже рассказывали на Хабре о том, как Острова выглядят и почему они визуально устроены именно так.
/ Москва / 29.06.2013 / Участие бесплатное 
