Ubiquiti, MikroTik და Cambium ერთ მონიტორინგში — მცირე და საშუალო ოპერატორისთვის

მცირე და საშუალო ოპერატორის ქსელი თითქმის არასდროსაა ერთვენდორიანი. ბირთვსა და საზღვარზე ჩვეულებრივ MikroTik დგას, ქალაქთაშორის და „ბოლო მილის“ უსადენო ხაზებზე — Ubiquiti, წვდომის დონეზე კი სულ უფრო ხშირად Cambium. თითოეულს თავისი მართვის სისტემა მოჰყვება: UISP, MikroTik-ის საკუთარი რუკა და WinBox, cnMaestro.

პრობლემა ის კი არაა, რომ ეს სისტემები ცუდია — პირიქით, თითოეული საკუთარ აპარატურაზე საუკეთესოა. პრობლემა ისაა, რომ ინციდენტი ვენდორის საზღვრებს არ სცნობს. აბონენტი წერს „ინტერნეტი არ მუშაობს“, დისპეტჩერს კი სამი ცალკე კონსოლი აქვს, სამი ცალკე პაროლით, და არსად ერთი ეკრანი, სადაც ჩანს — პრობლემა ბირთვშია, უსადენო გადასასვლელზე თუ აბონენტის მოწყობილობაზე.

რას აკეთებს კარგად თითოეული ვენდორის კონსოლი#

UISP (Ubiquiti). airMAX/airFiber ხაზებისა და UISP-სერიის მოწყობილობებისთვის ეს არის provisioning-ის, ფირმვეარის და კონფიგურაციის ბუნებრივი ადგილი. აჩვენებს signal/CCQ/airtime-ს იმ დეტალურობით, რომელსაც SNMP-ით ვერ მიიღებთ, და უსადენო ხაზის დაგეგმვას თავისი ინსტრუმენტებით აკეთებს.

გადიდება

MikroTik — რუკა და RouterOS. MikroTik-ის საკუთარი რუკის ინსტრუმენტი სწრაფად აწყობს ქსელის სქემას, კითხულობს SNMP-ს სხვა ვენდორებისგანაც და უფასოა. RouterOS თავად აწვდის ყველაფერს, რაც სჭირდება — ინტერფეისების სტატისტიკა, PPPoE სესიები, queue-ები, firewall counter-ები.

cnMaestro (Cambium). ePMP/PMP და cnPilot-ისთვის — რადიო პარამეტრები, სექტორის დატვირთვა, აბონენტის მოწყობილობის მდგომარეობა, ფირმვეარის ჯგუფური განახლება. Cambium-ის აპარატურაზე ალტერნატივა პრაქტიკულად არ არსებობს.

გადიდება

სად ჩერდება თითოეული#

ყველა ეს სისტემა ვენდორის საკუთარი პარკის მართვისთვისაა აშენებული და არა ქსელის ოპერირებისთვის. აქედან გამომდინარეობს სამი კონკრეტული ხარვეზი:

• ისტორია მოკლეა. ვენდორის კონტროლერი გუშინდელ ინციდენტს გაჩვენებთ, სამი თვის წინანდელ ტენდენციას — იშვიათად. capacity-ის დაგეგმვა კი სწორედ ტენდენციაზე დგას.
• კორელაცია არ არსებობს. უსადენო ხაზზე CCQ დაეცა და იმავე წუთს ბირთვში ინტერფეისი გაჯერდა — ეს ერთი ინციდენტია, მაგრამ ორ სხვადასხვა კონსოლში ორ სხვადასხვა ფაქტად ჩანს.
• alert-ები ვერ იმართება. სამი სისტემა სამ არხში წერს, severity-ს თითოეული თავისებურად განსაზღვრავს, ესკალაციის ერთიანი წესი კი არსად არის.

მიდგომა: კონტროლერები რჩება, ზემოთ ერთი ფენა ჩნდება#

ჩვენ ვენდორის კონსოლებს ვტოვებთ იქ, სადაც ისინი შეუცვლელია, და მათ ზემოთ ვდებთ ერთ ვენდორ-ნეიტრალურ ფენას, რომელსაც სამი ამოცანა აქვს: მდგომარეობა, ისტორია და alert-ები.

