Quão ruim é realmente instalar o Linux em uma grande partição?

Estaremos rodando o CentOS 7 em nosso novo servidor. Temos unidades de 6 x 300 GB em RAID6 internas ao servidor. (O armazenamento é amplamente externo na forma de uma caixa de ataque de 40 TB.) O volume interno chega a cerca de 1,3 TB se formatado como um único volume. Nosso administrador de sistemas acha que é uma péssima idéia instalar o sistema operacional em uma grande partição de 1,3 TB.

Eu sou biólogo. Instalamos constantemente um novo software para executar e testar, a maioria dos quais chega em / usr / local. No entanto, como temos cerca de 12 biólogos não especialistas em computação que usam o sistema, também coletamos muito lixo em casa. Nosso último servidor tinha uma partição de 200 GB para / e, após 2,5 anos, estava 90% cheio. Não quero que isso aconteça novamente, mas também não quero ir contra o conselho de especialistas!

Como podemos usar da melhor maneira possível os 1,3 TB disponíveis para garantir que haja espaço disponível quando e onde for necessário, mas que não crie um pesadelo de manutenção para o administrador de sistemas?

Os principais motivos (históricos) de particionamento são:

• para separar o sistema operacional dos dados do usuário e do aplicativo . Até o lançamento do RHEL 7, não havia caminho de atualização suportado e uma atualização de versão principal exigiria uma reinstalação e, por exemplo, ter /homeoutros dados (de aplicativos) em partições separadas (ou volumes LVM) permite preservar facilmente os dados do usuário e dados do aplicativo e limpe as partições do SO.

• Os usuários não podem fazer login corretamente e seu sistema começa a falhar de maneiras interessantes quando você fica sem espaço em disco completamente. Várias partições permitem atribuir espaço em disco reservado para o sistema operacional e mantê-lo separado da área em que os usuários e / ou aplicativos específicos podem gravar (por exemplo, /home /tmp/ /var/tmp/ /var/spool/ /oradata/etc.), atenuando o risco operacional de usuários e / ou aplicativos mal comportados.

• Contingente. A cota de disco permite ao administrador impedir que um usuário individual use todo o espaço disponível, interrompendo o serviço para todos os outros usuários do sistema. A cota de disco individual é atribuída por sistema de arquivos; portanto, uma única partição e, portanto, um único sistema de arquivos significa apenas 1 cotação de disco. Partições múltiplas (LVM) significam vários sistemas de arquivos, permitindo um gerenciamento de cota mais granular. Dependendo do cenário de uso, você pode, por exemplo, permitir a cada usuário 10 GB em seu diretório pessoal, 2 TB no diretório / data na matriz de armazenamento externo e configurar uma grande área de trabalho compartilhada, onde qualquer pessoa pode despejar conjuntos de dados muito grandes para seu diretório pessoal e onde a política se torna "cheia está cheia", mas quando isso acontece, nada também quebra.

• Fornecendo caminhos de E / S dedicados . Você pode ter uma combinação de SSDs e discos giratórios e faria bem em resolvê-los de maneira diferente. Não é tanto um problema em um servidor de uso geral, mas é bastante comum nas configurações de banco de dados também atribuir determinados eixos (discos) a diferentes finalidades para evitar contenção de E / S, por exemplo, disco separado para os logs de transações, discos separados para dados reais do banco de dados e separar discos para espaço temporário. .

• Inicialização Você pode precisar de uma /bootpartição separada . Historicamente, para resolver problemas de BIOS com a inicialização além do limite de 1024 cilindros, hoje em dia é mais comum o requisito de suporte a volumes criptografados, suporte a determinados controladores RAID, HBAs que não suportam inicialização a partir de SAN ou sistemas de arquivos não suportados pelo instalador, etc.

• Ajuste Você pode precisar de opções de ajuste diferentes ou até de sistemas de arquivos completamente diferentes.

Se você usa partições rígidas, mais ou menos precisa corrigi-las no momento da instalação e, em seguida, uma única partição grande não é a pior, mas vem com algumas das restrições acima.

Normalmente, recomendo particionar o volume principal como um único volume físico Linux LVM grande e, em seguida, criar volumes lógicos que atendam às suas necessidades atuais e, pelo restante do espaço em disco, deixe sem atribuição até que seja necessário .

Você pode expandir esses volumes e seus sistemas de arquivos conforme necessário (que é uma operação trivial que pode ser feita em um sistema ativo) ou criar outros adicionais.

