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

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



    К сожалению, не могу вспомнить, с чего все началось. На момент прихода в компанию, 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-адресу).


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

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

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

      Что такое Рапан?
        • +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
                В предыдущей конторе вокруг 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
                          Вот интересно, кто карму сливает, прокомментируйте хоть. Вам, видимо, есть что сказать?

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