[ English | Indonesia | Deutsch | 日本語 ]

Planung für die Bereitstellung und Bereitstellung von OpenStack

Die Entscheidungen, die Sie in Bezug auf Provisionierung und Bereitstellung treffen, wirken sich auf Ihre Wartung der Cloud aus. Ihr Konfigurationsmanagement wird sich im Laufe der Zeit weiterentwickeln können. Allerdings müssen mehr Überlegungen und Entwürfe angestellt werden, um im Vorfeld Entscheidungen über die Bereitstellung, Festplattenpartitionierung und Netzwerkkonfiguration treffen zu können.

Ein kritischer Teil der Skalierbarkeit einer Cloud ist der Aufwand, der für den Betrieb Ihrer Cloud erforderlich ist. Um die Betriebskosten für den Betrieb Ihrer Cloud zu minimieren, richten Sie eine automatisierte Bereitstellungs- und Konfigurationsinfrastruktur mit einem Konfigurationsmanagementsystem ein, wie beispielsweise Puppet oder Chef. In Kombination reduzieren diese Systeme den manuellen Aufwand und die Wahrscheinlichkeit von Bedienungsfehlern erheblich.

Diese Infrastruktur umfasst Systeme, die die Erstkonfiguration des Betriebssystems automatisch installieren und später die Konfiguration aller Dienste automatisch und zentral koordinieren, was sowohl den manuellen Aufwand als auch die Fehleranfälligkeit reduziert. Beispiele sind Ansible, CFEngine, Chefkoch, Marionette und Salz. Sie können OpenStack sogar verwenden, um OpenStack, genannt TripleO (OpenStack On OpenStack), bereitzustellen.

Automatisierte Bereitstellung

Ein automatisiertes Bereitstellungssystem installiert und konfiguriert Betriebssysteme auf neuen Servern, ohne Eingriffe, nach dem absoluten Minimum an manueller Arbeit, einschließlich physischem Racking, MAC-zu-IP-Zuweisung und Stromkonfiguration. Typischerweise basieren Lösungen auf Wrappern um PXE-Boot- und TFTP-Server für die Installation des Basis-Betriebssystems und die Übergabe an ein automatisiertes Konfigurationsmanagementsystem.

Sowohl Ubuntu als auch Red Hat Enterprise Linux enthalten Mechanismen zur Konfiguration des Betriebssystems, einschließlich Preseed und Kickstart, die Sie nach einem Netzwerkstart verwenden können. Typischerweise werden diese verwendet, um ein automatisiertes Konfigurationssystem zu starten. Alternativ können Sie auch einen abbildbasierten Ansatz für die Bereitstellung des Betriebssystems verwenden, z.B. den Systemimager. Sie können beide Ansätze mit einer virtualisierten Infrastruktur verwenden, z. B. wenn Sie VMs ausführen, um Ihre Kontrolldienste und die physische Infrastruktur zu trennen.

Wenn Sie einen Bereitstellungsplan erstellen, konzentrieren Sie sich auf einige wichtige Bereiche, da sie nach der Bereitstellung nur sehr schwer zu ändern sind. In den nächsten beiden Abschnitten wird über die Konfigurationen für:

• Festplattenpartitionierung und Festplattenarray-Setup für Skalierbarkeit

• Netzwerkkonfiguration nur für das PXE-Booten

Festplattenpartitionierung und RAID

An der Basis eines jeden Betriebssystems befinden sich die Festplatten, auf denen das Betriebssystem (OS) installiert ist.

Sie müssen die folgenden Konfigurationen auf den Festplatten des Servers vornehmen:

• Partitionierung, die eine größere Flexibilität für das Layout von Betriebssystem und Swap Space bietet, wie im Folgenden beschrieben.

• Hinzufügen zu einem RAID-Array (RAID steht für redundantes Array unabhängiger Festplatten), basierend auf der Anzahl der verfügbaren Festplatten, so dass Sie Kapazität hinzufügen können, wenn Ihre Cloud wächst. Einige Optionen werden im Folgenden näher beschrieben.

Die einfachste Möglichkeit, mit dem Programm zu beginnen, ist die Verwendung einer Festplatte mit zwei Partitionen:

• Dateisystem zum Speichern von Dateien und Verzeichnissen, in denen sich alle Daten befinden, einschließlich der Root-Partition, die das System startet und ausführt.

• Swap Space, um Speicher für Prozesse freizugeben, als unabhängiger Bereich der physischen Festplatte, der nur für Swapping und nichts anderes verwendet wird.

RAID wird in diesem vereinfachten Ein-Laufwerk-Setup nicht verwendet, da Sie im Allgemeinen für Produktions-Clouds sicherstellen möchten, dass bei Ausfall einer Festplatte eine andere an ihre Stelle treten kann. Verwenden Sie stattdessen für die Produktion mehr als eine Festplatte. Die Anzahl der Festplatten bestimmt, welche Arten von RAID-Arrays erstellt werden sollen.

