Frage SQL Server-Festplattenentwurf auf einem ISCSI-SAN


In der Regel werden Protokoll- und Datendateien auf separaten Festplatten getrennt vom Betriebssystem getrennt (tempdb, Backups und Swap-Datei auch) Ist diese Logik immer noch sinnvoll, wenn Ihre Laufwerke ausschließlich SAN-basiert sind und Ihre LUNs nicht aus bestimmten Festplatten- oder RAID-Sets bestehen - sie sind nur ein Teil der x Anzahl der Laufwerke im SAN und die LUN ist nur Speicherplatzzuweisung


27
2018-04-30 13:33


Ursprung




Antworten:


Protokolle und Datenlaufwerke weisen unterschiedliche Datenzugriffsmuster auf, die (zumindest in der Theorie) miteinander in Konflikt stehen, wenn sie sich ein Laufwerk teilen.

Protokoll schreibt

Der Protokollzugriff besteht aus einer sehr großen Anzahl von kleinen sequentiellen Schreibvorgängen. Etwas vereinfacht sind DB-Protokolle Ringpuffer, die eine Liste von Anweisungen zum Schreiben von Datenelementen an bestimmte Speicherorte auf der Platte enthalten. Das Zugriffsmuster besteht aus einer großen Anzahl von kleinen sequentiellen Schreibvorgängen, die garantiert abgeschlossen werden müssen - so dass sie auf die Festplatte geschrieben werden.

Idealerweise sollten Protokolle auf einem ruhigen RAID-1- oder RAID-10-Volume stehen (d. H. Nicht mit anderen geteilt werden). Logischerweise können Sie den Prozess als Haupt-DBMS-Protokolleinträge und einen oder mehrere Protokolllesethreads anzeigen, die die Protokolle konsumieren und die Änderungen auf die Datenplatten schreiben (in der Praxis wird der Prozess optimiert, sodass die Datenschreibvorgänge geschrieben werden sofort, wenn möglich). Wenn auf den Protokolldatenträgern anderer Datenverkehr vorhanden ist, werden die Köpfe durch diese anderen Zugriffe verschoben, und die sequentiellen Protokollschreibvorgänge werden zufällige Protokollschreibvorgänge. Diese sind viel langsamer, so dass ausgelastete Protokolldatenträger einen Hotspot erstellen können, der als Engpass für das gesamte System fungiert.

Datenschreibvorgänge

(aktualisiert) Protokollschreibvorgänge müssen auf dem Datenträger (bezeichnet als stabiles Medium) festgeschrieben werden, damit eine Transaktion gültig und für das Festschreiben geeignet ist. Man kann dies logischerweise als Protokolleinträge betrachten, die geschrieben werden, und dann als Anweisungen verwenden, um Datenseiten durch einen asynchronen Prozess auf die Platte zu schreiben. In der Praxis werden die Plattenseitenschreibvorgänge zum Zeitpunkt des Protokolleintrags tatsächlich vorbereitet und gepuffert, aber sie müssen nicht sofort geschrieben werden, damit die Transaktion festgeschrieben werden kann. Die Plattenpuffer werden durch den Lazy-Writer-Prozess auf stabile Medien (Platten) geschrieben (Danke an Paul Randal für das Aufzeigen), die Dieser Technet-Artikel diskutiert etwas detaillierter.

Dies ist ein stark wahlfreies Zugriffsmuster. Wenn Sie also die gleichen physikalischen Laufwerke mit Protokollen teilen, kann dies zu einem künstlichen Engpass bei der Systemleistung führen. Die Protokolleinträge müssen so geschrieben sein, dass die Transaktion festgeschrieben werden kann, sodass zufällige Suchvorgänge diesen Prozess verlangsamen (zufällige I / O-Vorgänge) viel langsamer als sequentielles Protokoll I / O) wird das Protokoll von einem sequentiellen in ein Gerät mit wahlfreiem Zugriff umwandeln. Dies führt zu einem schwerwiegenden Leistungsengpass auf einem ausgelasteten System und sollte vermieden werden. Dasselbe gilt für die Freigabe temporärer Bereiche mit Protokolldatenträgern.

Die Rolle des Caching

