Novos recursos de alta disponibilidade do Exchange 2007 SP1

 

Aplica-se a: Exchange Server 2007 SP1

Tópico modificado em: 2009-03-18

O Microsoft Exchange Server 2007 Service Pack 1 (SP1) apresenta vários recursos novos de alta disponibilidade, bem como aprimoramentos dos recursos de alta disponibilidade existentes. Os recursos novos e aprimorados estendem os cenários nos quais você pode obter dados e disponibilidade de serviço para as funções de servidor Exchange 2007. Os novos cenários permitem que as organizações separem os cenários de alta disponibilidade dos cenários de resiliência de site e permitem também implantar configurações personalizadas para as necessidades específicas da organização em cada área.

Os novos recursos de alta disponibilidade e aprimoramentos dos recursos já existentes estão disponíveis no Exchange 2007 SP1:

• Replicação contínua em espera (SCR)

• Suporte para os recursos a seguir no Windows Server 2008:

  • Vários clusters de failover de sub-rede

  • DHCP (Dynamic Host Configuration Protocol) IPv4 (Protocolo Internet versão 4)

  • IPv6

  • Exchange e configuração de rede de cluster de failover

  • Novos modelos de quorum (testemunha de compartilhamento de arquivo e disco)

• Replicação contínua (propagação e remessa de log) em uma rede de cluster redundante de um ambiente de replicação contínua em cluster (CCR)

• Aprimoramentos de relatório e de monitoramento

• Aprimoramentos de desempenho

• Aprimoramentos do dumpster de transporte

• Aprimoramentos do Console de Gerenciamento do Exchange

Todos esses recursos são descritos posteriormente neste tópico, acompanhados de links para a documentação que explica como planejar, implantar e gerenciar esses recursos. A tabela a seguir resume o suporte do Exchange 2007 para os recursos de cluster de failover no Windows Server 2003 e no Windows Server 2008.

Recursos de cluster de failover aceitos pelo Exchange 2007 SP1

Windows Server 2003	Windows Server 2008	Suporte do Exchange 2007
Disco de quorum compartilhado	Sem Principais: Quorum Somente de Disco	Aceito, mas não recomendado no Windows Server 2008.
Quorum de Conjunto de Nós Principais	Quorum de Nós Principais	Com suporte.
Quorum do Conjunto de Nós Principais com Testemunha de Compartilhamento de Arquivo	Quorum de Compartilhamento de Arquivos e Nós Principais	Aceito, e recomendado para CCR.
Quorum de disco compartilhado ou quorum do Conjunto de Nós Principais com testemunha de compartilhamento de arquivo	Quorum de Nós e Discos Principais	Aceito, e recomendado para SCCs (clusters de cópia única).
clusters com 8 nós	clusters com 16 nós	clusters com 8 nós apenas para SCCs. (CCR é um cluster com 2 nós.)
recursos de endereço IPv4	recursos de endereços IPv6 e IPv4	Aceito; entretanto, o encapsulamento IPv6 sobre IPv4 é aceito pelo Windows Server 2008, mas não pelo Exchange 2007.
Endereços IPv4 estáticos	Endereços DHCP-IPv4	Aceito, mas não recomendado para ambientes de produção.
Sub-rede única requerida para cada rede de cluster	Várias sub-redes aceitas em redes de cluster	Aceito para SCC e CCR.

Replicação Contínua em Espera

A SCR é um novo recurso apresentado no Exchange 2007 SP1. A SCR estende os recursos de replicação contínua existentes no RTM do Exchange 2007 e permite novos cenários de disponibilidade de dados para servidores de Caixa de Correio do Exchange 2007. A SCR usa o mesmo envio de logs e tecnologia de repetição usado pela replicação contínua local (LCR) e pela CCR para fornecer configurações e opções de implantação adicionais. SCR é semelhante a LCR e CCR, mas tem suas próprias características exclusivas:

• A SCR aceita vários destinos por grupo de armazenamento. LCR e CCR aceitam somente um destino de replicação por grupo de armazenamento (a cópia passiva).

• A SCR permite que um administrador especifique um intervalo de replicação. Isso é útil em vários cenários. Por exemplo, no caso de um failover com perdas do Nó A para o Nó B, se os arquivos de log perdidos forem repetidos no Nó M remoto, este poderá precisar ser propagado. No entanto, se os logs forem copiados, mas não repetidos, eles poderão ser excluídos, e novos arquivos de log poderão ser copiados e depois repetidos. Nesse caso, a cópia não precisará ser propagada novamente no Nó M.

