Quick Tip – VMware vSphere VM fail upon reboot

Wie auch sehr ausführlich in dem VMware KB „Windows 8 and Windows 2012 Server or later virtual machines fail upon reboot (2092807)“ kann es bei Windows 2012 Gästen als VMware ESXi 5.5 und 6.0 VM zu folgendem Fehler kommen:

  • Windows 8 und Windows 2012 Server oder später hängen bei einem Neustart im Boot Splash Screen
  • Virtuelle Maschine hat Hardware Version 10 (vmx-10)
  • Nach einem Reset bootet der Server wieder sauber
  • Dieses Problem tritt nicht auf, bei einem vollen Power-Cycle (herunterfahre und wieder hochfahren)
vSphere VM fail upon reboot - boot splash screen

Boot Splash Screen

Lösung des Problems

Folgende VMware ESXi Versionen beinhalten einen Fix

Eine vorübergehende Lösung ist das setzen einer erweiterten Option bei allen relevanten VMs:

monitor_control.enable_softResetClearTSC = TRUE

Um den Workaround schnell umzusetzen habe ich mir ein VMware PowerCLI Script geschrieben:

vRealize Operations – Application Dashboard

Um den Anwendungsbetreuern jederzeit einen Überblick über Ihre Systeme zu gewähren, habe ich in VMware vRealize Operations ein Application Dashboard für die kritischen Anwendungen erstellt.
Die Anwendungen um die es hierbei primär geht bestehen mindestens aus drei VMware vSphere VMs.

Die Nutzer der Dashboards sollen über folgendes einen Überblick bekommen:

  • Welche Systeme gehören zu der Anwendung
  • Wie ist die Topologie der zugehörigen VMs
  • Welche Abhängigkeiten haben die einzelnen VMs
  • Health Level der wichtigen Parameter der einzelnen VMs
  • Aktuelle und Vergangene Metriken der wichtigen Parameter der einzelnen VMs

Mein Application Dashboard

vRealize Operations - Application Dashboard

Erstellung des Application Dashboard

Custom Group

Der erste Schritt ist das erzeugen einer Custom Group für die Applikation.

! Wichtig ! Nur VMware vSphere VMs der Gruppe hinzufügen (keine ESXi Hosts oder Datastores)

custom group

Metric Config

Wir benötigen als Vorbereitung noch eine Metric Config. Diese legt dann in den Widgets die wichtigen Metriken der einzelnen VMs fest.

metric config

Super Metric

In dem XML wird auf eine Super Metric mir der ID sm_de9e1091-9b8b-42ce-9fc9-8af8a1daa508 verwiesen. Diese Metric zeigt die Uptime des Gastes in Tage an und muss noch manuell erzeigt werden.

super metric

super metric details

Die Formel der Super Metric:

Wie man an die ID der neuen „Super Metric“ herankommt ist in dem VMware Guide Super Metrics and XML Editing beschrieben.

! Wichtig ! Natürlich dann die ID aus der eigenen API durch die in meiner Beispiel-XML (sm_de9e1091-9b8b-42ce-9fc9-8af8a1daa508) austauschen

Custom Dashboard

Nun kommen wir endlich zu unserem eigentlichen Custom Dashboard.

custom dashboard list

Folgende Widgets habe ich dem Dashboard hinzugefügt:

  • Object List Widget
  • Object Relationship Widget
  • Topology Graph Widget
  • Scoreboard Widget
  • Property List Widget
  • Metric Chart Widget

Object List Widget

Für das Widget wählen wir die vorher erstellte Applikations-Gruppe.

object list widget

Object Relationship Widget

Bitte keine Elemente in dem Widget auswählen, diese werden später über die Interaktionen festgelegt.

object relationship widget

Topology Graph Widget

Die Objekte werden ebenfalls später über die Interaktionen festgelegt.

topology graph widget

Scoreboard Widget

In diesem Widget verwenden wir nun die neu erstellte Metrik Konfiguration „Application“.

scoreboard widget

Property List Widget

In diesem Widget ebenfalls die Metrik Konfiguration „Application“ wählen.

property list widget

Metric Chart Widget

Und auch das letzte Widget benötigt wieder unsere Metrik Konfiguration „Application“.

metric chart widget

Widget Interactions

Über die Widget Interactions legen wir zum Schluss noch die Datenquellen der Widgets fest.

widget interactions

Weitere Quellen

Bei meinen Recherchen zu dem Thema bin ich auf den großartigen Artikel von Scott Norris gestoßen. Hier auch unbedingt mal reinschauen, wenn man ein solches Dashboard für sich erzeugen möchte.

PRTG – Advanced Scheduled Task Sensor

Mit einer der letzten Versionen hat Paessler in PRTG den Scheduled Task Sensor endgültig eingestellt. In einem KB Artikel verweißt Peassler auf den ScheduledTask2XML sensor von PRTG Tools Family als Ersatz. Mir fehlt bei dem Tool allerdings etwas die Transparent und ich benötige nicht all diese Channels. Daher habe ich mir meinen eigenen PowerShell Advanced Sensor zur Scheduled Task Überwachung erstellt.

Scheduled Task Sensor in PRTG

In dem Beispiel ist dem Channel „LastRunInHours“ manuell ein Upper Warning und Error Level hinzugefügt. Der Channel „LastTaskResult“ wird automatisch mit den nötigen Error Levels konfiguriert.

Auszug aus der XML:

Scheduled Task Sensor in PRTG

Advanced Sensor in PRTG anlegen

Beispiel der Parameter für das Script:

Sensor Einstellungen:

Scheduled Task Sensor - Setup

Scheduled Task Sensor im Debug Mode

Der Debug und Verbose Modus ist nur zum Test auf dem Probe oder Core Server gedacht. Im PRTG Sensor diese Parameter bitte nicht verwenden.

Scheduled Task Sensor Debug Mode

PowerShell Script für den PRTG Advanced Sensor

 

GitLab CI/CD mit PowerShell – Teil 2 – Continuous Integration

In Teil 1 der Serie GitLab CI/CD mit PowerShell haben ich meinen Aufbau und den Installationsvorgang der GitLab Umgebung für kleine PowerShell Projekte aufgezeigt.
Nun steigen wir mit diesem Artikel direkt ein, was ein Projekt für Continuous Integration zusätzlich benötigt und wie die Tests bzw. ein Deployment aussehen können.

GitLab CI/CD mit PowerShell – Einführung

Continuous Integration ist In GitLab 8 voll integriert und bei jedem Projekt standardmäßig aktiviert. Um eine CI Pipline bei jedem Merge oder Push auszulösen muss lediglich ein weiteres File im Root des Projektes angelegt werden.

Zusätzliches File: .gitlab-ci.yml

In diesem File werden alle Schritte für den Runner definiert. Die Schritte sind in Stages aufgeteilt: Build, Test, Deploy

Außerhalb der Scripts in den Stages können in dem YAML File noch Pre- und Post-Scripte sowie Variablen definiert werden.
Die GitLab Doku bietet hier einen sehr guten Einblick in die umfangreichen Möglichkeiten.

GitLab CI/CD mit PowerShell – Tests

Wir schauen uns in dem Folgenden Beispiel als erstes die wohl am häufig genutzte Stage an, Test.

.gitlab-ci.yml Beispiel für Tests

Was haben wir in dem Beispiel definiert:

  1. Variable: Deaktivierung der SSL Verifizierung wegen eines sporadischen Problems
  2. Pre-Script: Import der PowerShell Module Pester und PSScriptAnalyzer
  3. Stages: Nur Test Stage
  4. Job Name: PS_ScriptAnalyzer
    1. Script: Ausführung der PSScriptAnalyzer Analysten mit Prüfung auf Error Level Fehler
    2. Tags:  Windows (zur Auswahl des Runners)
  5. Job Name: PS_Pester
    1. Script: Ausführung der Pester Tests mit Prüfung der Fehler
    2. Tags:  Windows (zur Auswahl des Runners)

