SlideShare ist ein Scribd-Unternehmen logo
COMLINE Cloud Services
Computing & Infrastructure Concepts
Christian Günther
Hannover, 09.12.2016
Die COMLINE AG präsentiert
Computing Concepts
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
 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 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
 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 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
 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 werden
Visualisierung 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 Domain
2. Update der Hardware/Software
3. Evtl. Neuinstallation aller Basiskomponenten
4. 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 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
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ü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.

Weitere ähnliche Inhalte

Andere mochten auch

Comment rédiger pour le web Yann Béguin
Comment rédiger pour le web Yann BéguinComment rédiger pour le web Yann Béguin
Comment rédiger pour le web Yann Béguin
ACPcef
 
Rendre accessible au mobile son application
Rendre accessible au mobile son applicationRendre accessible au mobile son application
Rendre accessible au mobile son applicationACPcef
 
234 978 952-232-144-2
234 978 952-232-144-2234 978 952-232-144-2
234 978 952-232-144-2
Dr Lendy Spires
 
TFF 2015, Marius Donhauser, hotelkit, "Hotelorganisation 2.0"
TFF 2015, Marius Donhauser, hotelkit, "Hotelorganisation 2.0"TFF 2015, Marius Donhauser, hotelkit, "Hotelorganisation 2.0"
TFF 2015, Marius Donhauser, hotelkit, "Hotelorganisation 2.0"
TourismFastForward
 
Lectura digitales3
Lectura digitales3Lectura digitales3
Lectura digitales3
Luis Gutiérrez
 
3 Tipps in 30 Minuten für mehr Umsatz und Gewinn
3 Tipps in 30 Minuten für mehr Umsatz und Gewinn3 Tipps in 30 Minuten für mehr Umsatz und Gewinn
3 Tipps in 30 Minuten für mehr Umsatz und Gewinn
Ralf Schmitz
 
Lecture de l'espace colonial à travers les ressources non normatives
Lecture de l'espace colonial à travers les ressources non normativesLecture de l'espace colonial à travers les ressources non normatives
Lecture de l'espace colonial à travers les ressources non normatives
Nabil RC
 
Quels Designs pour quel les lectures au 21e siècle ?
Quels Designs pour quel les lectures au 21e siècle ? Quels Designs pour quel les lectures au 21e siècle ?
Quels Designs pour quel les lectures au 21e siècle ?
Jeremy Fassio
 
Fontwork i taules
Fontwork i taulesFontwork i taules
Fontwork i taules
Antoni Maria Badia Ollé
 
????
????????
????
DeDe69100
 
DUBAI IN EINEM WORT: WOW!
DUBAI IN EINEM WORT: WOW!DUBAI IN EINEM WORT: WOW!
DUBAI IN EINEM WORT: WOW!
JT Touristik
 
Résultats Samoëns
Résultats SamoënsRésultats Samoëns
Résultats Samoëns
cnrnatation
 
Què ha suposat participar en la comunitat de pràctica? M.Angel Calejero
Què ha suposat participar en la comunitat de pràctica? M.Angel CalejeroQuè ha suposat participar en la comunitat de pràctica? M.Angel Calejero
Què ha suposat participar en la comunitat de pràctica? M.Angel Calejero
Departament de Justícia. Generalitat de Catalunya.
 
Guia del gestor d'aprenentatge en el lloc de treball (REGAL). Glòria Diaz
Guia del gestor d'aprenentatge en el lloc de treball (REGAL). Glòria DiazGuia del gestor d'aprenentatge en el lloc de treball (REGAL). Glòria Diaz
Guia del gestor d'aprenentatge en el lloc de treball (REGAL). Glòria Diaz
Departament de Justícia. Generalitat de Catalunya.
 
Aprenentatge informal i en el lloc de treball. Joan Galeano
Aprenentatge informal i en el lloc de treball. Joan GaleanoAprenentatge informal i en el lloc de treball. Joan Galeano
Aprenentatge informal i en el lloc de treball. Joan Galeano
Departament de Justícia. Generalitat de Catalunya.
 
Catalogue-formation-continue-chimie-materiaux-polymeres-metaux-composites-for...
Catalogue-formation-continue-chimie-materiaux-polymeres-metaux-composites-for...Catalogue-formation-continue-chimie-materiaux-polymeres-metaux-composites-for...
Catalogue-formation-continue-chimie-materiaux-polymeres-metaux-composites-for...Patrick CANCOU
 
