Tenho lido muito sobre aws ebs e muitas pessoas parecem encorajar as pessoas a congelar o sistema de arquivosduranteo instantâneo. No entanto, esta documentação da Amazon discorda:
Enquanto estiver sendo concluído, um instantâneo em andamento não será afetado por leituras e gravações contínuas no volume.
https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html
Por que muitas pessoas congelam o sistema de arquivos durante o instantâneo enquanto a documentação do AWS diz que o instantâneo não é afetado pela E/S?
E se meu sistema de arquivos for usado para FTP?
E se meu sistema de arquivos for usado para um banco de dados?
Responder1
Resposta curta:isso realmente depende do tipo de aplicativo que você está executando em sua instância.
Resposta longa:Basicamente, tirar uma foto instantânea de uma máquina em funcionamento é semelhante a "desligar a tomada" - ou seja: uma falha repentina, imediata e inesperada.
Ao executar com a barreira de E/S habilitada, o sistema de arquivos moderno com diário deve ser consistente, apesar de qualquer travamento. Isso faznãosignifica que os dados na memória não serão perdidos; em vez disso, os dados confirmados sãogarantidopara ser armazenado em armazenamento persistente (ou seja: disco).
Isso realmente se aplica a qualquer aplicativo registrado corretamente, especialmente bancos de dados compatíveis com ACID (uma lista não inclusiva: MSSQL, InnoDB, PostgreSQL, Oracle, IBM DB2, ecc). Novamente, isso faznãosignifica que uma perda repentina de energia (ou um instantâneo restaurado e não desativado) não levará a nenhuma perda de dados; em vez disso, significa que quando um COMMIT (possivelmente implícito) retorna, todos os dados relevantes estão em armazenamento estável.
Com esse aplicativo registrado em diário, você não precisa necessariamente desativar o sistema de arquivos. Na primeira inicialização após um snapshot restaurado, o sistema responderá aos seus diários (sistema de arquivos e bancos de dados) e um estado consistente será alcançado.
No entanto, existem muitas aplicações quenãoregistrar adequadamente suas atualizações e quaisexigiro equivalente a a fsckpara retornar a um estado consistente. O exemplo principal é MySQL+MyISAM: este mecanismo de banco de dados (muito comum) énãoCompatível com ACID, pois sua grande velocidade de gravação é obtida agrupando operações de E/S não relacionadas, com pouca consideração pelas barreiras de E/S regulares. Um desligamento incorreto (ou seja: perda de energia, falha do sistema ou mysql, snapshot não ativado) O banco de dados MyISAM pode ficar inoperante até que um procedimento mysqlcheck/mysqlrepairseja executado.
Os vários guias que recomendam desativar o sistema de arquivos antes de um snapshot fazem isso exatamente por este motivo: algum aplicativo "despreparado" (leia-se: MyISAM) pode ser um tanto danificado pelo desligamento repentino e restauração subsequente, exigindo uma verificação de consistência.
Conclusão:se você usar um sistema de arquivos registrado em diário com barreiras de E/S habilitadas (padrão em ext4 e XFS)eum banco de dados compatível com ACID, você estará seguro ao tirar snapshots não ativados. Na pior das hipóteses, você poderá ver algum erro/aviso não fatal ao montar o instantâneo, mas a resposta do diário deixará o sistema em um estado consistente. Se estiver usando MyISAM, entretanto, é melhor congelar/desativar seu sistema de arquivos antes de tirar um snapshot.
Responder2
Os snapshots da Amazon por si só não são seguros se forem obtidos enquanto o sistema estiver em execução. Eles estarão seguros se você desligar o sistema antes de criar o instantâneo. Quaisquer dados do sistema de arquivos armazenados em cache nos buffers do sistema operacional ou nos buffers de um aplicativo (por exemplo, bancos de dados) não farão parte do instantâneo. Isso pode levar a uma corrupção irrecuperável.
Tanto o Linux quanto o Windows possuem mecanismos fornecidos pelo sistema operacional para congelar o sistema (informar os aplicativos para liberar seus dados no disco). Uma vez concluído, um descongelamento é realizado permitindo que as aplicações continuem. Entre o congelamento e o descongelamento, o instantâneo é tirado. Nota: a maioria dos aplicativos não suporta congelamento/descongelamento e alguns o implementam incorretamente. Revise a documentação do seu fornecedor com cuidado.
Outro item importante é revisar onde seus aplicativos estão armazenando seus dados. Os bancos de dados, de acordo com as melhores práticas de design, armazenam seus dados, logs, etc. em diferentes sistemas de arquivos. Isso significa que você pode estar iniciando uma captura instantânea de um volume em um momento diferente da captura instantânea de outro volume (que pode ser necessário como um conjunto para restaurar com êxito o aplicativo e seus dados).
A chave é entender a diferença entre instantâneos consistentes com falhas e consistentes com aplicativos.
Aqui está um artigo sobre snapshots do EBS que explica as diferenças.
Instantâneos do EBS: consistentes com falhas versus consistentes com aplicativos
[Atualização após os comentários de Michael]
Os instantâneos implementam Copy-on-Write (COW). Depois que um instantâneo for iniciado, o sistema de arquivos poderá ser modificado. Se o sistema de arquivos gravar em um bloco de disco, o subsistema COW copiará o bloco original para seu cache interno para que o sistema de arquivos possa ser modificado durante o instantâneo.
Não é necessário manter o sistema de arquivos congelado durante o snapshot. Durante a criação do snapshot, as estruturas de dados de volume necessárias são criadas/copiadas para que não seja necessário manter o congelamento. Dependendo do sistema e da quantidade de dados armazenados em cache na memória, do tamanho do sistema operacional e dos diários do aplicativo, etc., o ciclo de congelamento/instantâneo/descongelamento pode durar apenas alguns segundos.
Aqui está um artigo sobre várias tecnologias de snapshot que incluem uma explicação sobre Copy-on-Write:
Usando diferentes tipos de tecnologias de snapshots de armazenamento para proteção de dados