Hinweis:

Open MPI auf Oracle Roving Edge Infrastructure verwenden

Einführung

Oracle Roving Edge Infrastructure ist eine robuste Cloud-Computing- und Speicherplattform, die für das Deployment an der Netzwerk-Edge oder an Standorten mit begrenzter oder keiner externen Konnektivität geeignet ist. Wenn sich größere, komplexere und anspruchsvollere Workloads auf die Netzwerk-Edge zubewegen, kann dies Herausforderungen für eine Edge-Infrastruktur darstellen.

Open MPI ist eine Implementierung des Message Passing Interface-(MPI-)Standards, der für die Entwicklung paralleler Anwendungen in High Performance Computing (HPC) verwendet wird. Open MPI kann verwendet werden, um High Performance Computing und hochparallele Workloads über relativ kleinere Infrastrukturteile bereitzustellen, die dann als größere, aggregierte Gruppe von Ressourcen arbeiten. Dieser Ansatz kann verwendet werden, um eine Workload auf CPU und andere Compute-Ressourcen wie GPU zu verteilen, die das Deployment größerer, rechenintensiver Aufgaben an der Netzwerk-Edge wie Vorhersagemodellierung oder andere Aufgaben des Typs Künstliche Intelligenz/Maschinelles Lernen (KI/ML) ermöglichen.

Mit dem offenen MPI können Sie parallele Workloads bereitstellen, die Ressourcen auf allen Oracle Roving Edge Infrastructure-Knoten nutzen. Netfilter stellt die erforderliche Zielnetzwerkadressübersetzung (DNAT) und Quellnetzwerkadressübersetzung (SNAT) für VM-Instanzen mit Clustersoftware bereit, die über Oracle Roving Edge Infrastructure-Knoten gehostet wird. In diesem Tutorial wird Open MPI mit Netfilter auf Oracle Roving Edge Infrastructure implementiert, auf dem ein Primzahlenrechner ausgeführt wird, um eine verbesserte Performance bei Verwendung paralleler Ressourcen zu demonstrieren.

Hintergrundinformationen

Die offene MPI kann auf mehreren VM-Instanzen innerhalb eines einzelnen Oracle Roving Edge Infrastructure-Knotens oder auf mehreren Oracle Roving Edge Infrastructure-Knoten ausgeführt werden. Die Ausführung auf einem einzelnen Oracle Roving Edge Infrastructure-Knoten ist nahtlos und stellt keine Probleme dar. Bei der Ausführung auf mehreren Oracle Roving Edge Infrastructure-Knoten ist es wichtig, das Networking auf Oracle Roving Edge Infrastructure-VM-Instanzen zu verstehen und zu verstehen, wie Open MPI Traffic weiterleitet, um mögliche Probleme zu vermeiden.

Networking auf Oracle Roving Edge Infrastructure Virtual Machine-Instanzen

Virtual-Machine-Instanzen, die auf Oracle Roving Edge Infrastructure ausgeführt werden, kommunizieren mit privaten IP-Adressen mit anderen VM-Instanzen in demselben Subnetz, das auf demselben Knoten gehostet wird. Öffentliche IP-Adressen können VM-Instanzen zugewiesen werden, die auf Oracle Roving Edge Infrastructure gehostet werden, damit Instanzen mit anderen Subnetzen und Ressourcen kommunizieren können, die außerhalb des Oracle Roving Edge Infrastructure-Knotens ausgeführt werden, auf dem sie gehostet werden.

Hinweis: Öffentliche IP-Adressen werden VM-Instanz-VNICs aus einem öffentlichen IP-Adresspool zugewiesen. Die Adressen werden zwar als Öffentliche IPs bezeichnet, sind jedoch tatsächlich IP-Adressen in demselben lokalen Netzwerk, in dem der Oracle Roving Edge Infrastructure-Knoten über seinen RJ-45-Port verbunden ist. Bei diesen Adressen kann es sich um eine IPv4-Adresse handeln, die über das Internet erreichbar ist, oder um Adressen in einem privaten Subnetz im lokalen Netzwerk. Diese Adressen werden auch als externe IP-Adressen bezeichnet, da sie mit Ressourcen verbunden werden können, die sich außerhalb des Knotens befinden, auf dem die VM-Instanz gehostet wird.

