Artigo original publicado na terça-feira, 6 de dezembro de 2011

Com as alterações na estratégia que anunciamos em O futuro do modo de hospedagem alguns meses atrás, queríamos aproveitar a oportunidade para esclarecer o que é suportado nos cenários de hospedagem.

Anunciamos que os hosters poderiam usar o Exchange 2010 SP2 para fornecer serviços hospedados do Exchange, assim que fossem liberados. Bem, acabamos de lançar o SP2 e agora também lançamos Orientação para multitenancy e hospedagem para o Exchange Server 2010 SP2 para ajudar o cliente a configurar suas soluções de maneira suportada. Criamos o site de orientação e soluções de multitenancy para reconhecer os fornecedores do painel de controle que oferecem detalhes adequados sobre suas soluções, para que possamos listá-las como tendo uma solução compatível. A orientação é voltada aos hosters e aos ISV, de painel de controle, mas também será útil para qualquer pessoa que tente criar um sistema do tipo multitenant (às vezes denominado nuvem privada), usando o Exchange 2010 SP2.

Atualização de 20 de dezembro: Acabamos de publicar Orientação da escala multitenant para o Exchange 2010 SP2, que contém uma orientação para escalar e implantar adequadamente uma solução multitenant do Exchange 2010 SP2.

A coisa mais importante para entender é que um hoster, um fornecedor de painel de controle ou qualquer pessoa que utilize e siga a orientação que publicamos para a criação de sua solução não é fundamentalmente diferente de qualquer outro cliente que implante o Exchange, mas opte por não alterar as configurações padrão. Nosso objetivo é que o suporte que oferecemos a você não seja diferente de outros clientes.

Por exemplo, se você for um cliente corporativo típico e implantar o Exchange, configurar algumas das Políticas do Catálogo de Endereços (ABPs), alterar algumas permissões do calendário e adicionar alguns milhares de domínios aceitos, obterá o suporte como sempre obteve, porque sua configuração utiliza apenas ferramentas e processos suportados. Como hoster ou criador de nuvem privada, não será diferente. Você também cria objetos, configura algumas ABPs e pode terminar com uma configuração incomum aos olhos de um cliente médio do Exchange, mas isso é tudo – incomum, personalizada conforme suas necessidades, mas suportada.

Aqui estão alguns exemplos para tentar esclarecer o que isso significa:

• Você telefona para nós com um problema do agente de transporte do Exchange e está claro que qualquer coisa que você cria não segue nenhuma da nossa orientação publicada de desenvolvimento. Iremos recomendar que você faca alterações para seguir a orientação, e esse conselho não muda se você é um hoster, um criador de uma nuvem privada ou uma organização corporativa.
• Você é um hoster e nos telefona para dizer que não consegue impedir que o OOF interno seja entregue entre os inquilinos da plataforma de hospedagem que você mesmo criou. Nós apontamos nossa orientação de hospedagem, onde dizemos claramente que esse é um problema conhecido nesse tipo de configuração e também que o documento sugere a abordagem certa para tentar resolvê-lo. Então, você quer abrir um caso de desenvolvedor separado para receber ajuda enquanto cria a solução.

Assim, como você pode ver, seja você um hoster ou um cliente corporativo, ou alguém que cria uma solução para hospedar diversos inquilinos de uma forma específica, e você usou ferramentas e métodos suportados para configurar o seu sistema, poderemos dar um suporte eficiente. Isso não é realmente diferente do que ocorre hoje, se você optar por fazer algumas mudanças incomuns no seu sistema, não pediremos para validar o sistema ponta a ponta antes de ajudá-lo a recuperar o banco de dados. Por outro lado, se o banco de dados falhou por causa de uma mudança incomum que você fez, iremos discutir por que você fez essas alterações e apontaremos que elas não são suportadas.

Se um fornecedor do painel de controle deseja vender a solução dele e ela está listada no nosso site, ele precisa nos fornecer uma confirmação por escrito de que a solução dele cumpre TODO o documento da orientação. Se ela cumprir apenas 90%, não será listada. Isso não impede que o fornecedor venda a solução dele, porque ele pode fazer isso sem que nós a analisemos, mas um cliente que quiser comprar não a verá listada no nosso site.

Portanto, em resumo, para os clientes que usam o Exchange 2010 SP2, iremos tratar nossos hosters e clientes corporativos da mesma forma – se a causa básica do seu problema for uma configuração ou operação não suportada, mostraremos isso e recomendaremos que você mude. O hoster pode realmente criar um sistema multitenant sem fazer qualquer alteração não suportada. A orientação que publicamos o ajudará, e recomendaremos que você a siga.

Gosto de pensar assim: nosso objetivo final ao fornecer a orientação e permitir que o hoster utilize o Exchange Server 2010 SP2 é garantir que ele tenha uma solução baseada em uma configuração suportada, que torne seu sistema igual ao de todos os outros. Realmente queremos que você receba suporte para o seu sistema quando você precisar, mas você precisa nos ajudar a ajudá-lo.

Greg Taylor

Este é um post de um blog localizado. Encontre o artigo original em Exchange 2010 Service Pack 2 and Hosting

Artigo original publicado em 08 de setembro de 2010, terça-feira

Um usuário está fora do escritório por algum motivo – em férias, doente ou em uma licença sabática ou ausência prolongada, ou viajando para um local remoto na empresa, e esquece de definir uma resposta automática, também conhecida como uma mensagem de ausência temporária ou OOF no Exchange/Outlook lingo. Como um administrador do Exchange, você recebe um email do gerente do usuário solicitando que você configure uma OOF para ele.

Nas versões anteriores do Exchange, você precisava acessar a caixa de correio do usuário para conseguir fazer isso. As mensagens de ausência temporária são armazenadas na árvore não IPM da caixa de correio de um usuário junto com outros metadados. Sem acessar a caixa de correio, não é possível modificar os dados dentro dela. Há duas maneiras para um administrador acessar uma caixa de correio:

1. Conceder a si mesmo a permissão de acesso completo a uma caixa de correio para a caixa de correio do usuário.
2. Alterar a senha do usuário e fazer logon como o usuário.

É seguro dizer que qualquer uma dessas opções é potencialmente perigosa. A primeira opção concede ao administrador acesso a todos os dados na caixa de correio do usuário. A segunda opção concede ao administrador acesso a todos os dados que a conta do usuário pode acessar dentro da sua empresa e bloqueia o usuário na sua própria conta (pois o usuário em questão não sabe mais a senha da conta).

No Exchange 2010, é possível configurar as opções de resposta automática para seus usuários sem usar nenhuma das opções acima. Você deve ser um membro de um grupo de funções que tem as funções de gerenciamento Destinatátios de email ou Opções do Usuário.

Configure as opções de resposta automática usando o painel de controle do Exchange

Para configurar uma resposta automática usando o ECP:

1. Em Correio > Opções, selecione Outro usuário (padrão Minha organização).
   
   Figura 1: Selecionar outro usuário

2. Selecione o usuário para o qual deseja configurar a resposta automática

3. Na nova janela, verifique se o nome do usuário é exibido na mensagem de alerta e clique em Diga às pessoas que está de férias
   
   Figura 2: Quando gerenciar outro usuário no ECP, um alerta próximo ao topo da página exibe o nome do usuário que você está gerenciando

4. Na guia Respostas automáticas, configure as opções de resposta automática para o usuário (consulte a captura de tela).

No Exchange 2007, introduzimos o recurso para criar mensagens de ausência temporária diferentes para destinatários externos e internos. Você também pode desativar ou ativar as mensagens de ausência temporária de acordo com o usuário e o domínio remoto nas configurações de Domínio Remoto. Para obter detalhes, consulte a postagem anterior Ausência temporária (OOF) do Exchange Server 2007.

Configure as opções de resposta automática usando o Shell

Esse comando programa respostas automáticas internas e externas de 8/9/2011 a 15/9/2011:

Set-MailboxAutoReplyConfiguration bsuneja@e14labs.com –AutoReplyState Scheduled –StartTime “9/8/2011” –EndTime “9/15/2011” –ExternalMessage “Mensagem External OOF aqui” –InternalMessage “Mensagem Internal OOF aqui”

Para configurar respostas automáticas para serem enviadas até que sejam desativadas (ou seja, sem uma programação), defina o parâmetro AutoReplyState como Habilitado e não especifique os parâmetros StarTime e EndTime. Para a sintaxe detalhada e descrições do parâmetro, consulte Set-MailboxAutoReplyConfiguration.

Esse comando recupera as configurações da resposta automática para uma caixa de correio.

Get-MailboxAutoReplyConfiguration bsuneja@e14labs.com

Esse comando desativa a resposta automática configurada para uma caixa de correio:

Set-MailboxAutoReplyConfiguration bsuneja@e14labs.com –AutoReplyState Disabled –ExternalMessage $null –InternalMessage $null

Bharat Suneja

Esta é uma postagem de blog traduzida. Encontre o artigo original em Configure Automatic Replies for a user in Exchange 2010

Artigo original publicado em 16 de setembro de 2011, sexta-feira.

Definições

Todos nós sabemos que no mundo do Microsoft Exchange DAG significa “Grupo de Disponibilidade de Banco de Dados”.

Banco de dados – porque em um servidor de caixa de correio do Exchange 2010 altamente disponível, o banco de dados, não o servidor, é a unidade de disponibilidade e é o banco de dados que pode falhar ou alternar entre vários servidores dentro de um DAG. Esse conceito é conhecido como mobilidade do banco de dados.

Grupo – como o escopo de disponibilidade é determinado pelos servidores da caixa de correio em um DAG combinado em um cluster de failover e trabalhando junto como um grupo.

Disponibilidade – essa palavra parece ser a menos óbvia e o termo mais ofuscado aqui (e também referido por ambos os outros termos). Ironicamente, isso tem uma definição matemática simples e tem um papel importante na compreensão geral dos princípios do design do Exchange.

A Wikipedia define “disponibilidade como o seguinte:

• O grau em que um sistema, subsistema ou equipamento está em um estado confirmável e operável especificado no início de uma missão, quando a missão é solicitada a um desconhecido, ou seja, um tempo aleatório. Simplificando, disponibilidade é a proporção de tempo e que um sistema está na condição de funcionamento. Isso é frequentemente descrito como uma taxa de missão capaz. Matematicamente, ela é expressa como 1 menos indisponibilidade.
• A proporção do (a) tempo total que uma unidade funcional é capaz de ser usada durante um determinado intervalo para (b) a duração do intervalo.

Usando os termos da teoria da probabilidade, ambas as definições significam a mesma coisa: probabilidade que um determinado sistema ou componente seja “operável” ou “capaz de ser usado” (ou seja, disponível) em um momento aleatório do tempo (quando testamos).

Matematicamente isso pode ser medido calculando a quantidade de tempo quando o sistema está disponível (“duração do serviço”) durante algum período estendido representativo estatisticamente (em geral, um ano), e dividindo pela duração total do período. Usando termos amplamente adotados de Tempo de Intervalo entre Falhas (MTBF) e Tempo de Intervalo para Reparo (MTTR) – o primeiro representa a disponibilidade/duração do serviço do sistema entre as falhas, enquanto o último representa o tempo de inatividade do sistema durante qualquer falha determinada, – disponibilidade pode ser expressa como uma fração:

A característica matemática oposta seria uma probabilidade de falha (pense em “não disponibilidade”):

A disponibilidade frequentemente é expressa como “número de noves”, de acordo com a tabela a seguir:

Nível da disponibilidade	Valor da disponibilidade	Probabilidade de falha	Tempo de inatividade aceito por ano
Dois noves	99%	1%	5.256 minutos = 3,65 dias
Três noves	99,9%	0,1%	525,6 minutos = 8,76 horas
Quatro noves	99,99%	0,01%	52,56 minutos
Cinco noves	99,999%	0,001%	5,26 minutos

É claro que o valor da disponibilidade seria diferente, dependendo se considerarmos o tempo de inatividade programado (planejado) e não programado (não planejado) ou basta apenas o tempo de inatividade não programado. O Contrato de Nível de Serviço que representa os requisitos de disponibilidade comercial deve ser muito específico sobre isso. Mas em todos os casos a disponibilidade de qualquer sistema ou componente determinado depende de muitos fatores e é absolutamente importante identificar e compreender essas dependências e como elas causam impacto na disponibilidade.

Como as dependências do serviço causam impacto na disponibilidade

A disponibilidade do banco de dados da caixa de correio do Exchange depende da disponibilidade de muitos outros serviços e componentes – por exemplo, o subsistema de armazenamento que hospeda o banco de dados, o servidor que opera esse banco de dados, a conectividade da rede para esse servidor, etc. Todos esses são componentes essenciais, e a falha em um único deles pode significar a perda do serviço, mesmo se o próprio banco de dados estiver em perfeitas condições. Isso significa que para o banco de dados estar disponível como um serviço, cada dependência única do banco de dados deve estar disponível também. Se identificarmos e isolarmos corretamente os componentes de dependência, podemos calcular matematicamente como eles determinam a disponibilidade resultante do próprio banco de dados da caixa de correio do Exchange.

Para um determinado banco de dados da caixa de correio do Exchange, os seguintes componentes podem ser considerados dependências críticas:

• Disco do banco de dados/subsistema de armazenamento – vamos dizer que sua disponibilidade é A₁;
• Servidor da caixa de correio (ambos os componentes de hardware e software) – dizemos que sua disponibilidade é A₂;
• Servidor de acesso para cliente (ambos os componentes de hardware e software) – lembre-se de que todos os clientes do Exchange 2010 se conectam ao banco de dados da caixa de correio somente via Servidor de acesso para cliente, e vamos supor que o CAS esteja instalado separadamente a partir do servidor da caixa de correio nesse caso – sua disponibilidade é A₃;
• Conectividade de rede entre clientes e o servidor de Acesso do cliente e entre o servidor de Acesso do cliente e o servidor de caixa de correio – sua disponibilidade é A₄;
• Potência no datacenter onde os servidores e o armazenamento estão localizados – sua disponibilidade é A₅;

Essa lista poderia continuar… Por exemplo, Active Directory e DNS representam a dependência crítica também parra o Exchange. E mais, além das dependências tecnológicas puras, a disponibilidade é influenciada por dependências do processo, como maturidade operacional e assim em diante: erro humano, operações definidas incorretamente, falta de coordenação da equipe, todos poderiam levar a inatividade do serviço. Não tentaremos compilar nenhuma lista extensa de dependências, mas em vez disso nos concentramos em como elas causam impacto na disponibilidade geral do serviço.

Como esses componentes são individualmente independentes uns dos outros, a disponibilidade de cada um representa um evento independente, e a disponibilidade resultante de um banco de dados da caixa de correio do Exchange representa uma combinação de todos esses eventos (em outras palavras, para um banco de dados da caixa de correio ficar disponível para os clientes todos esses componentes devem estar disponíveis). Na teoria da probabilidade, a probabilidade de uma combinação de eventos independentes é um produto das probabilidades individuais de cada evento:

Por exemplo, se você jogar três moedas, a probabilidade de obter caras em todas as três moedas é (1/2)*(1/2)*(1/2) = 1/8.

É importante perceber que como cada valor da disponibilidade individual não pode ser superior a 1 (ou 100%), e a disponibilidade do serviço resultante é simplesmente um produto das disponibilidades do componente individual, o valor da disponibilidade resultante não pode ser superior a menor das disponibilidades do componente dependente.

Isso pode ser ilustrado com o exemplo apresentado na tabela a seguir (os números aqui são amostras, mas muito realistas):

Nesse exemplo, você pode ver como as dependências de serviço são criticamente importantes. Mesmo para um banco de dados da caixa de correio que nunca falha (nunca é corrompida, nunca é infectada por vírus, etc.), a disponibilidade ainda permanece abaixo de 93,5%!

Conclusão: muitas dependências de serviço reduzem a disponibilidade.

Tudo o que você pode fazer para reduzir o número ou o impacto das dependências do serviço causará impacto positivo na disponibilidade geral do serviço. Por exemplo, você pode melhorar a maturidade operacional simplificando e protegendo o gerenciamento do servidor e otimizando os procedimentos operacionais. No lado técnico, você pode tentar reduzir o número de dependências do serviço tornando seu design mais simples – por exemplo, eliminando design complexo baseado em SAN, incluindo cartões HBA, comutadores de fibra, controladores de matriz e até mesmo controladores RAID e substituindo-o por um design DAS simples com um mínimo de peças móveis.

A redução nas dependências do serviço sozinha pode não ser suficiente para trazer a disponibilidade para o nível desejado. Outra maneira muito eficiente para aumentar a disponibilidade resultante e minimizar o impacto das dependência de serviço é aproveitar vários métodos de redundância, como utilizar fontes de alimentação duplas, placas de rede unidas, servidores de conexão em comutadores de rede múltiplos, usando a proteção RAID do sistema operacional, implementar balanceadores de carga para servidores de Acesso do Cliente e várias cópias dos bancos de dados da caixa de correio. Mas como exatamente a redundância aumenta a disponibilidade? Vamos olhar mais atentamente o balanceamento de carga e várias cópias do banco de dados como exemplo importantes.

Como a redundância causa impacto na disponibilidade

