Linux
Änderungen vorschlagen
PDFs
Konfigurationsthemen für das Linux-Betriebssystem.
Linux NFSv3 TCP-Slot-Tabellen
TCP-Slot-Tabellen sind das NFSv3 Äquivalent zur Warteschlangentiefe des Host Bus Adapters (HBA). Diese Tabellen steuern die Anzahl der NFS-Vorgänge, die zu einem beliebigen Zeitpunkt ausstehen können. Der Standardwert ist normalerweise 16, was für eine optimale Performance viel zu niedrig ist. Das entgegengesetzte Problem tritt auf neueren Linux-Kerneln auf, die automatisch die Begrenzung der TCP-Slot-Tabelle auf ein Niveau erhöhen können, das den NFS-Server mit Anforderungen sättigt.
Um eine optimale Performance zu erzielen und Performance-Probleme zu vermeiden, passen Sie die Kernel-Parameter an, die die TCP-Slot-Tabellen steuern.
Führen Sie die aus sysctl -a | grep tcp.*.slot_table Und beobachten Sie die folgenden Parameter:
# sysctl -a | grep tcp.*.slot_table sunrpc.tcp_max_slot_table_entries = 128 sunrpc.tcp_slot_table_entries = 128
Alle Linux-Systeme sollten enthalten sunrpc.tcp_slot_table_entries, Aber nur einige enthalten sunrpc.tcp_max_slot_table_entries. Beide sollten auf 128 gesetzt werden.
|
Wenn diese Parameter nicht eingestellt werden, kann dies erhebliche Auswirkungen auf die Leistung haben. In einigen Fällen ist die Performance eingeschränkt, da das linux-Betriebssystem nicht genügend I/O ausgibt In anderen Fällen erhöht sich die I/O-Latenz, wenn das linux Betriebssystem versucht, mehr I/O-Vorgänge auszustellen, als gewartet werden kann. |
Linux NFSv4.X Session-Slots
NFS-Session-Slots sind das NFSv4.X-Äquivalent zu den Slot-Tabellen von NFSv3. Der Standardwert ist üblicherweise 64. Ein Wert von 180 ist optimal, da er dem Session-Limit in ONTAP entspricht.
Beispiel für die Festlegung des Parameters max_session_slots:
# cat /etc/modprobe.d/nfsclient.conf options nfs max_session_slots=180
Dieser Parameter wird von einem Kernelmodul verwendet, das beim Systemstart geladen wird. Im Gegensatz zum NFSv3-Slottabellenparameter ist er nicht dynamisch. Ein Neustart ist erforderlich, damit die Änderung wirksam wird.
|
|
Wenn diese Parameter nicht festgelegt werden, kann dies erhebliche Auswirkungen auf die Performance haben. Die Performance kann erheblich eingeschränkt sein, da das Linux-Betriebssystem nicht genügend E/A-Operationen ausführt. |
Mount-Optionen für Linux NFS
In der folgenden Tabelle sind die Linux-NFS-Mount-Optionen für eine einzelne Instanz aufgeführt.
| Dateityp | Mount-Optionen |
|---|---|
AdR-Startseite |
|
Kontrolldateien Datendateien Wiederherstellungsprotokolle |
|
ORACLE_HOME |
|
In der folgenden Tabelle sind die Linux-NFS-Mount-Optionen für RAC aufgeführt.
| Dateityp | Mount-Optionen |
|---|---|
AdR-Startseite |
|
Kontrolldateien Datendateien Wiederherstellungsprotokolle |
|
CRS/Abstimmung |
|
Dediziert |
|
Freigegeben |
|
Der Hauptunterschied zwischen Single-Instance- und RAC-Mount-Optionen ist das Hinzufügen von actimeo=0 Zu den Mount-Optionen. Durch diese Ergänzung wird das Caching des Host-Betriebssystems deaktiviert, wodurch alle Instanzen im RAC Cluster eine konsistente Ansicht des Status der Daten haben. Obwohl Sie den verwenden init.ora Parameter filesystemio_options=setall Hat die gleiche Wirkung wie die Deaktivierung des Host-Caching, ist es weiterhin erforderlich, zu verwenden actimeo=0.
Der Grund actimeo=0 Ist für die gemeinsame Nutzung erforderlich ORACLE_HOME Die Bereitstellung soll die Konsistenz von Dateien wie den Oracle-Passwortdateien und den SPfiles erleichtern. Wenn jede Instanz in einem RAC-Cluster über einen dedizierten verfügt ORACLE_HOME, Dann ist dieser Parameter nicht erforderlich.
Im Allgemeinen sollten nicht-Datenbankdateien mit denselben Optionen gemountet werden, die für Datendateien mit einer einzigen Instanz verwendet werden, obwohl bestimmte Applikationen unterschiedliche Anforderungen haben können. Vermeiden Sie die Montageoptionen noac Und actimeo=0 Wenn möglich, da diese Optionen das Vorauslesen und Puffern auf Dateisystemebene deaktivieren. Dies kann zu schwerwiegenden Leistungsproblemen bei Prozessen wie Extraktion, Übersetzung und Laden führen.
ACCESS und GETATTR
Einige Kunden bemerken, dass ein extrem hohes Maß an anderen IOPS wie ACCESS und GETATTR ihre Workloads dominieren kann. In Extremfällen können Vorgänge wie Lese- und Schreibvorgänge bis zu 10 % des Gesamtbetrags ausmachen. Dies ist ein normales Verhalten bei jeder Datenbank, die die Verwendung einschließt actimeo=0 Und/oder noac Unter Linux, weil diese Optionen dazu führen, dass das Linux-Betriebssystem ständig Datei-Metadaten aus dem Speichersystem neu lädt. Vorgänge wie ACCESS und GETATTR sind Vorgänge mit geringen Auswirkungen, die aus dem ONTAP Cache in einer Datenbankumgebung bedient werden. Sie sollten nicht als echte IOPS-Werte wie Lese- und Schreibvorgänge betrachtet werden, die einen echten Bedarf an Storage-Systemen verursachen. Diese anderen IOPS erzeugen jedoch eine gewisse Last, insbesondere in RAC-Umgebungen. Um diesem Problem zu begegnen, aktivieren Sie DNFS, wodurch der Puffercache des Betriebssystems umgangen wird und unnötige Metadatenvorgänge vermieden werden.
nconnect
nconnect ist eine relativ neue Mount-Option. Sie ermöglicht es dem NFS-Client, für einen bestimmten Mountpunkt mehrere unabhängige TCP/IP-Verbindungen zu öffnen und anschließend die E/A zu multiplexen. Das Ergebnis sind mehr laufende Operationen, was die Performance verbessert, insbesondere in Netzwerken mit einer hohen Bandbreite. Der unter Linux maximal unterstützte Wert ist 16, aber NetApp empfiehlt einen Wert von 4 bis 8. Das Ergebnis ist eine Single-Instance-Performance, die mit der des dNFS Client vergleichbar ist, wenn dieser für einen einzelnen Pfad konfiguriert ist. Im Gegensatz zu dNFS kann nconnect nicht für Multiplexing über mehrere IP-Adressen und TCP/IP-Verbindungen hinweg konfiguriert werden.
Bei RAC verursacht nconnect aufgrund des zusätzlichen Metadatenverkehrs einen höheren Performance-Overhead als dNFS. Weitere Informationen enthält link:#Linux%20Direct%20NFS%20and Oracle %20AC[Linux Direct NFS and Oracle RAC].
Linux Direct NFS
Eine zusätzliche Mount-Option namens nosharecache ist erforderlich, wenn (a) DNFS aktiviert ist und (b) eine Quell-NFS-Freigabe mehr als einmal auf einem einzelnen Server (c) mit einer verschachtelten NFS-Einbindung eingebunden wird. Diese Konfiguration findet sich hauptsächlich in Umgebungen, die SAP-Anwendungen unterstützen. Beispielsweise könnte eine einzelne NFS-Freigabe auf einem NetApp System ein Verzeichnis unter /vol/oracle/base und ein zweites unter /vol/oracle/home enthalten. Wenn /vol/oracle/base bei /oracle eingebunden ist und /vol/oracle/home bei /oracle/home eingebunden ist, entstehen verschachtelte NFS-Einbindungen, die vom selben Ursprung stammen.
Das Betriebssystem erkennt, dass /oracle und /oracle/home sich auf derselben NFS-Freigabe befinden, was dasselbe Quelldateisystem ist. Das Betriebssystem verwendet dann denselben Gerätehandle für den Zugriff auf die Daten. Dies verbessert die Nutzung des Betriebssystem-Cachings und bestimmter anderer Operationen, beeinträchtigt jedoch DNFS. Wenn DNFS auf eine Datei wie spfile auf /oracle/home zugreifen muss, kann es fälschlicherweise versuchen, den falschen Pfad zu den Daten zu verwenden. Das Ergebnis ist ein fehlgeschlagener E/A-Vorgang. Fügen Sie in diesen Konfigurationen die nosharecache Mount-Option zu jedem NFS-Dateisystem hinzu, das eine Quell-NFS-Freigabe mit einem anderen NFS-Dateisystem auf diesem Host teilt. Dadurch wird das Linux-Betriebssystem gezwungen, einen unabhängigen Gerätehandle für dieses Dateisystem zuzuweisen.
Linux Direct NFS und Oracle RAC
Die Verwendung von DNFS bietet für Oracle RAC unter dem Linux-Betriebssystem besondere Performance-Vorteile, da Linux keine Methode bietet, direkte E/A zu erzwingen, was bei RAC für die Konsistenz über die Knoten hinweg erforderlich ist. Als Workaround erfordert Linux die Verwendung der `actimeo=0`Mount-Option, wodurch Dateidaten sofort aus dem Betriebssystem-Cache ablaufen. Diese Option wiederum zwingt den Linux NFS-Client, Attributdaten ständig erneut zu lesen, was die Latenz und die Last auf dem Storage Controller erhöht.
Durch die Aktivierung von DNFS wird der Host NFS-Client umgangen, und dieses Problem wird vermieden. Mehrere Kunden haben von deutlichen Performance Verbesserungen auf RAC Clustern und einer signifikanten Reduzierung der ONTAP Last (insbesondere im Vergleich zu anderen IOPS) nach der Aktivierung von DNFS berichtet.
Linux Direct NFS- und oranfstab-Datei
Bei der Verwendung von DNFS unter Linux mit der Multipathing-Option müssen mehrere Subnetze verwendet werden. Auf anderen Betriebssystemen können mehrere DNFS-Kanäle mithilfe des eingerichtet werden LOCAL Und DONTROUTE Optionen zum Konfigurieren mehrerer DNFS-Kanäle in einem einzigen Subnetz. Dies funktioniert jedoch unter Linux nicht richtig, und es können unerwartete Leistungsprobleme auftreten. Bei Linux muss sich jeder für den DNFS-Verkehr verwendete NIC in einem anderen Subnetz befinden.
I/O-Planer
Der Linux-Kernel ermöglicht eine Steuerung auf niedriger Ebene über die Art und Weise, wie I/O-Vorgänge zum Blockieren von Geräten geplant werden. Die Standardeinstellungen auf verschiedenen Linux-Distribution variieren erheblich. Tests zeigen, dass Deadline in der Regel die besten Ergebnisse bietet, aber gelegentlich NOOP war etwas besser. Der Unterschied in der Performance ist minimal, aber testen Sie beide Optionen, wenn es erforderlich ist, um die maximal mögliche Performance aus einer Datenbankkonfiguration zu extrahieren. CFQ ist in vielen Konfigurationen der Standard und hat bei Datenbank-Workloads erhebliche Performance-Probleme gezeigt.
Anweisungen zur Konfiguration des I/O-Planers finden Sie in der entsprechenden Dokumentation des Linux-Anbieters.
Multipathing
Einige Kunden sind während der Netzwerkunterbrechung auf Abstürze gestoßen, weil der Multipath-Daemon auf ihrem System nicht ausgeführt wurde. Bei aktuellen Versionen von Linux können der Installationsprozess des Betriebssystems und des Multipathing-Daemons diese Betriebssysteme für dieses Problem anfällig machen. Die Pakete sind ordnungsgemäß installiert, aber nach einem Neustart nicht für den automatischen Start konfiguriert.
Die Standardeinstellung für den Multipath-Daemon unter RHEL5.5 kann beispielsweise wie folgt angezeigt werden:
[root@host1 iscsi]# chkconfig --list | grep multipath multipathd 0:off 1:off 2:off 3:off 4:off 5:off 6:off
Dies kann mit den folgenden Befehlen korrigiert werden:
[root@host1 iscsi]# chkconfig multipathd on [root@host1 iscsi]# chkconfig --list | grep multipath multipathd 0:off 1:off 2:on 3:on 4:on 5:on 6:off
ASM Spiegelung
ASM-Spiegelung erfordert möglicherweise Änderungen an den Linux Multipath-Einstellungen, damit ASM ein Problem erkennen und zu einer alternativen Ausfallgruppe wechseln kann. Die meisten ASM-Konfigurationen auf ONTAP verwenden externe Redundanz. Das bedeutet, dass Datensicherung durch das externe Array bereitgestellt wird und ASM keine Daten spiegelt. Einige Standorte verwenden ASM mit normaler Redundanz, um normalerweise zwei-Wege-Spiegelung über verschiedene Standorte hinweg bereitzustellen.
Die Linux-Einstellungen, die im angezeigt werden "NetApp Host Utilities-Dokumentation" Schließen Sie Multipath-Parameter ein, die zu unbestimmter I/O-Warteschlange führen Dies bedeutet, dass ein I/O auf einem LUN-Gerät ohne aktive Pfade so lange wartet, wie es für den I/O-Abschluss erforderlich ist. Dies ist in der Regel wünschenswert, da Linux-Hosts so lange warten, bis die Änderungen des SAN-Pfads abgeschlossen sind, FC-Switches neu gestartet werden oder ein Storage-System einen Failover abschließt.
Dieses unbegrenzte Warteschlangenverhalten verursacht ein Problem mit der ASM-Spiegelung, da ASM einen I/O-Fehler empfangen muss, damit er I/O auf einer alternativen LUN erneut versuchen kann.
Legen Sie die folgenden Parameter in Linux fest multipath.conf Datei für ASM-LUNs, die mit ASM-Spiegelung verwendet werden:
polling_interval 5 no_path_retry 24
Mit diesen Einstellungen wird ein Timeout von 120 Sekunden für ASM-Geräte erstellt. Das Timeout wird als berechnet polling_interval * no_path_retry Sekunden lang. Der genaue Wert muss unter Umständen angepasst werden, aber ein Timeout von 120 Sekunden sollte für die meisten Anwendungen ausreichen. Insbesondere sollten in 120 Sekunden eine Controller-Übernahme oder -Rückgabe möglich sein, ohne dass ein I/O-Fehler auftritt, der dazu führen würde, dass die Fehlergruppe offline geschaltet wird.
A niedriger no_path_retry Value kann die für ASM erforderliche Zeit zum Wechsel zu einer alternativen Ausfallgruppe verkürzen. Dies erhöht jedoch auch das Risiko eines unerwünschten Failovers während Wartungsaktivitäten wie beispielsweise einem Controller-Takeover. Das Risiko kann durch eine sorgfältige Überwachung des ASM-Spiegelungsstatus verringert werden. Wenn ein unerwünschtes Failover auftritt, können die Spiegelungen schnell neu synchronisiert werden, wenn die Resynchronisierung relativ schnell durchgeführt wird. Weitere Informationen finden Sie in der Oracle-Dokumentation zu ASM Fast Mirror Resync für die verwendete Version der Oracle-Software.
Mount-Optionen für Linux xfs, ext3 und ext4
|
NetApp empfiehlt die Verwendung der Standard-Mount-Optionen. |