0,0
рейтинг
31 мая 2013 в 15:08

Разработка → Сказ о том, как мы карту с биллингом дружили

Хабр, и снова привет! В прошлом году я уже писал одну статью, после этого было несколько попыток написать новую, но все не выходило. Наконец появилась более или менее сформированная мысль, которую я и постараюсь оформить в виде полноценной статьи. Речь пойдет о работе с устройствами, точнее о том, как мы смогли связать базу данных используемого оборудования, их географическое расположение с используемым биллингом. Интересующиеся — под кат.



К сожалению, не могу вспомнить, с чего все началось. На момент прихода в компанию, Quantum GIS уже использовался, и частично сеть была нанесена на карту. Познакомиться с кугисом мне пришлось в связи с поставленной задачей — нанести все используемое оборудование в купленном провайдере (как раз в том провайдере, в который я и устроился). Надо сказать, на тот момент я вообще не понимал, для чего могут использоваться карты — ну ничего, мое мнение достаточно скоро изменилось на противоположное.

В принципе все просто, 4 слоя:

  • Устройства (коммутаторы, медиаконвертеры, сервера и т.д.);
  • Логические связи (откуда куда идет сигнал);
  • Муфты, сплайс-кассеты;
  • Кабель: оптика и медь (если используется в качестве магистралей).


2 таблицы в Postgre SQL, первая для хранения точек, вторая — для линий.

Муфта это, коммутатор, или важный клиент — определялось полем type. На тот момент типов было несколько, и о возможных проблемах в будущем никто не думал.

Прошло какое-то время, устройства были нанесены. Хронологию событий передать уже не смогу, так как к каждой задаче возвращались неоднократно, каждый раз подтягивая гайки. В любом случае, нанесенные устройства не давали особо никакой полезной информации. Устройства продолжали кочевать, номера портов меняться (имею ввиду монтажников, которым по боку, в 25-ый или 28-ой порт подключать коммутатор). По большому счету, на тот момент мы смогли увидеть некоторые проблемные места — использование utp в качестве магистралей и разросшиеся сегменты (было и такое, что с одного коммутатора было подключено до 40 других, и когда пропадало электричество в этом доме, без интернета оставались до 30 домов). Уже на этом этапе ставились задачи руководителям филиалов по устранению этих косяков.

Что же касается работы с картой, то мы могли только использовать Zabbix, который тупо пинговал устройства и подкрашивал красным цветом те, что не доступны.
Как я писал в прошлой статье, параллельно шла работа над созданием новой оболочки с наращиванием функционала для UTM. Разбивая адреса абонентов по запятой с пробелом мы получали список населенных пунктов, улиц и домов. Поработав с этим списком мы получили свою собственную базу адресов. А к стандартной таблице UTM — users добавили поле house_id, по которому мы могли получить правильный адрес абонента без сокращений и опечаток вплоть до дома. В новой оболочке адрес абонента стал набором селектов вместо одного текстового инпута. Да, кстати, КЛАДР не совпадает с тем, что пишется в паспортах у абонентов, поэтому мы не стали его использовать.

Получив список используемых адресов, мы привели в порядок и адреса у устройств на карте. Таким образом мы получили определенное количество абонентов и устройств, у которых совпадал house_id. Уже что-то. Проанализировав эту информацию мы получили список домов, в которых не числится ни одного устройства, а там подключены несколько абонентов.

Совсем забыл сказать, в нашем случае доступ к Интернету обеспечивался посредством vpn-соединения, поэтому пробелы в используемом оборудовании имеют место быть, особенно в случае поглощения одним провайдером другого, когда часть штата купленного провайдера отправляется за борт.

Так вот, есть список домов без устройств и с абонентами. Каждый случай уникален, где-то медная перекидка на соседний дом, где неуправляемый коммутатор подключен и т.д и т.п. Все проблемные места выявлены и устранены. Вновь найденные медные перекидки — под замену на оптику. Далее я перейду к другой теме, а подводя итог вышесказанного, повторюсь — к этим задачам мы возвращались неоднократно и в итоге смогли достичь 100%-ного знания о состоянии сети.

Далее я думаю стоит поговорить о логической составляющей процесса. Вообще, о настройке коммутаторов наверное есть смысл набросать отдельный пост, но и в этой теме не показать некоторые аспекты нельзя — не раскрою тему иначе.