• Ao contrário da CCR e da LCR, não é possível fazer backup de uma cópia da SCR. Ao usar a SCR, os cabeçalhos de banco de dados das cópias da SCR são atualizados, e os arquivos de log truncados, quando são feitos os backups do grupo de armazenamento de origem.

A SCR permite que você use replicação contínua para replicar os dados de um servidor de Caixa de Correio autônomo ou em cluster em um ambiente SCC ou CCR.

O processo de ativação das cópias dos dados do servidor de Caixa de Correio, criadas e mantidas pela SCR, é manual e foi criado para ser usado quando ocorrer uma falha significativa (e não para uso em interrupções simples recuperadas com um reinício ou por outro meio rápido). Você pode ativar um destino de SCR usando a portabilidade de banco de dados, a opção de recuperação do servidor (Setup /m:RecoverServer) ou, se o servidor de Caixa de Correio estiver em cluster, usando a opção de recuperação do servidor de caixas de correio em cluster (Setup /RecoverCMS). A opção escolhida terá como base a sua configuração e o tipo de falha ocorrida.

Para obter mais informações sobre SCR, consulte Replicação Contínua Em Espera.

Suporte para Windows Server 2008

O Windows Server 2008 inclui novos recursos de alta disponibilidade que são aceitos pelo Exchange 2007 SP1. No Windows Server 2008, os aprimoramentos para clusters de failover (conhecidos como clusters de servidor no Windows Server 2003 e versões anteriores) destinam-se a simplificar os clusters, ajudando-os a se tornarem mais seguros e a aprimorar a estabilidade do cluster. Além disso, a instalação e o gerenciamento do cluster tornaram-se mais fáceis e a segurança do cluster subjacente, a rede e os componentes de armazenamento foram aprimorados. Para obter uma lista completa dos aprimoramentos em clusters de failover, consulte Cluster de Failover com Windows Server 2008.

Além de aceitar o Windows Server 2008 como uma plataforma de sistema operacional, o Exchange 2007 SP1 também oferece suporte para os seguintes recursos de cluster de failover do Windows Server 2008. O suporte para esses recursos também foi integrado à instalação do Exchange 2007 para a versão de linha de comando (Setup.com) e para a versão de GUI (Setup.exe, também conhecida como Assistente de Instalação do Exchange Server 2007).

Suporte para vários clusters de failover de sub-rede

O cluster de failover do Windows Server 2008 introduz novos recursos de rede que são a principal mudança no funcionamento anterior de clusters herdados. Por exemplo, os clusters de failover do Windows Server 2008 introduzem suporte para várias sub-redes. Ao executar em um cluster de failover do Windows Server 2008, o Exchange 2007 inclui suporte para clusters dispersos geograficamente, para failover entre duas sub-redes. Esse suporte inclui ambos os SCCs, assim como os servidores de caixas de correio em um ambiente de CCR (replicação contínua em cluster).

Começando com o cluster de failover do Windows Server 2008 nós de cluster individuais agora podem ser colocados em redes roteadas separadas. Isso exige que os recursos dependentes de recursos de endereço IP (por exemplo, Nome da Rede) implementem uma lógica OR, já que é improvável que cada nó do cluster tenha uma conexão local direta com cada rede conhecida do cluster. Isso facilita que os recursos Endereço IP e Nome da Rede sejam colocados online quando serviços ou aplicativos forem alternados para nós remotos devido a falhas.

Importante

Todos os nós em um ambiente SCC ou CCR devem estar no mesmo site do Active Directory. Embora os clusters de failover do Windows Server 2008 ofereçam suporte para nós de cluster que sejam membros de sites do Active Directory diferentes, o Exchange 2007 não aceita essa configuração.

Ao usar vários clusters de failover de sub-rede, os endereços IP associados a um recurso de Nome de Rede serão registrados dinamicamente no DNS (se configurados para atualizações dinâmicas) quando se tornarem online. Portanto, apenas os recursos de Endereço IP que estiverem online serão retornados aos clientes. Como os nós de cluster podem ser colocados em redes roteadas diferentes e os mecanismos de comunicação foram alterados para usar protocolos de sessão confiáveis implementados sobre UDP (User Datagram Protocol) (unicast), os requisitos de rede dos clusters dispersados geograficamente do Windows Server 2003 não são mais aplicáveis no Windows Server 2008. Conseqüentemente, as organizações podem implantar um ambiente SCC ou CCR em duas centrais de dados físicas sem ter de usar a tecnologia virtual de LAN (VLAN) para abranger as sub-redes.

