Wiki  >  TechNet Articles  > 

Private Cloud Reference Model (de-DE) - TechNet Articles - United States (English) - TechNet Wiki

Einführung

Dieses Dokument bietet einen Überblick über das Private Cloud Reference Model. Für den Zweck dieses Dokument umfasst das Referenzmodell die Problemdefinition,

Private Cloud Reference Model (de-DE)

image die Anforderungen und den Umfang sowie die Identifikation aller notwendigen Ebenen und deren Abhängigkeiten untereinander.

Hinweis:
Dieses Dokument ist Teil einer Sammlung von Dokumenten welche eine Referenz Architektur für eine Private Cloud beschreiben. Die Lösung für Private Cloud ist ein Project innerhalb der Microsoft Community zu dem jeder inhaltlich beitragen kann, indem er die hier vorhandenen Inhalte ergänzt oder verbessert. Die Bearbeitung ist nach Anmeldung in diesem Portal möglich. Der Autor kann seinen Beitrag mit seinem Namen und Email-Adresse versehen um damit mit anderen Mitgliedern der Community in Austausch zu treten.

Das hier vorgestellte Referenzmodell bildet das Fundament einer Private Cloud Architektur. Neben der Definition des Umfangs erfolgt auch eine Festlegung der Begrifflichkeiten und soll dadurch sicherstellen, dass unterschiedliche Ansätze der hier mitwirkenden Autoren auf denselben Annahmen beruhen. Jeder, welcher an diesem Projekt zur Definition einer Referenz Architektur mitwirkt, sollte das hier vorgestellte Referenz Modell verstehen und es als Grundlage für die Entscheidung verwenden, ob der Umfang den eigenen Erfordernissen entspricht oder ob und welche Inhalte fehlen.

Das Referenzmodell wird zunächst als ein einfaches Diagramm dargestellt, im weiteren Verlauf werden die einzelnen Abschnitte einer jeden Ebene und Ihrer Komponenten beschrieben.

Dies ist ein generelles Dokument, welches  den grundlegenden Rahmen für die Entwicklung einer Public Cloud Referenz Architektur definiert. Die Zielgruppe dieses Dokuments sind all diejenigen, welche mit der Entwicklung von Private Clouds befasst sind. Der Inhalt kann von den Lesern zum Abgleich mit eigenen Inhalten zum Thema Private Cloud verwendet werden. Darüber hinaus ist das Dokument auch für eine erweiterte Zielgruppe von Architekten, Beratern, Service-Manager und technische Entscheider gedacht.

Table of Contents

Reference Model

Das Reference Model begleitet Architekten bei einer umfassenden Entwicklung von Private Cloud Architekturen. Darüber hinaus bietet es eine Begriffsdefinition für die jeweilige Zielgruppe.

Im Folgenden werden die Ebenen eines Private Cloud Referenz Modells dargestellt und in einzelne Teilbereiche unterteilt.


Abbildung 1: Das Private Cloud Reference Model

Das Referenzmodell kann in folgende Ebenen (Layer) unterteilt werden:

  • Die Software, Platform und Infrastructur Layer stellen den Technologiestack einer Private Cloud dar in dem jeder Layer Services für die darüber liegende Ebene bereitstellt
  • Die Service Operations und Management Layer stellen die prozess-orientierte Sichtweise dar und bieten darüber hinaus die notwendigen Werkzeuge um die Prozesse zu unterstützen
  • Der Service Delivery Layer stellt die gemeinsame Ausrichtung von geschäftlichen Anforderungen und der IT dar

