Skip to main content
BeeGFS on NetApp with E-Series Storage
Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

Besprechen der Best Practices

Beitragende
PDFs

Beachten Sie bei der Implementierung der BeeGFS auf NetApp-Lösung die Best Practice-Richtlinien.

Standardkonventionen

Folgen Sie beim physischen Zusammenbau und Erstellen der Ansible-Bestandsdatei diesen Standardkonventionen (weitere Informationen finden Sie unter "Erstellen des Ansible-Inventars").

  • Host-Namen der Dateiknoten werden nacheinander nummeriert (h01-HN) mit niedrigeren Zahlen oben im Rack und höheren Zahlen unten.

    Die Namenskonvention sieht beispielsweise [location][row][rack]hN wie folgt aus: beegfs_01.

  • Jeder Block-Node besteht aus zwei Storage-Controllern, die jeweils über einen eigenen Host-Namen verfügen.

    Mit einem Storage-Array-Namen wird im Rahmen eines Ansible-Inventars das gesamte Block-Storage-System bezeichnet. Die Namen des Speicher-Arrays sollten nacheinander nummeriert sein (a01 - an), und die Hostnamen für einzelne Controller werden aus dieser Namenskonvention abgeleitet.

    Beispielsweise kann bei einem Block-Node mit dem Namen ictad22a01 normalerweise Hostnamen für jeden Controller wie und konfiguriert ictad22a01-a ictad22a01-b`sein, in einem Ansible-Inventar jedoch als bezeichnet werden `netapp_01.

  • File- und Block-Nodes innerhalb desselben Bausteins teilen sich das gleiche Nummerierungsschema und sind im Rack nebeneinander, wobei beide Datei-Nodes oben und beide Block-Nodes direkt darunter liegen.

    Im ersten Baustein sind beispielsweise die Datei-Nodes h01 und h02 direkt mit den Block-Nodes a01 und a02 verbunden. Von oben nach unten sind die Hostnamen h01, h02, a01 und a02.

  • Bausteine werden in sequenzieller Reihenfolge auf der Grundlage ihrer Hostnamen installiert, sodass sich die niedrigeren Host-Namen oben im Rack befinden und die höheren nummerierten Host-Namen sich unten befinden.

    Ziel ist es, die Länge des Kabels zu minimieren, das oben auf den Rack Switches läuft, und eine standardisierte Implementierungspraxis zu definieren, um die Fehlerbehebung zu vereinfachen. Für Rechenzentren, in denen dies nicht erlaubt ist, aufgrund von Bedenken um die Rack-Stabilität, ist die umgekehrte sicherlich erlaubt, das Befüllen des Racks von unten nach oben.

InfiniBand-Storage-Netzwerkkonfiguration

Die Hälfte der InfiniBand-Ports an jedem Datei-Node werden für eine direkte Verbindung mit Block-Nodes verwendet. Die andere Hälfte ist mit den InfiniBand-Switches verbunden und wird für die BeeGFS-Client-Server-Konnektivität verwendet. Beim Bestimmen der Größe der IPoIB-Subnetze, die für BeeGFS-Clients und -Server verwendet werden, müssen Sie das erwartete Wachstum Ihres Compute/GPU-Clusters und BeeGFS-Dateisystems berücksichtigen. Wenn Sie von den empfohlenen IP-Bereichen abweichen müssen, beachten Sie, dass jede direkte Verbindung in einem einzelnen Baustein ein eigenes Subnetz hat und es keine Überschneidung mit Subnetzen gibt, die für die Client-Server-Konnektivität verwendet werden.

Direkte Verbindungen

Datei- und Block-Nodes innerhalb jedes Bausteins verwenden für ihre direkten Verbindungen immer die IPs in der folgenden Tabelle.

Hinweis Dieses Adressprogramm entspricht der folgenden Regel: Das dritte Oktett ist immer ungerade oder gerade, was davon abhängt, ob der Datei-Node ungerade oder gerade ist.
Datei-Node IB-Port IP-Adresse Block-Node IB-Port Physische IP-Adresse Virtuelle IP

ODD (h1)

i1a

192.168.1.10

Ungerade (c1)

2 a

192.168.1.100

192.168.1.101

ODD (h1)

i2a

192.168.3.10

Ungerade (c1)

2 a

192.168.3.100

192.168.3.101

ODD (h1)

i3a

192.168.5.10

Gleichmäßig (c2)

2 a

192.168.5.100

192.168.5.101

ODD (h1)

I4a

192.168.7.10

Gleichmäßig (c2)

2 a

192.168.7.100

192.168.7.101

Gleichmäßig (h2)

i1a

192.168.2.10

Ungerade (c1)

2b

192.168.2.100

192.168.2.101

Gleichmäßig (h2)

i2a

192.168.4.10

Ungerade (c1)

2b

192.168.4.100

192.168.4.101

Gleichmäßig (h2)

i3a

192.168.6.10

Gleichmäßig (c2)

2b

192.168.6.100

192.168.6.101

Gleichmäßig (h2)

I4a

192.168.8.10

Gleichmäßig (c2)

2b

192.168.8.100

192.168.8.101

