Tags: Azure, Netzwerk, Performance
Azure-Regionen sind in Availability Zones aufgeteilt, und diese verfügen über jeweils eigene Datacenter. Da die Zonen physisch auseinanderliegen, liefern sie unterschiedliche Latenzen. Damit es bei sensiblen Workloads nicht zu Engpässen kommt, lassen sich diese gezielt in Zonen platzieren.
Availability Zones sind physische Bereiche mit Rechenzentren in einer Azure Region wie beispielsweise West Europe. Sie gleichen Daten und Applikationen untereinander über eine synchrone Replikation ab, dienen also der Redundanz und somit der Ausfallsicherheit. Jedes Datacenter hat dafür eine unabhängige Stromversorgung, Kühlung und ein dediziertes Netzwerk.
Die Möglichkeit zur physischen Trennung der Workloads bietet somit eine zusätzliche Ausfallsicherheit. Durch diese Aufteilung ergeben sich auf der anderen Seite, bedingt durch die ungleiche Entfernung und mehrerer Hops, unterschiedliche Latenzwerte.
Manche Applikationen reagieren jedoch sensibel auf zu große Latenzen, so dass man sie in Zonen mit einer geringen Latenz platzieren wird. Dazu muss man erst einmal die Latenzen kennen bzw. messen. Für dieses Vorhaben habe ich ein interessantes Script (AvZone-Latency-Test.ps1) auf GitHub gefunden.
Script-Funktionen
Das Script erstellt drei virtuelle Maschinen, jede davon in einer separaten Zone. Die VMs werden mit einem Linux-Betriebssystem (hier: CentOS 8.0.1905) ausgestattet und gestartet. In ihnen führt es dann qperf aus, um die Latenz und den Durchsatz zu testen.
Es konfiguriert zudem automatisch alle Bedingungen innerhalb der Subscription, wie Resource Group, vNET, Subnet und Network Security Groups (NSG).
Voraussetzungen
Für das Ausführen des Scripts sind folgende Voraussetzungen zu beachten:
- Es ist eine Azure Subscription erforderlich (jede hat drei Zonen; der Name meiner Subscription lautet kueppers.lab)
- Die Quotas innerhalb der Subscription müssen ggfs. angepasst werden. Ich habe in meinem Lab die Standard DSv3 Family vCPUs auf 24 erhöht.
- PowerShell 5.1 oder neuere Version
- PowerShell-Module Posh-SSH und Az
Vorbereitungen
Das Posh-SSH-Modul (falls noch nicht vorhanden) kann man über folgenden Befehl installieren:
Install-Module -Name Posh-SSH -RequiredVersion 2.1
Für das Az-Module gibt man dieses Kommando ein:
Install-Module -Name Az -Scope CurrentUser -Repository PSGallery -Force
In meiner Umgebung habe ich zusätzlich alle Breaking Change Warnungen abgeschaltet:
Set-Item -Path Env:\SuppressAzurePowerShellBreakingChangeWarnings -Value $true
Das sollte man jedoch im Hinterkopf behalten und die Warnungen ggfs. reaktivieren.
Danach habe ich mich direkt über meinen Tenant mit Azure verbunden:
Connect-AzAccount -Tenant xxxxxxxx-yyyy-zzzz-xxxx-yyyyzzzzxxxx
Latenzmessung durchführen
Nach dem nun die Vorbereitungen getroffen sind, starte ich AvZone-Latency-Test.ps1 in der ISE (oder VS Code). Es akzeptiert auch Parameter für die Ausführung, beispielsweise ./AvZone-Latency-Test.ps1 -Region westeurope.
Zu Beginn fragt das Script den Namen der Subscription ab, legt die nötige Resource Group an und konfiguriert vNET, Subnet und NSG. Anschließend erstellt es die VMs.
Ist das alles erledigt, werden die virtuellen Maschinen gestartet.
Ich überprüfe den Status der Maschinen zusätzlich im Azure-Portal. Nach ihrem Start werden die SSH-Sessions generiert und qperf installiert.
Schließlich finden die Bandbreiten- und Latenz-Tests statt. Werfen Sie einen Blick in das Script ab Zeile 247, hier können Sie alle dazugehörigen Parameter aufschlüsseln.
Resultat und automatisches Purging
Über die tabellarische Ausgabe der Ergebnisse lassen sich die Zonen vergleichen. Das obere Ergebnis zeigt die Latenzen. Bei Zone 1 zu 2 ist in meinem Beispiel das Resultat 61 us (Microseconds). Der Vergleich von Zone 1 zu 3 liefert hier schon höhere Latenzen von 704 us.
Betrachten wir zudem die Bandbreiten, dann zeigt sich hier eine erhebliche Differenz (2,8 GB/sec zu 894 MB/sec).
Nach Ausgabe der Messergebnisse werden die automatisch konfigurierten Ressourcen bei Bedarf wieder entfernt und verursachen keine weiteren Kosten.
Täglich Know-how für IT-Pros mit unserem Newsletter
Marcel Küppers arbeitet seit über 25 Jahren in der IT, aktuell als Team Leader, zuvor als Consultant und Infrastructure Architect unter anderem für den japanischen Konzern JTEKT/TOYODA mit Verantwortung über die Europastandorte Krefeld und Paris.
Darüber hinaus wirkte er als Berater im EU-Projekt-Team für alle Lokationen des Konzerns mit und ist spezialisiert auf hochverfügbare virtualisierte Microsoft-Umgebungen plus Hybrid Cloud Solutions.
Zertifizierungen: MS Specialist und MCTS für Hyper-V/SCVMM, MCSE, MCITP, MCSA. Zusätzlich zertifiziert für PRINCE2 Projektmanagementmethode.
Ähnliche Beiträge
Weitere Links