Azure Storage Premium: für hohe Leistung konzipiert
Gilt für: ✔️ Linux-VMs ✔️ Windows-VMs ✔️ Flexible Skalierungsgruppen ✔️ Einheitliche Skalierungsgruppen
Dieser Artikel bietet Leitlinien zum Erstellen leistungsstarker Anwendungen mit Azure Storage Premium. Sie können die Anweisungen in diesem Dokument kombiniert mit den bewährten Methoden für hohe Leistung befolgen, die für von Ihrer Anwendung verwendeten Technologien gelten. Um die Leitlinien zu veranschaulichen, haben wir SQL Server in Storage Premium im gesamten Dokument als Beispiel verwendet.
Während wir uns in diesem Artikel mit leistungsbezogenen Szenarien auf der Speicherebene beschäftigen, ist es Ihre Aufgabe, die Anwendungsebene zu optimieren. Wenn Sie z. B. eine SharePoint-Farm in Storage Premium hosten, können die SQL Server-Beispiele in diesem Artikel zum Optimieren des Datenbankservers verwenden. Sie können darüber hinaus den Webserver und Anwendungsserver der SharePoint-Farm optimieren, um die beste Leistung zu erzielen.
In diesem Artikel werden häufig gestellte Fragen zum Optimieren der Anwendungsleistung in Storage Premium beantwortet:
- Wie können Sie die Leistung Ihrer Anwendung messen?
- Warum erzielen Sie nicht die erwartete hohe Leistung?
- Welche Faktoren beeinflussen die Anwendungsleistung in Storage Premium?
- Wie wirken sich diese Faktoren auf die Leistung Ihrer Anwendung in Storage Premium aus?
- Wie können Sie Eingabe-/Ausgabevorgänge pro Sekunde (IOPS), Bandbreite und Latenz optimieren?
Wir stellen diese Leitlinien speziell für Storage Premium bereit, da in Storage Premium ausgeführte Workloads überaus leistungsabhängig sind. Sofern hilfreich, stellen wir Beispiele bereit. Einige dieser Leitlinien können auch für Anwendungen befolgt werden, die auf virtuellen Infrastructure-as-a-Service-Computern (IaaS-Computern) mit Storage Standard-Datenträgern ausgeführt werden.
Hinweis
Manchmal ist ein vermutetes Problem mit der Datenträgerleistung tatsächlich ein Netzwerkengpass. In solchen Fällen sollten Sie Ihre Netzwerkleistung optimieren.
Wenn Sie ihren Datenträger mit einem Benchmark vergleichen möchten, lesen Sie die folgenden Artikel:
- Linux: Benchmarktests für Ihre Anwendung in Azure Disk Storage
- Für Windows: Datenträger mit einem Benchmark vergleichen
Wenn Ihr virtueller Computer den beschleunigten Netzwerkbetrieb unterstützt, stellen Sie sicher, dass dieser aktiviert ist. Wenn er nicht aktiviert ist, können Sie ihn sowohl unter Windows als auch unter Linux auf bereits bereitgestellten virtuellen Computern aktivieren.
Falls Sie noch nicht mit Storage Premium vertraut sind, lesen Sie zunächst die Artikel Auswählen eines Azure-Datenträgertyps für virtuelle IaaS-Computer und Skalierbarkeitsziele für Seitenblobspeicher bei Premium-Konten.
Anwendungsleistungsindikatoren
Wir verwenden Leistungsindikatoren wie zum Beispiel die folgenden, um zu bewerten, ob eine Anwendung erwartungsgemäß funktioniert:
- Wie schnell eine Anwendung eine Anforderung von Benutzer*innen verarbeitet.
- Wie viele Daten eine Anwendung pro Anforderung verarbeitet.
- Anzahl der Anforderungen, die eine Anwendung in einem bestimmten Zeitraum verarbeitet.
- Wie lange Benutzer*innen warten müssen, um eine Antwort zu erhalten, nachdem sie eine Anforderung übermittelt haben.
Die technische Begriffe für diese Leistungsindikatoren sind IOPS, Durchsatz oder Bandbreite und Latenz (Wartezeit).
In diesem Abschnitt erörtern wir gängige Leistungsindikatoren im Zusammenhang mit Storage Premium. Im Abschnitt Prüfliste für die Anwendungsleistung für Datenträger erfahren Sie, wie Sie diese Leistungsindikatoren für Ihre Anwendung messen. Im Anschluss lernen Sie unter Optimieren der Anwendungsleistung die Faktoren, die sich auf diese Leistungsindikatoren auswirken, und Empfehlungen zu ihrer Optimierung kennen.
IOPS
IOPS beschreibt die Anzahl von Anforderungen, die Ihre Anwendung pro Sekunde an Speicherdatenträger sendet. Ein E/A-Vorgang kann ein sequenzieller oder zufälliger Lese- oder Schreibvorgang sein. OLTP-Anwendungen (Online Transaction Processing, Onlinetransaktionsverarbeitung) wie die Website eines Onlinehändlers müssen viele gleichzeitige Anforderungen von Benutzer*innen sofort verarbeiten. Die Anforderungen von Benutzer*innen sind einfüge- und aktualisierungsintensive Datenbanktransaktionen, die die Anwendung rasch verarbeiten muss. Aus diesem Grund benötigen OLTP-Anwendungen eine sehr hohe IOPS-Leistung.
OLTP-Anwendungen verarbeiten Millionen kleiner und zufälliger E/A-Anforderungen. Wenn Sie eine solche Anwendung haben, müssen Sie die Anwendungsinfrastruktur für die IOPS-Optimierung entwerfen. Weitere Informationen zu allen Faktoren, die sie berücksichtigen sollten, um eine hohe IOPS-Leistung zu erzielen, finden Sie unter Optimieren der Anwendungsleistung.
Wenn Sie einen Storage Premium-Datenträger an Ihre Hochleistungs-VM anfügen, stellt Ihnen Azure gemäß der Datenträgerspezifikation eine garantierte IOPS-Anzahl bereit. Beispielsweise stellt ein Datenträger vom Typ „P50“ 7.500 IOPS bereit. Jeder Typ von Hochleistungs-VM weist außerdem ein bestimmtes IOPS-Limit auf. Für eine VM vom Typ Standard GS5 gilt beispielsweise ein Limit von 80.000 IOPS.
Throughput
Durchsatz oder Bandbreite ist die Menge der Daten, die Ihre Anwendung in einem angegebenen Intervall an die Speicherdatenträger überträgt. Wenn Ihre Anwendung E/A-Vorgänge mit hohen E/A-Einheitsgrößen durchführt, benötigt sie hohen Durchsatz. Data Warehouse-Anwendungen führen meist suchintensive Vorgänge, bei denen jeweils auf große Datenmengen zugegriffen wird, und üblicherweise Massenvorgänge durch. Aus diesem Grund erfordern solche Anwendungen einen höheren Durchsatz. Wenn Sie eine solche Anwendung haben, müssen Sie die Anwendungsinfrastruktur für eine Durchsatzoptimierung entwerfen. Im nächsten Abschnitt geht es um die Faktoren, die Sie einstellen müssen, um die Optimierung zu erreichen.
Wenn Sie einen Storage Premium-Datenträger an eine Hochleistungs-VM anfügen, bietet Azure Durchsatz gemäß der Spezifikation dieses Datenträgers. Ein P50-Datenträger stellt z. B. einen Datenträgerdurchsatz von 250 MB pro Sekunde bereit. Jeder Typ von Hochleistungs-VM weist außerdem ein bestimmtes Durchsatzlimit auf. Eine Standard-VM vom Typ GS5 bietet beispielsweise einen maximalen Durchsatz von 2.000 MB pro Sekunde.
Zwischen Durchsatz und IOPS gibt es, wie in der folgenden Formel dargestellt, einen Zusammenhang.
Aus diesem Grund ist es wichtig, die optimalen Durchsatz- und IOPS-Werte zu bestimmen, die Ihre Anwendung benötigt. Beim Versuch, einen der Faktoren zu optimieren, ist der andere ebenfalls betroffen. Weitere Details zum Optimieren von IOPS und Durchsatz finden Sie unter Optimieren der Anwendungsleistung.
Latency
Latenz (Wartezeit) ist die Zeit, die eine Anwendung zum Empfangen einer einzelnen Anforderung, deren Übertragung an die Speicherdatenträger und zum Zurücksenden der Antwort an den Client benötigt. Neben IOPS und Durchsatz ist die Wartezeit ein weiterer wichtiger Messwert für die Leistung einer Anwendung. Die Wartezeit eines Storage Premium-Datenträgers ist die benötigte Zeit zum Abrufen der Informationen für eine Anforderung und deren Übermittlung zurück an die Anwendung. Storage Premium bietet durchgängig eine niedrige Wartezeit. Premium-Datenträger bieten für die meisten E/A-Vorgänge Wartezeiten im einstelligen Millisekundenbereich. Wenn Sie die Hostcache-Einstellung ReadOnly für Storage Premium-Datenträger aktivieren, erhalten Sie bei Lesevorgängen eine wesentlich niedrigere Wartezeit. Weitere Informationen zum Zwischenspeichern auf Datenträgern finden Sie unter Zwischenspeichern auf Datenträgern.
Wenn Sie Ihre Anwendung optimieren, um höhere IOPS- und Durchsatzwerte zu erzielen, wirkt sich dies auf die Wartezeit der Anwendung aus. Prüfen Sie nach einer Optimierung der Anwendungsleistung stets die Wartezeit, um unerwartet hohe Wartezeiten zu vermeiden.
Die folgenden Vorgänge auf Steuerungsebene auf verwalteten Datenträgern können das Verschieben des Datenträgers von einem Speicherort zu einem anderen beinhalten. Diese Bewegung wird über die Hintergrundkopie der Daten orchestriert, was mehrere Stunden dauern kann. In der Regel beträgt die Zeit weniger als 24 Stunden, abhängig von der Datenmenge auf den Datenträgern. Während dieser Zeit können bei Ihrer Anwendung höhere Wartezeiten bei Lesevorgängen als üblich auftreten, da einige Lesevorgänge an den ursprünglichen Speicherort umgeleitet werden können, sodass es länger dauert, sie abzuschließen.
Die Wartezeit beim Schreiben ist während dieses Zeitraums nicht betroffen. Bei SSD Premium v2- und Ultra-Datenträgern kommt es zu einer höheren Wartezeit bei Lesevorgängen, wenn der Datenträger eine Sektorgröße von 4K aufweist. Wenn der Datenträger eine Sektorgröße von 512e aufweist, gibt es sowohl eine höhere Wartezeit bei Lese- als auch bei Schreibvorgängen.
Vorgänge auf der Steuerungsebene werden für Folgendes verwendet:
- Aktualisieren des Speichertyps
- Trennen eines Datenträgers von einer VM und Anfügen an eine andere
- Erstellen eines verwalteten Datenträgers aus einer VHD
- Erstellen eines verwalteten Datenträgers aus einer Momentaufnahme
- Konvertieren von nicht verwalteten Datenträgern in verwaltete Datenträger
Prüfliste für die Anwendungsleistung für Datenträger
Der erste Schritt beim Entwerfen hochleistungsfähiger Anwendungen in Storage Premium besteht darin, sich mit den Leistungsanforderungen der Anwendung vertraut zu machen. Nach dem Erfassen von Anforderungen können Sie Ihre Anwendung optimieren, um eine optimale Leistung zu erzielen.
Im vorherigen Abschnitt wurden mit IOPS, Durchsatz und Wartezeit die gängigsten Leistungsindikatoren vorgestellt. Sie müssen bestimmen, welche dieser Leistungsindikatoren für Ihre Anwendung wichtig sind, um Benutzern die gewünschte Funktionalität zu bieten. Eine hohe IOPS-Leistung spielt z. B. bei OLTP-Anwendungen, die Millionen von Transaktionen pro Sekunde verarbeiten, die größte Rolle. Ein hoher Durchsatz ist für Data Warehouse-Anwendungen von Bedeutung, die pro Sekunde große Datenmengen verarbeiten. Eine überaus niedrige Wartezeit ist entscheidend für Echtzeitanwendungen wie Websites für das Livestreaming von Video.
Messen Sie als Nächstes die maximalen Leistungsanforderungen der Anwendung während ihrer Lebensdauer. Verwenden Sie die folgende Beispielprüfliste als Anfang. Zeichnen Sie die maximalen Leistungsanforderungen von Workloads während des Normalbetriebs, zu Spitzenzeiten und außerhalb der Geschäftszeiten auf. Indem Sie Anforderungen für alle Workloadstufen bestimmen, können Sie die Gesamtleistungsanforderungen Ihrer Anwendung feststellen.
Der normale Workload einer E-Commerce-Website besteht beispielsweise aus den Transaktionen, die während der meisten Tage eines Jahres verarbeitet werden. Den Spitzenworkload der Website bilden die Transaktionen, die in der Vorweihnachtszeit oder bei Sonderverkaufsaktionen verarbeitet werden. Der Spitzenworkload fällt meist nur in einem begrenzten Zeitraum an, kann allerdings erfordern, dass Ihre Anwendung im Vergleich zum Normalbetrieb um das Zwei- bis Dreifache skaliert werden muss. Finden Sie die Anforderungen für das 50. Perzentil, das 90. Perzentil und 99. Perzentil heraus. Anhand dieser Informationen können Sie Ausreißer in den Leistungsanforderungen herausfiltern und sich auf die Maßnahmen für eine Optimierung entsprechend den richtigen Werten konzentrieren.
Prüfliste für Anforderungen an die Anwendungsleistung
| Leistungsanforderungen | 50-%-Perzentil | 90-%-Perzentil | 99-%-Perzentil |
|---|---|---|---|
| Transaktionen pro Sekunde maximal | |||
| % Lesevorgänge | |||
| % Schreibvorgänge | |||
| % zufällige Vorgänge | |||
| % sequenzielle Vorgänge | |||
| E/A-Anforderungsgröße | |||
| Durchschnittlicher Durchsatz | |||
| Maximaler Durchsatz | |||
| Minimale Latenz | |||
| Durchschnittliche Latenz | |||
| Maximale CPU-Nutzung | |||
| Durchschnittliche CPU-Nutzung | |||
| Arbeitsspeichermaximum | |||
| Durchschnittliche Arbeitsspeichernutzung | |||
| Warteschlangenlänge |
Hinweis
Ziehen Sie in Betracht, diese Zahlen basierend auf dem erwarteten zukünftigen Wachstum Ihrer Anwendung zu skalieren. Es ist stets eine gute Idee, für Wachstum im Voraus zu planen, da es schwieriger sein könnte, die Infrastruktur zur Verbesserung der Leistung später zu ändern.
Wenn Sie eine vorhandene Anwendung haben, die in Storage Premium verschoben werden soll, erstellen Sie für diese Anwendung zunächst die obige Prüfliste. Erstellen Sie anschließend einen Prototyp der Anwendung in Storage Premium, und entwerfen Sie die Anwendung basierend auf den Leitlinien unter Optimieren der Anwendungsleistung. Im nächsten Artikel werden die Tools beschrieben, die Sie verwenden können, um die Leistungsindikatoren zu erfassen.
Indikatoren zum Messen der Leistungsanforderungen der Anwendung
Die beste Methode zum Messen der Leistungsanforderungen Ihrer Anwendung ist die Verwendung von PerfMonÜberwachungstools, die vom Betriebssystem des Servers bereitgestellt werden. Sie können PerfMon für Windows und iostat für Linux verwenden. Diese Tools erfassen Zähler für jede im vorstehenden Abschnitt erläuterte Messgröße. Sie müssen die Werte dieser Zähler erfassen, wenn in der Anwendung Workloads im Normalbetrieb, zu Spitzenzeiten und außerhalb der Geschäftszeiten ausgeführt werden.
Die PerfMon-Zähler sind für Prozessor, Arbeitsspeicher und alle logischen und physischen Datenträger Ihres Servers verfügbar. Bei Verwenden von Storage Premium-Datenträgern mit einem virtuellen Computer gelten die Indikatoren für physische Datenträger für jeden Storage Premium-Datenträger. Die Indikatoren für logische Datenträger gelten für jedes Volume, das auf den Storage Premium-Datenträgern erstellt wurde. Sie müssen die Werte für die Datenträger erfassen, die den Workload Ihrer Anwendung hosten. Wenn es eine 1:1-Zuordnung zwischen logischen und physischen Datenträgern gibt, können Sie sich auf die Leistungsindikatoren für physische Datenträger beziehen. Beziehen Sie sich andernfalls auf die logischen Datenträgerzähler.
Unter Linux erzeugt der Befehl iostat einen Bericht der CPU- und Festplattenauslastung. Der Bericht zur Datenträgerauslastung bietet Statistiken pro physischem Gerät bzw. pro Partition. Wenn Sie einen Datenbankserver mit Daten- und Protokolldateien auf getrennten Datenträgern nutzen, erfassen Sie diese Daten für beide Datenträger. In der folgenden Tabelle werden die Leistungsindikatoren für Datenträger, Prozessoren und Arbeitsspeicher beschrieben:
| Leistungsindikator | BESCHREIBUNG | Systemmonitor | iostat |
|---|---|---|---|
| IOPS oder Transaktionen pro Sekunde | Anzahl der an den Speicherdatenträger pro Sekunde erfolgten E/A-Anforderungen | Datenträgerlesevorgänge pro Sekunde Datenträger-Schreibvorgänge pro Sekunde |
tps r/s w/s |
| Datenträgerlese- und -schreibvorgänge | % der auf dem Datenträger ausgeführten Lese- und Schreibvorgänge | % Datenträgerlesezeit % Datenträgerschreibzeit |
r/s w/s |
| Throughput | Menge der Daten, die pro Sekunde auf dem Datenträger gelesen oder geschrieben wird | Vom Datenträger gelesene Bytes/Sek. Auf Datenträger geschriebene Bytes/Sek. |
kB_read/s kB_wrtn/s |
| Latency | Gesamtzeit für das Ausführen einer E/A-Anforderung an den Datenträger | Mittlere Sek./Datenträgerlesevorgang Mittlere Sek./Datenträgerschreibvorgang |
await svctm |
| E/A-Größe | Größe der an die Speicherdatenträger gesendeten E/A-Anforderungen | Mittlere Datenträgerbytes/Lesevorgang Mittlere Datenträgerbytes/Schreibvorgang |
avgrq-sz |
| Warteschlangenlänge | Anzahl der ausstehenden E/A-Anforderungen, die vom Speicherdatenträger gelesen oder auf diesen geschrieben werden sollen. | Aktuelle Datenträger-Warteschlangenlänge | avgqu-sz |
| Arbeitsspeichermaximum | Für die reibungslose Ausführung der Anwendung erforderlicher Arbeitsspeicher | Committete verwendete Bytes (%) | vmstat verwenden |
| Maximale CPU-Nutzung | Für die reibungslose Ausführung der Anwendung erforderliche CPU | % Prozessorzeit | %util |
Weitere Informationen zu iostat und PerfMon (Systemmonitor)
Optimieren der Anwendungsleistung
Die wichtigsten Faktoren für die Leistung einer Anwendung, die in Storage Premium ausgeführt wird, sind die Art der E/A-Anforderungen, VM-Größe, Datenträgergröße, Anzahl der Datenträger, die Datenträgerzwischenspeicherung, Multithreading und Warteschlangenlänge. Sie können einige dieser Faktoren mithilfe vom System bereitgestellter Einstellungsmöglichkeiten steuern.
Die meisten Anwendungen bieten möglicherweise keine Option, die E/A-Größe und Warteschlangenlänge direkt zu ändern. In SQL Server können Sie z. B. die E/A-Größe und Warteschlangenlänge nicht festlegen. SQL Server wählt optimale Einstellungen für E/A-Größe und Warteschlangenlänge, um die beste Leistung zu erzielen. Es ist wichtig, die Auswirkungen beider Arten von Faktoren auf die Leistung Ihrer Anwendung zu verstehen, damit Sie entsprechende Ressourcen zum Erfüllen der Leistungsanforderungen bereitstellen können.
Nehmen Sie in diesem gesamten Abschnitt Bezug auf die von Ihnen erstellte Prüfliste mit den Anwendungsanforderungen, um zu bestimmen, was für die Optimierung der Leistung Ihrer Anwendung erforderlich ist. Anhand dieser Checkliste können Sie bestimmen, welche Faktoren in diesem Abschnitt Sie optimieren müssen.
Führen Sie zum Überprüfen der Auswirkungen der einzelnen Faktoren auf die Anwendungsleistung Benchmarktools aus. Eine schrittweise Anleitung zum Ausführen gängiger Benchmarktools für Windows- und Linux-VMs finden Sie in den Artikeln zum Anwenden von Benchmarks am Ende dieses Dokuments.
Optimierung von IOPS, Durchsatz und Latenz auf einen Blick
In der folgenden Tabelle sind die Leistungsfaktoren und die erforderlichen Schritte zum Optimieren von IOPS, Durchsatz und Wartezeit aufgeführt. In den Abschnitten, die auf diese Zusammenfassung folgen, werden die einzelnen Faktoren ausführlicher beschrieben.
Weitere Informationen zu VM-Größen und zu den für die einzelnen VM-Typen verfügbaren IOPS, Durchsätzen und Latenzen finden Sie unter Größen für virtuelle Computer in Azure.
| Leistungsfaktoren | IOPS | Throughput | Latency |
|---|---|---|---|
| Beispielszenario | OLTP-Anwendung eines Großunternehmens, die eine sehr hohe Rate von Transaktionen pro Sekunde benötigt. | Data Warehouse-Anwendung eines Großunternehmens, die große Datenmengen verarbeitet. | Nahezu in Echtzeit arbeitende Anwendungen, die Antworten auf Benutzeranforderungen sofort benötigen, wie z. B. Onlinespiele. |
| Leistungsfaktoren | |||
| E/A-Größe | Kleinere E/A-Größe führt zu mehr IOPS. | Höhere E/A-Größe führt zu höherem Durchsatz. | |
| Größe des virtuellen Computers | Wählen Sie eine VM-Größe, deren IOPS die Anforderung Ihrer Anwendung übersteigt. | Wählen Sie eine VM-Größe aus, deren Durchsatzlimit die Anforderung Ihrer Anwendung übersteigt. | Wählen Sie eine VM-Größe, deren Skalierungslimits die Anforderung Ihrer Anwendung übersteigen. |
| Datenträgergröße | Wählen Sie eine Datenträgergröße, deren IOPS die Anforderung Ihrer Anwendung übersteigt. | Wählen Sie eine Datenträgergröße, deren Durchsatzlimit die Anforderung Ihrer Anwendung übersteigt. | Wählen Sie eine Datenträgergröße, deren Skalierungslimits die Anforderung Ihrer Anwendung übersteigen. |
| Skalierungslimits für virtuelle Computer und Datenträger | Das IOPS-Limit der gewählten VM-Größe muss größer als die IOPS-Gesamtkapazität von Speicherdatenträgern sein, die daran angefügt sind. | Das Durchsatzlimit der gewählten VM-Größe muss größer als der Gesamtdurchsatz von Storage Premium-Datenträgern sein, die daran angefügt sind. | Die Skalierungslimits der gewählten VM-Größe müssen größer als die Gesamtskalierungslimits von Storage Premium-Datenträgern sein, die daran angefügt sind. |
| Datenträgercaching | Aktivieren Sie den ReadOnly-Cache auf Storage Premium-Datenträgern mit hohem Aufkommen von Lesevorgängen, um eine höhere IOPS-Leseleistung zu erhalten. | Aktivieren Sie den ReadOnly-Cache auf Premium-Speicherdatenträgern mit leseintensiven Vorgängen, um sehr niedrige Wartezeiten bei Lesevorgängen zu erhalten. | |
| Datenträgerstriping | Verwenden Sie mehrere Datenträger, und verbinden Sie sie per Striping, um durch die Kombination ein höheres IOPS- und Durchsatzlimit zu erreichen. Das kombinierte Limit pro VM muss höher als die kombinierten Limits angefügter Premium-Datenträger sein. | ||
| Stripegröße | Kleinere Stripegröße für zufällige kleine E/A-Muster in OLTP-Anwendungen. Wählen Sie beispielsweise für eine OLTP-Anwendung mit SQL Server eine Stripegröße von 64 KB. | Höhere Stripegröße für sequenzielle, große E/A-Muster in Data Warehouse-Anwendungen. Wählen Sie beispielsweise für Data Warehouse-Anwendungen mit SQL Server die Stripegröße 256 KB. | |
| Multithreading | Verwenden Sie Multithreading, um eine höhere Anzahl von Anforderungen in Storage Premium zu übertragen, was eine höhere IOPS- und Durchsatzrate zur Folge hat. Legen Sie z. B. für SQL Server einen hohen MAXDOP-Wert fest damit SQL Server mehr CPUs zugeordnet werden. | ||
| Warteschlangenlänge | Höhere Warteschlangenlänge führt zu mehr IOPS. | Höhere Warteschlangenlänge führt zu höherem Durchsatz. | Niedrigere Warteschlangenlänge führt zu niedrigeren Wartezeiten. |
Art der E/A-Anforderungen
Eine E/A-Anforderung ist eine E/A-Vorgangseinheit, die Ihre Anwendung ausführt. Das Bestimmen der Art der E/A-Anforderungen – zufällig oder sequenziell, Lese- oder Schreibvorgang, klein oder groß – hilft beim Ermitteln der Leistungsanforderungen Ihrer Anwendung. Sie müssen sich mit der Art der E/A-Anforderungen vertraut machen, um beim Entwurf der Anwendungsinfrastruktur die richtigen Entscheidungen zu treffen. E/A-Vorgänge müssen gleichmäßig verteilt sein, um die bestmögliche Leistung zu erzielen.
Die E/A-Größe ist einer der wichtigsten Faktoren. Die E/A-Größe ist die Größe des angeforderten E/A-Vorgangs, den Ihre Anwendung generiert hat. Die E/A-Größe wirkt sich erheblich auf die Leistung aus, insbesondere in Bezug auf IOPS und Bandbreite, die die Anwendung erreichen kann. Die folgende Formel zeigt die Beziehung zwischen IOPS, E/A-Größe und Bandbreite/Durchsatz.
Einige Anwendungen ermöglichen Ihnen das Ändern der E/A-Größe, andere hingegen nicht. Beispielsweise bestimmt SQL Server selbst die optimale E/A-Größe und bietet Benutzer*innen keine Möglichkeiten, sie zu ändern. Oracle bietet dagegen den Parameter DB_BLOCK_SIZE, mit dem Sie die E/A-Anforderungsgröße der Datenbank konfigurieren können.
Wenn Sie eine Anwendung verwenden, die das Ändern der E/A-Größe nicht ermöglicht, befolgen Sie die Leitlinien in diesem Artikel, um die Leistungsindikatoren zu optimieren, die für Ihre Anwendung am relevantesten sind. Beispiel:
- Eine OLTP-Anwendung generiert Millionen kleiner und zufälliger E/A-Anforderungen. Zum Verarbeiten dieser Art von E/A-Anforderungen müssen Sie die Anwendungsinfrastruktur für das Erzielen von mehr IOPS entwerfen.
- Eine Data Warehouse-Anwendung generiert große und sequenzielle E/A-Anforderungen. Zum Verarbeiten dieser Typen von E/A-Anforderungen müssen Sie die Anwendungsinfrastruktur für das Erzielen von mehr Bandbreite bzw. Durchsatz entwerfen.
Wenn Sie eine Anwendung verwenden, die das Ändern der E/A-Größe ermöglicht, sollten Sie neben den anderen Leitlinien für die Leistung diese Faustregel für die E/A-Größe befolgen.
- Kleinere E/A-Größe führt zu mehr IOPS. Beispiel: 8 KB für eine OLTP-Anwendung.
- Höhere E/A-Größe führt zu mehr Bandbreite/Durchsatz. Beispiel: 1.024 KB für eine Data Warehouse-Anwendung.
Es folgt ein Beispiel, wie Sie IOPS bzw. Durchsatz/Bandbreite für Ihre Anwendung berechnen können.
Angenommen, eine Anwendung verwendet einen P30-Datenträger. Die maximale IOPS- bzw. Durchsatz-/Bandbreitenrate eines P30-Datenträgers ist 5.000 IOPS bzw. 200 MB pro Sekunde. Wenn Ihre Anwendung die maximale IOPS-Größe vom P30-Datenträger erfordert und Sie eine kleinere E/A-Größe verwenden, z. B. 8 KB, beträgt die resultierende Bandbreite, die Sie erhalten können, 40 MB/s. Wenn Ihre Anwendung den maximalen Durchsatz/die maximale Bandbreite von einem P30-Datenträger erfordert und Sie eine größere E/A-Größe wie 1.024 KB verwenden, ist die resultierende IOPS kleiner, z. B. 200 IOPS.
Optimieren Sie die E/A-Größe so, dass Ihre Anwendung die Anforderungen sowohl an IOPS als auch an Durchsatz/Bandbreite erfüllt. In der folgenden Tabelle sind die verschiedenen E/A-Größen und ihre entsprechenden IOPS- und Durchsatzraten für einen P30-Datenträger zusammengefasst.
| Anwendungsanforderung | E/A-Größe | IOPS | Durchsatz/Bandbreite |
|---|---|---|---|
| Maximale IOPS-Anzahl | 8 KB | 5\.000 | 40 MB/Sek. |
| Maximaler Durchsatz | 1.024 KB | 200 | 200 MB/s |
| Max. Durchsatz + hohe IOPS-Rate | 64 KB | 3\.200 | 200 MB/s |
| Max. IOPS + hoher Durchsatz | 32 KB | 5\.000 | 160 MB/s |
Um eine IOPS-Rate und Bandbreite zu erzielen, die höher als der Maximalwert eines einzelnen Storage Premium-Datenträgers ist, verwenden Sie mehrere Premium-Datenträger in einem Stripeset. Entfernen Sie beispielsweise zwei P30-Datenträger, um eine kombinierte IOPS von 10.000 IOPS oder einen kombinierten Durchsatz von 400 MB/s zu erhalten. Wie im nächsten Abschnitt erläutert, müssen Sie eine VM-Größe verwenden, die IOPS und Durchsatz der kombinierten Datenträger unterstützt.
Hinweis
Wenn Sie entweder IOPS oder Durchsatz erhöhen, erhöht sich auch der andere Wert. Stellen Sie sicher, dass Sie die Durchsatz- oder IOPS-Grenzwerte des Datenträgers oder der VM nicht erreicht haben, wenn Sie einen der beiden erhöhen.
Führen Sie zum Überprüfen der Auswirkungen der E/A-Größe auf die Anwendungsleistung in Ihrer VM und auf Ihren Datenträgern Benchmarktools aus. Erstellen Sie mehrere Testläufe, und wählen Sie für jeden Lauf eine andere E/A-Größe, um die Auswirkungen zu prüfen. Weitere Informationen finden Sie in den Artikeln zum Anwenden von Benchmarks am Ende dieses Dokuments.
Größen von Hochleistungs-VMs
Beim Entwerfen einer Anwendung ist eine der ersten Aufgaben das Wählen einer VM zum Hosten Ihrer Anwendung. Storage Premium bietet verschiedene Größen von Hochleistungs-VMs zum Ausführen von Anwendungen, die eine höhere Rechenleistung und einen lokalen Datenträger mit hoher E/A-Leistung benötigen. Diese VMs bieten schnellere Prozessoren, ein höheres Arbeitsspeicher/Kern-Verhältnis und ein SSD-Laufwerk (Solid State Drive) als lokalen Datenträger. Beispiele für Hochleistungs-VMs, die Storage Premium unterstützen, sind die VMs der DS- und GS-Serie.
Hochleistungs-VMs stehen in mehreren Größen mit jeweils einer anderen Anzahl von CPU-Kernen, Arbeitsspeicher- und temporären Datenträgergröße und einem anderen Betriebssystem zur Verfügung. Jede VM-Größe weist außerdem eine maximale Anzahl von Datenträgern auf, die Sie an die VM anfügen können. Daher beeinflusst die gewählte VM-Größe die Verarbeitungs-, Arbeitsspeicher- und Speicherkapazität, die für Ihre Anwendung zur Verfügung steht. Sie hat außerdem Einfluss auf die Compute- und Speicherkosten. Nachstehend sind beispielsweise die Spezifikationen der maximalen VM-Größen in der DS- und GS-Serie aufgeführt.
| Größe des virtuellen Computers | CPU-Kerne | Arbeitsspeicher | VM-Datenträgergrößen | Maximale Anzahl von Datenträgern | Cachegröße | IOPS | Limits für Bandbreite, Cache und E/A |
|---|---|---|---|---|---|---|---|
| Standard_DS14 | 16 | 112 GB | Betriebssystem = 1.023 GB Lokales SSD = 224 GB |
32 | 576 GB | 50.000 IOPS 512 MB/s |
4.000 IOPS und 33 MB/s |
| Standard_GS5 | 32 | 448 GB | Betriebssystem = 1.023 GB Lokales SSD = 896 GB |
64 | 4\.224 GB | 80.000 IOPS 2.000 MB/s |
5.000 IOPS und 50 MB/s |
Eine vollständige Übersicht mit allen verfügbaren Azure-VM-Größen finden Sie unter Größen für virtuelle Computer in Azure. Wählen Sie eine VM-Größe, die Ihre Anforderungen an die Anwendungsleistung erfüllen und entsprechend skaliert werden kann. Berücksichtigen Sie darüber hinaus folgende wichtige Aspekte bei der Wahl der VM-Größe.
Skalierungslimits
Die maximalen IOPS-Limits pro VM und Datenträger sind unterschiedlich und voneinander unabhängig. Stellen Sie sicher, dass die Anwendung die IOPS innerhalb der Limits der VM sowie der angefügten Storage Premium-Datenträger unterstützt. Andernfalls wird die Anwendungsleistung gedrosselt.
Beispiel: Angenommen, eine Anwendungsanforderung ist ein IOPS-Wert von maximal 4.000. Um diese Stufe zu erreichen, stellen Sie einen P30-Datenträger in einer VM der DS1-Serie bereit. Der P30-Datenträger kann bis zu 5.000 IOPS bieten. Die VM der DS1-Serie ist jedoch auf 3.200 IOPS beschränkt. Daher wird die Anwendungsleistung gemäß dem VM-Limit auf 3.200 IOPS verringert und die Leistung wird beeinträchtigt. Um dies zu vermeiden, wählen Sie eine VM- und eine Datenträgergröße, die beide die Anwendungsanforderungen erfüllen.
Betriebskosten
In vielen Fällen ist es möglich, dass die Gesamtbetriebskosten bei der Verwendung von Storage Premium niedriger als bei der Verwendung von Storage Standard sind.
Nehmen wir als Beispiel eine Anwendung, die 16.000 IOPS benötigt. Um diese Leistung zu erzielen, benötigen Sie eine Azure-IaaS-VM vom Typ „Standard_D14“, die bei Verwenden von 32 Standardspeicher-Datenträgern mit je 1 TB eine maximale IOPS-Rate von 16.000 bietet. Jeder Storage Standard-Datenträger mit 1 TB kann maximal 500 IOPS erzielen.
- Die geschätzten Kosten für diese VM pro Monat liegen bei 1.570 $.
- Die monatlichen Kosten der 32 Storage Standard-Datenträger betragen 1.638 $.
- Die geschätzten monatlichen Gesamtkosten betragen 3.208 $.
Wenn Sie dieselbe Anwendung in Storage Premium hosten, benötigen Sie eine kleinere VM-Größe und weniger Storage Premium-Datenträger, wodurch die Gesamtkosten gesenkt werden. Eine VM vom Typ „Standard_DS13“ kann mithilfe von vier P30-Datenträgern die Anforderung von 16.000 IOPS erfüllen. Die VM vom Typ DS13 bietet maximal 25.600 IOPS, und jeder P30-Datenträger bietet maximal 5.000 IOPS. Diese Konfiguration kann insgesamt 5.000 x 4 = 20.000 IOPS bieten.
- Die geschätzten Kosten für diese VM pro Monat liegen bei 1.003 $.
- Die monatlichen Kosten der vier Storage Premium-Datenträger vom Typ P30 belaufen sich auf 544,34 $.
- Die geschätzten monatlichen Gesamtkosten betragen 1.544 $.
In der folgenden Tabelle wird die Aufschlüsselung der Kosten für Storage Standard und Storage Premium zusammengefasst.
| Monatliche Kosten | Standard | Premium |
|---|---|---|
| VM-Kosten pro Monat | 1.570,58 $ (Standard_D14) | 1.003,66 $ (Standard_DS13) |
| Datenträgerkosten pro Monat | 1\.638,40 $ (32 1-TB-Festplatten) | 544,34 $ (4 P30-Datenträger) |
| Gesamtkosten pro Monat | 3\.208,98 $ | 1\.544,34 $ |
Linux-Distributionen
Mit Storage Premium erhalten Sie unter Windows und Linux das gleiche Maß an Leistung für virtuelle Computer. Wir unterstützen viele Arten von Linux-Distributionen. Weitere Informationen finden Sie unter Von Azure unterstützte Linux-Distributionen.
Verschiedene Distributionen sind für verschiedene Arten von Workloads besser geeignet. Je nach Distribution, in der Ihr Workload ausgeführt wird, sind die Leistungsgrade unterschiedlich. Testen Sie die Linux-Distributionen mit Ihrer Anwendung, und wählen Sie diejenige, die am besten geeignet ist.
Überprüfen Sie bei Ausführen von Linux mit Storage Premium die neuesten Updates hinsichtlich erforderlicher Treiber, um eine hohe Leistung zu gewährleisten.
Größen von Storage Premium-Datenträgern
Storage Premium bietet verschiedene Größen, sodass Sie eine wählen können, die Ihren Anforderungen am besten entspricht. Jede Datenträgergröße hat ein anderes Skalierungslimit hinsichtlich IOPS, Bandbreite und Speicher. Wählen Sie abhängig von den Anwendungsanforderungen und der Größe der Hochleistungs-VM die richtige Storage Premium-Datenträgergröße. Die folgende Tabelle zeigt die verschiedenen Datenträgergrößen und ihre Kapazitäten. Die Datenträgergrößen P4, P6, P15, P60, P70 und P80 werden aktuell nur für verwaltete Datenträger unterstützt.
| SSD Premium-Größen | P1 | P2 | P3 | P4 | P6 | P10 | P15 | P20 | P30 | P40 | P50 | P60 | P70 | P80 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Datenträgergröße in GiB | 4 | 8 | 16 | 32 | 64 | 128 Bits | 256 KB | 512 | 1\.024 | 2\.048 | 4\.096 | 8\.192 | 16.384 | 32.767 |
| Bereitgestellte Basis-IOPS pro Datenträger | 120 | 120 | 120 | 120 | 240 | 500 | 1\.100 | 2\.300 | 5\.000 | 7\.500 | 7\.500 | 16.000 | 18.000 | 20.000 |
| **Erweiterte bereitgestellte IOPS pro Datenträger | – | – | – | – | – | – | – | – | 8\.000 | 16.000 | 20.000 | 20.000 | 20.000 | 20.000 |
| Bereitgestellter Basisdurchsatz pro Datenträger | 25 MB/s | 25 MB/s | 25 MB/s | 25 MB/s | 50 MB/s | 100 MB/s | 125 MB/s | 150 MB/s | 200 MB/s | 250 MB/s | 250 MB/s | 500 MB/s | 750 MB/s | 900 MB/s |
| **Bereitgestellter erweiterter Durchsatz pro Datenträger | – | – | – | – | – | – | – | – | 300 MB/s | 600 MB/s | 900 MB/s | 900 MB/s | 900 MB/s | 900 MB/s |
| Max. Burst-IOPS pro Datenträger | 3\.500 | 3\.500 | 3\.500 | 3\.500 | 3\.500 | 3\.500 | 3\.500 | 3\.500 | 30.000* | 30.000* | 30.000* | 30.000* | 30.000* | 30.000* |
| Max. Burstdurchsatz pro Datenträger | 170 MB/s | 170 MB/s | 170 MB/s | 170 MB/s | 170 MB/s | 170 MB/s | 170 MB/s | 170 MB/s | 1.000 MB/s* | 1.000 MB/s* | 1.000 MB/s* | 1.000 MB/s* | 1.000 MB/s* | 1.000 MB/s* |
| Max. Burstdauer | 30 Min. | 30 Min. | 30 Min. | 30 Min. | 30 Min. | 30 Min. | 30 Min. | 30 Min. | Unbegrenzt* | Unbegrenzt* | Unbegrenzt* | Unbegrenzt* | Unbegrenzt* | Unbegrenzt* |
| Qualifiziert für Reservierung | Nein | Keine | Keine | Keine | Keine | Keine | Keine | Nein | Ja, bis zu einem Jahr | Ja, bis zu einem Jahr | Ja, bis zu einem Jahr | Ja, bis zu einem Jahr | Ja, bis zu einem Jahr | Ja, bis zu einem Jahr |
*Gilt nur für Festplatten mit aktiviertem On-Demand-Bursting.
** Gilt nur für Datenträger bei denen Leistung plus (Vorschauversion) aktiviert ist.
Die zu wählende Anzahl von Datenträgern hängt von der gewählten Datenträgergröße ab. Zum Erfüllen Ihrer Anwendungsanforderung können Sie entweder einen einzelnen P50- oder mehrere P10-Datenträger verwenden. Berücksichtigen Sie bei Ihrer Wahl die nachstehenden Aspekte.
Skalierungslimits (IOPS und Durchsatz)
Die IOPS- und Durchsatzlimits der einzelnen Premium-Datenträgergrößen sind unterschiedlich und unabhängig von den VM-Skalierungslimits. Vergewissern Sie sich, dass die gesamten IOPS- und Durchsatzraten der Datenträger innerhalb der Skalierungslimits der gewählten VM-Größe liegen.
Beispiel: Angenommen, eine Anwendungsanforderung hat einen Durchsatz von maximal 250 MB/s, und Sie verwenden eine VM vom Typ DS4 mit einem einzelnen P30-Datenträger. In diesem Fall kann die VM vom Typ DS4 einen Durchsatz von bis zu 256 MB/s leisten. Ein einzelner P30-Datenträger weist jedoch eine Durchsatzbeschränkung von 200 MB/s auf. Die Anwendung wird daher aufgrund der Beschränkung des Datenträgers auf 200 MB/s beschränkt. Um diese Beschränkung zu umgehen, stellen Sie für die VM mehr als einen Datenträger bereit, oder ändern Sie die Größe Ihrer Datenträger in P40 oder P50.
Hinweis
Leseanforderungen, die aus dem Cache erfüllt werden, bleiben bei der IOPS- und Durchsatzleistung des Datenträgers unberücksichtigt und unterliegen deshalb keinen Datenträgerlimits. Für den Cache gelten separate IOPS- und Durchsatzlimits pro VM.
Beispielsweise erfolgen Ihre Lese- und Schreibvorgänge anfänglich mit 60 MB/s bzw. 40 MB/s. Mit der Zeit füllt sich der Cache auf, sodass immer mehr Leseanforderungen aus dem Cache erfüllt werden. Dadurch erhalten Sie einen höheren Schreibdurchsatz vom Datenträger.
Anzahl der Datenträger
Bestimmen Sie die benötigte Anzahl der Datenträger, indem Sie die Anwendungsanforderungen prüfen. Für jede VM gilt auch ein Limit für die Anzahl der Datenträger, die an die VM angefügt werden können. In der Regel ist diese Menge die doppelte Anzahl der Kerne. Stellen Sie sicher, dass die gewählte VM-Größe die erforderliche Anzahl von Datenträgern unterstützt.
Wie schon erwähnt, bieten Storage Premium-Datenträger eine höhere Leistung als Storage Standard-Datenträger. Wenn Sie Ihre Anwendung aus einer Azure IaaS-VM mit Storage Standard zu Storage Premium migrieren, benötigen Sie wahrscheinlich weniger Premium-Datenträger, um für Ihre Anwendung dieselbe oder eine höhere Leistung zu erzielen.
Datenträgercaching
Hochleistungs-VMs mit Storage Premium arbeiten mit einer mehrschichtigen Cachetechnologie mit dem Namen BlobCache. BlobCache verwendet für das Zwischenspeichern eine Kombination aus Host-RAM und lokalem SSD-Laufwerk. Dieser Cache ist für die persistenten Storage Premium-Datenträger und die lokalen VM-Datenträger verfügbar. Standardmäßig ist diese Cacheeinstellung auf Read/Write für Betriebssystem-Datenträger und auf und ReadOnly für in Storage Premium gehostete Datenträger festgelegt. Bei aktiviertem Cache auf den Storage Premium-Datenträgern können die Hochleistungs-VMs überaus hohe Leistungsgrade erreichen, die die zugrunde liegende Datenträgerleistung übersteigen.
Warnung
Die Datenträgerzwischenspeicherung wird für Datenträger mit einer Größe von 4 TiB und mehr nicht unterstützt. Wenn mehrere Datenträger an Ihre VM angefügt sind, unterstützt jeder Datenträger mit 4 TiB oder weniger das Zwischenspeichern.
Durch Ändern der Cacheeinstellung eines Azure-Datenträgers wird der Zieldatenträger getrennt und erneut angefügt. Wenn es sich um den Betriebssystem-Datenträger handelt, wird der virtuelle Computer neu gestartet. Beenden Sie alle Anwendungen und Dienste, die von dieser Unterbrechung betroffen sein könnten, bevor Sie die Cacheeinstellung des Datenträgers ändern. Wenn diese Empfehlungen nicht befolgt werden, kann dies zu einer Beschädigung der Daten führen.
Weitere Informationen zur Funktionsweise von BlobCache finden Sie im Blogbeitrag Inside Azure Premium Storage.
Es ist wichtig, das Zwischenspeichern für die richtige Gruppe von Datenträgern zu aktivieren. Ob Sie das Zwischenspeichern auf einem Premium-Datenträger aktivieren oder nicht, hängt vom Workloadmuster ab, das der Datenträger verarbeitet. Die folgende Tabelle zeigt die standardmäßigen Cacheeinstellungen für Betriebssystem und Datenträger.
| Datenträgertyp | Standardeinstellung für den Cache |
|---|---|
| Betriebssystem-Datenträger | ReadWrite |
| Datenträger | ReadOnly |
Wir empfehlen die folgenden Cacheeinstellungen für Datenträger.
| Cacheeinstellung für Datenträger | Empfehlung zur Verwendung dieser Einstellung |
|---|---|
| None | Konfigurieren Sie „host-cache“ mit None für Datenträger mit hohem oder ausschließlichem Schreibzugriff. |
| ReadOnly | Konfigurieren Sie „host-cache“ mit ReadOnly für Datenträger mit reinem Lese- und Lese-/Schreibzugriff. |
| ReadWrite | Konfigurieren Sie „host-cache“ nur dann mit ReadWrite, wenn Ihre Anwendung zwischengespeicherte Daten bei Bedarf ordnungsgemäß auf persistente Datenträger schreiben kann. |
ReadOnly
Durch Konfigurieren des ReadOnly-Caches für Storage Premium-Datenträger können Sie aus zwei Gründen für Ihre Anwendung eine niedrige Wartezeit bei Lesevorgängen und einen sehr hohe Leserate hinsichtlich IOPS und Durchsatz erzielen:
- Aus dem Cache erfüllte Leseanforderungen, der sich im Arbeitsspeicher der VM und auf dem lokalen SSD-Laufwerk befindet, sind schneller als Lesevorgänge vom Datenträger, der sich in Azure Blob Storage befindet.
- Storage Premium rechnet die aus dem Cache erfüllten Leseanforderungen nicht zur IOPS- und Durchsatzrate des Datenträgers. Aus diesem Grund kann Ihre Anwendung eine höhere Gesamtrate bei IOPS und Durchsatz erzielen.
ReadWrite
Für die Betriebssystem-Datenträger ist der ReadWrite-Cache standardmäßig aktiviert. Wir haben vor Kurzem auch die Unterstützung des ReadWrite-Caches auf Datenträgern hinzugefügt. Wenn Sie den ReadWrite-Cache nutzen, benötigen Sie eine ordnungsgemäße Möglichkeit zum Schreiben der Daten aus dem Cache auf persistente Datenträger. SQL Server übernimmt beispielsweise selbst das Schreiben von Daten im Cache auf beständige Speicherdatenträger. Das Verwenden eines ReadWrite-Caches mit einer Anwendung, die die benötigten Daten nicht beständig speichert, kann zu Datenverlusten führen, sollte die VM abstürzen.
None
Die Option None wird aktuell nur für reguläre Datenträger unterstützt. Für Betriebssystemdatenträger wird sie nicht unterstützt. Wenn Sie None für einen Betriebssystemdatenträger festlegen, wird die Einstellung intern überschrieben und auf ReadOnly festgelegt.
Als Beispiel können Sie diese Leitlinien auf SQL Server in Storage Premium anwenden, indem Sie die folgenden Schritte ausführen:
- Konfigurieren Sie den ReadOnly-Cache auf Storage Premium-Datenträgern, die Datendateien hosten.
- Die schnellen aus dem Cache erfolgenden Lesevorgänge verkürzen die Abfragezeit von SQL Server, da Datenseiten schneller aus dem Cache als von den Datenträgern direkt abgerufen werden.
- Das Erfüllen von Leseanforderungen aus dem Cache bedeutet, dass auf den Premium-Datenträgern ein höherer Durchsatz verfügbar ist. SQL Server kann diesen zusätzlichen Durchsatz für das Abrufen von mehr Datenseiten und andere Vorgänge wie Sichern/Wiederherstellen, Batchladevorgänge und Indexneuerstellungen nutzen.
- Konfigurieren Sie die Cacheeinstellung None für Storage Premium-Datenträger, die Protokolldateien hosten.
- Protokolldateien weisen in erster Linie Vorgänge mit vielen Schreibvorgängen auf, daher profitieren sie nicht vom ReadOnly-Cache.
Optimieren der Leistung auf Linux-VMs
Für alle SSD Premium- oder Ultra-Datenträger können Sie möglicherweise Barrieren für Dateisysteme auf dem Datenträger deaktivieren, um die Leistung zu verbessern, wenn bekannt ist, dass keine Caches vorhanden sind, bei denen Daten verloren gehen könnten. Wenn für die Datenträgerzwischenspeicherung in Azure ReadOnly oder None festgelegt ist, können Sie Barrieren deaktivieren. Wenn für die Zwischenspeicherung jedoch ReadWrite festgelegt ist, sollten Barrieren aktiviert bleiben, um die Dauerhaftigkeit des Schreibens sicherzustellen. Barrieren sind in der Regel standardmäßig aktiviert, aber Sie können Barrieren abhängig vom Dateisystemtyp mithilfe einer der folgenden Methoden deaktivieren:
- reiserFS: Verwenden Sie zum Deaktivieren von Barrieren die Bereitstellungsoption barrier=none. Verwenden Sie barrier=flush, um Barrieren explizit zu aktivieren.
- ext3/ext4: Verwenden Sie zum Deaktivieren von Barrieren die Bereitstellungsoption barrier=0. Verwenden Sie barrier=1, um Barrieren explizit zu aktivieren.
- XFS: Verwenden Sie zum Deaktivieren von Barrieren die Bereitstellungsoption nobarrier. Verwenden Sie barrier, um Barrieren explizit zu aktivieren. Seit Version 4.10 des Mainline-Linux-Kernels gewährleistet das Design des XFS-Dateisystems stets eine lange Lebensdauer. Das Deaktivieren von Barrieren hat keine Auswirkungen und die Option nobarrier ist veraltet. Einige Linux-Distributionen haben jedoch möglicherweise die Änderungen an einer Verteilungsversion mit einer früheren Kernelversion zurückportiert. Wenden Sie sich an Ihren Verteilungsanbieter, um den Status in der Verteilung und Version anzuzeigen, die Sie ausführen.
Datenträgerstriping
Wenn an eine Hochleistungs-VM mehrere persistente Storage Premium-Datenträger angefügt werden, können diese Datenträger ein Stripeset bilden, um ihre IOPS-, Bandbreiten- und Speicherkapazitäten zu aggregieren.
Unter Windows können Sie das Feature „Speicherplätze“ verwenden, um Datenträger in einem Stripeset zu verbinden. Sie müssen für jeden Datenträger in einem Pool eine Spalte konfigurieren. Andernfalls kann die Gesamtleistung des Stripesetvolumes aufgrund einer ungleichen Verteilung des Datenverkehrs auf die Datenträger niedriger sein als erwartet.
In der Server-Manager-Benutzeroberfläche können Sie die Gesamtanzahl der Spalten auf bis zu 8 für ein Stripesetvolume festlegen. Bei Anfügen von mehr als acht Datenträgern nutzen Sie PowerShell, um das Volume zu erstellen. Mithilfe von PowerShell können Sie die Anzahl der Spalten entsprechend der Anzahl der Datenträger festlegen. Wenn beispielsweise ein einzelnes Stripeset 16 Datenträger enthält, geben Sie 16 Spalten für den NumberOfColumns-Parameter im New-VirtualDisk PowerShell-Cmdlet an.
Unter Linux können Sie hierfür das Hilfsprogramm MDADM verwenden. Schritte zum Verbinden von Datenträgern in einem Stripeset unter Linux finden Sie unter Konfigurieren von Software-RAID unter Linux.
Stripegröße
Eine wichtige Konfigurationseinstellung beim Datenträgerstriping ist die Stripegröße. Die Stripe- bzw. Blockgröße ist die kleinste Datenmenge, die eine Anwendung auf einem Stripesetvolume adressieren kann. Die Stripegröße, die Sie konfigurieren, hängt von der Art der Anwendung und ihrem Anforderungsmuster ab. Bei Wahl der falschen Stripegröße ist eine falsche E/A-Abstimmung möglich, durch die sich die Leistung Ihrer Anwendung verschlechtert.
Wenn beispielsweise eine von Ihrer Anwendung generierte E/A-Anforderung größer als die Stripegröße des Datenträgers ist, wird sie vom Speichersystem über Stripe-Einheitsgrenzen hinweg auf mehrere Datenträger geschrieben. Wenn auf diese Daten zugegriffen werden soll, muss zum Erfüllen der Anforderung mehr als eine Stripe-Einheit durchsucht werden. Die kumulative Wirkung eines solchen Verhaltens kann zu beträchtlichen Leistungseinbußen führen. Wenn hingegen die Größe der E/A-Anforderung kleiner als die Stripegröße ist und diese zufälliger Art ist, können sich die E/A-Anforderungen auf demselben Datenträger anhäufen, was zu einem Engpass und schließlich zu einer Verschlechterung der E/A-Leistung führt.
Wählen Sie abhängig vom Workload Ihrer Anwendung eine geeignete Stripegröße aus. Wählen Sie für zufällige kleine E/A-Anforderungen eine kleinere Stripegröße. Wählen Sie für große sequenzielle E/A-Anforderungen eine größere Stripegröße. Ermitteln Sie Empfehlungen für die Stripegröße für die Anwendung, die Sie in Storage Premium ausführen. Konfigurieren Sie für SQL Server eine Stripegröße von 64 KB für OLTP-Workloads und 256 KB für Data Warehousing-Workloads. Weitere Informationen finden Sie unter Bewährte Methoden zur Leistung für SQL Server auf Azure-VMs.
Hinweis
Bei einer VM der DS-Serie können Sie ein Stripeset mit maximal 32 Storage Premium-Datenträgern und bei einer VM der GS-Serie mit maximal 64 Storage Premium-Datenträgern bilden.
Multithreading
Azure hat die Storage Premium-Plattform mit einem hohen Grad an Parallelität ausgelegt. Aus diesem Grund wird mit einer Multithreadanwendung eine höhere Leistung als mit einer Singlethreadanwendung erreicht. Eine Multithreadanwendung teilt ihre Aufgaben auf mehrere Threads auf und steigert die Effizienz ihrer Ausführung durch den maximalen Einsatz der VM- und Datenträgerressourcen.
Wenn Ihre Anwendung in einer VM mit einem Kern mithilfe zweier Threads ausgeführt wird, kann die CPU zwischen den beiden Threads umschalten, um für Effizienz zu sorgen. Während ein Thread auf den Abschluss eines Datenträger-E/A-Vorgangs wartet, kann die CPU zum anderen Thread umschalten. Auf diese Weise können zwei Threads mehr erreichen als einem einzelnem Thread möglich ist. Wenn die VM mehr als einen Kern hat, verkürzt sich die Ausführungszeit weiter, da jeder Kern Aufgaben parallel ausführt.
Sie sind ggf. nicht in der Lage, die Weise zu ändern, in der eine Standardanwendung das Singlethreading oder Multithreading implementiert. SQL Server unterstützt beispielsweise das Arbeiten mit mehreren CPUs und Kernen. SQL Server entscheidet jedoch selbst, unter welchen Umständen ein oder mehrere Threads zum Verarbeiten einer Abfrage genutzt werden. SQL Server kann mithilfe von Multithreading Abfragen ausführen und Indizes erstellen. Für eine Abfrage, für die große Tabellen verknüpft und Daten sortiert werden, ehe die Rückgabe an den Benutzer erfolgt, verwendet SQL Server wahrscheinlich mehrere Threads. Benutzer*innen können nicht steuern, ob SQL Server eine Abfrage mithilfe eines einzelnen oder mehrerer Threads ausführt.
Es gibt Konfigurationseinstellungen, die Sie ändern können, um dieses Multithreading bzw. die Parallelverarbeitung einer Anwendung zu beeinflussen. Für SQL Server ist dies z. B. die max degree of parallelism-Konfiguration. Diese auch MAXDOP genannte Einstellung ermöglicht Ihnen das Konfigurieren der maximalen Anzahl von Prozessoren, die SQL Server bei der Parallelverarbeitung verwenden kann. Sie können MAXDOP für einzelne Abfragen oder Indexvorgänge konfigurieren. Diese Funktion ist nützlich, wenn Sie bei einer leistungsabhängigen Anwendung die Ressourcen Ihres Systems gleichmäßig auslasten möchten.
Angenommen, Ihre mit SQL Server arbeitende Anwendung führt gleichzeitig eine umfangreiche Abfrage und einen Indexvorgang aus. Wir nehmen einmal an, dass der Indexvorgang Priorität vor der umfangreichen Abfrage haben soll. In einem solchen Fall können Sie den MAXDOP-Wert des Indexvorgangs höher als den MAXDOP-Wert der Abfrage festlegen. Auf diese Weise verfügt SQL Server über mehr Prozessoren, die für den Indexvorgang genutzt werden können, im Vergleich zur Anzahl der Prozessoren, die ausschließlich für die umfangreiche Abfrage verwendet werden können. Beachten Sie, dass Sie nicht die Anzahl der Threads steuern können, die SQL Server für jeden Vorgang verwendet. Sie können die maximale Anzahl der Prozessoren steuern, die für das Multithreading reserviert werden.
Lesen Sie die weiteren Informationen zu Graden an Parallelität in SQL Server. Hier erfahren Sie mehr zu Einstellungen, mit denen das Multithreading in Ihrer Anwendung und deren Konfiguration zum Optimieren der Leistung beeinflusst werden können.
Warteschlangenlänge
Die Warteschlangenlänge ist die Anzahl ausstehender E/A-Anforderungen im System. Der Wert der Warteschlangenlänge bestimmt, wie viele E/A-Vorgänge, die von den Speicherdatenträgern verarbeitet werden sollen, Ihre Anwendung in die Schlange stellen kann. Dieser Wert betrifft alle drei Anwendungsleistungsindikatoren, die wir in diesem Artikel behandelt haben: IOPS, Durchsatz und Wartezeit.
Warteschlangenlänge und Multithreading stehen in enger Beziehung. Der Wert der Warteschlangenlänge gibt an, wie viel Multithreading von der Anwendung erreicht werden kann. Wenn die Warteschlangenlänge hoch ist, kann die Anwendung mehr Vorgänge gleichzeitig ausführen, also mehr Multithreading unterstützen. Wenn die Warteschlangenlänge niedrig ist, obwohl die Anwendung mit mehreren Threads arbeitet, stehen nicht genügend Anforderungen für die gleichzeitige Ausführung in der Schlange.
Standardanwendungen lassen meist nicht das Ändern der Warteschlangenlänge zu, denn bei einer falschen Festlegung ist der Schaden größer als der Nutzen. Anwendungen legen in der Regel den richtigen Wert für die Warteschlangenlänge fest, um sich eine optimale Leistung zu sichern. Allerdings ist es wichtig, dieses Konzept zu verstehen, damit Sie Leistungsprobleme bei Ihrer Anwendung beheben können. Sie können die Auswirkungen der Warteschlangenlänge beobachten, indem Sie in Ihrem System Benchmarktools ausführen.
Einige Anwendungen bieten Einstellungen zum Beeinflussen der Warteschlangenlänge. Die SQL Server-Einstellung MAXDOP wurde beispielsweise im vorherigen Abschnitt vorgestellt. MAXDOP ist eine Möglichkeit, Warteschlangenlänge und Multithreading zu beeinflussen, obwohl dadurch der SQL Server-Wert der Warteschlangenlänge nicht direkt geändert wird.
Hohe Warteschlangenlänge
Bei einer hohen Warteschlangenlänge werden mehr Vorgänge auf dem Datenträger in die Schlange gestellt. Der Datenträger kennt die nächste Anforderungen in seiner Warteschlange vorzeitig. Daher kann der Datenträger Vorgänge im Voraus planen und sie in einer optimalen Sequenz verarbeiten. Da die Anwendung mehr Anforderungen zum Datenträger überträgt, kann der Datenträger mehr parallele E/A-Vorgänge verarbeiten. Schlussendlich kann die Anwendung mehr IOPS erzielen. Da die Anwendung mehr Anforderungen verarbeitet, erhöht sich auch der Gesamtdurchsatz der Anwendung.
In der Regel erzielt eine Anwendung einen maximalen Durchsatz bei 8 bis mehr als 16 ausstehenden E/A-Vorgängen pro angefügtem Datenträger. Wenn die Warteschlangenlänge den Wert 1 hat, überträgt die Anwendung nicht genügend E/A-Vorgänge an das System, sodass in einem bestimmten Zeitraum eine geringere Anzahl davon verarbeitet werden. Das bedeutet weniger Durchsatz.
Beispiel: Wenn in SQL Server der MAXDOP-Wert für eine Abfrage auf 4 festgelegt wird, erkennt SQL Server, dass bis zu vier Kerne verwendet werden können, um die Abfrage auszuführen. SQL Server bestimmt den besten Wert für die Warteschlangenlänge und die Anzahl der Kerne für die Abfrageausführung.
Optimale Warteschlangenlänge
Eine sehr hohe Warteschlangenlänge hat jedoch auch Nachteile. Wenn der Wert zu hoch ist, versucht die Anwendung, eine sehr hohe IOPS-Rate zu erzielen. Außer wenn die Anwendung über persistente Datenträger mit ausreichend bereitgestellten IOPS verfügt, kann sich ein sehr hoher Wert für die Warteschlangenlänge negativ auf die Anwendungswartezeiten auswirken. Die folgende Formel zeigt die Beziehung zwischen IOPS, Latenz und Warteschlangenlänge.
Die Warteschlangenlänge darf nicht auf einen beliebig hohen Wert festgelegt werden. Wichtig ist ein optimaler Wert, der der Anwendung genügend IOPS bieten kann, ohne für mehr Wartezeit zu sorgen. Wenn z. B. die Anwendungswartezeit 1 Millisekunde sein muss, ist die erforderliche Warteschlangenlänge zum Erzielen von 5.000 IOPS wie folgt: WL = 5.000 x 0,001 = 5.
Warteschlangenlänge für Stripesetvolume
Für ein Stripesetvolume muss die Warteschlangenlänge so hoch sein, dass jeder Datenträger über eine individuelle Spitzenwarteschlangenlänge verfügt. Nehmen wir als Beispiel eine Anwendung mit dem Wert 2 für die Warteschlangenlänge und mit vier Datenträgern im Stripeset. Die beiden E/A-Anforderungen werden an zwei Datenträger gerichtet, während die restlichen inaktiv bleiben. Konfigurieren Sie deshalb die Warteschlangenlänge so, dass alle Datenträger ausgelastet werden. Folgende Formel veranschaulicht, wie Sie die Warteschlangenlänge von Stripesetvolumes bestimmen.
Drosselung
Storage Premium stellt abhängig von den gewählten VM- und Datenträgergrößen die angegebene IOPS- und Durchsatzrate bereit. Immer wenn die Anwendung versucht, eine IOPS- oder Durchsatzrate über diese Limits der VM oder des Datenträgers hinaus zu nutzen, erfolgt eine Drosselung durch Storage Premium. Das Ergebnis ist eine beeinträchtigte Leistung Ihrer Anwendung, was eine höhere Wartezeit, einen niedrigeren Durchsatz oder eine niedrigere IOPS-Rate bedeuten kann.
Wenn Storage Premium keine Drosselung vornimmt, kann Ihre Anwendung vollständig ausfallen, sobald die zur Verfügung stehenden Ressourcen überschritten werden. Um Leistungsprobleme aufgrund der Drosselung zu vermeiden, stellen Sie Ihrer Anwendung stets ausreichend Ressourcen zur Verfügung. Berücksichtigen Sie, was zuvor in den Abschnitten „VM-Größen“ und „Datenträgergrößen“ erörtert wurde. Benchmarktests sind die beste Möglichkeit, um herauszufinden, welche Ressourcen Sie zum Hosten der Anwendung benötigen.
Nächste Schritte
Wenn Sie ihren Datenträger mit einem Benchmark vergleichen möchten, lesen Sie die folgenden Artikel:
- Linux: Benchmarktests für Ihre Anwendung in Azure Disk Storage
- Für Windows: Datenträger mit einem Benchmark vergleichen
Weitere Informationen zu den verfügbaren Datenträgertypen finden Sie unter
- Linux: Auswählen eines Datenträgertyps.
- Windows: Auswählen eines Datenträgertyps.
Für SQL Server-Benutzer*innen bietet sich das Lesen von Artikeln zu den bewährten Methoden für die Leistung von SQL Server an: