Galileo Computing < openbook > Galileo Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Geleitwort zu diesem Buch
Inhalt des Buchs
1 Warum eine neue Server-Version?
2 Editionen und Lizenzen
3 Hardware und Dimensionierung
4 Protokolle
5 Was überhaupt ist .NET?
6 Installation
7 Core-Installationsoption
8 Active Directory-Domänendienste
9 Netzwerkdienste im AD-Umfeld
10 Active Directory Lightweight Directory Services (AD LDS)
11 Active Directory-Verbunddienste (Federation Services)
12 Active Directory-Zertifikatdienste
13 Active Directory-Rechteverwaltungsdienste (AD RMS)
14 »Innere Sicherheit«
15 Dateisystem und Dateidienste
16 Drucken
17 Webserver (IIS)
18 SharePoint (Windows SharePoint Services, WSS)
19 Remotedesktopdienste (Terminaldienste)
20 Hochverfügbarkeit
21 Datensicherung
22 Servervirtualisierung mit Hyper-V
23 Windows PowerShell
24 Windows 7 und Windows Server 2008 R2
Stichwort

Download:
- ZIP, ca. 104 MB
Buch bestellen
Ihre Meinung?

Spacer
<< zurück
Windows Server 2008 R2 von Ulrich B. Boddenberg
Das umfassende Handbuch
Buch: Windows Server 2008 R2

Windows Server 2008 R2
geb., 1.410 S., 59,90 Euro
Galileo Computing
ISBN 978-3-8362-1528-2
Pfeil 20 Hochverfügbarkeit
Pfeil 20.1 Vorüberlegungen
Pfeil 20.1.1 Allgemeines
Pfeil 20.1.2 Hardware und Konfiguration
Pfeil 20.2 Failover-Cluster
Pfeil 20.2.1 Aktiv – Passiv – n+1
Pfeil 20.2.2 Installation
Pfeil 20.2.3 Anwendungen hinzufügen
Pfeil 20.2.4 Cluster schwenken
Pfeil 20.2.5 Feinkonfiguration des Clusters und weitere Vorgehensweise
Pfeil 20.3 Network Load Balancing
Pfeil 20.3.1 Funktionsweise des Network Load Balancings
Pfeil 20.3.2 Installation und Konfiguration
Pfeil 20.3.3 Ein paar Hintergründe
Pfeil 20.3.4 Webserver, Kerberos und NLB
Pfeil 20.3.5 NLB-Troubleshooting allgemein
Pfeil 20.3.6 NLB im Terminalserver-Umfeld


Galileo Computing - Zum Seitenanfang

20.3 Network Load Balancing Zur nächsten ÜberschriftZur vorigen Überschrift

Nicht alle Aspekte der Verfügbarkeit lassen sich sinnvoll mit dem Failover-Cluster abdecken. Das Verfahren kommt immer dann zum Einsatz, wenn eine Ressource nicht »dupliziert« werden kann, sondern genau der eine Applikationsserver vorhanden sein muss. Typische Beispiele sind ein Exchange-Postfachserver oder eine SQL Server-Datenbank: Wenn ein Postfach auf dem Server Exchange01 liegt, hilft es dem Anwender bei einem Ausfall wenig, dass Exchange02 und Exchange03 noch funktionieren – auf sein Postfach kann er nicht zugreifen. Es muss also dafür gesorgt werden, dass genau die Ressource Exchange01 möglichst schnell wieder verfügbar wird. Dies kann, wie beim Failover-Cluster der Fall, durchaus auf anderer Hardware sein, die sich dann aber als Exchange01 meldet.

Andere Serverdienste werden nicht geclustert, obwohl sie nicht weniger wichtig sind. Einige Beispiele:

  • Das Active Directory können Sie sehr einfach dadurch redundant auslegen, dass Sie weitere Domänencontroller implementieren. Fällt ein Domänencontroller aus, greifen die Clients automatisch auf die verbliebenen zu. Der Anwender bemerkt den Ausfall nicht einmal. Im AD-Umfeld sind als Ausnahmen die Server zu nennen, die FSMO-Rollen ausführen. Steht eine FSMO-Rolle nicht zur Verfügung, leidet der »normale« Betrieb aber nicht darunter.
  • DNS: Auch in diesem Fall basiert das Redundanzkonzept auf der Fähigkeit der Clients, einfach den nächsten DNS-Server zu kontaktieren.

Die Dienste aus dem zuvor genannten Beispiel sind deshalb relativ einfach redundant auszulegen, weil die »Redundanz-Intelligenz« (d. h. »Wie verhalte ich mich beim Ausfall der Ressource?«) in den jeweiligen Clients implementiert ist.

Nun gibt es aber noch eine dritte Gruppe von Diensten, die durch folgende Kriterien zu beschreiben ist:

  • Der einzelne Server ist ersetzbar, d. h., der Dienst ist nicht so »einzigartig«, dass nicht ein anderer Server den Benutzer weiter bedienen könnte.
  • Der Client verfügt nicht über integrierte Failover-Mechanismen.
  • Neben dem Thema der Verfügbarkeit kommen die Anforderungen der Lastverteilung mit ins Spiel.

Der Dienst, der optimal durch diese Anforderungen beschrieben wird, ist die Bereitstellung von Webapplikationen:

  • Eine Webapplikation kann von mehreren Servern gleichzeitig bereitgestellt werden. Der einzelne Webserver holt im Endeffekt nur Daten aus Datenbanken, bereitet diese auf und schickt sie via HTTP an den Benutzer. Ob dieser mit Webserver01 oder Webserver02 verbunden ist, ist unerheblich.
  • Ist ein Client mit Webserver01 verbunden, kann er nicht erkennen, dass er die Webapplikation genauso gut von Webserver02 oder Webserver03 bekommen könnte.
  • Wenn viele Anwender auf einen Webserver zugreifen, kann diese Last von einem einzelnen Server (Hardware) unter Umständen nicht mehr getragen werden. Demnach muss ein Verfahren zur Lastverteilung gefunden werden. Der Punkt, ab dem ein einzelner Server nicht mehr ausreicht, verschiebt sich immer weiter nach unten. Zwar wird die Serverhardware leistungsfähiger, allerdings werden Webapplikationen deutlich komplexer – es reicht schon lange nicht mehr, statische Seiten anzuzeigen.

