Kapitel 5 Bereitstellungskonzept

In der Entwicklungsphase eines Bereitstellungskonzepts w�hrend des Lebenszyklus der L�sung entwerfen Sie eine Bereitstellungsarchitektur auf hoher Ebene und eine Implementierungsspezifikation auf niedriger Ebene und bereiten eine Reihe von Pl�nen und Spezifikationen vor, die f�r die Implementierung der L�sung erforderlich sind. Die Projektgenehmigung findet in der Bereitstellungskonzeptphase statt.

Bereitstellungskonzept

Die Erstellung eines Bereitstellungskonzepts beginnt mit dem Bereitstellungsszenario, das w�hrend der Phasen des logischen Designs und der technischen Anforderungen des Lebenszyklus der L�sung erstellt wurde. Das Bereitstellungsszenario umfasst eine logische Architektur und die f�r die L�sung erforderlichen Anforderungen hinsichtlich der Dienstqualit�t (Quality of Service, QoS). Die in der logischen Architektur identifizierten Komponenten werden f�r physische Server und andere Netzwerkger�te �bergreifend zugeordnet, um eine Bereitstellungsarchitektur zu erstellen. Die QoS-Anforderungen bieten Anhaltspunkte hinsichtlich der Hardwarekonfiguration in Bezug auf Leistung, Verf�gbarkeit, Skalierbarkeit und andere QoS-Spezifikationen in diesem Zusammenhang.

Bei der Konzeption der Bereitstellungsarchitektur handelt es sich um einen von Wiederholungen gepr�gten Vorgang. Im Normalfall werden die QoS-Anforderungen erneut zurate gezogen und die im Vorfeld festgelegten Konzepte nochmals �berpr�ft. Hierbei wird die Wechselbeziehung der QoS-Anforderungen in Betracht gezogen und es wird versucht, ein Gleichgewicht zwischen dem so genannten Tradeoff und den Gesamtkosten zu erzielen, um so letzlich �ber eine optimale L�sung zu verf�gen, die den Gesch�ftszielen des Projekts gerecht wird.

Projektgenehmigung

Die Projektgenehmigung erfolgt im Rahmen der Bereitstellungskonzeptphase, im Normalfall nach der Erstellung der Bereitstellungsarchitektur. Die gesch�tzten realen Bereitstellungskosten werden anhand der Bereitstellungsarchitektur und ggf. anhand der nachfolgend beschriebenen Implementierungsspezifikationen ermittelt und den Interessengruppen zur Genehmigung vorgelegt. Im Anschluss an die Projektgenehmigung werden Vertr�ge hinsichtlich des Bereitstellungsabschlusses unterzeichnet und es werden die Ressourcen erworben und zugeordnet, die zur Implementierung des Projekts erforderlich sind.

Bereitstellungskonzeptausgaben

In der Bereitstellungskonzeptphase werden m�glicherweise folgende Spezifikationen und Pl�ne ausgearbeitet:

Bereitstellungsarchitektur. Eine Architektur auf hoher Ebene, aus der die Zuordnung einer logischen Architektur zu einer physischen Umgebung hervorgeht. Die physische Umgebung umfasst die Computerknoten in einer Intranet- bzw. Internetumgebung, Prozessoren, Speicher, Speicherger�te sowie weitere Hardware und Netzwerkger�te.

Implementierungsspezifikationen. Detaillierte Spezifikationen, die zur Erstellung der Bereitstellung herangezogen werden. Aus diesen Spezifikationen geht hervor, welche Computer- und Netzwerkhardware erforderlich ist. Au�erdem wird hier das Netzwerklayout f�r die Bereitstellung erl�utert. Zu den Implementierungsspezifikationen z�hlen Directory Services (Verzeichnisdienste), einschlie�lich Details zu Spezifikationen f�r einen Verzeichnisinformationsbaum (Directory Information Tree, DIT) sowie der f�r den Verzeichniszugriff definierten Gruppen und Rollen.

Implementierungspl�ne. Eine Reihe von Pl�nen, die unterschiedliche Aspekte der Implementierung einer Unternehmenssoftwarel�sung abdecken. Zu den Implementierungspl�nen z�hlen:

Migrationsplan. Hier werden die Strategien und Vorg�nge zur Migration von Unternehmensdaten und zur Aufr�stung von Unternehmenssoftware erl�utert. Die migrierten Daten m�ssen den Formaten und Standards der neu installierten Unternehmensanwendungen entsprechen. Voraussetzung f�r die Interoperabilit�t ist, dass von jeglicher Unternehmenssoftware die richtige Version vorliegt.

Installationsplan. Dieser Plan wird von der Bereitstellungsarchitektur abgeleitet und gibt Servernamen, Installationsverzeichnis, Installationsreihenfolge, Installationstypen f�r die einzelnen Knoten sowie die Konfigurationsinformationen an, die f�r die Installation und Konfiguration einer verteilten Bereitstellung erforderlich sind.

Benutzerverwaltungsplan. Umfasst Migrationsstrategien f�r Daten in bestehenden Verzeichnissen und Datenbanken, Spezifikationen zum Verzeichniskonzept, bei denen das in der Bereitstellungsarchitektur angegebene Kontoreplikationskonzept beachtet wird, sowie Vorgehensweisen zur Bereitstellung neuer Inhalte f�r Verzeichnisse.

Testplan. Hier wird beschrieben, wie die bereitgestellte Software getestet wird, einschlie�lich spezifischer Pl�ne f�r die Bereitstellung von Prototyp- und Pilotimplementierungen. Ein weiterer Bestandteil sind Belastungstests, bei denen die F�higkeit zur Handhabung der geplanten Auslastung ermittelt wird; bei Funktionstests wird �berpr�ft, ob der Betrieb erwartungsgem�� verl�uft.

Roll-out-Plan. Hier werden die Vorgehensweisen sowie der Terminplan f�r die Implementierung aus einer Plan- und Testumgebung in eine Produktionsumgebung erl�utert. Im Normalfall erfolgt die Implementierung in eine Produktionsumgebung in mehreren Phasen. Die erste Phase kann beispielsweise die Bereitstellung der Software f�r eine kleine Gruppe von Benutzern sein. Dann wird mit jeder weiteren Phase die Benutzeranzahl erh�ht, bis die Bereitstellung komplett abgeschlossen ist. Bei der phasenweisen Implementierung kann auch die zeitlich festgelegte Implementierung bestimmter Softwarepakete erfolgen, bis die Bereitstellung komplett abgeschlossen ist.

Wiederherstellungsplan. Hier wird erl�utert, wie das System nach unerwarteten Gesamtausf�llen wiederhergestellt werden kann. Der Wiederherstellungsplan sieht sowohl Vorgehensweisen f�r Ausf�lle gro�en als auch kleinen Ausma�es vor.

Betriebsplan (Run Book (Ausf�hrungsbuch)). Ein Handbuch mit Vorg�ngen, in dem �berwachungs-, Wartungs-, Installations- und Aufr�stungsaspekte angesprochen werden.

Schulungsbuch. Enth�lt Vorg�nge und Vorgehensweisen zur Schulung der Personen, die mit der neu installierten Software arbeiten werden (u. a. Administratoren und Endbenutzer).

Faktoren mit Auswirkung auf das Bereitstellungskonzept

Die Entscheidungen, die Sie in der Bereitstellungskonzeptphase treffen, werden von mehreren Faktoren beeinflusst. Ziehen Sie folgende Hauptfaktoren in Betracht:

Logische Architektur. In der logischen Architektur werden die Dienste in einer geplanten L�sung detailliert erl�utert; au�erdem wird auf die Wechselbeziehung zwischen den Komponenten eingegangen, die diese Dienste zur Verf�gung stellen. Verwenden Sie die logische Architektur als Anhaltspunkt daf�r, wie Dienste optimal verteilt werden k�nnen. Ein Bereitstellungsszenario umfasst die logische Architektur sowie die Anforderungen hinsichtlich der Dienstqualit�t (siehe nachfolgende Beschreibung).

Dienstqualit�tsanforderungen. Anhand der Anforderungen hinsichtlich der Dienstqualit�t (Quality of Service, QoS) werden unterschiedliche Aspekte des Betriebs einer L�sung angegeben. Anhand der QoS-Anforderungen k�nnen Sie Strategien ausarbeiten, mit denen Leistung, Verf�gbarkeit, Skalierbarkeit, Wartungseignung sowie andere Ziele in Bezug auf die Dienstqualit�t erreicht werden k�nnen. Ein Bereitstellungsszenario umfasst die (zuvor beschriebene) logische Architektur sowie die Anforderungen hinsichtlich der Dienstqualit�t.

Anwendungsanalyse. Die Anwendungsanalyse, die in der auf die technischen Anforderungen bezogenen Phase im L�sungszyklus erstellt wird, gibt Aufschluss �ber Anwendungsmuster, mit deren Hilfe sich Auslastung und Belastung in einem bereitgestellten System einsch�tzen lassen. Nutzen Sie die Anwendunganalyse, um leistungsbezogene Engp�sse zu isolieren und Strategien zur Erf�llung von QoS-Anforderungen auszuarbeiten.

