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

Question

Nós estaremos rodando o CentOS 7 em nosso novo servidor. Temos 6 drives de 300GB em raid6 internos para o servidor. (O armazenamento é em grande parte externo na forma de uma caixa de ataque de 40 TB.) O volume interno chega a aproximadamente 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 um biólogo. Constantemente instalamos novos softwares para rodar e testar, a maioria dos quais em / usr / local. No entanto, como temos cerca de 12 biólogos não especialistas em computador usando o sistema, também coletamos muito lixo em / home. Nosso último servidor tinha uma partição de 200GB para / e, após 2,5 anos, estava 90% cheio. Eu não quero que isso aconteça novamente, mas eu também não quero ir contra o conselho de especialistas!

Como podemos usar melhor o 1.3TB disponível para garantir que o espaço esteja disponível quando e onde for necessário, mas não crie um pesadelo de manutenção para o administrador de sistema?

    

Answer 1

As principais razões (históricas) para o 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, em seguida, ter por exemplo /home e outros dados (aplicativos) em partições separadas (ou LVM volumes) permite preservar facilmente os dados do usuário e os dados do aplicativo e limpar a (s) partição (ões) do sistema operacional.

• 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. Múltiplas partições permitem que você atribua espaço em disco rígido reservado para o SO e mantenha isso separado da área onde os usuários e / ou aplicativos específicos têm permissão para gravar (por exemplo, /home /tmp/ /var/tmp/ /var/spool/ /oradata/ etc.), mitigando risco operacional de usuários mal comportados e / ou aplicativos.

• Cota. A cota de disco permite que o administrador impeça 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 de disco. Múltiplas partições (LVM) significam vários sistemas de arquivos, permitindo um gerenciamento de cota mais granular. Dependendo do cenário de uso, você pode permitir, por exemplo, 10 GB de cada usuário em seu diretório inicial, 2 TB no diretório / data no storage array externo e configurar uma área de rascunho compartilhada grande onde qualquer um pode despejar conjuntos de dados muito grandes para o diretório inicial e onde a política se torna "cheia está cheia", mas quando isso acontece, nada quebra também.

• Fornecer caminhos de IO dedicados . Você pode ter uma combinação de SSDs e discos giratórios e faria bem em abordá-los de maneira diferente. Não tanto um problema em um servidor de propósito geral, mas bastante comum em configurações de banco de dados é também designar certos eixos (discos) para propósitos diferentes para evitar a contenção de E / S, por exemplo. separe o disco para os logs de transação, separe os discos para os dados reais do banco de dados e separe os discos para o espaço temporário. .

• Inicialização Você pode precisar de uma partição /boot separada. Historicamente, para resolver os problemas do BIOS ao inicializar além do limite de 1024 cilindros, atualmente é mais necessário um suporte para volumes criptografados, para suportar determinados controladores RAID, HBAs que não suportam a inicialização a partir de SAN ou sistemas de arquivos não suportados imediatamente pelo instalador etc.

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

Se você usar partições fixas, mais ou menos terá que acertar na hora da instalação e uma única partição grande não será a pior, mas vem com algumas das restrições acima.

Normalmente, eu recomendo particionar seu volume principal como um único volume físico grande do Linux LVM e, em seguida, criar volumes lógicos que atendam às suas necessidades atuais e pelo restante de seu disco espaço, 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 também.

Diminuir volumes de LVM é trivial, mas freqüentemente encolher os sistemas de arquivos neles não é suportado muito bem e provavelmente deve ser evitado.

    

Answer 2

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

Considere um processo na máquina preenchendo um arquivo de log muito rápido até o ponto em que não haja espaço livre disponível. Em uma máquina de partição única, isso poderia, por exemplo, impedir que o sistema grave novos dados em / tmp. Se houver outro processo que queira gravar em / tmp, ele 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 seu servidor antigo, que as pastas tendem a ficar maiores. 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 projeta seu próximo sistema adequadamente. O "-d 1" limita a saída a apenas um nível de profundidade de pasta, tornando-a mais legível.

    

Answer 3

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

O usuário root tem sua pasta home ( /root ) fora de /home por causa disso. Se o sistema de arquivos for preenchido 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 cria pontos de montagem separados para que /var , /tmp e /home consigam se conectar pelo menos como root para reparar o sistema quando uma das outras partições for preenchida. / p>     

Answer 4

IMHO, tendo 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 qualquer que seja seu sysadmin. Em seguida, coloque algum monitoramento, que você sabe, quando o sistema começar a ficar cheio e expanda os discos que você precisa. lvresize e resize2fs são ferramentas online e você pode fazer a expansão sem reiniciar o servidor. No entanto, você não pode reduzir discos, então você precisa começar razoavelmente pequeno e aumentar onde você vê a necessidade.

    

Answer 5

