Existe uma boa maneira de fazer backup de um petabyte de dados e armazená-lo?


19

Estou começando a ver clientes com centenas de terabytes de dados (em instalações do SQL Server). Como o volume total de dados em algumas empresas se aproxima de frações significativas de um petabyte, eu gostaria de examinar a base de conhecimento coletivo existente para ver o que as pessoas que lidam com essa magnitude de dados estão fazendo para protegê-lo.

O problema óbvio é que o armazenamento de vários backups desses dados é proibitivamente caro, usando armazenamento de classe empresarial, diabos, até mesmo apenas RAID-5.

As opções que vejo são as seguintes:

  1. Crie uma cópia espelhada dos dados em outro datacenter e envie-os continuamente diferenças (usando qualquer mecanismo disponível para sua fonte de dados - por exemplo, envio de log ou espelhamento de banco de dados com o SQL Server)
  2. Faça backups regulares usando um algoritmo de compactação robusto (provavelmente adequado apenas se os dados forem adequados para serem fortemente compactados)
  3. Faça backups fragmentados das partes críticas / variáveis ​​dos dados.
  4. Não faça backup dos dados e confie nos deuses da corrupção.

Estou vendo a opção nº 4 sendo adotada como padrão e, como especialista em HA / DR, é realmente assustador, mas o que aconselho como alternativa? Eu acho que o número 1 é a melhor abordagem, mas "acho que não" é a resposta usual quando são sugeridas alternativas além do número 4 e, possivelmente, do número 3.

Agora, é claro, depende da taxa de alteração e da criticidade dos dados. Não é necessário responder com isso, já que eu era responsável por todos os recursos de alta disponibilidade do SQL Server enquanto trabalhava na Microsoft, por isso sou versado nos argumentos 'depende' - essa é minha frase de efeito :-)

Eu ficaria muito interessado em ouvir as alternativas que eu perdi ou em saber que todo mundo está no mesmo barco e não há alternativa realista para gastar muito dinheiro em mais armazenamento.

Agradecemos antecipadamente - o devido crédito será dado a todas as respostas bem pensadas e expressas.


Ter uma ideia da escala das atualizações nos bancos de dados faria diferença nas opções de backup.
Dave Dustin

1
E a pergunta de acompanhamento - Existe uma boa maneira de restaurar um backup de um banco de dados de petabytes?
317 Rob Robk

"depende" também é o slogan de Joel Spolsky. Você pode ter que lutar com ele por isso!
Nick Kavadias

Eu simplesmente amo como todas as respostas ignoram a questão principal de "como armazenar os dados" com "por que você precisa armazenar os dados?" É como aquela piada sobre o martelo: você tem um martelo que eu poderia emprestar? por que você precisa disso? Eu preciso martelar um prego. Por que você precisa fazer isso? Para segurar o teto. Por que você precisa de um telhado? Para que a chuva não caia na minha casa. Oh - desculpe, eu não tenho um martelo.
Andriy Drozdyuk 01/06/09

Drozzy - mas essa é uma pergunta ortogonal ao que estou perguntando. Suponha que eles precisam armazenar os dados e a grande maioria precisa estar online. Pense no Hotmail, por exemplo, um de nossos clientes.
Paul Randal

Respostas:


6

Idéia fora do comum - todas as informações armazenadas são necessárias ou até úteis?

Quanto vale a informação? Parece obviamente ridículo gastar mais em manutenção e gerenciamento do que os dados valem.

Os dados no banco de dados são apropriados para armazenamento em um banco de dados? Por exemplo, a manutenção de arquivos principais compactados de vários gigabytes no banco de dados da organização de suporte oferece algum benefício real?

Há muitos dados duplicados no banco de dados? Por exemplo, mil pessoas mantêm dez cópias de cada boletim semanal de 10 MB?

Alguns dados têm uma "data de validade" após a qual não fornecem nenhum valor? Voltando ao exemplo da organização de suporte, por vários motivos, não há praticamente nenhum benefício em manter os arquivos principais do cliente mais de alguns meses após a entrega de uma correção.

