Hochleistungs-Speichercluster mit IBM-Spectrumskala bereitstellen

IBM Spectrum Scale ist ein Cluster-Dateisystem, das gleichzeitigen Zugriff auf ein oder mehrere Dateisysteme von mehreren Knoten ermöglicht. Die Knoten können SAN-angehängt, netzgebunden, eine Mischung aus SAN-angehängten und netzgebundenen Knoten oder in einer gemeinsam genutzten Clusterkonfiguration sein. Spectrum Scale ermöglicht einen leistungsstarken Zugriff auf einen gemeinsamen Datensatz, um eine Scale-out-Lösung zu unterstützen oder eine hochverfügbare Plattform bereitzustellen.

Architektur

Ein Anwendungsfall für Spectrum Scale ist die Bereitstellung von SAS-Grid-Anwendungen, die ein robustes I/O-Subsystem benötigen. In dieser Referenzarchitektur wird das Deployment einer High I/O-Durchsatzlösung mit einem IBM Spectrum-Dateisystem in Oracle Cloud Infrastructure erörtert.

Diese Referenzarchitektur verwendet eine Region mit einer Availability-Domain und regionalen Subnetzen. Sie können dieselbe Referenzarchitektur in einer Region mit mehreren Availability-Domains verwenden. Wir empfehlen Ihnen, regionale Subnetze für Ihr Deployment zu verwenden, unabhängig von der Anzahl der Verfügbarkeitsdomains.

Das folgende Diagramm veranschaulicht diese Referenzarchitektur.

Beschreibung von specter-oci.png folgt
Beschreibung der Abbildung specter-oci.png

Die Spectrum Scale-Dateisystemarchitektur verfügt über folgende Komponenten:

  • CES-Knoten

    Cluster Export Services (CES)-Knoten können integrierte Protokollfunktionen bedienen. Diese Knoten bieten SMB-, NFS- oder Objektzugriff auf Daten im IBM Spectrum Scale Dateisystem. Dieser Knoten ist optional. Für einen höheren Durchsatz empfehlen wir die Verwendung einer VM.Standard2.8 - oder höheren Form (mindestens zwei VNICs).

  • MGMT GUI-Knoten

    Dieser Knoten bietet eine GUI-Schnittstelle für Benutzer, um ihr Spectrum Scale-Dateisystem zu überwachen. Dieser Knoten ist optional. Wir empfehlen, eine VM.Standard2.16 - oder höhere Form zu verwenden, um ausreichend OCPU und Speicher bereitzustellen.

  • Clientknoten

    Diese Knoten verwenden das Spectrum Scale-Dateisystem. Sie werden von den Network Shared Disk (NSD)-Servern bereitgestellt.

  • NSD-Server

    Diese Server verwenden das NSD-Protokoll, um Clientknoten in einem Client-Serverprotokollmodell Daten zu dienen. NSD-Server bieten Zugriff auf Speicher, der auf Servern als lokale Blockgeräte sichtbar ist.

  • Objektspeicher

    Oracle Cloud Infrastructure Object Storage ist ein dauerhafter und skalierbarer internetbasierter Speicherservice.

  • Virtuelles Cloud-Netzwerk (VCN) und Subnetze

    Ein VCN ist ein softwaredefiniertes Netzwerk, das Sie in einer Oracle Cloud Infrastructure-Region eingerichtet haben. VCNs können in Subnetze segmentiert werden, die für eine Region oder eine Availability-Domain spezifisch sein können. Sowohl regionsspezifische als auch verfügbarkeitsdomainspezifische Subnetze können in demselben VCN nebeneinander bestehen. Ein Subnetz kann öffentlich oder privat sein.

  • Sicherheitslisten

    Für jedes Subnetz können Sie Sicherheitsregeln erstellen, die die Quelle, das Ziel und den Traffictyp angeben, die im Subnetz und außerhalb des Subnetzes zulässig sein müssen.

  • Availability-Domains

    Availability-Domains sind eigenständige, unabhängige Rechenzentren innerhalb einer Region. Die physischen Ressourcen in jeder Availability-Domain werden von den Ressourcen in den anderen Availability-Domains isoliert, was eine Fehlertoleranz bietet. Availability-Domains teilen keine Infrastruktur wie Strom oder Kühlung oder das interne Availability-Domainnetzwerk. Ein Fehler bei einer Availability-Domain wirkt sich daher unwahrscheinlich auf die anderen Availability-Domains in der Region aus.

