Benutzerorientierte Operationen

[ English | Deutsch | 日本語 | Indonesia ]

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:

  1. Abbild zum Hochladen abrufen

    $ wget http://download.cirros-cloud.net/0.3.5/cirros-0.3.5-x86_64-disk.img
    
  2. 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.

  3. 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)
    
  4. 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)
    
  5. 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'
    
  6. 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.

  7. Ü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/v3 als Endpunkt-URL, die in den Dateien glance-api.conf und nova-api.conf angegeben ist:

    [barbican]
    auth_endpoint = http://localhost:5000/v3
    

    Bemerkung

    Wenn sich Keystone stattdessen entfernt befindet, bearbeiten Sie die Dateien glance-api.conf und nova.conf. Konfigurieren Sie im Abschnitt [barbican] die Option auth_endpoint:

    [barbican]
    auth_endpoint = https://192.168.245.9:5000/v3
    
  8. 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-barbicanclient Python-Paket installiert ist

    • Richten 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.

Freigeben von Abbildern zwischen Projekten

In einer mandantenfähigen Cloud-Umgebung möchten Benutzer manchmal ihre persönlichen Abbilder oder Schattenkopien mit anderen Projekten teilen. Dies kann auf der Kommandozeile mit dem Tool glance vom Besitzer des Abbildes erfolgen.

Um ein Abbild oder eine Schattenkopie mit einem anderen Projekt zu teilen, gehen Sie wie folgt vor:

  1. Erhalten Sie die UUID des Abbildes:

    $ openstack image list
    
  2. Erhalten Sie die UUID des Projekts, für das Sie Ihr Abbild freigeben möchten, nennen wir es Zielprojekt. Leider können Nichtadministratoren den Befehl openstack nicht verwenden, um dies zu tun. Die einfachste Lösung besteht darin, die UUID entweder von einem Administrator der Cloud oder von einem Benutzer im Zielprojekt zu erhalten.

  3. Sobald Sie beide Informationen haben, führen Sie den Befehl openstack image add project aus:

    $ openstack image add project IMAGE_NAME_OR_UUID PROJECT_NAME_OR_UUID
    

    Zum Beispiel:

    $ openstack image add project 733d1c44-a2ea-414b-aca7-69decf20d810 \
      771ed149ef7e4b2b88665cc1c98f77ca
    
  4. Sie müssen nun im Ziel-Projektumfang handeln.

    Bemerkung

    Sie werden das freigegebene Abbild noch nicht sehen. Deshalb muss das Teilen akzeptiert werden.

    Um die Freigabe zu akzeptieren, müssen Sie den Mitgliederstatus aktualisieren:

    $ glance member-update IMAGE_UUID PROJECT_UUID accepted
    

    Zum Beispiel:

    $ glance member-update 733d1c44-a2ea-414b-aca7-69decf20d810 \
      771ed149ef7e4b2b88665cc1c98f77ca accepted
    

    Das Projekt 771ed149ef7e4b2b88665cc1c98f77ca wird nun Zugang zum Abbild 733d1c44-a2ea-414b-aca7-69decf20d810 haben.

    Tipp

    Sie können ausdrücklich um den Status eines ausstehenden Mitglieds bitten, um freigegebene Abbilder anzuzeigen, die noch nicht akzeptiert wurden:

    $ glance image-list --member-status pending
    

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.

Tabelle. Variantenparameter

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 True.

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 ingress oder egress.

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` und icmpv6.

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_max sein. 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_min beschränkt das Attribut port_range_max. Wenn das Protokoll ICMP oder ICMPv6 ist, muss dieser Wert ein ICMP- bzw. ICMPv6-Typ sein.

ethertype

Muss IPv4 oder IPv6` 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

Shared File Systems service (manila)

Ähnlich wie die Blockspeicherung ist das Shared File System ein persistenter Speicher, genannt Share, der in mandantenfähigen Umgebungen verwendet werden kann. Benutzer erstellen und mounten eine Freigabe als entferntes Dateisystem auf jedem Computer, der das Mounten von Freigaben erlaubt und Netzwerkzugriff auf den Share-Exporter hat. Diese Freigabe kann dann zum Speichern, Teilen und Austauschen von Dateien verwendet werden. Die Standardkonfiguration des Dienstes Shared File Systems hängt vom Backend-Treiber ab, den der Administrator beim Start des Dienstes Shared File Systems wählt. Weitere Informationen über bestehende Backend-Treiber finden Sie unter Share Backends im Entwicklerhandbuch für den Dienst Shared File Systems. Wenn beispielsweise OpenStack Block Storage-basiertes Backend verwendet wird, kümmert sich der Dienst Shared File Systems um alles, einschließlich VMs, Netzwerke, Schlüsselpaare und Sicherheitsgruppen. Andere Konfigurationen erfordern detailliertere Kenntnisse der Freigabefunktionalität, um spezifische Parameter und Funktionsweisen der Freigaben einzurichten und anzupassen.

Freigaben sind ein fernbetreibbares Dateisystem, so dass Benutzer eine Freigabe auf mehreren Hosts einbinden und von mehreren Hosts aus von mehreren Benutzern gleichzeitig darauf zugreifen können. Mit dem Dienst Shared File Systems können Sie eine große Anzahl von Operationen mit Freigaben durchführen:

  • Erstellen, Aktualisieren, Löschen und Erzwingen von Freigaben

  • Zugriffsregeln für Freigaben ändern, Freigabestatus zurücksetzen

  • Geben Sie Quoten für bestehende Benutzer oder Mandanten an

  • Erstellen von Freigabenetzwerken

  • Neue Freigabearten definieren

  • Führen Sie Operationen mit Share Snapshots durch: Erstellen, Ändern des Namens, Erstellen einer Freigabe aus einer Schattenkopie, Löschen

  • Arbeiten mit Konsistenzgruppen

  • Sicherheitsdienste nutzen

Weitere Informationen zur Share-Verwaltung finden Sie unter Share-Verwaltung im OpenStack Manila Administrator Guide. Was die Sicherheitsdienste betrifft, sollten Sie daran denken, dass verschiedene Treiber unterschiedliche Authentifizierungsmethoden unterstützen, während der generische Treiber die Sicherheitsdienste überhaupt nicht unterstützt (siehe Abschnitt Sicherheitsdienste im OpenStack Manila Administrator Guide).

Sie können eine Freigabe in einem Netzwerk erstellen, Freigaben auflisten und Informationen für eine bestimmte Freigabe anzeigen, aktualisieren und löschen. Sie können auch Schnappschüsse von Freigaben erstellen (siehe Share Schnappschüsse im OpenStack Manila Administrator Guide).

Es gibt standardmäßige und spezifische Freigabearten, mit denen Sie Backends filtern oder auswählen können, bevor Sie eine Freigabe erstellen. Die Funktionen und das Verhalten des Share-Typs ähneln dem Blockspeicher Datenträgertyp (siehe Share types im OpenStack Manila Administrator Guide).

Um Benutzern die Aufbewahrung und Wiederherstellung ihrer Daten zu erleichtern, bietet der Dienst Shared File Systems einen Mechanismus zum Erstellen und Betreiben von Schattenkopien (siehe Share Snapshots im OpenStack Manila Administrator Guide).

Ein Sicherheitsdienst speichert Konfigurationsinformationen für Clients zur Authentifizierung und Autorisierung. Innerhalb von Manila kann ein Freigabe-Netzwerk mit bis zu drei Sicherheitsarten verknüpft werden (für detaillierte Informationen siehe Sicherheitsdienste im OpenStack Manila Administrator Guide).

  • LDAP

  • Kerberos

  • Microsoft Active Directory

Der Dienst Shared File Systems unterscheidet sich von den im Blockspeicher implementierten Prinzipien. Der Dienst Shared File Systems kann in zwei Modi arbeiten:

  • Ohne Interaktion mit Freigabenetzwerken, im sogenannten „no share servers“-Modus.

  • Interaktion mit Freigabe-Netzwerken.

Der Netzwerkdienst wird vom Dienst Shared File Systems verwendet, um direkt mit Share-Servern zu arbeiten. Um die Interaktion mit dem Networking-Dienst einzuschalten, erstellen Sie eine Freigabe, die ein Freigabenetzwerk angibt. Um den Modus „Share Server“ auch außerhalb von OpenStack nutzen zu können, wird ein Netzwerk-Plugin namens StandaloneNetworkPlugin verwendet. Geben Sie in diesem Fall in der Konfiguration Netzwerkinformationen an: IP-Bereich, Netzwerktyp und Segmentierungs-ID. Sie können auch Sicherheitsdienste zu einem Freigabennetzwerk hinzufügen (siehe Abschnitt „Networking“ im OpenStack Manila Administrator Guide).

Die Grundidee von Konsistenzgruppen besteht darin, dass Sie Schattenkopien zum gleichen Zeitpunkt aus mehreren Dateisystemfreigaben erstellen können. Diese Schattenkopien können dann zur Wiederherstellung aller Freigaben verwendet werden, die der Konsistenzgruppe zugeordnet waren.

Der Shared File System Storage ermöglicht es Administratoren, Limits und Quoten für bestimmte Mandanten und Benutzer festzulegen. Limits sind die Ressourcenbeschränkungen, die für jeden Mandanten oder Benutzer erlaubt sind. Limits bestehen aus:

  • Ratenbegrenzungen

  • Absolute Grenzwerte

Ratenbegrenzungen steuern die Häufigkeit, mit der Benutzer spezifische API-Anfragen stellen können. Die Ratenbegrenzungen werden von den Administratoren in einer Konfigurationsdatei konfiguriert. Außerdem kann der Administrator Quoten angeben, die auch als Maximalwerte für absolute Limits pro Mandant bekannt sind. Während Benutzer nur die Menge ihrer verbrauchten Ressourcen sehen können. Der Administrator kann für die folgenden Ressourcen Ratenbegrenzungen oder Quoten festlegen:

  • Maximale verfügbare Fläche für alle Freigaben

  • Maximale Anzahl der Freigaben

  • Maximale Anzahl der gemeinsamen Netzwerke

  • Maximale Anzahl von Freigabe-Schattenkopien

  • Maximale Gesamtzahl aller Schattenkopien

  • Art und Anzahl der API-Aufrufe, die in einem bestimmten Zeitintervall erfolgen können

Der Benutzer kann seine Ratenbegrenzungen und absoluten Begrenzungen sehen, indem er die Befehle manila rate-limits und manila absolute-limits ausführt. Weitere Details zu Limits und Quoten finden Sie unter Quoten und Limits im Abschnitt „Share Management“ des OpenStack Administrator Guide Dokuments.

In diesem Abschnitt sind einige der wichtigsten Anwendungsfälle aufgeführt, die die wichtigsten Funktionen und Fähigkeiten des Dienstes Shared File Systems demonstrieren:

  • Freigabe erstellen

  • Arbeiten mit einer Freigabe

  • Zugriff auf Freigaben verwalten

  • Schattenkopien erstellen

  • Erstellen eines Freigabe-Netzwerks

  • Verwalten eines Freigabenetzwerkes

Bemerkung

Der Dienst Shared File Systems kann Sie nicht vorher warnen, wenn es sicher ist, eine bestimmte große Datenmenge auf eine bestimmte Freigabe zu schreiben oder eine Konsistenzgruppe zu entfernen, wenn ihr eine bestimmte Anzahl von Freigaben zugewiesen ist. In einer solchen potenziell fehlerhaften Situation können Sie im Falle eines Fehlers mit einer Fehlermeldung oder gar dem Versagen von Freigaben oder Konsistenzgruppen in einen falschen Status rechnen. Sie können auch mit einer gewissen Systembeschädigung rechnen, wenn ein Benutzer versucht, eine nicht verwaltete Freigabe zu entfernen, während ein Prozess sie für die Datenübertragung verwendet.

Freigabe anlegen

In diesem Abschnitt untersuchen wir den Prozess der Erstellung einer einfachen Freigabe. Sie besteht aus mehreren Schritten:

  • Überprüfen Sie, ob im Dienst Shared File Systems ein geeigneter Share Type definiert ist

  • Wenn ein solcher Share-Typ nicht existiert, sollte ein Admin ihn mit dem Befehl manila type-create erstellen, bevor andere Benutzer ihn verwenden können

  • Die Verwendung eines Freigabe-Netzwerks ist optional. Wenn Sie jedoch ein solches benötigen, überprüfen Sie, ob im Dienst Shared File Systems ein geeignetes Netzwerk definiert ist, indem Sie den Befehl manila share-network-list verwenden. Informationen zum Erstellen eines Freigabenetzwerks finden Sie weiter unten in diesem Kapitel unter Erstellen eines Freigabe-Netzwerks.

  • Erstellen Sie eine öffentliche Freigabe mit manila create.

  • Stellen Sie sicher, dass die Freigabe erfolgreich erstellt wurde und einsatzbereit ist (überprüfen Sie den Freigabestatus und sehen Sie sich den Exportort der Freigabe an).

Im Folgenden wird das gleiche ganze Verfahren Schritt für Schritt und im Detail beschrieben.

Bemerkung

Bevor Sie beginnen, stellen Sie sicher, dass der Dienst Shared File Systems auf Ihrem OpenStack-Cluster installiert und einsatzbereit ist.

Standardmäßig sind im Dienst Shared File Systems keine Freigabearten definiert, so dass Sie überprüfen können, ob ein erforderlicher bereits erstellt wurde:

$ manila type-list
+------+--------+-----------+-----------+----------------------------------+----------------------+
| ID   | Name   | Visibility| is_default| required_extra_specs             | optional_extra_specs |
+------+--------+-----------+-----------+----------------------------------+----------------------+
| c0...| default| public    | YES       | driver_handles_share_servers:True| snapshot_support:True|
+------+--------+-----------+-----------+----------------------------------+----------------------+

Wenn die Liste der Freigabetypen leer ist oder keinen benötigten Typ enthält, erstellen Sie mit diesem Befehl den gewünschten Freigabetyp:

$ manila type-create netapp1 False --is_public True

Dieser Befehl erstellt eine öffentliche Freigabe mit den folgenden Parametern: name = netapp1, spec_driver_handles_share_servers = False

Sie können nun eine öffentliche Freigabe mit my_share_net-Netzwerk, Standard-Freigabetyp, NFS-Protokoll für gemeinsame Dateisysteme und 1 GB Größe erstellen:

$ manila create nfs 1 --name "Share1" --description "My first share" \
  --share-type default --share-network my_share_net --metadata aim=testing --public
+-----------------------------+--------------------------------------+
| Property                    | Value                                |
+-----------------------------+--------------------------------------+
| status                      | creating                             |
| share_type_name             | default                              |
| description                 | My first share                       |
| availability_zone           | None                                 |
| share_network_id            | 9c187d23-7e1d-4d91-92d0-77ea4b9b9496 |
| share_server_id             | None                                 |
| host                        |                                      |
| access_rules_status         | active                               |
| snapshot_id                 | None                                 |
| is_public                   | True                                 |
| task_state                  | None                                 |
| snapshot_support            | True                                 |
| id                          | edd82179-587e-4a87-9601-f34b2ca47e5b |
| size                        | 1                                    |
| name                        | Share1                               |
| share_type                  | e031d5e9-f113-491a-843f-607128a5c649 |
| has_replicas                | False                                |
| replication_type            | None                                 |
| created_at                  | 2016-03-20T00:00:00.000000           |
| share_proto                 | NFS                                  |
| consistency_group_id        | None                                 |
| source_cgsnapshot_member_id | None                                 |
| project_id                  | e81908b1bfe8468abb4791eae0ef6dd9     |
| metadata                    | {u'aim': u'testing'}                 |
+-----------------------------+--------------------------------------+

Um zu bestätigen, dass die Erstellung erfolgreich war, siehe die Freigabe in der Freigabeliste:

$ manila list
+----+-------+-----+------------+-----------+-------------------------------+----------------------+
| ID | Name  | Size| Share Proto| Share Type| Export location               | Host                 |
+----+-------+-----+------------+-----------+-------------------------------+----------------------+
| a..| Share1| 1   | NFS        | c0086...  | 10.254.0.3:/shares/share-2d5..| manila@generic1#GEN..|
+----+-------+-----+------------+-----------+-------------------------------+----------------------+

Überprüfen Sie den Freigabestatus und sehen Sie den Exportort der Freigabe. Nach der Erstellung sollte der Freigabestatus ``verfügbar``werden:

$ manila show Share1
+-----------------------------+----------------------------------------------------------------------+
| Property                    | Value                                                                |
+-----------------------------+----------------------------------------------------------------------+
| status                      | available                                                            |
| share_type_name             | default                                                              |
| description                 | My first share                                                       |
| availability_zone           | nova                                                                 |
| share_network_id            | 9c187d23-7e1d-4d91-92d0-77ea4b9b9496                                 |
| export_locations            |                                                                      |
|                             | path = 10.254.0.3:/shares/share-18cb05be-eb69-4cb2-810f-91c75ef30f90 |
|                             | preferred = False                                                    |
|                             | is_admin_only = False                                                |
|                             | id = d6a82c0d-36b0-438b-bf34-63f3932ddf4e                            |
|                             | share_instance_id = 18cb05be-eb69-4cb2-810f-91c75ef30f90             |
|                             | path = 10.0.0.3:/shares/share-18cb05be-eb69-4cb2-810f-91c75ef30f90   |
|                             | preferred = False                                                    |
|                             | is_admin_only = True                                                 |
|                             | id = 51672666-06b8-4741-99ea-64f2286f52e2                            |
|                             | share_instance_id = 18cb05be-eb69-4cb2-810f-91c75ef30f90             |
| share_server_id             | ea8b3a93-ab41-475e-9df1-0f7d49b8fa54                                 |
| host                        | manila@generic1#GENERIC1                                             |
| access_rules_status         | active                                                               |
| snapshot_id                 | None                                                                 |
| is_public                   | True                                                                 |
| task_state                  | None                                                                 |
| snapshot_support            | True                                                                 |
| id                          | e7364bcc-3821-49bf-82d6-0c9f0276d4ce                                 |
| size                        | 1                                                                    |
| name                        | Share1                                                               |
| share_type                  | e031d5e9-f113-491a-843f-607128a5c649                                 |
| has_replicas                | False                                                                |
| replication_type            | None                                                                 |
| created_at                  | 2016-03-20T00:00:00.000000                                           |
| share_proto                 | NFS                                                                  |
| consistency_group_id        | None                                                                 |
| source_cgsnapshot_member_id | None                                                                 |
| project_id                  | e81908b1bfe8468abb4791eae0ef6dd9                                     |
| metadata                    | {u'aim': u'testing'}                                                 |
+-----------------------------+----------------------------------------------------------------------+

Der Wert is_public definiert die Sichtbarkeit der Freigabe: ob andere Mandanten die Freigabe sehen können oder nicht. Standardmäßig ist die Freigabe privat. Jetzt können Sie die erstellte Freigabe wie ein entferntes Dateisystem einbinden und für Ihre Zwecke verwenden.

Bemerkung

