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

 << zurück
Integrationshandbuch Microsoft-Netzwerk von Ulrich Schlüter
Windows Server 2003 R2, SBS 2003, ADS, Exchange Server, Windows XP und Microsoft Office
Buch: Integrationshandbuch Microsoft-Netzwerk

Integrationshandbuch Microsoft-Netzwerk
1.008 S., mit CD, 69,90 Euro
Rheinwerk Computing
ISBN 3-89842-847-8

>>Jetzt Buch bestellen!
gp Kapitel 18 Strategische Überlegungen und Tipps
  gp 18.1 Den Speicherverbrauch in den Griff bekommen
    gp 18.1.1 Speicherplatz zum Nulltarif zurückgewinnen
    gp 18.1.2 Kernentscheidungen zur Vermeidung unnötiger Speicherkosten
    gp 18.1.3 Welche Arten von Speicherfressern gibt es?
    gp 18.1.4 Wie spüren Sie diese Speicherfresser auf?
    gp 18.1.5 Wie vermeiden Sie zukünftig diese Speicherfresser?
    gp 18.1.6 Hardlinks und Abzweigungspunkte einsetzen
    gp 18.1.7 Verpflichtungserklärung als Anlage zum Arbeitsvertrag
  gp 18.2 Serverkonsolidierung durch Hardware-Virtualisierung
  gp 18.3 Windows Storage Server 2003 R2, Windows Compute Cluster Server 2003 oder Data Protection Manager 2006 einsetzen
  gp 18.4 Das Synchronisieren von Datenbeständen zwischen Servern verschiedener Standorte
  gp 18.5 Die Zeitsynchronisation innerhalb der Gesamtstruktur
  gp 18.6 Gruppentypen und Gruppenverschachtelung
  gp 18.7 Migration oder Neuinstallation
  gp 18.8 Domäne umbenennen – Domänencontroller mehrere Servernamen zuweisen
  gp 18.9 Das Rationalisierungspotenzial der RIS- und RIPrep–Methode
    gp 18.9.1 Die Testumgebung produktiv nutzen
    gp 18.9.2 Abbilder mit einem Laptop als RIS-Server mobil einspielen
    gp 18.9.3 Die Ergebnisse der Testumgebung mit geringem Aufwand in mehrere Produktivdomänen übernehmen
    gp 18.9.4 Kundendomänen standardisiert hochziehen und warten
  gp 18.10 Benötigte HAL-Abbilder
    gp 18.10.1 Windows mit mehreren HAL-Typen parallel installieren
    gp 18.10.2 Wenn mit Imagetools erstellte Systemabbilder nicht starten
  gp 18.11 Welche Anwendungen gehören in ein Abbild, welche sollten nachinstalliert werden?
    gp 18.11.1 MSI-Dateien für unbeaufsichtigte Installationen neu packen oder selbst erstellen
    gp 18.11.2 Sollte der Virenscanner in das Abbild eines Mustercomputers eingehen?
    gp 18.11.3 Sollte der Client einer kaufmännischen Anwendung in das Abbild eines Mustercomputers eingehen?
  gp 18.12 Welche Anwendungen können über Gruppenrichtlinien installiert werden?
  gp 18.13 MSI-Pakete zuweisen oder veröffentlichen?
  gp 18.14 Software wohl proportioniert verteilen
  gp 18.15 Ausfallsicherheit bei Servern
  gp 18.16 Einsparpotenziale bei der Beschaffung von Hardware
    gp 18.16.1 Preis- und Garantieverfall verbieten den Kauf auf Vorrat
    gp 18.16.2 Wartungsverträge für Server nützen vorwiegend dem Hersteller
  gp 18.17 Einsparpotentiale bei Software
    gp 18.17.1 PCs mit Windows XP Home Edition in eine Domäne aufnehmen
    gp 18.17.2 Gebrauchte Software preiswert einkaufen
    gp 18.17.3 Was ist »gebrauchte Software«?
    gp 18.17.4 Darf man Software weiterveräußern?
    gp 18.17.5 Darf man OEM-Software weiterveräußern?
    gp 18.17.6 Ist Gebrauchtsoftware updateberechtigt?
    gp 18.17.7 Was ist, wenn die gebrauchte Software schon registriert wurde?
    gp 18.17.8 Nach gebrauchter Software recherchieren
  gp 18.18 Kosten für WAN-Verbindungen – Ausbau der dezentralen IT-Struktur oder rigorose Zentralisierung?
    gp 18.18.1 Replikationsverkehr zwischen den Standorten abschätzen
    gp 18.18.2 In den Ausbau der WAN-Leitungen und nicht in dezentrale Strukturen investieren
  gp 18.19 Lizenzrechtliche Probleme
    gp 18.19.1 Microsoft Office oder OpenOffice?
    gp 18.19.2 Welche Microsoft-Office-Edition einsetzen?
  gp 18.20 Daten von defekten Festplatten wiederherstellen lassen
  gp 18.21 Das WWW-Prinzip: Work With Winners
  gp 18.22 Abhängigkeit von Einzelpersonen vermeiden
  gp 18.23 Das Vieraugen-Prinzip
  gp 18.24 Das KISS-Prinzip zur Vermeidung unnötiger Komplexität
  gp 18.25 Empfehlungen in Büchern und in Whitepapers des Internets haben ein sehr kurzes Verfallsdatum