Anwendungsf�lle. In Anwendungsf�llen, die in der auf die technischen Anforderungen bezogenen Phase im L�sungszyklus erstellt wurden, werden eindeutige Benutzerinteraktionen aufgef�hrt, die f�r eine Bereitstellung identifiziert wurden. Oft werden hierbei die g�ngigsten Anwendungsf�lle identifiziert. Obwohl die Anwendungsf�lle Bestandteil der Anwendungsanalyse sind, empfiehlt es sich, bei der Bewertung eines Bereitstellungskonzepts die Anwendungsf�lle zurate zu ziehen, um sicherzustellen, dass die entsprechenden Probleme richtig angegangen werden.

Vereinbarungen auf Dienstebene. In einer Vereinbarung auf Dienstebene (Service Level Agreement, SLA) werden die leistungsbezogenen Mindestanforderungen angegeben. Wenn diese Anforderungen nicht erf�llt werden, geht hieraus ebenfalls hervor, auf welcher Ebene und in welchem Umfang Kundenunterst�tzung vonn�ten ist. Die in einer Vereinbarung auf Dienstebene angegebenen Leistungsanforderungen sollten von einem Bereitstellungskonzept problemlos erf�llt werden.

Gesamtkosten. Bei der Ausarbeitung des Bereitstellungskonzepts analysieren Sie potenzielle L�sungen, die sich u. a. auf die Verf�gbarkeits-, Leistungs- und Skalierungsaspekte der QoS-Anforderungen beziehen. Bei jeder in Betracht gezogenen L�sung m�ssen jedoch auch die Kosten dieser L�sung sowie die Auswirkung dieser L�sung auf die Gesamtkosten beachtet werden. Ziehen Sie in jedem Fall den Tradeoff Ihrer Beziehung in Betracht und stellen Sie sicher, dass Ihre Ressourcen so optimiert wurden, dass die Gesch�ftsanforderungen innerhalb der Unternehmensgrenzen erf�llt werden.

Gesch�ftsziele. Gesch�ftsziele werden w�hrend der Phase der Gesch�ftsanalyse des L�sungszyklus festgelegt; hierzu z�hlen die Gesch�ftsanforderungen sowie die unternehmerischen Einschr�nkungen, die bei der Erf�llung dieser Ziele beachtet werden m�ssen. Das Bereitstellungskonzept wird letzlich anhand seiner F�higkeit zur Erf�llung der Gesch�ftsziele beurteilt.

Bereitstellungskonzept Methodik

Genau wie bei anderen Aspekten der Bereitstellungsplanung ist die Ausarbeitung des Bereitstellungskonzepts sowohl eine Kunst als auch eine Wissenschaft; folglich k�nnen hierf�r keine bis ins kleinste Detail spezifischen Vorg�nge und Vorgehensweise vorgegeben werden. Die Faktoren, die zu einem erfolgreichen Bereitstellungskonzept beitragen, gehen �ber Erfahrung bei der Konzeption, Kenntnisse im Bereich Systemarchitektur und Dom�nen sowie angewandtes kreatives Denken hinaus.

Bei der Bereitstellungskonzeption dreht es sich im Normalfall haupts�chlich darum, Leistungsvorgaben zu erf�llen und gleichzeitig anderen QoS-Anforderungen gerecht zu werden. Mit den von Ihnen eingesetzten Strategien muss ein Gleichgewicht der Tradeoffs Ihres Konzepts erreicht werden, um die L�sung zu optimieren. Die verwendete Methodik umfasst im Regelfall folgende Aufgaben:

Einsch�tzen von Prozessoranforderungen. Der erste Schritt bei der Bereitstellungskonzeption besteht h�ufig darin, die Anzahl der CPUs einzusch�tzen, die f�r die einzelnen Komponenten in der logischen Architektur erforderlich sind. Beginnen Sie mit den F�llen, die f�r die h�chste Auslastung stehen, und gehen Sie dann die restlichen Anwendungsf�lle durch. Ziehen Sie die Auslastung s�mtlicher Komponenten in Betracht, die die Anwendungsf�lle unterst�tzen, und passen Sie Ihre Einsch�tzungen entsprechend an. Greifen Sie auch auf Erfahrungen zur�ck, die Sie bisher bei der Konzeption von Unternehmenssystemen gesammelt haben.

Einsch�tzen von Prozessoranforderungen f�r sicheren Transport. Befassen Sie sich mit den F�llen, bei denen sicherer Transport erforderlich ist, und passen Sie die CPU-Einsch�tzungen entsprechend an.

Replizieren von Diensten hinsichtlich Verf�gbarkeit und Skalierbarkeit. Wenn die Prozessoreinsch�tzungen Ihren Vorstellungen entsprechen, nehmen Sie die �nderungen am Konzept vor, die hinsichtlich der QoS-Anforderungen in Bezug auf Verf�gbarkeit und Skalierbarkeit erforderlich sind. Ziehen Sie hierbei L�sungen f�r den Lastenausgleich in Betracht, bei denen Verf�gbarkeitsaspekte sowie Failover-Faktoren angegangen werden.

Identifizierung von Engp�ssen. �berpr�fen Sie bei weiteren Analyseschritten das Bereitstellungskonzept, um m�gliche Engp�sse auszumachen, durch die die Daten�bertragungsrate unter die Anforderungsgrenze absinkt, und nehmen Sie die entsprechenden Anpassungen vor.

Optimieren von Ressourcen. �berpr�fen Sie Ihr Bereitstellungskonzept in Bezug auf die Ressourcenverwaltung und ziehen Sie hierbei Optionen in Betracht, die die Anforderungen erf�llen und gleichzeitig die Kosten senken.

Verwalten von Risiken. Sehen Sie sich Ihre gesch�ftsbezogenen und technischen Analysen in Bezug auf Ihr Konzept nochmals durch und nehmen Sie �nderungen vor, die Ereignisse oder Situationen abdecken, die in fr�heren Planungsphasen au�er Acht gelassen wurden.

Einsch�tzen von Prozessoranforderungen

In diesem Abschnitt wird erl�utert, wie die Anzahl der Prozessoren (Central Processing Units, CPUs) sowie der erforderliche Speicherbedarf zur Unterst�tzung der Dienste in einem Bereitstellungskonzept ermittelt werden k�nnen. Hier wird anhand eines Beispielszenarios einer Kommunikationsbereitstellung Schritt f�r Schritt erkl�rt, wie die Einsch�tzung in diesem Fall abl�uft.

Bei der Einsch�tzung der CPU-Kapazit�t handelt es sich um einen von Wiederholungen gepr�gten Vorgang, bei dem folgende Punkte beachtet werden:

Logische Komponenten und deren Interaktion (gem�� der Darstellung von Komponentenabh�ngigkeiten in der logischen Architektur)

Anwendungsanalyse f�r die identifizierten Anwendungsf�lle

Dienstqualit�tsanforderungen

Bisher gesammelte Erfahrungen mit Bereitstellungskonzepten und Java Enterprise System

Beratung mit Sun Anbietern professioneller Dienste, die auf dem Gebiet der Konzeption und Implementierung unterschiedlicher Bereitstellungstypen erfahren sind

Der Einsch�tzungsvorgang umfasst die nachfolgend aufgef�hrten Schritte: Die Reihenfolge dieser Schritte ist nicht zwingend vorgegeben, stellt jedoch eine M�glichkeit zur Betrachtung der Faktoren dar, die sich auf das Endergebnis auswirken.

Ermitteln einer CPU-Basiseinsch�tzung f�r Komponenten, die f�r das System als Benutzereinstiegspunkte identifiziert wurden.

Eine bei der Konzeption zu treffende Entscheidung besteht darin, festzulegen, ob CPUs vollst�ndig oder teilweise geladen werden. Durch vollst�ndig geladene CPUs wird die Kapazit�t eines Systems maximiert. Bei der Kapazit�tssteigerung fallen Wartungskosten an; au�erdem muss die m�gliche Ausfallzeit beachtet werden, die durch das Hinzuf�gen weiterer CPUs anf�llt. In einigen F�llen haben Sie die M�glichkeit, weitere Computer hinzuzuf�gen, um den wachsenden Leistungsanforderungen gerecht zu werden.

Durch teilweise geladene CPUs wird die Verarbeitung �berm��iger Leistungsanforderungen erm�glicht, ohne dass hierbei sofort Wartungskosten anfallen. Aufgrund des nicht voll ausgelasteten Systems fallen jedoch Vorabkosten an.

Passen Sie die CPU-Einsch�tzungen so an, dass die Interaktion zwischen Komponenten ber�cksichtigt wird.

Sehen Sie sich die Interaktion zwischen Komponenten in der logischen Architektur genau an, um zu ermitteln, in welchen F�llen es durch abh�ngige Komponenten zu zus�tzlicher Auslastung kommt.

�berpr�fen Sie die Anwendungsanalyse auf spezifische Anwendungsf�lle hin, um die Spitzenauslastung f�r das System zu ermitteln, und nehmen Sie dann �nderungen an den Komponenten vor, die zur Verarbeitung dieser Spitzenauslastung vorgesehen sind.

Beginnen Sie mit den Anwendungsf�llen mit der gr��ten Gewichtung (die zur gr��ten Auslastung f�hren) und gehen Sie dann alle verbleibenden Anwendungsf�lle durch, um zu gew�hrleisten, dass s�mtliche geplanten Anwendungsszenarios abgedeckt sind.

