COMLINE Cloud Services
Computing & Infrastructure Concepts
Christian Günther
Hannover, 09.12.2016
Die COMLINE AG präsentie...
Computing Concepts
1. Elastizität statt Redundanz
2. Elastische Infrastruktur
3. Homogenität der physischen Plattform
4. Ressourcen-Pools
5. ...
 Früher wurde Verfügbarkeit vor allem durch
Redundanzen, also das Vorhalten von
Backupsystemen, erreicht.
 Die Backupsys...
 Um die Anforderung, nach 100%iger Verfügbarkeit von Cloud-Diensten zu erfüllen
muss ein ganzheitlicher Ansatz gewählt we...
 In einer elastischen Infrastruktur können Ressourcen
bei Bedarf allokiert und, fast noch wichtiger, wieder an
den Ressou...
Homogenität (von ὁμός homόs „gleich“ und
γένεσις genesis „Erzeugung, Geburt“, also
etwa: gleiche Beschaffenheit) bezeichne...
 Die Vereinheitlichung der physikalischen und auch virtualisierten Infrastruktur ist eine
Schlüsselkomponente um die Vorh...
Unter Ressource Pooling versteht man die Zusammenfassung mehrerer, meist getrennter
Hardware-Komponenten zu einer logische...
 Beim Ressource-Pooling werden Komponenten
(wie CPU, RAM oder Storage) nicht von einer
Anwendung alleine, sondern (gesteu...
 Virtualisierung bezeichnet die Abstraktion der
Hardware-Komponenten in logische Einheiten.
 Diese logischen Einheiten k...
 Fabric-Management entkoppelt
angebotene Dienste von spezifischen
Hypervisoren und ist damit eine weitere
Abstraktions-Eb...
 Durch die Kenntnis der Abhängigkeiten
untereinander können Auswirkungen auf
andere Komponenten erkannt werden.
 Dies er...
 Gemeinsame Nutzung ist das Schlüsselkonzept für eine optimierte Auslastung
vorhandener Ressourcen.
 Durch verschiedene ...
 Traditionell wurde Hardware nach einem
Incident-Modell gewartet, bei dem Komponenten
repariert oder ausgetauscht wurden,...
 Notwendig ist die Definition des Grades der
Abwertung, den man gewillt ist zu akzeptieren.
 Durch ein Wartungsmodell kö...
 Service Klassifizierung ist ein wichtiges Konzept, um die Vorhersagbarkeit der Cloud-
Plattform zu verbessern und gewüns...
Die Sicherheit des Cloud-Angebotes basiert auf 4
Stützpfeilern:
1. Abgesicherte Infrastruktur
2. Zugriff auf die Anwendung...
 Multitenancy bezeichnet die Möglichkeit
eine Infrastruktur, einen Service oder eine
Anwendung, logisch in voneinander
un...
Infrastructure Design Patterns
Die Infrastruktur der Cloud Service Plattform
wird entlang der folgenden Entwurfsmuster
konzipiert:
1. Ressource Pooling
2...
 Ressource Pooling bezeichnet
die Zusammenfassung
verschiedener Infrastruktur-
Komponenten zu einem
logischen System in d...
Problem:
 Werden dedizierte Infrastruktur-Ressourcen für jeden einzelnen Service genutzt, sind
deren Kapazitäten in aller...
 Verschiedene Service-Class Partitionen werden üblicherweise Aufgrund
unterschiedlicher Anforderungen, etwa hinsichtlich ...
 Korrekte Deployments und automatische
Failover-Operation (etwa bei Ausfall der
Hardware unter einer virtuellen Maschine)...
 Um Kapazitäts-Management korrekt zu
betreiben ist es notwendig, die verfügbaren
Ressourcen einer Betriebsumgebung genau ...
Computing Domains sind physisch Infrastruktur-Umgebungen. Sie bieten alle
Komponenten zur Ausführung von Diensten und Anwe...
Problem:
 Häufig fallen ganze Gruppen von Servern, aufgrund des Ausfalls einer gemeinsamer Ressource
wie Netzwerk-Switch ...
Problem:
 Jede Hardware-Komponente ist einmal am Ende ihres Lebenszyklus angelangt, oder wird zu klein
und muss aufgerüst...
Problem:
 Wenn Komponenten ausfallen, einem Upgrade unterzogen werden, oder es zu anderen Szenarien
aus dem Bereich der R...
 Um die Reservekapazität zu berechnen, wird das Entwurfsmuster des Ressource-Decay mit dem
Ansatz der physikalischen Faul...
Scale Units sind Einheiten zur (dynamischen) Erweiterung der Kapazität der Plattform.
Skaliert werden kann horizontal (etw...
Problem:
 Zur Inbetriebnahme von Infrastrukturkomponenten, wie Servern, Storage- oder
Netzwerksystemen, müssen diese besc...
Problem:
 Irgendwann wird jede Plattform an ihre Kapazitätsgrenzen stoßen, wodurch es zu
Performanceproblemen oder Ausfal...
Problem:
 Fällt eine Komponente aus, so kann dies zu Performanceproblemen oder Ausfällen der davon
abhängigen Services fü...
Die Umsetzung der vorgestellten Konzepte und Design Patterns wird in der
Präsentation zur CSP Plattform Infrastruktur darg...
Christian Günther
Principal Solution Architect
Mobile: +49 1511 22 40 942
E-Mail: christian.guenther@comlineag.de
COMLINE ...
Nächste SlideShare
Wird geladen in …5
×

02 Computing Concepts der COMLINE Cloud Service Platform - CSP

161 Aufrufe

Veröffentlicht am

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.

Veröffentlicht in: Technologie
  • Gehören Sie zu den Ersten, denen das gefällt!

02 Computing Concepts der COMLINE Cloud Service Platform - CSP

  1. 1. COMLINE Cloud Services Computing & Infrastructure Concepts Christian Günther Hannover, 09.12.2016 Die COMLINE AG präsentiert
  2. 2. Computing Concepts
  3. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 20. Infrastructure Design Patterns
  21. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 36. Die Umsetzung der vorgestellten Konzepte und Design Patterns wird in der Präsentation zur CSP Plattform Infrastruktur dargestellt. Umsetzung der Konzepte
  37. 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.

×