Ein zweites Beispiel sind die Terminaldienste. Für einen Benutzer ist es zunächst unerheblich, auf welchem Terminalserver »seine« Applikation läuft. Im Gegensatz zum Webserver-Beispiel kann innerhalb einer Sitzung nicht ohne Unterbrechung derselben der Server gewechselt werden, zunächst sind Terminaldienste aber ein typisches »Load-Balancing«-Szenario. Im Umfeld der Terminaldienste ist das Load Balancing der Microsoft Terminaldienste und des Citrix Presentation Servers (vormals Metaframe) zu unterscheiden:

  • Microsoft Terminaldienste nutzen ein netzwerkbasiertes Load Balancing, eben das Network Load Balancing.
  • Citrix verwendet ein applikationsabhängiges Load Balancing, bei dem in die Entscheidung, welchem Server die Anfrage zugeleitet wird, Kriterien wie die Auslastung von Servern etc. einbezogen werden.

Galileo Computing - Zum Seitenanfang

20.3.1 Funktionsweise des Network Load Balancings Zur nächsten ÜberschriftZur vorigen Überschrift

In Abbildung 20.41 ist die Funktionsweise des Network Load Balancings vereinfacht dargestellt:

  • Auf der rechten Seite sehen Sie vier Server, beispielsweise Webserver. Diese verfügen jeweils über eine eigene IP-Adresse (.191, .192 etc.).
  • Gewissermaßen »vor« den physikalischen Servern steht ein virtueller Server mit einer IP-Adresse. Hierbei handelt es sich allerdings im Grunde genommen nur um eine IP-Adresse, mit der die Clients Kontakt aufnehmen. Da aus Sicht eines Clients eine IP-Adresse stets einem Server zugeordnet ist, habe ich auf der Skizze einen solchen eingezeichnet – NLB ist aber letztendlich nur ein Algorithmus, der auf den »tatsächlichen Servern« ausgeführt wird.
  • Bei einer Anfrage eines Clients treffen die Server im Load-Balancing-Verbund eine Entscheidung, welcher Server die Anfrage bedient.

Abbildung 20.41 Funktionsweise des Network Load Balancing

Im Fall einer Webserver-Farm würde sozusagen hinter den Webservern noch ein Datenbankserver vorhanden sein, auf dem die Sitzungsinformationen der Benutzer gespeichert werden.

In einer Terminalserver-Farm würde ebenfalls eine zusätzliche Komponente gebraucht, nämlich der Server mit dem Session Directory (Sitzungsbroker).

Im Gegensatz zu einem Failover-Cluster sind für einen NLB-Cluster keine dedizierten LAN-Verbindungen für den Heartbeat o. Ä. notwendig. Außerdem gibt es keine gemeinsamen Speicherbereiche.

Wie bereits erwähnt wurde, benötigt Network Load Balancing keine weitere Hardware. Die Load-Balancing-Entscheidung, also welcher Server die Anfrage bearbeiten soll, wird durch einen Algorithmus getroffen, der unabhängig auf jedem Server des NLB-Verbunds ausgeführt wird.

Fällt ein Server des Verbunds aus, sendet er keine Heartbeat-Informationen mehr. Die übrigen Server werden dies bei der Berechnung berücksichtigen. Bis der Ausfall von den anderen Systemen bemerkt wird, vergehen in etwa 5 Sekunden.

Ein Network Load Balancing-Cluster ist durch seine verteilte Berechnungslogik bereits »per Design« sehr viel redundanter als eine Lösung, bei der der komplette Netzwerkverkehr durch eine »Blackbox« geleitet wird.

Network Load Balancing berücksichtigt nicht den Zustand der einzelnen Server in Hinblick auf Prozessor- und Speicherauslastung. Es ist aber deutlich intelligenter als ein einfaches Round-Robin-Verfahren.

Ein NLB-Cluster kann bis zu 32 Server umfassen.


Galileo Computing - Zum Seitenanfang

20.3.2 Installation und Konfiguration Zur nächsten ÜberschriftZur vorigen Überschrift

Die Installation eines NLB-Clusters ist im Normalfall unproblematisch. Im nächsten Abschnitt zeige ich Ihnen die notwendigen Schritte – nebst einiger Erläuterungen.


Hinweis

Es ist darauf hinzuweisen, dass es »ohne Weiteres« nicht möglich ist, auf einem einzigen physikalischen VMware Server oder ESX Server mehrere Knoten eines NLB-Clusters im Unicast-Modus zu installieren. Das Szenario macht in einer produktiven Umgebung auch herzlich wenig Sinn. Es könnte aber in der einen oder anderen Testumgebung ein Thema werden.

Zum Fehlerbild: Der NLB-Cluster kann zwar problemlos installiert werden, allerdings verlieren alle Konten bis auf einen die Netzwerkverbindungen.

Es gibt drei Möglichkeiten zur Abhilfe:

  • Man sorgt dafür, dass nicht zwei Knoten des NLB-Clusters auf demselben physikalischen Host laufen.
  • Oder: Man konfiguriert den NLB-Cluster als Multicast-Knoten.

NLB-Cluster einrichten

Der erste Schritt zur Einrichtung eines NLB-Clusters besteht darin, dass Sie das Feature Netzwerklastenausgleich auf allen Servern installieren, die dem NLB-Cluster hinzugefügt werden sollen. Prinzipiell wäre es zunächst nur auf dem ersten Knoten erforderlich, aber warum es nicht direkt überall erledigen? Die Installation besteht lediglich aus dem Hinzufügen des Features: Es werden bei diesem Schritt keinerlei Konfigurationen vorgenommen (Abbildung 20.42).

Abbildung 20.42 Der erste Schritt ist die Installation des Features »Netzwerklastenausgleich«. Diese muss auf allen beteiligten Servern erfolgen.

Die eigentliche Einrichtung des Clusters erfolgt im Netzwerklastenausgleich-Manager. Dieser findet sich bei Systemen mit installiertem NLB-Feature in der Verwaltung. Sie können die Einrichtung (und spätere Administration) übrigens auch ganz bequem vom Admin-PC aus erledigen – die Windows Server 2008-Administrationswerkzeuge für Windows Vista (Stichwort für die Suche im Download Center: Remote Server Administration Tools) enthalten ebenfalls den Netzwerklastenausgleich-Manager.

Die Einrichtung beginnt mit dem Aufruf der Funktion Neuer Cluster (Abbildung 20.43). Dort wählen Sie zunächst den ersten Server aus, der ein NLB-Clusterknoten werden soll. Auf der zweiten Seite des Assistenten führen Sie die für das NLB relevanten IP-Adressen des Servers auf (Abbildung 20.44). Das Network Load Balancing von Windows Server 2008 unterstützt – im Gegensatz zu den Vorgängerversionen – auch IPv6-Netzwerkadressen.

