View
117
Download
0
Category
Preview:
Citation preview
COMLINE Cloud ServicesComputing & Infrastructure Concepts
Christian GüntherHannover, 09.12.2016
Die COMLINE AG präsentiert
Computing Concepts
1. Elastizität statt Redundanz2. Elastische Infrastruktur3. Homogenität der physischen Plattform 4. Ressourcen-Pools5. Virtualisierte Runtime6. Fabric Management7. Partitionierung der Shared Ressourcen8. Ressource Decay9. Service Klassifizierung10.Sicherheit und Identitäts-Management11. Multitenancy
Computing Concepts
Früher wurde Verfügbarkeit vor allem durch Redundanzen, also das Vorhalten von Backupsystemen, erreicht.
Die Backupsysteme liefen in einem Stand-By-Betrieb mit und waren so konzipiert, dass sie, wenn das Hauptsystem ausfiel, dessen Arbeit übernehmen konnten.
Die von diesen Systemen bereitgestellte Rechenleistung konnte aber im produktiven Betrieb nicht genutzt werden.
Verfügbarkeit durch redundantes Bereitstellen von Infrastruktur ist entsprechend teuer und unflexibel.
Elastizität statt Redundanz – 1
Um die Anforderung, nach 100%iger Verfügbarkeit von Cloud-Diensten zu erfüllen muss ein ganzheitlicher Ansatz gewählt werden.
Statt der Bereitstellung redundanter Hardware ist es effektiver (und zumeist auch deutlich kostengünstiger), die gesamte Plattform (inklusive der Anwendungen) elastisch zu konzipieren – sie also in viele, voneinander unabhängig arbeitende Dienste, zu unterteilen.
Eine verteilte Architektur, z.B. auf Basis von unabhängigen Agenten, kann auf eine große Zahl kostengünstiger virtueller Knoten installiert werden. Fällt einer dieser Knoten aus, so übernehmen andere dessen Last, oder es können weitere Knoten schnell angefahren werden.
Außerdem können in einer verteilten, elastischen Architektur die Dienste problemlos über die Grenzen eines Rechenzentrums hinweg installiert werden, da die Partitionierung der Daten und Funktionen keine nachträglich einzubringende, sondern inhärente Eigenschaft des Systems ist.
Elastizität statt Redundanz – 2
In einer elastischen Infrastruktur können Ressourcen bei Bedarf allokiert und, fast noch wichtiger, wieder an den Ressource-Pool zurückgegeben werden.
Zugewiesene Kapazitäten auch wieder zurück-zunehmen ist ein wichtiger Baustein in der optimierten Auslastung der verfügbaren Hardware.
Auch das Prinzip gewünschtes Verhalten zu fördern, kann durch eine elastische Infrastruktur unterstützt werden – wenn das Abrechnungsmodell genutzte und wieder freigegebenen Ressourcen mit einbezieht.
Eine elastische Infrastruktur ist nur teilweise eine technische Gegebenheit, da deren effiziente Nutzung ganz direkt vom Verhalten der Anwender abhängt.
Hier ist eine enge Abstimmung zwischen Anbieter und Kunde notwendig, damit Auslastungsspitzen nicht dazu führen, dass unnötig große Kapazitäten dauerhaft (und damit kostenintensiv) vorgehalten werden.
Das Konzept der elastischen Infrastruktur erfüllt die Erwartung
nach unendlicher Kapazität
Elastische Infrastruktur
Homogenität (von ὁμός homόs „gleich“ und γένεσις genesis „Erzeugung, Geburt“, also etwa: gleiche Beschaffenheit) bezeichnet die Gleichheit einer physikalischen Eigenschaft über die gesamte Ausdehnung eines Systems oder auch die Gleichartigkeit von Elementen eines Systems.
Im Bereich der Infrastruktur bezieht sich Homogenität auf die Gleichartigkeit aller physischen Komponenten – also Server, Netzwerk- und Storagesysteme.
Homogene Infrastrukturen bieten eine Reihe von Vorteilen und erzeugen Skaleneffekte.
Homogenität der Infrastruktur-Plattform
Die Vereinheitlichung der physikalischen und auch virtualisierten Infrastruktur ist eine Schlüsselkomponente um die Vorhersagbarkeit des Gesamtsystems zu erreichen.
Das Antwort- und Lastverhalten lässt sich bei gleichartigen Komponenten einfacher für das Gesamtsystem ermitteln, als dies bei der Nutzung unterschiedlicher Systeme der Fall ist.
Durch die Nutzung gleichartiger Hardware- und Softwarekomponenten ergeben sich zusätzlich die folgenden positiven Eigenschaften– Kostengünstige Beschaffung durch größere Mengen
– Reduzierung der Komplexität
– Reduzierter Schulungsaufwand auf Seiten der Administratoren
– Vereinfachte/Beschleunigte Bereitstellung durch bekannte Verfahren
– Verbesserte und leichtere Automatisierung der operativen Prozesse
Homogenität der Infrastruktur-Plattform
Unter Ressource Pooling versteht man die Zusammenfassung mehrerer, meist getrennter Hardware-Komponenten zu einer logischen Einheit, um so etwa die Auslastung zu optimieren, die Kapazität zu erhöhen.
Ressource Pooling
Network 1
VLAN 1 VLAN n
Network n
VLAN 1 VLAN n
Compute Scale Unit 1 Compute Scale Unit n
SAN 1
Lun 1 Lun n
SAN n
Lun 1 Lun n Storage
Compute
Network
Ressourcen Pool
Beim Ressource-Pooling werden Komponenten (wie CPU, RAM oder Storage) nicht von einer Anwendung alleine, sondern (gesteuert) gemeinsam genutzt.
Durch das Poolen (Zusammenfassen) von Ressourcen werden die folgenden Effekte erzielt:– Effizientere Nutzung z.B. der Hardware– Managed SLAs – etwa über Pools mit
unterschiedlicher Priorität und Leistung
Durch Ressource-Pooling ist es nicht nur möglich die vorhandene Infrastruktur besser auszunutzen, sondern die Betriebskosten lassen sich auch besser auf Kunden verteilen und kostenoptimiert nutzen.
Die Zusammenfassung und gemeinsame Nutzung der verfügbaren Infrastruktur
(Ressource-Pooling), ist ein Schlüssel-Konzept zur optimalen
Nutzung einer Menge an verfügbarer Ressourcen.
Pool Compute Ressources
Virtualisierung bezeichnet die Abstraktion der Hardware-Komponenten in logische Einheiten.
Diese logischen Einheiten können verfügbare Ressourcen gemeinsam nutzen und erreichen somit eine deutliche bessere Ausnutzung.
Virtualisierte Komponenten können außerdem zwischen verschiedenen physischen Komponenten verschoben werden und ermöglichen damit eine ausfallsichere Wartung der Hardware.
Virtualisierung ist eines der Schlüsselkonzepte für Cloud-Services um Verfügbarkeit und kosteneffiziente Bereitstellung zu gewährleisten.
Früher wurde Virtualisierung gleichgesetzt mit Hardware-Virtualisierung, die CSP setzt dagegen konsequent auf Ressourcen-Virtualisierung. Dienste werden in Containern betrieben und diese können durchaus auch auf Hardware direkt betrieben werden.
Virtualisierte Runtime
Virtualisierung alleine reicht nicht, um den
Anforderungen an eine Cloud-Computing
Umgebung gerecht zu werden – zusätzlich bedarf
es noch eines Fabric Managements...
Fabric-Management entkoppelt angebotene Dienste von spezifischen Hypervisoren und ist damit eine weitere Abstraktions-Ebene oberhalb der Virtualisierung.
Das Fabric Management kennt Zusammenhänge und Abhängigkeiten von Komponenten untereinander.
Mittels Fabric-Management können Dienste auf einer virtualisierten Umgebung orchestriert und (z.B. last- oder wartungsgesteuert) verteilt werden.
Unter der Fabric (engl. Gewebe) versteht man die
Zusammenfassung von Rechnern, Netzwerk und Storage in eine
Computing-Domäne
Fabric Management
Durch die Kenntnis der Abhängigkeiten untereinander können Auswirkungen auf andere Komponenten erkannt werden.
Dies ermöglicht z.B. Entscheidungen zu Service-Verlagerungen, starten weiterer virtueller Maschinen oder Storage-Erweiterungen, um einem Ausfall vorzubeugen.
Eine notwendige Voraussetzung hierzu sind automatisierte Vorgänge und eine vereinheitlichte (homogene) Infrastruktur (siehe vorherige Slides).
Das Fabric Management kennt die Beziehungen und Abhängigkeiten
einzelner Komponenten untereinander
Fabric Management
Gemeinsame Nutzung ist das Schlüsselkonzept für eine optimierte Auslastung vorhandener Ressourcen.
Durch verschiedene Auslastungsprofile und Nutzer, kann eine vorhandene Infrastruktur optimal genutzt werden.
Trotzdem gibt es gesetzliche Regelungen, Geschäftsinteressen (oder andere interne Treiber), sowie eine Vielzahl anderer Anforderungen, welche eine Partitionierung der Ressourcen auf unterschiedlichen Ebenen der Anwendungs- und Infrastrukturlandschaft erwarten oder voraussetzen.
Entsprechend können Partitions-Strategien auf verschiedenen Ebenen angesiedelt sein, wobei immer gilt: „je weiter unten im Stack die Partitionierung angesiedelt ist, desto kostenintensiver (etwa durch redundante Hardware) ist zumeist ihre Durchsetzung“.
Die Geschäftsstrategie und hier vor allem das Kundensegment sowie deren Anforderungen an einen Cloud-Service Provider, bestimmen maßgeblich, die Partitionierungs-Strategie und damit deren technische Umsetzung.
Partitionierung gemeinsam genutzter Ressourcen
Partitionierung ist ein Schlüsselkonzept im Bereich von Cloud-Services, konkurriert aber immer mit dem Ressourcen-Sharing
Traditionell wurde Hardware nach einem Incident-Modell gewartet, bei dem Komponenten repariert oder ausgetauscht wurden, sobald ein Fehler vorlag.
Mit Ressourcen-Pools kann die Infrastruktur in ein Maintenance-Modell gebracht werden, bei dem Komponenten in Intervallen auszutauschen sind.
Ein gewisser Prozentsatz der Hardware kann dabei ausfallen, ohne dass Dienste in Mitleidenschaft gezogen und deshalb Incidents zum direktem Austausch ausgelöst werden.
Ausgefallene Komponenten werden in regelmäßigen Abständen, oder wenn der Ressourcen-Pool einen definierten Grad der Abwertung (engl. Decay) erreicht hat, ausgetauscht.
Service-Decay (Abwertung von Diensten in einem Ressourcen-Pools) ist eine Kennzahl für den Aufbau eines Wartungsplans
Ressource Decay
Notwendig ist die Definition des Grades der Abwertung, den man gewillt ist zu akzeptieren.
Durch ein Wartungsmodell können die Instand-haltungskosten der Cloud-Plattform reduziert werden, da es nicht zu plötzlich auftretenden Neuanschaffungen kommt.
Beispiel: Ein Provider mit einem Ressourcen-Pool von
100 Servern berechnet, dass ein Ausfall von 3% der Server ohne Service-Einschränkung einhergeht.
Nach dem Ausfall der ersten zwei Server wird eine entsprechende Notification ausgelöst.
Erst der Ausfall des 3 Servers startet einen Procurement- und Maintenance-Prozess.
Infrastruktur-Ressourcen als einen gemeinsamen Ressourcen-Pool zu behandeln, erlaubt es der Plattform,
einzelne Hardware-Ausfälle ohne nennenswerte Leistungseinbußen
zu verkraften.
Optimiertes Wartungsmodell
Service Klassifizierung ist ein wichtiges Konzept, um die Vorhersagbarkeit der Cloud-Plattform zu verbessern und gewünschtes Verhalten der Anwender zu fördern.
Wird ein Service mit verschiedenen Komponenten implementiert, können diese auf unterschiedlichen Klassen von Ressource Pools* bereitgestellt werden.
Hierdurch ergibt sich eine Klassifizierung (etwa vergleichbar mit einem SLA), welche im Service Katalog hinterlegt wird.
So kann ein Prozess durch mehrere vergleichbare Services bereitgestellt werden. Durch die unterschiedlichen Ressource-Pools und Implementierungen der Einzelkomponenten ergeben sich Unterschieden, etwa in der garantierten Verfügbarkeit, der erreichbaren Performance oder Flexibilität, welche sich wiederum im Preis niederschlagen.
Service Klassifizierung gibt dem Endanwender die Möglichkeit, anhand von Kriterien zu entscheiden welche Implementierungen eines Service, zu welchem Preis er beziehen will.
Als Service Provider eröffnet uns die Service Klassifizierung einen Standarisierten Weg zur Bereitstellung und Entwicklung von Prozessen und Diensten, was sich positiv auf Komplexität und Kosten auswirkt.
Service Klassifizierung
* Siehe Pool Compute Ressources
Die Sicherheit des Cloud-Angebotes basiert auf 4 Stützpfeilern:1. Abgesicherte Infrastruktur 2. Zugriff auf die Anwendungen und Dienste 3. Netzwerkabsicherung und Netzwerkzugang4. Identitätsmanagement
Alle Aktivitäten, sowohl durch interne Mitarbeiter, als auch durch externe (Partner und Kunden), müssen mit einer Identität verknüpft sein.
Hierzu ist es unabdingbar, dass auf allen Ebene Identitäten und Rechte geprüft werden.
Dies alles muss sowohl aus dem eigenen Netz, dem Internet und vor allem bei direkter Kopplung von Dritt-Firmennetzen sichergestellt sein.
Sicherheits- und Identitäts-Management sind die Eckpfeiler für einen langfristigen geschäftlichen
Erfolg eines Cloud-Service Angebots und erfordern viel
Konzeptionsarbeit, sowie kontinuierliche Prüfung
Sicherheit und Identitäts-Management
Multitenancy bezeichnet die Möglichkeit eine Infrastruktur, einen Service oder eine Anwendung, logisch in voneinander unabhängige Einheiten zu unterteilen und verschiedenen Business Units oder Kunden zur Verfügung zu stellen.
Um Services optimal am Markt anbieten zu können, ist Multitenancy ein wichtiges Konzept, zur Erreichung einer konkurrenzfähigen Kostenstruktur.
Überlegungen zu Multitenancy sollten in allen Phasen des Service-Aufbaus (also bei der Infrastruktur, der Plattform, dem Design und der Entwicklung) eingebracht werden.
Multitenancy
Infrastructure Design Patterns
Die Infrastruktur der Cloud Service Plattform wird entlang der folgenden Entwurfsmuster konzipiert:
1. Ressource Pooling2. Physikalische Fault Domain3. Upgrade Domain4. Reserve Capacity5. Skalierende Einheiten (Scale Units)6. Kapazitätsplanung7. Health Model
Entwurfsmuster sind bewährte Lösungsschablonen für
wiederkehrende Entwurfsprobleme.
Infrastructure Design Patterns
Ressource Pooling bezeichnet die Zusammenfassung verschiedener Infrastruktur-Komponenten zu einem logischen System in dem etwa eine Anwendung ausgeführt wird.
Zusammengefasst werden können dabei sowohl einzelne Elemente (wie CPU, RAM und Disk I/O) als auch Servereinheiten.
Ressource Pooling
Problem: Werden dedizierte Infrastruktur-Ressourcen für jeden einzelnen Service genutzt, sind
deren Kapazitäten in aller Regel nicht optimal ausgenutzt. Diese "underutilization" führt zu unnötig hohen Kosten, sowohl für den Anbieter, als
auch für den Kunden.
Lösung: Zusammenführen von Infrastruktur-Ressourcen in Ressource-Pools, um durch
gemeinsame Nutzung der Kapazität, eine bessere Auslastung der einzelnen Komponenten zu erreichen.
Um unterschiedliche Anforderungen an Ressourcen erfüllen zu können, etwa Sicherheit, Verfügbarkeit, Performance oder Konsistenz, kann es notwendig sein, verschiedene Ressource-Pools bereitzustellen.
Ebenfalls kann die unterschiedliche Nutzungsart einzelner Komponenten (wie etwa Netzwerk, CPU/RAM oder Storage), zu weiteren Ressourcen-Pools führen.
Die resultierende Entkopplung der Ressourcen ist notwendig und wünschenswert und reflektiert die Wirklichkeit der Service-Nutzung.
Ressource Pooling
Verschiedene Service-Class Partitionen werden üblicherweise Aufgrund unterschiedlicher Anforderungen, etwa hinsichtlich Sicherheit, Performance oder Verfügbarkeit, definiert.
Auch die Anforderung nach dedizierten Umgebungen, z.B. für spezielle Kunden, oder Organisationseinheiten, kann ein Grund für Service-Class Partitionen sein.
Sehr häufig werden für solche Service-Class Partitionen dann dedizierte Ressource-Pools bereitgestellt.
Ein Beispiel für dedizierte Ressource Pools für Service-Class Partitionen sind Unterschiede in der per SLA garantierten Verfügbarkeit. So kann ein Pool, aufgrund von Infrastruktur und Betriebskomponenten eine Verfügbarkeit von 99,99% garantieren, wohingegen ein anderer Pool eine geringere Verfügbarkeit garantiert.
Die Unterscheidung wird sich üblicherweise auch im Preis der Nutzung wiederspiegeln und stellt damit ein Instrument zur kosteneffizienten Nutzung der Cloud Plattform dar.
Es muss bei der Entwicklung und Bereitstellung einer Anwendung also auch darauf geachtet werden, welche Service-Klasse diese benötigt. Diese Klassifikation wird in der Konfiguration der Anwendung hinterlegt und schränkt den Betrieb auf dafür geeigneten Pools ein.
Ressource Pooling – Service Class Partitions
Korrekte Deployments und automatische Failover-Operation (etwa bei Ausfall der Hardware unter einer virtuellen Maschine) sind davon abhängig, dass das Systems-Management Tool über die Fähigkeiten der zugrundeliegenden Infrastruktur "bescheid weiß".
Ohne dieses Wissen kann es passieren, dass virtuelle Maschinen auf System verschoben werden, die dafür nicht ausgelegt sind und der Provisionierungs-Prozess gestört wird.
Ressource-Pools definieren die Kapazität von Betriebsumgebungen und ermöglichen damit sowohl automatisierte Provisionierung, als auch
System Management Tools benötigen definierte Grenzen, um
korrekt zu funktionieren.
Ressource Pooling – Systems Management Partitions
Um Kapazitäts-Management korrekt zu betreiben ist es notwendig, die verfügbaren Ressourcen einer Betriebsumgebung genau zu kennen.
Für ein Rechenzentrum kann z.B. in einen Ressource Pool die verfügbare Storagekapazität, die Rechenleistung und Netzwerk-Ressourcen zusammengefasst werden.
Mittels solcher Pools können dann Kapazitäten, basierend auf Kosten, SLAs etc., verteilt werdenVisualisierung verfügbarer
Kapazitäten, sowie deren Nutzung über Zeit
Ressource Pooling – Capacity Management Partitions
Computing Domains sind physisch Infrastruktur-Umgebungen. Sie bieten alle Komponenten zur Ausführung von Diensten und Anwendungen. Die wichtigsten Computing Domains sind die Fault- und die Upgrade Domain.
Computing Domains
Problem: Häufig fallen ganze Gruppen von Servern, aufgrund des Ausfalls einer gemeinsamer Ressource
wie Netzwerk-Switch o.ä., aus. Dies führt zu einer Reduzierung der Service-Qualität, oder sogar zum Ausfall ganzer Services,
wenn das Design der Cloud-Plattform dies nicht mit einbezieht.
Lösung: Um den Ausfall ganzer Servergruppen und aller drauf laufender Dienste abzusichern, sind
physikalische Fault-Domains, bereitzustellen. Diese können im Fehlerfall Dienste übernehmen, um die Verfügbarkeit der Dienste der Cloud-
Plattform weiter zu gewährleisten. Ein einzelnes Rechenzentrum ist je nach Ausstattung und Architektur der Anwendungen in der
Lage den Ausfall eines oder mehrerer Server abzusichern. Um den Ausfall gemeinsam genutzter Ressourcen (wie Netzwerk, Internetanbindung oder
Stromversorgung) ebenfalls abzusichern, muss das RZ all diese Komponenten redundant und über verschiedene Technologien bereitstellen.
Größere Ausfallszenarien oder Katastrophenfälle lassen sich aber auch bei einem mit mehrfach redundanten Systemen konzipierten RZ nicht überbrücken, so dass es physikalische Fault-Domains geben muss.
Physikalische Fault Domain
Problem: Jede Hardware-Komponente ist einmal am Ende ihres Lebenszyklus angelangt, oder wird zu
klein und muss aufgerüstet werden. Upgrades können zu einer Reduzierung des Service Levels oder zu Service-Qualität führen, wenn das Cloud-Plattform Design keine geeigneten Mechanismen bereithält.
Lösung: Eine geeignete Gegenmaßnahme, um im Falle von Upgrades keine Performance-,
Verfügbarkeits- oder Qualitätseinbußen zu erleiden, ist eine Upgrade-Domain. Werden Ressource-Pools zu groß ausgelegt, etwa, wenn es ausschließlich eine Pool gibt, der
das gesamte Rechenzentrum beinhaltet, ist keine differenzierte Bewegung von Ressourcen im Falle eines größeren Updates möglich.
Deshalb sollten kleinere Pools definiert und diese für Upgrade-Szenarien genutzt werden.
Ein optimaler Upgrade mit Ressource-Pools und Upgrade Domain verläuft nach folgendem Schema:1. Verschieben der Laufzeitumgebung des betroffenen Ressource-Pools in die Upgrade
Domain2. Update der Hardware/Software3. Evtl. Neuinstallation aller Basiskomponenten4. Aktualisierte Umgebung wieder als Laufzeitumgebung des Ressource-Pools zuweisen
Upgrade Domain
Problem: Wenn Komponenten ausfallen, einem Upgrade unterzogen werden, oder es zu anderen
Szenarien aus dem Bereich der Ressourcen-Abwertung kommt, hat dies negative Auswirkungen auf die Service-Qualität – z.B. Performance, Lastverträglichkeit oder Storage-Kapazität.
Lösung: Die Infrastruktur sollte über genügend Kapazitätsreserven verfügen, um Auswirkungen auf
Performance oder Lastverträglichkeit durch Hardware-Ausfälle zu vermeiden, oder zumindest zu minimieren.
Der Vorteil einer Betriebsumgebung, welche nach den Konzepten der Homogenität und mit Ressource-Pools aufgebaut wurde, ist, dass die Services auf jedem verfügbaren virtualisierten Server betrieben werden können. Hierdurch sind Verteilung und Lastausgleich einfach und effizient umsetzbar.
Reserve Capacity
Um die Reservekapazität zu berechnen, wird das Entwurfsmuster des Ressource-Decay mit dem Ansatz der physikalischen Fault-Domain, sowie der Upgrade-Domain kombiniert um näherungsweise die benötigte Kapazität, nach dem folgenden Schema zu antizipieren:
TOTALSERVERS = Anzahl an Servern im PoolServersInFD = Anzahl der Server in der Fault Domain ServersInUD = Anzahl der Server in einer Upgrade Domain ServersInDecay = Max Anzahl "abgewerter" Server, bevor ein Austausch notwendig wird.
Reserve capacity = ServersInFD + ServersInUD + ServersInDecay/TOTALSERVERS
Dem Ansatz liegt die Annahme zu Grunde, dass nur eine Domain zu einem gegebenen Zeitpunkt ausfällt.
Soll der Ausfall von mehr als einer Domain abgefedert werden, ist entsprechend mehr Reservekapazität vorzusehen. Selbstverständlich bedeutet dies auch mehr ungenutzte Kapazität im Normalbetrieb.
Berechnung der Reservekapazität
Scale Units sind Einheiten zur (dynamischen) Erweiterung der Kapazität der Plattform. Skaliert werden kann horizontal (etwa durch hinzufügen weiterer Computing Units) oder vertikal (etwa durch Vergrößerung der Kapazität einer VM).
Scale Units
Problem: Zur Inbetriebnahme von Infrastrukturkomponenten, wie Servern, Storage- oder
Netzwerksystemen, müssen diese beschafft, installiert und konfiguriert und in die bestehende Landschaft integriert werden. Dies benötigt Zeit und bindet Ressourcen, welche in dieser Zeit keine nennenswerten anderen Tätigkeiten ausführen können.
Lösung: Um den Mehraufwand, durch die Inbetriebnahme neuer Komponenten zu reduzieren, können
vorkonfigurierte Infrastrukturkomponenten gekauft werden. Noch effizienter ist es, wenn Kapazitätserweiterung (Skalierung) in den Einheiten schon
vorgesehen ist – wie z.B. bei Bladesystemen. Im Betrieb einer jeden Plattform kommt er Zeitpunkt, an dem die genutzte Kapaztät gleich der
verfügbaren (evtl. noch minus der Reserverkapazität) ist und neue Kapazität bereitgestellt werden muss.
Um in diesem Szenario agil, schnell und mit minimalen Kostendruck agieren zu können, ist die Beschaffung vorkonfigurierter Cloud Infrastruktur Einheiten ein erster Schritt.
Solche Kapazitätserweiterungen sollten außerdem in vorberechneten Quantitäten (oder Paketen) erfolgen, um den Aufwand zur Einrichtung (Aufbau Rack, Einschub Server, Verkabelung etc.) zielgerichtet und damit optimiert zu verteilen.
Die Pakete, in denen die Kapazität einer Infrastruktur erweitert wird, wird Scale Unit genannt.
Scale Unit zur Kapazitätserweiterung
Problem: Irgendwann wird jede Plattform an ihre Kapazitätsgrenzen stoßen, wodurch es zu
Performanceproblemen oder Ausfall der Dienste kommt.
Lösung: Definieren Sie einen Kapazitätsplan, der die Elemente Forecast (also geplante
Kapazitätsentwicklung) und die Zeit für Einkauf- und Bereitstellung neuer Komponenten vereint. Der Plan sollte in regelmäßigen Abständen, oder bei Einbringung neuer Kunden/Services
überprüft und ggf. aktualisiert werden. Der Kapazitätsplan muss dabei sowohl die derzeitig verfügbare, als auch, durch Angebots- oder
Nachfrageerweiterung veränderte Reserve- oder Upgradekapazität (siehe Reserve Capacity und Upgrade Domain) mit einbeziehen.
Anhand dieses Plans kann die Kapazität der Cloud Services Infrastruktur erweitert werden, ohne dass es zu Serviceausfällen kommt.
Ein Kapazitätsplan ist ein wichtiges Element, um der Erwartung nach unendlicher Kapazität zu entsprechen.
Ohne ein hohes Maß an Automatisierung und detaillierte Überwachung der Umgebung, kann ein Kapazitätsplan nicht funktionieren, weshalb diese Paradigmen und Konzepte unabdingbar sind.
Kapazitätsplanung
Problem: Fällt eine Komponente aus, so kann dies zu Performanceproblemen oder Ausfällen der davon
abhängigen Services führen.
Lösung: Definition eines Health Modells für jeden Service. Dieses Modell enthält alle Komponenten und
Dienste von denen ein Service abhängig ist, sowie für jeden Fehlerfall, die entsprechenden Aktivitäten, zur Wiederherstellung der Servicebereitschaft.
Service Management Tools müssen also die Abhängigkeiten zwischen Diensten untereinander und von Diensten zu Komponenten kennen und verstehen, um aus einem Fehlerevent (etwa Ausfall) eine entsprechende Action (etwa Serviceumzug) ableiten zu können.
Zur Erlangung dieses Einblicks in Bezug auf einen Service oder eine Anwendung dient auch das Dependency.-Manifest (siehe Dokument zu Software Architektur Guidelines – Abschnitt Abhängigkeiten).
Im weiteren Sinne basiert die automatisierte Bereitstellung von Services auf der Cloud Plattform, etwa durch den Fabric Manager, auf dem Health Modell und wird üblicherweise auch in dessen Umgebung detailliert aufgebaut.
Health Model
Die Umsetzung der vorgestellten Konzepte und Design Patterns wird in der Präsentation zur CSP Plattform Infrastruktur dargestellt.
Umsetzung der Konzepte
Christian GüntherPrincipal Solution Architect
Mobile: +49 1511 22 40 942E-Mail: christian.guenther@comlineag.de
COMLINE Computer und Softwarelösungen AG
Leverkusenstr. 54
DE - 22761 Hamburg
www.comlineag.de
Vielen Dank für Ihre Aufmerksamkeit.
Recommended