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 von specter-oci.png folgt](img/specter-oci.png)
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.
- Gehen Sie zu GitHub.
- Klonen oder laden Sie das Repository auf Ihren lokalen Computer herunter.
- Befolgen Sie die Anweisungen im Dokument
README
.