Abbildung 20.43 Die Einrichtung des Clusters erfolgt im »Netzwerklastenausgleich-Manager«.

Abbildung 20.44 Im Assistenten wählen Sie zunächst den ersten Knoten und die IP-Adressen aus.

Der Eintrag Priorität (eindeutige Host-ID) wird auf 1 festgelegt sein, und im Normalfall besteht kein Grund, dies zu ändern.

Auf der dritten Seite des Assistenten weisen Sie dem NLB-Cluster beliebig viele IP-Adressen zu. Dies können IPv4-Adressen, manuell eingegebene IPv6-Adressen oder automatisch generierte IPv6-Adressen sein. Wichtig ist, dass diese IP-Adressen noch nicht in Verwendung sein dürfen – sonst erscheint eine Fehlermeldung, und nichts funktioniert (Abbildung 20.45).

Abbildung 20.45 Eine oder mehrere IP-Adressen werden als Cluster-IP-Adressen angegeben. Diese Adressen dürften natürlich noch nicht anderweitig verwendet werden. Neu in Windows Server 2008 ist die Möglichkeit, auch IPv6-Adressen anzugeben.

Auf der nächsten Dialogseite des Assistenten entscheiden Sie im Bereich Clusterausführungsmodus, ob als Modus Unicast, Multicast oder IGMP-Multicast verwendet werden soll (Abbildung 20.46):

  • Multicast stellen Sie dann ein, wenn Sie Multicast-Anwendungen über die Cluster-IP-Adresse fahren möchten – das sagt ja auch der Name. Bei der Einrichtung des Clusters wird dann automatisch eine Multicast-Adresse erzeugt.
  • Weiterhin haben Sie die Möglichkeit, das IGMP (Internet Group Management Protocol) für den Multicast-Betrieb zu aktivieren. Dadurch wird erreicht, dass der für einen NLB-Cluster vorgesehene Datenverkehr nur durch die Ports geleitet wird, die für die Clusterhosts bestimmt sind, und nicht durch alle Switchports.

Abbildung 20.46 Wahl des »Clusterausführungsmodus«

Sofern Sie keine Multicast-Anwendungsszenarien implementieren, wählen Sie die Einstellung Unicast.

Ein weiterer wesentlicher Konfigurationsschritt ist die Festlegung der Portregeln (Abbildung 20.47). Sie definieren damit, auf welche Ports auf der Cluster-IP-Adresse reagiert wird, und vor allem, wie reagiert werden soll. Standardmäßig ist der Bereich von 0 bis 65 535 (also alle Ports) eingestellt, Sie können aber durchaus selektiver konfigurieren. In der Abbildung wird, da ich für das Beispiel einen NLB-Cluster für die Verwendung mit dem Internet Information Server baue, nur auf Port 80 »gelauscht«.

Mit dem Filtermodus wird angegeben, wie der NLB-Cluster sich für diesen Portbereich grundsätzlich verhalten soll:

  • Mehrfachhost: Eingehender Netzwerkverkehr, auf den diese Portregel zutrifft, wird über alle Knoten verteilt. Es findet also Load Balancing statt.
  • Einzelhost: Eingehender Netzwerkverkehr, auf den diese Portregel zutrifft, wird nur einem Knoten zugewiesen.
  • Die letzte Option ist das Deaktivieren des Portbereichs; wie nicht anders zu erwarten, führt das zum Blockieren der entsprechenden Pakete.

Abbildung 20.47 Sehr wichtig ist die Definition der Portregeln.

Beim Modus Mehrfachhost kann (bzw. muss) noch die Affinität konfiguriert werden:

  • Keine: In diesem Modus werden mehrere Verbindungen, die von einer IP-Adresse aufgebaut werden, zu verschiedenen Knoten gesendet.
  • Einfach: Bei dieser Einstellung, die übrigens die Standardeinstellung ist, werden die von einer IP-Adresse eingehenden Verbindungen immer demselben Knoten zugewiesenm.
  • Netzwerk: Diese Einstellung bewirkt, dass die Pakete, die aus einem Netz kommen, immer demselben Knoten zugewiesen werden. Diese Einstellung macht Sinn, wenn in einem Extranet-oder Internet-Szenario die Verbindungen von einem Kommunikationspartner über verschiedene Proxy-Server (die aber vermutlich alle in demselben Netz stehen) eingehen. In einem Intranet-Szenario, in dem vermutlich alle Anfragen aus demselben Netz kommen, ist diese Einstellung wenig sinnvoll, weil sie unter Umständen das Load Balancing völlig aufhebt.

Anzumerken wäre, dass Sie beliebig viele Portregeln definieren können. Der Gültigkeitsbereich einer Portregel lässt sich auf eine einzelne Cluster-IP-Adresse beschränken, so dass alle denkbaren Konfigurationsszenarien abzudecken sein sollten.

Nach Abschluss des Assistenten werden der Cluster und sein erster Knoten erzeugt. Wenn alles »richtig« gelaufen ist – und da gibt es normalerweise keine Probleme – sollte nach einer kurzen Dauer (5 bis 30 Sekunden) das in Abbildung 20.48 gezeigte Ergebnis zu sehen sein.

Abbildung 20.48 Der Cluster nebst erstem Knoten ist erfolgreich installiert worden.

Die Parameter des Clusters, wie beispielsweise die Portregeln, können über den Menüpunkt Clustereigenschaften im Kontextmenü des Clusters konfiguriert werden (Abbildung 20.49).

Abbildung 20.49 Mit dem Kontextmenü des Clusters kann ein Host hinzugefügt werden.

Clusterknoten hinzufügen

Das Hinzufügen von weiteren Knoten zum Cluster ist erfreulich simpel. Im Netzwerklastenausgleich-Manager wählen Sie im Kontextmenü des Clusters den Menüpunkt Host dem Cluster hinzufügen (Abbildung 20.49) – und schon befinden Sie sich in dem Assistenten, der letztendlich den Rest erledigt.


Hinweis

Sie können das Hinzufügen des weiteren Clusterknotens von jeder beliebigen Maschine aus ausführen, auf der der Netzwerklastenausgleich-Manager läuft – beispielsweise auch vom Admin-PC.


Zunächst möchte der Assistent von Ihnen den Namen des Servers wissen, der der neue Clusterknoten werden soll. In dem dann folgenden Dialog wählen Sie, welche IP-Adressen des Servers verwendet werden sollen. Die Einstellung Priorität (eindeutige Host-ID) kann im Normalfall auf dem vorgeschlagenen Wert belassen werden (Abbildung 20.50).

