Deploying Solaris 11 with. Thorsten Schlump T-Systems International GmbH

Transkript

1 Deploying Solaris 11 with OpenStack and LDAP based Puppet Thorsten Schlump T-Systems International GmbH

2 INHALTSVERZEICHNIS TOC 1. Einleitung 2. Puppet mit LDAP 3. Installation OpenStack mit Puppet 4. Netzwerk Layout 5. Vom Image zum Unified Archive 6. OpenStack Instanzen im LDAP 7. Workflow Deployment mit OpenStack 8. Ausblick und Fazit 2

3 Einleitung Warum OpenStack?

4 Einleitung Warum OpenStack? freie Architektur für Cloud Computing besteht aus zusammenhängenden Modulen Infrastructure-as-a-Service (IaaS) Generischer Ansatz für Software Defined Everything Diverse Einsatzmöglichkeiten (Private/Public Cloud etc.) Über 500 Firmen nehmen am Projekt teil Nutzerzahl wächst rasant 4

5 Einleitung Vergleich aktuelles Deployment vs. OpenStack Dynamic Toolset (DT) Tool zur Definition von Systemen plattformunabhängiger Ansatz Mandantenfähigkeit vollständige Konfigurationsmöglichkeit Verwendung durch Admin beinhaltet kein Plattformmanagement LDAP für User und Konfigurationen OpenStack freie Architektur für Cloud Computing plattformunabhängiger Ansatz Mandantenfähigkeit minimale Konfigurationsmöglichkeit Verwendung durch Kunde möglich Definition von Kontingenten möglich LDAP für User möglich, Konfigurationen werden vom OpenStack selbst verwaltet 5

6 Puppet mit LDAP External Node Classifier (ENC)

7 Puppet mit LDAP External Node Classifier (ENC) Sicherheitsebenen für den Zugriff auf den Puppet Master Der Domain Name des Full Qualified Domain Name (FQDN) muss im Puppet Master als gültig markiert sein Ansonsten erhält der Client kein signiertes Zertifikat (Sicherheitsebene 1) Der Domain Name des FQDN wird als Suchpfad im LDAP verwendet zz.ux.sys => dc=zz,dc=ux,dc=sys Hier muss nun eine Konfiguration für den Hostnamen gefunden werden Nur dann wird ein Katalog erstellt (Sicherheitsebene 2) Navigation im LDAP Baum Der Katalog enthält nicht nur Daten dieser Konfiguration, auch Referenzen sind möglich parentnode => cn=192_168_192_0,ou=profile, dc=zz,dc=ux,dc=adm:2 7

8 Puppet mit LDAP die leichte Art top-scope variablen zuzuweisen Fakten vom System (IST) Attribute aus LDAP (SOLL) Zur Verfügung stehende Daten ipaddress => iphostnumber = $::ipaddress = $::iphostnumber =

9 Installation OpenStack mit einem puppet Modul

10 Installation OpenStack mit einem puppet Modul Zusätzliche Attribute in der Konfiguration puppetvar => mode=osm puppetvar => osm=zzuxosm1 osm == Hostname => Controller Node Keystone Glance Nova Horizon Cinder Neutron osm!= Hostname => Compute Node Nova 10

11 Installation OpenStack Compute Services 11

12 Netzwerk Layout Internes und externes Netz

13 Netzwerk Layout internes Netz VXLAN = Virtual Extensible LAN VNI = VXLAN Network Identifier 13

14 Netzwerk Layout Externes Netz 14

15 Netzwerk Layout Netzwerktopologie 15

16 vom Image zum Unified Archive Einsatz der Basis Installation