A redução de volumes LVM é trivial, mas geralmente a redução dos sistemas de arquivos neles não é muito bem suportada e provavelmente deve ser evitada.

O conceito de usar várias partições é que uma completa no lugar errado não fará com que todo o sistema funcione inesperadamente.

Considere um processo na máquina preenchendo um arquivo de log rapidamente, até o ponto em que não há espaço livre disponível. Em uma máquina de partição única, isso pode, por exemplo, impedir que o sistema grave novos dados em / tmp. Se houver outro processo que deseje gravar em / tmp, provavelmente sairá com um erro, causando um comportamento inesperado.

Isso pode ser evitado se você usar partições diferentes para locais onde os usuários ou processos normalmente gravam (/ home, / var, / tmp).

Eu recomendaria que você verifique no servidor antigo quais pastas tendem a ficar grandes. Você pode fazer isso na linha de comando com

du -h -d 1 / 2> /dev/null

Você verá onde a maioria dos dados é acumulada e projetará seu próximo sistema adequadamente. O "-d 1" limita a saída a apenas um nível de profundidade da pasta, tornando-a mais legível.

O principal problema de ter uma única partição grande é que, enchendo o sistema de arquivos, é possível que não seja mais possível fazer login.

A raiz do usuário tem sua pasta inicial ( /root) fora por /homecausa disso. Se o sistema de arquivos estiver cheio em algumas circunstâncias, mesmo o root não poderá efetuar login e não poderá reparar o sistema.

Esta é a razão pela qual você normalmente criar pontos de montagem separados para /var, /tmpe /homeser capaz de entrar pelo menos como root para reparar o sistema quando uma das outras partições é preenchido.

IMHO, ter uma partição como / é bastante razoável.

Mas você pode usar o lvm (gerenciador de volume lógico). Use todo o disco como grupo lvm, mas crie pequenos discos lógicos para /, / home, / usr e o que o sysadmin preferir. Em seguida, coloque algum monitoramento, você sabe, quando o sistema começar a ficar cheio e expanda os discos necessários. lvresize e resize2fs são ferramentas on-line e você pode fazer a expansão sem reiniciar o servidor. No entanto, você não pode reduzir os discos, portanto, você precisa começar razoavelmente pequeno e aumentar onde achar necessário.

Existem problemas mínimos em relação à configuração de grande partição única do linux, mas possui grandes recompensas.

Alterar o layout de uma partição é algo um pouco difícil e arriscado, o que geralmente não é possível sem longos períodos de inatividade.

Sua única vantagem é que você tem alguma proteção contra problemas de disco cheio. Mas você encontrará esses problemas com muita frequência. Imagine a situação, se uma de suas partições estiver cheia e você não puder usar o espaço nas outras partições, mesmo que estejam quase vazias !

Alguns administradores de sistema profissionais têm uma opinião totalmente diferente sobre isso. Eles estão dizendo que ter várias partições pode tornar seu sistema mais confiável e você deve saber antes do seu particionamento qual será o tamanho das suas partições. Na minha opinião, isso simplesmente não pode ser dito, é uma terrível desvantagem na flexibilidade do sistema, e a verdadeira motivação deles é que eles simplesmente gostam de brincar com os mapas de partição .

Existe um sistema simples chamado lvm , que permite a movimentação / redimensionamento on-the-fly de "partições" (em sua terminologia, volumes). Mas em um único servidor de departamento local, IMHO normalmente não é necessário.

Há dois motivos principais para particionar:

1. Para manter os dados estáticos afastados dos dados não estáticos
2. Para manter os dados públicos longe dos dados privados

O primeiro motivo é o mais óbvio - você precisa isolar áreas que serão preenchidas com arquivos daquelas que não o fazem e, particularmente, deseja proteger /, para evitar um sistema não inicializável. Por exemplo, o diretório / var geralmente é onde os arquivos de log serão armazenados (var significa "variável") e é por isso que / var tende a ser montado em uma partição separada de /.

O segundo motivo acima é menos citado (eu o ouvi pela última vez em um curso do Veritas Volume Manager há cerca de 15 anos) e é realmente relevante apenas para sistemas em que muitas pessoas estão efetuando login e realizando trabalhos.

Existe uma arte no pareamento eficaz, e talvez seja por isso que existem administradores de sistema que o levem um pouco longe demais (IMO). Você não precisa apenas conhecer o sistema de arquivos de dentro para fora, mas também o uso pretendido. Pessoalmente, acho que é uma abordagem antiquada que está se tornando cada vez menos relevante para a maneira como os servidores são usados ​​hoje.