Siehe Share Management im Abschnitt „Shared File Systems“ im OpenStack Administrator Guide Dokument für Details zu den Vorgängen der Share Management.

Zugriff auf Freigaben verwalten

Derzeit haben Sie eine Freigabe und möchten den Zugriff auf diese Freigabe für andere Benutzer steuern. Dazu müssen Sie eine Reihe von Schritten und Operationen durchführen. Bevor Sie den Zugriff auf die Freigabe verwalten, beachten Sie die folgenden wichtigen Parameter. Um den Zugriff auf eine Freigabe zu gewähren oder zu verweigern, geben Sie eine dieser unterstützten Zugriffsebenen an:

  • rw: Lese- und Schreibzugriff (RW). Dies ist der Standardwert.

  • ``ro:``Lesezugriff (RO).

Zusätzlich sollten Sie auch eine dieser unterstützten Authentifizierungsmethoden angeben:

  • ip: authentifiziert eine Instanz über ihre IP-Adresse. Ein gültiges Format ist XX.XX.XX.XX oder XX.XX.XX.XX./XX. Zum Beispiel 0.0.0.0.0/0.

  • cert: authentifiziert eine Instanz durch ein TLS-Zertifikat. Geben Sie die TLS-Identität als IDENTKEY an. Ein gültiger Wert ist jede Zeichenkette mit einer Länge von bis zu 64 Zeichen im Common Name (CN) des Zertifikats. Die Bedeutung einer Zeichenkette hängt von ihrer Interpretation ab.

  • user: Authentifizierung durch einen bestimmten Benutzer- oder Gruppennamen. Ein gültiger Wert ist eine alphanumerische Zeichenkette, die einige Sonderzeichen enthalten kann und 4 bis 32 Zeichen lang ist.

Bemerkung

Mounten Sie keine Freigabe ohne Zugriffsregel! Dies kann zu einer Ausnahme führen.

Zugriff auf die Freigabe mit IP-Zugriffstyp und 10.254.0.4 IP-Adresse erlauben:

$ manila access-allow Share1 ip 10.254.0.4 --access-level rw
+--------------+--------------------------------------+
| Property     | Value                                |
+--------------+--------------------------------------+
| share_id     | 7bcd888b-681b-4836-ac9c-c3add4e62537 |
| access_type  | ip                                   |
| access_to    | 10.254.0.4                           |
| access_level | rw                                   |
| state        | new                                  |
| id           | de715226-da00-4cfc-b1ab-c11f3393745e |
+--------------+--------------------------------------+

Mounten Sie die Freigabe:

$ sudo mount -v -t nfs 10.254.0.5:/shares/share-5789ddcf-35c9-4b64-a28a-7f6a4a574b6a /mnt/

Überprüfen Sie dann, ob die Freigabe erfolgreich und gemäß den angegebenen Zugriffsregeln eingebunden wurde:

$ manila access-list Share1
+--------------------------------------+-------------+------------+--------------+--------+
| id                                   | access type | access to  | access level | state  |
+--------------------------------------+-------------+------------+--------------+--------+
| 4f391c6b-fb4f-47f5-8b4b-88c5ec9d568a | user        | demo       | rw           | error  |
| de715226-da00-4cfc-b1ab-c11f3393745e | ip          | 10.254.0.4 | rw           | active |
+--------------------------------------+-------------+------------+--------------+--------+

Bemerkung

Verschiedene Freigabefunktionen werden von verschiedenen Freigabetreibern unterstützt. In diesen Beispielen wurde ein generischer (Cinder als Backend) Treiber verwendet, der die Authentifizierungsmethoden user und cert nicht unterstützt.

Tipp

Für die Details der Funktionen, die von verschiedenen Treibern unterstützt werden, siehe Manila share features support mapping im Manila Developer Guide Dokument.

Share-Links verwalten

Es gibt noch einige andere nützliche Operationen, die Sie bei der Arbeit mit Freigaben durchführen würden.

Aktualisieren der Freigabe

Verwenden Sie diesen Befehl, um den Namen einer Freigabe zu ändern, ihre Beschreibung zu aktualisieren oder die Sichtbarkeit für andere Mandanten zu erhöhen:

$ manila update Share1 --description "My first share. Updated" --is-public False

Überprüfen Sie die Attribute des aktualisierten Share1:

$ manila show Share1
+-----------------------------+----------------------------------------------------------------------+
| Property                    | Value                                                                |
+-----------------------------+----------------------------------------------------------------------+
| status                      | available                                                            |
| share_type_name             | default                                                              |
| description                 | My first share. Updated                                              |
| availability_zone           | nova                                                                 |
| share_network_id            | 9c187d23-7e1d-4d91-92d0-77ea4b9b9496                                 |
| export_locations            |                                                                      |
|                             | path = 10.254.0.3:/shares/share-18cb05be-eb69-4cb2-810f-91c75ef30f90 |
|                             | preferred = False                                                    |
|                             | is_admin_only = False                                                |
|                             | id = d6a82c0d-36b0-438b-bf34-63f3932ddf4e                            |
|                             | share_instance_id = 18cb05be-eb69-4cb2-810f-91c75ef30f90             |
|                             | path = 10.0.0.3:/shares/share-18cb05be-eb69-4cb2-810f-91c75ef30f90   |
|                             | preferred = False                                                    |
|                             | is_admin_only = True                                                 |
|                             | id = 51672666-06b8-4741-99ea-64f2286f52e2                            |
|                             | share_instance_id = 18cb05be-eb69-4cb2-810f-91c75ef30f90             |
| share_server_id             | ea8b3a93-ab41-475e-9df1-0f7d49b8fa54                                 |
| host                        | manila@generic1#GENERIC1                                             |
| access_rules_status         | active                                                               |
| snapshot_id                 | None                                                                 |
| is_public                   | False                                                                |
| task_state                  | None                                                                 |
| snapshot_support            | True                                                                 |
| id                          | e7364bcc-3821-49bf-82d6-0c9f0276d4ce                                 |
| size                        | 1                                                                    |
| name                        | Share1                                                               |
| share_type                  | e031d5e9-f113-491a-843f-607128a5c649                                 |
| has_replicas                | False                                                                |
| replication_type            | None                                                                 |
| created_at                  | 2016-03-20T00:00:00.000000                                           |
| share_proto                 | NFS                                                                  |
| consistency_group_id        | None                                                                 |
| source_cgsnapshot_member_id | None                                                                 |
| project_id                  | e81908b1bfe8468abb4791eae0ef6dd9                                     |
| metadata                    | {u'aim': u'testing'}                                                 |
+-----------------------------+----------------------------------------------------------------------+

Freigabestatus zurücksetzen

Manchmal kann eine Freigabe erscheinen und dann in einem fehlerhaften oder Übergangszustand hängen. Unprivilegierte Benutzer verfügen nicht über die entsprechenden Zugriffsrechte, um diese Situation zu beheben. Wenn Sie jedoch über die Berechtigungen des Cloud-Administrators verfügen, können Sie den Status der Freigabe zurücksetzen, indem Sie Folgendes verwenden

$ manila reset-state [–state state] share_name

Befehl zum Zurücksetzen des Freigabestatus, wobei der Status angibt, welchem Zustand die Freigabe zugeordnet werden soll. Zu den Optionen gehören: Verfügbar, Fehler, Erstellen, Löschen, Error_Löschen Zustände.

Nach dem Ausführen

$ manila reset-state Share2 --state deleting

den Status der Freigabe überprüfen:

$ manila show Share2
+-----------------------------+-------------------------------------------+
| Property                    | Value                                     |
+-----------------------------+-------------------------------------------+
| status                      | deleting                                  |
| share_type_name             | default                                   |
| description                 | share from a snapshot.                    |
| availability_zone           | nova                                      |
| share_network_id            | 5c3cbabb-f4da-465f-bc7f-fadbe047b85a      |
| export_locations            | []                                        |
| share_server_id             | 41b7829d-7f6b-4c96-aea5-d106c2959961      |
| host                        | manila@generic1#GENERIC1                  |
| snapshot_id                 | 962e8126-35c3-47bb-8c00-f0ee37f42ddd      |
| is_public                   | False                                     |
| task_state                  | None                                      |
| snapshot_support            | True                                      |
| id                          | b6b0617c-ea51-4450-848e-e7cff69238c7      |
| size                        | 1                                         |
| name                        | Share2                                    |
| share_type                  | c0086582-30a6-4060-b096-a42ec9d66b86      |
| created_at                  | 2015-09-25T06:25:50.000000                |
| export_location             | 10.254.0.3:/shares/share-1dc2a471-3d47-...|
| share_proto                 | NFS                                       |
| consistency_group_id        | None                                      |
| source_cgsnapshot_member_id | None                                      |
| project_id                  | 20787a7ba11946adad976463b57d8a2f          |
| metadata                    | {u'source': u'snapshot'}                  |
+-----------------------------+-------------------------------------------+

Freigabe löschen

Wenn Sie eine Freigabe nicht mehr benötigen, können Sie sie mit dem Befehl manila delete share_name_or_ID löschen:

$ manila delete Share2

Bemerkung

Wenn Sie beim Erstellen einer Freigabe die Konsistenzgruppe angegeben haben, sollten Sie den Parameter –consistency-group angeben, um die Freigabe zu löschen:

$ manila delete ba52454e-2ea3-47fa-a683-3176a01295e6 --consistency-group \
  ffee08d9-c86c-45e5-861e-175c731daca2

Manchmal scheint es, dass eine Freigabe in einem der Übergangszustände hängt (d.h. „Erstellen, Löschen, Verwalten, Entmanagen, Vergrößern und Verkleinern“). In diesem Fall benötigen Sie zum Löschen den Befehl manila force-delete share_name_or_ID und administrative Berechtigungen, um ihn auszuführen:

$ manila force-delete b6b0617c-ea51-4450-848e-e7cff69238c7

Tipp

Weitere Details und zusätzliche Informationen zu anderen Fällen, Funktionen, API-Befehlen usw. finden Sie unter Share Management im Abschnitt „Shared File Systems“ im OpenStack Administrator Guide Dokument.

Schattenkopien erstellen

Der Dienst Shared File Systems bietet einen Mechanismus von Schattenkopien, die den Benutzern bei der Wiederherstellung ihrer eigenen Daten helfen. Um einen Schattenkopie zu erstellen, verwenden Sie den Befehl manila snapshot-create wie folgt:

$ manila snapshot-create Share1 --name Snapshot1 --description "Snapshot of Share1"
+-------------------+--------------------------------------+
| Property          | Value                                |
+-------------------+--------------------------------------+
| status            | creating                             |
| share_id          | e7364bcc-3821-49bf-82d6-0c9f0276d4ce |
| description       | Snapshot of Share1                   |
| created_at        | 2016-03-20T00:00:00.000000           |
| share_proto       | NFS                                  |
| provider_location | None                                 |
| id                | a96cf025-92d1-4012-abdd-bb0f29e5aa8f |
| size              | 1                                    |
| share_size        | 1                                    |
| name              | Snapshot1                            |
+-------------------+--------------------------------------+

Aktualisieren Sie dann bei Bedarf den Namen und die Beschreibung der erstellten Schattenkopie:

$ manila snapshot-rename Snapshot1 Snapshot_1 --description "Snapshot of Share1. Updated."

Um sicherzustellen, dass die Schattenkopie verfügbar ist, führen Sie nun aus:

$ manila snapshot-show Snapshot1
+-------------------+--------------------------------------+
| Property          | Value                                |
+-------------------+--------------------------------------+
| status            | available                            |
| share_id          | e7364bcc-3821-49bf-82d6-0c9f0276d4ce |
| description       | Snapshot of Share1                   |
| created_at        | 2016-03-30T10:53:19.000000           |
| share_proto       | NFS                                  |
| provider_location | 3ca7a3b2-9f9f-46af-906f-6a565bf8ee37 |
| id                | a96cf025-92d1-4012-abdd-bb0f29e5aa8f |
| size              | 1                                    |
| share_size        | 1                                    |
| name              | Snapshot1                            |
+-------------------+--------------------------------------+

Tipp

Weitere Details und zusätzliche Informationen zu Schattenkopien finden Sie unter Share Snapshots im Abschnitt „Shared File Systems“ im Dokument „OpenStack Administrator Guide“.

Erstellen eines Freigabe-Netzwerks

Um ein Freigabe-Netzwerk zu steuern, erfordert der Dienst Shared File Systems die Interaktion mit dem Networking-Dienst, um Share-Server selbst zu verwalten. Wenn der ausgewählte Treiber in einem Modus ausgeführt wird, der eine solche Art von Interaktion erfordert, müssen Sie das Freigabennetzwerk angeben, wenn eine Freigabe erstellt wird. Informationen zur Erstellung von Freigaben finden Sie unter Freigabe anlegen früher in diesem Kapitel. Überprüfen Sie zunächst die vorhandene Typenliste der Freigabenetzwerke nach:

$ manila share-network-list
+--------------------------------------+--------------+
| id                                   | name         |
+--------------------------------------+--------------+
+--------------------------------------+--------------+

Wenn die Liste der Freigaben-Netzwerke leer ist oder kein erforderliches Netzwerk enthält, erstellen Sie beispielsweise ein Freigabenetzwerk mit einem privaten Netzwerk und einem Subnetz.

$ manila share-network-create --neutron-net-id 5ed5a854-21dc-4ed3-870a-117b7064eb21 \
  --neutron-subnet-id 74dcfb5a-b4d7-4855-86f5-a669729428dc --name my_share_net \
  --description "My first share network"
+-------------------+--------------------------------------+
| Property          | Value                                |
+-------------------+--------------------------------------+
| name              | my_share_net                         |
| segmentation_id   | None                                 |
| created_at        | 2015-09-24T12:06:32.602174           |
| neutron_subnet_id | 74dcfb5a-b4d7-4855-86f5-a669729428dc |
| updated_at        | None                                 |
| network_type      | None                                 |
| neutron_net_id    | 5ed5a854-21dc-4ed3-870a-117b7064eb21 |
| ip_version        | None                                 |
| nova_net_id       | None                                 |
| cidr              | None                                 |
| project_id        | 20787a7ba11946adad976463b57d8a2f     |
| id                | 5c3cbabb-f4da-465f-bc7f-fadbe047b85a |
| description       | My first share network               |
+-------------------+--------------------------------------+