17 vom Image zum Unified Archive Einsatz der Basis Installation Modifikation der Basis Installation Installation eines zusätzlichen IPS Paketes openstack/ngz mit folgender Funktion: 1. Service zur Anpassung der Zone beim Start a. Modifikation der Hosttabelle damit IP zum FQDN passt b. Löschen aller Puppet Keys / Konfigurationen die nicht dem FQDN entsprechen c. Prüfung Routing im internen Netz (Erreichbarkeit Puppet Master) d. Verifikation gültiger root Benutzer (Cron) 2. Service um den Puppet Agent vom obigem Service abhängig zu machen Erstellung des Unified Archives # archiveadm create -z zzux0000 -e /var/tmp/ngz-sol11cpu0715-sparc.uar 17

18 OpenStack Instanzen im LDAP dynamische Synchronisierung

19 OpenStack Instanzen im LDAP Dynamische Synchronisierung (alt) Erste Variante (überholt): Synchronisierung aus der globalen Zone Periodisch wird auf jedem OpenStack Server ein Skript gestartet das folgende Aktionen durchführt: 1. Auflistung der aktiven Zonen 2. Prüfung ob bereits bearbeitet (lokale Datei und danach Anfrage an LDAP) 3. Zusammenstellung Daten der aktuellen Zone (Name, IP etc.) 4. Erstellung Hostkonfiguration über SSH Automatisierungsschnittstelle des DT Die Verteilung des Skriptes und der SSH Schlüssel erfolgt über ein IPS Paket openstack/gz im Rahmen der OpenStack Installation. Hauptproblem dieser Variante Änderungen eintragen wäre machbar, aber Löschen ist schwierig 19

20 OpenStack Instanzen im LDAP Dynamische Synchronisierung (neu) SSH Zugriff auf das DT limitiert Der SSH Zugriff auf das DT bedingt einen Schlüsselaustausch Seit der neusten Version gibt es aber eine SOAP Schnittstelle (XML über HTTPS) Zweite Variante (derzeit genutzt): Synchronisierung aus der Instanz heraus Es existiert bereits ein Skript das die OpenStack Instanz beim Start anpasst. Dieses Skript wird nun erweitert: Beim Start wird über die SOAP Schnittstelle die LDAP Konfiguration angelegt Beim Stopp wird über die SOAP Schnittstelle die LDAP Konfiguration gelöscht Damit ist auch das Problem der Änderungen gelöst, da eine Änderung der relevanten Konfigurationsdaten einen Neustart der Instanz bedingt. 20

21 Workflow Deployment mit OpenStack Lebenszyklus der Instanzen

22 Workflow Deployment mit OpenStack Lebenszyklus der Instanzen Instanz wird in Horizon erstellt/gestartet Service prüft die lokale Konfiguration, erstellt die LDAP Konfiguration, und der Puppet Agent übernimmt die weitere Anpassung Service löscht die LDAP Konfiguration Instanz wird in Horizon gelöscht/gestoppt 22

23 Ausblick und Fazit zukünftige Optimierungen

24 Ausblick und Fazit zukünftige Optimierungen Zentraler Speicherort für Systemkonfigurationen ist LDAP. Daher ist bei Systemen ohne native LDAP Anbindung eine Schnittstelle nötig. Die derzeitige Skript Schnittstelle funktioniert gut, ist aber nicht perfekt. Optimal wäre es wenn OpenStack direkt LDAP für Systemkonfigurationen nutzen könnte. Ein erster Ansatz ist das Modul nova.network.ldapdns. Ein anderer Ansatz basiert auf einer direkten Steuerung durch OpenStack. Ein Impuls löst über eine Schnittstelle eine Aktion im LDAP aus. Diverse Ansätze wie Logging, Messaging und Telemetrie werden derzeit evaluiert. 24

25 Ausblick und FAZIT Einsatz T-Systems Mit OpenStack können wir dem Kunden eine Managed Cloud anbieten Diese Cloud kann vom Kunden im Rahmen der bestellten Kontingente selbst verwaltet werden Es wird das Standard Solaris Image verwendet, daher kein großer Mehraufwand in der Bereitstellung Da OpenStack ein generischer Ansatz ist sind Teile auch für andere Derivate nutzbar und erlauben den Austausch von Komponenten 25

26 Fragen? 26

27 Vielen Dank!