Outro pensamento - é manter tantos dados abrindo a empresa para o passivo. Alguns dados devem-se, por lei, manter. Alguns dados, no entanto, devem ser "triturados" devido aos riscos apresentados se forem lançados acidental ou maliciosamente a partes inadequadas.


6

Sim, outra opção é a virtualização de armazenamento: um dispositivo que fica entre seus servidores e a SAN, como o IBM SVC. O SVC gerencia cópias SAN para SAN e pode fazer replicação remota (embora isso seja obviamente muito doloroso no nível de petabytes, a menos que você tenha taxas de alteração de dados muito baixas e uma largura de banda muito alta).

A parte interessante é que todo o processo é invisível para os servidores envolvidos. Se você estiver usando o SQL Server, crie seus grupos de arquivos para manter juntos as coisas com uma baixa taxa de alteração (como arquivos de vendas de mais de 3 anos atrás) e as coisas com uma alta taxa de alteração (como as vendas atuais) em um grupo de arquivos separado. Eles nem precisam ser completamente somente leitura - você só deseja projetá-lo para poder usar métodos de replicação diferentes para cada grupo de arquivos. O equipamento da SAN pode sincronizar luns via rede, fita ou SANs, o que significa que você pode enviar partes da SAN para frente e para trás. Isso é mais eficaz com equipamentos como o LeftHand, onde a SAN é composta por um conjunto de unidades participantes.

Em seguida, você pode sincronizar automaticamente o material com baixa taxa de alteração pelo fio e sincronizar a alta taxa de alteração com a sneakernet. (Parece que eu entendi isso de trás para a frente, mas é verdade - você não pode sincronizar as coisas de alta taxa de alteração pelo fio devido ao volume.) Até mesmo alguns dos equipamentos de baixo custo acomodam isso agora: o LeftHand permite replicar para outros LeftHand unidades no seu datacenter e, em seguida, envie-as para o datacenter externo. Conecte-os, junte-os ao lado remoto alterando IPs e grupos, e agora eles fazem parte da sua SAN de backup remoto. O argumento de vendas do LeftHand é simplesmente brilhante: configure suas duas SANs lado a lado em seu datacenter primário, sincronize-as e envie partes delas para o datacenter remoto enquanto algumas delas permanecem no seu atual datacenter para se manter sincronizado. Mover gradualmente '

Eu não fiz isso no nível de petabytes, no entanto. Você sabe o que eles dizem - na teoria, na teoria e na prática são os mesmos. Na prática...


Oi Brent, há hardware disponível que comprime dados no nível da SAN?
SuperCoolMoss

SuperCoolMoss - sim, absolutamente. A NetApp agrupa a desduplicação em suas SANs gratuitamente agora, por exemplo. Verifique com seu fornecedor de SAN e pergunte quais soluções de desduplicação eles oferecem.
Brent Ozar

E de nada, Paul. :-D
Brent Ozar

Estávamos executando o software de virtualização incipiente por um tempo. Acabou a desinstalação dos comutadores devido a alguns problemas. Parecia ótimo, mas não funcionou para nós.
Sam

3

A opção 1 é o espelhamento, que é quase tão ruim quanto a # 4: qualquer bug que corrompa dados e não é descoberto imediatamente, corromperá as duas cópias.

Se os dados forem críticos, considere soluções dedicadas; leia sobre os produtos Shark da IBM, por exemplo, ou produtos concorrentes do EMS etc. Eles possuem recursos como cópia em Flash, que permitem criar instantaneamente uma cópia lógica do arquivo sem duplicar os requisitos de disco; e então você pode fazer backup dessa cópia em (por exemplo) fita. Veja também o backup em fita robótica.