Die Netzwerkattribute Segmentierung_id, cidr, ip_version` und network_type werden automatisch auf die vom Netzwerkanbieter festgelegten Werte gesetzt.

Überprüfen Sie dann, ob das Netzwerk erstellt wurde, indem Sie die Netzwerkliste erneut anfordern:

$ manila share-network-list
+--------------------------------------+--------------+
| id                                   | name         |
+--------------------------------------+--------------+
| 5c3cbabb-f4da-465f-bc7f-fadbe047b85a | my_share_net |
+--------------------------------------+--------------+

Um schließlich eine Freigabe zu erstellen, die dieses Freigabennetzwerk verwendet, lesen Sie den zuvor in diesem Kapitel beschriebenen Anwendungsfall Freigabe erstellen.

Tipp

Weitere Informationen finden Sie unter Share Networks im Abschnitt „Shared File Systems“ im OpenStack Administrator Guide Dokument.

Verwalten eines Freigabe-Netzwerks

Es gibt ein Paar nützlicher Befehle, die bei der Manipulation von Freigabenetzwerken helfen. Überprüfen Sie zunächst die Netzwerkliste:

$ manila share-network-list
+--------------------------------------+--------------+
| id                                   | name         |
+--------------------------------------+--------------+
| 5c3cbabb-f4da-465f-bc7f-fadbe047b85a | my_share_net |
+--------------------------------------+--------------+

Wenn Sie das Backend mit driver_handles_share_servers = True (mit den Share-Servern) konfiguriert haben und bereits einige Operationen im Dienst Shared File Systems hatten, können Sie manila_service_network in der Neutronenliste der Netzwerke sehen. Dieses Netzwerk wurde vom Share-Treiber für den internen Gebrauch erstellt.

$ openstack network list
+--------------+------------------------+------------------------------------+
| ID           | Name                   | Subnets                            |
+--------------+------------------------+------------------------------------+
| 3b5a629a-e...| manila_service_network | 4f366100-50... 10.254.0.0/28       |
| bee7411d-d...| public                 | 884a6564-01... 2001:db8::/64       |
|              |                        | e6da81fa-55... 172.24.4.0/24       |
| 5ed5a854-2...| private                | 74dcfb5a-bd... 10.0.0.0/24         |
|              |                        | cc297be2-51... fd7d:177d:a48b::/64 |
+--------------+------------------------+------------------------------------+

Sie können auch detaillierte Informationen über das Freigabenetzwerk sehen, einschließlich der Felder network_type und segmentation_id:

$ openstack network show manila_service_network
+---------------------------+--------------------------------------+
| Field                     | Value                                |
+---------------------------+--------------------------------------+
| admin_state_up            | True                                 |
| availability_zone_hints   |                                      |
| availability_zones        | nova                                 |
| created_at                | 2016-03-20T00:00:00                  |
| description               |                                      |
| id                        | ef5282ab-dbf9-4d47-91d4-b0cc9b164567 |
| ipv4_address_scope        |                                      |
| ipv6_address_scope        |                                      |
| mtu                       | 1450                                 |
| name                      | manila_service_network               |
| port_security_enabled     | True                                 |
| provider:network_type     | vxlan                                |
| provider:physical_network |                                      |
| provider:segmentation_id  | 1047                                 |
| router:external           | False                                |
| shared                    | False                                |
| status                    | ACTIVE                               |
| subnets                   | aba49c7d-c7eb-44b9-9c8f-f6112b05a2e0 |
| tags                      |                                      |
| tenant_id                 | f121b3ee03804266af2959e56671b24a     |
| updated_at                | 2016-03-20T00:00:00                  |
+---------------------------+--------------------------------------+

Sie können auch die Sicherheitsdienste zum Freigabennetzwerk hinzufügen und entfernen.

Tipp

Weitere Informationen finden Sie im Unterabschnitt Sicherheitsdienste im Abschnitt „Shared File Systems“ des OpenStack-Administratorhandbuchs.

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_name angehä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 als snap (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 True oder 1 angegeben werden. False kann als False oder 0 angegeben 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

image_type

Momentaufnahme

instance_uuid

<uuuid der Instanz, die als Schattenkopie aufgenommen wurde>

base_image_ref

<uuuid des Originalabbildes der Instanz, die als Schattenkopie aufgenommen wurde>>

image_location

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öscht wird auf 1 gesetzt, wenn die Instanz gelöscht wurde und NULL, wenn sie nicht gelöscht wurde. Dieses Feld ist wichtig, um gelöschte Instanzen von Ihren Abfragen auszuschließen.

  • Das Feld uuuid ist 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_id und project_id sind 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 hostname enthä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_at

  • updated_at

  • deleted_at

  • scheduled_at

  • launched_at

  • terminated_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.)

Creative Commons Attribution 3.0 License

Except where otherwise noted, this document is licensed under Creative Commons Attribution 3.0 License. See all OpenStack Legal Documents.