Comunicações

Proteção de dados e recuperação de desastres no Exchange Server 2007

Lee Benjamin

Visão geral:

• Backup e restauração básicos
• Continuidade de dados
• Tecnologias de replicação
• Soluções alternativas

O Microsoft Exchange Server foi projetado com o backup em mente. As organizações precisam fazer backup dos dados de seus sistemas de mensagens e também devem ser capazes de recuperar essas informações. Para atender a essas necessidades, a Microsoft construiu toda uma gama de opções de proteção de dados, desde os tradicionais

backup e restauração no nível inferior, até a continuidade operacional e as soluções de continuidade de negócios que oferecem os mais altos níveis de disponibilidade e de recuperação de desastres. Neste artigo, examinarei essas opções a ajudarei você a decidir como implementar a melhor solução de recuperação do Exchange para a sua organização.

NÍVEL 1: BACKUP E RESTAURAÇÃO BÁSICOS

Você pode fazer backup dos arquivos do Exchange colocando seus bancos de dados offline, mas também pode fazer isso enquanto eles estão em execução. Na verdade, a última opção é a forma mais recomendada de backup do Exchange. Mas o Exchange é mais do que um conjunto de arquivos. É um armazenamento de informações com grandes arquivos de bancos de dados e logs de transação. As mensagens enviadas para o Exchange são registradas imediatamente nos logs de transação e, quando o sistema tem alguns ciclos livres (normalmente alguns milissegundos mais tarde), essas mensagens são copiadas para o banco de dados. Ao gravar as informações em disco o mais rápido possível, o Exchange oferece um nível muito alto de capacidade de recuperação. A disponibilidade de ambos os conjuntos de informações é fundamental para a recuperação do Exchange. Caso haja uma falha no seu sistema, a combinação do backup anterior e de todas as transações até aquele ponto permitirá que você restaure o Exchange até a informação mais recente. Observe que o Exchange reproduz automaticamente as transações em um banco de dados restaurado, se necessário.

Os programas de backup acessam informações no banco de dados do Exchange por meio da API de backup ESE (Mecanismo de Armazenamento Extensível) ou por meio de soluções VSS mais novas, das quais falarei mais adiante. Sempre que um backup ESE é iniciado, o Exchange suspende temporariamente todas as gravações no banco de dados. Ao mesmo tempo em que o ESE coloca temporariamente o banco de dados em um modo somente para permitir que ele seja copiado em um backup completo, ele também utiliza um banco de dados temporário para armazenar novas transações que ocorram durante o backup. Quando o backup estiver concluído, o ESE retornará o banco de dados ao seu modo leitura/gravação normal e aplicará as transações acumuladas em seu banco de dados temporário. Os logs de transação antigos também são limpos no final de um processo de backup bem-sucedido.

Embora esse processo de backup seja direto e transparente até mesmo para os usuários que se conectam no meio da noite durante o backup, o ESE pode demorar bastante tempo para terminar, especialmente porque os bancos de dados do Exchange podem ter desde alguns poucos gigabytes até 30 a 50, ou até mesmo 100 GB — fazendo com que fique praticamente impossível para as tecnologias padrão concluírem o backup em uma noite. Para você ter uma idéia das opções disponíveis com o NTBackup.exe, dê uma olhada na Figura 1.

Figura 1** Usando o utilitário NTBackup **

Práticas recomendadas para o Exchange

Se você quer poder se recuperar rapidamente de falhas comuns de hardware e do sistema, deverá executar backups completos do Exchange todas as noites. Para aprimorar o desempenho e a capacidade de recuperação sempre que um servidor Exchange utilizar discos locais, é importante que você use matrizes RAID separadas para armazenar os bancos de dados e os logs de transação do Exchange. Dessa forma, se um controlador RAID falhar, ou se mais de um disco do RAID falhar de forma que os outros discos não possam mais recriar os dados distribuídos, ainda assim você poderá se recuperar. Se você perder os seus logs de transação, ainda terá bancos de dados atualizados no Exchange nas outras unidades que garantirão a continuidade das operações normais com novos logs de transação. Se você perder as unidades de banco de dados, a sua estratégia de recuperação será voltar ao seu backup completo da noite anterior e aplicar os logs de transação do dia atual para atualizar os bancos de dados.