SAN-Controller haben in der Regel große RAM-Caches, die den Direktzugriffsverkehr in gewissem Umfang absorbieren können. Für transaktionale Integrität ist es jedoch wünschenswert, dass Plattenschreibvorgänge von einem DBMS garantiert abgeschlossen werden. Wenn ein Controller für die Verwendung von Write-Back-Caching eingerichtet ist, werden die fehlerhaften Blöcke zwischengespeichert und der E / A-Aufruf wird als abgeschlossen an den Host gemeldet.

Dies kann viele Konkurrenzprobleme ausgleichen, da der Cache eine Menge E / A absorbieren kann, die ansonsten auf die physische Festplatte gehen würden. Es kann auch die Paritätslese- und -schreibvorgänge für RAID-5 optimieren, was die Auswirkungen auf die Leistung von RAID-5-Volumes verringert.

Dies sind die Merkmale, die die Denkweise "Lass das SAN damit umgehen" vorantreiben, obwohl diese Sichtweise einige Einschränkungen hat:

  • Write-Back-Caching hat immer noch Fehlermodi, die Daten verlieren können, und der Controller hat mit dem DBMS geflockt, dass Blöcke auf die Festplatte geschrieben wurden, obwohl sie dies nicht getan haben. Aus diesem Grund empfiehlt es sich, das Write-Back-Caching für eine Transaktionsanwendung nicht zu verwenden. Dies gilt insbesondere für geschäftskritische oder finanzielle Daten, bei denen Datenintegritätsprobleme ernsthafte Konsequenzen für das Unternehmen haben können.

  • SQL Server (insbesondere) verwendet E / A in einem Modus, in dem ein Flag (FUA oder Forced Update Access) physische Schreibvorgänge auf den Datenträger erzwingt, bevor der Aufruf zurückgegeben wird. Microsoft hat eine Zertifizierungsprogramm und viele SAN-Anbieter produzieren Hardware, die diese Semantik berücksichtigt (Anforderungen zusammengefasst) Hier). In diesem Fall wird keine Cache-Menge die Schreibvorgänge auf der Festplatte optimieren, was bedeutet, dass der Protokollverkehr protokolliert wird werden Thrash wenn es auf einem geschäftigen geteilten Volume sitzt.

  • Wenn die Anwendung viel Festplattenverkehr generiert, kann ihr Arbeitssatz den Cache überschreiben, was ebenfalls zu Problemen bei der Schreibkonkurrenz führt.

  • Wenn das SAN für andere Anwendungen freigegeben ist (insbesondere auf demselben Datenträger), kann Datenverkehr von anderen Anwendungen Protokoll-Engpässe generieren.

  • Einige Anwendungen (z. B. Data Warehouses) erzeugen große transiente Lastspitzen, die sie auf SANs ziemlich asozial machen.

Auch in einem großen SAN werden separate Protokollvolumes empfohlen. Sie können damit davonkommen, sich nicht um Layout auf einer leicht genutzten Anwendung zu kümmern. Bei wirklich großen Anwendungen können Sie sogar von mehreren SAN-Controllern profitieren. Oracle veröffentlicht eine Reihe von Data Warehouse-Layout-Fallstudien, bei denen einige der größeren Konfigurationen mehrere Controller umfassen.

Übernehmen Sie die Verantwortung für die Leistung, wo sie hingehört

Stellen Sie das SAN-Team bei großen Volumes oder Problemen, bei denen die Leistung ein Problem darstellen könnte, für die Leistung der Anwendung zur Rechenschaft. Wenn sie Ihre Konfigurationsempfehlungen ignorieren, stellen Sie sicher, dass das Management sich dessen bewusst ist und dass die Verantwortung für die Systemleistung an der richtigen Stelle liegt. Definieren Sie insbesondere akzeptable Richtlinien für wichtige DB-Leistungsstatistiken wie E / A-Wartezeiten oder Wartezeiten für Seitenpufferungen oder akzeptable E / A-SLAs für Anwendungen.

Beachten Sie, dass die Verantwortung für die Aufteilung der Leistung auf mehrere Teams einen Anreiz bietet, mit dem Finger zu zeigen und das Geld an das andere Team weiterzugeben. Dies ist ein bekanntes Management-Anti-Pattern und eine Formel für Probleme, die Monate oder Jahre andauern, ohne jemals gelöst zu werden. Im Idealfall sollte ein einzelner Architekt die Berechtigung haben, Änderungen an Anwendungen, Datenbanken und SAN-Konfigurationen anzugeben.

