Achten Sie nicht auf das SAN hinter dem Vorhang

Es war einmal eine Zeit, in der ich meine eigenen SQL-Server baute und die Laufwerkskonfiguration, RAID-Level usw. kontrollierte. Der traditionelle Ratschlag zur Trennung von Daten, Protokollen, Tempdb und Backups (je nach Budget!) War immer ein ziemlich wichtiger Teil des SQL Server-Entwurfsprozesses.

Bei einem SAN auf Unternehmensebene fordere ich nur eine bestimmte Menge an Speicherplatz für einen neuen SQL-Server an, der in logische Laufwerke für Daten, Sicherungen und Dateifreigaben unterteilt ist. Das erleichtert mir sicherlich die Arbeit, aber es gibt einen Teil von mir, der sich nicht so wohl fühlt, dass ich nicht wirklich "hinter die Kulissen" gucken kann, um zu sehen, was dort wirklich los ist.

Meines Wissens nach konfiguriert das SAN-Team die verschiedenen Laufwerkstypen nicht unterschiedlich (Optimieren von Datenlaufwerken für den Direktzugriff im Vergleich zu Protokolllaufwerken für Streaming-Schreibvorgänge). Einige davon hängen möglicherweise vom SAN-Produkt selbst ab (wir haben einen HP XP12000 und einen HP XP24000), aber mir wurde versichert, dass die HP Software alle Arten von dynamischen Leistungskonfigurationen durchführt (nach E / A-Hotspots suchen und im laufenden Betrieb neu konfigurieren) Optimieren Sie diese LUNs, damit sich die App-Teams und DBAs um nichts mehr kümmern müssen. Etwas über "die Last aller Server auf eine große Anzahl von Spindeln verteilen" oder so ähnlich.

Meine Fragen / Diskussion:

1. Wie kann ich mich und die Anwendungsentwickler vergewissern, dass unsere SQL-Server nicht unter schlecht konfiguriertem Speicher leiden, ohne dass das SAN-Team Feinde hat? Verwenden Sie einfach perfmon Statistiken? Andere Benchmarks wie sqlio?

2. Wenn ich Tests auf diesen SAN-Laufwerken lade, kann ich dann wirklich zuverlässig und reproduzierbar messen, was ich sehen werde, wenn wir live gehen? (Unter der Annahme, dass die SAN-Software zu verschiedenen Zeitpunkten möglicherweise unterschiedlich dynamisch konfiguriert wird.)

3. Beeinflusst eine hohe E / A-Belastung in einem Teil des SAN (z. B. dem Exchange-Server) meine SQL-Server? (Unter der Annahme, dass sie nicht jedem Server dedizierte Festplatten zuweisen, was, wie mir mitgeteilt wurde, nicht der Fall ist)

4. Wäre es hier hilfreich, logische Laufwerke für verschiedene Funktionen zu trennen (Daten vs. Protokoll vs. Tempdb)? Würde das SAN sieht die verschiedene IO - Aktivität auf diesem und diese optimal anders konfigurieren?

5. Wir sind gerade in einer Weltraumkrise. Anwendungsteams werden aufgefordert, Datenarchive usw. zu kürzen. Würden das SAN-Team aufgrund von Platzproblemen unterschiedliche Entscheidungen bezüglich der Konfiguration des internen Speichers (RAID-Level usw.) treffen, die sich auf die Leistung meines Servers auswirken könnten?

Vielen Dank für Ihre Gedanken (ähnliches Thema in dieser SF-Frage kurz besprochen )

Wie kann ich mich und die Anwendungsentwickler vergewissern, dass unsere SQL-Server nicht unter schlecht konfiguriertem Speicher leiden, ohne dass das SAN-Team Feinde hat? Verwenden Sie einfach perfmon Statistiken? Andere Benchmarks wie sqlio?

Kurz gesagt, es gibt wahrscheinlich keinen Weg, um wirklich sicher zu sein. Ich würde sagen (ich bin ein SAN-Administrator), dass Sie sich keine Sorgen machen müssen, wenn Ihre Anwendungen Ihren Erwartungen entsprechen. Wenn Sie Leistungsprobleme feststellen, von denen Sie glauben, dass sie mit der SAN / Disk IO-Leistung zusammenhängen, ist es möglicherweise ratsam, nachzufragen. Ich verwende nicht viel HP-Speicher wie Sie, aber in der IBM / NetApp-Welt kann ich aus Erfahrung sagen, dass es nicht viele Optionen gibt, mit denen Sie ihn "schlecht" konfigurieren können. Heutzutage ist es für die meisten Unternehmen ein Rätsel, Raid-Arrays zu erstellen, und man kann es nicht wirklich falsch machen. In den meisten Fällen können Sie sicher sein, dass Ihre Festplatte einwandfrei funktioniert, es sei denn, sie mischen Laufwerksgeschwindigkeiten und -kapazitäten innerhalb derselben RAID-Gruppen.

