Configuring Zimbra As A Secondary / Backup MX Server

Lets assume that we have two mail servers

primary.mailserver.com
secondary.mailserver.com

What we ultimately want is secondary.mailserver.com to accept, store ( and forward ) mail for primary.mailserver.com when it goes down.

 

On secondary.mailserver.com from within the administration console add the domain in question you are configuring. From console on secondary.mailserver.com run the following commands as user zimbra

 

zmprov md domain.com zimbraMailCatchAllAddress @domain.com
zmprov md domain.com zimbraMailCatchAllForwardingAddress @domain.com
zmprov md domain.com zimbraMailTransport smtp:primary.mailserver.com

 

In DNS your primary mail server should have a lower weighting ( 1 in this example ) then your secondary (10) and should look something like this.

 

[root@mailhost ~]# dig mx mailserver.com

; <<>> DiG 9.7.3-P3-RedHat-9.7.3-8.P3.el6_2.1 <<>> mx mailserver.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43716
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;mailserver.com.            IN    MX

;; ANSWER SECTION:

mailserver.com.        3600    IN    MX    10 secondary.mailserver.com.
mailserver.com.        3600    IN    MX    1 primary.mailserver.com.

;; Query time: 104 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Jan  6 15:02:06 2012
;; MSG SIZE  rcvd: 72

Configuring Zimbra As A Secondary / Backup MX Server

Lets assume that we have two mail servers

primary.mailserver.com
secondary.mailserver.com

What we ultimately want is secondary.mailserver.com to accept, store ( and forward ) mail for primary.mailserver.com when it goes down.

 

On secondary.mailserver.com from within the administration console add the domain in question you are configuring. From console on secondary.mailserver.com run the following commands as user zimbra

 

zmprov md domain.com zimbraMailCatchAllAddress @domain.com
zmprov md domain.com zimbraMailCatchAllForwardingAddress @domain.com
zmprov md domain.com zimbraMailTransport smtp:primary.mailserver.com

 

In DNS your primary mail server should have a lower weighting ( 1 in this example ) then your secondary (10) and should look something like this.

 

[root@mailhost ~]# dig mx mailserver.com

; <<>> DiG 9.7.3-P3-RedHat-9.7.3-8.P3.el6_2.1 <<>> mx mailserver.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43716
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

;; QUESTION SECTION:
;mailserver.com.            IN    MX

;; ANSWER SECTION:

mailserver.com.        3600    IN    MX    10 secondary.mailserver.com.
mailserver.com.        3600    IN    MX    1 primary.mailserver.com.

;; Query time: 104 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)
;; WHEN: Fri Jan  6 15:02:06 2012
;; MSG SIZE  rcvd: 72

Howto set up a backup MX for Zimbra in Ubuntu/Debian

Have you ever wanted to set up a backup mail exchanger (MX) for your main Zimbra installation? Recently, I had this need for two of my Zimbra installations. Of course, if you run the enterprise version of Zimbra where they offer you the tools to do this without too much work out of the box. But if you just don’t have the resources to put up another full scale Zimbra server, you can achieve much of the same with much less. Of course, it won’t offer you all the bells and whistles that a full Zimbra installation will, but it does the trick if your needs are sparse.

You can run this backup MX of a low price VPS or similar services. And in this day and age, you have a huge selection of such providers that won’t set you back in terms of money. You have great providers such as Linode that offers this at an affordable price, that give you a virtual server where you have complete root access to your virtual server. Which is just what we need to achieve our task of setting up a backup MX. If this is something you want and need, please continue to read this article.What I’ve done, is make two BASH scripts to make the task of setting up a backup MX a breeze as well as making the process automated once set up. I assume in this howto that you already have a fully working installation of Zimbra in production. I also assume that you have NTP (Network Time Protocol) set up and working on both hosts. We first start the work on our main host, the existing Zimbra server. We require root privileges to run the script, so let’s sudo into the root account.

youruser@main:~: sudo su -
root@main:~#: wget "http://redmine.tolecnal.net/projects/zimbrabackupmx/repository/revisions/master/raw/gen-users.sh"
root@main:~#: vim gen-users.sh

