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

Inhaltsverzeichnis
Geleitwort
1 Warum eine neue Server-Version?
2 Editionen und Lizenzen
3 Hardware und Dimensionierung
4 Protokolle
5 Was ist .NET?
6 Installation
7 Die 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 Foundation und SharePoint Server
19 Remotedesktopdienste (Terminaldienste)
20 Hochverfügbarkeit
21 Datensicherung
22 Servervirtualisierung mit Hyper-V
23 Windows PowerShell
Stichwort

Jetzt Buch bestellen
Ihre Meinung?

Spacer
Windows Server 2012 R2 von Ulrich B. Boddenberg
Das umfassende Handbuch
Buch: Windows Server 2012 R2

Windows Server 2012 R2
Rheinwerk Computing
1392 S., 4., aktualisierte Auflage 2014, geb.
59,90 Euro, ISBN 978-3-8362-2013-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 vs. Passiv und 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.2.6 Clusterfähiges Aktualisieren
Pfeil 20.2.7 SQL Server 2012 installieren
Pfeil 20.3 Network Load Balancing
Pfeil 20.3.1 Funktionsweise des Network Load Balancing
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

Rheinwerk Computing - Zum Seitenanfang

20.3 Network Load Balancing Zur nächsten Ü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 (siehe ADDS-Kapitel). 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, nur statische Seiten anzuzeigen.

Rheinwerk Computing - Zum Seitenanfang

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

In Abbildung 20.64 ist die Funktionsweise des Network Load Balancing 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 darüber, welcher Server die Anfrage bedient.

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

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.

Abbildung

Abbildung 20.64 Funktionsweise des Network Load Balancing

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 etwa fünf 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.


Rheinwerk 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 einigen Erläuterungen.

Zwei Netzwerkadapter

Die Knoten des NLB-Clusters sollten mit zwei Netzwerkkarten bestückt sein. Über einen Netzwerkadapter läuft die Kommunikation der geclusterten IP-Adressen, über die andere die Kommunikation mit dem Server zu »Management-Zwecken«. Dies ist auch auf den nachfolgenden Screenshots zu sehen.

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 ergibt 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:

NLB-Cluster einrichten

Der erste Schritt zur Einrichtung eines NLB-Clusters besteht darin, das Feature Netzwerklastenausgleich auf allen Servern zu 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.65).

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-2012-Administrationswerkzeuge für Windows 8/8.1 (Stichwort für die Suche im Download Center: R emoteServerAdministrationTools) enthalten ebenfalls den Netzwerklastenausgleich-Manager.

Abbildung

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

Die Einrichtung beginnt mit dem Aufruf der Funktion Neuer Cluster (Abbildung 20.66). 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.67). Das Network Load Balancing ab Windows Server 2008 unterstützt – im Gegensatz zu den Vorgängerversionen – auch IPv6-Netzwerkadressen.

Abbildung

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

Abbildung

Abbildung 20.67 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, das 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 (Abbildung 20.68). Wichtig ist , dass diese IP-Adressen noch nicht in Verwendung sein dürfen – sonst erscheint eine Fehlermeldung, und nichts funktioniert.

Abbildung

Abbildung 20.68 Eine oder mehrere IP-Adressen werden als Cluster-IP-Adressen angegeben. Diese Adressen dürfen natürlich noch nicht anderweitig verwendet worden sein. Neu in Windows Server 2008 (und damit auch in 2012 vorhanden) 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.69):

  • 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

Abbildung 20.69 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.70). 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 Filterungsmodus 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

Abbildung 20.70 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 zugewiesen.
  • Netzwerk: Diese Einstellung bewirkt, dass die Pakete, die aus einem Netz kommen, immer demselben Knoten zugewiesen werden. Diese Einstellung ist sinnvoll, wenn in einem Extranet- oder Internetszenario die Verbindungen von einem Kommunikationspartner über verschiedene Proxyserver (die aber vermutlich alle im selben Netz stehen) eingehen. In einem Intranetszenario, 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, sodass 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.71 gezeigte Ergebnis zu sehen sein.

Abbildung

Abbildung 20.71 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.72).

Abbildung

Abbildung 20.72 Mithilfe des Kontextmenüs 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.72) – 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 durchfü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 (Abbildung 20.73). Die Einstellung Priorität (eindeutige Host-ID) kann im Normalfall auf dem vorgeschlagenen Wert belassen werden .

Abbildung

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

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.74). Die Schaltfläche Bearbeiten zeigt die Details der gewählten Portregel an.

Abbildung

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

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.75 gezeigte Zustand von selbst wieder einstellen.

Abbildung

Abbildung 20.75 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.76).

    Abbildung

    Abbildung 20.76 Im »DNS-Manager« wird ein neuer Hosteintrag 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.77).

    Abbildung

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


Rheinwerk 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.78). Es gibt hier keine Konfigurationsmöglichkeiten, sodass wir direkt zum nächsten Aspekt übergehen können.

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.79). 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

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

Abbildung

Abbildung 20.79 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.80). 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.69 und Abbildung 20.83).

