OpenStack Cluster-as-a-Service Infrastruktur

Diese Rolle erstellt softwaredefinierte OpenStack-Infrastruktur, die verwendet werden kann, um auf Abruf komplexe Anwendungs-Topologien zu erzeugen. Eine aktuelle Version von OpenStack Heat wird dazu genutzt.

Anforderungen

Die OpenStack-APIs sollten vom Zielhost aus zugänglich sein. OpenStack Newton oder eine neuere Version wird benötigt. Die Anmeldeinformationen des Clients sollten in der Umgebung gesetzt sein oder im clouds.yaml-Format angegeben werden.

In Bezug auf Python-Pakete sind folgende erforderlich:

• ansible
• jmespath (wird von dem json_query Filter benötigt)

Rollenvariablen

cluster_venv: Optionaler Pfad zu einem Python-Virtualenv, in dem das Python-Paket shade installiert ist.

cluster_auth_type: Optionaler Name des OpenStack-Authentifizierungs-Plugins, das verwendet werden soll.

cluster_auth: Optionales Wörterbuch, das Authentifizierungsinformationen enthält.

cluster_cloud: Optionaler Name des OpenStack-Client-Konfigurations-Cloudnamens, der verwendet werden soll.

cluster_state: Gewünschter Zustand des Clusters, einer von present, absent oder query. Der Standardwert ist present. Wenn der Wert query ist, wird der Cluster nicht aktualisiert, aber seine Konfiguration wird abgerufen und ein Ansible-Inventar erstellt.

cluster_name: Name, der dem Heat-Stack gegeben werden soll. Der Standardwert ist cluster.

cluster_environment_nodenet: Eine Umgebungsdatei, die die Ressource angibt, die für die Netzwerkressource pro Node, Cluster::NodeNet, verwendet werden soll. HINWEIS: Diese Option ist veraltet zugunsten von Ressourcen zur Definition von nodenet_resource innerhalb von Gruppen und einer globalen Standardressource unter Verwendung von nodenet_resource innerhalb von cluster_params.

cluster_environment_instance: Eine Umgebungsdatei, die die Ressource angibt, die für die Instanzen, Cluster::Instance, verwendet werden soll. HINWEIS: Diese Option ist veraltet zugunsten von Ressourcen für spezifische Gruppen, indem eine Definition für node_resource zur Gruppe hinzugefügt wird, und einer globalen Standardressource durch die Definition von node_resource innerhalb von cluster_params.

cluster_environment: Eine Liste von Umgebungsdateien, die beim Erstellen des Heat-Stacks verwendet werden sollen.

cluster_params: Parameter, die in den Heat-Stack übergeben werden.

• cluster_prefix: Namenspräfix, das für die Konstruktion von Instanz-Hostnamen verwendet werden soll.

• cluster_groups: JSON-strukturierte Liste von Node-Gruppen, die jeweils durch ein Wörterbuch beschrieben sind und folgende enthalten:

  • name: Ein Name, um auf diese Gruppe zu verweisen.
  • flavor: Der Name oder UUID eines Instanz-Flavors, der für das Bereitstellen dieser Gruppe verwendet werden soll.
  • image: Der Name oder UUID eines Images, das für das Bereitstellen dieser Gruppe verwendet werden soll.
  • user: Der Name eines Cloud-Benutzers, für den SSH-Schlüssel bereitgestellt wurden und für den passwortloses Sudo konfiguriert ist. Könnte zum Beispiel centos, debian oder ubuntu sein.
  • num_nodes: Die Anzahl der Knoten, die innerhalb dieser Gruppe erstellt werden sollen.
  • volume_size: Optionale Größe in GB der Volumes, die zum Booten von Instanzen in dieser Gruppe verwendet werden, wenn die Umgebungsdatei instance-w-volume.yaml verwendet wird.
  • volume_type: Optionale Art der Volumes, die zum Booten von Instanzen in dieser Gruppe verwendet werden, wenn die Umgebungsdatei instance-w-volume.yaml verwendet wird.

• cluster_keypair: Name eines SSH-Schlüsselpaares, das zur Verbindung mit den Instanzen verwendet werden soll.

• cluster_az: Name der Verfügbarkeitszone, in der die Instanzen erstellt werden sollen.

• cluster_config_drive: Ob Metadaten über ein Config-Drive bereitgestellt werden sollen. Standard ist false.

• cluster_net: JSON-strukturierte Liste von Netzwerken, die jeweils durch ein Wörterbuch beschrieben sind und folgendes enthalten:

  • net: Name oder UUID eines Neutron-Netzwerks, an das die Instanzen angeschlossen werden sollen.
  • subnet: Name oder UUID eines Neutron-Subnetzes, an das die Instanzen angeschlossen werden sollen.
  • security_groups: Optionale Liste von Namen oder UUIDs von Sicherheitsgruppen, die zu den Ports der Instanzen hinzugefügt werden sollen. Sicherheitsgruppen können in jedem aufgeführten Netzwerk vorhanden oder nicht vorhanden sein.
  • floating_net: Optionaler Name oder UUID eines Neutron-Netzwerks, an das Floating-IPs angeschlossen werden sollen, wenn die Ressourcen Cluster::NodeNet1WithFIP oder Cluster::NodeNet2WithFIP verwendet werden.

• node_resource: Ein Ressourcenname aus der Bibliothek benutzerdefinierter Knotenressourcennamen. Dieser Ressourcentyp wird standardmäßig für Gruppen verwendet, die keinen spezifischen Knotenressourcentyp überschreiben.

  Gültige Optionen sind:

  • Cluster::Instance: Eine Instanz mit nur flüchtigem Speicher. Dies ist der Standard.
  • Cluster::InstanceWithVolume: Eine Instanz, die mit einem Cinder-Volume bereitgestellt wird.