What the script ‘gen-users.sh’ does, is to query the Zimbra LDAP server for a list of active user accounts on all of your domains. This list is formatted in such a way that the backup host can easily parse it, and generate the necessary configuration files for postfix, which is used as the MTA on the backup host. You need to change a few things in the script before we proceed, namely the variables ‘REMOTEUSER’, ‘REMOTEHOST’ and ‘REMOTEPATH’. Since the scripts on both ends needs to be run as root, all that’s left to configure is really ‘REMOTEHOST’. Set this to the hostname of your backup MX host.

Since the list of users that are needed by the backup host needs to be copied over, I’ve chosen to do this using scp. Seeing as we want this process automated, we need to create a SSH key without a password using ssh-keygen.

root@main:~#: ssh-keygen -t rsa
root@main:~#: ssh root@remotehost mkdir -p .ssh
password:
root@main:~#: cat .ssh/id_rsa.pub | ssh root@remotehost 'cat &gt;&gt; .ssh/authorized_keys'
password:

To confirm that we’ve successfully enabled to authorized key on the remote host, we issue the following command (you should not need to enter a password).

root@main:~#: ssh root@remotehost hostname

At this point, the configuration files created by ‘gen-users.sh’ should be copied over to the remote host without being asked for a password. To automate the task, we also need to set up a crontab entry for the script. I prefer to run the script at 30 minute intervals, and I choose it to run at every whole hour and thirty minutes past the hour.

root@main:~#: crontab -e

Just add this to your crontab.

0/30 * * * * /root/gen-users.sh

Save the file, and cron should state that the crontab has been installed. To verify this, you can monitor your syslog and look out for the following:

Feb 12 11:30:02 mainhost BackupMX: SUCCESS: created the list of users
Feb 12 11:30:05 mainhost BackupMX: SUCCESS: sent user list to seattle.thebios.com

We now have to move over to our secondary box. I already assume that you have postfix installed and working for local mail delivery, and if you haven’t done so, do so now before proceeding. I won’t cover this process here, so if you’re in doubt on this one, please consult one of the many howto’s out there on how to get a basic postfix installation running. Just as on the main Zimbra host, we need to sudo into our root account and download the script.

youruser@backup:~: sudo su -
root@backup:~#: wget "http://redmine.tolecnal.net/projects/zimbrabackupmx/repository/revisions/master/raw/gen-postfix-config.sh"
root@backup:~#: vim gen-postfix-config.sh

You really shouldn’t need to change much here to get things working, maybe apart from the paths to postconf, postmap and postfix itself (if you’re not running Debian or Ubuntu). I would highly recommend that you keep ‘DEBUG’ enabled, even in production as it logs useful information to syslog. If you’ve successfully set up the main host, and verified that you indeed have the file ‘zimbra_recipients.list’ in your /root folder that was copied over with scp, we are good to go. All we need to do now is to set up a crontab entry for the job. I prefer to run this task at every five minutes past the hour and every 35 minutes past the hour. This is five minutes after the user/domain list was created on the main host, and should have made it over to the backup host (you did remember to set up NTP right?). So let’s set up the crontab.

root@backup:~#: crontab -e

Add this to your crontab

5/35 * * * * /root/gen-postfix-config.sh

Cron should now state that your crontab was successfully installed. At this point, you should be able to monitor your syslog to see that the script generates the needed configuration files for postfix. These files/configuration directives include:

  • The relay domains map (which domains postfix on our backup host should relay mails for if our main host is down)
  • The relay map (which user accounts under our domain(s) we allow incoming mail from)

If all has gone well, you should be able to see something similar to this in your syslog.

Feb 20 12:02:24 backuphost BackupMX: MD5 has changed - need to notify postfix of changes
Feb 20 12:02:24 backuphost BackupMX: Domains to relay for: $mydestination yourdomain1.com yourdomain2.org yourdomain3.net ... [etc]
Feb 20 12:02:24 backuphost BackupMX: SUCCESS: postconf updated with relay domains
Feb 20 12:02:24 backuphost BackupMX: SUCCESS: created the relay_recipient_maps file
Feb 20 12:02:24 backuphost BackupMX: SUCCESS: copied the relay map to /etc/postfix/backup-mx-relays
Feb 20 12:02:26 backuphost BackupMX: SUCCESS: postconf notified about the new relay map
Feb 20 12:02:26 backuphost postfix/postfix-script[18348]: refreshing the Postfix mail system
Feb 20 12:02:26 backuphost postfix/master[32541]: reload -- version 2.7.1, configuration /etc/postfix
Feb 20 12:02:26 backuphost BackupMX: SUCCESS: postfix configuration reloaded

