Мониторинг регенераторов SM-xx

[san]

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

Что нужно от регенераторов:

1. Собственно мониторинг. Периодическое обновление информации о состоянии участков линейного тракта, накопление статистики и т.д..
2. Детализация аварии на линейном тракте. Допустим тракт состоит из N участков (N-1 регенераторов) и в момент аварии пользователи хотят получить детализированное сообщение в программе мониторинга и логах, на каком участке и на какой паре произошла авария.

Сложности текущего варианта:

1. Для мониторинга нужно периодически посылать команду опроса, т.е. программе мониторинга кроме чтения придётся делать ещё и запись в определённую переменную, либо посылать команду другими средствами. В любом случае это дополнительная сложность.
2. При новом опросе таблица очищается и до окончания опроса в таблице не корректные данные (не понятно регенератор пропал(не отвечает) или опрос ещё не завершен) а точного признака окончания опроса нет, есть некоторые критерии, но мы их сами ещё не можем до конца сформулировать и я думаю что перекладывать задачу определения критериев конца опроса на пользователя не правильно.
3. Проблема с отказом EOC канала на платах SM-01, суть: EOC канал может перейти в нерабочее состояние при некоторых условиях(одновременное попадание ЕОС пакетов с разных сторон в регенератор). Подробности у Влада.
4. Конфликты с совместным доступом, это следствие из п. 1-3, если два пользователя независимо друг от друга будут проводить опрос и считывать таблицу, они могут мешать друг-другу.
   • Очищение таблицы вызванное опросами одного мешает прочитать таблицу другому.
   • При повторном опросе до завершения предыдущего, возможно проявление проблемы с EOC на SM-01. Так-же это возможно при мониторинге с двух сторон

Предлагается:

1. Плата SW-01 сама периодически отправляет команды опроса платам SM-xx и кэширует таблицы регенераторов для мониторинга и отображения в веб-интерфейсе.

2. При возникновении аварии линейного тракта производится немедленный опрос регенераторов для детализации аварии.

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

Вопросы:

• Критерии конца опроса (таймаут, кол-во регенераторов,...)
• Опрос по разным парам. Для простоты ограничиться опросом по паре А?
• Что делать с опросом с двух концов?

[alx]

Replying to san:

в момент аварии пользователи хотят получить детализированное сообщение в программе мониторинга и логах, на каком участке и на какой паре произошла авария.

Это ИМХО немного не по адресу - для исполнения этого желания плата SM-01 должна прислать плате SW-01 соответствующий TRAP. Следовательно, и реализовано это задача для платы SM-01, а не SW-01. В SW-01 все давно реализовано - при получении TRAP'а она аварию и в лог запишет, и в базу данных, и на экране отобразит...

[san]

немного не по адресу

Честно говоря, этот тикет весь не по адресу. Правильно было бы если плата SM сама опрашивала регенераторы и решала описанные выше задачи. Но она не умеет, и с почти 100% вероятностью и не будет уметь.

Если есть возможности решить эти вопросы не трогая плату SM, я бы хотел их использовать.

[alx]

Replying to san:

точного признака окончания опроса нет, есть некоторые критерии, но мы их сами ещё не можем до конца сформулировать

??? Ранее в устной беседе мы пришли к тому, что критерием окончания опроса является:

1. увидели в списке регенераторов плату SM-01 или SM-02 (она отличается от регенератора по типу, который читается из какой-то переменной);
2. таймаут, если плат SM-01/SM-02 в списке нет.

я думаю что перекладывать задачу определения конца опроса не правильно.

? Эту мысль я не понял. Перекладывать куда?

В любом случае это дополнительная сложность

Я бы не назвал это сложностью. :) Так, небольшое неудобство...

3. Неизвестна актуальность данных, считывая переменные из таблицы программа мониторинга не знает свежие это данные или опрос был год назад