Conceitualmente, todos os métodos de redundância significam uma coisa: há mais de uma instância de componentes disponível e pode ser usado simultaneamente com outras instâncias (como no balanceamento de carga) ou como uma substituição (como nas várias cópias do banco de dados). Vamos supor que temos n instâncias de um determinado componente (n servidores em uma matriz CAS ou n cópias do banco de dados em um DAG). mesmo se um deles falhar, as outras instâncias ainda podem ser usadas, mantendo assim a disponibilidade. A única situação quando enfrentamos inatividade real é quando todas as instâncias falham.

Conforme definido anteriormente, a probabilidade de falha para qualquer instância fornecida é P = 1 – A. Todas as instâncias são estatisticamente independentes umas das outras, o que significa que a disponibilidade ou falha de qualquer uma delas não causa impacto na disponibilidade de outras instâncias. Por exemplo, a falha de uma determinada cópia do banco de dados não causa impacto na probabilidade de falha de outra cópia daquele banco de dados (uma possível advertência aqui pode ser a corrupção do banco de dados lógico propagando da primeira cópia do banco de dados danificado para todas as outras cópias, mas vamos ignorar isso fator altamente improvável por enquanto – afinal, você sempre pode implementar uma cópia defasada do banco de dados ou um backup tradicional do ponto no tempo para tratar disso).

Novamente usando o mesmo teorema da teoria da probabilidade, a probabilidade de ralha de um conjunto de n componentes independentes é um produto das probabilidades de cada componente. Como todos os componentes aqui são idênticos (instâncias diferentes do mesmo objeto), o produto torna-se uma potência:

Aparentemente, pois P < 1, Pⁿ é inferior a P, o que significa que a probabilidade de falha reduz e como consequência a disponibilidade aumenta:

Para esclarecer, vamos considerar alguns exemplos da vida real. Digamos que estamos implementando várias cópias do banco de dados da caixa de correio, cada cópia é hospedada em uma única unidade SATA. Estatisticamente, a taxa de falha das unidades SATA é ~5% em um ano[1], que nos dá 5% de probabilidade de falha: P = 0,05 (que significa disponibilidade de 95%: A = 0,95). Como a disponibilidade mudará conforme adicionamos mais cópias do banco de dados? Olhe a tabela a seguir que deve ser autoexplicativa:

Muito impressionante, não é? Basicamente, cada cópia adicional do banco de dados na unidade SATA introduz o fator de multiplicação de 5% ou 1/20, assim a probabilidade de falha torna-se 20 vezes menor com cada cópia (e, de modo correspondente, a disponibilidade aumenta). Você pode ver que mesmo com as unidades SATA mais suspeitas implementar apenas 4 cópias do banco de dados trás disponibilidade do banco de dados para cinco noves.

Isso já é muito bom, mas pode ficar ainda melhor? Posso aumentar a disponibilidade ainda mais mesmo fazendo alterações na arquitetura (por exemplo, se adicionar ainda outra cópia do banco de dados estiverfora de questão)?

Realmente, é possível. Se você melhorar a disponibilidade individual de qualquer componente de dependência, isso será fator de aumento na disponibilidade geral do serviço, e leva a um efeito muito mais forte de adicionar componentes redundantes. Por exemplo, uma maneira possível para fazer isso sem quebrar a banca é usar unidades Nearline SAS em vez de unidades SATA. As unidades SAS têm uma taxa de falha anual de ~2,75% em vez dos ~5% da SATA. Isso reduzirá a probabilidade de falha para o componente de armazenamento no cálculo acima e, por isso, aumenta a disponibilidade geral do serviço. Basta comparar o impacto da adição de várias cópias do banco de dados:

• 5% AFR = fator de multiplicação 1/20 = cada nova cópia torna a falha do banco de dados 20 vezes menos provável.
• 2,75% AFR = fator de multiplicação de 1/36 = cada nova cópia torna a falha do banco de dados 36 vezes menos provável.

Esse impacto significativo que as cópias adicionais do banco de dados têm na disponibilidade do banco de dados também explica nossa orientação em como utilizar a proteção de dados nativos do Exchange que diz que várias cópias do banco de dados podem ser substituídas por backups tradicionais se um número suficiente (três ou mais) de cópias do banco de dados for implementado.

A mesma lógica se aplica à implementação de vários servidores de acesso para clliente em uma matriz CAS, vários comutadores de rede, etc. Vamos supor que implementamos 4 cópias do banco de dados e 4 servidores de Acesso do Cliente, e vamos revisitar a tabela de disponibilidade do componente que analisamos anteriormente:

Você pode ver como apenas porque implantamos 4 servidores de Acesso do Cliente e 4 cópias do banco de dados, a probabilidade de falha do serviço geral diminuiu mais do que 10-fold (de 6,5% a 0,6%) e disponibilidade do serviço aumenta de forma correspondente de 93,5% para um valor muito mais aceitável de 99,4%!

Conclusão: adicionar redundância às dependências do serviço aumenta a disponibilidade.

Juntando as peças

Uma questão interessante surge das conclusões anteriores. Analisamos dois fatores diferentes que causam impacto na disponibilidade geral do serviço de duas maneiras diferentes e descobrimos duas conclusões claras:

• adicionar mais dependências do sistema reduz a disponibilidade
• adicionar redundância às dependências do sistema aumenta a disponibilidade

O que acontece se os ambos forem fatores de uma determinada solução? Qual tendência é mais forte?

Considere o seguinte cenário:

Implementamos dois servidores de caixa de correio em um DAG com duas cópias do banco de dados da caixa de correio (uma cópia em cada servidor) e implementamos dois servidores de Acesso do Cliente em uma matriz com carga balanceada. (Para simplificar, só consideraremos a disponibilidade de um banco de dados da caixa de correio para conexões do cliente, deixando o Transporte de Hub e a Unificação de Mensagens fora de consideração por enquanto). Supondo que cada servidor tem sua probabilidade de falha individual de P, a disponibilidade desse sistema será melhor ou pior do que a disponibilidade de um único servidor autônomo do Exchange com funções de servidor de Caixa de Correio e Acesso do Cliente implementadas?

