Backup do servidor de streaming

Question

Eu quero levar um novo servidor de streaming para o meu site, que geralmente contém vídeos e arquivos de áudio. Mas como mantemos o backup do servidor de streaming se o tamanho do armazenamento estiver aumentando dia a dia.

Geralmente, em servidores de banco de dados, como o Sql Server, os backups podem ser facilmente obtidos e restaurados com muita facilidade, pois não ocupam muito espaço para aplicativos de médio alcance.

Por outro lado, como podemos fazer backup do servidor de streaming? Se o servidor falhar, deve haver um servidor / solução alternativa que deve diminuir o tempo de inatividade do servidor.

Como é a arquitetura de back-end do YouTube criada para lidar com isso?

    

Answer 1

O que fazemos é ter várias SANs FC, cada uma em sincronia entre diferentes datacentres, cada uma conectada a bancos de servidores que atuam como servidores de 'origem', traduzindo o armazenamento do FC para NFS ou CIFS / SMB. Esses servidores são então divididos em blocos VIP balanceados por carga que, por sua vez, alimentam blocos de servidores web com VIPs semelhantes, que são então apresentados via FW / LBs para o mundo externo.

O conteúdo real é periodicamente retirado de uma ou mais caixas FC SAN em uma caixa SAN dedicada que é então copiada para o disco em outro site, as fitas são então armazenadas com a Iron Mountain. Eu estou no negócio de streaming:)

Não há atalho com conteúdo, é grande e você só precisa lidar com isso. Se eu fosse você, configuraria uma máquina de backup dedicada com um grande volume de disco disponível e usaria o rsync para garantir que você tenha uma cópia de todos os arquivos no armazenamento de conteúdo principal, mesmo que isso inevitavelmente acabe como um superconjunto de seus dados ao vivo. Em seguida, faça backups em disco ou em fita dessa máquina e exclua periodicamente os dados antigos para mantê-los gerenciáveis.

O Oh and youtube não faz o backup adequado de nenhum conteúdo de usuários regulares; seu design garante que eles tenham várias cópias distribuídas em todo o mundo, mas isso é mais para o desempenho do que para os recursos de restauração. Eles fazem backup de seu próprio conteúdo ou de qualquer outro conteúdo pago para implantar, mas isso é uma pequena gota no oceano em comparação com todo o conteúdo que eles não têm obrigação contratual de armazenar.

    

Answer 2

Agora você está descobrindo por que ter um serviço de streaming de vídeo / áudio e mantê-lo confiável não é fácil de configurar. Para ter uma solução de backup completo, você precisa:

• Servidores adicionais para armazenar o conteúdo de backup.
• Largura de banda suficiente disponível (em uma rede de back-end separada) para lidar com o backup.
• Scripts para copiar o conteúdo em tempo hábil ou um backup automático à medida que os arquivos são adicionados ao servidor.

Se você estiver olhando para diminuir o tempo de inatividade, precisará adicionar pelo menos o dobro da quantidade de servidores que tem para a solução original, além de uma maneira de gerenciar essa rede. O custo será de pelo menos 2x da solução original.

Como o Chopper3 notou, é possível criar na infraestrutura a necessidade de fazer 'backups' porque quando o conteúdo é adicionado, ele é automaticamente espelhado.

    

Answer 3

Suponha que uma de suas perguntas é "Como a arquitetura de back-end do YouTube foi criada para lidar com isso". mesmo que você nunca tenha usado um ponto de interrogação em sua postagem, a resposta é que o Google é incrivelmente grande e tem vários servidores espalhados pelo mundo, e você pode ter certeza de que os dados estão armazenados em mais de uma máquina. no caso de um deles cair, os dados podem continuar em streaming.

Os planos de backup habituais incluem backup off-site, mas se você precisar ter um tempo de atividade alto, poderá precisar de backups locais e externos para poder restaurar rapidamente a partir do local, embora haja algum desastre no local. DC você terá que usar os fora do local.

Alguém mencionou backups em fita, embora eu recomende contra eles, já que você não precisa realmente ter arquivos dos dados, e provavelmente só quer poder sincronizar seus dados com outro servidor para ter um cópia de segurança. Existem ferramentas úteis, como o rsync, que podem manter os dados em sincronia e só fazem upload de arquivos modificados, evitando que você faça um backup completo.

Existem maneiras de complicar demais e formas de gastar dinheiro configurando muita redundância, mas algo me diz que você não pode pagar e não precisa do incômodo de gerenciar muitas máquinas.