SQL Server-Dateien lokal oder NAS oder SAN?

Ich muss einen neuen Server mit SQL Server 2008 installieren. Was empfehlen Sie? Einen Server mit Raid 10 oder die Dateien in einem NAS?

Was ist mit iSCSI, wenn ich es verwenden soll?

Was ist mit SAN?

Der Server verfügt über 4 GB RAM und diese Datenbankdatei umfasst ca. 2 GB.

Um zu verdeutlichen, dass der Server heute kein RAID hat, muss ich eine Strategie implementieren, damit meine Dateien sicher sind, wenn etwas passiert. Was soll ich also für Lokale Dateien, NAS, SAN wählen? Welche Option hat die meiste Leistung, welche ist sicherer?

NAS

Auf keinen Fall NAS für SQL Server. SMB / CIFS bietet keine ausreichende Unterstützung für die Dateisperrung, um ein DBMS zu unterstützen (zumindest vor einigen Jahren, ca. 2002-2003). Beachten Sie, dass NFS dies tut und Sie dies tatsächlich mit Oracle auf einem NFS-Server tun können. SQL Server auf einer CIFS-Freigabe ist jedoch aufgrund von Einschränkungen des Protokolls nicht zuverlässig. Sie können möglicherweise nicht einmal Dateien auf CIFS-gemounteten Freigaben ablegen.

SAN

Dies ist gut für Transaktionsanwendungen, da der Cache auf den RAID-Controllern sehr große Arbeitssätze aufnehmen kann. SAN-RAID-Controller unterstützen in der Regel mehr Cache als hostbasierte RAID-Controller, insbesondere in High-End-Kits, in denen ein RAID-Controller eine Multiprozessor-Box sein kann, die genauso leistungsfähig ist wie ein Server.

SANs mit zwei Controllern verfügen auch über eine Architektur ohne Single-Point-of-Failure und bieten viele Optionen für Hot-Backups. Dies macht sie aus Sicht der Verwaltbarkeit und Zuverlässigkeit zu einem Gewinn. Sie sind jedoch teuer und für das Streaming von Datenmengen beschränkt, obwohl es unwahrscheinlich ist, dass Letzteres ein Problem in einem Transaktionssystem darstellt.

Für Betriebssysteme sind SANs fast immer die beste Wahl, wenn sie verfügbar sind. Sie können auch von mehreren Servern mit Systemen mit niedrigem bis mittlerem Volumen gemeinsam genutzt werden. Sie kommen jedoch mit einem Preisschild, das dem kleinsten System, mit dem die Technologie verwendet werden kann, eine beträchtliche Untergrenze setzt.

Direkt anhängen

In einigen Fällen empfiehlt sich die direkte Speicherung von Anhängen. Eine Möglichkeit sind Streaming-Anwendungen mit eingeschränkter Bandbreite, bei denen die begrenzte Anzahl von Fibre-Channel-Verbindungen die verfügbare Bandbreite auf weniger beschränkt, als dies mit einem High-End-SAS-Controller möglich wäre. Diese sind jedoch wahrscheinlich ziemlich spezialisierte Anwendungen wie sehr großen Data Warehouse werden , wo eine Shared-Nothing - Architektur den besten Durchsatz liefern kann.

In der Tat ist Direct Attach Storage für Data Warehouse-Systeme aus mehreren Gründen häufig besser als ein SAN:

• In Data Warehouses werden die Festplattensubsysteme durch hohe vorübergehende Belastungsspitzen belastet. Dies macht sie in SANs ziemlich unsozial, da sie die Leistung anderer Systeme im SAN beeinträchtigen können.

• Der oben erwähnte Streaming-Engpass.

• Direct Attach-Speicher ist viel billiger als SAN-Speicher.

Ein weiterer Markt für Direct-Attach-Speicher ist der Verkauf an einen Markt, der nicht genug Geld für ein SAN zahlt. Dies gilt häufig für Anwendungen, die an KMU-Kunden verkauft werden. Für ein Point-of-Sale-System oder ein Praxismanagement-System mit sechs Benutzern ist ein SAN wahrscheinlich zu teuer. In solchen Situationen ist ein kleiner eigenständiger Tower-Server mit einigen internen Festplatten eine weitaus geeignetere Lösung.

