Topologia de armazenamento para o primeiro laboratório doméstico: unidade de arranque, dados das aplicações e armazenamento em massa

Um primeiro laboratório doméstico precisa de funções de armazenamento separadas para que reinstalar o host, reconstruir uma aplicação ou expandir a capacidade não implique mover todos os conjuntos de dados de uma só vez.

A unidade de arranque, o estado persistente das aplicações e o armazenamento em massa têm padrões distintos de falha, latência e crescimento. Tratá-los como um único disco indiferenciado é conveniente apenas até uma atualização encher o sistema de ficheiros raiz, uma base de dados competir com os ficheiros multimédia ou uma atualização de capacidade obrigar a mover o sistema operativo. Uma topologia clara permite alterar cada camada sem redefinir as restantes.

Atribua funções de armazenamento antes de escolher a capacidade das unidades

Comece pelo comportamento dos dados, não pelas designações do hardware. A camada do sistema inclui o sistema operativo, o estado dos pacotes, o motor de contentores e a configuração do host. A camada de dados das aplicações inclui bases de dados, configuração, segredos, índices e outros estados persistentes. A camada de armazenamento em massa inclui conteúdos multimédia, arquivos, cópias de segurança, ficheiros ISO, ficheiros de projetos e dados partilhados da família. A cache e os ficheiros temporários constituem uma quarta função, descartável.

A Puget Systems recomenda manter o sistema operativo e as aplicações na unidade principal e separar os recursos dos projetos quando é importante poder restaurá-los ou reinstalá-los de forma independente. Essa separação do armazenamento por função aplica-se facilmente a um laboratório doméstico, mesmo quando a carga de trabalho não envolve edição de vídeo.

Para cada serviço planeado, indique a que função pertence cada caminho, quem é o responsável, se pode ser regenerado, a que ritmo cresce e que operação de restauro o recupera. A escolha da unidade só deve ser feita depois de este mapa revelar os requisitos de capacidade e latência.

Mantenha a unidade de arranque substituível e com capacidade limitada

A unidade de arranque deve ter espaço suficiente para o sistema operativo, os registos, as atualizações de pacotes, as imagens de contentores e uma quantidade controlada de dados de trabalho. Não deve tornar-se o único local para bases de dados, ficheiros da família, imagens de máquinas virtuais ou carregamentos de aplicações, simplesmente porque essas localizações predefinidas eram as mais fáceis durante a instalação.

O guia da hierarquia do sistema de ficheiros da LinuxBlog explica que sistemas de ficheiros separados podem impedir que uma área de dados encha o sistema de ficheiros raiz e afete o resto do servidor. Esse princípio de contenção do sistema de ficheiros raiz é a principal razão para manter o crescimento persistente fora da camada de arranque.

Documente a configuração do host, as definições dos pacotes ou da composição, as definições de rede e as localizações das montagens de dados externos. A unidade de arranque passa no teste de substituibilidade quando pode ser reinstalada sem restaurar grandes volumes de dados e sem ter de adivinhar onde estava guardado o estado das aplicações.

Coloque os dados persistentes da aplicação num caminho de baixa latência definido deliberadamente

Bases de dados, índices, registos de contas, configurações e ficheiros pequenos atualizados frequentemente comportam-se de forma diferente de grandes arquivos multimédia. Podem ocupar pouco espaço, mas uma latência elevada ou cópias de segurança inconsistentes podem tornar as aplicações lentas ou impossíveis de recuperar. Um caminho dedicado, suportado por SSD, mantém este estado visível e independente das camadas descartáveis dos contentores.

A Better Stack explica que os volumes do Docker permitem que os dados persistentes tenham um ciclo de vida independente do contentor que os utiliza. Esse limite entre o ciclo de vida da aplicação e o dos dados é essencial, mesmo quando o laboratório doméstico usa montagens vinculadas em vez de volumes com nome.

Use localizações legíveis, como /srv/appdata/photo-service e /srv/appdata/database-name. Quando necessário, faça cópias de segurança das bases de dados com um método consistente com a aplicação e registe dependências como credenciais, versões do esquema e certificados. Não misture a cache neste caminho apenas porque é produzida pela mesma aplicação.

Featured

NAS de nuvem pessoal doméstica ZimaCube 2

ZimaCube2

$799.00 - $2,499.00

Buy Now

Use o armazenamento em massa para dados que exigem muita capacidade e são menos sensíveis à latência

O armazenamento em massa é o local adequado para bibliotecas multimédia, arquivos, cópias de segurança de dispositivos, ficheiros ISO, grandes volumes de dados de projetos e outros conjuntos de dados cuja principal necessidade é a capacidade. Os HDD continuam a ser úteis neste caso, porque as leituras e escritas sequenciais de grande dimensão nem sempre justificam o custo de armazenar todos os dados em memória flash.

A comparação da TechTarget entre SSD e HDD explica que os SSD oferecem menor latência, enquanto os HDD continuam a satisfazer de forma económica os requisitos de armazenamento de grande capacidade. Essa distinção entre latência e capacidade sustenta uma topologia em que os dados da aplicação ficam em SSD e os dados grandes, substituíveis ou sequenciais ficam em HDD.

O meio de armazenamento não é, por si só, a topologia. A regra importante é que as aplicações vejam caminhos estáveis baseados em funções, enquanto o administrador pode substituir posteriormente o armazenamento físico por trás desses caminhos.