This sums up this howto. I wish you all the best with setting this up, and I hope you found this useful. Comments are more than welcome, and if you find any bugs, please report them over at my

Solucionando problemas com o charset

Um problema muito comum ao utilizar o Apache 2 sobre uma distribuição Linux recente é os caracteres acentuados das páginas hospedadas aparecerem trocados por interrogações, quadrados ou vírgulas em alguns navegadores, como nesse screenshot:

Isso acontece em situações onde os arquivos das páginas hospedadas no servidor foram salvos usando o charset ISO-8859-1 (ou outro dos charsets pré-unicode) e o servidor Apache está configurado para usar UTF-8, que é o default no Ubuntu e na maioria das distribuições atuais.

Para solucionar o impasse, você tem basicamente três opções. A primeira é especificar o charset correto no header de cada página do site, o que é feito adicionando uma tag “meta” dentro da seção “head” da página, como em:

<meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8″ />
ou:
<meta http-equiv=”Content-Type” content=”text/html; charset=ISO-8859-1″ />

Algumas versões antigas do Internet Explorer entendem apenas a tag “http-equiv…”. Você pode adicioná-la também, de forma a manter compatibilidade com elas, como em:

<http-equiv=”Content-Type” content=”text/html; charset=utf-8″>

Continuando, a segunda opção é mudar a configuração do Apache para que ele passe a utilizar o ISO-8859-1 como charset padrão, em vez do UTF-8. Nas distribuições derivadas do Debian, isso é definido no arquivo “/etc/apache2/conf.d/charset“. Edite o arquivo, substituindo a linha:

AddDefaultCharset UTF-8

por:

AddDefaultCharset ISO-8859-1

Se, por acaso, o arquivo “/etc/apache2/conf.d/charset” não estiver disponível (ou a configuração não surtir efeito), edite o arquivo “/etc/apache2/apache2.conf“, descomentando (ou adicionando) a mesma linha.

No Fedora/CentOS a opção é incluída diretamente no arquivo “/etc/httpd/conf/httpd.conf” (perto do final do arquivo), basta substituir a linha “AddDefaultCharset UTF-8″ por “AddDefaultCharset ISO-8859-1″, assim como no Debian.

Se o servidor hospeda páginas escritas em português, é recomendável editar também a linha:

LanguagePriority en da nl et fr de el it ja ko no pl pt pt-br ltz ca es sv tw

… no “/etc/apache2/apache2.conf”, mudando a ordem das linguagens, de forma que o pt-br e o pt fiquem no início:

LanguagePriority pt-br pt en da nl et fr de el it ja ko no pl ltz ca es sv tw

Para que a configuração entre em vigor, é preciso fazer com que o Apache 2 recarregue a configuração:

# /etc/init.d/apache2 reload

ou:
# service httpd reload

O charset padrão do servidor é aplicado a todas as páginas onde o charset não é diretamente especificado na seção <head>, ajudando em casos em que você tem um grande volume de páginas antigas, onde o charset não é especificado.

Uma terceira opção, mais radical, seria mudar o charset de todas as páginas hospedadas (se você usa um gestor de conteúdo, muitas vezes esta opção estará disponível nas configurações) de “ISO-8859-1″ para “UTF-8″. Diversos editores de texto, incluindo o kwrite e o gedit, permitem trocar o charset usado, basta especificar qual quer usar nas configurações.

É possível também converter os arquivos diretamente, usando o comando “recode“, que está disponível nos repositórios de praticamente todas as distribuições que adotaram o uso do UTF8. Comece instalando o pacote, como em:

# apt-get install recode

ou:
# yum install recode

Para converter um arquivo, use o comando “recode -d ISO-8859-1..UTF-8″ seguido pelo arquivo a ser convertido, como em:

$ recode -d ISO-8859-1..UTF-8 arquivo.txt

Você pode também converter de uma vez diversos arquivos, como em:

$ recode -d ISO-8859-1..UTF-8 *.html