Wenn ich Tests auf diesen SAN-Laufwerken lade, kann ich dann wirklich zuverlässig und reproduzierbar messen, was ich sehen werde, wenn wir live gehen? (Unter der Annahme, dass die SAN-Software zu verschiedenen Zeitpunkten möglicherweise unterschiedlich dynamisch konfiguriert wird.)

Belastungstests sollten ausreichend zuverlässig sein. Beachten Sie jedoch, dass beim Testen einer einzelnen Box auf einem gemeinsam genutzten SAN / Disk Array die Leistung durch andere Systeme beeinträchtigt werden kann (und wird), die denselben Speicher verwenden.

Beeinflusst eine hohe E / A-Belastung in einem Teil des SAN (z. B. dem Exchange-Server) meine SQL-Server? (Unter der Annahme, dass sie nicht jedem Server dedizierte Festplatten zuweisen, was, wie mir mitgeteilt wurde, nicht der Fall ist)

Es kann. Es geht nicht nur um die Festplatten oder um die Festplatten, auf denen sich die Server befinden. Alle Daten werden über einen Festplattencontroller und anschließend über einen SAN-Switch bereitgestellt. Die Leistung, die Sie sehen werden, hängt stark davon ab, wie der Festplattencontroller mit den entsprechenden Festplattenregalen und dem entsprechenden SAN verbunden ist. Wenn das gesamte Array über einen einzelnen 4-Gbit / s-Faserstrang mit dem Backbone-SAN verbunden wird, wirkt sich dies eindeutig auf die Leistung aus. Wenn das Array über zwei redundante SANs mit Lastenausgleich und Bündelverbindungen verbunden ist, kann der Austausch allein nicht zu viel Bandbreite beanspruchen. Eine andere Sache, die berücksichtigt werden muss, ist, wie viele IO / sec das Array fähig ist. Solange das Array und das SAN, mit dem es verbunden ist, korrekt skaliert sind,

Wäre es hier hilfreich, logische Laufwerke für verschiedene Funktionen zu trennen (Daten vs. Protokoll vs. Tempdb)? Würde das SAN die verschiedenen E / A-Aktivitäten auf diesen sehen und sie optimal anders konfigurieren?

Dies ist wahrscheinlich eine Frage der Präferenz und hängt auch stark davon ab, wie Ihre Speicheradministratoren dies konfigurieren. Sie könnten Ihnen drei LUNs im selben Array oder Volume geben, in diesem Fall ist es sowieso egal. Wenn Sie einzelne LUNs auf verschiedenen Arrays, auf verschiedenen Volumes (physisch verschiedenen Festplatten) erhalten haben, ist es möglicherweise sinnvoll, diese zu trennen.

Wir sind gerade in einer Weltraumkrise. Anwendungsteams werden aufgefordert, Datenarchive usw. zu kürzen. Würden das SAN-Team aufgrund von Platzproblemen unterschiedliche Entscheidungen bezüglich der Konfiguration des internen Speichers (RAID-Level usw.) treffen, die sich auf die Leistung meines Servers auswirken könnten?

Ich kann mir nicht vorstellen, dass Ihr Speicheradministrator die RAID-Stufe ändern würde, um Speicherplatz freizugeben. Wenn er würde, sollte er wahrscheinlich gefeuert werden. Platzprobleme können dazu führen, dass Dinge anders konfiguriert werden, jedoch normalerweise nicht in einer Weise, die die Leistung beeinträchtigt. Sie werden möglicherweise etwas enger, wenn es darum geht, wie viel Platz sie Ihnen geben. Sie können Funktionen wie die Datendeduplizierung aktivieren (sofern das Array dies unterstützt), die die Leistung des Arrays beeinträchtigen können, während der Prozess ausgeführt wird, jedoch nicht rund um die Uhr.

Das SAN-Team sollte über Tools verfügen, mit denen Sie erkennen können, ob es sich bei Ihrer App um Hotspotting handelt. Natürlich sollten Sie auch an Ihrem Ende überwachen und messen.

Die meiste Erfahrung habe ich mit EMC gemacht, also mit YMMV. Das Folgende sollte jedoch für die meisten SAN-Geräte gelten.

Es gehen nur so viele Ports in das Array. Manchmal gibt es dazwischen einen SAN-Switch, zwischen dem Sie Zonen definieren können. Nur weil es sich bei dem Array im Wesentlichen um einen großen Speicherpool handelt, sollten Sie sich keine Gedanken über die E / A-Leistung machen.