Climcor cyber-carotheque-v1 resomar-2014
Climcor cyber-carotheque-v1 resomar-2014Climcor cyber-carotheque-v1 resomar-2014
Climcor cyber-carotheque-v1 resomar-2014cecileedytem
 

Andere mochten auch (20)

Mon métier
Mon métierMon métier
Mon métier
 
Comment rédiger pour le web Yann Béguin
Comment rédiger pour le web Yann BéguinComment rédiger pour le web Yann Béguin
Comment rédiger pour le web Yann Béguin
 
Rendre accessible au mobile son application
Rendre accessible au mobile son applicationRendre accessible au mobile son application
Rendre accessible au mobile son application
 
234 978 952-232-144-2
234 978 952-232-144-2234 978 952-232-144-2
234 978 952-232-144-2
 
TFF 2015, Marius Donhauser, hotelkit, "Hotelorganisation 2.0"
TFF 2015, Marius Donhauser, hotelkit, "Hotelorganisation 2.0"TFF 2015, Marius Donhauser, hotelkit, "Hotelorganisation 2.0"
TFF 2015, Marius Donhauser, hotelkit, "Hotelorganisation 2.0"
 
Lectura digitales3
Lectura digitales3Lectura digitales3
Lectura digitales3
 
3 Tipps in 30 Minuten für mehr Umsatz und Gewinn
3 Tipps in 30 Minuten für mehr Umsatz und Gewinn3 Tipps in 30 Minuten für mehr Umsatz und Gewinn
3 Tipps in 30 Minuten für mehr Umsatz und Gewinn
 
Lecture de l'espace colonial à travers les ressources non normatives
Lecture de l'espace colonial à travers les ressources non normativesLecture de l'espace colonial à travers les ressources non normatives
Lecture de l'espace colonial à travers les ressources non normatives
 
Quels Designs pour quel les lectures au 21e siècle ?
Quels Designs pour quel les lectures au 21e siècle ? Quels Designs pour quel les lectures au 21e siècle ?
Quels Designs pour quel les lectures au 21e siècle ?
 
Fontwork i taules
Fontwork i taulesFontwork i taules
Fontwork i taules
 
????
????????
????
 
DUBAI IN EINEM WORT: WOW!
DUBAI IN EINEM WORT: WOW!DUBAI IN EINEM WORT: WOW!
DUBAI IN EINEM WORT: WOW!
 
Résultats Samoëns
Résultats SamoënsRésultats Samoëns
Résultats Samoëns
 
Ernährungssoziologie
ErnährungssoziologieErnährungssoziologie
Ernährungssoziologie
 
Tourismus2020 toedt final
Tourismus2020 toedt finalTourismus2020 toedt final
Tourismus2020 toedt final
 
Què ha suposat participar en la comunitat de pràctica? M.Angel Calejero
Què ha suposat participar en la comunitat de pràctica? M.Angel CalejeroQuè ha suposat participar en la comunitat de pràctica? M.Angel Calejero
Què ha suposat participar en la comunitat de pràctica? M.Angel Calejero
 
Guia del gestor d'aprenentatge en el lloc de treball (REGAL). Glòria Diaz
Guia del gestor d'aprenentatge en el lloc de treball (REGAL). Glòria DiazGuia del gestor d'aprenentatge en el lloc de treball (REGAL). Glòria Diaz
Guia del gestor d'aprenentatge en el lloc de treball (REGAL). Glòria Diaz
 
Aprenentatge informal i en el lloc de treball. Joan Galeano
Aprenentatge informal i en el lloc de treball. Joan GaleanoAprenentatge informal i en el lloc de treball. Joan Galeano
Aprenentatge informal i en el lloc de treball. Joan Galeano
 
Catalogue-formation-continue-chimie-materiaux-polymeres-metaux-composites-for...
Catalogue-formation-continue-chimie-materiaux-polymeres-metaux-composites-for...Catalogue-formation-continue-chimie-materiaux-polymeres-metaux-composites-for...
Catalogue-formation-continue-chimie-materiaux-polymeres-metaux-composites-for...
 
Climcor cyber-carotheque-v1 resomar-2014
Climcor cyber-carotheque-v1 resomar-2014Climcor cyber-carotheque-v1 resomar-2014
Climcor cyber-carotheque-v1 resomar-2014
 

Ähnlich wie 02 Computing Concepts der COMLINE Cloud Service Platform - CSP

00 Einleitung und Übersicht zur COMLINE Cloud Service Plattform - CSP
00 Einleitung und Übersicht zur COMLINE Cloud Service Plattform - CSP00 Einleitung und Übersicht zur COMLINE Cloud Service Plattform - CSP
00 Einleitung und Übersicht zur COMLINE Cloud Service Plattform - CSP
Christian Guenther
 
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSPSoftware Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
Christian Guenther
 