Estabilizar os pontos de montagem e a ordem de arranque dos serviços

Uma unidade de dados que nem sempre é montada corretamente pode fazer com que uma aplicação grave numa pasta vazia do disco de arranque. O serviço pode parecer estar a funcionar normalmente enquanto enche o sistema de ficheiros errado. Identificadores estáveis e dependências de arranque evitam esta falha silenciosa da topologia.

O guia de particionamento de discos da LinuxBlog demonstra como inspecionar UUIDs de sistemas de ficheiros e pontos de montagem, em vez de depender apenas dos nomes dos dispositivos. Esse processo de verificação de montagens persistentes mantém os caminhos estáveis após reinícios, alterações de controladores ou adição de discos.

Monte os sistemas de ficheiros de dados em massa e de dados das aplicações antes de iniciar os contentores ou serviços dependentes. Teste dois reinícios e uma desconexão controlada do armazenamento com dados descartáveis. A ausência de um ponto de montagem deve impedir a execução da carga de trabalho ou gerar um alerta, em vez de redirecionar as gravações para o sistema de ficheiros raiz.

Faça cópias de segurança do estado das aplicações e dos dados em massa de acordo com diferentes unidades de recuperação

O estado das aplicações requer frequentemente configuração, consistência da base de dados, segredos e compatibilidade entre versões. Os dados em massa podem ser restaurados como ficheiros e diretórios. Um instantâneo de um único sistema de ficheiros pode ser útil, mas não garante por si só a recuperação completa de uma aplicação se as dependências estiverem noutro local.

A N2WS explica que a recuperação de bases de dados pode envolver dados, esquema, detalhes de configuração, registos e metadados de cópia de segurança, em vez de apenas uma pasta copiada. Esse modelo de recuperação de aplicações em várias partes permite definir políticas de cópia de segurança distintas para o estado das aplicações e para os ficheiros em massa.

Faça cópias de segurança das definições das aplicações e do estado consistente com frequência suficiente para cumprir os limites aceitáveis de perda de dados do serviço. Proteja os ficheiros em massa com instantâneos ou versões, além de uma cópia independente. Exclua a cache, a menos que a sua reconstrução provoque um tempo de inatividade inaceitável. Guarde pelo menos uma cópia de recuperação fora do conjunto de armazenamento ativo e teste tanto o restauro de um ficheiro como a reconstrução completa de uma aplicação.

Planear o crescimento da capacidade sem mover todas as camadas

A unidade de arranque cresce com pacotes, registos, imagens e atualizações. Os dados das aplicações crescem com bases de dados, índices e dados dos utilizadores. O armazenamento em massa cresce com ficheiros multimédia, cópias de segurança e arquivos. Estas taxas não estão relacionadas, pelo que cada nível precisa do seu próprio limiar de alerta e plano de expansão.

A TechTarget define o armazenamento por níveis como a associação dos dados a classes de armazenamento com diferentes características de preço, desempenho, capacidade e disponibilidade. Esse conceito de organização por níveis baseada em políticas ajuda a evitar que todos os problemas de capacidade se transformem numa migração de todo o servidor.

Configure alertas separados para a utilização do sistema de ficheiros raiz, dos dados das aplicações e do conjunto de armazenamento em massa. Sempre que possível, mantenha uma reserva operacional de 15–20%. Expanda a camada de armazenamento em massa adicionando ou substituindo capacidade por trás do mesmo caminho de montagem. Transfira os dados das aplicações apenas quando as medições de latência, proteção ou capacidade o justificarem, e não apenas por ter sido instalada uma nova unidade.

Escolha a topologia mais simples que mantenha claros os limites de recuperação

Num laboratório doméstico muito pequeno, as funções de arranque e dos dados das aplicações podem ficar num único SSD, desde que os diretórios sejam explícitos, tenham cópias de segurança e limites definidos. Os ficheiros de grande dimensão devem continuar num caminho de armazenamento separado. Uma disposição mais duradoura usa um SSD de arranque, uma camada protegida de SSD para os dados das aplicações e um conjunto de armazenamento em massa com várias unidades, mas só vale a pena acrescentar dispositivos quando isso simplifica a delimitação de falhas e a recuperação.

O projeto de servidor compacto da ServeTheHome mostra como se pode conceber um pequeno nó dedicado em torno de uma combinação definida de memória, armazenamento e rede, sem precisar de uma plataforma à escala de um bastidor. Esse modelo de servidor compacto e adaptado a uma função específica é uma melhor referência para um primeiro laboratório doméstico do que acrescentar camadas de armazenamento sem necessidade comprovada.

O guia da ZimaSpace sobre como construir um primeiro servidor em torno de três serviços interligados ajuda a identificar as funções iniciais dos dados das aplicações. Um servidor doméstico compacto ZimaBoard 2 é adequado para uma topologia compacta em que as camadas de arranque e das aplicações se mantêm próximas do armazenamento ligado diretamente por SATA ou PCIe. Um NAS com IA ZimaCube 2 torna-se a base mais adequada quando a camada de armazenamento em massa exige capacidade integrada para várias unidades, retenção mais prolongada, acesso simultâneo e recuperação centrada no armazenamento.

A topologia é bem-sucedida quando a substituição da unidade de arranque, a reconstrução de uma aplicação ou a expansão da capacidade de armazenamento em massa altera apenas uma camada e mantém claras as restantes funções de armazenamento.