Wir empfehlen Ihnen, eine der folgenden Optionen für mehrere Festplatten zu wählen:

Option 1

Partitionieren Sie alle Laufwerke horizontal auf die gleiche Weise, wie in Partitionierung von Laufwerken gezeigt.

Mit dieser Option können Sie verschiedenen RAID-Arrays verschiedene Partitionen zuweisen. Sie können die Partition 1 der Festplatte eins und zwei dem Partitions-Spiegel /boot zuordnen. Sie können die Partition 2 aller Festplatten zum Root-Partitionsspiegel machen. Sie können die Partition 3 aller Festplatten für eine cinder-volumes LVM-Partition verwenden, die auf einem RAID 10-Array läuft.

Partitionierung von Laufwerken

Während Sie in diesem Beispiel mit unbenutzten Partitionen enden können, wie z.B. Partition 1 in Laufwerk drei und vier, ermöglicht diese Option eine maximale Nutzung des Festplattenspeichers. Die I/O-Leistung kann ein Problem darstellen, da alle Festplatten für alle Aufgaben verwendet werden.

Option 2

Fügen Sie alle Rohdatenträger zu einem großen RAID-Array hinzu, entweder hardware- oder softwarebasiert. Sie können dieses große Array mit den Bereichen boot, root, swap und LVM partitionieren. Diese Option ist einfach zu implementieren und verwendet alle Partitionen. Allerdings kann es bei der Festplatten-I/O zu Problemen kommen.

Option 3

Weisen Sie ganze Festplatten bestimmten Partitionen zu. Sie können beispielsweise die Festplatte eins und zwei vollständig den Boot-, Root- und Swap-Partitionen unter einem RAID-1-Spiegel zuordnen. Ordnen Sie dann die Festplatten drei und vier vollständig der LVM-Partition zu, auch unter einem RAID-1-Spiegel. Festplatten-I/O sollte besser sein, da sich die I/O auf dedizierte Aufgaben konzentriert. Die LVM-Partition ist jedoch viel kleiner.

Tipp

Sie werden feststellen, dass Sie die Partitionierung selbst automatisieren können. Zum Beispiel verwendet MIT Vollautomatische Installation (FAI), um die anfängliche PXE-basierte Partition zu erstellen und dann mit einer Kombination aus min/max und prozentbasierter Partitionierung zu installieren.

Wie bei den meisten Architekturentscheidungen hängt die richtige Antwort von Ihrer Umgebung ab. Wenn Sie vorhandene Hardware verwenden, kennen Sie die Festplattendichte Ihrer Server und können einige Entscheidungen basierend auf den oben genannten Optionen treffen. Wenn Sie einen Beschaffungsprozess durchlaufen, helfen Ihnen die Anforderungen Ihres Benutzers auch bei der Bestimmung des Hardwarekaufs. Hier sind einige Beispiele aus einer privaten Cloud, die Webentwicklern benutzerdefinierte Umgebungen bei AT&T bietet. Dieses Beispiel stammt aus einem bestimmten Einsatz, so dass Ihre vorhandene Hardware oder Beschaffungsmöglichkeit davon abweichen kann. AT&T verwendet bei der Bereitstellung drei Arten von Hardware:

• Hardware für Steuerungsknoten, die für alle zustandslosen OpenStack-API-Dienste verwendet wird. Etwa 32-64 GB Arbeitsspeicher, kleine angeschlossene Festplatte, ein Prozessor, unterschiedliche Anzahl von Kernen, wie z.B. 6-12.

• Hardware für Compute-Knoten. Typischerweise 256 oder 144 GB Speicher, zwei Prozessoren, 24 Kerne. 4-6 TB direkt angeschlossener Speicher, typischerweise in einer RAID 5-Konfiguration.

• Hardware für Speicherknoten. Typischerweise ist der Festplattenspeicher für die niedrigsten Kosten pro GB Speicherplatz optimiert, während die Effizienz des Racks erhalten bleibt.

Auch hier hängt die richtige Antwort von Ihrer Umgebung ab. Sie müssen Ihre Entscheidung auf der Grundlage der Kompromisse zwischen Raumnutzung, Einfachheit und I/O-Leistung treffen.

Netzwerkkonfiguration

Die Netzwerkkonfiguration ist ein sehr großes Thema, das sich über mehrere Bereiche dieses Buches erstreckt. Stellen Sie zunächst sicher, dass Ihre Server PXE booten und erfolgreich mit dem Bereitstellungsserver kommunizieren können.

Beispielsweise können Sie normalerweise keine NICs für VLANs beim PXE-Boot konfigurieren. Außerdem können Sie normalerweise nicht PXE-Boot mit gebundenen NICs durchführen. Wenn Sie in dieses Szenario geraten, sollten Sie einen einfachen 1 GB-Switch in einem privaten Netzwerk verwenden, in dem nur Ihre Cloud kommuniziert.