Como desenvolvedor de software, estou particularmente farto do departamento de Operações que cria Máquinas Virtuais com esquemas de particionamento impensados ​​que restringem severamente o tamanho de / tmp, / home, / var e /, independentemente do espaço total em disco disponível, mas não monte opções óbvias como / usr ou / opt separadamente. Essas máquinas geralmente colocam o que resta do espaço em disco solicitado em um volume "/ stuff" no qual você inevitavelmente acaba instalando e associando tudo, mas isso dificilmente é um consolo. O resultado final é que geralmente gastamos mais tempo remexendo arquivos e enviando e-mails de aviso do que realizando qualquer trabalho real.

Não há nada inerentemente "ruim" em ter uma única partição. Em qualquer sistema, você deve monitorar proativamente o uso do disco e empregar estratégias sensatas de limpeza (por exemplo, rotação de log, cotas em diretórios pessoais), portanto, a única questão real é: com quantos sistemas de arquivos você deseja se preocupar?

Portanto, eu diria: a menos que você esteja 100% confiante em sua capacidade de particionar o sistema efetivamente para seu caso de uso específico, não particione .

IMHO cabe a você inteiramente. Primeiro, considere algumas coisas, embora inteiramente seja algo relativo.

• este sistema será administrado com freqüência?
• este sistema será usado por um ou mais usuários?
• esse sistema servirá como área de trabalho ou servidor ou ambos?

Como se pode considerar (quase) qualquer diretório, um ponto de montagem deve-se considerar também o que contém dados em crescimento e o que contém dados em crescimento.

Você ficaria surpreso com o pouco que um sistema Linux (um pouco crescente de dados) exige para executar e quanto é consumido pelo crescimento de dados (normalmente / var / opt / home / srv)

Também depende de como você define o uso desse sistema, que descreve os requisitos de particionamento. O uso para LVM incluído.

Um sistema de desktop típico exigiria cerca de 20 GB para instalar cargas de software, tendo todo o restante atribuído a uma casa / dedicada dedicada. O LVM causa uma sobrecarga menor no seu sistema e, nesse caso específico, não é de grande benefício. Embora as opiniões possam diferir.

Em um servidor, é menos provável que o software instalado seja tão dinâmico quanto em um sistema de desktop. Também é mais sábio ter pontos de montagem reais para componentes típicos do sistema de arquivos, como / tmp / var / usr / home / opt / srv. O uso do LVM aqui é recomendado para não dizer obrigatório.

Isso oferece uma grande modularidade do seu sistema, mas também permite fazer coisas tolas, como clonar essa partição em uma VM, por exemplo. Ou criando um backup em nível de bloco usando o dd.

Com base em alguma experiência, aqui estão algumas notas. Considere também que vários pontos de montagem permitam maior controle, atribuir um dispositivo de disco rápido ou lento a um ponto de montagem pode fazer muita diferença e aumentar significativamente a eficiência de custos.

Mounpoint /

• 1 GB (se estiver usando pontos de montagem separados para / var / usr / opt / home / tmp)
• +10 ou até +20 GB se usado como um sistema de desktop com um dispositivo doméstico / separado

se estiver usando o ponto de montagem / home

• atribua todo o espaço livre, se usado, / home ne

se estiver usando o ponto de montagem / opt

se estiver usando mountpoint / usr

• este é um assunto delicado e extremamente dependente da base de software instalada

se estiver usando mountpoint / var

• este é um assunto delicado e extremamente dependente da base de software instalada
• por exemplo, os bancos de dados escrevem seus dados aqui em sistemas baseados no Debian, se não todos em Linux
• ter um / var / tmp separado não é irracional

se estiver usando o ponto de montagem / tmp

• considere que tmpfs existe e aloca / tmp para RAM
• considere que alguns aplicativos podem escrever muitos dados aqui

Antes de tudo, tenho que questionar por que você está postando essa pergunta aqui, sendo um biólogo que está discutindo com um administrador de sistemas aparentemente competente a respeito dos pontos mais delicados do particionamento do disco rígido! (sem ofensa, apenas realmente me pergunto por que você não está confiando no seu administrador de sistemas).

Então, algumas observações:

• 1,3 TB não é mais uma unidade grande. Atualmente, 2 TB é um tamanho de unidade SATA mais ou menos padrão no mundo dos desktops.

• é improvável que uma instalação de qualquer distribuição Linux distro exija mais de 100 GB. Certamente, o tamanho de / (root) e (swap) deve ser facilmente determinado como números com limite superior, superdimensionando-os generosamente (para root) ou pelas diretrizes de configuração do sistema (swap).

