Frage Achte nicht auf das SAN hinter dem Vorhang


Es war einmal, ich baute meine eigenen SQL-Server, und hatte die Kontrolle über die Laufwerkskonfiguration, RAID-Level, etc. Der traditionelle Rat der Trennung von Daten, Logs, Tempdb, Backups, (je nach Budget!) War immer ein ziemlich wichtiger Teil des SQL-Server-Design-Prozesses.

Jetzt mit einem Enterprise-Level-SAN, ich fordere nur eine bestimmte Menge Speicherplatz für einen neuen SQL-Server, der in logische Laufwerke für Daten, Sicherungen und Dateifreigaben unterteilt ist. Sicherlich macht es meine Arbeit leichter, aber es gibt einen Teil von mir, der sich nicht ganz wohl fühlt, dass ich nicht wirklich "hinter den Vorhang" schauen kann, um zu sehen, was wirklich dort vor sich geht.

Mein Verständnis ist, dass das SAN-Team nicht verschiedene "Typen" von Laufwerken anders konfiguriert (Optimierung von Datenlaufwerken für wahlfreien Zugriff 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 dynamischer Leistungskonfiguration durchführt (auf E / A-Hotspots achten und im laufenden Betrieb neu konfigurieren) Optimieren Sie diese LUNs), damit sich die App-Teams und DBAs um nichts kümmern müssen. Etwas über "die Last aller Server über eine große Anzahl von Spindeln verteilen" oder so ähnlich.

Meine Fragen / Diskussion:

  1. Wie kann ich mir selbst und den Anwendungsentwicklern versichern, dass unsere SQL-Server nicht unter schlecht konfiguriertem Speicher leiden, ohne sich Feinde im SAN-Team zu machen? Verwenden Sie einfach Perfmon Statistiken? Andere Benchmarks wie sqlio?

  2. Wenn ich einen Test auf diese SAN-Laufwerke lade, gibt mir das wirklich eine verlässliche, wiederholbare Messung dessen, was ich sehen werde, wenn wir live gehen? (Angenommen, die SAN-Software könnte sich zu verschiedenen Zeitpunkten "dynamisch konfigurieren".)

  3. Beeinflusst eine schwere IO in einem Teil des SAN (sagen wir der Exchange-Server) meine SQL-Server? (vorausgesetzt, sie geben keinem Server dedizierte Festplatten, von denen mir gesagt wurde, dass sie es nicht sind)

  4. Würden hier logische Laufwerke für verschiedene Funktionen (data vs log vs. tempdb) getrennt werden? Würde das SAN sehen die unterschiedlichen IO-Aktivitäten darauf und bestmöglich unterschiedlich konfigurieren?

  5. Momentan sind wir in einem engen Raum. Anwendungsteams werden angewiesen, Datenarchive usw. zu trimmen. Würden Platzprobleme dazu führen, dass das SAN-Team unterschiedliche Entscheidungen darüber trifft, wie sie internen Speicher (RAID-Level usw.) konfigurieren, der sich auf die Leistung meines Servers auswirken könnte?

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


35
2018-05-07 23:16


Ursprung


Sie müssen vorsichtig sein, Lasttests, da es andere Benutzer in der San-Region beeinflussen könnte - das war meine Erfahrung in unserer Umgebung sowieso. - Sam
Wenn ich könnte, würde ich dir einen zusätzlichen Zuschlag für den Titel geben. - splattne


Antworten:


Wie kann ich mir selbst und den Anwendungsentwicklern versichern, dass unsere SQL-Server nicht unter schlecht konfiguriertem Speicher leiden, ohne sich Feinde im SAN-Team zu machen? Verwenden Sie einfach Perfmon Statistiken? Andere Benchmarks wie sqlio?