No primeiro cenário, os servidores de Caixa de Correio são independentes e ficarão indisponíveis somente se ambos os servidores falharem. A probabilidade de falha para o conjunto de dois servidores da caixa de correio será P × P = P². De modo correspondente, sua disponibilidade será A_MBX = 1 – P². Seguindo a mesma lógica, o serviços CAS estarão indisponíveis somente se ambos os servidores de Acesso do Cliente falharem, assim a probabilidade de falha para o conjunto de dois servidores de Acesso do Cliente serão novamente P × P = P², e de modo correspondente, sua disponibilidade será A_CAS = 1 – P².

Nesse caso, conforme você pode imaginar, dois servidores de caixa de correio ou dois servidores de Acesso do Cliente são exemplos de componentes redundantes do sistema.

Continuando com esse cenário… Para o sistema inteiro estar disponível, os dois conjuntos de servidores (conjunto de servidores de caixa de correio e Acesso do Cliente) devem estar disponíveis simultaneamente. Não falharem simultaneamente, mas estarem disponíveis simultaneamente, porque agora eles representam dependências do sistema em vez de componentes redundantes. Isso significa que a disponibilidade geral do serviço é um produto de disponibilidades de cada conjunto:

Certamente, o segundo cenário é muito mais simples, pois há apenas um servidor para considerar e sua disponibilidade é simples A = 1 – P.

Então, agora que calculamos os valores da disponibilidade para ambos os cenários, qual valor é maior, (1-P²)² ou 1-P?

Se marcarmos os gráficos de ambas as funções, veremos o seguinte comportamento:

(Eu usei o mecanismo computacional grátis Wolfram Alpha Mathematica Online para marcar de maneira rápida e fácil).

Podemos ver isso para os valores pequenos de P, a disponibilidade do sistema complexo de quatro servidores é maior que a disponibilidade do servidor único. Não há surpresa; isso é o que esperamos, certo? Entretanto, em P ~ 0.618 (mais precisamente, ) os dois marcadores cruzam e para valores maiores de P o sistema de servidor único realmente tem maior disponibilidade. Claro que você esperaria que o valor de P estivesse muito próximo a zero na vida real; entretanto, se você estiver planejando criar sua solução a partir de componentes muito suspeitos, provavelmente seria melhor com um único servidor.

Impacto da falha de domínios

Infelizmente, cenários de implementação da vida real raramente são tão simples quanto as situações discutidas acima. Por exemplo, como alterar a disponibilidade do serviço se você implementar servidores multifunção? Observamos no cenário acima que combinando as funções do servidor reduz efetivamente o número de dependências do serviço, então, provavelmente seria uma coisa boa? O que acontece se você colocar duas cópias do banco de dados do mesmo banco de dados na mesma matriz SAN ou invólucro DAS? O que acontece se todos os seus servidores de caixa postal estiverem conectados ao mesmo comutador de rede? O que acontece se você tiver todos acima e mais?

Todas essas situações lidam com o conceito de falha de domínios. Nos exemplos acima, o hardware do servidor ou uma matriz SAN, ou um comutador de rede representam uma falha do domínio. A falha do domínio interrompe a independência ou redundância dos componentes que ele combina – por exemplo, a falha do hardware do servidor em um servidor multifunção significa que todas as funções do Exchange nesse servidor ficam indisponíveis; de modo correspondente, a falha de um invólucro de disco ou de uma matriz SAN significa que todas as cópias do banco de dados hospedadas nesse invólucro ou matriz fica indisponível.

As falhas de domínio não são necessariamente uma coisa ruim. A diferença importante é que tipo de componentes constituem uma falha de domínio – são diferentes dependências do sistema ou componente redundantes do sistema. Vamos considerar dois exemplos acima para compreender essa diferença.

Cenário do servidor multifunção

Vamos comparar a disponibilidade de dois sistemas diferentes:

1. As funções dos servidores de caixa de correio e de Acesso do cliente hospedados no mesmo servidor que tem a probabilidade de falha de hardware de P;
2. As mesmas funções hospedadas em dois servidores separados, cada um com a mesma probabilidade de falha de hardware;

No primeiro caso, o hardware de um servidor único representa uma falha de domínio. Isso significa que todas as funções hospedadas estão todas disponíveis ou indisponíveis. Isso é simples; a disponibilidade geral desse sistema é A = 1 – P.

No segundo caso, o serviço geral estará disponível somente quando ambos os servidores estiverem disponíveis independentemente (porque cada função representa uma dependência crítica). Por isso, baseado na teoria da probabilidade, sua disponibilidade será A × A = A².

Novamente, como A < 1, isso significa que A² < A, então, a disponibilidade no segundo caso será menor.

Aparentemente, podemos adicionar outras funções do servidor do Exchange (Transporte de Hub e Unificação de Mensagens, se necessário) para o mesmo cenário sem interromper essa lógica.

Conclusão: a colocação das funções do servidor do Exchange em um servidor multifunção aumenta a disponibilidade geral do serviço.

Cenário de armazenamento compartilhado

Agora vamos considerar outro cenário de falha de domínio (duas cópias de banco de dados compartilhando a mesma matriz de armazenamento) e compara a disponibilidade do banco de dados nos dois casos a seguir:

1. Duas cópias do banco de dados hospedadas no mesmo armazenamento compartilhado (matriz SAN ou invólucro DAS), que tem a probabilidade de falha de P;
2. As mesmas cópias do banco de dados hospedadas em dois sistemas de armazenamento separados, cada um com a mesma probabilidade de falha;

No primeiro caso, o armazenamento compartilhado representa uma falha do domínio. Como no cenário anterior, isso significa que ambas as cópias do banco de dados estão disponíveis ou indisponíveis simultaneamente, então a disponibilidade geral é novamente A = 1 – P.