Benchmark auch das System unter Last. Wenn Sie es arrangieren können, können Second-Hand-Server und Direct-Attach-Arrays bei Ebay recht günstig gekauft werden. Wenn Sie eine Box wie diese mit ein oder zwei Festplatten-Arrays einrichten, können Sie mit der physischen Festplattenkonfiguration kühlen und den Effekt auf die Leistung messen.

Als Beispiel habe ich einen Vergleich zwischen einer Anwendung in einem großen SAN (einem IBM Shark) und einer Zwei-Socket-Box mit einem Direct-Attach-U320-Array durchgeführt. In diesem Fall überstieg die von ebay gekaufte Hardware im Wert von 3.000 £ die Leistung eines High-End-SAN von 1 Mio. £ um den Faktor zwei - auf einem Host mit ungefähr gleicher CPU- und Speicherkonfiguration.

Aus diesem speziellen Vorfall könnte man argumentieren, dass es eine sehr gute Möglichkeit ist, SAN-Administratoren ehrlich zu halten, wenn sie so etwas herumliegen haben.


37
2018-05-15 08:57



Ist das ein Cut'n'Paste oder die beste Antwort auf Serverfault !!!!!! :) - Chopper3
Nein, ich bin nur eine schnelle Schreibkraft; -} - ConcernedOfTunbridgeWells
Du bist der Mann. - squillman
Zufälligerweise habe ich das aus einem Link gelesen, den Sie in eine andere Antwort eingefügt haben. Dieser Teil Ihrer Antwort ist falsch "Datenelemente werden vom Log-Reader auf die Datenplatten geschrieben. Dies verbraucht Protokolleinträge und schreibt die Datenelemente auf die Festplatte." Datenseitenschreibvorgänge werden von den Prüfpunkt- und Lazy-Writer-Prozessen im Pufferpool ausgeführt und haben überhaupt nichts mit Protokolllesevorgängen zu tun. Datenseitenschreibvorgänge generieren auch keine Protokolldatensätze. - Paul Randal
Gut beobachtet. Ich habe den Artikel aktualisiert, um es zu beheben. - ConcernedOfTunbridgeWells


Ich gehe davon aus, dass das Equallogic-Tag und der Inhalt der Anfrage bedeuten, dass Sie über ein Equallogic-SAN sprechen. Im Folgenden wird speziell auf Equallogic eingegangen, und es gilt nicht für andere SAN-Typen.

Mit Equallogic-Arrays können die spezifischen Datenträger, die für Datenträger verwendet werden, nicht so präzise angegeben werden, wie dies beispielsweise mit EMC Clariion-Arrays möglich ist. Daher muss der Ansatz ein wenig anders sein.

Equallogic Architektur ist sehr automatisiert und dynamisch. Der Grundbaustein ist die Array-Einheit, nicht RAID-Packs \ -Gruppen innerhalb eines Arrays, wie es in anderen SANs der Fall ist. Jedes Array ist vollständig für RAID 5, 6, 10 oder 50 konfiguriert, obwohl dies nicht bedeutet, dass es nur eine RAID-Gruppe pro Array gibt. Sie können auf dieser Ebene nie entscheiden oder mit ihnen interagieren. Sie platzieren Arrays in Speicherpools, und Ihre Pools gehören dann zu einer Speichergruppe. Die Speichergruppe verfügt über eine virtuelle Cluster-IP-Adresse, die Sie als iSCSI Discovery-Ziel für alle Volumes innerhalb dieser Gruppe verwenden. Die EQL-Gruppenverwaltungssoftware und der Host-MPIO-Stapel verarbeiten die Umleitung auf IP-Ebene, die zur Weiterleitung an den am besten geeigneten Port benötigt wird die einzelnen Arrays bei der Anforderung von Datenblöcken, aber das ist etwas, das Sie nicht oder nur sehr eingeschränkt steuern können.

