COMLINE Cloud ServicesComputing & Infrastructure Concepts

Christian GüntherHannover, 09.12.2016

Die COMLINE AG präsentiert

Computing Concepts

1. Elastizität statt Redundanz2. Elastische Infrastruktur3. Homogenität der physischen Plattform 4. Ressourcen-Pools5. Virtualisierte Runtime6. Fabric Management7. Partitionierung der Shared Ressourcen8. Ressource Decay9. Service Klassifizierung10.Sicherheit und Identitäts-Management11. Multitenancy

Computing Concepts

Früher wurde Verfügbarkeit vor allem durch Redundanzen, also das Vorhalten von Backupsystemen, erreicht.

Die Backupsysteme liefen in einem Stand-By-Betrieb mit und waren so konzipiert, dass sie, wenn das Hauptsystem ausfiel, dessen Arbeit übernehmen konnten.

Die von diesen Systemen bereitgestellte Rechenleistung konnte aber im produktiven Betrieb nicht genutzt werden.

Verfügbarkeit durch redundantes Bereitstellen von Infrastruktur ist entsprechend teuer und unflexibel.

Elastizität statt Redundanz – 1

Um die Anforderung, nach 100%iger Verfügbarkeit von Cloud-Diensten zu erfüllen muss ein ganzheitlicher Ansatz gewählt werden.

Statt der Bereitstellung redundanter Hardware ist es effektiver (und zumeist auch deutlich kostengünstiger), die gesamte Plattform (inklusive der Anwendungen) elastisch zu konzipieren – sie also in viele, voneinander unabhängig arbeitende Dienste, zu unterteilen.

Eine verteilte Architektur, z.B. auf Basis von unabhängigen Agenten, kann auf eine große Zahl kostengünstiger virtueller Knoten installiert werden. Fällt einer dieser Knoten aus, so übernehmen andere dessen Last, oder es können weitere Knoten schnell angefahren werden.

Außerdem können in einer verteilten, elastischen Architektur die Dienste problemlos über die Grenzen eines Rechenzentrums hinweg installiert werden, da die Partitionierung der Daten und Funktionen keine nachträglich einzubringende, sondern inhärente Eigenschaft des Systems ist.

Elastizität statt Redundanz – 2

In einer elastischen Infrastruktur können Ressourcen bei Bedarf allokiert und, fast noch wichtiger, wieder an den Ressource-Pool zurückgegeben werden.

Zugewiesene Kapazitäten auch wieder zurück-zunehmen ist ein wichtiger Baustein in der optimierten Auslastung der verfügbaren Hardware.

Auch das Prinzip gewünschtes Verhalten zu fördern, kann durch eine elastische Infrastruktur unterstützt werden – wenn das Abrechnungsmodell genutzte und wieder freigegebenen Ressourcen mit einbezieht.

Eine elastische Infrastruktur ist nur teilweise eine technische Gegebenheit, da deren effiziente Nutzung ganz direkt vom Verhalten der Anwender abhängt.

Hier ist eine enge Abstimmung zwischen Anbieter und Kunde notwendig, damit Auslastungsspitzen nicht dazu führen, dass unnötig große Kapazitäten dauerhaft (und damit kostenintensiv) vorgehalten werden.

Das Konzept der elastischen Infrastruktur erfüllt die Erwartung

nach unendlicher Kapazität

Elastische Infrastruktur

Homogenität (von ὁμός homόs „gleich“ und γένεσις genesis „Erzeugung, Geburt“, also etwa: gleiche Beschaffenheit) bezeichnet die Gleichheit einer physikalischen Eigenschaft über die gesamte Ausdehnung eines Systems oder auch die Gleichartigkeit von Elementen eines Systems.

Im Bereich der Infrastruktur bezieht sich Homogenität auf die Gleichartigkeit aller physischen Komponenten – also Server, Netzwerk- und Storagesysteme.

Homogene Infrastrukturen bieten eine Reihe von Vorteilen und erzeugen Skaleneffekte.

Homogenität der Infrastruktur-Plattform

Die Vereinheitlichung der physikalischen und auch virtualisierten Infrastruktur ist eine Schlüsselkomponente um die Vorhersagbarkeit des Gesamtsystems zu erreichen.

