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

Question

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, gostaria de mostrar a base de conhecimento coletivo para ver o que as pessoas estão lidando com essa magnitude de dados para salvaguardá-la.

A questão óbvia é que armazenar múltiplos backups de tantos dados é proibitivamente caro, usando armazenamento de classe empresarial, até mesmo apenas RAID-5.

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

1. Criar uma cópia espelhada dos dados em outro datacenter e enviar continuamente diferenças a ela (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 se prestarem bem a serem muito 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 # 1 é a melhor abordagem, mas "eu não penso assim" é a resposta usual quando são sugeridas quaisquer alternativas além de # 4 e possivelmente # 3.

Agora, claro, isso depende da taxa de mudança e da criticidade dos dados. Não há necessidade de responder com isso como eu costumava ser responsável por todos os recursos de alta disponibilidade do SQL Server enquanto eu trabalhava na Microsoft, então eu sou bem versado nos argumentos 'depende' - essa é minha frase de efeito: -)

Eu ficaria muito interessado em ouvir qualquer alternativa que eu tenha perdido, ou em saber que todos os outros estão no mesmo barco e não há alternativa realista para gastar muito dinheiro em mais armazenamento.

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

    

Answer 1

Fora da ideia de parede - todas as informações armazenadas são necessárias ou mesmo úteis?

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

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

Existe um monte de dados duplicados no banco de dados? Por exemplo, mil pessoas mantêm dez cópias cada uma de um boletim semanal de 10MB?

Alguns dados possuem uma "data de expiração" após a qual não fornece nenhum valor? Voltando ao exemplo da organização de suporte, por vários motivos, não há virtualmente nenhum benefício em manter os arquivos principais do cliente mais do que alguns meses depois que uma correção foi entregue.

Outro pensamento - é manter tantos dados abrindo a empresa ao passivo. Alguns dados devem, por lei, manter. Alguns dados, no entanto, devem ser "triturados" por causa dos riscos apresentados se forem acidentalmente ou maliciosamente liberados para partes impróprias.

    

Answer 2

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 realmente baixas e largura de banda realmente alta).

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

Em seguida, você pode sincronizar o material de baixa taxa de mudança automaticamente, e sincronizar a alta taxa de alteração com sneakernet. (Parece que eu tenho isso de trás para frente, mas é verdade - você não pode sincronizar o material de alta taxa de mudança através do fio devido ao volume.) Até mesmo alguns equipamentos de baixo custo acomodam isso agora: o LeftHand permite replicar para outros Unidades LeftHand no datacenter e, em seguida, enviá-los para o datacenter externo. Conecte-os, junte-os ao lado remoto alterando IPs e grupos e agora eles fazem parte de sua SAN de backup remoto. O discurso de vendas do LeftHand sobre isso é simplesmente genial: configure suas duas SANs lado a lado em seu datacenter principal, coloque-as em sincronia e, em seguida, você pode enviar partes delas para o datacenter remoto, enquanto algumas delas permanecem em seu data center atual. datacenter para manter em sincronia. Gradualmente mova-os sem sair da sincronia.

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

    

Answer 3

A opção 1 é o espelhamento, que é quase tão ruim quanto o nº 4: qualquer bug que corrompa dados e não é descoberto imediatamente corromperá ambas as 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 o Flash-copy, que permitem criar instantaneamente uma cópia lógica do arquivo sem dobrar os requisitos de disco; e então você pode fazer backup dessa cópia para (por exemplo) fita. Olhe também para o backup de fita robótica.

    

Answer 4

Apontar para aqueles que querem armazenar um Petabyte de dados que o armazenamento não é barato.

Eu fico tão farto de pessoas reclamando de não ter um Terabyte extra de armazenamento on-line porque o disco é barato - o disco pode ser, mas o armazenamento gerenciado com certeza não é.

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

Uma das razões mais importantes para ter backups é a proteção contra erros do usuário (a maioria dos problemas de falha de hardware pode ser resolvida por soluções de hardware), mas o espelhamento de banco de dados não protege contra uma tabela descartada (OK, você pode proteger contra isso, mas ainda é possível obter guff não removível em seu banco de dados - a menos que a razão pela qual o banco de dados seja tão grande é que ele sempre emite inserções).

Como eu vejo, 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). Então eu acho que sua única opção é algum método de dividir os dados em pedaços pequenos o suficiente para serem restaurados em um período de tempo razoável e depois colocá-los no armazenamento de disco regularmente (e aqui as soluções do tipo EMS podem ajudar, se você tiver dinheiro).

    

Answer 5

Vídeo interessante detalhando a arquitetura do myspace.com (SQL2005 backend). Não tenho certeza se eles têm dbs petabyte individuais como eles escalam com vários dbs. Eles usam backups de snap da SAN.

link

    

Answer 6