Это не так. Если известно, что опрос выполняется не реже чем раз в N секунд, и известно, что опрос выполняется не более чем M секунд, то данные не могут быть старее (N + M) секунд. Разве нет?

Предлагается:

1. Плата SW-01 сама периодически отправляет команды опроса платам SM-xx и кэширует таблицы регенераторов для мониторинга и отображения в веб-интерфейсе.

ИМХО так делать нельзя в силу сложности номер 4. Ибо получится, что две платы, находящиеся на разных концах линии (а то и больше, если линии с ответвлениями), одновременно инициируют опрос. Главная сложность как раз и состоит в том, что новый опрос нельзя инициировать до тех пор, пока не закончился предыдущий. Следовательно, инициировать его можно только из одной точки (логично, если это будет тот же хост, на котором работает мониторинг).

2. При возникновении аварии линейного тракта производится немедленный опрос регенераторов для детализации аварии.

Опять-таки этого делать нельзя исходя из сложности 4. Надо дождаться окончания текущего опроса, и только тогда инициировать новый.

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

Опять-таки этого делать нельзя исходя из сложности 4.

[alx]

Replying to san:

с почти 100% вероятностью и не будет уметь.

Почему?

Если есть возможности решить эти вопросы не трогая плату SM, я бы хотел их использовать.

Вот есть у нас две платы - SM-01 и SW-01. При полном консенсусе, что аварии должна выдавать именно SM-01 ты предлагаешь вместо того чтобы реализовать в ней этот недостающий на данный момент функционал имитировать его наличие (генерируя "синтетические" TRAP'ы и имитируя их получение) другой платой? Зачем такие извращения? Не лучше ли и не проще ли сразу сделать по-уму?

[andrei]

Replying to san:

немного не по адресу

Честно говоря, этот тикет весь не по адресу. Правильно было бы если плата SM сама опрашивала регенераторы и решала описанные выше задачи. Но она не умеет, и с почти 100% вероятностью и не будет уметь.

Если есть возможности решить эти вопросы не трогая плату SM, я бы хотел их использовать.

Александр, да Вы становитесь политиком...

[alx]

Replying to andrei:

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

Данные на веб-странице и так постоянно обновляются (раз в секунду), без всякого нажатия. А вот нажимать кнопку "Опрос" в то время как опрос уже инициирован, нельзя. Можно игнорировать новые команды опроса до завершения текущего платой SW-01, но это возможно только при условии, что текущий опрос инициирован именно с той же платы SW-01, которая открыта браузером. Проблема в том, что браузером может быть открыта одна плата SW-01, а опрос инициирован совсем с другого блока, на другом конце линии. Тогда та плата, которая получит запрос пользователя, ничего не будет знать о том опросе, который уже инициирован. Как решить эту проблему, я не знаю.

[alx]

Replying to alx:

Как решить эту проблему, я не знаю.

Мне наиболее безопасным кажется такой вариант: вообще запретить "ручной" опрос регенераторов, убрать эту кнопку из веб-интерфейса. Опрос инициировать только автоматически, из одной точки сети. Если надо посмотреть состояние регенераторов - оператор подождет (N + M) секунд, о которых говорилось выше, как-нибудь не помрет он от нетерпения, я думаю... :)

[san]

критерием окончания опроса является: увидели в списке регенераторов плату SM-01 или SM-02 (она отличается от регенератора по типу, который читается из какой-то переменной);

да... но есть некоторые(редкие) случаи когда тракт заканчивается не платой SM, а устройством из прошлых линеек, и я не уверен что во всех из них есть признаки отличающие их от регенераторов, нужно уточнять

я думаю что перекладывать задачу определения конца опроса не правильно.

? Эту мысль я не понял. Перекладывать куда?

на пользователя (пропустил слово)

Если известно, что опрос выполняется не реже чем раз в N секунд, и известно, что опрос выполняется не более чем M секунд, то данные не могут быть старее (N + M) секунд. Разве нет?

