Nota do editor: Sabe bastante sobre esse tópico? Quer compartilhar seu conhecimento? Participe hoje mesmo do programa wiki do software IBM Lotus.

Apresentação

Virtualização é o termo do momento no segmento de mercado de computadores. E, como qualquer termo do momento, deve ser encarado com cautela. Além dos benefícios que a virtualização proporciona, há armadilhas inerentes que acompanham qualquer nova tecnologia. Este artigo demonstra que é possível implementar o Lotus Domino em um ambiente virtualizado (VM) com convidado Linux e alcançar um alto nível de escalabilidade no seu ambiente de produção. Analisaremos resultados recentes de avaliações de desempenho e um exemplo de produção real que demonstra a grande escalabilidade do Lotus Domino em ambiente Linux virtualizado. Mostraremos os resultados de uma avaliação de desempenho recente em que alcançamos 102.000 usuários da avaliação de desempenho de correio no NRPC do Lotus Domino em um kernel Linux em execução na VM.

Apresentaremos também os recursos de alguns dos vários ambientes virtualizados disponíveis no mercado atual e os benefícios que eles podem trazer ao Lotus Domino. Aproveitando esses novos recursos, você tem o potencial de refazer a arquitetura do seu ambiente Lotus Domino e de gerar economia de custos adicionais nos dias de hoje.

Voltar para parte superior

Virtualização e Lotus Domino: Qual o benefício?

Os benefícios obtidos executando um ambiente virtualizado dependem da tecnologia de virtualização escolhida para implementação. Nem todas as tecnologias de virtualização têm os mesmos recursos ou fornecem os mesmos benefícios. Entendendo os recursos e os benefícios do seu ambiente virtualizado específico, é possível evitar as limitações inerentes que cada uma dessas tecnologias de virtualização possui.

Por exemplo, no ambiente atual, se o Lotus Domino estiver sendo executado em hardware dedicado e um dos seus servidores ficar sem recursos, o que deverá ser feito? Primeiro, será preciso, comprar, pedir e aguardar a instalação do novo hardware. Depois, terá de comprar e instalar uma nova licença do Lotus Domino. Daí, criar e configurar um novo servidor Lotus Domino. Então, migrar parte da carga de trabalho do servidor com limitação de recursos para o novo servidor. No mundo virtual, seria preciso ativar a capacidade sobressalente ou acrescentar mais capacidade ao seu hardware existente e reconfigurar as imagens virtuais para os novos recursos; isso tudo. Não é necessário gerenciar e manipular seus servidores Lotus Domino se seus recursos estão no limite. A virtualização permite adequar sua infraestrutura às necessidades do seu ambiente Lotus Domino, em vez de adequar seu ambiente Lotus Domino aos limites de sua infraestrutura.

Outra vantagem do ambiente virtual é a capacidade de redução de custos por meio da consolidação de servidor e de reduções de infraestrutura. Visto que é possível estender dinamicamente novos recursos ao mundo virtual, pode-se arquitetar um ambiente Lotus Domino que aproveite esses recursos. Por exemplo, executando múltiplos servidores Lotus Domino em uma única imagem Linux como convidado em VM, é possível eliminar o requisito de conexões físicas de hardware entre os servidores. Dependendo do nível de consolidação, também é possível reduzir ou eliminar a infraestrutura de suporte atual em torno de servidores físicos.

Ao reduzir a complexidade do seu ambiente Lotus Domino, pode-se reduzir o número de servidores necessários para execução no seu ambiente. Essa redução da complexidade está diretamente relacionada à redução do custo para administrar (isto é, para instalar e atualizar) e para dar suporte (isto é, desempenho, capacidade, processos de determinação de problemas) ao seu ambiente. Como mostrado, pensar de forma diferente, em vez de simplesmente portar imagens existentes para seu mundo virtual, pode resultar em reduções substanciais de custo de execução da sua infraestrutura Lotus Domino.

A Figura 1 mostra um exemplo de como mudar de uma infraestrutura física distribuída do Lotus Domino para uma infraestrutura virtual centralizada do Lotus Domino.

Nesse exemplo, passamos de 18 sistemas de hardware, imagens de sistema operacional e servidores de correio do Lotus Domino para seis servidores de correio do Lotus Domino em dois convidados Linux em um VM.

