Sistema operativo de armazenamento vs. hipervisor num NAS com mini PC: que camada deve gerir os discos?

Instale o sistema operativo de armazenamento em bare metal quando a fiabilidade do armazenamento for a principal função do mini PC; escolha primeiro um hipervisor apenas quando os limites reais entre máquinas virtuais justificarem a camada adicional de falha e recuperação.

A questão importante não é se ambos os projetos podem funcionar. É saber que camada consegue detetar os discos físicos, comunicar o seu estado, controlar o conjunto de armazenamento e recuperar após uma falha do dispositivo de arranque ou da placa-mãe. Num NAS compacto, um controlador SATA ou uma ponte USB pode servir vários dispositivos, pelo que a resposta depende do percurso de hardware real e não de um diagrama.

Atribua a gestão dos discos, sem ambiguidades, a uma única camada

Um sistema operativo de armazenamento em bare metal deteta diretamente as unidades, os números de série, os contadores de erros, as temperaturas e os membros do conjunto de armazenamento. Isso facilita a interpretação dos alertas e a substituição de discos, porque a mesma camada gere tanto o sistema de ficheiros como os dados de hardware que o fundamentam.

Um projeto com o hipervisor primeiro pode preservar essa visibilidade ao passar um HBA ou controlador SATA completo para a máquina virtual de armazenamento. A apresentação de discos virtuais pode ocultar ou transformar dados de estado e cria uma dependência da configuração de armazenamento do anfitrião antes de o conjunto de armazenamento do sistema convidado poder sequer arrancar.

Escolha um responsável antes de criar dados. Se tanto o anfitrião como o sistema convidado puderem particionar, montar, colocar em cache ou monitorizar os mesmos dispositivos físicos, o projeto já falhou o primeiro requisito, independentemente do desempenho.

Verifique se o mini PC permite a passagem direta de um dispositivo sem dependências

Identifique todos os caminhos dos discos: SATA interno, ranhuras NVMe, pontes USB para SATA e qualquer adaptador PCIe. Depois, determine quais os dispositivos que partilham um controlador ou grupo IOMMU com a unidade de arranque do hipervisor, a interface de rede ou outro dispositivo que o anfitrião tenha de manter.

Um caso da comunidade que envolve um controlador SATA integrado partilhado com o anfitrião mostra o problema na prática: atribuir esse controlador ao sistema convidado de armazenamento também pode retirar ao hipervisor o acesso ao seu próprio disco. A passagem direta de discos virtuais individuais evitou a falha, mas reduziu a telemetria das unidades físicas.

A opção pelo hipervisor só é adequada se o sistema de armazenamento convidado puder receber um controlador completo e estável, ou outro caminho de dispositivo explicitamente suportado, enquanto o anfitrião mantém dispositivos de arranque e gestão independentes. Se essa separação for impossível, a gestão do armazenamento em bare metal é a opção mais simples.

Decida se a virtualização resolve um problema concreto

Um hipervisor pode isolar um sistema Windows convidado, uma rede de laboratório ou uma aplicação que precise do seu próprio kernel. Também pode facilitar a criação de instantâneos ao nível do sistema convidado e a reconstrução de sistemas. Estas vantagens são importantes quando as cargas de trabalho são reais e têm limites de manutenção ou de confiança distintos.

São menos importantes quando o plano consiste num serviço de armazenamento e em alguns contentores. Nesse caso, acrescentar um anfitrião, uma VM de armazenamento, redes virtuais e uma ordem de arranque dos sistemas convidados pode aumentar o número de componentes necessários para a mesma partilha de ficheiros, sem criar uma nova separação útil.

Execute um teste-piloto com a transferência de ficheiros mais exigente enquanto as cargas de trabalho previstas dos sistemas convidados estão ativas. Rejeite a opção do hipervisor se a contenção da CPU, a pressão sobre a memória ou o reinício de um sistema convidado puderem interromper o armazenamento de formas que a configuração bare-metal evitaria.

Featured

NAS de nuvem pessoal doméstica ZimaCube 2

ZimaCube2

$799.00 - $2,499.00

Buy Now

Compare os caminhos de recuperação antes das funcionalidades

Um segundo caso de passthrough, que envolve um HBA e um pool TrueNAS existente, ilustra por que motivo a ordem de arranque e o comportamento do firmware fazem parte do plano de recuperação. O pool pode estar intacto, mas a máquina virtual pode seguir um caminho de arranque inesperado.

Teste o restauro da configuração e a importação do pool com discos não críticos. Um instantâneo do hipervisor não é suficiente se depender do mesmo anfitrião avariado ou não conseguir recriar o mapeamento dos dispositivos; uma exportação da configuração do SO de armazenamento também não é suficiente se nunca tiver importado o pool em hardware de substituição.

Escolha a camada correspondente ao domínio de falha principal

Escolha um SO de armazenamento bare-metal quando o serviço de ficheiros for a função principal, o acesso direto ao estado dos discos e a importação simples do pool forem importantes, ou o Mini PC não conseguir isolar um controlador de forma eficaz. Execute apenas as aplicações cujas falhas esteja disposto a associar a esse anfitrião de armazenamento.

Escolha primeiro um hipervisor quando conseguir identificar vários sistemas convidados independentes, tiver caminhos separados para o anfitrião e os dispositivos de dados e já tiver testado o passthrough, a ordem de arranque, as atualizações do anfitrião e a recuperação. Para a questão mais abrangente da função do software, a decisão entre um SO NAS e Linux de uso geral é o próximo ponto de referência útil.

Deixe de comparar listas de funcionalidades quando o hardware atribui o mesmo controlador ao sistema anfitrião e aos discos de dados. Num NAS Mini PC, a topologia física pode determinar a arquitetura do software antes de a conveniência ou a qualidade do painel de controlo entrarem na discussão.