Quando ocorre um failover ou uma movimentação de um servidor de caixas de correio clusterizadas implantado em vários clusters de failover de sub-rede dispersos geograficamente, o nome do servidor de caixas de correio clusterizadas é mantido, mas o endereço IP atribuído ao nome não é mantido. A disponibilidade deste servidor para clientes e outros servidores dependerá da propagação do novo endereço IP em todo o DNS. Pode levar algum tempo para que a propagação de DNS ocorra. Por esse motivo, recomenda-se a configuração de um valor de Vida Útil (TTL) para o registro host de DNS do servidor de caixas de correio em cluster para 10 minutos.

Embora os clientes internos do Microsoft Outlook não precisem de perfis novos ou reconfigurados para se conectarem usando o novo endereço IP, eles precisarão aguardar até que seus caches DNS locais sejam limpos para que a resolução de nomes para o nome do servidor de caixas de correio em cluster seja movida de seu endereço IP antigo para o novo endereço IP. Depois que o endereço IP tiver sido propagado para os servidores DNS adequados, você poderá limpar o cache DNS dos clientes do Outlook usando o comando a seguir na linha de comando do cliente.

ipconfig /flushdns

Suporte para DHCP-IPv4

No cluster de failover do Windows Server 2008, o recurso existe onde os recursos de Endereços IP de cluster podem obter o endereçamento dos servidores de protocolo DHCP, como também por entradas estáticas. Se os próprios nós de cluster forem configurados para obter seus endereços IP de um servidor DHCP, o comportamento padrão será obter um endereço IP automaticamente para todos os recursos de Endereço IP de cluster. Se o nó de cluster tiver endereços IP atribuídos estaticamente, os recursos de Endereço IP do cluster precisarão ser configurados com endereços IP estáticos também. Assim, a atribuição de IP do recurso Endereço IP segue a configuração do nó físico e cada interface especifica no nó.

Suporte para IPv6

O Windows Server 2008 e o serviço de cluster aceitam o IPv6. Isso inclui ser capaz de oferecer suporte a recursos de Endereços IP IPv6 e recursos de Endereços IP IPv4 sozinho ou em combinação em um cluster. Além disso, os clusters de failover também oferecem suporte ao protocolo ISATAP e aceitam somente endereços IPv6 que permitem o registro dinâmico em DNS (registros de host AAAA e a zona de pesquisa reversa IP6.ARPA). Atualmente, há três tipos de endereço IPv6: global, site local e link local. Registros DNS dinâmicos não serão possíveis em endereços de link local e portanto endereços de link local não poderão ser usados em um cluster.

Dica

O uso de endereços IPv6 e de intervalos de endereço IP é aceito apenas quando o Exchange 2007 SP1 foi implantado em um computador que esteja executando o Windows Server 2008. Nesse caso, tanto IPv6 como IPv4 serão ativados nesse computador, e a rede aceita as duas versões de endereço IP. Caso o Exchange 2007 seja implantado nessa configuração, todas as funções de servidor poderão enviar e receber dados de dispositivos, servidores e clientes que usam endereços IPv6. Uma instalação padrão do Windows Server 2008 permite suporte para IPv4 e IPv6. Se o Exchange 2007 SP1 for instalado no Windows Server 2003, endereços IPv6 não serão aceitos. Para obter mais informações sobre o suporte do Exchange 2007 SP1 para endereços IPv6, consulte Suporte a IPv6 no Exchange 2007 SP1 e SP2.

Exchange e configuração de rede de cluster de failover

Ao configurar um SCC ou uma CCR no Exchange 2007 SP1, esteja ciente dos seguintes requisitos:

• IPv6 e DHCP IPv4 são aceitos apenas no Windows Server 2008. Nenhum dos dois pode se usado quando o Exchange 2007 está sendo executado no Windows Server 2003.

• DHCP IPv6 não é aceito pelo Windows Server 2008 ou pelo serviço de cluster. Conseqüentemente, também não é aceito pelo Exchange 2007. Somente endereços IPv6 dinâmicos atribuídos pelo sistema são aceitos.