Passen Sie die CPU-Einsch�tzungen so an, dass die Sicherheits-, Verf�gbarkeits- und Skalierbarkeitsanforderungen ber�cksichtigt werden.

Durch den Einsch�tzungsvorgang werden Anhaltspunkte zur Ermittlung der tats�chlich ben�tigten Verarbeitungsleistung bereitgestellt. Im Normalfall werden Prototypbereitstellungen basierend auf diesen Einsch�tzungen erstellt; anschlie�end erfolgt das strenge Testverfahren anhand erwarteter Anwendungsf�lle. Die tats�chlichen Verarbeitungsanforderungen f�r ein Bereitstellungskonzept lassen sich nur durch wiederholte Testl�ufe ermitteln.

Beispiel f�r das Einsch�tzen von Prozessoranforderungen

In diesem Abschnitt wird eine der Methoden erl�utert, mit der die f�r eine Beispielbereitstellung erforderliche Verarbeitungsleistung eingesch�tzt werden kann. Die Beispielbereitstellung basiert auf der logischen Architektur der identit�tsbasierten Kommunikationsl�sung f�r ein mittelst�ndisches Unternehmen (1000 bis 5000 Mitarbeiter), die im Abschnitt Identit�tsbasiertes Kommunikationsbeispiel erl�utert wird.

Die in diesem Beispiel verwendeten CPU-Werte und Speicherangaben sind willk�rlich gew�hlt und dienen lediglich der Veranschaulichung. Diese Angaben sind auf willk�rlich gew�hlten Daten begr�ndet, auf denen das theoretische Beispiel basiert. Zur Einsch�tzung der Prozessoranforderungen ist die eingehende Analyse unterschiedlicher Faktoren erforderlich. Diese Analyse w�rde folgende Informationen umfassen, ist jedoch nicht auf sie beschr�nkt:

Detaillierte Anwendungsf�lle und Anwendungsanalyse basierend auf eingehender Gesch�ftsanalyse

Durch Analyse von Gesch�ftsanforderungen ermittelte QoS-Anforderungen

Spezifische Kosten und Spezifikationen von Verarbeitungs- und Netzwerkhardware

Bei der Implementierung vergleichbarer Bereitstellungen gesammelte Erfahrungen



Achtung	Die in diesen Beispielen enthaltenen Informationen sollten nicht als spezifische Implementierungshinweise angesehen werden, sie dienen lediglich der Veranschaulichung eines Vorgangs, den Sie bei der Konzeption eines Systems m�glicherweise durchf�hren.

Ermitteln der CPU-Basiseinsch�tzung f�r Benutzereinstiegspunkte

Sch�tzen Sie zun�chst die Anzahl an CPUs ab, die zur Vearbeitung der erwarteten Auslastung s�mtlicher Komponenten ben�tigt werden, bei denen es sich um Benutzereinstiegspunkte handelt. Nachfolgend ist die logische Architektur f�r ein identit�tsbasiertes Kommunikationsszenario dargestellt, das zuvor (Kapitel 4, „Logisches Konzept“) beschrieben wurde.

Abbildung 5-1 Logische Architektur f�r ein identit�tsbasiertes Kommunikationsszenario

In der nachfolgenden Tabelle sind die Komponenten in der Pr�sentationsschicht der logischen Architektur aufgef�hrt, die in direkter Verbindung mit dem Endbenutzer der Bereitstellung stehen. Die Tabelle enth�lt CPU-Basiseinsch�tzungen, die von der Analyse der technischen Anforderungen, von Anwendungsf�llen, von der spezifischen Anwendungsanalyse sowie von mit diesem Bereitstellungstyp gesammelten Erfahrungen abgeleitet wurden.

Tabelle 5-1 CPU-Einsch�tzungen f�r Komponenten mit zugriffsbezogenen Benutzereinstiegspunkten
Komponente	Anzahl der CPUs	Beschreibung
Portal Server	4	Komponente, die Benutzereinstiegspunkt ist.
Communications Express	2	Leitet Daten an Messaging- und Kalender-Kan�le von Portal Server weiter.

CPU-Einsch�tzungen f�r Dienstabh�ngigkeiten aufnehmen

F�r die Komponenten, die Benutzereinstiegspunkte zur Verf�gung stellen, ist die Unterst�tzung weiterer Java Enterprise System-Komponenten erforderlich. Wenn Sie die Angabe von Leistungsanforderungen fortsetzen m�chten, nehmen Sie die Leistungseinsch�tzungen auf, damit die von anderen Komponenten ben�tigte Unterst�tzung ber�cksichtigt wird. Bei der Konzeption der logischen Architektur sollte der Typ von Interaktion zwischen Komponenten genau angegeben werden, wie im Beispiel mit der logischen Architektur im Abschnitt Beispiele f�r logische Architekturen erl�utert.

Tabelle 5-2 CPU-Einsch�tzungen f�r unterst�tzende Komponenten
Komponente	CPUs	Beschreibung
Messaging Server MTA (Eingang)	1	Leitet eingehende Mail-Nachrichten von Communications Express und E-Mail-Clients weiter.
Messaging Server MTA (Ausgang)	1	Leitet ausgehende Mail-Nachrichten an Empf�nger weiter.
Messaging Server MMP	1	Erm�glicht den Zugriff auf den Messaging Server-Nachrichtenspeicher f�r E-Mail-Clients.
Messaging Server STR (Nachrichtenspeicher)	1	Ruft E-Mail-Nachrichten ab und speichert sie.
Access Manager	2	Stellt Autorisierungs- und Authentifizierungsdienste bereit.
Calendar Server (Back-End)	2	Ruft Kalenderdaten f�r Communications Express, ein Calendar Server-Front-End, ab und speichert sie.
Directory Server	2	Stellt LDAP-(Lightweight Directory Access Protocol-)Verzeichnisdienste zur Verf�gung.
Web Server	0	Bietet Webcontainer-Unterst�tzung f�r Portal Serverund Access Manager. (Keine zus�tzlichen CPU-Zyklen erforderlich.)

Anwendungsf�lle auf Spitzenauslastung hin pr�fen

Kehren Sie zu den Anwendungsf�llen und der Anwendungsanalyse zur�ck, um die Bereiche zu identifizieren, in denen es zur Spitzenauslastung kommt, und passen Sie Ihre CPU-Einsch�tzungen entsprechend an.

In diesem Beispiel wird angenommen, dass folgende Spitzenladebedingungen identifiziert werden:

Anf�nglicher stufenweiser Anstieg von Benutzern bei der gleichzeitigen Anmeldung

E-Mail-Austausch innerhalb vorgegebener Zeitrahmen

Um diese Spitzenauslastung zu ber�cksichtigen, nehmen Sie �nderungen an den Komponenten vor, von denen diese Dienste zur Verf�gung gestellt werden. In der nachfolgenden Tabelle werden die Anpassungen erl�utert, die vorgenommen werden k�nnen, um diese Spitzenauslastung zu ber�cksichtigen.

Tabelle 5-3 Anpassungen der CPU-Einsch�tzung hinsichtlich der Spitzenauslastung
Komponente	CPUs (angepasst)	Beschreibung
Messaging Server MTA Eingang	2	1 CPU f�r eingehende E-Mails (Spitze) hinzuf�gen
Messaging Server MTA Ausgang	2	1 CPU f�r ausgehende E-Mails (Spitze) hinzuf�gen
Messaging Server MMP	2	1 CPU f�r zus�tzliche Auslastung hinzuf�gen
Messaging Server STR (Nachrichtenspeicher)	2	1 CPU f�r zus�tzliche Auslastung hinzuf�gen
Directory Server	3	1 CPU f�r zus�tzliche LDAP-Suchvorg�nge hinzuf�gen

Einsch�tzungen f�r andere Ladebedingungen �ndern

Fahren Sie mit Ihren CPU-Einsch�tzungen fort, um weitere QoS-Anforderungen zu ber�cksichtigen, die sich auf die Auslastung auswirken k�nnen:

Sicherheit. Ermitteln Sie in der auf die technischen Anforderungen bezogenen Phase, wie sich der sichere Transport von Daten auf die Auslastungsanforderungen auswirken kann, und passen Sie Ihre Einsch�tzungen entsprechend an. Im nachfolgenden Abschnitt, Einsch�tzen von Prozessoranforderungen f�r sichere Transaktionen, wird erl�utert, wie Anpassungen vorgenommen werden k�nnen.

Replikation von Diensten. Passen Sie die CPU-Einsch�tzungen dahin gehend an, dass die Replikation von Diensten bez�glich Verf�gbarkeit, Lastenausgleich und Skalierbarkeit ber�cksichtigt werden. Im nachfolgenden Abschnitt, Ermitteln von Verf�gbarkeitsstrategien, werden Gr��enaspekte f�r Verf�gbarkeitsl�sungen erl�utert. Im Abschnitt Ausarbeiten von Strategien hinsichtlich der Skalierbarkeit werden L�sungen hinsichtlich des verf�gbaren Zugriffs auf Verzeichnisdienste erl�utert.

Latente Kapazit�t und Skalierbarkeit. �ndern Sie CPU-Einsch�tzungen dahin gehend, dass f�r unerwartet hohe Auslastungen in der Bereitstellung latente Kapazit�t genutzt werden kann. �berpr�fen Sie die erwarteten Meilensteine f�r Skalierung und geplanten Lastenanstieg im Laufe der Zeit, um zu gew�hrleisten, dass jeder geplante Meilenstein zur Skalierung des Systems (horizontal oder vertikal) erreicht werden kann.