Es ist wichtig zu verstehen, wann eine VM-Instanz, die innerhalb eines Oracle Roving Edge Infrastructure-Knotens ausgeführt wird, versucht, auf Ressourcen außerhalb des Knotens zuzugreifen. Der Traffic wird über die externe IP-Adresse geleitet, die innerhalb des Knotens und an die externe Netzwerkverbindung weitergeleitet wird.

Im folgenden Image wird eine Beispiel-VM-Instanz auf dem Oracle Roving Edge Infrastructure-Knoten angezeigt. Beachten Sie die zugewiesenen öffentlichen und privaten IP-Adressen.

Eine Beispiel-VM-Instanz auf einem Oracle Roving Edge Infrastructure-Knoten

Herausforderungen für die Ausführung offener MPIs auf mehreren Oracle Roving Edge Infrastructure-Knoten

Die Verwendung privater IP-Adressen der VM-Instanz ist für das Clustering von Software, wie Open MPI, problematisch, wenn sie auf mehreren Oracle Roving Edge Infrastructure-Knoten implementiert wird. Jeder Knoten kennt keine Zuordnungen von privaten zu öffentlichen IP-Adressen und die Übersetzung der Zuordnungen für VM-Instanzen, die auf anderen Knoten gehostet werden. Da die Zuordnungen nicht gemeinsam verwendet werden, werden Pakete, die private IP-Adressen verwenden, entweder falsch weitergeleitet oder verloren.

Ein Beispiel, wie dieses Problem mit Open MPI aussehen könnte:

Offene MPIs, die auf VM-Instanzen ausgeführt werden, versuchen, den besten Netzwerkpfad zu bestimmen, mit dem andere VM-Instanzmitglieder erreicht werden können. Die Software prüft möglicherweise die lokalen Schnittstellen und IP-Adressen und registriert diese bei anderen Knoten im Cluster.

Open MPI für Oracle Roving Edge Infrastructure implementieren

Um die Nicht-Freigabe eines internen Netzwerks von Oracle Roving Edge Infrastructure zu bewältigen, wird die Netfilter-Software auf den Linux-VM-Instanzen verwendet, um Netzwerkpakete neu zu schreiben, die von VMs stammen, die auf anderen Oracle Roving Edge Infrastructure-Knoten gehostet werden, und für die sie bestimmt sind.

Designkonzeption

In diesem Tutorial werden drei Oracle Roving Edge Infrastructure Roving Edge Devices-(RED-)Knoten zum Erstellen eines offenen MPI-Clusters verwendet. Alle REDs sind mit einem gemeinsamen externen Netzwerk verbunden. Jeder Knoten wurde mit einem eigenen externen IP-Pool für die Zuweisung zu einer VM-Instanz konfiguriert.

VCN- und Subnetz-CIDR-Tabelle

RED-Name VCN-CIDR Subnetz-CIDR
RED1 10/16 10/24
RED2 10/16 10/24
RED3 10/16 10/24

Das folgende Beispiel zeigt zwei Netzwerkkonfigurationen aus zwei verschiedenen REDs.

Beispiel-VCN und Subnetz auf "RED1"

Beispiel-VCN und Subnetz auf "RED2"

Zielgruppe

Oracle Roving Edge Infrastructure-Administratoren, -Entwickler und -Benutzer.

Ziele

Voraussetzungen

Aufgabe 1: Virtual Machine-Instanzen erstellen

Erstellen Sie in jedem Subnetz auf jedem RED eine VM-Instanz.

Beispiel-IP-Adresszuweisungen:

RED-Name VM-Name VM O/S Private VM-IP Öffentliche VM-IP
RED1 redvm1 Ubuntu 22.04 10/24 10,123
RED2 redvm2 Ubuntu 22.04 10/24 10,123
RED3 redvm3 Ubuntu 22.04 10/24 10,123

Hinweis: Die VM-Instanzen in dieser Aufgabe werden mit einem aus Oracle Cloud Infrastructure (OCI) exportierten Image mit OCI Ubuntu 22.04 LTS erstellt. Jede Linux-Distribution mit geeigneten Open MPI-Packages kann verwendet werden, z.B. Oracle Linux 8 oder 9, Fedora usw.