Automatisierte Konfiguration

Der Zweck des automatischen Konfigurationsmanagements ist es, die Konsistenz eines Systems ohne menschliches Zutun herzustellen und aufrechtzuerhalten. Sie möchten die Konsistenz Ihrer Implementierungen aufrechterhalten, damit Sie jedes Mal die gleiche Cloud haben, wiederholbar. Der richtige Einsatz von automatischen Konfigurationsmanagement-Tools stellt sicher, dass Komponenten der Cloud-Systeme in bestimmten Zuständen sind, und vereinfacht die Bereitstellung und Verbreitung von Konfigurationsänderungen.

Diese Tools ermöglichen es auch, Änderungen zu testen und zurückzusetzen, da sie vollständig wiederholbar sind. Praktischerweise wurde in diesem Bereich ein großer Teil der Arbeit von der OpenStack-Community geleistet. Puppet, ein Konfigurationsmanagement-Tool, bietet sogar offizielle Module für OpenStack-Projekte in einem OpenStack-Infrastruktursystem namens Puppet OpenStack. Das Konfigurationsmanagement für Chef wird innerhalb von OpenStack Chef Repo bereitgestellt. Weitere Konfigurationsmanagementsysteme sind Juju, Ansible und Salt. Außerdem ist PackStack ein Befehlszeilenprogramm für Red Hat Enterprise Linux und Derivate, das Puppet-Module verwendet, um eine schnelle Bereitstellung von OpenStack auf bestehenden Servern über eine SSH-Verbindung zu unterstützen.

Ein integraler Bestandteil eines Konfigurationsmanagementsystems ist das Element, das es steuert. Sie sollten alle Elemente, die Sie automatisch verwalten lassen möchten oder nicht, sorgfältig in Betracht ziehen. Beispielsweise möchten Sie möglicherweise keine Festplatten mit Benutzerdaten automatisch formatieren.

Fernverwaltung

Nach unserer Erfahrung sitzen die meisten Betreiber nicht direkt neben den Servern, auf denen die Cloud läuft, und viele besuchen nicht unbedingt gerne das Rechenzentrum. OpenStack sollte vollständig fernkonfigurierbar sein, aber manchmal läuft nicht alles nach Plan.

In diesem Fall ist es ein Segen, einen Out-of-Band-Zugriff auf Knoten mit OpenStack-Komponenten zu haben. Das IPMI-Protokoll ist hier der De-facto-Standard, und die Anschaffung von Hardware, die es unterstützt, wird dringend empfohlen, um das Ziel eines ausgeleuchteten Rechenzentrums zu erreichen.

Darüber hinaus sollten Sie auch die Fernsteuerung in Betracht ziehen. Während IPMI normalerweise den Stromversorgungszustand des Servers steuert, kann der Fernzugriff auf die PDU, an die der Server angeschlossen ist, wirklich nützlich sein, wenn alles verkeilt erscheint.

Weitere Überlegungen

Sie können Zeit sparen, indem Sie die Anwendungsfälle für die zu erstellende Cloud verstehen. Die Anwendungsfälle für OpenStack sind vielfältig. Einige beinhalten nur die Speicherung von Objekten, andere erfordern vorkonfigurierte Compute-Ressourcen, um die Einrichtung der Entwicklungsumgebung zu beschleunigen, und wieder andere benötigen eine schnelle Bereitstellung von Compute-Ressourcen, die bereits pro Mandant mit privaten Netzwerken gesichert sind. Ihre Benutzer benötigen möglicherweise hochredundante Server, um sicherzustellen, dass ihre Legacy-Anwendungen weiterhin ausgeführt werden. Vielleicht wäre es ein Ziel, diese Legacy-Anwendungen so zu gestalten, dass sie auf mehreren Instanzen in einer cloudy, fehlertoleranten Weise laufen, aber es nicht zu einem Ziel machen, diese Cluster im Laufe der Zeit zu erweitern. Ihre Benutzer können angeben, dass sie aufgrund der starken Nutzung des Windows-Servers Skalierungsüberlegungen benötigen.

Sie können Ressourcen sparen, indem Sie nach der besten Lösung für die Hardware suchen, die Sie bereits installiert haben. Möglicherweise haben Sie eine High-Density-Speicherhardware zur Verfügung. Sie können diese Server für OpenStack Object Storage formatieren und neu verwenden. All diese Überlegungen und Anregungen von Anwendern helfen Ihnen, Ihren Anwendungsfall und Ihren Bereitstellungsplan zu erstellen.

Tipp

Für weitere Informationen über die OpenStack-Bereitstellung untersuchen Sie die unterstützten und dokumentierten vorkonfigurierten, vorkonfigurierten Installationsprogramme für OpenStack von Unternehmen wie Canonical, Cisco, Cloudscaling, IBM, Metacloud, Mirantis, Rackspace, Red Hat, SUSE, und SwiftStack.