Frage Gibt es eine gute Möglichkeit, ein Petabyte an Daten zu sichern und zu speichern?


Ich beginne, Clients mit Hunderten von Terabytes an Daten zu sehen (in SQL Server-Installationen). Da das Gesamtvolumen der Daten in einigen Unternehmen beachtliche Bruchteile eines Petabyte erreicht, möchte ich die kollektive Wissensbasis da draußen erkunden, um zu sehen, was Menschen mit dieser Datenmenge tun, um sie zu schützen.

Das offensichtliche Problem ist, dass das Speichern mehrerer Backups von so vielen Daten unerschwinglich teuer ist, indem Speicher der Enterprise-Klasse verwendet wird, hey, sogar nur RAID-5.

Optionen, die ich sehe, sind wie folgt:

  1. Erstellen Sie eine Spiegelkopie der Daten in einem anderen Datencenter, und senden Sie kontinuierlich Unterschiede an sie (mithilfe des für Ihre Datenquelle verfügbaren Mechanismus, z. B. Protokollversand oder Datenbankspiegelung mit SQL Server)
  2. Nehmen Sie regelmäßige Backups mit einem kräftigen Komprimierungsalgorithmus (wahrscheinlich nur dann, wenn sich die Daten gut eignen) schwer komprimiert)
  3. Führen Sie stückweise Sicherungen der kritischen / sich ändernden Teile der Daten durch.
  4. Sichern Sie die Daten nicht und vertrauen Sie den Korruptionsgöttern.

Ich sehe Option 4 als Standard und als HA / DR-Experte ist es wirklich beängstigend, aber was rate ich als Alternative? Ich denke, # 1 ist der beste Ansatz, aber "Ich glaube nicht" ist die übliche Antwort, wenn Alternativen außer # 4 und möglicherweise # 3 vorgeschlagen werden.

Jetzt hängt es natürlich von der Änderungsrate und Kritikalität der Daten ab. Keine Notwendigkeit, damit zu antworten, da ich für alle HA-Funktionen von SQL Server verantwortlich war, während ich bei Microsoft arbeitete, also bin ich versiert in den 'es kommt auf' Argumente - das ist mein Schlagwort :-)

Ich würde sehr daran interessiert sein, von Alternativen zu hören, die ich verpasst habe, oder zu hören, dass alle anderen im selben Boot sitzen und es keine realistische Alternative gibt, viel Geld für mehr Speicherplatz auszugeben.

Vielen Dank im Voraus - alle gut durchdachten und geäußerten Antworten werden gutgeschrieben.


19
2018-05-31 06:26


Ursprung


Eine Vorstellung von der Größe der Aktualisierungen der Datenbank (en) würde einen Unterschied in den Sicherungsoptionen machen. - Dave Dustin
Und die folgende Frage - Gibt es eine gute Möglichkeit, ein Backup einer Petabyte-Datenbank wiederherzustellen? - Rob Boek
"Es kommt darauf an", lautet auch Joel Spolskys Schlagwort. Vielleicht musst du dafür kämpfen! - Nick Kavadias
Ich liebe einfach, wie alle Antworten die Hauptfrage umgehen, wie "die Daten gespeichert werden" mit "Warum müssen Sie die Daten speichern?" Es ist wie der Witz über den Hammer: Hast du einen Hammer, den ich mir leihen könnte? Wieso brauchst du es? Ich muss einen Nagel hämmern. Warum musst du das tun? Das Dach halten. Warum brauchst du ein Dach? Damit der Regen nicht in mein Haus fließt. Oh - nein Entschuldigung, ich habe keinen Hammer. - drozzy
Drozzy - aber das ist eine orthogonale Frage zu dem, was ich frage. Angenommen, sie müssen die Daten speichern und die große Mehrheit muss online sein. Denken Sie zum Beispiel an Hotmail, einen unserer Kunden. - Paul Randal