Cloud-native Apps 2.0
Cloud-native Apps 2.0Cloud-native Apps 2.0
Cloud-native Apps 2.0
QAware GmbH
 
Data Center Automation for the Cloud
Data Center Automation for the CloudData Center Automation for the Cloud
Data Center Automation for the Cloud
inovex GmbH
 
Private Cloud mit Open Source
Private Cloud mit Open SourcePrivate Cloud mit Open Source
Private Cloud mit Open Source
Daniel Schneller
 
Steinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen EvolutionSteinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen Evolution
QAware GmbH
 
The cloud 2011
The cloud 2011The cloud 2011
The cloud 2011
Sascha Oehl
 
Microservices und das Entity Control Boundary Pattern
Microservices und das Entity Control Boundary PatternMicroservices und das Entity Control Boundary Pattern
Microservices und das Entity Control Boundary Pattern
Brockhaus Consulting GmbH
 
Fujitsu Storage Days 2017 - René Hübel: "Software Defined Storage – Über sieb...
Fujitsu Storage Days 2017 - René Hübel: "Software Defined Storage – Über sieb...Fujitsu Storage Days 2017 - René Hübel: "Software Defined Storage – Über sieb...
Fujitsu Storage Days 2017 - René Hübel: "Software Defined Storage – Über sieb...
Fujitsu Central Europe
 
Virtozzo Datasheet A4 De 170209
Virtozzo Datasheet A4 De 170209Virtozzo Datasheet A4 De 170209
Virtozzo Datasheet A4 De 170209guestcae1d
 
Cloud ms0.9
Cloud ms0.9Cloud ms0.9
Cloud ms0.9
Tom Peruzzi
 
Architektur und Automation als Enabler für DevOps
Architektur und Automation als Enabler für DevOpsArchitektur und Automation als Enabler für DevOps
Architektur und Automation als Enabler für DevOps
matfsw
 
8 Tipps für eine Cloud Strategie – wie Unternehmen heute die Cloud einsetzen
8 Tipps für eine Cloud Strategie – wie Unternehmen heute die Cloud einsetzen8 Tipps für eine Cloud Strategie – wie Unternehmen heute die Cloud einsetzen
8 Tipps für eine Cloud Strategie – wie Unternehmen heute die Cloud einsetzen
AWS Germany
 
Mobiles und flexibles Arbeiten mit der CANCOM AHP Private Cloud
Mobiles und flexibles Arbeiten mit der CANCOM AHP Private CloudMobiles und flexibles Arbeiten mit der CANCOM AHP Private Cloud
Mobiles und flexibles Arbeiten mit der CANCOM AHP Private Cloud
CANCOM
 
Suse in der neuen Welt des Rechenzentrums - ein Beispiel
Suse in der neuen Welt des Rechenzentrums - ein BeispielSuse in der neuen Welt des Rechenzentrums - ein Beispiel
Suse in der neuen Welt des Rechenzentrums - ein Beispiel
ATIX AG
 
Event-Streaming in Echtzeit: Der MongoDB-Kafka-Connector in Action!
Event-Streaming in Echtzeit: Der MongoDB-Kafka-Connector in Action!Event-Streaming in Echtzeit: Der MongoDB-Kafka-Connector in Action!
Event-Streaming in Echtzeit: Der MongoDB-Kafka-Connector in Action!
confluent
 
ONE Konferenz: Cloud Computing
ONE Konferenz: Cloud ComputingONE Konferenz: Cloud Computing
ONE Konferenz: Cloud Computing
Netcetera
 
AWS Roadshow Herbst 2013 Partnervortrag Hamburg: Direktgruppe - Data Center o...
AWS Roadshow Herbst 2013 Partnervortrag Hamburg: Direktgruppe - Data Center o...AWS Roadshow Herbst 2013 Partnervortrag Hamburg: Direktgruppe - Data Center o...
AWS Roadshow Herbst 2013 Partnervortrag Hamburg: Direktgruppe - Data Center o...
AWS Germany
 
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
QAware GmbH
 

Ähnlich wie 02 Computing Concepts der COMLINE Cloud Service Platform - CSP (20)