Beispiel-VM-Liste auf "RED3"

  1. Navigieren Sie in jedem RED zu Compute, Instanz, und klicken Sie auf Instanz erstellen.

  2. Geben Sie unter Compute-Instanz erstellen den Namen ein, wählen Sie das importierte benutzerdefinierte Image, die Ausprägung, das Netzwerk konfigurieren und die SSH-Schlüssel aus, und klicken Sie auf Erstellen.

    Compute-Image auf jedem RED erstellen

Aufgabe 2: Open MPI-Package auf jeder VM-Instanz installieren

Nachdem alle VM-Instanzen erstellt wurden, melden Sie sich über SSH mit dem beim Provisioning angegebenen Schlüssel bei jeder VM-Instanz an. Die folgenden Befehle sind für Ubuntu 22.04 geeignet. Sie müssen diese Anweisungen möglicherweise anpassen oder zusätzliche Package-Repositorys einbeziehen, wenn Sie eine andere Linux-Distribution verwenden.

  1. Führen Sie den folgenden Befehl aus, um das System zu aktualisieren und neu zu starten.

    sudo apt update && sudo apt upgrade -y

    Dieser Vorgang kann etwas länger dauern. Wenn dieser Vorgang abgeschlossen ist, starten Sie die Instanz neu.

    sudo shutdown -r now

  2. Melden Sie sich bei der Instanz an, und installieren Sie die Open MPI-Packages.

    Hinweis:

    • Dies wird durch einige Abhängigkeiten ziehen.

    • Das Package libopenmpi-dev ist nur erforderlich, um später ein Beispielprogramm zu kompilieren, mit dem getestet werden soll. Wenn Sie Open MPI-Funktionen nicht in Programme kompilieren möchten, ist dieses Paket nicht erforderlich.

    sudo apt install openmpi-bin libopenmpi-dev -y

Aufgabe 3: Zielnetzwerkadressübersetzung (DNAT) und Quellnetzwerkadressübersetzung (SNAT) einrichten

  1. Zeigen Sie Details zu jeder gestarteten VM-Instanz an, und notieren Sie sich die privaten und nach dem Zufallsprinzip zugewiesenen öffentlichen IP-Adressen. Navigieren Sie zu Compute, Instanz, und klicken Sie auf den Instanznamen, um die Details anzuzeigen.

    Beispiel-VM auf "RED3"

  2. Erstellen Sie die SNATs.

    • Wenn die SNAT-Regeln für jede VM in einer Tabelle zugeordnet werden, sollte es folgendermaßen aussehen:

      SNAT Von RED1 Von RED2 Von RED3
      Auf redvm1 - Eingabe src 10.123.123.67 SNAT to src 10.0.2.2 Eingabe src 10.123.123.101 SNAT to src 10.0.3.2
      Auf redvm2 Eingabe src 10.123.123.32 SNAT to src 10.0.1.2 - Eingabe src 10.123.123.101 SNAT to src 10.0.3.2
      Auf redvm3 Eingabe src 10.123.123.32 SNAT to src 10.0.1.2 Eingabe src 10.123.123.67 SNAT to src 10.0.2.2 -

    • Verwenden Sie iptables-Befehle für jede VM.

      • Auf redvm1.

        sudo iptables -I INPUT --src 10.123.123.0/24 -j ACCEPT -m comment --comment "Allow REDs public subnet access."
sudo iptables -t nat -I INPUT -p tcp -s 10.123.123.67 -j SNAT --to-source 10.0.2.2
sudo iptables -t nat -I INPUT -p tcp -s 10.123.123.101 -j SNAT --to-source 10.0.3.2
sudo netfilter-persistent save

      • Auf redvm2.

        sudo iptables -I INPUT --src 10.123.123.0/24 -j ACCEPT -m comment --comment "Allow REDs public subnet access."
