Standardmäßig werden Protokoll- und Datendateien getrennt, um die Festplatten vom Betriebssystem zu trennen (Tempdb, Backups und Auslagerungsdateien ebenfalls). Ist diese Logik weiterhin sinnvoll, wenn alle Laufwerke SAN-basiert sind und Ihre LUNS nicht aus bestimmten Festplatten- oder RAID-Sätzen bestehen -sie sind nur ein Teil der x-Anzahl von Laufwerken im SAN und die LUN ist nur die Speicherplatzzuweisung
Antworten:
Protokolle und Datenlaufwerke weisen unterschiedliche Datenzugriffsmuster auf, die sich (zumindest theoretisch) widersprechen, wenn sie ein Laufwerk gemeinsam nutzen.
Protokoll schreibt
Der Protokollzugriff besteht aus einer sehr großen Anzahl kleiner sequentieller Schreibvorgänge. Etwas vereinfacht ausgedrückt, sind DB-Protokolle Ringpuffer, die eine Liste von Anweisungen zum Auslesen von Datenelementen an bestimmte Speicherorte auf der Festplatte enthalten. Das Zugriffsmuster besteht aus einer großen Anzahl kleiner sequenzieller Schreibvorgänge, deren Ausführung garantiert werden muss, damit sie auf die Festplatte geschrieben werden.
Im Idealfall sollten sich die Protokolle auf einem leisen RAID-1- oder RAID-10-Volume befinden (dh nicht mit anderen geteilt werden). Logischerweise können Sie den Prozess als das Haupt-DBMS anzeigen, das Protokolleinträge und einen oder mehrere Protokollleser-Threads ausschreibt, die die Protokolle verbrauchen und die Änderungen auf die Datenfestplatten ausschreiben (in der Praxis wird der Prozess so optimiert, dass die Datenschreibvorgänge geschrieben werden wenn möglich sofort raus). Wenn auf den Protokolldatenträgern anderer Datenverkehr vorhanden ist, werden die Köpfe durch diese anderen Zugriffe verschoben, und die sequentiellen Protokollschreibvorgänge werden zu zufälligen Protokollschreibvorgängen. Diese sind viel langsamer, sodass ausgelastete Protokolldatenträger einen Hotspot erzeugen können, der als Engpass für das gesamte System fungiert.
Daten schreiben
(aktualisiert) Protokollschreibvorgänge müssen auf der Festplatte (als stabile Medien bezeichnet) festgeschrieben werden, damit eine Transaktion gültig und festschreibungsfähig ist. Man kann dies logisch als geschriebene Protokolleinträge anzeigen und dann als Anweisungen verwenden, um Datenseiten durch einen asynchronen Prozess auf die Festplatte zu schreiben. In der Praxis werden die Schreibvorgänge für die Datenträgerseite zum Zeitpunkt des Protokolleintrags tatsächlich vorbereitet und gepuffert, sie müssen jedoch nicht sofort geschrieben werden, damit die Transaktion festgeschrieben wird. Die Datenträger - Puffer werden durch die Lazy Writer - Prozess (für diesen Hinweis Dank Paul Randal) mit stabilem Medium (Festplatte) geschrieben , die In dieser Technet - Artikel bespricht in etwas mehr Detail.
Dies ist ein stark zufälliges Zugriffsmuster. Wenn Sie also dieselben physischen Datenträger mit Protokollen teilen, kann dies zu einem künstlichen Engpass bei der Systemleistung führen. Die Protokolleinträge müssen geschrieben werden, damit die Transaktion festgeschrieben werden kann. Wenn also zufällige Suchvorgänge diesen Prozess verlangsamen (zufällige E / A sind viel langsamer als sequentielle Protokoll-E / A), wird das Protokoll von einer Sequenz in ein Gerät mit wahlfreiem Zugriff umgewandelt. Dies führt zu einem ernsthaften Leistungsengpass auf einem ausgelasteten System und sollte vermieden werden. Gleiches gilt für die gemeinsame Nutzung temporärer Bereiche mit Protokolldatenträgern.
Die Rolle des Cachings
SAN-Controller haben in der Regel große RAM-Caches, die den Datenverkehr mit wahlfreiem Zugriff bis zu einem gewissen Grad absorbieren können. Aus Gründen der Transaktionsintegrität ist es jedoch wünschenswert, dass Festplattenschreibvorgänge von einem DBMS garantiert abgeschlossen werden. Wenn ein Controller so eingestellt ist, dass er Write-Back-Caching verwendet, werden die fehlerhaften Blöcke zwischengespeichert und der E / A-Aufruf wird als abgeschlossen an den Host gemeldet.
Dies kann eine Menge von Konfliktproblemen ausgleichen, da der Cache eine Menge von E / A-Vorgängen absorbieren kann, die andernfalls auf die physische Festplatte gelangen würden. Es kann auch die Paritätslese- und Schreibvorgänge für RAID-5 optimieren, wodurch die Auswirkungen auf die Leistung von RAID-5-Volumes verringert werden.
Dies sind die Merkmale, die die Denkschule "Lassen Sie das SAN damit umgehen" antreiben, obwohl diese Ansicht einige Einschränkungen aufweist:
Das Write-Back-Caching weist immer noch Fehlermodi auf, bei denen Daten verloren gehen können, und der Controller hat eine Verbindung zum DBMS hergestellt. Dabei wird darauf hingewiesen, dass Blöcke auf die Festplatte geschrieben wurden, auf denen sie tatsächlich nicht vorhanden sind. Aus diesem Grund möchten Sie das Write-Back-Caching möglicherweise nicht für eine Transaktionsanwendung verwenden. Dies gilt insbesondere für geschäftskritische Daten oder Finanzdaten, bei denen Datenintegritätsprobleme schwerwiegende Folgen für das Unternehmen haben können.
Insbesondere SQL Server 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 verfügt über ein Zertifizierungsprogramm, und viele SAN-Anbieter stellen Hardware her, die diese Semantik berücksichtigt ( hier zusammengefasste Anforderungen ). In diesem Fall optimiert keine Cache-Größe die Schreibvorgänge auf der Festplatte. Dies bedeutet, dass der Protokolldatenverkehr überlastet wird, wenn er sich auf einem ausgelasteten freigegebenen Volume befindet.
Wenn die Anwendung viel Festplattenverkehr generiert, wird der Cache möglicherweise von ihrer Arbeitsgruppe überlastet, was auch zu Problemen mit Schreibkonflikten führt.
Wenn das SAN mit anderen Anwendungen gemeinsam genutzt wird (insbesondere auf demselben Datenträger), kann der Datenverkehr von anderen Anwendungen zu Protokollengpässen führen.
Einige Anwendungen (z. B. Data Warehouses) erzeugen große vorübergehende Lastspitzen, die sie in SANs ziemlich unsozial machen.
Selbst in einem großen SAN werden separate Protokollvolumes empfohlen. Möglicherweise müssen Sie sich bei einer wenig genutzten Anwendung nicht um das Layout kümmern. Bei sehr großen Anwendungen können Sie sogar von mehreren SAN-Controllern profitieren. Oracle veröffentlicht eine Reihe von Fallstudien zum Data Warehouse-Layout, in denen einige der größeren Konfigurationen mehrere Controller umfassen.
Verantwortung für Leistung dort einsetzen, wo sie hingehört
Machen Sie das SAN-Team für die Leistung der Anwendung verantwortlich, wenn große Volumes vorhanden sind oder wenn die Leistung ein Problem darstellen könnte. Wenn sie Ihre Konfigurationsempfehlungen ignorieren, stellen Sie sicher, dass sich das Management dessen bewusst ist und die Verantwortung für die Systemleistung an der richtigen Stelle liegt. Legen Sie insbesondere akzeptable Richtlinien für wichtige DB-Leistungsstatistiken fest, z. B. E / A-Wartezeiten oder Page Latch-Wartezeiten oder akzeptable E / A-SLAs für Anwendungen.
Beachten Sie, dass die Aufteilung der Verantwortung für die Leistung auf mehrere Teams einen Anreiz darstellt, mit den Fingern zu zeigen und das Geld an das andere Team weiterzugeben. Dies ist ein bekanntes Anti-Muster für das Management und eine Formel für Probleme, die sich über Monate oder Jahre hinziehen, ohne jemals gelöst zu werden. Idealerweise sollte ein einzelner Architekt die Berechtigung haben, Änderungen an der Anwendung, der Datenbank und der SAN-Konfiguration anzugeben.
Testen Sie das System auch unter Last. Wenn Sie es arrangieren können, können gebrauchte Server und Direct-Attach-Arrays recht günstig bei Ebay gekauft werden. Wenn Sie eine solche Box mit einem oder zwei Festplatten-Arrays einrichten, können Sie die Konfiguration der physischen Festplatte anpassen und die Auswirkungen auf die Leistung messen.
Als Beispiel habe ich einen Vergleich zwischen einer Anwendung, die in einem großen SAN (einem IBM Shark) ausgeführt wird, und einer Box mit zwei Sockets und einem direkt angeschlossenen U320-Array durchgeführt. In diesem Fall übertraf die von ebay gekaufte Hardware im Wert von 3.000 GBP ein 1-Millionen-Pfund-High-End-SAN um den Faktor zwei - auf einem Host mit ungefähr gleichwertiger CPU- und Speicherkonfiguration.
Aufgrund dieses besonderen Vorfalls könnte argumentiert werden, dass das Herumliegen einer solchen Situation eine sehr gute Möglichkeit ist, SAN-Administratoren aufrichtig zu halten.
Ich gehe davon aus, dass das Equallogic-Tag und der Inhalt der Anforderung bedeuten, dass Sie sich für ein Equallogic-SAN interessieren. Das Folgende bezieht sich speziell auf Equallogic und gilt nicht für andere SAN-Typen.
Bei Equallogic-Arrays können die für Volumes verwendeten Datenträger nicht so genau wie bei EMC Clariion-Arrays angegeben werden, sodass der Ansatz etwas anders sein muss.
Equallogic Architecture ist sehr automatisiert und dynamisch. Sein grundlegender Baustein ist die Array-Einheit, nicht RAID-Packs \ Groups innerhalb eines Arrays, wie dies in anderen SANs der Fall ist. Jedes Array ist vollständig für RAID 5, 6, 10 oder 50 konfiguriert. Dies bedeutet jedoch nicht, dass es nur eine RAID-Gruppe pro Array gibt. Auf dieser Ebene müssen Sie sich lediglich nie für eine RAID-Gruppe entscheiden oder mit ihnen interagieren. Sie fügen Arrays in Speicherpools ein und Ihre Pools gehören dann zu einer Speichergruppe. Die Speichergruppe verfügt über eine Cluster \ virtuelle IP-Adresse, die Sie als iSCSI-Erkennungsziel für alle Volumes in dieser Gruppe verwenden. Die EQL-Gruppenverwaltungssoftware und der Host-MPIO-Stapel übernehmen die Umleitung auf IP-Ebene, die für die tatsächliche Weiterleitung an den am besten geeigneten Port erforderlich ist Die einzelnen Arrays beim Anfordern von Datenblöcken, aber das können Sie kaum oder gar nicht steuern.
Speichervolumes werden aus dem gesamten freien Speicherplatz in jedem Pool zugewiesen. Alle Volumes innerhalb eines Pools werden auf alle Arrays in diesem Pool verteilt (maximal 4 separate Arrays), um die Netzwerk-E / A auf die Gesamtzahl der Netzwerkschnittstellen (2 bis 4 pro E / A-Array, je nach Modell) und E / A zu verteilen über so viele Controller wie möglich. Die Equallogic-Verwaltungssoftware überwacht die Leistung von Volume und Array über einen längeren Zeitraum und optimiert dynamisch die Verteilung von Blöcken auf die Mitglieds-Arrays. Im Allgemeinen sollten Sie, sofern Sie nicht wissen, was Sie tun, alle Arrays in einem einzigen Pool zusammenfassen und die Konfiguration Ihrer Hochgeschwindigkeitsfestplatten (SAS 10k \ 15k) mit RAID 10 und die mittlere Geschwindigkeit mit RAID 50 sicherstellen oder 5, um sicherzustellen, dass der Optimierungsprozess tatsächlich die echten Hochleistungslaufwerke auswählt.
Je nach Laufwerkstyp und RAID-Typ haben Sie ungefähr 2500-5000 IOPs pro PS-Array. Wenn Sie genügend Gesamt-IOPs bereitstellen, sollte der automatisierte Verwaltungsprozess letztendlich eine gute Leistung liefern, selbst wenn Sie einfach alle Volumes in einem einzigen Pool zusammenfassen.
Wenn Sie jedoch sicherstellen möchten, dass Ihre Protokolle, Datenbanken, temporären Speicher, Betriebssystemlaufwerke usw. tatsächlich voneinander isoliert sind, können Sie einige Dinge tun. Zunächst können Sie eine RAID-Voreinstellung für ein Volume definieren, die garantiert, dass das betreffende Volume immer nur auf Arrays dieses RAID-Typs gespeichert wird (sofern sie im Pool vorhanden sind, zu dem das Volume gehört). Zweitens können Sie gestufte Speicherpools definieren, die nur Arrays enthalten, die die verschiedenen Leistungsstufen liefern, die Sie für diese bestimmte Stufe benötigen, und dann Ihre Volumes auf die entsprechenden Pools verteilen. Die Gesundheitswarnung, die mit diesem Ansatz einhergeht, lautet, dass Sie im Allgemeinen viele Arrays benötigen, um tatsächlich eine bessere Gesamtleistung zu erzielen. Dies ist für Sie möglicherweise weniger wichtig als die Gewährleistung der Leistung auf Ihren kritischen Volumes, daher ist es häufig immer noch die beste Wahl. Die Dell Referenzarchitektur für Oracle-Datenbanken verwendet einen Pool mit 2 RAID 10-Arrays für Daten, Abstimmungsfestplatte und OCR sowie einen separaten Pool mit einem einzelnen RAID 5-Array für den Flash-Wiederherstellungsbereich.
Zu jedem Zeitpunkt mit Equallogic sollten Sie sich fragen, ob die Entscheidungen, die Sie im Hinblick auf die erzwungene Partitionierung treffen, eine bessere Gesamtleistung für Ihre Volumes in Bezug auf verfügbare Netzwerkschnittstellen, Plattenspindeln und Controller ermöglichen. Wenn Sie dies nicht beantworten können, entscheiden Sie sich für die Mindestanzahl von Pools und lassen Sie diese die Details regeln, oder lassen Sie sich von einem Equallogic-Spezialisten ein echtes Design erstellen. Wenn Sie nur ein Array haben, können Sie die Volumes nicht trennen.
Wir speichern unsere DBs in einzelnen SAN-Boxen, jedoch mit separaten Daten-, Protokoll- und Sicherungs-LUNs, die sich jeweils auf unterschiedliche Datenträgergruppen verteilen und nach Geschwindigkeit geordnet sind. Dazu gehören Protokolle für RAID 10-LUNs mit 15 KBit / min, Daten für RAID 1-LUNs mit 10 bis 15 KBit / min und Sicherungen auf RAID 5 LUNs mit 7,2 U / min. Wir präsentieren auch Protokolle und Daten über verschiedene Controller im selben SAN.
Gute Frage!
Werfen Sie zunächst einen Blick auf Brent Ozars "Steel Cage BlogMatch" -Debatte zu diesem Thema.
In unserem Unternehmen speichern wir Daten und Protokolle für die meisten Server auf demselben SAN-Laufwerk und überlassen es dem SAN-Team, sicherzustellen, dass alles ordnungsgemäß funktioniert.
Ich fange an zu denken, dass dies nicht die beste Strategie ist, insbesondere für Server mit höherem Volumen. Das zugrunde liegende Problem ist, dass ich wirklich keine Möglichkeit habe, zu überprüfen, ob das SAN-Team wirklich mehr tut, als genügend Laufwerke für den von uns benötigten Speicherplatz zusammenzuschieben. Wir führen keine E / A-Benchmarks für die SAN-Laufwerke von unserer Seite aus oder so etwas. Wir gehen einfach davon aus, dass sie "ihre Arbeit machen" (Anpassung an Leistung und Speicherplatz), was wahrscheinlich ein bisschen naiv ist.
Mein anderer Gedanke ist, dass die Art des Zugriffs, den Daten und Protokolle benötigen, unterschiedlich ist. Ich werde versuchen, den Artikel zu finden, in dem ich kürzlich gelesen habe, in dem es darum ging, wie die beiden verschiedenen Laufwerkstypen wirklich auf sehr unterschiedliche Weise optimiert werden sollten (ich denke, einer musste für sequenzielle Schreibvorgänge optimiert werden, der andere für zufällige Lesevorgänge, so etwas .)
Kurz gesagt, ja, Sie würden separate Volumes für SQL Server-Datendateien, Protokolldateien sowie TempDB-Daten und -Protokolldateien erstellen.
Da Sie Ihre Frage mit Equallogic getaggt haben, lesen Sie bitte das kostenlose Dell Referenz-Architekturhandbuch: Bereitstellen von Microsoft® SQL Server® mit Dell EqualLogic ™ -Speicherarrays der PS5000-Serie (Registrierung erforderlich), bevor Sie Ihre Lösung entwerfen. Oft werden Sie feststellen, dass die Anleitungen zu bestimmten Konfigurationen erheblich von den allgemeinen Hinweisen abweichen können .
Ich würde BradC (+1) in Bezug auf die Leistung zustimmen. Im Allgemeinen verfügt ein gutes SAN über mehr unformatierte E / A-Vorgänge, als Sie erwarten können.
Es ist immer noch eine gute Idee, Ihre BACKUPs von Ihrem Live-System zu trennen.
Es wird außerdem empfohlen, die temporäre Datenbank von den Protokolldateien fernzuhalten. Das Zelt des SAN-Benutzers rollt mit den Augen, wenn Sie anfangen, nach "verschiedenen Eimern" (Fachbegriff) für Protokolle, Daten und Temp zu suchen. Wenn Sie ihnen jedoch mitteilen, dass dies so ist, können Sie die verschiedenen Datenmengen für jeden Bereich und messen Lassen Sie sich von ihnen ihre ausgefallenen Leistungsdiagramme zeigen!
Überprüfen Sie nur zweimal, ob der SAN-Typ die richtige Einstellung für Sie vorgenommen hat. Wenn Sie RAID 10 wollen, dann bestehen Sie darauf (ich tat es), obwohl sie immer wieder 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 auffüllen, sind Sie fertig!)
Achten Sie auch hier auf die Vermischung von Begriffen.
Allgemein und sehr einfach:
Sie können mehrere Volumes auf demselben Array haben, was Sie sich merken sollten, wenn Sie hochwertige Optimierungen vornehmen, die in diesem Thread erläutert werden.
Der Schlüssel ist, was mehrere andere erwähnt haben (nicht vergessen), die Daten / Logs / Backups auf verschiedenen Laufwerksspindeln zu trennen, nicht nur auf separaten Volumes.
Bearbeiten: und Helvick oben gab Ihnen eine großartige Antwort zu Equallogic SANs!