CPU-Einsch�tzungen aktualisieren

Im Normalfall werden CPUs auf eine gerade Zahl aufgerundet. Durch das Aufrunden auf eine gerade Zahl k�nnen die CPU-Einsch�tzungen zu gleichen Teilen zwischen zwei physischen Servern aufgeteilt werden; zudem wird ein kleiner Faktor f�r latente Kapazit�t hinzugef�gt. Sie sollten beim Aufrunden jedoch auf Ihre spezifischen Anforderungen hinsichtlich der Replikation von Diensten eingehen.

Als Faustregel werden f�r jede CPU 2 GB Speicher vorgesehen. Wie viel Speicher tats�chlich ben�tigt wird, h�ngt von Ihren spezifischen Gegebenheiten ab und kann durch Tests ermittelt werden.

In der nachfolgenden Tabelle sind die endg�ltigen Einsch�tzungen f�r das identit�tsbasierte Kommunikationsbeispiel aufgef�hrt. In diesen Einsch�tzungen ist keinerlei zus�tzliche Rechnerkapazit�t ber�cksichtigt, die f�r erh�hte Sicherheit und gr��ere Verf�gbarkeit h�tte hinzugef�gt werden k�nnen. Die Gesamtkapazit�t f�r Sicherheit und Verf�gbarkeit wird in den nachfolgenden Abschnitten hinzugef�gt.

Tabelle 5-4 Anpassungen von CPU-Einsch�tzungen f�r unterst�tzende Komponenten
Komponente	CPUs	Arbeitsspeicher
Portal Server	4	8 GB
Communications Express	2	4 GB
Messaging Server (MTA, Eingang)	2	4 GB
Messaging Server (MTA, Ausgang)	2	4 GB
Messaging Server (MMP)	2	4 GB
Messaging Server (Nachrichtenspeicher)	2	4 GB
Access Manager	2	4 GB
Calendar Server	2	4 GB
Directory Server	4	8 GB (aufgerundet von 3 CPUs/6 GB Speicher)
Web Server	0	0

Einsch�tzen von Prozessoranforderungen f�r sichere Transaktionen

Der sichere Transport von Daten beinhaltet die Verarbeitung von Transaktionen �ber ein sicheres Transportprotokoll wie Secure Sockets Layer (SSL) oder Transport Layer Security (TLS). F�r Transaktionen, die im Rahmen eines sicheren Transports durchgef�hrt werden, ist normalerweise zus�tzliche Rechnerkapazit�t erforderlich, um zun�chst eine sichere Sitzung (die als Handshake bezeichnet wird) einzurichten und dann die �bermittelten Daten zu ver- und entschl�sseln. Abh�ngig vom verwendeten Verschl�sselungsalgorithmus (z. B. des 40-Bit- oder des 128-Bit-Verschl�sselungsalgorithmus) ist m�glicherweise sehr viel zus�tzliche Rechnerkapazit�t erforderlich.

Damit sichere Transaktionen auf derselben Ebene wie nicht sichere Transaktionen ausgef�hrt werden k�nnen, muss zus�tzliche Rechnerkapazit�t eingeplant werden. Je nachdem, welche Art von Transaktion ausgef�hrt wird und welche Sun Java™ Enterprise System-Dienste hierf�r genutzt werden, ist f�r sichere Transaktionen u. U. das Vierfache an Rechnerkapazit�t erforderlich wie bei nicht sicheren Transaktionen.

Um einzusch�tzen, wie viel Verarbeitungsleistung f�r die Handhabung sicherer Transaktionen erforderlich ist, analysieren Sie Anwendungsf�lle, um den Prozentsatz an Transaktionen zu ermitteln, f�r die der sichere Transport erforderlich ist. Wenn die Leistungsanforderungen f�r sichere Transaktionen mit denen f�r nicht sichere Transaktionen �bereinstimmen, passen Sie die CPU-Einsch�tzungen dahin gehend an, dass die f�r sichere Transaktionen erforderliche Rechnerkapazit�t ber�cksichtigt wird.

In einigen Anwendungsszenarios ist der sichere Transport m�glicherweise nur zu Authentifizierungszwecken erforderlich. Sobald ein Benutzer f�r das System authentifiziert wurde, sind keine zus�tzlichen Sicherheitsma�nahmen f�r den Datentransport vonn�ten. In anderen Szenarios ist der sichere Transport m�glicherweise f�r s�mtliche Transaktionen Bedingung.

Wenn Sie beispielsweise den Produktkatalog einer E-Commerce-Site im Internet anzeigen, k�nnen s�mtliche Transaktionen nicht sichere Transaktionen sein, bis der Kunde seine Wahl getroffen hat und einen Kauf t�tigen m�chte. In einigen Anwendungszenarios, beispielsweise bei Bereitstellungen f�r Banken oder Brokerfirmen, m�ssen nahezu alle oder alle Transaktionen sicher sein; zudem muss f�r sichere und nicht sichere Transaktionen derselbe Leistungsstandard angewendet werden.

CPU-Einsch�tzungen f�r sichere Transaktionen

In diesem Abschnitt wird die Beispielbereitstellung weiterf�hrend erl�utert, um aufzuzeigen, wie CPU-Anforderungen f�r einen theoretischen Anwendungsfall berechnet werden k�nnen.

F�hren Sie zur Einsch�tzung der CPU-Anforderungen f�r sichere Transaktionen folgende Berechnungen durch:

Beginnen Sie mit einer Basiszahl f�r die CPU-Einsch�tzungen (wie im vorherigen Abschnitt, Beispiel f�r das Einsch�tzen von Prozessoranforderungen, erl�utert).

Berechnen Sie den Prozentsatz der Transaktionen, f�r die der sichere Transport erforderlich ist, und berechnen Sie dann die CPU-Einsch�tzungen f�r die sicheren Transaktionen.

Berechnen Sie die verringerten CPU-Einsch�tzungen f�r nicht sichere Transaktionen.

Z�hlen Sie die sicheren und die nicht sicheren Einsch�tzungen zusammen, um die CPU-Gesamteinsch�tzungen zu ermitteln.

Runden Sie die CPU-Gesamteinsch�tzung auf eine gerade Zahl auf.

In Tabelle 5-5 finden Sie eine Beispielberechnung, die auf Anwendungsf�llen und Anwendungsanalysen f�r Portal Server basiert, bei denen von Folgendem ausgegangen wird:

F�r s�mtliche Anmeldungen ist die sichere Authentifizierung erforderlich.

S�mtliche Anmeldungen machen 10 % der Portal Server-Gesamtauslastung aus.

Die Leistunganforderung f�r sichere Transaktionen ist mit der Leistungsanforderung f�r nicht sichere Transaktionen identisch.

Um die zus�tzliche Rechnerkapazit�t f�r die Handhabung sicherer Transaktionen zu ber�cksichtigen, wird die Anzahl der CPUs f�r die Verarbeitung dieser Transaktionen um den Faktor 4 erh�ht. Wie bei anderen CPU-Werten im Beispiel ist dieser Faktor willk�rlich gew�hlt und dient lediglich der Veranschaulichung.

Tabelle 5-5 �ndern von CPU-Einsch�tzungen f�r sichere Transaktionen
Schritt	Beschreibung	Berechnung	Ergebnis
1	Starten Sie mit einer Basiseinsch�tzung f�r s�mtliche Portal Server-Transaktionen.	Die Basiseinsch�tzung aus Tabelle 5-3 betr�gt 4 CPUs.	- - - - -
2	Berechnen Sie die zus�tzlichen CPU-Einsch�tzungen f�r sichere Transaktionen. Gehen Sie hierbei davon aus, dass f�r sichere Transaktionen im Vergleich zu nicht sicheren Transaktionen das 5fache an Prozessorkapazit�t erforderlich ist.	F�r 10 Prozent der Basiseinsch�tzung ist der sichere Transport erforderlich: 0,10 x 4 CPUs = 0,4 CPUs Erh�hen Sie die CPU-Kapazit�t f�r sichere Transaktionen um den Faktor 4: 4 x 0,4 = 1,6 CPUs	1,6 CPUs
3	Berechnen Sie die verringerten CPU-Einsch�tzungen f�r nicht sichere Transaktionen.	90 Prozent der Basiseinsch�tzung sind nicht sicher: 0,9 x 4 CPUs = 3,6 CPUs	3,6 CPUs
4	Berechnen Sie die angepassten CPU-Gesamteinsch�tzungen f�r sichere und nicht sichere Transaktionen.	Sichere Einsch�tzung + nicht sichere Einsch�tzung = Gesamtwert: 1,6 CPUs + 3,6 CPUs = 5,2 CPUs	5,2 CPUs
5	Runden Sie auf eine gerade Zahl auf.	5,2 CPUs ==> 6 CPUs	6 CPUs

Von den Berechnungen f�r sichere Transaktionen in diesem Beispiel w�rden Sie die CPU-Gesamteinsch�tzungen in Tabelle 5-5 dahin gehend �ndern, dass zwei zus�tzliche CPUs und 4 GB Speicher hinzugef�gt und so der Gesamtwert f�r Portal Server ermittelt wird.

