next up previous contents
Next: Beendigung Up: Modell für asynchrone Meldungen Previous: Dienstbereitstellung

Betriebsphase


 
Abbildung:  Zustandsdiagramm für das Bearbeiten eines Auftrags
44#44

Während des Betriebs des NFS-Dienstes sind vor allem Fehler-, Leistungs- und Sicherheitsaspekte die Grundlage für die Definition asynchroner Meldungen. Im Zustand «ready» wartet der NFS-Server auf Aufträge. In bestimmten Fällen sollte bei Eintreffen eines Auftrags eine Meldung erzeugt werden, wie folgende Aufzählung beschreibt:

Treffen mehr Aufträge für den Server ein, als die nfsd-Prozesse bearbeiten können, kommt es zur Überlastung (congestion) des Servers und zum Verlust von Aufträgen. Unter dieser Bedingung sollte das Eintreffen weiterer Aufträge die Meldung «nfs_request_rejected» auslösen. Im Modell ist die Parallelverarbeitung von Aufträgen durch mehrere nfsd-Serverprozesse nicht berücksichtigt. Eine genauere Abbildung der dynamischen Strukturen innerhalb eines NFS-Servers ist für diesen Zweck aber auch nicht erforderlich.

Das Eintreffen eines RPC-Auftrags bei einem nicht ausgelasteten Server führt zum Übergang von «ready» zu «process request». Dessen Unterzustände zeigt Abbildung 5.7. Vor dem Bearbeiten eines Auftrags durch den Server wird dieser auf der RPC-Schicht überprüft («check request»). Im Normalfall wird ein Auftrag nicht beanstandet und somit ausgeführt, womit wieder in den Zustand «ready» gewechselt wird. Für folgende Fehler bzw. unberechtigte Aufträge werden asynchrone Meldungen definiert:

badlen / header error:
Das Eintreffen von fehlerbehafteten Aufträgen führt neben der Erhöhung entsprechender Zähler zum Auslösen von Meldungen wie «nfs_req_badlen» oder «nfs_req_xdrcall».
bad user credentials:
Jeder NFS-Auftrag enthält eine Datenstruktur (credentials), die die User-ID und Group-IDs des Auftraggebers enthalten. Anhand dieser Datenstruktur bestimmt UNIX die Zugriffsrechte auf Dateien. Fehler in dieser Datenstruktur führen zur Zurückweisung des Auftrags und zur Meldung «nfs_req_bad_credentials(cause)». Cause beschreibt die Ursache wie z.B. ,,Benutzer unbekannt`` oder ,,Zu viele Gruppen``.
bad access:
Aufträge, die von Client-Maschinen stammen, denen der Zugriff nicht gestattet ist. Meldung: «nfs_req_bad_access(Host)»
readonly violation:
Schreibversuche auf Dateisystemen, die mit der Option «read-only» exportiert wurden. Meldung: «nfs_req_readonly(Host)»
invalid port:
Aufträge eines NFS-Clients, der einen nicht privelegierten UDP-Port benutzt. Meldung: «nfs_invalid_port(Port, Host)»

Meldungen, die von einzelnen Aufträgen erzeugt werden, können zu einer Überflutung des Managers führen, wenn fehlerhafte oder nicht berechtigte Aufträge gehäuft auftreten. Vorstellbar wäre auch die Definition von Schwellwerten für obige Klassen von Aufträgen. Dann könnte eine entsprechende Meldung erzeugt werden, wenn eine Absolutanzahl oder eine bestimmte Rate von Aufträgen einer Klasse überschritten wird.


 
Abbildung:  Zustandsdiagramm für die Prüfung von Export-Kommandos
45#45

In einem eigenen Diagramm in Abbildung 5.8 wird die Behandlung von Export- bzw. Unexport-Kommandos durch den Server modelliert, da diese nicht über die RPC-Schnittstelle abgewickelt werden. AIX sieht hierfür eigene Kommandos mknfsexp und rmnfsexp vor. Eine Überwachung des NFS-Dienstes durch eine Managementanwendung sollte auch diese Kommandos abdecken. Trifft während der Laufzeit des Servers eine Anforderung zum Export eines Dateisystems auf, sollte auch hier die Existenz und Lokalität des Dateisystems überprüft werden. Im Fehlerfall wird wiederum eine Meldung an den Manager gesendet. Soll während des Betriebs der Export eines Filesystems durch ein Unexport-Kommando zurückgenommen werden, sollte der Server anhand seiner Tabelle der von Clients importierten Dateisysteme überprüfen, ob dieses Dateisystem gerade in Benutzung ist. Für diesen Fall wird die Meldung «nfs_unexp_fs_used» vorgesehen.


next up previous contents
Next: Beendigung Up: Modell für asynchrone Meldungen Previous: Dienstbereitstellung
Copyright Munich Network Management Team