Check f. Cisco HyperFlex

Global Community Deutsch
1

Bevor ich das Rad hier neu erfinde…
hat jemand von Euch schon mal Cisco HyperFlex - Komponenten überwacht?

Habe hier konkret die Anfrage, bei der dann einzelne Cluster auf ihren Health - Status abgefragt werden sollen, die Hosts mit aufgeführt werden müssen (+ Disks, etc. etc.) und und…

Es gibt eine Möglichkeit, das ganze via API abzufragen.

Das würde ich dann demnächst entwickeln, wenn es bisher noch keine bereits bestehende Lösung von Euch gibt. Hat jemand eine Idee???

Besten Dank vorab für eine Rückantwort!

Sonnige Grüße aus Dortmund

Thomas

2

HyperFlex = UCS Geräte - soweit hab ich das bisher behandelt.
Hatte für ein System den bisherigen UCS Special Agent etwas erweitert und damit erstmal alles an Hardware Info bekommen was so notwendig/nützlich war.

Es ist aber bisher bei 1 od. 2 HyperFlex Systemen geblieben deshalb hab ich da auch noch nicht mehr gemacht.
Aber wie gesagt der UCS Special Agent ist ein guter Einstieg gewesen.

3

Hallo Andreas,

besten Dank für die schnelle Info.

Werde mir nächste Woche mal den UCS Special Agent anschauen.
Bei UCS haben wir bisher Eigenentwicklungen (für USC - FI z. B.)im Einsatz.
Dort bekommen wir zumindest die Faults, die auch der UCS - Manager in seiner GUI hat, angezeigt.

Wenn das mit dem UCS - Special - Agent zu aufwendig ist, dann kann / werde ich das mit API - Calls realisieren.
Mittlerweile scheint das ganz gut zu gehen.
Am letzten Freitag, haben wir mal verschiedene Abfragen gemacht.

Der Rest bleibt dann ja immer gleich, wenn die Daten im JSON - Format vorliegen.
Dann kann weiter entwickelt werden (Data - Source etc.).

Nochmals vielen Dank!

Sonnige Gruesse aus Dortmund

Thomas

4

Das gibt auch der Special Agent her :slight_smile:

Der Special Agent macht das alles per API - muss nur erweitert werden um die noch nicht vorhandenen API Aufrufe

5

Hallo Andreas, besten Dank noch einmal für die Info.

Der normale Special - Agent liefert uns hier leider nicht die Daten, die für uns notwendig sind.
Wir haben gestern noch weitere Infos bekommen.
Ist mal wieder ein Sonderfall…
Zuerst ein paar Angaben.
Bei den Hosts handelt es sich z. B. um

HX240C-M5SX
HX240C
HX220c
HXAF220c

Diese, so wurde es mir mitgeteilt, sind als “leicht modifizierte / aufgebohrte” C-Series Hosts
zu betrachten.

Hier gibt es, das die Hyperflex - Controller jeweils ESXi - Hosts laufen haben, die dann zusammen den Storage - Cluster bilden und entsprechend den Storage präsentieren, der dann von anderen ESXi - Systemen genutzt wird.

Der Cluster Status der Cluster - Storage - Systeme soll überwacht werden
Das Monitoring soll hier auf Controller - Ebene passieren.
Nicht über den UCS - Manager, nichts via vSphere - Client oder ähnlichen,
alles direkt auf den Controller bezogen.

Im Falle des “Cluster - Storages” ist es in der Vergangenheit wohl öfter vorgekommen,
das seitens UCS - Manager keine Fehler vorhanden waren, aber der / die Controller zeigten Fehler in der auf der CLI /Console an.

Um das alles jetzt zu monitoren, kann man die vorhandene Rest-API.
Dann kann man sich mit Bearer - Authentisierung etc., den Status der einzelnen Cluster abrufen.

Wir werden daher nicht drum herumkommen, das neu zu schreiben.
Wird halt nie langweilig :slight_smile:

Viele Gruesse aus Dortmund

Thomas

6

Ich mag dich zwar nicht entmutigen aber du wirst nicht drum rum kommen ebenfalls die ESX und auch die UCS APIs zu benutzen. Der Hyperflex Controller bietet laut Docu doch nur Infos zur Storage Schicht.
Der Zugriff auf die UCS Daten erfolgt doch hier genau so wie bei normalen UCS Systemen über die Fabric Interconnects da sollte auf dem Hypeflex auch was zurück kommen.

7

Hallo Andreas, kein Problem, Du entmutigst mich schon nicht.

Wir haben zum Glück bereits alle in unserem Umfeld vorhandenen ESXi - Systeme, vCenter Systeme (darunter auch die vCSA Appliance), so wie UCS - Hosts / Systeme, FI´s etc. in check_mk integriert.

Bisher kommen dabei, je nach System und Anforderungen, unterschiedlichste Kombinationen / Varianten von checks und agents zum Einsatz.

Neben SNMP - Abfragen / - Checks spielen bei uns dabei die selbstentwickelten Plugins eine große Rolle. (nicht nur bei UCS :slight_smile: )
Bei UCS hatten wir vor Jahren die Anforderung, als es zu der Zeit noch nicht wirklich etwas Vernünftiges bzgl. UCS - Checks was “Faults” angeht, gab, etwas für die UCS -Systeme bereit zu stellen bzw. zu entwickeln.
Da hat uns natürlich ein sehr guter Kollege, ein DL, bei unterstützt.

Es ist halt leider so, das nicht immer die gleichen Teams / Admins für die jeweiligen Systeme zuständig sind.
Das erleb(t)en wir immer wieder, während und auch nach der Migration sämtlicher Monitoring - Systeme zu einem “zentralen” Monitoring mit check_mk.

Daher gab es / gibt es bei uns immer wieder hier und da eine Teilung, was die Zuordnung der jeweiligen Systeme angeht.
FI´s und die restlichen UCS - Systeme sind davon auch betroffen.

Jetzt kam von einem Admin die Anforderung mit dem HX - Storage - Controller / Cluster.

Somit wird es jetzt erst vorerst einmal bei der zusätzlichen Arbeit - die Entwicklung via der RestAPI der HX - Controller - Systeme bleiben.
Es wird noch ein wenig dauern bis der check wirklich komplett, verifiziert und dann implementiert ist.
Es steht vorher noch der grosse Wechsel von 1.5 auf 1.6 an…

Es ist auf jeden Fall zunehmend in den letzten Monaten zu beobachten, das es immer mehr Anfragen gibt, was die Überwachung von Hardware - Komponenten angeht.

Grundsaetzliche soll natürlich, egal ob physikalisch oder virutell, alles Moegliche in check_mk
abgebildet werden.
Sei es (bei VMWare z. B.) die Überwachung von z. B. Cluster - Config - Status diverser Systeme aus vSphere Sicht, oder auch andere Appliances, CIMC - Boards via IPMI mit den ulkigsten Logikkonstrukten…etc. etc… :slight_smile:
Wird immer mehr :slight_smile:

Viele Gruesse aus Dortmund

Thomas

8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.