Infra - Exchange Server
Alta Disponibilidade no Exchange Server 2007 - Parte III
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).
por Anderson PatricioEsta é 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.
- Migrando e removendo o Exchange 2007 para Exchange 2010Exchange Server
- Migrando (e removendo) o Exchange 2007 para Exchange 2010Exchange Server
- Foto no Outlook 2010Exchange Server
- Exchange UM Test PhoneExchange Server
- Integrando o OCS ao Exchange UMOCS / LCS