Há algo interessante nessa questão - especificamente no que diz respeito à idéia de tempo de inatividade. Parte da ideia é que, se um aplicativo é sensível ao tempo de inatividade, o tempo de recuperação também deve ser levado em consideração. (Como argumento extremo, nenhum backup requer nenhum tempo de inatividade, a menos que você precise desses backups; nesse caso, o tempo de inatividade pode se aproximar do infinito )
Um pouco sobre o EBS
Os volumes e capturas instantâneas do EBS operam em um nível de bloco - uma conseqüência da qual permite a captura de capturas instantâneas enquanto uma instância está em execução, mesmo se o volume EBS estiver em uso. No entanto, apenas os dados que estão realmente no disco (ou seja, não estão no cache de arquivos) serão incluídos no instantâneo. É a última razão que dá origem à ideia de instantâneos consistentes.
- A maneira recomendada é desanexar o volume, capturá-lo instantaneamente e recolocá-lo - geralmente não é prático.
- A próxima melhor opção envolve liberar os caches de gravação em disco, congelar o sistema de arquivos e tirar seu instantâneo
Um ponto interessante aqui é que, nos dois casos acima, não é necessário aguardar a conclusão do instantâneo para recolocar / descongelar e retomar a gravação no disco - depois que o instantâneo tiver sido iniciado, seus dados serão consistentes nesse momento. Normalmente, isso requer apenas alguns segundos durante os quais seu disco está bloqueado para gravação. Além disso, como a maioria dos bancos de dados estrutura seus arquivos no disco de maneira razoável - há uma boa chance de que as inserções tenham um efeito mínimo nos blocos existentes - o que minimiza os dados adicionados ao instantâneo.
Considere o ponto do backup
Os volumes EBS já estão replicados em uma zona de disponibilidade - para que haja um certo grau de redundância. Se sua instância terminar, você poderá simplesmente anexar o volume EBS a uma nova instância e (depois de superar a falta de consistência) retomará onde você deixado de fora. Em muitos aspectos, isso torna o volume do EBS muito parecido com um instantâneo inconsistente, desde que você possa acessá-lo. Dito isto, a maioria dos usuários do EC2 provavelmente se lembra das falhas em cascata dos volumes EBS desde o início de 2011 - os volumes ficaram inacessíveis por vários dias e alguns usuários também perderam dados.
RAID1
Se você estiver tentando se proteger contra a falha de um disco EBS (isso acontece), considere uma configuração de RAID1. Como os volumes EBS são dispositivos de bloco, você pode facilmente usar o mdadm para configurá-los na configuração desejada. Se um de seus volumes EBS não estiver executando conforme as especificações, será fácil falhar manualmente (e depois substituí-lo por outro volume EBS). Obviamente, isso tem desvantagens - aumento do tempo para cada gravação, maior suscetibilidade ao desempenho variável, o dobro do custo de E / S (monetariamente, não em termos de desempenho), nenhuma proteção real contra uma falha mais generalizada da AWS (um problema comum no ano passado foi a incapacidade de desanexar volumes EBS que estavam em um estado bloqueado) e, é claro, o estado inconsistente do disco em falha.
S3FS
Uma opção para certas aplicações (definitivamente NÃO para bancos de dados) é montar o S3 como um sistema de arquivos local (por exemplo, via s3fs). Isso é lento, carece de alguns dos recursos que se esperaria de um sistema de arquivos e pode não se comportar como esperado (consistência eventual). Dito isso, para uma finalidade simples, como disponibilizar arquivos enviados entre instâncias, pode ter mérito. Obviamente, não é para nada que exija bom desempenho de leitura / gravação.
MySQL bin-log
Mais uma opção específica para o MySQL pode ser o uso do bin-log. Você pode configurar um segundo volume do EBS que armazenará seu log de bin (para minimizar o efeito das gravações adicionadas no seu banco de dados) e usá-lo em conjunto com quaisquer despejos de banco de dados que você fizer. Você pode até fazer isso com o s3fs, que pode realmente ter mérito se o desempenho for tolerável (um rsync provavelmente seria melhor do que tentar usar o s3fs diretamente, e você definitivamente desejará compactar o que puder).
Mais uma vez, porém, voltamos à idéia de propósito. Considere o que aconteceria com as sugestões acima:
- Volumes EBS inacessíveis:
- RAID1 - inútil, já que você não pode acessar os dados
- bin-log - inútil, a menos que você o tenha exportado para o S3 - provavelmente um atraso se você fez isso
- A instância termina inesperadamente:
- RAID1 - seus discos estão disponíveis, mas não são consistentes; seu banco de dados pode se recuperar sozinho da inconsistência
- bin-log - seus dados devem estar acessíveis, embora você possa precisar revisar os últimos eventos
- Alguém executa o DROP DATABASE como root:
- RAID1 - você tem duas cópias perfeitas de um banco de dados inexistente
- bin-log - você deve poder reproduzir os eventos até pouco antes do comando, para que esteja bem
Realmente, o RAID1 é praticamente inútil e o log de bin leva muito tempo - ambos podem ter mérito em determinadas circunstâncias, mas estão longe do backup da ideia.
Instantâneos
É importante observar que os instantâneos são diferenciais e armazenam apenas os blocos reais que contêm dados (e são compactados). Ao contrário do volume EBS, em que se você tiver um volume de 20 GB, mas usar apenas 1 GB, você ainda será cobrado pelo armazenamento 'provisionado' (20 GB). Com um instantâneo, você é cobrado apenas pelo que usar. Se nenhum dado for alterado entre os instantâneos, não há (teoricamente) nenhuma cobrança. (Os instantâneos são cobrados por PUTS / GETS e armazenamento usado).
Como um aparte, eu recomendo que os dados do seu aplicativo (incluindo bancos de dados) não sejam armazenados no volume raiz (que você já pode ter configurado). Uma das vantagens é que, esperançosamente, seu volume raiz vê um mínimo de alterações - o que significa que seus instantâneos podem ser menos frequentes (ou terão um mínimo de alterações), reduzindo o custo e a facilidade de uso.
Também é relevante mencionar que você pode excluir instantâneos antigos a qualquer momento - mesmo sendo diferenciais, eles não afetarão os outros instantâneos. Dito isto, cada bloco alocado para um instantâneo não será abandonado até que não exista nenhum instantâneo que ainda faça referência a esse bloco.
O problema com despejos periódicos é primeiramente o tempo entre despejos (possivelmente resolvido usando o log de bin do MySQL) e também a dificuldade de recuperação. Leva tempo para importar um despejo grande e reproduzir todos os eventos de um log de bin. Além disso, a criação de um despejo não deixa de ter suas implicações de desempenho. Provavelmente, esses despejos provavelmente exigem muito mais armazenamento do que um instantâneo. A configuração de um volume EBS exclusivamente para os bancos de dados e a captura instantânea que seria preferível na maioria dos aspectos (dito isso, tirar uma captura instantânea também tem um pouco de implicação no desempenho).
A beleza dos instantâneos e volumes EBS é que eles podem ser usados em outras instâncias. Se sua instância falhar na inicialização, você poderá anexar o volume raiz a outra instância para diagnosticar e corrigir o problema - ou apenas copiar seus dados - e poderá alternar volumes raiz com apenas alguns minutos de inatividade (pare a instância, desanexe o volume raiz, anexe um novo volume raiz, inicie a instância). Essa mesma idéia se aplica a ter seus dados em um segundo volume EBS. Basicamente, você apenas cria uma nova instância da AMI personalizada e anexa o volume atual do EBS a ela - isso ajuda a minimizar o tempo de inatividade.
(Pode-se argumentar (e eu provavelmente não o recomendaria) que você pode configurar duas cópias do MySQL no mesmo servidor (Master-slave), usando dois volumes EBS e, em seguida, encerrar seu slave para tirar uma foto instantânea de seu Volume do EBS - será consistente, sem tempo de inatividade -, mas provavelmente os custos de desempenho não valem a pena).
A AWS tem escalonamento automático - que poderá manter um número constante de instâncias (mesmo que esse número seja 1) -, no entanto, você implantaria a partir de um instantâneo - portanto, se seu instantâneo não for útil, a premissa não será muito útil. .
Mais alguns pontos - você pode implantar quantas instâncias quiser de um único instantâneo (diferente de um volume EBS, que pode ser anexado a uma única instância a qualquer momento). Além disso, os volumes EBS são restritos para uso em uma zona de disponibilidade, enquanto os instantâneos podem ser usados em uma região.
Idealmente, com um instantâneo, se o servidor ficar inativo, você poderá iniciar um novo usando o último instantâneo - especialmente se você separar o volume raiz dos dados, uma atualização incorreta resultará em um tempo de inatividade mínimo (já que você apenas transfira o volume EBS que contém seus dados - e tire uma foto instantânea para preservar qualquer coisa que possa ser corrompida devido a inconsistência).
Como observação lateral, a Amazon declara que a taxa de falhas dos volumes EBS aumenta com a quantidade de dados alterados desde a última captura instantânea.
Recomendações finais
- Use instantâneos - eles são ótimos - reduzem o tempo de inatividade muito mais do que causam
- Separe os dados e o volume raiz, talvez colocando os bancos de dados em seu próprio volume, e faça uma captura instantânea antes das atualizações, se necessário
- Use o bin-log para permanecer o mais "quente" possível - faça o upload (compactado) para o S3
- Verifique se realmente retirou os dados da instância (mesmo se os dados estiverem intactos em um volume EBS, o volume em si pode estar temporariamente inacessível).
Leitura recomendada:
(Acredito que escrevi muito, mas não o suficiente - mas espero que você encontre algo que valha a pena ler).