Speichervolumes werden aus dem gesamten freien Speicherplatz in jedem Pool zugewiesen. Alle Volumes innerhalb eines Pools sind auf alle Arrays in diesem Pool verteilt (bis zu maximal 4 separate Arrays), um das Netzwerk-IO über die gesamte Anzahl von Netzwerkschnittstellen (2-4 pro EQL-Array je nach Modell) und E / A zu verteilen über so viele Controller wie möglich. Die Equallogic-Verwaltungssoftware überwacht die Leistung von Volumes und Arrays und optimiert dynamisch die Verteilung von Blöcken auf die Member-Arrays. Im Allgemeinen, wenn Sie nicht wissen, was Sie tun, sollten Sie alle Arrays in einen einzigen Pool und lassen Sie es tun, denken Sie daran, dass Sie Ihre High-Speed-Festplatten (SAS 10k \ 15k) mit RAID 10, mittlere Geschwindigkeit mit RAID 50 zu konfigurieren oder 5, um sicherzustellen, dass der Optimierungsprozess tatsächlich die echten Hochleistungslaufwerke auswählt. Es kann einige Tage (7+) dauern, bis ein optimaler Zustand erreicht ist, aber im Allgemeinen sollte er eine ausgewogene Verteilung ziemlich schnell erreichen, da er die Volumes sofort über so viele Arrays verteilt wie möglich (wieder bis zu 4) ursprünglich erstellt.

In grober Näherung werden Sie je nach Laufwerkstyp und RAID-Typ zwischen 2500-5000 IOPs pro PS-Array haben. Wenn Sie genügend Gesamt-IOPs bereitstellen, sollte der automatisierte Verwaltungsprozess Ihnen schließlich eine gute Leistung bringen, selbst wenn Sie alle Volumes einfach in einem einzigen Pool zusammenfassen.

Wenn Sie jedoch sicherstellen möchten, dass Ihre Protokolle, Datenbanken, temporären Speicher, Betriebssystemlaufwerke usw. voneinander isoliert sind, können Sie einige Dinge tun. Erstens können Sie eine RAID-Voreinstellung für ein Volume definieren, die garantiert, dass das spezifische Volume immer nur für Arrays dieses RAID-Typs gespeichert wird (wenn sie im Pool vorhanden sind, zu dem das Volume gehört). Zweitens können Sie mehrstufige Speicherpools definieren, die nur Arrays enthalten, die die verschiedenen Leistungsklassen für diese bestimmte Stufe bereitstellen, und dann Ihre Volumes in die entsprechenden Pools verteilen. Die Gesundheitswarnung, die mit diesem Ansatz einhergeht, ist, dass Sie in der Regel viele Arrays benötigen, um eine bessere Gesamtleistung zu erzielen - das ist für Sie möglicherweise weniger wichtig, als die Leistung Ihrer kritischen Volumes zu garantieren, daher ist es oft immer noch das Beste Wahl. Die Referenzarchitektur von Dell für Oracle DBs verwendet einen Pool mit zwei RAID 10-Arrays für Daten, Voting-Datenträger und OCR sowie einen separaten Pool mit einem einzelnen RAID 5-Array für den Flash Recovery-Bereich.

Zu allen Zeitpunkten mit Equallogic sollten Sie sich fragen, ob die Entscheidungen, die Sie hinsichtlich der erzwungenen Partitionierung treffen, eine bessere Gesamtperformance für Ihre Volumes hinsichtlich verfügbarer Netzwerkschnittstellen, Festplattenspindeln und Controllern bieten. Wenn Sie das nicht beantworten können, entscheiden Sie sich für die Mindestanzahl von Pools und lassen Sie die Details behandeln oder erhalten Sie einen Equallogic-Spezialisten, um ein echtes Design zu erstellen. Wenn Sie nur ein Array haben, können Sie die Volumina nicht trennen.


9
2018-06-18 16:38





Wir speichern unsere DBs auf einzelnen SAN-Boxen, aber mit separaten Daten, Logs und Backup-LUNs, jeweils auf unterschiedlichen Festplattengruppen, nach Geschwindigkeit - mit RAID 10 15Krpm-LUNs, Daten zu RAID 1 10/15 krpm LUNs und Backup auf RAID 5 7,2 krpm LUNs. Wir präsentieren auch Protokolle und Daten über verschiedene Controller im selben SAN.


5
2018-05-15 10:33





Gute Frage!

Sehen Sie sich zuerst Brent Ozars an "Stahlkäfig BlogMatch" Debatte zu diesem Thema.