sudo iptables -t nat -I INPUT -p tcp -s 10.123.123.32 -j SNAT --to-source 10.0.1.2
sudo iptables -t nat -I INPUT -p tcp -s 10.123.123.101 -j SNAT --to-source 10.0.3.2
sudo netfilter-persistent save

      • Auf redvm3.

        sudo iptables -I INPUT --src 10.123.123.0/24 -j ACCEPT -m comment --comment "Allow REDs public subnet access."
sudo iptables -t nat -I INPUT -p tcp -s 10.123.123.32 -j SNAT --to-source 10.0.1.2
sudo iptables -t nat -I INPUT -p tcp -s 10.123.123.67 -j SNAT --to-source 10.0.2.2
sudo netfilter-persistent save

      Hinweis: Das Hinzufügen der ersten Regel (sudo iptables -I INPUT --src 10.123.123.0/24 -j ACCEPT), um den Zugriff aus dem Subnetz zuzulassen, das die REDs für ihre öffentlichen IPs verwenden. Ohne diese (oder eine ähnliche Regel) wird eingehender Traffic von RED zu RED wahrscheinlich von der empfangenden RED gelöscht. Bei diesen VMs werden die neuen Regeln mit sudo netfilter-persistent save beibehalten. Dieser Befehl ist jedoch wahrscheinlich etwas anderes, wenn Sie eine andere Linux-Distribution verwenden.

  3. Erstellen Sie die DNATs.

    • Wenn Sie die DNAT-Regeln für jede VM in einer Tabelle zuordnen, sollte dies wie folgt aussehen:

      DNAT Gehe zu RED1 Gehe zu RED2 Gehe zu RED3
      Auf redvm1 - Ausgabe dst 10.0.2.2 DNAT to dst 10.123.123.67 Ausgabe dst 10.0.3.2 DNAT to dst 10.123.123.101
      Auf redvm2 Ausgabe dst 10.0.1.2 DNAT to dst 10.123.123.32 - Ausgabe dst 10.0.3.2 DNAT to dst 10.123.123.101
      Auf redvm3 Ausgabe dst 10.0.1.2 DNAT to dst 10.123.123.32 Ausgabe dst 10.0.2.2 DNAT to dst 10.123.123.67 -

    • Verwenden Sie iptables-Befehle für jede VM.

      • Auf redvm1.

        sudo iptables -t nat -I OUTPUT -p tcp -d 10.0.2.2 -j DNAT --to-destination 10.123.123.67
sudo iptables -t nat -I OUTPUT -p tcp -d 10.0.3.2 -j DNAT --to-destination 10.123.123.101
sudo netfilter-persistent save

      • Auf redvm2.

        sudo iptables -t nat -I OUTPUT -p tcp -d 10.0.1.2 -j DNAT --to-destination 10.123.123.32
sudo iptables -t nat -I OUTPUT -p tcp -d 10.0.3.2 -j DNAT --to-destination 10.123.123.101
sudo netfilter-persistent save

      • Auf redvm3.

        sudo iptables -t nat -I OUTPUT -p tcp -d 10.0.1.2 -j DNAT --to-destination 10.123.123.32
sudo iptables -t nat -I OUTPUT -p tcp -d 10.0.2.2 -j DNAT --to-destination 10.123.123.67
sudo netfilter-persistent save

      Hinweis: Auf den VM-Instanzen werden die neuen Regeln mit sudo netfilter-persistent save dauerhaft gespeichert.

Aufgabe 4: Offene MPI einrichten

Open MPI verwendet SSH, um zwischen Clustermitgliedern zu kommunizieren. Daher müssen einige Dinge erledigt werden, bevor Jobs ausgeführt werden können.

  1. Offene MPI verwendet die privaten IP-Adressen jeder der VMs, macht /etc/hosts-Einträge für jede VM-Instanz und ihre private IP-Adresse auf jeder offenen MPI-VM-Instanz.

    Beispiel: Wenn Sie die Konfiguration über dem Eintrag /etc/hosts in redvm1 verwenden, werden die folgenden Einträge enthalten:

    127.0.0.1 localhost
127.0.1.1 redvm1  redvm1
10.0.2.2  redvm2
10.0.3.2  redvm3

    Auf redvm2 enthält die /etc/hosts die folgenden Einträge:

    127.0.0.1 localhost
