test

Sun Java Enterprise System 2005Q4 Handbuch zur Bereitstellungsplanung

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.

Dieses Kapitel enthält die folgenden Abschnitte:

Informationen zu Bereitstellungskonzepten

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

Die Konzipierung der Bereitstellungsarchitektur ist ein von Wiederholungen geprägter Vorgang. Die QoS-Anforderungen werden üblicherweise erneut zurate gezogen und die im Vorfeld festgelegten Konzepte nochmals überprüft. Dabei werden die Wechselbeziehungen der QoS-Anforderungen berücksichtigt 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 während der Bereitstellungskonzeptphase, üblicherweise nach der Erstellung der Bereitstellungsarchitektur. Die geschätzten realen Bereitstellungskosten werden anhand der Bereitstellungsarchitektur und gegebenenfalls 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:

Faktoren mit Auswirkung auf das Bereitstellungskonzept

Die Entscheidungen, die Sie in der Bereitstellungskonzeptphase treffen, werden von mehreren Faktoren beeinflusst. Berücksichtigen Sie folgende Schlüsselfaktoren:

Methodik des Bereitstellungskonzepts

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 steht im Mittelpunkt, Leistungsvorgaben zu erfüllen und gleichzeitig anderen QoS-Anforderungen gerecht zu werden. Mit den von Ihnen eingesetzten Strategien muss ein Gleichgewicht der Tradeoffs Ihrer Konzeptentscheidungen erreicht werden, um die Lösung zu optimieren. Die verwendete Methodik umfasst im Regelfall folgende Aufgaben:

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. Anhand eines Beispielszenarios einer Kommunikationsbereitstellung wird 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:

Der Einschätzungsvorgang umfasst die nachfolgend aufgeführten Schritte. Die Reihenfolge dieser Schritte ist nicht zwingend vorgegeben, stellt jedoch eine Möglichkeit zum Umgang mit den Faktoren dar, die sich auf das Endergebnis auswirken.

  1. Ermitteln Sie eine 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.

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

    Befassen Sie sich eingehend mit der Interaktion zwischen Komponenten in der logischen Architektur, um zu ermitteln, in welchen Fällen es durch abhängige Komponenten zu zusätzlicher Auslastung kommt.

  3. Ü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.

  4. 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 AbschnittIdentitä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:

Achtung – Achtung –

Die in diesen Beispielen enthaltenen Informationen dienen nicht als spezifische Implementierungshinweise, sondern lediglich der Veranschaulichung eines Vorgangs, den Sie bei der Konzeption eines Systems möglicherweise durchführen.

CPU-Basiseinschätzung für Benutzereinstiegspunkte ermitteln

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. Die folgende Abbildung zeigt die logische Architektur für ein identitätsbasiertes Kommunikationsszenario, dass zuvor unter Identitätsbasiertes Kommunikationsbeispiel beschrieben wurde.

Abbildung 5–1 Logische Architektur für ein identitätsbasiertes Kommunikationsszenario

Diagramm mit den logischen Komponenten eines in einer mehrschichtigen Architektur implementierten identitätsbasierten Kommunikationsszenarios.

In der folgenden 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 ein Benutzereinstiegspunkt ist. 

Communications Express 

2 

Leitet Daten an Messaging- und Kalenderkanäle von Portal Server weiter. 

Aufnehmen der CPU-Einschätzungen für Dienstabhängigkeiten

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 der Interaktion zwischen Komponenten genau angegeben werden, wie im Beispiel mit der logischen Architektur im Abschnitt Beispiel 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 die Empfänger weiter. 

Messaging Server MMP

1 