No segundo caso, o serviço geral estará disponível se pelo menos um sistema estiver disponível, e indisponível somente se ambos os sistemas falharem. Os sistemas de armazenamento em questão são independentes, por isso, a probabilidade de falha do serviço geral é P × P = P² e de modo correspondente a disponibilidade geral do serviço é A = 1 – P².

Novamente, como P < 1, isso significa que P² < P e, por isso, 1 – P² > 1 – P. Isso significa que a disponibilidade no segundo caso é maior.

Conclusão: a colocação das cópias do banco de dados no mesmo sistema de armazenamento reduz a disponibilidade geral do serviço.

Então, qual é a diferença entre esses dois cenários, porque a introdução de uma falha de domínio aumenta a disponibilidade no primeiro caso e reduz a disponibilidade no segundo caso?

É porque a falha de domínio no primeiro caso combina dependências de serviço, reduzindo efetivamente seus números e melhorando a disponibilidade, enquanto a falha de domínio no segundo caso combina componentes redundantes, reduzindo efetivamente a redundância e prejudicando a disponibilidade.

Todos esses conceitos e conclusões provavelmente seriam visualizados como segue:

(Não, nós não usamos o Wolfram Alpha para desenhar esse gráfico!)

Resumo

A arquitetura do Exchange 2010 oferece possibilidades poderosas para adicionar redundância no nível do Exchange (como implantação de várias cópias do banco de dados ou vários servidores de Acesso do Cliente em uma matriz CAS) e para reduzir o número de dependências do sistema (combinando funções do servidor do Exchange em um servidor multifunção ou usando arquitetura de armazenamento mais simples sem um número excessivo de componentes críticos). A regras e fórmulas simples apresentadas nesse artigo permitem calcular o efeito no valor da disponibilidade da implantação das cópias do banco de dados ou da combinação de funções do servidor do Exchange; você também pode calcular o impacto de falhas do domínio. É importante observar que tentamos usar esses modelos matemáticos simples para ilustrar os conceitos, não fingir para obter os valores precisos da disponibilidade. A vida real raramente apresenta os cenários básicos simples e você precisa de cálculos muito mais complexos para obter estimativas razoáveis para a disponibilidade dos seus sistemas reais; pode ser mais fácil para simplesmente medir a disponibilidade estatisticamente e verificar e ela atende aos requisitos SLA. Entretanto, a compreensão dos fatores que causam impacto na disponibilidade e como eles funcionam juntos em uma solução de engenharia complexa deve ajudar a projetar a solução de maneira adequada e obter um aumento significativo na disponibilidade geral do serviço, atendendo até mesmo os requisitos comerciais mais exigentes.

Boris Lokhvitsky
Arquiteto de entrega

[1] Os seguintes estudos realizados pela Carnegie Mellon University, pelo Google e pela Microsoft Research mostram 5% AFR para unidades SATA:

http://www.usenix.org/events/fast07/tech/schroeder/schroeder.pdf

http://labs.google.com/papers/disk_failures.pdf

http://research.microsoft.com/research/pubs/view.aspx?msr_tr_id=MSR-TR-2005-166

Esta é uma postagem de blog localizada. Leia o artigo original em DAG: Beyond the “A”

Artigo original publicado em 11 de outubro de 2011, terça-feira.

Passaram-se alguns meses desde que anunciamos algumas mudanças básicas nas instruções do suporte de virtualização do Exchange 2010 (consulte Anunciando suporte aprimorado de virtualização do hardware para Exchange 2010). Durante esse tempo, recebi algumas perguntas excelentes sobre os cenários de implantação específicos e como as alterações nas nossas instruções de suporte podem afetar essas implementações. Dado o volume de perguntas, parecia uma excelente oportunidade para postar algumas informações adicionais e esclarecimento.

Em primeiro lugar, um pouco de história. Quando fizemos as alterações nas nossas instruções de suporte, a primeira coisa que queríamos era garantir que os nossos clientes não iriam entrar em um estado em que a disponibilidade do serviço do Exchange pudesse ser reduzida como resultado do uso de uma implementação virtualizada. Em outras palavras, queríamos ter certeza de que o alto nível de disponibilidade pudesse ser obtido com uma implementação física do produto Exchange 2010 não seria de maneira nenhuma reduzido pela implementação de uma plataforma de virtualização. Claro, queríamos também garantir que o produto permanecesse funcional e que verificaríamos se a funcionalidade adicional fornecida pela pilha de virtualização não proporcionaria perda de nenhum dado do Exchange durante a operação normal.

Considerando esses pontos, aqui está uma visão geral rápido do que mudamos e o que isso realmente significa.

Com o Exchange 2010 SP1 (ou posterior) implantado:

• Todas as funções do servivor do Exchange 2010, incluindo Unificação de Mensagens, são suportadas em uma máquina virtual.
• As máquinas virtuais de Unificação de Mensagens têm os seguintes requisitos especiais:
  • Quatro processadores virtuais são necessários para a máquina virtual. A memória deve ser dimensionada usando a orientação padrão das práticas recomendadas.
  • Quatro núcleos do processador físico estão disponíveis para uso o tempo todo para cada máquina virtual da função Unificação de Mensagens. Esse requisito significa que nenhuma subscrição excessiva do processador pode estar em uso. Esse requisito afeta a capacidade da máquina virtual da função Unificação de Mensagens utilizar recursos do processador físico.