Говоря о том, что мы смогли выявить разросшиеся сегменты, я предполагаю, что мы уже определили какие-то стандарты. Да, они есть. Постараюсь кратко их перечислить, но если что-то непонятно — спрашивайте в комментариях, отвечу с удовольствием.

  1. Оборудование находится в сетях 192.168.x.0/24;
  2. Каждый коммутатор 192.168.x.1 задает столько сегментов, сколько гигабитных портов у него есть (не более 24). К примеру, D-Link DGS 3627G — 24 сегмента. x — скажем так, номер сети (растет с каждым L3);
  3. Каждый сегмент состоит не более чем из 10 устройств с не более чем 240 абонентскими портами;
  4. Каждый сегмент начинается с коммутатора, чей ip-адрес формируется по принципу: 192.168.x.y0, где y — номер порта L3, с которого сегмент подключен. Например, для коммутатора L3 с ip-адресом 192.168.37.1 куст на 19 порту начнется с коммутатора 192.168.37.190 (т.е. последнее число в адресе первого устройства всегда будет кратным 10);
  5. Остальные коммутаторы в сегменте (не более оставшихся 9 из 10 управляемых) получают адреса 192.168.x.y1-192.168.x.y9;
  6. Первый коммутатор в сегменте задает ip-адреса абонентов, подключенных в этом сегменте так: 10.x.y0.n, где n — порядковый номер абонента, растет вместе с количеством абонентов в сегменте. Мы добавили некоторое ограничение, n не может быть меньше 10 (единичка — шлюз, остальные на всякий случай держим в резерве), т.е. абонентам, подключенным от коммутаторов 192.168.37.190-192.168.37.199 — достанутся адреса 10.137.190.10-10.137.190.249;
  7. Вся сеть управления вынесена в отдельный 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-адресу).


и много-много всего другого.

Понимаю, что статья, как и в прошлый раз, получилась несколько размытой, но расписать четко все процессы, которые происходят внутри компании, не представляю возможным. Если какая-то тема требует более детального рассмотрения, обращайтесь — отвечу.
Владимир Коровин @vakorovin
карма
79,5
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

