Optimieren der Leistung auf Lsv3, Lasv3 und Lsv2-Serie Linux-VMs

  • Artikel

Achtung

Dieser Artikel bezieht sich auf CentOS, eine Linux-Distribution, die sich dem End-of-Life-Status (EOL) nähert. Sie sollten Ihre Nutzung entsprechend planen. Weitere Informationen finden Sie im CentOS-Leitfaden für das Lebensende.

Gilt für: ✔️ Linux-VMs ✔️ Einheitliche Skalierungsgruppen

Azure Virtual Machines (Azure VMs) der Serien Lsv3, Lasv3 und Lsv2 unterstützen verschiedene Workloads, die einen hohen E/A- und Durchsatz auf lokalem Speicher für eine Vielzahl von Anwendungen und Branchen benötigen. Die L-Serie ist ideal für Big Data, SQL, NoSQL-Datenbanken, Data Warehousing und große Transaktionsdatenbanken wie Cassandra, MongoDB, Cloudera und Redis geeignet.

Mehrere Builds sind auf dem Azure Marketplace dank der Zusammenarbeit mit Linux-Partnern verfügbar. Diese Builds sind für die Leistung der Lsv3-, Lasv3- und Lsv2-Serien optimiert. Verfügbare Builds umfassen die folgenden und späteren Versionen von:

  • Ubuntu 16.04
  • RHEL 8.0 und Klone, einschließlich CentOS, Rocky Linux und Alma Linux
  • Debian 9
  • SUSE Linux 15
  • Oracle Linux 8.0

Mit den Tipps und Vorschlägen in diesem Artikel können Sie sicherstellen, dass Ihre Workloads und Anwendungen die maximale Leistung erreichen, für die die virtuellen Computer konzipiert wurden.

Architektur des AMD EPYC™-Chipsatzes

Die VMs (virtuellen Computer) der Serien Lasv3 und Lsv2 verwenden AMD EPYC™ Server-Prozessoren, die auf der Zen-Mikroarchitektur basieren. AMD hat Infinity Fabric (IF) für EPYC™ als skalierbares Interconnect für sein NUMA-Modell entwickelt, das für On-Die-, On-Package- und Multi-Package-Kommunikation verwendet werden kann. Im Vergleich zu QPI (Quick-Path Interconnect) und UPI (Ultra-Path Interconnect), die in modernen monolithischen Intel-Prozessoren verwendet werden, kann AMDs Many-NUMA Small-Die-Architektur sowohl Leistungsvorteile als auch Herausforderungen mit sich bringen. Die tatsächlichen Auswirkungen von Speicherbandbreiten- und Wartezeitbeschränkungen können je nach Art der ausgeführten Workloads variieren.

Tipps zur Leistungsmaximierung

  • Wenn Sie ein benutzerdefiniertes Linux-Gastbetriebssystem für Ihre Workloads hochladen, ist der beschleunigte Netzwerkbetrieb standardmäßig deaktiviert. Falls Sie den beschleunigten Netzwerkbetrieb aktivieren möchten, sollten Sie diesen Schritt bei der Erstellung des virtuellen Computers ausführen, um die bestmögliche Leistung zu erzielen.
  • Um die maximale Leistung zu erzielen, führen Sie mehrere Aufträge mit tiefer Warteschlangenlänge pro Gerät aus.
  • Vermeiden Sie während aktiver Workloads eine Vermischung von NVMe-Verwaltungsbefehlen (etwa zum Abfragen von NVMe SMART-Informationen) und NVMe-E/A-Befehlen. Lsv3, Lasv3 und Lsv2-NVMe-Geräte basieren auf Hyper-V NVMe Direct-Technologie, die in den langsamen Modus wechselt, sobald NVMe-Verwaltungsbefehle ausstehen. Lsv3-, Lasv3- und Lsv2-Benutzer könnten einen drastischen Leistungsabfall bei der NVMe E/A-Leistung feststellen, wenn dies geschieht.
  • Lsv2-Benutzern wird nicht empfohlen, sich auf NUMA-Geräteinformationen (alle 0) verlassen, die im virtuellen Computer für Datenlaufwerke gemeldet werden, um die NUMA-Affinität für ihre Apps zu bestimmen. Zur Verbesserung der Leistung empfiehlt es sich, Workloads nach Möglichkeit auf CPUs aufzuteilen.
  • Die maximal unterstützte Warteschlangenlänge pro E/A-Warteschlangenpaar für Lsv3-, Lasv3- und Lsv2-VM-NVMe-Geräte beträgt 1024. Lsv3-, Lasv3- und Lsv2-Benutzern wird empfohlen, ihre (synthetischen) Benchmarking-Workloads auf eine Warteschlangenlänge von 1024 oder weniger zu beschränken, um zu vermeiden, dass Bedingungen für eine volle Warteschlange ausgelöst werden, was die Leistung verringern kann.
  • Die beste Leistung wird erzielt, wenn die E/A direkt auf jedes der rohen NVMe-Geräte erfolgt (ohne Partitionierung, Dateisysteme, RAID-Konfiguration usw.). Vergewissern Sie sich vor Beginn einer Testsitzung, dass sich die Konfiguration in einem bekannt frischen/sauberen Zustand befindet, indem Sie sie blkdiscard auf jedem der NVMe-Geräte ausführen. Um eine möglichst konstante Leistung während der Benchmarks zu erzielen, wird empfohlen, die NVMe-Geräte vor dem Test zu konditionieren, indem zwei Mal zufällige Schreibvorgänge auf alle LBAs der Geräte ausgeführt werden, wie in der Testspezifikation für SNIA Solid State Storage Enterprise Performance definiert.

Nutzen von lokalem NVMe-Speicher