• Endereços IPv6 estáticos são aceitos pelo Windows Server 2008 e pelo serviço de cluster. No entanto, o uso de endereços IPv6 estáticos contraria as práticas recomendadas. Como resultado, o Exchange 2007 não aceita a configuração de endereços IPv6 estáticos durante a instalação.

• O encapsulamento IPv6 sobre IPv4 é aceito pelo cluster do Windows Server 2008, mas a instalação do Exchange não permite a criação desse tipo de recurso de Endereço IP.

A instalação foi modificada no Exchange 2007 SP1 para aceitar as alterações descritas anteriormente. Ao usar o Assistente de Instalação do Exchange Server 2007, observe que há campos e páginas adicionais disponíveis para a configuração dos recursos do cluster, Endereço IP e Nome de Rede. Além disso, as opções /NewCMS e /RecoverCMS do Setup.com foram atualizadas para aceitar vários parâmetros opcionais novos, que estão documentados na tabela a seguir.

Parâmetros opcionais para /NewCMS e /RecoverCMS adicionados no Exchange 2007 SP1

Parâmetro	Descrição
CMSIPV4Addresses	Uma lista separada por vírgula usada para especificar um ou dois endereços IPv4 estáticos para o servidor de caixas de correio em cluster. Se forem especificados dois endereços estáticos, eles deverão estar em sub-redes diferentes.
CMSIPV4Networks	Uma lista separada por vírgula usada para especificar um ou dois nomes de rede de cluster IPv4. Esses nomes serão usados na criação de recursos DHCP-IPv4.
CMSIPV6Networks	Uma lista separada por vírgula usada para especificar um ou dois nomes de rede de cluster IPv6. Esses nomes serão usados na criação de recursos IPv6. Esse parâmetro pode ser usado com o parâmetro CMSIPV4Addresses ou CMSIPV4Networks.

Dica

Os parâmetros CMSIPV4Addresses e CMSIPV4Networks são exclusivos entre si.

O parâmetro CMSIPAddress, que era um parâmetro necessário para /NewCMS e /RecoverCMS na versão RTM do Microsoft Exchange Server 2007 ainda é usado para especificar um único endereço IPv4 estático para o servidor de caixas de correio em cluster. No entanto, no Exchange 2007 SP1, o parâmetro CMSIPAddress agora é opcional visto que a especificação de qualquer um dos quatro parâmetros disponíveis é suficiente para a instalação.

Os parâmetros da tabela anterior podem ser usados apenas no Windows Server 2008.

Novos Modelos de Quorum no Windows Server 2008

Quando ocorrem problemas na rede, eles podem interferir na comunicação entre os nós do cluster. Um conjunto pequeno de nós pode se comunicar através de uma parte em funcionamento da rede, mas podem não ser capazes de se comunicar com um conjunto diferente de nós em outra parte da rede. Essa situação pode causar problemas graves. Nessa situação de divisão, pelo menos um dos conjuntos de nós deve parar de ser executado como cluster, embora os conjuntos de nós não tenham informações definitivas sobre os estados dos outros nós.

Para evitar os problemas causados por uma divisão no cluster, o software de cluster requer que qualquer conjunto de nós executado como cluster use um algoritmo de votação para determinar se, em um momento específico, esse conjunto tem quorum. Como um cluster específico tem um conjunto de nós específico e uma configuração de quorum específica, o cluster saberá quantos votos constituem uma maioria (um quorum). Se o número ficar abaixo da maioria, a execução do cluster será interrompida. Os nós ainda perceberão a presença dos outros nós, no caso de aparecer novamente outro nó na rede, mas não começarão a funcionar como cluster até que o quorum volte a existir.

A configuração do quorum é um cluster de failover que determina o ponto no qual várias falhas interromperão a execução do cluster. As falhas relevantes nesse contexto são falhas de nós ou, em alguns casos, um disco de testemunha ou um compartilhamento de arquivo de testemunha (que contém uma cópia da configuração de cluster). O Windows Server 2008 permite que você escolha dentre quatro configurações de quorum possíveis:

• Nós Principais   Esse modelo é recomendado para clusters com um número de nós ímpar. Ele pode sustentar falhas de metade dos nós menos 1. Por exemplo, um cluster de 7 nós pode sustentar falhas de 3 nós.