Das Antwort- und Lastverhalten lässt sich bei gleichartigen Komponenten einfacher für das Gesamtsystem ermitteln, als dies bei der Nutzung unterschiedlicher Systeme der Fall ist.

Durch die Nutzung gleichartiger Hardware- und Softwarekomponenten ergeben sich zusätzlich die folgenden positiven Eigenschaften– Kostengünstige Beschaffung durch größere Mengen

– Reduzierung der Komplexität

– Reduzierter Schulungsaufwand auf Seiten der Administratoren

– Vereinfachte/Beschleunigte Bereitstellung durch bekannte Verfahren

– Verbesserte und leichtere Automatisierung der operativen Prozesse

Homogenität der Infrastruktur-Plattform

Unter Ressource Pooling versteht man die Zusammenfassung mehrerer, meist getrennter Hardware-Komponenten zu einer logischen Einheit, um so etwa die Auslastung zu optimieren, die Kapazität zu erhöhen.

Ressource Pooling

Network 1

VLAN 1 VLAN n

Network n

VLAN 1 VLAN n

Compute Scale Unit 1 Compute Scale Unit n

SAN 1

Lun 1 Lun n

SAN n

Lun 1 Lun n Storage

Compute

Network

Ressourcen Pool

Beim Ressource-Pooling werden Komponenten (wie CPU, RAM oder Storage) nicht von einer Anwendung alleine, sondern (gesteuert) gemeinsam genutzt.

Durch das Poolen (Zusammenfassen) von Ressourcen werden die folgenden Effekte erzielt:– Effizientere Nutzung z.B. der Hardware– Managed SLAs – etwa über Pools mit

unterschiedlicher Priorität und Leistung

Durch Ressource-Pooling ist es nicht nur möglich die vorhandene Infrastruktur besser auszunutzen, sondern die Betriebskosten lassen sich auch besser auf Kunden verteilen und kostenoptimiert nutzen.

Die Zusammenfassung und gemeinsame Nutzung der verfügbaren Infrastruktur

(Ressource-Pooling), ist ein Schlüssel-Konzept zur optimalen

Nutzung einer Menge an verfügbarer Ressourcen.

Pool Compute Ressources

Virtualisierung bezeichnet die Abstraktion der Hardware-Komponenten in logische Einheiten.

Diese logischen Einheiten können verfügbare Ressourcen gemeinsam nutzen und erreichen somit eine deutliche bessere Ausnutzung.

Virtualisierte Komponenten können außerdem zwischen verschiedenen physischen Komponenten verschoben werden und ermöglichen damit eine ausfallsichere Wartung der Hardware.

Virtualisierung ist eines der Schlüsselkonzepte für Cloud-Services um Verfügbarkeit und kosteneffiziente Bereitstellung zu gewährleisten.

Früher wurde Virtualisierung gleichgesetzt mit Hardware-Virtualisierung, die CSP setzt dagegen konsequent auf Ressourcen-Virtualisierung. Dienste werden in Containern betrieben und diese können durchaus auch auf Hardware direkt betrieben werden.

Virtualisierte Runtime

Virtualisierung alleine reicht nicht, um den

Anforderungen an eine Cloud-Computing

Umgebung gerecht zu werden – zusätzlich bedarf

es noch eines Fabric Managements...

Fabric-Management entkoppelt angebotene Dienste von spezifischen Hypervisoren und ist damit eine weitere Abstraktions-Ebene oberhalb der Virtualisierung.

Das Fabric Management kennt Zusammenhänge und Abhängigkeiten von Komponenten untereinander.

Mittels Fabric-Management können Dienste auf einer virtualisierten Umgebung orchestriert und (z.B. last- oder wartungsgesteuert) verteilt werden.

Unter der Fabric (engl. Gewebe) versteht man die

Zusammenfassung von Rechnern, Netzwerk und Storage in eine

Computing-Domäne

Fabric Management

Durch die Kenntnis der Abhängigkeiten untereinander können Auswirkungen auf andere Komponenten erkannt werden.

Dies ermöglicht z.B. Entscheidungen zu Service-Verlagerungen, starten weiterer virtueller Maschinen oder Storage-Erweiterungen, um einem Ausfall vorzubeugen.