Rheinwerk Computing

18.15 Ausfallsicherheit bei Servern  toptop

Werden mehrere Server in einer Domäne eingesetzt und besitzen diese Server unterschiedliche Funktionen, so stellt sich permanent die Frage, ob und welche Serverfunktionen redundant ausgelegt werden sollen und ob ein sinnvolles Arbeiten überhaupt möglich ist, wenn einer der Server ausgefallen ist. Holen Sie sich den Rat von drei unabhängigen Beratern zur Verteilung der Serverfunktionen und zur Absicherung der Server ein, und Sie werden mit großer Wahrscheinlichkeit drei verschiedene Konzepte als Lösungsvorschläge erhalten. Die Ursache ist nicht unbedingt ein unterschiedliches Wissen der Experten oder der Wunsch, Ihnen als neuem Kunden einen möglichst großen Auftragswert zu entlocken. Es gibt schlichtweg keine allgemein gültigen Konzepte, die auch in Bezug auf Kosten und Nutzen auf jedes Unternehmen nach »Schema F« anwendbar sind. Ebenso ist es sehr schwierig, das in der IT-Abteilung vorhandene Know-how treffend zu bewerten, das notwendig ist, um in Problemsituationen richtig vorzugehen, den Schaden gering zu halten und den aufgetretenen Fehler sachkundig zu analysieren und zu beheben.

Gibt es mehrere Standorte, an denen Server dezentral aufgestellt werden müssen, so wächst die Komplexität des Systems nicht linear, sondern eher exponentiell an. Sofort stellt sich die Frage, ob dezentrale Systemadministratoren auf ausreichend hohem Niveau geschult werden können, um mit Problemsituationen sachkundig umgehen zu können, oder ob es nicht kostengünstiger und bezüglich einer über die Standorte hinweg gleich bleibenden Qualität besser ist, fehlendes Know-how durch teure Anfangsinvestitionen zu kompensieren.

Gleichfalls schwer zu treffen sind quantifizierbare Aussagen darüber, wie kritisch die Verfügbarkeit der IT-Systeme für den Geschäftsprozess des Unternehmens ist: Welchen Schaden erleidet z.B. ein Unternehmen, wenn die IT-Dienste mehrere Stunden oder mehrere Tage nicht verfügbar sind? Was kostet der Produktionsausfall? Mit welchen Regressansprüchen seitens der Kunden muss eventuell gerechnet werden, wenn aufgrund des IT-Ausfalls Fertigstellungs- oder Liefertermine nicht eingehalten werden können? Wie groß ist der Image-Schaden für die IT-Abteilung gegenüber der Geschäftsleitung, wie groß ist der Image-Schaden des Unternehmens gegenüber den Kunden?

Eine mögliche Lösung: das Clustern von Servern

Das Clustern von Windows-Servern ist nicht mehr so teuer und kompliziert wie in den Anfangstagen dieser Technologie. Inzwischen bieten Server-Hersteller preiswerte Clusterlösungen »out of the box« an. Besteht Ihr Unternehmen aus vielen Filialen mit Benutzerzahlen, bei denen der Ausfall des Systems geschäftskritisch ist, das Aufstellen und Managen von Ausfallservern jedoch andererseits zu teuer und zu aufwändig erscheint, so sollten Sie einmal ein Angebot über einen Clusterserver einholen und Aufwand und Kosten mit ausfallsicheren Lösungen vergleichen, bei denen die Last und die Dienste auf mehrere Server pro Standort verteilt werden. Wie die Verkaufszahlen des Small Business Servers beweisen, ist es durchaus möglich, bis zu 75 Anwender mit einem Server zu bedienen und alle wichtigen Dienste wie DNS, DHCP, WINS, globaler Katalog, RIS, Datei- und Druckserver, Exchange Server, ja sogar SQL-Server und SMS-Server auf diesem Server unterzubringen, wenn an der Hardware-Ausstattung des Servers nicht gespart wird.

Ausfallszenarien