Auf der folgenden Dialogseite werden die Portregeln angezeigt. Sie können hier keine Portregeln hinzufügen oder löschen bzw. – auch wenn eine entsprechend benannte Schaltfläche vorhanden ist – bearbeiten (Abbildung 20.51). Die Schaltfläche Bearbeiten zeigt die Details der gewählten Portregel an.

Nach dem Hinzufügen des neuen Clusterknotens, was durchaus »ein Weilchen« dauern kann, sollten alle Knoten im Netzwerklastenausgleich-Manager zu sehen sein und mit dem Status Zusammengeführt angezeigt werden. Ein guter Test ist übrigens, den neuen Clusterknoten herunterzufahren und neu zu starten; wenn alles in Ordnung ist, müsste sich der in Abbildung 20.52 gezeigte Zustand von selbst wieder einstellen.

Abbildung 20.50 Hier wählen Sie den Knoten, den Sie hinzufügen wollen, und geben seine IP-Adressen an.

Abbildung 20.51 Die Port-Regeln des Clusters werden hier gezeigt, können aber beim Hinzufügen eines weiteren Knotens nicht geändert werden.

Abbildung 20.52 So sieht ein NLB-Cluster mit zwei Clusterknoten im »Netzwerklastenausgleich- Manager« aus.

Cluster-IP im DNS eintragen

Für einen ersten Test können Sie natürlich die Cluster-IP-Adresse eintragen und schauen, ob der gewünschte Dienst, beispielsweise Webserver oder Terminalserver, reagiert. Da das direkte Eintragen von IP-Adressen irgendwie doch sehr archaisch ist, bietet es sich natürlich an, einen DNS-Eintrag für die Cluster-IP-Adresse(n) zu erzeugen.

Die Vorgehensweise:

  • Öffnen Sie den DNS-Manager, und wählen Sie im Kontextmenü der entsprechenden Zone das Hinzufügen eines neuen Hosts. Ein A-Eintrag steht für eine IPv4-Adresse, ein AAAA-Eintrag für eine IPv6-Adresse (Abbildung 20.53).

Abbildung 20.53 Im DNS-Manager wird ein neuer Host-Eintrag für die NLB-Cluster-IP-Adresse vorgenommen. Im Kontextmenü der Zone findet sich der entsprechende Menüpunkt.

  • In dem sich öffnenden Dialog tragen Sie den gewünschten Namen sowie die IP-Adresse ein – ganz einfach (Abbildung 20.54).

Abbildung 20.54 In diesem simplen Dialog tragen Sie die IP-Adresse und den gewünschten Namen ein.


Galileo Computing - Zum Seitenanfang

20.3.3 Ein paar Hintergründe Zur nächsten ÜberschriftZur vorigen Überschrift

Nachdem das Network Load Balancing erfolgreich eingerichtet worden ist, werden die meisten Leser vermutlich nach ein paar Hintergründen verlangen. Ich möchte zwar nicht zu sehr in die Tiefe gehen, einige Aspekte zu beleuchten kann aber für ein nachhaltiges Verständnis der Technologie nicht schaden.

Veränderung der Netzwerkkonfiguration der NLB-Clusterknoten

Wenn ein Server zu einem NLB-Cluster hinzugefügt wird, gibt es in der Netzwerkkonfiguration zwangsläufig einige Änderungen, die Sie kennen sollten. Im Normalfall werden diese Anpassungen automatisch vorgenommen, es kann aber nicht schaden, in etwa zu wissen, was sich wann, wo, wie und warum ändert.

Kommen wir zunächst zur offensichtlichsten Änderung. In der Konfiguration der Netzwerkkarte ist das Element Netzwerklastenausgleich (NLB) vorhanden und aktiviert (Abbildung 20.55). Es gibt hier keine Konfigurationsmöglichkeiten (die Schaltfläche Eigenschaften ist deaktiviert), so dass wir direkt zum nächsten Aspekt übergehen können.

Abbildung 20.55 In der Konfiguration der Netzwerkkarte ist der »Netzwerklastenausgleich« vorhanden und aktiviert.

Im Gegensatz zu Hardware-Load-Balancern ist das Microsoft NLB in die Server integriert und verfügt »nur« über eine (oder mehrere) virtuelle IP-Adresse(n). Da die IP-Adresse des NLB-Clusters nicht »irgendwie in der Luft hängen« kann, wird sie jedem Knoten als zusätzliche Adresse hinzugefügt (Abbildung 20.56). Normalerweise würde eine auf mehreren Servern eingetragene IP-Adresse zu einer Adresskonfliktwarnung führen, die aber vom NLB-Treiber unterdrückt wird – in diesem Fall ist es ja auch kein Adresskonflikt.

Abbildung 20.56 Die virtuelle IP-Adresse des NLB-Clusters wird jedem Clusterknoten hinzugefügt.

Die Knoten des NLB-Clusters haben weiterhin dieselbe physikalische Adresse (MAC-Adresse). Wenn ein Server einem NLB-Cluster hinzugefügt wird, nimmt die Installationsroutine auch diese Änderung automatisch vor. Sie können das beispielsweise kontrollieren, indem Sie ipconfig /all aufrufen (Abbildung 20.57). Die Eigenschaft Physikalische Adresse wird auf allen Clusterknoten identisch sein. Zum Vergleich finden Sie sie auch in den Eigenschaften des Clusters (zu sehen in Abbildung 20.46 und Abbildung 20.60).

Abbildung 20.57 Mit »ipconfig /all« werden Sie feststellen, dass alle NLB-Clusterknoten dieselbe physikalische Adresse haben.

Falls eine Netzwerkkarte bzw. deren Treiber nicht das Überschreiben der »eingebauten« MAC-Adresse unterstützt, ist diese für die Verwendung mit Network Load Balancing ungeeignet. Die Konfiguration einer alternativen Hardwareadresse findet sich übrigens in den Eigenschaften der Netzwerkkarte (nicht der Netzwerkverbindung, Abbildung 20.58). Kurzer Hinweis: Ich zeige Ihnen den Dialog aus Abbildung 20.58, um Ihnen ein Gefühl für die Zusammenhänge zu vermitteln – nicht, dass mir jemand da andere Werte einträgt! Das würde den NLB-Cluster in einem inkonsistenten Zustand hinterlassen.

Abbildung 20.58 Bei den meisten Karten kann die Hardwareadresse überschrieben werden – wenn nicht, ist die Karte für die Verwendung mit NLB nicht geeignet.

Was sieht der Netzwerkmonitor?