Eine notwendige Voraussetzung hierzu sind automatisierte Vorgänge und eine vereinheitlichte (homogene) Infrastruktur (siehe vorherige Slides).

Das Fabric Management kennt die Beziehungen und Abhängigkeiten

einzelner Komponenten untereinander

Fabric Management

Gemeinsame Nutzung ist das Schlüsselkonzept für eine optimierte Auslastung vorhandener Ressourcen.

Durch verschiedene Auslastungsprofile und Nutzer, kann eine vorhandene Infrastruktur optimal genutzt werden.

Trotzdem gibt es gesetzliche Regelungen, Geschäftsinteressen (oder andere interne Treiber), sowie eine Vielzahl anderer Anforderungen, welche eine Partitionierung der Ressourcen auf unterschiedlichen Ebenen der Anwendungs- und Infrastrukturlandschaft erwarten oder voraussetzen.

Entsprechend können Partitions-Strategien auf verschiedenen Ebenen angesiedelt sein, wobei immer gilt: „je weiter unten im Stack die Partitionierung angesiedelt ist, desto kostenintensiver (etwa durch redundante Hardware) ist zumeist ihre Durchsetzung“.

Die Geschäftsstrategie und hier vor allem das Kundensegment sowie deren Anforderungen an einen Cloud-Service Provider, bestimmen maßgeblich, die Partitionierungs-Strategie und damit deren technische Umsetzung.

Partitionierung gemeinsam genutzter Ressourcen

Partitionierung ist ein Schlüsselkonzept im Bereich von Cloud-Services, konkurriert aber immer mit dem Ressourcen-Sharing

Traditionell wurde Hardware nach einem Incident-Modell gewartet, bei dem Komponenten repariert oder ausgetauscht wurden, sobald ein Fehler vorlag.

Mit Ressourcen-Pools kann die Infrastruktur in ein Maintenance-Modell gebracht werden, bei dem Komponenten in Intervallen auszutauschen sind.

Ein gewisser Prozentsatz der Hardware kann dabei ausfallen, ohne dass Dienste in Mitleidenschaft gezogen und deshalb Incidents zum direktem Austausch ausgelöst werden.

Ausgefallene Komponenten werden in regelmäßigen Abständen, oder wenn der Ressourcen-Pool einen definierten Grad der Abwertung (engl. Decay) erreicht hat, ausgetauscht.

Service-Decay (Abwertung von Diensten in einem Ressourcen-Pools) ist eine Kennzahl für den Aufbau eines Wartungsplans

Ressource Decay

Notwendig ist die Definition des Grades der Abwertung, den man gewillt ist zu akzeptieren.

Durch ein Wartungsmodell können die Instand-haltungskosten der Cloud-Plattform reduziert werden, da es nicht zu plötzlich auftretenden Neuanschaffungen kommt.

Beispiel: Ein Provider mit einem Ressourcen-Pool von

100 Servern berechnet, dass ein Ausfall von 3% der Server ohne Service-Einschränkung einhergeht.

Nach dem Ausfall der ersten zwei Server wird eine entsprechende Notification ausgelöst.

Erst der Ausfall des 3 Servers startet einen Procurement- und Maintenance-Prozess.

Infrastruktur-Ressourcen als einen gemeinsamen Ressourcen-Pool zu behandeln, erlaubt es der Plattform,

einzelne Hardware-Ausfälle ohne nennenswerte Leistungseinbußen

zu verkraften.

Optimiertes Wartungsmodell

Service Klassifizierung ist ein wichtiges Konzept, um die Vorhersagbarkeit der Cloud-Plattform zu verbessern und gewünschtes Verhalten der Anwender zu fördern.

Wird ein Service mit verschiedenen Komponenten implementiert, können diese auf unterschiedlichen Klassen von Ressource Pools* bereitgestellt werden.

Hierdurch ergibt sich eine Klassifizierung (etwa vergleichbar mit einem SLA), welche im Service Katalog hinterlegt wird.

So kann ein Prozess durch mehrere vergleichbare Services bereitgestellt werden. Durch die unterschiedlichen Ressource-Pools und Implementierungen der Einzelkomponenten ergeben sich Unterschieden, etwa in der garantierten Verfügbarkeit, der erreichbaren Performance oder Flexibilität, welche sich wiederum im Preis niederschlagen.