Spezielle Hardware zur Handhabung von SSL-Transaktionen

Spezielle Hardwareger�te, beispielweise SSL-Beschleunigungskarten und weitere Vorrichtungen, k�nnen Rechnerkapazit�t f�r die Handhabung der Einrichtung sicherer Sitzungen und der Ver- und Entschl�sselung von Daten bereitstellen. Wenn Sie f�r SSL-Vorg�nge spezielle Hardware einsetzen, wird ein Teil der Rechnerkapazit�t f�r SSL-Berechnungen genutzt, normalerweise f�r den so genannten Handshake-Vorgang, mit dem eine sichere Sitzung eingerichtet wird.

Diese Hardware erweist sich in Ihrer endg�ltigen Bereitstellungsarchitektur m�glicherweise als vorteilhaft. Aufgrund der Spezialisierung der Hardware sollten Sie die Leistungsanforderungen f�r sichere Transaktionen zun�chst im Hinblick auf die CPU-Kapazit�t einsch�tzen und erst dann die Vorteile der Verwendung spezieller Hardware zur Handhabung der zus�tzlichen Last in Betracht ziehen.

Zu den Faktoren, die bei der Erw�gung der Verwendung spezieller Hardware in Betracht gezogen werden m�ssen, z�hlt, ob die Anwendungsf�lle die Hardware unterst�tzen (z. B. Anwendungsf�lle, f�r die zahlreiche SSL-Handshake-Vorg�nge erforderlich sind) sowie die erh�hte Komplexit�t, die diese Art von Hardware mit sich bringt. Diese Komplexit�t ergibt sich aus dem Installieren, Konfigurieren, Testen und Verwalten dieser Ger�te.

Tabelle 5-6 Anpassungen der CPU-Einsch�tzung f�r sichere Portal Server-Transaktionen
Komponente	CPUs	Arbeitsspeicher
Portal Server	6	12 GB

Ermitteln von Verf�gbarkeitsstrategien

Ziehen Sie bei der Ausarbeitung einer Strategie f�r Verf�gbarkeitsanforderungen die Interaktion zwischen Komponenten sowie die Anwendungsanalyse in Betracht, um zu ermitteln, welche Verf�gbarkeitsl�sungen infrage kommen. Gehen Sie bei der Analyse jede Komponente einzeln durch und ermitteln Sie so die in Bezug auf Verf�gbarkeit und Failover am besten geeignete L�sung.

Nachfolgend sind Beispiele der Angaben aufgef�hrt, die bei der Ermittlung von Verf�gbarkeitsstrategien hilfreich sind:

Wie viele Verf�gbarkeits-Neunen sind angegeben?

Wie sehen die Leistungsspezifikationen in Bezug auf Failover-Situationen aus (z. B. mindestens 50 % Leistung bei Failover)?

Gehen aus der Anwendungsanalyse Zeiten mit Spitzenauslastung und andere Zeiten hervor?

Welche geografischen �berlegungen gibt es?

In der von Ihnen ausgew�hlten Verf�gbarkeitsstrategie m�ssen auch die Anforderungen hinsichtlich der Wartungseignung ber�cksichtigt werden (ziehen Sie hierzu die Erl�uterung unter Ausarbeiten von Strategien hinsichtlich der Skalierbarkeit zurate). Komplexe L�sungen mit gro�em Verwaltungs- und Wartungsaufwand sollten vermieden werden.

Verf�gbarkeitsstrategien

Die Verf�gbarkeitsstrategien f�r Java Enterprise System-Bereitstellungen beinhalten u. a. folgende Punkte:

Lastenausgleich. Nutzt redundante Hard- und Softwarekomponenten zur verteilten Lastenverarbeitung. Von einem Lastenausgleichssystem werden s�mtliche Anforderungen eines Diensts an eine von mehreren symmetrischen Instanzen des Dienstes weitergeleitet. Wenn eine der Instanzen ausf�llt, sind andere Instanzen verf�gbar, die eine gr��ere Last �bernehmen.

Failover. Umfasst die Verwaltung redundanter Hard- und Software zur Gew�hrleistung des ununterbrochenen Zugriffs von Diensten und der Sicherheit kritischer Daten beim Ausfall einer Komponente.

Replikation von Diensten. Durch die Replikation von Diensten werden mehrere Zugriffsm�glichkeiten auf dieselben Daten bereitgestellt. Directory Server enth�lt zahlreiche Replikations- und Synchronisierungsstrategien f�r den LDAP-Verzeichniszugriff.

Die nachfolgenden Abschnitte enthalten Beispiele f�r Verf�gbarkeitsl�sungen, die unterschiedliche Ebenen hinsichtlich Lastenausgleich, Failover und Replikation von Diensten bereitstellen.

System mit nur einem Server

Platzieren Sie alle Rechnerressourcen f�r einen Dienst auf einem einzelnen Server. Wenn der Server ausf�llt, schl�gt der gesamte Dienst fehl.

Austausch und Neukonfiguration von Hardwarekomponenten im laufenden Betrieb

Ausf�hrung mehrerer Anwendungen in fehlerisolierten Dom�nen auf dem Server

Aufr�stung hinsichtlich Kapazit�t und Leistungsgeschwindigkeit sowie E/A-Konfiguration ohne Neustart des Systems

Ein High-End-Server ist in der Regel teurer als ein vergleichbares System mit mehreren Servern. Ein einzelner Server hilft Kosten hinsichtlich Verwaltung, �berwachung und Hosting f�r Server in einem Datenzentrum zu sparen. Lastenausgleich, Failover und Entfernung von Einzelpunkt-Versagen gestalten sich in einem System mit mehreren Servern flexibler.

Horizontal redundante Systeme

Es gibt mehrere M�glichkeiten, die Verf�gbarkeit mit parallel redundanten Servern zu erh�hen, die sowohl Lastenausgleich als auch Failover bieten. In der nachfolgenden Abbildung sind zwei Replikationsserver dargestellt, die ein n+1-Failover-System zur Verf�gung stellen. In einem n+1-System ist ein zus�tzlicher Server vorhanden, der bei Ausfall eines Servers 100%-ige Kapazit�t bereitstellt.

Die Rechnerkapazit�t der in Abbildung 5-3 oben dargestellten Server ist identisch. Die Leistungsanforderungen werden von einem Server allein gehandhabt. Der andere Server stellt 100 % Leistung bereit, wenn er als Reserve in Anspruch genommen wird.

Der Vorteil eines n+1-Failover-Konzepts besteht darin, dass w�hrend eines Failovers 100 % Leistung bereitgestellt werden k�nnen. Zu den Nachteilen z�hlen die h�heren Hardwarekosten, denen keine entsprechende Steigerung der Gesamtleistung gegen�bersteht (da ein Server ausschlie�lich f�r den Einsatz in Failover-Situationen vorgesehen ist).

In der nachfolgenden Abbildung ist ein System dargestellt, in dem Lastenausgleich plus Failover implementiert werden und so die Leistung zwischen zwei Servern aufgeteilt wird.

In dem System, das in Abbildung 5-4 oben dargestellt ist, stehen beim Ausfalls eines Servers s�mtliche Dienste zur Verf�gung, jedoch nur zu einem bestimmten Prozentsatz der vollen Kapazit�t. Der verbleibende Server stellt die Rechnerkapazit�t von 6 CPUs bereit, es werden also 60 % der 10-CPU-Anforderung erf�llt.

Ein Vorteil dieses Konzepts besteht in der zus�tzlichen latenten Kapazit�t von 2 CPUs, wenn beide Server verf�gbar sind.

Aus der folgenden Abbildung geht die Verteilung zwischen mehreren Servern in Bezug auf Leistung und Lastenausgleich hervor.

Da das in Abbildung 5-5 dargestellte Konzept f�nf Server umfasst, stellen beim Ausfall eines Servers die verbleibenden Server die Rechnerkapazit�t von insgesamt 8 CPUs bereit; dies entspricht 80 % der 10-CPU-Leistungsanforderung. Wenn Sie dem Konzept einen zus�tzlichen Server mit einer Kapazit�t von 2 CPUs hinzuf�gen, verf�gen Sie �ber ein n+1-Konzept. Wenn ein Server ausf�llt, wird die Leistungsanforderung von den verbleibenden Servern zu 100 % erf�llt.

Mehr Leistung bei Ausfall eines einzelnen Servers

Gew�hrleistete Verf�gbarkeit sogar beim Ausfall mehrerer Server

Server k�nnen zu Wartungs- und Aktualisierungszwecken abwechselnd aus dem aktiven Betrieb genommen werden

Mehrere Low-End-Server sind in der Regel kosteng�nstiger als ein einzelner High-End-Server

Durch zus�tzliche Server k�nnen die Verwaltungs- und Wartungskosten jedoch deutlich ansteigen. Zudem m�ssen die Kosten f�r das Hosting der Server in einem Datenzentrum ber�cksichtigt werden. Ab einem bestimmten Punkt f�hrt das Hinzuf�gen weiterer Server zu einer verringerten Rendite.

Sun Cluster-Software