O espelhamento de banco de dados no SQL Server envia registros de log, não páginas físicas, para que a maioria das corrupções não seja copiada para espelhar. Sim, qualquer coisa que permita a captura de um espelho de divisão +, mas ainda resta o problema de onde colocar uma coisa maldita se for um PB. Mas qualquer coisa que seja diffs somente do original (por exemplo, instantâneos de banco de dados no SQL Server) é altamente suscetível à corrupção dos dados de origem subjacentes, tornando as diffs inúteis também. Você tentou armazenar um PB em fita + restaurá-lo durante a recuperação de desastres? Dias de inatividade :-( Embora ainda melhor do que a perda de dados total de Graças para resposta.!
Paul Randal

3

Aponte para aqueles que desejam armazenar um Petabyte de dados que o armazenamento não é barato.

Fico tão cansado de pessoas que reclamam de não ter um Terabyte extra de armazenamento on-line porque o disco é barato - pode ser, mas o armazenamento gerenciado com certeza não é.

Se é proibitivamente caro armazenar os backups, é proibitivamente caro armazenar os dados de maneira segura, para que a solução proposta não seja viável.

Um dos motivos mais importantes para ter backups é a proteção contra erros do usuário (a maioria dos problemas de falha de hardware pode ser tratada por soluções de hardware), mas mesmo o espelhamento de banco de dados não oferece proteção contra uma tabela descartada (OK, você pode proteger contra isso, mas ainda é É possível obter uma falha irremovível em seu banco de dados - a menos que o banco de dados seja tão grande que apenas emita inserções).

Na minha opinião, a fita não é mais uma solução viável - agora é mais barato trabalhar apenas com matrizes de disco (embora o armazenamento físico possa ser complicado). Portanto, acho que sua única opção é algum método de dividir os dados em pedaços pequenos o suficiente para serem restaurados em um prazo razoável e colocá-los no armazenamento em disco regularmente (e aqui as soluções do tipo EMS podem ajudar, se você tiver o dinheiro).


Sim - proponho cada vez mais a opção nº 3 - use o particionamento com base em dados se você puder e apenas faça backup dos dados mais recentes com frequência - mas ficaria surpreso com o número de pessoas que desejam oferecer suporte a VLDBs com esquemas arcaicos e ainda espera poder fazer backup, gerenciar e manter os dados com eficiência. Eu tenho que concordar com você sobre fita. Para os VLDBs, você também pode usar o disco e pagar o custo como uma compensação pelo rápido tempo de recuperação. Obrigado pela resposta!
Paul Randal

1
Concordo. Se você não pode pagar uma solução de backup, não pode pagar pelo armazenamento. Muitas pessoas vêem o armazenamento apenas como o preço dos discos.
Mark Henderson


2

ZFS. Claro, ainda está apenas começando, mas há várias áreas em que o ZFS foi projetado para lidar com esse tipo de coisa. Primeiro, é a capacidade de lidar com uma grande quantidade de dados, além de vários dispositivos de armazenamento diferentes (local, SAN, fibra etc.), enquanto mantém os dados seguros com somas de verificação e "viola a camada" da saúde do dispositivo e falhas. Como isso ajuda a resolver o backup de tantos dados?

Um método é usar instantâneos. Tire uma foto, envie-a para fita / disco / rede para transferência para o site remoto. As capturas instantâneas subsequentes enviam apenas os dados enviados e você pode manter os dados ativos nas duas extremidades, se necessário.

A outra é usar o software Solaris Cluster, onde (desde que você tenha largura de banda de rede suficiente), você pode ter um espelhamento ao vivo entre dois servidores e, se um deles cair, o segundo pode assumir o controle. É mais para uso em que a alta disponibilidade (HA) é importante, mas eu acho que a maioria dos lugares com tantos dados deseja HA.

E você diz que o ZFS não é suportado no Windows, o local habitual em que você pode encontrar o sqlserver; talvez você execute o Sun / ZFS no back-end e conecte-se via iSCSI. Talvez seja uma idéia horrível também, mas pelo menos vale a pena pensar um pouco para que você saiba o que não fazer.


Ideia interessante - que eu tinha mais hardware para brincar com idéias como essa.
Paul Randal

2

Você já viu o Amazon Glacier como uma opção?


A recuperação dos dados pode levar à falência da empresa, no entanto.
Tom O'Connor

1

IMO, a menos que você tenha algum tipo de hardware no nível godzilla, se você tiver muitos dados, deverá usar uma tecnologia de compactação de backup. Eu estou mais familiarizado com o LiteSpeed, mas existem produtos semelhantes de outros fornecedores e (é claro) um recurso semelhante está embutido no SQL2008. Você pode não obter compactação de 10 para 1, mas reduz os requisitos de armazenamento para o backup e também reduz os requisitos da janela de backup. Se seu objetivo é manter vários conjuntos de backups (ontem, mais um dia antes, mais um da semana passada e outro do mês passado ou uma série de diferenciais mais totais), que podem aumentar bastante se você alterar muitos dados em banco de dados), é uma simples questão de espaço de armazenamento.

