OpenStack — Eine Private Cloud von Grund auf aufbauen

Ein Kunde aus dem Finanzsektor brauchte Cloud — konnte aber aus regulatorischen Gründen die Daten nicht außerhalb des eigenen Rechenzentrums platzieren. Public Clouds wie AWS kamen nicht in Frage. Wir beschlossen, eine Private Cloud auf OpenStack aufzubauen.

Warum OpenStack?¶

Auf dem Private-Cloud-Markt gab es 2014 mehrere Alternativen: VMware vCloud Suite (teuer, aber bewährt), CloudStack (einfacheres Deployment) und OpenStack (größte Community, modulare Architektur). Der Kunde wollte eine herstellerunabhängige Lösung ohne Lock-in an einen einzelnen Anbieter. OpenStack — unterstützt von Unternehmen wie Rackspace, IBM, HP, Red Hat und Dutzenden anderen — war die logische Wahl.

Im April 2014 erschien das Icehouse-Release mit deutlichen Stabilitätsverbesserungen und neuen Funktionen in der Netzwerkschicht. Darauf bauten wir auf.

OpenStack-Komponenten¶

OpenStack ist kein einzelnes Produkt — es ist ein Ökosystem von Diensten, wobei jeder einen Aspekt der Cloud-Infrastruktur abdeckt:

• Keystone — Identität und Authentifizierung, zentrale Verwaltung von Benutzern und Tenants
• Nova — Compute-Dienst, verwaltet den Lebenszyklus virtueller Maschinen
• Neutron — Netzwerkdienst, virtuelle Netzwerke, Subnetze, Router, Firewalls
• Cinder — Block Storage, persistente Festplatten für VMs
• Glance — Registry von Betriebssystem-Images
• Horizon — Web-Dashboard zur Verwaltung
• Swift — Object Storage (analog zu S3)
• Heat — Orchestrierung, Infrastructure-as-Code-Templates

Hardware und Topologie¶

Wir setzten OpenStack auf 12 physischen Servern in einem Rack ein: 3 Controller-Knoten (HA), 8 Compute-Knoten und 1 Storage-Knoten mit einem Ceph-Cluster. Jeder Compute-Knoten hatte zwei Xeon E5-2650 v2 Prozessoren, 128 GB RAM und 2× SSD für Ephemeral Storage. Das Netzwerk war 10 GbE mit dedizierten VLANs für Management, Tenant-Traffic und Storage.

# OpenStack — Eine Private Cloud von Grund auf aufbauen
heat_template_version: 2014-10-16

resources:
  web_server:
    type: OS::Nova::Server
    properties:
      image: ubuntu-14.04-lts
      flavor: m1.medium
      key_name: deploy-key
      networks:
        - network: { get_resource: internal_net }

  floating_ip:
    type: OS::Neutron::FloatingIP
    properties:
      floating_network: external

  association:
    type: OS::Neutron::FloatingIPAssociation
    properties:
      floatingip_id: { get_resource: floating_ip }
      port_id: { get_attr: [web_server, addresses, internal_net, 0, port] }

Neutron: Die Netzwerkschicht als größte Herausforderung¶

Wenn Nova das Herz von OpenStack ist, dann ist Neutron sein komplexestes Organ. Virtuelle Netzwerke, Floating-IP-Adressen, Security Groups, Load Balancer — alles wird von Neutron verwaltet. Und 2014 war es auch die Komponente mit den meisten Bugs.

Wir wählten Open vSwitch als Netzwerk-Backend mit VXLAN-Tunneln zwischen den Compute-Knoten. Jeder Tenant hat ein isoliertes virtuelles Netzwerk — er kann den Traffic eines anderen Tenants nicht sehen. Security Groups implementieren eine zustandsbehaftete Firewall auf Port-Ebene.

Das größte Problem: Der Neutron L3 Agent war ein Single Point of Failure. Wenn der Netzwerk-Knoten ausfiel, funktionierten alle Floating IPs nicht mehr. Die Lösung — Distributed Virtual Router (DVR) — war in Icehouse experimentell. Wir setzten einen HA L3 Agent mit VRRP-Failover ein.

Ceph als Storage-Backend¶

Für Cinder (Block Storage) und Glance (Image Registry) wählten wir Ceph als Backend — ein verteiltes Speichersystem. Drei OSD-Knoten mit insgesamt 24 Festplatten stellten redundanten Speicher mit einem Replikationsfaktor von 3 bereit.

Der Vorteil der Ceph + OpenStack-Integration: Copy-on-Write-Klonen. Das Erstellen einer neuen VM aus einem Image dauert Sekunden — Ceph erstellt lediglich einen Thin Clone; die tatsächlichen Daten werden erst beim ersten Schreibvorgang kopiert.

Deployment-Automatisierung¶

Die manuelle Installation von 12 Servern hätte Wochen gedauert. Wir nutzten Puppet mit Modulen von stackforge (heute openstack-puppet) für die automatisierte Konfiguration aller Komponenten. Der gesamte Cluster konnte innerhalb von zwei Stunden „gelöscht und neu erstellt” werden — entscheidend für das Testen von Upgrades.

Betriebserfahrung¶

Monitoring¶

OpenStack generiert enorme Mengen an Logs. Wir setzten einen ELK Stack und Nagios für das Monitoring der API-Endpunkte ein. Die Schlüsselmetrik: API-Antwortzeit. Wenn die Nova-API länger als 2 Sekunden zum Antworten braucht, stimmt etwas nicht — typischerweise ein überlasteter RabbitMQ oder ein voller Compute-Knoten.

Upgrades¶

Das Upgrade von OpenStack zwischen Versionen ist notorisch schwierig. Jede Komponente hat eigene Datenbankmigrationen, API-Versionen ändern sich und Konfigurationen werden umbenannt. Unsere Strategie: Blue-Green Deployment der Controller-Knoten — die neue Version auf Standby-Knoten deployen, Traffic umschalten, alte Knoten als Fallback behalten.

Ergebnisse nach dem ersten Jahr¶

Auf dem Cluster laufen über 200 virtuelle Maschinen über 8 Tenants verteilt. Das Provisioning einer neuen VM dauert unter 30 Sekunden. Entwickler erstellen ihre Umgebungen selbst über das Horizon-Dashboard oder die CLI — kein Ticket beim Infrastruktur-Team nötig. Plattformverfügbarkeit im ersten Jahr: 99,95 %.

OpenStack ist nicht für jeden, aber für die richtigen Anwendungsfälle ausgezeichnet¶

OpenStack erfordert ein dediziertes Team — mindestens zwei Personen im Vollzeit-Betrieb. Es ist kein „Installieren und Vergessen”. Aber für Organisationen, die Cloud brauchen und nicht in eine Public Cloud gehen können oder wollen, ist es die beste Open-Source-Alternative.

Die wichtigste Lektion: Starten Sie mit einer minimalen Konfiguration (Nova, Neutron, Cinder, Keystone), bewähren Sie sie in der Produktion und fügen Sie erst dann weitere Dienste hinzu.