Computing und Infrastructure Concepts für Cloud Entwicklungen Domain Principles für Cloud Services und Cloud Anwendungsentwicklung In den letzten zehn bis fünfzehn Jahren haben sich eine Reihe von Architekturparadigmen etabliert, die heute die Grundlage für Unternehmensanwendungen definieren und in vielfältigen Standards, Frameworks und Best Practices so fest verankert sind, dass man kaum noch darüber nachdenkt. Wendet man diese Paradigmen unreflektiert auf Cloud-Anwendungen an, führt das in der Regel zu ernüchternden Resultaten. Insbesondere die für Cloud Computing wichtigen Eigenschaften Skalierbarkeit, Elastizität und Robustheit sind auf diese Weise nicht erreichbar. Ein Umdenken ist also notwendig, um die Potenziale der Cloud freizusetzen. Die COMLINE Cloud Computing Platform (CSP) ist die Antwort hierauf, sie ist eine moderne Plattform für Cloud-Computing und wurde als reaktives System konzipiert. Reaktive Systeme müssen stets antwortbereit, widerstandsfähig, elastisch und nachrichtenorientiert sein. Systeme und Plattformen, die nach diesen Anforderungen entwickelt werden, erweisen sich als anpassungsfähiger, mit weniger starr gekoppelten Komponenten und in jeder Hinsicht skalierbarer. Sie sind einfacher weiterzuentwickeln und zu verändern. Sie reagieren zuverlässiger und eleganter auf Fehler und vermeiden so desaströse Ausfälle. Reaktive Systeme bereiten dem Anwender durch ihre fortwährende Antwortfreudigkeit eine interaktive und höchst befriedigende Erfahrung. All diese Anforderungen erfüllt die COMLINE Cloud Service Plattform. Aus Sicht der COMLINE eine PaaS (Platform as a Service) dar, auf der COMLINE Cloud-Dienste entwickelt. Betrieben wird die CSP auf einem IaaS Modell in COMLINE-eigenen Rechenzentren in Berlin Die Cloud-Dienste werden zu Anwendungen zusammengefasst, die von Kunden der COMLINE im Sinne eines SaaS (Software as a Service) Modells gemietet und genutzt werden können. Sowohl die Plattform selber, als auch die Services und Anwendungen werden entlang einer Reihe von Guidelines entwickelt und betrieben. Diese Guidelines bilden die Grundlage aller Aktivitäten (von Design, über Konzeption bis hin zu Entwicklung und Betrieb) auf der CSP Die Folien auf Slideshare zeigen die Prinzipien, Paradigmen und Design Patterns auf, nach denen wir sowohl die CSP selber betreiben, als auch die Anwendungen auf ihr entwickeln und betreiben. Die CSP wurde massgeblich von Christian Günther konzipiert und stellt heute die DeFacto Entwicklungsplattform für COMLINE dar.

1. COMLINE Cloud Services
Computing & Infrastructure Concepts
Christian Günther
Hannover, 09.12.2016
Die COMLINE AG präsentiert

2. Computing Concepts

3. 1. Elastizität statt Redundanz
2. Elastische Infrastruktur
3. Homogenität der physischen Plattform
4. Ressourcen-Pools
5. Virtualisierte Runtime
6. Fabric Management
7. Partitionierung der Shared Ressourcen
8. Ressource Decay
9. Service Klassifizierung
10.Sicherheit und Identitäts-Management
11.Multitenancy
Computing Concepts

4.  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

5.  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

6.  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

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

8.  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

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

10.  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

11.  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...

12.  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

13.  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

14.  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

15.  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

16.  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

17.  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

18. Die Sicherheit des Cloud-Angebotes basiert auf 4
Stützpfeilern:
1. Abgesicherte Infrastruktur
2. Zugriff auf die Anwendungen und Dienste
3. Netzwerkabsicherung und Netzwerkzugang
4. 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

19.  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

20. Infrastructure Design Patterns

21. Die Infrastruktur der Cloud Service Plattform
wird entlang der folgenden Entwurfsmuster
konzipiert:
1. Ressource Pooling
2. Physikalische Fault Domain
3. Upgrade Domain
4. Reserve Capacity
5. Skalierende Einheiten (Scale Units)
6. Kapazitätsplanung
7. Health Model
Entwurfsmuster sind bewährte
Lösungsschablonen für
wiederkehrende Entwurfsprobleme.
Infrastructure Design Patterns

22.  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

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

24.  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

25.  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

26.  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 werden
Visualisierung verfügbarer
Kapazitäten, sowie deren Nutzung
über Zeit
Ressource Pooling – Capacity Management Partitions

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

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

29. 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 Domain
2. Update der Hardware/Software
3. Evtl. Neuinstallation aller Basiskomponenten
4. Aktualisierte Umgebung wieder als Laufzeitumgebung des Ressource-Pools zuweisen
Upgrade Domain

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

31.  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 Pool
ServersInFD = 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

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

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

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

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

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

37. Christian Günther
Principal Solution Architect
Mobile: +49 1511 22 40 942
E-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.