Это в том случае если программа мониторинга контролирует отправку опроса. А если опрос производится "третьей стороной" то программа мониторинга может не знать о времени опроса и кроме того есть ещё вариант "команда не прошла". Ну как минимум нужно учитывать это при настройке мониторинга, что создаёт дополнительные "небольшие неудобства" :)

нельзя исходя из сложности 4. Надо дождаться окончания текущего опроса, и только тогда инициировать новый.

Если таблица будет закэширована(не будет очищаться), то конфилкт будет только в "перебивании" опроса до его завершения. Для такого случая можно ввести понятие приоритетного опроса, который может быть отправлен до окончания не приоритетного.

Как быть с ручным опросом, я пока не знаю, пока я склоняюсь к мысли оставить его без ограничений(конфликтный). Я надеюсь что с появлением НОРМАЛЬНОГО опроса, ручным будут пользоваться в очень редких случаях.

не помрет он от нетерпения

Ещё как помрёт. Представь у тебя УАЗик с бригадой ждёт, а ты ждёшь пока опросится 10-й регенератор, когда тебе нужна инфа по второму.
Нужно бывает в некоторых случаях "именно сейчас" провести опрос, я бы эту возможность не стал убирать.

[alx]

Replying to san:

да... но есть некоторые(редкие) случаи когда тракт заканчивается не платой SM,

Обрати внимание, что приведенный мной критерий состоял из двух частей - a и b. Если линия кончается платой SM-0x, то работает условие a. Если нет - работает условие b.

на пользователя (пропустил слово)

С этой мыслью согласен.

Если известно, что опрос выполняется не реже чем раз в N секунд, и известно, что опрос выполняется не более чем M секунд, то данные не могут быть старее (N + M) секунд. Разве нет?

Это в том случае если программа мониторинга контролирует отправку опроса. А если опрос производится "третьей стороной"

Какая разница, как называется программа, отправляющая команду "Опрос"? Будь это программа мониторинга, или cron - все равно ведь указание о том, куда и с какой периодичностью отправлять эту команду, дает человек (назовем его оператором). Следовательно, он знает, с каким периодом производится опрос. Случай безумного оператора мы, я думаю, рассматривать не будем. :)

то программа мониторинга может не знать о времени опроса

А зачем программе мониторинга это знать? ИМХО ей этого знать не надо. Ее дело - получать данные регенераторов.

и кроме того есть ещё вариант "команда не прошла".

Не понял... Почему не прошла? Связь с аппаратурой пропала? Но если с аппаратурой нет связи, то и система мониторинга не сможет получить параметры регенераторов! А если она их не может получить, то какая разница, опрашиваются регенераторы или нет? Появится связь с оборудованием - возобновится и опрос регенераторов, и система мониторинга возобновит получение данных...

Ну как минимум нужно учитывать это при настройке мониторинга, что создаёт дополнительные "небольшие неудобства" :)

Не понял... Как и зачем это надо учитывать, и какие такие неудобства создает учет? :)

нельзя исходя из сложности 4. Надо дождаться окончания текущего опроса, и только тогда инициировать новый.

Если таблица будет закэширована(не будет очищаться), то конфилкт будет только в "перебивании" опроса до его завершения. Для такого случая можно ввести понятие приоритетного опроса, который может быть отправлен до окончания не приоритетного.

Очень интересно... Раскрой, пожалуйста, свою мысль. Что это за приоритетный опрос, и почему его, в отличие от неприоритетного, можно выполнять, не дожидаясь завершения уже выполняющегося опроса? Может это решит все наши "опросные" проблемы?

Ещё как помрёт. Представь у тебя УАЗик с бригадой ждёт, а ты ждёшь пока опросится 10-й регенератор, когда тебе нужна инфа по второму.

