
Haben Sie gute oder schlechte Erfahrungen mit dem Betrieb von SQL Server OLTP-Systemen auf NetApp-Geräten, die Sie teilen möchten? Ich habe mit einem kleinen, relativ kleinvolumigen Cluster mit einem NetApp-Gerät der unteren Preisklasse gearbeitet und fand die Umgebung im Allgemeinen instabil, zumindest im Vergleich zu meinen Erfahrungen mit anderen SANs, iSCSI-Arrays und DAS-Setups. Ich kann kaum glauben, dass RAID DP und WAFL mehr als nur Feenstaub-Technologien sind. Mir wurde als Lösung vorgeschlagen, dass ich nur ein größeres, besseres NetApp mit PAM-Karten und anderer cooler Technologie brauche, von der ich noch nie gehört habe, und ich denke, ich wäre besser dran, wenn ich ein Viertel davon für gute direkt angeschlossene Laufwerke und einen leistungsstarken Server ausgeben würde. Gleichzeitig bin ich der Meinung, dass ein SAN der Enterprise-Klassesollenetwas sein, auf das ich mich verlassen kann, dass es durchweg stabiler und leistungsfähiger ist als die weniger teure Lösung, die ich vorschlagen könnte. Sind Sie ein SQL Server DBA in einer OLTP-Umgebung und lieben Ihre NetApp? Wenn Sie sie nicht mögen, warum nicht?
Antwort1
SQL Server kann nicht (oder zumindest nicht seit Kurzem) mit einem freigegebenen SMB-Volume arbeiten, da SMB die erforderliche Dateisperrsemantik nicht unterstützt. Dazu benötigen Sie LUNs, die über iSCSI, FC über Ethernet oder Fibre Channel verfügbar sind. Wenn Sie NetApp als Filer verwenden, der SMB-Volumes freigibt, könnte dies die Ursache Ihres Problems sein.
Kaufen Sie ein SAN, wenn Sie SAN-Funktionen (Snapshot-Backups usw.) möchten, andernfalls kaufen Sie den Direct-Attach-Speicher. Wenn Sie wirklich nur eine Box mit SQL Server möchten, um ein Portfolio von Apps mit mäßiger Belastung zu unterstützen, reicht wahrscheinlich eine einzelne große SQL Server-Box mit Direct-Attach-Speicher aus. Sie ist billiger, schneller und kostet Sie wahrscheinlich weniger SQL Server-Lizenzen.
Für einige große Werte reicht wahrscheinlich eine Standard-Nelahem-Box mit zwei Sockeln wie eine DL380 G6 aus. Diese kostet Sie eine SQL Server-Lizenz im Wert von zwei Sockeln, verfügt über 8 Kerne und benötigt bis zu 192 GB RAM. Sie kann intern 16 Festplatten aufnehmen und Sie können 100 oder mehr extern mit Standardcontroller und externen Regaloptionen (MSA70) anschließen. Die meisten anderen Anbieter bieten eine Box mit ähnlichen Spezifikationen an.
Wenn Sie SQL Server EE verwenden, sind die Kosten für die Maschine und eine DR-Box wahrscheinlich geringer als für die SQL Server-Lizenz für zwei Sockel. Wenn Sie klein anfangen, belegen Sie nur einen Sockel und sparen Sie 20.000 USD oder mehr bei der Lizenz.
Ich denke, diese Art von Box wird unterschätzt und wird es heutzutage noch mehr – da VMs und Blades jetzt der letzte Schrei sind. Dies ist jedoch eine wirklich leistungsstarke Maschine, die eine ziemlich aggressive Datenbankarbeitslast für nur zwei Sockets einer SQL Server-Lizenz unterstützen kann. Wenn Sie derzeit ein Low-End-SAN verwenden, ist dies günstiger und bietet eine um Längen bessere Leistung.
Antwort2
Wenn Sie nur MSSQL in einem Cluster ausführen möchten, dann würde ich Ihnen ein dediziertes 8-Gbit/s-FC-Array empfehlen – vor allem, wenn die Leistung unter Last im Vordergrund steht und der Endpreis weniger wichtig ist. Wenn Sie kein Clustering benötigen, ist der obige Beitrag von CoTW natürlich ein starkes Argument für DAS (ich liebe MSAs auch ;))
Wir verwenden hauptsächlich HDS/HP-XP und HP-EVA, haben aber trotzdem jede Menge NetApps-Boxen im Haus, einfach weil sie ein wirklich guter Kompromiss sind. Eine einzige Box zu haben, die bei all diesen Protokollen oft mehr als gut genug ist, kann ein echter Segen sein. Allerdings sind sie meiner Meinung nach bei FC/FCoE nicht annähernd so gut wie dedizierte Boxen und für iSCSI/NFS nicht viel besser als OpenFiler usw. – ich denke auch, dass es eine Schweinerei ist, sie von „Bare Metal“ aus einzurichten, wenn man eine einigermaßen komplexe Umgebung hat. Aber es lässt sich nicht leugnen, dass NetApps für viele Leute sehr wertvoll erscheinen, ich persönlich habe nur meine Zweifel.