Lokal oder SAN ist die einzige Möglichkeit, die Leistung aufrechtzuerhalten. In einigen Fällen kann SAN schneller als die lokale Festplatte sein, da der Schreibcache größer und der Datendurchsatz parallel konfiguriert ist.

Vermeiden Sie Hochleistungs-Datei-E / A über Windows-Freigaben. Es gibt einen großen Protokoll-Overhead, der den Durchsatz drastisch verlangsamt. Ich habe zum Beispiel vor Jahren gemessen, dass eine große Dateiübertragung über ein WAN mit FTP über Windows-Freigaben ~ 50% schneller war.

Verwenden Sie kein NAS.

Verwenden Sie entweder local (mittelfristig in Ordnung mit einem guten RAID-Controller), aber wenn das Budget dies zulässt, sollten Sie sich für ein anständiges SAN entscheiden. Mit etwas Glück können Sie damit beginnen, das SAN mit anderen Systemen zu "teilen" und einen Großteil des anfänglichen Aufwands zurückzufordern.

4 GB RAM sind für die meisten Systeme ausreichend, sofern es sich um einen dedizierten SQL Server handelt (und dies sollte immer der Fall sein). Wenn Sie dies noch nicht in Betracht gezogen haben, verwenden Sie ein 64-Bit-Betriebssystem und einen SQL-Server, damit Sie problemlos mehr RAM in das System stecken können, ohne sich mit PAE / AWE-Dingen herumärgern zu müssen.

Denken Sie auch an Virtualisierung. Benötigen Sie einen Testserver? Ein Entwickler-Server? Testen Sie die Installation von SP1? (Schamloses Plus für früheren Beitrag: sql-server-in-vmware )

Bei einer Datenbankgröße von 2 GB gibt es keinen Grund, überhaupt ein SAN in Betracht zu ziehen. Ein NAS funktioniert nicht. Sie sollten nur daran denken, ein NAS für Backups zu verwenden, damit Sie Backups nicht auf demselben Computer wie Ihre Daten speichern. Außerdem ist es einfach, Kopien vom NAS für die externe Speicherung zu erstellen.

Verwenden Sie bei einer kleinen Datenbank nur lokale Festplatten in einem RAID 1 oder RAID 10. Wenn Ihre Datenbank in den Arbeitsspeicher passt, müssen Sie sich nicht so viele Gedanken über die E / A-Leistung machen. Verwenden Sie 64-Bit-Fenster und geben Sie dort 8 Gigs ein. Das wird viel für das Betriebssystem übrig lassen und Ihnen Raum zum Wachsen geben.

Ich arbeite mit Systemen, die sowohl lokale RAID-Festplatten als auch Glasfaser-SANs verwenden. Das SAN scheint eine bessere Leistung zu erbringen, auch wenn das frühere eine neuere und schnellere Maschine ist. Ich denke, ein wesentlicher Faktor ist, dass die lokale Festplattenanordnung ein einzelnes Laufwerk ist, sodass SQL die Festplatten-E / A mit dem Betriebssystem und der Auslagerungsdatei gemeinsam nutzt. Dies trägt wahrscheinlich stark zum Luftwiderstand bei.

Wie @spoulson bereits erwähnt hat, kann das SAN eine weitaus bessere Festplattenleistung bieten. Es ist nicht nur ein separates Laufwerk, sondern wahrscheinlich auch eine viel schnellere Festplattenhardware.

In unserem Fall verwenden wir SAN, da es einen zentralisierten Speicherbereich für automatische Failover-VERITAS SQL Server-Dienstgruppen bietet. Wenn der primäre Computer ausfällt, werden die im SAN bereitgestellten Windows-Laufwerke erneut auf dem Hot-Backup-Computer bereitgestellt, und der Server wird ziemlich schnell wiederhergestellt. Dies setzt natürlich ein VERITAS-ähnliches System für die Verwaltung von Servicegruppen voraus, das möglicherweise außerhalb Ihres Anwendungsbereichs liegt.