Antworten:


Abseits der Wand - ist die gesamte gespeicherte Information notwendig oder sogar nützlich?

Wie viel ist die Information tatsächlich wert? Es scheint offensichtlich lächerlich, mehr in Wartung und Verwaltung auszugeben, als die Daten wert sind.

Sind die Daten in der Datenbank für die Speicherung in einer Datenbank geeignet? Werden zum Beispiel komprimierte Multi-Gigabyte-Kerndateien in der Datenbank der Support-Organisation wirklich genutzt?

Gibt es viele duplizierte Daten in der Datenbank? Zum Beispiel, halten 1000 Personen zehn Exemplare eines wöchentlichen 10-MB-Newsletters?

Haben einige Daten ein "Ablaufdatum", nach dem sie keinen Wert mehr liefern? Wenn wir zum Beispiel aus der Support-Organisation zurückkehren, hat es aus verschiedenen Gründen praktisch keinen Vorteil, Kunden-Kerndateien länger als ein paar Monate nach der Lieferung eines Fixes zu behalten.

Ein anderer Gedanke - hält so viele Daten, die das Unternehmen zu Verbindlichkeiten öffnen. Einige Daten muss man per Gesetz behalten. Einige Daten sollten jedoch wegen der Risiken "geschreddert" werden, wenn sie versehentlich oder böswillig an unpassende Parteien weitergegeben werden.


6
2018-05-31 08:36





Ja, eine andere Option ist die Speichervirtualisierung: ein Gerät, das wie IBM SVC zwischen Ihren Servern und dem SAN sitzt. SVC verwaltet SAN-zu-SAN-Kopien und kann Remotereplikation durchführen (obwohl das auf Petabyte-Ebene offensichtlich ziemlich schmerzhaft ist, wenn Sie nicht wirklich niedrige Datenänderungsraten und eine wirklich hohe Bandbreite haben).

Der glatte Teil ist, dass der gesamte Prozess für die beteiligten Server unsichtbar ist. Wenn Sie SQL Server verwenden, entwerfen Sie Ihre Dateigruppen Dinge mit einer niedrigen Änderungsrate zusammen zu halten (wie Verkäufe Archiv von> 3 Jahren), und die Dinge mit einer hohen Änderungsrate (wie aktuelle Verkauf) auf einer separate Dateigruppe. Sie müssen nicht einmal vollständig schreibgeschützt sein - Sie möchten es nur so gestalten, dass Sie für jede Dateigruppe verschiedene Replikationsmethoden verwenden können. Das SAN-Gerät kann LUNs über Netzwerk, Band oder über SANs synchronisieren - das bedeutet, dass Sie Teile des SAN hin und her transportieren können. Dies ist bei Getrieben wie LeftHands effektiver, wo das SAN aus einem Pool von teilnehmenden Einheiten besteht.

Dann können Sie die Inhalte mit niedriger Änderungsrate automatisch über die Verbindung synchronisieren und die hohe Änderungsrate mit sneakernet synchronisieren. (Klingt wie ich, dass nach hinten haben, aber es ist wahr - Sie können nicht die hohe Änderungsrate Sachen über den Draht durch Volumen synchronisieren.) Sogar einige der Low-End-Gang dieses beherbergt jetzt: Lefthand können Sie auf andere replizieren LeftHand-Einheiten in Ihrem Datencenter und senden Sie sie dann an Ihr Offsite-Datencenter. Schließen Sie sie an, verbinden Sie sie mit der Remote-Seite, indem Sie IPs und Gruppen ändern, und jetzt sind sie Teil Ihres Remote-Backup-SAN. Die linke Verkaufsmasche auf das ist einfach genial: Ihr zwei SANs Seite-an-Seite in Ihrem primären Rechenzentrum einrichten, so dass sie synchron bekommen, dann können Sie Teile davon über zu dem entfernten Rechenzentrum versenden, während einige von ihnen in Ihrem aktuellen Aufenthalt Rechenzentrum zu synchronisieren. Bewegen Sie sie nach und nach, ohne dass die Synchronisation verloren geht.