127.0.1.1 redvm2  redvm2
10.0.1.2  redvm1
10.0.3.2  redvm3

    Auf redvm3 enthält die /etc/hosts die folgenden Einträge:

    127.0.0.1 localhost
127.0.1.1 redvm3  redvm3
10.0.1.2  redvm1
10.0.2.2  redvm2

  2. Außerdem müssen wir sicherstellen, dass die SSH-Äquivalenz zwischen jeder VM für die zu verwendende offene MPI vorhanden ist.

    Hinweis: Hierbei wird davon ausgegangen, dass es sich um neue VMs handelt, die keine vorhandenen SSH-Schlüssel für den Ubuntu-Benutzer enthalten. Wenn Sie ältere VMs verwenden, für die bereits SSH-Schlüssel erstellt wurden, müssen Sie diese Anweisungen anpassen. Diese Anweisungen können vorhandene Schlüssel überschreiben und Sie aus Ihren VMs sperren.

    1. Erstellen Sie in redvm1 ein neues Public- oder Private-Key-Paar (wenn Sie noch keine Schlüssel erstellt haben). Verwenden Sie den Befehl ssh-keygen ähnlich ssh-keygen -b 4096 -t rsa (übernehmen Sie die Standardwerte, legen Sie kein Kennwort für die neuen Schlüssel fest). Dadurch werden ~/.ssh/id_rsa und ~/.ssh/id_rsa.pub generiert.

    2. Fügen Sie den neuen Public Key der Datei authorized_keys hinzu, indem Sie cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys ausführen oder manuell über einen Texteditor kopieren.

    3. Kopieren Sie id_rsa und id_rsa.pub in das Verzeichnis ~/.ssh des ubuntu-Benutzers auf redvm2 und redvm3. Stellen Sie sicher, dass Sie id_rsa.pub zu authorized_keys hinzufügen, cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys auf redvm2 und redvm3 ausführen.

    4. Nachdem dies geschehen ist, stellen Sie von jeder VM eine Verbindung zu allen anderen VMs einschließlich der VM selbst her, um sicherzustellen, dass die Konnektivität funktioniert und SSH den anderen Hosts vertraut.

      • SSH-Verbindung zu redvm1.

        ubuntu@redvm1:~$ ssh redvm1 date
The authenticity of host 'redvm1 (127.0.1.1)' can't be established.
ED25519 key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'redvm1' (ED25519) to the list of known hosts.
Fri Apr  5 04:28:57 UTC 2024
ubuntu@redvm1:~$
ubuntu@redvm1:~$ ssh redvm2 date
The authenticity of host 'redvm2 (10.0.2.2)' can't be established.
ED25519 key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'redvm2' (ED25519) to the list of known hosts.
Wed Jan 31 04:29:11 UTC 2024
ubuntu@redvm1:~$
ubuntu@redvm1:~$ ssh redvm3 date
The authenticity of host 'redvm3 (10.0.3.2)' can't be established.
ED25519 key fingerprint is SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
This key is not known by any other names
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'redvm3' (ED25519) to the list of known hosts.
Wed Jan 31 04:29:19 UTC 2024

    5. Wiederholen Sie die obigen Schritte, um eine Verbindung zwischen redvm2 und redvm2, redvm1 und redvm3 herzustellen und redvm3 mit redvm3, redvm1 und redvm2 zu verbinden.

  3. Erstellen Sie für jedes Cluster Member einen gemeinsamen Speicherort.

    Hinweis: Idealerweise verfügen alle VM-Instanzen, die Open MPI verwenden, über einen Shared Storage-Speicherort. Dies kann die Form von NFS, GlusterFS, OCFS2 oder einer beliebigen Anzahl anderer Shared File System-Lösungen haben. Dies ist besonders wichtig, wenn ein gemeinsames Arbeitsverzeichnis oder Dataset für die Workload erforderlich ist.

    Ein freigegebenes Dateisystem ist in diesem Beispiel nicht erforderlich, sondern nur ein Speicherort mit einem gemeinsamen Namen für unsere Testbinärdateien. Erstellen Sie auf jeder VM den allgemeinen Namensspeicherort /mpitest.

    sudo mkdir /mpitest && sudo chown ubuntu:ubuntu /mpitest

    Wenn Sie ein freigegebenes Dateisystem verwenden, wird das freigegebene Dateisystem an diesem Speicherort auf allen VM-Instanzen gemountet.

  4. Erstellen Sie eine hostfile zur Verwendung mit mpirun. Weitere Informationen finden Sie unter Wie verwende ich die Option -hostfile für mpirun?.

    1. Wir erstellen zwei hostfiles zum Testen. Erstellen Sie auf redvm1 mit dem oben erstellten allgemeinen Namensspeicherort /mpitest eine Datei /mpitest/mpihosts.txt mit dem folgenden Inhalt:

      redvm1