• As máquinas virtuais do servivor do Exchange (incluindo as máquinas virtuais da caixa de correio do Exchange que fazem parte de um DAG), podem ser combinadas com cluster de failover baseado no host e tecnologia de migração, sempre que as máquinas virtuais forem configuradas de formr a não salvar e restaurar o estado no disco quando movivo ou colocado offline. Toda atividade de failover deve resultar em uma inicialização a frio quando a máquina virtual for ativada no nó de destino. Toda migração planejada deve resultar em desligamento e inicialização a frio, ou em uma migração online que utilizar uma tecnologia como a migração ao vivo Hyper-V. A migração do hipervisor de máquinas virtuais é suportada pelo fornecedor do hipervisor; por isso, você deve garantir que seu fornecedor de hipervisor tenha sido testado e suporte a migração das máquinas virtuais do Exchange. A Microsoft oferecer suporte à migração ao vivo Hyper-V dessas máquinas virtuais.

Vamos repassar algumas definições para ter certeza de que estamos todos pensando sobre os termos nas instruções de suporte da mesma maneira.

• Inicialização a frio Isso ser refere à ação de ativar um sistema a partir de um estado desativado para um início limpo do sistema operacional. Nenhum estado do sistema operacional tem sido persistente nesse caso.
• Estado salvo Quando uma máquina virtual é desativada, geralmente os hipervisores têm a capacidade de salvar o estado da máquina virtual nesse momento para que quando a máquina seja ativada novamente, ela retorno para aquele estado em vez de ir para uma partida de “inicialização a frio”. O “estado salvo” seria o resultado de uma operação “Salvar” no Hyper-V.
• Migração planejada Quando um administrador do sistema inicia a transferência de uma máquina virtual de um host do hipervisor para outro, chamamos isso de migração planejada. Essa pode ser uma migração única ou um administrador do sistema pode configurar alguma automação que seja responsável pela transferência da máquina virtual em uma base programada ou como resultado de algum outro evento que ocorre no sistema diferente de falha do hardware ou do software. O ponto principal aqui é que a máquina virtual do Exchange está operando normalmente e precisa ser realocada por algum motivo – isso pode ser feito através de uma tecnologia como a migração ao vivo ou vMotion. Se a máquina virtual do Exchange ou o host do hipervisor onde a VM está localizada apresentar algum tipo de condição de falha, o resultado disso seria não ser “planejado”.

Virtualizando servivores de Unificação de Mensagens

Uma das alterações feitas foi a adição de suporte para a função Unificação de Mensagens no Hyper-V e outros hipervisores suportados. Como mencionei no início desse artigo, queríamos garantir que todas as alterações feitas na nossa instrução de suporte resultasse no produto permanecendo totalmente funcional e proporcionar o melhor serviço possível aos nossos usuários. Como tal, precisamos que o Exchange Server 2010 SP1 seja implementado para suporte à UM. O motivo para isso é bem simples. A função UM depende de um componente de mídia fornecido pela equipe da Microsoft Lync. Nossos parceiros na Lync fizeram algum trabalho antes da liberação do Exchange 2010 SP1 para permitir processamento de áudio de alta qualidade em tempo real em uma implantação virtual e na liberação SP1 do Exchange 2010 integramos essas alterações na função UM. Depois disso, fizemos alguns testes adicionais para garantir que a experiência do usuário fosse o mais ideal possível e modificamos a nossa instrução de suporte.

Como você notará, temos exigências específicas sobre a configuração da CPU para máquinas virtuais (e máquinas do host do hipervisor) nas quais a UM está sendo executada. Essa é uma segurança adicional contra a má experiência do usuário (que aparecem como baixa qualidade de voz).

Cluster de failover baseado no host & Migração

Grande parte da confusão em torno da instrução de suporte alterada decorre da combinação de detalhes sobre a tecnologia do cluster de failover baseado no host & migração com o 2010 DAGs). A orientação aqui é realmente muito simples.

• Primeiro, vamos falar sobre se oferecemos suporte à tecnologia de migração de terceiros (como o VMotion da VMware). A Microsoft não pode criar instruções de “suporte” para integração dos produtos hipervisor de terceiros usando essas tecnologias com o Exchange 2010, pois essas tecnologias não fazem parte do programa de Validação de Virtualização de Servivores (SVVP) que abrange outros aspectos do nosso suporte para hipervisores de terceiros. Criamos uma instrução genérica aqui sobre o suporte, mas, além disso, você precisa garantir que seu fornecedor hipervisor suporta a combinação da sua tecnologia de migração/cluster com o Exchange 2010. Para simplificar o máximo possível: se o seu fornecedor hipervisor oferecer suporte à tecnologia de migração com o Exchange 2010, ofereceremos suporte do Exchange 2010 com sua tecnologia de migração.

• Em segundo lugar, vamos falar sobre como definimos o cluster de failover baseado no host. Isso se refere a todo tipo de tecnologia que oferece capacidade automática para reagir em falhas no nível do host e inicias as VMs afetadas em servivores alternativos. O uso dessa tecnologia é realmente suportado dentro da instrução de suporte fornecida, supondo que esteja em um cenário de falha, a VM será ativada a partir de uma inicialização a frio no host alternativo. Queremos garantir que a VM nunca será ativada a partir do estado salvo que é persistente no disco, pois ela estará “parada” em relação ao resto dos membros do DAG.

• Em terceiro lugar, quando se trata de tecnologia de migração na instrução de suporte, falaremos sobre todo tipo de tecnologia quer permite uma transferência planejada de uma VM de uma máquina do host para outra. Além disso, esta pode ser uma transferência automatizada que ocorre como parte do recurso de balanceamento de carga (mas não está relacionado a uma falha no sistema). As migrações são realmente suportadas enquanto as VMS nunca são ativadas a partir do estado saldo que é persistente no disco. Isso significa que a tecnologia que mova uma VM através do transporte do estado e a memória da VM na rede sem tempo de inatividade percebido são suportado para uso com o Exchange 2010. Observe que um fornecedor hipervisor de terceiros deve fornecer suporte para a tecnologia de migração, enquanto a Microsoft fornecerá suporte para o Exchange quando usado nesta configuração. No caso do Microsoft Hyper-V, isso significa que a migração ao viso é compatível, mas a migração rápida não.