In Situationen, in denen ein hohes Ma� an Verf�gbarkeit erforderlich ist (z. B. bei vier oder f�nf Neunen), sollten Sie Sun Cluster-Software als Bestandteil Ihres Verf�gbarkeitskonzepts in Erw�gung ziehen. Bei einem Cluster-System handelt es sich um die Kombination redundanter Server mit Speicher und anderen Netzwerkressourcen. Die Server in einem Cluster kommunizieren st�ndig miteinander. Wenn einer der Server in den Offline-Modus versetzt wird, wird er von den verbleibenden Ger�ten im Cluster isoliert und der Failover-Vorgang f�r jegliche Anwendungen oder Daten vom deaktivierten Knoten in einen anderen Knoten durchgef�hrt. Der Failover-Vorgang l�uft relativ schnell und mit nur geringer Beeintr�chtigung der Dienstbereitstellung f�r die Benutzer des Systems ab.

F�r Sun Cluster-Software sind zus�tzliche dedizierte Hardware und besondere Kenntnisse hinsichtlich Konfiguration, Verwaltung und Wartung vonn�ten.

Beispiele f�r Verf�gbarkeitskonzepte

Dieser Abschnitt enth�lt zwei Beispiele f�r Verf�gbarkeitsstrategien, die auf der identit�tsbasierten Kommunikationsl�sung eines mittelst�ndischen Unternehmens (1000 bis 5000 Mitarbeiter) basieren, die zuvor unter Identit�tsbasiertes Kommunikationsbeispiel erl�utert wurden. In der ersten Verf�gbarkeitsstrategie ist der Lastenausgleich f�r Messaging Server dargestellt. In der zweiten Strategie wird eine Failover-L�sung erl�utert, bei der Sun Cluster-Software zum Einsatz kommt.

Beispiel des Lastenausgleichs f�r Messaging Server

In der nachfolgenden Tabelle werden die Einsch�tzungen hinsichtlich CPU-Kapazit�t f�r die einzelnen logischen Messaging Server-Komponenten in der logischen Architektur aufgef�hrt. In dieser Tabelle wird die endg�ltige Einsch�tzung erneut verwendet, die im Abschnitt CPU-Einsch�tzungen aktualisieren ermittelt wurde.

Tabelle 5-7 Anpassungen von CPU-Einsch�tzungen f�r unterst�tzende Komponenten
Komponente	CPUs	Arbeitsspeicher
Messaging Server (MTA, Eingang)	2	4 GB
Messaging Server (MTA, Ausgang)	2	4 GB
Messaging Server (MMP)	2	4 GB
Messaging Server (Nachrichtenspeicher)	2	4 GB

Gehen Sie bei diesem Beispiel davon aus, dass in der auf die technischen Anforderungen bezogenen Phase folgende Dienstqualit�tsanforderungen festgelegt wurden:

Verf�gbarkeit. Die Gesamtverf�gbarkeit des Systems sollte 99,99 % betragen (geplante Ausfallzeiten sind hier nicht ber�cksichtigt). Der Ausfall eines einzelnen Computersystems sollte nicht zum Ausfall der Dienstbereitstellung f�hren.

Skalierbarkeit. Kein Server sollte eine Auslastung von mehr als 80 % der t�glichen Spitzenauslastung erreichen und im System muss das langfristige Wachstum von 10 % pro Jahr ber�cksichtigt werden.

Zur Erf�llung der Verf�gbarkeitsanforderung m�ssen f�r jede Messaging Server-Komponente zwei Instanzen bereitgestellt werden (jeweils eine auf separaten Servern). Wenn ein Server einer Komponente ausf�llt, wird der Dienst vom anderen Server bereitgestellt. In der folgenden Abbildung wird das Netzwerkdiagramm f�r diese Verf�gbarkeitsstrategie dargestellt.

In der obigen Darstellung hat sich die Anzahl der CPUs im Vergleich zur urspr�nglichen Einsch�tzung verdoppelt. F�r die Verdopplung der CPUs gibt es folgende Gr�nde:

Wenn ein Server ausf�llt, stellt der verbleibende Server die CPU-Kapazit�t zur Handhabung der Last bereit.

Hinsichtlich der Skalierbarkeitsanforderung, gem�� der kein einzelner Server zu mehr als 80 % der Spitzenauslastung beansprucht werden soll, wird dieser Sicherheitsspielraum durch die zus�tzliche CPU-Kapazit�t bereitgestellt.

Hinsichtlich der Skalierbarkeitsanforderung, gem�� der ein Lastanstieg von 10 % pro Jahr ber�cksichtigt werden soll, wird durch die zus�tzliche CPU-Kapazit�t latente Kapazit�t verf�gbar gemacht, die die wachsende Last abdeckt, bis zus�tzliche Skalierung erforderlich wird.

Failover-Beispiel mit Sun Cluster-Software

In der nachfolgenden Abbildung ist ein Beispiel einer Failover-Strategie f�r das Calendar Server-Back-End und den Messaging Server-Datenspeicher dargestellt. Das Calendar Server-Back-End und der Datenspeicher werden auf separaten Servern repliziert und unter Verwendung von Sun Cluster-Software f�r das Failover konfiguriert. Die Anzahl an CPUs und der entsprechende Arbeitsspeicher werden in Sun Cluster auf jedem Server repliziert.

Beispiel f�r Replikation von Verzeichnisdiensten

Verzeichnisdienste k�nnen repliziert werden, um Transaktionen auf unterschiedliche Server aufzuteilen und auf diese Weise die Hochverf�gbarkeit zu gew�hrleisten. Directory Server bietet u. a. folgende Strategien f�r die Replikation von Diensten:

Mehrere Datenbanken. Speichert unterschiedliche Bestandteile eines Verzeichnisbaums in separaten Datenbanken.

Vorw�rtsverkettung und Referrals. Nimmt die Verkn�pfung verteilter Daten in einen einzelnen Verzeichnisbaum vor.

Einzelmaster-Replikation. Stellt eine zentrale Quelle f�r die Master-Datenbank bereit, die im Anschluss auf Verbraucher-Replikate aufgeteilt wird.

Multimaster-Replikation. Verteilt die Master-Datenbank auf mehrere Server. Von jedem dieser Master wird die zugeh�rige Datenbank auf Verbraucher-Replikate verteilt.

Verf�gbarkeitsstrategien f�r Directory Server sind ein komplexes Thema, das den Rahmen dieses Handbuchs sprengen w�rde. In den nachfolgenden Abschnitten, Einzelmaster-Replikation und Multimaster-Replikation, werden die grundlegenden Replikationsstrategien detailliert erl�utert. Ausf�hrliche Informationen zu den Verf�gbarkeitsstrategien f�r Directory Server finden Sie im Directory Server-Handbuch zur Bereitstellungsplanung, http://docs.sun.com/doc/817-7607).

Einzelmaster-Replikation

In der nachfolgenden Abbildung ist eine Einzelmaster-Replikationsstrategie dargestellt, anhand der grundlegende Replikationskonzepte veranschaulicht werden.

In einer Einzelmaster-Replikation verwaltet eine Instanz von Directory Server die Master-Verzeichnisdatenbank und protokolliert s�mtliche �nderungen. Die Master-Datenbank wird auf einer beliebigen Anzahl an Verbraucher-Datenbanken repliziert. Die Verbraucher-Instanzen von Directory Server werden f�r Lese- und Suchvorg�nge optimiert. S�mtliche Schreibvorg�nge, die von einem Verbraucher empfangen werden, werden an den Master zur�ckverwiesen. Die Verbraucher- Datenbanken werden in regelm��igen Abst�nden vom Master aktualisiert.

Einzelne f�r datenbankbezogene Lese- und Schreibvorg�nge optimierte Directory Server-Instanz

Eine beliebige Anzahl von f�r Lese- und Suchvorg�nge optimierten Verbraucher-Instanzen von Directory Server

Horizontale Skalierbarkeit f�r Verbraucher-Instanzen von Directory Server

Multimaster-Replikation

In der nachfolgenden Abbildung ist eine Multimaster-Replikationsstrategie dargestellt, die m�glicherweise zur globalen Verteilung des Verzeichniszugriffs verwendet wird.

In einer Multimaster-Replikation wird die Master-Verzeichnisdatenbank von einer oder mehreren Instanzen von Directory Server verwaltet. Jeder Master weist eine Replikationsvereinbarung auf, aus der Vorgehensweisen f�r die Synchronisierung der Master-Datenbanken ersichtlich sind. Jeder Master wird auf eine beliebige Anzahl an Verbraucher-Datenbanken repliziert. Wie bei der Einzelmaster-Replikation werden die Verbraucher-Instanzen von Directory Server f�r den Lese- und Suchzugriff optimiert. S�mtliche Schreibvorg�nge, die von einem Verbraucher empfangen werden, werden an den Master zur�ckverwiesen. Die Verbraucher-Datenbanken werden in regelm��igen Abst�nden vom Master aktualisiert.

Die Multimaster-Replikationsstrategie bietet alle Vorteile einer Einzelmaster-Replikation und zus�tzlich eine Verf�gbarkeitsstrategie, von der der Lastenausgleich f�r Aktualisierungen des Masters bereitgestellt werden k�nnen. Sie k�nnen auch eine Verf�gbarkeitsstrategie implementieren, die die lokale Steuerung von Verzeichnisvorg�ngen erm�glicht, ein wichtiger Aspekt f�r Unternehmen mit global verteilten Datenzentren.

Ausarbeiten von Strategien hinsichtlich der Skalierbarkeit

