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 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.18 Kosten für WAN-Verbindungen Ausbau der dezentralen IT-Struktur oder rigorose Zentralisierung?  downtop

Die für Server und Bandlaufwerke getroffenen Aussagen gelten übrigens auch für die Bandbreiten bei der Anbindung von Standorten oder Telearbeitsplätzen. Die Leitungskapazitäten und Kosten von WAN-Leitungen speziell über das Internet verändern sich drastisch. Beispiele dafür sind Flatrates und DSL-Verbindungen zum Internet Provider, die inzwischen jeder Privatperson zu erschwinglichen Kosten zur Verfügung stehen. Empfehlungen in Whitepapers, bei denen oft immer noch 64-KB/s Leitungen zugrunde gelegt werden, sind oft bereits Makulatur, wenn das Buch endlich gedruckt ist oder der Artikel im Internet erscheint. Mittels VPN können Standorte oder Telearbeitsplätze heute sicher, kostengünstig und mit hoher Bandbreite an zentrale Serverfarmen angeschlossen werden.

Das zukünftige Datenaufkommen auf den WAN-Leitungen setzt sich aus E-Mails, der Replikation der Inhalte öffentlicher Exchange-Ordner und dem Replikationsverkehr zwischen den globalen Katalogservern zusammen. Der angesprochene Active-Directory-Replikationsverkehr tritt natürlich nur in Domänen mit mehreren Standorten auf.

Zumindest in kleineren Organisationen ist der Replikationsverkehr zwischen den globalen Katalogservern der Standorte nur während der Einführungsphase beträchtlich. Denn bei Unternehmen, deren Organisationsstruktur recht stabil ist und die eine geringe Personalfluktuation haben, ändern sich sowohl die Mitgliedschaften in den Gruppen als auch die zu replizierenden Attribute nach der Einführung des Systems nicht mehr häufig.

Hinzu kommt eine weitere Auslastung der WAN-Leitungen, wenn Sie Terminalservertechnologie einsetzen. Diese Technologie ist unter Windows Server 2003 inzwischen so weit ausgereift, dass das Einsparpotenzial, das sich ergibt, wenn alle Anwendungen nur noch auf Servern in der Zentrale statt auf dezentralen Servern laufen, die Daten zentral gehalten und auch nur in der Zentrale gesichert werden müssen, immens ist.


Rheinwerk Computing

18.18.1 Replikationsverkehr zwischen den Standorten abschätzen  downtop

Um den durch das Einrichten neuer Postfächer, die Neuzuweisung zu Gruppen und die Änderung einzelner Attribute (z.B. die Telefonnummer oder die Raumnummer eines Mitarbeiters) hervorgerufenen Replikationsverkehr nach der Implementierungsphase abzuschätzen, saldieren Sie die Anzahl der Personalzugänge und -abgänge pro Jahr. Außerdem stellen Sie fest, wie viele Mitarbeiter pro Jahr die Abteilung wechseln oder wie oft im Jahr ein Mitarbeiter in eine Projektgruppe ein- oder austritt. Diese Anzahl dividieren Sie durch die Anzahl der Jahresarbeitstage und durch die Anzahl der Active-Directory-Standorte. So erhalten Sie die Anzahl der Änderungen, die pro Arbeitstag über die WAN-Leitungen an die globalen Katalogserver repliziert werden müssen. Der dadurch verursachte Replikationsverkehr wird zumindest in Einrichtungen des öffentlichen Dienstes sehr gering ausfallen, da dort die Personalfluktuationsrate in der Regel sehr gering ist. Er fällt z.B. dadurch erheblich niedriger aus, wenn Sie neutrale Kennungen (z.B. Benutzer001 bis Benutzer999) statt personalisierter Kennungen (Name des Benutzers als Benutzerkennung) einführen, da an diesen Kennungen so gut wie keine Änderungen mehr vorgenommen werden.

Ein Beispielszenario kann diesen theoretischen Sachverhalt aufhellen: Stellen Sie sich ein Unternehmen vor mit je 100 Mitarbeitern an 5 Standorten, also insgesamt 500 Mitarbeitern. Wenn jedes Jahr 10 Mitarbeiter pro Standort das Unternehmen verlassen und 10 neue Mitarbeiter eingestellt werden, so sind das 50 Objekte, die pro Jahr gelöscht, und 50 Objekte, die pro Jahr neu angelegt werden müssen, in der Summe 100 Objektänderungen.

Wenn außerdem an jedem Standort pro Jahr 10 Mitarbeiter die Abteilung wechseln, so müssen 50 Objekte aus Sicherheitsgruppen gelöscht werden und in eine andere Sicherheitsgruppe eingefügt werden. Das ergibt erneut 100 Objektänderungen.

Wenn durchschnittlich pro Standort und pro Jahr 5 Projektgruppen neu erstellt werden und 5 aufgelöst werden und diese Projektgruppen durchschnittlich aus 6 Projektmitarbeitern bestehen, so sind das pro Standort 60 Objektveränderungen, bei 5 Standorten also in der Summe weitere 300 Objektänderungen.

