Um programador deve manter as bases de dados no nó de computação ou no nó de armazenamento?

Por predefinição, mantenha os ficheiros ativos da base de dados em armazenamento de baixa latência junto ao processamento e use o nó de armazenamento para cópias de segurança, despejos, réplicas e arquivos.

Essa predefinição muda quando o nó de armazenamento disponibiliza um percurso de armazenamento em blocos concebido de propósito, com latência medida, semântica de durabilidade correta e um benefício de recuperação que justifique a dependência adicional. A decisão não se resume a capacidade local versus capacidade de rede: os registos de transações, os ficheiros de dados, as cópias de segurança, os carregamentos das aplicações e as bases de dados de teste descartáveis têm padrões de escrita e consequências de falha diferentes.

Separe o estado da base de dados dos despejos e das cópias de segurança

Identifique todos os caminhos relacionados com a base de dados antes de escolher um nó. O diretório de dados principal e o registo de transações são estado ativo; exigem uma ordenação consistente das escritas e uma latência previsível. Os despejos lógicos, as cópias de segurança completas, os registos arquivados, as exportações e os ficheiros carregados pelas aplicações têm padrões de acesso diferentes e, muitas vezes, podem atravessar a rede em segurança.

Não monte uma partilha NAS e coloque tudo lá dentro. Mantenha o volume ativo da base de dados separado dos destinos das cópias de segurança e dos dados de aplicações em massa. Assim, é possível ajustar, monitorizar, encher, criar instantâneos, restaurar e migrar cada função sem fingir que todos os dados persistentes precisam do mesmo suporte.

Para bases de dados temporárias de branches ou testes de CI, o tempo de reconstrução pode ser mais importante do que a durabilidade. Coloque-as em armazenamento local rápido e recrie-as a partir de migrações ou de dados de origem sanitizados. No caso da base de dados de serviço usada diariamente por um programador, considere uma falha do SSD local como um evento de recuperação e mantenha a cópia remota suficientemente atualizada para cumprir o objetivo de ponto de recuperação declarado.

Meça o percurso de escrita antes de escolher um nó

O desempenho da base de dados depende de mais do que o débito sequencial. Meça a latência dos commits síncronos, as leituras e escritas aleatórias, a profundidade da fila durante o tráfego de cópias de segurança e o comportamento quando o percurso de rede fica bloqueado. Uma ligação 10GbE pode transferir ficheiros grandes rapidamente e, ainda assim, acrescentar latência e mais um ponto de falha a cada transação.

Uma comparação publicada do PostgreSQL concluiu que o NVMe local proporcionava uma latência mais baixa e previsível do que os serviços de nuvem testados com armazenamento ligado à rede, assinalando também as vantagens de elasticidade e durabilidade do armazenamento em rede. Esses testes de desempenho do PostgreSQL com armazenamento local e ligado à rede não garantem os mesmos resultados num laboratório doméstico, mas mostram por que razão a colocação da base de dados deve basear-se em medições da carga de trabalho, e não apenas na velocidade da interface.

Execute um teste representativo com o mesmo sistema de ficheiros, definições de sincronização, versão da base de dados, conjunto de dados e concorrência previstos para o serviço. Durante o teste, inicie uma cópia de segurança de grandes dimensões ou uma transferência de multimédia na rede de armazenamento. Se a latência de cauda ou o tempo de confirmação se tornarem erráticos, a capacidade centralizada não está a compensar a partilha do caminho.

Por predefinição, coloque os ficheiros da base de dados principal perto da computação

Para um programador, um nó de computação e bases de dados de dimensão modesta, SSD locais em espelho ou um volume local recuperável costumam tornar mais clara a gestão. O processo da base de dados, os respetivos ficheiros de dados e o registo de escrita antecipada falham em conjunto, enquanto o nó de armazenamento recebe cópias de segurança através de um processo que tem em conta a base de dados, em vez de alojar remotamente um sistema de ficheiros sempre aberto.

A colocação local não significa usar uma única unidade de arranque sem proteção. Sempre que possível, separe o volume da base de dados do sistema operativo, monitorize o espaço livre e o estado das unidades, reserve capacidade para operações de manutenção e exporte cópias de segurança antes das atualizações. Fixe a colocação dos contentores ou das máquinas virtuais para que um escalonador não inicie a base de dados noutro nó sem os respetivos dados.

Utilize armazenamento local apenas quando o processo de recuperação for fiável. Se a substituição do nó de computação exigir adivinhar se uma cópia está desatualizada, o armazenamento centralizado pode expor uma falha existente nas cópias de segurança, em vez de a criar. Corrija o processo de cópia de segurança e restauro antes de otimizar o caminho dos dados.

Featured

ZimaBoard 2 - Mini servidor doméstico para a sua grande ideia

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

Utilize o nó de armazenamento para cópias de segurança, réplicas e arquivos

Um nó de armazenamento é valioso quando recebe despejos consistentes com a aplicação, cópias de segurança completas, registos de transações arquivados, instantâneos imutáveis ou uma réplica da base de dados com uma finalidade de recuperação própria. Também pode alojar anexos grandes ou exportações analíticas, enquanto o catálogo da base de dados e os registos sensíveis à latência permanecem locais.

Os testes da comunidade com o PostgreSQL através de NFS num servidor de armazenamento produziram resultados contraintuitivos e levantaram questões de configuração, em vez de oferecerem uma resposta universal. É por isso que o armazenamento remoto como opção principal deve ser tratado como uma exceção concebida para o efeito: valide o comportamento síncrono, o tratamento de falhas, as opções de montagem, a semântica da cache e a recuperação na pilha específica.

Valide a recuperação de falhas e o critério para a migração

Teste quatro situações: reinicie a base de dados de forma normal, interrompa o nó de computação durante as escritas, interrompa a ligação ao armazenamento durante uma cópia de segurança e restaure para um anfitrião vazio. Confirme o ponto de recuperação, o tempo de recuperação, as verificações de integridade da base de dados e o comportamento de reconexão da aplicação. Um teste de desempenho rápido em condições normais não comprova que o percurso de escrita seja seguro quando ocorre uma interrupção.

A configuração está validada quando os dados ativos têm latência previsível, as cópias de segurança não conseguem sobrescrever nem bloquear a opção principal e um nó de computação de substituição consegue restaurar os dados sem depender de pressupostos de armazenamento não documentados. Transfira os ficheiros principais para um serviço de armazenamento concebido para o efeito apenas quando as vantagens medidas em recuperação ou mobilidade superarem a dependência da rede; volte a guardá-los localmente quando a latência de cauda ou as falhas de ligação se tornarem a principal causa de incidentes.

Para decidir a arquitetura geral, a comparação da ZimaSpace entre um NAS centrado no armazenamento e um servidor doméstico centrado na computação ajuda a determinar que função deve permanecer estável à medida que as cargas de trabalho de desenvolvimento mudam.

Regra final de configuração

Por predefinição, guarde os ficheiros ativos da base de dados num SSD local protegido e use o nó de armazenamento para cópias de segurança verificadas, arquivos e réplicas selecionadas. Escolha o armazenamento remoto como opção principal apenas depois de medir a semântica de escrita, a latência de cauda, o comportamento perante falhas e as vantagens na recuperação.