Letzten Monat kündigte NetApp mit dem EF600 sein neuestes Midrange-All-Flash-Array an. Während der EF600 auf denselben Markt ausgerichtet ist wie der EF570, es ist kein Ersatz. Während der EF570 NVMe unterstützt, ist der EF600 End-to-End-NVMe, was ein neues Maß an Flexibilität und Leistung bietet, das es in der Mittelklasse bisher nicht gab. Abgesehen von der Leistung und dem Preis-Leistungs-Verhältnis bietet der EF600 ein Maß an Zukunftssicherheit, das den Anforderungen von morgen gerecht wird, ohne dass umfangreiche Upgrades erforderlich sind.
Letzten Monat kündigte NetApp mit dem EF600 sein neuestes Midrange-All-Flash-Array an. Während der EF600 auf denselben Markt ausgerichtet ist wie der EF570, es ist kein Ersatz. Während der EF570 NVMe unterstützt, ist der EF600 End-to-End-NVMe, was ein neues Maß an Flexibilität und Leistung bietet, das es in der Mittelklasse bisher nicht gab. Abgesehen von der Leistung und dem Preis-Leistungs-Verhältnis bietet der EF600 ein Maß an Zukunftssicherheit, das den Anforderungen von morgen gerecht wird, ohne dass umfangreiche Upgrades erforderlich sind.
Was die Leistung angeht: Der EF600 behauptet 2 Millionen IOPS, bis zu 44 GB/s Bandbreite und eine Latenz von unter 100 μs bei bestimmten Arbeitslasten. Dieses Leistungsniveau öffnet das Array für neue leistungsempfindliche Workloads wie Oracle-Datenbanken, Echtzeitanalysen sowie hochleistungsfähige parallele FS wie BeeGFS und Spectrum Scale. Das Leistungsprofil leitet sich weitgehend von der End-to-End-NVMe-Implementierung des EF600 ab. Dadurch kann das Array auch 100 Gbit NVMe über InfiniBand, 100 Gbit NVMe über RoCE und 32 Gbit NVMe über FC unterstützen, was in Zukunft wichtiger sein wird. Darüber hinaus kann der EF600 bis zu 367 TB Kapazität in seinem 2U-Formfaktor unterbringen
Der EF600 basiert auf fünf Generationen NetApp-Hardware, die sich als zuverlässig erwiesen hat. Unter dem Gesichtspunkt der Verfügbarkeit bietet der EF600 sechs 9er und automatisiertes Failover mit erweiterter Überwachung. Das Array kann ein Problem erkennen, bevor ein Laufwerk ausfällt. Im Falle eines Ausfalls kann die Dynamic Disk Pool-Technologie des Arrays schnellere Laufwerkswiederherstellungen durchführen als mit RAID5 oder RAID6. Durch SANtricity (das für Flash optimiert ist) kann der EF600 mehrere Datenschutzoptionen wie dynamische Kapazität, dynamische Migration der Segmentgröße, dynamische RAID-Level-Migration bereitstellen und verfügt über unterbrechungsfreie Firmware-Updates.
NetApp AFA EF600-Spezifikationen
| Formfaktor | 2U |
| Systemspeicher | Bis zu 128GB |
| Lagerung | |
| Maximale Rohkapazität | 360TB |
| Maximale Laufwerke | 24 |
| Unterstützte Laufwerkstypen | SSD 1.9 TB, 3.8 TB, 7.6 TB 3.8 TB FIPS 1.9 TB, 3.8 TB, 7.6 TB, 15.3 TB FDE |
| Host-E/A-Ports | Optionale zusätzliche E/A-Ports: 16 Ports 32 GB FC 16 Ports 32 GB NVMe über FC 8 Ports 100 GB NVMe über InfiniBand 8 Ports 100 GB NVMe über RoCE-Ethernet |
| Systemmanagement | SANtricity System Manager 11.60 (webbasiert, On-Box) |
| Kennzahlen | |
| IOPS | 2 Millionen |
| Durchschnittliche Latenz | <100 μs bis zu 200,000 4K-Zufallsschreib-IOPS <100 μs bis zu 150,000 4K-Zufallslese-IOPS <250 μs bis zu 2,000,000 4K-Zufallslese-IOPS |
| Anhaltender Durchsatz | Bis zu 44 GB/s |
| Physik | |
| Abmessungen HxBxT | 3.43 x 9.02 x 17.6 in (8.7 x 48.3 x 44.7 cm) |
| Gewicht | 53.66lb (24.34kg) |
| kVA | Typisch: 0.979 Maximum: 1.128 |
| Watts | Typisch: 979.09 Maximum: 1,128 |
| BTU | Typisch: 3348 Maximum: 3,859.128 |
NetApp AFA EF600 Build und Design
Das NetApp AFA EF600 ist ein 2U-Array, das das Standard-Erscheinungsbild aller anderen NetApp-Arrays aufweist: die gleiche elegante Blende mit NetApp-Branding. Unter der Blende befinden sich die 24 Laufwerksschächte, die vertikal über die Vorderseite des Arrays verlaufen. Wie bereits erwähnt, ist NetApp auf einen leuchtend blauen Laufwerksschacht umgestiegen, der besser zu seinem Branding passt. Der Netzschalter und die LED-Anzeigen befinden sich auf der linken Seite des Geräts.
Wenn wir uns zur Rückseite des Geräts bewegen, sehen wir das Spiegelbild der übereinander liegenden Controller. Von links nach rechts sind das Netzteil, ein RJ45-Port, ein USB 3.0-Port, ein Management-Port und zwei Netzwerk-Ports zu sehen, wobei die obere rechte Seite in diesem Fall mit FC-Anschlüssen für NVMe über FC belegt ist.
NetApp AFA EF600-Management
Das neue EF600 unterstützt die NetApp SANtricity OS 11.XX-Softwarepakete, die die Controller-Firmware, die IOM-Firmware und den SANtricity System Manager für den Betrieb der Speicherarrays der E-Serie und EF-Serie umfassen. SANtricity System Manager unterstützt Sie bei der Vereinfachung des Verwaltungsworkflows. Die GUI sieht frisch aus und fühlt sich auch so an, mit einer einfachen On-Box-Weboberfläche und einfacher Terminologie.
Wenn Sie sich beim System Manager anmelden, wird als erster Bildschirm die Registerkarte „Startseite“ angezeigt. Hier sehen Sie das Dashboard im Hauptteil der GUI. Unabhängig davon, auf welcher Registerkarte Sie sich befinden, werden in der oberen rechten Ecke der GUI immer die verfügbaren allgemeinen Optionen angezeigt. einschließlich Einstellungen, Hilfe, Abmelden und auch der aktuell angemeldete Benutzer. Und im linken Bereich werden die primären Systemregisterkarten angezeigt: Startseite, Speicher, Hardware, Einstellungen und Support.
Im Dashboard können Sie einen Blick auf kritische Bereiche werfen und den Zustand und die Gesundheit des Speicher-Arrays zusammenfassen. Oben zeigt Ihnen der Benachrichtigungsbereich den Systemstatus und die Komponenten an; Im Leistungsbereich werden wichtige Kennzahlen angezeigt, darunter IOPS, MiB/S und CPU. Im Kapazitätsbereich können Sie die zugewiesene Systemkapazität sehen. und der Speicherhierarchiebereich bietet Ihnen eine organisierte Ansicht der verschiedenen Hardwarekomponenten und Speicherobjekte, die vom Speicherarray verwaltet werden.
Wenn Sie zur Registerkarte „Speicher“ wechseln, gelangen Sie zu den Hauptsystemkategorien, in denen die Konfiguration von Pools und Volumes, Gruppen, Volumes, Hosts, Leistung und Snapshots angezeigt wird. Einige davon werden in den folgenden Abschnitten detailliert beschrieben.
Auf der Seite „Pools und Volume-Gruppen“ werden die Pools und Volume-Gruppen angezeigt, die im System erstellt wurden. ermöglicht das Bearbeiten bestehender oder das Erstellen neuer Laufwerke aus nicht zugewiesenen Laufwerken. Auf dieser Seite werden auch die Gesamtkapazität, die genutzte Kapazität, die Anzahl der Laufwerke, die RAID-Konfiguration und andere Statistiken dieser Pools oder Volume-Gruppen angezeigt.
Auf der Seite „Volumes“ werden die konfigurierten Volumes angezeigt. Für jedes Volume werden auf der Seite der Status, die zugewiesenen Hosts, der Pool oder die Volume-Gruppe, zu der sie gehören, die gemeldete Kapazität, die zugewiesene Kapazität und andere Informationen angezeigt. In diesem Bereich können Sie auch Volumes erstellen oder bearbeiten oder Workloads pro Anwendung definieren.
Die Seite „Leistung“ bietet mehrere Möglichkeiten, die Leistung des Speicher-Arrays zu überwachen. Auf der Registerkarte „Logische Ansicht“ können Sie die Komponenten definieren, die Sie überwachen möchten, einschließlich des gesamten Systems, des Pools, der Volume-Gruppe oder eines einzelnen Volumes. Sie können auch andere wichtige Bereiche des Speicherarrays mithilfe der physischen und Anwendungs- und Arbeitslastansicht überwachen. Auf die Seite „Leistung“ kann auch über die Startseite zugegriffen werden, indem Sie auf „Leistungsdetails anzeigen“ klicken.
Auf der nächsten Registerkarte, der Hardware-Registerkarte, können Sie die physischen Regale, Controller und Laufwerke verwalten, die im Speicher-Array installiert sind. Auf dieser Seite werden die Treiber angezeigt, die sich irgendwo im Speicherarray befinden. Sie können diese Ansicht auch ändern, um Treiber pro Pool oder Volume-Gruppe anzuzeigen.
Durch Klicken auf das Controller-Symbol unter dem Controller-Regalbereich können Sie die Einstellungen für Controller A oder Controller B auswählen und anzeigen. Von diesem Fenster aus können Sie zu den verschiedenen Registerkarten „Basis“, „Cache“, „Hostschnittstellen“, „Laufwerkschnittstellen“, „Verwaltungsports“ und „DNS/NTP“ wechseln, um detaillierte Informationen zum Controller anzuzeigen.
Durch Klicken auf eines der anderen Symbole, ebenfalls unter dem Controller-Shelf-Bereich, wird das Fenster „Shelf-Komponenteneinstellungen“ geöffnet. Dieser Bereich eignet sich hervorragend zur Überwachung des Status und der Einstellungen der Regalkomponenten, einschließlich Informationen zu Netzteilen, Lüftern, Temperatur, Batterien und SFPs.
Auf der Registerkarte „Einstellungen“ können Sie Benachrichtigungen konfigurieren, um Sie zu benachrichtigen, wenn ein Problem mit dem Speicher-Array vorliegt. In diesem Bereich können Sie auch Systemeinstellungen wie den Namen des Speicher-Arrays ändern, Benutzer authentifizieren, Zertifikate importieren und andere systemweite Funktionen ausführen.
In der Zugriffsverwaltung können Sie die Benutzerauthentifizierung im System einrichten. In diesem Bereich können Sie Passwörter und lokale Benutzer verwalten, Berechtigungen konfigurieren, Verzeichnisserver hinzufügen und andere Zugriffsverwaltungskonfigurationen vornehmen. Zu den Authentifizierungsmethoden gehören RBAC (rollenbasierte Zugriffskontrolle), Verzeichnisdienste und Security Assertion Markup Language (SAML) 2.0.
Auf der letzten Registerkarte, der Support-Registerkarte, können Sie Diagnosen durchführen und wichtige Informationen sammeln, die möglicherweise vom technischen Support angefordert werden. wenn Sie Probleme mit dem Speicherarray haben. Hier können Sie das Ereignisprotokoll verwenden, um historische Aufzeichnungen des Speicher-Arrays anzuzeigen. führen auch Systemaktualisierungen durch.
Wenn Sie im Support-Center-Bereich nach unten scrollen, können Sie sich die wichtigsten Speicher-Array-Eigenschaften ansehen, z. B. die weltweite Kennung des Speicher-Arrays, die Seriennummer des Gehäuses, die Anzahl der Einschübe, die Anzahl der Laufwerke, den Laufwerkstyp, die Anzahl der Controller, die Controller-Firmware-Version usw. Systemverwaltungsversion und andere Systeminformationen.
NetApp AFA EF600-Konfiguration
Der NetApp EF600 wurde mit 24 NVMe-SSDs geliefert, allesamt 1.92-TB-Modelle von Samsung. Speziell für die Speicherung haben wir RAID10 genutzt, das häufig von Kunden verwendet wird, die dieses Speicherarray kaufen. Mit 24 Laufwerken und einem Zwei-Controller-Layout haben wir sie in zwei Volumengruppen zu je zwölf Laufwerken aufgeteilt. Von diesen beiden Volume-Gruppen haben wir jedem Host jeweils ein Volume zugewiesen (zwei Volumes pro Host, verteilt auf beide Controller), mit einer Größe von 100 GB. Bei 12 Rechenhosts ergab dies eine Gesamtgröße des Arbeitsdatensatzes von 24 x 100 GB oder 2.4 TB.
Für die Back-End-Konnektivität unterstützt der EF600 derzeit nur NVMeoF, FCP-Unterstützung kommt in Kürze. Das System wurde mit allen 32-Gb-FC-Optiken geliefert und für diesen Test haben wir unsere 12 Hosts auf die neuesten Emulex 32-Gb-Dual-Port-HBAs aktualisiert. Während wir traditionell AFAs in VMware getestet haben, haben wir zum Benchmarken der NVMeoF-Leistung eine Bare-Metal-Installation von SLES 12 SP4 auf jedem Host ausgeführt. Wir haben alle 16 32-Gb-Ports (acht pro Controller) genutzt, die an unsere Dual-Switch-FC-Fabric mit Brocade G620-Switches angeschlossen sind. Insgesamt ermöglichte dies eine theoretische Bandbreite von 512 GB vom Speicherarray (64 GB/s), wobei unser 12-Host-Cluster mit zwei Ports 768 GB oder 96 GB/s in der Spitze unterstützt.
VDBench-Workload-Analyse
Wenn es um das Benchmarking von Speicher-Arrays geht, sind Anwendungstests am besten und synthetische Tests stehen an zweiter Stelle. Obwohl sie keine perfekte Darstellung der tatsächlichen Arbeitslasten darstellen, helfen synthetische Tests dabei, Speichergeräte mit einem Wiederholbarkeitsfaktor zu vergleichen, der es einfach macht, Konkurrenzlösungen direkt miteinander zu vergleichen. Diese Workloads bieten eine Reihe unterschiedlicher Testprofile, die von „Vier-Ecken“-Tests über allgemeine Tests der Datenbankübertragungsgröße bis hin zu Trace-Erfassungen aus verschiedenen VDI-Umgebungen reichen. Alle diese Tests nutzen den gemeinsamen vdBench-Workload-Generator mit einer Skript-Engine, um Ergebnisse über einen großen Computing-Testcluster zu automatisieren und zu erfassen. Dadurch können wir dieselben Arbeitslasten auf einer Vielzahl von Speichergeräten wiederholen, einschließlich Flash-Arrays und einzelnen Speichergeräten.
Profile:
- 4K Random Read: 100 % Read, 128 Threads, 0-120 % Iorate
- 4K Random Write: 100 % Schreiben, 64 Threads, 0-120 % Iorate
- 64K sequentielles Lesen: 100 % Lesen, 16 Threads, 0-120 % Leserate
- 64K Sequentielles Schreiben: 100 % Schreiben, 8 Threads, 0-120 % Iorate
- Synthetische Datenbank: SQL und Oracle
- VDI-Vollklon- und Linked-Clone-Traces
Unsere VDBench-Tests wurden nebeneinander mit dem EF600 auf NVMeoF und dem EF570 auf FC durchgeführt. Beim zufälligen 4K-Lesen startete der EF600 bei 206,592 mit einer Latenz von 192.7 μs und blieb unter 1 ms, bis er etwa 2,082,389 IOPS erreichte; Der Höchstwert lag bei 2,082,693 mit einer Latenz von 1.4 ms. Der EF570 startete bei 103,330 mit einer Latenz von 184μs. Der EF570 erreicht zweimal einen Spitzenwert, und nach der ersten Spitze blieb er unter 1 ms, bis er 929,562 IOPS erreichte. Anschließend erreichte er ein Maximum von 1,031,613 IOPS mit einer Latenz von 2.5 ms.
Betrachtet man die 4K-Schreibleistung, so starteten beide Subsysteme erneut mit einer extrem niedrigen Latenz von unter 100 μs. Die Leistung des EF600 lag deutlich unter 1 ms, bis etwa 640,171 IOPS erreichten, wo das Array auch seinen Höhepunkt erreichte. Dies war ein deutlicher Unterschied im Vergleich zur Spitzenleistung des EF570 von 222,416 IOPS bei einer Latenz von 4.7 ms.
Bei der Umstellung auf sequentielle Workloads betrachten wir die Spitzenleistung bei 64K-Lesevorgängen. Hier startete der EF600 unter 500 μs bei 128,713 IOPS oder 4 GB/s und erreichte einen Spitzenwert von 643,152 IOPS oder 40.2 GB/s mit einer Latenz von 458 μs. zeigt eine konstante Latenz über die Gesamtleistung an. Der EF570 startete ebenfalls unter 500 μs und blieb unter 1 ms, bis er 202,776 IOPS oder 12.67 GB/s erreichte, und erreichte dann schnell einen Spitzenwert von 247,692 IOPS oder 15.48 GB/s mit einer Latenz von 2 ms.
Beim 64K-Schreiben begannen beide Arrays mit einer Latenz von unter einer Millisekunde unter 250 μs und behielten eine konstante Latenz bei, kurz bevor sie ihre Spitzenleistung erreichten. Der EF600 erreichte einen Spitzenwert von 141,859 IOPS oder 8.87 GB/s bei einer Latenz von 1.3 ms. Die Leistung des EF570 erreichte ihren Höhepunkt bei 80,675 oder 5 GB/s bei einer Latenz von 3.2 ms.
Unsere nächste Testreihe sind unsere SQL-Workloads: SQL, SQL 90-10 und SQL 80-20. Im SQL starteten beide Arrays unter 200 μs und blieben auch nach Erreichen der Spitzenleistung unter 1 ms. Beim EF600 sahen wir einen Spitzenwert von 1,880,526 IOPS bei einer Latenz von 398 μs. Und der EF570 hatte einen Spitzenwert von 1,029,910 IOPS mit einer Latenz von 818 μs.
Mit SQL 90-10 haben wir gesehen, dass beide Arrays gestartet wurden und die Leistung unter einer Latenz von 1 ms gehalten wurde. Der EF600 erreichte einen Spitzenwert von 1,784,866 IOPS mit einer Latenz von 387 μs, während der EF570 mit 600 IOPS bei einer Latenz von 875,340 μs nur die Hälfte der Leistung des EF853 erreichte.
Mit SQL 80-20 sahen wir erneut einen ähnlichen Ausgangspunkt für die Latenz in beiden Arrays, nämlich über 200 μs. Der EF600 startete mit 156,264 IOPS und erreichte einen Spitzenwert von 1,559,733 IOPS mit einer Latenz von 406 μs. Der EF570 startete mit 73,990 IOPS und erreichte mit einer Latenz von 739,139 ms seinen Höhepunkt bei 1.1 IOPS.
Unsere nächsten Benchmarks sind unsere Oracle-Workloads: Oracle, Oracle 90-10 und Oracle 80-20. Mit Oracle startete der EF600 bei 153,376 IOPS mit einer Latenz von 158 μs und blieb dabei unter einer Latenz von weniger als einer Millisekunde. Anschließend erreichte er einen Spitzenwert von 1,531,381 IOPS mit einer Latenz von 507 μs. Dies wird mit dem Spitzenwert des EF570 von 718,141 IOPS bei einer Latenz von 1.2 ms verglichen.
In Oracle 90-10 startete der EF600 mit 172,788 IOPS bei einer Latenz von 161 μs und blieb während des gesamten Tests unter 1 ms. Anschließend erreichte er seinen Höhepunkt bei 1,660,486 IOPS mit einer Latenz von 286 μs. Der EF570 hingegen hatte eine Spitzenleistung von 874,181 IOPS bei einer Latenz von 650μs.
Für Oracle 80-20 startete der EF600 mit 156,113 IOPS bei einer Latenz von 158 μs und blieb bis zum Ende des Tests unter einer Latenz von weniger als einer Millisekunde. Der EF600 erreichte seinen Spitzenwert bei 1,514,221 IOPS mit einer Latenz von 310 μs. Das war etwa das Doppelte der 570 IOPS des EF735,093 mit einer Latenz von 681 μs.
Schlussfolgerung
Das NetApp AFA EF600 ist ein End-to-End-NVMe-Array für die Mittelklasse. Das Array ist nur 2U groß, kann aber in seinem kleinen Rahmen bis zu 367 TB Kapazität packen und bietet eine Leistung, die mit viel größeren Enterprise-Arrays mithalten kann. Dazu gehören 2 Millionen IOPS, bis zu 44 GB/s Bandbreite und eine Latenz von unter 100 μs. Das Array verfügt außerdem über eine gewisse integrierte Zukunftssicherheit mit der Unterstützung von 100 Gbit NVMe über InfiniBand, 100 Gbit NVMe über RoCE, FCP-Unterstützung und 32 Gbit NVMe über FC. Wie alle NetApp-Arrays verfügt das EF600 über hohe Verfügbarkeit und mehrere integrierte Datenschutzfunktionen.
Im Hinblick auf die Leistung haben wir den EF600 mit NVMe-oF mit dem EF570 über FCP verglichen. Dies sollte nicht zeigen, welches besser ist, sondern vielmehr, um zu veranschaulichen, was man von den beiden Einheiten erwarten kann. Beim 4K-Zufallslesen hatte der EF600 mit über 570 Millionen IOPS mehr als die doppelte Spitzenleistung des EF2 und fast die Hälfte der Latenz mit nur 1.4 ms. Beim 4K-Schreiben hatte der EF600 fast die dreifache Spitzenleistung (3 IOPS) bei einem Drittel der Latenz (ca. 640 ms). Bei unseren sequentiellen 1.5-KB-Workloads konnten wir eine Spitzenleistung von 64 GB/s beim Lesen und 40.2 GB/s beim Schreiben erzielen, etwa 8.87-mal schneller beim Lesen und 2.6-mal schneller beim Schreiben. Für SQL erzielte der EF1.8 Spitzenwerte von 600 Millionen IOPS, 1.88 Millionen IOPS für SQL1.78-90 und 10 Millionen IOPS für SQL 1.56-80, alle bei einer Latenz von weniger als einer Millisekunde. Bei unseren Oracle-Tests erreichte der EF20 600 Millionen IOPS, 1.53 Millionen IOPS auf Oracle 1.66-90 und 10 Millionen IOPS auf Oracle 1.51-80, wiederum alle unter einer Latenz von 20 ms.
Der AFA EF600 ist ein weiteres beeindruckendes Array von NetApp. Der EF600 bietet Midrange-Benutzern die Kapazität, die sie benötigen, sowie eine sehr hohe Transaktionsleistung mit geringer Latenz. Für Kunden, die weder die Datenreduzierung noch die umfangreichen Datendienste benötigen, die die ONTAP-Seite des Hauses bietet, erfüllt der EF600 die Rolle, Hochleistung für gezielte Anwendungen zu bieten, die von den neuesten NVMe-SSD- und Datentransporttechnologien profitieren können . Letztendlich wird das EF600 nicht jedermanns Sache sein, aber das ist nicht die Absicht, es ist eindeutig kein Schweizer Taschenmesser. Die Absicht von NetApp mit dem EF600 ist etwas taktischer; Das Ziel besteht darin, eine robuste Plattform bereitzustellen, die in der Lage ist, Anwendungen aufzunehmen, die außerhalb der üblichen Virtualisierungs-Hotspots liegen, und eine schnellere Wertschöpfung für das Unternehmen zu ermöglichen. Der EF600 wird KI-, ML- und Datenbank-Workloads beschleunigen und dem Unternehmen schneller als je zuvor in dieser Speicherkategorie umsetzbare Erkenntnisse liefern. Für dieses Preis-Leistungs-Verhältnis und die Zuverlässigkeit, die diese EF der fünften Generation bietet, erhält die NetApp EF-Familie mit dem EF600 einen weiteren StorageReview Editor's Choice Award.
Besprechen Sie diese Rezension
Melden Sie sich für den StorageReview-Newsletter an