ou:
$ recode -d ISO-8859-1..UTF-8 *.php

O recode não salva cópias dos arquivos originais, por isso é importante que você sempre execute o comando sobre uma cópia dos arquivos, substituindo os arquivos originais só depois de verificar e testar. Concluindo, é possível também fazer o caminho inverso, convertendo arquivos de UTF-8 para ISO-8859-1, invertendo a sintaxe do comando, como em:

$ recode -d UTF-8..ISO-8859-1 *.html

A principal observação nesse caso é que o recode só consegue converter caracteres UTF-8 que possuem um correspondente dentro da codificação ISO-8859-1, por isso não deve ser usado em textos que incluam caracteres de línguas asiáticas, por exemplo.

Raid

Redundant Array of Independent Drives, também denominado Redundant Array of Inexpensive Drives ou mais conhecido como simplesmente RAID ou ainda em português: Conjunto Redundante de Discos Independentes ou também Conjunto Redundante de Discos Econômicos ou ainda Arranjo Redundante de Discos Independentes, é um meio de se criar um sub-sistema de armazenamento composto por vários discos individuais, com a finalidade de ganhar segurança e desempenho.

Popularmente, RAID seriam dois ou mais discos (por exemplo, HD ou disco rígido) trabalhando simultaneamente para um mesmo fim, por exemplo, citando o exemplo de RAID-1 logo abaixo, serviria como um espelhamento simples, rápido e confiável entre dois discos, para fazer o backup de um disco em outro. Apesar do RAID oferecer segurança e confiabilidade na adição de redundância e evitar falhas dos discos, o RAID não protege contra falhas de energia ou erros de operação. Falhas de energia, código errado de núcleo ou erros operacionais podem danificar os dados de forma irrecuperável.

Índice

[esconder]

[editar] História

O RAID foi proposto em 1988 por David A. Patterson, Garth A. Gibson e Randy H. Katz na publicação “Um Caso para Conjuntos de Discos Redundantes Econômicos (RAID)”. Publicado na Conferência SIGMOD de 1988: pp. 109–16.

[editar] Vantagens

  1. Ganho de desempenho no acesso.
  2. Redundância em caso de falha em um dos discos.
  3. Uso múltiplo de várias unidades de discos.
  4. Facilidade em recuperação de conteúdo “perdido”.

[editar] Arquiteturas

[editar] Implementação Via software

Na implementação via software, o sistema operacional gerencia o RAID através da controladora de discos, sem a necessidade de um controlador de RAIDs, tornando-a mais barata.

Nesse tipo de implementação, todo o processamento necessário para o gerenciamento do RAID é feito pela CPU. Toda movimentação de dados(leitura e escrita) é feita por uma camada de software que faz a abstração entre a operação lógica (RAID) e os discos físicos, e é controlada pelo sistema operacional.

A configuração do RAID via software é feita pelo sistema operacional, que precisa ter implementado no próprio núcleo a utilização de RAIDs via software. É possível criar RAIDs via software no Mac OS X, Linux, FreeBSD e no Windows (versão server).

[editar] Implementação Via hardware

Controladoras RAID em hardware usam layouts de disco proprietários (e diferentes). Por isso, normalmente não é possível misturar controladoras de fabricantes diferentes. Eles não utilizam recursos do processador. O BIOSBasic Input/Output System – pode iniciar (dar boot) por ela, e um integração maior com o driver de dispositivo pode oferecer um melhor tratamento de erros.

Uma implementação de RAID em hardware requer pelo menos uma controladora especialmente dedicada para isso. Em uma estação de trabalho (PC comum) isso pode ser uma placa de expansão PCI, PCI-e ou uma placa integrada à placa-mãe. Controladoras utilizando a maioria dos tipos de drive podem ser usadas – IDE/ATA, Serial ATA, SCSI, SSA, Fibre Channel, e às vezes uma combinação. A controladora e os discos utilizados devem estar isolados. Podem estar conectados diretamente ao computador, ou conectados via SAN. A controladora gerencia os drives e faz os cálculos de paridade necessários pelo nível de RAID escolhido.

