Kapazitätsübersicht pro Cluster

Bei einem Ereignis schickt das Dashboard einen HTTP-POST mit JSON an die hinterlegten Ziele — für ITSM (ServiceNow/Jira), Automatisierung (Ansible AWX, n8n), Pipelines (GitLab/GitHub) oder Chat (Slack/Teams). Jeder Payload wird mit dem Secret HMAC-SHA256-signiert (Header X-Kapa-Signature), damit der Empfänger die Echtheit prüfen kann. Secrets werden nie zurück angezeigt und liegen bewusst nicht im Backup.

Ist die Ankündigung aktiv, sieht jeder Benutzer sie einmal als Popup – nach dem Klick auf „Verstanden" erscheint sie nicht erneut. Eine Änderung an Titel oder Text zeigt sie allen Benutzern noch einmal. Beispiele: Neues aus einem Release, neue Datacenter/Cluster, Wartungsfenster.

Die angezeigten Namen der Rollen sind frei wählbar. Die Rechte bleiben an der internen Rolle (linke Spalte) gebunden und ändern sich dadurch nicht.

Anträge durchlaufen die Teams von oben nach unten. Erst wenn alle Teams freigegeben haben, ist ein Antrag genehmigt. Ohne Teams gilt einstufig (Admin genehmigt direkt). Reviewer werden oben ihrem Team zugewiesen. Die E-Mail/Verteiler je Team wird angeschrieben, sobald das Team im Workflow an der Reihe ist (siehe „Mail-Benachrichtigungen"); mit „Team-Adressen speichern" sichern.

Bis zu 3 Stufen, jede Stufe eine Tag-Kategorie. In der Kapazitätsübersicht erscheinen dann kaskadierende Auswahllisten (Stufe 2 zeigt nur Werte, die zur Wahl in Stufe 1 passen). Die Kategorien kommen aus den vorhandenen Cluster-Tags – sind noch keine Daten geladen, ist die Liste leer.

Erfüllt der Ziel-Cluster nach Abzug des Antrags alle Schwellen, gibt das System markierte Stufen automatisch frei (Freigebender: „Auto-Freigabe", vollständig im Audit-Log). Geprüft wird bei der Antragstellung und immer, wenn eine Stufe neu an der Reihe ist. Greift eine Schwelle nicht oder fehlen Daten (z. B. kein Workload-Wert), geht der Antrag ganz normal an das Team — die Auto-Freigabe lehnt nie ab.

Nur angehakte Teams werden automatisch freigegeben — z. B. Team 1 prüft manuell, die weiteren Stufen laufen automatisch durch. Ohne Teams gilt der Haken sinngemäß für die einstufige Freigabe.

Haken = die Rolle sieht das Merkmal. Wirkt im UI und im Datenpaket (serverseitig entfernt). Administratoren sehen immer alles. Hier geht es nur um Sichtbarkeit — Rechte (Genehmigen, Verwaltung, Team-Sicht der Anforderer) bleiben fest an den Rollen.

Ist dies aktiv, können Freigebende beim Genehmigen und alle Berechtigten in der Storage-Übersicht eine LUN-Vergrößerung oder eine neue LUN anfragen. Das Storage-Team ruft die offenen Anfragen per API ab (/api/v1/storage-requests, auch CSV inkl. NAA) und meldet mit einem Token-Schreibrecht „Storage" die Umsetzung zurück.

Datastores kleiner als dieser Wert werden komplett aus der Auswertung genommen — sie erscheinen nirgends (Storage-Übersicht, Cluster- Detail) und zählen auch nicht in die Storage-Kapazität/Auslastung. Praktisch, um kleine Boot-/ISO-/Scratch-Datastores auszublenden. 0 = alle anzeigen. Die Änderung löst gleich einen neuen Datenabruf aus.

Datastores, deren Name einen dieser Begriffe enthält, werden ebenfalls komplett ausgeschlossen (überall, inkl. Kapazität). Mehrere durch Komma trennen, Groß-/Kleinschreibung egal — z. B. iso, backup, scratch. Ein Begriff wirkt als Teiltreffer (service erwischt auch server-service-01); */? gehen als Platzhalter (*-iso, lun-??-tmp). Leer = kein Filter.

Obergrenze für Storage-Anfragen (Vergrößerung und neue LUN). Größere Wünsche werden abgelehnt. Als internes Limit gedacht — Randnotiz: VMFS-6 unterstützt ohnehin höchstens 64 TB je Datastore. 0 = kein Limit.

vROps liefert für vSAN keinen sauberen Nutzbar-nach-RAID-Wert, nur die physische Roh- und Belegt-Kapazität. Die Auslastung in % stimmt damit ohnehin; der Faktor rechnet nur die absolute nutzbare Kapazität aus der Policy (Annahme): RAID-1 ≈ 50 %, RAID-5 ≈ 75 % (3+1) bzw. 67 % (2+1), RAID-6 ≈ 67 %. Bei gemischten Policies je Cluster den passenden Standard wählen.

Override je Cluster (optional – für abweichende Policies). Einfach lostippen: vorgeschlagen werden nur Cluster mit vSAN-Datastores.

Portgruppen, die hier zutreffen, werden komplett ausgeblendet — in der VLAN-Suche, im Netzwerk-Reiter der Cluster-Details und im Datenpaket. Die Änderung löst gleich einen neuen Datenabruf aus.

Portgruppen, deren Name einen dieser Begriffe enthält. Mehrere durch Komma trennen, Groß-/Kleinschreibung egal — */? gehen als Platzhalter (*-uplink, PG-Test-?). Leer = kein Filter.

Portgruppen mit diesen VLAN-IDs. Einzelne IDs und Bereiche, durch Komma getrennt — z. B. 99, 205, 3900-3999. Wirkt nur auf Portgruppen mit einer einzelnen VLAN-ID (Trunk-Bereiche blendet bereits die Uplink-Erkennung aus). Leer = kein Filter.

Für Bereiche ohne Netzanbindung an ein vROps: Ein Kollege führt das PowerCLI-Skript gegen das isolierte vCenter aus und lädt das erzeugte JSON hier mit einem Quellnamen hoch. Die Cluster erscheinen dann wie eine eigene vROps-Quelle — inklusive Kapazitätsanfragen, VLAN-Suche und Storage-Übersicht. Die Daten sind statisch (Stand = Import-Datum, als Tag am Cluster sichtbar); die Auto-Freigabe klammert diese Cluster bewusst aus. Ein erneuter Import unter demselben Namen ersetzt die Quelle.

Übernimmt eure bestehende Excel-Liste: in Excel als CSV speichern und hier hochladen. Alle Zeilen kommen als genehmigt an (Freigebender „Import"); die Gültigkeit rechnet ab dem Original-Datum — ältere Einträge laufen entsprechend sofort ab (wird gemeldet). Bereits vorhandene Kapa-Nummern werden übersprungen, ein erneuter Import erzeugt also keine Duplikate. Spalten werden an der Kopfzeile erkannt — Reihenfolge egal, zusätzliche Spalten werden ignoriert:

API-Dokumentation öffnen (interaktiv, mit „Ausführen") · OpenAPI-Spec zum Import in Swagger/Postman.

Legt fest, bei welchem Ereignis eine Mail rausgeht. Anforderer = der jeweilige Antragsteller (automatisch). Admin/Auditor = die eingetragene Verteiler-Adresse. Reviewer / „Team ist dran" = die Team-Adresse aus der Teams-Tabelle (Reiter „Benutzer & Rollen"). Voraussetzung ist ein konfigurierter SMTP-Server. „Freigabe" meint die endgültige Genehmigung. „Erinnerung" mailt das gerade zuständige Team (bzw. den Admin-Verteiler), wenn ein Antrag zu lange auf seine Freigabe wartet.

Betreff und HTML-Text der Reservierungs-Mails. Verfügbare Variablen unten einfach anklicken, um sie an der Cursor-Position einzufügen. Leer lassen = eingebaute Standardvorlage. Die Vorschau rechts rendert beim Tippen live mit Beispieldaten.

Wie ein Cronjob: jeder Teilbereich hat seinen eigenen Takt — so muss nicht alles bei jedem Abruf gelesen werden. Kapazität (VMs, CPU/RAM/Disk, Tanzu), Netzwerk (Portgruppen/VLANs) und Storage (Datastores/LUNs). Cluster, Hosts und Tags laufen immer mit. Leer oder 0 = Standard-Intervall. Der ⟳-Knopf oben kann jederzeit alles oder einen einzelnen Bereich sofort aktualisieren.

Alle angezeigten Zeiten (Stand, Log, die Abgleich-Uhrzeiten im ⟳-Menü, Mail-Zeitstempel) erscheinen in dieser Zeitzone. Der Abruf-Takt selbst ist davon unberührt (er rechnet in Sekunden). Leer = Zeitzone des Servers. IANA-Name, z. B. Europe/Berlin – die Sommer-/Winterzeit wird damit automatisch berücksichtigt.

Die im System gesetzten Werte (aus INI, kapa.env bzw. Kommandozeile). Nur zur Ansicht – Änderungen erfolgen in der Konfiguration und erfordern einen Neustart. Passwörter werden nie angezeigt (nur, ob gesetzt).