O sistema operacional utilizado foi o Ubuntu Server 12.04.3 x64 e o Hardware foi um computador comum Duo Core com 1 GB de RAM, 1 slot IDE (PATA), 4 slots SATA, comunicação de rede onboard Ethernet e acesso à Internet.

O slot PATA foi particularmente interessante, pois ainda é comum encontrar placas-mãe com ela. Como eu possuía um HD PATA de 160 GB novo (por assim dizer), aproveitei e o utilizei no sistema operacional. Conectei dois HDs SATA iguais de 500 GB para o RAID e servir para armazenar os dados disponibilizados na rede.

Assim, me restaram mais dois slots SATA livres para um upgrade de outro array RAID1, se eu precisar.

A utilização de um HD exclusivo para o sistema operacional não é uma regra, mas, é uma boa prática. Mesmo se eu não tivesse o HD PATA, teria adicionado outro HD SATA dedicado ao sistema operacional ou, pensaria em soluções alternativas, como instalar o Ubuntu Server em um Disk-on-key, em vez de um HD.

Instalei o Ubuntu sem adicionar nenhum pacote extra com o SSH, LAMP, etc. A instalação do Ubuntu, não será abordada no texto.

Para a edição dos arquivos de configuração, utilizei o editor de texto nano, mas não tente usar outro editor como Vi ou Emacs, pois as configurações não irão funcionar. 😉

Vale ressaltar, que todos os comandos listados abaixo precisaram de direitos de administrador ou root. 

Criando o RAID virtual

Instale o gerenciador de RAID virtual, com o seguinte comando:

# apt-get install mdadm

Durante a instalação, opte por No Configuration para Postfix. O arquivo de configuração mdadm.conf, está localizado em /etc/mdadm no Debian/Ubuntu ou, no /etc em distribuições não baseadas no Debian.

Criaremos agora, um array (disco virtual que será referência para o RAID) em que os dois discos serão vinculados:

# mdadm –create –verbose /dev/md0 –level=1 -n2 /dev/sdX1 /dev/sdZ1
# mdadm –detail –scan >> /etc/mdadm/mdadm.conf

As referencias /dev/sdX1 e /dev/sdZ1 são para os discos SATA, onde sdX1 e sdZ1, geralmente, correspondem a sdb1 e sdc1. (você poder verificar os dispositivos conectados ao computador através do comando: fdisk -l)

Ao executar este dois comandos acima (mdadm), serão criadas a referência ao RAID virtual /dev/md0 (primeiro comando) e suas configurações serão guardadas no arquivo de configurações de RAID virtual (segundo comando).

Para verificar se está tudo funcionando corretamente, execute o comando:

$ cat /proc/mdstat

Obs.: para este comando, não é necessário direitos de administrador.

Deve aparecer algo semelhante às linhas abaixo:

Personalities : [linear] [multipath] [raid0] [raid1] [raid6] [raid5] [raid4] [raid10]
md127 : active raid1 sdb1[0] sdc1[1]
488253248 blocks super 1.2 [2/2] [UU]

O [UU], indica que os discos estão ativos no RAID. Veja no final deste tutorial, outras dicas de gerenciamento do RAID.

Formatando o RAID

É possível utilizar qualquer sistema de arquivos para o RAID. Eu utilizei o XFS, por ser um sistema de arquivos antigo (1994), estável, robusto e muito bom para leitura de dados, que é a minha necessidade. Entretanto, você pode utilizar o formato padrão do Ubuntu (ext4) ou, até mesmo o NTFS do Windows.

Para quem decidiu pelo XFS, como eu, instale os pacotes xfsprogs e xfsdump:

# apt-get install xfsprogs xfsdump

Em seguida, execute o seguinte comando para formatar o RAID virtual:

# mkfs.xfs -f /dev/md0

Caso prefira o formato ext4, simplesmente utilize o comando:

# mkfs.ext4 /dev/md0

Eu, realmente, não encontrei nenhuma vantagem em utilizar NTFS, mas se você o preferir, poderá formatar o RAID com este sistema de arquivos, com o comando:

# mkntfs /dev/md0

Veja mais dicas no final do texto, sobre tratamento de HDs.

Montando o RAID

Precisamos de um diretório para a montagem do RAID. Crie um no diretório em /mnt, como no exemplo abaixo:

# mkdir /mnt/raid_a

Você precisará do número de identificação do RAID para acrescentarmos no /etc/fstab. Para isso, execute o seguinte comando:

# blkid
Ou:
# ls -l /dev/disk/by-uuid/

Você deve copiar o código ID referenciado por …/md0.

Caso tenha formatado o RAID virtual como XFS, você encontrará um ID no seguinte formato:

Caso tenha formatado o RAID virtual como NTFS, você encontrará um ID no formato:

* Atenção: eu executei este comando após o reinício do computador. E a referência do código ID mudou de …/md0 para …/md127. Não encontrei nenhuma explicação para tal fato, entretanto, isso não altera em nada os próximos passos.

Outro fato interessante, é que, mesmo formatando RAID virtual (/dev/md0) como XFS, os discos continuaram com o seu formato original (NTFS), entretanto, isso não afetou o funcionamento do RAID.

Execute o comando fdisk -l, para verificar todos os detalhes dos dispositivos.

Agora, configuraremos a montagem automática do RAID após o boot do sistema. Para isso, edite o arquivo /etc/fstab:

# nano /etc/fstab

No final do arquivo, inclua a seguinte linha para o RAID formatado como XFS/ext4:

Ou, para o RAID formatado como NTFS:

Reinicie o computador e verifique se tudo funciona como devido.

Criando a árvore de diretórios

É uma boa prática, criar um diretório dentro do /mnt/raid_a para abrigar os documentos que serão armazenados no servidor. Assim, não haverá confusão, caso queira utilizar o espaço disponível nos discos do RAID para outros fins. No nosso caso, o DFS também será instalado no RAID.

Por enquanto, criaremos os seguintes diretórios:

# mkdir /mnt/raid_a/ddata
# mkdir /mnt/raid_a/dirraid

Caso tenha optado pelo XFS/ext4, é necessário mudar as permissões da pasta. Esta mudança não foi necessária, quando testei o RAID formatado como NTFS:

# chmod 777 /mnt/raid_a/ddata

Agora, terminarei de descrever a configuração do servidor. Depois, retornaremos às pastas compartilhadas e DFS.

Permitindo acesso remoto ao servidor

O acesso remoto a servidores GNU/Linux, é bem conhecido e simples de configurar, mas, prefiro incluir todos os passos que realizei e na mesma sequência, para diminuir a possibilidade de falhas.

Assim, instale o ssh-server da seguinte forma:

# apt-get install openssh-server

Agora, você pode acessar o seu servidor através de clientes SSH como o PuTTY, ou o KiTTY.

Sincronizando o horário com o Domain Windows

O servidor NTP oferece o serviço de sincronização de data e hora, com a sua data e hora interna aos computadores da rede.

A sincronização da data e hora é particularmente importante em redes Windows, para que os computadores e cliente membros do Domain possam ser autenticados. Por isso os servidores Windows, quando atuam como Domain Controler (DC), geralmente são servidores NTP.

Além do mais, é uma boa prática que todos os hosts da rede tenham como referência, um servidor NTP interno. Portanto, o nosso servidor será sincronizado com o DC da rede.

Instale o pacote NTP através do comando:

# apt-get install ntp

Ajuste manualmente a data e hora do servidor em relação ao Domain Controler (DC):

# ntpdate -u <nomedodcserver>.<nomedarede>

Onde:

• <nomedodcserver> :: é o nome do servidor atual como Domain Controler.
• <nomedarede> :: é o nome do domínio.

Editaremos o arquivo /etc/ntp.conf para que o ajuste do horário seja automático, da seguinte forma:

# nano /etc/ntp.conf

Comente as seguintes linhas como demonstrado abaixo:

E adicione as seguintes linhas e salve as alterações:

Reinicie o serviço NTP, executando o seguinte comando:

# service ntp restart

Para verificar se o NTP está devidamente configurado, execute:

# ntpdc -p

Associando o servidor à rede Windows

Instalaremos agora, os pacotes necessários para que um servidor GNU/Linux possa ser um Member Server de uma rede Windows. Em seguida, realizaremos todas as configurações necessárias para que isso seja possível.

# apt-get install samba winbind libpam-modules

Ao configurar o Samba, estaremos dando continuidade ao item 4, que falava sobre pastas compartilhadas e, em paralelo, dando continuidade à configuração do servidor.

Criamos dois diretórios com os seguintes propósitos:

• /mnt/raid_a/ddata :: pasta de dados que o servidor armazenará.
• /mnt/raid_a/dirraid :: root do DFS.

Vamos para a configuração do Samba Winbind. Edite o arquivo:

# nano /etc/samba/smb.conf

Como descrito a seguir:

Modifique o arquivo /etc/nsswitch.conf, para que as linhas fiquem desta forma:

Reinicie os serviços do Samba e do Winbind:

# service smbd start
# service winbind start

Ingressaremos no domínio (Windows Group Management) com o comando:

# net rpc join member -U <Domain Administrator>

Será solicitada a senha da conta <Domain Adminstrator>.
Caso ocorra algum problema, adicione o parâmetro: -S < nomedodcserver>

Liberando login de usuários do Domain ao servidor

Instale o Kerberos, usando o comando:

# apt-get install krb5-user libkrb53

Agora, será descrita uma lista de arquivos que serão editados. Os comentários serão suprimidos, para uma melhor visualização:

# nano /etc/pam.d/common-account  # O Winbind configura automaticamente, mas convém verificar.

# nano /etc/pam.d/common-auth  # O Winbind configura automaticamente, mas convém verificar.

# nano /etc/pam.d/common-session

Ao final reinicie o servidor.

Associando o servidor ao Active Directory

Para adicionar o servidor GNU/Linux ao Active Directory, execute o comando a seguir:

# net ads join -U <administrator do domain>

Um texto parecido com o seguinte, será mostrado:

Joined ‘FILESERVERNAME’ to realm ‘exemple.local’
No DNS domain configured for datdserver. Unable to perform DNS Update.
DNS update failed!

Para verificar se está tudo OK, use o comando abaixo:

# wbinfo -t

O seguinte texto deve ser retornado:

Checking the trust secret for domain DOMAINAME via RPC calls succeeded

Outros comandos interessantes, que podem ser utilizados para verificar se o servidor está integrado ao Domain, são:

# wbinfo -u
# wbinfo -b

Lista os usuários e grupos dos Domain. Um outro comando que pode ser utilizado para testar referenciando semente a um usuário, é:

# wbinfo -a DOAMINAME\\user%’password’

Permitindo que usuários do Domain atuem como root do servidor

Para isso, basta alterar o arquivo /etc/sudoers e acrescentar as seguintes linhas:

Configurando o DFS

Para que as pastas compartilhadas pelo Samba possam ser referenciadas pelo serviço DFS do Windows, é necessário ativar este serviço no Samba. Para isso, adicione a seguinte linha no final do bloco [global] do /etc/samba/smb.conf:

Se a intenção é possibilitar ao servidor GNU/Linux agir como DFS, como no meu caso, então, crie a pasta que servirá de pasta raiz do DFS.

Como mencionado no início do tutorial, eu utilizarei o RAID para armazenar esta pasta raiz:

# mkdir /mnt/raid_a/dfsroot
# chmod 755 /mnt/raid_a/dfsroot

Você pode escolher qualquer outro nome, além de dfsroot.

Após o bloco [global], adicione as seguintes linhas para definir o diretório raiz do DFS:

Agora, criaremos os links necessários para serem disponibilizados pelo DFS.

O primeiro link, será para o diretório Dados, que disponibilizamos anteriormente.