Essa implementação presume que seu VM e hardware escolhidos tenham a capacidade necessária para suportar essa carga de trabalho. Também, visto que os convidados Linux são executados na mesma área de cobertura física, podem aproveitar as tecnologias de LAN virtual (VLAN). Essa capacidade não só elimina a necessidade de servidor de hub, mas a VLAN permite que os servidores Lotus Domino se comuniquem entre si com a velocidade da memória, não da LAN. Essa capacidade elimina também a necessidade de um backbone dedicado para cuidar do tráfego servidor a servidor (correio, cluster, replicação, administração) entre os servidores.

Voltar para parte superior

Aviões, trens e automóveis: Nem toda virtualização é criada igual

Como sugere o título desta seção, há modos diferentes de fornecer transporte, cada um com características únicas de velocidade, capacidade e distância. Também há muitos modos diferentes de executar virtualização hoje em dia. A virtualização pode ser executada no hardware, no firmware ou mesmo no software. Às vezes, a virtualização é executada usando uma combinação dessas abordagens. A configuração depende dos produtos de virtualização e do software, firmware e hardware de apoio escolhidos.

Nem todas essas tecnologias de virtualização, porém, atendem às mesmas necessidades comerciais ou fornecem os mesmos benefícios. Dependendo da tecnologia de virtualização e de como é implementada, as características de desempenho que a tecnologia de virtualização específica fornece podem variar. Quanto maior o gasto adicional de uma tecnologia de virtualização específica, mais recursos serão necessários para a execução dessa implementação.

A virtualização não é um conceito novo; ela existe há mais de 40 anos. Foi introduzida como produto em 1967, com o CP-67. Os fornecedores que oferecem virtualização têm históricos e experiências diferentes, com muita atividade recente, nos últimos poucos anos. A IBM tem mais de 40 anos de experiência em aprimoramentos de desempenho e melhorias em ambientes virtuais.

Diferentes aspectos da virtualização podem ter custos diferentes associados a eles. Por exemplo, a capacidade de virtualizar encadeamentos em um processador pode ter um custo diferente do custo de virtualizar a E/S. Esse fato significa que é preciso avaliar todos os custos do seu ambiente virtual, incluindo de processador, memória e E/S, a fim de entender o custo total de execução nesse ambiente virtual. Visto que o Lotus Domino pode ter um impacto significativo sobre os processadores, a memória e a E/S, dependendo dos recursos e funções ativados, é preciso entender como esses componentes funcionam para avaliar os custos da virtualização com o Lotus Domino.

Como mostra a figura 2, há várias abordagens diferentes à implementação básica de servidor na virtualização, incluindo particionamento de hardware, hypervisor bare-metal e hypervisor hospedado.

Também é importante entender como a virtualização cria sua implementação de hypervisor. Como a figura 3 demonstra, as várias implementações têm seus benefícios e seus problemas.

Entendendo como sua virtualização é implementada, é possível entender melhor como aproveitar os recursos dela. O Red Paper IBM intitulado "IBM Systems Virtualization: Servers, Storage, and Software", publicado em abril de 2008 (REDP-4396), fornece uma descrição bastante detalhada sobre as diferentes tecnologias de virtualização e seus benefícios e problemas.

Voltar para parte superior

102 mil usuários de avaliação de desempenho do Lotus Domino em um kernel Linux em VM

No último trimestre de 2008, foi lançada uma versão nativa para Linux, de 64 bits, do Lotus Domino. Foi preparada uma avaliação de desempenho com os seguintes dois objetivos:

• Queríamos ver o impacto na escalabilidade do Lotus Domino em um único servidor de partição Lotus Domino durante o uso do novo código nativo de 64 bits em comparação como código antigo de 32 bits.
• Queríamos ver até que ponto podíamos forçar um kernel Linux virtualizado em um ambiente de sistema operacional de 64 bits executando Lotus Domino em VM.

A avaliação de desempenho foi feita no Washington System Center, em Gaithersburg, Maryland, Estados Unidos. Para essa avaliação de desempenho, foi usado um sistema z10 EC 2097-764. O sistema tinha 64 processadores gerais (não incluindo os processadores de E/S, sobressalentes, e assim por diante) e 1.52 TB de memória. Apenas parte desse sistema foi alocada para essa avaliação de desempenho. Uma partição lógica, ou LPAR, foi criada no sistema com uma configuração inicial de quatro processadores e 48 GB de memória. Nessa LPAR, criamos uma imagem do sistema operacional de VM e um kernel Linux em VM, com acesso aos quatro mecanismos e a 10 GB de memória. Nessa configuração inicial de 4 processadores centrais (CPs) ou mecanismos/10 GB, executaríamos nossos testes iniciais em um único servidor de partição Lotus Domino.

Observe que esse sistema não era dedicado à avaliação de desempenho do Lotus Domino, mas executava outras cargas de trabalho ao mesmo tempo. Além da avaliação de desempenho do Lotus Domino, havia duas outras avaliações de desempenho do cliente em execução ao mesmo tempo no mesmo hardware físico. Uma dessas era para um cliente do setor de seguros; a outra, para um cliente do setor financeiro. Cada uma dessas avaliações de desempenho tinha sua própria LPAR e virtualização dentro do mesmo hardware físico. Além dessas cargas de trabalho, várias outras LPARs menores também estavam em execução nesse sistema.

O dispositivo de armazenamento de acesso direto (DASD) total conectado a esse sistema físico, por meio de vários canais de fibra, era de bem mais de 200 TB. Para a carga de trabalho do Lotus Domino, terminamos com cerca de 20 TB de DASD conectados a esse kernel Linux, definidos como dispositivos "extended count key data" (ECKD). Muitas vezes surge a questão quanto ao uso de números de unidade lógica (LUNs) SCSI conectados a ECKD DASD ou Fibre Channel Protocol (FCP). Existem prós e contras em cada opção. O uso mais eficiente de LUNs SCSI conectados a FCP no ambiente Linux é por subcanais FCP dedicados em vez de dispositivos emulados z/VM®.

Nesse caso, a pilha de SCSI do Linux é utilizada para gerenciar, ler e gravar dados em LUNs de destino. A desvantagem dessa configuração é que os dispositivos em disco de destino não ficam visíveis no ambiente Conversational Monitor System (CMS), de modo que ferramentas e processos z/VM não podem ser utilizados para ajudar no gerenciamento desses dispositivos. Eles só ficam disponíveis no ambiente Linux e, portanto, devem ser gerenciados a partir desse contexto. Estudos sobre desempenho conduzidos pelo IBM Boeblingen Lab sugerem que o uso de subcanais FCP dedicados e LUNs SCSI proporciona o melhor desempenho em termos de megabytes transferidos por segundo. Essa solução também tende a incorrer em gasto adicional de processador mais baixo a partir de uma perspectiva do z/VM porque é possível utilizar qioassist de hardware (disponível no z9® e z10), já que o processo de E/S é baseado em qdio em vez de em subcanal inicial. Para obter uma descrição mais detalhada de qdio, consulte o documento “Queued Direct I/O (QDIO)”, na seção de referências.

O aspecto negativo dessa solução é que o subsistema de canal System z® não fornece automaticamente suporte a caminhos múltiplos para os dispositivos de armazenamento de destino. Todos os caminhos múltiplos devem ser criados definindo-se manualmente uma configuração de caminhos múltiplos no Linux e utilizando-se o suporte ao mapeador de dispositivos para essa configuração.

A vantagem do uso dos dispositivos ECKD DASD é que eles ficam visíveis a partir do ambiente z/VM CMS e, portanto, podem ser facilmente gerenciados em um ambiente de programação de um sistema z/VM típico. Outro benefício é que o gerenciamento de caminhos múltiplos para o subsistema de armazenamento de destino está totalmente contido no subsistema de canal do hardware e não requer nenhuma intervenção manual do lado do Linux. A desvantagem é que a arquitetura de E/S do System z especifica que apenas uma operação de E/S pode estar ativa por vez em um dispositivo de destino específico (UCB ou subcanal DASD). É possível superar essa restrição utilizando volumes de acesso paralelo (PAVs). Com o novo suporte disponível nas versões mais recentes do driver DASD do Linux e o recurso DS8300 hyperpav, é possível utilizar de forma eficaz o PAV com Linux no System z e conseguir taxas de rendimento semelhantes àquelas do ambiente FCP dedicado descrito anteriormente.

Nosso ambiente consistia em dispositivos ECKD alocados como dispositivos 3390 modelo 27. Utilizamos dispositivos ECKD porque eles estavam prontamente disponíveis, enquanto que um ambiente FCP SCSI não estava.

Para o primeiro conjunto de testes, demos ao Lotus Domino quatro segundos de CP e 10 GB de memória para estabelecer a linha de base para a execução de um único servidor Lotus Domino em um convidado Linux. Nessa série de testes, forçamos essa instância do Lotus Domino o máximo possível antes de travá-la. Essa abordagem nos permitiu escalar essa instância do Lotus Domino e ver até que ponto ela conseguiria chegar com recursos ilimitados. Visto que queríamos comparar avaliações de desempenho anteriores do release do Lotus Domino, reconstruímos seus ambientes, suas configurações e suas cargas de trabalho. A definição básica para essa avaliação de desempenho era a seguinte:

• Nenhum registro de transações
• Cargas de trabalho R6Mail
• Um servidor Lotus Domino em um convidado Linux em VM

A carga de trabalho R6Mail é simulada por meio de operações de correio e de calendário do Lotus Notes Client para as ações do servidor. Ela envia 4,67 mensagens por usuário por hora. Para obter informações adicionais sobre essa carga de trabalho, consulte o artigo do developerWorks® "The new Domino 6 Notesbench workloads: Heavier by request!".

Conforme mostrado na figura 4, pudemos alcançar de 19 mil a 20 mil usuários da avaliação de desempenho em uma única instância do Lotus Domino antes de ela falhar.

Nessas medições, medimos os segundos de CP utilizados em vez taxas de ocupação do processador, conforme mostrado na figura 5.

A taxa de ocupação do processador é um cálculo do recurso utilizado (segundos do CP) dividido pelo recurso disponível. Historicamente, esse cálculo tinha um numerador aleatório (uso de segundos do CP) dividido pelo denominador estático (recurso do processador físico disponível). Visto que metade dessa equação era estática e só mudava quando uma unidade era atualizada ou descarregada para a área de troca, o número de ocupação do processador era uma boa indicação dos recursos em uso. Mas no mundo virtual, o denominador agora pode ser um valor aleatório também.

Por mais de cinco anos, o número de processadores em determinado ambiente virtual pode mudar a cada 10 segundos no hardware de uma grande empresa. Nessas configurações, o número de processadores disponíveis nas medições é agora um número fracionário, porque em um intervalo de um minuto, ele pode mudar várias vezes. Por exemplo, o número de processadores em um minuto poderia ser 4,5 e 5.166 no próximo minuto. Essa variação significa que a taxa de ocupação do processador agora possui um denominador aleatório e um numerador aleatório, o que torna esse valor basicamente inútil em um mundo virtual de produção. Ao medir segundos do CP, você sabe a quantidade de recursos do processador que o ambiente utilizou, mas não quanto dele está disponível em um ambiente virtual que pode mudar constantemente.

Em nossas medições, utilizamos um intervalo de coleta de 10 minutos. Esse intervalo significa que a 600 segundos do CP (10 minutos x 60 segundos), você utiliza o equivalente de um mecanismo integral de capacidade do processador.

A outra desvantagem no mundo virtual é que a taxa de ocupação do processador pode ser enganosa sobre quanto resta da capacidade. Se você tem um sistema com dois processados físicos e define duas imagens de sistema operacional, cada uma com dois processadores lógicos, essa configuração dá a você um total de quatro processadores lógicos. Se ambas as imagens do sistema operacional forem tratadas e gerenciadas igualmente por sua tecnologia de virtualização, quando ambas as imagens do sistema operacional tiverem uma taxa de ocupação do processador de 50 por cento, você terá 100 por cento de ocupação do sistema físico e estará sem capacidade. Ao entender a quantidade de recursos (segundos do CP) que você está utilizando, em vez de uma porcentagem de um número de capacidade virtual, você estará em posição melhor para gerenciar e monitorar seu ambiente.

Além de avaliar os recursos utilizados, também examinamos o custo da execução dos usuários da avaliação de desempenho. A Figura 6 mostra o custo do processador para os usuários ativos por 15 minutos do Lotus Domino. Essa representação é obtida pela divisão do número utilizado de segundos do processador pela instância do servidor Lotus Domino no número de usuários ativos para cada período de amostra.

A Figura 6 mostra uma tendência interessante, mas esperada. O custo mais elevado por usuário ocorre no início da avaliação de desempenho. Visto que os usuários estão efetuando login e validando sua autorização, o gasto adicional do processamento é associado a esse custo elevado. Por exemplo, se um servidor for reiniciado no meio de um turno ocupado, você precisará planejar recursos adicionais de processador quando a população inteira do usuário se registrar de volta no servidor. O verdadeiro custo de estado estável fica mais baixo após os usuários serem autenticados no servidor e terem estabelecido suas sessões de comunicação.