Der erfolgreiche Lauf der Pipeline sieht dann so aus

GitLab CI/CD mit PowerShell - Pipeline

 

PSScriptAnalyzer Log

ps_scriptanalyzer-log

Pester Log

ps_pester-log_v2

Die beiden Beispiel Tests stellen auch für mich meine Baseline der Qualitätskontrolle in meinen Projekten dar.

  • Qualität des Codes mit PSScriptAnalyzer anhand der Regeln Prüfen
  • Grundlegende Tests mit Pester festlegen

Durch dieses Vorgehen ist die Prüfung des Projekts auch jederzeit außerhalb von GitLab CI/CD mit PowerShell möglich und muss nicht separat erarbeitet werden.

PSScriptAnalyzer

Was ist PSScriptAnalyzer

PSScriptAnalyzer is a static code checker for Windows PowerShell modules and scripts. PSScriptAnalyzer checks the quality of Windows PowerShell code by running a set of rules. The rules are based on PowerShell best practices identified by PowerShell Team and the community. It generates DiagnosticResults (errors and warnings) to inform users about potential code defects and suggests possible solutions for improvements.

In meine Tests in GitLab ziehe ich nur die Errors in PSScriptAnalyzer zu rate. Dies sind z.B. nicht verwendete Variablen oder die Verwendung von reservierten Parametern in Funktionen.
Alle Regeln mit deren Level können in der Übersicht der PSScriptAnalyzer Regel Dokumentation auf GitHub eingesehen werden.

Installation von PSScriptAnalyzer

PowerShell 5

Mit PowerShell 5 ist der beste Weg die direkte Installation aus der PowerShell Gallery.

PowerShell 4

Der einfachste Weg ist der Umweg über die PowerShell 5.

  • Das Modul in PowerShell 5 herunterladen

  • Dann den Ordner in „C:\Windows\System32\WindowsPowerShell\v1.0\Modules“ auf dem Server mit PowerShell 4 kopieren
  • Modul laden

Pester

Was ist Pester

Pester provides a framework for running unit tests to execute and validate PowerShell commands from within PowerShell. Pester consists of a simple set of functions that expose a testing domain-specific language (DSL) for isolating, running, evaluating and reporting the results of PowerShell commands.

Pester tests can execute any command or script that is accessible to a Pester test file. This can include functions, cmdlets, modules and scripts. Pester can be run in ad-hoc style in a console or it can be integrated into the build scripts of a continuous integration (CI) system.

Pester ist nicht erst seit GitLab CI/CD mit PowerShell ein wichtiges Werkzeug für mich. Daher versuche ich die CI Tests innerhalb von GitLab so zu erstellen, dass die Tests auch weiterhin direkt in Pester brauchbar sind.

Für Pester Neulinge ist das GitHub Wiki ein guter Start in das Thema.

Installation von Pester

PowerShell 5

Mit PowerShell 5 ist der beste Weg wieder die direkte Installation aus der PowerShell Gallery.

PowerShell 4

Der einfachste Weg ist der Download des GitHub Pester Repositorys.

  • Das Repository als Zip herunterladen
  • Dann das Zip in „C:\Windows\System32\WindowsPowerShell\v1.0\Modules“ auf dem Server mit PowerShell 4 extrahieren
  • Modul laden

Meine Basis Tests mit Pester

Was Teste ich an Funktionen immer mindestens mit Pester:

  • Fehlerfreier Import der Funktion
  • Grundlegende Nutzung der Funktion (Wenn das non-Destructive möglich ist)

GitLab CI/CD mit PowerShell – Deploy

Fügt man dem YAML File noch die Stage Deploy hinzu und definiert diese, werden alle Deploy Job Scripte nach den erfolgreichen Tests ausgeführt.

.gitlab-ci.yml Beispiel mit Deployment

In den Deploy Jobs habe ich auf eine GitLab Runner Variable zugegriffen: $CI_PROJECT_DIR

Die Variable beinhaltet den Pfad in welches das Repositoy für den Build kopiert wird.

Der erfolgreiche Lauf der kompletten Pipeline sieht dann so aus

