Existe-t-il un bon moyen de sauvegarder un pétaoctet de données et de le stocker?

Je commence à voir des clients avec des centaines de téraoctets de données (dans les installations SQL Server). Alors que le volume total de données dans certaines entreprises approche des fractions significatives d'un pétaoctet, j'aimerais explorer la base de connaissances collective pour voir ce que les personnes confrontées à cette ampleur de données font pour les protéger.

Le problème évident est que le stockage de plusieurs sauvegardes de cette quantité de données est extrêmement coûteux, en utilisant un stockage de classe entreprise, diable, même juste RAID-5.

Les options que je vois sont les suivantes:

1. Créez une copie miroir des données dans un autre centre de données et envoyez continuellement des différences à celui-ci (en utilisant le mécanisme disponible pour votre source de données - par exemple, l'envoi de journaux ou la mise en miroir de bases de données avec SQL Server)
2. Prenez des sauvegardes régulières en utilisant un algorithme de compression lourd (probablement uniquement adapté si les données se prêtent bien à une forte compression)
3. Effectuez des sauvegardes fragmentaires des parties critiques / changeantes des données.
4. Ne sauvegardez pas les données et ne faites pas confiance aux dieux de la corruption.

Je vois l'option # 4 adoptée par défaut, et en tant qu'expert HA / DR, c'est vraiment effrayant, mais que dois-je conseiller comme alternative? Je pense que le n ° 1 est la meilleure approche, mais "je ne pense pas" est la réponse habituelle lorsque des alternatives autres que le n ° 4 et éventuellement le n ° 3 sont suggérées.

Maintenant, bien sûr, cela dépend du taux de changement et de la criticité des données. Pas besoin de répondre avec cela, car j'étais responsable de toutes les fonctionnalités HA de SQL Server pendant que je travaillais chez Microsoft, donc je connais bien les arguments `` ça dépend '' - c'est ma devise :-)

Je serais très intéressé d'entendre des alternatives que j'ai manquées, ou d'entendre que tout le monde est dans le même bateau et qu'il n'y a pas d'alternative réaliste à dépenser beaucoup d'argent pour plus de stockage.

Merci d'avance - toutes les réponses réfléchies et exprimées seront dûment prises en compte.

Idée décalée - toutes les informations stockées sont-elles nécessaires ou même utiles?

Quelle est la valeur réelle de l'information? Il semble évidemment ridicule de dépenser plus pour l'entretien et la gestion que les données n'en valent.

Les données de la base de données sont-elles appropriées pour le stockage dans une base de données? Par exemple, le fait de conserver des fichiers de base de plusieurs gigaoctets compressés dans la base de données de l'organisation de support offre-t-il vraiment un avantage réel?

Y a-t-il beaucoup de données en double dans la base de données? Par exemple, mille personnes conservent-elles dix exemplaires chacune d'un bulletin hebdomadaire de 10 Mo?

Certaines des données ont-elles une "date d'expiration" après laquelle elles ne fournissent aucune valeur? Pour revenir à l'exemple de l'organisation de support, pour diverses raisons, il est pratiquement inutile de conserver les fichiers principaux des clients plus de quelques mois après la livraison d'un correctif.

Une autre pensée - est de conserver autant de données ouvrant l'entreprise au passif. Certaines données doivent, selon la loi, être conservées. Certaines données, cependant, devraient être "déchiquetées" en raison des risques posés si elles sont accidentellement ou par malveillance transmises à des parties inappropriées.

Oui, une autre option est la virtualisation du stockage: un périphérique qui se trouve entre vos serveurs et le SAN, comme IBM SVC. SVC gère les copies SAN vers SAN et peut effectuer une réplication à distance (bien que cela soit évidemment assez pénible au niveau du pétaoctet, sauf si vous avez des taux de changement de données très bas et une bande passante vraiment élevée.)