Service Klassifizierung gibt dem Endanwender die Möglichkeit, anhand von Kriterien zu entscheiden welche Implementierungen eines Service, zu welchem Preis er beziehen will.

Als Service Provider eröffnet uns die Service Klassifizierung einen Standarisierten Weg zur Bereitstellung und Entwicklung von Prozessen und Diensten, was sich positiv auf Komplexität und Kosten auswirkt.

Service Klassifizierung

* Siehe Pool Compute Ressources

Die Sicherheit des Cloud-Angebotes basiert auf 4 Stützpfeilern:1. Abgesicherte Infrastruktur 2. Zugriff auf die Anwendungen und Dienste 3. Netzwerkabsicherung und Netzwerkzugang4. Identitätsmanagement

Alle Aktivitäten, sowohl durch interne Mitarbeiter, als auch durch externe (Partner und Kunden), müssen mit einer Identität verknüpft sein.

Hierzu ist es unabdingbar, dass auf allen Ebene Identitäten und Rechte geprüft werden.

Dies alles muss sowohl aus dem eigenen Netz, dem Internet und vor allem bei direkter Kopplung von Dritt-Firmennetzen sichergestellt sein.

Sicherheits- und Identitäts-Management sind die Eckpfeiler für einen langfristigen geschäftlichen

Erfolg eines Cloud-Service Angebots und erfordern viel

Konzeptionsarbeit, sowie kontinuierliche Prüfung

Sicherheit und Identitäts-Management

Multitenancy bezeichnet die Möglichkeit eine Infrastruktur, einen Service oder eine Anwendung, logisch in voneinander unabhängige Einheiten zu unterteilen und verschiedenen Business Units oder Kunden zur Verfügung zu stellen.

Um Services optimal am Markt anbieten zu können, ist Multitenancy ein wichtiges Konzept, zur Erreichung einer konkurrenzfähigen Kostenstruktur.

Überlegungen zu Multitenancy sollten in allen Phasen des Service-Aufbaus (also bei der Infrastruktur, der Plattform, dem Design und der Entwicklung) eingebracht werden.

Multitenancy

Infrastructure Design Patterns

Die Infrastruktur der Cloud Service Plattform wird entlang der folgenden Entwurfsmuster konzipiert:

1. Ressource Pooling2. Physikalische Fault Domain3. Upgrade Domain4. Reserve Capacity5. Skalierende Einheiten (Scale Units)6. Kapazitätsplanung7. Health Model

Entwurfsmuster sind bewährte Lösungsschablonen für

wiederkehrende Entwurfsprobleme.

Infrastructure Design Patterns

Ressource Pooling bezeichnet die Zusammenfassung verschiedener Infrastruktur-Komponenten zu einem logischen System in dem etwa eine Anwendung ausgeführt wird.

Zusammengefasst werden können dabei sowohl einzelne Elemente (wie CPU, RAM und Disk I/O) als auch Servereinheiten.

Ressource Pooling

Problem: Werden dedizierte Infrastruktur-Ressourcen für jeden einzelnen Service genutzt, sind

deren Kapazitäten in aller Regel nicht optimal ausgenutzt. Diese "underutilization" führt zu unnötig hohen Kosten, sowohl für den Anbieter, als

auch für den Kunden.

Lösung: Zusammenführen von Infrastruktur-Ressourcen in Ressource-Pools, um durch

gemeinsame Nutzung der Kapazität, eine bessere Auslastung der einzelnen Komponenten zu erreichen.

Um unterschiedliche Anforderungen an Ressourcen erfüllen zu können, etwa Sicherheit, Verfügbarkeit, Performance oder Konsistenz, kann es notwendig sein, verschiedene Ressource-Pools bereitzustellen.

Ebenfalls kann die unterschiedliche Nutzungsart einzelner Komponenten (wie etwa Netzwerk, CPU/RAM oder Storage), zu weiteren Ressourcen-Pools führen.

Die resultierende Entkopplung der Ressourcen ist notwendig und wünschenswert und reflektiert die Wirklichkeit der Service-Nutzung.

Ressource Pooling

