AWS EBS snapshot. A consistência do FileSystem REALMENTE é necessária?

1

Eu tenho lido muito sobre o aws ebs e muitas pessoas parecem encorajar as pessoas a congelar o sistema de arquivos durante o instantâneo. No entanto, este pedaço de documentação amazônica implora diferir:

While it is completing, an in-progress snapshot is not affected by ongoing reads and writes to the volume.

https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-creating-snapshot.html

Por que muitas pessoas congelam o sistema de arquivos durante o snapshot enquanto a documentação do aws diz que o snapshot não é afetado por E / S?

E se meu sistema de arquivos for usado para um ftp?

E se meu sistema de arquivos for usado para um banco de dados?

    
por Nico 16.02.2018 / 05:47

2 respostas

2

Resposta curta: depende do tipo de aplicativo que você está executando em sua instância.

Resposta longa: Basicamente, tirar uma foto instantânea de um computador em execução é semelhante a "extrair o plugue de energia", ou seja, uma falha súbita, imediata e inesperada.

Quando executado com a barreira de E / S habilitada, o moderno sistema de arquivos com diário deve ser consistente, apesar de qualquer falha. Isto não significa que os dados na memória não serão perdidos; em vez disso, os dados comprometidos são garantidos para serem armazenados em armazenamento persistente (isto é: disco).

Isso realmente se aplica a qualquer aplicativo com diário apropriado, especialmente bancos de dados compatíveis com ACID (uma lista não inclusiva: MSSQL, InnoDB, PostgreSQL, Oracle, IBM DB2, ecc). Novamente, isso não significa que uma perda repentina de energia (ou um snapshot restaurado, não em repouso) não levará a perda de dados; em vez disso, significa que quando um COMMIT (possivelmente implícito) retorna, quaisquer dados relevantes estão no armazenamento estável.

Com esse aplicativo registrado, você não precisa estritamente quiesce o sistema de arquivos. A primeira inicialização após um instantâneo 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 muitos aplicativos que não registram adequadamente suas atualizações e que exigem o equivalente a um fsck para retornar a um estado consistente. O principal exemplo é o MySQL + MyISAM: este mecanismo de banco de dados (muito comum) não é compatível com ACID, pois sua grande velocidade de gravação é alcançada por lotes de operações de E / S não relacionadas, com pouca consideração para barreiras regulares de E / S . Um desligamento inadequado (isto é: perda de energia, travamento do sistema ou do mysql, snapshot não-habilitado) O banco de dados MyISAM pode ficar inoperante até que um mysqlcheck/mysqlrepair seja executado.

O guia que recomenda desativar o sistema de arquivos antes que um instantâneo faça isso por esse motivo: alguns aplicativos "despreparados" (leia-se: MyISAM) podem ser danificados pelo desligamento repentino e pela restauração subseqüente, exigindo uma verificação de consistência. p>

Resumindo: se você usar um sistema de arquivos com as barreiras de I / O ativadas (padrão em ext4 e XFS) e um banco de dados compatível com ACID, você deve estar seguro tirar instantâneos não atendidos. Na pior das hipóteses, você pode ver alguns erros / avisos não fatais ao montar o snapshot, mas a resposta do diário trará o sistema em um estado consistente. Se usando MyISAM, no entanto, é melhor congelar / quiesce seu sistema de arquivos antes de tirar um instantâneo.

    
por 16.02.2018 / 20:57
4

Os instantâneos da Amazon não são seguros se forem executados enquanto um sistema estiver em execução. Eles estão seguros se você desligar o sistema antes de criar o instantâneo. Qualquer dado do sistema de arquivos armazenado em cache nos buffers do sistema operacional ou nos buffers de um aplicativo (por exemplo, bancos de dados) não fará parte do instantâneo. Isso pode levar a corrupção irrecuperável.

Tanto o Linux quanto o Windows têm mecanismos fornecidos pelo sistema operacional para congelar o sistema (informe os aplicativos para liberar seus dados no disco). Quando isso estiver concluído, um descongelamento é executado, permitindo que os aplicativos continuem. Entre o congelamento e o descongelamento, o instantâneo é tirado. Nota: a maioria das aplicações não suporta congelamento / descongelamento e algumas implementam errado. Revise a documentação de seus fornecedores com cuidado.

Outro item importante é revisar onde seus aplicativos estão armazenando seus dados. Bancos de dados, sob design de melhores práticas, armazenam seus dados, logs, etc. em diferentes sistemas de arquivos. Isso significa que você pode estar iniciando um instantâneo de um volume em um horário diferente para o instantâneo 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 os instantâneos consistentes entre o aplicativo e o que é consistente com o aplicativo.

Aqui está um artigo sobre os instantâneos do EBS que explica as diferenças.

Instantâneos do EBS: consistente com falhas versus consistente com aplicativos

[Atualização após os comentários de Michael]

Os instantâneos implementam a Cópia na gravação (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 em 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 instantâneo. Durante a criação da captura instantânea, as estruturas de dados de volume necessárias são criadas / copiadas para que a retenção do congelamento não seja necessária. Dependendo do sistema e da quantidade de dados armazenados em cache na memória, o tamanho do sistema operacional e dos diários de aplicativos, etc., o ciclo de congelamento / instantâneo / descongelamento pode ser tão rápido quanto alguns segundos.

Aqui está um artigo sobre várias tecnologias de snapshots que incluem uma explicação de Copy-on-Write:

Usando diferentes tipos de tecnologias de instantâneos de armazenamento para dados proteção

    
por 16.02.2018 / 06:39