É importante que você limite o tamanho dos bancos de dados do seu Exchange para que cada um possa ser copiado para o backup — e, mais importante, restaurado — em um tempo razoável. Para a maioria das organizações, isso significa manter o tamanho dos bancos de dados entre 30 e 50 GB. Quando um banco de dados ficar maior do que isso, será recomendável dividi-lo em diversos bancos de dados para que a restauração seja gerenciável.

A seqüência de backup e de restauração

A localização dos bancos de dados e dos logs de transação é muito importante — não só para o desempenho do backup como também para a velocidade de recuperação. Hoje, todos os servidores oferecem suporte a diversos níveis de redundância de unidades de disco, conhecidos como RAID. Basicamente, o RAID permite que uma unidade de disco falhe sem prejudicar o sistema, embora seu desempenho se torne mais lento até que o disco seja substituído e recriado. Até lá, o controlador RAID deve recriar os dados a partir dos discos que restaram de forma dinâmica, em resposta a cada solicitação de acesso a disco. Para obter mais informações sobre o design de espaço de armazenamento no servidor para caixas de correio, consulte o documento do IT Showcase da Microsoft "Adotando os 64 bits com o Exchange Server 2007".

Um dos principais recursos do Exchange é o seu design de banco de dados de instância única. Isso significa que somente uma cópia de uma mensagem específica e um único anexo (se existir) serão armazenados em um banco de dados do Exchange. Se a mensagem foi enviada para vários destinatários do mesmo armazenamento de informações, serão criados ponteiros adicionais para os objetos (mensagem, anexo), evitando que eles sejam duplicados. Essa vantagem não vale só para obtermos mais eficiência de entrega, mas também economiza espaço para o Exchange, tanto em disco como em fita.

Embora o Exchange seja bom em recuperar todo o banco de dados, a restauração de caixas de correio, pastas ou mensagens individuais exige primeiro a recuperação de toda a fita. Não é nenhuma surpresa saber que os usuários querem recursos de restauração mais granulares. A instância única em fita dificulta muito essa restauração. Os fornecedores de backup responderam a essa necessidade com o "Backup Brick-Level" (que eu não recomendo). Após a conclusão de um backup completo do banco de dados do Exchange usando a API de backup ESE aprovada, os produtos adicionam todas as caixas de correio à fita de backup. Como a API de backup não oferece uma forma de retirar os dados de caixas de correio individuais, usa-se o MAPI. Como resultado, a fita de backup leva consideravelmente mais tempo, já que você está duplicando todas as mensagens e anexos.

A Microsoft fez alguns aperfeiçoamentos que resolveram parcialmente o problema. Por exemplo, a lixeira administrativa (ou Dumpster) mantém os itens por um tempo depois que eles são excluídos pelos usuários, caso eles sejam novamente necessários. Além disso, não é mais necessário manter um servidor reserva como uma floresta de recuperação do Exchange; os grupos de armazenamento de recuperação permitem que um administrador monte parcialmente bancos de dados restaurados recuperados de fita e copie ou mescle dados no nível das caixas de correio.

A prática leva à perfeição

Muitas organizações aprenderam da forma mais difícil que, a despeito do nível de backup e de recuperação escolhido, a mídia de backup e os procedimentos de recuperação devem ser testados regularmente. Muitos administradores descobriram se a sua tecnologia de backup e seus procedimentos de restauração funcionavam ou não somente depois de um desastre. O melhor momento para o teste é o dia seguinte à criação e à configuração do seu servidor novo, quando ele já estiver operacional em sua organização do Exchange mas ainda possuir alguns poucos usuários. Neste momento, você deve executar um backup completo do Exchange, backups regulares das suas unidades e capturar o estado do sistema, o que inclui os arquivos fundamentais no disco do sistema, assim como a metabase do IIS (onde é mantida a configuração de roteamento do Exchange). Em seguida, reformate calmamente o novo servidor e comece tudo outra vez, atualizando as notas tomadas durante a primeira instalação do servidor. Você deve ser capaz de restaurar configurações a partir do estado do sistema, mas também precisa ter a documentação adequada para reimplementá-las manualmente.

