This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

Orion Skalierung

Ich frage mich manchmal ob es einen Zusammenhang zwischen dem Wachstum einer Firma und dem Wachstum des IT Teams gibt. Vermutlich nicht so wirklich!

Es ist leicht zu messen, wenn der Helpdesk überfordert ist und wenn der CEO einmal zu lange auf ein Ticket warten muss ist das vielleicht ein Argument um das Staffing zu erhöhen.

Nagut, wenn der CEO zu lange warten muss wird das Staffing vielleicht zuerst um einen Kopf kürzer… emoticons_happy.png

Aber im DC oder Infrastruktur-Management? Eine Handvoll mehr Switches, ein neuer Host - das kann doch alles problemlos von denen verwaltet werden die das bisher auch schon gemacht haben. Aber sicher doch!
In einer perfekten Welt ganz bestimmt, aber in einer perfekten Welt würden Dolce & Gabbana die Frühjahrskollektion kostenfrei direkt zu mir ins Haus liefern.

Im Idealfall sollte das IT Team natürlich mitwachsen um mit den erhöhten Ansprüchen umgehen zu können.

Das gleiche gilt natürlich auch für ein Solarwinds Deployment.

Die meisten von euch setzen Orion in einem ganz normalen Szenario ein – wir nennen es “central deployment”.

Die Orion VM kommt irgendwo in ein DC, oder auch ganz einfach den Serverraum und alles was von dort aus erreicht werden kann wird direkt abgefragt.
Das ist simpel und in der Infrastruktur muss nur sichergestellt werden, dass die Kommunikationsmethoden des/der entsprechenden Module zu den jeweiligen Elementen gegeben sind, als Beispiel also UDP 161 für SNMP, vielleicht UDP 2055 für Netflow.
Die darunterliegende Infrastruktur ist für uns transparent und uninteressant, solange eine Verbindung vorhanden ist.

Wie in meinem Posting zur Lizensierung erklärt, kann man das beim NPM bis zu etwa 10000 Interfaces einfach so gestalten. Darüber hinaus muss dann ausskaliert werden.

Der erste Schritt ist hier ein zusätzliches Abfragemodul einzusetzen.

Ich werfe in diesem Posting mit verschiedenen Begriffen um mich, lasst mich das zuerst einmal erklären inklusive der Abkürzungen die es bei uns gibt:

Zusätzlicher Poller --> Additional Polling Engine --> APE
Zusätzlicher Webserver
--> Additional Webserver --> AWS
Übergeordnete Zentralkonsole
--> Enterprise Operating Console --> EOC
Orion Server
--> Anwendungsserver, aber auch primärer Poller (sobald APE involviert sind)
Hochverfügbarkeit
--> High Availability --> HA

Zuerst etwas Theorie – zusammen gefasst:
Ein Poller erweitert die Kapazitäten sämtlicher vorhandener Orion Module um die gleiche Menge wie die „unlimitierten“ Versionen, also pro Poller z.B. weitere 10000 Interfaces beim NPM.
Der Installationsprozess erstellt im Prinzip eine Kopie des Orion Servers, daher sollten auch die Resources identisch sein.
Es wird die gleiche Datenbank genutzt! Das ist wichtig beim Planen des Standortes.

Üblicherweise setze ich mir einen Poller in ein entferntes DC und lasse alles, was dort steht, lokal abfragen. Der Poller sendet die Statistiken direkt in die DB.
Wenn die Verbindung einmal abbricht werden die Daten für eine Weile zwischengespeichert und beim Wiederherstellen der Verbindung in die DB abgesetzt.
Im Moment wird dazu noch MSMQ genutzt welches allerdings mittelfristig durch RabbitMQ abgelöst werden wird.

Die komplette Theorie inklusive der Kommunikationsports hier:
https://support.solarwinds.com/Success_Center/Network_Performance_Monitor_(NPM)/NPM_Documentation/Scalability_Engine_Guidelines_for_SolarWinds_Orion_Products?CMPSource=THW&CMP=DIRECT

Achtung: Oftmals wird hier nur auf die Ports geachtet. Bitte ignoriert die maximale Latenz nicht – die sollte unter 200 ms liegen.

