Abbildanforderungen

Linux

Für ein Linux-basiertes Abbild, das volle Funktionalität in einer OpenStack Compute Cloud hat, gibt es ein paar Anforderungen. Für einige von diesen können Sie die Anforderungen durch die Installation der `cloud-init <https://cloudinit.readthedocs.org/en/latest/> `_ Paket erfüllen. Lesen Sie diesen Abschnitt, bevor Sie Ihr eigenes Abbild erstellen, um sicherzustellen, dass das Abbild die OpenStack-Funktionen unterstützt, die Sie verwenden möchten.

• Festplattenpartitionen und Resize-Root-Partition beim Booten (cloud-init)

• Keine Hardcoded MAC Adresse Informationen

• SSH-Server läuft

• Firewall deaktivieren

• Zugriffsinstanz mit ssh public key (cloud-init)

• Verarbeiten von Benutzerdaten und anderen Metadaten (cloud-init)

• Paravirtualisierte Xen-Unterstützung im Linux-Kernel (Xen Hypervisor nur mit Linux-Kernel-Version < 3.0)

Festplattenpartitionen und Resize-Root-Partition beim Booten (cloud-Init)

Wenn Sie ein Linux-Abbild erstellen, müssen Sie entscheiden, wie die Festplatten partitioniert werden sollen. Die Wahl der Partitionsmethode kann die Größenänderungsfunktionalität beeinflussen, wie in den folgenden Abschnitten beschrieben.

Die Größe der Festplatte in einem virtuellen Maschinenbild wird bestimmt, wenn Sie das Abbild zunächst erstellen. Allerdings können Sie mit OpenStack Instanzen mit verschiedenen Größenlaufwerken starten, indem Sie verschiedene Varianten angeben. Zum Beispiel, wenn Ihr Abbild mit einer 5 GB Festplatte erstellt wurde, und Sie starten eine Instanz mit einer Variante von m1.small. Die resultierende virtuelle Maschineninstanz hat standardmäßig eine primäre Plattengröße von 20 GB. Wenn die Festplatte für eine Instanz geändert wird, werden Nullen nur zum Ende hinzugefügt.

Ihr Abbild muss in der Lage sein, seine Partitionen beim Booten zu ändern, um die vom Benutzer angeforderte Größe zu erfüllen. Andernfalls müssen Sie nach dem Booten der Instanz die Partitionen manuell ändern, um auf den zusätzlichen Speicher zuzugreifen, auf den Sie zugreifen können, wenn die mit der Variante verknüpfte Datenträgergröße die Datenträgergröße überschreitet, mit der Ihr Abbild erstellt wurde.

Xen: eine ext3/ext4-Partition (keine LVM)

Wenn Sie den OpenStack XenAPI-Treiber verwenden, passt der Compute-Dienst automatisch die Partition und das Dateisystem für Ihre Instanz beim Booten an. Automatische Größenänderung tritt auf, wenn die folgenden Bedingungen zutreffen:

• auto_disk_config=True wird als Eigenschaft auf dem Abbild in der Abbildregistrierung gesetzt.

• Die Festplatte auf dem Abbild hat nur eine Partition.

• Das Dateisystem auf der einen Partition ist ext3 oder ext4.

Wenn Sie Xen verwenden, empfehlen wir Ihnen, bei der Erstellung Ihrer Abbilder eine einzelne ext3- oder ext4-Partition (nicht von LVM verwaltet) zu erstellen. Ansonsten weiterlesen.

Nicht-Xen mit Cloud-init / Cloud-Tools: eine ext3 / ext4-Partition (keine LVM)

Sie müssen diese Elemente für Ihr Abbild konfigurieren:

• Die Partitionstabelle für das Abbild beschreibt die Originalgröße des Abbildes.

• Das Dateisystem für das Abbild füllt die Originalgröße des Abbildes.

Dann müssen Sie während des Bootvorgangs:

• Ändern Sie die Partitionstabelle, um sie auf den zusätzlichen Speicherplatz aufmerksam zu machen:

  • Wenn Sie LVM nicht verwenden, müssen Sie die Tabelle ändern, um die vorhandene Root-Partition zu erweitern, um diesen zusätzlichen Speicherplatz zu umfassen.

  • Wenn Sie LVM verwenden, können Sie der Partitionstabelle einen neuen LVM-Eintrag hinzufügen, ein neues LVM-Volume erstellen, die Volume-Gruppe hinzufügen und die logische Partition mit dem Root-Volume erweitern.

• Ändern Sie die Größe des Root-Volume-Dateisystems.

Je nach Distribution ist der einfachste Weg, dies zu unterstützen, in Ihrem Abbild zu installieren:

• das cloud-init <https://launchpad.net/cloud-init> `__ Paket,

• das cloud-utils <https://launchpad.net/cloud-utils> _ Paket, das auf Ubuntu und Debian auch das ``growpart` Werkzeug für das Erweitern von Partitionen enthält,

• wenn Sie Fedora, CentOS 7 oder RHEL 7 verwenden, wird das cloud-utils-growpart-Paket, das das growpart-Tool enthält, um Partitionen zu erweitern,

• wenn Sie Ubuntu oder Debian benutzen, ist das cloud-initramfs-growroot <https://launchpad.net/cloud-initramfs-tools> `_ -Paket, das die Größe der Root-Partition beim ersten Start unterstützt.

Wenn diese Pakete installiert sind, führt das Abbild die Grössenänderung der Root-Partition beim Booten aus. Zum Beispiel in der /etc/rc.local Datei.

Wenn Sie cloud-initramfs-tools` nicht installieren können, hat Robert Plestenjak ein GitHub-Projekt namens `linux-rootfs-resize <https://github.com/flegmatik/linux-rootfs-resize>`_, das Skripts enthält, die eine ramdisk aktualisieren, indem sie` `growpart verwenden, damit das Abbild beim Booten korrekt verändert wird.

Wenn Sie die cloud-init und cloud-utils Pakete installieren können, empfehlen wir Ihnen, bei der Erstellung Ihrer Abbilder eine einzelne ext3 oder ext4 Partition (nicht von LVM verwaltet) zu erstellen.

Nicht-Xen ohne cloud-init/cloud-Tools: LVM

Wenn Sie cloud-init und cloud-tools innerhalb Ihres Gastes nicht installieren können und Sie die Größe ändern möchten, müssen Sie ein Skript schreiben, das Ihr Abbild beim Booten ausführt, um die Partitionstabelle zu ändern. In diesem Fall empfehlen wir die Verwendung von LVM zur Verwaltung Ihrer Partitionen. Wegen einer Einschränkung im Linux-Kernel (ab diesem Schreiben) können Sie keine Partitionstabelle einer Rawdisk ändern, bei der Partitionen aktuell installiert sind, aber Sie können dies für LVM tun.

Ihr Skript muss so etwas wie das Folgende tun:

1. Ermitteln Sie, ob auf der Festplatte zusätzlicher Speicherplatz vorhanden ist. Zum Beispiel, analysieren Sie die Ausgabe von parted /dev/sda --script "print free".

2. Erstellen Sie eine neue LVM-Partition mit dem zusätzlichen Speicherplatz. Zum Beispiel, parted /dev/sda --script "mkpart lvm ... ".

3. Erstellen Sie einen neuen physischen Datenträger. Zum Beispiel, pvcreate /dev/sda6.

4. Erweitern Sie die Volume-Gruppe mit dieser physischen Partition. Zum Beispiel, vgextend vg00 /dev/sda6.

5. Erweitern Sie das logische Volume, das die Root-Partition enthält, um den Platzbedarf. Zum Beispiel lvextend /dev/mapper/node-root /dev/sda6.

6. Ändern Sie die Größe des Root-Dateisystems. Zum Beispiel, resize2fs /dev/mapper/node-root.

Sie brauchen keine `` /boot``-Partition, es sei denn, Ihr Abbild ist eine ältere Linux-Distribution, die erfordert, dass /boot nicht von LVM verwaltet wird.

Keine Hardcoded MAC Adresse Informationen

Sie müssen die Netzwerk-Persistenzregeln im Abbild entfernen, da sie dazu führen, dass die Netzwerkschnittstelle in der Instanz als eine andere Schnittstelle als eth0 auftritt. Dies liegt daran, dass Ihr Abbild eine Aufzeichnung der MAC-Adresse der Netzwerkschnittstellenkarte hat, als es zum ersten Mal installiert wurde, und diese MAC-Adresse ist bei jedem Start der Instanz unterschiedlich. Sie sollten folgende Dateien ändern:

• Ersetzen Sie /etc/udev/rules.d/70-persistent-net.rules mit einer leeren Datei (enthält Netzwerk-Persistenzregeln, einschließlich MAC-Adresse).

• Ersetzen Sie /lib/udev/rules.d/75-persistent-net-generator.rules mit einer leeren Datei (dies erzeugt die Datei oben).

• Entfernen Sie die HWADDR-Zeile aus /etc/sysconfig/network-scripts/ifcfg-eth0 auf Fedora-basierten Abbildern.

Bemerkung

Wenn Sie die Netzwerk-persistenten Regeln-Dateien löschen, erhalten Sie eine udev kernel Warnung zum Booten, weshalb wir empfehlen, sie mit leeren Dateien zu ersetzen.

Stellen Sie sicher, dass ssh-Server läuft

Sie müssen einen ssh-Server in das Abbild installieren und sicherstellen, dass er beim Booten startet, oder Sie können keine Verbindung zu Ihrer Instanz herstellen, indem Sie ssh verwenden, wenn es in OpenStack bootet. Dieses Paket wird normalerweise openssh-server genannt.

Firewall deaktivieren

Im Allgemeinen empfehlen wir Ihnen, alle Firewalls innerhalb Ihres Abbildes zu deaktivieren und OpenStack Sicherheitsgruppen zu verwenden, um den Zugriff auf Instanzen zu beschränken. Der Grund dafür ist, dass eine Firewall auf Ihrer Instanz installiert ist, kann es schwieriger machen, Netzwerkprobleme zu beheben, wenn Sie keine Verbindung zu Ihrer Instanz herstellen können.

Zugriffsinstanz mit ssh public key (cloud-init)

Die typische Art, wie Benutzer auf virtuelle Maschinen zugreifen, die auf OpenStack laufen, ist ssh mit Public Key Authentifizierung. Damit dies funktioniert, muss Ihr virtuelles Maschinenbild so konfiguriert sein, dass der ssh-Public-Key aus dem OpenStack-Metadatendienst oder dem Config-Laufwerk zum Booten heruntergeladen wird.

Wenn sowohl der XenAPI-Agent als auch cloud-init in einem Abbild vorhanden sind, behandelt cloud-init die ssh-Schlüssel-Injektion. Das System setzt voraus, dass cloud-init vorhanden ist, wenn das Abbild die cloud_init_installed Eigenschaft hat.

Verwenden Sie cloud-init, um den öffentlichen Schlüssel zu holen

Das cloud-init-Paket holt automatisch den öffentlichen Schlüssel vom Metadatenserver und platziert den Schlüssel in ein Konto. Das Konto variiert je nach Verteilung. Auf Ubuntu-basierten virtuellen Maschinen heißt das Konto ubuntu, auf Fedora-basierten virtuellen Maschinen, das Konto heißt fedora, und auf CentOS-basierten virtuellen Maschinen wird das Konto centos genannt.

Sie können den Namen des von cloud-init` verwendeten Kontos ändern, indem Sie die Datei ``/etc/cloud/cloud.cfg bearbeiten und eine Zeile mit einem anderen Benutzer hinzufügen. Um beispielsweise cloud-init zu konfigurieren, um den Schlüssel in ein Konto mit dem Namen admin zu setzen, verwenden Sie die folgende Syntax in der Konfigurationsdatei:

users:
  - name: admin
    (...)

Schreiben Sie ein benutzerdefiniertes Skript, um den öffentlichen Schlüssel abzurufen

Wenn Sie nicht in der Lage sind, cloud-init in den Gast zu installieren, können Sie ein benutzerdefiniertes Skript schreiben, um den öffentlichen Schlüssel abzurufen und zu einem Benutzerkonto hinzuzufügen.

Um den ssh-öffentlichen Schlüssel abzurufen und dem Root-Account hinzuzufügen, editiere die Datei /etc/rc.local und füge folgende Zeilen vor der Zeile `` touch /var/lock/subsys/local`` hinzu. Dieses Code-Fragment wird aus der `rackerjoe oz-image-build CentOS 6 Vorlage genommen <https://github.com/ rackerjoe/oz-image-build/blob/master/templates/centos60_x86_64.tdl> `_.

if [ ! -d /root/.ssh ]; then
  mkdir -p /root/.ssh
  chmod 700 /root/.ssh
fi

# Fetch public key using HTTP
ATTEMPTS=30
FAILED=0
while [ ! -f /root/.ssh/authorized_keys ]; do
  curl -f http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key > /tmp/metadata-key 2>/dev/null
  if [ $? -eq 0 ]; then
    cat /tmp/metadata-key >> /root/.ssh/authorized_keys
    chmod 0600 /root/.ssh/authorized_keys
    restorecon /root/.ssh/authorized_keys
    rm -f /tmp/metadata-key
    echo "Successfully retrieved public key from instance metadata"
    echo "*****************"
    echo "AUTHORIZED KEYS"
    echo "*****************"
    cat /root/.ssh/authorized_keys
    echo "*****************"
  else
    FAILED=`expr $FAILED + 1`
    if [ $FAILED -ge $ATTEMPTS ]; then
      echo "Failed to retrieve public key from instance metadata after $FAILED attempts, quitting"
      break
    fi
    echo "Could not retrieve public key from instance metadata (attempt #$FAILED/$ATTEMPTS), retrying in 5 seconds..."
    sleep 5
  fi
done

Bemerkung

Einige VNC-Clients ersetzen: (Doppelpunkt) mit; (Semikolon) und _ (Unterstrich) mit - (Bindestrich). Wenn Sie eine Datei über eine VNC-Sitzung bearbeiten, stellen Sie sicher, dass es http: nicht http ist. und authorized_keys nicht authorized-keys.

Prozessdaten und andere Metadaten bearbeiten (cloud-init)

Zusätzlich zum ssh-öffentlichen Schlüssel kann ein Abbild zusätzliche Informationen von OpenStack benötigen, um Benutzerdaten auf Instanzen zu verschieben, die der Benutzer bei der Anforderung des Abbildes übermittelt hat. Beispielsweise möchten Sie den Hostnamen der Instanz beim Booten festlegen. Oder Sie möchten Ihr Abbild so konfigurieren, dass es Benutzerdateninhalte als Skript beim Booten ausführt.

Sie können auf diese Informationen über den Metadatendienst zugreifen oder auf Metadaten auf dem Konfigurationslaufwerk speichern <https://docs.openstack.org/user-guide/cli-config-drive.html> verweisen`_. Da der OpenStack-Metadatendienst mit der Version 2009-04-04 des Amazon EC2-Metadatendienstes kompatibel ist, konsultieren Sie die Amazon EC2-Dokumentation zum Thema Instanzmetadaten verwenden für Details zum Abrufen der Benutzerdaten.

Der einfachste Weg, diese Art von Funktionalität zu unterstützen, besteht darin, das cloud-init-Paket in Ihr Abbild zu installieren, das standardmäßig so konfiguriert ist, dass es Benutzerdaten als ausführbares Skript behandelt und den Hostnamen festlegt.

Stellen Sie sicher, dass das Abbild das Bootprotokoll zur Konsole schreibt

Sie müssen das Abbild so konfigurieren, dass der Kernel das Bootprotokoll an das ttyS0 Gerät schreibt. Insbesondere müssen die console = tty0 console = ttyS0,115200n8 Argumente an den Kernel beim Booten übergeben werden.

Wenn Ihr Abbild grub2 als Bootloader verwendet, sollte es eine Zeile in der Grub-Konfigurationsdatei geben. Zum Beispiel, /boot/grub/grub.cfg, was so aussieht:

linux /boot/vmlinuz-3.2.0-49-virtual root=UUID=6d2231e4-0975-4f35-a94f-56738c1a8150 ro console=tty0 console=ttyS0,115200n8

Wenn console=tty0 console=ttyS0,115200n8 nicht angezeigt wird, müssen Sie Ihre Grub-Konfiguration ändern. Im Allgemeinen sollten Sie die `` grub.cfg`` nicht direkt aktualisieren, da sie automatisch generiert wird. Stattdessen sollten Sie die /etc/default/grub Datei bearbeiten und den Wert der GRUB_CMDLINE_LINUX_DEFAULT Variable ändern:

GRUB_CMDLINE_LINUX_DEFAULT="console=tty0 console=ttyS0,115200n8"

Als nächstes aktualisieren Sie die Grub-Konfiguration. Auf Debian-basierten Betriebssystemen wie Ubuntu führen Sie diesen Befehl aus:

# update-grub

Auf Fedora-basierten Systemen wie RHEL und CentOS und auf openSUSE führen Sie diesen Befehl aus:

# grub2-mkconfig -o /boot/grub2/grub.cfg

Paravirtualisierte Xen-Unterstützung im Kernel (nur Xen Hypervisor)

Vor der Linux-Kernel-Version 3.0 hatte der Mainline-Branch des Linux-Kernels keine Unterstützung für paravirtualisierte Xen-Virtual Machine-Instanzen (was Xen DomU-Gäste anruft). Wenn Sie den Xen-Hypervisor mit Paravirtualisierung ausführen und ein Abbild für eine ältere Linux-Distribution erstellen möchten, die über einen Vorkern 3.0 verfügt, müssen Sie sicherstellen, dass das Abbild einen Kernel startet, der mit Xen-Unterstützung kompiliert wurde.

Verwalten Sie den Abbildcache

Verwenden Sie die Optionen in der nova.conf Datei, um zu steuern, ob und wie lange unbenutzte Basisbilder im /var/lib/nova/instances/_base / `` gespeichert sind. Wenn Sie die Live-Migration von Instanzen konfiguriert haben, teilen sich alle Ihre Compute-Knoten ein gemeinsames `` /var/lib/nova/instances/ Verzeichnis.

Für Informationen über die libvirt Abbilder in OpenStack, siehe `Das Leben eines OpenStack libvirt Abbild von Pádraig Brady <http://www.pixelbeat.org/docs/openstack_libvirt_images/> `_.

Image-Cache-Management-Konfigurationsoptionen

Konfigurationsoption = Standardwert	(Typ) Beschreibung
preallocate_images=none	(StrOpt) VM-Abbild-Vorbereitungsmodus: keiner Vorn erfolgt keine Speicherbereitstellung. Platz Die Speicherung ist bei Instanzstart vollständig vergeben. Die $instance_dir/ Abbilder sind `fallocated <http://www.kernel.org/doc/man-pages/online/pages/man2/fallocate.2.html> `_ um sofort festzustellen, ob genügend Platz vorhanden ist, und möglicherweise die VM I/O-Leistung aufgrund der fortlaufenden Zuweisungsvermeidung und der besseren Lokalisierung von Blockzuweisungen zu verbessern.
remove_unused_base_images=True	(BoolOpt) Sollten unbenutzte Basisbilder entfernt werden? Wenn auf True gesetzt, wird das Intervall, bei dem die Basisbilder entfernt werden, mit den beiden folgenden Einstellungen eingestellt. Wenn auf false gestellt, werden Basisabbilder niemals von Compute entfernt.
remove_unused_original_minimum_age_seconds=86400	(IntOpt) Unbenutzte unbesetzte Basisabbilder jünger als diese werden nicht entfernt. Standard ist 86400 Sekunden oder 24 Stunden.
remove_unused_resized_minimum_age_seconds=3600	(IntOpt) Unbenutzte verkleinerte Basisbilder, die jünger als diese sind, werden nicht entfernt. Die Voreinstellung ist 3600 Sekunden oder eine Stunde.

Um zu sehen, wie sich die Einstellungen auf das Löschen einer laufenden Instanz auswirken, überprüfen Sie das Verzeichnis, in dem die Abbilder gespeichert sind:

# ls -lash /var/lib/nova/instances/_base/

In der /var/log/compute/compute.log Datei suchen Sie nach der Kennung:

2012-02-18 04:24:17 41389 WARNING nova.virt.libvirt.imagecache [-] Unknown base file: /var/lib/nova/instances/_base/06a057b9c7b0b27e3b496f53d1e88810a0d1d5d3_20
2012-02-18 04:24:17 41389 INFO nova.virt.libvirt.imagecache [-] Removable base files: /var/lib/nova/instances/_base/06a057b9c7b0b27e3b496f53d1e88810a0d1d5d3 /var/lib/nova/instances/_base/06a057b9c7b0b27e3b496f53d1e88810a0d1d5d3_20
2012-02-18 04:24:17 41389 INFO nova.virt.libvirt.imagecache [-] Removing base file: /var/lib/nova/instances/_base/06a057b9c7b0b27e3b496f53d1e88810a0d1d5d3

Weil 86400 Sekunden (24 Stunden) die Standardzeit für `` remove_unused_original_minimum_age_seconds`` ist, können Sie entweder auf dieses Zeitintervall warten, um das Basisabbild zu entfernen oder den Wert auf einen kürzeren Zeitraum in der nova.conf Datei setzen. Starten Sie alle nova-Dienste neu, nachdem Sie eine Einstellung in der nova.conf Datei geändert haben.