Por essa razão, as avaliações de desempenho tendem a diminuir o tempo de carregamento do último conjunto de usuários se eles estiverem forçando o processador para o seu limite e para dar algum tempo antes da medição do estado estável. Além disso, pode-se ver que o custo por usuário atingiu um pico no final dessa execução antes de o servidor falhar, indicando que ele estava começando a ficar sob tensão antes de falhar. Visto que esse teste era a execução de um único DPAR com todo correio entregue localmente, entendemos que o custo por usuário aumentaria quando acessássemos vários DPARs e tivéssemos correio local e remoto para entregar.

Um de nossos objetivos no uso dessa avaliação de desempenho era ver se poderíamos ultrapassar 100 mil usuários da avaliação de desempenho em um convidado do Linux. Com base nos testes em um único servidor de partição Lotus Domino, calculamos que precisaríamos executar 17 mil usuários de avaliação de desempenho em cada um dos seis servidores de partição Linux Domino em um convidado Linux. Incluímos cinco servidores de partição Lotus Domino adicionais para fazer com que esse único convidado Linux equivalesse aos seis servidores de partição Lotus Domino. Além disso, incluímos mais quatro CPs, aumentamos a memória para 26 GB e incluímos mais DASD para suportar a carga total de usuários.

Cada DPAR recebeu seu próprio diretório de dados do Notes e quatro diretórios de correio exclusivos no caminho /notesdatax/mail. Distribuímos o DASD para as caixas de correio do usuário por esses pontos de montagem. Cada servidor de partição Lotus Domino foi definido para ser executado com uma ID de usuário separada e recebeu um endereço IP exclusivo. Visto que todos esses servidores de partição Lotus Domino residiam na mesma área de cobertura física, pudemos utilizar VLANs e transferir dados entre eles na velocidade da memória (transferência de buffer TCP/IP para buffer TCP/IP) sem precisar enviar o tráfego servidor a servidor para uma rede de backbone físico.

Nosso primeiro teste de 100 mil foi definido para aumentar para 60 mil na mesma taxa que o teste do servidor único, e depois para diminuir os usuários que eram incluídos. Com 50 mil usuários, porém, começamos a observar problemas com a execução. As mensagens estavam começando a se acumular e os tempos de resposta nos clientes estavam começando a se prolongar. Com base na análise do Lotus Domino e em dados da plataforma, detectamos um gargalo de E/S. Enquanto o DS8000® e a VM apresentavam tempos de resposta de menos de 2 ms, observamos tempos de resposta de mais de 80 ms fora do kernel Linux.

Enquanto investigávamos esse problema, tentamos vários testes para saber se poderíamos contornar esse gargalo de E/S. Durante as várias execuções de testes, fizemos o seguinte:

• Reduzimos a quantidade de dados sendo gravados em log.nsf
• Aumentamos a memória do convidado Linux para 48 GB
• Aumentamos o tamanho do NSF_Buffer_Pool
• Movemos mail.box(es) (cada DPAR tinha seis) para um disco RAM
• Movemos names.nsf para um disco RAM
• Movemos log.nsf para um disco RAM
• Movemos mail.box(es), log.nsf, names.nsf para um disco RAM
• Alteramos o número de mail.box(es)
• Alteramos o número de encadeamentos na tarefa do servidor
• Alteramos o número de encadeamentos na tarefa do roteador para a entrega de mensagem local e remota
• Atualizamos o servidor Lotus Domino para o código GA nível gold
• Configuramos MailLeaveSessionsOpen=1

Embora nenhuma dessas mudanças fizesse qualquer diferença no gargalo de E/S e no problema de escalabilidade encontrado, a configuração do parâmetro notes.ini MailLeaveSessionsOpen para 1 causou uma diferença mensurável nos recursos do processador em uso. Vimos o custo do processador por usuário ativo por 15 minutos ir de 0,07 para 0,05 segundos do processador, o que significa uma redução de cerca de 28 por cento para a execução das mesmas cargas de trabalho. Esse parâmetro diz ao Lotus Domino para deixar aberta a sessão para a entrega de correio entre os vários servidores. Antes da configuração desse parâmetro, o Lotus Domino estabelecia uma sessão com um servidor de correio para o qual estava transferindo uma mensagem, autenticava, enviava a mensagem e descartava a sessão. Ao deixar a sessão aberta, o Lotus Domino pôde reutilizar as sessões existentes em vez de restabelecê-las constantemente.

