Ansible Server Leistungsbewertung (Rolle)

Verstehen Sie die Leistung Ihres Maschinen/Containers/Droplets/Linode mit Ansible.

Wenn es auf einem neuen Host ausgeführt wird, gibt es Ihnen einen Eindruck davon, was die Basisleistung ist und ob diese Ihre Ziele erfüllt.

Bitte beachten Sie, dass das Projekt nur unmittelbare Anforderungen erfüllt, die von unserem Operationsteam vorangetrieben werden. Es sollte jedoch in vielen Fällen ausreichen. Ich freue mich darauf, mit Ihrer Hilfe auf mehr Systeme und Anwendungsfälle zu erweitern.

Der Katalysator

Der Katalysator für dieses Projekt war das teilweise zufällige Verhalten unserer Cloud-Maschinen. Lassen Sie mich die Details, wer der Anbieter ist, indem ich ihren Namen in einen völlig unrelated und kryptischen Codenamen umwandle: "der Hai".

Der Hai ist gut darin, neue Cloud-Maschinen zu starten, nennen wir diese Krill. Die Leistung der Krill wird in der Dokumentation des Haifischs nicht klar angegeben, außer dass sie geteilte CPUs haben. Speziell steht nirgendwo, welche IOPS Sie von Festplatten oder RAM erwarten können, oder wie hoch der Speicher-Durchsatz ist, oder welche CPU-Familie die zugrunde liegenden Hypervisoren haben; und die Chancen stehen gut, dass Sie eine Maschine erhalten, die im unteren Leistungsspektrum angesiedelt ist.

Der Hai kümmert sich nicht wirklich darum, gleichwertige Krill zu erstellen, ihm geht es nur darum, VIELE davon zu erstellen. Und aus diesem Grund drückt er so viele Krill wie möglich auf einen einzelnen Hypervisor, bis es unmöglich wird, weitere unterzubringen, und an diesem Punkt ist die Leistungsverschlechterung, die die Benutzer sehen, offensichtlich.

Als Benutzer kümmern Sie sich jedoch nur um die Leistung und gehen davon aus, dass alles, wofür Sie bezahlen (stündlich), beim Starten immer dieselben Spezifikationen und Fähigkeiten bietet. Verständlicherweise ist dies entscheidend für Ihre Anwendung/Ihr Geschäft, und offiziell sollten Sie von dem Hai keine anderen Informationen erwarten (außer der offiziell angegebenen und dokumentierten Volatilität im Bereich der gemeinsamen CPU, wenn spezifische Arten von geteiltem Krill verwendet werden - aber das ist das einzige, was sie erwähnen).

Anwendungsfall

Die Rolle wurde erstellt, um zweiseitige Überprüfungen zu ermöglichen.

1. Zuerst möchten Sie es vor jeder tatsächlichen Bereitstellung ausführen, um sicherzustellen, dass Ihre Basislinie Ihren Annahmen entspricht, und möglicherweise Ihre Krill löschen und neu erstellen, wenn es zu weit abweicht.
2. Dann möchten Sie, dass dies nach Plan ausgeführt wird oder durch spezifische Ereignisse (wie wenn Sie einen Rückgang der Antwortzeiten Ihrer Anwendung sehen, der von anderen Tools bereitgestellt wird) ausgelöst wird, um zu überprüfen, ob die aktuellen Probleme, mit denen Sie konfrontiert sind, nicht auf eine unterdurchschnittliche Infrastruktur zurückzuführen sind. Zumindest bevor Sie den Entwicklern die Schuld für nicht optimierten Code geben. Oder naja, das können Sie wahrscheinlich trotzdem tun, denn wir glauben fest an das Meta-Game "früh veröffentlichen, optimieren, wenn gedrängt".

Niedriges Konzept

Der Plan ist, eine Reihe von Assertions über die Leistungsfähigkeiten der Maschinen zu haben, die die Bereitstellung blockieren, mit minimal zusätzlicher Software. Daher könnte das Endergebnis eher heuristisch als eine tatsächliche Ja/Nein-Antwort sein, aber es sollte als Testkanarien geeignet sein.

Testen

./bootstrap_testing.sh
source testing_env/bin/activate
read -s PASS && ANSIBLE_BECOME_PASS=$PASS molecule verify -s lxd

Es wird still, damit Sie Ihr Sudo-Passwort eingeben können. Geben Sie es ein, drücken Sie die Enter-Taste, und es wird fortgesetzt.

Nutzung

wenn aus dem Git-Repo geklont

Ergänzen Sie Ihre playbook.yml mit dieser Rolle und passen Sie die Parameter an, um die akzeptable Basisleistungsgrenze festzulegen.

- name: Überprüfung
  hosts: alle
  become: true

  roles:
    - role: ansible-server-performance-assessment
      spa_disk_write_MB_per_s_assertion: 300 [in MB/s, nach Belieben anpassen]
      spa_disk_read_MB_per_s_assertion: 300 [in MB/s, nach Belieben anpassen]
    
      # NETZWERK BENCH
      # Danke speedtest.net! Ich hätte nie gedacht, dass ich dich in der Produktion verwenden würde, aber hier sind wir.
      spa_speedtest_tmp_file: /tmp/spa_speedtest.out
      spa_downlink_assertion: 100  # Wert in Mb/s (BITS pro Sekunde)
      spa_uplink_assertion: 100  # Wert in Mb/s (BITS pro Sekunde)
        
      # SPEICHER BENCH
      spa_memory_speed_assertion: 10000  # Wert in MB/s (BYTES pro Sekunde)
        
      # CPU BENCH
      spa_cpu_event_per_second_assertion: 300  # Anzahl der Ereignisse pro Sekunde, wie von Sysbench berichtet

  tags:
    - benchmark
    - never

Das obige Beispiel wird nur ausgeführt, wenn der Parameter --tags=benchmark an Ansible übergeben wird (für eine einfachere Integration in vorhandene Playbook-Dateien).

Einschränkungen

Die Rolle funktioniert nicht besonders gut oder gar nicht auf nicht en-Locales, da einige der Benchmark-Software die Analyse mit spezifischen Phrasen in ihren Ausgaben durchführt. Das könnte mit einer zweiten Entwicklungsrunde von jemandem, der mit awks und regulären Ausdrücken besser vertraut ist als ich, verbessert werden.