Ich habe das jedoch nicht im Petabyte-Bereich getan. Sie wissen, was sie sagen - in der Theorie, in der Theorie und in der Praxis sind sie gleich. In der Praxis...


6
2018-05-31 12:20



Hi Brent, gibt es Hardware, die Daten auf SAN-Ebene komprimiert? - SuperCoolMoss
Cooles Zeug - danke Brent - Paul Randal
SuperCoolMoss - ja, absolut. NetApp bündelt beispielsweise Deduplizierung jetzt kostenlos in seine SANs. Erkundigen Sie sich bei Ihrem SAN-Anbieter und welche Deduplizierungslösungen bieten Sie an. - Brent Ozar
Und gern geschehen, Paul. :-D - Brent Ozar
Wir haben die angehende Virtualisierungssoftware eine Zeitlang ausgeführt. Die Deinstallation von den Switches ist aufgrund einiger Probleme beendet. Klingt gut, hat aber nicht geklappt. - Sam


Option 1 ist Spiegeln, was fast so schlimm ist wie # 4: Jeder Fehler, der Daten beschädigt und nicht sofort entdeckt wird, wird beide Kopien beschädigen.

Wenn die Daten kritisch sind, sollten Sie dedizierte Lösungen in Erwägung ziehen. Lesen Sie zum Beispiel über IBM Shark-Produkte oder konkurrierende Produkte von EMS usw. Sie verfügen über Funktionen wie Flash-Copy, mit denen Sie sofort eine logische Kopie der Datei erstellen können, ohne die Festplattenanforderungen zu verdoppeln. und dann können Sie diese Kopie auf (z. B.) Band sichern. Schauen Sie sich auch Robotic Tape Backup an.


3
2018-05-31 06:37