Existem problemas mínimos em torno da configuração de grande partição única do Linux, mas ela tem grandes recompensas.

Alterar um layout de partição é um pouco difícil e arriscado, o que muitas vezes 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 muito com freqüê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 elas estejam quase vazias !

Alguns administradores de sistemas 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 de particionar, qual será o tamanho de suas partições. Na minha opinião, isso simplesmente não pode ser dito, é uma terrível desvantagem na flexibilidade do sistema, e sua real motivação é que eles estão simplesmente gostando de brincar com os mapas de partição. . p>

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

    

Answer 6

Existem dois motivos principais para o particionamento:

1. Para manter os dados estáticos longe de dados não estáticos
2. Para manter os dados públicos longe de dados particulares

A primeira razão é a mais óbvia - você precisa isolar áreas que serão preenchidas com arquivos daqueles que não são, e você 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 (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 fazem login e realizam trabalhos.

Existe uma espécie de arte para um paritioning eficaz, e talvez seja por isso que há administradores de sistema que levam isso um pouco longe demais (IMO). Não apenas você precisa conhecer o sistema de arquivos de dentro para fora, mas também precisa conhecer o uso pretendido. Eu pessoalmente acho que é uma abordagem bastante antiquada que está se tornando menos e menos relevante para a forma como os servidores são usados hoje.

Como desenvolvedor de software, estou particularmente cansado do Virtual Machines de criação de departamentos de Ops com esquemas de particionamento irrefletidos que restringem severamente o tamanho de / tmp, / home, / var e /, independentemente do espaço total em disco disponível mas não monte escolhas óbvias como / usr ou / opt separadamente. Essas máquinas comumente colocam o que sobrou do espaço em disco que você pediu em um volume "/ stuff" que inevitavelmente acaba instalando e ligando tudo simbolicamente, mas isso dificilmente é um consolo. O resultado final é que muitas vezes passamos mais tempo vasculhando arquivos e enviando e-mails de aviso do que fazendo 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 de manutenção (por exemplo, rotação de log, cotas nos diretórios home), portanto a única questão real é: com quantos sistemas de arquivos separados você quer se preocupar?

Por isso, 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 de todo .

    

Answer 7

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

• esse sistema será administrado com frequência?
• esse sistema será usado por um ou mais usuários?
• esse sistema funcionará como um desktop ou um servidor, ou ambos?

Como é possível considerar (quase) qualquer diretório, um ponto de montagem também deve considerar o que contém dados que crescem um pouco e o que contém dados crescentes.

You'd be surprised how little a linux system ( somewhat growing data ) requires to run and how much is consumed by growing data ( typically /var /opt /home /srv )

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

A typical desktop system would require about 20GB for installing loads of software, having all the rest assigned to a dedicated /home will do fine then. LVM causes minor overhead on your system and in this particular case is not of such great benefit. Though opinions might differ.

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

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

Com base em alguma experiência, aqui estão algumas notas. Além disso, considere ter vários pontos de montagem permitindo um maior controle, atribuir um dispositivo de disco rápido ou lento a um ponto de montagem pode fazer uma enorme diferença e pode aumentar consideravelmente 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 estiver usando um sistema de área de trabalho com um / home
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 o ponto de montagem / usr

• é complicado e altamente dependente da base de software instalada

se estiver usando o mountpoint / var

• é complicado e altamente dependente da base de software instalada
• por exemplo, bancos de dados escrevem seus dados aqui em sistemas baseados no Debian, se não todos Linux
• ter um / var / tmp separado não é insensato

se estiver usando o ponto de montagem / tmp

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

Answer 8

Eu tenho que questionar, em primeiro lugar, por que você está postando essa pergunta aqui, sendo um biólogo que está discutindo com um administrador de sistema aparentemente competente sobre os pontos mais delicados do particionamento do disco rígido! (sem ofensa, apenas se perguntando por que você não está confiando em seu administrador de sistema).

Então, algumas observações:

• 1.3 TB não é mais uma unidade grande. 2 TB é um tamanho de unidade SATA mais ou menos padrão no mundo dos desktops atualmente.

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

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

• você provavelmente deve colocar seu software especial em uma partição separada (ponto de montagem para / usr / local / bin etc) para que você possa preservá-lo nas atualizações do sistema operacional e nos wipes de partição raiz. Caso contrário, você se depara com a possibilidade de ter que reinstalar seus aplicativos de software "especiais" após uma atualização / correção do sistema operacional / o que quer que seja.

• Se você quiser se preocupar com a administração do seu sistema, eu faria uma pergunta diferente: qual é o processo de recuperação depois que o prédio pegar fogo e os servidores e caixas de RAID forem destruídos? A menos que os dados de que você cuida permaneçam inteiramente em sua cabeça, essa é uma pergunta que todo usuário deve fazer ao seu pessoal de TI / sysadmin. A estratégia deve incluir perguntas como "como vamos replicar o hardware que precisamos" e "quanto tempo levará até que possamos voltar a trabalhar". Algumas discussões sobre a virtualização de seus servidores podem ajudar a resolver problemas relacionados a dependências de hardware e fazer com que as coisas voltem a funcionar sem a necessidade de reconfigurar o sistema operacional (pois ele pode ser configurado para ser executado em um ambiente de dispositivo "flexível"), mesmo quando hardware subjacente é completamente diferente)