Verschiedene Service-Class Partitionen werden üblicherweise Aufgrund unterschiedlicher Anforderungen, etwa hinsichtlich Sicherheit, Performance oder Verfügbarkeit, definiert.

Auch die Anforderung nach dedizierten Umgebungen, z.B. für spezielle Kunden, oder Organisationseinheiten, kann ein Grund für Service-Class Partitionen sein.

Sehr häufig werden für solche Service-Class Partitionen dann dedizierte Ressource-Pools bereitgestellt.

Ein Beispiel für dedizierte Ressource Pools für Service-Class Partitionen sind Unterschiede in der per SLA garantierten Verfügbarkeit. So kann ein Pool, aufgrund von Infrastruktur und Betriebskomponenten eine Verfügbarkeit von 99,99% garantieren, wohingegen ein anderer Pool eine geringere Verfügbarkeit garantiert.

Die Unterscheidung wird sich üblicherweise auch im Preis der Nutzung wiederspiegeln und stellt damit ein Instrument zur kosteneffizienten Nutzung der Cloud Plattform dar.

Es muss bei der Entwicklung und Bereitstellung einer Anwendung also auch darauf geachtet werden, welche Service-Klasse diese benötigt. Diese Klassifikation wird in der Konfiguration der Anwendung hinterlegt und schränkt den Betrieb auf dafür geeigneten Pools ein.

Ressource Pooling – Service Class Partitions

Korrekte Deployments und automatische Failover-Operation (etwa bei Ausfall der Hardware unter einer virtuellen Maschine) sind davon abhängig, dass das Systems-Management Tool über die Fähigkeiten der zugrundeliegenden Infrastruktur "bescheid weiß".

Ohne dieses Wissen kann es passieren, dass virtuelle Maschinen auf System verschoben werden, die dafür nicht ausgelegt sind und der Provisionierungs-Prozess gestört wird.

Ressource-Pools definieren die Kapazität von Betriebsumgebungen und ermöglichen damit sowohl automatisierte Provisionierung, als auch

System Management Tools benötigen definierte Grenzen, um

korrekt zu funktionieren.

Ressource Pooling – Systems Management Partitions

Um Kapazitäts-Management korrekt zu betreiben ist es notwendig, die verfügbaren Ressourcen einer Betriebsumgebung genau zu kennen.

Für ein Rechenzentrum kann z.B. in einen Ressource Pool die verfügbare Storagekapazität, die Rechenleistung und Netzwerk-Ressourcen zusammengefasst werden.

Mittels solcher Pools können dann Kapazitäten, basierend auf Kosten, SLAs etc., verteilt werdenVisualisierung verfügbarer

Kapazitäten, sowie deren Nutzung über Zeit

Ressource Pooling – Capacity Management Partitions

Computing Domains sind physisch Infrastruktur-Umgebungen. Sie bieten alle Komponenten zur Ausführung von Diensten und Anwendungen. Die wichtigsten Computing Domains sind die Fault- und die Upgrade Domain.

Computing Domains

Problem: Häufig fallen ganze Gruppen von Servern, aufgrund des Ausfalls einer gemeinsamer Ressource

wie Netzwerk-Switch o.ä., aus. Dies führt zu einer Reduzierung der Service-Qualität, oder sogar zum Ausfall ganzer Services,

wenn das Design der Cloud-Plattform dies nicht mit einbezieht.

Lösung: Um den Ausfall ganzer Servergruppen und aller drauf laufender Dienste abzusichern, sind

physikalische Fault-Domains, bereitzustellen. Diese können im Fehlerfall Dienste übernehmen, um die Verfügbarkeit der Dienste der Cloud-

Plattform weiter zu gewährleisten. Ein einzelnes Rechenzentrum ist je nach Ausstattung und Architektur der Anwendungen in der

Lage den Ausfall eines oder mehrerer Server abzusichern. Um den Ausfall gemeinsam genutzter Ressourcen (wie Netzwerk, Internetanbindung oder

Stromversorgung) ebenfalls abzusichern, muss das RZ all diese Komponenten redundant und über verschiedene Technologien bereitstellen.

Größere Ausfallszenarien oder Katastrophenfälle lassen sich aber auch bei einem mit mehrfach redundanten Systemen konzipierten RZ nicht überbrücken, so dass es physikalische Fault-Domains geben muss.

