LXD spielt seine Stärken beim Verwalten mehrerer LXD-Server aus. Sind zwei LXD-Instanzen miteinander verbunden, arbeiten die lxc-Kommandos Host-übergreifend, wie etwa:
$ lxc remote add lxd2 192.168.56.103:8090
Certificate fingerprint: b253acc45147d....
ok (y/n)? y
Admin password for lxd2:
Client certificate stored at server: lxd2
Das Admin-Passwort ist dasjenige, das bei "lxc init" angegeben wurde. Die Zeile "Client certificate stored at server: lxd2 " signalisiert, dass das lokale Client-Zertifikat am Host lxd2 eingerichtet ist. Somit starten lxc-Kommandos ohne weitere Authentifizierung am zweiten LXD-Host, wie Listing 4 zeigt.
Am wichtigsten Feature für den reibungslosen LXD-Betrieb im Cloud-Bereich wird noch gearbeitet: der Live-Migration von Containern über das CRIU-Framework. Auch nach der Veröffentlichung von Ubuntu 16.04 war dabei noch nicht alles im Reinen. Wenn irgendwann alles funktioniert, migriert lxc move einen Container live:
$ lxc move container0 lxd2: container0
Je mehr virtuelle Maschinen auf einem LXD-Host laufen, umso wichtiger ist die Ressourcen-Beschränkung einzelner Container. Die Möglichkeiten zur Limitierung orientieren sich an den Subsystemen der Linux Control Groups (cgroups) [1]. Die wichtigsten im Produktivbetrieb sind CPU, Hauptspeicher, I/O-Zugriffe und Netzwerkverkehr. Bereits vor LXD – bei Verwendung der lxc-tools – wurden Container-Limits definiert. Die Einstellungen wurden in eigens dafür vorgesehene Dateien eingetragen. LXD ändert diese Vorgehensweise – es führt eine lokale Datenbank als Backend und das Kommando lxc config ein [2]. Obendrein gibt es LXD-Profile, Konfigurationsvorlagen, die den Containern zugeordnet werden. Standardmäßig liefert eine LXD-Installation das Profil "default" aus:
$ lxc profile show default
name: default
config: {}
description: ""
devices:
eth0:
name: eth0
nictype: bridged
parent: lxcbr0
type: nic
Das Profil "default" verbindet einen Container mit der Bridge "lxcbr0" und macht ihn dadurch vom Host aus erreichbar. Ansonsten befinden sich darin keine weiteren Einstellungen. Wer möchte, kann das Profil aber beliebig erweitern:
$ lxc profile edit default
name: default
config: limits.memory: 128MB
[...]
Die Einstellung "limits.memory" erweitert in diesem Fall das Profil um eine Hauptspeicher-Beschränkung für Container. Jene, die das Profil nutzen, verbrauchen von nun an maximal 128 MByte an Arbeitsspeicher:
$ lxc profile apply container0 default
Profile default applied to container0
$ lxc exec container0 -- cat /proc/meminfo | grep MemTotal
MemTotal: 131072 kB
Wer nicht sofort das komplette Profil abändern möchte, setzt einzelne Parameter direkt für einen Container:
$ lxc config set container1 limits.memory 64MB
Listing 3: Container auflisten
$ lxc list +------------+----------------+-----------------------+-------+----------------+-----------------+ | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | +------------+----------------+-----------------------+-------+----------------+-----------------+ | container0 | RUNNING | 10.0.3.100 (eth0) | | PERSISTENT | 0 | +------------+----------------+-----------------------+-------+----------------+-----------------+ | container1 | STOPPED | | | PERSISTENT| 0 | +------------+----------------+-----------------------+-------+----------------+-----------------+
Listing 4: Ausführung auf einem anderen Container-Host
$ lxc launch trusty lxd2:trusty1 Creating trusty1 Starting trusty1 $ lxc list lxd2: +------------+----------------+-----------------------+-------+----------------+-----------------+ | NAME | STATE | IPV4 | IPV6 | TYPE | SNAPSHOTS | +------------+----------------+-----------------------+-------+----------------+-----------------+ | trusty1 | RUNNING | | | PERSISTENT| 0 | +------------+----------------+-----------------------+-------+----------------+-----------------+