In unserem Unternehmen stellen wir für die meisten Server Daten und Protokolle auf demselben SAN-Laufwerk bereit und überlassen es dem SAN-Team, sicherzustellen, dass alles richtig funktioniert.

Ich fange an zu denken, dass dies nicht die beste Strategie ist, besonders für Server mit höherem Volumen. Das zugrunde liegende Problem besteht darin, dass ich wirklich nicht überprüfen kann, ob das SAN-Team wirklich mehr tut, als genug Laufwerke für den benötigten Platz zusammenzuschlagen. Wir betreiben keine IO-Benchmarks gegen die SAN-Laufwerke von unserer Seite oder irgendetwas, wir gehen nur davon aus, dass sie "ihren Job machen" (Anpassung sowohl an die Leistung als auch an den Platz), was wahrscheinlich etwas naiv ist.

Mein anderer Gedanke ist, dass die nett der Zugriff, den Daten vs Protokolle benötigt, ist unterschiedlich. Ich werde versuchen, den Artikel zu finden, den ich kürzlich gelesen habe, der darüber redete, wie die zwei verschiedenen Laufwerkstypen wirklich auf sehr unterschiedliche Weise optimiert werden sollten (ich denke, dass man eine Optimierung für sequentielle Schreibvorgänge benötigte, die andere benötigte Optimierung für zufällige Lesevorgänge) .)


4
2018-04-30 13:45





Kurz gesagt, Sie erstellen separate Volumes für SQL Server-Datendateien, Protokolldateien und TempDB-Daten- und Protokolldateien.

Da Sie Ihre Frage mit Equallogic markiert haben, lesen Sie sich bitte die kostenlosen Informationen durch Dell Reference Architecture Guide: Bereitstellen von Microsoft SQL Server mit Dell EqualLogic PS5000 Series Storage Arrays (Registrierung erforderlich), bevor Sie Ihre Lösung entwerfen. Oft wirst du das finden Hinweise zu bestimmten Konfigurationen können sich erheblich von allgemeinen Hinweisen unterscheiden.


4
2018-05-30 10:47





Ich würde BradC (+1) in Bezug auf die Leistung zustimmen. Im Allgemeinen hat ein gutes SAN mehr rohe I / O, als Sie erwarten könnten.

Es ist immer noch eine gute Idee, Ihre BACKUPs von Ihrem Live-System zu trennen (Offensichtlich, ich weiß, aber wenn ich ein £ 1 für jedes Mal hatte, sehe ich das ...)

Außerdem wird empfohlen, die Tempdb von den Protokolldateien fernzuhalten. Das Zelt des SAN-Kerls, um ihre Augen auf Sie zu rollen, wenn Sie "verschiedene Eimer" (technischer Begriff) für Protokolle, Daten und Temp wollen, aber wenn Sie ihnen sagen, dass es so ist, können Sie die unterschiedliche Menge von Daten IO zu jedem Bereich und messen Bringen Sie sie dazu, Ihnen ihre ausgefallenen Leistungsdiagramme zu zeigen!

Einfach doppelt / doppelt prüfen, ob der SAN-Typ es für dich eingerichtet hat. Wenn Sie RAID 10 wollen, dann bestehen Sie darauf (ich tat), obwohl sie sagten, dass ihr RAID 5 keine Leistungseinbußen hat.

(Für "dateibasierte" Operationen ist RAID 5 in Ordnung. Für intensive Schreibvorgänge, sobald Sie den Schreibpuffer füllen, ist Ihr verschraubt!)


3
2018-04-30 13:52



+1 für Social Engineering die Storage-Nerds. - pboin


Beachten Sie auch hier die Mischung der Begriffe.

Generell und sehr einfach:

  • Array = ein Pool von Festplatten in einer RAID-Einstellung (wie RAID5)
  • Volume = ein Teil eines Arrays, der dem Host im SAN mit einer LUN präsentiert wird

Sie können mehrere Volumes auf demselben Array haben, was Sie sich merken sollten, wenn Sie in diesem Thread hochwertige Optimierungen durchführen.

Der Schlüssel ist, was einige andere erwähnt haben (vergesst es nicht), trennt das Daten / Log / Backup auf verschiedenen Laufwerkspindeln, nicht nur getrennte Volumes.

Bearbeiten: und Helvick oben gab Ihnen eine - große - Antwort über Equallogic SANs!


2
2018-06-25 10:11