Der NLB-Cluster ist für den Client, der auf einen dahinterliegenden Serverdienst zugreift, völlig transparent – der Client benötigt also keine zusätzliche Software oder dergleichen. Das lässt sich auch leicht »nachweisen«, wenn man den Verbindungsaufbau mit dem Netzwerkmonitor beobachtet.


Hinweis

Einige allgemeine Hinweise zur Arbeit mit dem Netzwerkmonitor finden Sie in Kapitel 4.


In Abbildung 20.59 sehen Sie einen Mitschnitt des Netzwerkverkehrs, bei dem der Browser eine Website aufruft, die via Network Load Balancing von zwei Webservern gehostet wird. Vor Beginn der Aufzeichnung wurden der ARP-Cache (arp -d) und der DNS-Cache (ipconfig /flushdns) geleert. Sie können folgende Verhaltensweisen beobachten:

  • Pakete 43,44: Zunächst muss der Client die Hardwareadresse des DNS-Servers auflösen. Dies geschieht mithilfe des ARP-Protokolls (siehe auch Abschnitt 4.3.2).

Abbildung 20.59 Verbindungsaufbau zu einem NLB-Cluster (Webserver) aus Sicht eines Clients

  • Paket 45, 46: Nun fragt der Client beim DNS-Server nach der IP-Adresse des NLB-Clusters. In diesem Fall lautet der Name ubinfwebnlb.ubinf.intra.
  • Paket 47–49: Nun wird es spannend: Der Client fragt (ARP Request) nach der Hardwareadresse der IP-Adresse des Clusters (Paket 47). Wie Sie zuvor erfahren haben, ist diese IP-Adresse bei allen Knoten des NLB-Clusters als zusätzliche Adresse eingetragen, und weiterhin haben alle Server (bzw. die »beteiligten« Netzwerkkarten) dieselbe Hardwareadresse.
    • So erklärt sich, warum es in diesem Fall zwei gleichlautende ARP-Responses gibt (zwei Server arbeiten in dem NLB-Cluster). Die zurückgegebene Adresse entspricht natürlich der Cluster-IP des NLB-Clusters, wie man in Abbildung 20.60 vergleichen kann.

Abbildung 20.60 Die physikalische Adresse des NLB-Clusters wird bei der ARP-Auflösung der Adresse zurückgegeben.

  • In den folgenden Paketen sehen Sie den Aufbau einer TCP-Verbindung, die Initiierung einer HTTP-Session und die Authentifizierung.

Authentifizierung

Bleiben wir ruhig noch ein wenig bei dem Thema »Webapplikationen und NLB«, was ja das meistgenutzte Szenario für NLB-Konfigurationen ist (gefolgt von den Terminaldiensten).

Bei Intranet-Anwendungen ist häufig die Authentifizierung ein extrem wichtiges Thema, um beispielsweise Szenarien realisieren zu können, wie sie in Abbildung 4.40 (weiter vorn in Abschnitt 4.4.3) gezeigt sind.

Meine kleine Web-Testapplikation zeigt, dass beim Zugriff auf den NLB-Cluster im Normalfall eine NTLM-Authentifizierung erfolgt.

Abbildung 20.61 Beim Zugriff auf den NLB-Cluster wird, wenn Sie nicht gezielt etwas daran tun, NTLM verwendet – nicht Kerberos.