Alles klar, jetzt kommt die Praxis!

Der Prozess ist seit etwa einem Jahr denkbar einfach.
Zuerst wird eine VM aufgesetzt die im Idealfall, wie oben schon angemerkt, die gleichen Ressourcen hat wie das primäre Orion System.

Von der VM aus gehe ich mittels Browser auf meinen Orion Server und zu Settings --> All Settings --> Polling Engines und dort klicke ich auf diese freundliche Schaltfläche

01.png

Das Ding führe ich aus und sehe:

02.png

Dann werde ich gefragt was ich denn eigentlich vorhabe, ausnahmsweise weiss ich das auch und entscheide mich zuerst für die APE:

03.png

Oh hier kommt eine Zwischenfrage:

04.png

Hier sei kurz gesagt, dass APEs sowohl beim SRM als auch beim VMAN kostenlos sind, für die anderen Module aber nicht!
Bei mir spielt Geld aber keine Rolle! Nur bei Dolce & Gabbana emoticons_happy.png

Der Installer zieht sich die korrekten Dateien nun vom Orion Server und testet:

05.png

Bei mir passt alles:

06.png

Und dann startet die tatsächliche Installation die aussieht wie die eines einzelnen Orion Moduls daher spare ich uns die Zeit und Screenshots.

Das habe ich mir so gedacht! Windows ist anderer Meinung:

07.png

Ich schiebe die Schuld einfach auf Windows und starte den Vorgang noch einmal. Windows kann sich schließlich auch nicht wehren.

Dieses Mal: Prima!

08.png

Was jetzt folgt kennt ihr auch:

09.png

Alles bleibt bei den defaults – next next next und irgendwann:

10.png

Dann öffnet sich ein Browser mit meiner Orion URL – was jetzt?

Zuerst gehe ich wieder zu Settings --> All Settings --> Polling Engines und verifiziere die APE:

11.png

Die APE lebt und ist verbunden aber langweilt sich. Das ändere ich nun.

Manage Nodes

12.png

Suche mir irgendeine Node und klicke auf More Actions / Change Polling Engine

13.png

Wähle aus:

14.png

Ich kann links nach Polling Engine gruppieren:

15.png

Natürlich kann ich das auch im Bulk ändern mit mehreren Nodes gleichzeitig, ebenso geht das direkt in der Datenbank bei NodesData in der Spalte EngineID:

16.png

Irgendwann nächstes Jahr reden wir mal über die Datenbank. Aber nicht jetzt.

Das gleiche Spiel gibt es beim zusätzlichen Webserver.
Zuerst: Warum brauche ich den?
Wir sagen bei 20-25 Benutzern die gleichzeitig auf Orion zugreifen macht es Sinn, AWS einzusetzen um die Last zu verteilen.
Aber!

Ein AWS ist vergleichsweise günstig für einen dreistelligen Listenpreis zu bekommen.
Einige Kunden setzen den auch bei weniger gleichzeitigen Zugriffen ein allein um ein schnelleres Webinterface zu bekommen.

Auch dazu etwas Hintergrund:
Auf dem Orion Server hat das Polling höchste Priorität. Alles andere wird hinterhergestellt.
Wenn die Ressourcen knapp werden, muss unter anderem die Web-Performance darunter leiden.

Wenn das GUI outsourced ist, bekomme ich also auch bei kleineren Deployments bessere Performance.

Probiert es einfach einmal aus – der Prozess ist einfach. Tatsächlich genauso wie oben erklärt daher gehe ich nicht erneut durch die Schritte. Passt einfach nur hier auf:

17.png

Gut, jetzt gehen wir mal noch einen Schritt weiter.
Wir garantieren offiziell bis zu neun APEs neben dem NPM (oder anderen Modulen), es gibt Deployments da draußen die deutlich höher ausfallen. Sogar in Deutschland emoticons_wink.png
Wenn ein Unternehmen jetzt aber auch darüber hinauswächst? Sagen wir mal 500 000 Interfaces?

Dann arbeiten wir mit individuellen Instanzen.

Hier bekommt jede Region ein eigenes Orion zum Spielen. Mit allen notwendigen Modulen und jeweils einer eigenen Datenbank.