A maioria das implementações em hardware proveem cache de leitura e escrita, o que (dependendo da carga de I/O) melhora a performance. Na maioria dos casos, o cache de escrita é não-volátil (protegido por bateria), e portanto, escritas pendentes não são perdidas no caso de uma falha no suprimento de energia. Implementações em hardware promovem performance garantida, não sobrecarregam o processador e podem suportar vários sistemas operacionais, já que a controladora apresentará ao sistema operacional um disco simples.

A maioria das implementações em hardware também suporta o “hot-swapping”, permitindo que discos com falha sejam substituídos enquanto o sistema está sendo executado.

[editar] Falso RAID

A implementação via software geralmente não possui uma fácil configuração. Já na implementação via hardware as controladoras tem um preço muito elevado. Então foi criada uma “controladora barata” que em vez de um chip controlador RAID você utiliza uma combinação de funções especiais na BIOS da placa e drivers instalados no sistema operacional .

[editar] Comparação entre as arquiteturas

Ao compararmos RAIDs por software e por hardware percebe-se que os implementados através de software são mais flexíveis que os via hardware. Por outro lado, os primeiros exigem da CPU mais tempo de processamento. Comparando os dispositivos de blocos, os em software também são flexíveis podendo ser usados em discos inteiros, partições ou outro dispositivo de bloco.

[editar] Níveis de RAID

Níveis de RAID são as várias maneiras de combinar discos para um fim.

[editar] RAID

RAID-0

O sistema RAID consiste em um conjunto de dois ou mais discos rígidos com dois objetivos básicos:

  1. tornar o sistema de disco mais rápido (isto é, acelerar o carregamento de dados do disco), através de uma técnica chamada divisão de dados (data striping ou RAID 0);
  2. tornar o sistema de disco mais seguro, através de uma técnica chamada espelhamento (mirroring ou RAID 1).

Essas duas técnicas podem ser usadas isoladamente ou em conjunto.

[editar] Vetor RAID 0 Linear

É uma simples concatenação de partições para criar uma grande partição virtual.

[editar] RAID 0 (Striping)

RAID-0

No striping, ou distribuição, os dados são subdivididos em segmentos consecutivos (stripes, ou faixas) que são escritos sequencialmente através de cada um dos discos de um array, ou conjunto. Cada segmento tem um tamanho definido em blocos. A distribuição, ou striping, oferece melhor desempenho comparado a discos individuais, se o tamanho de cada segmento for ajustado de acordo com a aplicação que utilizará o conjunto, ou array.

Há problemas de confiabilidade e desempenho. RAID-0 não terá desempenho desejado com sistemas operacionais que não oferecem suporte a busca combinada de setores. Uma desvantagem desta organização é que a confiança se torna geometricamente pior. Um disco SLED com um tempo médio de vida de 20.000 horas será 4 vezes mais seguro do que 4 discos funcionando em paralelo com RAID 0 (admitindo-se que a capacidade de armazenamento somada dos quatro discos for igual ao do disco SLED). Como não existe redundância, não há confiabilidade neste tipo de organização.

Vantagens:

  • acesso rápido as informações (até 50% mais rápido);
  • custo baixo para expansão de memória.

Desvantagens:

  • caso algum dos setores de algum dos HD’s venha a apresentar perda de informações, o mesmo arquivo que está dividido entre os mesmos setores dos demais HD’s não terão mais sentido existir, pois uma parte do arquivo foi corrompida, ou seja, caso algum disco falhe, não tem como recuperar;
  • não é usada paridade.

[editar] RAID 1

RAID-1

RAID-1

RAID-1 é o nível de RAID que implementa o espelhamento de disco, também conhecido como mirror. Para esta implementação são necessários no mínimo dois discos. O funcionamento deste nível é simples: todos os dados são gravados em dois discos diferentes; se um disco falhar ou for removido, os dados preservados no outro disco permitem a não descontinuidade da operação do sistema.

Vantagens:

  • caso algum setor de um dos discos venha a falhar, basta recuperar o setor defeituoso copiando os arquivos contidos do segundo disco;
  • segurança nos dados (com relação a possíveis defeitos que possam ocorrer no HD).

Desvantagens:

  • custo relativamente alto se comparado ao RAID 0;
  • ocorre aumento no tempo de escrita;
  • não é usada paridade.

[editar] RAID 2

