Storage- und Performance-Anforderungen erfüllt
Änderungen vorschlagen
PDFs
Sie müssen die Storage-Anforderungen für StorageGRID-Nodes verstehen, damit Sie ausreichend Speicherplatz für die Erstkonfiguration und die künftige Storage-Erweiterung bereitstellen können.
Die Speicher- und Leistungsanforderungen variieren je nach Ihrer softwarebasierten Knotenimplementierung.
|
„Linux“ bezieht sich auf eine RHEL-, Ubuntu- oder Debian-Bereitstellung. Eine Liste der unterstützten Versionen finden Sie im "NetApp Interoperabilitäts-Matrix-Tool (IMT)" . |
Speicherkategorien
StorageGRID Nodes erfordern drei logische Storage-Kategorien:
-
Container Pool — Performance-Tier (10K SAS oder SSD) Speicher für die Knoten-Container, die dem Container-Engine-Speichertreiber zugewiesen wird, wenn Sie die Container-Engine auf den Hosts installieren und konfigurieren, die Ihre StorageGRID-Knoten unterstützen.
-
Systemdaten — Performance-Tier (10.000 SAS oder SSD) Speicher für persistenten Speicher pro Node von Systemdaten und Transaktionsprotokollen, die die StorageGRID Host Services nutzen und einzelnen Nodes zuordnen werden.
-
Objektdaten — Performance-Tier (10.000 SAS oder SSD) Storage und Capacity-Tier (NL-SAS/SATA) Massenspeicher für die persistente Speicherung von Objektdaten und Objekt-Metadaten.
Sie müssen RAID-gestützte Blockgeräte für alle Speicherkategorien verwenden. Nicht redundante Festplatten, SSDs oder JBODs werden nicht unterstützt. Sie können für jede der Storage-Kategorien gemeinsam genutzten oder lokalen RAID-Speicher verwenden. Wenn Sie jedoch die Funktion zur Node-Migration in StorageGRID verwenden möchten, müssen Sie sowohl System- als auch Objektdaten auf Shared Storage speichern. Weitere Informationen finden Sie unter "Anforderungen für die Container-Migration für Nodes".
Performance-Anforderungen erfüllt
Die Performance der für den Container-Pool verwendeten Volumes, Systemdaten und Objektmetadaten wirkt sich erheblich auf die Gesamt-Performance des Systems aus. Sie sollten Performance-Tier-Storage (10.000 SAS oder SSD) für diese Volumes verwenden, um eine angemessene Festplatten-Performance in Bezug auf Latenz, Input/Output Operations per Second (IOPS) und Durchsatz sicherzustellen. Sie können Capacity-Tier (NL-SAS/SATA)-Storage für den persistenten Storage von Objektdaten verwenden.
Für die Volumes, die für den Container-Pool, Systemdaten und Objektdaten verwendet werden, muss ein Write-Back-Caching aktiviert sein. Der Cache muss sich auf einem geschützten oder persistenten Medium befinden.
Anforderungen für Hosts, die NetApp ONTAP-Speicher verwenden
Wenn der StorageGRID Node Storage verwendet, der aus einem NetApp ONTAP System zugewiesen wurde, vergewissern Sie sich, dass auf dem Volume keine FabricPool-Tiering-Richtlinie aktiviert ist. Das Deaktivieren von FabricPool Tiering für Volumes, die in Verbindung mit StorageGRID Nodes verwendet werden, vereinfacht die Fehlerbehebung und Storage-Vorgänge.
|
|
Verwenden Sie FabricPool niemals, um StorageGRID-bezogene Daten in das Tiering zurück zu StorageGRID selbst zu verschieben. Das Tiering von StorageGRID-Daten zurück in die StorageGRID verbessert die Fehlerbehebung und reduziert die Komplexität von betrieblichen Abläufen. |
Anzahl der erforderlichen Hosts
Jeder StorageGRID Standort erfordert mindestens drei Storage-Nodes.
|
|
Führen Sie in einer Produktionsimplementierung nicht mehr als einen Storage Node auf einem einzelnen physischen oder virtuellen Host aus. Die Verwendung eines dedizierten Hosts für jeden Speicherknoten stellt eine isolierte Ausfalldomäne zur Verfügung. |
Andere Node-Typen wie Admin-Nodes oder Gateway-Nodes können auf denselben Hosts implementiert oder je nach Bedarf auf ihren eigenen dedizierten Hosts implementiert werden.
|
|
Disk Snapshots können nicht zur Wiederherstellung von Grid Nodes verwendet werden. Lesen Sie stattdessen die "Recovery von Grid Nodes" Verfahren für jeden Node-Typ. |
Anzahl der Speichervolumes für jeden Knoten
In der folgenden Tabelle ist die Anzahl der für jeden Host erforderlichen Storage Volumes (LUNs) und die Mindestgröße für jede LUN angegeben, basierend darauf, welche Nodes auf diesem Host implementiert werden.
Die maximale getestete LUN-Größe beträgt 39 TB.
|
|
Diese Nummern gelten für jeden Host, nicht für das gesamte Raster. |
| Zweck der LUN | Storage-Kategorie | Anzahl LUNs | Minimale Größe/LUN |
|---|---|---|---|
Storage-Pool für Container-Engine |
Container-Pool |
1 |
Gesamtzahl der Nodes × 100 GB |
|
Systemdaten |
1 für jeden Node auf diesem Host |
100GB |
Storage-Node |
Objektdaten |
3 für jeden Speicherknoten auf diesem Host Hinweis: Ein auf Linux-Software basierender Speicherknoten kann 1 bis 48 Speichervolumes haben. Ein auf VMware-Software basierender Speicherknoten kann 1 bis 16 Speichervolumes haben. Es werden mindestens 3 Speichervolumes empfohlen. |
12 TB (mindestens 4 TB/LUN) Maximale getestete LUN-Größe: 39 TB. Sehen Storage-Anforderungen für Storage-Nodes für weitere Informationen. |
Storage-Node (nur Metadaten) |
Objekt-Metadaten |
1 |
Mindestens 4 TB/LUN Maximale getestete LUN-Größe: 39 TB. Sehen Storage-Anforderungen für Storage-Nodes für weitere Informationen. Hinweis: Nur ein Rangedb ist für Metadaten-only Storage Nodes erforderlich. |
Prüfprotokolle für Admin-Node |
Systemdaten |
1 für jeden Admin-Node auf diesem Host |
200GB |
Admin-Node-Tabellen |
Systemdaten |
1 für jeden Admin-Node auf diesem Host |
200GB |
|
|
Abhängig von der konfigurierten Prüfebene, der Größe der Benutzereingaben wie dem S3-Objektschlüsselnamen und der Menge der Prüfprotokolldaten, die Sie aufbewahren müssen, müssen Sie möglicherweise die Größe der Prüfprotokoll-LUN auf jedem Admin-Knoten erhöhen. Im Allgemeinen generiert ein Grid ungefähr 1 KB Prüfdaten pro S3-Vorgang. Dies würde bedeuten, dass ein 200 GB LUN 70 Millionen Vorgänge pro Tag oder 800 Vorgänge pro Sekunde für zwei bis drei Tage unterstützen würde. |
Minimaler Speicherplatz für einen Host
In der folgenden Tabelle ist der erforderliche Mindestspeicherplatz für jeden Node-Typ aufgeführt. Anhand dieser Tabelle können Sie bestimmen, welcher Storage-Mindestbetrag für den Host in jeder Storage-Kategorie bereitgestellt werden muss. Dabei können Sie festlegen, welche Nodes auf diesem Host implementiert werden.
|
|
Disk Snapshots können nicht zur Wiederherstellung von Grid Nodes verwendet werden. Lesen Sie stattdessen die "Recovery von Grid Nodes" Verfahren für jeden Node-Typ. |
Jeder Knotenhost benötigt eine 100 GB große LUN für das Betriebssystem.
| Node-Typ | Container-Pool | Systemdaten | Objektdaten |
|---|---|---|---|
Storage-Node |
100GB |
100GB |
4.000GB |
Admin-Node |
100GB |
500 GB (3 LUNs) |
Nicht zutreffend |
Gateway-Node |
100GB |
100GB |
Nicht zutreffend |
Beispiel: Berechnen des Speicherbedarfs für einen Host oder eine virtuelle Maschine
Angenommen, Sie planen, drei Knoten auf demselben Host oder derselben virtuellen Maschine bereitzustellen: einen Speicherknoten, einen Admin-Knoten und einen Gateway-Knoten. Sie sollten dem Host mindestens neun Speichervolumes zur Verfügung stellen. Sie benötigen mindestens 300 GB Performance-Tier-Speicher für die Knotencontainer, 700 GB Performance-Tier-Speicher für Systemdaten und Transaktionsprotokolle und 12 TB Capacity-Tier-Speicher für Objektdaten.
| Node-Typ | Zweck der LUN | Anzahl LUNs | Die LUN-Größe |
|---|---|---|---|
Storage-Node |
Storage-Pool für Container-Engine |
1 |
300 GB (100 GB/Node) |
Storage-Node |
|
1 |
100GB |
Storage-Node |
Objektdaten |
3 |
12 TB (4 TB/LUN) |
Admin-Node |
|
1 |
100GB |
Admin-Node |
Prüfprotokolle für Admin-Node |
1 |
200GB |
Admin-Node |
Admin-Node-Tabellen |
1 |
200GB |
Gateway-Node |
|
1 |
100GB |
Gesamt |
9 |
Container-Pool: 300 GB Systemdaten: 700 GB Objektdaten: 12,000 GB |
| Node-Typ | Zweck der LUN | Anzahl LUNs | Die LUN-Größe |
|---|---|---|---|
Storage-Node |
Betriebssystem-Volume |
1 |
100GB |
Storage-Node |
Objektdaten |
3 |
12 TB (4 TB/LUN) |
Admin-Node |
Betriebssystem-Volume |
1 |
100GB |
Admin-Node |
Prüfprotokolle für Admin-Node |
1 |
200GB |
Admin-Node |
Admin-Node-Tabellen |
1 |
200GB |
Gateway-Node |
Betriebssystem-Volume |
1 |
100GB |
Gesamt |
8 |
Systemdaten: 700 GB Objektdaten: 12,000 GB |
Spezifische Speicheranforderungen für Speicherknoten
Linux und VMware haben unterschiedliche Speicheranforderungen für Speicherknoten:
-
Ein Linux-Software-basierter Speicherknoten kann 1 bis 48 Speichervolumes haben
-
Ein VMware-Software-basierter Storage Node kann 1 bis 16 Speichervolumes haben
-
Es werden drei oder mehr Speichervolumes empfohlen.
-
Jedes Speichervolumen sollte mindestens 4 TB groß sein.
|
|
Ein Appliance-Speicherknoten kann außerdem über bis zu 48 Speichervolumes verfügen. |
Wie in der Abbildung dargestellt, reserviert StorageGRID Speicherplatz für Objekt-Metadaten auf dem Storage Volume 0 jedes Storage-Nodes. Alle verbleibenden Speicherplatz auf dem Storage-Volume 0 und anderen Storage-Volumes im Storage-Node werden ausschließlich für Objektdaten verwendet.
Um Redundanz zu gewährleisten und Objekt-Metadaten vor Verlust zu schützen, speichert StorageGRID drei Kopien der Metadaten für alle Objekte im System an jedem Standort. Die drei Kopien der Objektmetadaten werden gleichmäßig auf alle Storage-Nodes an jedem Standort verteilt.
Bei der Installation eines Grid mit metadatenreinen Storage-Nodes muss das Grid auch eine Mindestanzahl an Nodes für Objekt-Storage enthalten. Weitere Informationen zu nur Metadaten-Storage-Nodes finden Sie unter"Typen von Storage-Nodes".
-
Für ein Grid an einem Standort werden mindestens zwei Storage-Nodes für Objekte und Metadaten konfiguriert.
-
Bei einem Grid mit mehreren Standorten werden mindestens ein Storage Node pro Standort für Objekte und Metadaten konfiguriert.
Wenn Sie Volume 0 eines neuen Storage-Node Speicherplatz zuweisen, müssen Sie sicherstellen, dass für den Anteil aller Objekt-Metadaten des Node ausreichend Speicherplatz vorhanden ist.
-
Mindestens müssen Sie Volume 0 mindestens 4 TB zuweisen.
Wenn Sie nur ein Storage-Volume für einen Storage-Node verwenden und dem Volume maximal 4 TB zuweisen, kann der Storage-Node beim Starten und Speichern von Objektmetadaten in den schreibgeschützten Storage-Status wechseln.
Wenn Sie Volume 0 weniger als 500 GB zuweisen (nur für den nicht-produktiven Einsatz), sind 10 % der Kapazität des Speicher-Volumes für Metadaten reserviert. -
Die Node-Ressourcen, die nur auf Softwarebasierten Metadaten basieren, müssen mit den vorhandenen Storage-Nodes-Ressourcen übereinstimmen. Beispiel:
-
Wenn der bestehende StorageGRID Standort SG6000 oder SG6100 Appliances verwendet, müssen die rein softwarebasierten Nodes mit Metadaten die folgenden Mindestanforderungen erfüllen:
-
128 GB RAM
-
8-Core-CPU
-
8 TB SSD oder äquivalenter Storage für die Cassandra-Datenbank (rangedb/0)
-
-
Wenn die vorhandene StorageGRID Site virtuelle Speicherknoten mit 24 GB RAM, 8-Kern-CPU und 3 TB oder 4 TB Metadatenspeicher verwendet, sollten die softwarebasierten Nur-Metadaten-Knoten ähnliche Ressourcen verwenden (24 GB RAM, 8-Kern-CPU und 4 TB Metadatenspeicher (rangedb/0)).
Beim Hinzufügen eines neuen StorageGRID Standorts sollte die Metadaten-Gesamtkapazität des neuen Standorts mindestens den vorhandenen StorageGRID Standorten entsprechen, und neue Standortressourcen sollten den Storage-Nodes an den vorhandenen StorageGRID Standorten entsprechen.
-
-
Wenn Sie ein neues System installieren (StorageGRID 11.6 oder höher) und jeder Speicherknoten mindestens 128 GB RAM hat, weisen Sie Volume 0 mindestens 8 TB zu. Bei Verwendung eines größeren Werts für Volume 0 kann der zulässige Speicherplatz für Metadaten auf jedem Storage Node erhöht werden.
-
Verwenden Sie bei der Konfiguration verschiedener Storage-Nodes für einen Standort, falls möglich, die gleiche Einstellung für Volume 0. Wenn ein Standort Storage-Nodes unterschiedlicher Größe enthält, bestimmt der Storage-Node mit dem kleinsten Volume 0 die Metadaten-Kapazität dieses Standorts.
Weitere Informationen finden Sie unter "Management von Objekt-Metadaten-Storage".