Alta Disponibilidade no Exchange
Server 2007 - Parte III
Por Anderson Patricio
Esta
é a terceira parte da nossa série
de artigos sobre Alta
Disponibilidade no Exchange
Server 2007, iremos abordar um
dos tipos de alta
disponibilidade da função de Mailbox que é o
CCR (Cluster Continuous Replication)
através desta funcionalidade
conseguimos ter um cluster de
Exchange com as bases e logs
replicados em um outro servidor,
sem a necessidade de utilizarmos
um storage. No Exchange Server
2007 temos dois tipos de Cluster
SCC (Single Copy Cluster) e o
CCR, no primeiro caso temos
exatamente o que existe hoje com
as soluções de cluster para
Exchange 2003, um disco no storage
que é compartilhado por duas
máquinas, o nó ativo é o
responsável pelos discos e
consequentemente pela base e
recursos do cluster. No cenário
com CCR existe um nó ativo e
um passivo, o passivo recebe a
replicação de logs do ativo e
estes logs são aplicados a base
do passivo, com os dados sendo
replicados para os discos
internos sem a figura do storage.
Visão Geral
O
CCR (Cluster Continuous
Replication) é uma
funcionalidade que permite alta
disponibilidade do Exchange
Server 2007, ele faz uma cópia
assíncrona dos logs do servidor
ativo para o servidor passivo,
estes logs são verificados e
aplicados na base que está no nó
passivo, e a outra vantagem é
que ele utiliza os recursos de
alta disponibilidade da
infra-estrutura do Windows
Server 2003 que é o serviço de
Cluster.
A
arquitetura do CCR é para prover
alta disponibilidade para os
servidores Mailbox Servers do
Exchange Server 2007, lembrando
que quando implementamos um CCR
as outras regras CAS e Hub
Transport não podem ser
instaladas na mesma máquina que
as soluções de alta
disponibilidade do Mailbox do
Exchange Server 2007.
Características
que valem ser ressaltadas:
-
Tempo de
backup e performance,
podemos usar soluções de
terceiros para fazerem
backup do nó passivo sem
degradar a performance do nó
ativo que está sendo
utilizado pelos usuários,
pela ferramenta do ntbackup
(streaming) não se pode
fazer tal operação;
-
Não é
necessário a dependência de
Storage devido a base ser
replicada em ambos os
servidores
-
O hardware
não precisa estar na HCL na
seção de Cluster
-
Pode ser
instalado geograficamente
disperso em dois datacenters
separados por kms de
distância
Podemos
resumir o funcionamento do CCR
da seguinte forma: quando
instalamos o nó secundário
(passivo) cada storage
group e sua(s) respectiva(s)
bases são copiadas do nó ativo
para o passivo, esta operação é
chamado "seeding" este é a base
para as futuras replicações. A
partir deste ponto toda a cópia
de logs do nó ativo para o
passivo, depois de concluídas
são aplicadas continuamente na
base do passivo. Uma
representação gráfica da solução
é mostrado abaixo:

No
Exchange Server 2007 temos os
logs de apenas 1MB, com isto a
base passiva é atualizada
continuamente, cada log criado é
copiado para o nó passivo, cada
cópia de log que chega no nó
passivo ele é verificado contra
corrupções e então aplicado a
base passiva. Quando acontece
uma falha no nó ativo o nó
passivo assume a operação não
impactando o usuário final.
Quando temos o CCR, a pasta de
logs do nó ativo é compartilhada
administrativamente, ou seja
recebe um $ no final, com o nome
do GUID do storage group, o nó
passivo se conecta neste
compartilhamento copia estes
arquivos de logs através de SMB
(Server Message Block).
Alguns
pontos interessantes sobre a
implementação de CCR:
Segurança
Os
dados são copiados via SMB,
sem criptografia, se
desejarmos uma segurança
maior podemos estar
habilitando IPSec entre as
máquinas.
Passivo
e Ativo quando ocorre
failover...
Na
hora da instalação são
instalados separadamente as
funções de ativo e passivo,
quando ocorre um failover é
necessário não precisamos
alterar nada neste processo?
Não, o Exchange Server trata
isto de forma automática a
direção da replicação é
alterada automaticamente sem
a necessidade de intervenção
administrativa.
Dados são
perdidos durante o failover?
Esta
é uma pergunta normal nas
comunidades Microsoft,
durante o processo de
failover temos a perda de
mensagens? A resposta é não,
temos como configurar
tamanho de mensagens e
período que o Hub Transport
fica aguardando para enviar
as mensagens, com isto não
existe perda de mensagens.
Tamanho
máximo das bases..
Algumas
considerações sobre o
tamanho máximo de uma base
no CCR:
-
Bases
rodando em servidores
sem replicação contínua,
o aconselhado é até
100GB
-
Bases
rodando em servidores
com replicação contínua
a placa de rede Giba o
limite aumenta para
200GB
Sistema
operacional..
Estamos
falando de cluster, ou seja,
obrigatório uso de Windows
Server 2003 Enterprise ou
DataCenter
Vamos
enumerar alguns pontos
importantes na implementação do
CCR no Exchange Server 2007:
-
Instalar o
hotfix 921181 em ambos os
nós do cluster, este hotfix
permite a utilização de um
share como quorum no modelo
MNS (Majority Node Set),
podemos baixá-lo através
deste link:
http://support.microsoft.com/kb/921181,
-
Criação de
um compartilhamento no Hub
Transport para ser utilizado
como Quorum desta solução
-
Configurar o
recurso de MNS Quorum no
cluster para o
compartilhamento feito no
Hub Transport
-
Implementar
os nós Ativo e Passivo
-
Configurar o
Hub Transport para ajustar a
entrega e tempo das
mensagens entre o Hub e o
Clustered Mailbox Server
Implementando o
share para ser utilizado como
Quorum no Hub Transport
O
nome deste recurso de criar um
compartilhamento e utilizar como
Quorum é chamado de File
Share witness e ele é um
melhoramento do MNS (Majority
Node Set) cluster
geograficamente dispersos. Mas o
interessante desta
funcionalidade é que permite que
um compartilhamento externo
determine o status de dois nós
de um cluster.
Lembrando
que o KB 921181 deve ser
executado em cada um dos nós do
cluster independente da
plataforma do sistema
operacional (x32, x64 ou ainda
Itanium) para que a
implementação de CCR funcione.
E
em qual máquina devemos
configurar o compartilhamento
para ser utilizado no CCR?
Qualquer máquina, mas a
Microsoft recomenda a utilização
de um servidor com a função de
Hub Transport, por dois motivos:
o administrador de Exchange tem
acesso por padrão a esta máquina
e pode ajudar na parte de
resolução de problemas e o outro
ponto é que no Hub Transport que
configuramos os tempos que uma
mensagem fica no aguardo do
failover de nós, com isto temos
um ponto centralizado de
informações de quorum e entrega
de mensagens.
-
Vamos criar
uma pasta chamada
MNS-Quorum no servidor
que está o Hub Transport
-
Vamos clicar
com o botão direito nesta
pasta, clicar na pasta
Sharing vamos deixar o
nome do compartilhamento de
MNS-Quorum, este nome
não é fixo pode ser qualquer
nome. Feito isto devemos
clicar em Permissions.

-
Share
Permissions. Devemos colocar
as permissões de
compartilhamento, devemos
dar permissão para a conta
que o serviço de cluster
usa, em nosso artigo estamos
colocando o administrador
para resolução de problemas
diversos e a conta que é
utilizado pelo serviço de
cluster (svc.cluster) ambas
com Full Control neste
compartilhamento. Devemos
clicar em OK.

-
Devemos ir
até a guia Security
vamos colocar também o
Administrator e a conta
responsável pelo serviço de
cluster com Full Control.
Feito isso clicamos em OK.

Configurando o serviço de
Cluster e configurando MNS
Quorum
Não
vamos entrar no mérito de boas
práticas de configuração do
Cluster, mas podemos encontrar
muitas informações sobre isto em
Best practices for installing
and upgrading cluster nodes,
vamos utilizar o seguinte
cenário para criação do cluster:

Onde
no primeiro cenário temos um
servidor de autenticação (Domain
Controller Srv-AD01) e dois nós
instalados com o Windows Server
Enterprise chamados srv-nodo01 e
srv-nodo02. Neste ponto já
configuramos o compartilhamento
no servidor srv-ad01 que é o Hub
Transport desta organização, e
vamos em frente com a criação do
serviço de cluster no primeiro
nó:
-
Efetuar
logon no primeiro nó do
cluster, em nosso exemplo
srv-nodo01
-
Ir em
Start, Program Files,
Administrative Tools
-
Clicar em
Cluster Administrator
-
A primeira
tela será de a mostrada na
figura abaixo devemos
selecionar Create new
cluster em Action
e clicar em OK

