Skip to main content
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Entwicklung einer ONTAP FlexCache Hotspot-Remediation-Lösung

Beitragende netapp-dbagwell netapp-lenida
Änderungen vorschlagen

Um Hotspots zu beheben, werden die zugrundeliegenden Ursachen von Engpässen untersucht, die Gründe analysiert, warum automatisch bereitgestelltes FlexCache nicht ausreicht, sowie die technischen Details betrachtet, die für eine effektive Architektur einer FlexCache Lösung notwendig sind. Durch das Verständnis und die Implementierung von High-Density FlexCache Arrays (HDFAs) lässt sich die Leistung optimieren und Engpässe in anspruchsvollen Workloads beseitigen.

Den Engpass verstehen

Die folgende Bild zeigt ein typisches Hotspotting-Szenario mit einer einzelnen Datei. Das Volume ist ein FlexGroup mit einem einzelnen Bestandteil pro Knoten, und die Datei befindet sich auf Knoten 1.

Auch wenn alle Netzwerkverbindungen der NAS-Clients auf verschiedene Knoten im Cluster verteilt werden, bleibt der Engpass bei der CPU bestehen, die die Volume-Affinität bedient, auf der sich die Hot File befindet. Es entsteht außerdem Cluster-Netzwerkverkehr (Ost-West-Verkehr) für die Aufrufe von Clients, die mit anderen Knoten als dem verbunden sind, auf dem sich die Datei befindet. Der Overhead des Ost-West-Verkehrs ist typischerweise gering, aber bei Hochleistungs-Compute-Workloads zählt jedes bisschen.

Abbildung 1: FlexGroup Single-File-Hotspot-Szenario

Abbildung 1: FlexGroup Single-File-Hotspot-Szenario

Warum eine automatisch bereitgestellte FlexCache nicht die Lösung ist

Um Hotspots zu beheben, sollten der CPU-Engpass und idealerweise auch der Ost-West-Verkehr beseitigt werden. FlexCache kann helfen, wenn es richtig eingerichtet ist.

Im folgenden Beispiel wird FlexCache automatisch mit System Manager, NetApp Console oder Standard-CLI-Argumenten bereitgestellt. Abbildung 1 und Abbildung 2 erscheinen zunächst gleich: Beide sind vier-Knoten, Einzelkomponenten-NAS-Container. Der einzige Unterschied besteht darin, dass der NAS-Container in Abbildung 1 ein FlexGroup ist und der NAS-Container in Abbildung 2 ein FlexCache ist. Jede Abbildung zeigt denselben Engpass: die CPU von Knoten 1 für Volume-Affinitätsdienste beim Zugriff auf die Hot File sowie Ost-West-Verkehr, der zur Latenz beiträgt. Ein automatisch bereitgestellter FlexCache hat den Engpass nicht beseitigt.

Abbildung 2: Automatisch bereitgestelltes FlexCache Szenario

Abbildung 2: Automatisch bereitgestelltes FlexCache Szenario

Anatomie eines FlexCache

Um eine FlexCache effektiv für die Hotspot-Behebung zu gestalten, ist es wichtig, einige technische Details über FlexCache zu kennen.

FlexCache ist immer eine dünn besetzte FlexGroup. Eine FlexGroup besteht aus mehreren FlexVols. Diese FlexVols werden als FlexGroup-Bestandteile bezeichnet. In einer Standard-FlexGroup-Konfiguration gibt es einen oder mehrere Bestandteile pro Knoten im Cluster. Die Bestandteile sind unter einer Abstraktionsschicht „zusammengenäht“ und werden dem Client als ein einziger großer NAS-Container präsentiert. Wenn eine Datei in eine FlexGroup geschrieben wird, bestimmen Ingest-Heuristiken, auf welchem Bestandteil die Datei gespeichert wird. Es kann sich um einen Bestandteil handeln, der die NAS-Verbindung des Clients enthält, oder um einen anderen Knoten. Der Speicherort ist unerheblich, da alles unter der Abstraktionsschicht abläuft und für den Client unsichtbar ist.

Dieses Verständnis von FlexGroup lässt sich auf FlexCache anwenden. Da FlexCache auf einem FlexGroup basiert, gibt es standardmäßig einen einzelnen FlexCache, der auf allen Knoten im Cluster Bestandteile hat, wie in Abbildung 1 dargestellt. In den meisten Fällen ist dies eine sehr gute Eigenschaft. Alle Ressourcen im Cluster werden genutzt.

Für die Behebung von Hot Files ist dies jedoch aufgrund zweier Engpässe nicht ideal: CPU für eine einzelne Datei und Ost-West-Datenverkehr. Wenn ein FlexCache mit Bestandteilen auf jedem Node für eine Hot File erstellt wird, befindet sich diese Datei dennoch nur auf einem der Bestandteile. Das bedeutet, dass eine CPU für den gesamten Zugriff auf die Hot File zuständig ist. Auch die Menge des Ost-West-Datenverkehrs, der zum Erreichen der Hot File erforderlich ist, sollte begrenzt werden.

Die Lösung ist ein Array mit hoher Dichte FlexCaches.

Anatomie einer High-Density-FlexCache

Ein High-Density FlexCache (HDF) hat Bestandteile auf so wenigen Knoten, wie es die Kapazitätsanforderungen für die zwischengespeicherten Daten zulassen. Das Ziel ist, den Cache auf einem einzigen Knoten zu betreiben. Wenn die Kapazitätsanforderungen dies unmöglich machen, können die Bestandteile stattdessen auf nur wenige Knoten verteilt werden.

Ein Cluster mit 24 Knoten könnte beispielsweise drei hochdichte FlexCaches haben:

  • Eine, die sich über die Knoten 1 bis 8 erstreckt

  • Eine zweite, die die Knoten 9 bis 16 umfasst

  • Ein drittes, das die Knoten 17 bis 24 umfasst

Diese drei HDFs bilden ein High-Density FlexCache Array (HDFA). Sind die Dateien gleichmäßig auf die einzelnen HDFs verteilt, besteht eine 1-zu-8-Chance, dass die vom Client angeforderte Datei lokal an der Frontend NAS-Verbindung liegt. Wenn 12 HDFs jeweils nur zwei Knoten umfassen, besteht eine 50%ige Chance, dass die Datei lokal ist. Wenn die HDF auf einen einzelnen Knoten reduziert und 24 davon erstellt werden, ist garantiert, dass die Datei lokal ist.

Diese Konfiguration eliminiert den gesamten Ost-West-Verkehr und, was am wichtigsten ist, stellt 24 CPUs/Volume-Affinitäten für den Zugriff auf die Hot File bereit.

Verwandte Informationen

"Dokumentation zu FlexGroup und TRs"