Por fim, determinamos que o problema de E/S foi causado pela maneira como os volumes ECKD estavam sendo suportados no Linux e como os pedidos estavam sendo enfileirados no nível do dispositivo lógico. Uma correção para os volumes de acesso paralelo (PAVs) está sendo fornecida com o SLES 11, mas ela não estava disponível para nosso uso no momento da avaliação de desempenho. Reconfiguramos o subsistema de E/S para dividir os volumes em unidades lógicas menores, de 3 GB, criando assim mais unidades lógicas para a mesma quantidade total de DASD. Essa configuração nos forneceu mais unidades lógicas para Linux de modo que pudemos propagar a E/S para os mesmos sistemas DS8000.

Após reconfigurarmos o DASD, pudemos escalar para cerca de 85 mil usuários antes de ficarmos sem capacidade nos oito CPs. Incluímos mais quatro CPs para deixar a VM e o convidado Linux com 12 CPs para as próximas execuções. Nosso convidado virtual e os servidores Lotus Domino recebem um aumento de 50 por cento no número de CPs disponíveis, sem precisar recriar, redistribuir nem fazer qualquer mudança no Lotus Domino para a capacidade adicional.

Com essa capacidade adicional, pudemos atingir um estado estável de 17 mil usuários em cada uma das seis DPARs, com um estado estável total de 102 mil usuários em um convidado Linux em execução em VM. A Figura 7 mostra a contagem de usuários conectados e ativos por 15 minutos em uma dessas execuções.

Durante o estado estável para a execução, fizemos uma média de 1,5 milhão de transações do Lotus Domino a cada 10 minutos durante o teste ou de 9 milhões de transações do Lotus Domino por hora, conforme mostrado na Figura 8.

Durante essas execuções, a carga de trabalho de E/S total nesse convidado Linux único atingiu um pico pouco abaixo de 27 mil E/Ss por segundo. Pudemos calcular a média de tempo de resposta de menos de 2 ms no DS8000s, VM e kernel Linux. Durante essas execuções, as outras cargas de trabalho mencionadas anteriormente estavam ativas no mesmo servidor, de modo que o número total de E/S por segundo nesse servidor era muito maior que apenas as 27 mil para a carga de trabalho do Lotus Domino.

Durante as várias execuções com diferentes números de usuários, o custo do processador por usuário ficou estável até atingirmos a marca de 80 mil usuários. Nesse ponto, o custo por usuário começou a aumentar, à medida que incluíamos os últimos 20 mil usuários. Não vimos esse crescimento no teste de DPAR única ao atingir 17 mil usuários, nem o vimos no teste de 51 mil usuários, que está documentado na próxima seção deste artigo, no qual executamos vários servidores Lotus Domino com 17 mil usuários. Esse crescimento no custo do processador por usuário parecia estar relacionado ao gasto adicional do próprio kernel Linux.

Para essa avaliação de desempenho e outras medições, vimos um gasto adicional de cerca de 10 por cento para o primeiro convidado em VM. Além disso, há cerca de 1 a 2 por cento de gasto adicional para cada convidado adicional posterior de VM (não servidor de partição Lotus Domino). Esse gasto adicional de 10 por cento dividido pelas seis instâncias do servidor Lotus Domino significa que, para essa configuração, tivemos aproximadamente 2 por cento de gasto adicional para cada servidor Lotus Domino nesse ambiente virtual para essa avaliação de desempenho. Observe, porém, que nem todas as plataformas e tecnologias de virtualização atingem esse nível de escalabilidade, rendimento e baixo gasto adicional em uma única área de cobertura física. Portanto, esses números não devem ser utilizados para implementações virtuais do Lotus Domino diferentes daquela detalhada neste artigo.

Voltar para parte superior

Escalabilidade vertical e horizontal

Quando se migra para um ambiente virtual para sua infraestrutura Lotus Domino, é o momento ideal para examinar a infraestrutura existente. A maneira mais rápida e fácil é mudar seus servidores Lotus Domino existentes para seu novo ambiente. Essa abordagem normalmente não permite aproveitar totalmente ou utilizar melhor seu novo ambiente virtual. Uma das medições que executamos foi avaliar a diferença na execução de determinada carga de trabalho em duas configurações diferentes. Para medir essa diferença, executamos cargas de trabalho idênticas nas mesmas configurações com uma diferença: o número de servidores de partição Lotus Domino.