Skalierbarkeit ist die F�higkeit, Ihrem System mehr Kapazit�t zur Verf�gung zu stellen; normalerweise durch das Hinzuf�gen von Systemressourcen ohne �nderung der Bereitstellungsarchitektur. Bei der Anforderungsanalyse werden normalerweise Prognosen hinsichtlich des erwarteten Zuwachses eines Systems abgegeben; als Grundlage dienen hier die Gesch�ftsanforderungen und die nachfolgende Anwendungsanalyse. Diese Prognosen der Anzahl der Benutzer eines Systems und der Kapazit�t des Systems zur Erf�llung der jeweiligen Anforderungen sind h�ufig Einsch�tzungen, die stark von den tats�chlichen Werten f�r das bereitgestellte System abweichen. Ihr Konzept sollte so flexibel sein, dass Abweichungen in Ihren Prognosen kein Problem darstellen.

Ein skalierbares Konzept stellt ausreichend latente Kapazit�t zur Handhabung einer gr��eren Last bereit, bis ein System mit weiteren Ressourcen aktualisiert werden kann. Skalierbare Konzepte k�nnen ohne weiteres so skaliert werden, dass die Handhabung einer gr��eren Last ohne Neukonzeption des Systems erm�glicht wird.

Latente Kapazit�t

Die latente Kapazit�t ist ein Aspekt der Skalierbarkeit, bei dem zus�tzliche Leistung und Verf�gbarkeitsressourcen f�r das System bereitgestellt werden k�nnen, das daraufhin in der Lage ist, ungew�hnliche Spitzenauslastung zu handhaben. Sie k�nnen auch �berwachen, wie latente Kapazit�t in einem bereitgestellten System verwendet wird, um zu ermitteln, wie das System durch das Hinzuf�gen von Ressourcen skaliert werden kann. Die latente Kapazit�t stellt eine der M�glichkeiten dar, mit der Sicherheitsaspekte in Ihr Konzept integriert werden k�nnen.

Die Analyse von Anwendungsf�llen kann bei der Ermittlung von Szenarios hilfreich sein, in denen es zu ungew�hnlicher Spitzenauslastung kommen kann. Nutzen Sie diese Analyse ungew�hnlicher Spitzenauslastung und einen Faktor zur Abdeckung unerwarteten Zuwachses, um latente Kapazit�t verf�gbar zu machen, durch die die Sicherheit Ihres Systems erh�ht wird.

Ihr System sollte in der Lage sein, die geplante Kapazit�t f�r einen angemessenen Zeitraum zu handhaben, normalerweise f�r die ersten 6 bis 12 Monate des Betriebs. Wartungszyklen k�nnen verwendet werden, um Ressourcen hinzuzuf�gen oder die Kapazit�t nach Bedarf zu erh�hen. Im Idealfall sollten Sie in der Lage sein, Aktualisierungen des Systems in regelm��igen Abst�nden zu planen, die Vorhersage der erforderlichen Kapazit�tserh�hungen erweist sich jedoch in vielen F�llen als schwierig. Verlassen Sie sich bei der Ermittlung des richtigen Zeitpunkts f�r die Aktualisierung eines Systems auf die genaue �berwachung Ihrer Ressourcen sowie auf Gesch�ftsprognosen.

Wenn Sie die phasenweise Implementierung Ihrer L�sung beabsichtigen, k�nnen Sie die Erh�hung der Kapazit�t so planen, dass sie mit anderen Verbesserungen f�r jede Phase zusammenf�llt.

Skalierbarkeitsbeispiel

Anhand des Beispiels in diesem Abschnitt wird die horizontale und vertikale Skalierung einer L�sung veranschaulicht, mit der Messaging Server implementiert wird. F�r die horizontale Skalierung f�gen Sie einem Server f�r die Handhabung steigender Last zus�tzliche CPUs hinzu. F�r die vertikale Skalierung wird die steigende Last durch das Hinzuf�gen weiterer Server gehandhabt, auf die die Last aufgeteilt wird.

Bei diesem Beispiel wird von einem Benutzerstamm mit 50000 Benutzern ausgegangen, der durch zwei Nachrichtenspeicherinstanzen unterst�tzt wird, die f�r den Lastenausgleich aufgeteilt werden. Jeder Server verf�gt �ber zwei CPUs, insgesamt stehen also vier CPUs zur Verf�gung. Aus der nachfolgenden Abbildung geht hervor, wie dieses System zur Handhabung der ansteigenden Last f�r 250000 Benutzer und 2000000 Benutzer skaliert werden kann.


Hinweis	In Abbildung 5-10 wird der Unterschied zwischen vertikaler und horizontaler Skalierung erl�utert. In dieser Abbildung sind keine zus�tzlichen Faktoren zu sehen, die bei der Skalierung ber�cksichtigt werden m�ssen, beispielsweise Lastenausgleich, Failover sowie �nderungen in Anwendungsmustern.

Identifizieren von Leistungsengp�ssen

Einer der Schl�ssel f�r ein erfolgreiches Bereitstellungskonzept ist das Identifizieren potenzieller Leistungsengp�sse und das Ausarbeiten einer Strategie zu deren Vermeidung. Zu einem Leistungsengpass kommt es, wenn die Datenzugriffsrate vorgegebene Systemanforderungen nicht erf�llen kann.

Engp�sse k�nnen anhand unterschiedlicher Hardwareklassen in Kategorien eingeteilt werden (wie in der nachfolgenden Tabelle mit Datenzugriffspunkten innerhalb eines Systems angegeben). In dieser Tabelle werden zudem m�gliche L�sungsvorschl�ge f�r Engp�sse in den einzelnen Hardwareklassen unterbreitet.

Tabelle 5-8 Datenzugriffspunkte
Hardwareklasse	Relative Zugriffsgeschwindigkeit	L�sungsvorschl�ge zur Leistungssteigerung
Prozessor	Nanosekunden	Vertikale Skalierung: Mehr Verarbeitungsleistung bereitstellen, Prozessorcache vergr��ern Horizontale Skalierung: Parallele Verarbeitungsleistung f�r den Lastenausgleich bereitstellen
Systemspeicher (RAM)	Mikrosekunden	Systemspeicher bestimmten Aufgaben zuordnen Vertikale Skalierung: Zus�tzlichen Speicher bereitstellen Horizontale Skalierung: Zus�tzliche Instanzen f�r Parallelverarbeitung und Lastenausgleich erstellen
Lese- und Schreibvorg�nge auf Festplatte	Millisekunden	Festplattenzugriff mithilfe von Festplattenarrays (Redundant Array of Independent Disks, RAID) optimieren Festplattenzugriff bestimmten Funktionen zuordnen, beispielsweise dem reinen Lese- oder Schreibzugriff Daten, auf die h�ufig zugegriffen wird, im Systemspeicher zwischenspeichern
Netzwerkschnittstelle	Variiert in Abh�ngigkeit von Bandbreite und Zugriffsgeschwindigkeit von Knoten im Netzwerk	Bandbreite erh�hen Beschleunigungshardware f�r den Transport sicherer Daten bereitstellen Leistung der Knoten im Netzwerk erh�hen, um h�here Datenverf�gbarkeit zu gew�hrleisten

Am Anfang eines Bereitstellungskonzepts stehen in der Regel Basiseinsch�tzungen der Verarbeitungsleistung s�mtlicher Komponenten in der Bereitstellung sowie deren Abh�ngigkeiten. Im Anschluss wird ermittelt, wie Engp�sse in Bezug auf Systemspeicher und Festplattenzugriff vermieden werden k�nnen. An letzter Stelle steht die Pr�fung der Netzwerkschnittstelle auf potenzielle Engp�sse sowie die Ausarbeitung von Strategien, mit denen diese Engp�sse beseitigt werden k�nnen.

Optimieren des Festplattenzugriffs

Eine wichtige Komponente des Bereitstellungskonzepts ist die Geschwindigkeit des Festplattenzugriffs auf h�ufig genutzte Datengruppen, beispielsweise LDAP-Verzeichnisse. Der Festplattenzugriff ist die langsamste Art des Zugriffs auf Daten und h�ufig die Ursache f�r leistungsbezogene Engp�sse.

Eine M�glichkeit zur Optimierung des Festplattenzugriffs besteht darin, Lese- und Schreibvorg�nge voneinander zu trennen. Schreibvorg�nge sind nicht nur kostspieliger als Lesevorg�nge, Lesevorg�nge (Suchvorg�nge f�r LDAP-Verzeichnisse) treten normalerweise deutlich h�ufiger auf als Schreibvorg�nge (Aktualisierungen von Daten in LDAP-Verzeichnissen).

Eine weitere M�glichkeit zur Optimierung des Festplattenzugriffs besteht darin, Datentr�ger (z. B. Festplatten) f�r unterschiedliche E/A-Vorg�nge vorzusehen. Sie k�nnen beispielsweise den separaten Festplattenzugriff f�r Protokollierungsvorg�nge (z. B. die Transaktions- und Ereignissprotokolle) von Directory Server und f�r LDAP-Schreib- und Lesevorg�nge erm�glichen.

Au�erdem sollten Sie die Implementierung einer oder mehrerer Instanzen von Directory Server, die f�r Lese- und Schreibvorg�nge vorgesehen sind, sowie die Verteilung replizierter Instanzen auf lokale Server f�r den Lese- und Suchzugriff in Erw�gung ziehen. Zudem stehen Optionen f�r Vorw�rtsverkettung und Verkn�pfung zur Verf�gung, mit denen sich der Zugriff auf Verzeichnisdienste optimieren l�sst.


