NetXMS Support Forum

Приветствую!

Прошу помочь разобраться с мониторингом кластеров.
Сколько не пытался понять как именно и в каком порядке создаётся DCI для кластера, так и не понял...

Можно для нубов, по шагам...? На абстрактном примере, кластер с двумя нодами.



Плиз.

DCI создаются на объекте кластера. Фактически объект кластера работает как шаблон для своих узлов, т.е. как только закрываем DCI editor, сразу обновляется конфигурация узлов. Единственное дополнение - можно связать DCI с ресурсом, тогда этот DCI будет собираться только с той ноды, где сейчас активен этот ресурс.
Активность ресурса определяется по IP адресу, узел на котором находится IP счмтается текущим владельчем ресурса.

ох. мне бы примерчик... =)
если не сильно затруднительно.

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



оффтоп: кстати странно... не вижу что бы народ активно делился опытом. обычно народ участвует в дискуссиях, а тут... тишина. не понимаю.

Ok, poprobuju primerchik. Itak, u nas est' Microsoft Cluster iz dvuh uzlov: NODE_A i NODE_B. Na kazdom uzle stoit NetXMS agent. Sam klaster nazivaetsja CLUSTER. Obe nodi vkljucheni v obschuju set' 192.168.1.0/24, u nodi A adres 192.168.1.11, u nodi B - 192.168.1.12. Krome togo, mezdu nodami est' otdel'nij sync interfeis s setkoj 10.0.0.0/8, noda A imeet adres 10.0.0.1, noda B - 10.0.0.2. Eta setka potencial'no perekrivaetsja s drugimi setjami i v principe iz ostal'nogo mira nedostupna. Est' 3 resursnie gruppi:
1. Cluster group, imja: ClusterGroup, virtual'nij IP 192.168.1.10
2. Shared disk, imja: SharedDisk, virtual'nij IP 192.168.1.20. Na aktivnoj node viden kak disk X:
3. Exchange server, imja: Exchange, virtual'nij IP 192.168.1.30. Na aktivnoj node rabotajut Exchange servisi + viden disk E:

Zadacha: monitorit' dostupnost' resursov, mesto na diske.

Chto delaem:

1. Sozdaem ob'ekt tipa "Cluster", nazivaem ego CLUSTER.
2. V properties CLUSTER dobavljaem Cluster Interconnect Network 10.0.0.0/8
3. Tam-ze na zakladke Resources opredeljaem resursi (pari imja - IP adres):
    ClusterGroup 192.168.1.10
    SharedDisk 192.168.1.20
    Exchange 192.168.1.30
4. Teper' mozno sozdavat' nodi NODE_A i NODE_B. Sozdaem ih pod ob'ektom CLUSTER. V kachestve Ip adresov ukazivaem 192.168.1.11 i 192.168.1.12 (t.e. ih fiksirovannie adresa).
5. Esli posmotrim ih konfiguraciju, to virtual'nih adresov v spiske interfeisov bit' ne dolzno. Esli vibrat' ob'ekt CLUSTER v Object Browser, to v zakladke Cluster dolzni videt' pravil'noe polozenie resursov po nodam.
6. teper' mozem opredeljat' parametri. Vibiraem "Data Collection" u ob'ekta CLUSTER, i dobavljaem DCI dlja monitoringa clusternih resursov. Poskol'ku sobirat' informaciju skazem po svobodnomu mestu na diske X: s nodi gde etogo resursa sejchas net bessmislenno, to pri nastrojke DCI ukazivaem k kakomu resursu on otnositsja v pole "Associate with cluster resource". Dannie budut sobiratsja tol'ko s togo uzla, gde v dannij moment aktiven ukazannij resurs.
7. V ostal'nom nodi konfigurjatsja kak obichno.

S klasterami svjazani takze neskol'ko sistemnih sobitij:

SYS_CLUSTER_DOWN
SYS_CLUSTER_UP
SYS_CLUSTER_RESOURCE_DOWN
SYS_CLUSTER_RESOURCE_UP
SYS_CLUSTER_RESOURCE_MOVED

Pri neobhodimosti mozno ih obrabativat'.

Vot vrode i vse.

Best regards,
Victor

Спасибо большое, Виктор, за понимание и помощь!
Как только закончу решение проблемы мониторинга температур серверов, сразу займусь кластером.

(кстати поздравляю нас всех с победой нашей сборной!)

Тестирование кластерного монитора произведено...
Работает и работает хорошо, я бы даж сказал отлично! =)

Правда по мере тестирования возникли следующие вопросы:

1. Почему уже созданные ноды нельзя переносить под объект кластера? Ведь для этого нужно только Parent-объект сменить у ноды.. Так? =)
2. Если мы правильно поняли, то DCI, занимающийся мониторингом кластера, встроен в движок NetXMS (поскольку в списке субагентов нет ничего, даже отдалённо похожего на мониторинг кластеров).

Почему возник вопрос? Дело в том, что в случае, если какая-то из нод не доступна, а потом снова поднимается, то сначала генерится Warning, а потом нода автоматом переводится в состояние Normal. Это понятно. А вот с переездом ресурсов с ноды на ноду- вот тут странно. Если Event типа Resource_Moved имеет состояние Warning (это- по умолчанию), то нет никакой возможности вернуть статус ноды в Normal (TimeOut не помогает, поскольку он очевидно действительно additional, и не оверрайдит текущий статус ноды... И получается что нода постоянно висит в состоянии Outstanding (если использовать дефолтный Event "Resource_Moved"). И вернуть статус кластера в Normal можно только вручную.

Ну да не суть. Из положения мы вышли, отказавшись от генерации аларма при перемещении ресурсов кластера с ноды на ноду. Оставили только mailto в Actions. Т.е. событие перемещения регистрируется со статусом Warning, но при этом нода не помечается как сбойная (и не требуется прерывание текущей обработки).

И к началу темы: поскольку опрос (DCI) встроен в движок NetXMS, мы не можем процессить ответы Агента с кластера.  А значит не можем запустив процесс Alram'ом потом его остановить... Не знаю, удобно ли это.... Ну, в общем, это под вопросом.

3. По поводу глубины и точности мониторинга. Возник такой вопрос: мы сейчас можем мониторить только ресурсы типа Групп. А как быть с ресурсами, входящими в группы? Предположим, что их там не один и не два. И некоторые из них могут отваливаться... И получается, что сейчас невозможно отследить состояние упавших ресурсов. Только состояние Групп... Можно это как-то доработать? Чтобы мониторинг был более аккуратен? Пожааалуйста. =)

4. DCI на уровне объекта кластера создать можно, но вроде как они не работают. По крайней мере, точно не работает определение свободного места на диске C. Я понимаю, почему оно не работает, но тогда зачем оставлена такая возможность (добавлять DCI'и)?

По логике вещей, или нужно оставить возможность добавлять только КЛАСТЕРНЫЕ DCI, или совсем отключить возможность добавления DCI на уровне объекта кластера... Где-то так...

* * * * *

К кластеру отношения не имеет, но что бы не плодить темы: можно ли убрать из Win GUI сворачивание всех узлов при нажатии на F5 (Refresh)? Довольно неудобно... =) Пусть они не сворачиваются. Можно так сделать?

Попробую ответить по порядку:

1. Там внутри получались кое-какие сложности, поэтому поленился делать Надо будет не ленится и сделать. В 0.2.22 не обещаю, но потом точно сделаю (особенно если записать в feature requests).

2. Мониторинг кластеров на данный момент сделан очень примитивно - это по сути мониторинг виртуальных адресов. Т.е. в рамках Status poll сервер проверяет, доступны ли IP адреса кластерных ресурсов и на какой ноде они находятся. Ну и в случае изменения ситуации генерирует соответствующее событие.

Что касается resource moved - можно на аларм, создаваемый по этому событию, ставить timeout - а по событию SYS_ALARM_TIMEOUT делать ему terminate.

Не понял насчет запустить/остановить процесс. Что имелось ввиду?

3. Отдельные ресурсы можно мониторить через соответствующие параметры агента, как обычно - сервисы через System.ServiceState, процессы через Process.Count, и т.д.

4. Должны работать. Если не работают, то это баг. Фактически настройка DCI на объекте кластера - это тоже самое что настройка DCI в шаблоне, жестко ппривязанном к узлам кластера. Можно прислать точную последовательность действий, что делалось и что не работает?

Виктор, спасибо за помощь!

А по порядку - это правильно, так проще =)

1. Записал в feature requests (https://www.netxms.org/forum/index.php/topic,414.0.html).

2. А усилять и расширять мониторинг кластеров не планируется? Кстати большое Вам спасибо за то, что уже реализовано!

А можно поподробнее о SYS_ALARM_TIMEOUT? я уже отписал в теме по монитрингу HTTP, что получаю чрезвычайно странный результат при использовании данного параметра а также параметра Timeout. Может быть я их просто неправильно использую? Подскажите... =)

Запустить/остановить процесс - имелось ввиду Event Processing (запуск процессинга эвента и остановка процессинга эвента).