Physikalische Fault Domain

Problem: Jede Hardware-Komponente ist einmal am Ende ihres Lebenszyklus angelangt, oder wird zu

klein und muss aufgerüstet werden. Upgrades können zu einer Reduzierung des Service Levels oder zu Service-Qualität führen, wenn das Cloud-Plattform Design keine geeigneten Mechanismen bereithält.

Lösung: Eine geeignete Gegenmaßnahme, um im Falle von Upgrades keine Performance-,

Verfügbarkeits- oder Qualitätseinbußen zu erleiden, ist eine Upgrade-Domain. Werden Ressource-Pools zu groß ausgelegt, etwa, wenn es ausschließlich eine Pool gibt, der

das gesamte Rechenzentrum beinhaltet, ist keine differenzierte Bewegung von Ressourcen im Falle eines größeren Updates möglich.

Deshalb sollten kleinere Pools definiert und diese für Upgrade-Szenarien genutzt werden.

Ein optimaler Upgrade mit Ressource-Pools und Upgrade Domain verläuft nach folgendem Schema:1. Verschieben der Laufzeitumgebung des betroffenen Ressource-Pools in die Upgrade

Domain2. Update der Hardware/Software3. Evtl. Neuinstallation aller Basiskomponenten4. Aktualisierte Umgebung wieder als Laufzeitumgebung des Ressource-Pools zuweisen

Upgrade Domain

Problem: Wenn Komponenten ausfallen, einem Upgrade unterzogen werden, oder es zu anderen

Szenarien aus dem Bereich der Ressourcen-Abwertung kommt, hat dies negative Auswirkungen auf die Service-Qualität – z.B. Performance, Lastverträglichkeit oder Storage-Kapazität.

Lösung:  Die Infrastruktur sollte über genügend Kapazitätsreserven verfügen, um Auswirkungen auf

Performance oder Lastverträglichkeit durch Hardware-Ausfälle zu vermeiden, oder zumindest zu minimieren.

Der Vorteil einer Betriebsumgebung, welche nach den Konzepten der Homogenität und mit Ressource-Pools aufgebaut wurde, ist, dass die Services auf jedem verfügbaren virtualisierten Server betrieben werden können. Hierdurch sind Verteilung und Lastausgleich einfach und effizient umsetzbar.

Reserve Capacity

Um die Reservekapazität zu berechnen, wird das Entwurfsmuster des Ressource-Decay mit dem Ansatz der physikalischen Fault-Domain, sowie der Upgrade-Domain kombiniert um näherungsweise die benötigte Kapazität, nach dem folgenden Schema zu antizipieren:

TOTALSERVERS = Anzahl an Servern im PoolServersInFD = Anzahl der Server in der Fault Domain ServersInUD = Anzahl der Server in einer Upgrade Domain ServersInDecay = Max Anzahl "abgewerter" Server, bevor ein Austausch notwendig wird.

Reserve capacity = ServersInFD + ServersInUD + ServersInDecay/TOTALSERVERS

Dem Ansatz liegt die Annahme zu Grunde, dass nur eine Domain zu einem gegebenen Zeitpunkt ausfällt.

Soll der Ausfall von mehr als einer Domain abgefedert werden, ist entsprechend mehr Reservekapazität vorzusehen. Selbstverständlich bedeutet dies auch mehr ungenutzte Kapazität im Normalbetrieb.

Berechnung der Reservekapazität

Scale Units sind Einheiten zur (dynamischen) Erweiterung der Kapazität der Plattform. Skaliert werden kann horizontal (etwa durch hinzufügen weiterer Computing Units) oder vertikal (etwa durch Vergrößerung der Kapazität einer VM).

Scale Units

Problem: Zur Inbetriebnahme von Infrastrukturkomponenten, wie Servern, Storage- oder

Netzwerksystemen, müssen diese beschafft, installiert und konfiguriert und in die bestehende Landschaft integriert werden. Dies benötigt Zeit und bindet Ressourcen, welche in dieser Zeit keine nennenswerten anderen Tätigkeiten ausführen können.

Lösung: Um den Mehraufwand, durch die Inbetriebnahme neuer Komponenten zu reduzieren, können