Empfehlungen

Ihre Anforderungen können von der hier beschriebenen Architektur abweichen. Verwenden Sie die folgenden Empfehlungen als Ausgangspunkt.

  • Compute Form, Bastion Host

    Ein Bastion-Host wird verwendet, um auf Knoten im privaten Subnetz zuzugreifen. Verwenden Sie die VM.Standard.E2.1 - oder VM.Standard.E2.2-Form.

  • Compute-Ausprägung, CES-Knoten

    Verwenden Sie eine VM.Standard2.8 - oder höhere Form (mindestens zwei VNICs) für einen höheren Durchsatz.

  • Compute-Ausprägung, MGMT-GUI-Knoten

    Verwenden Sie eine VM.Standard2.16 - oder höhere Form, um ausreichend OCPU und Speicher bereitzustellen.

  • Compute-Ausprägung, Clientknoten

    Der Benutzer kann mehrere Clientknoten haben. Beginnen Sie mit einer VM.Standard2.24-Form, und skalieren Sie bei Bedarf nach oben oder unten.

  • Compute-Ausprägung, NSD-Server

    NSD-Server benötigen hohe Durchsatz- und Verarbeitungsleistung. Verwenden Sie eine Form von BM.Standard2.52 oder BM.Standard.E2.64. Verwenden Sie außerdem mindestens zwei NSD-Serverknoten.

  • VCN

    Legen Sie beim Erstellen des VCN fest, wie viele IP-Adressen Ihre Cloud-Ressourcen in jedem Subnetz benötigen. Geben Sie mit der Notation Classless Inter-Domain Routing (CIDR) eine Subnetzmaske und einen Netzwerkadressbereich an, der für die erforderlichen IP-Adressen groß genug ist. Verwenden Sie einen Adressbereich, der sich im standardmäßigen privaten IP-Adressraum befindet.

    Wählen Sie einen Adressbereich, der sich nicht mit Ihrem On-Premise-Netzwerk überschneidet, damit Sie gegebenenfalls eine Verbindung zwischen VCN und Ihrem On-Premise-Netzwerk herstellen können.

    Nachdem Sie ein VCN erstellt haben, können Sie den Adressbereich nicht ändern.

    Wenn Sie die Subnetze entwerfen, berücksichtigen Sie Ihre Verkehrsfluss- und Sicherheitsanforderungen. Ordnen Sie alle Ressourcen innerhalb einer bestimmten Ebene oder Rolle an dasselbe Subnetz zu, das als Sicherheitsgrenze dienen kann.

    Verwenden Sie regionale Subnetze.

  • Sicherheitslisten

    Verwenden Sie Sicherheitslisten, um Ingress- und Egressregeln zu definieren, die für das gesamte Subnetz gelten. Beispiel: Diese Architektur ermöglicht ICMP intern für das gesamte private Subnetz.

Überlegungen

  • Performance

    Um die beste Leistung zu erzielen, wählen Sie die richtige Compute Form mit der entsprechenden Bandbreite.

  • Verfügbarkeit

    Verwenden Sie eine High Availability-Option basierend auf Ihrer Deployment-Anforderung.

  • Kostenfaktor

    Bare-Metal-Instanzen bieten eine höhere Performance bei I/O-Vorgängen für höhere Kosten. Bewerten Sie Ihre Anforderungen, um die entsprechende Compute Form auszuwählen.

  • Überwachung und Warnungen

    Richten Sie Überwachung und Alerts für die CPU- und Speichernutzung für Ihre Knoten ein, um die Form bei Bedarf nach oben oder unten zu skalieren.

Bereitstellen

Der Terraform-Code zum Bereitstellen dieser Referenzarchitektur ist auf GitHub verfügbar.

  1. Gehen Sie zu GitHub.
  2. Klonen oder laden Sie das Repository auf Ihren lokalen Computer herunter.
  3. Befolgen Sie die Anweisungen im Dokument README.