Opções de backup do servidor de nuvens Rackspace

4

Eu recentemente me inscrevi na Rackspace para hospedar alguns servidores de banco de dados. Eu tenho dois servidores MySQL configurados e tenho um método para criar backups (usando as ferramentas Percona Xtrabackup e innobackupex). Eu tenho tentado usar a duplicidade para copiar esses backups para o armazenamento do S3 e do CloudFiles, e está levando forreverr ! Eu esperaria que o backup do S3 não fosse muito rápido, mas o backup do CloudFiles levou 15 horas para fazer o backup de 9 GB. Isso é terrivelmente lento e inaceitável para mim.

Examinei o código-fonte de duplicidade e, por padrão, ele não utiliza o ServiceData Rackspace para transferir para o cloudfiles. Então eu olhei para o código-fonte cloudfiles para o lib que a duplicidade usa para o backend CF, e vi que havia uma opção ambiental para utilizar o Servicenet ( RACKSPACE_SERVICENET ). Contanto que isso seja definido como algo , o cloudfiles lib deve estar se conectando a cloudfiles via o Rackspace Servicenet, que DEVE fazer para transferências rápidas. Não.

Eu não tenho certeza se a limitação de velocidade é por causa de alguma limitação do CloudFiles ou se a biblioteca Python do cloudfiles não está realmente conectando via o servicenet do RackSpace.

Algum de vocês tem alguma outra sugestão de como eu deveria / poderia fazer para conseguir esses backups fora do servidor e para um terceiro ou serviço de backup remoto?

    
por Jim Rubenstein 08.06.2011 / 15:22

2 respostas

2

Usamos o Rackspace Server Backup (também conhecido como JungleDisk Server Backup), que, assim como o Duplicity, faz dedupe e compactação local e, em seguida, faz o upload de "chunks" via HTTP para um provedor de nuvem. Vimos alguns problemas de desempenho, e o motivo subjacente foi que nossos pontos de provisionamento para arquivos em nuvem versus servidores em nuvem eram diferentes. Nossos servidores em nuvem foram criados no datacenter DFW, mas todos os buckets de arquivos em nuvem do JungleDisk estão no datacenter ORD.

A Rackspace atualmente não oferece às pessoas a escolha de qual datacenter elas usarão, porque a instalação DFW está próxima da capacidade. Então, tudo para contas "mais recentes" como provisionadas em ORD. Portanto, você precisa abrir um ticket de suporte para alterar seu ponto de provisionamento.

Além disso, você não pode usar o ServiceNet entre datacenters da Rackspace (ainda).

Dito isso, vemos 40+ Mbps durante os backups, mesmo cruzando datacenters da Rackspace usando o Rackspace Cloud Backup, portanto, suspeito que você tenha alguma forma de problema de configuração com duplicidade ou esteja limitado a disco ou CPU durante o backup. Você já tentou executar o backup para o mesmo destino a partir de arquivos externos da nuvem? Como um simples HTTP PUT de um arquivo grande é executado (isto é, exclui a duplicidade de um teste)?

    
por 29.06.2011 / 16:28
2

Talvez não seja uma resposta completa, mais uma sugestão. Você não poderia configurar uma instância do Amazon EC2 que espelhava continuamente (ou perdia por alguns minutos) os principais servidores de banco de dados. Em seguida, você pode executar backups dessa instância do EC2 diretamente no S3 e obter velocidades de transferência mais rápidas, além de reduzir a carga em seus principais dispositivos de banco de dados.

Embora 15 horas para 9GB sejam, se minha matemática mental estiver correta (o que provavelmente não é), menos de 2MB / s, o que soa como um problema. Talvez valha a pena entrar em contato com o suporte da Rackspace perguntando por que a velocidade de transferência é baixa.

    
por 13.06.2011 / 09:54