Ermöglicht den Zugriff auf 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 Server und 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:

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:

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 Ihre spezifischen Anforderungen hinsichtlich der Replikation von Diensten berücksichtigen.

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 folgenden 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 JavaTM Enterprise System-Dienste hierfür genutzt werden, ist für sichere Transaktionen u. U. das Vierfache an Rechnerkapazität erforderlich als 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 erforderlich. In anderen Szenarios ist der sichere Transport möglicherweise für sämtliche Transaktionen erforderlich.

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 weiter erläutert, um aufzuzeigen, wie CPU-Anforderungen für einen theoretischen Anwendungsfall mit sicheren sowie nicht sichere Transkationen berechnet werden können.

Um die CPU-Anforderungen für sichere Transaktionen einzuschätzen, führen Sie folgende Berechnungen durch:

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

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

  3. Berechnen Sie die verringerten CPU-Einschätzungen für nicht sichere Transaktionen.

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

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

In CPU-Einschätzungen für sichere Transaktionen finden Sie eine Beispielberechnung, die auf Anwendungsfällen und Anwendungsanalysen für Portal Server basiert, bei denen von Folgendem ausgegangen wird:

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 Anwendungsfälle auf Spitzenauslastung hin prüfen 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 4fache 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 CPU-Einschätzungen für sichere Transaktionen dahin gehend ändern, dass zwei zusätzliche CPUs und 4 GB Speicher hinzugefügt und so der Gesamtwert für Portal Server ermittelt wird.

Komponente 

CPUs 

Arbeitsspeicher 

Portal Server 

6 

12 GB 

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 der Installation, der Konfiguration, dem Testen und Verwalten dieser Geräte.

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 für Angaben aufgeführt, die bei der Ermittlung von Verfügbarkeitsstrategien hilfreich sind:

In der von Ihnen ausgewählten Verfügbarkeitsstrategie müssen auch die Anforderungen hinsichtlich der Wartungseignung berücksichtigt werden, die unter Konzeption für optimale Ressourcennutzung beschrieben sind. Komplexe Lösungen mit großem Verwaltungs- und Wartungsaufwand sollten vermieden werden.

Verfügbarkeitsstrategien

Die Verfügbarkeitsstrategien für Java Enterprise System-Bereitstellungen beinhalten folgende Punkte:

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.

Abbildung 5–2 System mit nur einem Server

Die Abbildung zeigt einen einzelnen Server mit 10 CPUs, die die Leistungsanforderungen erfüllen.

Sun bietet High-End-Server mit folgenden Vorteilen:

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 Single-Point-of-Failure 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.

Abbildung 5–3 N+1-Failover-System mit zwei Servern

Die Abbildung zeigt zwei Replikationsserver mit jeweils 10 CPUs, die die 10-CPU-Leistungsanforderung erfüllen.

Die Rechnerkapazität der Server in der oben gezeigten Abbildung Horizontal redundante Systeme 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 folgenden Abbildung ist ein System dargestellt, in dem Lastenausgleich plus Failover implementiert werden und so die Leistung zwischen zwei Servern aufgeteilt wird.

Abbildung 5–4 Lastenausgleich plus Failover zwischen zwei Servern

Die Abbildung zeigt zwei Server mit jeweils 6 CPUs, die die 10-CPU-Leistungsanforderung erfüllen.

In dem System, das in Horizontal redundante Systeme 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.

Abbildung 5–5 Verteilung der Last zwischen n Servern

Die Abbildung zeigt 5 Server mit jeweils 2 CPUs, die die 10-CPU-Leistungsanforderung erfüllen.

Da das in der Abbildung Horizontal redundante Systeme dargestellte Konzept 5 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.

Dieses Konzept bringt folgende Vorteile mit sich:

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

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 folgenden Tabelle sind 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 berechnet wurden.

Tabelle 5–6 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 Phase der technischen Anforderungen folgende Dienstqualitätsanforderungen festgelegt wurden:

Um die Verfügbarkeitsanforderung zu erfüllen, 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.

Das Architekturdiagramm zeigt die Verfügbarkeit von Messaging Server MMP- und MTA-Komponenten.

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

Failover-Beispiel mit Sun Cluster-Software

