SDB:KIWI Kochbuch Wolke mit ONebula
| Getestet mit openSUSE | Empfohlene Artikel | Verwandte Artikel | |||
|
|
|
|
||
Inhaltsverzeichnis
Erstelle eine private Wolke unter Verwendung von OpenNebula
Dieses Beispiel wird Sie durch alle Schritte führen, um die Infrastruktur für Ihre eigene Wolke zu erstellen. Sie basiert auf OpenNebula. Dieses Beispiel führt Sie durch den Bau von 3 separaten Abbildern: einem Haupt-Knoten-Abbild (Head Node Image), einem Wolken-Knoten-Abbild (Cloud Node Image), und einem Gast Image. Sind das Head Node Image und das Cloud Node Image erstellt, kann die Wolken-Infrastruktur auf einer geeigneten Hardware in weniger als 10 Minuten angewendet werden. Das Hinzufügen von Wolken-Knoten in der Zukunft benötigt weniger als 5 Minuten.
Ab KIWI-Version 4.91.3 enthält das Paket kiwi-doc das Beispiel suse-nebula-cloud in dem speziellen Verzeichnis der Version /usr/share/doc/packages/kiwi/examples/extras.
Die Beispiele, die mit dem Paket kiwi-doc geliefert werden, werden nur auf dem gegenwärtig "unterstützten" openSUSE-Versionen getestet und unterstützt.
Bevor Sie beginnen, entscheiden Sie, ob Sie das Beispiel während der Erstellung modifizieren wollen, um das Abbild an Ihre Bedürfnisse anzupassen. Wenn Sie Modifizierungen machen wollen, wird empfohlen, dass Sie die Beispielkonfigurationsbäume in ein Arbeitsverzeichnis kopieren. Zum Beispiel:
Wollen Sie keine Veränderungen durchführen, können Sie einfach die Kommandos verwenden, die in der Datei '.readme (unter /usr/share/doc/packages/kiwi/examples/extras/<VERSION>/suse-nebula-cloud.readme).
Dieses Beispiel zur Wolkeninfrastruktur verwendet KVM (die virtuelle Maschine mit Linux Kernel) als die darunter liegende Virtualisierungstechnologie. Daraus ergibt sich, dass Sie nur das Wolken-Knoten-Abbilder auf Hardware anwenden können, die die Virtualisierungsinstruktionen unterstützen. Das Haupt-Knoten-Abbild kann in einer virtuellen Maschine oder einer "weniger bedeutenden" Maschine laufen. Wenn das Haupt-Knoten-Abbild als Gast der Wolke läuft, könnte das Probleme verursachen. So ist wahrscheinlich die "weniger bedeutende" Maschine mit einer Menge Speicherplatz die beste Wahl.
OpenNebula unterstützt ebenso die Verwendung von Xen als die darunter liegende Virtualisierungstechnologie. Wenn Sie Xen bevorzugen, müssen Sie angemessene Änderungen in den Konfigurationsdateien (config.xml für die Haupt- und Wolken-Knoten durchführen. Alles andere sollte das Gleiche bleiben (der Xen-Einsatz wurde nicht getestet).
Die Grundkonzepte von Kwi: Konfigurationsbäume, Konfigurationsdateien usw. wurden in anderen Beispielen erklärt. Bitte konsultieren Sie die grundlegenderen Beispiele zuerst. Machen Sie dieses Wolken-Beispiel nicht zu Ihrem ersten Kiwi-Projekt.
Zur Wolkenadministration lesen Sie bitte die OpenNebula Dokumentation.
Erstellung des Haupt-Knotens
Wir lassen die Einführungen hinter uns und fahren direkt mit dem Thema fort. Die Grundlagen der Wolken-Berechnung sind anderswo im Internet gut erklärt und darum werden wir unsere Aufmerksamkeit auf die Besonderheiten des OpenNebula-Beispiels konzentrieren. Wenn Sie die blutigen Details wissen wollen, lesen Sie bitte die OpenNebula Seiten.
Erstellung der Haupt-Knoten-Konfiguration
Der Haupt-Knoten-Konfigurations-Baum ist enthalten in /usr/share/doc/packages/kiwi/examples/extras/<VERSION>/suse-nebula-cloud/cloud_head. Lassen Sie uns zuerst einen Blick in die Datei config.xml werfen. Die Typensektion ist wie folgt konfiguriert:
<type image="oem" filesystem="ext3" boot="oemboot/suse-11.4" installstick="true" installboot="install" boottimeout="2">
<oemconfig>
<oem-boot-title>OpenNebula Head Node</oem-boot-title>
<oem-shutdown>true</oem-shutdown>
<oem-swap>true</oem-swap>
<oem-swapsize>2048</oem-swapsize>
<oem-unattended>true</oem-unattended>
</oemconfig>
</type>
Das Abbild ist ein OEM-Abbild. Es ist selbst installierend, wie durch den Wert des image Attributs angezeigt. Der Wert des boot-Attributes könnte in Ihrer config.xml-Datei anders sein, abhängig von der Version des Beispiels, das Sie beleuchten. Das Abbild ist eingerichtet, um vom USB-Stick ausgeführt zu werden, wie durch den Wert des installstick-Attributs festgelegt. Mit dem installstick-Attribut wählen wir die Standard-Boot-Option aus, der der Installations-Modus sein soll, im Gegensatz zum Start von der Festplatte. Das boottimeout Attribut bestimmt die Zeit, die der Bootloader warten wird, bis die ausgewählte Option startet. Der Grundkonfiguration des Typs folgend, sind einige spezielle Optionen für das OEM-Abbild eingerichtet. Zuerst wird der Start-Titel für das eingesetzte Abbild für den OpenNebula Haupt-Knoten unter Verwendung des <oem-boot-title>-Elements festgelegt. Der Wert das <oem-shutdown>-Elements ist auf true zu setzen, um das System nach der Einrichtung herunter zu fahren. In Kombination mit der <oem-unattended>-Funktion erlaubt dieses Ihnen, den Stick an Ihre Zielmaschine anzuschließen, einzuschalten und weg zu gehen. Wenn Sie zurück kommen und die Maschine ist aus, dann wissen Sie, dass die Einrichtung abgeschlossen ist. Komfortabel.
Das Root-Passwort ist auf cloudDemo und Benutzersektion der Datei config.xml eingestellt. Allerdings wird das Root-Passwort während der Erststart-Prozedur geändert. Diese Konfiguration ist aber irrelevant. Mehr unten zur Erststart-Prozedur.
<users group="root">
<user pwd="cloudDemo" pwdformat="plain" home="/root" name="root"/>
</users>
Bevor wir zur nächsten Datei im Konfigurationsbaum gehen, schauen wir auf die Konfiguration der Repositorys. Zusätzlich zum Standard-Repository der Distributions-Version wird das Repository des Virtualisierungsprojektes Wolke OpenNebula vom openSUSE Build Service hinzugefügt. Dieses Repository liefert die Pakete, die notwendig sind, um OpenNebula als Wolken-Infrastruktur zu installieren.
Der Rest der Datei config.xml ist Standard und sollte selbsterklärend sein.
Als nächstes lassen Sie uns das Script config.sh betrachten. Die Einträge
suseInsertService nfsserver suseInsertService sshd
aktivieren den NFS und SSH Service auf dem System. OpenNebula verwendet SSH für Aktionen zwischen den Wolken-Knoten und dem Haupt-Knoten. Der NFS-Server wird benötigt, um das Home-Verzeichnis des Wolken-Administrators (oneadmin) zu exportieren und erlaubt es, NFS in die Wolken-Knoten entsprechend einzuhängen. Details über die Wolken-Administration und die Bereitstellung des Home-Verzeichnisses finden Sie unter "Planung der Installation" in der OpenNebula Dokumentation.
Nach dem Hinzufügen der Service richten wir den Willkommenstext für die Erststart-Prozedur ein, indem wir die Variable FIRSTBOOT_WELCOME_DIR unter Verwendung der von Kiwi unterstützten Funktion baseUpdateSysConfig modifizieren. Diese Funktion verändert nur vorhandene Werte. Sie fügt keine neuen Variablen in die Konfigurationsdateien ein. Wie angedeutet durch diesen Kommentar, ist IPv6 für die Wolke deaktiviert.
baseUpdateSysConfig /etc/sysconfig/firstboot FIRSTBOOT_WELCOME_DIR /usr/share/susenebula # deaktiviere IPv6 echo “alias net-pf-10 off” >> /etc/modprobe.conf.local echo “alias ipv6 off” >> /etc/modprobe.conf.local
Als letztes bringen wir einige Erlaubnisse in Ordnung, die wichtig sind, damit die Dinge funktionieren und es uns erlaubt, die Wolken-Infrastruktur als ein Nicht-Root-Benutzer zu verwenden.
# Das Verzeichnis für die Authentifizierungs-Datei muss vorhanden # sein, so dass das YaST-Modul die Datei schreiben kann. mkdir /var/lib/one/.one # Setze die gewünschte Erlaubnis chown oneadmin:cloud /var/lib/one/.one # Die Erlaubnis für den Testfall chown -R oneadmin:cloud /home/ctester
Das Verzeichnis /var/lib/one ist das Home-Verzeichnis des Benutzers oneadmin, wie durch das Paket opennebula eingerichtet, gebaut in OpenNebula project on OBS. Das Verzeichnis ctester ist im Overlay-Baum eingerichtet und kann verwendet werden, um die grundlegenden Funktionen der Wolke zu testen, die das Gastabbild verwendet, das auf der Konfiguration basiert, die mit dem Beispiel geliefert wird. Das Verzeichnis wird nicht benötigt, wenn Sie Ihre eigene Wolke bauen. Es existiert nur zur Demonstration und Überprüfung.
Grundsätzlich wird das Management der Eigentumsrechte nicht benötigt, wenn man Abbilder mit Kiwi baut. Da Kiwi grundsätzlich die geeigneten Eigentumsrechte einrichtet. In diesem Fall arbeiten wir außerhalb des Kiwi-Algorithmus zur Eigentums-Anweisung. Kiwi wendet eine einfache Regel auf das Eigentum an. Alles im Home-Verzeichnis des Benutzers ist Eigentum des Benutzers. Alles andere, was während des Baus des Abbildes erstellt wird, gehört Root. In unserem Fall müssen wir keinen Benutzer ctester in der Datei config.xml erstellen. Darum sieht Kiwi das Verzeichnis /home/ctester (vom Overlay-Baum, mehr darüber später) als ein erstelltes Verzeichnis, das dem Benutzer gehört. Dieses führt in den Kiwi-Eigentümer-Einstellungen zu Root. Da wir dieses Verzeichnis als einen Testfall für die Wolken-Infrastruktur verwenden wollen, müssen wir die Eigentumsrechte des Benutzers oneadmin auf Lese/Schreibzugriff setzen.
Andere Einträge in die Datei config.sh sind Standard und sollten zur Zeit keine weiteren Erklärungen bedürfen.
Nun lassen Sie uns einen Blick auf den Inhalt des Overlay-Baums werfen. Da das ein Beispiel für Kiwi ist, wie man Dinge einrichtet und keine Anleitung für eine gegebene Programmiersprache oder verwandte Themen ist, werden die ausführlichen Details weg gelassen.
Im Verzeichnis cloud_head/root/etc/init.d finden wir zwei neue Init-Scripts. Eins wird verwendet, um den Registrierungs-Service zu steuern und das andere ist zur Steuerung eines Informations-Services.
Das Verzeichnis cloud_head/root/etc/init.d enthält die Datei firstboot.xml, das das Verfahren für den Erststart-Prozess beschreibt. Die Variable FIRSTBOOT_WELCOME_DIR, die in config.sh eingerichtet ist, wie oben gezeigt, macht den Erststart-Prozess mit der speziellen Willkommensbotschaft, die in cloud_head/root/usr/share/susenebula/welcome.txt zu finden ist, bekannt. Der Erststart-Prozess ist eingerichtet, eine Lizenz anzuzeigen, wenn vorhanden, und läßt den Benutzer die Tastaturbelegung konfigurieren, die Zeit und das Datum und das Root-Passwort. Das sind Standard YaST-Module. Der abschließende Konfigurationsschritt, der in firstboot.xml eingerichtet wird, ist ein Modul mit Namen opennebula.ycpund ist unter cloud_head/root/usr/share/YaST2/clients/ zu finden. Dieses Modul wird benötigt, um die Information einzurichten, um die Haup-Knoten-Einrichtung zu komplettieren. Das Script cloud_head/root/usr/share/firstboot/scripts/finalizeSetup (in Python geschrieben) vervollständigt die Einrichtung und läuft nachdem allen "GUI"-basierenden Schritten in der Erststart-Prozedur komplett sind. Informationen über die Konfigurierung des Erststart-Prozesses finden Sie unter YaST Erststart-Dokumentation. Informationen über ycp, die Implementierungssprache für YaST-Module finden Sie unter YaST Dokumentation. Ein abschließender Teil, der sich auf den Erststart im Overlay-Baum bezieht ist die Datei cloud_head/root/var/lib/YaST2/reconfig_system. Diese Datei ist leer und ist eine Trigger-Datei, um den Erststart-Prozess zu starten, einfach indem sie vorhanden ist.
Die Service, die von den Init-Scripten, wie oben erwähnt, gesteuert werden, sind cloud_head/root/sbin/suseNebulaRegSrv und cloud_head/root/sbin/suseNebulaConfSrv. Beide Service sind in Python integriert. suseNebulaRegSrv ist der Anmelde-Service, der es dem Wolken-Knoten erlaubt, sich selbst beim Erststart (Wolken-Knoten-Erststart) anzumelden. Das ist im Grundsatz ein Service, der auf eine Verbindung an der Netzwerk-Schnittstelle (eingerichtet während des Erststarts des haupt-Knotens) am Port 8445 wartet und die auf der Information basieren, die vom verbundenen Absender geliefert wird, der den Wolken-Knoten mit dem Wolken-Infrastruktur-Kode erfasst, der auf dem Haupt-Knoten läuft. Der Registrierungs-Service modifiziert ebenso die Datei /etc/dhcpd.conf, um sicher zu stellen, dass der registrierte Knoten immer die gleiche IP-Adresse erhält. Andernfalls müsste sich die Anmeldung bei der Wolken-Infrastruktur bei jedem Start des Wolken-Knotens ändern. Und das ist nicht unbedingt notwendig. Der Informations-Servis, der in suseNebulaConfSrv implementiert ist, liefert eine Information zu einem Wolken-Knoten so, dass sich der Wolken-Knoten selbst konfigurieren kann. Die gelieferte Information enthält die Benutzer- und Gruppen-Information des oneadmin-Kontos, das automatisch durch das Paket opennebula auf dem Haupt-Knoten erstellt wird. Es enthält ebenso die IP-Adresse des Haup-Knotens, die vom Wolken-Knoten-Kode verwendet wird, um die Einhänge-Information (mount information) in /etc/fstab einzurichten. Mehr dazu im Abschgnitt Wolken-Knoten. Schauen Sie sich den Kode an, um alle Informationen zu sehen, die vom Informations-Service geliefert werden.
Wir haben eine Datei exports unter cloud_head/root/etc/exports. Die Datei exportiert einfach das Verzeichnis /var/lib/one, so dass NFS eingehängt werden kann.
Schließlich kommen wir im Verzeichnis cloud_head/root/home/ctester an. Die Inhalte dieses Verzeichnisses sind, streng genommen, zur Unterstützung der schnellen Verifizierung der Funktionalität der Wolken-Einrichtung. Sind der Haupt-Knoten und ein Wolken-Knoten eingerichtet, kann man einfach das Abbild .qcow2 kopieren, das vom Abbild Wolken-Gast (cloud_guest) im Verzeichnis /home/ctester und dem Lauf des startTestVM-Scripts sowie dem Benutzer oneadmin erstellt wurden. Das wird das Abbild anmelden und eine VM (Virtual Machine) des Abbildes starten. Die Dateien testVM.one und testVM.vmd sind Konfigurationsdateien von OpenNebula zur Abbild-Registrierung und VM (Virtual Machine)-Einrichtung. Details zu den Konfigurationsdateien finden Sie in den Dokumentationen Image Definition und VM Definition. Die Datei .README hat eine kurze Gedächtnisstütze über all dies.
Bevor wir fortfahren, die Einrichtung des Wolken-Knoten zu untersuchen, einige Details zur Einrichtung des Haupt-Knoten. Der Haupt-Knoten betreibt einen DHCP-Server (nur IPv4) auf einer konfigurierten Netzwerkbrücke (br0). Die Brücke hat die statische IP-Adresse, die während des Erststarts eingerichtet wurde und besitzt einen Alias für den Link der lokalen IP von 169.254.1.1. Der Link der lokalen IP wird verwendet, als die lauschende IP für den Informations-Service an Port 8445. Damit können wir die Informations-Erkennung des Wolken-Knoten fest kodieren, um diesen Alias zu verbinden. Keine dynamische Erkennung über Avahi ist erforderlich (Avahi würde in diesem Fall ein Overkill sein). Weiterhin wurde unser DHCP-Server eingerichtet, damit er eine "spezielle Funktion" besitzt. Die erscheint im YaST-Modul opennebula.ycp. Diese "spezielle Funktion" erkennt diesen DHCP-Server. Und wir verwenden ihn, um sicher zu stellen, dass der Wolken-Knoten nur das Leasing von diesem DHCP-Server akzeptiert. So, auch wenn andere DHCP-Server im Netzwerk vorhanden sind, werden unsere Wolken-Knoten keine Leasings akzeptieren, außer sie werden vom Wolken-Haupt-Knoten angeboten. Details zur Verwendung dieser netten kleinen Funktion können Sie durch Erkundung des opennebula.ycp-Kodes erfahren oder Sie konsultieren die DHCP man pages.
Das erklärt die Abbild-Einrichtung des Haupt-Knotens sehr gut und deckt die Grundeinstellung und Funktionalität zum Betreiben eines Haupt-Knotens ab. Es ist Zeit mit dem Wolken-Knoten-Abbild fortzufahren.
Erstellung des Wolken-Knoten
Für einen OpenNebula-Wolken-Knoten benötigen wir nichts als eine Maschine, auf der ein Hypervisor läuft. Auf dem Wolken-Knoten ist kein OpenNebula-Kode eingerichtet. Der benötigte OpenNebula-Kode ist in der NFS des eingehängten Home-Verzeichnis des Benutzers oneadmin enthalten. Diese minimale Anforderung für den Wolken-Knoten spiegelt sich in der Datei config.xml für den Wolken-Knoten wieder.
Erstellung der Wolken-Knoten-Konfiguration
Der einzige Unterschied zu einer Basis-KVM, die auf einer Hypervisor-Konfiguration basiert sind die zusätzlichen Ruby-Pakete. Die Wolken-Knoten-Konfiguration wird wie ein OEM-Abbild eingerichtet, nur als der Haupt-Knoten. Darum unterscheidet sich die Definition des <type>-Elements nur im Titel für das GRUB-Menü von der Haupt-Knoten-Definition. So ist für den Haupt-Knoten ein Root-Passwort eingerichtet. Aber das ist unbedeutend, da der Wolken-Knoten, als Teil der Selbstkonfiguration, das Root-Passwort erben wird, das während der Haupt-Knoten-Konfiguration eingerichtet wurde.
Die Datei config.sh schaltet IPv6 ab, so wie es die Haupt-Knoten-Konfiguration macht, und richtet den IPv6-DHCP-Client auf /bin/false, um den Start eines IPv6-Clients zu deaktivieren.
# Deaktivierung IPv6 baseUpdateSysConfig /etc/sysconfig/network/dhcp DHCLIENT6_BIN /bin/false echo “alias net-pf-10 off” >> /etc/modprobe.conf.local echo “alias ipv6 off” >> /etc/modprobe.conf.local sed -i "s/#net.ipv6.conf.all.disable_ipv6 = 1/net.ipv6.conf.all.disable_ipv6 = 1" /etc/sysctl.conf
Die folgende Zeile in config.sh,
baseUpdateSysConfig /etc/sysconfig/network/dhcp DHCLIENT_BIN dhclient
setzt den DHCP-Client als den ISC-Client anstelle des Standard-dhcpcd-Client ein. Der Grund für diese Einstellung ist, dass dhcpcd respektiert nicht die Einstellungen in /etc/dhclient.conf und besitzt keine Optionen die Einschränkungen zur Leasing-Akzeptanz von einem spezifizierten DHCP-Server zu konfigurieren. Die Selbstkonfiguration und Anmeldung des Wolken-Knoten ist von der DHCP-Funktion abhängig gemacht, das erlaubt es uns, den Client einzurichten, um nur ein Leasing von einem spezifizierten DHCP-Server zu akzeptieren. Darum muss der ISC-Client auf dem Wolken-Knoten (und dem Gast-Abbild) verwendet werden. Die Konfiguration des DHCP-Clients passiert im cloudNodeConfig-Script (mehr zu diesem Script unten).
Nachfolgend die Einrichtung von DHCP. Das Script config.sh verändert die Konfigurationsdatei für den Daemon libvirt.
sed -i "s/#listen_tcp = 1/listen_tcp = 1/" /etc/libvirt/libvirtd.conf
Diese Änderung erlaubt dem Daemon libvirt nach TCP-Verbindungen zu lauschen. Die OpenNebula-Infrastruktur verwendet die libvirt API, um die virtuelle Maschinen auf den Wolken-Knoten zu organisieren. Der Daemon für libvirt läuft auf den Wolken-Knoten, da das Script config.sh den Service über
suseInsertService libvirtd
während des Abbild-Bau-Prozesses einfügt. Zum Schluss wird ein Softlink von qemu-kvm erstellt, der zu dem Namen kvm ausführbar ist. Die Bezeichnung kvm ist fest in den OpenNebula-Kode kodiert und wird nicht von dem Paket qemu unterstützt. Das vervollständigt die Übersicht zur Datei config.sh.
Der Overlay-Baum für das Wolken-Knoten-Abbild ist etwas einfacher als der Overlay-Baum für den Haupt-Knoten. Der Host-Name des Knotens ist vorkonfiguriert, der Knoten-1 (node-1) in cloud_cloud/root/etc/HOSTNAME zu sein. Diese Einstellung wird während der Selbstkonfigurationsphase beim Erststart geändert. (Schließlich wollen wir nicht, dass alle Wolken-Knoten mit node-1 bezeichnet werden.) Der Haupt-Knoten unterhält einen Zähler und die Knoten bekommen einen Hostnamen benannt (Schauen Sie in der Einführung von cloud_head/root/sbin/suseNebulaConfSrv nach Details.) Die Erststartmagie wird von der Implementierung von cloud_cloud/root/etc/init.d/boot.local gehandhabt, die das Script cloud_cloud/root/usr/share/firstboot/scripts/cloudNodeConfig aufruft, wenn die Trigger-Datei cloud_cloud/root/var/lib/firstboot existiert. Das Script cloudNodeConfig findet die zuerst verbundene Netzwerkschnittstelle und konfiguriert das Netzwerk zum Link der örtlichen Adresse von 169.254.1.2. Damit läuft der Konfigurationsservice auf dem Haupt-Knoten auf 169.254.1.1. Port 8445 kann kontaktiert werden und die Konfigurations-Information ist gerettet. Als Teil der Selbstkonfiguration ist die Datei /etc/fstab auf dem Wolken-Knoten modifiziert, um eine NFS-Einhängung des Home-Verzeichnisses des Benutzers oneadmin in var/lib/one zu aktivieren. Ist erst der Knoten konfiguriert, das Produktion/Wolken-Netzwerk eingerichtet (eine Brücke mit der Bezeichnung br0) und die erhaltene DHCP-Adresse bei dem Haupt-Knoten registriert, um sicher zu stellen, dass der Wolken-Knoten die gleiche IP-Adresse erhalten wird, sollte sie neu gestartet werden. Jeder Aspekt der Selbstkonfiguration und der Registrierung des Wolken-Knotens ist im Script cloudNodeConfig enthalten (implementiert in Pyton). Schließlich enthält der Overlay-Baum folgende Policykit-Regel:
[Remote libvirt SSH access] Identity=unix-user:oneadmin Action=org.libvirt.unix.manage ResultAny=yes ResultInactive=yes ResultActive=yes
Das erlaubt den Benutzer oneadmin auf libvirt zu zu greifen und die virtuelle Maschine zu steuern, die in Ihrer Wolke läuft. Die Regel ist in der Datei cloud_cloud/root/etc/polkit-1/localauthority/50-local.d/60-suseNebula-access.pkla enthalten.
Dieses komplettiert die Konfiguration des Wolken-Knoten. Bauen Sie das Abbild gemäß den Instruktionen in der Datei .readme, die mit dem Beispiel mit geliefert wird. Ist erst der Bau abgeschlossen, können Sie das resultierende Abbild auf einen USB-Stick verfrachten und es verwenden, um so viele Wolken-Knoten wie Sie zu Ihrer Wolkeneinrichtung hinzufügen wollen, zu installieren. So wie mit dem Haupt-Knoten erfolgt die Installation in einem unbeabsichtigten Modus und die Maschine wird sich abschalten, wenn die Anfangsinstallation komplett ist. Beim Erststart (nachdem der USB-Stick entfernt ist) wird der Wolken-Knoten sich selbst konfigurieren, wie vorher diskutiert. Es ist nicht notwendig, eine Tastatur oder einen Monitor an den Wolken-Knoten anzuschließen. Schalten Sie einfach die Maschine an und beobachten Sie (tatsächlich ist da nichts zu sehen) wie die Magie passiert. Der Wolken-Knoten muss natürlich an das gleiche Netzwerk angeschlossen sein, wie der Haupt-Knoten.
Sie können den System-Log auf dem Haupt-Knoten beobachten, wann die Wolken-Knoten-Registrierung komplett ist. Oder Sie können einfach das Kommando onehost list auf dem Haupt-Knoten verwenden, um zu beobachten, wann der neue Wolken-Knoten sich zeigt. Nachrichten werden in das System-Log des Haupt-Knotens und des Wolken-Knoten geschrieben.
Einen Gast erstellen
Eine Wolken-Infrastruktur eingerichtet zu haben ist großartig, aber ohne laufende virtuelle Maschinen auf der Infrastruktur, hat die Einrichtung nicht viel von einer Wolke. Die Konfiguration eines Gast-Abbildes, das vom Kiwi-Beispiel unterstützt wird, ist nur ein rudimentäres Abbild, um das Format des Gast-Abbildes zu zeigen. Wenn Sie dieses Beispiel als einen Leitfaden verwenden, können Sie relativ leicht Ihr eigenes Gast-Abbild bauen, das Ihren Bedarf deckt. Überprüfen Sie die SUSE Gallery und Sie könnten gerade das finden, wonach Sie suchen, ohne ein Abbild bauen zu müssen. Für mehr GUI-Spass können Sie das SUSE Studio mit OpenNebula -Anleitung auf der OpenNebula-Seite verwenden, um Abbilder mit SUSE Studio zu bauen.
Die darunter liegende KVM Virtualisierungs-Technologie funktioniert glücklicher Weise ebenso mit einem VMware-Abbild, so dass Sie nicht notwendiger Weise ein ursprüngliches virtuelles KVM-Festplatten-Abbild haben müssen. Die Verwendung unterschiedlicher Abbild-Typen ist in der VM-Konfigurations-Vorlage eingerichtet. Bitte konsultieren Sie die OpenNebula Dokumentation.
Die Gast-Konfiguration erstellen
Die Datei config.xml spezifiziert nur einen minimalen Satz von Paketen. Der Schlüssel ist die Einrichtung des Elements <type>.
<type image="vmx" primary="true" filesystem="ext4" boot="vmxboot/suse-11.3" format="qcow2"/>
Das Gast-Abbild ist eine virtuelle Maschine. Folglich muss das Abbild vom Typ vmx sein, da wir KVM als Virtualisierungs-Infrastruktur für unsere Wolke gewählt haben. Wir bevorzugen es, dass unser Gast-Abbild im Format qcow2 ist. Das ist das native KVM-Format. Der Rest der Datei config.xml ist Standardzeug und sollte bekannt sein.
Das Script config.sh hat einige Anpassungen wie folgt:
baseUpdateSysConfig /etc/sysconfig/bootloader LOADER_LOCATION mbr baseUpdateSysConfig /etc/sysconfig/network/dhcp DHCLIENT_BIN dhclient # deaktiviere IPv6 baseUpdateSysConfig /etc/sysconfig/network/dhcp DHCLIENT6_BIN /bin/false echo “alias net-pf-10 off” >> /etc/modprobe.conf.local echo “alias ipv6 off” >> /etc/modprobe.conf.local sed -i "s/#net.ipv6.conf.all.disable_ipv6 = 1/net.ipv6.conf.all.disable_ipv6 = 1" /etc/sysctl.conf echo "option suse-nebula code 239 = ip-address;" >> /etc/dhclient.conf echo "require suse-nebula;" >> /etc/dhclient.conf echo "request suse-nebula;" >> /etc/dhclient.conf
Wie bei dem Haupt- und den Wolken-Knoten ist IPv6 deaktiviert. Der Ort des Bootloaders ist auf Master Boot Record (MBR) eingestellt und der ISC dhclient ist als DHCP-Client konfiguriert. Wir wollen, dass der Gast seine IP-Adresse vom DHCP-Server erhält, der auf dem Wolken-Haupt-Knoten läuft und nicht irgend ein anderer DHCP-Server auf dem Netzwerk, mit dem die Wolke verbunden ist. In diesem Beispiel ist die DHCP-Funktion, die die Annahme des Leasing-Angebot steuert, fest kodiert (die letzten 3 Zeilen des obigen Kode-Schnipsels) als Standardeinstellung der Konfiguration des Haupt-Knotens. Die feste Kodierung dieser Einstellung ist vollkommen angemessen, da Sie den Namen der Funktion kennen werden, den Sie an den DHCP-Server abgegeben haben, sobald der Hauptknoten konfiguriert ist und Sie Ihre Kiwi-Konfiguration für Ihren Gast eingerichtet haben. Wenn Sie mehrere Wolken haben oder flexibler sein wollen, können Sie eine Selbstkonfiguration zum Gast hinzufügen, gemäß den Zeilen der Wolken-Knoten-Selbstkonfiguration. Für den Gast brauchen Sie nur die DHCP-Funktion des Haupt-Knotens.
Der Overlay-Baum ist grundsätzlich leer und enthält gerade genug Informationen, um das Netzwerk im Gast zum Laufen zu bekommen.
Bauen Sie das Gast-Abbild gemäß den bereitgestellten Informationen in der Datei .readme. Das erhaltene Abbild kann leicht außerhalb der Wolke auf einer Maschine, die KVM hat, getestet werden. Sie müssen nur qemu-kvm starten und den Pfad zum Abbild angeben. Dieser Weg kann sicher stelle, dass sich Ihr Abbild so verhält, bevor Sie es in der Wolke einsetzen. Sind Sie sich der DHCP-Einstellungen in Ihrem Gast-Abbild bewusst. Wenn Sie auf einer Maschine testen, dass keinen Netzwerkzugang zum Wolken-Haupt-Knoten hat, werden Sie nicht in der Lage sein, über das Netzwerk zur Maschine zu gelangen.
Wenn Sie das endgültige Abbild in das Verzeichnis /home/ctester auf dem Wolken-Haupt-Knoten kopieren, änderen Sie seine Berechtigungen auf lesbar durch den Benutzer oneadmin und dann führen Sie das Script startTestVM als Benutzer oneadmin aus. Das erstellte Gast-Abbild wird in die Wolke eingesetzt werden. Der Gast lässt sshd laufen, so dass Sie sich damit verbinden können. Oder Sie können vncviewer auf Port 5905 (siehe estVM.vmd) des Wolken-Knotens verwenden, wo die virtuelle Maschine angeordnet wurde (verwende onevm list, um die Information zu erhalten).
Bevor wir zum Ende kommen, eine kurze Bemerkung zum Benutzer-Konto oneadmin. Der Benutzer wird vom Paket opennebula von OBS eingerichtet. Und während der Installation wird ein willkürliches Passwort für den Benutzer oneadmin generiert. Ebenso erzeugt das Paket einen SSH-Schlüssel für das oneadmin Benutzer-Konto. Es ist nicht notwendig sich als der Benutzer oneadmin anzumelden um die OpenNebula-Wolke zu bedienen. Für Instruktionen, die sich auf "als der Benutzer oneadmin arbeiten" beziehen, verwenden Sie das Kommando sudo -u oneadmin. Als Administrator steht es Ihnen natürlich frei, dieses Verhalten gemäß Ihren Wünschen zu ändern.
Wie wäre es mit einer GUI
OpenNebula unterstützt eine Web-UI zum Mamagement der Wolke über den Service Sunstone. Die Konfiguration, enthalten in Kiwi-Version 4.91.3, aktivierte nicht oder bedachte nicht den Web-UI-Service. Die so ab Kiwi-Version 4.92.3 gelieferte Konfiguration unterstützt die Verwendung des Sunstone-Service. Das Init-Script sunstone wird vom Script finalizeSetup modifiziert, das am Ende der Erststart-Prozedur läuft. finalizeSetup richtet die IP-Adresse des Haupt-Knotens und den Ort der Berechtigungsdatei im Init-Script sunstone ein. Der sunstone-Service wird in die Init-Sequenz eingefügt. Nachdem das System gestartet ist, können Sie die Web-UI an Port 4567 von einem Browser, der auf einer Maschine läuft, der sich mit dem Haupt-Knoten verbinden kann, anschließen.
Zusammenfassung
Das Beispiel liefert alles, was Sie brauchen, um eine "Wolke in einer Box" zu haben. In weniger als 2 Stunden können Sie eine private Wolke fertig und laufen haben.
Zur Administration einer Wolke konsultieren Sie bitte die OpenNebula-Dokumentation.