Netzwerklatenz für Azure Availability Zones messen


    Tags: , ,

    Azure Availability ZonesAzure-Regionen sind in Availability Zones aufge­teilt, und diese ver­fügen über jeweils eigene Data­center. Da die Zonen physisch aus­ein­ander­liegen, liefern sie unter­schiedliche Latenzen. Damit es bei sen­siblen Work­loads nicht zu Eng­pässen kommt, lassen sich diese ge­zielt in Zonen platzieren.

    Availability Zones sind physische Bereiche mit Rechenzentren in einer Azure Region wie beispielsweise West Europe. Sie gleichen Daten und Appli­kationen untereinander über eine synchrone Replikation ab, dienen also der Redundanz und somit der Ausfall­sicherheit. Jedes Datacenter hat dafür eine unabhängige Strom­versorgung, Kühlung und ein dediziertes Netzwerk.

    Azure-Region mit separaten Zonen

    Die Möglichkeit zur physischen Trennung der Workloads bietet somit eine zusätzliche Ausfall­sicherheit. 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.

    Angabe der Subscription

    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.

    RG, vNET, Subnet, NSG und VMs werden automatisch konfiguriert

    Ist das alles erledigt, werden die virtuellen Maschinen gestartet.

    Blick in das Azure Portal: VMs wurden erzeugt und gestartet

    Ich überprüfe den Status der Maschinen zusätzlich im Azure-Portal. Nach ihrem Start werden die SSH-Sessions generiert und qperf installiert.

    Abbildung 5.0 SSH Konfiguration und Installation von qperf

    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.

    Ausgabe der Messergebnisse

    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

    Wir ver­wenden Ihre Mail-Adresse nur für den Ver­sand der News­letter.
    Es erfolgt keine per­sonen­be­zogene Auswertung.

    Bild von Marcel Küppers

    Marcel Küppers arbeitet seit über 25 Jahren in der IT, aktuell als Team Leader, zuvor als Consultant und Infra­structure Architect unter anderem für den japani­schen Konzern JTEKT/TOYODA mit Verant­wortung über die Europa­standorte Krefeld und Paris. Da­rüber hinaus wirkte er als Berater im EU-Projekt-Team für alle Loka­tionen des Kon­zerns mit und ist spezia­lisiert auf hoch­verfügbare virtuali­sierte 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.
    // Kontakt: E-Mail, Twitter, LinkedIn //

    Ähnliche Beiträge

    Weitere Links