O tempo gasto neste exercício de fogo reduzirá significativamente o seu tempo de recuperação no futuro. Repita esse processo periodicamente. Durante o processo, cronometre o tempo de obtenção das fitas armazenadas em um local externo. Aqueles que já passaram por esse intervalo interminável quase sempre começam a pensar mais seriamente em como os backups de disco para disco podem ser uma parte importante de sua estratégia de backup e de restauração — mesmo quando o armazenamento de fitas em um local externo continue a ser a sua principal opção para a recuperação de desastres.

Os desafios do backup em fita

A restauração a partir de fita leva muito tempo. Agora, o Exchange é tão fundamental para as organizações que os usuários e a gerência esperam que ele esteja disponível sempre. Quando há um problema sério, a maioria das organizações é pega de surpresa. Ninguém está preparado para ouvir que a restauração do banco de dados de 75 GB a partir de uma fita levará 8 horas — e isso não inclui o tempo gasto com a obtenção das fitas do local externo ou com a reinstalação do sistema operacional.

Além disso, ainda há o desafio da recuperação do banco de dados correto a partir da fita. Em 10 anos, desde o lançamento do Exchange, o custo do armazenamento em disco e de WANs caiu consideravelmente. Como resultado, muitas organizações podem adquirir métodos mais rápidos de backup e de restauração. Essas organizações podem aproveitar as tecnologias que permitem a elas obter uma continuidade operacional e a recuperação de desastres para a infra-estrutura do seu Exchange.

NÍVEL 2: CONTINUIDADE OPERACIONAL

A Continuidade Operacional é um conjunto de processos e de tecnologias criado para tornar a recuperação a mais rápida possível, minimizando o tempo de inatividade inesperado. A Continuidade Operacional oferece um RTO (Recovery Time Objective) e um RPO (Recovery Point Objective) aprimorados em fitas para a recuperação local. Ela se esforça para eliminar, onde for possível, o tempo gasto no retorno das fitas para a organização. Examine a Figura 2 para fazer uma comparação entre a Continuidade Operacional e o backup e a restauração, além da recuperação de desastres.

Figura 2** Continuidade da recuperação **(Clique na imagem para aumentar a exibição)

Esse diagrama ilustra a seqüência da recuperação e da disponibilidade, desde o lento e barato, no canto inferior esquerdo, até o rápido e caro, no canto superior direito, com uma transição deliberadamente difusa entre a continuidade operacional e as soluções de recuperação de desastres.

O gráfico lhe dá uma idéia das vantagens e desvantagens de custo, de tempo de recuperação e de disponibilidade nessas abordagens. Neste artigo, farei uma distinção clara entre os processos de continuidade local e de recuperação de desastres. A recuperação de desastres é sempre vista como remota, com o envio de dados para um local externo como o principal objetivo. A distância introduz desafios adicionais e, normalmente, é muito mais cara, mas a recuperação de desastres está relacionada à continuidade de negócios após eventos catastróficos. Falarei mais sobre isso em instantes.

Um pouco de história

Como o Exchange se tornou uma parte vital da infra-estrutura e, à medida que mais informações são armazenadas em seus bancos de dados, ficou claro que os tempos de backup e de restauração precisavam ser reduzidos. Trabalhando com a Microsoft, algumas das grandes organizações chegaram a uma abordagem que oferecia um retorno bastante aperfeiçoado para operações parciais. Se uma organização pudesse receber emails do mundo externo e enviar emails para ele, seria como se nada tivesse acontecido. Afinal de contas, a aparência é importante.

Para implementar essa restauração do tipo "sinal de linha" para o Exchange, um novo banco de dados vazio foi colocado no lugar do danificado. O Exchange e o Active Directory® criaram, então, novas caixas de correio com as permissões apropriadas, e os usuários eram capazes de enviar e de receber. Quando as fitas de backup foram obtidas e os dados recuperados, eles poderiam ser montados administrativamente. O administrador do Exchange mesclaria então as caixas de correio restauradas às caixas de correio de "sinal de linha". As caixas de correio poderiam ser priorizadas conforme a necessidade. Embora fosse um aperfeiçoamento, esse era um processo complexo e muito demorado que originalmente usava o EXMERGE e que foi adaptado aos grupos de armazenamento de recuperação. Entretanto, devemos notar que a restauração completa dos dados após um cenário de recuperação "sinal de linha" pode ser uma tarefa árdua e complicada (especialmente quando podemos ter até 50 grupos de armazenamento no Exchange 2007). Se você considerar a implementação de um cenário de recuperação "sinal de linha", tenha o cuidado de verificar se todas as vantagens valem o esforço.