Комментарии (23)

  • +1
    дешевле поменять Рапан, чем коммутатор

    Что такое Рапан?
    • 0
      • +3
        Стихи у них на сайте клевые.

        Купаясь, резвый мальчуган
        Со дна достал рапан.
        Взрослеет славный мальчуган,
        Манить стал парня чистоган

        Тут детский опыт нужен нам:
        Чтоб доступ перекрыть ворам,
        Поставь скорее тут и там
        Недорогой прибор «Рапан»!
  • +2
    Выглядит неплохо! Эт самое, что хотелось-бы спросить:
    Судя по скриншоту правильно-ли я понимаю, что это самопал с
    • Twitter bootstrap
    • Биллинг
    • подобие ERP\CRM
    • QGis
    • EMS\SNMP модуль для оборудования

    и все в одном флаконе из браузера?

    Это можно увидеть\потыкать?
    • 0
      — Бутстрап натягиваю прямо сейчас, так что да.
      — Биллинг фактически самописный, но т.к. для комиссий требуется сертифицированный, то обеспечиваем обратную совместимость. Т.е. при работе через эту систему информация пишется и туда и сюда. Интерфейс UTM закрыт сейчас, поэтому проверять на несоотвествие перестали, а раньше еще и следили, чтоб информация совпадала.
      — Так и есть, здесь и абоненты и заявки и железо и всякие проверки и отчеты. Да все в-общем тут собрано.
      — QGis да, вы статью читали?
      и SNMP и банальный telnet — сейчас используется три типа конфигураций. Базовая — при настройке коммутатора (все, что требуется для безопасной работы самого коммутатора), Привязки абонентов, и третья — резка скорости абонентам на порту, в случае, если абонент не оплачивает Интернет в течении 2х месяцев до 64кб — это сделано недавно, из-за того, что некоторые абоненты по акции подключаются бесплатно и держат шнурок только для бесплатных каналов iptv, пользуясь интернетом от конкурентов, или вообще не пользуясь интернетом. Так вот каждая модель коммутатора описана тремя файлами. Каждый такой файл принимает несколько параметров и на на основе их создает конфигурацию. Очень удобно, раньше все хранилось в одном файле, но как только количество используемого железа стало расти, всякие «если да кабы» стали непомерно раздувать размер скрипта и усложнять его поддержку.
      — Если-б не костыли с используемым биллингом, давно-б на github выкинул, а так и знаю, что система классная создана и разработчиков не притянуть.
      • 0
        для комиссий достаточно предоставить сертификат про убогий UTM. А по факту писАть для себя/людей приемлемый функционал. У нас, например, полностью был переписан тарификатор после ржаки над mysql-логами работы UTM-овского. Опять же акции (попади в ад коммерсы) и прочее прочее
  • 0
    какой у вас брас и почему бы не заменить часть железа на агрегациях?
    • 0
      Сервера с linux на борту. А что касается замены, а зачем? Задача vlan на абонента не стоит. Все работает, зачем трогать то, что работает? Да и деньги тратятся в немалых объемах на перестроение купленных сетей. Возможно когда-то руководство и задумается на этим, но пока не видим высоких нагрузок, а следовательно и аргументов нет.
  • 0
    Я сейчас пытаюсь приучить Яндекс-карты к Заббиксу. Пока показывает точки с проблемами на карте.
    Хочу ещё добавить возможность нанесения коммутационных линий связи, ну, возможно ещё некоторые фичи.
    Начал всё один парень здесь, я продолжаю эпопею на github
  • 0
    Не понял, вы точки и линии при помощи postgis в postgre храните?
    и как выводите в openlayers?
    • 0
      Да, именно постгис и используем. А как выводим, посмотрите сообщения Александра, 2,5 года назад, когда я устроился на работу, карта уже существовала.
  • 0
    Глобализация. Вас еще не продали купили?
    • 0
      Нет, не продали )
  • 0
    В предыдущей конторе вокруг UTM написали на PERL+TemplanteToolkit оболочку. В ней были мониторинг, тикет трекер, рабочее место тех.поддержки, склад, всевозможная статистика, территориальное разделение по монтажникам, управление активным оборудованием через Telnet/snmp, и масса других функций. Потом нас продали, проект умирает, в связи с внедрением другого биллинга.
  • 0
    >>Да, кстати, КЛАДР не совпадает с тем, что пишется в паспортах у абонентов
    С этим все сталкивались.
    Мне вот интересно, это только «в этой стране» официальная база домов (да и все остальные базы) отличается от реальности, и только в этой стране такой бардак и её за 10-15 лет не могут привести в порядок?
  • 0
    Не сочтите за рекламу, но userside.ua
    Готовый продукт.
    сам пользуюсь и другим рекомендую.
    платный.
    разработчики по русски понимают прекрасно.
    меганавороченный. там есть все, что Вы описали в статье и даже много больше.
  • 0
    Тоже недавно заморочился у себя с картами. Потому что реализация карт в zabbix'е — это что-то.
    Тайлы делает tilestream, карта — leaflet, данные с OSM, данные по доступности и истории доступности коммутаторов — с zabbix'a. Результат выглядит вот так:
    habrastorage.org/storage2/b47/578/5d7/b475785d7a636572af80af2ed9e0986f.png
    • 0
      А что у Вас за информацию коммутатор показывает?
      Сеть неуправляемая?
      • 0
        Когда коммутатор уходил в онлайн-офлайн (конкретно этот коммутатор выключает на ночь клиент-торговыйцентр).
        Не совсем понял, что имеете в виду под управляемостью сети?
        • 0
          Наверное не совсем корректно выразился, но Вы меня сейчас поймете.
          В нашем случае под наблюдением находится каждый порт и каждому порту мы придаем значение.
          В момент, когда в систему добавляется новый тип устройства, описываются порты, которые в нем есть.
          И дальнейшая работа с устройством зависит и от этого описания.
          Линки, которые можно видеть на приведенных изображениях — показывают информацию с какого порта в какой подключены два устройства. Если здесь изменить значения портов, то во-первых эту информацию проверит Заббикс на соответствие (по mac-адресам), а во вторых это повлияет на проброс нужных виланов.
          Из Вашего изображения не ясно, какую смысловую нагрузку, кроме собственно иерархии, несут линки. Отсюда я сделал вывод, что управление портами в Вашем случае не происходит. А также не заметил никаких различий между изображениями коммутаторов, отсюда либо все оборудование однотипно, либо не важно какое оно.
          Как-то так ))
          • 0
            Теперь понял ).
            Фактически у меня показывается только состояние (ping test) коммутатора, надо было сразу это написать. Линки действительно показывают только иерархию, чтобы визуально понимать что происходит. Как это будет выглядеть завтра — я пока не знаю, но у вас увидел много интересных мыслей.
  • 0
    В нашем случае Заббикс только меняет значения полей в БД, а не рисует карты. Промахнулся.
  • 0
    Вот интересно, кто карму сливает, прокомментируйте хоть. Вам, видимо, есть что сказать?

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.