• nodenet_resource: Ein Ressourcenname aus der Bibliothek benutzerdefinierter Netzwerkressourcen für die Netzwerktechnik von Knoten. Dieser Ressourcentyp wird für Gruppen verwendet, die keine Netzwerk-Konfiguration für Instanzen der Gruppe angeben.

  Gültige Optionen sind:

  • Cluster::NodeNet1: Ein einzelnes Netzwerk ohne zugewiesene Floating-IPs. Dies ist der Standard.
  • Cluster::NodeNet1WithFIP: Ein einzelnes Netzwerk mit zugewiesener und mit dem Port verbundener Floating-IP.
  • Cluster::NodeNet1WithPreallocatedFIP: Ein einzelnes Netzwerk mit Floating-IP (entnommen aus einer vorab zugewiesenen und bereitgestellten Liste) und mit dem Port verbunden.
  • Cluster::NodeNet2: Zwei Netzwerkschnittstellen. Die ersten beiden in cluster_net aufgeführten Netzwerke werden verwendet.
  • Cluster::NodeNet2WithFIP: Zwei Netzwerkschnittstellen. Die ersten beiden in cluster_net aufgeführten Netzwerke werden verwendet. Eine Floating-IP wird vom ersten Netzwerk zugewiesen und mit der Instanz verbunden.
  • Cluster::NodeNet2WithFIPSRIOV: Zwei Netzwerkschnittstellen. Die erste Schnittstelle hat eine Floating-IP, die (unter Verwendung von floating_net und security_groups) angebracht ist. Die zweite Schnittstelle ist als SR-IOV-Portressource konfiguriert, für eine leistungsstarke interne Vernetzung. Die ersten beiden in cluster_net aufgeführten Netzwerke werden verwendet.
  • Cluster::NodeNet3: Drei Netzwerkschnittstellen. Die ersten drei in cluster_net aufgeführten Netzwerke werden verwendet.

• router_networks: Eine optionale Liste von IP-Subnetz-CIDRs, die als erlaubte Netzwerke hinzugefügt werden sollten. Dies ist erforderlich, wenn ein Port mit einem Gateway-Knoten verbunden ist, der IP-Routing zwischen Subnetzen durchführt. Diese sollten dem Format von allowed_address_pairs entsprechen hier. Eine einfache, großzügige Konfiguration für router_networks wäre:

router_networks:
  - ip_address: "0.0.0.0/0"

cluster_inventory: Nach der Bereitstellung wird eine Inventardatei generiert, die in nachfolgenden Ansible-gesteuerten Konfigurationen verwendet werden kann.

cluster_roles: Eine Reihe von Gruppenzuordnungen, die in der generierten Ansible-Inventardatei vorgenommen werden sollen. Dieser Parameter ist eine Liste von Wörterbüchern in folgender Form:

• name: Name der Gruppe, die im Ansible-Inventar definiert werden soll.
• groups: Eine Liste von Gruppen, die aus den oben bereitgestellten Wörterbuch-Objekten für cluster_groups ausgewählt wurden.

cluster_group_vars: Ein Wörterbuch, das Inventargruppen den Gruppenvariablen zuordnet, die für diese Gruppe definiert werden sollen. Die Gruppenvariablen für jede Gruppe sind als Wörterbuch definiert, das Variablennamen ihren Werten zuordnet.

cluster_environment_group: Ein optionaler Ansible-Gruppenname, zu dem alle Cluster-Hosts und localhost hinzugefügt werden. Dies kann nützlich sein, wenn es eine einzige Gruppe gibt, die eine Umgebung wie Entwicklung/Staging/Produktion repräsentiert.

Abhängigkeiten

Diese Rolle benötigt das Vorhandensein des Python-Pakets shade auf dem Zielhost. Das Paket kann in einer Python-Virtual-Umgebung installiert werden, in diesem Fall sollte der Pfad zum Virtualenv in der cluster_venv-Variable angegeben werden.

Die Rolle stackhpc.os-shade kann verwendet werden, um das Python-Paket shade zu installieren.

Beispiel-Playbook

Das folgende Playbook erstellt einen Heat-Stack für einen Cluster, der eine login-Gruppe und eine compute-Gruppe enthält.

---
# Dieses Playbook verwendet die Ansible OpenStack-Module, um einen Cluster
# mit einer Anzahl von Bare-Metal-Compute-Node-Instanzen zu erstellen und ihn
# für eine SLURM-Partition zu konfigurieren.
- hosts: openstack
  roles:
    - role: stackhpc.cluster-infra
      cluster_name: "openhpc"
      cluster_params:
        cluster_prefix: "ohpc"
        cluster_keypair: "admin_rsa"
        cluster_net:
          - net: "internal"
            subnet: "internal"
            floating_net: "external"
            security_groups:
              - "default"
              - "slurm"
        cluster_groups:
          - name: "login"
            flavor: "compute-B"
            image: "CentOS7-OpenHPC"
            num_nodes: 1
            node_resource: "Cluster::InstanceWithVolume"
            node_resource: "Cluster::NodeNet1WithFIP"
          - name: "compute"
            flavor: "compute-A"
            image: "CentOS7-OpenHPC"
            num_nodes: 16
      cluster_group_vars:
        cluster:
          ansible_user: centos

Autoreninformationen

• Stig Telfer (stig@stackhpc.com)
• Bharat Kunwar (bharat@stackhpc.com)