Kurz gesagt, es gibt wahrscheinlich keinen Weg, wirklich sicher zu sein. Was ich sagen würde (ich bin ein SAN-Administrator), ist, dass, wenn Ihre Anwendungen Ihre Erwartungen erfüllen, machen Sie sich keine Sorgen darüber. Wenn Sie feststellen, dass Leistungsprobleme auftreten, von denen Sie glauben, dass sie mit der Leistung von SAN / Disk IO zusammenhängen könnten, sollten Sie nachfragen. Ich verwende nicht so 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 sie "schlecht" konfigurieren könnten. Die meisten Unternehmensspeicher in diesen Tagen erfordern viel Rätselraten beim Erstellen von Raid-Arrays und lassen Sie nicht wirklich falsch liegen. Wenn sie nicht die Laufwerksgeschwindigkeiten und -kapazitäten innerhalb der gleichen RAID-Gruppen mischen, können Sie in den meisten Fällen sicher sein, dass Ihre Festplatte einwandfrei funktioniert.

Wenn ich einen Test auf diese SAN-Laufwerke lade, gibt mir das wirklich eine verlässliche, wiederholbare Messung dessen, was ich sehen werde, wenn wir live gehen? (Angenommen, die SAN-Software könnte sich zu verschiedenen Zeitpunkten "dynamisch konfigurieren".)

Belastungstest sollte viel zuverlässig sein. Beachten Sie jedoch, dass beim Laden einer Box, die sich auf einem gemeinsam genutzten SAN / Disk-Array befindet, die Leistung von anderen Systemen mit demselben Speicher beeinträchtigt wird (und wird).

Beeinflusst eine schwere IO in einem Teil des SAN (sagen wir der Exchange-Server) meine SQL-Server? (vorausgesetzt, sie geben keinem Server dedizierte Festplatten, von denen mir gesagt wurde, dass sie es nicht sind)

Es kann. Es geht nicht nur um die Festplatten oder um welche Festplatten die Server laufen. Alle Daten werden über einen Festplattencontroller und dann über einen SAN-Switch bereitgestellt. Die Leistung, die Sie sehen werden, hängt stark davon ab, wie der Plattencontroller angeschlossen ist, die entsprechenden Plattenregale und das entsprechende SAN. Wenn das gesamte Array auf einem einzelnen Strang von 4-Gbit / s-Glasfaser an das Backbone-SAN angeschlossen wird, wirkt sich dies eindeutig auf die Leistung aus. Wenn das Array über zwei redundante SANs verbunden ist, die unter Verwendung von Bündelverbindungen lastverteilt sind, würde es unmöglich sein, allein durch den Austausch zu viel Bandbreite zu belegen. Eine andere Sache, die berücksichtigt werden muss, ist, wie viele IO / Sek das Array fähig ist. Solange das Array und das SAN, mit dem es verbunden ist, korrekt skaliert sind, sollte schweres IO in anderen Teilen der SAN-Umgebung die SQL-Leistung nicht beeinträchtigen.

Würden hier logische Laufwerke für verschiedene Funktionen (data vs log vs. tempdb) getrennt werden? Würde das SAN die verschiedenen IO-Aktivitäten auf diesen sehen und sie optimal anders konfigurieren?

Das ist wahrscheinlich eine Frage der Präferenz und hängt auch stark davon ab, wie Ihre Speicheradministratoren es konfigurieren. Sie könnten Ihnen drei LUNs im selben Array oder Volumen geben, in diesem Fall ist es trotzdem egal. Wenn sie Ihnen individuelle LUNs auf verschiedenen Arrays in verschiedenen Volumes (physisch unterschiedlichen Festplatten) gegeben haben, dann könnte es sich für Sie lohnen, sie zu trennen.

Momentan sind wir in einem engen Raum. Anwendungsteams werden angewiesen, Datenarchive usw. zu trimmen. Würden Platzprobleme dazu führen, dass das SAN-Team unterschiedliche Entscheidungen darüber trifft, wie sie internen Speicher (RAID-Level usw.) konfigurieren, der sich auf die Leistung meines Servers auswirken könnte?