• Nós e Discos Principais   Esse modelo é recomendado para clusters com um número par de nós. Ele poderá sustentar falhas de metade dos nós se o disco de testemunha continuar online. Por exemplo, um cluster de 6 nós com um disco de testemunha pode sustentar falhas de 3 nós. Poderá também sustentar falhas de metade dos nós menos 1 se o disco de testemunha estiver offline ou falhar. Por exemplo, um cluster de 6 nós no qual o disco de testemunha tenha falhado pode sustentar falhas de 2 nós (3-1 = 2).

• Compartilhamento de Nós e Arquivos Principais   Esse modelo foi criado para clusters com configurações especiais, e é recomendado para servidores de caixas de correio em cluster em um ambiente CCR. Esse modelo funciona da mesma forma que o modelo de Nós e Discos Principais, mas em vez de um disco de testemunha, ele usa uma testemunha de compartilhamento de arquivo.

• Sem Principais: Somente Disco   Esse modelo, embora aceito, não é recomendado. Ele pode sustentar falhas de todos os nós, exceto 1. No entanto, essa configuração não é recomendada porque o disco é um ponto de falha único.

Replicação contínua sobre redes de cluster redundantes

No RTM do Exchange 2007, toda a cópia e propagação de arquivo de log de transação em um ambiente CCR ocorre na rede pública. Essa configuração tem os seguintes limites:

• Quando o nó passivo fica indisponível por várias horas, um número significativo de logs podem ser gerados e precisem ser transferidos. O movimento desses logs deve ser o mais rápido possível quando o nó passivo estiver disponível. Ao copiar os logs pela rede pública, o movimento dos logs compete com o tráfego do cliente. Isso afeta o tráfego do cliente e deixa a ressincronização mais lenta.

• Quando a rede pública falha, o failover tem perdas, mesmo que os dados do log estejam disponíveis.

• O uso de uma rede isolada para a comunicação de log permite a segurança dos dados de mensagem sem o uso de criptografia e sem a perda de desempenho associada.

• Tempestades de log podem ocorrer em algumas circunstâncias. Quando ocorrem, o sistema passa por uma sobrecarga excepcionalmente alta de replicação. Essa situação poderá resultar na privação do cliente se os dados de log precisarem se comunicados por meio da mesma rede usada para a comunicação com clientes.

Nem todos esses problemas ocorrerão na mesma freqüência. No entanto, é certo que o primeiro problema acontecerá com freqüência de meses porque os nós passivos ficam offline para atividades regulares de manutenção.

O Exchange 2007 SP1 minimiza os efeitos dos problemas anteriores permitindo que o administrador crie um ou mais redes mistas no cluster (por exemplo, uma rede de cluster que ofereça suporte tanto a tráfego de pulsação de cluster interno quanto a tráfego de cliente) para remessa de log. O Exchange 2007 SP1 também habilita um administrador para determinar uma rede específica a ser usada para propagação.

Dica

As redes de cluster usadas para envio de logs ou propagação devem ser configuradas como redes mistas. Um rede mista consiste em qualquer rede de cluster que esteja configurada tanto para o tráfego de acesso de cluster (pulsação) quanto para o de cliente. Além disso, quando o adaptador de rede é configurado com um nome de host de replicação contínua, o administrador precisa marcar a caixa de seleção Registrar os endereços desta conexão no DNS na caixa de diálogo de propriedades Configurações TCP/IP Avançadas. O servidor DNS usado pelo adaptador de rede pode estar localizado na rede pública ou privada; no entanto, independentemente de sua localização, ele deverá estar acessível para ambos os nós para que a resolução de nome de host possa ocorrer.

O suporte para cópia de logs sobre uma rede mista é configurado usando um novo cmdlet do Shell de Gerenciamento do Exchange denominado Enable-ContinuousReplicationHostName. De maneira similar, a desativação deste recurso é realizada usando o cmdlet Disable-ContinuousReplicationHostName. Quando um servidor de caixas de correio clusterizadas existir em um ambiente CCR, um administrador pode executar Enable-ContinuousReplicationHostName em ambos os nós do cluster e especificar nomes de host e endereços IP adicionais, que serão posteriormente criados em grupos de cluster dedicados que estarão associados a cada nó. Após ter realizado essa tarefa, o serviço de replicação do Microsoft Exchange começará a usar a rede recentemente criada para cópia de logs logo após a configuração bem-sucedida e a confirmação de que a nova rede está operacional. Se várias redes novas forem criadas, o serviço de replicação do Microsoft Exchange irá selecionar aleatoriamente uma delas. Se a rede especificada ficar indisponível, o serviço de replicação do Microsoft Exchange irá automaticamente começar a usar outras redes de replicação ou, caso nenhuma esteja disponível, ele começará a usar a rede pública para remessa de logs em 5 minutos. (A descoberta da rede do serviço de replicação do Microsoft Exchange ocorre a cada 5 minutos.) Quando a rede de replicação preferida estiver disponível de novo, o serviço de replicação do Microsoft Exchange irá automaticamente revertê-la para o envio de logs. Para obter mais informações sobre cmdlets, consulte Enable-ContinuousReplicationHostName e Disable-ContinuousReplicationHostName.

