Conhecendo as distribuições Linux e FreeBSD em CD, cresci dando a cada diretório como /usr, /var, /opt, e assim por diante, sua própria partição. Uma das regras sagradas era que /deve ser protegido contra execução completa.
Hoje em dia vejo com muita frequência sistemas onde o par /tmpou /varestá na partição raiz e sistemas falhando porque um aplicativo ocupou todo o espaço disponível, por exemplo, abaixo do /optou /tmp.
Então, por que muitos administradores usam apenas uma partição em vez de uma abordagem mais sofisticada para particionamento? Perdi alguma coisa na última década?
Responder1
O particionamento simples é o padrão em muitos ambientes. Imagens de sistema operacional populares em muitas nuvens, esquema de partição padrão em instaladores, simplificam a automação para encontrar um disco. Funciona bem, os discos muitas vezes podem ser estendidos para tamanhos enormes online e o cloud-init estenderá o sistema de arquivos para você.
Até que fique confuso. Ocasionalmente, as pessoas trazem problemas para o servidor. Falha de instâncias falhando porque / está completamente cheio. Depois de coisas comuns, como limpeza de arquivos de log, eles ficam se perguntando como reduzir o tamanho de / e evitar que isso aconteça novamente. Complicado, o reparticionamento não pode ser feito on-line, a redução dos sistemas de arquivos definitivamente requer a desmontagem e, portanto, a inicialização de um ambiente de recuperação, e o Linux XFS não pode ser reduzido de qualquer maneira.
Minha configuração ideal de armazenamento do Linux é um pequeno disco para inicialização e sistema operacional e discos separados para armazenamento de aplicativos. Tudo LVM, deixando algum espaço livre no VG para necessidades futuras. Por exemplo, em um servidor de banco de dados, inicialize a partir de /dev/sda1, mas os dados em /var/lib/pgsql/ são armazenados em um VG diferente em PV /dev/sdb. Um esquema como esse permite que os dados e o sistema operacional sejam restaurados separadamente e truques interessantes, como criar uma nova instância de VM, mas mover o mesmo volume de dados. Provavelmente muito complicado para uma instância de aplicativo simples, sem muito estado e, portanto, com requisitos simples de armazenamento. Mas ainda é possível.
Responder2
Também notei a tendência que você mencionou, mas as respostas serão opinativas.
No passado, tínhamos máquinas físicas com discos físicos: era difícil fazer alterações e exigia tempo de inatividade. Hoje em dia, graças aos Gerenciadores de Volume Lógico e às Máquinas Virtuais, é muito fácil expandir um disco:
- Todos os sistemas de arquivos usados em sistemas de servidores suportam expansão ao vivo.
- As configurações RAID são transparentes para o sistema conectado - organizadas no armazenamento.
- As máquinas virtuais possuem discos virtuais que podem ser facilmente expandidos.
- Em servidores físicos conectados a sistemas de armazenamento, um disco virtual é apresentado em essência.
Portanto, muitos administradores optam por uma configuração mais simples (ou simplista!), sistemas particionados únicos (ou duas partições, apenas os dados separados) e contam com ferramentas de monitoramento para notificar pouco espaço livre, que pode ser facilmente expandido.
Responder3
Um dos motivos pode ser que hoje em dia você pode atualizar facilmente as versões do sistema operacional sem reformatar as partições.
Ainda crio uma partição dedicada para/home, mas provavelmente não há mais motivos reais.
Responder4
“Mantenha a simplicidade” é um princípio de design bastante comum. As VMs de hoje são fáceis de expandir, diferentemente dos servidores físicos de anos atrás.