Mas, existe uma ressalva, se digitarmos o caminho \\seuserv\Dados, este será visível. Após criarmos o link no DFS, poderemos acessar a mesma pasta através do caminho \\seuserv\dfsroot\Dados.

Do meu ponto de vista, isso não é elegante. Então, para solucionar esta situação, podemos tornar a pasta \\seuserv\Dados invisível, acrescentando o sinal $ no smb.conf, da seguinte forma:

Após os devidos ajustes, acesse a pasta /mnt/raid_a/dfsroot e execute o seguinte comando:

# ln -s msfs:seuserv\\Dados$ Dados

Como o DFS não tem muito sentido se não houver referências às pastas compartilhadas em outros servidores, segue alguns exemplos de links que poderão ser criados neste mesmo diretório.

Cria uma pasta compartilhada \\seuserv\dfsroot\OutrasPastas em referência a outro servidor da rede:

# ln -s msdfs:outroserv\\outrapasta OutrasPastas

Cria uma pasta compartilhada com espaço no nome \\seuserv\dfsroot\Pasta 2, em referência a uma pasta também com espaço no nome:

# ln -s “msdfs:outroserv\\pasta com espacos” “Pasta 2”

* Importante: O serviço DFS precisa estar ativo no servidor ao qual você fizer referência, tanto em servidores Windows, quanto em servidores GNU/Linux.

Definindo o acesso ao servidor via SSH

É muito recomendado definir que usuários, ou grupo de usuários, possuam acesso ao servidor via SSH.

Para isso, é necessário alterar o arquivo /etc/ssh/sshd_config. Para definir que somente os administradores do domínio tenham acesso a este servidor, acrescente a seguinte linha no final do arquivo:

E, em seguida, reinicie o serviço SSH:

# service ssh restart

Vale ressaltar que o root (que vem desativado por padrão no Ubuntu) e a conta administrativa criada do GNU/Linux, não terão mais acesso ao sistema via SSH, somente pelo terminal.

Ativando o Firewall

A Canonical (empresa responsável pelo Ubuntu) trouxe a interface UFW (Uncomplicated Firewall), que veio para facilitar o gerenciamento do Firewall do GNU/Linux. O UFW nada mais é do que uma interface para o IPtables. O UFW já vem pré-configurado para diversos serviços como, por exemplo, DHCP Client, DNS Client e ICMP. O UFW vem desativado por padrão.

Como a nossa intenção é utilizá-lo, então, é necessário adicionar algumas regras, simples, para liberar o acesso dos serviços do nosso servidor.

Nós temos apenas dois serviços que precisam ser liberados, que são para o SSH e Samba:

# ufw allow ssh
# ufw allow samba

Também, é uma boa prática incluir uma restrição aos IPs permitidos para acessar o servidor. Minha rede está configurada para a rede Classe C 192.168.1:

# ufw allow from 192.168.1.0/24

Para finalizar, ative o Firewall:

# ufw enable

Prevenindo erro de escrita no RAID

Com uma falha no fornecimento de energia, existe uma pequena possibilidade de haver perda dos dados mais recentes (em cache), em especial em sistemas RAID. Nos casos mais graves, podem ocorrer uma corrupção do sistema de arquivos.

Vale ressaltar, que o XFS possui seu próprio sistema de Write Back. Caso você seja paranoico (como eu), desabilite o Write Back para cada um dos HDs, com os seguintes comandos:

# hdparm -W0 /dev/sdX
# hdparm -W0 /dev/sdZ

Atenção ao W. Ele tem que estar em maiúsculo!

Se for mostrado algum erro, é porque o seu HD não suporta o comando e nada será alterado, nem nenhum dado perdido.

Verifique se está tudo funcionando, com o comando:

# hdparm -I /dev/sdX

Para que esta configuração esteja ativa no próximo boot, adicione estas linhas no final do arquivo /etc/rc.local, logo antes do comando exit 0 (se ele existir):

Manutenção do RAID virtual

Removendo disco de um array:

# mdadm –fail /dev/md0 /dev/sdX1 –remove /dev/sdX1