Die Datenbankspiegelung in SQL Server enthält Protokolldatensätze, keine physischen Seiten, sodass die meisten Fehler nicht in den Spiegel kopiert werden. Yup, alles, was eine Split-Mirror + Backup erlaubt, aber immer noch mit dem Problem, wo man verdammt noch mal, wenn es ein PB ist. Aber alles, was nur aus dem Original diffs ist (z. B. db-Snapshots in SQL Server), ist stark anfällig für die Beschädigung der zugrunde liegenden Quelldaten, sodass auch diffs nutzlos sind. Haben Sie versucht, einen PB auf Band zu speichern und ihn während der Notfallwiederherstellung wiederherzustellen? Tage der Ausfallzeit :-( Obwohl immer noch besser als der gesamte Datenverlust. Danke für die Antwort! - Paul Randal


Weisen Sie auf diejenigen, die ein Petabyte von Daten speichern möchten, dass der Speicher nicht billig ist.

Ich habe so die Nase voll von Leuten, die darüber meckern, kein zusätzliches Terabyte Online-Speicher zu haben, weil die Disk billig ist - die Disk kann es sein, aber der gemanagte Speicher ist es nicht.

Wenn es zu teuer ist, die Backups zu speichern, ist es sehr teuer, die Daten auf sichere Weise zu speichern, so dass die vorgeschlagene Lösung nicht praktikabel ist.

Einer der wichtigsten Gründe für Sicherungen, die ist der Schutz von Benutzerfehlern (die meisten Hardware-Fehler Probleme mit durch Hardware-Lösungen behandelt werden können), sondern auch die Datenbankspiegelung ist kein Schutz vor einer gelöschten Tabelle (OK, Sie dagegen schützen können, aber es ist nach wie vor Es ist möglich, unwiderrufliches Guff in deine DB zu bekommen - es sei denn, die DB ist so groß, dass sie nur Einsätze ausgibt.

Wie ich sehe, ist Tape keine brauchbare Lösung mehr - es ist jetzt billiger, einfach mit Disk-Arrays zu arbeiten (obwohl physischer Speicher umständlich sein kann). Ich denke, Ihre einzige Option ist eine Methode, die Daten in Stücke zu zerlegen, die klein genug sind, um in einem vernünftigen Zeitrahmen wiederhergestellt zu werden und sie dann regelmäßig auf den Plattenspeicher zu bringen (und hier können Lösungen vom Typ EMS Ihnen helfen) Kasse).


3
2018-05-31 07:03



Yup - Ich biete Option 3 mehr und mehr an - benutze datenbasierte Partitionierung der Daten, wenn du nur die neuesten Daten sichern kannst - aber du wärst überrascht, wie viele Leute VLDBs mit unterstützen wollen archaische Schemas und erwarten weiterhin, dass die Daten effizient gesichert, verwaltet und verwaltet werden können. Ich würde mit dir über Tape zustimmen müssen, für VLDBs kannst du genauso gut mit Disketten gehen und die Kosten als Gegenleistung gegen schnelle Wiederherstellungszeiten bezahlen. Danke für die Antwort! - Paul Randal
Genau. Wenn Sie sich keine Backup-Lösung leisten können, können Sie sich den Speicher nicht leisten. Zu viele Leute sehen Speicher nur als den Preis der Festplatten. - Mark Henderson♦


Interessantes Video, das die Architektur von myspace.com detailliert darstellt (SQL2005 Backend). Nicht sicher, ob sie einzelne Petabyte dbs haben, wenn sie mit mehreren dbs skalieren. Sie verwenden SAN-Snap-Sicherungen.

http://wtv.watchtechvideos.com/topic70.html


3
2018-05-31 09:35





ZFS. Sicher, es fängt gerade erst an, aber es gibt eine Reihe von Bereichen, in denen ZFS genau für solche Dinge ausgelegt ist. Zunächst einmal ist es in der Lage, eine große Menge an Daten sowie eine Vielzahl von verschiedenen Speichergeräten (lokal, SAN, Glasfaser, etc.) zu behandeln, während alle Daten sicher mit Prüfsummen und "Schicht verletzend" das Bewusstsein für den Gerätezustand und Fehler. Wie hilft diese Hilfe, diese vielen Daten zu sichern?

Eine Methode besteht darin, Snapshots zu verwenden. Machen Sie eine Momentaufnahme, senden Sie diese an Tape / Disk / Net zur Übertragung an die Gegenstelle. Nachfolgende Snapshots senden nur Daten, die gesendet wurden, und Sie können bei Bedarf Live-Daten an beiden Enden speichern.

Die andere Möglichkeit besteht darin, Solaris Cluster-Software zu verwenden, bei der (solange Sie über ausreichende Netzwerkbandbreite verfügen) eine Live-Spiegelung zwischen zwei Servern möglich ist, und wenn die eine untergeht, kann die zweite übernehmen. Es ist eher für den Einsatz dort geeignet, wo hohe Verfügbarkeit (HA) wichtig ist, aber ich würde vermuten, dass die meisten Orte mit so vielen Daten HA haben.

Und Sie sagen, dass ZFS nicht unter Windows unterstützt wird, der übliche Ort, an dem Sie sqlserver finden könnten, vielleicht führen Sie Sun / ZFS im Backend aus und verbinden sich über iSCSI. Vielleicht ist das auch eine schreckliche Idee, aber es lohnt sich zumindest, etwas darüber nachzudenken, damit Sie wissen, was Sie nicht tun sollten.


2
2018-06-01 20:40



Interessante Idee - mit solchen Ideen hatte ich noch mehr Hardware im Kopf. - Paul Randal


Hast du dich für den Amazon Glacier entschieden?


2
2018-04-12 11:12



Die Wiederherstellung der Daten könnte jedoch das Unternehmen ruinieren. - Tom O'Connor


IMO, es sei denn, Sie haben eine Art von Godzilla-Level-Hardware, wenn Sie so viele Daten haben, sollten Sie eine Backup-Komprimierungstechnologie verwenden. Ich bin mit LiteSpeed ​​am besten vertraut, aber es gibt ähnliche Produkte von anderen Anbietern und (natürlich) eine ähnliche Funktion ist in SQL2008 eingebaut. Möglicherweise erhalten Sie keine 10-zu-1-Komprimierung, aber die Speicheranforderungen für die Sicherung werden reduziert, und die Anforderungen für das Sicherungsfenster können ebenfalls verringert werden. Wenn es Ihr Ziel ist, mehrere Backup-Sätze zu behalten (gestern plus einen Tag davor, plus einen aus der letzten Woche und einen aus dem letzten Monat oder eine Reihe von Differenzen plus Vollsummen, die sehr groß werden können, wenn Sie viele Daten ändern) die Datenbank), es ist eine einfache Frage des Speicherplatzes.