• o ponto de montagem para / home deve estar apontando para algo fora do seu servidor RAID de 40 TB. Não há necessidade de que esses dados, os diretórios pessoais dos usuários, estejam em qualquer lugar desse dispositivo raiz. Colocá-los no servidor RAID provavelmente oferece uma melhor proteção de qualquer maneira. E, provavelmente, é uma instalação NAS facilmente expansível, enquanto o pouco RAID incorporado na caixa do servidor provavelmente não é.

• você provavelmente deve colocar seu software especial em uma seção separada (ponto de montagem para / usr / local / bin etc.) para preservar isso nas atualizações do sistema operacional e nas limpezas da partição raiz. Caso contrário, você terá a possibilidade de reinstalar seus aplicativos de software "especiais" após uma atualização / correção do sistema operacional / o que for.

• se você quiser se preocupar com a administração do sistema, faça uma pergunta diferente: qual é o processo de recuperação de desastre após o prédio pegar fogo e os servidores e caixas RAID serem destruídos? A menos que os dados com os quais você se preocupe permaneçam inteiramente na sua cabeça, essa é uma pergunta que todo usuário deve fazer com o pessoal de TI / administrador de sistemas. A estratégia deve incluir perguntas como "como replicaremos o hardware de que precisamos" e "quanto tempo levará para que possamos voltar a funcionar". Algumas discussões sobre a virtualização de seus servidores podem ajudar a resolver problemas relacionados a dependências de hardware e colocar as coisas em funcionamento novamente sem a necessidade de reconfigurar o sistema operacional (pois ele pode ser configurado para ser executado em um ambiente de dispositivo "flexível" que não muda,

• Da mesma forma, você pode perguntar qual é a estratégia para proteger os dados do usuário contra perdas de dados de erros do programa e do usuário. Salvar um arquivo vazio sobre o excelente rascunho do seu trabalho de pesquisa ou fazer com que um usuário digite o comando errado (rm -rf * por exemplo) causará a perda de dados com a mesma segurança que um terremoto ou incêndio ou outro dano físico. As soluções para recuperação de arquivos individuais são um pouco diferentes (ou podem ser!) Das mais úteis para recuperação de desastres por atacado.

-

Isso permite fazer backup, restaurar ou reinstalar o sistema operacional independentemente dos dados do usuário. Isso lhe dá liberdade, independência e segurança.

1. É muito mais fácil migrar para outra distribuição Linux ainda preservando a maioria absoluta dos dados do usuário.

2. É fácil reverter atualizações de buggy aplicando o backup da partição do sistema operacional (é necessária a inicialização dupla). Esse backup pode até ser bastante antigo - você pode aplicá-lo e atualizar mais tarde para a versão conscientemente estável.

3. É simples reverter para a versão anterior do sistema operacional se você não gostar da "atualização principal" aplicada recentemente (é necessária a inicialização dupla).

Para o maior potencial dessa abordagem, você também deve configurar a inicialização dupla (também pode ser o CentOS / CentOS), para que você possa sobrescrever uma partição do sistema operacional enquanto executa o sistema operacional a partir de outra. E, certamente, você deve fazer backup da partição do sistema pelo menos uma vez em alguns meses.

Minha resposta curta é que mesmo uma área de trabalho nunca deve usar "uma grande partição". Recentemente, tentei isso contra o meu julgamento, porque era "apenas um laptop" e o instalador automático usou uma única partição, e apenas cliquei no botão.

Quando fui instalar uma distribuição diferente, tive que reparticionar minhas unidades porque o instalador não instalaria sobre uma distribuição existente. Ele pode manter sua casa intacta se ela estiver em sua própria partição. Então, acabei inicializando um live-cd gparted e diminuindo a partição, criando novas partições para / home e outras pessoas, movendo meus dados para as novas partições e, finalmente, inicializando no instalador do novo sistema operacional.

Idealmente, coloque / em um SSD, / home em um disco rígido, / var em um disco rígido, / usr poderia estar em um SSD ou HDD, dependendo da frequência com que você planeja atualizar. / tmp para um disco rígido. Normalmente, faço outra partição para arquivos de mídia compartilhados, como mp3s e filmes, com links simbólicos a partir do meu / home. Observe que / sbin faz parte da raiz e é / bin e / root. Essa é a diferença entre / bin e / usr / bin, é / usr é algo que pode não estar disponível até que todas as suas unidades estejam montadas; portanto, o comando mount não pode estar em / usr! Eu costumo manter algumas partições extras para outras distribuições linux, como a que a gparted está no meu disco rígido, caso eu estrague algo realmente ruim, tenho outro sistema ativo pronto para fazer o trabalho de recuperação.

Para um servidor em que você pode precisar mover coisas, adicionar armazenamento dinamicamente e precisar ficar sempre ativo, use definitivamente o LVM !!!

Você não precisa instalar o software em / usr / local; pode instalar todo o software em um prefixo diferente, que pode estar em / home. A maioria dos softwares pode fazer isso quando você o compila da fonte, executando, por exemplo, ./configure --prefix=/home/bin

Como você é um biólogo, pode estar interessado em muitos softwares que não estão devidamente compactados em rpm ou deb e você precisará compilá-lo da fonte de qualquer maneira.

Sou administrador de sistemas de um sistema HPC com muitos biólogos entre nossos usuários; instalamos todo o software que eles solicitam em um / apps / sistema de arquivos; portanto, sei que é possível fazer isso na maioria dos softwares; no entanto, às vezes, seja muito difícil. Para resolver esse problema, meus colegas e eu escrevemos em uma ferramenta chamada EasyBuild (gratuito e de código aberto). Ele pode compilar e instalar software a partir da fonte, instalá-lo em uma pasta diferente e criar automaticamente um arquivo de módulo de ambiente para você. você pode ter 2 versões diferentes do mesmo software instaladas e não ter conflitos.

Dê uma olhada na nossa lista de pacotes que podemos instalar com apenas um comando, como biólogo você pode reconhecer muitos deles ;-)

