Gerenciando clusters de cópia única
Aplica-se a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Tópico modificado em: 2008-03-06
Além das tarefas de gerenciamento e administração diárias de uma organização do Exchange, há tarefas que são específicas de um cluster de cópia única (SCC).
As tarefas administrativas de um SCC são:
Gerenciar recursos de disco.
Gerenciar grupos de armazenamento e bancos de dados.
Exibir parâmetros de configuração e o status do SCC e do CMS (servidor de caixas de correio clusterizadas).
Gerenciando o cluster ou o CMS, por exemplo, iniciando e parando o CMS, e realizando manutenção no cluster.
Ao contrário das versões anteriores do Microsoft Exchange Server, em que o Administrador de Cluster era usado para muitas tarefas administrativas, várias das tarefas de gerenciamento de um SCC envolvem o uso do Console de Gerenciamento do Exchange ou o Shell de Gerenciamento do Exchange. No entanto, há algumas tarefas de gerenciamento que exigem o Administrador de Cluster ou a interface de gerenciamento de linha de comando de Cluster.exe.
Dica
O Administrador do Cluster e Cluster.exe fornecem mecanismos para movimentar grupos de recursos entre nós em um cluster. Ao realizar uma entrega de um CMS em um SCC, é recomendável que você use o cmdlet Move-ClusteredMailboxServer ou o novo assistente para Gerenciar Servidores de Caixas de Correio Clusterizadas no Exchange Server 2007 Service Pack 1 (SP1) em vez das ferramentas de gerenciamento de cluster, pois tanto o cmdlet como o assistente permitem que o administrador especifique um motivo para a entrega.
Gerenciar recursos de disco
Um SCC usa armazenamento compartilhado para hospedar todos os dados do grupo de armazenamento. O armazenamento compartilhado deve ser disponibilizado a todos os servidores configurados para hospedagem do CMS e ser integrado corretamente ao modelo de recursos do CMS. Em alguns casos, você pode precisar adicionar novo armazenamento a uma configuração existente. Em outros casos, o armazenamento a ser usado foi utilizado anteriormente por outro CMS. O tópico Como adicionar um recurso de disco físico a um servidor de caixas de correio em cluster fornece um procedimento de como adicionar um novo recurso de disco a um modelo de recursos do CMS.
Dica
Esse procedimento presume que o recurso não é uma dependência mencionada em outro grupo de armazenamento.
Depois de qualquer alteração de configuração, é aconselhável que você verifique se as dependências e definições de configuração adequadas estão em vigor. O tópico Como configurar dependências de disco para um cluster de cópia única no Windows Server 2003 descreve esse procedimento.
Se for necessário gerenciar volumes de disco em um SCC, os bancos de dados no grupo de armazenamento deverão ser desmontados. Para obter as etapas detalhadas sobre como desmontar um banco de dados, consulte "Montando e desmontando bancos de dados" adiante neste tópico.
Gerenciando grupos de armazenamento e bancos de dados
Existe uma série de tarefas administrativas que você pode executar relacionadas aos grupos de armazenamento e bancos de dados no CMS em seu SCC. Essas tarefas incluem a criação e remoção de bancos de dados e grupos de armazenamento, montagem e desmontagem de bancos de dados e relocação de dados de grupo de armazenamento movendo arquivos de log, arquivos de sistema ou arquivos de bancos de dados para um novo local. Em um SCC, várias dessas tarefas exigem que a configuração de disco compartilhado seja alterada ou que o modelo de recursos do CMS seja atualizado.
Criando e removendo bancos de dados
O processo para criar e remover bancos de dados em um SCC é idêntico ao usado em uma configuração autônoma, exceto pelo fato de que os discos físicos precisam ser adicionados ou excluídos do modelo de recursos do CMS.
Para obter etapas detalhadas sobre como criar um novo banco de dados de pasta pública, consulte Como criar um novo banco de dados de pasta pública. Para obter etapas detalhadas sobre como atualizar o modelo de recursos do cluster, consulte Como configurar dependências de disco para um cluster de cópia única no Windows Server 2003.
Para remover um banco de dados de caixa de correio, todas as caixas de correio devem primeiro ser desabilitadas ou removidas do banco de dados. Para remover um banco de dados de pasta pública, primeiramente todo o conteúdo deve ser removido do banco de dados. Para obter etapas detalhadas sobre como remover um banco de dados de pasta pública, consulte Como remover um banco de dados de pasta pública.
Se o disco físico do banco de dados não for reutilizado imediatamente pelo CMS, ele deverá ser removido do modelo de recursos do CMS. Isso pode ser realizado seguindo as etapas em Como remover um recurso de disco físico de um servidor de caixas de correio em cluster. Para obter etapas detalhadas sobre como atualizar o modelo de recursos do cluster, consulte Como configurar dependências de disco para um cluster de cópia única no Windows Server 2003.
Criando e removendo grupos de armazenamento
O processo para criar e remover grupos de armazenamento em um SCC é idêntico ao usado em uma configuração autônoma, exceto pelo fato de que os discos físicos precisam ser adicionados ou excluídos do modelo de recursos do CMS. Para obter etapas detalhadas sobre como criar um novo grupo de armazenamento, consulte Como criar um Novo Grupo de Armazenamento. Para obter etapas detalhadas sobre como remover um grupo de armazenamento, consulte Como remover um grupo de armazenamento. Para obter etapas detalhadas sobre como atualizar o modelo de recursos do cluster, consulte Como configurar dependências de disco para um cluster de cópia única no Windows Server 2003.
Montagem e desmontagem de bancos de dados
Ocasionalmente, pode ser necessário montar ou desmontar bancos de dados em um ambiente de SCC. O processo para montar e desmontar bancos de dados em um ambiente de SCC é idêntico ao usado em qualquer computador com o Exchange 2007. Para obter etapas detalhadas sobre como montar um banco de dados, consulte Como montar um banco de dados. Para obter etapas detalhadas sobre como desmontar um banco de dados, consulte Como desmontar um banco de dados.
Movendo o local de um grupo de armazenamento ou banco de dados
Pode ser necessário mover o local dos arquivos do grupo de armazenamento ou o local de um banco de dados em um SCC. A hora de mover os locais do arquivo depende do tamanho do banco de dados sendo movido, o número de arquivos de log de transações sendo movidos, e a taxa de transferência para as operações de disco. O banco de dados é desmontado durante qualquer movimentação. Em um SCC, a relocação de um grupo de armazenamento pode exigir que a configuração do disco compartilhado seja alterada ou que o modelo de recursos do CMS seja atualizado.
Para obter etapas detalhadas sobre como alterar o local dos arquivos de log do grupo de armazenamento ou arquivos de sistema, consulte Como mover um grupo de armazenamento em um cluster de cópia única. Para obter etapas detalhadas sobre como alterar o local de um banco de dados, consulte Como mover um banco de dados em um cluster de cópia única.
Exibindo status e definições de configuração
Depois que uma configuração de SCC for implantada, você poderá usar o Console de Gerenciamento do Exchange e o Shell de Gerenciamento do Exchange para exibir os parâmetros de configuração de grupos de armazenamento e bancos de dados no servidor. As informações de configuração incluem os locais do grupo de armazenamento e arquivos de banco de dados. Para obter etapas detalhadas sobre como exibir informações de configuração do grupo de armazenamento do SCC, consulte Como exibir configuração de grupo de armazenamento em um cluster de cópia única.
Para obter etapas detalhadas sobre como exibir informações de configuração do banco de dados do SCC, consulte Como exibir configuração doo banco de dados em um cluster de cópia única.
Para obter etapas detalhadas sobre como exibir e alterar parâmetros de configuração e dependências de disco físico do SCC, consulte Como configurar dependências de disco para um cluster de cópia única no Windows Server 2003.
Além disso, é possível examinar o status do CMS usando o Shell de Gerenciamento do Exchange. Para obter etapas detalhadas sobre como exibir o status atual de um CMS em um SCC, consulte Como exibir o status de um servidor de caixas de correio em cluster em um cluster de cópia única.
Gerenciar servidores de caixas de correio clusterizadas
Além de configurar dependências e recursos de disco para grupos de armazenamento e bancos de dados, as três outras principais tarefas administrativas para gerenciar um CMS em um SCC são colocar um CMS online, colocá-lo offline e movê-lo entre nós no cluster. O gerenciamento de um CMS também pode envolver o desligamento ou a reinicialização de um dos nós no cluster como parte do gerenciamento de atualização ou de outras operações de manutenção.
Movendo um servidor de caixas de correio clusterizadas entre nós
A movimentação manual de um CMS entre nós é chamada de entrega ou interrupção agendada. Ao realizar uma entrega de um CMS em um SCC, é recomendável que você use o cmdlet Move-ClusteredMailboxServer em vez da ferramenta Gerenciamento de Cluster de Failover (Windows Server 2008), do Administrador de Cluster (Windows Server 2003), ou do Cluster.exe em um dos sistemas operacionais, pois o cmdlet permite especificar um motivo para a entrega. No Exchange 2007 SP1, você também pode usar o assistente para Gerenciar Servidores de Caixas de Correio Clusterizadas no Console de Gerenciamento do Exchange para realizar uma entrega de um CMS.
Dica
A movimentação de um CMS entre os nós causa uma breve interrupção no serviço. Além disso, os backups de qualquer grupo de armazenamento no CMS são cancelados.
Ao mover um CMS em um cluster de failover no qual há latência de rede entre os nós, convém fazer a movimentação a partir do nó passivo.
Iniciando e parando os servidores de caixas de correio clusterizadas
A ferramenta Gerenciamento de Cluster do Failover (Windows Server 2008), o Administrador de Cluster (Windows Server 2003) e a ferramenta de linha de comando Cluster.exe têm a capacidade de colocar recursos online e offline. Colocar um CMS offline é chamado parar e colocar um CMS online é chamado iniciar.
A maneira apropriada de iniciar um CMS é usar o cmdlet Start-ClusteredMailboxServer. A forma recomendada de parar um CMS é usar o cmdlet Stop-ClusteredMailboxServer. No Exchange 2007 SP1, também é possível usar o assistente para Gerenciar Servidores de Caixas de Correio Clusterizadas no Console de Gerenciamento do Exchange para iniciar ou parar um CMS.
Para obter etapas detalhadas sobre como colocar um CMS em um SCC online, consulte Como iniciar um servidor de caixas de correio em cluster em um cluster de cópia única. Para obter etapas detalhadas sobre como colocar um CMS em um SCC offline, consulte Como parar um servidor de caixas de correio em cluster em um cluster de cópia única.
Executando a manutenção no cluster
A manutenção deve sempre ser executada no nó passivo do cluster. Geralmente, atualizações, hotfixes e outros aplicativos não devem ser instalados no nó ativo (um nó que possua um CMS no momento). Para obter etapas detalhadas sobre como instalar pacotes cumulativos de atualizações do Exchange em um SCC, consulte Aplicando os pacotes cumulativos de atualização do Exchange 2007 em servidores de caixas de correio clusterizadas.
Se for necessário fazer manutenção no nó ativo, o CMS deverá ser movido primeiro para um nó passivo com o uso do cmdlet Move-ClusteredMailboxServer. Depois de movido o CMS, o nó anteriormente ativo passa a ser o nó passivo, e o nó anteriormente passivo se torna o nó ativo. A manutenção poderá então ser executada, e uma entrega que mova o CMS na direção oposta poderá ser realizada.
Um SCC permite que você agende uma interrupção do sistema de um nó específico sem uma interrupção do CMS. Em um SCC de dois nós, apenas um nó pode ser colocado offline de cada vez se você precisar manter a disponibilidade de dados e serviços. Colocar os dois nós offline resultará em uma interrupção no serviço.
Uma interrupção agendada é iniciada através do cmdlet Move-ClusteredMailboxServer do Shell de Gerenciamento do Exchange. O tópico Como mover um servidor de caixas de correio clusterizadas em um cluster de cópia única fornece um procedimento para executar uma interrupção agendada.
Antes de desligar ou reiniciar qualquer nó em um SCC, é recomendável que você verifique qual nó está hospedando o CMS. Essas informações podem ser obtidas usando o cmdlet Get-ClusteredMailboxServerStatus.
Desligando nós do cluster
Se todos os nós do cluster precisarem ser desligados (inclusive os nós ativos), interrompa primeiro o CMS. O processo de desligamento do Windows não é sensível ao Exchange. Por isso, é recomendável que você só encerre nós passivos. Se um nó ativo precisar ser desligado ou reiniciado, é recomendável que você mova o CMS para outro nó disponível. Para obter etapas detalhadas que explicam como mover um CMS para outro nó, consulte Como mover um servidor de caixas de correio clusterizadas em um cluster de cópia única.
Se o CMS não puder ser movido para o nó passivo (talvez porque o nó já foi desligado), é recomendável que ele seja parado (colocado offline) antes de desligar o nó ativo. Para obter etapas detalhadas sobre como colocar um CMS em um SCC offline, consulte Como parar um servidor de caixas de correio em cluster em um cluster de cópia única.
Caso seja necessário reiniciar ou desligar o nó ativo e você não possa mover o CMS para o nó passivo, é recomendável usar a Diretiva de Grupo para garantir que o CMS seja parado antes de reiniciar ou desligar um nó ativo. O Windows Server fornece um conjunto de scripts de desligamento de computador baseados em diretivas que você pode gerenciar usando o snap-in Diretiva de Grupo. Esse snap-in inclui extensões que permitem especificar um script a ser executado quando você desligar o computador. Esses scripts são executados na conta Sistema Local. Por exemplo, é possível criar um script de encerramento que execute o cmdlet Move-ClusteredMailboxServer ou o cmdlet Stop-ClusteredMailboxServer, com os parâmetros adequados. Também é recomendável usar um script de desligamento porque ele reduz as chances de um sistema ser desligado ou reiniciado por um administrador que não tenha ciência da necessidade de mover ou parar o CMS antes de desligar o nó ativo.