RAID 2 é similar ao RAID 4, mas armazena informação ECC (Error Correcting Code), que é a informação de controle de erros, no lugar da paridade. Este fato possibilita uma pequena protecção adicional, porém o RAID 2 ficou obsoleto pelas novas tecnologias de disco já possuírem este tipo de correcção internamente. O RAID 2 origina uma maior consistência dos dados se houver queda de energia durante a escrita. Baterias de segurança e um encerramento correto podem oferecer os mesmos benefícios

Vantagem:

  • usa ECC.

Desvantagem:

  • hoje em dia há tecnologias melhores para o mesmo fim.

[editar] RAID 3

RAID-3

O RAID 3 é uma versão simplificada do RAID nível 2. Nesse arranjo, um único bit de paridade é computado para cada palavra de dados e escrito em um drive de paridade. À primeira vista, pode parecer que um único bit de paridade dá somente detecção de erro, e não correção de erro. Para o caso de erros aleatórios não detectados, essa observação é verdadeira. Todavia, para o caso de uma falha de drive, ela provê correção total de erros de um bit, uma vez que a posição do bit defeituoso é conhecida. Se um drive falhar, o controlador apenas finge que todos os seus bits são “zeros”. Se uma palavra apresentar erro de paridade, o bit que vem do drive extinto deve ter sido um “um”, portanto, é corrigido.

A fim de evitar o atraso em razão da latência rotacional, o RAID 3 exige que todos os eixos das unidades de disco estejam sincronizados. A maioria das unidades de disco mais recentes não possuem a opção de sincronização do eixo, ou se são capazes disto, faltam os conectores necessários, cabos e documentação do fabricante.

Vantagens:

  • leitura rápida;
  • escrita rápida;
  • possui controle de erros.

Desvantagem:

  • Montagem difícil via software.

[editar] RAID 4

O RAID 4 funciona com três ou mais discos iguais. Um dos discos guarda a paridade (uma forma de soma de segurança) da informação contida nos discos. Se algum dos discos avariar, a paridade pode ser imediatamente utilizada para reconstituir o seu conteúdo. Os discos restantes, usados para armazenar dados, são configurados para usarem segmentos suficientemente grandes (tamanho medido em blocos) para acomodar um registro inteiro. Isto permite leituras independentes da informação armazenada, fazendo do RAID 4 um array perfeitamente ajustado para ambientes transacionais que requerem muitas leituras pequenas e simultâneas.

O RAID 4 assim como outros RAID’s, cuja característica é utilizarem paridade, usam um processo de recuperação de dados mais envolvente que arrays espelhados, como RAID 1. Este nível também é útil para criar discos virtuais de grande dimensão, pois consegue somar o espaço total oferecido por todos os discos, exceto o disco de paridade. O desempenho oferecido é razoável nas operações de leitura, pois podem ser utilizados todos os discos em simultâneo.

Sempre que os dados são escritos no array, as informações são lidas do disco de paridade e um novo dado sobre paridade deve ser escrito para o respectivo disco antes da próxima requisição de escrita ser realizada. Por causa dessas duas operações de I/O, o disco de paridade é o factor limitante do desempenho total do array. Devido ao facto do disco requerer somente um disco adicional para protecção de dados, este RAID é mais acessível em termos monetários que a implementação do RAID 1.

Vantagens:

  • taxa de leitura rápida;
  • possibilidade do aumento de área de discos físicos.

Desvantagens:

  • taxa de gravação lenta;
  • em comparação com o RAID 1, em caso de falha do disco, a reconstrução é difícil, pois o RAID 1 já tem o dado pronto no disco espelhado;
  • tecnologia não mais usada por haver melhores para o mesmo fim.

[editar] RAID 5

RAID-5

RAID-5

O RAID 5 é frequentemente usado e funciona similarmente ao RAID 4, mas supera alguns dos problemas mais comuns sofridos por esse tipo. As informações sobre paridade para os dados do array são distribuídas ao longo de todos os discos do array , ao invés de serem armazenadas num disco dedicado, oferecendo assim mais desempenho que o RAID 4, e, simultaneamente, tolerância a falhas.