Не понял, что ты имел в виду, упоминая 10-й и 2-й. Но общий смысл я понял. В свою очередь, предлагаю тебе представить ту же ситуацию, когда ты нажимаешь "Опросить" чтобы получить состояние 2-го регенератора, так как не хочешь подождать лишние 30 секунд, в результате все опросы "ломаются" из-за конфликта, и тебе с бригадой вместо того чтобы ехать домой придется ехать чинить ставший недоступным регенератор...

[alx]

Случайно убрал изменение. Возвращаю.

[san]

опросы "ломаются"

Если это про проблему с EOC в SM-01, то да.
Стоит учесть, что вероятность появления такой проблемы достаточно низкая (Влад ты где?), и "ручным опросом" создать её практически невозможно(мне неизвестны случаи отказа EOC в аппаратуре 3U). Отчасти (или даже в основном) поэтому плата SM и не имеет авто-опроса, так автор "решил" проблему c EOC

[san]

Зачем такие извращения? Не лучше ли и не проще ли сразу сделать по-уму?

Я попробую ещё раз поднять этот вопрос на "верхнем" уровне, но надежд на плату SM у меня почти не осталось :).

[alx]

Replying to san:

опросы "ломаются"

Если это про проблему с EOC в SM-01, то да.

Что такое ЕОС?

Стоит учесть, что вероятность появления такой проблемы достаточно низкая (Влад ты где?), и "ручным опросом" создать её практически невозможно

Логика подсказывает, что плата SM-0X, получив команду опроса, не знает, и не может знать, "вручную" посылка этой команды была инициирована или автоматически. Следовательно, если возможно сломать мониторинг автоматической отправкой команды, то можно сломать и вручную.

(мне неизвестны случаи отказа EOC в аппаратуре 3U).

Может они тебе неизвестны, потому что так (отправка команды опроса вручную на фоне периодических автоматических опросов) просто никто никогда не делает? Я предполагаю, что в руководстве по эксплуатации этот момент (о необходимости посылки команды для обновления данных) либо вообще не освещен, либо освещен плохо, без заострения на нем внимания. В результате в практике эксплуатации, на которую ты ссылаешься, мониторят регенераторы без их реального опроса, по незнанию видя устаревшие данные, как долгое время не знал я, что, мониторя SM-01 в "Демо доступе", получал состояние регенераторов двухмесячной давности... :) :) :)

Отчасти (или даже в основном) поэтому плата SM и не имеет авто-опроса, так автор "решил" проблему c EOC

Вот именно что "решил". :) Проблема: при мониторинге аппаратура может взорваться. Решение: записать в РЭ: "Запрещается мониторить аппаратуру!". :) :) :)

[san]

...

А зачем программе мониторинга это знать? ИМХО ей этого знать не надо. Ее дело - получать данные регенераторов.

Согласен, убираю п.3 из "сложностей".

По критериям окончания опроса: бывают ещё всякие "ведроиды"(регенераторы c выделением предыдущих линеек), переприём мониторинга через RS-232 и может ещё какие-то рудименты и что они там выдают в переменные я не знаю, нужно уточнять, возможно всё это стоит внести в "не поддерживаемое", но я пока не готов окончательно это решить.

Что такое ЕОС?

Служебный канал внутри DSL через который опрашиваются регенераторы и удаленный конец (Embedded Operations Channel кажется)

В результате в практике эксплуатации, на которую ты ссылаешься, мониторят регенераторы без их реального опроса.

Не совсем так. Практически все пользователи знают что состояние таблицы обновляется только после команды опрос, т.к. параметры DSL тракта одни из важнейших при запуске аппаратуры в работу. Но в большинстве случаев регенераторы никто НЕ МОНИТОРИТ(потому что не понятно как а если и понятно, то неудобно/сложно), но их ОПРАШИВАЮТ вручную через веб-морду по факту происшествия, или при необходимости получить данные для статистики. Так вот в результате ручного опроса пока никто не пострадал :) не смотря на то что жмут кнопку не дождавшись конца опроса