3. Т.е. если я правильно понял, то ресурсы, которые входят в кластерную группу, можно мониторить ровно точно так же, как и обычные ресурсы, находящиеся на одиночной ноде? Но в таком случае на каком уровне нужно создавать DCI'и? На уровне кластера? Или на уровне каждой из нод? Прошу подсказать =).

4. Не работает, однозначно =).

По крайней мере с опросом дисков.

Если вопрос о последовательности создания кластера, то всё делалось по Вашему описанию, точь-в-точь. Если имеется ввиду создание DCI на уровне Кластера, то тут всё было сделано абсолютно точно также, как для обычной ноды.

Создал DCI типа Disk.FreePerc. Пробовал и для диска C: (есть на обеих нодах, понятное дело) и для диска S: (есть только на одной из нод). Обе ноды кластера- активные.

После создания (интервал опроса- 60 секунд) DCI ничего не получает. При попытке посмотреть данные через Data Collection -> Show Data получаю ошибку: Unable to retrievecollected data: Database failure.

И в таблице Collected Data в поле Value получаю единственную запись: ERROR LOADING DATA FROM SERVER.

Прошу помочь советом.

UP

Нужна подсказка... 

прошу прощения за настойчивость, но предыдущий вопрос всё ещё актуален.

UP.

Proshu proshenija za bol'shie zaderzki s otvetami, bil ochen' bol'shoj zaval na rabote. Sejchas postarajus' v techenii dnja otvetit' na vse voprosi na forume.

Quote from: Anth0ny on July 09, 2008, 05:45:54 PM
2. А усилять и расширять мониторинг кластеров не планируется? Кстати большое Вам спасибо за то, что уже реализовано!

Eto bilo-bi interesno, no ja poka ploho predstavljaju chto i kak tam mozno bilo bi uluchshit'. Mozno sdelat' otdel'noe obsuzdenie v feature request i pridti k novoj sheme monitoringa klasterov. Togda mozno budet ee i realizovat'.

Quote from: Anth0ny on July 09, 2008, 05:45:54 PM
А можно поподробнее о SYS_ALARM_TIMEOUT? я уже отписал в теме по монитрингу HTTP, что получаю чрезвычайно странный результат при использовании данного параметра а также параметра Timeout. Может быть я их просто неправильно использую? Подскажите... =)

Ja segodnja/zavtra proverju etot funkcional, pohoze tam kakie-to strashnie bagi...

Quote from: Anth0ny on July 09, 2008, 05:45:54 PM
Запустить/остановить процесс - имелось ввиду Event Processing (запуск процессинга эвента и остановка процессинга эвента).

Zdes' kakoe-to nesovpadenie terminov pohoze Nel'zja zapustit'/ostanovit' obrabotku sobitija - ona vsegda proishodit (t.e. kazdoe sobitie obrabativaetsja). Mozno po sobitiju zapuskat' vneshnie processi - cherez Actions, sozdavat' u ubirat' alarmi, menjat' sostojanija situacij.

Quote from: Anth0ny on July 09, 2008, 05:45:54 PM
3. Т.е. если я правильно понял, то ресурсы, которые входят в кластерную группу, можно мониторить ровно точно так же, как и обычные ресурсы, находящиеся на одиночной ноде? Но в таком случае на каком уровне нужно создавать DCI'и? На уровне кластера? Или на уровне каждой из нод? Прошу подсказать =).

DCI nado sozdavat' na urovne klastera, ukazivaja dlja kazdogo DCI k kakomu resursu on otnositsja. (Esli etogo ne delat', to skazem DCI na status servisa Exchange'a na neaktivnoj node vizovet srabativanie thresholda na to, chto servis ostanovlen, pojavlenie alarma, etc., hotja eto normal'naja situacija). Privjazka DCI k resursu vizivaet sbor dannih tol'ko s toj nodi, gde sejchas nahoditsja resurs.

Quote from: Anth0ny on July 09, 2008, 05:45:54 PM
4. Не работает, однозначно =).

По крайней мере с опросом дисков.

Если вопрос о последовательности создания кластера, то всё делалось по Вашему описанию, точь-в-точь. Если имеется ввиду создание DCI на уровне Кластера, то тут всё было сделано абсолютно точно также, как для обычной ноды.

Создал DCI типа Disk.FreePerc. Пробовал и для диска C: (есть на обеих нодах, понятное дело) и для диска S: (есть только на одной из нод). Обе ноды кластера- активные.

После создания (интервал опроса- 60 секунд) DCI ничего не получает. При попытке посмотреть данные через Data Collection -> Show Data получаю ошибку: Unable to retrievecollected data: Database failure.