In der folgenden Abbildung wird 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 Nachrichtenspeicher 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.

Abbildung 5–6 Failover-Konzept mit Sun Cluster-Software

Das Architekturdiagramm zeigt den mit Sun Cluster-Software für Failover-Zwecke bereitgestellten Calendar Server- und Message Server-Speicher.

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:

Verfügbarkeitsstrategien für Directory Server sind ein komplexes Thema, das den Rahmen dieses Handbuchs sprengen würde. In den folgenden Abschnitten, Einzelmaster-Replikation und Multimaster-Replikation werden die grundlegenden Replikationsstrategien erläutert. Ausführliche Informationen finden Sie in Kapitel 12, Designing a Highly Available Deployment, im Sun Java System Directory Server 5 2005Q1 Deployment Plannning Guide.

Einzelmaster-Replikation

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

Abbildung 5–7 Beispiel für eine Einzelmaster-Replikation

Das Diagramm zeigt den Datenstrom für eine Einzelmaster-Replikation.

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.

Zu den Vorteilen einer Einzelmaster-Replikation zählen:

Multimaster-Replikation

In der folgenden Abbildung ist eine Multimaster-Replikationsstrategie dargestellt, die zur globalen Verteilung des Verzeichniszugriffs verwendet werden kann.

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.

Abbildung 5–8 Beispiel für eine Multimaster-Replikation

Das Diagramm zeigt den Datenstrom für eine Multimaster-Replikation.

Die Multimaster-Replikationsstrategie bietet alle Vorteile einer Einzelmaster-Replikation und zusätzlich eine Verfügbarkeitsstrategie, durch die der Lastenausgleich für Aktualisierungen des Masters bereitgestellt werden kann. 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.

Festlegen 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 üblicherweise 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 die Verwendung der latenten Kapazität in einem bereitgestellten System überwachen, 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 50.000 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 250.000 Benutzer und 2.000.000 Benutzer skaliert werden kann.

Hinweis –

In der Abbildung Skalierbarkeitsbeispiel wird der Unterschied zwischen vertikaler und horizontaler Skalierung erläutert. Es werden keine zusätzlichen Faktoren veranschaulicht, die bei der Skalierung berücksichtigt werden müssen, beispielsweise Lastenausgleich, Failover sowie Änderungen in Anwendungsmustern.

Abbildung 5–9 Beispiele für horizontale und vertikale Skalierung

Das Architekturdiagramm zeigt die vertikale und horizontale Skalierung im Vergleich mit einer Basisarchitektur.

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 folgenden 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–7 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 

Netzwerk -schnittstelle  

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 

Hinweis –

Unter Identifizieren von Leistungsengpässen 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.

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. Abschließend wird die Prüfung der Netzwerkschnittstelle auf potenzielle Engpässe sowie die Ausarbeitung von Strategien, mit denen diese Engpässe beseitigt werden können, durchgeführt.

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 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 Verkettung und Verknüpfung zur Verfügung, mit denen sich der Zugriff auf Verzeichnisdienste optimieren lässt.

In Kapitel 6, Defining System Characteristics, im Sun Java System Directory Server 5 2005Q1 Deployment Plannning Guide werden verschiedene für die Planung des Festplattenzugriffs zu berücksichtigende Faktoren erläutert. Folgende Themen werden in diesem Kapitel behandelt:

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 folgenden Tabelle sind einige Systemqualitäten und die zugehörigen Überlegungen im Hinblick auf die Ressourcenverwaltung aufgeführt.

Tabelle 5–8 Überlegungen hinsichtlich 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 Ihrem Verfügbarkeitskonzept berücksichtigt? 

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 Dienstqualitätsanforderungen 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 folgenden 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.

Achtung – Achtung –

Die in der folgenden 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.

Abbildung 5–10 Beispiel für eine Bereitstellungsarchitektur

Diese Abbildung zeigt ein Beispiel für ein Bereitstellungsarchitektur-Layout.