vorkonfigurierte Infrastrukturkomponenten gekauft werden. Noch effizienter ist es, wenn Kapazitätserweiterung (Skalierung) in den Einheiten schon

vorgesehen ist – wie z.B. bei Bladesystemen. Im Betrieb einer jeden Plattform kommt er Zeitpunkt, an dem die genutzte Kapaztät gleich der

verfügbaren (evtl. noch minus der Reserverkapazität) ist und neue Kapazität bereitgestellt werden muss.

Um in diesem Szenario agil, schnell und mit minimalen Kostendruck agieren zu können, ist die Beschaffung vorkonfigurierter Cloud Infrastruktur Einheiten ein erster Schritt.

Solche Kapazitätserweiterungen sollten außerdem in vorberechneten Quantitäten (oder Paketen) erfolgen, um den Aufwand zur Einrichtung (Aufbau Rack, Einschub Server, Verkabelung etc.) zielgerichtet und damit optimiert zu verteilen.

Die Pakete, in denen die Kapazität einer Infrastruktur erweitert wird, wird Scale Unit genannt.

Scale Unit zur Kapazitätserweiterung

Problem: Irgendwann wird jede Plattform an ihre Kapazitätsgrenzen stoßen, wodurch es zu

Performanceproblemen oder Ausfall der Dienste kommt.

Lösung:  Definieren Sie einen Kapazitätsplan, der die Elemente Forecast (also geplante

Kapazitätsentwicklung) und die Zeit für Einkauf- und Bereitstellung neuer Komponenten vereint. Der Plan sollte in regelmäßigen Abständen, oder bei Einbringung neuer Kunden/Services

überprüft und ggf. aktualisiert werden. Der Kapazitätsplan muss dabei sowohl die derzeitig verfügbare, als auch, durch Angebots- oder

Nachfrageerweiterung veränderte Reserve- oder Upgradekapazität (siehe Reserve Capacity und Upgrade Domain) mit einbeziehen.

Anhand dieses Plans kann die Kapazität der Cloud Services Infrastruktur erweitert werden, ohne dass es zu Serviceausfällen kommt.

Ein Kapazitätsplan ist ein wichtiges Element, um der Erwartung nach unendlicher Kapazität zu entsprechen.

Ohne ein hohes Maß an Automatisierung und detaillierte Überwachung der Umgebung, kann ein Kapazitätsplan nicht funktionieren, weshalb diese Paradigmen und Konzepte unabdingbar sind.

Kapazitätsplanung

Problem: Fällt eine Komponente aus, so kann dies zu Performanceproblemen oder Ausfällen der davon

abhängigen Services führen.

Lösung: Definition eines Health Modells für jeden Service. Dieses Modell enthält alle Komponenten und

Dienste von denen ein Service abhängig ist, sowie für jeden Fehlerfall, die entsprechenden Aktivitäten, zur Wiederherstellung der Servicebereitschaft.

Service Management Tools müssen also die Abhängigkeiten zwischen Diensten untereinander und von Diensten zu Komponenten kennen und verstehen, um aus einem Fehlerevent (etwa Ausfall) eine entsprechende Action (etwa Serviceumzug) ableiten zu können.

Zur Erlangung dieses Einblicks in Bezug auf einen Service oder eine Anwendung dient auch das Dependency.-Manifest (siehe Dokument zu Software Architektur Guidelines – Abschnitt Abhängigkeiten).

Im weiteren Sinne basiert die automatisierte Bereitstellung von Services auf der Cloud Plattform, etwa durch den Fabric Manager, auf dem Health Modell und wird üblicherweise auch in dessen Umgebung detailliert aufgebaut.

Health Model

Die Umsetzung der vorgestellten Konzepte und Design Patterns wird in der Präsentation zur CSP Plattform Infrastruktur dargestellt.

Umsetzung der Konzepte

Christian GüntherPrincipal Solution Architect

Mobile: +49 1511 22 40 942E-Mail: christian.guenther@comlineag.de

COMLINE Computer und Softwarelösungen AG

Leverkusenstr. 54

DE - 22761 Hamburg

www.comlineag.de

Vielen Dank für Ihre Aufmerksamkeit.