Adicionando um disco ao array:

# mdadm –add /dev/md0 /dev/sdY1

Verificando o status do array:

# mdadm –detail /dev/md0
Ou:
# cat /proc/mdstat

Removendo um array:

# mdadm –stop /dev/md0
# mdadm –remove /dev/md0

“Zerando” o HD para formatação NTFS

Uma boa prática é “zerar” completamente o HD, para depois formatá-lo como NTFS, assim, siga os seguintes passos para cada um deles (/dev/sdX e /dev/sdZ):

# fdisk /dev/sdX

Dicas:

• Clique m, para obter uma lista de comandos possíveis.
• Clique p, para listar as partições em sdX.

Comando (m para ajuda): d
Partição selecionada 1

Comando (m para ajuda): n Comando – ação
e    estendida
p    partição primaria (1-4)

p
Numero da partição (1-4): 1
Primeiro cilindro (1-121601, padrão 1):
Usando valor padrão 1
Last cilindro, +cilindros or +size{K,M,G} (1-121601, padrão 121601):
Usando valor padrão 121601

Comando (m para ajuda): t

Partição selecionada 1
Código hexadecimal (digite L para listar os códigos): 7
O tipo da partição 1 foi alterado para 7 (HPFS ou NTFS)

Comando (m para ajuda): w

# mkntfs /dev/sdX1

Outros comandos interessantes para o gerenciamento de partições NTFS em GNU/Linux são:

Altera o nome da partição:

# ntfslabel /dev/sdX1 NovoNome

Para corrigir erros na partição, é necessária a instalação do pacote ntfs-3g, que inclusive, já contém os comandos do pacote ntfsprogs:

# apt-get install ntfs-3g
# ntfsfix /dev/sdX1

Pode ser necessário garantir ao grupo do administrador do domínio acesso de administrador dos HDs do servidor. Para isso, execute o seguinte comando no servidor GNU/Linux:

# net rpc rights grant ‘nome da rede Domain\Domain Admins’ SeDiskOperatorPrivilege -U <nome do administrador do domínio>

Opções de configuração do XFS no fstab

Esta foi uma contribuição do Galactus neste tópico do Ubuntu Fórum:

noatime :: os tempos de acesso dos dados não serão atualizados quando lidos, apenas quando gravados. Não há risco de perda de dados com essa opção. Se o tempo de acesso dos dados for importante para você não use essa opção.

nodiratime :: os tempos de acesso dos diretórios não serão atualizados quando lidos, apenas quando gravados. Não há risco de perda de dados com essa opção. Se o tempo de acesso dos diretórios for importante para você não use essa opção.

nobarrier :: essa opção faz com que a verificação dos dados entre o cache do disco e o buffer da memória não sejam mais feitas. Com essa opção ativa você acelera a gravação dos dados mas existe o risco de perda de dados em uma queda de energia ou travamento do sistema, aquilo que estiver aberto pode ser perdido.

logbufs :: diz o número de buffers que devem ser guardados na memória, esse número varia de 2 a 8. Nos kerneis mais recentes o 8 já é o padrão. Essa opção ajuda muito o XFS a lidar com arquivos pequenos e aumenta o consumo de RAM. Use 8 e seja feliz!

logbsize :: especifica o tamanho de cada buffer na memória. Você pode especificar o tamanho em bytes ou kilobytes, o padrão é 32k nas versões mais recentes do kernel. Você pode aumentar esse valor para 64k, 128k até o máximo de 256k. Essa opção ajuda muito o XFS a lidar com arquivos pequenos e aumenta o consumo de RAM. Use 256k e seja feliz!

allocsize :: determina o tamanho final da pré-alocação do buffer de I/O. Seu tamanho varia de 64Kib a 1Gib. Essa opção ajuda a diminuir a fragmentação do disco e aumenta a velocidade de transferência de arquivos grandes. No caso do disco rígido servir apenas para arquivos grandes como imagens ISO, use 512mb, no geral 64mb está de bom tamanho. Você não aumenta o risco de perda de dados com essa opção. Na prática notei que quanto maior esse número, melhor a taxa de transferência, mas também o sistema fica mais “preso” a essa transferência, então não abuse.

