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)
Teil III SLP (Service Location Protocol) - Themen
8. Planen und Aktivieren von SLP (Aufgaben)
9. Verwalten von SLP (Aufgaben)
Konfigurieren von SLP-Eigenschaften
Grundelemente der SLP-Konfigurationsdatei
Kommentarzeilen und Notationen
So ändern Sie Ihre SLP-Konfiguration
Modifizieren der Häufigkeit von DA-Advertisements und -Erkennungen
Beschränken von UAs und SAs auf statisch konfigurierte DAs
So beschränken Sie UAs und SAs auf statisch konfigurierte DAs
Konfigurieren der DA-Erkennung für DFÜ-Netzwerke
So konfigurieren Sie die DA-Erkennung für DFÜ-Netzwerke
Konfigurieren des DA-Takts für häufige Partitionen
So konfigurieren Sie den DA-Takt für häufige Partitionen
Verwenden verschiedener Netzwerkmedien, Topologien oder Konfigurationen
Verringern von SA-Neuregistrierungen
So reduzieren Sie SA-Neuregistrierungen
Konfigurieren der Multicast-Lebensdauereigenschaft
So konfigurieren Sie die Multicast-Lebensdauereigenschaft
So konfigurieren Sie die Paketgröße
Konfigurieren des Nur-Broadcast-Routing
So konfigurieren Sie Nur-Broadcast-Routing
Modifizieren von Zeitüberschreitungseinstellungen bei SLP-Suchanforderungen
Ändern der standardmäßigen Zeitüberschreitungseinstellungen
So ändern Sie standardmäßige Zeitüberschreitungseinstellungen
Konfigurieren der Zufallswartezeit
So konfigurieren Sie die Zufallswartezeit
Wann Bereiche zu konfigurieren sind
Überlegungen zum Konfigurieren von Bereichen
Multihoming-Konfiguration für SLP
Wann mehrere nicht gesteuerte Netzwerkschnittstellen zu konfigurieren sind
Konfigurieren mehrerer nicht gesteuerter Netzwerkschnittstellen (Übersicht der Schritte)
Konfigurieren der net.slp.interfaces-Eigenschaft
So konfigurieren Sie die net.slp.interfaces -Eigenschaft
Proxy-Advertisement auf Multihomed-Hosts
DA-Bereitstellung und Zuweisung von Bereichsnamen
Überlegungen zum Konfigurieren von mehreren nicht gesteuerten Netzwerkschnittstellen
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
In diesem Abschnitt wird die strategische Bereitstellung von DAs in einem Netzwerk beschrieben, in dem SLP ausgeführt wird.
SLP funktioniert nur in Verbindung mit den Basisagenten (UAs und SAs), aber nicht in Verbindung mit bereitgestellten DAs oder konfigurierten Bereichen. Alle Agenten, die keine spezielle Konfiguration aufweisen, verwenden den default-Bereich. DAs dienen als Cache für Service-Advertisements. Durch die Bereitstellung von DAs wird die Anzahl von Meldungen verringert, die über das Netzwerk übermittelt werden. Außerdem wird die Zeit reduziert, die erforderlich ist, um Antworten auf die Meldungen zu erhalten. Diese Funktion ermöglicht SLP, größere Netzwerke aufzunehmen.
Der Hauptgrund für die Bereitstellung von DAs ist die Verringerung des Multicast-Datenverkehrs und der Verzögerungen, die mit der Erfassung von Unicast-Antworten verbunden sind. In einem großen Netzwerk mit vielen UAs und SAs kann der mit der Serviceerkennung verbundene Multicast-Datenverkehr so stark zunehmen, dass das Netzwerk an Leistungsfähigkeit verliert. Durch Bereitstellen eines oder mehrerer DAs müssen UAs einzelne Serviceanforderungen an DAs senden, und SAs müssen sich mit DAs mithilfe von Unicast registrieren. Das einzige SLP-registrierte Multicast in einem Netzwerk mit DAs ist für die aktive und passive DA-Erkennung bestimmt.
SAs werden automatisch mit DAs registriert, die innerhalb der gemeinsamen Bereiche erkannt werden, sodass keine Multicast-Serviceanforderungen akzeptiert werden müssen. Multicast-Anforderungen in Bereichen, die nicht vom DA unterstützt werden, werden jedoch weiterhin vom SA beantwortet.
Serviceanforderungen von UAs werden einzeln an DAs versendet, anstatt diese mehrfach im Netzwerk zu versenden, wenn ein DA in den Bereichen des UA bereitgestellt ist. Dementsprechend wird das Multicast durch DAs in den Bereichen des UA reduziert. Wenn das Multicast für normale UA-Anforderungen entfällt, wird die Zeit, die für den Empfang von Antworten benötigt wird, bedeutend reduziert (von Sekunden auf Millisekunden).
DAs sind der Mittelpunkt für SA- und UA-Aktivitäten. Durch Bereitstellen eines oder mehrerer DAs für eine Reihe von Bereichen entsteht ein zentraler Punkt für die Überwachung der SLP-Aktivität. Durch die Verwendung der DA-Protokollierung ist es einfacher, Registrierungen und Anforderungen zu überwachen, als die Protokolle von mehreren im Netzwerk verstreuten SAs zu überprüfen. Sie können je nach zu bewältigenden Rechenlasten beliebig viele DAs für einen bestimmten Bereich oder mehrere Bereiche bereitstellen.
In Netzwerken ohne aktiviertes Multicast-Routing können Sie SLP für die Verwendung von Broadcast verwenden. Broadcasts sind jedoch sehr ineffizient, weil jeder Host die Meldung verarbeiten muss. Außerdem werden Broadcasts normalerweise nicht über Router weitergegeben. Dadurch können Services in einem Netzwerk ohne Multicast-Routing-Unterstützung nur im selben Teilnetz erkannt werden. Eine teilweise Unterstützung des Multicast-Routing führt dazu, dass die Erkennung von Services in einem Netzwerk inkonsistent ist. Multicast-Meldungen werden für die Erkennung von DAs verwendet. Eine teilweise Unterstützung des Multicast-Routing hat darum zur Folge, dass UAs und SAs die Services mit allen bekannten DAs im Bereich des SA registrieren. Wenn beispielsweise ein UA einen DA namens DA1 abfragt und der SA Services mit DA2 registriert hat, kann der UA keinen Service erkennen. Weitere Informationen zum Bereitstellen von SLP in Netzwerken ohne Multicast finden Sie unter Konfigurieren des Nur-Broadcast-Routing.
Bei einem Netzwerk mit inkonsistenter standortübergreifender Unterstützung des Multicast-Routing müssen Sie die SLP-UAs und SAs mit einer konsistenten Liste von DA-Standorten konfigurieren, indem Sie die net.slp.DAAdresseses-Eigenschaft verwenden.
Der SLPv2-DA von unterstützt auch die Interoperabilität mit SLPv1. Die SLPv1-Interoperabilität ist standardmäßig im DA aktiviert. Wenn in Ihrem Netzwerk SLPv1-Geräte (wie beispielsweise Drucker) enthalten sind oder Sie die Software Novell Netware 5 einsetzen, die SLPv1 für die Serviceerkennung verwendet, sollten Sie einen DA bereitstellen. Ohne einen DA sind die Solaris-SLP-UAs nicht in der Lage, von SLPv1 bekannt gegebene Services zu finden.
Stellen Sie DAs in Ihrem Unternehmen bereit, wenn eine der folgenden Bedingungen zutrifft:
Bei einer Messung mit snoop wurde festgestellt, dass der Multicast-SLP-Datenverkehr 1 Prozent der Bandbreite in Ihrem Netzwerk übersteigt.
Die UA-Clients müssen lange Verzögerungen oder Zeitüberschreitungen während der Anforderung von Multicast-Services in Kauf nehmen.
Sie haben vor, die Überwachung der SLP-Service-Advertisements für bestimmte Bereiche auf einem oder mehreren Hosts zu zentralisieren.
Ihr Netzwerk ist nicht Multicast-fähig und besteht aus mehreren Teilnetzen, die Services gemeinsam nutzen.
In Ihrem Netzwerk werden Geräte eingesetzt, die frühere Versionen von SLP (SLPv1) unterstützen, oder Sie planen, die SLP-Serviceerkennung in Verbindung mit Novell Netware 5 einzusetzen.
Wenden Sie das folgende Verfahren, an um die net.slp.isDA-Eigenschaft in der slp.conf-Datei auf True zu setzen.
Hinweis - Sie können nur einen DA pro Host zuweisen.
Rollen umfassen Autorisierungen und privilegierte Befehle. Weitere Informationen zu Rollen finden Sie unter Konfigurieren von RBAC (Übersicht der Schritte) in Systemverwaltungshandbuch: Sicherheitsservices.
# svcadm disable network/slp
net.slp.isDA=True
# svcadm enable network/slp
Dieser Abschnitt enthält Empfehlungen, wo DAs in verschiedenen Situationen bereitzustellen sind:
Wenn das Multicast-Routing nicht aktiviert ist und DAs benötigt werden, um die Serviceerkennung zwischen Teilnetzen zu ermöglichen
In diesem Fall muss ein DA auf einem Host mit Schnittstellen und allen Teilnetzen bereitgestellt werden, die Services gemeinsam nutzen. Die net.slp.interfaces-Konfigurationseigenschaft muss nicht definiert werden, es sei denn, IP-Pakete werden nicht zwischen den Schnittstellen weitergeleitet. Weitere Informationen zum Konfigurieren der net.slp.interfaces-Eigenschaft finden Sie unter Multihoming-Konfiguration für SLP.
Wenn DAs für die Skalierbarkeit bereitgestellt werden und dadurch in erster Linie der Agentenzugriff optimiert werden soll
UAs geben normalerweise viele Serviceanforderungen an DAs weiter. Ein SA registriert sich einmal mit einem DA und kann das Advertisement in periodischen, aber seltenen Intervallen aktualisieren. Dementsprechend erfolgt der UA-Zugriff auf DAs sehr viel häufiger als der SA-Zugriff. Auch ist die Zahl der Service-Advertisements normalerweise kleiner als die Zahl der Anforderungen. Darum lassen sich die meisten DA-Bereitstellungen effizienter gestalten, wenn sie für den UA-Zugriff optimiert werden.
Bereitstellen von DAs, sodass sie sich topologisch nahe bei den UAs im Netzwerk befinden, wodurch der UA-Zugriff optimiert wird
Natürlich müssen Sie den DA mit einem Bereich konfigurieren, der sowohl von den UA-Clients als auch von den SA-Clients genutzt wird.
Sie können mehrere DAs für dieselbe Gruppe von Bereichen zwecks Lastausgleich bereitstellen. Stellen Sie DAs in folgenden Fällen bereit:
UA-Anforderungen an einen DA lösen eine Zeitüberschreitung aus oder werden mit der Fehlermeldung DA_BUSY_NOW zurückgegeben.
Das DA-Protokoll zeigt, dass viele SLP-Anforderungen fallen gelassen werden.
Das Netzwerk der Benutzer, die gemeinsam die Services in den Bereichen nutzen, umspannt eine Reihe von Gebäuden oder physischen Standorten.
Sie können eine snoop-Ablaufverfolgung des SLP-Datenverkehrs durchführen, um festzustellen, wie viele UA-Anforderungen mit der Fehlermeldung DA_BUSY_NOW zurückgegeben werden. Wenn sehr viele UA-Anforderungen zurückgegeben werden, können UAs in Gebäuden, die physisch und topologisch vom DA entfernt sind, langsam antworten oder übermäßig viele Zeitüberschreitungen auslösen. In solch einem Fall können Sie in jedem Gebäude einen DA bereitstellen, um die Reaktionsfähigkeit der UA-Clients innerhalb des Gebäudes zu verbessern.
Leitungsverbindungen zwischen Gebäuden sind oft langsamer als lokale Netzwerke innerhalb von Gebäuden. Wenn Ihr Netzwerk mehrere Gebäude oder physische Standorte umspannt, setzen Sie die net.slp.DAAddresses-Eigenschaft in der /etc/inet/slp.conf-Datei auf eine Liste von spezifischen Hostnamen oder -adressen, damit die UAs nur auf die von Ihnen angegebenen DAs zugreifen.
Wenn ein bestimmter DA viel Hostspeicher für Serviceregistrierungen belegt, verringern Sie die Anzahl der SA-Registrierungen, indem Sie die Anzahl der Bereiche reduzieren, die vom DA unterstützt werden. Sie können einen Bereich, der viele Registrierungen aufweist, in zwei Teile aufteilen. Dann können Sie einen der neuen Bereiche unterstützen, indem Sie einen weiteren DA auf einem anderen Host bereitstellen.