Welches SAN-Storage für KMU?
Hallo Zusammen, das Storagethema rückt nun tatsächlich ins Finale.
Momentan wurde mir eine FAS2060 und E2800 für ca 52000- 54000 angeboten (SanSwitche, 3 FC Karten und Kabel + Einrichtung inclu). 40TB SAS netto
Was sagst Ihr zu dem Preis und vorallem, wie steht nun das Verhältnis zur 3 PAR 8200 bzw MSA 2040 und zur Fujitsu Dx100?
Insgesamt habe ich bei der NETAPP ein gutes Gefühl von den Erzählungen her .
Und könnte man die Einrichtung selbst hinbekommen ?
Folgendes soll mit dem Storage fabriziert werden:
3 ESX DL380G7 38 Instanzen (später 45 Instanzen) Größtenteils VPN Verbindungsrechner, Exchange 2 Dcs und kleiner Filer, sowie ein paar SAP Systeme (nicht produktiv, sondern rein Entwicklung) 5 Physische Server, wo die Oracle DBs auf dem Storage sitzen sollen. Das ganze sollte ja für z.B. die NetApp kein Problem darstellen? (rein SAS)
Was sagt Ihr?
Momentan wurde mir eine FAS2060 und E2800 für ca 52000- 54000 angeboten (SanSwitche, 3 FC Karten und Kabel + Einrichtung inclu). 40TB SAS netto
Was sagst Ihr zu dem Preis und vorallem, wie steht nun das Verhältnis zur 3 PAR 8200 bzw MSA 2040 und zur Fujitsu Dx100?
Insgesamt habe ich bei der NETAPP ein gutes Gefühl von den Erzählungen her .
Und könnte man die Einrichtung selbst hinbekommen ?
Folgendes soll mit dem Storage fabriziert werden:
3 ESX DL380G7 38 Instanzen (später 45 Instanzen) Größtenteils VPN Verbindungsrechner, Exchange 2 Dcs und kleiner Filer, sowie ein paar SAP Systeme (nicht produktiv, sondern rein Entwicklung) 5 Physische Server, wo die Oracle DBs auf dem Storage sitzen sollen. Das ganze sollte ja für z.B. die NetApp kein Problem darstellen? (rein SAS)
Was sagt Ihr?
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 342129
Url: https://administrator.de/contentid/342129
Ausgedruckt am: 18.11.2024 um 07:11 Uhr
52 Kommentare
Neuester Kommentar
Hat zwar mit dem direkten Thema nix zu tun: Redundantes SAN aber ein nicht redundantes LAN bei den Servern ?! Kein wirklich gutes Konzept bzw. LAN Design.
Ein toter LAN Switch und deine SAN Redundanz ist für die Katz.
Hier gehören auch mindestens 2 LAN Switches im Stack oder als HA mit VRRP dazu für einen durchgängige Redundanz.
Die generelle Frage die sich bei KMU immer stellt ob teure FC Infrastruktur überhaupt noch sein muss und man mit einem modernen Ethernet Fabric basierten Switchdesign (TRILL oder SPF) und Storage Priorisierung nicht ganz auf IP Storage mit einem 10G/40G Backbone setzt um nicht 2 Infrastrukturen gleichzeitig mit Servicekosten, Management usw. betreiben zu müssen. (Kosten)
Auch wenn FC Pflicht ist haben hybride Fabric Switches ja die Option FC über deren Dual Mode Ports (Ethernet und FC fähig) FC auch vollständig über die Ethernet Infrastruktur abzubilden.
Nur mal so nebenbei am Freitag....
Ein toter LAN Switch und deine SAN Redundanz ist für die Katz.
Hier gehören auch mindestens 2 LAN Switches im Stack oder als HA mit VRRP dazu für einen durchgängige Redundanz.
Die generelle Frage die sich bei KMU immer stellt ob teure FC Infrastruktur überhaupt noch sein muss und man mit einem modernen Ethernet Fabric basierten Switchdesign (TRILL oder SPF) und Storage Priorisierung nicht ganz auf IP Storage mit einem 10G/40G Backbone setzt um nicht 2 Infrastrukturen gleichzeitig mit Servicekosten, Management usw. betreiben zu müssen. (Kosten)
Auch wenn FC Pflicht ist haben hybride Fabric Switches ja die Option FC über deren Dual Mode Ports (Ethernet und FC fähig) FC auch vollständig über die Ethernet Infrastruktur abzubilden.
Nur mal so nebenbei am Freitag....
Kannst du die Einrichtung selbst hinbekommen? Klar - auch die Techniker werden da nich mit Voodoo oder Magie vorstehen. OB du es kannst musst du selbst wissen. Denn dazu gehört nicht nur ein paar Partitionen anlegen sondern auch die Überlegung wie z.B. Redundanz geschaffen wird, wie du dafür sorgst das bei x paralleln Zugriffen auf den Datastore sich nicht die Daten zerlegen usw...
Moin,
dein Post enthällt etwas magere Informationen...
Das komplette Fabric inkl. der HBAs ist in 16G FC ausgeführt?
EDIT:
lg,
Slainte
dein Post enthällt etwas magere Informationen...
Das komplette Fabric inkl. der HBAs ist in 16G FC ausgeführt?
FAS2060, 3 PAR 8200 bzw MSA 2040 und zur Fujitsu Dx100?
Da sind die Leistungsklassen aber geanz schon gemischt Ich persönlich halte NetApp aber nicht für den geeigneten Unterbau für ESXi-Hosts (VMFS ist mEn NFS als Datastore überlegen)Das ganze sollte ja für z.B. die NetApp kein Problem darstellen?
Lässt sich ohne genaue Analyse der IOPS-Anforderungen und der Platten/LUN Konfig der NetApp nicht beantworten(rein SAS)
Heutzutage würde ich keine SAN mehr kaufen, in der nicht zumindest 2, 4 oder 6 SSDs als Autotierung oder Cache verbaut sind.EDIT:
Kannst du die Einrichtung selbst hinbekommen?
Kann man sicher, allerdings setzen einige Hersteller (bei der HPE 3PAR weis ich das sicher) vorraus, das die Systeme von Certified Engineers eingerichtet werden, da sonst kein Support gewährleistet wird (und du hast die SAN doch mit 24/7 4h angefragt, oder?)lg,
Slainte
Hallo!
Das ist alles sehr schwer einzuschätzen, weil niemand die Performanceanforderungen abschätzen kann, aber da Du auf SAS ohne Flash gehst, scheint es sich ja im Rahmen zu halten.
Bei dieser Anforderung würde ich ja eher auf ein Open-E Jovian Metrocluster oder ein Starwind-Storage gehen. Die Hardwareauswahl hast Du selbst in der Hand und kannst recht einfach einen Flash-Cache ergänzen - bei Open-E über eine ZIL-SSD, bei Starwind z.B. über eine NVMe.
Grüße
Phil
Das ist alles sehr schwer einzuschätzen, weil niemand die Performanceanforderungen abschätzen kann, aber da Du auf SAS ohne Flash gehst, scheint es sich ja im Rahmen zu halten.
Bei dieser Anforderung würde ich ja eher auf ein Open-E Jovian Metrocluster oder ein Starwind-Storage gehen. Die Hardwareauswahl hast Du selbst in der Hand und kannst recht einfach einen Flash-Cache ergänzen - bei Open-E über eine ZIL-SSD, bei Starwind z.B. über eine NVMe.
Grüße
Phil
Indem du ein Storage bei Dell anfragst und die eine DPack Messung machen. Danach hast du eine schöne (herstellerunabhängige) Auswertung deines Ist-Bedarfs und VMware mag bei gutem Preis auch eine Equallogic oder Compellent mit vVOL.
VG,
Thomas
Ich kann Dir uneingeschränkt Pure Storage empfehlen. Schlägt alles andere im Storage Bereich um längen.
Wenn iOPS gefordet sind kommt niemand an Pure heran.
https://www.purestorage.com/de/products/flash-array-m.html
Wir haben vor dem Kauf von alle Hersteller eingeladen und ein Test gemacht.
Storage, Fibre Channel, 2 Hosts und dies zwei Wochen Produktiv genutzt. Dann hat sich ganz klar herausgestellt, dass kein anderer Hersteller einhält was er verspricht.
Wenn iOPS gefordet sind kommt niemand an Pure heran.
https://www.purestorage.com/de/products/flash-array-m.html
Wir haben vor dem Kauf von alle Hersteller eingeladen und ein Test gemacht.
Storage, Fibre Channel, 2 Hosts und dies zwei Wochen Produktiv genutzt. Dann hat sich ganz klar herausgestellt, dass kein anderer Hersteller einhält was er verspricht.
Wie gen au könnte ich eine IOPS Messung durchführen?
Das sollte idR das Systemhaus machen, bevor ein Angebot erstellt bzw Konzept ausgearbeitet wird - alles andere ist reines Ratespiel bzw. fast schon unseriös. Wichtig ist hier den zukünftigen Bedarf mit einzurechnen (SANs kauft man für 3-5 Jahre Nutzungsdauer)Was wäre an der Stelle besser?
Mit MSAs hab ich gute Erfahrungen gemacht bei so kleineren Installationen wie deiner. Für die größeren würde ich 3PAR nehmen. 4 SSDs als Cache( Bin mir aber gerade nicht sicher, ob es die MSA verwalten kann)
Ja, das kann die 204xdas Ganze ist mit 4h support bzw. NBD
NBD ist bei der zentralen SAN ein no-go!
Wir haben unsere FC-Infrastruktur begraben da es mit neue Mellanox Ethernet keinen Großen Sinn mehr hat und die Kosten sind unvergleichbar. Die ganze Infrastruktur läuft jetzt mit drei StarWind knoten https://www.starwindsoftware.com/starwind-hyperconverged-appliance. Insgesamt sind das ca. 150 Mitarbeiter, 24TB Speicher für 50 VMs (SAP, ERP, Exchange, DC, RDP und so weiter). Die Knoten sind all-flash mit 40 GbE Mellanox backend. Soweit funktioniert alles ganz toll.
Der Preis war für uns ganz wichtig und die Komplette Lösung liegt im ganz anderen Niveau wenn Mann es mit NetApp oder 3PAR vergleicht. Deshalb von mir aus ist es für klein und mittelunternehmen total empfehlenswert.
Der Preis war für uns ganz wichtig und die Komplette Lösung liegt im ganz anderen Niveau wenn Mann es mit NetApp oder 3PAR vergleicht. Deshalb von mir aus ist es für klein und mittelunternehmen total empfehlenswert.
Zitat von @Net-Runner:
Wir haben unsere FC-Infrastruktur begraben da es mit neue Mellanox Ethernet keinen Großen Sinn mehr hat und die Kosten sind unvergleichbar. Die ganze Infrastruktur läuft jetzt mit drei StarWind knoten https://www.starwindsoftware.com/starwind-hyperconverged-appliance. Insgesamt sind das ca. 150 Mitarbeiter, 24TB Speicher für 50 VMs (SAP, ERP, Exchange, DC, RDP und so weiter). Die Knoten sind all-flash mit 40 GbE Mellanox backend. Soweit funktioniert alles ganz toll.
Der Preis war für uns ganz wichtig und die Komplette Lösung liegt im ganz anderen Niveau wenn Mann es mit NetApp oder 3PAR vergleicht. Deshalb von mir aus ist es für klein und mittelunternehmen total empfehlenswert.
Wir haben unsere FC-Infrastruktur begraben da es mit neue Mellanox Ethernet keinen Großen Sinn mehr hat und die Kosten sind unvergleichbar. Die ganze Infrastruktur läuft jetzt mit drei StarWind knoten https://www.starwindsoftware.com/starwind-hyperconverged-appliance. Insgesamt sind das ca. 150 Mitarbeiter, 24TB Speicher für 50 VMs (SAP, ERP, Exchange, DC, RDP und so weiter). Die Knoten sind all-flash mit 40 GbE Mellanox backend. Soweit funktioniert alles ganz toll.
Der Preis war für uns ganz wichtig und die Komplette Lösung liegt im ganz anderen Niveau wenn Mann es mit NetApp oder 3PAR vergleicht. Deshalb von mir aus ist es für klein und mittelunternehmen total empfehlenswert.
Hallo!
Starwind hat in meinen Augen nur einen hässlichen Punkt: Die DR-Knoten können nicht "aktiv" genommen werden. Das können andere Systeme besser, dass man z.B. einen Snapshot auf dem DR-Knoten "Read-Write" clonen kann.
Sonst ist das System gut.
Wichtig: Starwind läuft unter Windows. Entsprechend kann das die Lizensierung DEUTLICH verkomplizieren, da Clients, die nur Linux-VMs nutzen plötzlich CALs benötigen.
Grüße
Phil
Da wir es als Komplett-Lösung gekauft haben war die Lizensierung für uns doch keine Frage.
Für DR-Knoten ist eigentlich nicht Starwind sondern VEEAM verantwortlich der mit dabei vorkonfiguriert kommt. Dieser macht DR-replikation von VMs und Backup. Mit dem letzten Update fahren jetzt die Backups automatisch zu AWS Glacier was ich wirklich toll finde.
Für DR-Knoten ist eigentlich nicht Starwind sondern VEEAM verantwortlich der mit dabei vorkonfiguriert kommt. Dieser macht DR-replikation von VMs und Backup. Mit dem letzten Update fahren jetzt die Backups automatisch zu AWS Glacier was ich wirklich toll finde.
[IOPS Messung] ... uns wurde glaube anfangs mal so etwas gegen ein paar 1000 € angeboten.
Ja ist so üblich, wird dann aber normalerweise mit dem Preis der SAN verrechnetet (vorausgesetzt man kauft beim gleichen Systemhaus)Wie waren deine MSAs ausgestattet und was lief da so drauf?
2x SSD als Cache, 14x 10k SAS RAID10 + 2x Global Hotspare - das ganze 2 Mal und mit Replikation - angebunden per FC Fabric an 3 ESXi mitzusammen etwa 20-30 VMs (allerdings ohne SQL/ERP und Exchange) und 1 Veeam Backup Host.
Wenn ich 3 x DL 380 G7 mit jeweils 8 Platten im RAID 10, dann wird doch die MSA mit Ihren sx 24 Platten trotzdem eine viel häöhere Performance heraus holen?
Schon richtig, allerdings kommen bei einer SAN idR mehr Hosts bzw. VMs auf das Plattensystem zu. Ist schon ein Unterschied, ob 10 VMs auf das RAID über SAS zugreifen, oder 30 VMs auf 3 Hosts über FC.Wie viel IOPS wird die MSA bei solch konfig haben
Das Berechnen von IOPS ist nicht unbedingt trivial, liest mal z.B. hier: http://www.techrepublic.com/blog/the-enterprise-cloud/calculate-iops-in ...Hat denn die MSA zusätzlichen Flash intern verbaut?
DIE MSA hat sicher (gebufferten) Cache auf Controller-Ebene. Flash (im Sinne von SSDs mit mehreren hundert GB Speicher) hat sie nicht, die muss man als SSD dazu konfigurierenweshalb die FAS2650 nicht als gutes Block Storage durchgeht.
Weil's kein Blockstorage ist Für NetApp ist alles NFS... zwar können die Boxen auch iSCSI und FC - aber da werden dann die LUNs intern als Files angelegt - zumindest hatte mir das der NetApp Technical Sales Typ letztes Jahr so erklärt.
Und wie schon gesagt: NFS ist als Datastore für VMWare einem Blockdevice mit vmfs unterlegen.
Zitat von @SlainteMhath:
Und wie schon gesagt: NFS ist als Datastore für VMWare einem Blockdevice mit vmfs unterlegen.
Und wie schon gesagt: NFS ist als Datastore für VMWare einem Blockdevice mit vmfs unterlegen.
Moin,
kommt halt auf die benoetigten Features an. NFS ist simpler, kann aber nicht alles. Und ob die FAS das intern als File behandelt oder nicht ist dem ESXi egal, fuer den ist das Blockstorage mit allen Vorteilen.
VG,
Thomas
Hm, ich schrieb vorhin noch einmal einen NETAPP Systems Engineer an und fragte nach. Er meinte, alle beide Geräte sind Blockstorages und sprechen beide Blockprotokolle ISCSI und FC.
Dem muss ich aus eigener Erfahrung wiedersprechen!
Eine NetApp FAS ist im Prinzip ein Gehäuse mit zwei Intel Servern auf denen ein OS namens "Ontab" läuft.
Wobei allerdings immer nur ein Server aktiv ist. Der andere läuft "doof" mit verbraucht Strom und wartet bis der andere ausfällt...
Fast alle anderen Storages (Dell, EMC, Fujitsu, HPE, Huawei) arbeiten mit zwei gleichzeitig arbeitenden Controllern und liefern somit die doppelte Geschwindigkeit eines einzelnen Failover Systems. Erst im unwahrscheinlichen Fehlerfall übernimmt ein Controller die Aufgabe und reduziert somit die mögliche Höchstgeschwindigkeit.
Die Platten der Storages sind im ziemlich exotischen RAID4 bzw. RAID-DP (Raid4 mit zwei Paritydisks) angeordnet, was bedeutet das die Performance nicht linear mit der Anzahl der Platten wächst und die Last asymetrisch, vorallem auf den Parity Platten, verteilt ist. Bei SSDs ist dies ein echter Nachteil, da diese überdurchschnittlich schnell durch die hohe Schreiblast "verschleißen".
Auf diesem RAID ist ein NetApp eigenes Dateisystem namens "WAFL" installiert.
Dies bedeutet, das kein Host DIREKT auf die LUN und Volumes ihr eigenes Dateisystem (NTFS, VMFS, usw.) schreiben kann. Es wird immer in das WAFL umgewandelt. (Was natürlich nicht ohne Verluste geht...)
Dies ist nicht unbedingt ein Nachteil, da WAFL einige zu seiner Zeit revolutionäre Features mitbrachte (z.B. Snap on Write) Allerdings bezeichnet NetApp seine Storages selbst als "Filer" was die Sache ziemlich genau trifft.
Auch wenn man die NetApp Systeme mitlerweile auch per FC und iSCSI ansprechen kann: Unter der Haube werkelt leider nur ein File orientiertes NAS Storage
So richtig steht das eben auch nicht im Datasheet.
Dafür stehen aber dort dutzende tolle Features ohne die ein gläubiger NetApp Jünger nicht leben kann!
Z.B. ein (verglichen mit aktuellen Speichern) primitives (weil nicht "Inline" sondern als "Post Processing") "quasi Dedup" welches die Daten komprimiert...
Das macht das eh schon relativ langsame System zwar noch langsamer, hilft aber beim verkaufen, da NetApps häufig mit einer zu kleinen Nettokapazität verkauft werden!
An den (bei den z.T. kaum auf dauer haltbaren Dedupraten) bald fälligen Erweiterungen, verdient dann der Händler und holt sich den hohen "Einstiegsrabatt" wieder rein...
};-D
Ich würde darauf bestehen, das die Netto Speicherkapazität die du bestellst UNKOMPRIMIERT und nicht dedupliziert zur Verfügung gestellt wird. Und zwar in einem von DIR bestimmten RAID Level. (z.B. RAID10 für Performance, RAID60 für Sicherheit)Und wie schon gesagt: NFS ist als Datastore für VMWare einem Blockdevice mit vmfs unterlegen.
Sehr hilfreiche Info, ich werde den Kollegen von NETAPP noch einmal detailierter dazu befragen.Dafür war damals aber NetApp die ersten die sich in die Vsphere integrieren ließen.
Okay, das können heute allerdings fast alle anderen auch...
Ich habe mir das ganze mal auf den datsgheets angeschaut und da habe ich wirklich in allen belangen die FAS als viel besser bewertet. 512GB NVMe pro Controller, 64GB ECC memory, 8GB NVMe RAM / Bei der MSA sehe ich max 6GB Cache per Controller und 12 GB pro Array
Das nennt man übrigens "Feature-Fucking"!
Oder zu Deutsch: "Äpfel mit Birnen vergleichen"
Die Ausstattung der Controller mit Speicher lässt aufgrund der vollkommen unterschiedlichen Architektur (s.o.) keinerlei Rückschlüsse auf die zu erwartende Geschwindigkeit zu.
Es ist höchstens ein Anzeichen dafür, das NetApp versucht mit viel Cache und "Buzzwords" wie "NVMe" die prinzipbedingten Nachteile ihres Konzepts zu kaschieren...
Wenn dir der Cache der MSA zu klein sein sollte kannst Du ihn übrigens gern mit bis zu 8TB erweitern!
Oder du lässt das "Bullshit Cache Bingo" bleiben und nutzt den SSD Speicher für eine echte Beschleinigung des Storages, in dem du z.B. reine "All Flash" LUN anlegst, oder wie bei der MSA 2042 (bzw. der neuen MSA2052) die "Autotiering" Option nutzt...
Angesichts des technischen Rückstandes und hohen Verluste an Marktanteilen und Umsatz die NetApp derzeit einfährt ist es zudem fraglich ob das Unternehmen eine große Zukunft hat.
Mir wäre dies ganz recht, denn die Fa. NetApp hat mir bereits diverse Überstunden der Fehlersuche (Die "NetApp Sekte" ist es nie gewesen - Es ist IMMER der Server oder das SAN schuld!) und einen geplatzter Winterurlaub beschert...
@Dr.EVIL
Super Post! Darf ich den zitieren, wenn das nächste Mal NetApp bei mir anklingelt? Das waren im groben genau die Punkte, dir mir damals auch komisch aufgestoßen sind (v.A. das WAFL..)
Super Post! Darf ich den zitieren, wenn das nächste Mal NetApp bei mir anklingelt? Das waren im groben genau die Punkte, dir mir damals auch komisch aufgestoßen sind (v.A. das WAFL..)
Zitat von @SlainteMhath:
@Dr.EVIL
Super Post! Darf ich den zitieren, wenn das nächste Mal NetApp bei mir anklingelt? Das waren im groben genau die Punkte, dir mir damals auch komisch aufgestoßen sind (v.A. das WAFL..)
@Dr.EVIL
Super Post! Darf ich den zitieren, wenn das nächste Mal NetApp bei mir anklingelt? Das waren im groben genau die Punkte, dir mir damals auch komisch aufgestoßen sind (v.A. das WAFL..)
Natürlich darfst Du das...
Aber sei Vorsichtig!
Ähnlich der Nobel-Heimcomputer von Äpp-el, sind auch die NetÄpp Anhänger, dank der vermutlich aus dem "Bible-Belt" des mittleren Westens der USA stammenden Marketing Abteilung, wie eine religiöse Sekte indoktriniert!
Auf Ketzerei und Heräsie reagieren sie sehr empfindlich, denn:
"Wo die Tatsachen fehlen, muss der Glaube die Fakten ersetzen." (Frei nach D.Trump)
Reicht denn dann 10g Ethernet aus oder muss es immer FC sein?
Und der nächste Glaubenskrieg 16G FC ist "schneller" als 10G iSCSI und 8G FC ist (etwas) "langsamer" - lass dir beides anbieten (jeweils mit dedizierten HBAs/NICs und Switches). Von HPE gibt's teilweise günstige Bundles mit 2x8Port 16G FC Switches...
Wenns im Budget rechte eng ist, kann man auch "hyper-converged" fahren, also LAN + iSCSI über den gleichen Switch/NIC, davon halte ich persönlich aber nur bedingt etwas.
Die SAN Anbindung wäre ein anderes Thema!
Wenn Du nicht mehr als 4 Server anschließen möchtest, würde ich sogar zu einem direkten 12Gbit/s SAS Anschluss raten...
In deinem Fall, mit mehr Servern, hast du die Qual der Wahl:
FC mit 8 oder 16Gbit oder 10Gbit iSCSI.
8Gbit FC und 10 Gbit iSCSI haben etwa die gleiche Nettobandbreite (Vom TCP/IP des iSCSI gehen etwa 20% "Overhead" ab.)
Was aber fast wichtiger als die Bandbreite wäre, ist die Latenz (Zeit, nach dem ein Block dem Host OS als geschrieben gemeldet, bzw. gelesen wurde)
Dies spielt vor allem dann eine Rolle, wenn SSDs mit Zugriffszeiten im Nanaosekunden Bereich im Spiel sind!
Um hier die Geschwindigkeit eines FC SAN zu erreichen muss man bei der iSCSI Infrastruktur schon SEHR TIEF in die Tasche greifen.
"Irgendein" 10Gbit Switch ohne "Port Forwarding", mit "shared Memory" und zuwenig schnellem Buffer pro Port und "normalo" Prozessor, der vielleicht als "Etagenverteiler" noch gute Dienste leistet, reicht für ein iSCSI SAN mit Jumboframes nicht aus!
In deinem Speziellen Fall würde ich wenigstens zwei HPE 5700 mit je 40 Ports (Stückpreis, ca. 11.000,-€ uvP.) einplanen.
Auch bei der Wahl der NIC für die Hosts sollte man auf "CPU Offload" Fähigkeit achten (Bei HPE: Alles auf dem "FlexFabric" steht)
Hier ist ein 16Gbit FC SAN bei ähnlichen Kosten (zwei FC Switche und je ein Doppel-HBA pro Host) fast doppelt so "schnell"!
Dein Systemhaus kann hier sicherlich ein faires Angebot machen...
Wenn Du nicht mehr als 4 Server anschließen möchtest, würde ich sogar zu einem direkten 12Gbit/s SAS Anschluss raten...
In deinem Fall, mit mehr Servern, hast du die Qual der Wahl:
FC mit 8 oder 16Gbit oder 10Gbit iSCSI.
8Gbit FC und 10 Gbit iSCSI haben etwa die gleiche Nettobandbreite (Vom TCP/IP des iSCSI gehen etwa 20% "Overhead" ab.)
Was aber fast wichtiger als die Bandbreite wäre, ist die Latenz (Zeit, nach dem ein Block dem Host OS als geschrieben gemeldet, bzw. gelesen wurde)
Dies spielt vor allem dann eine Rolle, wenn SSDs mit Zugriffszeiten im Nanaosekunden Bereich im Spiel sind!
Um hier die Geschwindigkeit eines FC SAN zu erreichen muss man bei der iSCSI Infrastruktur schon SEHR TIEF in die Tasche greifen.
"Irgendein" 10Gbit Switch ohne "Port Forwarding", mit "shared Memory" und zuwenig schnellem Buffer pro Port und "normalo" Prozessor, der vielleicht als "Etagenverteiler" noch gute Dienste leistet, reicht für ein iSCSI SAN mit Jumboframes nicht aus!
In deinem Speziellen Fall würde ich wenigstens zwei HPE 5700 mit je 40 Ports (Stückpreis, ca. 11.000,-€ uvP.) einplanen.
Auch bei der Wahl der NIC für die Hosts sollte man auf "CPU Offload" Fähigkeit achten (Bei HPE: Alles auf dem "FlexFabric" steht)
Hier ist ein 16Gbit FC SAN bei ähnlichen Kosten (zwei FC Switche und je ein Doppel-HBA pro Host) fast doppelt so "schnell"!
Dein Systemhaus kann hier sicherlich ein faires Angebot machen...
"Deduplikation" hat meiner Meinung in einem primären Festplatten Storage nichts zu suchen! (Ist eher was für den Backupstorage Bereich...)
Der Grund liegt in den "Backend I/O"!
Für jeden I/O den du an das Storage schickst, werden allein für das RAID mehrer I/O im "Inneren" des Storage erzeugt.
Durch Dedulikation wird die Anzahl dieser I/O um ein mehrfaches gesteigert.
Dementsprechend wäre ein primäres Blockstorage mit Festplatten viel zu langsam!
NetApp macht daher den Trick, die Daten zuerst in einem nicht deduplizierten Bereich zu sammeln und in Zeiten in denen es "nicht so auffällt" (z.B. Nachts) zeitverzögert zu deduplizieren.
Irgendwann wird der Storage dann aber spürbar langsamer...
Bei einem reinen "All Flash" Storage sieht dies aber besser aus: Ist der Prozessor des Storage schnell genug kann die Deduplikation in "Echtzeit" durchgeführt werden.
Allerdings reden wir hier von einer ganz anderen Preislage von Storages, wie z.B. der 3PAR (HPE StoreServ) oder der Dell EMC² VMAX...
DIe MSA hat im übrigen eine imho recht gut funktionierende Kompression (Thin Provisioning), die in vielen Fällen (mindestens) genau so hohe Datenreduktionen wie eine (schlechte, s.o.) Deduplikation erreicht!
Eines sollte aber in beiden Fällen klar sein:
Datenreduktion verlangsamt den Storage! (Je nach Leistung der Controller mehr oder weniger)
"Overprovisioning", also mehr Speicher zur Verfügung stellen als physikalisch vorhanden ist, führt fast zwangsläufig zu Streß bei der Administration:
Bei mir war es eine unbedarfte Sekretärin, die ALLE Fotos der Weihnachtsfeier, in voller Größe an ALLE Angestellten der Firma geschickt hat und so das Storage zum "Overflow" gebracht hat. (JPG kann schlecht weder komprimiert noch dedupliziert werden...)
Aus diesem Grund würde ich "Thin Provisioning" nur im Notfall, wenn sich das Storage der 90% Füllung nähert und der Chef nicht schnell genug Geld für eine Erweiterung ausgiebt, "zünden". ("Act like Scotty!")
Der Grund liegt in den "Backend I/O"!
Für jeden I/O den du an das Storage schickst, werden allein für das RAID mehrer I/O im "Inneren" des Storage erzeugt.
Durch Dedulikation wird die Anzahl dieser I/O um ein mehrfaches gesteigert.
Dementsprechend wäre ein primäres Blockstorage mit Festplatten viel zu langsam!
NetApp macht daher den Trick, die Daten zuerst in einem nicht deduplizierten Bereich zu sammeln und in Zeiten in denen es "nicht so auffällt" (z.B. Nachts) zeitverzögert zu deduplizieren.
Irgendwann wird der Storage dann aber spürbar langsamer...
Bei einem reinen "All Flash" Storage sieht dies aber besser aus: Ist der Prozessor des Storage schnell genug kann die Deduplikation in "Echtzeit" durchgeführt werden.
Allerdings reden wir hier von einer ganz anderen Preislage von Storages, wie z.B. der 3PAR (HPE StoreServ) oder der Dell EMC² VMAX...
DIe MSA hat im übrigen eine imho recht gut funktionierende Kompression (Thin Provisioning), die in vielen Fällen (mindestens) genau so hohe Datenreduktionen wie eine (schlechte, s.o.) Deduplikation erreicht!
Eines sollte aber in beiden Fällen klar sein:
Datenreduktion verlangsamt den Storage! (Je nach Leistung der Controller mehr oder weniger)
"Overprovisioning", also mehr Speicher zur Verfügung stellen als physikalisch vorhanden ist, führt fast zwangsläufig zu Streß bei der Administration:
Bei mir war es eine unbedarfte Sekretärin, die ALLE Fotos der Weihnachtsfeier, in voller Größe an ALLE Angestellten der Firma geschickt hat und so das Storage zum "Overflow" gebracht hat. (JPG kann schlecht weder komprimiert noch dedupliziert werden...)
Aus diesem Grund würde ich "Thin Provisioning" nur im Notfall, wenn sich das Storage der 90% Füllung nähert und der Chef nicht schnell genug Geld für eine Erweiterung ausgiebt, "zünden". ("Act like Scotty!")
Lasse Dir auch einen Preis für die 2052 geben...
Bei dieser handelt es sich um ein "All inclusive Paket" mit zwei SSDs.
Dies ist in vielen Fällen interessanter als eine 2050 nachträglich mit SSDs und der "Advanced Data Services Suite" auszustatten.
Eine SAS Variante gibt es leider für die noch "nagelneue" MSA2050 (noch) nicht. Hier ist man auf das weiterhin angebotene 2040/42 System angewiesen.
DIe Bedienung ist für jemanden, der bereits Erfahrungen mit Storages hat, eher leicht...
Hat man erst einmal das Prinzip begriffen: Zwei Controller = immer Paarweise in zwei "Pools" arbeiten ("The Power of 2")
...Ist die Bedienung beinahe "selbsterklärend".
Man sollte sich aber trotzdem vom Systemhaus eine gute Einweisung geben lassen...
Wichtig ist, das man keine "linearen", sondern "virtuelle" LUN anlegt. Diese lassen sich bedeutend flexibeler handhaben als herkömmliche RAID Verbünde mit festen RAID Leveln.
Monitoring ist ebenfalls vorhanden:
Zum einen gibt es die Möglichkeit sich per Mail über Störungen und Ereignisse informieren zu lassen.
Dann gibt es einen (allerdings imho etwas "rudimentären") Performance Monitor in dem man sich das Leistungsverhalten des Array anzeigen lassen kann.
Und das Gerät ist natürlich SNMP fähig und kann so durch alle bekannten Systeme überwacht werden.
Eine direkte Integration in VSphere ist über OneView für VMWare möglich. Aber das habe ich noch nicht ausprobiert...
Zum Lesen (falls noch nicht bekannt):
http://h20195.www2.hpe.com/v2/redirect.aspx?/products/quickspecs/15935_ ...
http://h20195.www2.hpe.com/v2/redirect.aspx?/products/quickspecs/15936_ ...
Bei dieser handelt es sich um ein "All inclusive Paket" mit zwei SSDs.
Dies ist in vielen Fällen interessanter als eine 2050 nachträglich mit SSDs und der "Advanced Data Services Suite" auszustatten.
Eine SAS Variante gibt es leider für die noch "nagelneue" MSA2050 (noch) nicht. Hier ist man auf das weiterhin angebotene 2040/42 System angewiesen.
DIe Bedienung ist für jemanden, der bereits Erfahrungen mit Storages hat, eher leicht...
Hat man erst einmal das Prinzip begriffen: Zwei Controller = immer Paarweise in zwei "Pools" arbeiten ("The Power of 2")
...Ist die Bedienung beinahe "selbsterklärend".
Man sollte sich aber trotzdem vom Systemhaus eine gute Einweisung geben lassen...
Wichtig ist, das man keine "linearen", sondern "virtuelle" LUN anlegt. Diese lassen sich bedeutend flexibeler handhaben als herkömmliche RAID Verbünde mit festen RAID Leveln.
Monitoring ist ebenfalls vorhanden:
Zum einen gibt es die Möglichkeit sich per Mail über Störungen und Ereignisse informieren zu lassen.
Dann gibt es einen (allerdings imho etwas "rudimentären") Performance Monitor in dem man sich das Leistungsverhalten des Array anzeigen lassen kann.
Und das Gerät ist natürlich SNMP fähig und kann so durch alle bekannten Systeme überwacht werden.
Eine direkte Integration in VSphere ist über OneView für VMWare möglich. Aber das habe ich noch nicht ausprobiert...
Zum Lesen (falls noch nicht bekannt):
http://h20195.www2.hpe.com/v2/redirect.aspx?/products/quickspecs/15935_ ...
http://h20195.www2.hpe.com/v2/redirect.aspx?/products/quickspecs/15936_ ...
Nicht unbedingt Brocade!
Es gibt bei HPE die "B" Serie (Brocade) und die "C" Serie (Cisco)
Die "B" Switche sind aber sicherlich die "gängigeren", da preiswerteren Modelle...
Ich verwende ein FC Fabric aus vier SN3000 /24Port Switchen, sowie zwei älteren 8Gbit Switchen für die Tape Librarys u.a.
Die Bedienung hat sich seit "Silkworm" Zeiten kaum verändert.
Es gibt bei HPE die "B" Serie (Brocade) und die "C" Serie (Cisco)
Die "B" Switche sind aber sicherlich die "gängigeren", da preiswerteren Modelle...
Ich verwende ein FC Fabric aus vier SN3000 /24Port Switchen, sowie zwei älteren 8Gbit Switchen für die Tape Librarys u.a.
Die Bedienung hat sich seit "Silkworm" Zeiten kaum verändert.
Hmmm...
-Dein Storage ist per FC angebunden
-Die Hosts sind per FC angebunden
-Deine Library ist per FC angebunden
-Dein B2D NAS ist per FC angebunden
-Der Backup Server ist es nicht?
Okay: Ich weis, das es Veeam mit FC Verbindungen nicht so "hat" und die MSA leider nicht, wie die 3PAR, StoreVirtual, oder Nimble direkte Snapshots zur SIcherung per Veeam freigeben kann. Aber:
Wie erreichen dann die Daten aus den ESX die Library?
Der Datentransport von der Vsphere (bzw. deren ESX Server) zum Veeam Server geht über das LAN.
Aber vom Veeam Server zu den "Backup Devices" muss es nach meinem Verständniss eine FC Verbindung geben!
Also sollte auch der Backup Server über eine FC Karte verfügen. Nicht in erster Linie für den Zugriff auf die MSA, aber für das weiterleiten der Daten auf das NAS und die Tapes...
-Dein Storage ist per FC angebunden
-Die Hosts sind per FC angebunden
-Deine Library ist per FC angebunden
-Dein B2D NAS ist per FC angebunden
-Der Backup Server ist es nicht?
Okay: Ich weis, das es Veeam mit FC Verbindungen nicht so "hat" und die MSA leider nicht, wie die 3PAR, StoreVirtual, oder Nimble direkte Snapshots zur SIcherung per Veeam freigeben kann. Aber:
Wie erreichen dann die Daten aus den ESX die Library?
Der Datentransport von der Vsphere (bzw. deren ESX Server) zum Veeam Server geht über das LAN.
Aber vom Veeam Server zu den "Backup Devices" muss es nach meinem Verständniss eine FC Verbindung geben!
Also sollte auch der Backup Server über eine FC Karte verfügen. Nicht in erster Linie für den Zugriff auf die MSA, aber für das weiterleiten der Daten auf das NAS und die Tapes...