Speicher- und Leistungsanforderungen für StorageGRID
Änderungen vorschlagen
PDFs
Sie müssen die Speicheranforderungen für StorageGRID-Knoten verstehen, um sicherzustellen, dass Sie über genügend Speicherplatz verfügen, um die Erstkonfiguration und zukünftige Speichererweiterung zu unterstützen.
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 Node-Container, der dem Container-Engine-Speichertreiber zugewiesen wird, wenn die Container-Engine auf den Hosts installiert und konfiguriert wird, die Ihre StorageGRID Nodes unterstützen.
-
Systemdaten – Performance-Tier (10K SAS oder SSD) Speicher für die persistente Speicherung von Systemdaten und Transaktionsprotokollen pro Knoten, die von den StorageGRID Hostdiensten genutzt und einzelnen Knoten zugeordnet 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.
Für alle Speicherkategorien sind RAID-basierte Blockgeräte erforderlich. Nicht redundante Festplatten, SSDs oder JBODs werden nicht unterstützt. Gemeinsam genutzter oder lokaler RAID-Speicher kann für jede Speicherkategorie verwendet werden. Für die Migration von Knoten in StorageGRID müssen sowohl Systemdaten als auch Objektdaten auf gemeinsam genutztem Speicher abgelegt werden. Weitere Informationen finden sich 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.
|
|
In einer Implementierung in der Produktion sollte nicht mehr als ein Storage Node auf einem einzelnen physischen oder virtuellen Host betrieben werden. Ein dedizierter Host für jeden Storage Node bietet eine isolierte Ausfalldomäne. |
Sie können andere Knotentypen, wie z. B. Admin Nodes oder Gateway Nodes, auf denselben Hosts bereitstellen oder sie bei Bedarf auf eigenen dedizierten Hosts bereitstellen.
|
|
Festplatten-Snapshots können nicht zur Wiederherstellung von Grid-Knoten verwendet werden. Stattdessen sind die "Recovery von Grid Nodes" Verfahren für die jeweiligen Knotentypen zu beachten. |
Anzahl der Speichervolumes für jeden Knoten
Die folgende Tabelle zeigt die Anzahl der für jeden Host erforderlichen Speichervolumes (LUNs) und die Mindestgröße, die für jede LUN erforderlich ist, abhängig davon, welche Knoten auf diesem Host implementiert sind.
Die maximal getestete LUN Größe beträgt 100 TiB.
|
|
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 Linux softwarebasierter Storage Node und ein VMware softwarebasierter Storage Node können 1 bis 48 Speichervolumes haben. Mindestens 3 Speichervolumes werden empfohlen. |
12 TB (mindestens 4 TB/LUN) Maximal getestete LUN Größe: 100 TiB. Weitere Informationen sind unter Storage-Anforderungen für Storage-Nodes verfügbar. |
Storage-Node (nur Metadaten) |
Objekt-Metadaten |
1 |
Mindestens 4 TB/LUN Maximal getestete LUN Größe: 100 TiB. Weitere Informationen sind unter Storage-Anforderungen für Storage-Nodes verfügbar. 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 vom konfigurierten Revisionsprotokoll-Level, der Größe der Benutzereingaben wie dem S3-Objektschlüsselname und dem Umfang der zu speichernden Revisionsprotokolldaten kann es erforderlich sein, die Größe der Revisionsprotokoll LUN auf jedem Admin-Knoten zu erhöhen. Im Allgemeinen generiert ein Grid etwa 1 KB Revisionsprotokolldaten pro S3-Vorgang, was bedeutet, dass eine 200 GB LUN 70 Millionen Vorgänge pro Tag oder 800 Vorgänge pro Sekunde für zwei bis drei Tage unterstützt. |
Minimaler Speicherplatz für einen Host
Die folgende Tabelle zeigt den minimalen Speicherplatzbedarf für jeden Knotentyp. Mit dieser Tabelle lässt sich die Mindestspeicherkapazität bestimmen, die dem Host in jeder Speicherkategorie bereitgestellt werden muss, abhängig davon, welche Knoten auf diesem Host implementiert sind.
|
|
Festplatten-Snapshots können nicht zur Wiederherstellung von Grid-Knoten verwendet werden. Stattdessen sind die "Recovery von Grid Nodes" Verfahren für die jeweiligen Knotentypen zu beachten. |
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 Storage Node, einen Admin Node und einen Gateway Node. Sie sollten dem Host mindestens neun Storage Volumes bereitstellen. Es werden mindestens 300 GB Performance-Tier-Speicher für die Node-Container, 700 GB Performance-Tier-Speicher für Systemdaten und Transaktionsprotokolle sowie 12 TB Capacity-Tier-Speicher für Objektdaten benötigt.
| 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 folgende Speicheranforderungen für Storage Nodes:
-
Ein Linux-Software-basierter Storage Node kann 1 bis 48 Speichervolumes haben.
-
Ein VMware softwarebasierter Speicherknoten kann 1 bis 48 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 Grids mit reinen Metadaten-Speicherknoten muss das Grid auch eine Mindestanzahl an Knoten für die Objektspeicherung enthalten. Weitere Informationen zu reinen Metadaten-Speicherknoten sind unter "Typen von Storage-Nodes" verfügbar.
-
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.
-
Bei der Konfiguration verschiedener Storage Nodes für einen Standort sollte nach Möglichkeit dieselbe Einstellung für Volume 0 verwendet werden. Enthält ein Standort Storage Nodes unterschiedlicher Größe, bestimmt der Storage Node mit dem kleinsten Volume 0 die Metadatenkapazität dieses Standorts.
Weitere Informationen finden Sie unter "Management von Objekt-Metadaten-Storage".