გასაღები SNMP-ია: სამივე ვენდორი მას მხარს უჭერს. MikroTik-ს სრული MIB აქვს, Ubiquiti-ს — ინტერფეისებისა და უსადენო სტატისტიკის, Cambium-ს — რადიოსი და აბონენტების. სადაც SNMP ვერ სწვდება (მაგალითად cnMaestro-ს აგრეგირებული მაჩვენებლები), ვიყენებთ მათ API-ს.

რას ვზომავთ უსადენო წვდომის ქსელში#

ზოგადი „up/down“ უსადენო ქსელში თითქმის უსარგებლოა — ხაზი „ცოცხალია“ და მაინც არ მუშაობს. სამუშაო მინიმუმი ქვემოთაა, და თითოეული ეს მაჩვენებელი პირდაპირ რუკაზე, კვანძის გვერდით აისახება — ინჟინერს ცალკე დაშბორდის გახსნა არ სჭირდება:

ამას ემატება ის, რაც კონკრეტულ ხაზზე კი არა, კვანძზე იზომება:

• PPPoE/DHCP სესიების რაოდენობა — მკვეთრი ვარდნა უფრო სწრაფად ამბობს „კვანძი წავიდა“, ვიდრე ping-ის ტაიმაუტი.
• ოპტიკური დონეები (GPON/EPON და ტრანკები) — დაცემა თანდათანობითია და დროზე ჩანს, თუ ისტორია გაქვთ.
• ტემპერატურა და კვების ხაზი — აკუმულატორის ძაბვასთან ერთად ეს ხსნის ღამის ჩავარდნების იმ ნაწილს, რომელიც სხვაგვარად „აუხსნელია“.
• Uplink-ის გაჯერება — ხშირად „ქსელი ნელია“ სწორედ ეს არის და არა რადიო.

გადიდება

alert, რომელსაც აზრი აქვს#

მრავალვენდორულ ქსელში alert-ების ხმაური ორმაგდება: ერთი ავარია სამ სისტემაში სამ შეტყობინებას ბადებს. ამიტომ alert-ის წესი ჩვენთან ყოველთვის სამ კითხვაზე პასუხობს:

1. ვის ეხება — ერთი აბონენტი, სექტორი, თუ კვანძი? severity აქედან გამომდინარეობს და არა მოწყობილობის ტიპიდან.
2. რა უნდა გაკეთდეს — თუ შეტყობინებას runbook არ მოჰყვება, ის შეტყობინება არაა, ხმაურია.
3. ვის ეშვება — ესკალაციის მატრიცა severity-ის მიხედვით, და არა „ყველას ერთ ჯგუფში“.

დამატებით: მშობელი კვანძის ჩავარდნისას შვილების alert-ები ჩახშობილი უნდა იყოს. ტოპოლოგიის რუკა სწორედ ამისთვის არ არის დეკორაცია — ის კავშირების იერარქიას აძლევს alert-ების ძრავას.

საიდან დავიწყოთ#

პრაქტიკაში ეს ოთხი ნაბიჯია და არცერთი მათგანი არ საჭიროებს არსებული სისტემების გამორთვას:

1. ინვენტარი და აღმოჩენა — ყველა მოწყობილობა ერთ სისტემაში, SNMP-ით. აქვე ირკვევა, რამდენი მოწყობილობა არსად არ იყო აღრიცხული.
2. ტოპოლოგია და დამოკიდებულებები — რომელი კვანძი რომელზეა დამოკიდებული. ეს ერთადერთი გზაა alert-ების ხმაურის შესამცირებლად.
3. ისტორია და დაშბორდები — ჯერ uplink-ები და ბირთვი, შემდეგ სექტორები, ბოლოს აბონენტის დონე.
4. alert-ები და ესკალაცია — severity, dedup, runbook-ები, ერთი არხი.

ამის შემდეგ ვენდორის კონსოლები რჩება იქ, სადაც მათ ადგილი აქვთ — ინჟინერი მათ იმისთვის ხსნის, რომ გამოსწორება განახორციელოს, და არა იმისთვის, რომ გაიგოს, საერთოდ რა მოხდა.