O suporte para propagação em um cluster redundante é configurado usando o cmdlet Update-StorageGroupCopy, que foi atualizado no Exchange 2007 SP1 ara incluir um novo parâmetro chamado DataHostNames. Esse parâmetro é usado para especificar que rede de cluster deverá ser usada para propagação. Para obter mais informações sobre as alterações ao cmdlet Update-StorageGroupCopy no Exchange 2007 SP1, consulte Update-StorageGroupCopy.

Após uma rede de cluster ter sido criada para replicação contínua, você pode usar o cmdletGet-ClusteredMailboxServerStatus para exibir informações atualizadas sobre as redes de cluster que foram habilitadas para atividade de replicação contínua. Os detalhes da nova saída incluem:

• OperationalReplicationHostNames:{Host1,Host2,Host3}

• FailedReplicationHostNames:{Host4}

• InUseReplicationHostNames:{Host1,Host2}

Para obter mais informações sobre as alterações feitas no cmdlet Get-ClusteredMailboxServerStatus no Exchange 2007 SP1, consulte Get-ClusteredMailboxServerStatus.

Para obter mais informações sobre como habilitar redes de cluster para replicação contínua no Windows Server 2003, consulte Como habilitar redes redundantes de cluster para envio e propagação de logs no Windows Server 2003.

Para obter mais informações sobre como habilitar redes de cluster para replicação contínua no Windows Server 2008, consulte Como habilitar redes redundantes de cluster para envio e propagação de log no Windows Server 2008.

Para obter mais informações sobre como desabilitar redes de cluster para replicação contínua, consulte Como desabilitar a replicação de uma rede de cluster.

Aprimoramentos de relatório e de monitoramento

O Exchange 2007 SP1 também apresenta várias alterações que aprimoram a gerenciabilidade do Exchange 2007. Essas alterações aprimoram os recursos de relatório de cluster na RTM do Exchange 2007 e incluem uma funcionalidade adicional criada para monitoramento pró-ativo de ambientes de replicação contínua. Especificamente, as alterações e aprimoramentos corrigem deficiências conhecidas com o cmdlet Get-StorageGroupCopyStatus, apresentam um novo cmdlet chamado Test-ReplicationHealth e fornecem maior visibilidade pela janela de perda coberta pelo dumpster de transporte. Para obter mais informações sobre esses aprimoramentos de relatório e de monitoramento, consulte Monitorando a replicação contínua.

Aprimoramentos de desempenho

Aprimoramentos no desempenho que beneficiam as implantações de alta disponibilidade foram realizados no Exchange 2007 SP1. Esses aprimoramentos incluem:

• Reduções de E/S nos discos contendo cópias passivas de grupos de armazenamento em ambientes de replicação contínua   No Exchange 2007 SP1, a estrutura da arquitetura da replicação contínua foi modificada para que o cache do banco de dados seja mantido no nó passivo entre lotes de atividade de repetição de log. A manutenção do cache de banco de dados da atividade de log habilita o serviço de replicação do Microsoft Exchange a nivelar os recursos de cache de banco de dados do Extensible Storage Engine (ESE), que, por sua vez, reduz a entrada/saída (E/S) do disco que ocorre nos LUNs (números de unidades lógicas) da cópia passiva. Em contrapartida, no Exchange 2007 RTM, um novo cache de banco de dados foi criado para cada lote de atividade de repetição, o que, em alguns casos, duplica ou triplica a atividade de E/S do disco no nó ativo.

  Movimentação mais rápida de servidores de caixas de correio clusterizadas entre nós em um ambiente CCR   Essas melhorias habilitam servidores de caixas de correio clusterizadas a se moverem entre nós em dois minutos ou menos. Isso inclui as movimentações realizadas por um administrador (usando o cmdlet Move-ClusteredMailboxServer) e failovers que são gerenciados pelo serviço de cluster. Para realizar movimentações rápidas em um ambiente CCR, os bancos de dados ficam offline sem liberar o cache do banco de dados. Em um SCC, a movimentação do servidor de caixas de correio em cluster leva aproximadamente cinco minutos. A liberação do cache do banco de dados ainda ocorre antes de o servidor de caixas de correio em cluster ser movido. Essa é uma liberação oportuna que permite aos clientes permanecer conectados ao banco de dados. Esse comportamento reduz o tempo de inatividade ocorrido quando o servidor de caixas de correio em cluster é movido para outro nó.

  Durante o processo de failover, a ID do evento 9868 é registrada duas vezes para indicar o status da operação de liberação, e a ID do evento 113 é registrada para indicar o status da replicação. Esses eventos se assemelham aos seguintes:

  ID do Evento: 9868 Origem: MSExchangeIS Categoria: Geral Digite: Informações Descrição: A tentativa de liberar cache para o servidor '<MailboxServerName>' foi concluída com 0 falha dos grupos de armazenamento em alcançar a profundidade do ponto de verificação desejada.

  ID do Evento: 9868 Origem: MSExchangeIS Categoria: Geral Digite: Informações Descrição: A tentativa de liberar cache para o servidor '<MailboxServerName>' foi concluída com 2 falha dos grupos de armazenamento em alcançar a profundidade do ponto de verificação desejada.

  ID do Evento: 113 Origem: MSExchangeRepl Categoria: Mover Digite: Informações Descrição: A limpeza do cache do Armazenamento de Informações antes da transferência do servidor de caixa de correio em cluster '<MailboxServerName>' não foi concluída. Dados: Grupo de armazenamento '<MailboxServerName>\<StorageGroupName>': o início da profundidade do ponto de verificação era 19 e o fim era 17. Grupo de armazenamento '<MailboxServerName>\<SecondStorageGroupName>': o início da profundidade do ponto de verificação era 19 e o fim era 13.

Aprimoramentos do dumpster de transporte

O dumpster de transporte é um recurso da função de servidor Transporte de Hub. O dumpster de transporte mantém uma fila de mensagens entregues recentemente aos destinatários cujas caixas de correio estão em um servidor de caixas de correio em cluster de um ambiente CCR. Essa fila é limitada pelo tempo que a mensagem é mantida e o espaço total usado. Quando ocorre um failover com perdas, o servidor de caixas de correio em cluster solicita automaticamente a cada servidor de Transporte de Hub no site do Active Directory para reenviar a mensagem da fila do dumpster de transporte.

No Exchange 2007 SP1, o recurso de dumpster de transporte foi aprimorado das seguintes maneiras:

• Suporte para LCR   O dumpster de transporte agora inclui suporte para implantações de LCR. Ao contrário da CCR, em que a solicitação de nova entrega do dumpster de transporte é parte automática do processo de recuperação, o processo é manual em um ambiente LCR. O cmdlet Restore-StorageGroupCopy foi atualizado no Exchange 2007 SP1 para incluir a solicitação de reenvio do dumpster de transporte. Portanto, quando um administrador ativa uma cópia passiva de um grupo de armazenamento em um ambiente LCR usando o cmdlet Restore-StorageGroupCopy, a solicitação de envio do dumpster de transporte ocorre como parte do processo de ativação.

• Estatística do dumpster de transporte   Para informar melhor um administrador antes de recuperar um servidor que possua arquivos de log ausentes, o dumpster de transporte foi aprimorado para incluir informações estatísticas que fornecem o estado atual de todos os servidores de Transporte de Hub que contêm mensagens de um grupo de armazenamento afetado. Essas estatísticas incluem um número de mensagens, bem como o período da mensagem mais antiga, disponível em cada servidor de Transporte de Hub no site do Active Directory. Essas estatísticas podem ser vistas ao usar um novo parâmetro para o cmdlet Get-StorageGroupCopyStatus denominado DumpsterStatistics. Ao usar esse novo valor, o resultado de Get-StorageGroupCopyStatus incluirá as estatísticas do dumpster de transporte de todos os servidores de Transporte de Hub acessíveis, bem como uma lista dos servidores de Transporte de Hub que não estão acessíveis. Os servidores acessíveis serão listados em uma estrutura de diversos valores denominada DumpsterStatistics, e os servidores inacessíveis serão listados como uma cadeia de caracteres de diversos valores denominada DumpsterStatisticsNotAvailable, como ilustrado a seguir:

  DumpsterStatistics: {HUB1 (carimbo de data e hora mais antigo; número de itens no dumpster; tamanho do dumpster), HUB2 (carimbo de data e hora mais antigo; número de itens no dumpster; tamanho do dumpster), HUB3 (carimbo de data e hora mais antigo; número de itens no dumpster; tamanho do dumpster)}

  DumpsterStatisticsNotAvailable: {HUB4,HUB5}

  No exemplo anterior, o carimbo de data e hora mais antigo é a hora em que a mensagem foi recebida no servidor de Transporte de Hub e não a hora em que a mensagem foi entregue originalmente para o servidor de Caixa de Correio.

  O cmdlet Get-StorageGroupCopyStatus também inclui uma nova estrutura de diversos valores denominada OutstandingDumpsterRequests, que inclui servidores de Transporte de Hub com solicitações pendentes e o intervalo de tempo (baixo–alto) para solicitações pendentes, como ilustrado a seguir:

  OutstandingDumpsterRequests: {HUB1 (time-low;time_high), HUB5 (time_low;time_high)}