Serviços de Cópia de Sombra de Volume

Para aproveitar os discos mais baratos e remover a sobrecarga de processador dos servidores Exchange de produção, foi desenvolvida uma nova API de backup para o Microsoft® Windows Server® 2003 e para o Exchange. O serviço VSS (Cópia de Sombra de Volume) foi criado para fazer cópias consistentes do estado atual dos dados. Esses instantâneos são cópias somente leitura rápidas dos dados do Exchange que incluem sucessivamente somente os dados alterados. As cópias normalmente apontam para outro servidor com espaço em disco disponível ou para uma SAN (Rede de Área de Armazenamento). Diversos instantâneos podem ser mantidos, com backups feitos em fita. Como resultado, o servidor Exchange de produção não precisa mais sofrer um impacto em seu desempenho por causa do software de backup e da sobrecarga da cópia para fita.

Existem diversas vantagens em usar o VSS para a proteção dos dados do Exchange. Primeiro, o seu servidor Exchange não sofrerá mais quedas de desempenho causadas por operações de backup em fita. Embora o backup em fita ainda seja necessário, ele poderá usar a cópia dos dados do Exchange, não causando impacto no desempenho do usuário. Segundo, é possível capturar instantâneos com mais freqüência do que um por noite. E, como bônus, você pode manter vários instantâneos no servidor secundário ou em outro armazenamento local.

Existem alguns produtos de terceiros no mercado que aproveitam os recursos de instantâneo do VSS. Alguns simplesmente reduzem o tempo necessário para o backup e a restauração dos bancos de dados do Exchange, enquanto que outros adicionam recursos como uma recuperação mais granular do que a nativa do Exchange, para que você possa restaurar até o nível das caixas de correio. Embora ninguém goste de backups brick, as pessoas querem ser capazes de restaurar pastas específicas ou até mesmo mensagens.

Tecnologias de replicação

O failover do Exchange mediado por software é uma opção oferecida por alguns fornecedores de replicação. Ele faz com que um servidor Exchange em espera seja disponibilizado e, em seguida, informa ao Active Directory que todas as caixas de correio dos usuários foram movidas. Existem duas formas de se fazer isso e ambas requerem algumas personalizações nos ambientes do Exchange e do Windows. Uma envolve alguns truques com o seu DNS para que o servidor em espera assuma o nome e o endereço IP do servidor que falhou. Essa opção tem a vantagem de ser mais fácil do ponto de vista das estações de trabalho clientes, já que o Outlook® acha que ainda está usando o mesmo servidor.

A segunda opção usa um servidor em espera que esteja executando o Exchange e que mantém cópias do banco de dados, mas sem nada montado. No caso de uma falha, o servidor em espera informa o Active Directory que todas as caixas de correio dos usuários foram movidas para ele. Em seguida, um script é executado, ou uma Diretiva de Grupo é distribuída, dizendo aos clientes que eles estão em um servidor de email diferente. O Outlook 2007 reconhece o Active Directory, o que facilita o processo, já que ele descobrirá automaticamente esses mapeamentos por conta própria.

Cluster local com MSCS

O ponto mais alto da seqüência de disponibilidade é o MSCS (Microsoft Cluster Services); o Exchange é um aplicativo que reconhece clusters. O cluster compartilha informações entre dois ou mais computadores para que, quando um deles falhar, os outros possam assumir o controle. Hoje, a maioria dos clusters do Exchange possui dois ou quatro nós, embora até oito nós possam ser usados. Um dos nós será sempre designado como passivo — operacional com o Windows Server em execução e com o Exchange Server instalado, mas sem caixas de correio ativas. Era possível haver um cluster de dois nós ativo/ativo no Exchange 2003, mas, devido às cargas de desempenho, isso não é mais recomendado e não será suportado no Exchange 2007.