Wenn Sie also das Gefühl haben, IO-Probleme zu haben, müssen Sie den Engpass eingrenzen. Befindet sich der HBA irgendwo zwischen dem HBA und dem Array, können Sie herausfinden, ob der HBA maximal ausgelastet ist oder ob der SAN-Port auf der Switch- / Array-Seite überzeichnet ist. Darüber hinaus sollte das SAN-Team die Zugriffsmuster für Ihre App überwachen, sowohl nach einem Kaltstart als auch nach einem Warmstart.

Offensichtlich macht der zugrunde liegende Speicher einen Unterschied, wenn Sie langsames RAID5 oder schnelles RAID10 verwenden, da Sie irgendwann auf die Festplatte zugreifen müssen, unabhängig von den verschiedenen Cache-Ebenen.

HTH. Sie können mich offline anpingen, wenn Sie ein bestimmtes Problem haben, da das Durchsuchen eine Weile dauern kann.

Wie kann ich mich und die Anwendungsentwickler vergewissern, dass unsere SQL-Server nicht unter schlecht konfiguriertem Speicher leiden, ohne dass das SAN-Team Feinde hat? Verwenden Sie einfach perfmon Statistiken? Andere Benchmarks wie sqlio?

Das erste, was Sie wissen müssen, bevor Sie ein Benchmarking durchführen, ist die Toleranz, unter der Ihre eigene Workload ausgeführt werden muss. Vergleichen Sie also Ihre eigenen Daten, bevor Sie sich das neue System ansehen. Wenn Sie also feststellen, dass Sie bei Spitzenlasten (Backups?) Maximal 56 MB / s erreichen und feststellen, dass das SAN-verbundene Festplatten-Array bei simulierten Spitzenlasten „nur“ 110 MB / s erreicht, können Sie dies tun versichert, dass das Limit nicht der I / O-Kanal sein wird.

Beim Auschecken eines neuen Festplatten-Arrays habe ich diese Art von Leistungstests durchgeführt. Das neue Array verwendete SATA-Laufwerke anstelle von Fibre-Channel-Laufwerken (SCSI), und ich musste mir versichern, dass es in unserer Umgebung funktionieren würde. Ich war zutiefst zweifelhaft. Aber nach der Charakterisierung stellte ich fest, dass das neue System unter Peak genügend I / O-Overhead hatte, um mit dem gemessenen Peak auf den zuverlässigeren Festplatten Schritt zu halten. Es überrascht mich.

Wenn ich Tests auf diesen SAN-Laufwerken lade, kann ich dann wirklich zuverlässig und reproduzierbar messen, was ich sehen werde, wenn wir live gehen? (Unter der Annahme, dass die SAN-Software zu verschiedenen Zeitpunkten möglicherweise unterschiedlich dynamisch konfiguriert wird.)

Aufgrund der gemeinsamen Nutzung von SAN-Festplattenarrays ist die Leistung über die Woche unterschiedlich. Wenn Sie bereits wissen, wann Ihre E / A-Spitzenlast ist, führen Sie eine Reihe von Belastungstests zu der Tageszeit durch, zu der Ihre E / A-Spitzenlast ist. Auf diese Weise können Sie besser charakterisieren, welche Art von I / O-Overhead in den Zeiträumen verfügbar ist, an denen Sie am meisten interessiert sind. Durch Lasttests außerhalb der Stoßzeiten erhalten Sie ein Gefühl dafür, wie "bissig" die Dinge werden, aber durch Spitzenprüfungen geben Sie wahre Grenzen zu überprüfen.

Beeinflusst eine hohe E / A-Belastung in einem Teil des SAN (z. B. dem Exchange-Server) meine SQL-Server? (Unter der Annahme, dass sie nicht jedem Server dedizierte Festplatten zuweisen, was, wie mir mitgeteilt wurde, nicht der Fall ist)

Wenn die Exchange-LUNs Festplatten mit Ihren SQL-LUNs gemeinsam nutzen, werden sie dies auf jeden Fall tun. Wir verwenden HP EVAs, keine XPs, aber ich denke, sie verwenden die gleiche Terminologie für "Festplattengruppen". LUNs in derselben Datenträgergruppe geben Datenträger frei und kämpfen daher auf diesen physischen Geräten um E / A. Je mehr Datenträger Sie in eine Datenträgergruppe einfügen, desto mehr Spielraum muss das Array für die I / O-Jonglierung haben. Die Arrays (zumindest die EVAs tun dies, und ich nehme an, die teureren XPs tun dasselbe) verteilen logische LUN-Blöcke nicht sequentiell auf die physischen Festplatten. Auf diese Weise können die von Ihnen vorgeschlagenen Aktionen ausgeführt werden. Dabei werden Gruppen von Blöcken, auf die häufig zugegriffen wird, dynamisch auf verschiedene physische Geräte verteilt, um die Parallelität zu erhöhen und E / A-Konflikte auf Festplattenebene zu reduzieren.