Es ist ein bewusster Versuch, Technologien und Prozesse (wie beispielsweise die Information Technology Infrastructure Library (ITIL) gemeinsam abzubilden. Dies ist notwendig, da Cloud Computing zu gleichen Teilen aus Technologien und Prozessen besteht.

Auf den ersten Blick scheint kein großer Unterschied zur traditionellen IT Erkennbar – aber dies ist auch keine Referenzarchitektur, sondern ein Referenzmodell. Viele der bekannten IT Probleme scheinen für eine Private Cloud weiterhin zuise dar und bieten darüber hinaus die notwendigen Werkzeuge um die Prozesse zu unterstützen

  • Der Service Delivery Layer stellt die gemeinsame Ausrichtung von geschäftlichen Anforderungen und der IT dar

    • Die verschiedenen Schichten (Layer) sind wie im Folgenden definiert:

    • Service Delivery Layer: Dieser Layer umfasst die Anforderungen des Service Managements welche zur Abstimmung unter den Service Verantwortlichen in verschiedenen Bereichen verwendet werden kann. Neben der betriebswirtschaftlichen Sicht wird hier auch der operative Aspekt eines Services (Services) betrachtet
    • Software Layer: Dieser Layer unterstützt Geschäftsprozesse durch Software und Anwendungen (z.B. CRM). Im Software Layer werden Virtuelle Maschinen (VMs) aus dem Infrastruktur Layer und möglicherweise auch  Anwendungen aus dem Platform Layer verwendet
    • Platform Layer: Der Platform Layer bietet oberhalb des Betriebssystems sogenannte Building-Blocks welche im Software Layer Verwendung finden. Die Building-Blocks des Platform Layers basieren auf Virtualisierungsservices aus dem Infrastruktur Layer
    • Infrastructure Layer: Dieser Layer stellt im Wesentlichen Virtualisierungsservices für den Platform Layer bereit.
    • Service Operations Layer: Services dieses Layers unterstützen den IT Betrieb und Support in Form von Prozessen und Service Management
    • Management Layer: In diesem Layer sind Managementservices zu finden welche in den Infrastruktur, Plattform und Software Layer Verwendung finden. Diese Services beinhalten eine Reihe von Managementwerkzeugen zur Unterstützung von IT Dienstleistungen und Prozessen. Der Management Layer bietet eine Auswahl von grundlegenden Funktionalitäten für die Infrastruktur Schicht als auch ergänzende Funktionen für die Plattform und Software Schicht

    Im Folgenden werden die verschiedenen Layer im Detail vorgestellt:

    Service Delivery Layer

    Der Service Delivery Layer ist die Schnittstelle zwischen dem Kerngeschäft des Kunden und seiner IT. Er dient zur Übertragung von Anforderungen aus dem geschäftlichen Umfeld in Dienstleistungen aus der IT und stellt deren Bereitstellung sicher. Diese Fähigkeiten sind allen Services (Servicesn) eines Cloud Modells (Infrastructure as a Service - IaaS, Plattform as a Service – PaaS und Software as a Service - SaaS) gemein.


    Abbildung 2: Service Delivery Layer Components

    Als primäre Schnittstelle zwischen den Bereichen IT und dem Kerngeschäft besitzt der Service Delivery Layer Informationen und liefert Antworten auf die folgenden Fragen:

    • Welche Services werden benötigt?
    • Für welche Services werden von Entscheidungsträgern finanzielle Mittel bereitgestellt?
    • Wie kann die Verwendung einer Private Cloud die Sichtweise auf die IT als Kostenstelle ändern, dahin gehend das IT zukünftig als strategischer Partner zur Unterstützung des Kerngeschäfts gesehen wird?

    Mit diesen Fragen im Hinterkopf ergeben sich zwei wesentliche Probleme innerhalb des Service Layers welche die IT adressieren muss:

    • Wie kann eine Plattform mit Merkmalen einer Cloud für Geschäftsprozesse bereitgestellt werden, welche den Geschäftszielen gerecht wird?
    • Wie kann ein einfach zu verstehendes, auf aktuellem Verbrauch basierendes Kostenmodell umgesetzt werden, welches zur Beeinflussung von Geschäftsentscheidungen verwendet werden kann?

    Eine Organisation muss daher die folgenden Eigenschaften eines cloud-basierten Services übernehmen, wenn damit verbundenen Geschäftsziele erreicht werden sollen:

    • Perception of Infinite Capacity:  Aus Sicht des Nutzers eines cloud-basierten Services gibt es keine Begrenzungen in Bezug auf Kapazität oder Skalierung
    • Perception of Continuous Availability: Für den Nutzer wird ein Service aus der Cloud unterbrechungsfrei bereitgestellt. Fehler innerhalb der Cloud werden durch verschiedene Mechanismen transparent gegenüber dem Nutzer gehandhabt
    • Resilience over Redundancy Mindset: Der Fokus des Cloud-Providers liegt in der Sicherstellung von Services durch Stabilität und Elastizität anstatt durch Redundanz
    • Service Provider’s Approach in Delivering Infrastructure: Eine IT Organisation welche Cloud-basierte Services anbietet tut das anhand von klar definierten Vorgaben, gegenüber des Kunden aber auch für die angebotenen Services
    • Drive Predictability: Nur durch eine hohe Standardisierung können Services aus der Cloud der zuvor festgelegten Gute bereitgestellt werden
    • Minimize Human Involvement: Die Private Cloud wird mit einem maximalen Grad an Automatisierung betrieben. Nur durch entsprechende Automatismen lässt sich die vom Kunden gewünschte Elastizität und Stabilität erreichen
    • Optimization of Resource Usage: Der Anbieter eine Private Cloud realisiert eine kostengünstige Bereitstellung von Servicesn durch optimale Auslastung und effizientes Management
    • Encourage Desired Cosumer Behaviour:  Durch eine flexible und kosteneffiziente Gestaltung der angebotenen Services wird das Nutzungsverhalten der Services beeinflusst
    Der Service Layer besteht aus folgenden Komponenten:
    • Financial Managenent: Das Finanz-Management umfasst Funktionen und Prozesse welche notwendig sind um den Anforderungen des Cloud-Anbieters in Bezug auf das vorhandene Budget, die Abrechnung, eine Messung der Dienstleistungen und deren Abrechnung gerecht zu werden
    • Demand Management: Das Bedarfs-Management umfasst ein Verständnis für die Anforderungen des Kunden und deren Beeinflussung dahingehend, dass Services effizient zur Verfügung gestellt werden können. Die Grundsätze von Verfügbarkeit und dem Gefühl unendlicher Skalierung sind notwendig das Vertrauen des Kunden in die Cloud zu stärken und somit dessen Nachfrage zu erhöhen. Darüber hinaus stellen Kosten, die Qualität der bereitgestellten Services wie auch deren Flexibilität weitere Faktoren zur Beeinflussung des Kundenbedarfs dar
    • Business Relationship Management: Das Management von geschäftlichen Verbindungen zwischen dem Kunden und der IT resultiert aus dem Verständnis heraus, dass sich die für die Cloud-Services verantwortliche IT-Abteilung als Dienstleister versteht. Der Reifegrad der dazu verwendeten Prozesse ist die Grundlage für eine effektive Beziehung zum Kunden.
    • Service Catalog: Das Ergebnis aus Demand und Business Relationship Management ist ein Service Katalog welcher die angebotenen Services und deren Klassifizierungen beinhaltet bzw. dokumentiert. Der Katalog beschreibt die Klasse eines jeden Services, die Nutzungsbedingungen, Eigenschaften der angebotenen Service-Levels als auch das Kostenmodell. Der Service Katalog erfährt im Verlauf der Zeit Anpassungen um Änderungen in den Anforderungen der Kunden zu berücksichtigen
    • Service Life Cycle Management: Das Service Life Cycle Management betrachtet den vollständigen Lebenszyklus eines angebotenen Services. Der Umfang besteht normalerweise in der Identifikation von Anforderungen, geht über die Analyse von Abhängigkeiten bis hin zur Bereitstellung des Services. Für das Design eines Services spielen neben den identifizierten Anforderungen auch die allen Services zu Grunde liegende Strategie des Cloud-Anbieters eine Rolle. Nach der Bereitstellung des Services, erfolgt eine Übergabe des Services an den Betrieb und eine kontinuierliche Verbesserung der Service Qualität. Die Einnahme der Sichtweise eines Dienst-Anbieters (Providers) stellt für die bereitstellende IT-Abteilung einen wichtigen Aspekt für ein erfolgreiches Service Life Cycle Management der angebotenen Service-Levels als auch das Kostenmodell. Der Service Katalog erfährt im Verlauf der Zeit Anpassungen um Änderungen in den Anforderungen der Kunden zu berücksichtigen
    • Service Life Cycle Management: Das Service Life Cycle Management betrachtet den vollständigen Lebenszyklus eines angebotenen Services. Der Umfang besteht normalerweise in der Identifikation von Anforderungen, geht über die Analyse von Abhängigkeiten bis hin zur Ber dar
    • Service-Level Management: Im Rahmen des Service-Level Managements erfolgt die Verhandlung von Service-Level Agreements (SLAs) und die Sicherstellung deren Einhaltung. Im Rahmen der SLAs erfolgen eine Definition des Services und dessen messbare Parameter wie Verfügbarkeit, Skalierung aber auch die Prozesse zur Abrechnung von Leistungen und die Kostenstruktur des Services.
    • Continuity and Availability Management: Durch das Management der Verfügbarkeit von Services wird sichergestellt, dass die Erwartungshaltung des Kunden gegenüber des von ihm in Anspruch genommenen Services erfüllt wird. Ein kontinuierliches Management bewertet Risiken und deren Handhabung im Fehlerfall und stellt auch hier eine Bereitstellung eines von Services sicher.
    • Capacity Management: Über ein Management der bereitgestellten Kapazitäten wird nach außen, also gegenüber dem Kunden sichergestellt, dass die private Cloud bzw. der von ihm in Anspruch genommene Dienst in der Lage ist, entsprechend seinen Anforderungen zu skalieren und somit als ein Dienst mit unendlicher Kapazität wahrgenommen wird. Dabei fließen auch zukünftige Anforderungen in das Management mit ein um die Bereitstellung der notwendigen Ressourcen für den Anbieter möglichst effektiv zu gestalten. Damit einhergehend ist eine ständige Optimierung der Ressourcen Nutzung innerhalb der private Cloud.
    • Information Security Management: Die Gewährleistung der Datensicherheit für einen angebotenen Dienst ist ein wichtiger Bestandteil um das Vertrauen in eine Private-Cloud herzustellen und zu stärken. Die innerhalb des Unternehmens definierte Richtlinie zum Umgang mit vertraulichen und sicherheitsrelevanten Daten hat maßgeblichen Einfluss auf die Architektur einer Private-Cloud und der von ihr bereitgestellten Services. Die Möglichkeit Services für einzelne Kunden zu segmentieren sowie eine generelle Mandaten Fähigkeit sind  dabei wichtige Faktoren zum erfolgreichen Betrieb einer Private-Cloud

    Software Layer

    Über den Software Layer werden Anwendungen mit entsprechenden Laufzeitumgebungen und Komponenten versorgt um darauf basierend Services bereitstellen zu können. Der Software Layer verwendet Ressourcen aus dem Virtualisierungslayer als auch aus der Infrastruktur und der Plattform Schicht. Der Software layer stellt die Schnittstelle zum Benutzer dar.

    Platform Layer

    Der Platform Layer stellt Anwendungen Services unter Verwendung von Ressourcen der Virtualisierungsschicht der Software Schicht zur Verfügung. Der Platform Layer hat unterschiedliche Schnittstellen wie zum Beispiel HTTP oder REST.

    Infrastructure Layer

    Der Infrastructure Layer stellt Hypervisor Services in Form von Virtuellen Maschinen (VMs) dem Platform und Software Layer zur Verfügung. Auf dieser Ebene werden die Anforderungen an die Infrastruktur zum Betrieb dieser VMs definiert. Diese Anforderungen beinhalten neben dem Hypervisor, den physikalischen Servern und den Speicher Systemen auch die Einrichtung des Rechenzentrums selbst wie zum Beispiel das Netzwerk, die Datenschränke und die Kühlung der Systeme.


    Abbildung 3: Infrastructure Layer Components

    Die Bestandteile der Infrastruktur Ebene beinhalten:

    • Das Netzwerk (Network): Die Network Services stellen den Transport und die Adressierung von Datenpaketen innerhalb der Provider Infrastruktur und der VMs des Kunden sicher. Darüber hinaus werden auch die Anforderungen an physikalische und virtuelle Netzwerk Switches, Router und Firewalls sowie VLANs (Virtual Local Area Networks) spezifiziert
    • Die Computer (Compute): Innerhalb dieser Ebene werden Bestandteile der Server spezifiziert und zur Verfügung gestellt. Dazu gehören die CPUs, der Hauptspeicher (RAM), Netzwerk und Grafikkarte sowie der verwendete Speicher. Diese Ebene beinhaltet die Server Hardware und den verwendeten Hypervisor bzw. das Betriebssystem unter dem die Services zur Virtualisierung ausgeführt werden
    • Den Speicher (Storage): Die Speicher Ebene stellt physikalischen Speicher den Provider zur Verfügung welcher diesen seinen Kunden in Form von virtuellen Disks bereitstellt. Um eine hinreichende Flexibilität sicher zu stellen wird der Speicher über ein Netzwerk (SAN oder LAN) bereitgestellt
    • Der Hypervisor: Der Hypervisor stellt VirtualisierungsServices zur partitionierung der Serverhardware, des lokalen Netzwerks und der SpeicherServices bereit
    • Das Rechenzentrum:  Das Rechenzentrum beinhaltet neben dem Gebäude selbst auch die Racks, Stromversorgung, Kühlung sowie die elektrischen Anschlüsse

    Service Operations Layer

    Der Service Operations Layer spezifiziert die Prozesse welche notwendig sind um IT als Service anzubieten. Dieser Layer bedient sich bei Konzepten und Best Practices wie ITIL und dem Microsoft Operations Framework (MOF).

     Der Fokus dieses Layers liegt in der Realisierung von Anforderungen welche im Service Delivery Layer definiert sind. Technologien alleine reichen nicht aus um Services mit Cloud-Attributen bereit zu stellen, hierzu ist zusätzlich noch ein ausgereiftes IT Service Management notwendig.

    Allen drei Services (Iaas, Paas und Saas) setzks, Stromversorgung, Kühlung sowie die elektrischen Anschlüsse

    Service Operations Layer

    Der Service Operations Layer spezifiziert die Prozesse welche notwendig sind um IT als Service anzubieten. Dieser Layer en sich unter dem Aspekt des Betriebs aus den folgenden Bestandteilen zusammen. 


    Abbildung 4: Operations Layer Components

    Die einzelnen Bestandteile des Operations Layers beinhalten:

    • Change Management: Das Change Management definiert die Kontrolle und Verantwortung über den kompletten Lebenszyklus eines Changes. Der Sinn des Change Managements liegt darin notwendige Veränderungen an einem System mit einer möglichst geringen Unterbrechung sicherzustellen. Im Rahmen des Change Managements werden die Risiken und Kosten einer Veränderung in Relation zu ihrem Nutzen bewertet. Eine hoch automatisierte Durchführung von Changes und die Möglichkeit Dauer und Auswirkungen zu bestimmen sind integrale Bestandteile eines ausgereiften Change Managements
    • Service Asset und Configuration Management: Im Rahmen des Service Asset und Configuration Managements werden Informationen über die Bestandteile welche zur Erbringung eines Services notwendig sind gesammelt. Dabei ist es wichtig detaillierte Konfigurationen einzelner Komponenten und deren Abhängigkeiten untereinander zu dokumentieren und zu sammeln. Zusätzliche sollten ebenso alte Konfigurationen und Daten genauso wie zu erwartende Änderungen vorgehalten werden. Ein ausgereiftes Service Asset und Configuration Management ist notwendig um eine vorausschauende Kalkulation der bereitgestellten Services durchführen zu können
    • Release und Deployment Management: Im Rahmen des Release und Development Managements wird sichergestellt das Changes, also Änderungen, an einem einem Service bewertet, getestet und durchgeführt werden unter der Maßgabe den Service selbst geringstmöglich zu beinträchtigen. Das Change Management stellt hierzu einen Genehmigungsprozess zur Verfügung. Dabei wird auch geprüft, was und weshalb ein Change durchgeführt wird. Das Release und Deployment Management stellt das Verfahren bereit um die Implementierung von Changes durchzuführen. Wie auch bei den anderen Bestandteilen des Operations Layer liegt auch hier ein wichtiges Merkmal in der automatisierten Durchführung der Änderungen
    • Knowledge Management: Das Knowledge Management ist verantwortlich für die Sammlung, Analyse, Speicherung und Bereitstellung von Information innerhalb einer Organisation oder eines bereitgestellten Services.
    • Incident and Problem Management: Das Incident und Problem Management hat das Ziel Service Unterbrechungen mit der größtmöglichen Geschwindigkeit zu beheben. Im Rahmen des Problem Managements werden aufgetretene Fehler und Incidents in der Vergangenheit analysiert um diese in Zukunft vermeiden oder deren Auswirkung verringern zu können. In einer Private Cloud, sorgt eine entsprechende Auslegung von Services für die notwendige Robustheit gegenüber auftretenden Fehlern. Durch die Möglichkeit Fehlerquellen erkennen zu können, wird durch das Incident und Problem Management die Stabilität und Qualität des angebotenen Services erhöht.
    • Request Fullfillment: Das Ziel des Request Fullfillments ist das Management von Benutzer Anfragen für die angebotenen Services. Soll die IT den Ansprüchen eines Service Providers genügen, müssen die verfügbaren und angebotenen Services in einem Service Katalog angeboten werden. Anhand dieses Katalogs kann der Benutzer, sprich Kunde, entsprechend seinen geschäftlichen Anforderungen die passenden Services auswählen. Self-Service Portale, können hierbei den Prozess zusätzlich unterstützen.
    • Access Management: Das Access oder auch Zugriffs Management verhindert den nicht autorisierten Zugriff auf angebotene Services. Darüber hinaus wird sichergestellt, dass authentifizierte Benutzer genau die Ressourcen nutzen können welche für sie bestimmt sind. Im Rahmen des Access Managements werden Richtlinien verwendet welche durch das Security Management im Service Delivery Layer definiert wurden. Das Access Management erlangt höchste Wichtigkeit zur Sicherstellung der Mandaten Fähigkeit eines angebotenen Services.
    • Systems Administration: Das Ziel der System Administration ist die Ausführung von Tätigkeiten welche notwendig sind um ein System betriebsfähig zu halten. Eine ausgereifte und etablierte System Administration ist notwendig um einen angebotenen Dienst auch für zukünftige Anforderungen kalkulieren zu können. Darüber hinaus sind die meisten Aufgaben der System Administration automatisiert und dokumentiert

    Management Layer

    Der Management Layer definiert die benötigten Fähigkeiten um Operation und Service Layer Prozesse und Prozeduren umzusetzen, welche IaaS, PaaS und SaaS bereitstellen. Diese Fähigkeiten bauen aufeinander auf und ergänzen sich in den Schichten Infrastructure, Platform und Software.


    Abbildung 5: Management Layer Components Related to Infrastructure

    Der Komponenten des Management Layer mit Relation zum Infrastructure Layer sind:

    • Service Reporting: Service Reporting ist der Mechanismus um Performance Reports über Service Level zu erstellen. Die Anforderungen an die Werkzeuge zum Service Reporting sollten sich an den Anforderung der Service Level orientieren, welche durch das Service Level Management im Service Level festgelegt werden
    • Service Management System: Ein Service Management System ist ein Werkzeug zur Unterstützung des Service Management Prozesses. Idealerweise sollte dieses Werkzeug in der Lage sein, Daten und Informationen aller Werkzeuge des Management Layers zu integrieren. Es sollte außerdem in Lage sein, die Daten zu verarbeiten und geeignete darzustellen. Als Minimum sollte das Service Management System eine Verbindung zum Configuration Management System (CMS) - allgemein als Configuration Management Database (CMDB) bekannt – haben, und Incidents, Problems und Changes nachverfolgen und protokollieren, Es ist weiterhin vorteilhaft wenn das Service Management System mit dem Service Health Modeling System integriert ist, damit Incident Tickets automatisch generiert werden können.
    • Service Health Modeling: Das Service Health Modeling System stellt sicher das der Service alle im Service Level festgelegten Ziele erfüllt. Dieses System sollte jede zur Erbringung des Services notwendige Komponente sowie die Beziehung zu und Abhängigkeit von anderen Komponenten kennen. Das Service Health Modeling System sollte erkennen, wenn sich ein überwachter Wert einem Schwellwert nähert oder eine Komponente in einen Fehlerzustand gerät, um das Problem entweder zu beheben oder den Betrieb zu alarmieren.
    • Configuration Management System: Ein Configuration Management System (CMS) ist die Stelle an der Daten über alle Configuration Items (CI) gesammelt, gespeichert, verwalten, aktualisiert und aufbereitet werden. Ein CMS besteht aus eine Anzahl von Configuration Management Databases (CMDBs), von denen jede einen Teil der Konfigurationsdaten verwaltet. Das CMS sollte idealerweise die Informationen der CMDBs für Aufbereitung, Analyse und Präsentation integrieren und korrelieren. Das CMs sollte außerdem in der Lage sein Konfigurationen zu überwachen und Abweichungen vom Sollzustand zu erkennen und zu beheben.
    • Fabric Management: Fabric Management ist das Werkzeug um die Virtual Hosts Virtual Networks und Storage zu verwalten. Das Fabric Management stellt die Orchestrierung bereit, um den Lebenszyklus eines vom Endkunden genutzten Workloads (eine oder mehrere virtuelle Maschinen die zusammen einen Service bereitstellen; Microsoft Office SharePoint Portal um ein Beispiel zu nennen).
    • Deployment and Provisioning Management: Deployment and Provisioning Management ist der Satz von Werkzeugen um die Prozesse auszuführen, welche durch das Release und Deployment Management im Operations Layer definiert werden. Das Deployment hat die Bereitstellung oder Installation einer Computer oder einer Service Komponente im allgemeinen Sinn zum Ziel. Provisioning ist der Prozess welcher Servicespezifische und Instanzspezifische Attribute auf die deployten Ressourcen anwendet.
    • Data Protection: Data Protection, also der Schutz der Daten, bietet die Möglichkeit zu Sicherung und Wiederherstellung von Daten, Hosts, sowie Infrastruktur und Service-Komponenten. Richtlinien für den Schutz der Daten sollten im IT Service Layer durch Service-Level Management und Information Security Management festgelegt werden
    • Network Management: Das Network Management verwaltet die zugrundeliegende Netzwerkstruktur wie VLANs, Switch Ports, Load Balancers, und Firewallregeln. Network Management bietet darüber hinaus eine Reihe von Servicesn welche IaaS unterstützen, beispielsweise Dynamic Host Configuration Protocol (DHCP), Domain Name System (DNS), and Pre-Boot Execution Environment (PXE).
    • Security Management: Security Management setzt die Security Richtlininen um (z.B. Regeln zur Komplexität von Kennwörtern) welche die Infrastruktur betreffen. Es stellt weiterhin Security Services wie Directory, Authentisierung und Authentifizierung bereit.

    Im weiteren Verlauf dieser Serie wird jedes Modell des Referenzmodels näher betrachtet, um die Details jeder Ebene herauszuarbeiten. Dies wird als Ergebnis eine komplette Reference Architecture für Private Cloud darstellen. Security (was Identity und Access Management umfasst) wird nicht im Referenzmodel berücksichtigt. Dies ist keine Unterlassung, sondern der Erkenntnis geschuldet das Security ein übergreifender Bereich ist welcher alle Aspekte der Architektur beeinflusst. Anstatt einen Security Block in der Mitte zu platzieren, der Beziehungen zu allen anderen Blöcken haben würde, akzeptieren wir diese übergreifende Natur des Security Themas und werden diese Thematik in einem Dokument zur Cloud Security Architektur adressieren und in der Betrachtung der einzelnen Layers.


    RESSOURCEN:
     

    ACKNOWLEDGEMENTS LIST:
    If you edit this page and would like acknowledgement of your participation in the v1 version of this document set, please include your name below:
    [Enter your name here and include any contact information you would like to share]

    Return to Reference Architecture for Private Cloud