O backup baseado em grupo de arquivos (IOW, colocar dados não voláteis em determinados FGs e fazer backup com pouca frequência) nunca parece voar porque os desenvolvedores ou usuários não decidem ou não quais dados são voláteis e o que não é, e em brownfield cenários em que você frequentemente não pode correr o risco.

Se um site de failover for um requisito, além de pensar no Database Mirror), convém conversar com o fornecedor de armazenamento de seus clientes para ver se eles oferecem algo como SRDF, que é uma tecnologia de replicação de dados baseada em hardware. Naturalmente, a replicação (de qualquer tipo, mas particularmente em tempo real ou quase em tempo real) não substitui os backups.


Estou realmente ansioso pelo momento em que eu possa obter uma solução de armazenamento com deduplicação de dados. Não vai ser tão cedo, mas a natureza dos meus dados provavelmente levaria a um corte no tamanho em disco como de 75%
Matt Simmons

Sim - a compactação de backup é minha opção 2, mas geralmente é necessário outro controlador de domínio. Eu gosto da ideia de ter uma SAN remota com diferentes maneiras de sincronizar LUNS. Obrigado
Paul Randal

1

Eu não acho que você tem muita escolha aqui na fita v. Disco. A fita provavelmente não será cortada em uma janela de backup comum, a menos que você a distribua, e não tenho certeza de que a confiabilidade esteja lá.

Então você está pronto para backups em disco. Você está versionando? Significado: você se preocupa em voltar ao backup 2 (atual db menos 2 backups)? Ou backup 3? Nesse caso, você pode ter problemas, mas é provável que você precise lidar com backups de log, e não tantos backups de dados.

Se você pode separar alguns dados como somente leitura / sem alteração, talvez você tenha tamanhos / janelas de backup gerenciáveis. Ou pelo menos você espera que a tecnologia de backup e a largura de banda estejam acompanhando o crescimento dos dados.

Não acho que você esteja fazendo o backup e mantendo uma segunda cópia para se recuperar de problemas com o primário. Isso significa hardware, corrupção, etc., e você está orando diariamente para que os erros não sejam enviados para a segunda cópia. As cópias provavelmente estão sendo feitas com SAN-SAN, com alguma tecnologia de captura instantânea. embora a cópia original possa ser via Fed-Ex, e não através do fio. A largura de banda para mover 100 TB não é fácil de encontrar para ninguém.

Eu acho que você precisa de uma combinação de 1, 2 e 3 (não 4), com excelente gerenciamento de backup de log.

Na verdade, acho que a qualquer momento você está realmente vendo três cópias de seus dados. A execução do CHECKDB em 1 das cópias enquanto a 2ª cópia está sendo usada para realmente receber as alterações. Em seguida, você captura a segunda cópia da primeira e continua. Com tantos dados, imagino que você precisaria de alguma diligência aqui. Paul, como o checkdb funciona em um banco de dados de 100TB multiusuário que está online?