Ich denke nicht, dass dein Speicheradministrator den Raid-Level ä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, aber normalerweise nicht auf eine leistungsbeeinflussende Weise. Sie werden vielleicht ein wenig enger darüber, wie viel Platz sie Ihnen geben. Sie können Funktionen wie die Datendeduplizierung aktivieren (wenn das Array dies unterstützt), die die Leistung des Arrays beeinträchtigen können, während der Prozess läuft, aber nicht rund um die Uhr.


16
2018-05-13 16:23



re: separate Laufwerke Ich erinnerte mich an unsere Serverleute, die sagten, dass dies die Leistung wegen einer Disk-Queue auf Betriebssystemebene verlangsamen würde. - Sam


Das SAN-Team sollte über Tools verfügen, mit denen Sie herausfinden können, ob Ihre App Hotspotting ist. Natürlich solltest du auch dein Ziel überwachen und messen.

Die meisten meiner Erfahrungen sind mit EMC so YMMV. Das Folgende sollte jedoch für die meisten SAN-Geräte gelten.

Es gibt nur so viele Ports, die in das Array gehen. Manchmal gibt es einen SAN-Switch, zwischen dem Sie Zonen definieren können. Nur weil das Array im Wesentlichen ein großer Speicherpool ist, heißt das nicht, dass Sie sich nicht um die IO-Leistung kümmern sollten.

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

Offensichtlich macht der zugrundeliegende Speicher einen Unterschied, sagen wir langsam große RAID5 vs schnelle RAID10 laufen, wie Sie irgendwann die Festplatte unabhängig von den verschiedenen Ebenen des Caches treffen müssen.

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


6
2018-05-08 00:17



+1 stimmte zu, und deshalb verwenden alle meine SQL Server sogar mit einem großen EMC SAN direkt angeschlossenen Speicher; Es entfernt eine Variable aus der Leistungsgleichung. Ich mag konsistente Leistungserwartungen, etwas, das in einer gemeinsamen Umgebung nicht möglich ist. - SqlACID
Beachten Sie, dass ich nicht sage, kein SAN zu verwenden. Ich habe einige ziemlich massive Rechenzentrums-Buildouts überwacht, die gut funktionieren. Umso wichtiger ist es, die Funktionsweise von IO auf verschiedenen Ebenen besser zu verstehen und dafür zu sorgen, dass sie gut zusammenarbeiten. - Jauder Ho
Danke für die ausführliche Antwort. Beachten Sie, dass ich keine habe Spezifisch (gemessen) Leistungsbedenken zu diesem Zeitpunkt. Ich versuche, auf einigen Servern einen Plan für ein Baseline-Benchmarking zu erstellen, da wir diese Dinge nicht routinemäßig verfolgen. Ich fühle mich mit der Handbewegung immer unbehaglicher. "Das SAN-Team hat alles im Griff" ohne Daten, die es unterstützen. Mir wurde auch gesagt, dass alles als RAID 5 konfiguriert wird, von dem ich weiß, dass es nicht immer die SCHNELLSTE Wahl ist. - BradC
Nun, Handwaving ist generell schlecht =) Jede Performance Arbeit sollte immer quantifizierbare Zahlen haben. RAID5 im Allgemeinen ist eine schlechte Idee für eine DB-Arbeitslast. Aber das ist nur meine Meinung. - Jauder Ho
Ich habe das schon mal über HP EVA SANs gesehen (IIRC das sind read-added Hitachi Kit). Da ich Leistungsprobleme mit einem SAN hatte, empfehle ich Ihnen, ein Referenzsystem mit Direct Attach-Speicher zu finden und auf beiden Plattformen einen Thrash-Test mit einer Beschreibung durchzuführen. Protokolle sind ein potenzieller Engpass in einer Datenbank. Im Allgemeinen wird es als am besten angesehen, diese auf einem separaten (und ruhigen) Datenträger zu haben. Ich bin ein wenig skeptisch, dass Sie in diesem SAN unter Last keine Leistungsprobleme sehen würden, aber der große Cache auf den Controllern sollte die E / A in den meisten Fällen glätten. - ConcernedOfTunbridgeWells