gitlab-pipeline_deploy

GitLab CI/CD mit PowerShell – Teil 1 – Installation

Als meine PowerShell Skripte immer umfangreicher wurden und zu kleinen Projekten ausgeufert sind, wuchs der Wunsch nach einer besseren Versionskontrolle für meine Skripte. Somit musste ein Version Control System her. Ich bin sehr froh, dass damals meine Wahl auf GitLab gefallen ist. Dieses wirklich großartige Produkt bietet weitaus mehr als nur eine reine Versionskontrolle. Mit GitLab war ich bestens vorbereitet auf meinen nächsten Schritt im Bereich DevOps: GitLab CI/CD (Continuous Integration / Continuous Delivery) mit PowerShell

Einleitung zu GitLab CI/CD mit PowerShell

Bevor ich in das Thema einsteige, möchte ich noch ein paar einleitende Worte zu Versionkontrolle, Continuous Integration und Continuous Delivery verlieren.

Warum Versionskontrolle

Eine Versionkontrolle soll alle Änderungen am Code eines Projekts festhalten. Somit ist es jederzeit möglich auf beistimme Stände zu springen oder Stände miteinander zu vergleichen. Weiter wird natürlich auch festgehalten wer, wann und was geändert hat.

Wenn heutzutage über Versionskontrolle gesprochen wird, ist im Normalfall Distributed Version Control (DVC) gemeint. Das bestbekannteste Distributed Version Control System (DVCS) ist wohl GIT.

Warum Continuous Integration und Continuous Delivery

Dieses Thema kann man nun sehr ausführlich aus der Sicht eines echten Entwicklers mit umfangreichen Projekten betrachten, was den Rahmen vermutlich sprengen würde. Daher zeige ich hier nur meinen spezifischen Nutzen auf.

Für mich ist Continuous Integration in meinem Umfeld eine Qualitätskontrolle und dient zur Vermeidung von Fehlern.
Jeder Push in das Projekt löst vordefinierte Tests mit dem aktuellen Codes dieses Projektes aus.

Das Ergebnis wird dann in der GitLab Oberfläche für alle Nutzer visualisiert :

GitLab CI/CD mit PowerShell - Build Status

Aber auch das Log der Testläufe kann jederzeit angezeigt werden:

GitLab CI/CD mit PowerShell - Test Run

Continuous Delivery (Deployment) ist dann dafür zuständig den aktuellen Entwicklungsstand des Projektes in einen ausführbaren Zustand zu bringen. Dies kann z.B. das simple Kopieren der Daten an den benötigten Ort sein. Aber natürlich sind auch wesentlich komplexere Vorgänge denkbar.

Prozess von GitLab CI/CD:

GitLab CI/CD mit PowerShell - Flow

Welche Tools verwenden

Für die Nutzung unter Windows verwende ich verschiedene Tools:

Unter Linux bzw. in dem Beispiel unter Ubuntu verwende ich das Paket git-core:

Weitere Ressourcen

Ein guter Einstieg ist das Buch Pro Git. Erhältlich als Ebook oder als gedruckte Version auf Amazon.

progit2

Mein GitLab CI/CD Aufbau

Da ich es zu 90% nur mit PowerShell Projekten zu tun habe und Entwicklung nichts Betriebs kritisches ist, sieht der Aufbau sehr einfach aus:

  • Ein GitLab Server
  • Ein PowerShell Runner
  • Anbindung an das Microsoft Active Directory

 

GitLab CI/CD mit PowerShell - Aufbau

GitLab CI/CD mit PowerShell – Aufbau

Dieser eine Runner ist so aufgelegt, dass er alle für mich relevanten Arten von PowerShell Skripten ausführen kann.

Meine Module und SnapIns:

Basis Installation von GitLab 8.11

Ich habe für den GitLab Server als Betriebssystem wie empfohlen Ubuntu 16.04 x64 gewählt. Die Installation ist komplett ohne Zwischenfälle abgelaufen.

Vorbereitung Betriebssystem

Installation VIM Editor