Zur Veranschaulichung skizzieren wir eine Beispieldomäne: Sie besteht aus zwei Domänencontrollern, damit sich die Mitarbeiter bei einem Ausfall des ersten Domänencontrollers über den zweiten weiter anmelden können. Liegen die servergespeicherten Profile (Roaming Profiles), die Basisverzeichnisse (Home Directories) der Anwender oder die Gruppenablagen auf dem ausgefallenen Server, so wird die Arbeit trotz geglückter Anmeldung über den zweiten Domänencontroller stark beeinträchtigt. Man wird einwerfen, dass die Mitarbeiter bis zur Wiederverfügbarkeit des ersten Domänencontrollers zumindest Microsoft Office starten und neue Dokumente erstellen können, die sie dann auf der lokalen Festplatte zwischenspeichern können. Liegen jedoch die Vorlageverzeichnisse mit den Vorlagen für Geschäftsbriefe und Berichte ebenfalls auf dem ausgefallenen Server, so können auch keine Briefe oder Berichte verfasst werden. Könnten diese Dokumente denn ausgedruckt werden? Nicht, wenn der Ausdruck auf Netzdruckern erfolgen muss und die Warteschlangen der Netzdrucker auf dem ausgefallenen Server liegen.

In einer derartigen Stresssituation ist es andererseits für den Administrator kaum zumutbar, beim Lösen seines Serverproblems ständig durch die Anrufe von Mitarbeitern gestört zu werden, die zwar Word, Excel oder den Internet Explorer starten können, jedoch die Dokumentvorlagen nicht finden, nicht wissen, wohin sie ein neues Dokument speichern sollen, da doch der auf den ausgefallenen Server umgeleitete Ordner Eigene Dateien plötzlich ins Nichts verweist, oder deren Internet Explorer plötzlich keine Favoriten mehr anzeigt, weil das Favoriten-Verzeichnis ebenfalls auf den ausgefallenen Server umgelegt wurde.

Zweifelhaft ist es, ob die Mitarbeiter besser bedient sind, wenn sie während des Ausfalls des Servers weiterhin Dokumente erstellen und lokal auf den Festplatten abspeichern können. Ist der ausgefallene Server wieder betriebsbereit und melden die Mitarbeiter sich erneut an, so besteht die Gefahr, dass sie die lokal gespeicherten Dokumente nicht wieder finden oder aber nicht auf den Server verschieben und weitere Dokumente lokal speichern. Diese würden dann jedoch nicht in die tägliche Sicherung einfließen und bei einem Ausfall der lokalen Festplatte endgültig verloren gehen. Der Supportaufwand wird wahrscheinlich unverhältnismäßig hochgetrieben. Ein Konzept, das Datenhaltung aus Datenschutz- und Datensicherheitsgründen ausschließlich auf dem Server vorsieht, wird ausgehöhlt, wenn bei Ausfall eines Servers mit den lokal zwischengespeicherten Profilen weitergearbeitet werden darf.

Was nützt es andererseits, wenn der Domänencontroller zwecks Ausfallsicherheit doppelt ausgelegt wurde, jedoch der Datenbankserver ausfällt, der das Backend zur kaufmännischen Anwendung ist? Wenn z.B. SAP die geschäftskritische Anwendung ist und der SAP-Datenbankserver ausfällt oder die Leitung zum SAP-Host unterbrochen ist, können sich die Mitarbeiter zwar an der Domäne anmelden und vielleicht die Zeit mit Surfen im Internet überbrücken, der betriebliche Schaden wird dadurch jedoch kaum gemildert.

Und wie wichtig ist die Ausfallsicherheit des Exchange Server als Kommunikationsplattform zwischen den Mitarbeitern des Unternehmens und den Kunden? Wenn alle Kunden- und Lieferantenadressen als externe Kontakte auf dem Exchange Server gepflegt werden und die gesamte Korrespondenz mit Kunden und Lieferanten sowie geschäftskritischer Workflow über die öffentlichen Ordner des Exchange Server abgewickelt wird, nützt es recht wenig, wenn der Exchange Server wegen fehlender Redundanz komplett ausfällt, dass die Domänencontroller, Dateiserver und Datenbankserver redundant ausgelegt sind und sauber ihre Dienste bereitstellen. Das Geschäft liegt dann danieder.

In Kapitel 24, Serverdienste und Ausfallfallsicherheit, wird auf die redundante Auslegung von Servern mit bestimmten Diensten ausführlich eingegangen.

 << zurück
  
 Ihre Meinung?
Wie hat Ihnen das Openbook gefallen?
Ihre Meinung

 Buchtipps
Zum Rheinwerk-Shop: Windows Server 2012 R2






 Windows Server
 2012 R2


Zum Rheinwerk-Shop: Office 365






 Office 365


Zum Rheinwerk-Shop: Microsoft Hyper-V






 Microsoft Hyper-V


Zum Rheinwerk-Shop: IT-Handbuch für Fachinformatiker






 IT-Handbuch für
 Fachinformatiker


Zum Rheinwerk-Shop: Windows 8 für Administratoren






 Windows 8 für
 Administratoren


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





Copyright © Rheinwerk Verlag GmbH 2006
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