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:
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.
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.
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. Erläutert die Strategien und Vorgänge zur Migration von Unternehmensdaten und zur Aufrüstung von Unternehmenssoftware. Die migrierten Daten müssen den Formaten und Standards der neu installierten Unternehmensanwendungen entsprechen. Voraussetzung für die Interoperabilität ist, dass von sämtlicher 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, die das in der Bereitstellungsarchitektur angegebene Kontoreplikationskonzept berücksichtigen, sowie Vorgehensweisen zur Bereitstellung neuer Inhalte für Verzeichnisse.
Testplan. Beschreibt Verfahren zum Testen der bereitgestellten Software, einschließlich spezifischer Pläne für die Bereitstellung von Prototyp- und Pilotimplementierungen, Belastungstests, bei denen die Fähigkeit zur Handhabung der geplanten Auslastung ermittelt wird sowie Funktionstests, mit denen überprüft wird, ob der Betrieb erwartungsgemäß verläuft.
Roll-out-Plan. Beschreibt die Vorgehensweisen sowie den Terminplan für die Implementierung aus einer Plan- und Testumgebung in eine Produktionsumgebung. 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. Beschreibt, 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 denen Überwachungs-, Wartungs-, Installations- und Aufrüstungsverfahren beschrieben werden.
Schulungsbuch. Enthält Vorgänge und Vorgehensweisen zur Schulung von Administratoren und Endbenutzern für die Verwendung der neu installierten Software.
Die Entscheidungen, die Sie in der Bereitstellungskonzeptphase treffen, werden von mehreren Faktoren beeinflusst. Berücksichtigen Sie folgende Schlüsselfaktoren:
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 an die Dienstqualität (Quality of Service, QoS) werden unterschiedliche Aspekte des Betriebs einer Lösung angegeben. Verwenden Sie die QoS-Anforderungen, um Strategien auszuarbeiten, 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 Phase der technischen Anforderungen im Lösungszyklus erstellt wurde, 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 Phase der technischen Anforderungen im Lösungslebenszyklus 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. Hieraus geht ebenfalls hervor, auf welcher Ebene und in welchem Umfang Kundenunterstützung vonnöten ist, wenn diese Anforderungen nicht erfüllt werden. Die in einer Vereinbarung auf Dienstebene angegebenen Leistungsanforderungen sollten von einem Bereitstellungskonzept problemlos erfüllt werden können.
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 berücksichtigt 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.
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. Der erste Schritt bei der Bereitstellungskonzeption besteht häufig darin, die Anzahl der Prozessoren (Central Processing Units, 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.
Beachten Sie bei der Analyse die Tradeoffs Ihrer Konzeptentscheidungen. So stellen sich beispielsweise folgende Fragen: Welche Auswirkungen hat die Verfügbarkeits- und Skalierbarkeitsstrategie auf die Wartungseignung des Systems? Welche sonstigen Kosten entstehen durch die Strategien?
Identifizieren 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.
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:
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 zum Umgang mit den Faktoren dar, die sich auf das Endergebnis auswirken.
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.
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.
Ü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.
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:
Detaillierte Anwendungsfälle und Anwendungsanalyse basierend auf eingehender Geschäftsanalyse
Durch Analyse von Geschäftsanforderungen ermittelte QoS-Anforderungen
Spezifische Kosten und Spezifikationen bezüglich Verarbeitungs- und Netzwerkhardware
Bei der Implementierung vergleichbarer Bereitstellungen gesammelte Erfahrungen
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.
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.
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. |
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. |
1 |
Ermöglicht den Zugriff auf Messaging Server-Nachrichtenspeicher für E-Mail-Clients. |
|
1 |
Ruft E-Mail-Nachrichten ab und speichert sie. |
|
2 |
Stellt Autorisierungs- und Authentifizierungsdienste bereit. |
|
2 |
Ruft Kalenderdaten für Communications Express, ein Calendar Server-Front-End, ab und speichert sie. |
|
2 |
Stellt LDAP-(Lightweight Directory Access Protocol-)Verzeichnisdienste zur Verfügung. |
|
0 |
Bietet Webcontainer-Unterstützung für Portal Server und Access Manager. (Keine zusätzlichen CPU-Zyklen erforderlich.) |
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 |
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 Phase der technischen Anforderungen, wie sich der sichere Transport von Daten auf die Auslastungsanforderungen auswirken kann, und passen Sie Ihre Einschätzungen entsprechend an. Im folgenden Abschnitt, Einschätzen von Prozessoranforderungen für sichere Transaktionen , wird erläutert, wie die 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 folgenden Abschnitt, Ermitteln von Verfügbarkeitsstrategien, werden Größenaspekte für Verfügbarkeitslösungen erläutert. Im Abschnitt Festlegen 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.
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 |
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.
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:
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 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:
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.
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 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.
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:
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, die unter Konzeption für optimale Ressourcennutzung beschrieben sind. Komplexe Lösungen mit großem Verwaltungs- und Wartungsaufwand sollten vermieden werden.
Die Verfügbarkeitsstrategien für Java Enterprise System-Bereitstellungen beinhalten folgende Punkte:
Lastenausgleich. Nutzt redundante Hard- und Softwarekomponenten zur verteilten Lastenverarbeitung. Von einem Lastenausgleichssystem werden sämtliche Anforderungen eines Dienstes 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.
Sun Cluster-Software beinhaltet eine Failover-Lösung für kritische Daten, die von Back-End-Komponenten verwaltet werden, beispielsweise der Nachrichtenspeicher für Messaging Server und Kalenderdaten für Calendar Server.
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.
Platzieren Sie alle Rechnerressourcen für einen Dienst auf einem einzelnen Server. Wenn der Server ausfällt, schlägt der gesamte Dienst fehl.
Sun bietet High-End-Server mit folgenden Vorteilen:
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 Single-Point-of-Failure gestalten sich in einem System mit mehreren Servern flexibler.
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 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.
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.
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:
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.
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.
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.
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:
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 zu einem Dienstausfall 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.
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.
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:
Wenn ein Server ausfällt, stellt der verbleibende Server die CPU-Kapazität zur Handhabung der Last bereit.
Hinsichtlich der Skalierbarkeitsanforderung, wonach 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, wonach 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.
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.
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.
Verkettung 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 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.
In der folgenden 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.
Zu den Vorteilen einer Einzelmaster-Replikation zählen:
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
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.
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.
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.
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.
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.
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.
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 |
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.
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:
Minimum memory and disk space requirements Bietet Einschätzungen dazu, wie viel Festplatten- und Speicherplatz für Verzeichnisse unterschiedlicher Größe benötigt wird.
Sizing physical memory for cache access Enthält Anleitungen zur Einschätzung der Cachegröße gemäß der geplanten Nutzung von Directory Server sowie zur Planung der Gesamtspeichernutzung.
Sizing disk subsystems Enthält Informationen zur Planung der Festplattengröße gemäß den Verzeichnissuffixe und zu Directory Server-Faktoren, die 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.
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 |
---|---|
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? |
Haben Sie den leistungsbezogenen Mehraufwand, der für die Handhabung sicherer Transaktionen erforderlich ist, ausreichend berücksichtigt? |
|
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? |
|
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? |
|
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? |
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.
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.
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.