![]() | |
Sun Java Enterprise System 2005Q1 Handbuch zur Bereitstellungsplanung |
Kapitel 3
Technische AnforderungenWährend der Phase der technischen Anforderungen des Lebenszyklus einer Lösung führen Sie eine Anwendungsanalyse durch, bestimmen Anwendungsfälle und ermitteln die Dienstqualitätsanforderungen für die geplante Bereitstellungslösung.
Dieses Kapitel enthält die folgenden Abschnitte:
Informationen über technische AnforderungenDie Analyse der technischen Anforderungen beginnt mit Geschäftsanforderungsdokumenten, die während der Geschäftsanalysephase des Lebenszyklus einer Lösung erstellt werden. Verwenden Sie die Geschäftsanalyse als Grundlage und gehen Sie wie folgt vor:
- Führen Sie eine Anwendungsanalyse durch, mit deren Hilfe Sie die erwarteten Ladebedingungen bestimmen können.
- Erstellen Sie Anwendungsfälle, die typische Benutzerinteraktionen mit dem System beispielhaft darstellen.
- Erstellen Sie einen Satz an Dienstqualitätsanforderungen (Quality of Service, QoS), die definieren, welche Leistung eine bereitgestellte Lösung in Bereichen, wie beispielsweise Antwortzeit, Verfügbarkeit, Sicherheit usw., erbringen muss.
Die Dienstqualitätsanforderungen werden von der Anwendungsanalyse abgeleitet, wobei die Anwendungsfälle, unter Berücksichtigung der Geschäftsanforderungen und -einschränkungen zuvor ermittelt werden.
Die Geschäftsanforderungen werden später mit logischen Architekturen in der Phase des logischen Konzepts gepaart, um ein Bereitstellungsszenario zu entwerfen. Das Bereitstellungsszenario ist die wichtigste Eingabe für die Bereitstellungskonzeptphase des Lebenszyklus der Lösung.
Wie im Fall der Geschäftsanalyse gibt es keine einfache Formel für die Analyse der technischen Anforderungen, mit der die Anwendungsanalyse, Anwendungsfälle und Systemanforderungen generiert werden. Für die Analyse der technischen Anforderungen müssen die Geschäftsdomäne, die geschäftlichen Ziele und die zugrunde liegende Systemtechnologie begriffen werden.
AnwendungsanalyseBei der Anwendungsanalyse werden die verschiedenen Benutzer der zu entwerfenden Lösung sowie die Anwendungsmuster für jene Benutzer ermittelt. Die zusammengetragenen Informationen bieten eine Grundlage für die Einschätzung der Ladebedingungen auf dem System. Die Anwendungsanalyseinformationen sind auch bei der Gewichtung der Anwendungsfälle, wie unter Anwendungsfälle beschrieben, von Nutzen.
Während der Anwendungsanalyse sollten Sie Benutzer wannimmer möglich befragen, vorhandene Daten zu Anwendungsmustern untersuchen und Befragungen bei Herstellern und Administratoren von früheren Systemen durchführen. In der folgenden Tabelle werden die Faktoren aufgeführt, die bei der Durchführung einer Anwendungsanalyse berücksichtigt werden sollten.
AnwendungsfälleAnwendungsfälle stellen die typische Benutzerinteraktion mit der zu entwerfenden Lösung beispielhaft dar und beschreiben den vollständigen Verlauf eines Vorgangs aus der Perspektive eines Endbenutzers. Wenn für das Konzept eine komplette Gruppe von Anwendungsfällen zugrunde gelegt wird, wird das Augenmerk dauerhaft darauf gelegt, dass die gewünschte Funktionalität erbracht wird. Anwendungsfälle sind die wichtigste Grundlage für ein logisches Konzept.
Weisen Sie den Anwendungsfällen eine relative Gewichtung zu, wobei die höchste Gewichtung die Fälle erhalten, die für die häufigsten Benutzeraufgaben stehen. Die Gewichtung von Anwendungsfällen ermöglicht Ihnen die Fokusierung Ihrer Konzeptentscheidungen auf die Systemdienste, die am häufigsten verwendet werden.
Anwendungsfälle können durch zwei Ebenen näher beschrieben werden.
- Anwendungsfallberichte. Beschreibungen der einzelnen Anwendungsfälle, einschließlich der primären und alternativen Ereignisabläufe.
- Anwendungsfalldiagramme. Diagramme, die die Beziehungen zwischen den Beteiligten und die Anwendungsfälle bildlich darstellen und dadurch eine formellere Organisation des Ereignisflusses bieten. Anwendungsfalldiagramme eignen sich zur Darstellung langer oder komplexer Anwendungsfälle. Normalerweise verwenden Sie Unified Modeling Language-(UML-)Standards, um Anwendungsfalldiagramme zu zeichnen.
DienstqualitätsanforderungenDienstqualitätsanforderungen (QoS-Anforderungen) sind technische Spezifikationen, die die Dienstqualität von Merkmalen, wie beispielsweise der Leistung, Verfügbarkeit, Skalierbarkeit und Zweckmäßigkeit, bestimmen. QoS-Anforderungen werden durch die geschäftlichen Bedürfnisse bestimmt, die durch die Anforderungen für das Unternehmen angegeben werden. Wenn beispielsweise ein Dienst 24 Stunden jeden Tag im gesamten Jahr verfügbar sein muss, muss die Verfügbarkeitsanforderung auf diese Anforderung im Unternehmen abzielen.
In der folgenden Tabelle werden die Systemqualitäten aufgeführt, die normalerweise die Grundlage für die QoS-Anforderungen bilden.
Systemqualitäten sind eng miteinander verknüpft. Die Anforderungen für eine Systemqualität können die Anforderungen und das Konzept für andere Systemqualitäten beeinflussen. So kann beispielsweise ein höheres Sicherheitsniveau die Leistung beeinträchtigen, was wiederum die Verfügbarkeit beeinflusst. Das Hinzufügen weiterer Server, um Verfügbarkeitsprobleme zu beheben, wirkt sich auf die Wartungskosten (Zweckmäßigkeit) aus.
Für die Entwicklung eines Systems, das sowohl die geschäftlichen Anforderungen als auch Einschränkungen befriedigt, muss klar sein, wie die Systemqualitäten verknüpft sind und wie diese abgestimmt werden.
In den folgenden Abschnitten werden die Systemqualitäten, die sich auf das Bereitstellungskonzept auswirken, näher beschrieben. Es wird außerdem erklärt, welche Faktoren bei der Gestaltung der QoS-Anforderungen berücksichtigt werden müssen. Ein Abschnitt zu den Anforderungen für die Dienstebenen, die die Grundlage für die Vereinbarungen auf Dienstebene (Service Level Agreement, SLA) bilden, ist ebenfalls enthalten.
Leistung
Geschäftsanforderungen messen die Leistung normalerweise in nicht technischen Begriffen, die sich auf die Antwortzeit beziehen. Eine Geschäftsanforderung für den internetbasierten Zugriff könnte beispielsweise wie folgt lauten:
Untersuchen Sie, beginnend mit dieser Geschäftsanforderung sämtliche Anwendungsfälle, um zu bestimmen, wie Sie diese Anforderung auf einer Systemebene ausdrücken können. In einigen Fällen möchten Sie möglicherweise Benutzerladebedingungen miteinschließen, die während der Anwendungsanaylse ermittelt wurden. Drücken Sie die Leistungsanforderung für jeden Anwendungsfall in Bezug auf die Antwortzeit unter bestimmten Ladebedingungen oder in Bezug auf die Antwortzeit zuzüglich Datendurchsatz aus. Geben Sie auch die zulässige Anzahl an Fehlern an.
Im Folgenden sehen Sie zwei Beispiele für die Angabe der Systemanforderungen für die Leistung:
Die Antwortzeit bei der Webseitenaktualisierung darf während des gesamten Tages 4 Sekunden nicht überschreiten (Prüfung alle 15 Minuten), wobei nur unter 3,4 Fehler pro eine Million Transaktionen auftreten dürfen.
Während definierter Spitzenzeiträume muss das System 25 sichere Anmeldungen pro Sekunde zulassen, wobei die Antwortzeit für jeden Benutzer 12 Sekunden nicht überschreiten darf und weniger als 3,4 Fehler pro eine Million Transaktionen auftreten dürfen.
Leistungsanforderungen sind eng mit Verfügbarkeitsanforderungen (Failover-Auswirkung auf die Leistung) und der latenten Kapazität (Menge der verfügbaren Kapazität für die Bewältigung außergewöhnlichen Spitzenauslastung) verknüpft.
Verfügbarkeit
Über die Verfügbarkeit kann man die Betriebszeit eines Systems bestimmen. Sie bemisst sich normalerweise aus dem Prozentsatz der Zeit, während der Benutzer auf das System zugreifen kann. Die Zeit, in der das System nicht verfügbar ist (Ausfallzeit) kann durch Ausfälle der Hardware, der Software, des Netzwerks oder durch einen beliebigen anderen Faktor (z. B. Unterbrechung der Stromversorgung) verursacht werden, durch den das System zum Stillstand kommt. Geplante Zeiten, in denen das System zu Servicezwecken (Wartung und Aufrüstungen) heruntergefahren wird, werden nicht als Ausfallzeit bezeichnet. Ein grundlegende Gleichung zur Berechnung der Systemverfügbarkeit als Prozentsatz der Betriebszeit ist:
Verfügbarkeit = Betriebszeit / (Betriebszeit + Ausfallzeit) * 100%
Normalerweise messen Sie die Verfügbarkeit anhand der Anzahl der „Neunen“, die Sie erreichen können. Beispielsweise erhalten Sie bei 99%-iger Verfügbarkeit zwei Neunen. Die Angabe zusätzlicher Neunen wirkt sich erheblich auf das Bereitstellungskonzept aus. In der folgenden Tabelle wird die unvorhergesehene Ausfallzeit bei zusätzlichen „Verfügbarkeits-Neunen“ auf einem System berechnet, das 24 Stunden an 7 Tagen die Woche im gesamten Jahr (insgesamt 8760 Stunden) verfügbar ist.
Fehlertolerante Systeme
Verfügbarkeitsanforderungen von vier oder fünf Neunen erfordern im Normalfall ein fehlertolerantes System. Ein fehlertolerantes System muss in der Lage sein, seinen Dienst während eines Hardware- oder Softwareausfalls fortzusetzen. Normalerweise wird die Fehlertoleranz durch Redundanz in der Hardware (CPUs, Speicher- und Netzwerkgeräte) als auch in der Software, die die wichtigsten Dienste zur Verfügung stellt, erreicht.
Bei einem Einzelpunkt-Versagen handelt es sich um eine Hardware- oder Softwarekomponente, die Teil eines wichtigen Pfads ist, aber nicht von redundanten Komponenten gesichert wird. Der Ausfall dieser Komponente führt zum Dienstausfall des Systems. Wenn Sie ein fehlertolerantes System konzipieren, müssen Sie potenzielle Einzelpunkt-Versagen ermitteln und vermeiden.
Fehlertolerante Systeme können in der Implementierung und Wartung teuer sein. Stellen Sie sicher, dass Sie die verstanden haben, worin die Geschäftsanforderungen für die Verfügbarkeit liegen, und berücksichtigen Sie die Strategien und Kosten der Verfügbarkeitslösungen, die diese Anforderungen erfüllen.
Priorisieren der Dienstverfügbarkeit
Aus Sicht des Benutzers bezieht sich die Verfügbarkeit oft eher auf einzelne Dienste als auf die Verfügbarkeit des gesamten Systems. So hat es beispielsweise im Normalfall keine oder nur geringe Auswirkungen auf andere Dienste, wenn keine Instant Messaging-Dienste verfügbar sind. Wenn jedoch Dienste nicht verfügbar sind, von denen viele andere Dienste abhängig sind (z. B. Directory Server), sind die Auswirkungen weitreichender. Genauere Verfügbarkeitsspezifikationen sollten deutlich auf Anwendungsfälle und Anwendungsanalysen verweisen, für die eine höhere Verfügbarkeit erforderlich ist.
Es ist hilfreich, Verfügbarkeitsbedürfnisse anhand von verschiedenen sortierten Prioritäten aufzulisten. In der folgenden Tabelle wird die Verfügbarkeit verschiedener Diensttypen nach Priorität geordnet aufgeführt.
Dienstausfall
Im Rahmen des Verfügbarkeitskonzepts wird auch berücksichtigt, was geschieht, wenn die Verfügbarkeit beeinträchtigt wird oder eine Komponente ausfällt. Hierbei muss auch berücksichtigt werden, ob die angemeldeten Benutzer Sitzungen neu starten müssen und inwiefern ein Fehler in einem Bereich sich auf andere Bereiche eines Systems auswirkt. QoS-Anforderungen sollten diese Szenarien beachten und angeben, wie die Bereitstellung auf derartige Situationen reagiert.
Skalierbarkeit
Unter Skalierbarkeit wird die Fähigkeit verstanden, einem System Kapazitäten hinzuzufügen, sodass das System eine zusätzliche Auslastung durch bestehende Benutzer oder durch einen erweiterten Benutzerstamm unterstützen kann. Die Skalierbarkeit setzt normalerweise eine Erweiterung der Ressourcen voraus; es sollten jedoch keine Änderungen am Konzept der Bereitstellungsarchitektur oder Dienstausfälle erforderlich sein, die sich aufgrund der für das Hinzufügen zusätzlicher Ressourcen benötigten Zeit ergeben.
Wie auch die Verfügbarkeit bezieht sich die Skalierbarkeit eher auf einzelne von einem System bereitgestellte Dienste als auf das gesamte System. Im Fall von Diensten, von denen andere Dienste abhängig sind (z. B. Directory Server), kann sich die Skalierbarkeit auf das gesamte System auswirken.
Sie geben die Skalierbarkeitsanforderungen nicht notwendigerweise mit den QoS-Anforderungen an, es sei denn, das geplante Wachstum der Bereitstellung wird eindeutig in den Geschäftsanforderungen festgehalten. Während der Bereitstellungskonzeptphase des Lösungszyklus sollte die Bereitstellungsarchitektur grundsätzlich einen gewissen Spielraum für die Skalierung des Systems einschließen, auch wenn keine QoS-Anforderungen für die Skalierbarkeit angegeben wurden.
Wachstumseinschätzung
Bei der Einschätzung des Wachstums eines Systems zur Ermittlung der Skalierbarkeitsanforderungen muss mit Hochrechnungen, Schätzungen und Vermutungen gearbeitet werden, die möglicherweise nicht eintreten. Es gibt folgende drei Schlüssel für die Entwicklung von Anforderungen für ein skalierbares System:
- Hochleistungskonzept-Strategie. Bei der Spezifikation der Leistungsanforderungen sollte die latente Kapazität eingeschlossen werden, um Auslastungen zu berücksichtigen, die im Laufe der Zeit zunehmen. Maximieren Sie außerdem die Verfügbarkeit innerhalb der Budgeteinschränkungen. Durch diese Strategie können Sie das Wachstum absorbieren und Meilensteine für die Skalierung des Systems besser setzen.
- Inkrementelle Bereitstellung. Durch eine inkrementelle Bereitstellung können Sie besser planen, wann Ressourcen hinzugefügt werden. Geben Sie eindeutige Meilensteine für die Skalierung des Systems an. Meilensteine sind normalerweise lastenbasierte Anforderungen, die mit bestimmten Daten für die Prüfung der Skalierbarkeit koordiniert werden.
- Umfassende Leistungsüberwachung. Durch die Überwachung der Leistung können Sie besser festlegen, wann dem System Ressourcen hinzugefügt werden sollten. Anforderungen für die Überwachung der Leistung können einen Leitfaden für Operatoren und Administratoren darstellen, die für die Wartung und Aktualisierung verantwortlich sind.
In der folgenden Tabelle werden die Faktoren aufgeführt, die bei der Ermittlung der Skalierbarkeitsanforderungen berücksichtigt werden sollten.
Sicherheitsanforderungen
Sicherheit ist ein komplexes Thema, das alle Stufen eines bereitgestellten Systems betrifft. Die Entwicklung von Sicherheitsanforderungen schließt die Identifizierung der Sicherheitsbedrohungen und die Entwicklung einer Strategie zur Bekämpfung dieser Gefahren ein. Diese Sicherheitsanalyse beinhaltet folgende Schritte:
Bei der Analyse der Sicherheitsanforderungen sollte ein Querschnitt durch die Interessengruppen in Ihrem Unternehmen, wie beispielsweise leitende Angestellte, Unternehmensanalysten und Mitarbeiter aus dem IT-Bereich, einbezogen werden. Häufig wird in einem Unternehmen ein Sicherheitsarchitekt ernannt, der die Entwicklung und Implementierung der Sicherheitsmaßnahmen leiten soll.
Im folgenden Abschnitt werden einige der Bereiche beschrieben, die bei der Sicherheitsplanung abgedeckt werden.
Elemente eines Sicherheitsplans
Die Planung der Sicherheit eines Systems ist Bestandteil des Bereitstellungskonzepts, das für die erfolgreiche Implementierung unabdingbar ist. Ziehen Sie bei der Sicherheitsplanung folgende Aspekte in Betracht:
- Physische Sicherheit. Die physische Sicherheit betrifft den physischen Zugriff auf Router, Server, Serverräume, Datenzentren und andere Teile der Infrastruktur. Andere Sicherheitsmaßnahmen werden beeinträchtigt, wenn eine nicht autorisierte Person einen Serverraum betreten und dort die Routerverbindungen trennen kann.
- Netzwerksicherheit. Die Netzwerksicherheit betrifft den Zugriff auf Ihr Netzwerk über Firewalls, sichere Zugriffsbereiche, Zugriffssteuerungslisten und den Portzugriff. Um die Netzwerksicherheit herzustellen, entwickeln Sie Strategien gegen unberechtigte Zugriffe, Sabotage und Dienstverweiterungs-(DoS-)Angriffe.
- Anwendungs- und Anwendungsdatensicherheit. Die Anwendungs- und Anwendungsdatensicherheit deckt den Zugriff auf Benutzerkonten, Unernehmensdaten und Unternehmensanwendungen mithilfe von Authentifizierungs- und Berechtigungsprozeduren und -richtlinien ab. Dieser Bereich beinhaltet die Definition folgender Richtlinien:
- Persönliche Sicherheitspraktiken. Eine unternehmensübergreifende Sicherheitsrichtlinie definiert die Arbeitsumgebung und die Methoden, denen alle Benutzer unterworfen sind, um sicherzustellen, dass andere Sicherheitsmaßnahmen wie geplant funktionieren. Im Normalfall entwickeln Sie einen Sicherheitsleitfaden oder ein Handbuch und bieten Schulungen zu den Sicherheitspraktiken für die Benutzer an. Um eine effektive umfassende Sicherheitsstrategie zu gewährleisten, müssen vernünftige Sicherheitsmaßnahmen Teil der Unternehmenskultur werden.
Latente Kapazität
Die latente Kapazität ist die Fähigkeit einer Bereitstellung, eine außergewöhnliche Spitzenauslastung zu bewältigen, ohne zusätzliche Ressourcen hinzuzufügen. Normalerweise geben Sie QoS-Anforderungen nicht direkt über die latente Kapazität an, aber diese Systemqualität ist ein Faktor für die Verfügbarkeit, Leistung und Skalierbarkeit des Systems.
Wartungseignungsanforderungen
Die Wartungseignung ist die Einfachheit, mit der ein bereitgestelltes System gewartet werden kann. Dazu zählen Aufgaben wie Überwachung des Systems, Behebung von auftretenden Problemen, Hinzufügen zum und Entfernen von Benutzern vom System und Aufrüsten der Hardware- und Softwarekomponenten.
Beim Planen der Wartungseignungsanforderungen sollten Sie die in der folgenden Tabelle aufgeführten Aspekte berücksichtigen.
Anforderungen an die DienstebeneIn einer Vereinbarung auf Dienstebene (Service Level Agreement, SLA) werden die leistungsbezogenen Mindestanforderungen angegeben. Wenn diese Anforderungen nicht erfüllt werden, geht hieraus ebenfalls hervor, auf welcher Ebene und in welchem Umfang Kundenunterstützung vonnöten ist. Anforderungen an die Dienstebene sind Systemanforderungen, die die Bedingungen angeben, auf denen die SLA basiert.
Wie auch QoS-Anforderungen werden Anforderungen an die Dienstebene von den Geschäftsanforderungen abgeleitet und garantieren die allgemeine Systemqualität, die das bereitgestellte System aufweisen muss. Da die Vereinbarung auf Dienstebene als Vertrag angesehen wird, sollten die Anforderungen an die Dienstebene eindeutig festgelegt sein. Die Anforderungen an die Dienstebene definieren genau, unter welchen Bedingungen die Anforderungen getestet werden und welche Folgen es nach sich zieht, wenn die Anforderungen nicht erfüllt werden.