Particionamento de servidor Unix e layout do sistema de arquivos

Há muitas informações contraditórias sobre o particionamento de servidores Unix na Internet, por isso preciso de alguns conselhos sobre como proceder.

Até o momento, nos servidores em nosso ambiente de teste, não me importava muito com o particionamento e configurei uma única /partição monolítica e uma troca. Esse esquema de particionamento não parece uma boa ideia para nossos servidores de produção. Encontrei um bom ponto de partida aqui , mas parece muito vago nos detalhes.

Basicamente, eu tenho um servidor no qual executarei uma pilha LAMP básica (Apache, PHP e MySQL). Ele terá que lidar com uploads de arquivos (até 2 GB). O sistema possui uma matriz de 2 TB RAID 1.

Eu pretendo definir:

/         100GB 
/var     1000GB (apache files and mysql files will be here), 
/tmp      800GB (handles the php tmp file)
/home      96GB
swap        4GB

Isso parece sadio ou estou complicando demais as coisas?

Uma coisa a ter em mente ao organizar suas partições são os modos de falha. Normalmente, essa pergunta tem a forma: "O que acontece quando a partição x é preenchida?" O mais caro voretaq7 trouxe à tona a situação, /causando uma série de problemas difíceis de diagnosticar. Vejamos algumas situações mais específicas.

O que acontece se sua partição armazenando logs estiver cheia? Você perde dados de auditoria / relatório e, às vezes, é usado pelos invasores para ocultar suas atividades. Em alguns casos, seu sistema não autenticará novos usuários se não conseguir registrar o evento de login.

O que acontece em um sistema baseado em RPM quando /varestá cheio? O gerenciador de pacotes não instala ou atualiza pacotes e, dependendo da sua configuração, pode falhar silenciosamente.

É fácil preencher uma partição, especialmente quando um usuário é capaz de escrever nela. Por diversão, executar este comando e ver o quão rápido você pode fazer um arquivo grande bem: cat /dev/zero > zerofile.

Além de preencher partições, quando você coloca locais em diferentes pontos de montagem, também pode personalizar as opções de montagem.

O que acontece quando /dev/não está montado noexec? Como /devgeralmente é assumido que o sistema operacional é mantido e contém apenas dispositivos, ele era frequentemente (e algumas vezes ainda é) usado para ocultar programas maliciosos. Sair noexecpermite iniciar binários armazenados lá.

Por todas essas razões e mais, muitos guias de proteção discutirão o particionamento como uma das primeiras etapas a serem executadas. Na verdade, se você está construindo um novo servidor como particionar o disco é quase exatamente a primeira coisa que você tem que decidir sobre, e muitas vezes o mais difícil de mudar mais tarde. Existe um grupo chamado Center for Internet Security que produz vários guias de configuração fáceis de ler. Provavelmente, você pode encontrar um guia para seu sistema operacional específico e ver quaisquer detalhes que eles possam dizer.

Se olharmos para o RedHat Enterprise Linux 6, o esquema de particionamento recomendado é o seguinte:

# Mount point           Mount options
/tmp                    nodev,nosuid,noexec
/var                    
/var/tmp                bind (/tmp)
/var/log
/var/log/audit
/home                   nodev
/dev/shm                nodev,nosuid,noexec

O princípio por trás de todas essas alterações é impedir que elas impactem uma à outra e / ou limitar o que pode ser feito em uma partição específica. Pegue as opções, /tmppor exemplo. O que isso diz é que nenhum nó de dispositivo pode ser criado lá, nenhum programa pode ser executado a partir daí e o bit set-uid não pode ser definido em nada. Por sua própria natureza, /tmpé quase sempre gravável no mundo e geralmente é um tipo especial de sistema de arquivos que existe apenas na memória. Isso significa que um invasor pode usá-lo como um ponto de preparo fácil para descartar e executar código malicioso e, ao travar (ou simplesmente reiniciar), o sistema limpará todas as evidências. Como a funcionalidade de /tmpnão exige nenhuma dessas funcionalidades, podemos desativar facilmente os recursos e evitar essa situação.

Os locais de armazenamento log, /var/loge /var/log/auditsão esculpidos fora a ajuda tampão-los de esgotamento dos recursos. Além disso, o auditd pode executar algumas tarefas especiais (geralmente em ambientes de segurança mais alta) quando o armazenamento de log começa a encher. Ao colocá-lo em sua partição, essa detecção de recurso tem um desempenho melhor.

Para ser mais detalhado e citar mount(8), é exatamente isso que as opções usadas acima são:

noexec Não permita a execução direta de nenhum binário no sistema de arquivos montado. (Até recentemente, era possível executar binários de qualquer maneira usando um comando como /lib/ld*.so / mnt / binary. Esse truque falha desde o Linux 2.4.25 / 2.6.0.)

nodev Não interprete caracteres ou bloqueie dispositivos especiais no sistema de arquivos.

nosuid Não permita que os bits set-user-identifier ou set-group-identifier entrem em vigor. (Isso parece seguro, mas na verdade é bastante inseguro se você tiver o suidperl (1) instalado).

