instância do AWS EC2 (Windows Server 2008): instantâneo diário do EBS sem tempo de inatividade

Question

TL; TR

Eu preciso fazer backup de um volume do AWS EBS sem tempo de inatividade.

Em detalhes

Eu tenho uma instância do "Windows Server 2008" " EC2 " no Amazon AWS com dois EBS-volumes como C: e D: drivers do sistema.

No driver C: funciona o sistema operacional, no driver D: funciona um serviço da web, eu preciso fazer backup apenas D: .

O serviço web é uma aplicação Delphi SOAP usada para baixar alguns arquivos de acordo com a requisição, por exemplo:

http://www.example.com/dir/service.dll?filename=foo.zip

(nesse caso, o serviço da web responde com o arquivo foo.zip , localizado em D:\dir\files\ ).

Em cada solicitação, este aplicativo grava alguns arquivos (arquivos de sessão e arquivos de log) em D:\dir\temp\ . Isso é um problema, porque tirar um instantâneo do volume de uso não é seguro, de Documentos da AWS :

You can take a snapshot of an attached volume that is in use. However, snapshots only capture data that has been written to your Amazon EBS volume at the time the snapshot command is issued. If you can pause any file writes to the volume long enough to take a snapshot, your snapshot should be complete.

Minha ideia é implementar em meu serviço da web um modo somente leitura, baseado na existência de um arquivo em um diretório.

procedure onRequest(Sender: TObject; Request: TWebRequest; Response: TWebResponse; var Handled: Boolean);
begin
    FReadOnlyMode := FileExists('D:\dir\flag\read_only_mode.txt');
    // ... other code

Em cada solicitação, o serviço verifica se o arquivo existe e se ele existe, o servidor entrando no modo de somente leitura e não escreve nada (nenhum arquivo de log, nenhum arquivo de sessão).

A estratégia de backup é baseada em uma tarefa diária do Windows, que executa um arquivo de lote, por exemplo. backup.bat :

:: 1. stop all web service writes operation
echo.>D:\dir\flag\read_only_mode.txt

:: 2. Use sync.exe for flush all data to disk D
sync.exe d

:: 3. Use Amazon CLI for snapshot the volume:
aws ec2 create-snapshot --volume-id vol-XXXXXXXXXX --description "D snapshot."

:: 4. Remove 'read_only_mode' flag:
del /F /Q D:\dir\flag\read_only_mode.txt

(mais informações sobre Windows Sync e Amazon CLI )

A pergunta é: meus snapshots do EBS serão consistentes?

Sou novo na AWS, qualquer outra sugestão é apreciada!

Desculpa pelo meu mau inglês

    

Answer 1

Em teoria, para que os snapshots do EBS sejam consistentes , você precisaria estar executando nenhum aplicativo com estado no momento em que o snapshot começa a ser criado. Infelizmente, o próprio Windows pode ser considerado stateful, o que pode causar confusão, especialmente se você estiver usando o cache de gravação.

Existem algumas partes interessantes mas confusas para isso:

• A parte 'instantâneo' do processo de instantâneo é feita imediatamente, não é necessário desativar gravações durante todo o tempo em que um instantâneo está pendente. Um grande volume pode levar horas para concluir o instantâneo, mas essa é apenas a parte backup ou cópia do instantâneo. Enquanto a Amazon não sofrer um corte de energia durante esse processo, o instantâneo final será os dados no disco exatamente no momento do instantâneo.
• Os instantâneos são obtidos de forma assíncrona. Portanto, a ferramenta de linha de comando não deve bloquear enquanto a captura instantânea estiver sendo criada, e seu retorno não terá relevância para o status da captura instantânea.

Tudo considerado, no entanto, isso geralmente não causa um grande problema. A questão da consistência é geralmente pequena. A principal coisa que pega as pessoas é a questão do cache. Se você tem o cache de gravação de disco ativado em seu sistema operacional ou aplicativo (ele está ativado no Windows por padrão), só porque você pensa ter escrito um arquivo em disco, não significa que o arquivo tenha sido gravado.

A outra grande questão que afasta as pessoas são as transações. Se, por exemplo, se você criar um site que permita o upload de arquivos, seus problemas estarão relacionados à captura instantânea durante o processo. Um exemplo comum seria um registro de banco de dados dizendo que o arquivo '1234' foi enviado para 'd: / files / 1234', mas o arquivo não existente como o arquivo não terminou de ser copiado para esse local quando o instantâneo aconteceu, mas o registro do banco de dados já está comprometido.

Uma coisa sobre a qual as pessoas se confundem é a consistência das palavras neste contexto, não se refere à capacidade de restaurar o instantâneo. Você sempre poderá criar um volume a partir do snapshot, o problema é se o seu aplicativo conseguir entender em que estado ele estava depois.

Se você tirasse um instantâneo do EBS de uma unidade do sistema Windows durante um procedimento de atualização do Windows, você acabará com alguns arquivos atualizados e alguns arquivos não. Felizmente, o Windows entende o processo de atualização e deve notar que a atualização falhou e lidar com isso na inicialização.

Se você pode escrever seu aplicativo para não se preocupar com arquivos parcialmente gravados em disco (não importa se uma entrada de log está faltando?), não é necessário usar o modo somente leitura. Uma maneira de abordar isso com uploads de arquivos é ter a pasta de upload diferente do local final (no mesmo disco). Quando o upload do arquivo for concluído e bem-sucedido, mova o arquivo para o local de repouso. O movimento deve ser realizado como um arquivo 'renomear' ao invés de byte por byte, e acontecer instantaneamente. Se o arquivo nunca chegar ao local final, você sabe que o upload falhou.