00 Einleitung und Übersicht zur COMLINE Cloud Service Plattform - CSP
00 Einleitung und Übersicht zur COMLINE Cloud Service Plattform - CSP00 Einleitung und Übersicht zur COMLINE Cloud Service Plattform - CSP
00 Einleitung und Übersicht zur COMLINE Cloud Service Plattform - CSP
 
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSPSoftware Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
Software Architecture Design Patterns der COMLINE Cloud Service Platform - CSP
 
Cloud-native Apps 2.0
Cloud-native Apps 2.0Cloud-native Apps 2.0
Cloud-native Apps 2.0
 
Data Center Automation for the Cloud
Data Center Automation for the CloudData Center Automation for the Cloud
Data Center Automation for the Cloud
 
Private Cloud mit Open Source
Private Cloud mit Open SourcePrivate Cloud mit Open Source
Private Cloud mit Open Source
 
Steinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen EvolutionSteinzeit war gestern! Wege der cloud-nativen Evolution
Steinzeit war gestern! Wege der cloud-nativen Evolution
 
The cloud 2011
The cloud 2011The cloud 2011
The cloud 2011
 
Microservices und das Entity Control Boundary Pattern
Microservices und das Entity Control Boundary PatternMicroservices und das Entity Control Boundary Pattern
Microservices und das Entity Control Boundary Pattern
 
Big Data Appliances
Big Data AppliancesBig Data Appliances
Big Data Appliances
 
Fujitsu Storage Days 2017 - René Hübel: "Software Defined Storage – Über sieb...
Fujitsu Storage Days 2017 - René Hübel: "Software Defined Storage – Über sieb...Fujitsu Storage Days 2017 - René Hübel: "Software Defined Storage – Über sieb...
Fujitsu Storage Days 2017 - René Hübel: "Software Defined Storage – Über sieb...
 
Virtozzo Datasheet A4 De 170209
Virtozzo Datasheet A4 De 170209Virtozzo Datasheet A4 De 170209
Virtozzo Datasheet A4 De 170209
 
Cloud ms0.9
Cloud ms0.9Cloud ms0.9
Cloud ms0.9
 
Architektur und Automation als Enabler für DevOps
Architektur und Automation als Enabler für DevOpsArchitektur und Automation als Enabler für DevOps
Architektur und Automation als Enabler für DevOps
 
8 Tipps für eine Cloud Strategie – wie Unternehmen heute die Cloud einsetzen
8 Tipps für eine Cloud Strategie – wie Unternehmen heute die Cloud einsetzen8 Tipps für eine Cloud Strategie – wie Unternehmen heute die Cloud einsetzen
8 Tipps für eine Cloud Strategie – wie Unternehmen heute die Cloud einsetzen
 
Mobiles und flexibles Arbeiten mit der CANCOM AHP Private Cloud
Mobiles und flexibles Arbeiten mit der CANCOM AHP Private CloudMobiles und flexibles Arbeiten mit der CANCOM AHP Private Cloud
Mobiles und flexibles Arbeiten mit der CANCOM AHP Private Cloud
 
Suse in der neuen Welt des Rechenzentrums - ein Beispiel
Suse in der neuen Welt des Rechenzentrums - ein BeispielSuse in der neuen Welt des Rechenzentrums - ein Beispiel
Suse in der neuen Welt des Rechenzentrums - ein Beispiel
 
Event-Streaming in Echtzeit: Der MongoDB-Kafka-Connector in Action!
Event-Streaming in Echtzeit: Der MongoDB-Kafka-Connector in Action!Event-Streaming in Echtzeit: Der MongoDB-Kafka-Connector in Action!
Event-Streaming in Echtzeit: Der MongoDB-Kafka-Connector in Action!
 
ONE Konferenz: Cloud Computing
ONE Konferenz: Cloud ComputingONE Konferenz: Cloud Computing
ONE Konferenz: Cloud Computing
 
AWS Roadshow Herbst 2013 Partnervortrag Hamburg: Direktgruppe - Data Center o...
AWS Roadshow Herbst 2013 Partnervortrag Hamburg: Direktgruppe - Data Center o...AWS Roadshow Herbst 2013 Partnervortrag Hamburg: Direktgruppe - Data Center o...
AWS Roadshow Herbst 2013 Partnervortrag Hamburg: Direktgruppe - Data Center o...
 
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.Steinzeit war gestern! Wege der Cloud-nativen Evolution.
Steinzeit war gestern! Wege der Cloud-nativen Evolution.
 

02 Computing Concepts der COMLINE Cloud Service Platform - CSP

  • 1. COMLINE Cloud Services Computing & Infrastructure Concepts Christian Günther Hannover, 09.12.2016 Die COMLINE AG präsentiert
  • 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
  • 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.