Warum wird dies benötigt?

Es gibt einige Redundanzfälle, bei denen eine Gruppe virtueller Maschinen in einem redundanten Cluster ausgeführt wird. In solchen Fällen bilden die virtuellen Maschinen untereinander ein Redundanzschema. Wenn eine virtuelle Maschine ausfällt oder beschädigt wird, bietet der Rest des Clusters weiterhin Dienste an. In einem solchen Szenario sollten diese virtuellen Maschinen auf separaten physischen Hosts ausgeführt werden, um eine bessere Kontinuität bei Ausfällen physischer Hosts zu gewährleisten. Wenn sie auf demselben Host laufen, wären bei einem Ausfall dieses Hosts mehrere Mitglieder des Clusters betroffen. Daher sollten diese virtuellen Maschinen immer auf verschiedenen Hosts ausgeführt werden ("Anti-Affinity").



Openstack Anti-Affinity-Richtlinien

 

VHI ist eine Openstack-basierte Plattform. Openstack verfügt bereits über eine Methode zur Implementierung von Anti-Affinity-Regeln, und diese Methode kann auch in VHI verwendet werden. Wie bei vielen Openstack-Vorgängen erfordert auch diese Methode die Verwendung von Openstack-Befehlszeilen-Tools.

Es wird dabei vorausgesetzt, dass die API Anbindung über einen OpenStack Client an unser vDatacenter bereits vorhanden ist. 


  1. Wir werden eine Richtlinie für Anti-Affinity erstellen. Dazu erstellen Sie einfach eine Servergruppe in Openstack und legen die Richtlinie für die Gruppe fest.
  2. Überprüfen Sie die vorhandenen Richtlinien mit

    #openstack --insecure server group list

    Standardmäßig sind keine Servergruppen definiert. Das Ergebnis ist leer, wenn noch keine Servergruppen definiert sind.


  3. Wir werden eine Servergruppe mit den Namen "aff2" für Anti-Affinitätsrichtlinien definieren. Dies kann mit dem Openstack-Befehl durchgeführt werden:

    #nova server-group-create aff2 anti-affinity


    Die ID der Richtlinien wird während des Betriebs herangezogen.

  4. Jetzt können wir diesen Richtlinien virtuelle Maschinen zuweisen. Die Zuweisung von Richtlinien für virtuelle Maschinen kann nur während der VM-Erstellung erfolgen, nicht danach. Daher müssen wir die virtuellen Maschinen über die Befehlszeilenschnittstelle mit den erforderlichen Richtlinieneinstellungsoptionen erstellen. In unserem Beispiel werden wir zwei virtuelle Maschinen mit dem Image "cirros", der Variante "tiny", 1 GB Festplattenspeicher und einem "öffentlichen" Netzwerk erstellen.

  5. Wir beginnen mit dem Sammeln der erforderlichen Informationen

    #openstack --insecure network list

    Beachten Sie die Netzwerkkennung "public" (401352b7-5bea-4baa-9c1a-322655154175)


    #openstack --insecure image list

    Beachten Sie den Image-Name "cirros" (e6ed3145-36ec-43ed-8198-17cc757d8395)


    #openstack --insecure flavor list

    wählen Sie einen Flavor, in diesem Beispiel wird es "tiny" sein

  6. Wir erstellen zwei Festplatten-Volumes, die für die virtuellen Maschinen verwendet werden. Diese Volumes werden mit dem "cirros"-Image mit 1 GByte Größe erstellt.

    #openstack --insecure volume create --image cirros --size 1 uhvol1
    #openstack --insecure volume create --image cirros --size 1 uhvol2

  7. Nun sind wir bereit, unsere virtuellen Maschinen zu erstellen. Diese werden, in unserem Beispiel, vmtest1 und vmtest2 genannt.

    #openstack --insecure server create vmtest1 \
    --flavor tiny \
    --nic net-id=401352b7-5bea-4baa-9c1a-322655154175 \
    --volume uhvol1 \
    --hint group=be3479fc-b45f-4ae2-8a9b-25a1e1f54171

    #openstack --insecure server create vmtest2 \
    --flavor tiny \
    --nic net-id=401352b7-5bea-4baa-9c1a-322655154175 \
    --volume uhvol2 \
    --hint group=be3479fc-b45f-4ae2-8a9b-25a1e1f54171

  8. Die VM-Erstellung kann auch über das VHI-Verwaltungspanel beobachtet werden. Die beiden VMs werden gemäß der Richtlinie auf separaten physischen Knoten geplant.

    Anmerkung:
    Wenn Sie beispielsweise 3 VMs zur Regeln hinzufügen, so werden alle 3 VMs auf 3 verschiedenen Knoten platziert. Bei 4 VMs pro  entsprechend auf 4 verschiedenen Knoten usw.