[san]

если возможно сломать мониторинг автоматической отправкой команды, то можно сломать и вручную

возможно
Я подвожу к тому что может вероятность этого события при опросе вручную настолько низкая, что можно ей пренебречь.

[alx]

Replying to san:

Что такое ЕОС?

Служебный канал внутри DSL через который опрашиваются регенераторы

Тогда да, это я про проблему с ЕОС.

Не совсем так. Практически все пользователи знают ... Но ... регенераторы никто НЕ МОНИТОРИТ

Ну так это то же самое. Это не тот случай, который мы рассматриваем, поэтому и ссылаться на практику нельзя. Мы ведь рассматриваем случай, когда опросы регенераторов все время производятся благодаря периодическим автоматически отправляемым командам "Опрос", и на фоне этого оператор дает "вручную" внеочередную команду опроса...

[san]

Вместо старого п.3. записал в сложности проблему с Eoc, раскрыл суть конфликтов в п.4.

Насчёт проблемы опроса регенераторов SM-01 с двух сторон, вижу пока такие возможные решения:

• в плате SM-01 должна быть настройка количества опрашиваемых регенераторов.

или

• инициатор опроса должен знать когда начнётся/закончится опрос с другой стороны

[alx]

Replying to san:

• в плате SM-01 должна быть настройка количества опрашиваемых регенераторов.

Не понимаю, что это даст. Допустим, настроили опрашивать два регенератора из четырех. В результате мы не будем знать состояние оставшихся неопрашиваемыми регенераторов...

• инициатор опроса должен знать когда начнётся/закончится опрос с другой стороны

Давай потеоретизируем. Постановка задачи:

1. опрос регенераторов может инициироваться разными блоками в сети.
2. новый опрос не должен инициироваться до тех пор, пока не закончился предыдущий.

Таким образом, процесс опроса регенераторов является общим (разделяемым) ресурсом с эксклюзивным доступом. Решением может быть организация некоего MUTEX'а, который необходимо захватывать для доступа к ресурсу (для проведения опроса). Это может быть либо один выделенный MUTEX, либо распределенный (набор MUTEX'ов).

Распределенный вариант - это захват MUTEX'а на каждой плате SW-01, которая потенциально может инициировать опрос. Здесь есть сразу несколько проблем:

• как узнать, сколько SW-01 имеется в (возможно, разветвленной) линии DSL, и какие у них адреса?
• разные SW-01 могут не иметь доступа друг к другу (принадлежать разным организациям, работать в разных VLAN, наконец, вообще не иметь передачи данных в канале DSL, а только телефонные каналы).
• вопросы безопасности - злонамеренный неавторизованный захват MUTEX'а хотя бы на одной плате остановит опрос всех плат в сети.

Вариант одного выделенного MUTEX'а лишен перечисленных недостатков, но вместо организации выделенного MUTEX'а можно просто организовать выделенный инициатор опросов регенераторов, а всем остальным просто запретить инициировать опрос (убрать кнопку из веб-интерфейса). Вариант централизованного опроса мне видится лучше хотя бы в силу его простоты.

[alx]

Replying to alx:

... можно просто организовать выделенный инициатор опросов регенераторов, а всем остальным просто запретить инициировать опрос (убрать кнопку из веб-интерфейса).

Добавлю дегтя. :) В теории это звучит просто. На практике же, даже убрав кнопку из веб-интерфейса, мы никогда не сможем быть уверены, что никто никогда не воспользуется старой версией ПО, где кнопка "Опрос" еще есть, и не нажмет ее... Таким образом, гарантированного решения проблемы с ЕОС, видимо, не будет никогда...

[viktam]

Может имеет смысл, на данный момент сделать хотя бы половинчатое решение для плат SM-02 и регенераторов bis.M, там вроде бы проблемы с EOC нет.
Последнее замечание мы получили от Связьинвеста по оборудованию для Дружбы. У нас последние поставки и проектируемые объекты реализуются на SM-02/

