Estou trabalhando com um sistema que obtém um conjunto de 42 instantâneos rotativos diários do EBS de cada um de seus numerosos (40) volumes para fins de recuperação de desastres. Os volumes EBS são agregados em um volume RAID. Um conjunto de instantâneos consistentes é obtido congelando o sistema de arquivos durante a obtenção dos instantâneos. Cada volume individual tem apenas 2 TiB.
Durante o teste de DR, descobriu-se que leva mais de 24 horas para copiar os mais de 20 TiB de dados do aplicativo (banco de dados PostgreSQL, muitas tabelas grandes) de volumes baseados em instantâneos do EBS criados a partir dos instantâneos e em novos não instantâneos. volumes de backup. Isso ocorre com um paralelismo considerável na cópia, graças a 8 rsyncs trabalhando ao mesmo tempo em diferentes subárvores.
Se os dados não forem copiados para novos volumes EBS, o aplicativo baseado em PostgreSQL será executado como uma mosca no mel por muitos dias, presumivelmente até que os blocos do volume EBS sejam sujos, de modo que agora eles estejam diretamente no volume EBS, não vindo de o instantâneo.
Por contast, uma cópia dos mesmos dados de um conjunto de volumes EBS sem backup de instantâneo para outro leva apenas algumas horas, e fazê-lo com hardware "real" de escala semelhante leva muito menos novamente.
Por que eu estaria vendo diferenças de desempenho tão extremas entre volumes com backup de instantâneo e volumes simples?
Minha hipótese é que ele está copiando na gravação, portanto, limpe os blocos que não foram alterados, pois o instantâneo deve ser buscado separadamente. Se houver uma pilha de 40 instantâneos fazendo backup do volume, presumivelmente ele está tendo alguma dificuldade em localizar rapidamente o bloco no instantâneo mais recente em que aparece e buscá-lo.
Existe alguma maneira de forçar a AWS a pré-preencher de forma eficiente e linear todo o novo volume do EBS a partir do instantâneo, em vez de fazer uma cópia preguiçosa na gravação, como realmente parece fazer?
Alguma outra ideia para contornar isso? Um conjunto de instantâneos para DR é muito menos útil se a recuperação demorar mais de um dia.
A leitura do volume restaurado deve ser suficiente.
Curiosamente, parece que o uso sequencial de "leitura forçada" tem um
dddesempenho melhor do que as leituras mais aleatórias que resultariam da leitura do sistema de arquivos, mas é claro que você pode fazer as duas coisas ao mesmo tempo - vá em frente, monte-o e comece a fazer o que quer que seja você precisa, mas também leia e descarte do dispositivo de bloco comdd.Essa aparente diferença faria sentido, principalmente se a infraestrutura de snapshot do EBS não armazenar realmente os blocos de snapshot em partes do tamanho de um "bloco" (4.096 bytes). Parece que seria um design bastante ineficiente, exigindo milhares de operações para cada megabyte.
Pode melhorar ainda mais a restauração se você fizer várias leituras sequenciais começando em diferentes deslocamentos. Não testado, mas o gnu
ddaparentemente pode "pular" blocos e começar a ler diferente do início.Mas você definitivamente não precisa criar volumes "novos". Depois que os blocos são carregados por uma leitura, eles estão "no" EBS e não no instantâneo.
Realmente não deveria importar quantos instantâneos estavam fazendo o backup. Os dados não são armazenados "nos" instantâneos. Cada instantâneo contém o registro completo do que chamarei casualmente de "ponteiros" para todos os blocos de dados que o compõem (não apenas os alterados) e presumivelmente onde eles foram armazenados no armazenamento de apoio (S3) usado pela infraestrutura de instantâneo.
Se você tiver instantâneos A, B e C obtidos em ordem do mesmo volume e excluir o instantâneo B, todos os blocos que mudaram de A para B, mas não de B para C, ainda estarão disponíveis para restaurar o instantâneo C, mas eles não são literalmente movidos de B para C quando você exclui o instantâneo B.
Quando você exclui um snapshot, o EBS limpa o armazenamento de backup de blocos que não são mais necessários usando a contagem de referência. Os blocos que não são referenciados por nenhum instantâneo são tratados em segundo plano por um processo de várias etapas que primeiro os sinaliza como desnecessários, que para de cobrar por eles e, na verdade, os exclui alguns dias depois, quando o fato de que são genuinamente em refcount = 0 foi confirmado. Fonte.
Por causa disso, o número de instantâneos que originalmente contribuíram com blocos para o volume restaurado não deve ter um motivo para afetar o desempenho.
Informações adicionais possivelmente úteis: o seguinte não altera a precisão da resposta acima, mas pode ser útil em determinadas situações.
No final de 2019, a EBS anunciou um novo recurso chamado Fast Snapshot Restore , que permite que os volumes criados em zonas de disponibilidade designadas a partir de snapshots designados sejam instantaneamente ativados sem a necessidade de aquecimento.
Usando um depósito de crédito e com base no tamanho do instantâneo designado (ou seja, o tamanho do volume do disco do qual foi obtido) -- não no tamanho do volume de destino (que pode ser maior que o do instantâneo) -- isso O recurso permite criar volumes de 1024 G/tamanho por hora, portanto, um instantâneo de 128 GiB pode criar 8 volumes pré-aquecidos por hora. À medida que os instantâneos ficam menores, o número de volumes que você pode criar por hora, por instantâneo e por zona de disponibilidade é limitado a 10.
O serviço também é surpreendentemente caro -- US$ 0,75 por hora, por snapshot, por zona de disponibilidade (!?) -- no entanto, isso pode não ser algo que você precisaria deixar rodando continuamente e, sob essa luz, parece ter algum valor potencial .
Quando você ativa o recurso, a API do serviço pode informar quando ele está realmente pronto para uso e 60 minutos por TiB é o cronograma declarado para "otimizar um instantâneo" (o que, lendo nas entrelinhas, significa construir e aquecer um primário oculto volume dentro do EBS a partir do snapshot, que posteriormente será clonado pelo serviço para criar volumes EBS adicionais; o recurso parece ser realmente utilizável apenas após a conclusão desse estágio e os volumes criados a partir do mesmo snapshot antes desse ponto são apenas volumes comuns).
Contanto que você tenha tempo para esperar pelo estágio de "otimização" e processos em vigor para encerrar o comportamento de restauração rápida quando não precisar mais dele (para evitar uma cobrança de cobrança inesperada muito grande), isso parece ter aplicabilidade em casos limitados casos de uso.