Do ponto de vista da segurança, essas são ótimas opções para conhecer, pois permitem que você coloque proteções no próprio sistema de arquivos. Em um ambiente altamente seguro, você pode até adicionar a noexecopção /home. Isso tornará mais difícil para o usuário padrão gravar scripts de shell para processar dados, por exemplo, analisar arquivos de log, mas também impedirá que eles executem um binário que elevará privilégios.

Além disso, lembre-se de que o diretório inicial padrão do usuário raiz é /root. Isso significa que ele estará no /sistema de arquivos, não no /home.

Exatamente quanto você dá a cada partição pode variar bastante, dependendo da carga de trabalho do sistema. Um servidor típico que eu gerenciei raramente exigirá interação pessoal e, como tal, a /homepartição não precisa ser muito grande. O mesmo se aplica, uma /varvez que tende a armazenar dados bastante efêmeros que são criados e excluídos com frequência. No entanto, um servidor Web normalmente usa /var/wwwcomo playground, o que significa que ele também precisa estar em uma partição separada ou /var/deve ser aumentado.

No passado, eu recomendei o seguinte como linhas de base.

# Mount Point       Min Size (MB)    Max Size (MB)
/                   4000             8000
/home               1000             4000
/tmp                1000             2000
/var                2000             4000
swap                1000             2000
/var/log/audit       250

Elas precisam ser revisadas e ajustadas de acordo com a finalidade do sistema e com o funcionamento do seu ambiente. Eu também recomendaria o uso do LVM e contra a alocação de todo o disco. Isso permitirá que você cresça ou adicione partições facilmente, se essas coisas forem necessárias.

Ignorando a matriz RAID subjacente ( consulte esta pergunta para obter mais detalhes sobre os níveis da matriz RAID e quando você deseja usá-los ), vamos nos concentrar na pergunta principal que você está perguntando:
"Como devo definir os sistemas de arquivos do meu servidor Unix?"

O que há de errado com uma /partição gigante ?

Como você observou na sua pergunta, muitas distribuições Linux (especialmente as distribuições "Desktop" como o Ubuntu) usam um layout muito simples do sistema de arquivos: /e [swap].

Esse esquema tem a vantagem da simplicidade - é ótimo para usuários de DOS / Windows que estão acostumados ao PC doméstico com "o disco rígido" como um grande recipiente monolítico ( C:\) no qual você despeja coisas e não precisa se preocupar sobre a falta de espaço nos sistemas de arquivos - apenas mantenha a capacidade do disco e tudo está (pelo menos teoricamente) bem.

O esquema do sistema de arquivos únicos tem várias desvantagens - a desvantagem mais frequentemente citada é que os sistemas Unix tendem a reagir muito mal quando o sistema de arquivos raiz fica cheio (a ponto de se recusar a inicializar) e se tudo está sendo gravado na /(raiz) um programa ou usuário rebelde pode derrubar todo o sistema.
Um único sistema de arquivos grande também é propenso a ser uma perda total no caso de uma falha do sistema e subsequente corrupção do sistema de arquivos.

Os problemas acima, além de um forte senso de organização, são os motivos pelos quais os servidores Unix geralmente têm vários sistemas de arquivos.

Como você divide o sistema de arquivos Unix?

Então, esperançosamente, você está convencido de que ter vários sistemas de arquivos faz sentido. A questão agora é como você divide o sistema em partes lógicas e como decide quanto espaço cada um recebe?
A resposta é que você conhece e entende o que o seu sistema operacional vai colocar onde. O ponto de partida para esse entendimento é a hierpágina de manual. A maioria dos sistemas Unix vem com ( man hierde um sistema linux e man hierde um sistema BSD ), e isso, além do seu conhecimento local sobre o que o código que você está instalando vai fazer, irá guiá-lo na criação de um layout de particionamento sadio.

Vou descrever aqui um esquema geral de particionamento, mas esse esquema sempre deve ser modificado para atender às suas necessidades específicas.

Um Esquema Geral de Particionamento Unix

/
    The "root partition", /, does not usually need to be very large.
    It holds the basic items needed to boot the system, mount other filesystems
    and get you to a running, usable, multi-user environment.  It's also what
    is available to you when you bring up the system in single-user ("recovery")
    mode.  
    The contents of / should not change or grow substantially over time.

    NOTE: Anything that doesn't go on one of the other partitions described
          below will wind up taking space on the root partition (/).

/var
    The /var filesystem holds variable data -- log files, email, and on some
    systems databases (like MySQL or Postgres) store their data files here.  
    `/var` should be "Big Enough" to hold all the data you intend to cram into
    it.  I generally advise 10GB for systems that won't have a database or email
    server (just logs).  If you are building a database or mail server you
    should obviously make `/var` larger, or carve out separate filesystems for
    the database/mail data.