Com o Hyper-V, é importante estar ciente de que o comportamento padrão ao selecionar a operação “Mover” em uma VM é realmente executar uma migração rápida. Para ficar em um estado suportado com os membros do Exchange 2010 SP1 DAG, é essencial ajustar esse comportamento conforme mostrado nas configurações da VM abaixo (as configurações exibidas aqui representam como você deve fazer a implantação com o Hyper-V):

Vamos revisar. No Hyper-V, a migração ao vivo é suportada para membros do DAG, mas a migração rápida, não. Visualmente, isso significa que isso é suportado:

E isso não é suportado:

Esperamos que isso ajude a esclarecer nossa instrução de suporte e orientação para as alterações do SP1. Aguardamos ansiosamente qualquer comentário que você queira nos fazer!

Jeff Mealiffe

Esta é uma postagem de blog localizada. Consulte o artigo original em Demystifying Exchange 2010 SP1 Virtualization

Artigo original publicado em 19 de agosto de 2100, sexta-feira.

Depois de um verão cheio de eventos da Microsoft reunindo parceiros, clientes e nossa organização de vendas interna, pensei em compartilhar algumas das discussões que eu tive com esses grupos em torno da nossa evolução nas nuvens e, especificamente, en torno do Exchange Online. Uma das coisas principais na qual estivemos envolvido é nosso ciclo de desenvolvimento para o serviço online como comparado com o lado do software do servidor. O Exchange Online é o maior exemplo dessa mudança, e é algo que sempre me perguntam nas principais experiências do cliente em ambas as soluções.

Há grandes lições do mundo do servidor no local que influenciam o Exchange Online, como o compromisso com o grau de qualidade da empresa, segurança, privacidade e, acima de tudo, ser adequado às necessidades do cliente. E, também há algumas diferenças principais entre as duas ofertas, como a cadência da liberação. Com um serviço online, há a capacidade de fazer alterações regularmente como muitos serviços ao consumidor, como fazem o Bing e o Windows Live. Para um serviço comercial como o Exchange Online, adotamos uma abordagem um pouco diferente para a nossa cadência de liberação que atrai tanto os comentários do cliente e a nossa experiência com software comercial, aproveitando a flexibilidade dos serviços.

Com o Office 365 e o Exchange Online, adotamos a abordagem de serviço e fornecemos recursos melhores e mais recentes aos nossos clientes, porque sabemos que recursos atualizados orientam a satisfação do cliente (consulte nosso Partner Blog). Entretanto, também reconhecemos que mesmo com o Exchange Online, os clientes precisam com frequência gerenciar a verificação de TI, treinamento e comunicações do usuário para o suporte correto dos novos recursos que estão sendo lançados. Apreciamos muito esse aspecto da funcionalidade dos lançamentos baseados no que os clientes nos disseram ao longo dos anos, e temos uma abordagem única para fornecimento contínuo de recursos e capacidades de serviço, e a sensibilidade de saber como isso afeta os nossos clientes.

Nossa cadência de liberação do Exchange Online tem três camadas –

1. Atualizações contínuas de serviços: Isso acontece duas vezes por semana e os bastidores das melhorias dos serviços são transparentes para o cliente.
2. Recurso adicional e liberações de capacidades a cada 90 dias: estes são novos recursos ou capacidades de serviços que agregam um novo valor para os clientes, mas não necessariamente acionam novo treinamento significativo ou ruptura na experiência do usuário. Quando aplicável, os administradores de serviço podem decidir se criam os recursos disponíveis para os usuários finais.
3. Liberações dos principais recursos e capacidades a cada 12-24 meses: esses são recursos e capacidades novos significativos que os clientes geralmente gostam de planejar para preparar a equipe de TI e/ou os usuários. Também oferecemos um período de 12 meses para os clientes receberem essas atualizações, proporcionando tempo para planejar. Um exemplo disso é a alteração com o Exchange Online no Office 365, pois adicionamos arquivamento, correio de voz e renovamos a interface do usuário do Outlook Web App (OWA).

Há também semelhanças importantes entre a cadência de liberação e o ciclo de desenvolvimento básico do Exchange Server e do Exchange Online. Nossos clientes confiam em nós para fornecer recursos inovadores e importantes conforme a evolução do mundo ao redor. Embora os serviços ofereçam a capacidade de entregar atualizações mais rápido, um serviço essencial para a empresa precisa inovar além de apenas aumentar os recursos pequenos e frequentes. Os ciclos de liberação de vários anos permitem investimentos significativos de engenharia estejam à frente das alterações nos negócios necessárias e aproveitam a nova tecnologia. A adição de correio de voz, arquivamento e recursos de conformidade no Exchange são ótimos exemplos das áreas de investimento recentes. Sem esses grandes investimentos, os clientes ficam apenas com as melhorias incrementais ao longo do tempo. Apesar de adotarmos o ciclo de liberação mais frequente disponível para nós com o Exchange Online, continuaremos a ouvir os comentários dos clientes e a fazer grandes investimentos que mantenham o Exchange à frente do nível da empresa em mensagem, calendário e proteção.

Independentemente do servidor no local ou do serviço online, minha equipe e eu continuamos comprometidos em ajudar nossos clientes a serem produtivos, e os ajudaremos a adotar a nuvem da maneira que funcionar para os seus negócios. Faremos isso enquanto entregamos recursos e capacidades líderes do setor que nossos clientes disseram que precisam e investimos em tecnologias inovadoras que serão uma surpresa para você. Você sempre pode esperar um mapa claro das atualizações para que possa se planejar corretamente para as próximas mudanças, e continuaremos a impulsionar o setor com investimentos ambiciosos para entregar a melhor solução de mensagem do mercado.

Rajesh Jha
Vice-presidente corporativo
Microsoft Exchange

Esta é uma postagem de blog localizada. Consulte o artigo original em Development cadence in a cloud world