И в таблице Collected Data в поле Value получаю единственную запись: ERROR LOADING DATA FROM SERVER.

Dannie smotreli na node ja nadejus'? Poskol'ku na ob'ekte klastera dannih net - eto virtual'nij ob'ekt, tak-ze kak i template. Real'nie dannie sobirajutsja dlja uzlov - ob'ekt klastera s tochki zrenija nastrojki DCI rabotaet kak template + dopolnitel'nie pravila kogda sobirat' dannie a kogda net.

Best regards,
Victor

Quote from: Victor Kirhenshtein
Proshu proshenija za bol'shie zaderzki s otvetami, bil ochen' bol'shoj zaval na rabote. Sejchas postarajus' v techenii dnja otvetit' na vse voprosi na forume.

Спасибо Вам Виктор за Вашу работу! =)
Очень жду помощь... Проблема в том, что далеко не все подробности настройки и работы NetXMS освещены в Документации. И поэтому приходится изводить Вас вопросами.. =(

Quote from: Victor Kirhenshtein
Eto bilo-bi interesno, no ja poka ploho predstavljaju chto i kak tam mozno bilo bi uluchshit'. Mozno sdelat' otdel'noe obsuzdenie v feature request i pridti k novoj sheme monitoringa klasterov. Togda mozno budet ee i realizovat'.

Оки! Я сам- не великий специалист по кластерам. Вот мой начальник- другое дело. Я попросил его накидать (эскизно) предложение по улучшению мониторинга кластеров, я потом напишу в Предложения. Кстати, прошу заметить, что только в Вашем мониторинге реализован прямой метод контроля кластеров (я перебрал много разных перед тем, как остановился на NetXMS. Т.е. NetXMS - в своём роде уникальный продукт. Вот ежели бы ещё добавить парсинг логов, так и вообще ничего другого не нужно будет (тот же самый Nagios всё равно использует отдельный внешний модуль для контроля логов, встроенного у него нет).

Quote from: Victor Kirhenshtein
Ja segodnja/zavtra proverju etot funkcional, pohoze tam kakie-to strashnie bagi...

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

Вот ещё бы именно этот пункт улучшить и добавить в него подсчёт кол-ва полученных негативных Событий и запускать дополнительное Событие не по таймауту, а по этому заданному количеству... Я уже оформлял нечто подобное в Предложениях, https://www.netxms.org/forum/index.php/topic,404.0.html, пункт 1.

Но дальнейший анализ показал что создавать свойство "Duration" (или можно ещё наверное сказать "Counting events") лучше всего именно в связке с Timeout'ом. Как мне кажется- вполне логично. Т.е. нужен выбор (radio button) или одного, или другого параметра. Или же вообще отказаться от параметра Timeout и заменить его на Counting events... Почему? Мы же уже имеем возможность контролировать параметр Времени при помощи указания интервала опроса для каждой DCI? А значит второй контроль по времени но уже со стороны Timeout'а мне кажется немного эээ... нелогичным... Поскольку События продолжают собираться по мере запуска DCI с указанным ему интервалом, в этом разделе (Timeout) лучше наверное было бы подсчитывать количество полученных Событий. А время их получения (интервал) нами уже задан в DCI.

Очень надеюсь что пишу терминологически правильно и понятно... Стараюсь.

Quote from: Victor Kirhenshtein
Zdes' kakoe-to nesovpadenie terminov pohoze Nel'zja zapustit'/ostanovit' obrabotku sobitija - ona vsegda proishodit (t.e. kazdoe sobitie obrabativaetsja). Mozno po sobitiju zapuskat' vneshnie processi - cherez Actions, sozdavat' u ubirat' alarmi, menjat' sostojanija situacij.

Виктор, попробую объяснить, почему я использую данные термины именно так...

Если смотреть на просто Событие, то оно - вещь статическая и по сути никакой динамикой не обладает. Динамичным его делает Threshold, который помечает DCI указанным ему Событием при наступлении указанных в Threshold'е условии.

Далее: когда DCI помечается Threshold'ом указанным ему Событием, происходит Обработка События в Event Processing Policy.

Именно поэтому я использую оборот "Запуск События на обработку".

Если Вам интересно, могу выложить свой вариант Документации по NetXMS. Он ориентирован не на Администратора системы, а на Оператора. И потому там есть детальное (по возможности, информация к сожалению есть не на всё, часть пришлось додумать самому) описание Интерфейса и элементной базы NetXMS но отсутствуют некоторые пункты официальной Документации. Плюс - поступенчатое руководство по созданию объектов и мониторингу. Сейчас я заканчиваю документ, он почти отформатирован, там строк примерно 500...

Quote from: Victor Kirhenshtein
DCI nado sozdavat' na urovne klastera, ukazivaja dlja kazdogo DCI k kakomu resursu on otnositsja. (Esli etogo ne delat', to skazem DCI na status servisa Exchange'a na neaktivnoj node vizovet srabativanie thresholda na to, chto servis ostanovlen, pojavlenie alarma, etc., hotja eto normal'naja situacija). Privjazka DCI k resursu vizivaet sbor dannih tol'ko s toj nodi, gde sejchas nahoditsja resurs.

Quote from: Victor Kirhenshtein
Dannie smotreli na node ja nadejus'? Poskol'ku na ob'ekte klastera dannih net - eto virtual'nij ob'ekt, tak-ze kak i template. Real'nie dannie sobirajutsja dlja uzlov - ob'ekt klastera s tochki zrenija nastrojki DCI rabotaet kak template + dopolnitel'nie pravila kogda sobirat' dannie a kogda net.

Понял, проверил. Действительно всё так, Вы правы. Правда есть некоторые странности: при создании на уровне Кластера DCI для мониторинга диска С:, этот DCI почему-то обслуживает не обе ноды, а только одну. Не пойму почему. На второй ноду ошибки не выдаёт, но и данные не собирает...

В заключение хочу отметить, что я пристаю к Вам с расспросами далеко не из праздного любопытства: на начало августа у нас запланировано промышленное внедрение NetXMS. Вот я и как главный по мониторингу и готовлюсь.... =)

