Cache bei gespiegeltem SAN
Hallo zusammen,
ich bin immer noch an einem Storage-Performance-Thema dran, wozu ich auch schon in der Vergangenheit den ein oder anderen Thread erstellt hatte.
Zusammenfassend geht es darum, dass eine spezielle Datenbank-Anwendung ausschließlich von einem Storage mit schnellem Cache profitiert.
Beispiel: Gute Werte bei einer langsam drehenden SATA Platte die an einem RAID Controller hängt.
Schlechte Werte bei einem Fullflash SAN ohne Cache.
Wir haben zwischenzeitlich mit anderen Nutzern sprechen können, die für die Behebung sogar technologisch einen Schritt zurück gegangen sind. D.h. von einem Fullflash ohne Cache zu einem SAN mit drehenden Platten aber Cache.
Aktuell:
RZ1 = SAN1 + ESX1
RZ2 = SAN2 + ESX2
VM läuft auf ESX1 im RZ1 und greift auf SAN1 zu. Volume ist aber auf SAN2 gespiegelt.
Das Write-Acknowlege kommt erst vom SAN1 zurück, wenn es auch auf SAN2 geschrieben ist.
Vorschlag des Herstellers: ein SAN mit Cache oder Cache nachrüsten, wenn möglich.
Wenn nun die Applikation im RZ1 vom SAN1 aufgrund des Write Caches das Acknowlege schon früher bekommt, also, bevor es auf SAN2 gespiegelt wurde, was passiert bei einem plötzlichen Ausfall von SAN1?
Nach meinem Verständnis würde das zu einem Datenverlust und zu einer inkonsistenten DB führen, wenn ich diese VM im RZ2 starte.
Falls dem so ist, kann man das umgehen oder anders lösen?
Ist das generell das Problem bei einem Storage Cache?
Oder geht ein SAN in diesem Fall anders mit dem Cache um?
Gruß und besten Dank
ich bin immer noch an einem Storage-Performance-Thema dran, wozu ich auch schon in der Vergangenheit den ein oder anderen Thread erstellt hatte.
Zusammenfassend geht es darum, dass eine spezielle Datenbank-Anwendung ausschließlich von einem Storage mit schnellem Cache profitiert.
Beispiel: Gute Werte bei einer langsam drehenden SATA Platte die an einem RAID Controller hängt.
Schlechte Werte bei einem Fullflash SAN ohne Cache.
Wir haben zwischenzeitlich mit anderen Nutzern sprechen können, die für die Behebung sogar technologisch einen Schritt zurück gegangen sind. D.h. von einem Fullflash ohne Cache zu einem SAN mit drehenden Platten aber Cache.
Aktuell:
RZ1 = SAN1 + ESX1
RZ2 = SAN2 + ESX2
VM läuft auf ESX1 im RZ1 und greift auf SAN1 zu. Volume ist aber auf SAN2 gespiegelt.
Das Write-Acknowlege kommt erst vom SAN1 zurück, wenn es auch auf SAN2 geschrieben ist.
Vorschlag des Herstellers: ein SAN mit Cache oder Cache nachrüsten, wenn möglich.
Wenn nun die Applikation im RZ1 vom SAN1 aufgrund des Write Caches das Acknowlege schon früher bekommt, also, bevor es auf SAN2 gespiegelt wurde, was passiert bei einem plötzlichen Ausfall von SAN1?
Nach meinem Verständnis würde das zu einem Datenverlust und zu einer inkonsistenten DB führen, wenn ich diese VM im RZ2 starte.
Falls dem so ist, kann man das umgehen oder anders lösen?
Ist das generell das Problem bei einem Storage Cache?
Oder geht ein SAN in diesem Fall anders mit dem Cache um?
Gruß und besten Dank
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 31058621657
Url: https://administrator.de/contentid/31058621657
Ausgedruckt am: 19.12.2024 um 04:12 Uhr
20 Kommentare
Neuester Kommentar
Kannst du den Cache für das Lun nicht abstellen?
Sollte jedes Storage können.
Wie heißt denn das Storage und wie ist das HA Design im Detail?
Sollte jedes Storage können.
Wie heißt denn das Storage und wie ist das HA Design im Detail?
Ganz ehrlich das sind doch alles Fragen an den SAN Hersteller. Du schreibst ja nicht mal was das für eine SAN ist, ist die aktiv/aktiv gespiegelt oder aktiv/passiv? Unser SAN ist aktiv passiv und spiegelt nur in Intervalen. Dennoch sollte der Stand des letzten Snapshots konsistent sein, nur eben bis zu 10 Minuten alt.
Ein SAN ohne Cache? Also komplett ohne. Das wirft viele Fragen auf.
Die Replikation läuft dich nicht über das Frontend? Sondern über einen Replikationslink.
IBM SAN Volume Controller kennst Du?
Die Replikation läuft dich nicht über das Frontend? Sondern über einen Replikationslink.
IBM SAN Volume Controller kennst Du?
Es ist sehr schwer Dir zu helfen. Wir wissen nichts über so gut wie alles, was relevant wäre.
Das SVC oder vergleichbar virtualisiert den Storage Layer und deine Server und Datenbanken haben keinen Bezug zum tatsächlich LUN und dessen Bedingungen.
Das Problem ist sicherlich sehr vielfältig zu lösen. Aber nicht hier und so.
Welche Datenbank-Engine ist im Einsatz und was muss die Software draus zaubern? Sind es jeweils Hardwares oder sind es VMs?
Wir haben monströs große MSSQL Server Cluster die nach dem Reboot oder wenn sqlserver.exe neu gestartet wird das Storage durch die Mangel drehen. Dann ziehen die Hosts auch 300-500k IOPS. Danach ist aber schnell Ruhe und viel wird über RAM abgefedert.
Unsere HANAs sind auch eher auf RAM aus, als auf Storage.
AA-HA kann sehr sehr viele Fallstricke haben. Sowohl im Storage als auch auf Ebene der Applikationen.
Das SVC oder vergleichbar virtualisiert den Storage Layer und deine Server und Datenbanken haben keinen Bezug zum tatsächlich LUN und dessen Bedingungen.
Das Problem ist sicherlich sehr vielfältig zu lösen. Aber nicht hier und so.
Welche Datenbank-Engine ist im Einsatz und was muss die Software draus zaubern? Sind es jeweils Hardwares oder sind es VMs?
Wir haben monströs große MSSQL Server Cluster die nach dem Reboot oder wenn sqlserver.exe neu gestartet wird das Storage durch die Mangel drehen. Dann ziehen die Hosts auch 300-500k IOPS. Danach ist aber schnell Ruhe und viel wird über RAM abgefedert.
Unsere HANAs sind auch eher auf RAM aus, als auf Storage.
AA-HA kann sehr sehr viele Fallstricke haben. Sowohl im Storage als auch auf Ebene der Applikationen.
Hi,
üblicherweise ist das so, dass gespiegelte SAN mit Cache namhafter Hersteller das "WriteAcknowlege" erst dann senden, wenn die Änderung in beiden Cache angekommen ist. Erst danach beginnen beide Seiten, es auf die Platten runterzuschreiben.
Weiterhin haben solche SAN dann eine extra Backupbatterie, welche genau diese und nur diese Cache absichert.
So jedenfalls kenne ich das z.B. von NetApp und von EMC, als das noch mein Thema war. Und das war schon vor Jahren so.
E.
üblicherweise ist das so, dass gespiegelte SAN mit Cache namhafter Hersteller das "WriteAcknowlege" erst dann senden, wenn die Änderung in beiden Cache angekommen ist. Erst danach beginnen beide Seiten, es auf die Platten runterzuschreiben.
Weiterhin haben solche SAN dann eine extra Backupbatterie, welche genau diese und nur diese Cache absichert.
So jedenfalls kenne ich das z.B. von NetApp und von EMC, als das noch mein Thema war. Und das war schon vor Jahren so.
E.
Sobald ich den Stromstecker am Storage1 ziehe, benötige ich den Inhalt des Cache ja schon auf Storage2.
Wenn der Inhalt noch nicht im 2. Cache angekommen ist, dann bekommt der Client doch kein OK. Insofern ist das doch in Ordnung.Wenn der Client das OK bekommen hat, dann ist es auch in beiden Cache. Wenn jetzt eine Seite ausfällt, bevor diese ihren Cache runtergeschrieben hat, dann schreibt das trotzdem die andere Seite es von ihrem Cache runter. Wenn die ausgefallene Seite dann wieder hoch fährt, dann schreibt sie erst alles auch ihrem eigenen Cache runter (Batterie vorausgesetzt) und repliziert dann anschließend alle zwischenzeitlichen Änderungen von der anderen Seite.
Wenn man da ein "richtiges" SAN im Cluster hat, dann haben die Hersteller solche Szenarien schon berücksichtigt. Alles andere würde den Namen nicht verdienen.
Du sagtest es gibt vier dedizierte Backend Replikationslinks?
Steht die Hardware in einem Haus?
Muss die Synchronität wirklich auf Blockebene hergestellt werden und kann nicht auf Applikationsebene erreicht werden?
Ich kenne die Pures nur aus diversen Teststellungen, es sieht aber so aus als würdest du mit den Bedingungen von Pure und eurer Umgebung leben müssen.
Cache abstellen kann was bringen, könnte aber zu einem Feuerwerk an IOPS führen.
Wie ist der Support?
Steht die Hardware in einem Haus?
Muss die Synchronität wirklich auf Blockebene hergestellt werden und kann nicht auf Applikationsebene erreicht werden?
Ich kenne die Pures nur aus diversen Teststellungen, es sieht aber so aus als würdest du mit den Bedingungen von Pure und eurer Umgebung leben müssen.
Cache abstellen kann was bringen, könnte aber zu einem Feuerwerk an IOPS führen.
Wie ist der Support?
Wieviel Gebäude das sind, ist vollkommen egal. Interessant ist nur die Datenverbindung zwischen diesen. Wenn da LWL in ausreichender Bandbreite anliegt, dann ist es egal, ob der zweite Stapel im Nebenraum oder Nebengebäude oder anderem Stadtteil steht.
Wie die das genau machen mit dem Spiegeln des Cache, musst Du bitte den Hersteller fragen. Das hängt dann auch davon ab, welches Cluster Model genau man da aufsetzt. Da haben die Hersteller ja verschiedene im Angebot.
Wir haben bei uns auch gespiegelte Pure im Einsatz. Welche ganau und wie genau die jetzt im Cluster sind, kann ich nicht sagen. Nur, dass diese sauschnell sind und wir auch keine Probleme mit dem Spiegel haben.
Wie die das genau machen mit dem Spiegeln des Cache, musst Du bitte den Hersteller fragen. Das hängt dann auch davon ab, welches Cluster Model genau man da aufsetzt. Da haben die Hersteller ja verschiedene im Angebot.
Wir haben bei uns auch gespiegelte Pure im Einsatz. Welche ganau und wie genau die jetzt im Cluster sind, kann ich nicht sagen. Nur, dass diese sauschnell sind und wir auch keine Probleme mit dem Spiegel haben.
Wir bräuchten einen Pure-Profi hier um die Details erschöpfen zu beantworten.
Zwei Gebäude in der selben Liegenschaft, somit wäre die Synchronisation in deutlich unter einer Sekunde möglich?
Wenn ich es richtig verstehe, dann hast du zwei DB-Server die das selbe Storage nutzen und due willst die DBs synchron halten über Blockebenenreplikation? Die Datenbankserver samt Software lassen sich dauerhaft somit im Betrieb Blöcke unterschieben? versteh ich das richtig? oder ist Replikation nicht deutlich weiter oben angesiedelt, vielleicht per IP?
Es ist auch nur eine Storage? Nicht zwei, die LUNS hochverfügbar spiegeln?
Das was das SVC von IBM seinem Wert verschafft, könnte dir helfen. Eine virtuelle Storage Schicht über den virtuellen Storages. Dann sehen die Hosts nur noch ihre LUNS mit dem Dateisystem.
Es gibt auch andere Anbieter die das können.
Bezüglich des Cache abstellen wäre interessant zu wissen ob das Acknowledgen sich verändert. Ohne Cache wird das Storage jedes Bit sofort lesen und schreiben müssen und macht das dann prinzipbedingt so schnell wie möglich.
Für mich wäre jetzt als erstes zu klären:
1. Ist das DB-Design mit den Applikationen dahinter eine unterstützte Anwendung. Wenn ja, wer macht den Support und kann den rahmen nennen in dem das läuft.
2. Ist das Ganze seitens Pure supportet. Wenn ja, wie ist die Zusage dass das unter welchen Bedingungen funktioniert.
Zwei Gebäude in der selben Liegenschaft, somit wäre die Synchronisation in deutlich unter einer Sekunde möglich?
Wenn ich es richtig verstehe, dann hast du zwei DB-Server die das selbe Storage nutzen und due willst die DBs synchron halten über Blockebenenreplikation? Die Datenbankserver samt Software lassen sich dauerhaft somit im Betrieb Blöcke unterschieben? versteh ich das richtig? oder ist Replikation nicht deutlich weiter oben angesiedelt, vielleicht per IP?
Es ist auch nur eine Storage? Nicht zwei, die LUNS hochverfügbar spiegeln?
Das was das SVC von IBM seinem Wert verschafft, könnte dir helfen. Eine virtuelle Storage Schicht über den virtuellen Storages. Dann sehen die Hosts nur noch ihre LUNS mit dem Dateisystem.
Es gibt auch andere Anbieter die das können.
Bezüglich des Cache abstellen wäre interessant zu wissen ob das Acknowledgen sich verändert. Ohne Cache wird das Storage jedes Bit sofort lesen und schreiben müssen und macht das dann prinzipbedingt so schnell wie möglich.
Für mich wäre jetzt als erstes zu klären:
1. Ist das DB-Design mit den Applikationen dahinter eine unterstützte Anwendung. Wenn ja, wer macht den Support und kann den rahmen nennen in dem das läuft.
2. Ist das Ganze seitens Pure supportet. Wenn ja, wie ist die Zusage dass das unter welchen Bedingungen funktioniert.
Ja, wir haben grundsätzlich Aktiv-Aktiv- LUNs und die Controller stehen onsite bis zu Kilometer auseinander. Offsite gibt es auch Konstrukte.
Dennoch wäre es naiv von uns auf dich zu schließen.
Zumal ich für uns behaupte mit Dell EMC jemand zu haben, der das Thema auch wirklich kann und dessen Support sein Geld wert ist.
Wie das bei Pure aussieht kann ich nicht beurteilen.
Unsere Leihstellungen haben uns nie überzeugt.
Dennoch wäre es naiv von uns auf dich zu schließen.
Zumal ich für uns behaupte mit Dell EMC jemand zu haben, der das Thema auch wirklich kann und dessen Support sein Geld wert ist.
Wie das bei Pure aussieht kann ich nicht beurteilen.
Unsere Leihstellungen haben uns nie überzeugt.
Zitat von @ElmerAcmeee:
Hallo,
Wir haben nun auch noch eine kleine Powerstore - aber eben nicht im Spiegel.
Kann ich nur empfehlen und möchte ich auch nicht mehr missen.
Nur hat sie keinen Cache, was in dem "Super-Spezial-Workload" uncool ist.
Wir sind in Deutschland mit der größte Kunde dieser *** Software. Evtl fällt dies bei Kleineren nicht so auf.
Sobald ich Erkenntnisse darüber habe, wie das mit dem Cache im synchronen Spiegel gelöst ist, würde ich das hier ergänzen - wenn ich es nicht vergesse.
Hallo,
Quote from @8585324113:
Zumal ich für uns behaupte mit Dell EMC jemand zu haben, der das Thema auch wirklich kann und dessen Support sein Geld wert ist.
DELL hatte damals kein Produkt, welches unsere damaligen Anforderungen erfüllt hat.Zumal ich für uns behaupte mit Dell EMC jemand zu haben, der das Thema auch wirklich kann und dessen Support sein Geld wert ist.
Wir haben nun auch noch eine kleine Powerstore - aber eben nicht im Spiegel.
Wie das bei Pure aussieht kann ich nicht beurteilen.
Die Pure ist gut, schnell, zuverlässig und der Support ist der Knaller - schaut auch über den Tellerrand hinweg.Kann ich nur empfehlen und möchte ich auch nicht mehr missen.
Nur hat sie keinen Cache, was in dem "Super-Spezial-Workload" uncool ist.
Wir sind in Deutschland mit der größte Kunde dieser *** Software. Evtl fällt dies bei Kleineren nicht so auf.
Sobald ich Erkenntnisse darüber habe, wie das mit dem Cache im synchronen Spiegel gelöst ist, würde ich das hier ergänzen - wenn ich es nicht vergesse.
"Damals" gab es noch die Compellent, die konnte alles. (Die Storage Liebe meines Lebens)
Das know how ist wie das der Equallogic immer noch vorhanden.
Ich kenne aber auch euren Bedarf nicht. Daher müßig die Diskussion.
Ansonsten, kannst du diese Fragen aus diesem Post beantworten: Cache bei gespiegeltem SAN
Und wie gesagt, ein SVC kann helfen. Die Köpfe werden gerne für herstellerübergreifende Migrationen eingesetzt.