Wie kann ich mir selbst und den Anwendungsentwicklern versichern, dass unsere SQL-Server nicht unter schlecht konfiguriertem Speicher leiden, ohne sich Feinde im SAN-Team zu machen? Verwenden Sie einfach Perfmon Statistiken? Andere Benchmarks wie sqlio?

Das erste, was Sie wissen müssen, bevor Sie ein Benchmarking durchführen, ist, mit welcher Toleranz Ihre eigene Arbeitslast ausgeführt werden soll. Vergleichen Sie also Ihre eigenen Sachen, bevor Sie das neue System ausprobieren. Auf diese Weise können Sie feststellen, dass Sie bei Spitzenlasten (Backups?) Maximal 56 MB / s pushen und feststellen, dass das SAN-Attached Disk Array unter simulierten Lastspitzen nur 110 MB / s überträgt 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-Laufwerken), und ich musste mir selbst versichern, dass es in unserer Umgebung funktionieren würde. Ich war zutiefst zweifelhaft. Aber nach der Charakterisierung fand ich heraus, dass das neue System genügend I / O-Overhead unter dem Peak hatte, um mit dem gemessenen Peak auf den zuverlässigeren Disks Schritt zu halten. Es überrascht mich.

Wenn ich einen Test auf diese SAN-Laufwerke lade, gibt mir das wirklich eine verlässliche, wiederholbare Messung dessen, was ich sehen werde, wenn wir live gehen? (Angenommen, die SAN-Software könnte sich zu verschiedenen Zeitpunkten "dynamisch konfigurieren".)

Aufgrund der gemeinsamen Natur von SAN-Festplattenanordnungen ist die Leistung über die Woche hinweg variabel. Wenn Sie bereits wissen, wann Ihre Spitzen-E / A-Last ist, führen Sie eine Reihe von Lasttests während der Tageszeit durch, zu der die Spitzen-E / A-Last liegt. Auf diese Weise können Sie besser charakterisieren, welche Art von E / A-Overhead in den Zeiträumen verfügbar ist, in denen Sie am meisten interessiert sind. Lasttests außerhalb der Spitzenzeiten geben Ihnen ein Gefühl dafür, wie 'knackige' Dinge ankommen, aber Peak-Tests geben Sie wahre Grenzen Überprüfung.

Beeinflusst eine schwere IO in einem Teil des SAN (sagen wir der Exchange-Server) meine SQL-Server? (vorausgesetzt, sie geben keinem Server dedizierte Festplatten, von denen mir gesagt wurde, dass sie es nicht sind)

Wenn die Exchange-LUNs Festplatten mit Ihren SQL-LUNs gemeinsam nutzen, werden sie dies auch tun. Wir verwenden HP EVAs, keine XPs, aber ich denke, sie verwenden die gleiche "Disk-Group" -Terminologie. LUNs in derselben Festplattengruppe verwenden Festplatten gemeinsam und konkurrieren daher auf diesen physischen Geräten um I / O. Je mehr Festplatten Sie in eine Festplattengruppe legen, desto mehr Spielraum muss das Array mit I / O jonglieren. Die Arrays (zumindest die EVAs machen das, und ich nehme an, dass die teureren XPs dasselbe tun) verteilen logische LUN-Blöcke auf den physischen Festplatten auf nicht-sequentielle Weise. Dadurch können Sie das tun, was Sie vorschlagen, indem Sie Gruppen häufig aufgerufener Blöcke dynamisch auf verschiedene physische Geräte verteilen, um die Parallelität zu erhöhen und die E / A-Konkurrenz auf der Festplattenebene zu reduzieren.