Hinweis	In Tabelle 5-8 sind Hardwareklassen nach relativer Zugriffsgeschwindigkeit aufgef�hrt, hieraus l�sst sich schlie�en, dass langsame Zugriffspunkte, beispielsweise Festplatten, mit gr��erer Wahrscheinlichkeit zu Engp�ssen f�hren. Prozessoren, die nicht gen�gend Leistung zur Handhabung einer gro�en Last aufweisen, k�nnen jedoch auch h�ufig die Ursache von Engp�ssen sein.

Im Kapitel zum Gr��enaspekt des Systems im Directory Server Deployment Planning Guide, http://docs.sun.com/doc/817-7607, werden unterschiedliche Faktoren erl�utert, die bei der Planung des Datentr�ger-(Festplatten-)Zugriffs ber�cksichtigt werden m�ssen. Folgende Themen werden in diesem Kapitel behandelt:

Minimum memory and disk space requirements. Hier finden Sie Einsch�tzungen dazu, wie viel Festplatten- und Speicherplatz f�r Verzeichnisse unterschiedlicher Gr��e ben�tigt wird.

Sizing physical memory for cache access. Hier finden Sie Anleitungen zur Einsch�tzung der Cachegr��e gem�� der geplanten Nutzung von Directory Server sowie zur Planung der Gesamtspeichernutzung.

Sizing disk subsystems. Hier erfahren Sie, wie die Planung der Festplattengr��e gem�� den Verzeichnissuffixen vorgenommen wird und welche Directory Server-Faktoren sich auf die Datentr�gernutzung auswirken. Au�erdem wird erl�utert, wie Dateien datentr�ger�bergreifend verteilt werden und welche Alternativen es im Hinblick auf Festplattenarrays gibt.

Konzeption f�r optimale Ressourcennutzung

In einem Bereitstellungskonzept m�ssen nicht nur die Ressourcen eingesch�tzt werden, die f�r die Erf�llung von QoS-Anforderungen erforderlich sind. In der Konzeptionsphase m�ssen vielmehr alle verf�gbaren Optionen analysiert und die beste L�sung ausgew�hlt werden, bei der bei geringstm�glichen Kosten die Erf�llung der QoS-Anforderungen gew�hrleistet werden kann. Sie m�ssen den Tradeoff s�mtlicher Konzeptentscheidungen analysieren, um sicherzustellen, dass der in einem Bereich erzielte Vorteil nicht von unverh�ltnism��igen Kosten in einem anderen aufgehoben wird.

So wird beispielsweise durch die horizontale Skalierung aus Verf�gbarkeitsgr�nden m�glicherweise die Gesamtverf�gbarkeit erh�ht, es ist jedoch auch ein h�herer Kostenaufwand im Hinblick auf Wartung und Service vonn�ten. Durch die vertikale Skalierung aus Leistungsgr�nden wird m�glicherweise die Rechnerkapazit�t auf kosteng�nstige Weise erh�ht, es kann jedoch sein, dass die zus�tzliche Kapazit�t von einigen Diensten nicht effizient genutzt wird.

�berpr�fen Sie vor Fertigstellung Ihrer Konzeptstrategie Ihre Entscheidungen nochmals, um sicherzustellen, dass ein Gleichgewicht zwischen der Nutzung von Ressourcen und dem Gesamtvorteil f�r die vorgeschlagene L�sung erzielt wurde. Bei dieser Analyse wird �blicherweise gepr�ft, wie sich Systemqualit�ten in einem Bereich auf andere Systemqualit�ten auswirken. In der nachfolgenden Tabelle sind einige Systemqualit�ten und die zugeh�rigen �berlegungen im Hinblick auf die Ressourcenverwaltung aufgef�hrt.

Tabelle 5-9 �berlegungen in Bezug auf die Ressourcenverwaltung
Systemqualit�t	Beschreibung
Leistung	K�nnen die Dienste bei Leistungsl�sungen, bei denen die einzelnen Server eine hohe Zahl an CPUs aufweisen, mit Schwerpunkt die Rechnerkapazit�t effizient nutzen? (Bei einigen Diensten gibt es beispielsweise eine Obergrenze hinsichtlich der Anzahl an CPUs, die effizient genutzt werden k�nnen.)
Latente Kapazit�t	Kann mit Ihrer Strategie eine Last gehandhabt werden, die die Leistungseinsch�tzungen �bersteigt? Wird die �berm��ige Last durch die vertikale Skalierung auf Server, den Lastenausgleich auf andere Server oder durch beides gehandhabt? Reicht die latente Kapazit�t zur Handhabung ungew�hnlicher Spitzenlast aus, bis der n�chste Meilenstein der Bereitstellungsskalierung erreicht wird?
Sicherheit	Haben Sie den leistungsbezogenen Mehraufwand, der f�r die Handhabung sicherer Transaktionen erforderlich ist, ausreichend ber�cksichtigt?
Verf�gbarkeit	Haben Sie in Bezug auf horizontal redundante L�sungen die langfristigen Wartungskosten ausreichend ber�cksichtigt? Haben Sie die geplanten Ausfallzeiten ber�cksichtigt, die f�r die Wartung des Systems erforderlich sind? Wurde ein Kostengleichgewicht zwischen High-End- und Low-End-Servern erzielt?
Skalierbarkeit	Haben Sie in Ihrer Einsch�tzung Meilensteine f�r die Bereitstellungsskalierung ber�cksichtigt? Verf�gen Sie �ber eine Strategie, mit der ausreichend latente Kapazit�t zur Handhabung von prognostiziertem Lastanstieg bereitgestellt wird, bis die Meilensteine f�r die Skalierung der Bereitstellung erreicht werden?
Wartungseignung	Haben Sie die Kosten f�r Verwaltung, �berwachung und Wartung in Ihr Verf�gbarkeitskonzept aufgenommen? Haben Sie L�sungen f�r die delegierte Verwaltung (bei denen Endbenutzern die Ausf�hrung einiger Verwaltungsaufgaben erm�glicht wird) in Erw�gung gezogen, um Verwaltungskosten zu senken?

Verwalten von Risiken

Beim Gro�teil der Informationen, auf denen sich ein Bereitstellungskonzept st�tzt, beispielsweise die Dienstanforderungen und die Anwendungsanalyse, handelt es sich nicht um empirische Daten, sondern um Daten, die auf Einsch�tzungen und Prognosen basieren, die von Gesch�ftsanalysen abgeleitet wurden. Diese Prognosen k�nnen aus zahlreichen Gr�nden falsch sein, u. a. durch unvorhergesehene Umst�nde im Gesch�ftsklima, fehlerhafte Methoden der Datenzusammenstellung oder einfach aus Fehlern, die Benutzern unterlaufen. Sehen Sie sich vor der Fertigstellung eines Bereitstellungskonzepts nochmals die Analysen an, auf denen das Konzept basiert, um sicherzustellen, dass in Ihrem Konzept etwaige realistische Abweichungen von Einsch�tzungen oder Prognosen ber�cksichtigt wurden.

Wenn beispielsweise in der Anwendungsanalyse die tats�chliche Nutzung des Systems zu niedrig eingesch�tzt wurde, laufen Sie Gefahr, ein System zu konfigurieren, dass dem anfallenden Datenverkehr nicht gewachsen ist. Ein Konzept, dass den Leistungsvorgaben nicht gerecht wird, wird mit Sicherheit als Misserfolg betrachtet.

Wenn auf der anderen Seite ein System konfiguriert wird, das um einiges leistungsf�higer ist als erforderlich, werden Ressourcen abgezogen, die anderswo sinnvoll eingesetzt werden k�nnten. Der Schl�ssel liegt darin, einen Sicherheitsspielraum einzuplanen, der die Anforderungen �bertrifft, gleichzeitig aber den verschwenderischen und folglich nicht effizienten Einsatz von Ressourcen unterbindet.

Der verschwenderische Einsatz von Ressourcen ist ein Fehler des Konzepts, da die nicht gen�gend beanspruchten Ressourcen an anderer Stelle h�tten eingesetzt werden k�nnen. Zudem k�nnten verschwenderische L�sungen von den Interessengruppen als Nichterf�llung von in gutem Glauben abgeschlossenen Vertr�gen interpretiert werden.

Beispiel f�r eine Bereitstellungsarchitektur

In der nachfolgenden Abbildung ist eine fertig gestellte Bereitstellungsarchitektur f�r die Beispielbereitstellung dargestellt, die weiter oben in diesem White Paper eingef�hrt wurde. Diese Abbildung dient als Anhaltspunkt f�r die Pr�sentation einer Bereitstellungsarchitektur.

Zur�ck Inhalt Index Weiter
Sun Java Enterprise System 2005Q1 Handbuch zur Bereitstellungsplanung


Achtung	Die in der nachfolgenden Abbildung dargestellte Bereitstellungsarchitektur dient lediglich der Veranschaulichung. Es handelt sich hierbei nicht um eine Bereitstellung, die tats�chlich konzipiert, erstellt oder getestet wurde, und sollte folglich bei der Bereitstellungsplanung nicht als Anhaltspunkt herangezogen werden.