Insgesamt ergeben sich 100 + 100 + 300 = 500 Änderungen, die über ein Jahr mit ca. 220 Arbeitstagen zwischen den globalen Katalogservern der Standorte ausgetauscht werden müssen, das heißt pro Arbeitstag im Durchschnitt 2,3 Objektänderungen, die jedem globalen Katalogserver an jedem der 5 Standorte mitgeteilt werden müssen. Auch wenn in diesem Beispiel nicht sauber zwischen Objekten und Objektattributen unterschieden wird, so wird doch schnell deutlich, dass selbst eine langsame WAN-Verbindung zwischen den 5 Standorten mit dem erzeugten Replikationsverkehr nicht überfordert sein wird.

Besteht jedoch die Gesamtstruktur des Beispielunternehmens aus 50 Standorten mit durchschnittlich 500 Mitarbeitern, von denen pro Jahr 10  % das Unternehmen verlassen und durch Neueinstellungen ersetzt werden, so sind das 5  000 Objektänderungen pro Jahr (2  500 Abgänge und 2  500 Zugänge).

Wechseln außerdem 10  % der Mitarbeiter im Durchschnitt pro Jahr die Abteilung und damit ihre Zugehörigkeit zu Sicherheitsgruppen, so sind das 2  500 Abgänge aus einer Sicherheitsgruppe und 2  500 Zugänge zu einer anderen Sicherheitsgruppe, also zusammen weitere 5  000 Objektänderungen, die repliziert werden müssen.

Werden an jedem Standort pro Jahr 10 Projektgruppen mit durchschnittlich 5 Projektmitarbeitern ins Leben gerufen und genau so viele Projektgruppen aufgelöst, so sind das insgesamt 100 Mitgliedschaften in Projektgruppen, die pro Standort eingetragen oder aufgelöst werden müssen, in der Summe 5  000 Objektänderungen aufgrund von Änderungen bei der Projektgruppenzugehörigkeit.

Pro Jahr müssen also 15  000 Objektänderungen an jeden globalen Katalogserver repliziert werden, bei 220 Arbeitstagen sind das 68 Objektänderungen pro Arbeitstag. Bei einem kleinen Standort mit nur 20 Mitarbeitern, der durch eine langsame WAN-Verbindung angebunden ist und einen Domänencontroller mit globalem Katalogserver hat, können diese 68 Objektänderungen die Leitung stärker belasten. Ob die Leitung aber wegen des Replikationsverkehrs überlastet wird, ist zu bezweifeln. Der Engpass wird wahrscheinlich eher durch den E-Mail-Verkehr zwischen diesem Standort und den anderen Standorten verursacht als durch den Replikationsverkehr zum und vom globalen Katalogserver dieses Standortes.


Rheinwerk Computing

18.18.2 In den Ausbau der WAN-Leitungen und nicht in dezentrale Strukturen investieren  toptop

Projektiert man die Entwicklung der von Providern angebotenen WAN-Bandbreiten und deren Kosten aus der Vergangenheit in die Zukunft und versucht man aufgrund dieser Kostenprojektion, die beiden Alternativen »Modernisierung und weiterer Ausbau der dezentralen IT-Infrastruktur« und »rigorose Zentralisierung der IT-Infrastruktur« in einer mittelfristigen Gegenüberstellung von Kosten und Nutzen zu vergleichen, so wird man wahrscheinlich zu dem Ergebnis kommen, dass jeder eingesparte dezentrale Server, dezentrale Streamer, dezentral abzusichernde Serverraum (Zugangskontrolle, Doppelböden, Feuerschutz, Klimaanlage) und besonders die eingesparten dezentralen IT-Personalkosten den Ausbau der WAN-Leitungen rechtfertigen, mit dem langfristigen Ziel, Serverhardware und teures Know-how nur noch in einem zentralen Rechenzentrum zu vereinen.

Microsoft ist übrigens diesen Weg selbst gegangen. Schon im Buch »Das Multi-Server-Netzwerk« (Martin Kuppinger und Hans-Roland Becker, Microsoft Press, 1995) wurde beschrieben, wie Microsoft Zentraleuropa die Server in einem zentralen Rechenzentrum in Unterschleißheim zusammenführte. In den Niederlassungen von Microsoft finden Sie kaum noch Produktivserver und erst recht keine dezentralen Administratoren. Microsoft bietet übrigens regelmäßig Führungen durch das Microsoft-Rechenzentrum in Unterschleißheim an und demonstriert, wie das Münchner Rechenzentrum in das weltweite Microsoft-Netz eingebunden ist und wie der Umzug in das neue Gebäude im Oktober 2000 gemeistert wurde.

 << zurück
  
  Zum Katalog
Zum Katalog: Integrationshandbuch Microsoft-Netzwerk
Integrationshandbuch Microsoft-Netzwerk
Jetzt bestellen!
 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchtipps
Zum Katalog: Windows Server 2012 R2






 Windows Server
 2012 R2


Zum Katalog: Office 365






 Office 365


Zum Katalog: Microsoft Hyper-V






 Microsoft Hyper-V


Zum Katalog: IT-Handbuch für Fachinformatiker






 IT-Handbuch für
 Fachinformatiker


Zum Katalog: Windows 8 für Administratoren






 Windows 8 für
 Administratoren


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
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.


[Rheinwerk Computing]

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