Instalaltion GitLab

Initialisierung GitLab

Basis Konfiguration von GitLab 8.11

LDAP

Wie in dem Diagramm zu sehen arbeite ich mit einem Microsoft Active Directory.

GitLab integrates with LDAP to support user authentication. This integration works with most LDAP-compliant directory servers, including Microsoft Active Directory, Apple Open Directory, Open LDAP, and 389 Server. GitLab EE includes enhanced integration, including group membership syncing.

Quelle: GitLab LDAP Doku

Mit einem Domain Controller sieht meine Konfiguration so aus:

GitLab - LDAP

HTTPS

Ich verwende ein Microsoft CA signierten Zertifikat. Hierbei hat die folgende Vorgehensweise ohne Komplikationen funktioniert:

  1. In gitlab.yml:
    1. Set the port option in section 1 to 443.
    2. Set the https option in section 1 to true.
  2. In the config.yml of gitlab-shell:
    1. Set gitlab_url option to the HTTPS endpoint of GitLab (e.g. https://git.example.com).
    2. Set the certificates using either the ca_file or ca_path option.
  3. Use the gitlab-ssl Nginx example config instead of the gitlab config.
    1. Update YOUR_SERVER_FQDN.
    2. Update ssl_certificate and ssl_certificate_key.
    3. Review the configuration file and consider applying other security and performance enhancing features.

Quelle: GitLab Doku – Using HTTPS

Mit dem zusätzlichen HTTP zu HTTPS Redirect sieht meine Konfiguration so aus:

GitLab - HTTPS

Installation des Multi-Runner für GitLab CI unter Windows

Als erstes muss das Binary noch heruntergeladen werden: x86 oder amd64

Mehr Details zum Multi-Runner:

In meinem Fall verwende ich die 64Bit Variante, abgelegt unter „C:\Multi-Runner“.

Multi-Runner registrieren

Regierungsprozess Fragt nun einige Daten ab:

  • gitlab-ci coordinator: https://<GitLab Server>/ci
  • gitlab-ci token: Für einen Globalen Runner ist dies in der Admin Area zu finden

GitLab Runner - Token

  • gitlab-ci description: Hostname
  • executor: shell
  • gitlab-ci tags: Windows

Nun muss noch manuell eine weitere Zeile in die erzeugte Konfiguration (Im Pfad der EXE) eingetragen werden:

GitLab Runner - Config

Multi-Runner Dienst installieren

Der Dienst wir so als „Local System“ registriert. Dies in meinem Fall nicht ausreichend, also habe ich einen AD User mit den benötigten Rechten (vCenter, Veeam, etc.) erzeigt und starte den Dienst als dieser User.

Multi-Runner prüfen

Unter Admin Area > Runners ist nun der neue Windows Runner zu finden:

GitLab Runner

Nun ist die die das GitLab System inklusive einem Runner bereit für das erste Projekt.

Wie ein Projekt mit Continuous Integration / Continuous Delivery aufgebaut sein muss und welche Möglichkeiten GitLab CI/CD bietet werde ich im Teil 2 dieser Serie näher ausführen.

Stay tuned…

vRealize Operations – Brocade Port Alerts

Der VMware Solutions Exchange bietet für vRealize Operations ein Brocade SAN Analytics Management Pack. Dieses Bringt einige sehr gute Dashboards zur Analyse der SAN Fabric mit sich. Zusätzlich liefert es auch sinnvolle Metriken zur Analyse der jeweiligen FibreChannel (FC) Ports, leider aber keine Brocade Port Alerts.

Wie man die wichtigsten Alarme bezüglich seiner Brocade FC Ports in vRealize Operations selbst anlegen kann, möchte ich daher nun aufzeigen.

Als wichtige Metriken habe ich für mich folgendes eingestuft:

  • CRC Fehler
  • Tx Nutzung über Schwellwert
  • Rx Nutzung über Schwellwert

Vorausetzungen für Brocade Port Alerts

  • VMware vRealize Operations 6.x (6.1 – 6.3 wurden getestet)
  • Brocade SAN Analytics Management Pack 2.x (2.0 und 2.1 wurden getestet)
  • vRealize Operations Brocade Fabric Adapter angebunden an SAN Network Advisor (12.3.4 wurde getestet)

Die gesamte Konfiguration des Brocade SAN Network Advisor ist relativ aufwendig und ich empfehle daher den Brocade Network Advisor User Guide ebenso wie den Brocade SAN Analytics Management Pack Users Guide einmal in Ruhe vorher durchzulesen.

Konfiguration der Voraussetzungen

Die wichtigsten Schritte aus den beiden Guides habe ich kurz zusammengefasst.

Konfiguration des Brocade SAN Network Advisor

In dem folgenden Screenshot sind zwei SAN Fabrics erfolgreich mit dem Brocade SAN Network Advisor discovered worden und ein erster Seed durchgeführt. Die nicht überwachten Geräte in dem Beispiel sind verbundene HP VirtualConnect Module.

Brocade Port Alerts - Fabric Discovery

Fabric Discovery

Details zu der Konfiguration sind dem Brocade Network Advisor SAN User Guide zu entnehmen.

Konfiguration der Performance Daten Erfassung der SAN Switches

Ohne diese beiden Schritte sind keine Metriken in vRealize Operations zu sehen und damit auch keine Alarme möglich. Der Brocade SAN Analytics Management Pack muss vorab installiert werden.

Continue reading

VMware vRealize Suite Updates

VMware hat in den letzten Wochen seinen wichtigsten Produkte in der vRealize Suite Updates spendiert. Gestern wurde vRealize Automation 7.1 und vRealize Operations 6.3 veröffentlicht. Beide Produkte kommen mit großen Neuerungen und Verbesserungen daher. Vor nicht ganz zwei Wochen wurde bereits vRealize Log Insight 3.6 freigegeben. in diesem Release mangelt es ebenfalls nicht an neuen Funktionen und Ausblicken auf das nächste Release.

Alle Produkte der VMware vRealize Suite machen mit ihren kontinuierlichen Update Zyklen wirklich gewaltige Fortschritte und wachsen zudem immer besser zusammen!

vRealize Suite Updates –  vRealize Automation 7.1

vRealize Suite Updates - vRA 7.1

Jad El-Zein hat bereits einen umfangreichen Artikel zu den Neuerung im Detail veröffentlicht:
The Scoop: vRealize Automation 7.1

Besonders freue ich mich über die Import Möglichkeit besehender 6.2.x Installationen! Es wird hoffentlich bald ein Artikel dazu folgen.

Hier die Neuerungen aus den Release Notes:

What’s New

The vRealize Automation 7.1 release includes resolved issues and the following changes.

  • Streamlined installation process using a silent installer.
  • Agent and prerequisite command line interface.
  • Migration tool to move data from a source vRealize Automation 6.2.x environment to a fresh vRealize Automation 7.1 environment while preserving the source environment.
  • IPAM integration framework with ability to deploy machines and applications with automated assignment of IP addresses from leading IP address management systems, with the first integration with Infoblox.
  • Integrated support for Active Directory policies.
  • Custom property dictionary controls to improve property definitions and vRealize Orchestrator actions.
  • Reconfigure life-cycle events by means of event broker workflow subscriptions.
  • Additional vSphere provisioning options and data collection improvements.
  • Ability to manually conduct horizontal scale in and scale out of vRealize Automation deployments, including the automatic update of dependent components.
  • Customizable message of the day portlet available on the home page.
  • Additional information and filter options on the Items page.
  • New ready-to-import blueprints for vSphere and AWS available from the VMware Solution Exchange.
  • Discontinued support for PostgreSQL external database.

Continue reading

VMware vExpert 2016

Letzten Freitag war es nun endlich soweit, ich wurde für die VMware vExpert 2016 Auszeichnung ausgewählt. Lange habe ich mir es erhofft und nun hat es tatsächlich geklappt. Es ist mir eine große Ehre!

Ich danke allen Lesern dieses Blogs und natürlich auch meiner anderen Community Beiträge. Es macht mir unsagbar viel Spaß an dieser wirklich großartigen Community teilzuhaben, vielen Dank dafür.

Herzlichen Glückwunsch noch einmal an alle anderen vExpert`s!

P.S. Das erste Mal mit #vExpert Hashtag

 

 

PRTG – Veeam Cloud Connect Monitoring

Wer zum Veeam Cloud Connect Monitoring keinen eigenen Veeam ONE Server im Einsatz hat, was nicht sehr ungewöhnlich ist, muss sich eine eigene Lösungen schaffen. In jedem Fall ist es als Veeam Service Provider notwendig  die Ressourcen seiner Kunden im Auge zu behalten. Alleine schon für das Korrekte Reporting an Veeam (v9 Update 2 bietet hier allerdings enorme Verbesserungen. Siehe VCSP Forum) aber auch um frühzeitig auf Engpässe bei den Quotas reagieren zu können.
Alle nötigen Informationen für das Monitoring und Reporting der Veeam Cloud Connect Mandanten finden sich bereits im Veeam Enterprise Manager. Leider findet man diese nicht direkt in der Web Oberfläche, sondern nur per RESTful API. Die Schnittstelle ist aber sauber dokumentiert und sehr strukturiert aufgebaut (Siehe RESTful API Reference).

Somit ist es also möglich sich mit etwas PowerShell alle nötigen Informationen per EXE/Script Advanced Sensor in PRTG anzuzeigen. Damit ist ganz nebenbei auch für eine saubere Aufbewahrung der statistischen Daten gesorgt.

Welche Daten sind von Relevanz:

  • Anzahl gesicherter VMs
  • Konfiguriertes Backup Storage Quota
  • Genutztes Backup Storage Quota
  • Anzahl Replizierter VMs
  • Genutzte Replika vCPUs
  • Genutzter Replika Arbeitsspeicher
  • Konfiguriertes Replika Storage Quota
  • Genutztes Replika Storage Quota

Zusätzlich ist für das Veeam Cloud Connect Monitoring ein prozentualer Storage Quota sinnvoll, somit kann ein Alert auf diesen Wert pro Mandant gebunden werden.

! Hinweis ! Zur Vereinfachung verzichte ich bisher auf die Aufschlüsselung der Replika-Ressourcen nach Hardware Plan. Aktuell werden alle zugeordneten Ressourcen addiert.

So könnte der Sensor mit seinen Channels aussehen:

PRTG - Veeam Cloud Connect Monitoring- Übersicht Continue reading

Script – Get vSphere VM Max IOPS

Ich habe in einem früheren Artikel bereits ein PowerCLI Script veröffentlicht welches einen sehr umfangreichen Report über Klassifizierungen und IOPS von VMware vSphere VM Disks ausgibt. Es hat sich aber gezeigt, am häufigsten wird einfach nur VM Max IOPS über einen gewissen Zeitraum benötigt. Sei es zur Problem Analyse oder nur als statistische Daten.

Daher habe ich mir eine vereinfachte PowerShell Funktion angefertigt, so ist die Verwendung des Reports sehr simpel und flexibel. Ich gebe auch zu, dass das vorherige Script etwas zu umfangreich und aufwändig war…

VM Max IOPS

Get-VM | Get-VMmaxIOPS -Minutes 60

In dem Screenshot ist auch gut zu sehen, dass die Funktion sogar die einzelnen Disks der VM nach SCSI-ID und Datastore aufschlüsselt.

Hier ein paar Beispiele für die Anwendung:

  • Alle VMs mit den maximalen IOPS der letzten Stunde, Sortiert nach IOPS

  • Alle VMs im Ordner „TST“ mit den maximalen IOPS der letzten Stunde, Sortiert nach IOPS

  • Alle VMs im Cluster „Clsuter01“ mit den maximalen IOPS der letzten Stunde, Sortiert nach IOPS

  • Alle VMs mit mehr als 4 CPUs mit den maximalen IOPS der letzten Stunde, Sortiert nach IOPS

Continue reading