Der lokale Speicher auf dem 1,92 TB NVMe-Datenträger auf allen Lsv3-, Lasv3- und Lsv2-VMs ist flüchtig. Bei einem erfolgreichen Standardneustart des VMs bleiben die Daten auf der lokalen NVMe-Platte erhalten. Die Daten bleiben nicht auf dem NVMe-Speicher erhalten, wenn die VM umverteilt oder gelöscht oder ihre Zuordnung aufgehoben wird. Die Daten bleiben nicht erhalten, wenn ein anderes Problem dazu führt, dass der VM oder die Hardware, auf der sie läuft, nicht mehr funktionsfähig ist. In diesem Fall werden sämtliche Daten auf dem alten Host sicher gelöscht.

Es gibt auch Fälle, in denen der VM auf einen anderen Host-Rechner verschoben werden muss, z.B. während einer geplanten Wartungsmaßnahme. Geplante Wartungsarbeiten und einige Hardwarefehler lassen sich mithilfe von Scheduled Events antizipieren. Verwenden Sie Scheduled Events (geplante Ereignisse), um über voraussichtliche Wartungs- und Wiederherstellungsarbeiten auf dem Laufenden zu bleiben.

Falls der VM im Rahmen eines geplanten Wartungsereignisses auf einem neuen Host mit leeren lokalen Datenträgern neu erstellt werden muss, müssen die Daten neu synchronisiert werden. (Auch hier werden sämtliche Daten auf dem alten Host sicher gelöscht). Dieses Szenario tritt auf, weil VMs der Lsv3-, Lasv3- und Lsv2-Serie derzeit keine Live-Migration auf lokalen NVMe-Datenträgern unterstützen.

Für die geplante Wartung stehen zwei Modi zur Verfügung.

Standardmäßige, kundenseitig gesteuerte VM-Wartung

  • Der virtuelle Computer wird innerhalb eines 30-tägigen Zeitfensters auf einen aktualisierten Host verschoben.
  • Lsv3-, Lasv3- und Lsv2-Lokalspeicherdaten können verloren gehen, daher wird empfohlen, die Daten vor dem Ereignis zu sichern.

Automatische Wartung

  • Tritt ein, wenn der Kunde keine kundengesteuerte Wartung durchführt oder aufgrund von Notfallmaßnahmen, wie z. B. einem Zero-Day-Sicherheitsereignis.
  • Die Beibehaltung der Kundendaten ist vorgesehen, es besteht jedoch ein geringes Risiko, dass der virtuelle Computer (VM) einfriert oder neu gestartet wird.
  • Lsv3-, Lasv3- und Lsv2-Lokalspeicherdaten können verloren gehen, daher wird empfohlen, die Daten vor dem Ereignis zu sichern.

Verwenden Sie bei anstehenden Dienstereignissen den gesteuerten Wartungsprozess, und wählen Sie einen Aktualisierungstermin aus, der für Sie am besten geeignet ist. Sichern Sie Ihre Daten vor dem Ereignis auf einem Premium-Speicher. Nach Abschluss des Wartungsereignisses können Sie Ihre Daten auf den aktualisierten lokalen NVMe-Speicher der Lsv3-, Lasv3- und Lsv2-VMs zurückspielen.

Daten bleiben unter anderem in folgenden Szenarien auf lokalen NVMe-Datenträgern erhalten:

  • Der virtuelle Computer wird ausgeführt und ist fehlerfrei.
  • Der virtuelle Computer wird von Ihnen oder von Azure direkt neu gestartet.
  • Die VM wird angehalten (ohne Aufhebung der Zuordnung beendet).
  • Die meisten der geplanten Wartungsvorgänge.

Zu den Szenarien, in denen die Daten zum Schutz des Kunden sicher gelöscht werden, zählen folgende:

  • Die VM wird erneut bereitgestellt, beendet (Aufheben der Zuordnung) oder (von Ihnen) gelöscht.
  • Der virtuelle Computer wird fehlerhaft und muss aufgrund eines Hardwareproblems zur Dienstreparatur zu einem anderen Knoten migriert werden.
  • Ein paar der geplanten Wartungsvorgänge, bei denen der virtuelle Computer für die Wartung zu einem anderen Host migriert werden muss.

Häufig gestellte Fragen

Im Folgenden finden Sie häufig gestellte Fragen zu diesen Serien.

Wie beginne ich mit der Bereitstellung von VMs der L-Serie?

Sie können ähnlich wie bei anderen virtuellen Computern das Portal, die Azure-Befehlszeilenschnittstelle oder PowerShell verwenden, um einen virtuellen Computer erstellen.

Führt der Ausfall eines einzigen NVMe-Datenträger zum Ausfall aller VMs auf dem Host?

Wenn für den Hardwareknoten ein Datenträgerfehler erkannt wird, befindet sich die Hardware in einem Fehlerzustand. Wenn dieses Problem auftritt, wird automatisch die Zuordnung aller VMs auf dem Knoten aufgehoben, und die VMs werden auf einen fehlerfreien Knoten verschoben. Für VMs der Lsv3-, Lasv3- und Lsv2-Serie bedeutet dieses Problem, dass die Daten des Kunden auf dem ausfallenden Knoten ebenfalls sicher gelöscht werden. Der Kunde muss die Daten auf dem neuen Knoten erneut erstellen.

Muss ich die Einstellungen vom Typ „blk_mq“ ändern?

RHEL/CentOS 7.x verwendet automatisch „blk_mq“ für die NVMe-Geräte. Es sind keine Konfigurations- oder Einstellungsänderungen erforderlich.

Nächste Schritte

Sehen Sie sich die Spezifikationen für alle speicheroptimierten virtuellen Computer in Azure an.