• Da mesma forma, você pode querer perguntar qual é a estratégia para proteger os dados do usuário contra perdas de dados de erro de programa e usuário. Salvar um arquivo vazio sobre o rascunho realmente grande do seu trabalho de pesquisa, ou ter um usuário digitando o comando errado (rm -rf *, por exemplo) causará perda de dados com tanta certeza quanto um terremoto, incêndio ou outros danos físicos. 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.

-

Answer 9

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 do Linux que ainda preserva a maioria absoluta dos dados do usuário.

2. É fácil reverter atualizações de bugs, aplicando o backup da partição do sistema operacional (a inicialização dupla é necessária). Este backup pode até ser bastante antigo - você pode aplicá-lo e depois atualizá-lo para a versão com conhecimento de causa estável.

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

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

    

Answer 10

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

Quando fui instalar uma distro diferente, tive que reparticionar minhas unidades porque o instalador não seria instalado em uma distro existente. Pode e manterá seu / home intacto se estiver em sua própria partição. Então, acabei inicializando um live-cd com o gparted e encolhendo a partição, fazendo novas partições para / home e outros, movendo meus dados para as novas partições e, finalmente, inicializando no instalador para o novo sistema operacional.

Idealmente, coloque / em um SSD, / home em um disco rígido, / var em um disco rígido, / usr pode estar em um SSD ou HDD, dependendo da freqüência com que você planeja atualizar. / tmp para um disco rígido. Eu costumo fazer outra partição para arquivos de mídia compartilhados como mp3s e filmes com links simbólicos para ele do meu / home. Note que / sbin faz parte do root e é / bin e / root. Essa é a diferença entre / bin e / usr / bin, é / usr é uma coisa que pode não estar disponível até que todas as suas unidades estejam montadas, então o comando mount não pode estar em / usr! Eu costumo manter um par de partições extras para outras distribuições linux, como a que está no meu disco rígido apenas no caso de eu estragar algo muito ruim, eu tenho outro sistema live pronto para fazer o trabalho de recuperação.

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

    

Answer 11

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

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

Sou um administrador de sistema para um sistema HPC com muitos biólogos entre nossos usuários, instalamos todos os softwares que eles solicitam em um sistema de arquivos / apps /, então eu sei que é possível fazer isso para a maioria dos softwares, às vezes pode ser muito difícil. Para resolver este problema, meus colegas e eu escrevemos em uma ferramenta chamada EasyBuild (Free e open source) Ele pode compilar e instalar o software a partir do código-fonte e instalá-lo em uma pasta diferente e criar automaticamente um arquivo módulo de ambiente para você. pode ter duas versões diferentes do mesmo software instalado 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; -)

Aviso: Sou um desenvolvedor do EasyBuild

    

Answer 12

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

A primeira e mais publicamente prática razão para isto é que a maioria dos Sistemas Linux requerem uma partição swap (geralmente entre 1-2 * a sua RAM) também requer um sistema separado, boot ou partições home e no caso da UEFI inicializando sistemas Linux uma partição EFI (apenas 500MB).

O segundo motivo, especificamente aplicável à sua situação, é que a utilização de 6 unidades de 300 GB e a criação de uma invasão 6 não é, para dizer o mínimo, a classificação ideal. Embora a nova tecnologia elogie o Raid 6 como um sistema universalmente melhor, o algoritmo de striping é 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 uma peça adicional de hardware. Qual deve ser usado, em minha opinião respeitosa, no seu caso para comprar discos maiores para evitar falhas de disco, tempo de inatividade, recuperação de desastres ou custos adicionais de ajuda técnica. Eu entendo que alguns, talvez muitos, irão discordar de mim e eu quero reafirmar que quando os discos se tornarem maiores em tamanho nos próximos dois anos (já que eles 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, eu não sugiro o uso de 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ê quiser maximizar a eficiência, use unidades maiores e várias partições. Dessa forma, se você tiver uma falha de disco duplo, não haverá tempo de inatividade em determinados pontos de montagem ou pouco dependendo do / dev + / dir.

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

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 gostaria de ouvir mais dos outros, a favor e contra esse argumento e para levantar outros pontos. Se você não concorda, deixe-me saber o porquê. Poster - Eu vou PM alguns links também.

Um amor pela nossa comunidade Linux Spencer Reiser

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