-
Welcome to
the new Cluster Wizard. Tela
inicial do assistente de
criação do cluster, devemos
clicar em Next.

-
Cluster name
and Domain. Devemos escolher
o domínio e o nome do
cluster, ele será o primeiro
recurso de nome deste novo
cluster. Feito as escolhas
devemos clicar em Next.

-
Select
Computer. Nome do nó onde
estamos instalando o
cluster, devemos clicar em
Next.

-
Analyzing
Configuration. Será feito
uma análise da máquina e
ambiente para validar se o
servidor está apto a criação
do Cluster, podemos ir
expandindo os aviso em
amarelo (Warning) para
termos mais informações.

-
Analyzing
Configuration. Verificando
os detalhes do aviso,
verificamos que ele não
encontrou um quorum em um
storage, isto ocorre porque
não temos e vamos utilizar o
MNS para isto, devemos
clicar em Next

-
IP Address.
Devemos definir o endereço
IP que será utilizado pelo
recurso virtual chamado
srv-cluster, devemos
preencher o endereço IP e
clicar em Next.

-
Cluster
Service Account. Aqui
devemos escolher uma conta
para rodar o serviço de
Cluster, neste artigo
estaremos utilizando um
usuário chamado svc.cluster.
Devemos clicar em Next.

-
Proposed
Cluster Configuration. Nos
será mostrado uma visão
geral do que definimos até
agora, neste ponto que
escolhemos qual será o tipo
de Quorum a ser utilizado,
devemos clicar no botão
Quorum..

-
Cluster
Configuration Quorum. Aqui é
que definimos o tipo de
quorum não físico e sim MNS,
devemos escolher Majority
Node Set e clicar em OK
e Next na próxima
tela.

-
Creating the
Cluster. Haverá uma nova
análise do cluster e
instalação dos serviços, a
tarefa completa, devemos
clicar em Next.

-
Completing
the New Server Cluster
Wizard. Cluster criado com
sucesso, devemos clicar em
Finish.

Com
o término da instalação, já
podemos visualizar a nossa rede
com mais uma máquina que é o
srv-cluster com o IP
192.168.0.210, ele foi o recurso
virtual que acabamos de criar
durante a configuração do
cluster. Abaixo já podemos
verificar que as máquinas do
cluster srv-nodo01 e srv-nodo02,
já possuem um novo servidor na
rede o srv-cluster, mas até este
ponto o nome e ip deste novo
servidor é respondido apenas
pelo nó srv-nodo01.

Adicionando o segundo nó ao
cluster...
Continuando
nosso processo, devemos
adicionar o segundo servidor srv-nodo02
ao cluster para que ambos possam
passar recursos entre si,
para tanto devemos efetuar os
seguintes passos:
-
Efetuar
logon no servidor srv-nodo01
-
Abrir o
Cluster Administrator
-
Clicar com o
botão direito em cima de Srv-nodo01
-
Expandir
New e clicar em Node

-
Tela inicial
do assistente de adição de
um segundo nó, devemos
clicar em Next.

-
Select
Computers. Devemos digitar o
nome do novo servidor e
clicar em Add depois
que o mesmo apareceu na
caixa em Selected
computes, feito isso
devemos clicar em Next.

-
Analyzing
Configuration. O assistente
do cluster irá fazer uma
análise do segundo nó após a
tarefa estar completa,
devemos clicar em Next

-
Cluster
Service Account. Como esta é
a segunda máquina, já temos
a conta do cluster já
configurada apenas
precisamos confirmar a senha
da conta de serviço e clicar
em Next.

-
Proposed
Cluster Configuration. Nos
será apresentando um sumário
da implementação do segundo
nó que está prestes a
começar, para tanto devemos
clicar em Next.

-
Adding Nodes
to the Cluster. Devemos
esperar o fim das tarefas e
clicar em Next.

-
Tela final
do assistente, agora já
possuímos as duas máquinas
no cluster (srv-nodo01 e srv-nodo02).

-
No Cluster
Administrator já podemos
verificar as duas máquinas
participando do cluster.