Dateigroup-basierte Sicherung (IOW, nichtflüchtige Daten auf bestimmte FGs und die Rückseite selten) scheint nie zu fliegen, weil Entwickler oder Benutzer nicht entscheiden können oder nicht entscheiden können, welche Daten flüchtig sind und was nicht, und in Brownfield Szenarien können Sie oft nicht das Risiko eingehen.

Wenn eine Failover-Site eine Voraussetzung ist, sollten Sie nicht nur über Database Mirror nachdenken, sondern auch mit dem Speicherhersteller Ihres Clients sprechen, um zu erfahren, ob SRDF, eine hardwarebasierte Datenreplikationstechnologie, angeboten wird. Natürlich, Replikation (von jeder Art, aber insbesondere Echtzeit- oder Fast-Realtime-Replikation) ist kein Ersatz für Backups.


1
2018-05-31 12:22



Ich freue mich sehr auf die Zeit, in der ich eine Datendeduplizierungsspeicherlösung bekommen kann. Es wird nicht so bald sein, aber die Art meiner Daten würde wahrscheinlich zu einer Verringerung der Größe auf der Festplatte von etwa 75% führen. - Matt Simmons
Yup - Backup-Komprimierung ist meine Option 2, aber oft ist ein weiterer DC erforderlich. Ich mag die Idee, ein entferntes SAN mit verschiedenen Möglichkeiten der Synchronisierung von LUNs zu haben. Vielen Dank - Paul Randal


Ich denke nicht, dass Sie hier auf Band v. Band wird es wahrscheinlich nicht in einem regulären Sicherungsfenster schneiden, wenn Sie es nicht stripen, und ich bin mir nicht sicher, ob die Zuverlässigkeit da ist.

Sie sind also auf Festplatten-Backups angewiesen. Bist du versioniert? Was bedeutet, dass Sie sich Sorgen machen, zu Backup 2 (aktuelle Datenbank minus 2 Backups) zurückzukehren? Oder Backup 3? In diesem Fall haben Sie möglicherweise Probleme, aber wahrscheinlich müssen Sie Log-Sicherungen durchführen, nicht so viele Datensicherungen.

Wenn Sie einige der Daten als schreibgeschützt / nicht veränderbar abspalten können, haben Sie möglicherweise verwaltbare Sicherungsgrößen / -fenster. Oder zumindest hoffen Sie, dass Backup-Technologie und Bandbreite das Datenwachstum aufholen.

Ich glaube nicht, dass Sie so viel Backups machen, wie Sie eine zweite Kopie aufbewahren, um sich von Problemen mit Ihrer Primärversion zu erholen. Das bedeutet Hardware, Korruption usw., und Sie beten täglich, dass Fehler nicht in die zweite Kopie geschickt werden. Die Kopien werden wahrscheinlich mit SAN-SAN gemacht, mit einigen Snap-Shot-Technologie. obwohl die Originalkopie möglicherweise über Fed-Ex und nicht über die Leitung erfolgen würde. Bandbreite um 100 TB zu bewegen ist nicht leicht für jedermann zu kommen.

