Estratégias de alta disponibilidade
Aplica-se a: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Tópico modificado em: 2007-08-31
Este tópico fornece uma ampla visão geral de alta disponibilidade no Microsoft Exchange Server 2007. Este tópico também introduz o processo de decisão recomendado para selecionar a solução de disponibilidade que é adequada para sua organização.
Os termos disponibilidade e alta disponibilidade podem ter significados diferentes, dependendo do contexto em que são usados e do público envolvido. Eles podem ser usados para descrever várias metas empresariais e requisitos técnicos, desde metas de disponibilidade somente de hardware, a metas de missão crítica de serviço de mensagens como um todo.
Geralmente, é relativamente fácil para as organizações terem expectativas inadequadas em relação às metas de disponibilidade. Para as organizações é fácil também exigir níveis de disponibilidade mais altos do que elas estão dispostas a pagar antes que as implicações de custo sejam entendidas.
As implicações de custo das soluções de maior disponibilidade incluemi, mas não se limitam, ao seguinte:
Hardware
Software
Infra-estrutura de rede
Treinamento
Prestação de serviços
Custos operacionais
Prestação de serviços refere-se aos acordos contratuais feitos com provedores de serviços terceirizados ou acordos em nível operacional feitos com divisões de tecnologia da informação dentro da sua organização, para fornecer ou dar manutenção a serviços ou componentes de tecnologia da informação
Disponibilidade
A disponibilidade refere-se a um nível de serviço fornecido por aplicativos, serviços ou sistemas. Sistemas altamente disponíveis têm um tempo de inatividade mínimo, planejado ou não. A disponibilidade é freqüentemente expressa como uma porcentagem de tempo que um serviço ou sistema está disponível, por exemplo, 99.9% para um serviço que estará indisponível durante 8,75 horas por ano.
Para melhorar a disponibilidade, você precisa implementar os mecanismos de tolerância a falhas para mascarar ou minimizar o impacto de falhas dos componentes e das dependências do serviço. A tolerância a falhas é conseguida por meio da implantação da redundância a pontos únicos dos componentes da falha.
Ao planejar a disponibilidade para o Microsoft Exchange, considere todos os componentes que são parte da infra-estrutura de mensagens. Alguns componentes também podem ser outros serviços que têm subcomponentes. A disponibilidade do serviço de mensagens é determinada pela disponibilidade de cada componente que é parte da infra-estrutura.
Definindo os requisitos de disponibilidade
A disponibilidade de um serviço é um problema complexo que abrange muitas disciplinas. Muitos enfoques diferentes podem ser adotados para fornecer os níveis de disponibilidade necessários, e cada um deles tem suas próprias implicações de custo.
Entretanto, os requisitos de disponibilidade podem freqüentemente ser expressos em termos um tanto simplistas pelo cliente e sem uma compreensão completa das implicações. Essa situação pode levar a mal-entendidos entre o cliente e a organização de tecnologia da informação, níveis inapropriados de investimento e, por último, à insatisfação do cliente causadas pelo estabelecimento de expectativas inadequadas.
Uma necessidade expressa de disponibilidade de 99,5% pode ser diferente de outra necessidade de disponibilidade de 99,5%. Um necessidade pode discutir a disponibilidade da plataforma de hardware isoladamente e outra pode discutir a disponibilidade do serviço completo de ponta a ponta. Mesmo a definição da disponibilidade do serviço completo de ponta a ponta pode variar muito. É importante entender exatamente como algumas necessidades de disponibilidade podem ser medidas. Por exemplo:
Se todo hardware e software no servidor principal estiver funcionando corretamente e as conexões de usuário estiverem prontas para serem aceitas pelo aplicativo, a solução é considerada 100% disponível?
Se houver 100 usuários, mas 25% deles não puderem se conectar devido a uma falha de rede local, a solução ainda será considerada 100% disponível?
Se apenas um usuário dos 100 usuários puder se conectar e processar trabalho, a solução será considerada apenas 1% disponível?
Se todos os 100 usuários puderem se conectar mas o serviço está prejudicado, com apenas duas de três transações de cliente disponíveis, ou se o desempenho estiver ruim, como isso afeta as medidas de disponibilidade?
O período ao longo do qual a disponibilidade deve ser medida também pode ter um efeito significativo na definição de disponibilidade. Uma requisição de disponibilidade de 99,9% ao longo de um período de um ano permite 8.75 horas de inatividade. Uma requisição de disponibilidade de 99,9% em períodos de quatro semanas permite apenas 40 minutos de inatividade em cada período.
Além disso, é necessário identificar e negociar períodos de inatividade para manutenção planejada, atualizações de service pack e atualizações de software. A quantidade de inatividade planejada que pode ser tolerada tem um efeito significativo na definição das necessidades de disponibilidade.
A liberação da versão RTM (Versão de Produção) do Microsoft Exchange Server 2007 inclui novos recursos que podem reduzir custos e aumentar o tempo de ativação:
Replicação contínua local A LCR (replicação contínua local) é uma solução em um único servidor que usa tecnologia interna para criar e manter uma cópia de um grupo de armazenamento em um segundo conjunto de discos que são conectados ao mesmo servidor como o grupo de armazenamento de produção. A LCR fornece remessa de log assíncrona, repetição de log e uma troca manual rápida para uma cópia dos dados. Para obter mais informações sobre LCR, consulte Replicação contínua local.
Replicação contínua em cluster A CCR (Replicação Contínua em Cluster) combina os recursos de replicação e repetição do Exchange 2007 com recursos de falha nos serviços de Cluster da Microsoft. A CCR é uma solução que pode ser implantada sem um único ponto de falha em um único centro de dados ou entre dois centros de dados. Para obter mais informações sobre CCR, consulte Replicação Contínua em Cluster. A CCR fornece várias vantagens sobre agrupamentos em versões anteriores do Exchange Server e clusters de cópia única no Exchange 2007. Para obter detalhes sobre essas vantagens, consulte Vantagens da Replicação Contínua em Cluster em relação aos Clusters de Cópia Única.
Clusters de cópia única Clusters de cópia única (SCC), conhecidos como clusters de armazenamento compartilhado nas versões anteriores do Exchange Server, estão presentes no Exchange 2007 com algumas alterações e aprimoramentos importantes. Para obter mais informações sobre SCC, consulte Clusters de cópia única.
O Microsoft Exchange Server 2007 Service Pack 1 (SP1) adiciona um recurso adicional projetado para fornecer resiliência de site:
- Replicação Contínua em Espera É um novo recurso apresentado no Exchange 2007 SP1. Como o próprio nome diz, a SCR foi projetada para cenários que usem ou habilitem o uso de servidores de recuperação em espera. A SCR estende os recursos de replicação contínua existentes e permite novos cenários de disponibilidade de dados para servidores de Caixa de Correio do Exchange 2007. A SCR usa a mesma remessa de log e tecnologia de repetição usada pela LCR e pela CCR para fornecer configurações e opções de implantação adicionais. A SCR pode ser usada para replicar dados de servidores de Caixa de Correio autônoma e servidores de caixa de correio em cluster. Para obter mais informações sobre SCR, consulte Replicação Contínua Em Espera.
Esses recursos fornecem oportunidades de recuperação avançadas que atendem a vários requisitos de disponibilidade. A tabela a seguir lista vários requisitos de disponibilidade e oferece uma comparação de soluções do Exchange 2007 com soluções de recuperação de desastre que estavam presentes no Exchange Server 2003. Para obter mais informações sobre configurações de alta disponibilidade para o Exchange 2007, consulte Implantações de Alta Disponibilidade.
Comparação de soluções de alta disponibilidade com base nos requisitos de disponibilidade
| Requisito de disponibilidade | Solução do Exchange 2003 | Solução do Exchange 2007 RTM | Solução do Exchange 2007 SP1 |
|---|---|---|---|
Arquivamento de longo prazo |
Backups completos diários. Restaurar backups para servidor reconstruído de forma idêntica. |
Backups completos semanais e backups incrementais diários Restaurar backups para qualquer servidor. |
Backups completos semanais e backups incrementais diários Restaurar backups para qualquer servidor. |
Responder aos erros de usuário |
Padrão de dumpster de 7 dias. Acima de 7 dias, restaurar backups para recompilar servidor de forma idêntica. |
Padrão de dumpster de 14 dias. Acima de 14 dias, restaurar backups para qualquer servidor. |
Padrão de dumpster de 14 dias. Acima de 14 dias, restaurar backups para qualquer servidor. |
Resiliência contra falhas:
|
Restaurar backups para servidor reconstruído de forma idêntica. |
Replicação contínua. Nenhuma restauração é necessária. Falha autônoma ou falha dupla de CCR: Tom de discagem em local alternado ou portabilidade de banco de dados. |
Replicação contínua. Nenhuma restauração é necessária. Falha autônoma ou falha dupla de CCR: Tom de discagem em local alternado ou portabilidade de banco de dados. |
Resiliência contra desastre em todo o site |
Restaurar backups para servidor reconstruído de forma idêntica. |
Replicação contínua no segundo site. Nenhuma restauração é necessária. Falha autônoma ou falha dupla de CCR: Tom de discagem em local alternado ou portabilidade de banco de dados. |
Replicação contínua em espera no segundo site. Nenhuma restauração é necessária. Portabilidade do banco de dados ou ativação do servidor em espera. |
Selecionando a solução de disponibilidade apropriada
Várias configurações podem ser usadas para aprimorar a disponibilidade de uma implantação do Exchange 2007. Uma etapa significativa referente à seleção da solução de disponibilidade correta exige uma análise de um conjunto de opções selecionado para determinar qual solução melhor atende às suas metas empresariais e seus requisitos de disponibilidade. Uma maneira de fazer isso é criar uma tabela com uma seção para cada tipo de falha. Em cada seção da tabela, use uma linha para identificar cada solução que fornece uma estratégia de recuperação consistente com seus requisitos de disponibilidade para a falha. Documente os fatores significativos da solução nas colunas. Os fatores típicos são:
Tempo de recuperação
Impacto dos dados de recuperação
Custos de hardware e software associados
Custos de recursos associados
Probabilidade do evento
Implicações nos negócios
Riscos da complexidade
Soluções de terceiros
Prós
Contras
Depois de concluir essas tabelas, selecione várias soluções para obter uma análise dos custos. Para cada solução selecionada, você deve desenvolver um custo estimado por caixa de correio, que pode ser representado também em uma tabela. Na tabela de custos, assegure-se de fornecer uma linha que caracterize a qualidade da solução em relação às metas empresariais. Verifique se você avaliou várias opções. Selecione pelo menos uma solução que satisfaça as exigências, mas que seja diferente da solução típica que sua organização escolher.
Finalmente, reveja as metas empresariais, os requisitos de disponibilidade, as possíveis soluções e a análise dos custos para selecionar a solução. Durante esse processo, considere as seguintes chaves para tomar a decisão correta:
Ter uma definição clara de metas empresariais prioritárias A prioritização é importante, uma vez que metas diferentes provavelmente entrarão em conflito.
Desafie as verdades históricas que podem não se aplicar mais Utilize o potencial completo do Exchange 2007 durante a etapa de projeto e avaliação. A experiência tem mostrado que a maioria das soluções econômicas podem exigir novas abordagens para backups, armazenamento e operações.
Examine pontos de falhas únicos no seu sistema de mensagem Uma única cópia de dados de caixa de correio armazenado em uma SAN (rede de área de armazenamento) significa que os dados não estão completamente protegidos contra danos e falhas. Os danos e as falhas podem ocorrer de várias maneiras para essa cópia única dos dados, independentemente da quantidade de redundância fornecida pela SAN. Com a SCC, uma falha na SAN pode fazer com que o serviço experimente horas de perda de dados e dias de interrupção. CCR é uma solução de disponibilidade que pode causar perda de alguns dados quando ocorrer uma falha no servidor, mas ela também mantém duas cópias dos dados. A CCR minimiza a maioria da perda de dados quando ocorre uma falha no servidor usando um recurso do servidor de Transporte de Hub chamado dumpster de transporte. Como resultado, os dados da caixa de correio são preservados na maioria das circunstâncias de uma falha permanente.
Explore o intervalo de opções de armazenamento que estão disponíveis para cada solução A CCR fornece organizações com a opção de usar um amplo intervalo de soluções de armazenamento, como armazenamento conectado diretamente. A CCR não exige uma malha da SAN, que reduz a complexidade e os custos associados. O armazenamento conectado diretamente, seja de uma solução de armazenamento de SAN ou de baixo custo, é mais fácil de implantar e operar.
Considere que a CCR e a LCR permitem alterar a estratégia de backup do backup típico completo diário para um backup completo menos freqüente e a estratégia incremental diária A CCR e a LCR podem ter suporte também de um SLA (acordo de nível de serviço) mais curto para recuperação da primeira falha. O SLA para recuperação de uma falha dupla (as duas cópias com falha ou danificadas) pode precisar ser prolongado pelo SLA de restauração atual. Alterações como essa podem reduzir drasticamente o seu custo total de propriedade (TCO) porque os custos de backup são normalmente um componente principal do TCO. Além disso, a opção por uma estratégia de backup baseada em disco também pode reduzir os custos de backup.
Investigue o uso de tecnologia de replicação contínua no Exchange 2007 para criar uma solução A CCR torna desnecessária a tecnologia de replicação de terceiros. Atualmente, a CCR aceita clusters de dois nós, com cada nó mantendo uma cópia dos dados. Uma solução resiliente do site com base nesta tecnologia possui vários benefícios:
Ela garante que os dados da caixa de correio no centro de dados de backup esteja disponível para os clientes.
A replicação contínua move menos dados do que a maioria das soluções de terceiros.
Ela exige menos integração para criar uma solução resiliente do site.
Crie tabelas que identificam o comportamento de recuperação e os custos associados com as várias opções Para obter a tabela de custos, verifique se ela contém algumas opções que desafiam as práticas existentes. Use os fatos nas tabelas que você criar para projetar uma solução que:
Forneça a melhor solução para os requisitos comerciais.
Satisfaça os requisitos de custos.
Represente um nível de implantação e uma complexidade de operações que sua organização possa aceitar.
Produtos e componentes básicos
A implantação de produtos e componentes deve ser baseada em suas capacidades de atender a requisitos rigorosos de confiabilidade e disponibilidade. Considere esses requisitos como um ponto essencial no planejamento da disponibilidade. O investimento adicional necessário para atingir níveis ainda mais altos de disponibilidade será em vão e os níveis de disponibilidade não serão atingidos, se esses produtos e componentes básicos não forem confiáveis e forem propensos a falhas.
Processos de gerenciamento de serviços
Processos de gerenciamento de serviços eficientes contribuem para níveis mais altos de disponibilidade. Processos como gerenciamento de disponibilidade, gerenciamento de incidentes, gerenciamento de problemas e gerenciamento de alterações exercem um papel importante no gerenciamento geral do serviço de mensagens.
Gerenciamento de sistemas
O gerenciamento de sistemas deve oferecer monitoramento, diagnóstico e recuperação de erros automática para permitir rápida detecção e correção das falhas possíveis e reais.
Soluções especiais com redundância completa
Para conseguir uma disponibilidade contínua na faixa dos 100%, são necessárias soluções dispendiosas que incorporem redundância completa. Redundância é a técnica de melhorar a disponibilidade usando componentes duplicados. Para atender aos rigorosos requisitos de disponibilidade, esses componentes devem funcionar paralelamente e de forma autônoma.
Estabelecendo metas de disponibilidade e requisitos do SLA
A obtenção de níveis de disponibilidade altos começa com a implantação de produtos e componentes de boa qualidade. No entanto, esses produtos e componentes isoladamente não são capazes de fornecer os níveis contínuos de disponibilidade necessários. Você deve considerar as metas de disponibilidade no processo de estruturação, no primeiro estágio possível do desenvolvimento. Essa abordagem evita a possibilidade de custos elevados relacionados a retrabalho, atualizações não planejadas necessárias para atender à disponibilidade exigida, ferramentas não planejadas para monitorar a infra-estrutura, gastos imprevistos para eliminar pontos de falha únicos na infra-estrutura, manutenção e conservação.
Uma das primeiras etapas para alcançar a alta disponibilidade é rever o SLA que você estabeleceu para a sua organização. Depois de estabelecer um SLA, você pode determinar as configurações de implantação e de servidor do Exchange 2007 mais adequadas a esse acordo.
A seguir, as principais considerações para alta disponibilidade em relação à recuperação de desastres:
Inatividade permitida Considere o tempo máximo de inatividade permitida aceitável para sua organização, com base na definição de disponibilidade de serviço do Exchange da organização. Dependendo da definição de tempo de inatividade de sua organização, você pode conseguir atender ao SLA da organização usando uma estratégia de recuperação de sinal de linha de mensagem. Uma estratégia de recuperação de sinal de linha de mensagem abrange o oferecimento aos usuários de uma caixa de correio temporária, para que possam enviar e receber mensagens de email imediatamente após um desastre. Essa estratégia recupera rapidamente o serviço de email antes de recuperar dados históricos da caixa de correio. Geralmente, a recuperação é concluída com a eventual mesclagem dos dados de caixa de correio históricos e temporários.
Tempo de recuperação permitido Considere o tempo máximo permitido para cada tipo de operação de recuperação de desastres. Por exemplo, você deve especificar o período aproximado de tempo necessário para recuperar uma caixa de correio, um único banco de dados ou todo um servidor que esteja executando o Exchange 2007.
Tolerância à perda de dados Considere a tolerância que sua organização tem para a perda temporária ou permanente de dados do Exchange. Por exemplo, sua organização pode ser capaz de tolerar perda temporária de dados de caixa de correio desde o backup anterior por um período de 24 horas, desde que os usuários possam enviar e receber mensagens no prazo de 4 horas. Em outros casos, convém considerar requisitos mais rigorosos, como exigir que todos os dados do Exchange até o ponto de falha sejam restaurados no prazo máximo de 4 horas.
Depois de considerar o impacto da inatividade em sua organização e decidir o nível de tempo de atividade que deseja atingir em seu ambiente de mensagens, você está pronto para estabelecer um SLA. Os requisitos do SLA determinam como os componentes, como armazenamento, agrupamento em cluster e backup e recuperação, influenciam em sua organização.
Ao avaliar SLAs, você deve iniciar pela identificação das horas de operação regular e as expectativas em relação ao tempo de inatividade planejado. Você deve então determinar as expectativas de sua organização em relação a disponibilidade, desempenho e possibilidade de recuperação, inclusive tempo para entrega de mensagens, porcentagem de tempo de atividade do servidor, quantidade de armazenamento necessário e tempo para recuperação de um banco de dados do Exchange.
Além disso, você deve identificar o custo estimado de inatividade não programada, para definir a tolerância a falhas adequada em seu sistema de mensagens.
Os recursos do Exchange 2007 e do Windows Server 2003 podem afetar o modo como você projeta sua organização para atender aos SLAs. Por exemplo, LCR, CCR, SCCs, o VSS (Serviço de Cópia de Sombra de Volume), grupos de armazenamento de recuperação, portabilidade do banco de dados e recursos de portabilidade do sinal de linha podem permitir que você desafie os limites previamente impostos por seus SLAs.
A tabela a seguir lista algumas das categorias e elementos específicos que talvez seja coveniente incluir em seus SLAs.
Categorias e elementos em um SLA de nível empresarial típico
| Categorias de SLA | Exemplos de elementos de SLA |
|---|---|
Horas de operação |
|
Disponibilidade do serviço |
|
Desempenho do sistema |
|
Recuperação de desastres |
|
Assistência técnica e suporte |
|
Outro |
|
Incluir uma série de medidas de desempenho em seus SLAs ajuda a garantir que você esteja atendendo aos requisitos específicos de desempenho de seus usuários. Por exemplo, se houver alta latência ou baixa largura de largura de banda disponível entre clientes e servidores de caixa de correio, os usuários visualizariam o nível de desempenho de maneira diferente dos administradores do sistema. Especificamente, os usuários considerariam o nível de desempenho como fraco, embora os administradores de sistema considerem esse nível aceitável. Portanto, assegure-se de monitorar níveis de latência de entrada/saída (E/S) de disco.
Dica
Para cada elemento de SLA, você também deve determinar os limites de desempenho específicos para medir o desempenho juntamente com objetivos de disponibilidade. Além disso, você deve determinar a freqüência com que fornecerá estatísticas para gerenciamento de tecnologia de informação e outros gerenciamentos.
Estabelecendo Acordos de Nível de Serviço com Seus Fornecedores
Muitas empresas que dão importância às soluções de alta disponibilidade usam os serviços de fornecedores terceirizados para atingir seus objetivos de alta disponibilidade. Nesses casos, atingir um sistema de mensagens com alta disponibilidade exige serviços de fornecedores externos de hardware e software. Fornecedores sem agilidade e com equipe de vendas mal treinada podem reduzir a disponibilidade do sistema de mensagens.
Assegure-se de negociar um SLA com cada um de seus principais fornecedores. Estabelecer SLA com seus fornecedores ajuda a garantir que seu sistema de mensagens tenha um desempenho de acordo com as especificações, ofereça suporte para o crescimento necessário e esteja disponível para um padrão específico. A ausência de um SLA pode aumentar bastante o tempo de indisponibilidade do sistema de mensagens.
Importante
Verifique se sua equipe conhece os termos de cada SLA. Por exemplo, muitos SLAs de fornecedores de hardware contêm cláusulas que permitem apenas que o pessoal de suporte do fornecedor ou membros certificados da equipe de sua organização abram a caixa do servidor. A inobservância do cumprimento dessa cláusula pode resultar em violação do SLA e possível anulação de todas as garantias e responsabilidades.
Além de estabelecer um SLA com seus principais vendedores, você também deve testar periodicamente os procedimentos de escalação de testes, testando a solicitação de suporte. Para confirmar se você tem as informações de contato mais recentes, teste também os pagers e troncos de telefonia.
Considerações sobre disponibilidade
É recomendável que você considere as seguintes questões para determinar as necessidades de disponibilidade:
Conheça a vulnerabilidade a falhas do projeto de infra-estrutura proposto. Você deve certificar-se de que não existam pontos de falha isolados. Um ponto de falha isolado é qualquer componente da infra-estrutura de mensagens que não tem capacidade de redundância e pode afetar o usuário, quando falhar. O projeto técnico proposto para a solução deve englobar toda a configuração de ponta a ponta.
Considere os níveis mínimos de disponibilidade necessários à empresa para o serviço de mensagens, e os níveis mínimos de confiabilidade, manutenção e conservação de cada componente da infra-estrutura de mensagens.
Considere a capacidade de testar ou simular novos componentes para certificar-se de que correspondem aos requisitos especificados. Para verificar se os novos componentes do projeto podem corresponder aos requisitos especificados, é importante que o método de teste a ser utilizado garanta a disponibilidade prevista. Os testes também devem ser realizados quando os componentes são atendidos. Ferramentas de simulação para gerar a demanda de usuários prevista para o novo serviço de tecnologia de informação devem ser consideradas com muito cuidado para garantir que os componentes continuem funcionando em condições de stress e grande demanda.
Considerações sobre alta disponibilidade
Uma solução de mensagens de alta disponibilidade exige que você invista e implante uma solução de monitoramento, processos de gerenciamento de serviços, ferramentas de gerenciamento de sistemas e redundância. Para implantações com maior disponibilidade, é importante não existir qualquer ponto de falha isolado nessa configuração de ponta a ponta. O planejamento para alta disponibilidade deve considerar a eliminação de pontos de falha isolados e o fornecimento de componentes alternativos para causar o mínimo possível de interrupção na operação comercial, se ocorrer uma falha de componente. O planejamento também deve eliminar ou minimizar os efeitos da paralisação prevista na operação dos negócios, normalmente necessária para acomodar atividades de manutenção, como a implantação de alterações na infra-estrutura. Os critérios de recuperação devem definir restabelecimento de serviços e recuperação rápidos como objetivo principal do planejamento da fase de recuperação.
Ao desenvolver um plano de implantação para sua solução de mensagens, você deve identificar os objetivos da solução. Isso é especialmente importante quando você projeta as características de disponibilidade da solução. Freqüentemente, os objetivos de uma empresa resultam em contradições. Por exemplo, seus objetivos de disponibilidade podem incluir 100% de disponibilidade, exigindo ao mesmo tempo que as últimas atualizações de segurança sejam aplicadas dentro de uma semana a partir da data em que se tornem disponíveis. Os custos são outro fator que freqüentemente cria desafios para os planos de implantação. Seguir uma metodologia de planejamento que identifique todos os requisitos comerciais e avalie as opções disponíveis em relação a esses requisitos é a melhor abordagem para a identificação da solução correta para seu negócio.
A obtenção da alta disponibilidade exige foco contínuo nas práticas operacionais de sua organização. Todos os casos de interrupção precisam ser compreendidos. Para interrupções que possam ser impedidas por alterações no processo, as alterações de processo apropriadas precisam ser iniciadas.
Outro fator importante para a maximização da disponibilidade é o monitoramento proativo do ambiente do Exchange. Com monitoramento proativo, as áreas problemáticas no sistema podem ser identificadas antes de causarem falhas e interrupções. Além disso, o monitoramento pode alertar a equipe de operações sobre problemas que não são recuperados automaticamente pelo sistema. Em situações assim, uma resposta em tempo hábil pode diminuir a duração da interrupção, aumentando assim a disponibilidade.
O Exchange 2007 posiciona as dependências em infra-estrutura em uma central de dados. Como resultado, a disponibilidade do Exchange é sujeita à disponibilidade fornecida por suas dependências. Aconselhamos as organizações a estabelecer SLAs para cada dependência. O SLA deve especificar a disponibilidade do serviço fornecido e o tempo de recuperação quando ocorrer uma falha. Por exemplo, o serviço de diretório do Active Directory é uma dependência principal do Exchange. Se a disponibilidade do Active Directory for menor do que os objetivos de disponibilidade do Exchange, é provável que o Exchange não atinja seus objetivos.
A disponibilidade do Exchange 2007 depende da disponibilidade de outros serviços dentro da infra-estrutura de tecnologia da informação. Serviços como o Active Directory e rede devem estar funcionando para que o Exchange funcione. A disponibilidade desses serviços afeta diretamente a disponibilidade do Exchange. Entretanto, você deve garantir que as exigências de disponibilidade do Exchange não sejam maiores que a disponibilidade para suas dependências. Uma lista típica de dependências é:
Active Directory
Sistema de nome de domínio
Rede TCP/IP
Subsistema de armazenamento
Serviços de backup
Serviços de monitoramento
Infra-estrutura da central de dados (energia e ar condicionado)
Depois de estabelecer suas metas empresariais e seus SLAs para as dependências do Exchange, recomendamos que você desenvolva uma lista inicial de requisitos de disponibilidade para serviços de mensagens. A lista deve incluir todas as classes gerais de falha e o RTO (objetivo de tempo de recuperação) esperado. Para falhas relacionadas a dados, essa lista deve incluir uma indicação do impacto da falha sobre os dados. Isso pode ser especificado pela indicação de um RPO (objetivo de ponto de recuperação). Um RPO identifica o impacto nos dados especificando um tempo que define o nível de dados que estarão disponíveis após a recuperação. As falhas a serem consideradas devem incluir:
Item de mensagem único perdido
Caixa de correio única perdida
Banco de dados perdido ou danificado
Falha no disco
Falha ou dano em volume de disco
Falha em unidade de armazenamento
Falha do servidor
Conectividade de rede perdida
Falha da central de dados
Em muitas organizações, os requisitos de disponibilidade estabelecidos variam de acordo com o tipo de usuário. Por exemplo, alguns usuários podem usar o sistema de mensagens para rastrear entregas ou vendas, e outros podem usá-los para mensagens não-críticas. O RTO e RPO para usuários que dependem do sistema de mensagens para processos críticos deve ser o mais curto possível, enquanto que aqueles que usam o sistema de mensagens para processos não-críticos podem tolerar um RTO ou RPO mais longo.
Para obter mais informaçoes
Para obter mais informações sobre resiliência de site para o Exchange 2007, consulte Site Resilience Configurations.