| Navigationslinks �berspringen | |
| Druckansicht beenden | |
|
Systemverwaltungshandbuch: Netzwerkdienste |
Teil I Netzwerkdienste - Themen
2. Verwalten von Webcache-Servern
Teil II Zugriff auf Netzwerkdateisysteme - Themen
4. Verwalten von Netzwerkdateisystemen (Übersicht)
5. Verwaltung des Netzwerkdateisystems (Aufgaben)
6. Zugreifen auf Netzwerkdateisysteme (Referenz)
Schlüsselwörter für die /etc/default/nfs-Datei
Konfigurationsdateien und nfsmapid
nfsmapid und DNS-TXT-Datensätze
Ermitteln der Domain der NFS-Version 4
Konfigurieren der Standarddomain der NFS-Version 4
Zusätzliche Informationen zu nfsmapid
mount-Optionen für NFS-Dateisysteme
Nicht dateisystemspezifische share-Optionen
NFS-spezifische share-Optionen
Einrichten von Zugriffslisten mit dem share-Befehl
Funktionsweise des NFS-Service
Dateisystem-Namespace in NFS-Version 4
Temporäre Dateizugriffsroutinen in NFS-Version 4
Clientwiederherstellung in NFS-Version 4
OPEN-Unterstützung zur gemeinsamen Nutzung in NFS-Version 4
Zugriffskontrolllisten (ACLs) und nfsmapid in NFS-Version 4
Aushandlung der Dateiübertragungsgröße
Funktionsweise der Option -public und der NFS-URLs beim Einhängen
Was ist ein repliziertes Dateisystem?
Clientseitiges Failover in NFS-Version 4
Funktionsweise der NFS-Serverprotokollierung
Funktionsweise des WebNFS-Service
Funktionsweise der WebNFS-Sicherheitsaushandlung
WebNFS-Beschränkungen bei Verwendung eines Webbrowsers
Verwenden vom sicheren RPC mit NFS
Wie autofs durch das Netzwerk navigiert (Maps)
Wie autofs den Navigationprozess startet (Master-Map)
Wie autofs die nächsten schreibgeschützten Dateien für Clients auswählt (mehrere Speicherorte)
Variablen in einem Map-Eintrag
Maps, die sich auf andere Maps beziehen
Modifizieren, wie autofs im Netzwerk navigiert (Modifizieren von Maps)
Standardmäßiges Verhalten von autofs bei Verwendung von Name Services
Teil III SLP (Service Location Protocol) - Themen
8. Planen und Aktivieren von SLP (Aufgaben)
9. Verwalten von SLP (Aufgaben)
10. Integrieren von veralteten Services
Teil V Serielle Vernetzung - Themen
15. Solaris PPP 4.0 (Überblick)
16. PLanen einer PPP-Verbindung (Aufgaben)
17. Einrichten einer PPP-Einwahlverbindung (Aufgaben)
18. Einrichten einer PPP-Standleitungsverbindung (Aufgaben)
19. Einrichten der PPP-Authentifizierung (Aufgaben)
20. Einrichten eines PPPoE-Tunnels (Aufgaben)
21. Beheben von allgemeinen PPP-Problemen (Aufgaben)
22. Solaris PPP 4.0 (Referenz)
23. Migrieren von Asynchronous Solaris PPP zu Solaris PPP 4.0 (Aufgaben)
25. Verwalten von UUCP (Aufgaben)
Teil VI Arbeiten mit Remote-Systemen - Themen
27. Arbeiten mit Remote-Systemen (Übersicht)
28. Verwalten des FTP-Servers (Aufgaben)
29. Zugriff auf Remote-Systeme (Aufgaben)
Teil VII Überwachen von Netzwerkdiensten - Themen
Mit diesen Befehlen können NFS-Probleme behoben werden.
Mit diesem Befehl können Sie statistische Informationen zu NFS- und RPC-Verbindungen sammeln. Die Syntax des Befehls lautet folgendermaßen:
nfsstat [ -cmnrsz ]
Zeigt clientseitige Informationen an.
Zeigt Statistiken für jedes mit NFS eingehängte Dateisystem an.
Gibt an, dass NFS-Informationen sowohl auf der Clientseite als auch auf der Serverseite angezeigt werden sollen.
Zeigt RPC-Statistiken an.
Zeigt serverseitige Informationen an.
Gibt an, dass die Statistiken auf null gesetzt werden sollen.
Wenn keine Optionen in der Befehlszeile angegeben werden, werden die -cnrs-Optionen verwendet.
Das Sammeln von serverseitigen Statistiken kann wichtig für die Behebung von Problemen sein, wenn neue Software oder neue Hardware in die Datenverarbeitungsumgebung integriert wird. Wenn dieser Befehl mindestens einmal pro Woche ausgeführt wird und die Ergebnisse gespeichert werden, können die erzielten Leistungen bestens nachverfolgt werden.
Siehe folgendes Beispiel:
# nfsstat -s Server rpc: Connection oriented: calls badcalls nullrecv badlen xdrcall dupchecks dupreqs 719949194 0 0 0 0 58478624 33 Connectionless: calls badcalls nullrecv badlen xdrcall dupchecks dupreqs 73753609 0 0 0 0 987278 7254 Server nfs: calls badcalls 787783794 3516 Version 2: (746607 calls) null getattr setattr root lookup readlink read 883 0% 60 0% 45 0% 0 0% 177446 23% 1489 0% 537366 71% wrcache write create remove rename link symlink 0 0% 1105 0% 47 0% 59 0% 28 0% 10 0% 9 0% mkdir rmdir readdir statfs 26 0% 0 0% 27926 3% 108 0% Version 3: (728863853 calls) null getattr setattr lookup access 1365467 0% 496667075 68% 8864191 1% 66510206 9% 19131659 2% readlink read write create mkdir 414705 0% 80123469 10% 18740690 2% 4135195 0% 327059 0% symlink mknod remove rmdir rename 101415 0% 9605 0% 6533288 0% 111810 0% 366267 0% link readdir readdirplus fsstat fsinfo 2572965 0% 519346 0% 2726631 0% 13320640 1% 60161 0% pathconf commit 13181 0% 6248828 0% Version 4: (54871870 calls) null compound 266963 0% 54604907 99% Version 4: (167573814 operations) reserved access close commit 0 0% 2663957 1% 2692328 1% 1166001 0% create delegpurge delegreturn getattr 167423 0% 0 0% 1802019 1% 26405254 15% getfh link lock lockt 11534581 6% 113212 0% 207723 0% 265 0% locku lookup lookupp nverify 230430 0% 11059722 6% 423514 0% 21386866 12% open openattr open_confirm open_downgrade 2835459 1% 4138 0% 18959 0% 3106 0% putfh putpubfh putrootfh read 52606920 31% 0 0% 35776 0% 4325432 2% readdir readlink remove rename 606651 0% 38043 0% 560797 0% 248990 0% renew restorefh savefh secinfo 2330092 1% 8711358 5% 11639329 6% 19384 0% setattr setclientid setclientid_confirm verify 453126 0% 16349 0% 16356 0% 2484 0% write release_lockowner illegal 3247770 1% 0 0% 0 0% Server nfs_acl: Version 2: (694979 calls) null getacl setacl getattr access getxattrdir 0 0% 42358 6% 0 0% 584553 84% 68068 9% 0 0% Version 3: (2465011 calls) null getacl setacl getxattrdir 0 0% 1293312 52% 1131 0% 1170568 47%
Die oben dargestellte Auflistung ist ein Beispiel für NFS-Serverstatistiken. Die ersten fünf Zeilen beziehen sich auf RPC und die übrigen Zeilen auf die Meldung von NFS-Vorgängen. Beide Statistiken geben Aufschluss über die durchschnittliche Anzahl von badcalls oder calls pro Woche. Dies kann bei der Erkennung eines Problems hilfreich sein. Der badcalls-Wert dient zur Angabe der Anzahl von ungültigen Meldungen, die ein Client gesendet hat. Dieser Wert kann auf Probleme mit der Netzwerkhardware hindeuten.
Aus manchen Verbindungen resultieren Schreibvorgänge auf den Datenträgern. Ein plötzlicher Anstieg in diesen Statistiken kann auf ein Problem hindeuten. Dann sollte eine Untersuchung durchgeführt werden. Bei Statistiken der NFS-Version 2 sollte auf die Verbindungen setattr, write, create, remove, rename , link, symlink, mkdir und rmdir geachtet werden. Bei Statistiken der NFS-Versionen 3 und 4 sollte auf den Wert commit geachtet werden. Wenn der Wert von commit bei einem NFS-Server im Vergleich mit einem anderen, fast identischen Server relativ hoch ist, prüfen Sie, ob die NFS-Clients über genügend Speicher verfügen. Die Anzahl der commit-Vorgänge auf dem Server steigt an, wenn Clients keine verfügbaren Ressourcen haben.
Mit diesem Befehl wird ein Datenstapelprotokoll für jeden Prozess angezeigt. Der Befehl pstack muss vom Eigentümer des Prozesses oder vom root-Benutzer ausgeführt werden. Sie können pstack verwenden, um festzustellen, wo ein Prozess hängt. Die einzige Option, die in Verbindung mit diesem Befehl verwendet werden darf, ist die PID-Option des Prozesses, der von Ihnen überprüft werden muss. Weitere Informationen finden Sie auf der Manpage proc(1).
Im folgenden Beispiel wird der laufende nfsd-Prozess geprüft.
# /usr/bin/pgrep nfsd 243 # /usr/bin/pstack 243 243: /usr/lib/nfs/nfsd -a 16 ef675c04 poll (24d50, 2, ffffffff) 000115dc ???????? (24000, 132c4, 276d8, 1329c, 276d8, 0) 00011390 main (3, efffff14, 0, 0, ffffffff, 400) + 3c8 00010fb0 _start (0, 0, 0, 0, 0, 0) + 5c
Das Beispiel zeigt, dass der Prozess auf eine neue Verbindungsanforderung wartet, was eine normale Antwort ist. Wenn der Stapel zeigt, dass der Prozess nach der Absendung einer Anforderung weiterhin abgefragt wird, hängt der Prozess möglicherweise. Führen Sie die unter So starten Sie die NFS-Services neu beschriebenen Schritte aus, um das Problem zu beheben. Gehen Sie nochmals die unter NFS-Fehlerbehebungsverfahren beschriebenen Schritte durch, um sicherzugehen, dass das Problem auf einen hängenden Prozess oder ein hängendes Programm zurückzuführen ist.
Mit diesem Befehl werden Informationen zum RPC-Service generiert, der auf einem System ausgeführt wird. Sie können mit diesem Befehl auch den RPC-Service ändern. Für diesen Befehl stehen zahlreiche Optionen zur Verfügung. Weitere Informationen finden Sie auf der Manpage rpcinfo(1M). Es folgt eine kurze Darstellung von einigen der Optionen, die Sie in Verbindung mit diesem Befehl verwenden können:
rpcinfo [ -m | -s ] [ hostname ]
rpcinfo -T transport hostname [ progname ]
rpcinfo [ -t | -u ] [ hostname ] [ progname ]
Zeigt eine Tabelle mit Statistiken der rpcbind-Vorgänge an.
Zeigt eine kurze Liste aller registrierten RPC-Programme an.
Zeigt Informationen zu Services an, die spezielle Übertragungsverfahren oder Protokolle verwenden.
Untersucht die RPC-Programme, die TCP verwenden.
Untersucht die RPC-Programme, die UDP verwenden.
Wählt das Übertragungsverfahren oder Protokoll für die Services aus.
Wählt den Hostnamen des Servers aus, von dem Sie Informationen benötigen.
Wählt das RPC-Programm aus, über das Informationen gesammelt werden sollen.
Wenn kein Wert für hostname angegeben ist, wird der lokale Hostname verwendet. Sie können progname durch eine RPC-Programmnummer ersetzen. Bedenken Sie aber, dass sich viele Benutzer an den Namen erinnern können, nicht aber an die Nummer. Bei Systemen, auf denen die Software der NFS-Version 3 nicht ausgeführt wird, können Sie die Option -p anstelle der Option -s verwenden.
Die Daten, die durch diesen Befehl bereitgestellt werden, können Folgendes enthalten:
Die RPC-Programmnummer
Die Versionsnummer für ein bestimmtes Programm
Das verwendete Transportprotokoll
Den Namen des RPC-Service
Den Eigentümer des RPC-Service
Im folgenden Beispiel werden Informationen zu den RPC-Services gesammelt, die auf einem Server ausgeführt werden. Der Text, der durch die Ausführung des Befehls erstellt wurde, wird mithilfe des Befehls sort gefiltert, wodurch die Ausgabe lesbarer wird. Mehrere Zeilen, auf denen RPC-Services aufgelistet waren, wurden aus dem Beispiel entfernt.
% rpcinfo -s bee |sort -n
program version(s) netid(s) service owner
100000 2,3,4 udp6,tcp6,udp,tcp,ticlts,ticotsord,ticots rpcbind superuser
100001 4,3,2 ticlts,udp,udp6 rstatd superuser
100002 3,2 ticots,ticotsord,tcp,tcp6,ticlts,udp,udp6 rusersd superuser
100003 3,2 tcp,udp,tcp6,udp6 nfs superuser
100005 3,2,1 ticots,ticotsord,tcp,tcp6,ticlts,udp,udp6 mountd superuser
100007 1,2,3 ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 ypbind superuser
100008 1 ticlts,udp,udp6 walld superuser
100011 1 ticlts,udp,udp6 rquotad superuser
100012 1 ticlts,udp,udp6 sprayd superuser
100021 4,3,2,1 tcp,udp,tcp6,udp6 nlockmgr superuser
100024 1 ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 status superuser
100029 3,2,1 ticots,ticotsord,ticlts keyserv superuser
100068 5 tcp,udp cmsd superuser
100083 1 tcp,tcp6 ttdbserverd superuser
100099 3 ticotsord autofs superuser
100133 1 ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 - superuser
100134 1 ticotsord tokenring superuser
100155 1 ticots,ticotsord,tcp,tcp6 smserverd superuser
100221 1 tcp,tcp6 - superuser
100227 3,2 tcp,udp,tcp6,udp6 nfs_acl superuser
100229 1 tcp,tcp6 metad superuser
100230 1 tcp,tcp6 metamhd superuser
100231 1 ticots,ticotsord,ticlts - superuser
100234 1 ticotsord gssd superuser
100235 1 tcp,tcp6 - superuser
100242 1 tcp,tcp6 metamedd superuser
100249 1 ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 - superuser
300326 4 tcp,tcp6 - superuser
300598 1 ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 - superuser
390113 1 tcp - unknown
805306368 1 ticots,ticotsord,ticlts,tcp,udp,tcp6,udp6 - superuser
1289637086 1,5 tcp - 26069
Die folgenden zwei Beispiele zeigen, wie Informationen über einen bestimmten RPC-Service gesammelt werden, indem ein bestimmtes Übertragungsverfahren auf einem Server ausgewählt wird. Im ersten Beispiel wird der mountd-Service überprüft, der über TCP ausgeführt wird. Im zweiten Beispiel wird der NFS-Service überprüft, der über UDP ausgeführt wird.
% rpcinfo -t bee mountd program 100005 version 1 ready and waiting program 100005 version 2 ready and waiting program 100005 version 3 ready and waiting % rpcinfo -u bee nfs program 100003 version 2 ready and waiting program 100003 version 3 ready and waiting
Dieser Befehl wird oft verwendet, um zu prüfen, ob im Netzwerk Pakete vorhanden sind. Der Befehl snoop muss als root ausgeführt werden. Mit dem Befehl kann sichergestellt werden, dass die Netzwerkhardware sowohl auf dem Client als auch auf dem Server funktioniert. Zahlreiche Optionen stehen zur Verfügung. Weitere Informationen finden Sie auf der Manpage snoop(1M). Es folgt eine kurze Darstellung des Befehls:
snoop [ -d device ] [ -o filename ] [ host hostname ]
Gibt die lokale Netzwerkschnittstelle an.
Speichert alle erfassten Pakete im Dateinamen.
Zeigt nur Pakete an, die an einen bestimmten Host und von diesem gesendet werden.
Die Option -d device ist auf Servern hilfreich, die mehrere Netzwerkschnittstellen haben. Sie können viele Ausdrücke verwenden, anstatt den Host zu definieren. Durch eine Kombination von Befehlsaudrücken mit grep können Daten generiert werden, die spezifisch genug für eine nützliche Verwendung sind.
Stellen Sie bei der Fehlerbehebung sicher, dass Pakete an den richtigen Host und von diesem gesendet werden. Achten Sie auch auf Fehlermeldungen. Durch das Speichern der Pakete in einer Datei kann das Prüfen der Daten vereinfacht werden.
Sie können diesen Befehl zum Prüfen verwenden, wenn ein Prozess hängt. Der Befehl truss muss vom Eigentümer des Prozesses oder vom root-Benutzer ausgeführt werden. Sie können viele Optionen in Verbindung mit diesem Befehl verwenden. Weitere Informationen finden Sie auf der Manpage truss(1). Es folgt eine kurze Syntax des Befehls:
truss [ -t syscall ] -p pid
Wählt Systemaufrufe aus, die verfolgt werden sollen.
Zeigt die PID des Prozesses an, der verfolgt werden soll.
syscall kann eine durch Komma getrennte Liste von Systemaufrufen sein, die verfolgt werden sollen. Wenn syscall mit ! gestartet wird, werden die aufgelisteten Systemaufrufe aus der Ablaufverfolgung ausgeschlossen.
Das Beispiel zeigt, dass der Prozess erst dann fortgesetzt wird, wenn eine Verbindungsanforderung von einem neuen Client eingeht.
# /usr/bin/truss -p 243 poll(0x00024D50, 2, -1) (sleeping...)
Im vorangegangenen Beispiel wird eine normale Antwort erzielt. Wenn sich die Antwort nicht ändert, nachdem eine neue Verbindungsanforderung gesendet wurde, hängt der Prozess möglicherweise. Führen Sie die unter So starten Sie die NFS-Services neu beschriebenen Schritte aus, um das hängende Programm wiederherzustellen. Gehen Sie nochmals die unter NFS-Fehlerbehebungsverfahren beschriebenen Schritte durch, um sicherzugehen, dass das Problem auf einen hängenden Prozess oder ein hängendes Programm zurückzuführen ist.
|