Mit dem Netzwerkmonitor kann man auch leicht erkennen, warum das so ist. Abbildung 20.62 zeigt den entscheidenden Auszug aus der schon zuvor besprochenen Sitzung:

  • Der Client initiiert die HTTP-Sitzung und bekommt einen 401-Fehler (unauthorized) zurück (Paket 69 in Abbildung 20.59).
  • Der Client baut daraufhin eine Verbindung zum Domänencontroller auf und fordert dort ein Ticket zum Zugriff auf die Ressource HTTP/ubinfwebnlb an (HTTP/ubinfwebnlb ist der Service Principal Name (SPN). Sie sehen diese Anforderung in Paket 81.
  • In Paket 84 teilt der Domänencontroller mit, dass ihm dieser SPN unbekannt ist (KRB_ERROR – KDC_ERR_S_PRINCIPAL_UNKNOWN).
  • Da Kerberos nicht möglich ist, fällt der Client auf die NTLM-Authentifizierung zurück (Paket 88 ff.).

Der Benutzer wird zwar zunächst glücklich sein, denn er kann auf die Website zugreifen. Sofern die Webapplikation aber darauf angewiesen ist, dass die Delegierung der Identität funktioniert, gibt es ein Problem.

Abbildung 20.62 Die Kerberos-Authentifizierung kommt nicht zustande, weil der angeforderte »Service Principal Name« nicht existiert.

Bleibt noch die Frage zu klären, warum der Service Principal Name nicht gefunden wird? Ganz einfach:

  • Die Standard-SPNs (Servername und FQDN) werden automatisch registriert. Der Name des NLB-Clusters ist aber kein Servername und wurde »nur« dadurch erzeugt, dass er im DNS eingetragen wurde.
  • Wenn der Client eine Authentifizierung anfordert, übergibt er den Namen, über den er auf die Ressource zugreift, was ja in Abbildung 20.62 (Paket 81) sehr schön zu sehen ist.
  • Und wenn der zum DNS-Namen passende SPN nicht registriert worden ist, gelingt die Kerberos-Authentifizierung eben nicht.

Mehr zum Thema Service Principal Name finden Sie auch in Abschnitt 4.4.4.

Die Lösung ist nun auf den ersten Blick ganz einfach: Man registriert »einfach mal eben schnell« den SPN für den DNS-Namen des NLB-Clusters. Und damit sind wir in unserer beliebten Rubrik »Echte Probleme von echten Kunden aus echten Projektsituationen« – und ich habe dem Thema einen eigenen Abschnitt, nämlich den nun folgenden gewidmet.


Galileo Computing - Zum Seitenanfang

20.3.4 Webserver, Kerberos und NLB Zur nächsten ÜberschriftZur vorigen Überschrift

Die Webapplikationen, die heute auf Webservern ausgeführt werden, zeigen keine statischen Seiten mehr, sondern sind komplexe Business-Applikationen. Es ist mehr als einleuchtend, dass solche Applikationen auch auf weitere Server im Netz zugreifen müssen. Wenn dies mit der Windows-Identität des angemeldeten Benutzers geschehen soll, sieht das Szenario so aus, wie in Abbildung 20.63 gezeigt:

  • Der Benutzer greift mit seiner Windows-Identität auf den NLB-Cluster zu.
  • In der Konfiguration der Webapplikation ist festgelegt, dass die Identität des angemeldeten Benutzers angenommen wird (Impersonation).
  • Wenn die Webapplikation auf andere Server im internen Netz zugreifen soll, soll dies auch mit der Identität des angemeldeten Benutzers geschehen.

Wir befinden uns hiermit in einem Szenario, in dem die Kerberos-Delegierung funktionieren muss. Die Voraussetzungen sind:

  • Der Benutzer muss sich am Webserver mit Kerberos anmelden.
  • Dem Server muss für Delegierung vertraut werden. Genauer gesagt muss es heißen: Dem Computerkonto des Servers oder dem Konto, unter dem der Anwendungspool läuft, muss für Delegierung vertraut werden. Der letztgenannte Fall trifft nur dann zu, wenn der Anwendungspool nicht unter einem der eingebauten Konten (Netzwerkdienst etc.) läuft.
  • Der Service Principal Name muss »richtig« registriert sein.
  • Der Browser des Clients muss den Webserver in der Lokales Intranet-Zone einsortieren.

Abbildung 20.63 In diesem NLB-Szenario muss Kerberos-Delegierung funktionieren – das ist nicht ganz trivial.


Kerberos

Einen einigermaßen ausführlichen Überblick über Kerberos finden Sie in Abschnitt 4.4.2 ff. Falls Sie mit Kerberos und der Delegierung nicht so sehr vertraut sind, möchte ich Ihnen dringend empfehlen, vorab diese Abschnitte zu lesen.


Kerberos in einem NLB-Szenario zum Laufen zu bringen, ist nun wirklich kein unlösbares Problem – so ganz trivial ist es aber auch nicht, weshalb ich Ihnen erstens die Ursache und zweitens die Lösung zeigen möchte.

Kurze Analyse des Problems

Wie ich bereits im vorherigen Abschnitt gezeigt habe, kommt die Kerberos-Authentifizierung in einem NLB-Cluster nicht zustande, weil kein Service Principal Name vorhanden ist (siehe Abbildung 20.62, Paket 84). Wenn Sie einen Service Principal Name (SPN) registrieren, müssen Sie diesen einem Konto (im einfachsten Fall einem Computerkonto) zuordnen, mit dessen Schlüssel das Zugriffsticket verschlüsselt wird.

In Abbildung 20.64 sehen Sie nun das Problem:

  • Letztendlich wird der Client auf den Server ubinfWebNlb1, ..2 oder ..3 zugreifen. Welcher es wird, kann man zum Zeitpunkt der Kerberos-Ticket-Anforderung nicht vorhersagen.
  • Da der Domänencontroller das Ticket nicht für alle drei Computerkonten gleichzeitig verschlüsseln kann, wird der Zugriff nur in einem Drittel der Fälle erfolgreich sein.

Abbildung 20.64 Für welches Computerkonto soll der Domänencontroller das Kerberos-Ticket ausstellen?

In Abbildung 20.65 können Sie sehen, was passiert, wenn ein Client einem Server ein Kerberos-Zugriffsticket präsentiert, das der Server nicht entschlüsseln kann. Der Server wird dreimal nach der Anmeldung fragen und schließlich einen Zugriffsfehler ausgeben.

Abbildung 20.65 So sieht es aus, wenn ein Kerberos-Ticket von der Ressource nicht verarbeitet werden kann, weil es für ein anderes Konto verschlüsselt worden ist.

Die Lösung ist so einfach wie einleuchtend: Man muss »nur« dafür sorgen, dass die Webapplikation auf allen beteiligten Servern unter demselben Dienstkonto läuft. Das Dienstkonto muss dabei ein Domänenkonto sein. Das Kerberos-Ticket wird dann für dieses Dienstkonto erstellt, so dass der Zugriff auf alle Server gelingt. Abbildung 20.66 zeigt die Funktionsweise in schematischer Darstellung.

Da für die Realisierung der in Abbildung 20.66 gezeigten Lösung diverse Konfigurationsschritte notwendig sind, zeige ich Ihnen die Vorgehensweise und durchzuführenden Schritte in etwas ausführlicherer Form. Da die Vorgehensweise direkt mehrere Bereiche berührt (IIS, Active Directory, NLB) riskiere ich ein paar »Doubletten« und zeige Ihnen die Konfiguration »en bloc«.

Abbildung 20.66 Die Lösung: Die Webapplikation nutzt ein Domänenkonto.

Vorbereitung und Testapplikation

Damit man sehen kann, ob die Anmeldung mit Kerberos erfolgt und ob tatsächlich eine Delegierung möglich ist, verwende ich die bereits bekannte selbst gebastelte Webapplikation, die ich Ihnen auf Wunsch gern zusende (ulrich@boddenberg.de).

Zunächst müssen Sie aber dafür sorgen, dass auf den Webservern des NLB-Clusters die Windows-Authentifizierung möglich ist: Dazu muss der entsprechende Rollendienst installiert werden (Abbildung 20.67).

Dann kopieren Sie die Testapplikation in ein Verzeichnis auf den Servern, am einfachsten in c:\inetpub\wwwroot.

Im Internetinformationsdienste-Manager müsste das neue Verzeichnis direkt zu sehen sein, zumindest dann, wenn Sie es in den vorgeschlagenen Pfad kopiert haben. Machen Sie aus dem Verzeichnis eine Anwendung, indem Sie den Menüpunkt In Anwendung konvertieren aufrufen (Abbildung 20.68). Es wird ein Dialog erscheinen, in dem Sie einige Grundeinstellungen für die neue Anwendung vornehmen können; bestätigen Sie die vorbelegten Werte – wir werden sie später anpassen (Abbildung 20.69).

Abbildung 20.67 »Windows-Authentifizierung« muss als Rollendienst hinzugefügt werden.

Abbildung 20.68 Konvertieren Sie das Verzeichnis in eine Anwendung.

Abbildung 20.69 In diesem Dialog werden einige Grundeinstellungen beim Konvertieren der Anwendung abgefragt – bestätigen Sie die vorbelegten Werte.

Wechseln Sie nun in den Dialog Authentifizierung für die neu angelegte Anwendung – nicht für die Website! Dort nehmen Sie folgende Einstellungen vor (Abbildung 20.70):

  • Anonyme Authentifizierung wird deaktiviert.
  • ASP.NET-Identitätswechsel müsste bereits aktiviert sein und muss dies auch bleiben.
  • Formularauthentifizierung wird deaktiviert.
  • Windows-Authentifizierung wird aktiviert.

Rollendienst hinzufügen

Falls die Windows-Authentifizierung in der Auflistung nicht vorhanden ist, müssen Sie sie noch als Rollendienst hinzufügen (siehe Abbildung 20.67).


Abbildung 20.70 Die Steuerung der Authentifizierung für die Anwendung

Bereiten Sie alle Server des NLB-Clusters (in diesem Beispiel sind es zwei) wie beschrieben vor. Sie können die Anwendung auf dem jeweiligen Server direkt aufrufen, indem Sie den Namen des Servers und nicht des NLB-Clusters angeben. Sie werden das in Abbildung 20.71 gezeigte Ergebnis sehen:

  • Die Authentifizierung wird mit Kerberos durchgeführt.
  • Der Impersonation Level wird Impersonation sein – wir benötigen zwar für den NLB-Cluster den Level Delegation, das braucht uns aber hier noch nicht zu stören.

Abbildung 20.71 Wenn Sie die neue Webanwendung direkt, also mit der URL des Servers und nicht mit der URL des NLB-Clusters aufrufen, müssten Sie zu diesem Ergebnis kommen.


Hinweis

Beachten Sie, dass der Internet Explorer die aufgerufene URL in die Zone Lokales Intranet einsortieren muss. Eventuell müssen Sie die Zonen anpassen. Weiterhin muss im Browser die Windows-Authentifizierung aktiviert sein.


Konfiguration verändern

Jetzt geht’s richtig los. Wir werden folgende Anpassungen durchführen:

  • Anlegen eines neuen Anwendungspools: Die Poolidentität wird ein Domänenbenutzerkonto sein.
  • Die Anwendung wird in den neuen Anwendungspool verschoben.
  • Für den DNS-Namen des NLB-Clusters wird ein Service Principal Name angelegt.
  • Dem Benutzerkonto, das als Identität des Anwendungspools eingetragen ist, wird für die Delegierung vertraut.

Falls Sie alle Schritte auch ohne die Hilfe dieses Buchs durchführen können, sind Sie bereits ein IIS-Profi. Top! Alle anderen werden diesen Status nach der Durchführung der nachfolgend im Detail beschriebenen Schritte erreicht haben.

Los geht’s:

  • Fügen Sie im Internetinformationsdienste-Manager einen neuen Anwendungspool hinzu (Abbildung 20.72).
  • Vergeben Sie einen beliebigen aussagekräftigen Namen, und akzeptieren Sie ansonsten die Voreinstellungen (Abbildung 20.73).

Abbildung 20.72 Hinzufügen eines Anwendungspools

Abbildung 20.73 Die vorgeschlagenen Einstellungen können Sie übernehmen.

  • Falls nicht bereits eines vorhanden ist, legen Sie ein neues Domänenbenutzerkonto an (mit dem Snap-In Active Directory-Benutzer und -Computer).
  • Öffnen Sie die Eigenschaften des neu angelegten Anwendungspools, und geben als Identität das Domänenbenutzerkonto an (Abbildung 20.74).

Der neue Anwendungspool kann nun verwendet werden. Nun muss noch die Anwendung angepasst werden:

  • Rufen Sie die Grundeinstellungen der Anwendung auf, und legen Sie als Anwendungspool den neu erstellten Pool fest (Abbildung 20.75).
  • Rufen Sie den Authentifizierung-Dialog der Anwendung auf, und deaktivieren Sie in den Eigenschaften der Windows-Authentifizierung die Kernelmodus-Authentifizierung (Abbildung 20.76)
  • Führen Sie ein iisreset aus.

Abbildung 20.74 In den Eigenschaften des neuen Anwendungspools tragen Sie das Domänenbenutzerkonto ein, das als Identität verwendet werden soll.

Abbildung 20.75 In den Grundeinstellungen der Anwendung wählen Sie den neu angelegten Anwendungspool aus.

Abbildung 20.76 In den Eigenschaften der Windows-Authentifizierung der Anwendung deaktivieren Sie die Kernelmodus-Authentifizierung.


Hinweis

Neben einigen anderen Features (z. B. Performance bei der Authentifizierung) sorgt die Kernelmodus-Authentifizierung dafür, dass Kerberos-Tickets nicht von dem als Identität des Anwendungspools eingetragenen Konto entschlüsselt werden, sondern mit dem Computerkonto. Das ist zwar in vielen Fällen durchaus hilfreich – im Moment benötigen wir aber wirklich genau das Gegenteil.

Das Abschalten der Kernelmodus-Authentifizierung führt schnell zum gewünschten Ergebnis und ist aus der grafischen Konfigurationsoberfläche heraus zu erledigen. Der bessere Weg ist allerdings, das Attribut useAppPoolCredentials auf true zu setzen. Das müssen Sie allerdings in der XML-Konfigurationsdatei der Anwendung erledigen.


Sie können, sozusagen als Zwischenergebnis, einen kleinen Test durchführen, indem Sie die Webanwendung über den Namen des NLB-Clusters angeben. Wenn Sie alles richtig gemacht haben, wird die Testapplikation erscheinen. Die Authentifizierung wird aber noch nicht mit Kerberos durchgeführt werden, sondern »nur« mit NTLM (Abbildung 20.77).

Abbildung 20.77 Kurzer Test für das erste Zwischenergebnis: Der Zugriff auf den NLB-Cluster funktioniert, allerdings nur mit NTLM.

Kleines Quiz:

  • Frage:Warum nur mit NTLM?
  • Antwort (bitte rückwärts lesen): nednahrov eman lapicnirp ecivres niek

Nun geht es an die Registrierung der Service Principal Names. In meinem Beispiel lauten die Namen des NLB-Clusters ubinfWebNlb bzw. ubinfWebNlb.ubinf.intra. Der Anwendungspool läuft unter dem Konto ubinf\WebService.

Die SPNs werden wie in Abbildung 20.78 mit dem Werkzeug setspn.exe registriert.

Abbildung 20.78 Registrieren der Service Principal Names für den Servernamen und den FQDN

Als Nächstes rufen Sie die Eigenschaften des »Identität-des-Anwendungspools-Domänenbenutzerkontos« im Snap-In Active Directory-Benutzer und -Computer auf. Dort, und zwar auf der Registerkarte Delegierung, konfigurieren Sie, dass dem Konto für Delegierung vertraut werden soll. Es gibt dabei letztendlich zwei Möglichkeiten (Abbildung 20.79):

  • Wenn Sie sich für die in der Abbildung gewählte Einstellung (Benutzer bei Delegierungen aller Dienste vertrauen [nur Kerberos]) entscheiden, gibt es bei der Delegierung keine Einschränkungen, d. h., der unter diesem Konto laufende Dienst kann auf sämtliche Ressourcen des Netzes mit der Identität des angemeldeten Benutzers zugreifen.
  • Alternativ können Sie die dritte Option, Benutzer bei Delegierungen angegebener Dienste vertrauen, selektieren und genau die Dienste angeben, auf die per Delegierung zugegriffen werden kann. Es werden die SPNs der Dienste angegeben, beispielsweise LDAP/ubinfdc10 oder MSSQLSvc/ubinfcsql01. Man spricht dabei von einer Constrained Delegation, also eingeschränkter Delegierung. Es ist hierbei sogar möglich, eine Delegierung zu ermöglichen, obwohl der Anwender nur mit NTLM angemeldet ist. Ich würde aber immer versuchen, Kerberos zum Laufen zu bringen, anstatt Constrained Delegation mit NTLM zu verwenden.

Hinweis

Es ist übrigens vollkommen klar, dass die Nutzung von Constrained Delegation (also die dedizierte Vorgabe, an welche Dienste das Konto delegieren darf) die empfohlene Variante ist.

Wenn das Vertrauen bei Delegierung neu eingerichtet ist, muss der delegierende Server (also der Webserver) neu gestartet werden.


Abbildung 20.79 Hier wird konfiguriert, dass dem Domänenbenutzerkonto, das als Identität des Anwendungspools verwendet wird, für Delegierung vertraut wird.

Wenn Sie die Eigenschaften des Kontos schon geöffnet haben, können Sie einen anderen Aspekt überprüfen. Auf der Registerkarte Attribut-Editor haben Sie die Möglichkeit, jedes Attribut eines Active Directory-Objekts einzusehen und zu modifizieren – Sie brauchen also nicht extra ASDI-Editor zu starten.

Im Attribut servicePrincipalName müssten die beiden neu angelegten SPNs zu finden sein (Abbildung 20.80). setspn.exe macht also nichts anderes, als in dieses Attribut zu schreiben.

Nun kommt der spannende Moment: Rufen Sie, mit mehr oder weniger zitternden Knien etc., die Adresse des NLB-Clusters auf. Sie sollten die Ausgabe aus Abbildung 20.81 erhalten:

  • Das Authentifizierungsprotokoll ist Kerberos.
  • Als Impersonation Level ist Delegation angegeben.

Was tun Sie, wenn es nicht funktioniert?

Wenn Sie alle Schritte durchgeführt haben, kann es eigentlich nicht sein, dass die Konfiguration nicht funktioniert. Wenn Sie hinreichend schnell nach der Ausführung der letzten Einstellungen den Browser gestartet haben, werden Sie vermutlich doch eine Enttäuschung erleben. Die Änderungen sind aus mehreren Gründen nicht sofort aktiv: Wenn Sie mehrere DCs einsetzen, dauert es mehr oder weniger lange, bis alle Änderungen repliziert sind. Auch bei nur einem DC dauert es ein Weilchen, bis die Änderungen wirklich greifen. Eine weitere Ursache ist, dass der Client gegebenenfalls noch die alte NTLM-Anmeldung im Zwischenspeicher hat. Einmal Ab- und Anmelden hilft. Dies gilt übrigens auch, wenn Sie zuvor eine Kerberos-Anmeldung ohne Delegierung durchgeführt haben.

Abbildung 20.80 Im Attribut-Editor können Sie sehen, dass die beiden neuen SPNs im Attribut »servicePrincipalName« eingetragen sind.

Gehen Sie also nach dem Abschluss der Änderung in die Teeküche, oder rufen Sie Ihre Partnerin oder Partner an, um zu besprechen, in welchem Restaurant Sie heute die Kerberos-Erfolge feiern wollen – und dann sollte es eigentlich klappen.

Abbildung 20.81 Hurra, es hat funktionert!

Interessant ist auch, mit dem Kerbtray-Utility, das Sie bereits aus Abschnitt 4.4.2 ff. kennen, die Kerberos-Tickets auf dem Client anzeigen zu lassen. Wenn die Kerberos-Authentifizierung gelungen ist, wird dort ein Ticket vorhanden sein, das zum Zugriff auf den NLB-Cluster berechtigt (Abbildung 20.82).

Abbildung 20.82 Mit »Kerbtray.exe« können Sie das ausgestellte Kerberos-Ticket bewundern.


Galileo Computing - Zum Seitenanfang

20.3.5 NLB-Troubleshooting allgemein Zur nächsten ÜberschriftZur vorigen Überschrift

Wer sich bereits länger mit IT beschäftigt, weiß, dass alles grundsätzlich ganz einfach ist, der Teufel dann aber doch im Detail steckt.

Meiner Erfahrung nach zählt NLB in den meisten Fällen zwar nicht zu den hauptsächlichen Verursachern von grauen Haaren, aber es gibt auch hier hinreichend viele Dinge, die einfach schiefgehen können.

Unter der URL http://technet.microsoft.com/en-us/library/cc732592.aspx hat das Microsoft Technet-Team eine ausführliche Liste von möglichen Fehlerszenarien zusammengestellt, die ich Ihnen im Ernstfall empfehlen möchte.


Galileo Computing - Zum Seitenanfang

20.3.6 NLB im Terminalserver-Umfeld topZur vorigen Überschrift

Für das Load Balancing im Terminalserver-Umfeld kommt ebenfalls NLB zum Einsatz. Dieses Anwendungsszenario finden Sie im Terminaldienste-Kapitel.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.






<< zurück
  Zum Katalog
Zum Katalog: Windows Server 2008 R2

Windows Server 2008 R2
Jetzt bestellen


 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Windows 7 für Administratoren






 Windows 7 für
 Administratoren


Zum Katalog: Konzepte und Lösungen für Microsoft-Netzwerke






 Konzepte und
 Lösungen für
 Microsoft-Netzwerke


Zum Katalog: Office SharePoint Server 2007 und Windows SharePoint Services 3.0






 Office SharePoint
 Server 2007 und
 Windows SharePoint
 Services 3.0


Zum Katalog: Exchange Server 2007 und Office Communications Server 2007






 Exchange Server 2007
 und Office
 Communications
 Server 2007


Zum Katalog: Citrix XenApp 5






 Citrix XenApp 5


Zum Katalog: PC-Netzwerke






 PC-Netzwerke


Zum Katalog: VMware vSphere 4






 VMware vSphere 4


Zum Katalog: VMware vSphere 4 - Videotraining






 VMware vSphere 4
 - Videotraining


Zum Katalog: VirtualBox






 VirtualBox


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Galileo Press 2010
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Galileo Computing]

Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de