Quote from: Anth0ny on July 17, 2008, 10:57:28 AM
Понял, проверил. Действительно всё так, Вы правы. Правда есть некоторые странности: при создании на уровне Кластера DCI для мониторинга диска С:, этот DCI почему-то обслуживает не обе ноды, а только одну. Не пойму почему. На второй ноду ошибки не выдаёт, но и данные не собирает...

А Вы случайно не привязали DCI для диска C: к какому-нибудь ресурсу?

Quote from: Anth0ny on July 17, 2008, 10:57:28 AM

Quote from: Victor Kirhenshtein
Zdes' kakoe-to nesovpadenie terminov pohoze Nel'zja zapustit'/ostanovit' obrabotku sobitija - ona vsegda proishodit (t.e. kazdoe sobitie obrabativaetsja). Mozno po sobitiju zapuskat' vneshnie processi - cherez Actions, sozdavat' u ubirat' alarmi, menjat' sostojanija situacij.

Виктор, попробую объяснить, почему я использую данные термины именно так...

Если смотреть на просто Событие, то оно - вещь статическая и по сути никакой динамикой не обладает. Динамичным его делает Threshold, который помечает DCI указанным ему Событием при наступлении указанных в Threshold'е условии.

Далее: когда DCI помечается Threshold'ом указанным ему Событием, происходит Обработка События в Event Processing Policy.

Именно поэтому я использую оборот "Запуск События на обработку".
главный по мониторингу и готовлюсь.... =)

Вообще-то идея немного другая: событие - это как раз динамический объект (и с очень коротким временем жизни) - событие возникает, проходит через event policy, вызывая тем самым какие-то действия, записывается в лог - и исчезает. Не надо путать события с шаблонами событий (то что мы видим в Control Panel -> Events) - те действительно статические объекты.

Пороговые значения (thresholds) у DCI - это лишь один источник событий. События также генерируются при опросе статуса узлов (SYS_NODE_DOWN например), как результат обработки SNMP трапов, просто могут присылаться из внешних систем (например через nxevent).

Хмм.. вроде нет.

Сейчас пересоздал DCI и всё заработало. Чудеса....

Создавал на контейнере Кластера новый DCI (как и в прошлый раз так):

Описание: Кластер - Свободное место на Диске С: (в %)
Параметр: Disk.FreePerc(C:)

Интервал: 600 секунд

Только теперь оно заработало... Чудеса...

По поводу Событий и Терминологии: да, всё так. Очевидно у меня произошла логическая подмена понятия События и Шаблона События... =) Хотя мне почему-то кажется что мы объясняем одно и тоже только с разных точек зрения и суть от этого не меняется. Да, вопрос терминологии... =))

Просто получается так, что часть DCI с Threshold'ами зашита в движок (как например в случае с кластером), и События для этого случая уже заранее предопределены. И другие не задействовать. А часть (бОльшая) Событий создаётся Оператором вручную и без DCI и сопутствующего ему Threshold'а - смысла не имеет, просто запись в Базе.

Я именно от этого и отталкивался.