[ English | Indonesia | Deutsch | 日本語 ]
Benutzerorientierte Operationen¶
Dieses Handbuch richtet sich an OpenStack-Betreiber und soll keine erschöpfende Referenz für Benutzer sein, aber als Betreiber sollten Sie über ein grundlegendes Verständnis für die Nutzung der Cloud-Einrichtungen verfügen. In diesem Kapitel wird OpenStack aus einer grundlegenden Benutzerperspektive betrachtet, die Ihnen hilft, die Bedürfnisse Ihrer Benutzer zu verstehen und festzustellen, wann Sie ein Trouble Ticket erhalten, ob es sich um ein Benutzerproblem oder ein Serviceproblem handelt. Die wichtigsten Konzepte sind Abbilder, Varianten, Sicherheitsgruppen, Blockspeicher, Shared File System Storage und Instanzen.
Bild¶
OpenStack-Abbilder können oft als „Vorlagen für virtuelle Maschinen“ bezeichnet werden. Abbilder können auch Standardinstallationsmedien wie ISO-Images sein. Im Wesentlichen enthalten sie bootfähige Dateisysteme, die zum Starten von Instanzen verwendet werden.
Hinzufügen vonAbbildern¶
Es gibt mehrere vorgefertigte Abbilder, die einfach in den Abbild-Dienst importiert werden können. Ein gängiges Abbild zum Hinzufügen ist das CirrOS-Bild, das sehr klein ist und zu Testzwecken verwendet wird. Um dieses Abbild hinzuzufügen, geben Sie einfach ein:
$ wget http://download.cirros-cloud.net/0.3.5/cirros-0.3.5-x86_64-disk.img
$ openstack image create --file cirros-0.3.5-x86_64-disk.img \
--public --container-format bare \
--disk-format qcow2 "cirros image"
Der Befehl openstack image create bietet eine Vielzahl von Optionen für die Arbeit mit Ihrem Abbild. Die Option --min-disk ist beispielsweise nützlich für Abbilder, die Root-Disks einer bestimmten Größe erfordern (z.B. große Windows Abbilder). Um diese Optionen anzuzeigen, führen Sie aus:
$ openstack help image create
Führen Sie den folgenden Befehl aus, um die Eigenschaften vorhandener Abbilder anzuzeigen:
$ openstack image show IMAGE_NAME_OR_UUID
Hinzufügen von signierten Abbildern¶
Um eine Vertrauenskette von einem Endbenutzer zum Abbild-Dienst und zum Compute-Abbild-Dienst zu schaffen, kann ein Endbenutzer signierte Abbilder importieren, die zunächst im Abbild-Dienst und später im Compute-Dienst verifiziert werden können. Für die Aktivierung dieser Signaturfunktion müssen entsprechende Eigenschaften des Abbild-Dienstes eingestellt werden.
Bemerkung
Vor den folgenden Schritten muss ein asymmetrisches Schlüsselpaar und Zertifikat generiert werden. In diesem Beispiel heißen diese private_key.pem bzw. new_cert.crt und befinden sich beide im aktuellen Verzeichnis. Beachten Sie auch, dass das Abbild in diesem Beispiel cirros-0.3.5-x86_64-disk.img ist, aber jedes Abbild kann verwendet werden.
Die folgenden Schritte sind erforderlich, um die Signatur zu erstellen, die für die signierten Abbilder verwendet wird:
Abbild zum Hochladen abrufen
$ wget http://download.cirros-cloud.net/0.3.5/cirros-0.3.5-x86_64-disk.img
Verwenden Sie den privaten Schlüssel, um eine Signatur des Abbildes zu erstellen
Bemerkung
Die folgenden impliziten Werte werden in diesem Beispiel zur Erstellung der Signatur verwendet:
Signatur-Hash-Verfahren = SHA-256
Signaturschlüsseltyp = RSA-PSS
Bemerkung
Die folgenden Optionen werden derzeit unterstützt:
Signatur-Hash-Methoden: SHA-224, SHA-256, SHA-384 und SHA-512
Signaturschlüsseltypen: DSA, ECC_SECT571K1, ECC_SECT409K1, ECC_SECT571R1, ECC_SECT409R1, ECC_SECP521R1, ECC_SECP384R1 und RSA-PSS
Erzeugen Sie eine Signatur des Abbildes und konvertieren Sie es in eine base64-Darstellung:
$ openssl dgst -sha256 -sign private_key.pem -sigopt rsa_padding_mode:pss \ -out image-file.signature cirros-0.3.5-x86_64-disk.img $ base64 -w 0 image-file.signature > signature_64 $ cat signature_64 'c4br5f3FYQV6Nu20cRUSnx75R/VcW3diQdsUN2nhPw+UcQRDoGx92hwMgRxzFYeUyydRTWCcUS2ZLudPR9X7rM THFInA54Zj1TwEIbJTkHwlqbWBMU4+k5IUIjXxHO6RuH3Z5f/SlSt7ajsNVXaIclWqIw5YvEkgXTIEuDPE+C4='
Bemerkung
Die Verwendung der Image API v1 erfordert oben ‚-w 0‘, da mehrzeilige Abbildeigenschaften nicht unterstützt werden.
Die Image API v2 unterstützt mehrzeilige Eigenschaften, so dass diese Option für v2 nicht erforderlich ist, aber dennoch verwendet werden kann.
Kontext anlegen
$ python >>> from keystoneclient.v3 import client >>> keystone_client = client.Client(username='demo', user_domain_name='Default', password='password', project_name='demo', auth_url='http://localhost:5000/v3') >>> from oslo_context import context >>> context = context.RequestContext(auth_token=keystone_client.auth_token, tenant=keystone_client.project_id)
Zertifikat im DER-Format kodieren
>>> from cryptography import x509 as cryptography_x509 >>> from cryptography.hazmat import backends >>> from cryptography.hazmat.primitives import serialization >>> with open("new_cert.crt", "rb") as cert_file: >>> cert = cryptography_x509.load_pem_x509_certificate( cert_file.read(), backend=backends.default_backend() ) >>> certificate_der = cert.public_bytes(encoding=serialization.Encoding.DER)
Zertifikat im DER-Format in Castellan hochladen
>>> from castellan.common.objects import x_509 >>> from castellan import key_manager >>> castellan_cert = x_509.X509(certificate_der) >>> key_API = key_manager.API() >>> cert_uuid = key_API.store(context, castellan_cert) >>> cert_uuid u'62a33f41-f061-44ba-9a69-4fc247d3bfce'
Hochladen von Abbildern zum Abbild-Dienst mit Signatur-Metadaten
Bemerkung
Die folgenden Signatureigenschaften werden verwendet:
img_signature verwendet die Signatur signature_64
img_signature_certificate_uuuid verwendet den Wert von cert_uuuid in Abschnitt 5 oben
img_signature_hash_method passt zu’SHA-256‘ in Abschnitt 2 oben
img_signature_key_type entspricht ‚RSA-PSS‘ in Abschnitt 2 oben
$ . openrc demo $ export OS_IMAGE_API_VERSION=2 $ openstack image create --property name=cirrosSignedImage_goodSignature \ --property is-public=true --container-format bare --disk-format qcow2 \ --property img_signature='c4br5f3FYQV6Nu20cRUSnx75R/VcW3diQdsUN2nhPw+UcQRDoGx92hwMgRxzFYeUyydRTWCcUS2ZLudPR9X7rMTHFInA54Zj1TwEIbJTkHwlqbWBMU4+k5IUIjXxHO6RuH3Z5fSlSt7ajsNVXaIclWqIw5YvEkgXTIEuDPE+C4=' \ --property img_signature_certificate_uuid='62a33f41-f061-44ba-9a69-4fc247d3bfce' \ --property img_signature_hash_method='SHA-256' \ --property img_signature_key_type='RSA-PSS' < ~/cirros-0.3.5-x86_64-disk.img
Bemerkung
Die maximale Grenze für die Zeichensignatur des Abbildes beträgt 255.
Überprüfen Sie die Keystone-URL
Bemerkung
Die Standardkonfiguration von Keystone geht davon aus, dass sich Keystone im lokalen Host befindet, und verwendet
http://localhost:5000/v3als Endpunkt-URL, die in den Dateienglance-api.confundnova-api.confangegeben ist:[barbican] auth_endpoint = http://localhost:5000/v3
Bemerkung
Wenn sich Keystone stattdessen entfernt befindet, bearbeiten Sie die Dateien
glance-api.confundnova.conf. Konfigurieren Sie im Abschnitt[barbican]die Optionauth_endpoint:[barbican] auth_endpoint = https://192.168.245.9:5000/v3
Die Signaturprüfung tritt auf, wenn Compute das signierte Abbild startet
Bemerkung
nova-compute servers müssen zunächst durch die folgenden Schritte aktualisiert werden:
Stellen Sie sicher, dass cryptsetup installiert ist, und stellen Sie sicher, dass
pythin-barbicanclientPython-Paket installiert istRichten Sie den Key Manager-Dienst ein, indem Sie /etc/nova/nova/nova.conf bearbeiten und die Einträge im folgenden Codeblock hinzufügen
Das Flag verify_glance_signatures ermöglicht Compute die automatische Validierung signierter Instanzen vor dem Start. Diese Validierungsfunktion ist aktiviert, wenn der Wert auf TRUE gesetzt ist
[key_manager] api_class = castellan.key_manager.barbican_key_manager.BarbicanKeyManager [glance] verify_glance_signatures = TRUE
Bemerkung
Die api_class[keymgr] ist ab Newton veraltet, daher sollte sie nicht in dieser Version oder darüber hinaus enthalten sein.
Löschen von Abbildern¶
Um ein Abbild zu löschen, führen Sie es einfach aus:
$ openstack image delete IMAGE_NAME_OR_UUID
Vorsicht
Im Allgemeinen hat das Löschen eines Abbildes keinen Einfluss auf Instanzen oder Schattenkopien, die auf dem Abbild basieren. Einige Treiber können jedoch verlangen, dass das Originalabbild vorhanden ist, um eine Migration durchzuführen. Beispielsweise funktioniert die XenAPI-Live-Migration gut, wenn das Abbild gelöscht wird, aber libvirt schlägt fehl.
Weitere CLI-Optionen¶
Ein kompletter Satz von Optionen kann über:
$ glance help
oder die Command-Line Interface Reference.
Der Abbild-Dienst und die Datenbank¶
Das Einzige, was der Abbild-Dienst nicht in einer Datenbank speichert, ist das Abbild selbst. Die Datenbank des Abbild-Dienstes hat zwei Haupttabellen:
„Abbilder“
image_properties
Die direkte Arbeit mit der Datenbank und SQL-Abfragen kann Ihnen benutzerdefinierte Listen und Berichte über Abbilder liefern. Technisch gesehen können Sie Eigenschaften von Abbildern über die Datenbank aktualisieren, obwohl dies im Allgemeinen nicht empfohlen wird.
Beispiel Abbild-Dienst Datenbankabfragen¶
Ein interessantes Beispiel ist das Ändern der Tabelle der Abbilder und des Besitzers dieses Abbildes. Dies ist einfach möglich, wenn Sie einfach die eindeutige ID des Eigentümers anzeigen. Dieses Beispiel geht einen Schritt weiter und zeigt den lesbaren Namen des Eigentümers an:
mysql> select glance.images.id,
glance.images.name, keystone.tenant.name, is_public from
glance.images inner join keystone.tenant on
glance.images.owner=keystone.tenant.id;
Ein weiteres Beispiel ist die Anzeige aller Eigenschaften für ein bestimmtes Abbild:
mysql> select name, value from
image_properties where id = <image_id>
Varianten¶
Virtuelle Hardware-Vorlagen werden in OpenStack als „Varianten“ bezeichnet und definieren Größen für RAM, Festplatte, Anzahl der Kerne usw. Die Standardinstallation bietet fünf Varianten.
Diese sind von Admin-Benutzern konfigurierbar (die Rechte können auch an andere Benutzer delegiert werden, indem die Zugriffskontrollen für compute_extension:flavormanage in /etc/nova/policy.json auf dem nova-api` Server neu definiert werden). Um die Liste der verfügbaren Flavors auf Ihrem System zu erhalten, führen Sie run:
$ openstack flavor list
+----+-----------+-------+------+-----------+-------+-----------+
| ID | Name | RAM | Disk | Ephemeral | VCPUs | Is Public |
+----+-----------+-------+------+-----------+-------+-----------+
| 1 | m1.tiny | 512 | 1 | 0 | 1 | True |
| 2 | m1.small | 2048 | 20 | 0 | 1 | True |
| 3 | m1.medium | 4096 | 40 | 0 | 2 | True |
| 4 | m1.large | 8192 | 80 | 0 | 4 | True |
| 5 | m1.xlarge | 16384 | 160 | 0 | 8 | True |
+----+-----------+-------+------+-----------+-------+-----------+
Der Befehl openstack flavor create ermöglicht es autorisierten Benutzern, neue Varianten zu erstellen. Zusätzliche Befehle zur Manipulation von Varianten können mit dem folgenden Befehl angezeigt werden:
$ openstack help | grep flavor
Varianten definieren eine Reihe von Parametern, so dass der Benutzer die Wahl hat, welchen Typ von virtueller Maschine er ausführen möchte - genau wie beim Kauf eines physischen Servers. Tabelle. Variantenparameter listet die Elemente auf, die gesetzt werden können. Beachten Sie insbesondere extra_specs, mit dem Sie Freiformmerkmale definieren können, die eine große Flexibilität über die Größe von RAM, CPU und Festplatte hinaus bieten.
Column |
Beschreibung |
|---|---|
ID |
Eindeutige ID (Integer oder UUID) für die Variante. |
Name |
Ein beschreibender Name, wie z.B. xx.size_name, ist konventionell, aber nicht erforderlich, obwohl einige Tools von Drittanbietern darauf angewiesen sein können. |
Speicher_MB |
Speicher der virtuellen Maschine in Megabyte. |
Disk |
Größe der virtuellen Root-Festplatte in Gigabyte. Dies ist eine ephemere Festplatte, in die das Basis-Abbild kopiert wird. Sie verwenden es nicht, wenn Sie von einem persistenten Datenträger booten. Die Größe „0“ ist ein Sonderfall, der die native Größe des Basisabbbildes als Größe des ephemeren root-Datenträgers verwendet. |
Ephemeral |
Gibt die Größe einer sekundären ephemeren Datenplatte an. Dies ist eine leere, unformatierte Festplatte und existiert nur für das Leben der Instanz. |
Swap |
Optionale Swap Space-Zuweisung für die Instanz. |
VCPUs |
Anzahl der virtuellen CPUs, die der Instanz präsentiert werden. |
RXTX_Factor |
Optionale Eigenschaft, die es den erstellten Servern ermöglicht, eine andere Bandbreitenobergrenze als die in dem Netzwerk, an das sie angeschlossen sind, definierte zu haben. Dieser Faktor wird mit der rxtx_base Eigenschaft des Netzwerks multipliziert. Der Standardwert ist 1,0 (d.h. derselbe wie im angeschlossenen Netzwerk). |
Is_Public |
Boolescher Wert, der angibt, ob die Variante für alle Benutzer oder privat verfügbar ist. Private Varianten erhalten nicht den aktuellen Mandanten, der ihnen zugeordnet ist. Standardwert ist |
extra_specs |
Zusätzliche optionale Einschränkungen, auf welchen Compute-Knoten der Flavor laufen kann. Dies ist als Schlüssel-Wert-Paare implementiert, die mit den entsprechenden Schlüssel-Wert-Paaren auf Compute-Knoten übereinstimmen müssen. Kann verwendet werden, um Dinge wie spezielle Ressourcen zu implementieren (z.B. Varianten, die nur auf Compute-Knoten mit GPU-Hardware laufen können). |
Private Varianten¶
Ein Benutzer benötigt möglicherweise eine benutzerdefinierte Variante, die speziell auf ein Projekt abgestimmt ist, an dem er gerade arbeitet. So kann der Benutzer beispielsweise 128 GB Speicherplatz benötigen. Wenn Sie wie oben beschrieben eine neue Variante anlegen, hat der Benutzer Zugriff auf den benutzerdefinierten Variante, aber auch alle anderen Mandanten in Ihrer Cloud. Manchmal ist diese Freigabe nicht erwünscht. In diesem Szenario kann es in diesem Fall sehr schnell dazu führen, dass Ihre Cloud die volle Kapazität erreicht, wenn alle Benutzer Zugriff auf eine Variante mit 128 GB Speicher haben. Um dies zu verhindern, können Sie den Zugriff auf den benutzerdefinierten Variante mit dem Befehl ‚ command:nova flavor-access-add einschränken:
$ nova flavor-access-add FLAVOR_ID PROJECT_ID
Um die Zugriffsliste einer Variante anzuzeigen, gehen Sie wie folgt vor:
$ nova flavor-access-list [--flavor FLAVOR_ID]
Tipp
Sobald der Zugriff auf einen Flavor eingeschränkt wurde, können keine anderen Projekte außer denjenigen, die expliziten Zugriff haben, die Variante sehen. Dazu gehört auch das Admin-Projekt. Achten Sie darauf, dass Sie das Admin-Projekt zusätzlich zum ursprünglichen Projekt hinzufügen.
Es ist auch hilfreich, einen bestimmten numerischen Bereich für benutzerdefinierte und private Varianten zuzuweisen. Auf UNIX-basierten Systemen haben Nicht-system-Konten in der Regel eine UID ab 500. Ein ähnlicher Ansatz kann mit kundenspezifischen Varianten verfolgt werden. Auf diese Weise können Sie leicht erkennen, welche Varianten für die gesamte Cloud benutzerdefiniert, privat und öffentlich sind.
Wie modifiziere ich eine bestehende Variante?¶
Das OpenStack-Dashboard simuliert die Möglichkeit, einen Variante zu ändern, indem es eine bestehende Variante löscht und einen neuen mit dem gleichen Namen erstellt.
Sicherheitsgruppen¶
Ein häufiges Problem mit OpenStack für neue Benutzer kann beim Starten einer Instanz keine geeignete Sicherheitsgruppe festlegen. Infolgedessen kann der Benutzer die Instanz im Netzwerk nicht kontaktieren.
Sicherheitsgruppen sind Sätze von IP-Filterregeln, die auf das Netzwerk einer Instanz angewendet werden. Sie sind projektspezifisch, und die Projektmitglieder können die Standardregeln für ihre Gruppe bearbeiten und neue Regelsätze hinzufügen. Alle Projekte haben eine „default“-Sicherheitsgruppe, die auf Instanzen angewendet wird, die keine andere Sicherheitsgruppe definiert haben. Sofern nicht anders angegeben, verweigert diese Sicherheitsgruppe den gesamten eingehenden Datenverkehr.
Tipp
Wie im vorherigen Kapitel erwähnt, wird die Anzahl der Regeln pro Sicherheitsgruppe durch die quota_security_group_rules gesteuert, und die Anzahl der zulässigen Sicherheitsgruppen pro Projekt wird durch die quota_security_groups Quota gesteuert.
Endbenutzerkonfiguration von Sicherheitsgruppen¶
Sicherheitsgruppen für das aktuelle Projekt finden Sie im OpenStack-Dashboard unter Access & Security. Um Details zu einer bestehenden Gruppe anzuzeigen, wählen Sie die Aktion Edit Security Group für diese Sicherheitsgruppe. Natürlich kann das Ändern bestehender Gruppen über diese Bearbeitungsoberfläche erfolgen. Es gibt eine Schaltfläche Create Security Group auf der Hauptseite Access & Security zum Erstellen neuer Gruppen. Wir besprechen die in diesen Feldern verwendeten Begriffe, wenn wir die Befehlszeilenäquivalente erklären.
Einstellung mit Openstack-Befehl
Wenn Ihre Umgebung Neutron verwendet, können Sie die Einstellungen für Sicherheitsgruppen mit dem Befehl openstack konfigurieren. Holen Sie sich eine Liste der Sicherheitsgruppen für das Projekt, in dem Sie tätig sind, indem Sie folgenden Befehl verwenden:
$ openstack security group list
+------------------------+---------+------------------------+-------------------------+
| ID | Name | Description | Project |
+------------------------+---------+------------------------+-------------------------+
| 3bef30ed-442d-4cf1 | default | Default security group | 35e3820f7490493ca9e3a5e |
| -b84d-2ba50a395599 | | | 685393298 |
| aaf1d0b7-98a0-41a3-ae1 | default | Default security group | 32e9707393c34364923edf8 |
| 6-a58b94503289 | | | f5029cbfe |
+------------------------+---------+------------------------+-------------------------+
Um die Details einer Sicherheitsgruppe anzuzeigen:
$ openstack security group show 3bef30ed-442d-4cf1-b84d-2ba50a395599
+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field | Value |
+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| created_at | 2016-11-08T21:55:19Z |
| description | Default security group |
| id | 3bef30ed-442d-4cf1-b84d-2ba50a395599 |
| name | default |
| project_id | 35e3820f7490493ca9e3a5e685393298 |
| project_id | 35e3820f7490493ca9e3a5e685393298 |
| revision_number | 1 |
| rules | created_at='2016-11-08T21:55:19Z', direction='egress', ethertype='IPv6', id='1dca4cac-d4f2-46f5-b757-d53c01a87bdf', project_id='35e3820f7490493ca9e3a5e685393298', |
| | revision_number='1', updated_at='2016-11-08T21:55:19Z' |
| | created_at='2016-11-08T21:55:19Z', direction='egress', ethertype='IPv4', id='2d83d6f2-424e-4b7c-b9c4-1ede89c00aab', project_id='35e3820f7490493ca9e3a5e685393298', |
| | revision_number='1', updated_at='2016-11-08T21:55:19Z' |
| | created_at='2016-11-08T21:55:19Z', direction='ingress', ethertype='IPv4', id='62b7d1eb-b98d-4707-a29f-6df379afdbaa', project_id='35e3820f7490493ca9e3a5e685393298', remote_group_id |
| | ='3bef30ed-442d-4cf1-b84d-2ba50a395599', revision_number='1', updated_at='2016-11-08T21:55:19Z' |
| | created_at='2016-11-08T21:55:19Z', direction='ingress', ethertype='IPv6', id='f0d4b8d6-32d4-4f93-813d-3ede9d698fbb', project_id='35e3820f7490493ca9e3a5e685393298', remote_group_id |
| | ='3bef30ed-442d-4cf1-b84d-2ba50a395599', revision_number='1', updated_at='2016-11-08T21:55:19Z' |
| updated_at | 2016-11-08T21:55:19Z |
+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
Diese Regeln sind alle „allow“-Typenregeln, da der Standard abgelehnt wird. Dieses Beispiel zeigt den vollen Portbereich für alle Protokolle, die von allen IPs erlaubt sind. In diesem Abschnitt werden die gängigsten Parameter für Sicherheitsgruppenregeln beschrieben:
- Richtung
Die Richtung, in der die Sicherheitsgruppenregel angewendet wird. Gültige Werte sind
ingressoderegress.- remote_ip_prefix
Dieser Attributwert entspricht dem angegebenen IP-Präfix als Quell-IP-Adresse des IP-Pakets.
- protocol
Das Protokoll, das von der Sicherheitsgruppenregel übernommen wird. Gültige Werte sind
null`,tcp,udp`,icmp, icmp` undicmpv6.- port_range_min
Die minimale Portnummer in dem Bereich, der von der Sicherheitsgruppenregel erfüllt wird. Wenn das Protokoll TCP oder UDP ist, muss dieser Wert kleiner oder gleich dem Attributwert
port_range_max_maxsein. Wenn das Protokoll ICMP oder ICMPv6 ist, muss dieser Wert ein ICMP- bzw. ICMPv6-Typ sein.- port_range_max
Die maximale Portnummer in dem Bereich, die von der Sicherheitsgruppenregel erfüllt wird. Das Attribut
port_range_minbeschränkt das Attributport_range_max. Wenn das Protokoll ICMP oder ICMPv6 ist, muss dieser Wert ein ICMP- bzw. ICMPv6-Typ sein.- ethertype
Muss
IPv4oderIPv6`sein, und die im CIDR vertretenen Adressen müssen den Ein- oder Ausgangsregeln entsprechen.
Wenn Sie eine neue Sicherheitsgruppe hinzufügen, sollten Sie einen beschreibenden, aber kurzen Namen wählen. Dieser Name erscheint in Kurzbeschreibungen der Instanzen, die ihn verwenden, wo das längere Beschreibungsfeld dies oft nicht tut. Zu sehen, dass eine Instanz die Sicherheitsgruppe http verwendet, ist viel einfacher zu verstehen als bobs_group` oder secgrp1.
Dieses Beispiel erstellt eine Sicherheitsgruppe, die Webverkehr überall im Internet zulässt. Wir nennen diese Gruppe global_http, die klar und einigermaßen prägnant ist und kapselt, was erlaubt ist und von wo aus. Von der Kommandozeile aus, tun Sie es:
$ openstack security group create global_http --description "allow web traffic from the Internet"
Created a new security_group:
+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field | Value |
+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| created_at | 2016-11-10T16:09:18Z |
| description | allow web traffic from the Internet |
| headers | |
| id | 70675447-1b92-4102-a7ea-6a3ca99d2290 |
| name | global_http |
| project_id | 32e9707393c34364923edf8f5029cbfe |
| project_id | 32e9707393c34364923edf8f5029cbfe |
| revision_number | 1 |
| rules | created_at='2016-11-10T16:09:18Z', direction='egress', ethertype='IPv4', id='e440b13a-e74f-4700-a36f-9ecc0de76612', project_id='32e9707393c34364923edf8f5029cbfe', |
| | revision_number='1', updated_at='2016-11-10T16:09:18Z' |
| | created_at='2016-11-10T16:09:18Z', direction='egress', ethertype='IPv6', id='0debf8cb-9f1d-45e5-98db-ee169c0715fe', project_id='32e9707393c34364923edf8f5029cbfe', |
| | revision_number='1', updated_at='2016-11-10T16:09:18Z' |
| updated_at | 2016-11-10T16:09:18Z |
+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
Unmittelbar nach dem Erstellen hat die Sicherheitsgruppe nur eine Zulassungsaustrittsregel. Damit es das tut, was wir wollen, müssen wir einige Regeln hinzufügen:
$ openstack security group rule create --help
usage: openstack security group rule create [-h]
[-f {json,shell,table,value,yaml}]
[-c COLUMN]
[--max-width <integer>]
[--noindent] [--prefix PREFIX]
[--remote-ip <ip-address> | --remote-group <group>]
[--dst-port <port-range>]
[--icmp-type <icmp-type>]
[--icmp-code <icmp-code>]
[--protocol <protocol>]
[--ingress | --egress]
[--ethertype <ethertype>]
[--project <project>]
[--project-domain <project-domain>]
<group>
$ openstack security group rule create --ingress --ethertype IPv4 \
--protocol tcp --remote-ip 0.0.0.0/0 global_http
Created a new security group rule:
+-------------------+--------------------------------------+
| Field | Value |
+-------------------+--------------------------------------+
| created_at | 2016-11-10T16:12:27Z |
| description | |
| direction | ingress |
| ethertype | IPv4 |
| headers | |
| id | 694d30b1-1c4d-4bb8-acbe-7f1b3de2b20f |
| port_range_max | None |
| port_range_min | None |
| project_id | 32e9707393c34364923edf8f5029cbfe |
| project_id | 32e9707393c34364923edf8f5029cbfe |
| protocol | tcp |
| remote_group_id | None |
| remote_ip_prefix | 0.0.0.0/0 |
| revision_number | 1 |
| security_group_id | 70675447-1b92-4102-a7ea-6a3ca99d2290 |
| updated_at | 2016-11-10T16:12:27Z |
+-------------------+--------------------------------------+
Obwohl nur die neu hinzugefügte Regel ausgegeben wird, ist diese Operation additiv:
$ openstack security group show global_http
+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Field | Value |
+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| created_at | 2016-11-10T16:09:18Z |
| description | allow web traffic from the Internet |
| id | 70675447-1b92-4102-a7ea-6a3ca99d2290 |
| name | global_http |
| project_id | 32e9707393c34364923edf8f5029cbfe |
| project_id | 32e9707393c34364923edf8f5029cbfe |
| revision_number | 2 |
| rules | created_at='2016-11-10T16:09:18Z', direction='egress', ethertype='IPv6', id='0debf8cb-9f1d-45e5-98db-ee169c0715fe', project_id='32e9707393c34364923edf8f5029cbfe', |
| | revision_number='1', updated_at='2016-11-10T16:09:18Z' |
| | created_at='2016-11-10T16:12:27Z', direction='ingress', ethertype='IPv4', id='694d30b1-1c4d-4bb8-acbe-7f1b3de2b20f', project_id='32e9707393c34364923edf8f5029cbfe', protocol='tcp', |
| | remote_ip_prefix='0.0.0.0/0', revision_number='1', updated_at='2016-11-10T16:12:27Z' |
| | created_at='2016-11-10T16:09:18Z', direction='egress', ethertype='IPv4', id='e440b13a-e74f-4700-a36f-9ecc0de76612', project_id='32e9707393c34364923edf8f5029cbfe', |
| | revision_number='1', updated_at='2016-11-10T16:09:18Z' |
| updated_at | 2016-11-10T16:12:27Z |
+-----------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
Die umgekehrte Operation heißt openstack security group rule delete und gibt die ID der Sicherheitsgruppe an. Ganze Sicherheitsgruppen können mit openstack security group delete entfernt werden.
Um Sicherheitsgruppenregeln für einen Cluster von Instanzen zu erstellen, verwenden Sie RemoteGroups.
RemoteGroups sind eine dynamische Möglichkeit, den CIDR der zulässigen Quellen zu definieren. Der Benutzer gibt eine RemoteGroup (Sicherheitsgruppenname) an, und dann werden alle anderen Instanzen der Benutzer, die die angegebene RemoteGroup verwenden, dynamisch ausgewählt. Diese dynamische Auswahl erspart die Notwendigkeit individueller Regeln, um jedes neue Mitglied des Clusters zuzulassen.
Der Code ähnelt dem obigen Beispiel von openstack security group rule create. Um RemoteGroup zu verwenden, geben Sie --remote-group anstelle von --remote-ip an. Zum Beispiel:
$ openstack security group rule create --ingress \
--ethertype IPv4 --protocol tcp \
--remote-group global_http cluster
Die „Cluster“-Regel erlaubt den SSH-Zugriff von jeder anderen Instanz aus, die die Gruppe global-http verwendet.
Block Speicher¶
OpenStack-Datenträger sind persistente Blockspeichergeräte, die angehängt und von Instanzen getrennt werden können, aber immer nur an eine Instanz gleichzeitig angehängt werden können. Ähnlich wie bei einer externen Festplatte bieten sie keinen gemeinsamen Speicher wie ein Netzwerk-Dateisystem oder ein Objektspeicher. Es bleibt dem Betriebssystem in der Instanz überlassen, ein Dateisystem auf das Blockgerät zu legen und es zu mounten oder nicht.
Wie bei anderen Wechselplattentechnologien ist es wichtig, dass das Betriebssystem nicht versucht, die Festplatte zu nutzen, bevor es sie entfernt. Bei Linux-Instanzen bedeutet dies in der Regel, dass alle Dateisysteme, die vom Datenträger gemountet sind, entfernt werden. Der OpenStack-Datenträger-Dienst kann nicht sagen, ob es sicher ist, Datenträger aus einer Instanz zu entfernen, also tut er, was ihm gesagt wird. Wenn ein Benutzer den Datenträger-Dienst anweist, ein Datenträger von einer Instanz zu trennen, während es geschrieben wird, können Sie eine gewisse Beschädigung des Dateisystems sowie Fehler von jedem Prozess innerhalb der Instanz erwarten, der das Gerät verwendet hat.
Es ist nichts OpenStack-spezifisches, sich der Schritte bewusst zu sein, die erforderlich sind, um auf Blockgeräte innerhalb des Instanzbetriebssystems zuzugreifen, sie möglicherweise für die erste Verwendung zu formatieren und vorsichtig zu sein, wenn man sie entfernt. Das Besondere daran ist, wie man neue Datenträger erstellt und sie anhängt und von Instanzen trennt. Diese Operationen können alle über die Seite Volumes des Dashboards oder über den Befehlszeilen-Client openstack durchgeführt werden.
Um neue Datenträger hinzuzufügen, benötigen Sie nur eine Datenträgergröße in Gigabyte. Geben Sie diese entweder in das Webformular Create Volume ein oder verwenden Sie die Befehlszeile:
$ openstack volume create volume1 --size 10
Dadurch wird ein 10 GB großer Datenträger erstellt. Auflistung der vorhandenen Datenträger und der Instanzen, mit denen sie verbunden sind, falls vorhanden:
$ openstack volume list
+--------------------------------------+--------------+--------+------+-------------+
| ID | Display Name | Status | Size | Attached to |
+--------------------------------------+--------------+--------+------+-------------+
| 6cf4114a-56b2-476b-acf7-7359d8334aa2 | volume1 | error | 10 | |
+--------------------------------------+--------------+--------+------+-------------+
OpenStack Blockspeicher ermöglicht auch die Erstellung von Schattenkopien von Datenträgern. Denken Sie daran, dass es sich hierbei um einen Snapshot auf Blockebene handelt, der absturzkonsistent ist, so dass es am besten ist, wenn der Datenträger nicht mit einer Instanz verbunden ist, wenn die Schattenkopie erstellt wird, und zweitbester, wenn der Datenträger nicht auf der Instanz verwendet wird, an die es angehängt ist. Wenn der Datenträger stark genutzt wird, kann die Schattenkopie ein inkonsistentes Dateisystem aufweisen. Standardmäßig erstellt der Datenträger-Dienst keine Schattenkopie eines Datenträger, das an ein Abbild angehängt ist, obwohl er dazu gezwungen werden kann. Um einen Datei-Überblick zu erstellen, wählen Sie entweder Create Snapshot in der Spalte actions neben dem Datenträgernamen auf der Dashboard Volumes Seite, oder führen Sie diesen über die Befehlszeile aus:
$ openstack help snapshot create
usage: openstack snapshot create [-h] [-f {json,shell,table,value,yaml}]
[-c COLUMN] [--max-width <integer>]
[--noindent] [--prefix PREFIX]
[--name <name>] [--description <description>]
[--force] [--property <key=value>]
<volume>
Create new snapshot
positional arguments:
<volume> Volume to snapshot (name or ID)
optional arguments:
-h, --help show this help message and exit
--name <name> Name of the snapshot
--description <description>
Description of the snapshot
--force Create a snapshot attached to an instance. Default is
False
--property <key=value>
Set a property to this snapshot (repeat option to set
multiple properties)
output formatters:
output formatter options
-f {json,shell,table,value,yaml}, --format {json,shell,table,value,yaml}
the output format, defaults to table
-c COLUMN, --column COLUMN
specify the column(s) to include, can be repeated
table formatter:
--max-width <integer>
Maximum display width, <1 to disable. You can also use
the CLIFF_MAX_TERM_WIDTH environment variable, but the
parameter takes precedence.
json formatter:
--noindent whether to disable indenting the JSON
shell formatter:
a format a UNIX shell can parse (variable="value")
--prefix PREFIX add a prefix to all variable names
Bemerkung
Weitere Informationen zum Aktualisieren von Blockspeicher-Datenträgern (z.B. Größenänderung oder Übertragung) finden Sie im OpenStack End User Guide.
Fehler bei der Erstellung von Blockspeichern¶
Wenn ein Benutzer versucht, einen Datenträger zu erstellen und der Datenträger in einen Fehlerzustand versetzt wird, ist der beste Weg zur Fehlerbehebung, die Cinder-Logdateien für die UUID des Datenträgers zu erfassen. Versuchen Sie zuerst die Protokolldateien auf dem Cloud-Controller und dann den Speicherknoten, auf dem der Datenträger erstellt werden sollte:
# grep 903b85d0-bacc-4855-a261-10843fc2d65b /var/log/cinder/*.log
Instanz¶
Instanzen sind die laufenden virtuellen Maschinen innerhalb einer OpenStack-Cloud. In diesem Abschnitt erfahren Sie, wie Sie mit ihnen und den zugrunde liegenden Abbildern, ihren Netzwerkeigenschaften und ihrer Darstellung in der Datenbank arbeiten.
Startinstanzen¶
Um eine Instanz zu starten, müssen Sie ein Abbild, eine Variante und einen Namen auswählen. Der Name muss nicht eindeutig sein, aber Ihr Leben wird einfacher sein, wenn es darum geht, dass viele Tools den Namen anstelle der UUID verwenden, solange der Name eindeutig ist. Sie können eine Instanz aus dem Dashboard über die Schaltfläche Launch Instance auf der Seite Instances starten oder indem Sie die Aktion Launch neben einem Abbild oder einem Schattenkopie auf der Seite Images auswählen.
Führen Sie dies auf der Befehlszeile aus:
$ openstack server create --flavor FLAVOR --image IMAGE_NAME_OR_ID
Es gibt eine Reihe von optionalen Elementen, die angegeben werden können. Du solltest den Rest dieses Abschnitts lesen, bevor du versuchst, eine Instanz zu starten, aber das ist der Basisbefehl, auf dem spätere Details geschichtet sind.
Um Instanzen aus dem Dashboard zu löschen, wählen Sie die Aktion Delete Instance neben der Instanz auf der Seite Instances.
Bemerkung
In Releases vor Mitaka wählen Sie die entsprechende Aktion Terminate instance.
Führen Sie dies über die Befehlszeile aus:
$ openstack server delete INSTANCE_ID
Es ist wichtig zu beachten, dass das Ausschalten einer Instanz diese nicht im Sinne von OpenStack beendet.
Instanz Boot-Fehler¶
Wenn eine Instanz nicht startet und sofort in einen Fehlerzustand übergeht, gibt es verschiedene Möglichkeiten, um herauszufinden, was schief gelaufen ist. Einige davon können mit normalem Benutzerzugriff durchgeführt werden, während andere den Zugriff auf Ihren Protokollserver oder Compute-Knoten erfordern.
Die einfachsten Gründe, warum Knoten nicht starten können, sind Quotenverletzungen oder der Scheduler kann keinen geeigneten Compute-Knoten finden, auf dem die Instanz ausgeführt werden kann. In diesen Fällen ist der Fehler offensichtlich, wenn Sie einen openstack server show auf der fehlerhaften Instanz ausführen:
$ openstack server show test-instance
+--------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------+
| Field | Value |
+--------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------+
| OS-DCF:diskConfig | AUTO |
| OS-EXT-AZ:availability_zone | nova |
| OS-EXT-SRV-ATTR:host | None |
| OS-EXT-SRV-ATTR:hypervisor_hostname | None |
| OS-EXT-SRV-ATTR:instance_name | instance-0000000a |
| OS-EXT-STS:power_state | NOSTATE |
| OS-EXT-STS:task_state | None |
| OS-EXT-STS:vm_state | error |
| OS-SRV-USG:launched_at | None |
| OS-SRV-USG:terminated_at | None |
| accessIPv4 | |
| accessIPv6 | |
| addresses | |
| config_drive | |
| created | 2016-11-23T07:51:53Z |
| fault | {u'message': u'Build of instance 6ec42311-a121-4887-aece-48fb93a4a098 aborted: Failed to allocate the network(s), not rescheduling.', |
| | u'code': 500, u'details': u' File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 1779, in |
| | _do_build_and_run_instance\n filter_properties)\n File "/usr/lib/python2.7/site-packages/nova/compute/manager.py", line 1960, in |
| | _build_and_run_instance\n reason=msg)\n', u'created': u'2016-11-23T07:57:04Z'} |
| flavor | m1.tiny (1) |
| hostId | |
| id | 6ec42311-a121-4887-aece-48fb93a4a098 |
| image | cirros (9fef3b2d-c35d-4b61-bea8-09cc6dc41829) |
| key_name | None |
| name | test-instance |
| os-extended-volumes:volumes_attached | [] |
| project_id | 5669caad86a04256994cdf755df4d3c1 |
| properties | |
| status | ERROR |
| updated | 2016-11-23T07:57:04Z |
| user_id | c36cec73b0e44876a4478b1e6cd749bb |
+--------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------+
In diesem Fall zeigt die Meldung Fehler die Meldung NoValidHost an, die anzeigt, dass der Scheduler nicht in der Lage war, die Instanzanforderungen zu erfüllen.
Wenn openstack server show den Fehler nicht ausreichend erklärt, ist die Suche nach der Instanz UUID in der nova-compute.log auf dem Compute-Knoten, auf dem sie geplant wurde, oder der nova-scheduler.log auf Ihren Scheduler-Hosts ein guter Ort, um mit der Suche nach Problemen der unteren Ebene zu beginnen.
Wenn Sie openstack server show als Admin-Benutzer verwenden, wird der Compute-Knoten, auf dem die Instanz geplant wurde, als hostId angezeigt. Wenn die Instanz bei der Einplanung fehlgeschlagen ist, ist dieses Feld leer.
Verwendung instanzspezifischer Daten¶
Es gibt zwei Haupttypen von instanzenspezifischen Daten: Metadaten und Benutzerdaten.
Instanz-Metadaten¶
Für Compute sind Instanz-Metadaten eine Sammlung von Schlüssel-Wert-Paaren, die einer Instanz zugeordnet sind. Compute liest und schreibt in diese Schlüssel-Wert-Paare zu jeder Zeit während der Lebensdauer der Instanz, sowohl innerhalb als auch außerhalb der Instanz, wenn der Endbenutzer die Compute-API dazu verwendet. Sie können jedoch die instanzassoziierten Schlüssel-Wert-Paare nicht mit dem Metadatendienst abfragen, der mit dem Amazon EC2 Metadatendienst kompatibel ist.
Als Beispiel für Instanzmetadaten können Benutzer SSH-Schlüssel mit dem Befehl openstack keypair create erzeugen und registrieren:
$ openstack keypair create mykey > mykey.pem
Dadurch wird ein Schlüssel namens mykey erzeugt, den du mit Instanzen verknüpfen kannst. Die Datei mykey.pem ist der private Schlüssel, der an einem sicheren Ort gespeichert werden sollte, da er den Root-Zugriff auf Instanzen ermöglicht, denen der mykey Schlüssel zugeordnet ist.
Verwenden Sie diesen Befehl, um einen vorhandenen Schlüssel bei OpenStack zu registrieren:
$ openstack keypair create --public-key mykey.pub mykey
Bemerkung
Sie müssen den passenden privaten Schlüssel haben, um auf die diesem Schlüssel zugeordneten Instanzen zugreifen zu können.
Um einen Schlüssel einer Instanz beim Booten zuzuordnen, fügen Sie --key-name mykey zu Ihrer Kommandozeile hinzu. Zum Beispiel:
$ openstack server create --image ubuntu-cloudimage --flavor 2 \
--key-name mykey myimage
Beim Booten eines Servers können Sie auch beliebige Metadaten hinzufügen, um sie leichter zwischen anderen laufenden Instanzen identifizieren zu können. Verwenden Sie die Option --property mit einem Schlüssel-Wert-Paar, wo Sie die Zeichenkette sowohl für den Schlüssel als auch für den Wert zusammensetzen können. Sie können z.B. eine Beschreibung und auch den Ersteller des Servers hinzufügen:
$ openstack server create --image=test-image --flavor=1 \
--property description='Small test image' smallimage
Wenn Sie die Serverinformationen anzeigen, sehen Sie die Metadaten, die in der Metadatenzeile enthalten sind:
$ openstack server show smallimage
+--------------------------------------+----------------------------------------------------------+
| Field | Value |
+--------------------------------------+----------------------------------------------------------+
| OS-DCF:diskConfig | MANUAL |
| OS-EXT-AZ:availability_zone | nova |
| OS-EXT-SRV-ATTR:host | rdo-newton.novalocal |
| OS-EXT-SRV-ATTR:hypervisor_hostname | rdo-newton.novalocal |
| OS-EXT-SRV-ATTR:instance_name | instance-00000002 |
| OS-EXT-STS:power_state | Running |
| OS-EXT-STS:task_state | None |
| OS-EXT-STS:vm_state | active |
| OS-SRV-USG:launched_at | 2016-12-07T11:20:08.000000 |
| OS-SRV-USG:terminated_at | None |
| accessIPv4 | |
| accessIPv6 | |
| addresses | public=172.24.4.227 |
| config_drive | |
| created | 2016-12-07T11:17:44Z |
| flavor | m1.tiny (1) |
| hostId | aca973d5b7981faaf8c713a0130713bbc1e64151be65c8dfb53039f7 |
| id | 4f7c6b2c-f27e-4ccd-a606-6bfc9d7c0d91 |
| image | cirros (01bcb649-45d7-4e3d-8a58-1fcc87816907) |
| key_name | None |
| name | smallimage |
| os-extended-volumes:volumes_attached | [] |
| progress | 0 |
| project_id | 2daf82a578e9437cab396c888ff0ca57 |
| properties | description='Small test image' |
| security_groups | [{u'name': u'default'}] |
| status | ACTIVE |
| updated | 2016-12-07T11:20:08Z |
| user_id | 8cbea24666ae49bbb8c1641f9b12d2d2 |
+--------------------------------------+----------------------------------------------------------+
Instanz Benutzerdaten¶
Der Schlüssel user-data ist ein spezieller Schlüssel im Metadatendienst, der eine Datei enthält, auf die cloud-fähige Anwendungen innerhalb der Gastinstanz zugreifen können. Zum Beispiel ist cloudinit ein Open-Source-Paket von Ubuntu, das aber in den meisten Distributionen verfügbar ist, das die frühzeitige Initialisierung einer Cloud-Instanz übernimmt, die diese Benutzerdaten nutzt.
Diese Benutzerdaten können in eine Datei auf Ihrem lokalen System abgelegt und dann bei der Instanzerstellung mit dem Flag --user-data <user-data-file> übergeben werden.
Beispiel
$ openstack server create --image ubuntu-cloudimage --flavor 1 \
--user-data mydata.file mydatainstance
Um den Unterschied zwischen Benutzerdaten und Metadaten zu verstehen, stellen Sie fest, dass Benutzerdaten erstellt werden, bevor eine Instanz gestartet wird. Auf die Benutzerdaten kann innerhalb der Instanz zugegriffen werden, wenn sie ausgeführt werden. Benutzerdaten können verwendet werden, um die Konfiguration, ein Skript oder alles, was der Mandant wünscht, zu speichern.
Datei-Injektion¶
Beliebige lokale Dateien können auch zum Zeitpunkt der Erstellung in das Instanzdateisystem platziert werden, indem Sie die Option --file <dst-path=src-path> verwenden. Sie können bis zu fünf Dateien speichern.
Nehmen wir zum Beispiel an, Sie haben eine spezielle authorized_keys Datei namens special_authorized_keysfile, die Sie aus irgendeinem Grund auf die Instanz setzen möchten, anstatt die normale SSH-Schlüsselinjektion zu verwenden. In diesem Fall können Sie den folgenden Befehl verwenden:
$ openstack server create --image ubuntu-cloudimage --flavor 1 \
--file /root/.ssh/authorized_keys=special_authorized_keysfile \
authkeyinstance
Zuordnen von Sicherheitsgruppen¶
Sicherheitsgruppen, wie bereits erwähnt, sind in der Regel erforderlich, um den Netzwerkverkehr auf eine Instanz zuzulassen, es sei denn, die Standard-Sicherheitsgruppe für ein Projekt wurde geändert, um freizügiger zu sein.
Das Hinzufügen von Sicherheitsgruppen erfolgt üblicherweise beim Booten der Instanz. Wenn Sie aus dem Dashboard starten, tun Sie dies auf der Registerkarte Access & Security des Dialogs Launch Instance.
Es ist auch möglich, Sicherheitsgruppen hinzuzufügen und zu entfernen, wenn eine Instanz ausgeführt wird. Dies ist derzeit nur über die Kommandozeilen-Tools möglich. Hier ist ein Beispiel:
$ openstack server add security group SERVER SECURITY_GROUP_NAME_OR_ID
$ openstack server remove security group SERVER SECURITY_GROUP_NAME_OR_ID
„Floating IPs“¶
Wenn in einer Bereitstellung Floating IPs konfiguriert sind, hat jedes Projekt eine begrenzte Anzahl von Floating IPs, die durch eine Quote gesteuert werden. Diese müssen jedoch vor ihrer Nutzung - in der Regel durch den Projektverwalter - dem Projekt aus dem zentralen Pool zugeordnet werden. Um eine Floating IP einem Projekt zuzuweisen, verwenden Sie die Schaltfläche Allocate IP To Project auf der Registerkarte Floating IPs der Seite Access & Security des Dashboards. Die Befehlszeile kann auch verwendet werden:
$ openstack floating ip create NETWORK_NAME_OR_ID
Einmal zugewiesen, kann eine Floating IP laufenden Instanzen aus dem Dashboard zugewiesen werden, indem Sie entweder Associate aus der Dropdown-Liste Aktionen neben der IP auf der Seite Floating IPs der Seite Access & Security auswählen oder diese Auswahl neben der Instanz treffen, der Sie sie auf der Seite Instances zuordnen möchten. Die umgekehrte Aktion, Dissoziate Floating IP, ist auf der Registerkarte Floating IPs der Seite Access & Security und auf der Seite Instances verfügbar.
Um eine Floating IP einem Server von der Befehlszeile aus zuzuordnen oder zu trennen, verwenden Sie die folgenden Befehle:
$ openstack server add floating ip SERVER IP_ADDRESS
$ openstack server remove floating ip SERVER IP_ADDRESS
Blockspeicher anbringen¶
Sie können Blockspeicher an Instanzen aus dem Dashboard auf der Seite Volumes anhängen. Klicken Sie auf die Aktion Anhänge verwalten neben dem Volume, das Sie anhängen möchten.
Um diese Aktion von der Befehlszeile aus auszuführen, führen Sie den folgenden Befehl aus:
$ openstack server add volume SERVER VOLUME_NAME_OR_ID --device DEVICE
Sie können auch die Gerätezuordnung von Blockdeviceblocks beim Booten der Instanz über den nova-Kommandozeilen-Client mit dieser Option festlegen:
--block-device-mapping <dev-name=mapping>
Das Format für die Blockgerätezuordnung lautet <dev-name>=<id>:<type>:<size(GB)>:<delete-on-terminate>, wo:
- dev-name
Ein Gerätename, bei dem der Datenträger im System unter
/dev/dev/dev_nameangehängt ist- ID
Die ID des Datenträgers, von dem gebootet werden soll, wie in der Ausgabe des Befehls :openstack volume list gezeigt
- Typ
Entweder
snap, was bedeutet, dass der Datenträger aus einer Schattenkopie erstellt wurde, oder etwas anderes alssnap(eine leere Zeichenkette ist gültig). Im vorherigen Beispiel wurde der Datenträger nicht aus einer Schattenkopie erstellt, daher lassen wir dieses Feld in unserem folgenden Beispiel leer.- Größe (GB)
Die Größe des Datenträgers in Gigabyte. Es ist sicher, dieses Feld leer zu lassen und den Compute Service die Größe herleiten zu lassen.
- delete-on-terminate
Ein Boolean, um anzugeben, ob der Datenträger beim Beenden der Instanz gelöscht werden soll. True kann als
Trueoder1angegeben werden. False kann alsFalseoder0angegeben werden.
Der folgende Befehl startet eine neue Instanz und hängt gleichzeitig ein Datenträger an. Der Datenträger der ID 13 wird als /dev/vdc angehängt. Wenn es keine Schattenkopie ist, wird keine Größe angegeben und wird beim Beenden der Instanz nicht gelöscht:
$ openstack server create --image 4042220e-4f5e-4398-9054-39fbd75a5dd7 \
--flavor 2 --key-name mykey --block-device-mapping vdc=13:::0 \
boot-with-vol-test
Wenn Sie zuvor den Blockspeicher mit einem bootfähigen Dateisystem-Abbild vorbereitet haben, ist es sogar möglich, von einem persistenten Blockspeicher zu booten. Der folgende Befehl bootet ein Abbild von dem angegebenen Datenträger. Es ist ähnlich wie der vorherige Befehl, aber das Abbild wird weggelassen und der Datenträger wird nun als /dev/vda angehängt:
$ openstack server create --flavor 2 --key-name mykey \
--block-device-mapping vda=13:::0 boot-from-vol-test
Detaillierte Anweisungen zum Starten einer Instanz von einem bootfähigen Datenträger finden Sie im OpenStack End User Guide.
Um normal von einem Abbild zu booten und Blockspeicher anzuhängen, ordnen Sie das Gerät einem anderen Gerät als vda zu. Anweisungen zum Starten einer Instanz und zum Anhängen eines Datenträgers an die Instanz sowie zum Kopieren des Abbildes auf den angehängten Datenträger finden Sie im OpenStack End User Guide.
Aufnahme von Schattenkopien¶
Der OpenStack-Schattenkopie-Mechanismus ermöglicht es Ihnen, neue Abbilder aus laufenden Instanzen zu erstellen. Dies ist sehr praktisch, um Basisbilder zu aktualisieren oder um ein veröffentlichtes Abbild aufzunehmen und für den lokalen Gebrauch anzupassen. Um eine laufende Instanz mit Hilfe der CLI in ein Abbild einzufügen, gehen Sie wie folgt vor:
$ openstack image create IMAGE_NAME --volume VOLUME_NAME_OR_ID
Die Dashboard-Schnittstelle für Schattenkopien kann verwirrend sein, da die Schattenkopien und Abbilder auf der Seite Images angezeigt werden. Ein Instanz-Schattenkopie ist jedoch ein Abbild. Der einzige Unterschied zwischen einem Abbild, das Sie direkt in den Abbilddienst hochladen, und einem Abbild, das Sie per Schattenkopie erstellen, besteht darin, dass ein mit Schattenkopie erstelltes Abbild zusätzliche Eigenschaften in der glance-Datenbank hat. Diese Eigenschaften finden Sie in der Tabelle Abbild_Eigenschaften` und beinhalten:
Name |
Wert |
|---|---|
|
Momentaufnahme |
|
<uuuid der Instanz, die als Schattenkopie aufgenommen wurde> |
|
<uuuid des Originalabbildes der Instanz, die als Schattenkopie aufgenommen wurde>> |
|
Momentaufnahme |
Live-Schattenkopien¶
Live-Schattenkopie ist eine Funktion, die es Benutzern ermöglicht, die laufenden virtuellen Maschinen zu Schattenkopie zu machen, ohne sie anzuhalten. Diese Schattenkopien sind einfach nur Festplatten-Schattenkopie. Das Schattenkopieren einer Instanz kann nun ohne Ausfallzeiten durchgeführt werden (vorausgesetzt, QEMU 1.3+ und libvirt 1.0+ werden verwendet).
Bemerkung
Wenn Sie die libvirt-Version 1.2.2.2 verwenden, kann es zu intermittierenden Problemen bei der Erstellung von Live-Schattenkopie kommen.
Um die Live-Schattenkopie von libvirt effektiv zu deaktivieren, bis das Problem behoben ist, fügen Sie die folgende Einstellung zu nova.conf hinzu.
[workarounds]
disable_libvirt_livesnapshot = True
Sicherstellen, dass Schattenkopien von Linux-Gästen konsistent sind
Der folgende Abschnitt ist aus Sébastien Hans OpenStack: Durchführen eines konsistenten Snapshots-Blog-Eintrags.
Eine Schattenkopie erfasst den Zustand des Dateisystems, nicht aber den Zustand des Speichers. Um sicherzustellen, dass Ihre Schattenkopie die gewünschten Daten enthält, müssen Sie dies vor Ihrer Schattenkopie sicherstellen:
Laufende Programme haben ihren Inhalt auf die Festplatte geschrieben
Das Dateisystem hat keine „schmutzigen“ Puffer: wo Programme den Befehl zum Schreiben auf die Festplatte gegeben haben, das Betriebssystem aber noch nicht das Schreiben durchgeführt hat
Um sicherzustellen, dass wichtige Dienste ihren Inhalt auf die Festplatte geschrieben haben (z.B. Datenbanken), empfehlen wir Ihnen, die Dokumentation dieser Anwendungen zu lesen, um festzustellen, welche Befehle ausgegeben werden müssen, damit sie ihren Inhalt auf die Festplatte synchronisieren können. Wenn Sie sich nicht sicher sind, wie Sie dies tun sollen, ist der sicherste Ansatz, diese laufenden Dienste einfach zu stoppen.
Um das Problem des „dirty“ Puffers zu lösen, empfehlen wir, vor der Schattenkopie den Sync-Befehl zu verwenden:
# sync
Das Ausführen von sync schreibt schmutzige Puffer (gepufferte Blöcke, die geändert, aber noch nicht auf den Festplattenblock geschrieben wurden) auf die Festplatte.
Es reicht nicht aus, nur sync auszuführen, um sicherzustellen, dass das Dateisystem konsistent ist. Wir empfehlen, das Tool fsfreeze zu verwenden, das den neuen Zugriff auf das Dateisystem unterbindet, und ein stabiles Abbild auf der Festplatte zu erstellen, das für Schattenkopie geeignet ist. Das fsfsfreeze Werkzeug unterstützt mehrere Dateisysteme, einschließlich ext3, ext4 und XFS. Wenn Ihre Instanz der virtuellen Maschine unter Ubuntu ausgeführt wird, installieren Sie das util-linux-Paket, um fsfsfreeze zu erhalten:
Bemerkung
In dem sehr häufigen Fall, dass der zugrundeliegende Schattenkopie über LVM gemacht wird, wird das Einfrieren des Dateisystems automatisch von LVM behandelt.
# apt-get install util-linux
Wenn Ihr Betriebssystem keine Version von fsfreeze` zur Verfügung hat, können Sie stattdessen xfs_freeze verwenden, die unter Ubuntu im Paket xfsprogs verfügbar ist. Trotz der „xfs“ im Namen funktioniert xfs_freeze auch auf ext3 und ext4, wenn Sie einen Linux-Kernel der Version 2.6.29 oder höher verwenden, da es auf der Ebene des virtuellen Dateisystems (VFS) ab 2.6.29 funktioniert. Die xfs_freeze-Version unterstützt die gleichen Befehlszeilenargumente wie fsfsfreeze.
Betrachten Sie das Beispiel, wo Sie eine Schattenkopie eines persistenten Blockspeicherdatenträgers machen möchten, das vom Gastbetriebssystem als /dev/vdb erkannt und auf /mnt gemountet wird. Der Befehl fsfreeze akzeptiert zwei Argumente:
- -f
Einfrieren des Systems
- -u
Auftauen (Auftauen) des Systems
Um den Datenträger in Vorbereitung auf die Schattenkopie einzufrieren, würden Sie folgendes als root innerhalb der Instanz tun:
# fsfreeze -f /mnt
Sie müssen das Dateisystem mounten, bevor Sie den Befehl fsfsfreeze ausführen.
Wenn der Befehl fsfsfreeze -f ausgegeben wird, dürfen alle laufenden Transaktionen im Dateisystem abgeschlossen werden, neue Schreibsystemaufrufe werden gestoppt und andere Aufrufe, die das Dateisystem verändern, gestoppt. Am wichtigsten ist, dass alle schmutzigen Daten, Metadaten und Protokollinformationen auf die Festplatte geschrieben werden.
Sobald der Datenträger eingefroren ist, versuchen Sie nicht mehr, von dem Datenträger zu lesen oder in es zu schreiben, da diese Vorgänge hängen bleiben. Das Betriebssystem stoppt jeden I/O-Vorgang und alle I/O-Versuche werden verzögert, bis das Dateisystem aufgetaut wurde.
Sobald Sie den Befehl fsfsfreeze erteilt haben, ist es sicher, die Schattenkopie auszuführen. Wenn zum Beispiel den Datenträger Ihrer Instanz den Namen mon-volume hatte und Sie es zu einem Abbild mit dem Namen mon-snapshot schnappen wollten, konnten Sie nun folgendes ausführen:
$ openstack image create mon-snapshot --volume mon-volume
Wenn die Schattenkopie fertig ist, können Sie das Dateisystem mit dem folgenden Befehl als root innerhalb der Instanz auftauen:
# fsfreeze -u /mnt
Wenn Sie das Root-Dateisystem sichern möchten, können Sie den vorhergehenden Befehl nicht einfach ausführen, da er die Eingabeaufforderung einfriert. Führen Sie stattdessen den folgenden Einzeiler, als root, innerhalb der Instanz aus:
# fsfreeze -f / && read x; fsfreeze -u /
Nach diesem Befehl ist es üblich, den Befehl openstack image create von Ihrem Arbeitsplatz aus aufzurufen, und nach Abschluss des Befehls die Eingabetaste in Ihrer Instanz zu drücken, um ihn wieder einzufrieren. Natürlich könnten Sie dies automatisieren, aber zumindest wird es Ihnen ermöglichen, richtig zu synchronisieren.
Sicherstellen, dass Schattenkopien von Windows-Gästen konsistent sind
Das Erhalten konsistenter Schattenkopien von Windows-VMs ist konzeptionell ähnlich wie das Erhalten konsistenter Schattenkopien von Linux-VMs, obwohl es zusätzliche Dienstprogramme erfordert, um mit einem reinen Windows-Subsystem zu koordinieren, das für konsistente Backups ausgelegt ist.
Windows XP und spätere Versionen enthalten einen Volume Shadow Copy Service (VSS), der ein Framework bietet, mit dem konforme Anwendungen konsistent auf einem Live-Dateisystem gesichert werden können. Um dieses Framework zu nutzen, wird ein VSS-Requester ausgeführt, der dem VSS-Dienst signalisiert, dass ein konsistentes Backup benötigt wird. Der VSS-Dienst benachrichtigt konforme Anwendungen (sogenannte VSS-Schreiber), um ihre Datenaktivität zu unterbinden. Der VSS-Dienst weist den Kopierdienstleister dann an, eine Schattenkopie zu erstellen. Sobald die Schattenkopie erstellt wurde, deaktiviert der VSS-Dienst die VSS-Schreiber und setzt die normale I/O-Aktivität fort.
QEMU stellt einen Gastagenten zur Verfügung, der bei Gästen ausgeführt werden kann, die auf KVM-Hypervisoren laufen. Dieser Gastagent koordiniert auf Windows-VMs mit dem Windows VSS-Dienst, um einen Workflow zu ermöglichen, der konsistente Snapshots gewährleistet. Diese Funktion erfordert mindestens QEMU 1.7. Die relevanten Befehle des Gastagenten sind:
- guest-file-flush
Schreiben Sie „schmutzige“ Puffer auf die Festplatte, ähnlich wie bei der Linux-Operation
sync.- guest-fsfreeze
Suspendieren Sie die I/Os auf den Festplatten, ähnlich wie beim Linux-Betrieb
fsfsfreeze -f.- gast-fsfsfreeze-thaw
Setzen Sie die I/O auf den Festplatten fort, ähnlich wie bei der Operation Linux
fsfsfreeze -u.
Um Schattenkopien von einer Windows-VM zu erhalten, können diese Befehle nacheinander geskriptet werden: die Dateisysteme leeren, die Dateisysteme einfrieren, die Dateisysteme schnappen und dann die Dateisysteme freigeben. Wie beim Skripten ähnlicher Workflows mit Linux-VMs muss beim Schreiben eines solchen Skripts Vorsicht walten, um sicherzustellen, dass die Fehlerbehandlung gründlich ist und Dateisysteme nicht im eingefrorenen Zustand verbleiben.
Instanzen in der Datenbank¶
Während Instanzinformationen in einer Reihe von Datenbanktabellen gespeichert sind, ist die Tabelle, die Sie am ehesten in Bezug auf Benutzerinstanzen betrachten müssen, die Instanztabelle.
Die Instanztabelle enthält die meisten Informationen über laufende und gelöschte Instanzen. Es hat eine verwirrende Anzahl von Feldern; eine vollständige Liste finden Sie in der Datenbank. Dies sind die nützlichsten Felder für Operatoren, die nach Formularabfragen suchen:
Das Feld
gelöschtwird auf1gesetzt, wenn die Instanz gelöscht wurde undNULL, wenn sie nicht gelöscht wurde. Dieses Feld ist wichtig, um gelöschte Instanzen von Ihren Abfragen auszuschließen.Das Feld
uuuidist die UUID der Instanz und wird in allen anderen Tabellen der Datenbank als Fremdschlüssel verwendet. Diese ID wird auch in Protokollen, dem Dashboard und Befehlszeilenwerkzeugen zur eindeutigen Identifizierung einer Instanz angegeben.Es steht eine Sammlung von Fremdschlüsseln zur Verfügung, um Beziehungen zur Instanz zu finden. Die nützlichsten von diesen -
user_idundproject_idsind die UUIDs des Benutzers, der die Instanz gestartet hat und des Projekts, in dem sie gestartet wurde.Das Feld
host`sagt aus, welcher Compute-Knoten die Instanz hostet.Das Feld
hostnameenthält den Namen der Instanz, wenn sie gestartet wird. Der Anzeigename ist zunächst identisch mit dem Hostnamen, kann aber mit dem Befehl nova rename zurückgesetzt werden.
Eine Reihe von zeitbezogenen Feldern sind nützlich, um zu verfolgen, wann Zustandsänderungen an einer Instanz stattgefunden haben:
created_atupdated_atdeleted_atscheduled_atlaunched_atterminated_at
Viel Glück!¶
Dieser Abschnitt sollte eine kurze Einführung in einige der nützlichsten der vielen OpenStack-Befehle sein. Eine vollständige Liste finden Sie im OpenStack Administrator Guide. Wir hoffen, dass Ihre Nutzer zufrieden bleiben und Ihre harte Arbeit! anerkennen (Für mehr harte Arbeit blättern Sie die Seite zum nächsten Kapitel, wo wir die systembezogenen Operationen besprechen: Wartung, Ausfälle und Debugging.)