Assim como o esquema de clusters do Exchange 2003, os clusters do Exchange 2007 que incluem um nó passivo ainda poderão usar uma única matriz de armazenamento compartilhada. Embora as matrizes de armazenamento de cluster normalmente tenham alguns recursos de redundância para resistirem a muitos tipos de falhas, ainda assim elas oferecem somente uma cópia dos dados, deixando uma janela de vulnerabilidade aberta. É por isso que esses agrupamentos são chamados de SCC (cluster de cópia única), para podermos distingui-los da próxima geração em proteção de dados, que chegará com o MCC (cluster de várias cópias) do Exchange 2007. Discutiremos os MCCs mais adiante, quando examinarmos a recuperação de desastres.

Replicação contínua local

A LCR (Replicação contínua local) é um novo recurso do Exchange 2007 que oferece uma forma aperfeiçoada de manter uma segunda cópia dos bancos de dados e dos logs de transação do Exchange no mesmo servidor. Ela adiciona uma camada de redundância à prática recomendada de termos o banco de dados do Exchange em um RAID e o log de transações em outro: a LCR possibilita o armazenamento de uma segunda cópia dos logs na matriz que contém a cópia principal do banco de dados e, então, armazena uma segunda cópia do banco de dados na matriz que contém a cópia principal dos logs (consulte a Figura 3). Se tanto o controlador RAID como a matriz falharem, você ainda terá o seu banco de dados e os logs de transação na outra matriz. Dessa forma, você poderá continuar a operar — embora um pouco nervoso e com alguma degradação no desempenho — até ser capaz de recriar a matriz que falhou.

Figura 3** Configurando a LCR **

A LCR é uma solução de continuidade operacional local, não uma solução de backup e, portanto, você ainda precisa de uma estratégia de backup completo. Com a LCR, também há um impacto no desempenho, já que o seu servidor fará duas cópias do banco de dados e dos logs de transação. Além disso, na implementação do Exchange 2007, existem algumas limitações que tornarão a LCR mais adequada somente a organizações menores, já que ela só oferece suporte a um banco de dados em um grupo de armazenamento e a um banco de dados de pastas públicas na organização.

O failover com uma recuperação de LCR não é instantâneo — um profissional de TI experiente terá de executar scripts para ter o Exchange de volta. O processo exige a execução de comandos do Shell de Gerenciamento do Exchange, executados fora do console de gerenciamento do Exchange.

Onde o Exchange Server 2003 Enterprise Edition permitia que uma organização executasse até 20 bancos de dados do Exchange (quatro grupos de armazenamento com até cinco bancos de dados cada), o Exchange 2007 Enterprise Edition permite até 50 grupos de armazenamento, cada um com seu próprio banco de dados. Os logs de transação também foram reduzidos dos arquivos de 5 MB do Exchange 2003 para arquivos de 1 MB no Exchange 2007. Ambas as alterações foram feitas para oferecerem suporte à LCR — e à CCR (Replicação contínua em cluster), que se tornará relevante dentro de algum tempo.

As pequenas e médias empresas usarão a LCR para oferecerem uma proteção maior de dados para suas operações com o Exchange. A LCR é fácil de implementar mas ainda envolve a intervenção manual. Como uma solução mesmo servidor/disco local, a LCR é somente a primeira etapa em direção à continuidade operacional aperfeiçoada. Embora ela ofereça proteção contra falhas de um RAID e de controlador RAID, várias panes de disco ou falhas de controlador RAID simultâneas são relativamente raras. Na maior parte do tempo, os cenários de falha envolvem a queda de todo o servidor, o que nos leva à próxima etapa da proteção do Exchange.

A replicação local fora do host feita por terceiros