Aprimoramentos do Console de Gerenciamento do Exchange

O Exchange 2007 SP1 inclui novos elementos da GUI no Console de Gerenciamento do Exchange criados para aprimorar a experiência de configuração e de gerenciamento dos servidores de caixas de correio em cluster. Esses aprimoramentos incluem:

• Assistente de Gerenciamento de Servidor de Caixas de Correio em Cluster   Esse assistente é usado para mover, parar ou iniciar um servidor de caixas de correio em cluster em um ambiente CCR e em um SCC. A funcionalidade de mover e parar inclui também campos opcionais de comentário do administrador, permitindo que ele informe o motivo pelo qual o servidor de caixas de correio em cluster foi movido ou parado. Esse assistente equivale ao uso dos seguintes cmdlets do Shell de Gerenciamento do Exchange:

  • Move-ClusteredMailboxServer

  • Stop-ClusteredMailboxServer

  • Start-ClusteredMailboxServer

• Gerenciar replicação contínua   Foram incluídos no Console de Gerenciamento do Exchangecontroles adicionais de interface de usuário, que permitem que um administrador suspenda, continue, atualize e restaure a replicação contínua. Esses controles são equivalentes ao uso dos seguintes cmdlets do Shell de Gerenciamento do Exchange:

  • Suspend-StorageGroupCopy

  • Resume-StorageGroupCopy

  • Update-StorageGroupCopy

  • Restore-StoreGroupCopy

  Você pode usar esses cmdlets e as tarefas do Console de Gerenciamento do Exchange correspondentes para gerenciar a replicação contínua nos ambientes CCR e LCR.

  Dica

  Em um ambiente CCR, o assistente de Atualização de Cópia do Grupo de Armazenamento está disponível apenas no nó passivo, enquanto o assistente de Restauração de Cópia do Grupo de Armazenamento está disponível apenas no nó ativo.

• Guia Servidor de Caixas de Correio em Cluster   Uma nova guia foi adicionada à caixa de diálogo Propriedades do Servidor dos servidores de Caixa de Correio existentes em um cluster. Essa informação está disponível nos ambientes SCC e CCR. A nova guia fornece informações detalhadas sobre o servidor de caixas de correio em cluster e permite que um administrador configure o valor da propriedade AutoDatabaseMountDial dos servidores de caixas de correio em cluster em um ambiente CCR. Muitas das informações exibidas na nova guia também estão disponíveis usando o cmdlet Get-ClusteredMailboxServerStatus. Para obter mais informações sobre a guia Servidor de Caixas de Correio em Cluster, consulte Propriedades do Servidor > Guia Servidor de Caixas de Correio em Cluster.

• Página Replicação Contínua em Cluster   Uma nova página foi adicionada à caixa de diálogo Propriedades do Grupo de Armazenamento dos servidores de Caixa de Correio implantados em um ambiente CCR. A nova página de propriedade fornece informações detalhadas sobre o status de replicação contínua no cluster. Para obter mais informações sobre a página Replicação Contínua em Cluster, consulte Propriedades do Grupo de Armazenamento > Página Replicação Contínua em Cluster.

Para obter mais informações

O Windows Server 2008 inclui vários recursos que foram aprimorados ou renomeados. Para obter informações sobre as modificações do recurso entre o Windows Server 2003 e o Windows Server 2008, consulte Alterações na terminologia.