ZFS. Claro, ele ainda está apenas começando, mas há várias áreas em que o ZFS foi projetado para lidar com esse tipo de coisa. Em primeiro lugar, é capaz de lidar com uma grande quantidade de dados, bem como vários dispositivos de armazenamento diferentes (local, SAN, fibra etc.), tudo isso mantendo os dados seguros com somas de verificação e conscientização da integridade do dispositivo. falhas. Como isso ajuda a resolver o backup de tantos dados?

Um método é usar instantâneos. Tire um instantâneo, envie para fita / disco / net para transferir para o site remoto. Os instantâneos subsequentes enviam apenas dados que foram enviados e você pode manter os dados ativos em ambas as extremidades, se necessário.

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

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

    

Answer 7

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

    

Answer 8

IMO, a menos que você tenha algum tipo de hardware no nível godzilla, se você tiver tantos dados, deverá usar uma tecnologia de compactação de backup. Eu estou mais familiarizado com o LiteSpeed, mas existem produtos similares de outros fornecedores e (é claro) um recurso similar é 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 pode reduzir os requisitos de janela de backup. Se sua meta for manter vários conjuntos de backups (ontem e no dia anterior, mais um da semana passada e um do mês anterior, ou uma série de diferenciais mais totais, o que pode ficar muito grande se você alterar muitos dos dados banco de dados), é uma questão simples de espaço de armazenamento.

O backup baseado em grupo de arquivos (IOW, coloca os dados não voláteis em certos FGs e os que sobrescrevem raramente) parece nunca voar porque os desenvolvedores ou usuários não podem ou não podem decidir quais dados são voláteis e quais não são e em cenários brownfield, muitas vezes você não pode assumir 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 dos seus clientes para ver se eles oferecem algo como o SRDF, que é uma tecnologia de replicação de dados baseada em hardware. Naturalmente, a replicação (de qualquer tipo, mas particularmente replicação em tempo real ou quase em tempo real) não é um substituto para backups.

    

Answer 9

Eu não acho que você tenha muita escolha aqui em fita v. disco. É improvável que a fita seja cortada em uma janela de backup regular, a menos que você a limpe, e não tenho certeza se a confiabilidade existe.

Então você está com os backups em disco. Você está fazendo o versionamento? Significado você se preocupa em voltar ao backup 2 (db atual menos 2 backups)? Ou backup 3? Nesse caso, você pode ter problemas, mas provavelmente o que você precisa manipular são backups de log, e não muitos backups de dados.

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

Eu não acho que você está fazendo o backup tanto quanto você está mantendo uma segunda cópia em torno, a fim de se recuperar de problemas com o seu 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 no SAN-SAN, com algumas tecnologias de encaixe rápido. embora a cópia original possa ser via Fed-Ex e não através do fio. Largura de banda para mover 100 TB não é fácil de encontrar para qualquer um.

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 olhando para 3 cópias de seus dados. Executar CHECKDB em 1 das cópias enquanto a segunda cópia está sendo usada para receber as alterações. Então você tira essa segunda cópia para a 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 multiusuário de 100 TB que está on-line?

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

    

Answer 10

Tecnicamente, o armazenamento é barato, mas no nível de petabyte, não muito. Isso realmente depende do aplicativo, mas eu diria que alguma combinação de estratégia # 2 e # 3 será a resposta, com # 2 um dado e # 3 dependendo de quanto investimento você pode fazer no armazenamento e o tipo de armazenamento e IO / poder computacional que lhe permitirá sair com tão pouco incrementalismo e o máximo de backup completo e discreto possível.

Alternativamente, algo como o Amazon S3 também pode entrar em jogo dependendo da sua largura de banda e da quantidade de alterações nos dados - neste volume, colocando pelo menos alguns deles nos servidores de outra pessoa e deixando que eles se preocupem com a redundância. mais e mais rentável.

    

Answer 11

Fale com seu fornecedor de armazenamento, eles terão um produto de desduplicação que já usaram antes, combinado com a compactação normal. Com frequência, você pode reduzir o volume de dados em 70%. É claro que qualquer pessoa com o dinheiro para gastar em um petabyte de armazenamento provavelmente também terá o orçamento para comprar uma solução de backup decente - se ainda não tiver, basta perguntar a eles o que perder esse petabyte custaria à empresa. / p>     

Answer 12

Em um data warehouse de grande porte, grande parte dos dados é proveniente de fontes já armazenadas em backup. Eu trabalhei em instalações Teradata e ODW, onde eles pegaram a opção # 4, mas sabiam que poderiam restaurar um ou dois dias de dados transacionais e transformá-los a partir dos sistemas de origem.

Em um cliente de varejo (no momento em que eles tinham um dos 5 maiores DWs do mundo, cerca de 200 TB ... dá uma ideia de quanto tempo atrás), eles optaram pela opção # 1 depois de comprar um novo servidor Teradata de classe Petabyte. Os nós antigos seriam usados para um instantâneo do sistema do dia anterior, enquanto o novo mantinha o existente. Isso também foi bom do ponto de vista do failover - de vez em quando eles levavam a coisa toda para manutenção e nós passávamos a usar o antigo servidor lento com dados antigos.

Honestamente, 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.