Para enriquecer os recursos de recuperação do Exchange, outros fornecedores desenvolveram produtos que aproveitam a replicação "fora do host" usando os arquivos de log do Exchange para manter uma cópia em espera do banco de dados do Exchange em outra máquina. Neste caso, a solução de proteção de dados ou arquivamento executa um backup completo ESE do Exchange em um computador diferente e, em seguida, extrai os logs de transação assim que o Exchange os fecha. Ela insere essas transações em sua cópia do banco de dados do Exchange para que esteja sempre atualizada. Como já observei, esses logs são relativamente pequenos (de 5 MB no Exchange 2003 e de 1 MB no Exchange 2007) e, portanto, assim que o backup completo é concluído, a cópia desses arquivos de log para o servidor fora do host quase não representará sobrecarga para o servidor Exchange.

NÍVEL 3: RECUPERAÇÃO DE DESASTRES E ALTA DISPONIBILIDADE

A recuperação de desastres é a capacidade de voltar a operar caso o principal data center se torne indisponível. O Exchange merece uma recuperação de desastres efetiva porque as funções de email e de calendário são a alma de muitas organizações de hoje.

Algumas empresas imaginam que seus tradicionais backups em fita armazenados em um local externo são uma forma de recuperação de desastres, mas se o seu data center for destruído pelo fogo ou por uma enchente, uma van trazendo alguns conjuntos de fitas não terá utilidade alguma. A recuperação de desastres envolve, necessariamente, a mudança não só de seus dados para um local externo, como também da tecnologia e dos processos necessários para que o aplicativo volte a funcionar. Para ser eficiente, a recuperação de desastres se baseia na separação dos sistemas principal e secundário por alguma distância. A distância que deve haver entre os locais depende da magnitude do desastre com que você está preocupado. Se você se preocupa com fogo, talvez outro prédio do seu campus seja remoto o suficiente. Entretanto, os desastres de infra-estrutura que envolvem trens ou aeronaves poderiam afetar um raio de dois quilômetros ou mais. Muitos desastres são regionais: enchentes, tempestades de gelo, terremotos e até falta de energia elétrica. As comunicações podem sofrer com suas próprias calamidades — qualquer coisa, desde uma escavadeira que destrua o link com o seu provedor até ataques de negação de serviço e ataques de negação de serviço da Internet visando o comércio em geral.

De forma prática, se a sua organização já tiver mais de um local com equipes de TI, um deles poderá atender aos seus critérios para a continuidade operacional remota, dados os tipos de desastres dos quais você está se defendendo. Usar as suas próprias instalações e pessoal será bem mais barato do que contratar um provedor de recuperação de desastres ou do que alugar um espaço em um novo local.

Por fim, a recuperação de desastres também está relacionada à percepção: passar aos clientes a confiança de que você ainda está funcionando. As pessoas são compreensivas quando um desastre atinge uma cidade ou uma área, mas se a sua empresa não voltar a funcionar dentro de dois dias ou de uma semana, existe a possibilidade de que os clientes e os fornecedores acreditem no pior; muitas empresas vão à falência por esse motivo. Para o cliente, você deve passar a idéia de que está se recuperando, para que eles tenham a certeza de que o seu negócio vai continuar operando. Os clientes terão idéias diferentes sobre uma recuperação em tempo hábil: é compreensível que eles sejam menos pacientes com problemas em suas empresas de serviços financeiros do que com, digamos, problemas em seus fornecedores de móveis de escritório.

Exigência da recuperação de desastres

Ser capaz de fazer o Exchange funcionar novamente após um desastre requer a replicação de seus dados para o site secundário e o uso da tecnologia de replicação preparada para apresentar os dados para um outro servidor Exchange que possa usá-los e, em seguida, notificar os clientes do Outlook que suas caixas de correio foram movidas.

O Exchange é um aplicativo exigente em relação à replicação, particularmente se ela for feita a uma distância muito longa. Como um banco de dados verdadeiramente transacional, a ordem de cada gravação é extremamente importante. Para complicar ainda mais o desafio, o protocolo de transporte usado pelo Exchange para comunicar todas as transações e informações do sistema entre servidores é o SMTP, protocolo que usa intensivamente a largura de banda. Além disso, com clusters do Exchange, é preciso manter uma pulsação entre os sistemas a cada 500 milissegundos. Se o nó secundário não receber essa pulsação, poderá disparar um failover.

