SQL Server - Trennen von Daten-, Protokoll- und TempDB-Dateien in einem SAN

Ich habe einen SQL Server mit einem SAN verbunden. Unser neuer Speicheranbieter empfiehlt, dass sich alle LUNs über das gesamte Festplattenarray erstrecken, bei dem es sich um RAID5 handelt. Normalerweise würde ich vom SAN-Administrator 3 separate LUNs (Daten, Protokoll und TempDB) anfordern. Ist es angesichts der Empfehlung des neuen Anbieters sinnvoll, separate LUNs zu erstellen? Oder würde ich die gleiche Leistung sehen, wenn alles in einer LUN wäre, da es sowieso alle Festplatten umfassen würde?

Großartiger Artikel hier, der aber meine genaue Situation nicht ganz anspricht: http://www.brentozar.com/archive/2008/08/sql-server-on-a-san-dedicated-or-shared-drives/

Eine zu berücksichtigende Sache ist, dass die Protokolldateien sequentielle Schreibvorgänge sind, während die Datendateien nicht sequentiell sind. Dies ist einer der Gründe für separate LUNs. Protokolldateien schreiben schneller, wenn sie sich auf einer eigenen LUN befinden, da die Spindeln nicht herumspringen müssen, sondern nur sequentiell schreiben. Wenn Sie eine Datendatei hinzufügen, müssen die Spindeln herumspringen und Sie verlieren etwas an Leistung. Ich hoffe, dass ich dort die richtige Terminologie habe, da ich mit SANs selbst nicht allzu vertraut bin. Die Idee dahinter sollte jedoch sein.

Häufig sind Herstellerempfehlungen falsch, wenn es um SQL Server geht. Nur weil SQL Server andere Anforderungen hat als die meisten Anwendungen, die ein SAN verwenden.

Viel hängt vom SAN ab. Normalerweise möchten Sie verschiedene LUNs mit unterschiedlichen Caching-, Komprimierungs-, Verschlüsselungs-, Read-Ahead-, Write-Through- / Back-Richtlinien, Prioritäten usw. konfigurieren. Die SQL-Datendateien weisen häufig ein anderes Verhalten als die Tempdb oder das Protokoll auf Dateien. Die Zugriffsmethode / das Netzwerk kommt auch ins Spiel, da Trunking, Multi-Pathing und andere Technologien je nach Zugriffsmethode (FC, iSCSI, ..) und Infrastruktur möglicherweise funktionieren oder nicht. Sie möchten in der Lage sein, Ihr Netzwerk mit SQL Server maximal zu nutzen, da Latenz und Durchsatz von entscheidender Bedeutung sind. Ich habe Fälle mit Netzwerk-Teaming-Setup gesehen, aber aufgrund anderer Einschränkungen, die dem Client nicht bekannt waren, konnte nur 1 Gbit / s verwendet werden. Ich stimme Kenneth zu, nehme Herstellerempfehlungen mit einer großen Dosis Salz, sie sind ziemlich häufig falsch. SQL Server ist ein launisches Biest, Es gibt nur sehr wenige Absolute, normalerweise nur mehr Fragen. Die richtigen Fragen zu stellen (durch Testen) ist wirklich der Schlüssel.

Nehmen Sie keine "Empfehlungen von Anbietern mit einer großen Dosis Salz", es sei denn, diese stammen aus der Verkaufs- oder Marketingabteilung. Im Gegenteil, wenn Sie Zugang zu den Mitarbeitern der technischen Implementierung erhalten, schließen Sie Freunde.

Dies ist wahrscheinlich eine der neuen Appliances, die den Speicherpool virtualisieren und Auto-Tier-Funktionen enthalten. Ein Beispiel wäre Compellent . Sie führen alle Arten von SAN-Voodoo aus, wie zum Beispiel:

• Schreiben Sie aktive Datenblöcke mit leistungsoptimierten RAID-Levels wie RAID 10 in den Tier 1-Speicher.
• Migrieren Sie inaktive Datenblöcke automatisch in einen Speicher niedrigerer Ebene mit RAID 5 oder 6 mit höherem Overhead und hohem Schutz.

Für den Compellent ist der Speicher in drei Ebenen unterteilt, wobei Tier1 die schnellste (SSD oder RAID 10) bis hin zu träge Tier3 mit 7.000 SAS-Festplatten ist. Ich habe noch keine davon in einer Produktionsumgebung verwendet, habe aber Zugriff auf eine, gegen die ich hoffentlich einige Tests durchführen kann.

Ich gebe zu, sowohl fasziniert als auch ängstlich gegenüber den Auto-Tier-Funktionen zu sein, die auf dem Papier wunderbar klingen, aber in der Produktion möglicherweise problematisch sind. Das erste Beispiel, bei dem der Auto-Tier-Mechanismus möglicherweise beeinträchtigt wurde, waren Datenbanksicherungen. Dort haben Sie ein sich wiederholendes High-Write-Ziel, das den Tiering-Mechanismus dazu verleiten kann, die Blöcke in einen Hochleistungspool zu verschieben und möglicherweise Daten herauszuschieben, die dort vorhanden sein sollten.

Zur ursprünglichen Frage:

... macht es Sinn, separate LUNs zu erstellen?

Wahrscheinlich nicht, nein. Machen Sie dem Anbieter den Anwendungsfall klar, um sicherzugehen, aber wenn es sich um ein Gerät vom Typ Compellent handelt, glaube ich nicht, dass Sie durch die Aufteilung Ihrer LUNs etwas gewinnen.

Gibt es einen Grund, LUNs zu trennen? Fast immer. Andernfalls wird die LUN-Warteschlange auf dem Windows-Server überlastet. Unabhängig von Betriebssystem, Virtualisierung oder Speicherplattform ist es schmerzhaft, unter vollständigen Bedingungen zu leiden