La partie lisse est que l'ensemble du processus est invisible pour les serveurs impliqués. Si vous utilisez SQL Server, vous concevez vos groupes de fichiers pour garder ensemble les éléments à faible taux de modification (comme les archives des ventes d'il y a> 3 ans) et les éléments à taux de modification élevé (comme les ventes actuelles) sur un groupe de fichiers distinct. Ils n'ont même pas besoin d'être complètement en lecture seule - vous voulez juste le concevoir de manière à pouvoir utiliser différentes méthodes de réplication pour chaque groupe de fichiers. L'équipement SAN peut synchroniser les luns via le réseau, la bande ou via les SAN - ce qui signifie que vous pouvez expédier des parties du SAN d'avant en arrière. Ceci est plus efficace avec des équipements comme LeftHand, où le SAN est composé d'un pool d'unités participantes.

Ensuite, vous pouvez synchroniser automatiquement les éléments à faible taux de changement sur le fil et synchroniser le taux de changement élevé avec sneakernet. (On dirait que je l'ai à l'envers, mais c'est vrai - vous ne pouvez pas synchroniser les trucs à taux de changement élevé sur le fil en raison du volume.) Même certains des équipements bas de gamme peuvent le faire maintenant: LeftHand vous permet de répliquer vers d'autres Unités LeftHand dans votre centre de données, puis expédiez-les à votre centre de données hors site. Branchez-les, joignez-les du côté distant en changeant les IP et les groupes, et maintenant ils font partie de votre SAN de sauvegarde à distance. L'argumentaire de vente de LeftHand à ce sujet est tout simplement génial: installez vos deux SAN côte à côte dans votre centre de données principal, synchronisez-les, puis vous pouvez en expédier des parties vers le centre de données distant tandis que certains restent dans votre actuel centre de données pour rester synchronisé. Déplacer progressivement '

Je n'ai cependant pas fait cela au niveau du pétaoctet. Vous savez ce qu'ils disent - en théorie, en théorie et en pratique sont les mêmes. En pratique...

L'option 1 est la mise en miroir, ce qui est presque aussi mauvais que le n ° 4: tout bogue qui corrompt les données, et qui n'est pas découvert immédiatement, corrompra les deux copies.

Si les données sont critiques, envisagez des solutions dédiées; découvrez les produits IBM Shark, par exemple, ou les produits concurrents d'EMS, etc. Ils ont des fonctionnalités telles que la copie Flash, qui vous permettent de créer instantanément une copie logique du fichier sans doubler les exigences de disque; puis vous pouvez sauvegarder cette copie sur (par exemple) une bande. Examinez également la sauvegarde robotique sur bande.

Faites remarquer à ceux qui veulent stocker un pétaoctet de données que le stockage n'est pas bon marché.

J'en ai tellement marre des gens qui gémissent de ne pas avoir un téraoctet supplémentaire de stockage en ligne parce que le disque est bon marché - le disque peut l'être, mais le stockage géré n'est certainement pas le cas.

S'il est extrêmement coûteux de stocker les sauvegardes, il est prohibitif de stocker les données de manière sûre, de sorte que la solution proposée n'est pas viable.

L'une des raisons les plus importantes d'avoir des sauvegardes est la protection contre les erreurs des utilisateurs (la plupart des problèmes de défaillance matérielle peuvent être résolus par des solutions matérielles), mais même la mise en miroir de bases de données n'est pas une protection contre une table supprimée (OK, vous pouvez vous protéger contre cela, mais c'est toujours possible d'obtenir une guff inamovible dans votre base de données - à moins que la raison pour laquelle la base de données est si grande est qu'elle n'émet que des insertions).

Comme je le vois, la bande n'est plus une solution viable - il est maintenant moins cher de simplement travailler avec des matrices de disques (bien que le stockage physique puisse être gênant). Je pense donc que votre seule option est une méthode pour diviser les données en morceaux suffisamment petits pour être restaurés dans un délai raisonnable, puis les stocker régulièrement sur le disque (et ici, les solutions de type EMS peuvent vous aider, si vous avez le en espèces).

Vidéo intéressante détaillant l'architecture de myspace.com (backend SQL2005). Je ne sais pas s'ils ont des dbs de pétaoctets individuels car ils évoluent avec plusieurs dbs. Ils utilisent des sauvegardes instantanées SAN.

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

ZFS. Bien sûr, cela ne fait que commencer, mais il existe un certain nombre de domaines dans lesquels ZFS est conçu pour gérer ce genre de chose. Tout d'abord, il est capable de gérer une grande quantité de données, ainsi qu'une multitude de périphériques de stockage différents (local, SAN, fibre, etc.), tout en gardant les données en sécurité avec des sommes de contrôle et une "couche violant" la conscience de la santé de l'appareil et les échecs. Comment cela peut-il aider à résoudre la sauvegarde de cette quantité de données?

Une méthode consiste à utiliser des instantanés. Prenez un instantané, envoyez-le sur bande / disque / net pour le transférer sur le site distant. Les instantanés suivants n'envoient que les données qui ont été envoyées, et vous pouvez conserver des données en direct aux deux extrémités si nécessaire.

L'autre consiste à utiliser le logiciel Solaris Cluster où (tant que vous disposez d'une bande passante réseau suffisante), vous pouvez avoir une mise en miroir en direct entre deux serveurs et si l'un tombe en panne, le second peut prendre le relais. C'est plus pour une utilisation où la haute disponibilité (HA) est importante, mais je suppose que la plupart des endroits avec autant de données veulent HA.