Como mencionado, os backups de log e, provavelmente, um leitor de log, não são críticos? Você não precisa recuperar tabelas eliminadas / erro do usuário dos logs, em vez de um backup? Você pode potencialmente atalho enviando cópias da SAN com algum atraso, mas ainda não vi essa tecnologia. Uma SAN de envio de logs que pode atrasar as alterações em 4 horas (ou em algum intervalo) para permitir a recuperação de problemas antes de substituir os dados. Ou alguma ferramenta de log-reader-of-SAN-block-changes? Sem isso, você precisa gerenciar esses logs de transações, que podem ser um nível totalmente diferente de rastrear esses backups em vários sistemas de arquivos por algumas xxx horas, para permitir a recuperação potencial de erros não fatais.


Hey Steve - alguns clientes precisam de versões, outros não. Depende de quão avançado é o seu pensamento sobre HA / DR e quanto dinheiro eles têm. CHECKDB em um banco de dados de 100 TB? Não faço ideia - nunca testei acima de vários TB e o AFAIK não foi testado> 10 TB. Eu adoraria ouvir como isso acontece em 2005/2008. Obrigado
Paul Randal

Ei, você é o cara que deveria pedir um teste. Talvez o Sr. Cox da SQLCAT possa executar uma. A situação de HA / DR é importante. A Amazon pode não se importar com versões. Outros podem depender de questões legais / regulatórias. É algo para se pensar.
9788 Steve Jones

0

Tecnicamente, o armazenamento é barato, mas no nível de petabytes, nem tanto. Realmente depende da aplicação, mas eu diria que alguma combinação das estratégias 2 e 3 será a resposta, com a segunda e a terceira, dependendo de quanto investimento você pode fazer em armazenamento e o tipo de armazenamento e IO / poder computacional que permitirão que você se desenvolva com o mínimo de incrementalismo e com o backup completo mais discreto possível.

Como alternativa, algo como o Amazon S3 também pode entrar em jogo, dependendo da sua largura de banda e quanta alteração há nos dados - nesse volume, colocando pelo menos parte deles nos servidores de outras pessoas e deixando-os se preocupar com redundância cada vez mais económicamente viáveis.


Eu tenho que concordar com a pessoa que fez a pergunta. O armazenamento é barato. / Gerenciado / armazenamento é caro como o inferno.
31510 Matt Simmons

0

Fale com o seu fornecedor de armazenamento, eles terão um produto de deduplicação que eles usaram antes, combinado com a compactação regular, você pode frequentemente reduzir sua pegada de dados em 70%. É claro que qualquer pessoa com dinheiro para gastar em um petabyte de armazenamento também provavelmente terá o orçamento para comprar uma solução de backup decente - se não tiver, basta perguntar o que perder esse petabyte custaria aos negócios.


Sim - teve a compactação como opção 2 e a maioria desses clientes não possui muita duplicação nos dados. Discordo do dinheiro extra - às vezes (e frequentemente) o crescimento do volume de dados ultrapassa o orçamento para armazenamento redundante. Várias empresas da Fortune-100 com quem trabalho estão nesse estado para algumas de suas aplicações.
Paul Randal

Mas obrigado pelo comentário!
Paul Randal

0

Em um grande armazém de dados corporativos, muitos dados são provenientes de fontes que já foram armazenadas em backup. Eu trabalhei nas instalações Teradata e ODW, onde eles escolheram a opção 4, mas sabiam que poderiam restaurar um ou dois dias de dados transacionais e transformá-los nos sistemas de origem.

Em um cliente de varejo (na época em que eles tinham um dos 5 maiores DWs do mundo, a cerca de 200 TB ... dá uma idéia de quanto tempo isso foi), eles optaram pela opção nº 1 depois de comprar um novo Petabyte servidor Teradata de classe. Os nós antigos seriam usados ​​para uma captura instantânea do sistema do dia anterior, enquanto o novo mantinha o existente. Isso também era bom do ponto de vista de failover - de vez em quando eles desmontavam tudo para manutenção e passávamos a usar o servidor lento antigo com dados do dia anterior.

Honestamente, porém, parecia um grande desperdício de processamento / armazenamento / etc manter a coisa funcionando ... particularmente quando a maior vantagem era que seus administradores e técnicos da NCR tinham que trabalhar menos noites para realizar manutenção irregular.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.