Home Themengebiete... Themengebiete... Tips (Client)

2.1 Tips (Server)


2.1.1 name space: Lange Dateinamen

< TopTen! >

Das Filesystem eines NetWare-Servers emuliert normalerweise eine DOS-Maschine. Er reserviert deshalb für Dateinamen nur 11 Zeichen (8.3)

Wenn man aber Win95-, Windows NT -, OS/2- oder Macintosh-Dateien auf dem Server speichern will, dann müssen die systemspezifischen Dateiinformationen und Dateinamen wie z.B. Win / OS/2 Dateinamen (255 Zeichen) oder Macintoshdateinamen (32 Zeichen incl. Blanks) und ResourceForkInformationen irgendwo gespeichert werden.
Das geschieht durch Einsatz des 'NAME SPACE', der genügend Freiraum für das jeweilige Dateisystem zur Verfügung stellt.

Dieser Name Space muß pro Volume und Betriebssystem angelegt werden durch

  1. einmaliges Laden des Namensunterstützungs-NLMs (z.B. load OS2.NAM (das jeweilige .NAM wird später automatisch geladen)

  2. einmaliges Einrichten des 'NAME SPACE' auf einem Volume durch:
    ADD NAME SPACE <name space> [TO [VOLUME]] <volume name>

ein name space kann sein

Die eingerichteten Name Spaces kann man sich durch VOLUMES an der Fileserver Console anzeigen lassen.

Bei NW 3.11 muß man noch einen Patch aus 311PTx.EXE einspielen: OS2OPNFX.NLM. Dieser Patch wird auch mit dem Netware Client 32 für Windows 95 mitgeliefert.

Durch die längeren Dateinamen ist auch der Arbeitsspeicherbedarf des File Servers größer.

Wer VREPAIR auf einem Volume mit Name Space laufen lassen will, muß zuvor die passende Namespace Erweiterung für VREPAIR laden. (LOAD V_OS2, V_MAC, V_NFS)

Einen Name Space kann man mit folgendem Befehl wieder entfernen:

Load vrepair - Vrepair Options - Remove name space support

2.1.2 DEFRAG unter Netware

Für NetWare 3.xx oder 4.xx gibt es keinerlei Defragmentier-Programme.

Novell selbst gibt an, daß durch eine spezielle Zugriffstechnik ('elevator seeking') ein optimaler Zugriff auf die Daten gewährleistet ist, der kein Defragmentieren benötigt.

Es wird wohl auch keine Drittfirma etwas derartiges anbieten (können), da Novell die Filestrukturen bisher nicht veröffentlicht hat.

2.1.3 Server als Arbeitsplatz unter DOS !?

Kann man auf einem Novell-Server einen Arbeitsplatz unter DOS einrichten oder geht das nur auf im Netz befindlichen Arbeitsplätzen?

Bei NetWare < V3.0 kann der Server "nicht-dediziert" betrieben werden, d.h. außer dem Server-Task kann auch mit DOS gearbeitet werden. (man muß aber nicht)

Einschränkung: auf dem Server-Arbeitsplatz können nur Programme im REAL-Mode verwendet werden. Windows läuft nur bis Version 3.0 im REAL-Mode. Außerdem ist natürlich hier der Server viel gefährdeter, wenn das im Vordergrund laufende DOS-Programm abstürzt!

NetWare v3.0 - v3.12 kann nur "dediziert" betrieben werden.

NetWare v4.x kann als TASK unter OS/2 in Verbindung mit NetWare für OS/2 "nicht-dediziert" betrieben werden, ansonsten nur dediziert.

PROBLEME:

2.1.4 Speicher wird erst nach Tagen knapper

Es ist nicht weiter verwunderlich, daß ein knapp mit Speicher ausgerüsteter Server erst einige Zeit läuft, bevor er Fehler zeigt oder sogar mit einem Abend abstürzt. Wie aus der Dokumentation zu entnehmen ist, wird von den file cache buffers neben den für cache nonmovable- (NLMs), cache movable- (hash Tables, FATs und Directory- Einträge), permanent- (communication- und directory cache buffers) und semi-permanent-memory-pool (LAN- und disk-driver) auch noch Speicher für alloc short term memory entnommen.
Diese kurzfristigen Zuordnungen werden für drive mappings, SAP- und RIP-Tabellen, Druckerwarteschlangen und Informationen über die user connections benötigt und bei Freigabe nicht wieder an die file cache buffers zurückgegeben (nicht mehr benötigter Speicher kann hierbei nur noch innerhalb des alloc short term memory weiterverwendet werden).
Es ist leicht nachzuvollziehen, wie sich das im Laufe der Zeit auf die Speicherbereiche des Servers auswirkt und welche Folgen es hat, wenn die file cache buffers sehr knapp bemessen sind.

2.1.5 Fileserver-Resourcen

Richtwerte für die Fileserver-Resourcen:

Ganz wichtig ist auf jeden Fall der Wert der Cache Buffers, die sollten ca. 50% haben. Bei unter 20 % wird es da schon sehr knapp und auch gefährlich für die Stabilität.

Ich kenne die folgenden Werte :

Wobei dieser Wert von der gesamten Plattenmenge abhängt. Bei großen Datenbeständen verändert sich die Berechnung.

Während die Wahrscheinlichkeit, daß eine Datei ein zweites Mal angefordert wird, bei ca. 2GB Volumes noch relativ groß ist, sieht das bei 8 GB mit mehreren Tausend Dateien anders aus.

2.1.6 SCSI-Platten-Problem

WARNING! Volume BIG last segment (0) ends at x instead of y

hier der passende Auszug aus der NSEPro:

Explanation:

The segment ends at a block which is incorrect based on the operating system's calculation of where the segment begins and how large it is.

Action:

None. This message is for information only.

2.1.7 Drive deactivated due to ...

1.1.10 Device #0 (5B010) xxxxxxxxx-deactivated due to drive failure.

Diese Fehlermeldung deutet auf ein Hardware-Problem hin. Novell konnte während des Backups nicht mehr auf die Platte zugreifen und hat sie deshalb deaktiviert. Wenn die Platte auch das SYS-Volume enthält, geht danach auf dem Server überhaupt nichts mehr.

Mögliche Ursachen für die Deaktivierung währen:

Lösungsvorschläge:

2.1.8 CONFIG.SYS im Server

< NEU! >

Man benötigt keine CONFIG.SYS beim Server!

Vor allem Programme wie HIMEM.SYS oder gar EMM386.EXE stellen den Speicher um, was der Netware als protected mode System gar nicht paßt. Auch FILES und BUFFERS Einstellungen oder Tastaturtreiber bringen (außer bei der Installation) gar nichts.

Bei manchen Installationen wird die HIMEM.SYS verwendet, damit der Speicher über 16 MB erkannt wird. Sobald aber mehr als 32 BM Speicher eingebaut werden, ergeben sich andere, viel größere Probleme. Außerdem gibt es bei Netware 3.1x und 4.x bereits Patches, die auch auf PCI File Servern den kompletten Speicher ohne REGISTER MEMORY erkennen.

Darüberhinaus gibt es ältere Versionen von Treibern für Plattencontroller, die noch einen Eintrag in der CONFIG.SYS benötigen. Hier empfiehlt es sich dringend, aktuelle Versionen der Treiber zu besorgen.

2.1.9 Salvage-Problem

Wenn auf einem Volume (bei mehreren im Server) die Meldung kommt, daß keine Rechte vorliegen, um Dateien aus gelöschten Verzeichnissen zurückzuholen, obwohl man als Supervisor angemeldet ist, dann gibt es auf diesem Volume kein Verzeichnis /DELETED.SAV mehr, in dem diese Dateien normalerweise liegen.

Wenn man dieses Verzeichnis neu anlegt und am besten wie im Original auf System und Hidden setzt, kann SALVAGE in Zukunft auch wieder Dateien aus gelöschten Verzeichnissen zurückholen.

2.1.10 Fehlermeldung: Insufficient directory space

Nach dem Installieren eines neuen Volumes und anschließendem Kopieren von größeren Datenmengen auf dieses Volume kam folgende Meldung: 

 6/30/95 4:33:20 pm  Severity = 5.
 1.1.39 Cache memory allocator out of available memory.

Da gibt es zwei Möglichkeiten:

  1. Das neue Volume ist so groß, daß ihr das Server RAM erweitern müßt, um ordentlich damit arbeiten zu können.

  2. Ein neues Volume hat zunächst ganz wenig Directory entries (64 Stück). Die werden erst on-the-fly während des Betriebs vergrößert, während man auf dem Volume arbeitet. Kopiert man schon ganz zu Beginn ganz viele Files auf ein neues Volume, dann gehen ihm die Verzeichniseinträge aus, weil er mit dem Erstellen irgendwie nicht nachkommt. Abhilfe: ein paarmal mittelmäßig viele Files daraufkopieren und gleich wieder löschen. Ruf mal volinfo auf und schau Dir währenddessen die Anzahl der belegten und freien Verzeichniseinträge an.

2.1.11 NCP Packet Signature

(wurde ab NW 3.12 eingeführt, weil die NW 3.11, die diese Funktion nicht hatte, "geknackt" wurde.)

Bereits beim Verbindungsaufbau wird ein Schlüssel für diese Verbindung vereinbart. Aus diesem Schlüssel, der niemals über das Netz geht, wird eine "NCP Paket Signature" ermittelt. Diese Signature wird an jedes Paket gehängt, welches in Zukunft ausgetauscht wird. Pakete ohne oder mit der falschen Signature werden verworfen. Der Level der Kontrolle läßt sich an Fileserver und Workstation einstellen. (Level 0 - 3). Je höher der Level, desto höher die Security. Die Performance fällt bei höherem Level.

Unter NW 3.11 kann man mit dem "PBURST.NLM" die Signature ebenfalls benutzen. Man muß aber auf jeden Fall auf der Clientseite mit den VLMs arbeiten, weil die NETX die Packet Signature auch nicht beherrscht.

Anmerkung:

Wenn man eine Anwendung am Laufen hat, die NetBIOS braucht, wirft der Server alle diese Pakete als "unsicher" kommentarlos weg. Dies nur als Warnung...

2.1.12 Unterschiede NW 3.11, 3.12, 4.xx

Neuerungen in Version 3.12 gegenüber 3.11:

Neuerungen ab Version 4.0x:

Neuerungen ab Version 4.11:

2.1.13 Probleme bei BINDFIX

Wenn beim Durchführen von BINDFIX die Meldung "Cannot Write *.old Files" kommt, hat das meist folgenden Grund:

Wie Du nach dem Lauf von BINDFIX sehen kannst, erstellt dieses Utility bei jedem Lauf drei Dateien (NET$OBJ.OLD, NET$PROP.OLD und NET$VAL.OLD), um ggf. die ursprüngliche Bindery wiederherstellen zu können. Wenn diese Dateien anschließend mit einem Schreibschutz versehen wurden (evtl. unbeabsichtigt mit dem Utility FLAG), kann ein neuer Lauf von BINDFIX natürlich seine Sicherungsdateien nicht mehr erstellen.

2.1.14 SPEED

Zusammenstellung einiger SPEED Werte:

386SX16 (*):

95

386DX16 (*):

120

386DX25:

109 - 150 (je nach Waitstates)

386DX33:

322

386DX40:

305, 367 - 397

486SX25:

687

486DX33:

879, 905 - 915

486DX50:

1340 - 1375

486DX/2 66:

1834

486DX/2 80:

ca. 2100

486DX4-100 (AMD):

2745

AMD 5x86:

3658

Pentium60:

3294

Pentium90:

3456, 4246 - 4954

Pentium100:

4915-5467

Pentium120:

6604

Pentium133:

7323

Pentium166MMX:

9174

PPro150:

12350

Die Spanne zeigt jeweils den kleinsten und größten (sinnvollen) Wert, der mir gemeldet wurde inkl. einiger Ausreißer. SPEED kann auch nachträglich an der Console manuell gestartet werden und zeigt eine kurze Info und Vergleichswerte ( (*), s. oben) an.

SPEED wird automatisch beim Hochfahren des Servers gestartet und dient hauptsächlich als Indiz, ob folgende Einstellungen in Ordnung sind:

2.1.15 EISA Server mit > 16 MB

Bei EISA-Boards muß bzw. sollte REGISTER MEMORY nicht angeben werden, wenn der Speicher im EISA-Setup richtig angemeldet ist. Auch die Tricks mit AUTOEXEC.NCF auf C: müssen nicht angewandt werden.

Es gibt allerdings EISA-Rechner, bei denen der Speicher scheinbar nicht korrekt angemeldet wird. Für diese Rechner gilt in Bezug auf Speicherreservierung oberhalb 16 MB dasselbe wie für ISA-Rechner. (siehe Tip von Adaptec bzgl. Speicher ISA-Rechner >16MB)

2.1.16 Workstation Überwachung

Eine Möglichkeit, mit der man überwachen kann, ob sich eine Workstation aufgehängt bzw. keine Verbindung mehr mit dem Server hat:

Setze in der autoexec.ncf die Zeile

set console display watchdog logouts=on

Damit bekommt man auf der Console folgende Zeilen:

1/2/96 12:05pm: 1.1.x User xx on station x cleared by connection watchdog
Connection cleared due to communication or station failure

Die Zeit, nachdem Netware die WS-Connection löscht, ist ebenfalls über einen SET-Parameter einstellbar.

2.1.17 Serverspiegelung (SFTIII)

SFT III heißt "System Fault Tolerance Level III" - das ist nach SFT I und SFT II die bisher höchste Sicherheitsstufe von NetWare, bei der Du nicht nur Festplatten spiegeln kannst, sondern ganze Server. Die werden über eine Hochgeschwindigkeits-Netzwerkverbindung gekoppelt und synchronisieren sich automatisch untereinander. Beide Server sollten weitgehend identisch sein. Wenn einer der beiden Server ausfällt oder gewartet wird, sollte automatisch der andere einspringen, ohne daß die Benutzer etwas merken.

Man benötigt zwei Server mit jeweils einer zusätzlichen Karte, über die sich die Server spiegeln und als eine SFTIII-Lizenz.

Beide Server sind im Normalzustand ständig gespiegelt, Platten und Hauptspeicher. Beim Ausfall eines Servers übernimmt der andere sofort die Kontrolle. Nachdem der Fehler behoben ist, kann der ehemals defekte Server wieder gestartet werden, er wird automatisch auf den aktuellen Stand gespiegelt, ohne daß auch hier die Benutzer etwas mitbekommen.

Achtung: Leider laufen nicht alle NLM's, die auf einem "normalen" Server auch auf einem SFTIII. Aber die wichtigsten Programme (Sicherung, Mailing...) funktionieren.

Außerdem gab es die SFT III bisher für NW 3.11 (nicht 3.12!), diese Version wurde von Novell aber wegen diverser Probleme eingestellt. Aktuell ist die Version für NW 4.11.

2.1.18 Plattensynchronisation

Nicht alle gespiegelten Partitionen auf diesem System sind synchronisiert

(bei Netware 4.1x bzw. die entsprechende Meldung auf englisch bei NW 3.1x)

Das bedeutet, daß es im Server gespiegelte Platten gibt, die durch einen Absturz nicht mehr synchron sind. Der Server kopiert, solange diese Meldung läuft, die "funktionierende" Partition auf die "kaputte", um sie wieder zu synchronisieren.
Am Ende gibt er auf der Konsole eine Meldung aus, daß er fertig synchronisiert hat. Je nachdem, wie groß die gespiegelte Platte ist, dauert das recht lange (bei 2 GB durchaus 2-3 Stunden). Und so lange ist auch der Zugriff der Clients auf diese Platte zwar möglich, aber relativ langsam, weil im Hintergrund die komplette Platte kopiert wird.

2.1.19 Loader cannot find Public symbol...

< TopTen! >

Viele Programme (NLMs) nutzen die Routinen, die von dem Modul CLIB.NLM zur Verfügung gestellt werden. Da dieses Modul mit der Zeit immer wieder erweitert wird, verursachen Anwendungen, die diese neuen Routinen ansprechen wollen, obigen Fehler.

Abhilfe: die neueste CLIB.NLM benutzen.

Manchmal kann es auch daran liegen, daß NLMs für NW 4.x programmiert wurden. Diese Version hat neue Routinen, die aber bei der NW 3.1x über die Module AFTER311.NLM/A3112.NLM zur Verfügung gestellt werden. Das Modul AFTER311.NLM muß deshalb bei manchen Programmen zuvor manuell geladen werden, A3112.NLM wird dann automatisch nachgeladen.

Für die Netware 4.x sind die Module in dem Novell-Patch LIBUP?.EXE enthalten, bei der Netware 3.1x neuerdings in einem eigenen Patchkit LIB312.EXE.

2.1.20 CDROM im Server

< TopTen! >

Aktuell ist die Version CDUP4.EXE bzw. CDISC.EXE (siehe unten)

Das CDROM.NLM aus CDUP4 funktioniert auch mit ATAPI CDROMs, wobei die mitgelieferten Disktreiber (im neuen HAM-Standard) verwendet werden müssen. AFTER311.NLM muß zuvor manuell geladen werden.

Schritte:

  1. Controllerunterstützung für die CD-ROM laden:

    1. bei SCSI: LOAD ASPICD (ASPI-Treiber für CD-ROM)
      bzw. LOAD ASPICD lun_enable=ff für CD-ROM-Wechsler
      "ff" steht dabei fuer die unterstuetzten LUNs (in Bitschreibweise). Sicherheitshalber aktiviert man eben alle (FFh=255)
      Man kann den aktuellen ASPICD.DSK von Adaptec übrigens auch für nicht-Adaptec- SCSI-Controller verwenden.

    2. bei IDE: LOAD IDECD

  2. LOAD AFTER311

  3. LOAD CDROM

  4. CD HELP gibt eine ausführliche Hilfeseite aus

  5. CD DEVICE LIST oder CD VOLUME LIST gibt eine Liste der verfügbaren CD-Roms aus.

  6. bei Bedarf: Volumename umbenennen mit CD RENAME /D=nummer neuer-name

  7. CD MOUNT [volume name|volume nummer] zum Mounten der CD-ROM
    (durch das Cachen der Verzeichnisinfos geht das Mounten ab dem zweiten Mal erheblich schneller)

  8. MAP x:=volumename: zum Ansprechen der CD-ROM am Client

Die Netware 3.11 wird übrigens bei der CDUP4.* nicht mehr unterstützt.

Es gibt von Novell auch eine andere Variante namens CDISC.EXE, die nur mit Netware 4.1x läuft, dafür aber eine bessere Funktionalität beinhaltet. Mehrere CD-ROM- Laufwerke können z.B. über ein Laufwerksmapping angesprochen werden und auch die Cachingfunktionen sind besser.

Alternativ kann man aber auch Mitsumi CD-ROMS (mit eigenem Controller) über das Programm MITSUMI.* von WKU, Köln ansprechen. Das funktioniert auch unter NW 3.11 und lt. Aussage einiger Leute auch mit Netware 4.1x. Dieses NLM ist mittlerweile Freeware, wird dafür aber nicht mehr supported.

2.1.21 Memory für Novell Server berechnen

Formel für die benötigte Speicherkapazität bei NW 3.1x:

0,023 * Platte (in MB) / Blocksize (in KB) + 2 MB (für Netware 3.11)
(bzw. 0,032 * usw., wenn mit Namespaces OS2, MAC oder NFS gearbeitet wird)

Bei 4K Blocksize für 3 GB: 0,023 * 3,0 * 1024 / 4 + 2 = 19,96
In der Praxis heißt das, daß 20 MB knapp sind, 24 MB dagegen reichen werden.

Bei 8K Blocksize für 3 GB: 0,023 * 3,0 * 1024 / 8 + 2 = 10,83
In der Praxis heißt das, das 16 MB dann genügen...

Dazu muß man aber IMMER noch die zusätzlich geladenen NLMs hinzurechnen, wie z.B. PServer, ArcServe, Netshield, MPR.

Bei Netware 4.x ist die Formel aufwendiger, da dort auch die Speicherverwaltung (u.a. wegen Blocksuballocation) komplizierter ist.

Der absolute Minimalwert liegt übrigens für die NW 3.1x bei 4 MB RAM, bei der NW 4.1x bei 8 MB, besser 16 MB.

2.1.22 lost hardware interrupts

< TopTen! >

Primary (Secondary) interrupt controller detected a lost hardware interrupt

Grob gesagt entsteht diese Meldung immer dann, wenn das anfragende Device seinen Interrupt verliert, bevor der Interrupt-Controller ein OK von der CPU bekommt.
Stehen Daten an, die das Interrupt-Device (z.B. eine Netzwerkkarte oder der HD-Controller) versenden muß, so gibt dieses Device eine Interrupt-Anfrage, einen Event, an den Interrupt-Controller PIC (Programmable Interrupt Controller) weiter.
Der PIC sammelt alle Events. Die CPU wird ihre derzeitige Aufgabe so bald als möglich zwischenspeichern und für diesen Service unterbrechen und fragt die Unterbrechung beim PIC an. Findet nun der PIC die Interrupt-Anfrage (EVENT) des Devices nicht mehr, erhalten wir einen "....lost hardware interrupt".

In einem 16-Bit-Rechner werden 2 PIC's eingesetzt: Primary (Int. 0-7) und Secondary = (Int. 8-15). Abhängig davon, welcher Interrupt verloren geht, bekommen wir entweder "Primary controller..." oder "Secondary ...".

Da das Interrupt-Device aber noch immer Daten zu versenden hat, wird es eine erneute Anfrage an den PIC senden ...., der wiederum erfragt bei der CPU einen Interrupt-Service ...., und so weiter ..., und so weiter. Damit erklärt sich auch, warum die Meldung eines verlorenen Interrupt durchaus mehrmals hintereinander am Monitor erscheinen kann.

Im nahen Zusammenhang steht auch die Meldung "Spurious hardware interrupt XX detected", die bei Systemen mit Shared-Interupt vorkommen kann.

Da im rechnerinternen Ablauf durchaus ein Int.-Request verloren geht, ist nicht immer ein Fehler vorhanden. Sollte die Meldung jedoch öfter erscheinen und der Datendurchsatz erheblich verlangsamt werden, müssen wir auf Ursachenforschung gehen.

Warum kann eine Interrupt-Anfrage verloren gehen?

Lösungsmöglichkeiten:

2.1.23 NW 3.1x mit >16 MB RAM

< TopTen! >

Man kann sich seit den Patchkits 311PTF.EXE bzw. 312PT8.EXE (oder neuer) mit Hilfe des LOADER Patches das Register Memory sparen, da durch ein Patchen der Server.exe der komplette Speicher erkannt wird. (mit diversen PCI-Rechnern getestet)

Ansonsten funktioniert folgendes Vorgehen:

Der nachfolgende Text bezieht sich nur auf ISA-Rechner, auf welchen Novell Netware nur bis zu 16 MB installierten Arbeitsspeicher selbständig erkennt und jeder weitere Arbeitsspeicher mittels dem Befehl "Register Memory" angemeldet werden muß. Hierbei sollte jedoch auch beachtet werden, das viele Mainboards mit VLB- oder PCI-Bussystem ebenfalls ISA-Rechner in diesem Sinne bleiben.

Sollte man unsicher sein, ob dieser Fall auf das eigene System zutrifft, so kann man dies auf folgende Art und Weise feststellen:

  1. Start des Servers manuell per "SERVER -NS"

  2. Eingabe eines beliebigen Servernamens

  3. Eingabe einer beliebigen "Internal Netnumber"

  4. Eingabe des Befehls "MEMORY" am Server-Prompt.

Sollten nun nur 16 MB (von z.B. 32MB) als "erkannt" gemeldet werden, so wird der nachfolgend beschriebene Weg notwendig werden.

Prinzipielles:

Netware 3.x lädt beim Mounten der Volumes die Verzeichnisinformationen dieser physikalischen Gebilde nach einer "Top/Down" Methode in den aktuell verfügbaren Arbeitsspeicher - also immer von der maximal verfügbaren Speicherobergrenze an abwärts. Da das Mounten des SYS-Volumes jedoch beim Laden des Festplattentreibers vollautomatisch erfolgt, kann dies unter Netware 3.x zu massiven Speicherproblemen führen. Denn - wie jeder Systembetreiber wissen sollte - läßt sich unter Netware 3.x der Arbeitsspeicher oberhalb 16MB erst in der AUTOEXEC.NCF (also nach Mounten des Volumes SYS) anmelden.

Lösung:

Sämtlicher verfügbarer Arbeitsspeicher muß bereits vor Laden des Plattentreibers (bzw. vor dem Mounten des Volumes SYS) dem System bekannt sein.

Wie geht dies?

Man gehe nach folgendem Schema vor:

  1. Entfernen der Plattentreiber aus der STARTUP.NCF im DOS-Startverzeichnis der SERVER.EXE

  2. Aufbau einer AUTOEXEC.NCF im gleichen DOS-Verzeichnis, in dem sich auch die SERVER.EXE liegt, nach folgendem Schema: 

       FILE SERVER NAME xxxx
   IPX INTERNAL NET 111111
   REGISTER MEMORY 1000000 xxxxxxx      (xxxxxxx => siehe unten)
   LOAD <PLATTENTREIBER>
   MOUNT SYS
   SYS:SYSTEM\AUTOEXEC.NCF

  3. Aufbau der "normalen" AUTOEXEC.NCF im Verzeichnis SYS:SYSTEM\
    Wie bisher - lediglich die Zeilen "FILE SERVER NAME" und "IPX INTERNAL NET" sollten (wenn Fehlermeldungen unerwünscht sind) weggelassen werden.

Resultat:

Durch den oben beschriebenen Weg erreicht man, daß vor dem Laden aller NLMs in den Arbeitsspeicher des Servers der gesamte verfügbare Speicher der Maschine dem System bekannt ist. Man vermeidet somit die normalerweise entstehenden Zerklüftungen des Speichers, welche unter Umständen zu massiven Problemen führen können.

Alle weiteren serverbasierenden Programme (Datensicherung usw.) können jedoch weiterhin (gemäß deren Standard-Prozeduren) mittels der AUTOEXEC.NCF im Verzeichnis "SYS:SYSTEM" geladen werden.

Parameter von REGISTER MEMORY: 

 register memory <startadress> <Länge>  (beide Zahlen in hex)

 decimal 16777216/1048576/65536/4096/256/16/1
 16Meg =  1          0     0     0    0   0 0  =1'000'000

Gesamtspeicher:    Befehl:

     24M           register memory  1'000'000  800'000
     32M           register memory  1'000'000  1'000'000
     48M           register memory  1'000'000  2'000'000
     64M           register memory  1'000'000  3'000'000
  usw.

2.1.24 Piepsen: Novell-Server Fehlermeldung

Ein Novell-Server 'piepst' (fast) immer, wenn an der Serverkonsole eine Meldung ausgegeben wird. Diese Meldungen werden i.d.R. (wenn das noch möglich ist) in das File-ServerError-Log geschrieben und können von dort aus wieder abgerufen werden.

Das File-ServerError-Log kann man sich wie folgt anschauen:

  1. als Supervisor anmelden

  2. Syscon aufrufen

  3. Supervisor-Options auswählen

  4. in dem Menue 'View File-Server Error Log' auswählen

2.1.25 Bindery open requested by ...

Beim Hochfahren des Servers erscheint grundsätzlich die Meldung:

BINDERY OPEN REQUESTED BY THE servername

Das ist keine Fehlermeldung, sondern eine Systemmeldung. Er sagt damit nur, daß der Server <Servername> gerade die Anforderung (Request) zum Öffnen der Bindery gegeben hat.

2.1.26 Reihenfolge in der AUTOEXEC.NCF

Die LAN-Treiber lade ich erst ganz am Ende des Mount-Prozesses aller Volumes, damit meine voreiligen User beim Einloggen vor dem Mounten aller Volumes nicht scharenweise anrufen, warum sie nicht auf das Laufwerk XYZ zugreifen können. Das spart Nerven, falls der Server in normalen Netzwerkbetriebszeiten neu hochgefahren werden muß.

2.1.27 Polling Process

Bei LOAD MONITOR -P / Processor Utilization wird beim Polling Process etwa 98% angezeigt.

In Multitasking-Umgebungen gibt es einen Task, der dann abläuft, wenn kein anderer Task Rechenzeit beansprucht. Meistens heißt der Task IDLE, Novell nennt ihn Polling Process. Mit anderen Worten: Der Server langweilt sich.

Laß mal Perform3 von allen Stationen laufen, während ArcServe sichert, dann geht der Polling-Prozess Richtung Null.

2.1.28 Server Console S/W

Wenn ich über RCONSOLE auf die Server-Console zugreife und das Monitor-NLM lade, ist das Bild auch auf meinem Color Workstationbildschirm schwarz-weiß. Allerdings sind die Meldungen diverser NLM's (z.B. vom CDROM) bunt!

Zwei Möglichkeiten:

  1. Du hast eine monochrome Karte (z.B. Hercules-kompatibel) im Server

  2. Es ist eine EGA bzw. VGA Karte, beim Einschalten war aber kein Farbmonitor angeschlossen, die Monitor-ID-Pins also unbeschaltet (das wird meines Wissens nicht von allen VGA-Karten ausgewertet)

Diese Information (Mono/Color Display) wird vom BIOS verwaltet und von diversen DOS-Programmen sowie den NLMs, die auf die Standard-Bibliotheken zur Fensterverwaltung aufbauen, genutzt.

CDROM.NLM kümmert sich nicht um diese Einstellung und schreibt immer Farbattribute (wodurch der Text auf einem Hercules-Monitor nicht gerade gut lesbar ist).

Wenn am Server gar kein Monitor vorgesehen ist, ist z.B. Abhilfe möglich, indem Pin 11 des VGA-Steckers auf Masse gelegt wird.

2.1.29 VREPAIR automatisieren

Man kann VREPAIR gleich mit einem Volume-Namen als Parameter aufrufen, z.B. VREPAIR SYS

Das klappt sowohl mit NW 4.x als auch mit der 3.12. (3.11 nicht getestet)

So nebenbei werden durch diese Art des Aufrufes alle Benutzerdialoge abgestellt und das aufrufende NCF-File solange angehalten, bis VREPAIR die Kontrolle wieder zurückgibt.

In Verbindung mit dem Laden des Disk-Treibers in der c:autoexec.ncf kann man also ein VREPAIR automatisch vor dem Mounten der Volumes durchführen lassen.

2.1.30 DOWN Batches

SHUTDOWN.NCF : 

   [Sonderbefehle, falls notwendig]
   down
   exit

REBOOT.NCF : 

   [Sonderbefehle, falls notwendig]
   remove dos
   down
   exit
(oder alternativ nur REMOVE DOS und Aufruf von SHUTDOWN)

RESTART.NCF : 

   {Sonderbefehle, falls notwendig]
   down
   restart server

Der letzte Befehl ist möglicherweise nicht allen geläufig, da er erst ab NW 4.1 klappt. NW 4.1x führt dabei exit aus und startet die server.exe sofort neu.

Gerade bei großen Serversystemen ist restart besser als reboot. z.B. bei einem gut ausgestatteten Server mit SCSI Komponenten. Darüber hinaus funktionieren bei "restart server" die Schalter -na -ns weiter.

2.1.31 802.2 / 802.3 Frames parallel auf dem Server

In einem bestehenden Netzwerk wird noch das 802.3-Frame verwendet. Die Einbindung neuer Stationen bzw. der Einsatz neuer Treiber erfolgt bereits mit dem 802.2 Frame. Man kann nun in einer Großaktion die Frames von Server und allen Arbeitsstationen gleichzeitig umstellen oder aber es werden (evtl. nur für eine Übergangszeit) beide Frames parallel gefahren. Das ist insbesondere dann (dauerhaft) notwendig, wenn Bootproms noch den alten Frame Ethernet_802.3 zum Booten benötigen.

Die Idee besteht darin, auf einer physikalisch existierenden Karte zwei logische Karten abzubilden, die je ein anderes Frame benutzen (hier am Beispiel NE2000 Karte): 

  LOAD NE2000 INT=3 PORT=300 Frame=Ethernet_802.3 Name=NETZ3
  LOAD NE2000 INT=3 PORT=300 Frame=Ethernet_802.2 Name=NETZ2
  BIND IPX TO NETZ3 NET=3
  BIND IPX TO NETZ2 NET=2

Die Pakete werden jetzt von der einen logischen Karte auf die andere "geroutet". Zu beachten ist dabei, daß mit dieser Konfiguration auf einem physikalischen Netzwerkstrang zwei logische Netzwerke verwaltet werden (unterschiedliche NET-Adressen im BIND-Befehl).

Nach der Umstellung des Netzwerkes auf den 802.2 Header in den Frames können dann die Einträge zur Konfiguration des 802.3-Frames gelöscht werden.

Die Speicherbelastung und Performanceeinbuße aufgrund von ein oder zwei zusätzlichen Protokollen ist kaum meßbar. Die Netzwerkkartentreiber werden physikalisch nur einmal geladen und von den Protokollen zusammen genutzt, das heißt es wird kein zusätzlicher Cache-Speicher zum Laden des NLMs belegt. Deshalb leidet auch keine Plattenperformance darunter.

2.1.32 richtige Server-Hardware

Die Diskussion in den Echos und Newsgroups laufen alle auf einen Nenner hinaus:

Ein Server muß problemlos laufen - das ist das oberste Gebot. Wenn er darüber hinaus auch noch schnell ist, schadet das auch nicht.

Während die einen jedoch NoName-Produkte empfehlen:

Ich setze hier in allen Servern Pentium PCI auf SOYO-Boards ein. Keinerlei Probleme. Die SOYO-Boards schneiden zwar je nach testender PC-Zeitschrift mal besser - mal schlechter ab, aber ihr einsamer Vorteil liegt darin, daß die völlig stabil laufen.
Inzwischen sollen auch ASUS-Boards absolut stabil laufen.

oder:

ich habe Erfahrungen mit Compaq und selbstgebauten Servern. Beide laufen problemlos. Nachteil der Compaq-Maschinen ist die Nichtkompatibilität zu "normalen" Rechnern. Wenn der Speicher erweitert werden soll, passen zum Beispiel nicht alle Module. Daher haben wir die neueren Server Marke Eigenbau. Bestückt sind sie mit Soyo-Boards und IBM- Platten. Asus-Boards hatten bei uns als Arbeitsstationen Probleme gemacht, danach sind wir nach Soyo gewechselt. Die Soyos laufen etwas konservativer, als die Asus (sprich ca. 2-3% langsamer), sind dafür absolut stabil. Quantum-Platten haben sich als nicht dauerlauffest gezeigt, gleiches gilt für NEC. IBM-Platten sind relativ laut, was bei einem Server aber nicht stört. Aber dafür arbeiten sie sehr stabil. Ihre Leistungsaufnahme ist sehr gering, was sich in einer geringen Temperatur bemerkbar macht.

und Markenprodukte folgendermaßen bewerten:

Du kannst auch einen Marken-Server kaufen. Ich habe mir mal erklären lassen, was die alles anders/besser machen, schon interessant, aber leider völlig unbezahlbar.

halten andere Marken-Produkte (COMPAQ, HP, SNI) für die richtige Wahl für einen Server:

So schlecht fährt man mit "vernünftiger" Hardware auch nicht. Ich setze schon seit Jahren Compaq Server ein und hatte noch keinen Defekt. Letzte Up-Time war 338 Tage.

Einig sind sich jedoch die meisten über die eingesetzte Hardware. Ein optimaler Server sollte folgende Komponenten beinhalten:

weitere Tips:

Bei Netzwerkkarte, SCSI-Controller usw. würde ich nie OEM-Versionen kaufen, sondern immer auf die Vollversion/Combo bestehen, denn die Treiber, CDs, Handbücher usw. braucht man dann doch irgendwann.
Auch die Platten sollten keine OEM Ware sein, denn die Hersteller geben meist 2 oder 3 Jahre Garantie, OEM Platten haben nur das halbe Jahr vom Händler.

Verlasse Dich auch nicht auf PnP, sondern stelle die Interrupts von SCSI-Controller und Netzwerkkarte manuell ein.

2.1.33 hohe IRQs bei Netware Servern

Es gibt unter der Netware öfters diverse Probleme (vor allem bei SCSI- und (E)IDE- Controllern), wenn man eine beliebige Erweiterungskarte mit IRQ 15 verwendet. Auch die Verwendung von IRQ 14 macht Schwierigkeiten, weil das der Standard-IRQ für den ersten (Onboard-) (E)IDE-Controller im System ist.

Sollte die Verwendung von IRQ 12 nicht klappen, so ist wahrscheinlich die PS/2-Maus im BIOS nicht deaktiviert worden.

2.1.34 Absturzursachen bei Netware Servern

2.1.35 4 GB Platte: nur 2.1 GB frei !?

Bei Novell-Volumes, die größer als 2,1 GB sind, zeigt DOS nur max. diese 2,1 GB als frei an, Anwendungen wie dBase 2.0 (DOS) bringen sogar Speicher-Voll- Fehler beim Neuerstellen von Indexen.

Das Problem hat eigentlich nichts mit Novell zu tun, sondern liegt in der Verwaltung von DOS, das in diesem Fall mit LongInts arbeitet und diese nur max. 2,1474.... GB (2^10 Byte) aufnehmen können. Der freie Platz ist natürlich trotzdem vorhanden.

Sollten Anwendungsprogramme trotzdem Probleme damit haben, bieten sich folgende Lösungsansätze an:

2.1.36 Netware Demoversionen

IntranetWare und IntranetWare SB:

Am besten direkt bei Novell Deutschland nachfragen. Dort gibt es (momentan) eine zeitbeschränkte 12-User-Version, die nach Ablauf dieser Zeit automatisch eine zeitlich unbeschränkte 2-User-Version wird. Scheinbar reduziert sich diese Version zwar auf eine Ein-User-Version, aber es können weiterhin zwei Benutzer darauf zugreifen!

In IntranetWare und IntranetWare for Small Business ist die Netware 4.11 enthalten.

NW 3.1x:

Eine Demoversion der Netware 3.1x gibt es nicht! Es gibt allerdings eine 2 User Runtime Version (sowohl NW 3.11 als auch NW 3.12), die mit dem Multiprotokollrouter (MPR) verteilt wird.

2.1.37 Probleme mit (E)IDE im Server

< NEU! >

Bei (E)IDE-Servern kommt es immer wieder vor, daß die Meldung can't write to FAT erscheint, zum Teil mit anschließendem Dismounten des betreffenden Volumes.

Der Fehler tritt oft nur bei starkem Zugriff in Verbindung mit vielen Schreib- und Lesevorgängen auf.

Zuerst sollt geprüft werden, welcher Plattentreiber geladen ist. Der ISADISK.DSK ist bei (E)IDE-Platten nicht zu empfehlen, aber auch vom IDE.DSK gibt es einen (mittlerweile schon älteren) Patch, der Probleme mit großen EIDE-Platten behebt. Einige Hersteller liefern auch einen eigenen Plattentreiber zum Controller/Board mit. Auch hier sollte nach aktuellen Versionen gesucht werden.

Eine andere Lösung ist das Ausschalten des Blockmodus im Rechner BIOS. Durch diesen Blockmodus schreibt der Controller blockweise auf die Platte. Dadurch gibt es unter Netware Timeouts, die obiges Fehlerverhalten hervorrufen.

Copyright © by Stefan Braunstein (sbraunst@POBoxes.com)
Letzte Aktualisierung am 1. Dezember 1997

Home Themengebiete... Themengebiete... Tips (Client)