Et vous dites que ZFS n'est pas pris en charge sous Windows, l'endroit habituel où vous pouvez trouver sqlserver, peut-être que vous exécutez Sun / ZFS sur le backend et que vous vous connectez via iSCSI. C'est peut-être une idée horrible aussi, mais cela vaut au moins la peine d'y réfléchir afin que vous sachiez quoi ne pas faire.

Avez-vous envisagé Amazon Glacier en option?

OMI, sauf si vous avez une sorte de matériel de niveau godzilla, si vous avez autant de données, vous devriez utiliser une technologie de compression de sauvegarde. Je connais le mieux LiteSpeed, mais il existe des produits similaires d'autres fournisseurs et (bien sûr) une fonctionnalité similaire est intégrée à SQL2008. Il se peut que vous n'obteniez pas de compression 10: 1, mais cela réduit les exigences de stockage pour la sauvegarde et peut également réduire les exigences de votre fenêtre de sauvegarde. Si votre objectif est de conserver plusieurs jeux de sauvegarde (hier plus la veille, plus un de la semaine dernière et un du mois dernier, ou une série de différentiels plus les pleins, qui peuvent devenir très gros si vous modifiez beaucoup de données dans la base de données), c'est une simple question d'espace de stockage.

La sauvegarde basée sur un groupe de fichiers (IOW, place des données non volatiles sur certains FG et sauvegarde rarement) ne semble jamais voler parce que les développeurs ou les utilisateurs ne veulent pas ou ne peuvent pas décider quelles données sont volatiles et ce qui ne l'est pas, et dans les friches industrielles des scénarios que vous ne pouvez souvent pas prendre le risque.

Si un site de basculement est requis, en plus de penser au miroir de base de données), vous souhaiterez peut-être parler au fournisseur de stockage de vos clients pour voir s'ils proposent quelque chose comme SRDF, qui est une technologie de réplication de données basée sur le matériel. Naturellement, la réplication (quelle qu'elle soit, mais en particulier la réplication en temps réel ou quasi-temps réel) ne remplace pas les sauvegardes.

Je ne pense pas que vous ayez beaucoup de choix ici sur bande contre disque. La bande ne le coupera probablement pas dans une fenêtre de sauvegarde régulière à moins que vous ne la rayiez, et je ne suis pas sûr que la fiabilité soit là.

Vous en êtes donc aux sauvegardes sur disque. Êtes-vous en train de versionner? Cela signifie-t-il que vous craignez de revenir à la sauvegarde 2 (sauvegardes db actuelles moins 2)? Ou sauvegarde 3? Dans ce cas, vous pourriez avoir des problèmes, mais ce que vous devez probablement gérer, ce sont les sauvegardes de journaux, pas tellement les sauvegardes de données.

Si vous pouvez séparer certaines des données en lecture seule / sans modification, vous disposez peut-être de tailles / fenêtres de sauvegarde gérables. Ou du moins vous espérez que la technologie de sauvegarde et la bande passante rattraperont la croissance des données.