Die einzige Einschränkung, mit der wir zu kämpfen haben, ist, dass die SAN-Speicherplatzzuweisung konservativ gehandhabt wird. Weil es teuer ist, wird es nicht aus einer Laune heraus verteilt. Mit dem von uns verwendeten EMC SAN können Sie keinen zugewiesenen Speicherplatz zurückfordern, ohne eine gesamte LUN zu sichern. Wenn wir also feststellen, dass der zugewiesene Speicherplatz mehr ist, als wir benötigen, und einen Teil dieses Speicherplatzes für eine andere LUN verwenden möchten, können wir den übergroßen nicht einfach verkleinern. Wir müssen es fallen lassen und neu zuweisen. Dies funktioniert in einer Produktionsumgebung nicht so gut.

Vermeiden Sie NAS, wie andere vorgeschlagen haben. Sie können Ihre Datendateien auch auf einer externen USB-Festplatte ablegen.

Für eine kleine Datenbank mit 2 GB wäre ein SAN ein Overkill.

Im Allgemeinen möchten Sie nicht, dass Ihre SQL-Laufwerke für andere Anwendungen freigegeben werden. Ebenso ist es umso besser, je mehr Spindeln (Festplatten) Sie Ihre Dateien verteilen können. Mit einer kleinen Datenbank, wie Sie sie beschreiben, können Sie alles, was Sie brauchen, in den Arbeitsspeicher einbauen, sodass die Festplattenleistung weniger von Bedeutung ist.

Das heißt, erstellen Sie kein einziges RAID-10-Volume und legen Sie ALLE Ihre Datenbankdateien darauf ab. Sie könnten mit etwas Einfachem beginnen, wie: Daten - 2x 73 GB 15 KB RPM, RAID1-Protokolle - 2x 73 GB 15 KB RPM, RAID1-Sicherungen - einzelne große 7200 RPM oder ein Paar in RAID1

Wenn Sie das Budget für ein Upgrade haben, fügen Sie ein weiteres separates Volume für TempDB hinzu (wenn Sie komplexe Berichts- / Analyse-Abfragen durchführen) oder geben Sie dem Protokoll-Volume mehr Festplatten und konfigurieren Sie es als RAID10, wenn Ihr System mehr Transaktionen mit einem hohen Volumen umfasst von Updates.

Ein SAN würde wahrscheinlich das 3-4-fache des direkt angeschlossenen Speichers für eine entsprechende Anzahl von Laufwerken kosten. SANs bieten viele erweiterte Funktionen für Backup / Snapshot, Clusterunterstützung und LUN-Migration und -Erweiterung. Wenn diese für Sie wichtig sind, ist es möglicherweise die zusätzlichen Kosten wert.

Haftungsausschluss: Es gibt viele schwerwiegende Probleme beim Speichern von SQL Server-Datenbankdateien auf einem NAS. Wenn alle anderen Optionen gleich sind, ist es richtig, die SAN-Option zu wählen. Eine ausführliche Diskussion der relevanten Themen finden Sie in MS KB304261 . Dieser Thread ist jedoch zu einem zentralen Anlaufpunkt für andere Fragen zu SQL Server auf einer Netzwerkfreigabe geworden. Ich möchte lieber Verweise auf den Status der NAS-Unterstützung in SQL Server-Versionen veröffentlichen.

Nicht wenige Leute experimentieren jetzt mit der Verwendung von NAS mit MS SQL.

Dies war bisher standardmäßig verboten, jedoch konnte man die Einschränkung in MS SQL 2008 und MS SQL 2005 aufheben. Seit MS SQL 2008 R2 gibt es keine solche Einschränkung.

In MS SQL 2005 und 2008 ist der Schlüssel das Ablaufverfolgungsflag, das die Verwendung von Netzwerkfreigaben verbietet. Man kann ausstellen

 DBCC TRACEON(1807, -1)
 CREATE DATABASE [test] ON  PRIMARY 
 ( NAME = N'test', FILENAME = N'\\storage\mssql_db\test.mdf' )

Weitere Details im September 2010 im MSDN-Blog von Varun Dhawan.

Zumindest technisch ist das Ausführen von SQL Server auf einem NAS möglich. Die Wahl hängt von vielen Faktoren ab, und es ist nicht schwer vorstellbar, dass auf einem NAS Speicherplatz für eine Datenbank zur Verfügung steht.