Falls eine Netzwerkkarte bzw. deren Treiber nicht das Überschreiben der »eingebauten« MAC-Adresse unterstützt, ist sie 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.81). Kurzer Hinweis: Ich zeige Ihnen den Dialog aus Abbildung 20.81, 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

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

Abbildung

Abbildung 20.81 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.82 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).
  • 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: Jetzt 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.

    Abbildung

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

    So erklärt es 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.83 vergleichen kann.

    Abbildung

    Abbildung 20.83 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 Intranetanwendungen ist häufig die Authentifizierung ein extrem wichtiges Thema, um beispielsweise Szenarien realisieren zu können, wie sie in Abbildung 4.40 (weiter oben in Abschnitt 4.4.3) gezeigt sind.

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

Abbildung

Abbildung 20.84 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.85 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.82).
  • 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.).

Abbildung

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

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.

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.85 (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. Damit sind wir auch schon 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.


Rheinwerk 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 Businessapplikationen. 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.86 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).
  • Soll die Webapplikation auf andere Server im internen Netz zugreifen, muss dies auch mit der Identität des angemeldeten Benutzers geschehen.

Abbildung

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

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, 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 die Zone Lokales Intranet einsortieren.

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.

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.

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.85, 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.

Abbildung

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

In Abbildung 20.87 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.

In Abbildung 20.88 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

Abbildung 20.88 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, sodass der Zugriff auf alle Server gelingt. Abbildung 20.89 zeigt die Funktionsweise in schematischer Darstellung.

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

Abbildung

Abbildung 20.89 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.90).

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.91).

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.92).

Abbildung

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

Abbildung

Abbildung 20.91 Konvertieren Sie das Verzeichnis in eine Anwendung.

Abbildung

Abbildung 20.92 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.93):

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

Abbildung

Abbildung 20.93 Die Steuerung der Authentifizierung für die Anwendung

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.90).

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.94 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

Abbildung 20.94 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.95).

    Abbildung

    Abbildung 20.95 Hinzufügen eines Anwendungspools

  • Vergeben Sie einen beliebigen aussagekräftigen Namen, und akzeptieren Sie ansonsten die Voreinstellungen (Abbildung 20.96).

    Abbildung

    Abbildung 20.96 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 Sie als Identität das Domänenbenutzerkonto an (Abbildung 20.97).

Abbildung

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

Der neue Anwendungspool kann jetzt 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.98).
  • Rufen Sie den Authentifizierung-Dialog der Anwendung auf, und deaktivieren Sie in den Eigenschaften der Windows-Authentifizierung die Kernelmodus-Authentifizierung (Abbildung 20.99).
  • Führen Sie ein iisreset aus.

Abbildung

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

Abbildung

Abbildung 20.99 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.100).

Abbildung

Abbildung 20.100 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.101 mit dem Werkzeug setspn.exe registriert.

Abbildung

Abbildung 20.101 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.102):

  • 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.

    Abbildung

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

  • 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 einer eingeschränkten Delegierung. Es ist hierbei sogar denkbar, 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.

Da 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 den ASDI-Editor zu starten.

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

Abbildung

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

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.104 erhalten:

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

Was tun Sie, wenn es nicht funktioniert?

Haben Sie alle Schritte durchgeführt, 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 etwas länger, 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.

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

Abbildung

Abbildung 20.104 Hurra, es hat funktioniert!

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.105).

Abbildung

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

Kerbtray vs. klist

Seit Windows Server 2008 (also auch in 2012) gibt es das Kommandozeilenwerkzeug klist. Das auf dem Screenshot gezeigte Kerbtray funktioniert auch in den neuen Betriebssystemversionen, muss aber nachinstalliert werden – auf dem Screenshot ist es jedoch einfach übersichtlicher.


Rheinwerk Computing - Zum Seitenanfang

20.3.5 NLB-Troubleshooting allgemeinZur 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 maßgeblichen 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 für den Ernstfall empfehlen möchte.



Ihre Meinung

Wie hat Ihnen das Openbook gefallen? Wir freuen uns immer über Ihre Rückmeldung. Schreiben Sie uns gerne Ihr Feedback als E-Mail an kommunikation@rheinwerk-verlag.de.

<< zurück




Copyright © Rheinwerk Verlag GmbH, Bonn 2014
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.


Nutzungsbestimmungen | Datenschutz | Impressum

Rheinwerk Verlag GmbH, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, service@rheinwerk-verlag.de

Cookie-Einstellungen ändern


  Zum Rheinwerk-Shop
Zum Rheinwerk-Shop: Windows Server 2012 R2






Windows Server 2012 R2
Jetzt Buch bestellen


 Ihre Meinung?
Wie hat Ihnen das Openbook gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Rheinwerk-Shop: Office 365






 Office 365


Zum Rheinwerk-Shop: Microsoft Hyper-V






 Microsoft Hyper-V


Zum Rheinwerk-Shop: Linux-Server






 Linux-Server


Zum Rheinwerk-Shop: Vmware vSphere 5






 Vmware vSphere 5


Zum Rheinwerk-Shop: Windows 8 für Administratoren






 Windows 8 für
 Administratoren


 Lieferung
Versandkostenfrei bestellen in Deutschland, Österreich und der Schweiz
InfoInfo