Das System hat viele Vorteile, so kann man z.B. unterschiedliche Lizenzgrößen in Europa und den USA nutzen, auch unterschiedliche Module.
Man hat in den jeweiligen Regionen den vollen Zugriff auf sein eigenes Zeugs und es kann mir relativ egal sein, was an anderer Stelle vor sich geht.
Ebenso kann ich so ein Setup auch als Art von active/active sehen und einige extrem kritische Nodes von zwei Standorten aus überwachen, falls mal irgendwo ein Totalausfall ist.
Last but not least – manchmal gibt es schwierige politische Situationen in einer global agierenden Firma und hier kann ein System mit individuellen Instanzen einfach Brennpunkte aus Diskussionen nehmen. Jeder überwacht halt sein eigenes Zeugs!

Aber, auch bei getrennten Instanzen möchte ich sicher irgendwie mit der Gesamtsituation unzufrieden die Gesamtsituation im Überblick halten. Wie geht das?

Dazu gibt es die EOC!

Vereinfacht gesagt, ist die EOC das virtuelle Gegenstück zu einer Kontrollwand bei der NASA wie ihr das aus vielen Filmen kennt. Ja genau, die gleichen Filme mit als Raumschiffen getarnten Bügeleisen.

Früher hat die EOC auch tatsächlich so ausgesehen, hat aber vor etwa einem halben Jahr ein neues Kleidchen bekommen und sieht jetzt wie ein modernes Orion System aus.

Verschiedene Orion Instanzen sitzen irgendwo und werden zu einer gemeinsamen EOC verbunden, wo dann die Daten bzw Störungen zusammenfließen.

Die Software wird irgendwo auf einer VM abgelegt und benötigt eine eigene Datenbank. Installiert wird es wieder sehr einfach – hier nur ein Bild:

18.png

Dann der Config Wizard, den haben wir auch schon des Öfteren gesehen, aber eine Einstellung ist wichtig:

19.png

Legt eine neue DB an. Auch wenn es angeboten wird, nutzt nicht die Orion DB.
Nochmal.
Legt eine neue DB an.

Das kann gerne in der gleichen Instanz wie ein Orion sein, aber erspart euch den Ärger und mischt es nicht in die gleichen DB.

Nach Installation und Login erscheint dieses Element:

20.png

Ich verbinde mein Orion:

21.png

Ich kann der Instanz einen netten Namen geben oder vielleicht einen speziellen Benutzer anlegen:

acc.png

Das war es:

22.png

Viel gibt es hier allerdings nicht zu tun.

Irgendwo läuft etwas nicht wie gewünscht zeigt die EOC es an, ihr klickt drauf und landet dann bei der entsprechenden Orion Instanz.

Weitere Informationen gibt es hier:

https://support.solarwinds.com/Success_Center/Enterprise_Operations_Console_(EOC)

Okay, wie so üblich gibt es ein paar Themen auf die ich nicht eingegangen bin!
Bei den APEs gibt es z.B. auch „stackable“ Poller, also „stapelbar“ was nichts anderes heisst, dass ich einen Zusatzpoller auf die gleiche VM wie das Orion selbst werfen kann.
Ganz vorsichtig ausgedrückt ist das suboptimal, da zum einen nicht jedes Modul stacked Poller unterstützt, und ich so zum anderen weder Loadbalancing noch Regionen auseinanderziehen kann.

Ein großes Thema auf das ich hier nicht eingegangen bin ist die Ausfallsicherheit/Hochverfügbarkeit. Das allerdings hebe ich mir für einen neuen Blogpost nächstes Jahr auf!

Bis dahin wünsche ich euch frohe Weihnachten usw usw.

Ich schreibe dies gerade während eines weiteren Aufenthaltes in unserem Büro in London und Secret Santa hat gerade stattgefunden (auf Deutsch: Wichteln). Man kennt mich hier zu gut:

23.jpg

Geekzeugs, Katzen, Essen…toll! Nur kein Dolce & Gabbana, aber das kommt dann sicher, wenn ich wieder zurück in Cork bin!

Bis dahin macht es gut und entspannt euch!