Configurando o MNS para utilizar
o compartilhamento que criamos
no Hub Transport..
Agora
que já definimos o
compartilhamento e instalamos o
serviço de cluster em ambos os
nós, devemos ajustar o MNS para
utilizar o compartilhamento
previamente criado.
Esta
definição é feita por linha de
comando através da seguinte
sintaxe:
cluster res "majority node set"
/priv MNSFileShare=\\srv-ad01\MNS-Quorum
E
para visualizarmos a alteração e
a atual propriedade, devemos
rodar:
cluster res "Majority node set"
/priv

Implementação do CCR (Cluster Continuous
Replication) no nó ativo do
Cluster
Vamos
começar pelo nó ativo, agora que
já temos todos os pré-requisitos
em ambas as máquinas do Cluster,
devemos efetuar logon na máquina
que será o nó ativo e devemos
colocar a mídia do Exchange
Server e executar o setup, os
passos rotineiros de qualquer
instalação serão apenas
descritos aqui, vamos nos focar
somente nas mudanças do setup em
relação a configuração do
cluster, como segue:
-
Na tela
inicial do setup, onde
devemos instalar os
pré-requisitos da seção
Install tais como: .NET
Framework 2.0, MMC 3.0 e
Windows PowerShell, com
todos pré-requisitos
instalados devemos clicar em
Step 4: Install Microsoft
Exchange.

-
Introduction.
Tela inicial do assistente
de instalação devemos clicar
em Next.
-
License
Agreement. Contrato de
licença do produto, devemos
clicar em I accept the
terms in the license
agreement e clicar em
Next.
-
Error
Reporting. Devemos escolher
entre enviar os erros para a
Microsoft relacionados ao
produto, depois da escolha
feita, devemos clicar em
Next.
-
Installation
Type. Como estaremos criando
um cluster CCR no Exchange
Server 2007, devemos clicar
em Custom Exchange Server
Installation, escolher o
caminho da instalação e
clicar em Next.

-
Server Role
Selection. Devemos
selecionar Active
Clustered Mailbox Role,
podemos verificar que todas
opções são desmarcadas feito
a escolha devemos clicar em
Next.

-
Exchange
Organization. Caso seja o
primeiro servidor da
organização será solicitado
o nome da nova organização,
caso não esta tela não será
solicitada.
-
Cluster
Settings. Nesta tela que
escolhemos qual será o tipo
de cluster que o Exchange
Server 2007 desempenhará,
devemos clicar em Cluster
Continuous Replication e
devemos preencher nome do
servidor e endereço IP, a
partir deste ponto será
criado um CMS (Clustered
Mailbox Server) no Cluster
Administrator. Em nosso
artigo os dados serão:
Nome do CMS: srv-exchange
Endereço IP: 192.168.0.215.

-
Client
Settings. Nesta opção
devemos escolher se devemos
escolher se este servidor
terá suporte a Public
Folders, caso exista Outlook
2003 ou versões anteriores
como cliente do Exchange
Server, devemos clicar em
Yes do contrário em
No. Clique em Next.
-
Readiness
Check. Será feito uma
validação de pré-requisitos
ou ainda hotfixes
necessários para a
instalação correta do
produto, devemos prestar
atenção em todos detalhes
mostrados nesta etapa, caso
não tenha nenhuma pendência
devemos clicar em Install.
-
Completion.
Tela final do instalação,
podemos verificar que todos
os componentes foram
instalados com sucesso
inclusive o CMS (Clustered
Mailbox Server), devemos
clicar em Finish.

Com
isto terminamos a instalação do
Exchange no nó ativo, nossos
próximos passos serão vistos na
parte IV desta série de artigos,
onde faremos testes de
movimentação, cmdlets do
Exchange Management Shell e
instalação do segundo nó.
Conclusão
Neste
terceiro artigo da série sobre
alta disponibilidade do Exchange
Server 2007, desmistificamos em
parte o CCR
(Cluster Continuous
Replication) onde as empresas
podem implementar um Cluster de
Exchange sem a necessidade de
storage para replicar os dados,
através de um conceito utilizado
em banco de dados SQL que é o
Log Shipping, verificamos como
criar o Cluster entre os dois
servidores, configuração do
compartilhamento no Hub
Transport e instalação do
Exchange Server no nó ativo. No
próximo artigo estaremos
mostrando como implementar o nó
passivo, verificação do CCR
através do Exchange Management
Shell e Exchange Management
Console.
Anderson
Patricio
http://www.andersonpatricio.org