Em nossa primeira etapa de teste, executamos 51 mil usuários da avaliação de desempenho em três DPARs e determinamos o custo por usuário. Depois executamos os mesmos 51 mil usuários em seis DPARs na mesma configuração virtual e determinamos o custo por usuário. A Figura 9 mostra os resultados desses testes..

Como podemos ver, o custo do processador era 20 por cento menor por usuário com a consolidação da carga de trabalho para menos servidores de partição Lotus Domino. Também vimos esse tipo de redução nos ambientes de produção do cliente e da IBM quando eles estão preparados para executar a consolidação do servidor. Ao escalar sua infraestrutura do Lotus Domino verticalmente (consulte a Figura 1 para ver um exemplo), não só se economiza os recursos necessários para a execução desse ambiente, mas também se economiza custos de administração porque agora há menos servidores para gerenciar, atualizar e dar suporte.

A chave para aproveitar completamente os benefícios virtuais é ter uma implementação física/virtual que permita a inclusão de recursos em seu ambiente para que você possa crescer verticalmente primeiro sem ter que reconstruir o ambiente horizontalmente.

Voltar para parte superior

Não só avaliações de desempenho, mas funcionalidade hoje!

"Tudo isso parece muito bom, mas como isso realmente funciona na produção?" é a pergunta que provavelmente você está se fazendo. A IBM já trabalhou com um cliente para migrar 14 mil usuários de produção para dois kernels Linux. Cada convidado do Linux em VM suporta cerca de 8 TB de DASD. Existem aproximadamente 7 mil usuários de produção em cada kernel, com cada convidado executando vários DPARS. Além dos servidores de correio, eles também têm servidores de nome e um servidor administrativo dentro desses dois convidados do Linux para um total de quatro DPARS em cada convidado do Linux. Essa configuração foi feita com o Lotus Domino 7 antes do advento do código de 64 bits do Lotus Domino versão 8.5 que permite hoje maior consolidação do servidor. Esse cliente teve uma redução no número de instâncias gerenciadas do Lotus Domino e na configuração de infraestrutura.

Não só os clientes estão implementando o Lotus Domino no Linux em ambientes em grande escala, mas também a IBM. A IBM está no processo de mudar suas cargas de trabalho de produção para o Lotus Domino no Linux para System z. A publicação "Consolidação do Lotus Domino e Lotus Notes para o Linux no System z" é um resumo da atividade que já ocorreu durante essa migração. Essa publicação inclui uma descrição da mudança de 103 sistemas de hardware com 35.100 aplicativos Lotus Domino para o Lotus Domino no Linux para System z. Procure publicações adicionais, já que esse trabalho se estenderá em seguida para o ambiente de correio.

Voltar para parte superior

Pense de forma inovadora com a virtualização

Como vimos, uma das vantagens da virtualização é a capacidade de estender dinamicamente sua infraestrutura para suportar seu ambiente Lotus Domino. Essa vantagem, junto com a capacidade do hardware corporativo de mudar dinamicamente e de aumentar sua configuração durante o uso, pode conduzi-lo a caminhos novos e diferentes para a execução de seu ambiente Lotus Domino.

Hoje a maioria dos clientes que utiliza armazenamento em cluster executa uma configuração ativa/ativa. Essa configuração implica em carga de trabalho balanceada em ambos os lados do cluster, utilizando igualmente os recursos. A outra maneira de executar o cluster do Lotus Domino é em uma configuração ativa/passiva, em que toda carga de trabalho está no lado ativo do cluster e apenas a carga de trabalho necessária para manter a sincronização está no lado passivo. A principal desvantagem dessa configuração é que um servidor parece praticamente vazio porque está lá apenas "por via das dúvidas".