Es stellt sich die Frage, wie viel E / A-Budget diese Datenträgergruppe hat und ob die Anwendungen, die diese LUNs verwenden, für E / A überzeichnet sind. Das ist eine Frage, die die Speicheradministratoren im Auge behalten müssen. Es könnte sein, dass die Spitzen-E / A für Exchange (wahrscheinlich während der Backups) nicht mit den SQL-Ladevorgängen übereinstimmen und beide Systeme problemlos nebeneinander bestehen können.

Würden hier logische Laufwerke für verschiedene Funktionen (data vs log vs. tempdb) getrennt werden? Würde das SAN die verschiedenen IO-Aktivitäten auf diesen sehen und sie optimal anders konfigurieren?

Für die HP-Arrays müssten Sie die verschiedenen I / O-Muster auf verschiedene Datenträger kopieren Gruppen nicht LUNs. Datenbank-E / A-Muster sollten nicht gleichzeitig mit Web-Serving-Zugriffsmustern existieren. Unterschiedliche LUNs verbessern Ihre Leistung nur dann merklich, wenn sie sich in unterschiedlichen Datenträgergruppen befinden. Wenn sie sich in der gleichen Plattengruppe befinden, ist der einzige wirkliche Vorteil für das Betriebssystem, wo es E / A-Planung im Kernel durchführen kann, um die Parallelität zum Plattensubsystem zu verbessern. Das gesagt...

Die HP-Arrays sind meines Wissens sowieso unterschiedlichen Zugriffsmustern auf LUNs bewusst, achten aber genau auf die tatsächlichen logischen Blöcke. Wenn Sie die Protokolle an eine andere LUN anhängen, werden die logischen Blöcke gebunden, die diesen E / A-Datenverkehr erhalten, und das erleichtert das Sortieren logischer Blöcke auf den physischen Festplatten.

Momentan sind wir in einem engen Raum. Anwendungsteams werden angewiesen, Datenarchive usw. zu trimmen. Würden Platzprobleme dazu führen, dass das SAN-Team unterschiedliche Entscheidungen darüber trifft, wie sie internen Speicher (RAID-Level usw.) konfigurieren, der sich auf die Leistung meines Servers auswirken könnte?

Bestimmt. Wenn der Platz knapp ist, erhalten Sie keine dedizierten Plattengruppen für Ihre E / A (es sei denn, Ihre Speicherumgebung ist groß genug, um die Zuweisung von 7 TB physischer Festplatte für Ihre ausschließliche Verwendung zu rechtfertigen, zu welchem ​​Zeitpunkt dies der Fall sein könnte ). Die Raid5 / Raid10-Debatte hängt zu einem großen Teil von den Richtlinien der Organisation ab, und Fragen sind Ihre beste Wette.


5
2018-05-18 20:28





Ich schlage vor, einen Dialog mit Ihrem SAN-Team und Ihrem Händler zu eröffnen, um Ihre Bedenken zu beheben. Eines der Probleme, die Sie bei der Ausführung 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 haben tonnenweise batteriegepufferten Cache, der in vielen Fällen (insbesondere wenn Sie synthetische Benchmarks ausführen) bedeutet, dass Sie in den RAM schreiben und eine kick-ass-Leistung erzielen.

Abhängig von Ihrer Umgebung und der von Ihnen verwendeten Lösung kann es sein, dass einige Hersteller CE gerade eingeflogen sind und das SAN gemäß den von ihm bevorzugten Standards eingerichtet haben. Das passiert mehr als du denkst. Sie müssen die Shell "Das SAN-Team kennt alle" verlassen, bis Sie sicher sind, dass die Lösung Ihren Anforderungen entspricht.

Viel Glück.


1
2018-05-10 03:16





Ich war einmal auf einer Orakelkonferenz mit einem Vortrag über dieses Thema - SANE für Datenbanken.

Der Hauptteil des Vortrags ist verfügbar in diese PDF-Datei oder auf der Website des Autors Hier


1
2018-05-18 19:58



Interessant. Er plädiert dafür, immer auf dedizierten Laufwerken im SAN für jede Oracle db zu bestehen. - BradC