Isenção de responsabilidade: sou desenvolvedor do EasyBuild

Penso que, em geral, para um usuário iniciante / introdutório * ix, ter o menor número de partições pode funcionar até que mais se aprenda sobre a natureza do sistema. No entanto, você não pode simplesmente ter uma parição e, no seu caso, senhor, por várias razões.

A primeira e mais pública razão prática disso é que a maioria dos sistemas Linux exige uma partição de troca (geralmente entre 1-2 * sua RAM) também requer um sistema separado, partições de inicialização ou home e, no caso de UEFI, inicializando sistemas linux uma partição EFI (apenas 500 MB).

A segunda razão, especificamente aplicável à sua situação, é que pegar unidades de 300GB de 6x e transformá-las em um raid 6 não é, para dizer o mínimo, o arranjo ideal. Embora a nova tecnologia considere o Raid 6 como um sistema universalmente melhor, o algoritmo de distribuição é mais necessário e o espaço necessário para armazenar informações (comparado ao RAID 5) é maior em tamanho.

Sem mencionar que o RAID 6 requer hardware adicional. Que, em minha opinião respeitosa, deve ser usado no seu caso para comprar discos maiores para evitar falhas no disco, tempo de inatividade, recuperação de desastres ou custos adicionais de ajuda técnica. Entendo que alguns, muitos talvez, não concordem comigo e quero reafirmar que, quando os discos aumentam de tamanho nos próximos dois anos (já que caíram de preço nos últimos) RAID6, para matrizes maiores e grandes corporações de renda serão uma escolha óbvia. No entanto, neste caso, não sugiro o uso do RAID 6.

Para o segundo problema (não baseado em RAID), criar uma partição gigante quando espelhada pode funcionar para você, no entanto, se você deseja maximizar a eficiência, use unidades maiores e várias partições. Dessa forma, se houver uma falha no disco duplo, você não terá tempo de inatividade em determinados pontos de montagem ou pouco dependendo do / dev + / dir.

Pelo menos, faça seu / sys (sistema, kernel, etc) funcionar separadamente, para que, por qualquer motivo, seu kernel decida não inicializar, você pode simplesmente usar um kernel de recuperação, inicialização remota ou PXE, inicialização em disco, etc, seu kernel e ter empresa- amplo acesso às suas informações enquanto ocorre o processo de recuperação d.

Sua empresa pode não se importar com esses detalhes, desde que o sistema funcione, mas estou tentando explicar os motivos pelos quais as pessoas fazem as coisas. Eu também adoraria ouvir mais dos outros, a favor e contra esse argumento e levantar outros pontos. Se você não concordar, deixe-me saber o porquê. Cartaz - eu também vou lhe dar alguns links.

Um amor pela comunidade Linux Spencer Reiser

PS Especialmente em servidores ou sistemas de rede disponíveis ao público em geral, mesmo que via credencial, seria realmente melhor separar suas partições. Outros podem inserir mais aqui, preciso de mais café.