As complexidades de gerenciamento de tais desafios pode ser o motivo pelo qual a Microsoft só esteja entrando nesse espaço agora, com o Exchange 2007. Na ausência da Microsoft, diversas soluções de terceiros têm sido desenvolvidas para a replicação de dados do Exchange, tanto na forma baseada em host como na baseada em matriz.

Os fornecedores perceberam que poderiam estender um cluster dispersando os nós por locais diferentes; chamamos isso de um cluster estendido. Hoje, a forma mais comum de implementar os clusters estendidos é por meio de produtos de replicação de dados de uso geral feitos por terceiros ou por aqueles especificamente voltados para a extensão de um nó do Exchange. Você pode fazer isso com o MSCS, mas o requisito de sub-rede é desafiador em uma WAN. Os clusters e as complexidades de provisionar conectividade confiável e em grande largura de banda a data centers remotos aumentam, compreensivelmente, o custo e os requisitos da equipe para criar, manter e testar periodicamente os sistemas de recuperação de desastres.

Replicação contínua em cluster

A Microsoft estende seu suporte a cluster com a replicação contínua em cluster no Exchange 2007. A CCR estende a capacidade da LCR de manter duas cópias de um banco de dados e dos logs de transação do Exchange para implementar a mesma idéia em dois nós de cluster. A recuperação de desastres implica em separação geográfica dos sistemas principal e secundário, e os clusters de várias cópias (MCC) não serão capazes de se estender por distâncias significativas até que o Windows Server 2008, cujo codinome era "Longhorn", possibilite a utilização de clusters estendidos.

A tecnologia que permite que nós MCC tenham cópias separadas dos dados chama-se conjunto de nós principais (MNS) e se refere ao processo de seleção conduzido por dois ou mais nós, para determinar qual deles manterá a cópia de produção dos dados. Quando houver uma falha, os nós restantes farão uma nova seleção para determinar quem assumirá o papel de novo servidor principal de processamento/dados. Quem oferece suporte a essa democracia técnica é a CCR, garantindo que cada nó tenha um banco de dados atualizado. Os clusters do Exchange 2007 que utilizarem a CCR ficarão limitados a dois nós.

Em cenários maiores, os servidores Exchange normalmente configuram o disco de sistema local no próprio servidor e se conectam ao banco de dados do Exchange por meio de uma SAN, usando SCSI, fibra ou matrizes de disco iSCSI. Com um cluster MCC/MNS, uma questão interessante é se o armazenamento avançado do Exchange voltará a usar matrizes RAID locais para cada nó. Se a finalidade de um cluster MNS é permitir que cada nó tenha seu próprio armazenamento separado, ainda assim faz sentido apontar cada nó para uma SAN, cujo principal propósito é oferecer armazenamento comum?

Um cenário provavelmente intermediário do MCC/MNS seria ter um nó principal com armazenamento na SAN e um nó de cluster secundário com discos locais ou com uma SAN iSCSI de menor custo. Esse nó secundário poderia ser remoto em relação ao data center principal, em um local sem uma infra-estrutura de SAN.

A despeito de como isso acontece, o fato de o MCC usar MNS e CCR é uma outra etapa na hierarquia de redundância e de disponibilidade avançada, já que vários computadores estarão preparados para o failover e os dados serão replicados em elementos de armazenamento separados. Entretanto, isso ainda está totalmente confinado em um único data center até o lançamento do Windows Server 2008. O Windows Server 2008 oferecerá suporte nativo aos clusters estendidos, permitindo que os nós de um cluster MNS estejam geograficamente separados pela distância que quiserem — desde que a latência da rede entre os nós seja menor do que 500 ms. Até lá (e depois), a tecnologia de cluster de terceiros pode ser usada sobre o MNS e a CCR para oferecer a separação geográfica necessária para os clusters estendidos como uma solução de recuperação de desastres eficiente.

A utilização de clusters é o ponto mais alto da seqüência de recuperação de desastres, e a CCR está adequadamente posicionada como um recurso de grande disponibilidade do Exchange. E mesmo que a combinação represente uma sobrecarga de custos e de pessoal, ela promete ser a melhor solução para clientes que desejam operar um ambiente Microsoft homogêneo.

Continuidade operacional remota de terceiros