IPoIB-Adressierungsschemata für BeeGFS-Client-Server

Auf jedem Datei-Node werden mehrere BeeGFS-Serverservices ausgeführt (Management, Metadaten oder Storage). Damit jeder Service unabhängig vom anderen Datei-Node ein Failover durchführen kann, verfügt jeder über eindeutige IP-Adressen, die zwischen beiden Nodes schweben können (auch als logische Schnittstelle oder LIF bezeichnet).

Diese Bereitstellung setzt zwar nicht zwingend voraus, dass für diese Verbindungen folgende IPoIB-Subnetzbereiche verwendet werden und definiert ein Standard-Adressierungsschema, das folgende Regeln anwendet:

  • Das zweite Oktett ist immer ungerade oder sogar, basierend darauf, ob der InfiniBand-Port des Datei-Nodes ungerade oder sogar ungerade ist.

  • BeeGFS Cluster-IPs sind immer xxx. 127.100.yyy Oder xxx.128.100.yyy.

Hinweis Zusätzlich zur Schnittstelle, die für die bandinterne Betriebssystemverwaltung verwendet wird, können zusätzliche Schnittstellen von Corosync für Cluster Heart-Schläge und Synchronisation verwendet werden. So wird sichergestellt, dass der Verlust einer einzelnen Schnittstelle das gesamte Cluster nicht in den Fall bringt.

  • Der BeeGFS Management Service ist immer im Betrieb xxx.yyy.101.0 Oder xxx.yyy.102.0.

  • BeeGFS Metadatendienste sind immer dabei xxx.yyy.101.zzz Oder xxx.yyy.102.zzz.

  • BeeGFS Storage-Services finden sich immer bei xxx.yyy.103.zzz oder xxx.yyy.104.zzz.

  • Adressen im Bereich 100.xxx.1.1 Bis 100.xxx.99.255 Sind für Kunden reserviert.

IPoIB-Adressierungsschema für ein einzelnes Subnetz

In diesem Bereitstellungshandbuch wird ein einziges Subnetz-Schema verwendet, da die in aufgeführten Vorteile im aufgeführt "Softwarearchitektur"sind.

Subnetz: 100.127.0.0/16

Die folgende Tabelle enthält den Bereich für ein einzelnes Subnetz: 100.127.0.0/16.

Zweck InfiniBand-Port IP-Adresse oder Bereich

BeeGFS Cluster-IP

i1b oder i4b

100.127.100.1 - 100.127.100.255

BeeGFS Management

i1b

100.127.101.0

i2b

100.127.102.0

BeeGFS-Metadaten

i1b oder i3b

100.127.101.1 - 100.127.101.255

i2b oder i4b

100.127.102.1 - 100.127.102.255

BeeGFS-Speicherung

i1b oder i3b

100.127.103.1 - 100.127.103.255

i2b oder i4b

100.127.104.1 - 100.127.104.255

BeeGFS-Clients

(Je nach Kunde)

100.127.1.1 - 100.127.99.255

IPoIB zwei Subnetz-Adressierungsschema

Ein zwei-Subnetz-Adressierungsschema wird nicht mehr empfohlen, kann aber trotzdem implementiert werden. In den folgenden Tabellen finden Sie ein empfohlenes zwei-Subnetz-Schema.

Subnetz A: 100.127.0.0/16

In der folgenden Tabelle ist der Bereich für Subnetz A angegeben: 100.127.0.0/16.

Zweck InfiniBand-Port IP-Adresse oder Bereich

BeeGFS Cluster-IP

i1b

100.127.100.1 - 100.127.100.255

BeeGFS Management

i1b

100.127.101.0

BeeGFS-Metadaten

i1b oder i3b

100.127.101.1 - 100.127.101.255

BeeGFS-Speicherung

i1b oder i3b

100.127.103.1 - 100.127.103.255

BeeGFS-Clients

(Je nach Kunde)

100.127.1.1 - 100.127.99.255
Subnetz B: 100.128.0.0/16

In der folgenden Tabelle ist der Bereich für Subnetz B angegeben: 100.128.0.0/16.

Zweck InfiniBand-Port IP-Adresse oder Bereich

BeeGFS Cluster-IP

I4b

100.128.100.1 - 100.128.100.255

BeeGFS Management

i2b

100.128.102.0

BeeGFS-Metadaten

i2b oder i4b

100.128.102.1 - 100.128.102.255

BeeGFS-Speicherung

i2b oder i4b

100.128.104.1 - 100.128.104.255

BeeGFS-Clients

(Je nach Kunde)

100.128.1.1 - 100.128.99.255
Hinweis In dieser NetApp Verified Architecture werden nicht alle IPs in den oben genannten Bereichen verwendet. Sie zeigen, wie IP-Adressen vorzugewiesen werden können, um eine einfache Erweiterung des Dateisystems mit einem konsistenten IP-Adressierungschema zu ermöglichen. In diesem Schema entsprechen BeeGFS-Datei-Knoten und Service-IDs dem vierten Oktett eines bekannten IP-Bereichs. Das Filesystem konnte bei Bedarf auf jeden Fall über 255 Nodes oder Services skaliert werden.