Ich denke, Sie brauchen eine Kombination von 1, 2 und 3 (nicht 4), mit exzellenten Log-Backup-Management.

Eigentlich denke ich, dass Sie zu irgendeinem Zeitpunkt wirklich 3 Kopien Ihrer Daten betrachten. CHECKDB auf 1 der Kopien ausführen, während die zweite Kopie verwendet wird, um Änderungen tatsächlich zu empfangen. Dann Snapshot diese zweite Kopie auf die erste und weiter. Mit so vielen Daten würde ich mir vorstellen, dass Sie hier etwas Sorgfalt brauchen würden. Paul, wie funktioniert checkdb auf einer Multi-User, 100TB db, die online ist?

Wie erwähnt, sind nicht Log-Sicherungen und wahrscheinlich ein Log-Reader, kritisch? Müssen Sie keine Drop-Tables / Benutzerfehler aus den Protokollen und nicht aus einer Sicherung wiederherstellen? Sie können dies möglicherweise verkürzen, indem Sie SAN-Kopien mit einer gewissen Verzögerung senden, aber ich habe diese Technologie noch nicht gesehen. Ein Protokollversand-SAN, das Änderungen um 4 Stunden (oder ein Intervall) verzögern kann, damit Sie vor dem Überschreiben von Daten Probleme beheben können. Oder einige Log-Reader-von-SAN-Block-Änderungen-Tool? Ohne das müssen Sie diese Transaktionsprotokolle verwalten, die möglicherweise eine ganze andere Stufe der Überwachung dieser Sicherungen auf verschiedenen Dateisystemen für einige xxx Stunden umfassen, damit Sie potenziell von nicht schwerwiegenden Fehlern wiederherstellen können.


1
2018-06-01 20:17



Hey Steve - einige Kunden brauchen Versionen, andere nicht. Hängt davon ab, wie fortgeschritten ihr HA / DR-Denken ist und wie viel Geld sie haben. CHECKDB in einer 100 TB Datenbank? Keine Ahnung - ich habe es nie über mehrere TB und AFAIK getestet es wurde nicht getestet> 10 TB. Ich würde gerne hören, wie es in 2005/2008 tut. Vielen Dank - Paul Randal
Hey, du bist der Typ, der nach einem Test fragen sollte. Vielleicht kann Herr Cox bei SQLCAT einen laufen lassen. Die HA / DR-Situation ist wichtig. Amazon interessiert sich vielleicht nicht für Versionen. Andere könnten von rechtlichen / regulatorischen Problemen abhängen. Es ist etwas zum Nachdenken. - Steve Jones


Technisch, Speicher ist billig, aber im Petabyte-Bereich, nicht so sehr. Es hängt wirklich von der Anwendung ab, aber ich würde sagen, dass eine Kombination aus Strategie # 2 und # 3 die Antwort sein wird, mit # 2 und # 3 je nachdem, wie viel Sie in Speicher und Art von Investitionen investieren können Speicher und I / O-Rechenleistung, die Sie mit so wenig Inkrementalismus und so viel diskreter, vollständiger Sicherung wie möglich durchkommen lassen.

Alternativ kann auch etwas wie Amazon S3 ins Spiel kommen, abhängig von Ihrer Bandbreite und wie viel Veränderung es in den Daten gibt - bei diesem Volume wird mindestens ein Teil davon auf die Server von jemand anderem übertragen und sie werden sich Sorgen um Redundanz machen kosteneffizient.


0
2018-05-31 07:41



Ich muss der Person zustimmen, die die Frage gestellt hat. Die Lagerung ist billig. / Managed / Storage ist teuer wie die Hölle. - Matt Simmons