Não há dúvidas de que a solução da Microsoft e as extensões de terceiros ocuparão o lugar mais alto na seqüência de recuperação quando essa combinação estiver disponível. O failover automático em segundos — melhor é impossível. Ainda assim, nem todas as empresas precisam desse nível de disponibilidade e de continuidade de negócios, nem podem investir as centenas de milhares de dólares necessários para obtê-lo. Para muitas empresas, uma solução confiável que restaure totalmente o Exchange em minutos oferecerá toda a continuidade operacional necessária.

Como um exemplo, a Mimosa Systems, Inc. estende a continuidade operacional em um único data center para a continuidade remota. No local remoto, a recuperação de desastres da Mimosa mantém uma cópia do Exchange, a mantém atualizada com os logs de transação enviados pelo servidor Exchange principal e está sempre pronta para disponibilizar essa cópia para o servidor Exchange em espera. O servidor Exchange remoto usa hardware de servidor padrão e, assim como na implementação de um data center único, você o mantém aquecido e sempre pronto para ser ativado em caso de desastre. Se houver um desastre, um operador no site remoto inicia o failover e o executa, incluindo a montagem dos arquivos do banco de dados em espera, remapeando as caixas de correio e os perfis do Outlook. Entretanto, devemos notar que tais soluções de terceiros estão sujeitas aos limites de suporte definidos no artigo da Base de Dados de Conhecimento "Diretiva de suporte da Microsoft para produtos de terceiros que modificam ou extraem conteúdo de banco de dados do Exchange".

Conclusão

A proteção de dados do Exchange está disponível como uma seqüência de tecnologias e procedimentos que podem ser agrupados em três níveis, com base no custo e nos recursos. Quando começar a pensar sobre seus requisitos para a proteção de dados do Exchange, você deverá considerar quanto tempo de inatividade será tolerado pelas pessoas atingidas. Um desempenho maior e uma recuperação mais rápida custam mais, sendo que as opções avançadas giram em torno dos seis dígitos. Existem soluções mais baratas que se aproximam dos mais altos níveis de disponibilidade, mas não chegam a alcançá-los. As opções que você fizer deverão refletir as necessidades reais da sua organização.

Service Pack 1 para Exchange 2007

Ainda em versão beta, o Service Pack 1 (SP1) para o Exchange 2007 deve incluir alguns recursos que estão fazendo falta aos administradores, incluindo aperfeiçoamentos no OWA, recursos adicionais de GUI no Console e muito mais.

Os administradores que planejam soluções de recuperação se interessarão particularmente no fato de que o Exchange 2007 SP1 também inclui uma solução de disponibilidade de terceiros para complementar a LCR e a CCR: a replicação contínua secundária (SCR). Ela é uma abordagem intermediária e a Microsoft visa a uma capacidade de recuperação maior, sem a complexidade da "alta disponibilidade completa".

A SCR permitirá a replicação do banco de dados e dos logs de transação do Exchange para um servidor Exchange diferente daquele que normalmente armazena as suas caixas de correio. O destino da SCR pode ser local ou remoto, e pode ser um servidor Exchange em espera ou um cluster. No entanto, a SCR não requer um cluster em ambos os locais e é diferente da CCR, já que o destino é um ambiente em espera e o failover é um processo manual. Observe que você ainda precisará fazer aquela primeira cópia grande pela rede — essencialmente, um backup completo. Talvez você precise fazer essa replicação grande de tempos em tempos e deve ficar atento ao impacto causado na rede, assim como acontece com a CCR e as soluções de terceiros. Estou esperando uma adoção significativa tanto da SCR como da CCR e de produtos complementares que ofereçam recursos similares e, algumas vezes, melhores.

Lee Benjamin tem uma empresa chamada ExchangeGuy Consulting Services, onde trabalha diretamente com clientes e presta consultoria a parceiros da Microsoft. Lee é presidente do maior grupo de usuários de Exchange do mundo, o ExchangeServerBoston, e é diretor do BostonUserGroups. Ele também é MVP para Exchange, Microsoft Certified Trainer e, com freqüência, faz palestras em conferências do setor.

© 2008 Microsoft Corporation e CMP Media, LLC. Todos os direitos reservados. A reprodução parcial ou completa sem autorização é proibida..