/usr
    The /usr filesystem holds "userland" programs, data, manual pages, etc.
    This is where things like the Firefox browser binary live.  On systems that
    will have a lot of large user applications this filesystem may be very large
    (100GB or more), and on stripped-down servers it may be relatively small.  
    A good rule of thumb is that the /usr filesystem should be twice as large
    as you need it to be in order to fit your initial installation of programs.

/home
    The /home filesystem holds user home directories, and on desktop systems is
    the largest and most prone to filling up.  When you download files from the
    internet, create spreadsheets, store a music library, etc. that data is
    stored in your home directory, and it adds up fast.
    It's important to allow enough room under /home for the "accumulated junk"
    you will gather over time, even on servers -- ad-hoc tarball backups, 
    package files you copied over to install, and the like.

Sistemas de arquivos especiais

/tmp and /var/tmp
    The temporary scratch space (/tmp) is "special" -- on most Unix systems
    the contents of /tmp are cleared on reboot, and on many modern systems
    /tmp is a special "tmpfs" (RAM) filesystem for better performance.
    /var/tmp is usually "persistent temporary files" (like vi recovery
    files), and is not cleared on reboot
    The same general rule applies as for all other filesystems: Make sure
    your temporary scratch filesystems are big enough to hold the stuff you
    want to put in them.

[swap]
    Swap Space is used by the kernel when you are running low on RAM --
    The old general rule of thumb was to have at least twice as much swap
    as you did RAM, however on modern systems it's usually sufficient to
    have "enough" swap -- 2GB is a practical lower limit, and an amount
    between half the installed RAM and the total installed RAM is usually
    adequate.
    On modern systems with relatively huge RAM pools (12G and up) it is
    probably not practical to use the system if it's swapping heavily
    enough to warrant the old "Twice the installed RAM" rule.

A prática de dividir o sistema de arquivos dessa maneira é dos dias em que não havia invasão de software e as unidades de disco eram pequenas, então você tinha que usar vários deles e, portanto, a única maneira de fazer isso era desmembrar o sistema de arquivos e coloque diretórios diferentes em unidades diferentes. A outra razão histórica para isso era que você podia desmontar facilmente uma partição e dumpfazer backup, o que não era possível fazer com a raiz. Atualmente, essa ferramenta caiu amplamente em desuso e pode ser usada em um instantâneo do LVM, mesmo na raiz.

Há pouca ou nenhuma razão para fazer isso mais. O único motivo que resta para fazer isso é se você deseja, por exemplo, impedir o /tmppreenchimento de todo o disco.

Esse motivo é amplamente irrelevante hoje em dia, porque a prova de que os usuários têm acesso geral ao shell foi esquecido e, atualmente, os servidores executam serviços dedicados, como servidores da Web ou de correio. Como você não tem usuários aleatórios capazes de executar comandos arbitrários, geralmente não precisa se preocupar com eles tentando preencher o seu sistema de arquivos (e mesmo quando o fez, você tinha cotas de disco para impedir isso).

Quanto ao nível de invasão a ser usado, é preciso lembrar que o principal objetivo da invasão não é proteger os dados (é para isso que servem os backups), mas manter o tempo de atividade. Se você realizar /tmpum raid0, seu servidor continuará inativo e você precisará repará-lo se um dos discos falhar. Você também pode usar o raid10 em vez do raid1, para obter melhor desempenho também.

Uma boa razão para NÃO interromper o sistema de arquivos é que, se você errar nas alocações, poderá acabar com parte do sistema de arquivos, apesar de haver muito espaço livre em outro lugar. Corrigir isso pode ser difícil, a menos que você use LVM e deixe algum espaço não atribuído.

Muitas informações de particionamento foram geradas quando o espaço em disco era insuficiente. Como resultado, você verá partições relativamente pequenas para vários casos. Os tamanhos de partição necessários variam dependendo do uso do servidor. O mais variável tendem a ser /tmp, /var, home, /opt, e /srv. /usrtende a ter um tamanho razoável e estável. O espaço para /pode incluir uma ou todas as outras partições e seus requisitos de espaço. O dimensionamento é realmente dependente do que você está fazendo no sistema.

Eu iria aumentar swape montar /tmpem tmpfs. Você /tmpusará o swap como uma loja de suporte, mas usará a memória conforme disponível. O tamanho da sua /tmpaparência é extremamente alto, mas manipula o carregamento interrompido que não é limpo.

Eu consideraria mover os arquivos MySQL para /srv. Este é um nível relativamente novo na hierarquia de discos.

Se você não conhece seus requisitos finais, considere usar o LVM e expandir suas partições como preenchimento.

Dependendo da sua arquitetura - talvez você não queira usar / tmp, pois é limpo após cada reinicialização. Se o seu site lida com o eventual processamento de envios, alterá-lo para outro local (via php.ini) pode ser uma ideia; em que você pode torná-lo em qualquer ponto de montagem.

Como sugerido anteriormente, é altamente recomendável usar o LVM e incrementar conforme necessário.

Eu também recomendo uma partição dedicada para dados do MySQL (você ainda pode montá-la em / var / lib / mysql).