delaylog :: atrasa a gravação das informações no journal do XFS o máximo possível. São parâmetros internos do XFS que determinarão quando as informações serão salvas. Essa opção acelera muito o XFS mas aumenta o risco de perda de dados no caso de uma queda de energia ou travamento do sistema. Note que você não está desativando o Journal, apenas atrasando a gravação dos dados nele. A opção delaylog não funciona em versões antigas do XFS ou do kernel Linux.

osynciosync :: essa aqui é complicada, mas resumindo, essa opção tem haver com uma espécie de garantia de que as gravações dos dados e metadados ocorram em sincronia com o cache do disco. Entendeu? Eu também não! Para piorar ainda mais, dizem que essa opção é obsoleta e não faz mais “efeito”. Na prática o que notei é que o XFS pode ficar mais ágil com essa opção no fstab do que sem ela, dependendo da carga no sistema! Para quem usa kerneis mais novos, talvez o melhor seja não usar essa opção. Faça os seus testes e observe se ela ajuda mais que prejudica seu sistema. Ah sim, ela não é indicada para quem vai ter grandes bancos de dados no disco rígido.

inode64 :: indica que o XFS pode criar inodes em qualquer lugar do sistema de arquivos, essa opção pode criar problemas em aplicações de backup que não podem lidar com grande número de inodes. Essa opção é sempre indicada em grandes servidores de arquivos. Na prática achei que aumenta a latência em geral para o desktop. Também notei o seguinte, ou você usa o inode64 ou usa o allocsize para melhor desempenho. Os dois juntos atrasaram o tempo de resposta do desktop! Eu prefiro o allocsize para desktop e o inode64 para servidores de arquivos. Faça os seus testes e verifique se ele é bom pra você.

Desfragmentação de partições XFS

Mais uma contribuição do Galactus, disponível neste tópido:

Esta é uma grande vantagem, frente a outros sistemas de arquivos que sua distro pode usar. O XFS é capaz de ser desfragmentado com suas partições montadas e ativas, sem risco de perda de dados.

Contudo, eu sugiro que o ideal seja fazer isso com todos os programas e arquivos fechados. O motivo é simples, se for detectado que um arquivo está em uso, este arquivo em particular, não é desfragmentado.

Quanto mais potente for o seu processador, mais rápida será a sua desfragmentação. A primeira desfragmentação/reorganização é bastante demorada. O comando para desfragmentar é o xfs_fsr e deve ser dado como root. Ele vai reorganizar o sistema de arquivos, um arquivo por vez, procurando compactar e melhorar a disposição das extensões dos arquivos junto aos blocos e inodes. Ele também desfragmenta os 10% de arquivos mais fragmentados por vez que é executado.

Como root, você pode fazer:

# xfs_fsr -t 8000 /dev/sdxy -v

Onde:

• O -t, é o tempo máximo que ele pode levar para desfragmentar/reorganizar em segundos. Se não colocar o -t, o valor padrão é 7200 ou 2 horas.
• O -v, é o modo verbose, ou seja, ele vai te mostrar o que está fazendo, muito bom para saber se ele pulou algum arquivo que estava aberto.

Você também pode saber o quão desfragmentado o seu disco rígido está, antes de executar uma desfragmentação. O comando é:

# xfs_db -c frag -r /dev/sdxy

Exemplo da saída do comando:

# xfs_db -c frag -r /dev/sda5

  
  actual 232989, ideal 232230, fragmentation factor 0.33%

Eu recomendo que você faça uso do xfs_fsr, todas as vezes que uma quantidade grande de programas forem instalados ou removidos, assim, como se os seus dados forem inseridos, alterados ou deletados do disco.

Eu não espero a fragmentação aumentar, como ele reorganiza os inodes, o sistema fica sempre ágil com a execução frequente do xfs_fsr.