redvm2
redvm3

    2. Erstellen Sie eine Datei /mpitest/mpihosts_slots.txt mit dem folgenden Inhalt:

      redvm1 slots=1
redvm2 slots=1
redvm3 slots=1

Hinweis: In diesem Tutorial werden Tests nur von redvm1 ausgeführt, sodass diese Dateien nicht in redvm2 und redvm3 kopiert werden müssen. Wenn Sie auch Jobs von anderen VMs ausführen möchten, müssen Sie diese Dateien in die anderen VM-Instanzen kopieren oder ein ordnungsgemäßes freigegebenes Dateisystem wie NFS verwenden.

Aufgabe 5: VM-Instanz testen

  1. Ein einfacher Test verteilter Befehle.

    • Ein einfacher Test besteht nur darin, einen Befehl wie hostname für alle Cluster Member aufzurufen. Im Folgenden finden Sie die erwartete Ausgabe, die auf drei Knoten mit der Datei slots=1 (mpihosts_slots.txt) ausgeführt wird. Die Direktive slots informiert mpirun darüber, wie viele Prozesse diesem Knoten zugewiesen werden können, anstatt mpirun die Anzahl der Prozesse zu bestimmen.

      Hinweis: Die Angabe von slots ist möglicherweise erforderlich, wenn Sie andere Ressourcen als CPU (z.B. GPUs) verwenden, bei denen Sie Prozesse auf die Anzahl der anderen Ressource beschränken möchten. Andernfalls können Prozesse fehlschlagen, da die anderen Ressourcen nicht zugewiesen werden können.

      ubuntu@redvm1:~$ cd /mpitest

ubuntu@redvm1:/mpitest$ cat mpihosts_slots.txt
redvm1 slots=1
redvm2 slots=1
redvm3 slots=1

ubuntu@redvm1:/mpitest$ mpirun --hostfile mpihosts_slots.txt hostname
redvm1
redvm2
redvm3

    • Führen Sie denselben Test aus, aber ohne die Datei slots (mpihosts.txt) anzugeben, bestimmt mpirun die verfügbaren CPUs und führt die Anzahl der hostname-CPU-Befehle auf jedem Knoten aus. Diese drei VMs haben 16 CPUs. Daher sollten wir 3 x 16 Antworten (16 von jedem Hostnamen) erhalten.

      ubuntu@redvm1:/mpitest$ cat mpihosts.txt
redvm1
redvm2
redvm3

ubuntu@redvm1:/mpitest$ mpirun --hostfile mpihosts.txt hostname | sort | uniq -c
    16 redvm1
    16 redvm2
    16 redvm3

  2. Erstellen Sie eine Binärdatei für einen offenen MPI-Test.

    Für einen richtigen Test mit einem Programm, das Open MPI verwendet, verwenden wir ein Beispiel für den Primzahlenrechner von John Burkardt. Das muss auf redvm1 heruntergeladen und kompiliert werden. Weitere Informationen finden Sie unter Prime Number Calculator von John Burkardt.

    ubuntu@redvm1:~$ cd /mpitest

ubuntu@redvm1:/mpitest$ curl https://people.sc.fsu.edu/~jburkardt/c_src/prime_mpi/prime_mpi.c -o prime_mpi.c
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                Dload  Upload   Total   Spent    Left  Speed
100  4699  100  4699    0     0   2990      0  0:00:01  0:00:01 --:--:--  2991

ubuntu@redvm1:/mpitest$ mpicc prime_mpi.c -o prime_mpi