Die Frage ist, über wie viel E / A-Budget diese Datenträgergruppe verfügt und ob die Anwendungen, die diese LUNs verwenden, für E / A überzeichnet sind. Das ist eine Frage, die die Storage-Administratoren im Auge behalten müssen. Möglicherweise stimmen die Spitzen-E / A-Vorgänge für Exchange (möglicherweise während der Sicherungen) nicht mit den SQL-Ladevorgängen überein, und beide Systeme können problemlos koexistieren.

Wäre es hier hilfreich, logische Laufwerke für verschiedene Funktionen zu trennen (Daten vs. Protokoll vs. Tempdb)? Würde das SAN die verschiedenen E / A-Aktivitäten auf diesen sehen und sie optimal anders konfigurieren?

Für die HP Arrays müssen Sie die verschiedenen E / A-Muster in verschiedene Datenträgergruppen und nicht in LUNs einteilen . Beispielsweise sollten Datenbank-E / A-Muster nicht mit Zugriffsmustern für Web-Serving koexistieren. Verschiedene LUNs verbessern Ihre Leistung nur dann merklich, wenn sie sich in verschiedenen Datenträgergruppen befinden. Wenn sie sich in derselben Datenträgergruppe befinden, hat das Betriebssystem den einzigen wirklichen Vorteil, dass es die E / A-Planung im Kernel durchführen kann, um die Parallelität zum Datenträgersubsystem zu verbessern. Das gesagt...

Soweit ich weiß, kennen die HP Arrays unterschiedliche Zugriffsmuster auf LUNs, achten jedoch genau auf die tatsächlichen logischen Blöcke. Wenn Sie die Protokolle auf einer anderen LUN ablegen, werden die logischen Blöcke, die diese Art von E / A-Verkehr erhalten, eingeschränkt, und die Aufgabe wird erleichtert, die logischen Blöcke auf den physischen Datenträgern richtig zu sortieren.

Wir sind gerade in einer Weltraumkrise. Anwendungsteams werden aufgefordert, Datenarchive usw. zu kürzen. Würden das SAN-Team aufgrund von Platzproblemen unterschiedliche Entscheidungen bezüglich der Konfiguration des internen Speichers (RAID-Level usw.) treffen, die sich auf die Leistung meines Servers auswirken könnten?

Bestimmt. Wenn der Speicherplatz knapp ist, erhalten Sie keine dedizierten Datenträgergruppen für Ihre E / A (es sei denn, Ihre Speicherumgebung ist groß genug, um 7 TB physischen Datenträger für Ihre ausschließliche Verwendung zu reservieren. In diesem Fall ist dies möglicherweise der Fall ). Die Raid5 / Raid10-Debatte hängt zu einem großen Teil von den Richtlinien der Organisation ab, und Fragen ist die beste Wahl.

Ich schlage vor, einen Dialog mit Ihrem SAN-Team und Ihrem Lieferanten zu eröffnen, um Ihre Bedenken auszuräumen. Eines der Probleme, die Sie beim Ausführen Ihrer eigenen Benchmarks haben werden, ist, dass Ihre Tests möglicherweise keinen Einfluss darauf haben, was in der Produktion passiert, insbesondere bei Spitzenlasten. Die meisten SANs verfügen über Tonnen von batteriegepuffertem Cache, was in vielen Fällen (insbesondere wenn Sie synthetische Benchmarks ausführen) bedeutet, dass Sie in den Arbeitsspeicher schreiben und eine hervorragende Leistung erzielen.

Abhängig von Ihrer Umgebung und der von Ihnen verwendeten Lösung ist möglicherweise gerade ein Hersteller-CE eingeflogen und hat das SAN nach dem von ihm bevorzugten Standard eingerichtet. Das passiert mehr als du denkst. Sie müssen bei der Shell "Das SAN-Team kennt sich aus" abhauen, bis Sie sicher sind, dass die Lösung Ihren Anforderungen entspricht.

Viel Glück.

Ich war einmal auf einer Oracle-Konferenz mit einem Vortrag zu diesem Thema - SAN für Datenbanken.

Wesentlicher Inhalt des Vortrages ist verfügbar in dieser PDF - Datei oder auf der Autoren - Website hier