[alx]

Replying to viktam:

для плат SM-02 и регенераторов bis.M, там вроде бы проблемы с EOC нет.

Все верно, у SM-02 такой проблемы нет.

Я хотел бы уточнить свою мысль. То, что у нас, как я написал, нет гарантированного решения для SM-01, не означает, что упомянутый вариант с запретом "ручного" опроса бесполезен. Безусловно, убирание кнопки "Опрос" из веб-интерфейса, хоть и не гарантирует на 100% отсутствие "лишней" команды опроса, но очень сильно снижает вероятность ее появления. И чем больше времени пройдет с момента убирания кнопки, тем менее вероятно, что у кого-то где-то в сети сохранится блок со старой версией ПО. Так что лично я по-прежнему считаю, что это - наиболее оптимальный вариант из предложенных здесь.

[alx]

Саша, а я правильно понимаю, что если есть линия DSL с платами SM-01 на концах, и одной из SM-01 дали команду "Опросить регенераторы", то в результате опроса обновится таблица только у той SM-01, которой давали команду, а в другой SM-01 останутся старые данные? Или все-таки обе SM-01 обновят данные независимо от того, с какого конца опрос инициирован?

[viktam]

Кстати с проблемой EOC по своей практике сталкивался на старой линейке оборудования (модемы) на Белэнерго . Была постоянно запущена с 2-х сторон программа Monitor, после перехода на Супервизор - проблема не проявлялась. На новом (3U оборудовании) на практике не встречался.

[san]

Саша, а я правильно понимаю, что если есть линия DSL с платами SM-01 на концах, и одной из SM-01 дали команду "Опросить регенераторы", то в результате опроса обновится таблица только у той SM-01, которой давали команду, а в другой SM-01 останутся старые данные?

Правильно

[alx]

Replying to san:

Саша, а с чем, если не секрет, связано снижение приоритетности этой задачи?

[andrei]

Лет через 10 вообще тикет закроют с пометкой "слишком ветхий".

[san]

Да Андрей прав, 10 месяцев прошло никто из пользователей об этой проблеме не вспоминал, видимо все привыкли и не жалуются :)

[viktam]

Replying to san:

Да Андрей прав, 10 месяцев прошло никто из пользователей об этой проблеме не вспоминал, видимо все привыкли и не жалуются :)

Выскажу свое мнение, пока я вижу у своих потребителей тенденцию к централизации управления, движение идет медленно, но всё таки идёт. К счастью мы приняли решение перехода на платы SM-02, но есть старые поставки и их много.
К примеру Бел ЖД, развернут в качестве тестирования на центральном диспетчерском пункте всей ЖД, в Минске Supervisor. Сейчас прорабатывается вариант поставки трассы Минск - Барановичи - Брест, для резерва и замены К-60 (около 400км). На узловых станциях есть SDH. По мониторингу этой трассе есть: Центральная диспетчерская служба всей ЖД, Служба эксплуатации Минского отделения, Брестского отделения, Барановической дистанции + локальные узловые станции с наличием местной аварийной бригады: Береза (между Брестом и Барановичами), Столбцы (между Минском и Брестом). Получается многоступеньчатый контроль, и не известно как он будет работать, кто какие элементы будет опрашивать и что нажимать.
Так что проблему закрывать рановато.
Наибольшие проблемы у меня были на оборудование старого МС, Белэнерго, 2 круглосуточных центра управления и 1 переодический, счас они смирились, да и проблема стала проявляться реже, и по моей статистике, проблема с EOC, происходит раз в год полтора, привыкли, перезапустили модемы и все работает. Недавно был мой выезд к ним, они были в удивлении несколько раз перезапускали трассу, ethernet не восстановился. По моему приезду, я начал немного искать - в итоге подвис коммутатор, перезапустил его всё заработало. Но привычка по нашему оборудованию остается.