Je ne pense pas que vous sauvegardiez autant que vous en gardiez une deuxième copie afin de récupérer des problèmes avec votre principal. Cela signifie du matériel, de la corruption, etc., et vous priez quotidiennement pour que les erreurs ne soient pas envoyées à la deuxième copie. Les copies sont très probablement réalisées en SAN-SAN, avec une technologie de capture instantanée. bien que la copie originale puisse être via Fed-Ex plutôt que sur le fil. La bande passante pour déplacer 100 To n'est pas facile à trouver pour personne.

Je pense que vous avez besoin d'une combinaison de 1, 2 et 3 (pas 4), avec une excellente gestion de la sauvegarde des journaux.

En fait, je pense qu'à tout moment, vous regardez vraiment 3 copies de vos données. Exécution de CHECKDB sur 1 des copies pendant que la 2e copie est utilisée pour recevoir réellement les modifications. Ensuite, vous prenez un instantané de cette deuxième copie sur la première et continuez. Avec autant de données, j'imagine que vous auriez besoin de diligence ici. Paul, comment fonctionne checkdb sur une base de données multi-utilisateurs de 100 To en ligne?

Comme mentionné, les sauvegardes de journaux, et probablement un lecteur de journaux, ne sont-elles pas critiques? N'avez-vous pas besoin de récupérer des tables de dépôt / erreur utilisateur à partir des journaux plutôt qu'une sauvegarde? Vous pouvez potentiellement raccourcir cela en envoyant des copies SAN dans un certain délai, mais je n'ai pas vu cette technologie. Un SAN d'envoi de journaux qui peut retarder les modifications de 4 heures (ou un certain intervalle) pour vous permettre de récupérer des problèmes avant d'écraser les données. Ou un outil de modification de bloc de lecture de journal de SAN? Sans cela, vous devez gérer ces journaux de transactions, ce qui pourrait être un tout autre niveau de suivi de ces sauvegardes sur divers systèmes de fichiers pendant environ xxx heures pour vous permettre de récupérer éventuellement d'erreurs non fatales.

Techniquement, le stockage est bon marché, mais au niveau du pétaoctet, pas tellement. Cela dépend vraiment de l'application, mais je dirais qu'une combinaison des stratégies # 2 et # 3 sera la réponse, avec # 2 une donnée et # 3 selon le montant d'investissement que vous pouvez faire dans le stockage et le type de stockage et puissance d'E / S qui vous permettront de vous en sortir avec le moins d'incrémentalisme et autant de sauvegarde complète et discrète que possible.

Alternativement, quelque chose comme Amazon S3 peut également entrer en jeu en fonction de votre bande passante et de la quantité de changement dans les données - à ce volume, en mettre au moins une partie sur les serveurs de quelqu'un d'autre et les laisser se soucier de la redondance devient de plus en plus rentable.

Parlez à votre fournisseur de stockage, ils auront un produit de déduplication qu'ils ont utilisé auparavant, combiné à une compression régulière, vous pouvez souvent réduire votre empreinte de données de 70%. Bien sûr, toute personne ayant de l'argent à dépenser pour un pétaoctet de stockage est également susceptible d'avoir le budget nécessaire pour acheter une solution de sauvegarde décente - si ce n'est pas le cas, il vous suffit de leur demander ce que la perte de ce pétaoctet coûterait à leur entreprise.

Dans un grand entrepôt de données d'entreprise, une grande partie des données provient de sources déjà sauvegardées. J'ai travaillé sur des installations Teradata et ODW où ils ont pris l'option n ° 4, mais je savais qu'ils pouvaient restaurer un jour ou deux de données transactionnelles et les transformer à partir des systèmes source.

Chez un client de détail (à l'époque, il avait l'un des 5 plus grands DW au monde, à environ 200 To ... vous donne une idée de la date), il a opté pour l'option # 1 après avoir acheté un nouveau pétaoctet -class serveur Teradata. Les anciens nœuds seraient utilisés pour un instantané du système de la veille, tandis que le nouveau conservait l'existant. C'était également agréable du point de vue du basculement - de temps en temps, ils retiraient le tout pour la maintenance et nous devions simplement utiliser l'ancien serveur lent avec des données d'un jour.

Honnêtement cependant, cela semblait être un gros gaspillage de traitement / stockage / etc.