O aspecto negativo da configuração ativa/ativa é que a carga de trabalho total é a soma das duas metades. Em caso de falha, toda a carga de trabalho de um lado é deslocada para o outro. Embora a maioria das configurações seja precisamente dimensionada no começo, com o tempo, ambos os lados do cluster aumentam. É possível saber se a carga de trabalho inteira ainda pode se ajustar a um lado do cluster? Você realmente desativou metade do cluster durante o principal período de pico para validar se a carga de trabalho ainda pode se ajustar? Além disso, nem todos os gargalos ocorrem no processador; está disponível a largura da banda de E/S e rede para suportar cargas de trabalho de failover de pico? Se você não testar e validar ativamente seu armazenamento em cluster durante cargas de pico, durante uma falha real o lado do failover pode ficar limitado e apresentar tempos de resposta ruins ou até mesmo falhar.

No mundo virtual, é possível executar o cluster do Lotus Domino ativo/passivo e saber de quais recursos ele precisa para executar toda a sua carga de trabalho em um lado, porque ele já está de um lado do cluster. Há diversas opções para o lado passivo no mundo virtual. É possível reutilizar os recursos no lado passivo para as cargas de trabalho com prioridade mais baixa (cargas de trabalho de teste, desenvolvimento e outras não Lotus Domino) que possam ser sacrificadas temporariamente durante uma falha. Examine uma solução de capacidade on demand. Esse tipo de solução permite planejar o failover de alguma porcentagem de sua população (falhas do servidor individuais) com a capacidade adicional restante ativada dinamicamente em uma falha integral. A vantagem de uma solução de capacidade on demand é que não é preciso comprar 100 por cento do hardware passivo até utilizá-lo. A opção de reutilizar ou não pagar até precisar utilizar o recurso agora é sua, mas não é preciso mais a capacidade reserva, esperando "só para o caso de" ocorrer uma situação que a justifique.

Voltar para parte superior

Conclusão

Nem todas as tecnologias de virtualização proporcionam os mesmos benefícios ou têm os mesmos gastos adicionais. Algumas tecnologias de virtualização (como a que executamos) existem há mais de 40 anos, com muitos aprimoramentos e aperfeiçoamentos. A IBM executa o Lotus Domino em um ambiente virtual desde o Lotus Domino 4.5.1. A IBM consolidou a maioria de seus servidores de aplicativos Lotus Domino para o Linux para System z em VM. A IBM também anunciou planos para mudar seu servidor de correio para esse ambiente.

Embora o ambiente de virtualização no System z que utilizamos na avaliação de desempenho deste artigo tivesse um gasto adicional acumulativo de menos de 2 por cento para cada instância do servidor Lotus Domino, essa avaliação de desempenho não é típica da maioria das tecnologias de virtualização. Entender o custo de seu ambiente virtual é crítico para a criação de uma implementação virtual de sucesso. Além disso, o custo baixo associado à capacidade de virtualizar quantidades maciças de E/Ss nesses exemplos (avaliação de desempenho e produção) permite uma escalabilidade vertical e uma redução de custos significativas.

A virtualização do ambiente Lotus Domino pode ajudar muito a agilizar e a reduzir seu custo total de propriedade (TCO). Mesmo que a mudança de servidores existentes ofereça uma economia, a verdadeira economia vem da capacidade de consolidação de seus servidores (redução de sua complexidade ambiental) em uma escala vertical. Além disso, economias de custos substanciais de administração e gerenciamento podem ser constatadas ao agilizar seu ambiente e reduzir a complexidade (com menos servidores Lotus Domino para gerenciar, atualizar e dar suporte) da sua implementação do Lotus Domino. Por fim, ajustar sua infraestrutura ao Lotus Domino em vez de ajustar o Lotus Domino à sua infraestrutura pode reduzir o TCO e dar-lhe a capacidade de reagir com mais rapidez e flexibilidade às necessidades de seus negócios.

Recursos

• Participar do fórum de discussão.
  
  
• Leia o Red Paper IBM "IBM Systems Virtualization: Servers, Storage, and Software."
  
  
• Leia a publicação IBM "Consolidação do Lotus Domino e Lotus Notes para o Linux no System z."
  
  
• Saiba mais sobre Queued Direct I/O (QDIO).
  
  

Sobre os autores

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Apresentação
• Virtualização e Lotus Domino: Qual o benefício?
• Aviões, trens e automóveis: Nem toda virtualização é criada igual
• 102 mil usuários de avaliação de desempenho do Lotus Domino em um kernel Linux em VM
• Escalabilidade vertical e horizontal
• Não só avaliações de desempenho, mas funcionalidade hoje!
• Pense de forma inovadora com a virtualização
• Conclusão
• Recursos
• Sobre os autores
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais