102.6 Lektion 1

Zertifikat:

LPIC-1

Version:

5.0

Thema:

102 Linux-Installation und -Paketverwaltung

Zielsetzung:

102.6 Linux als Virtualisierungs-Gast

Lektion:

1 von 1

Einführung

Eine der großen Stärken von Linux ist seine Vielseitigkeit. Ein Aspekt dieser Vielseitigkeit ist die Fähigkeit, Linux als Mittel zum Hosten anderer Betriebssysteme oder einzelner Anwendungen in einer vollständig isolierten und sicheren Umgebung zu verwenden. Diese Lektion konzentriert sich auf die Konzepte der Virtualisierung und Containertechnologien sowie auf einige technische Details, die bei der Bereitstellung einer virtuellen Maschine auf einer Cloudplattform berücksichtigt werden sollten.

Virtualisierungsübersicht

Virtualisierung ist eine Technologie, die es einer Softwareplattform, einem sogenannten Hypervisor, ermöglicht, Prozesse auszuführen, die ein vollständig emuliertes Computersystem enthalten. Der Hypervisor ist für die Verwaltung der Ressourcen der physischen Hardware verantwortlich, die von den einzelnen virtuellen Maschinen genutzt werden können. Diese virtuellen Maschinen werden als Gäste des Hypervisors bezeichnet. Eine virtuelle Maschine hat viele Aspekte eines physischen Computers, die in Software emuliert werden, wie z.B. das BIOS und die Festplattencontroller eines Systems. Eine virtuelle Maschine verwendet häufig Festplattenimages, die als einzelne Dateien gespeichert werden. Eine virtuelle Maschine hat zudem über die Hypervisorsoftware Zugriff auf den RAM und die CPU des Hostrechners. Der Hypervisor teilt den Zugriff auf die Hardwareressourcen des Hostsystems unter den Gästen auf und ermöglicht so die Ausführung mehrerer Betriebssysteme auf einem einzigen Hostsystem.

Zu den häufig verwendeten Hypervisoren für Linux gehören:

Xen: Xen ist ein quelloffener Typ-1-Hypervisor, was bedeutet, dass er nicht auf ein zugrunde liegendes Betriebssystem angewiesen ist, um zu funktionieren. Ein solcher Hypervisor ist als Bare-Metal-Hypervisor bekannt, da der Computer direkt in den Hypervisor booten kann.
KVM: Die Kernel Virtual Machine ist ein Linux-Kernelmodul für die Virtualisierung. KVM ist ein Hypervisor sowohl vom Typ-1- als auch vom Typ-2-Hypervisor, da er, obwohl er ein generisches Linux-Betriebssystem benötigt, um zu funktionieren, durch die Integration in eine laufende Linuxinstallation als Hypervisor genutzt werden kann. Virtuelle Maschinen, die mit KVM bereitgestellt werden, verwenden den libvirt-Daemon und zugehörige Softwaredienstprogramme, die erstellt und verwaltet werden.
VirtualBox: VirtualBox ist eine beliebte Desktopanwendung, mit der virtuelle Maschinen einfach erstellt und verwaltet werden können. Oracle VM VirtualBox ist plattformübergreifend und funktioniert unter Linux, MacOS und Microsoft Windows. Da VirtualBox zur Ausführung ein zugrunde liegendes Betriebssystem benötigt, handelt es sich um einen Typ-2-Hypervisor.

Einige Hypervisor ermöglichen die dynamische Verlagerung einer virtuellen Maschine. Der Prozess des Verschiebens einer virtuellen Maschine von einer Hypervisorinstallation zu einer Anderen wird als Migration bezeichnet. Die dabei eingesetzten Techniken unterscheiden sich je nach Hypervisorimplementierung. Einige Migrationen können nur durchgeführt werden, wenn das Gastsystem vollständig heruntergefahren wurde. Andere wiederum können bei laufendem Gastbetrieb durchgeführt werden (auch Livemigration genannt). Solche Techniken können während der Wartungsfenster für Hypervisor oder für die Systemresilienz hilfreich sein, wenn ein Hypervisor nicht mehr funktioniert und der Gast zu einem funktionierenden Hypervisor verschoben werden kann.

Typen von virtuellen Maschinen

Es gibt drei Haupttypen von virtuellen Maschinen: den vollständig virtualisierten Gast, den paravirtualisierten Gast und den hybriden Gast.

Vollständig virtualisiert: Alle Anweisungen, deren Ausführung von einem Gastbetriebssystem erwartet werden, müssen innerhalb einer vollständig virtualisierten Betriebssysteminstallation ausgeführt werden können. Der Grund dafür ist, dass innerhalb des Gastes keine zusätzlichen Softwaretreiber installiert sind, um die Anweisungen entweder auf simulierte oder reale Hardware zu übersetzen. Ein vollständig virtualisierter Gast ist ein Gast, bei dem sich der Gast (oder HardwareVM) nicht bewusst ist, dass es sich um eine laufende virtuelle Maschineninstanz handelt. Damit diese Art der Virtualisierung auf x86-basierter Hardware stattfinden kann, müssen die Intel VT-x oder AMD-V CPU-Erweiterungen auf dem System aktiviert werden, auf dem der Hypervisor installiert ist. Dies kann über ein BIOS- oder UEFI-Konfigurationsmenü erfolgen.
Paravirtualisiert: Ein paravirtualisierter Gast (oder PVM) ist ein Gast, bei dem das Gastbetriebssystem weiß, dass es sich um eine laufende virtuelle Maschineninstanz handelt. Diese Arten von Gästen verwenden einen modifizierten Kernel und spezielle Treiber (bekannt als Gasttreiber), die dem Gastbetriebssystem helfen, die Software- und Hardwareressourcen des Hypervisors zu nutzen. Die Leistung eines paravirtualisierten Gastes ist aufgrund des Vorteils, den diese Softwaretreiber bieten, oft besser als die des vollständig virtualisierten Gastes.
Hybride: Paravirtualisierung und Vollvirtualisierung können so kombiniert werden, dass unmodifizierte Betriebssysteme eine nahezu native E/A-Leistung erzielen, indem paravirtualisierte Treiber auf vollständig virtualisierten Betriebssystemen verwendet werden. Die paravirtualisierten Treiber enthalten Speicher- und Netzwerkgerätetreiber mit verbesserter Festplatten- und Netzwerk-E/A-Performanz.

Virtualisierungsplattformen stellen häufig Gasttreiberpakete für virtualisierte Betriebssysteme zur Verfügung. Die KVM verwendet Treiber aus dem Virtio-Projekt, während Oracle VM VirtualBox Gasterweiterungen verwendet, die von einer herunterladbaren ISO CD-ROM-Imagedatei zur Verfügung gestellt werden.

Beispiel `libvirt` virtuelle Maschine

Wir werden uns ein Beispiel einer virtuellen Maschine ansehen, die von libvirt verwaltet wird und den KVM-Hypervisor verwendet. Eine virtuelle Maschine besteht oft aus einer Gruppe von Dateien, in erster Linie aus einer XML-Datei, die die virtuelle Maschine definiert (wie z.B. ihre Hardwarekonfiguration, Netzwerkkonnektivität, Anzeigefähigkeiten und mehr) und einer zugehörigen Festplattenimagedatei, die die Installation des Betriebssystems und seiner Software enthält.

Beginnen wir zunächst mit der Untersuchung einer Beispiel XML-Konfigurationsdatei für eine virtuelle Maschine und ihre Netzwerkumgebung:

$ ls /etc/libvirt/qemu
total 24
drwxr-xr-x 3 root root 4096 Oct 29 17:48 networks
-rw------- 1 root root 5667 Jun 29 17:17 rhel8.0.xml

Note

Der qemu-Teil des Verzeichnispfads bezieht sich auf die zugrunde liegende Software, auf die KVM-basierte virtuelle Maschinen angewiesen sind. Das QEMU-Projekt stellt Software für den Hypervisor bereit, um Hardwaregeräte zu emulieren, die von der virtuellen Maschine verwendet werden, wie z.B. Festplattencontroller, Zugriff auf die Host-CPU, Netzwerkkartenemulation und mehr.

Beachten Sie, dass es ein Verzeichnis namens networks gibt. Dieses Verzeichnis enthält Definitionsdateien (auch unter Verwendung von XML), die Netzwerkkonfigurationen erstellen, die von den virtuellen Maschinen verwendet werden können. Dieser Hypervisor verwendet nur ein Netzwerk, und daher gibt es nur eine Definitionsdatei, die eine Konfiguration für ein virtuelles Netzwerksegment enthält, das von diesen Systemen verwendet wird.

$ ls -l /etc/libvirt/qemu/networks/
total 8
drwxr-xr-x 2 root root 4096 Jun 29 17:15 autostart
-rw------- 1 root root  576 Jun 28 16:39 default.xml
$ sudo cat /etc/libvirt/qemu/networks/default.xml
<!--
WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE
OVERWRITTEN AND LOST. Changes to this xml configuration should be made using:
  virsh net-edit default
or other application using the libvirt API.
-->

<network>
  <name>default</name>
  <uuid>55ab064f-62f8-49d3-8d25-8ef36a524344</uuid>
  <forward mode='nat'/>
  <bridge name='virbr0' stp='on' delay='0'/>
  <mac address='52:54:00:b8:e0:15'/>
  <ip address='192.168.122.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='192.168.122.2' end='192.168.122.254'/>
    </dhcp>
  </ip>
</network>

Diese Definition umfasst ein privates Netzwerk der Klasse C und ein emuliertes Hardwaregerät, das als Router für dieses Netzwerk fungiert. Es gibt auch einen Bereich von IP-Adressen für den Hypervisor zur Verwendung mit einer DHCP-Serverimplementierung, die den virtuellen Maschinen zugewiesen werden können, die dieses Netzwerk nutzen. Diese Netzwerkkonfiguration verwendet auch Network Address Translation (NAT), um Pakete an andere Netzwerke, wie das LAN des Hypervisors, weiterzuleiten.

Nun wenden wir unsere Aufmerksamkeit auf eine Definitionsdatei einer virtuellen Maschine von Red Hat Enterprise Linux 8. (Abschnitte mit besonderen Hinweisen sind fett dargestellt):

$ sudo cat /etc/libvirt/qemu/rhel8.0.xml
<!--
WARNING: THIS IS AN AUTO-GENERATED FILE. CHANGES TO IT ARE LIKELY TO BE
OVERWRITTEN AND LOST. Changes to this xml configuration should be made using:
  virsh edit rhel8.0
or other application using the libvirt API.
-->

<domain type='kvm'>
  <name>rhel8.0</name>
  <uuid>fadd8c5d-c5e1-410e-b425-30da7598d0f6</uuid>
  <metadata>
    <libosinfo:libosinfo xmlns:libosinfo="http://libosinfo.org/xmlns/libvirt/domain/1.0">
      <libosinfo:os id="http://redhat.com/rhel/8.0"/>
    </libosinfo:libosinfo>
  </metadata>
  <memory unit='KiB'>4194304</memory>
  <currentMemory unit='KiB'>4194304</currentMemory>
  <vcpu placement='static'>2</vcpu>
  <os>
    <type arch='x86_64' machine='pc-q35-3.1'>hvm</type>
    <boot dev='hd'/>
  </os>
  <features>
    <acpi/>
    <apic/>
    <vmport state='off'/>
  </features>
  <cpu mode='host-model' check='partial'>
    <model fallback='allow'/>
  </cpu>
  <clock offset='utc'>
    <timer name='rtc' tickpolicy='catchup'/>
    <timer name='pit' tickpolicy='delay'/>
    <timer name='hpet' present='no'/>
  </clock>
  <on_poweroff>destroy</on_poweroff>
  <on_reboot>restart</on_reboot>
  <on_crash>destroy</on_crash>
  <pm>
    <suspend-to-mem enabled='no'/>
    <suspend-to-disk enabled='no'/>
  </pm>
  <devices>
    <emulator>/usr/bin/qemu-system-x86_64</emulator>
    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2'/>
      <source file='/var/lib/libvirt/images/rhel8'/>
      <target dev='vda' bus='virtio'/>
      <address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
    </disk>
    <controller type='usb' index='0' model='qemu-xhci' ports='15'>
      <address type='pci' domain='0x0000' bus='0x02' slot='0x00' function='0x0'/>
    </controller>
    <controller type='sata' index='0'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1f' function='0x2'/>
    </controller>
    <controller type='pci' index='0' model='pcie-root'/>
    <controller type='pci' index='1' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='1' port='0x10'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x0' multifunction='on'/>
    </controller>
    <controller type='pci' index='2' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='2' port='0x11'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x1'/>
    </controller>
    <controller type='pci' index='3' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='3' port='0x12'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x2'/>
    </controller>
    <controller type='pci' index='4' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='4' port='0x13'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x3'/>
    </controller>
    <controller type='pci' index='5' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='5' port='0x14'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x4'/>
    </controller>
    <controller type='pci' index='6' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='6' port='0x15'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x5'/>
    </controller>
    <controller type='pci' index='7' model='pcie-root-port'>
      <model name='pcie-root-port'/>
      <target chassis='7' port='0x16'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x02' function='0x6'/>
    </controller>
    <controller type='virtio-serial' index='0'>
      <address type='pci' domain='0x0000' bus='0x03' slot='0x00' function='0x0'/>
    </controller>
    <interface type='network'>
      <mac address='52:54:00:50:a7:18'/>
      <source network='default'/>
      <model type='virtio'/>
      <address type='pci' domain='0x0000' bus='0x01' slot='0x00' function='0x0'/>
    </interface>
    <serial type='pty'>
      <target type='isa-serial' port='0'>
        <model name='isa-serial'/>
      </target>
    </serial>
    <console type='pty'>
      <target type='serial' port='0'/>
    </console>
    <channel type='unix'>
      <target type='virtio' name='org.qemu.guest_agent.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='1'/>
    </channel>
    <channel type='spicevmc'>
      <target type='virtio' name='com.redhat.spice.0'/>
      <address type='virtio-serial' controller='0' bus='0' port='2'/>
    </channel>
    <input type='tablet' bus='usb'>
      <address type='usb' bus='0' port='1'/>
    </input>
    <input type='mouse' bus='ps2'/>
    <input type='keyboard' bus='ps2'/>
    <graphics type='spice' autoport='yes'>
      <listen type='address'/>
      <image compression='off'/>
    </graphics>
    <sound model='ich9'>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x1b' function='0x0'/>
    </sound>
    <video>
      <model type='virtio' heads='1' primary='yes'/>
      <address type='pci' domain='0x0000' bus='0x00' slot='0x01' function='0x0'/>
    </video>
    <redirdev bus='usb' type='spicevmc'>
      <address type='usb' bus='0' port='2'/>
    </redirdev>
    <redirdev bus='usb' type='spicevmc'>
      <address type='usb' bus='0' port='3'/>
    </redirdev>
    <memballoon model='virtio'>
      <address type='pci' domain='0x0000' bus='0x05' slot='0x00' function='0x0'/>
    </memballoon>
    <rng model='virtio'>
      <backend model='random'>/dev/urandom</backend>
      <address type='pci' domain='0x0000' bus='0x06' slot='0x00' function='0x0'/>
    </rng>
  </devices>
</domain>

Diese Datei definiert eine Reihe von Hardwareeinstellungen, die von diesem Gast verwendet werden, wie z.B. die Menge an RAM, die ihm zugewiesen wird, die Anzahl der CPU-Kerne vom Hypervisor, auf die der Gast Zugriff hat, die Festplattenimagedatei, die mit diesem Gast verbunden ist, seine Anzeigefähigkeiten (über das SPICE-Protokoll) und den Zugriff des Gastes auf USB-Geräte sowie emulierte Tastatur- und Mauseingaben.

Beispiel für Festplattenspeicher einer virtuellen Maschine

Das Festplattenimage dieser virtuellen Maschine befindet sich unter /var/lib/libvirt/images/rhel8. Hier befindet sich das Festplattenimage auf diesem Hypervisor:

$ sudo ls -lh /var/lib/libvirt/images/rhel8
-rw------- 1 root root 5.5G Oct 25 15:57 /var/lib/libvirt/images/rhel8

Die aktuelle Größe dieses Diskimages verbraucht nur 5,5 GB Speicherplatz auf dem Hypervisor. Das Betriebssystem innerhalb dieses Gastes sieht jedoch eine 23,3 GB große Festplatte, was durch die Ausgabe des folgenden Befehls aus der laufenden virtuellen Maschine belegt wird:

$ lsblk
NAME          MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
vda           252:0    0 23.3G  0 disk
├─vda1        252:1    0    1G  0 part /boot
└─vda2        252:2    0 22.3G  0 part
  ├─rhel-root 253:0    0   20G  0 lvm  /
  └─rhel-swap 253:1    0  2.3G  0 lvm  [SWAP]

Dies ist auf die Art der Festplattenbereitstellung zurückzuführen, die für diesen Gast verwendet wird. Es gibt mehrere Arten von Festplattenimages, die eine virtuelle Maschine verwenden kann. Die beiden Haupttypen sind:

COW: Copy-on-Write (auch als thin-provisioning oder sparse images bezeichnet) ist eine Methode, bei der eine Datenträgerdatei mit einer vordefinierten oberen Größengrenze erstellt wird. Die Größe des Images nimmt nur zu, wenn neue Daten geschrieben werden. Genau wie im vorherigen Beispiel sieht das Gastbetriebssystem die vordefinierte Speichergrenze von 23,3 GB, hat aber nur 5,5 GB Daten auf die Imagedatei geschrieben. Das für die virtuelle Maschine verwendete Speicherabbildformat ist qcow2, ein QEMU COW-Dateiformat.
RAW: Ein roher oder vollständiger Datenträgertyp ist eine Datei, der der gesamte Speicherplatz bereits zugewiesen ist. Beispielsweise verbraucht eine 10 GB große Rohdatenträger-Imagedatei 10 GB tatsächlichen Speicherplatz auf dem Hypervisor. Dieser Datenträgertyp hat einen Leistungsvorteil, da der gesamte benötigte Speicherplatz bereits vorhanden ist, so dass der zugrundeliegende Hypervisor einfach Daten auf den Datenträger schreiben kann. Dies geschieht ohne den Leistungseinbruch durch die Überwachung des Datenträgerimages, um sicherzustellen, dass noch nicht die Speichergrenze erreicht ist, und durch die Erweiterung der Dateigröße, wenn weitere Daten auf den Datenträger geschrieben werden.

Es gibt andere Virtualisierungsmanagementplattformen wie Red Hat Enterprise Virtualization und oVirt, die physische Festplatten als Backupspeicherorte für das Betriebssystem einer virtuellen Maschine nutzen können. Diese Systeme können Storage Area Network (SAN)- oder Network Attached Storage (NAS)-Geräte verwenden, um ihre Daten zu schreiben. Der Hypervisor behält somit den Überblick darüber, welche Speicherorte zu welchen virtuellen Maschinen gehören. Diese Speichersysteme können Technologien wie das Logical Volume Management (LVM) verwenden, um die Größe des Plattenspeichers einer virtuellen Maschine je nach Bedarf zu vergrößern oder zu verkleinern und die Erstellung und Verwaltung von Speichersnapshots zu unterstützen.

Arbeiten mit Vorlagen für virtuelle Maschinen

Da virtuelle Maschinen in der Regel nur Dateien sind, die auf einem Hypervisor ausgeführt werden, ist es einfach, Vorlagen zu erstellen, die für bestimmte Einsatzszenarien angepasst werden können. Häufig verfügt eine virtuelle Maschine über eine Basisinstallation des Betriebssystems und einige vorkonfigurierte Authentifizierungskonfigurationseinstellungen, um zukünftige Systemstarts zu erleichtern. Dies verkürzt die Zeit, die für den Aufbau eines neuen Systems benötigt wird, indem es wiederholt benötigten Arbeitsaufwand reduziert, wie z.B. die Installation des Basispakets und die lokalen Einstellungen.

Diese Vorlage der virtuellen Maschine könnte dann später auf ein neues Gastsystem kopiert werden. In diesem Fall würde der neue Gast umbenannt, eine neue MAC-Adresse für seine Netzwerkschnittstelle generiert und je nach Verwendungszweck können weitere Änderungen vorgenommen werden.

Die D-Bus-Maschinenkennung

Viele Linuxinstallationen verwenden eine Maschinenidentifikationsnummer, die bei der Installation generiert wird, die so genannte D-Bus-Maschinenkennung. Wenn jedoch eine virtuelle Maschine geklont wird, um als Vorlage für andere virtuelle Maschineninstallationen verwendet zu werden, müsste eine neue D-Bus-Maschinenkennung erstellt werden, um sicherzustellen, dass Systemressourcen vom Hypervisor auf das entsprechende Gastsystem geleitet werden.

Der folgende Befehl kann verwendet werden, um zu überprüfen, ob eine D-Bus-Maschinenkennung für das laufende System vorhanden ist:

$ dbus-uuidgen --ensure

Wenn keine Fehlermeldungen angezeigt werden, ist eine ID für das System vorhanden. Um die aktuelle D-Bus-Maschinenkennung anzuzeigen, führen Sie den folgenden Befehl aus:

$ dbus-uuidgen --get
17f2e0698e844e31b12ccd3f9aa4d94a

Die angezeigte Textfolge ist die aktuelle ID-Nummer. Keine zwei Linux-Systeme, die auf einem Hypervisor laufen, sollten die gleiche D-Bus-Maschinenkennung haben.

Die D-Bus-Maschinenkennung befindet sich unter /var/lib/dbus/machine-id und stellt einen symbolischen Link auf /etc/machine-id dar. Es wird davon abgeraten, diese ID-Nummer auf einem laufenden System zu ändern, da es zu Systeminstabilitäten und Abstürzen kommen kann. Wenn zwei virtuelle Maschinen dieselbe D-Bus-Maschinenkennung haben, gehen Sie wie folgt vor, um eine neue ID zu erzeugen:

$ sudo rm -f /etc/machine-id
$ sudo dbus-uuidgen --ensure=/etc/machine-id

Für den Fall, dass /var/lib/dbus/machine-id kein symbolischer Link auf /etc/machine-id ist, muss /var/lib/dbus/machine-id entfernt werden.

Bereitstellung von virtuellen Maschinen in der Cloud

Es gibt eine Vielzahl von IaaS-Anbietern (infrastructure as a service), die Hypervisorsysteme betreiben und virtuelle Gästeimages bereitstellen. Praktisch all diese Anbieter verfügen über Tools, die es einem Administrator ermöglichen, benutzerdefinierte virtuelle Maschinen auf der Grundlage einer Vielzahl von Linux-Distributionen zu erstellen, bereitzustellen und zu konfigurieren. Viele dieser Unternehmen verfügen auch über Systeme, die den Einsatz und die Migration von virtuellen Maschinen ermöglichen, die innerhalb der Organisation eines Kunden erstellt wurden.

Bei der Beurteilung eines Einsatzes eines Linux-Systems in einer IaaS-Umgebung gibt es einige Schlüsselelemente, die ein Administrator kennen sollte:

Rechnerinstanzen: Viele Cloudanbieter berechnen Nutzungsraten, die auf “Recheninstanzen” basieren, oder darauf, wie viel CPU-Zeit Ihre Cloud-basierte Infrastruktur verbraucht. Eine sorgfältige Planung, wie viel Rechenzeit Anwendungen tatsächlich benötigen, hilft dabei, die Kosten einer Cloudlösung überschaubar zu halten.

Recheninstanzen beziehen sich häufig auch auf die Anzahl der virtuellen Maschinen, die in einer Cloudumgebung bereitgestellt werden. Auch hier gilt, dass die Anzahl der Instanzen von Systemen, die gleichzeitig ausgeführt werden, auch einen Einfluss darauf hat, wie viel CPU-Gesamtzeit einem Unternehmen in Rechnung gestellt wird.
Blocklagerung: Cloudanbieter stellen einer Organisation auch verschiedene Ebenen von Blockspeicher zur Verfügung. Einige Angebote sind einfach als webbasierter Netzwerkspeicher für Dateien gedacht. Andere Angebote beziehen sich auf externen Speicher für eine in der Cloud bereitgestellte virtuelle Maschine, die für das Hosting von Dateien verwendet werden kann.

Die Kosten für solche Angebote hängen von der Menge des verwendeten Speichers und der Geschwindigkeit der Speicherung in den Rechenzentren des Anbieters ab. Ein schnellerer Speicherzugriff kostet in der Regel mehr. Umgekehrt sind Daten “at rest” (wie bei der Archivierung) oft sehr preiswert.
Vernetzung: Eine der Hauptkomponenten der Zusammenarbeit mit einem Anbieter von Cloudlösungen ist die Konfiguration des virtuellen Netzwerks. Viele IaaS-Anbieter werden in irgendeiner Form über webbasierte Dienstprogramme verfügen, die für den Entwurf und die Implementierung verschiedener Netzwerkrouten, Teilnetzwerke und Firewallkonfigurationen genutzt werden können. Einige werden sogar DNS-Lösungen anbieten, so dass öffentlich zugängliche FQDN (fully qualified domain names) Ihren dem Internet zugewandten Systemen zugewiesen werden können. Es gibt sogar “hybride” Lösungen, die eine bestehende, vor Ort vorhandene Netzwerkinfrastruktur über ein VPN (virtual private network) mit einer Cloud-basierten Infrastruktur verbinden und so die Kommunikation beider Infrastrukturen miteinander ermöglicht.

Sicherer Zugang für Gäste in der Cloud

Die am weitesten verbreitete Methode, die für den Zugriff auf einen entfernten virtuellen Gast auf einer Cloudplattform verwendet wird, ist die Verwendung von OpenSSH Software. Auf einem Linux-System, das sich in der Cloud befindet, würde der OpenSSH-Server laufen, während ein Administrator einen OpenSSH-Client mit vorab gemeinsam genutzten Schlüsseln für den Fernzugriff verwenden würde.

Dem Administrator dient, zum Erstellen des Schlüsselpaares, folgender Befehl:

$ ssh-keygen

und folgt anschließend den Eingabeaufforderungen, um ein SSH-Schlüsselpaar aus öffentlichem und privatem Schlüssel zu erzeugen. Der private Schlüssel verbleibt auf dem lokalen System des Administrators (gespeichert in ~/.ssh/) und der öffentliche Schlüssel wird auf das entfernte Cloudsystem kopiert. Dies entspricht genau der Methode, die man bei der Arbeit mit vernetzten Maschinen in einem Firmen Netzwerk anwenden würde.

Der Administrator würde dazu den folgenden Befehl ausführen:

$ ssh-copy-id -i <public_key> user@cloud_server

Dadurch wird der öffentliche SSH-Schlüssel aus dem soeben erzeugten Schlüsselpaar auf den entfernten Cloud-Server kopiert. Der öffentliche Schlüssel wird in der Datei ~/.ssh/authorized_keys des Cloudservers abgelegt und die entsprechenden Berechtigungen auf die Datei gesetzt.

Note	Wenn es nur eine öffentliche Schlüsseldatei im Verzeichnis `~/.ssh/` gibt, dann kann die Option `-i` vernachlässigt werden, da der Befehl `ssh-copy-id` standardmäßig die öffentliche Schlüsseldatei im Verzeichnis (typischerweise die Datei mit der Endung `.pub`) verwendet.

Einige Cloudanbieter generieren automatisch ein Schlüsselpaar, wenn ein neues Linux-System bereitgestellt wird. Der Administrator muss dann den privaten Schlüssel für das neue System vom Cloudanbieter herunterladen und auf seinem lokalen System speichern. Beachten Sie, dass die Berechtigungen für SSH-Schlüssel 0600 für einen privaten Schlüssel und 0644 für einen öffentlichen Schlüssel sein müssen.

Vorkonfigurieren von Cloudsystemen

Ein nützliches Werkzeug, das die Bereitstellung von Cloud-basierten virtuellen Maschinen vereinfacht, ist das Dienstprogramm cloud-init. Dieser Befehl ist zusammen mit den zugehörigen Konfigurationsdateien und dem vordefinierten Image der virtuellen Maschine eine anbieterneutrale Methode zur Bereitstellung eines Linuxgastes bei einer Vielzahl von IaaS-Anbietern. Mithilfe von YAML (YAML Ain’t Markup Language) Klartextdateien kann ein Administrator Netzwerkeinstellungen, die Auswahl von Softwarepaketen, die Konfiguration von SSH-Schlüsseln, die Erstellung von Benutzerkonten, Gebietsschemaeinstellungen sowie eine Vielzahl anderer Optionen vorkonfigurieren, um schnell neue Systeme zu erstellen.

Beim ersten Hochfahren eines neuen Systems liest cloud-init die Einstellungen aus den entsprechenden YAML-Konfigurationsdateien ein und wendet diese an. Dieser Prozess muss nur bei der Ersteinrichtung eines Systems ausgeführt werden und vereinfacht die Bereitstellung neuer Systeme auf der Plattform eines Cloudproviders.

Die bei cloud-init verwendete YAML-Datei Syntax heißt cloud-config. Hier ein Beispiel für eine cloud-config Datei:

#cloud-config
timezone: Africa/Dar_es_Salaam
hostname: test-system

# Update the system when it first boots up
apt_update: true
apt_upgrade: true

# Install the Nginx web server
packages:
 - nginx

Beachten Sie, dass in der obersten Zeile kein Leerzeichen zwischen dem Hashsymbol (#) und dem Begriff cloud-config steht.

Note	`cloud-init` ist nicht nur für virtuelle Maschinen. Die `cloud-init`-Toolsuite kann auch zur Vorkonfiguration von Containern (wie z.B. LXD-Linux-Containern) verwendet werden.

Container

Die Containertechnologie ähnelt in einigen Aspekten einer virtuellen Maschine, bei der Sie eine isolierte Umgebung erhalten, um eine Anwendung einfach zu implementieren. Während bei einer virtuellen Maschine ein ganzer Computer emuliert wird, wird bei einem Container gerade genug Software bereitgestellt, um eine Anwendung ausführen zu können. Auf diese Weise gibt es wesentlich weniger Overhead.

Container ermöglichen eine größere Flexibilität als die einer virtuellen Maschine. Ein Anwendungscontainer kann von einem Host zu einem anderen migriert werden, genauso wie eine virtuelle Maschine von einem Hypervisor zu einem anderen Hypervisor migriert werden kann. Manchmal muss eine virtuelle Maschine jedoch ausgeschaltet werden, bevor sie migriert werden kann, während bei einem Container die Anwendung während der Migration immer ausgeführt wird. Mit Containern ist es auch einfach, neue Versionen von Anwendungen zusammen mit einer bestehenden Version zu implementieren. Wenn Benutzer ihre Sitzungen mit laufenden Containern beenden, können diese Container von der Containerorchestrierungssoftware automatisch aus dem System entfernt und durch die neue Version ersetzt werden, wodurch sich die Ausfallzeiten verringern.

Note	Es gibt zahlreiche Containertechnologien für Linux, wie z.B. Docker, Kubernetes, LXD/LXC, systemd-nspawn, OpenShift und mehr. Die genaue Implementierung eines Containersoftwarepakets übersteigt allerdings den Rahmen der LPIC-1-Prüfung.

Container nutzen den control groups (besser bekannt als cgroups) Mechanismus innerhalb des Linux-Kernels. Der cgroup Mechanismus ist eine Möglichkeit, Systemressourcen wie Speicher, Prozessorzeit sowie Speicher- und Netzwerkbandbreite für eine einzelne Anwendung zu partitionieren. Ein Administrator kann cgroups direkt verwenden, um Systemressourcenbegrenzungen für eine Anwendung oder eine Gruppe von Anwendungen festzulegen, die innerhalb einer einzigen cgroup existieren könnten. Im Wesentlichen ist es das, was Containersoftware für den Administrator umsetzt, zusammen mit der Bereitstellung von Werkzeugen, die die Verwaltung und den Einsatz von cgroups erleichtern.

Note

Gegenwärtig sind Kenntnisse von cgroups für das Bestehen der LPIC-1-Prüfung nicht erforderlich. Das Konzept der cgroup wird hier lediglich erwähnt, damit der Kandidat zumindest ein gewisses Hintergrundwissen darüber hat, wie eine Anwendung im Interesse der Auslastung der Systemressourcen getrennt wird.

Geführte Übungen

Welche CPU-Erweiterungen sind auf einer x86-basierten Hardwareplattform erforderlich, um darauf vollständig virtualisierte Gäste auszuführen?
Eine unternehmenskritische Serverinstallation, welche die höchste Performanz erfordert, wird wahrscheinlich welche Art von Virtualisierung verwenden?
Zwei virtuelle Maschinen, die von der gleichen Vorlage geklont wurden und den D-Bus verwenden, arbeiten fehlerhaft. Beide haben separate Hostnamen und Netzwerkkonfigurationseinstellungen. Welcher Befehl kann verwendet werden, um festzustellen, ob jede der virtuellen Maschinen unterschiedliche D-Bus-Maschinenkennungen besitzen?

Offene Übungen

Führen Sie den folgenden Befehl aus, um zu prüfen, ob in Ihrem System bereits CPU-Erweiterungen für die Ausführung virtueller Maschinen aktiviert sind (Ergebnisse können je nach CPU variieren):

grep --color -E "vmx|svm" /proc/cpuinfo

Abhängig vom System kann dies vmx (für Intel VT-x-aktivierte CPUs) oder svm (für AMD SVM-aktivierte CPUs) sein. Sollten Sie kein Ergebnis erhalten, überprüfen Sie Ihre BIOS- oder UEFI-Optionen, um die Virtualisierung für Ihren Prozessor zu aktivieren.
Wenn Ihr Prozessor Virtualisierungen unterstützt, recherchieren Sie in der Dokumentation Ihrer Distribution bezüglich dem Ausführen eines KVM-Hypervisors.
- Installieren Sie die erforderlichen Pakete zum Ausführung eines KVM-Hypervisors.
- Wenn Sie eine grafische Desktopumgebung verwenden, empfiehlt es sich, auch die Anwendung virt-manager zu installieren, bei der es sich um ein grafisches Front-End handelt, welches auf einer KVM-Installation verwendet werden kann. Dies erleichert die Installation und Verwaltung von virtuellen Maschinen.
- Laden Sie ein Linux-Distributions ISO-Image Ihrer Wahl herunter, und erstellen Sie mit Hilfe der Dokumentation Ihrer Distribution eine neue virtuelle Maschine anhand dieses ISO-Images.

Zusammenfassung

In dieser Lektion behandelten wir die konzeptionellen Grundlagen von virtuellen Maschinen und Containern und wie diese Technologien unter Linux eingesetzt werden können.

Es wurden folgende Befehle behandelt:

dbus-uuidgen: Wird verwendet, um die D-Bus-ID eines Systems zu verifizieren und anzuzeigen.
ssh-keygen: Wird verwendet, um ein öffentliches und privates SSH-Schlüsselpaar zu erzeugen, welches beim Zugriff auf entfernte, cloudbasierte Systeme benötigt wird.
ssh-copy-id: Wird verwendet, um den öffentlichen SSH-Schlüssel eines Systems auf ein entferntes System zu kopieren, um die Fernauthentifizierung zu erleichtern.
cloud-init: Wird verwendet, um die Konfiguration und Bereitstellung von virtuellen Maschinen und Containern in einer Cloudumgebung zu unterstützen.

Lösungen zu den geführten Übungen

Welche CPU-Erweiterungen sind auf einer x86-basierten Hardwareplattform erforderlich, um darauf vollständig virtualisierte Gäste auszuführen?

VT-x für Intel-CPUs oder AMD-V für AMD-CPUs
Eine unternehmenskritische Serverinstallation, welche die höchste Performanz erfordert, wird wahrscheinlich welche Art von Virtualisierung verwenden?

Ein Betriebssystem, das Paravirtualisierung wie Xen als Gastbetriebssystem nutzt, kann die verfügbaren Hardwareressourcen besser nutzen, wenn Softwaretreiber verwendet werden, die für die Zusammenarbeit mit dem Hypervisor entwickelt wurden.
Zwei virtuelle Maschinen, die von der gleichen Vorlage geklont wurden und den D-Bus verwenden, arbeiten fehlerhaft. Beide haben separate Hostnamen und Netzwerkkonfigurationseinstellungen. Welcher Befehl kann verwendet werden, um festzustellen, ob jede der virtuellen Maschinen unterschiedliche D-Bus-Maschinenkennungen besitzen?

dbus-uuidgen --get

Lösungen zu den offenen Übungen

Führen Sie den folgenden Befehl aus, um zu prüfen, ob in Ihrem System bereits CPU-Erweiterungen für die Ausführung virtueller Maschinen aktiviert sind (Ergebnisse können je nach CPU variieren):

grep --color -E "vmx|svm" /proc/cpuinfo

Abhängig vom System kann dies vmx (für Intel VT-x-aktivierte CPUs) oder svm (für AMD SVM-aktivierte CPUs) sein. Sollten Sie kein Ergebnis erhalten, überprüfen Sie Ihre BIOS- oder UEFI-Optionen, um die Virtualisierung für Ihren Prozessor zu aktivieren.

Die Ergebnisse variieren je nach CPU. Hier ist eine Beispielausgabe von einem Computer mit einer Intel-CPU mit aktivierten Virtualisierungserweiterungen:

$ grep --color -E "vmx|svm" /proc/cpuinfo
flags		: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb rdtscp lm constant_tsc art arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc cpuid aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 sdbg fma cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm abm 3dnowprefetch cpuid_fault epb invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm mpx rdseed adx smap clflushopt intel_pt xsaveopt xsavec xgetbv1 xsaves dtherm ida arat pln pts hwp hwp_notify hwp_act_window hwp_epp md_clear flush_l1d

Wenn Ihr Prozessor Virtualisierungen unterstützt, recherchieren Sie in der Dokumentation Ihrer Distribution bezüglich dem Ausführen eines KVM-Hypervisors.
- Installieren Sie die erforderlichen Pakete zum Ausführung eines KVM-Hypervisors.
  
  Dies variiert je nach verwendeter Distribution. Folgend einige Ansatzpunkte:
  
  Ubuntu — https://help.ubuntu.com/lts/serverguide/libvirt.html
  
  Fedora — https://docs.fedoraproject.org/en-US/quick-docs/getting-started-with-virtualization/
  
  Arch Linux — https://wiki.archlinux.org/index.php/KVM
- Wenn Sie eine grafische Desktopumgebung verwenden, empfiehlt es sich, auch die Anwendung virt-manager zu installieren, bei der es sich um ein grafisches Front-End handelt, welches auf einer KVM-Installation verwendet werden kann. Dies erleichert die Installation und Verwaltung von virtuellen Maschinen.
  
  Auch dies wird je nach Distribution variieren. Ein Beispiel für Ubuntu sieht wie folgt aus:
  $ sudo apt install virt-manager
- Laden Sie ein Linux-Distributions ISO-Image Ihrer Wahl herunter, und erstellen Sie mit Hilfe der Dokumentation Ihrer Distribution eine neue virtuelle Maschine anhand dieses ISO-Images.
  
  Diese Aufgabe wird leicht durch das virt-manager-Paket erledigt. Eine virtuelle Maschine kann jedoch von der Kommandozeile aus mit dem Befehl virt-install erstellt werden. Probieren Sie beide Methoden aus, um ein Verständnis dafür zu bekommen, wie virtuelle Maschinen eingesetzt werden.