next up previous contents
Next: Filesystem Up: 5.1.3 Optimierung des Objektmodells Previous: 5.1.3 Optimierung des Objektmodells

NFS-Server

Die Klasse NFS_Server wird im optimierten Modell von der generischen Klasse Server abgeleitet. Es gelten folgende Entsprechungen für die Attribute der generischen Klasse und der alten Klasse NFSServer:

Request:
Entspricht dem Zähler calls aus der Statistik von nfsstat
Reject:
Die Anzahl der zurückgewiesenen Aufträge kann beim NFS-Server nicht bereitgestellt werden. Hierzu müßte die Anzahl der verlorenen Pakete bei Überlauf des UDP-Socketpuffers ermittelt werden.
Accept:
Entspricht ebenfalls dem Zähler calls der NFS-Schicht, da für Reject der Wert 0 angenommen werden muß.
Utilization
: Für die untersuchte Implementierung kann nicht ermittelt werden, wieviele nfsd-Serverprozesse gerade einen Auftrag bearbeiten.
Depart:
Da Utilization nicht ermittelt werden kann, kann Depart aufgrund der kurzen Verweilzeit der Aufträge im Server mit Accept gleichgesetzt werden.
Delay:
Die Bearbeitungszeit des letzten Auftrags ist ebenfalls für diese Implementierung nicht ermittelbar. Es gibt aber NFS-Implementierungen, die ein Log über die letzten n bearbeiteten Aufträge führen. Dort wird auch die Bearbeitungszeit angegeben.
Bad:
Dieses Attribut entspricht der Summe aus badlen und xdrcall.
Error:
Für dieses Attribut liefert netstat keine Information. Möglicherweise können solche Fehler durch Überwachen der Daemon-Klasse des UNIX-Systemlogs syslog identifiziert werden.
NotAuthorized:
Entspricht dem Zähler badcalls.

Der Zustand des Servers wird über die Statusattribute, die von der Klasse compObject geerbt werden, ausgedrückt.

OperationalState:
Die Betriebsbereitschaft kann, wie oben beschrieben, durch Kontrolle der Existenz der Serverprozesse und durch die Null-Prozedur der RPC-Schicht ermittelt werden.
UsageState:
Da keine Aussagen über die Nutzung gemacht werden können, hat dieses Attribut stets den Wert «unknown».
AdminState:
Ein NFS-Server kann nur durch das Betriebssystem gesperrt werden. Hierzu muß allen Prozessen das Signal «Stop» gesendet werden. Dies entspricht dem Zustand «locked». Der Normalzustand während des Betriebs ist «unlocked».

Durch das schreibbare Attribut NumberOfNfsd kann die Anzahl der nfsd-Serverprozesse dynamisch verändert werden. Dies erlaubt das AIX-Kommando chnfs. Ebenfalls kann die Größe des Socketpuffers durch das schreibbare Attribut BufferSize verändert werden. Das Attribut Nullrecv verbleibt ebenfalls in der Klasse NFS_Server. Es folgt die Beschreibung der Methoden:

create:
(Methode ererbt von Object.) Erstmaliges Einrichten des Servers durch Anpassen der Bootskripten. AIX-Kommando: mknfs -B
delete:
(Methode ererbt von Object.) Stoppen aller Serverprozesse, Entfernen der Einträge aus den Bootskripten, Löschen der Datei /etc/exports. AIX-Kommando: rmnfs -B
start:
(Methode ererbt von Server.) Starten aller Serverprozesse. AIX-Kommando: mknfs -N
stop:
(Methode ererbt von Server.) Stoppen aller Serverprozesse. AIX-Kommando: rmnfs -N
listRemoteMounts:
Listet alle von Clients importierten Dateisysteme des Servers auf. AIX-Kommando: showmount -a
listExports:
Listet alle von diesem Server exportierten Dateisysteme auf. AIX-Kommando: lsnfsexp
resetCounter:
Setzt die Zähler für die Auftragsstatistiken zurück. AIX-Kommando: nfsstat -sz

Jeder Client, der ein Dateisystem des Servers importiert, wird im optimierten Modell durch eine Instanz der Klasse RemouteMountInfo repräsentiert. Die Liste wird über die 1:n-Aggregation zwischen NFS_Server und RemoteMountInfo modelliert. Es entfällt die Klasse remoteMountTabEntry.

Im ersten Modell wurde der Export eines Dateisystems durch einen Server durch Instantiierung der abgeleiteten Klasse NFSFilesystem beschrieben. Durch den Export wird aber in Wirklichkeit kein neues Filesystem erzeugt, sondern nur eine Berechtigung für Clients zum Import eines bestehenden Filesystems geschaffen. Aus diesem Grund wird die neue Klasse ExportOptions als Beziehungsklasse zwischen NFS_Server und Filesystem eingeführt und die Methode export() der Klasse Filesystem zugeordnet. Ein Export entspricht jetzt dem Schaffen einer exports-Assoziation zwischen einer Instanz eines NFS-Servers und eines Filesystems. Hierdurch wird die Klasse ExportOptions instantiiert, die als veränderbare Attribute die Exportoptionen für das Dateisystem besitzt. Streng genommen kann durch obige Assoziation nur der Export kompletter Filesysteme modelliert werden. Um das Modell nicht unnötig zu komplizieren, wird durch das zusätzliche Attribut ExportPath festgelegt, ob das gesamte Filesystem oder nur ein Teilbaum davon exportiert wird.

Das ebenfalls neue Attribut Mode der Klasse ExportOptions kann die Werte «read-only», «read-write» und «read-mostly» einnehmen. Letzterer Wert schränkt das Schreibrecht auf bestimmte Clients ein. Berechtigungslisten (access control lists) werden im neuen Modell durch die wiederverwendbare generische Klasse AccessControl modelliert. Das Attribut Right bezeichnet die vergebene Berechtigung. Subject ist die Liste der Subjekte, die die angegebene Berechtigung besitzen. Zum Hinzufügen und Löschen von Subjekten von der Berechtigungsliste sind die Methoden add_subject() und delete_subject() vorgesehen. Der Klasse ExportOptions sind genau zwei bzw. drei Berechtigungslisten zugeordnet. Eine für die Liste der zugangsberechtigten Clients ( Access), eine für die Clients mit Superuser-Rechten (Root) und eine für die Clients mit Schreibberechtigung, falls das Dateisystem mit dem Modus «read-mostly» exportiert ist. Die Methode zum Aufheben des Exports (unexport()) wird ebenfalls der Beziehungsklasse zugeordnet, da ein ,,Unexport`` nur sinnvoll ist, wenn ein entsprechender Export - also eine Instanz von ExportOptions - existiert.


next up previous contents
Next: Filesystem Up: 5.1.3 Optimierung des Objektmodells Previous: 5.1.3 Optimierung des Objektmodells
Copyright Munich Network Management Team