Para aumentar o desempenho de leitura de um array RAID 5, o tamanho de cada segmento em que os dados são divididos pode ser optimizado para o array que estiver a ser utilizado. O desempenho geral de um array RAID 5 é equivalente ao de um RAID 4, excepto no caso de leituras sequenciais, que reduzem a eficiência dos algoritmos de leitura por causa da distribuição das informações sobre paridade. A informação sobre paridade é distribuída por todos os discos; perdendo-se um, reduz-se a disponibilidade de ambos os dados e a paridade, até à recuperação do disco que falhou. Isto causa degradação do desempenho de leitura e de escrita.

Vantagens:

  • maior rapidez com tratamento de ECC;
  • leitura rápida (porém escrita não tão rápida).

Desvantagem:

  • sistema complexo de controle dos HDs.

[editar] RAID 6

É um padrão relativamente novo, suportado por apenas algumas controladoras. É semelhante ao RAID 5, porém usa o dobro de bits de paridade, garantindo a integridade dos dados caso até 2 dos HDs falhem ao mesmo tempo. Ao usar 8 HDs de 20 GB cada um, em RAID 6, teremos 120 GB de dados e 40 GB de paridade.

Vantagem:

  • possibilidade falhar 2 HDs ao mesmo tempo sem perdas.

Desvantagens:

  • precisa de N+2 HDs para implementar por causa dos discos de paridade;
  • escrita lenta;
  • sistema complexo de controle dos HDs.

[editar] RAID 0 (zero) + 1

RAID-0+1

O RAID 0 + 1 é uma combinação dos níveis 0 (Striping) e 1 (Mirroring), onde os dados são divididos entre os discos para melhorar o rendimento, mas também utilizam outros discos para duplicar as informações. Assim, é possível utilizar o bom rendimento do nível 0 com a redundância do nível 1. No entanto, é necessário pelo menos 4 discos para montar um RAID desse tipo. Tais características fazem do RAID 0 + 1 o mais rápido e seguro, porém o mais caro de ser implantado. No RAID 0+1, se um dos discos vier a falhar, o sistema vira um RAID 0.

Ex: se os dois discos que possuam a sequencia A1, A3, A5 falharem ao mesmo tempo, haverá perda de dados. Se apenas uma das controladoras falhar, o sistema continua funcionando, mas sem outra tolerância a falha e sem o ganho de velocidade.

Vantagens:

  • segurança contra perda de dados;
  • pode falhar 1 dos HD’s, ou os dois HD’s do mesmo DiskGroup, porém deixando de ser RAID 0 + 1.

Desvantagens:

  • alto custo de expansão de hardware (custo mínimo = 4N HDs);
  • os drives devem ficar em sincronismo de velocidade para obter a máxima performance.

[editar] RAID 1+0

RAID-10

O RAID 1+0, ou 10, exige ao menos 4 discos rígidos. Cada par será espelhado, garantindo redundância, e os pares serão distribuídos, melhorando desempenho. Até metade dos discos pode falhar simultaneamente, sem colocar o conjunto a perder, desde que não falhem os dois discos de um espelho qualquer — razão pela qual usam-se discos de lotes diferentes de cada ‘lado’ do espelho. É o nível recomendado para bases de dados, por ser o mais seguro e dos mais velozes, assim como qualquer outro uso onde a necessidade de economia não se sobreponha à segurança e desempenho.

Vantagens:

  • segurança contra perda de dados;
  • pode falhar um ou dois dos HDs ao mesmo tempo, dependendo de qual avaria.

Desvantagens:

  • alto custo de expansão de hardware (custo mínimo = 2N HDs);
  • os drivers devem ficar em sincronismo de velocidade para obter a máxima performance.

[editar] RAID 50

RAID-50

É um arranjo híbrido que usa as técnicas de RAID com paridade em conjunção com a segmentação de dados. Um arranjo RAID-50 é essencialmente um arranjo com as informações segmentadas através de dois ou mais arranjos. Veja o esquema representativo abaixo:

Vantagens:

  • alta taxa de transferência;
  • ótimo para uso em servidores.

Desvantagens:

  • alto custo de implementação e expansão de memória.

[editar] RAID 100

RAID 100

O RAID 100 basicamente é composto do RAID 10+0. Normalmente ele é implementado utilizando uma combinação de software e hardware, ou seja, implementa-se o RAID 0 via software sobre o RAID 10 via Hardware.

[editar] Ver também

Commons
O Commons possui multimídias sobre RAID

[editar] Ligações externas