ubuntu@redvm1:/mpitest$ ls -l prime_mpi
-rwxrwxr-x 1 ubuntu ubuntu 16736 Apr  5 05:38 prime_mpi

    Da ein freigegebenes Dateisystem nicht zum Testen eingerichtet ist, muss die Binärdatei prime_mpi in redvm2 und redvm3 in demselben Verzeichnis kopiert werden, in dem sie sich auf redvm1 befindet. Führen Sie den folgenden Befehl aus.

    ubuntu@redvm1:/mpitest$ scp prime_mpi redvm2:/mpitest
prime_mpi                                                                                                                     100%   16KB  27.4MB/s   00:00
ubuntu@redvm1:/mpitest$ scp prime_mpi redvm3:/mpitest
prime_mpi                                                                                                                     100%   16KB  28.3MB/s   00:00

  3. Um eine Baseline zu vergleichen, führen Sie eine binäre Standalone-Version von Open MPI aus. Führen Sie prime_mpi ohne offenen MPI für eine Baseline oder einen Vergleich aus.

    ubuntu@redvm1:/mpitest$ ./prime_mpi
31 January 2024 06:08:17 AM

PRIME_MPI
  C/MPI version

  An MPI example program to count the number of primes.
  The number of processes is 1

        N        Pi          Time

        1         0        0.000003
        2         1        0.000000
        4         2        0.000000
        8         4        0.000000
        16         6        0.000000
        32        11        0.000001
        64        18        0.000002
      128        31        0.000022
      256        54        0.000019
      512        97        0.000066
      1024       172        0.000231
      2048       309        0.000810
      4096       564        0.002846
      8192      1028        0.010093
    16384      1900        0.037234
    32768      3512        0.137078
    65536      6542        0.515210
    131072     12251        1.932970
    262144     23000        7.243419

PRIME_MPI - Master process:
  Normal end of execution.

31 January 2024 06:08:27 AM

    Hinweis: Die Anzahl der Prozesse beträgt 1, und die Ausführung dauert etwa 10 Sekunden.

  4. Eine verteilte Ausführung mit Open MPI. Führen Sie prime_mpi mit Open MPI für alle verfügbaren CPUs auf den drei VM-Instanzen aus, und verwenden Sie die Datei mpihosts.txt.

    ubuntu@redvm1:/mpitest$ mpirun --hostfile mpihosts.txt ./prime_mpi
31 January 2024 06:09:02 AM

PRIME_MPI
  C/MPI version

  An MPI example program to count the number of primes.
  The number of processes is 48

        N        Pi          Time

        1         0        0.020740
        2         1        0.000428
        4         2        0.000331
        8         4        0.000392
        16         6        0.000269
        32        11        0.000295
        64        18        0.000374
      128        31        0.000390
      256        54        0.000380
      512        97        0.000331
      1024       172        0.000351
      2048       309        0.000385
      4096       564        0.000740
      8192      1028        0.001931
    16384      1900        0.006316
    32768      3512        0.021577
    65536      6542        0.078834
    131072     12251        0.273368
    262144     23000        0.808825

PRIME_MPI - Master process:
  Normal end of execution.

31 January 2024 06:09:03 AM

    Es werden 48 Prozesse verwendet und die Ausführung dauert etwa 1 Sekunde.

    Erkunden Sie Open MPI, indem Sie dasselbe Beispiel ausführen, aber die Datei mpihosts_slots.txt verwenden. Im Vergleich zur Standalone-Ausführung von prime_mpi sollten Sie eine Verbesserung sehen. Es wird jedoch nur 1 Prozessor auf jedem Knoten (insgesamt 3) und nicht die vollständige Ergänzung auf allen Knoten verwendet. Durch Ändern der Anzahl der Slots auf den einzelnen VM-Instanzen können Sie die Verteilung des Jobs steuern.

Danksagungen

Weitere Lernressourcen

Lernen Sie andere Übungen auf docs.oracle.com/learn kennen, oder greifen Sie auf weitere kostenlose Lerninhalte im Oracle Learning YouTube Channel zu. Außerdem können Sie education.oracle.com/learning-explorer besuchen, um Oracle Learning Explorer zu werden.

Die Produktdokumentation finden Sie im Oracle Help Center.