 | Nível: Intermediário O. Michael Atogi, IBM Solution for Compliance in a Regulated Environment (SCORE), SDI Corp.
Shyjee Mathai, Advisory Software Engineer, IBM
14/Jul/2009 Em uma implementação do IBM SCORE, é possível formar clusters com os servidores auxiliares, de rendição, de sobreposição ou de publicação para prover alta disponibilidade e escalabilidade de desempenho usando a funcionalidade de cluster do IBM® WebSphere® Application Server, como utilizada pelos servidores auxiliares.
Nota do editor: Conhece muito sobre esse tópico? Deseja compartilhar seu conhecimento? Participe do programa wiki software IBM Lotus hoje mesmo.
Apresentação
O IBM Solution for Compliance in a Regulated Environment (SCORE) é uma solução de gerenciamento de documentos que utiliza diversas tecnologias IBM como o WebSphere Application Server, o IBM WebSphere Portal, o IBM WebSphere Process Server, o DB2®, o IBM Content Manager e diversas outras soluções adquiridas junto a outros fornecedores. O SCORE fornece gerenciamento de documento eletrônico de ponta a ponta no segmento de mercado farmacêutico e suporta muitos padrões globais de mercado (como o Electronic Common Technical Document, eCTD) para submissões de drogas a agências governamentais reguladoras (dos EUA); as diretrizes do FDA (Título 21 CFR Parte 11) sobre registros e assinaturas eletrônicos; e o GxP.
A arquitetura do IBM SCORE se estende a vários servidores lógicos para obter a multiplicidade de funções que ela entrega. Dois servidores lógicos que merecem atenção nesta discussão são o de rendição e o de sobreposição. O servidor de rendição é responsável pela conversão de um formato nativo, por exemplo, os documentos Microsoft® Word ou JPEG, em um arquivo PDF de somente leitura. O servidor de sobreposição é responsável, primariamente, pela aplicação de sobreposições pré-configuradas à parte superior dos documentos PDF. Outras funções do servidor de sobreposição incluem publicação (concatenação de vários documentos PDF), inclusão de números de página, geração de índices, adição de uma assinatura eletrônica a um documento, entre outras coisas. Esses dois servidores lógicos foram tradicionalmente implementados usando produtos de outros fornecedores. Nesta discussão, abordamos as implementações do Adobe® LiveCycle Enterprise Suite de tais servidores lógicos.
Nas implementações típicas, os servidores de rendição e de sobreposição são singulares. No caso de grandes documentos, as funções de rendição e publicação de documentos podem consumir uma quantidade exagerada de tempo de processamento. Quando tais documentos estão em processamento, os tempos de respostas de outros pedidos podem padecer. Ademais, a disponibilidade geral e rendimento do sistema podem decair nesse modo singular. O sistema geral não é escalável.
Assim, para serviços de cluster de outros fornecedores, usar os recursos de armazenamento em cluster do WebSphere Application Server significa agrupar servidores de rendição e de sobreposição em cluster. As seções a seguir abordam os conceitos básicos sobre o armazenamento em cluster do WebSphere Application Server, as diversas topologias de armazenamento em cluster e como elas são usadas para operações de failover e para a obtenção de alto rendimento transacional com ilustrações práticas.
Conceitos básicos sobre armazenamento em cluster do WebSphere Application Server
Um cluster de servidores é uma coleção de um ou mais servidores de aplicativos do mesmo tipo (WebSphere Application Server, Apache Application Server, JBOSS, WebLogic Application Server) dentro de uma célula. Uma célula é um escopo administrativo no IBM WebSphere Network Deployment e uma coleção de nós. Assim, para criar um cluster, uma célula deve ser criada e possuir nós. O administrador do sistema associa nós em uma célula usando o console de administração do WebSphere Application Server.
Normalmente, um nó é composto de um ou mais servidores; o servidor que deve sempre estar presente recebe a denominação NodeAgent. Os servidores de um cluster também são chamados de membros do cluster. Os membros de um cluster são servidores que podem executar como servidores de aplicativos. No WebSphere Network Deployment, o conjunto de arquivos de configuração, modelos e outros recursos usados em um ambiente do tempo de execução são agrupados em um perfil. Para definir um cluster, é necessário ter, pelo menos, dois perfis definidos na célula, um para o gerente de implementação e outro para o servidor ou servidores de aplicativo.
Um servidor de aplicativos tem uma propriedade que é usada na distribuição de trabalhos. Essa propriedade é denominada peso do servidor. O peso do servidor é um inteiro não assinado designado pelo administrador do sistema usando o console de administração do WebSphere Application Server. Se um cluster tiver apenas um membro, o peso do servidor não terá nenhuma importância real, uma vez que o servidor não trabalhará mais com o peso 1 do que faria com o peso 4. Quando um cluster com mais de um membro recebe trabalho, ele o distribui aos membros na proporção de seus pesos. Nessa condição, o peso de um servidor é diretamente proporcional à sua capacidade de consumir trabalho. Essa noção de peso do servidor é explorada quando o balanceamento de cargas está ativado. Nas figuras 1-3, a notação SnWn indica o servidor N e seu peso correspondente.
Topologias de armazenamento em cluster
Há três topologias de armazenamento em cluster:
- Armazenamento em cluster vertical
- Armazenamento em cluster horizontal
- Combinação de tipos de armazenamento em cluster
Armazenamento em cluster vertical
Esta topologia é um tipo de armazenamento em cluster em que os membros estão dentro de um sistema físico específico. Por exemplo, se você tiver um nó denominado nodeX. E esse nó tiver capacidade de processamento, memória e disco rígido suficiente para quatro servidores, server1 – server4. E se você criar um cluster denominado cluster1. Os servidores server1 a server4 serão incluídos como membros do cluster1. Qualquer aplicativo corporativo, app1, poderá ser implementado no cluster1. Essa abordagem significa que os servidores 1-4 executarão, cada qual, uma cópia de app1. Quando chegar uma solicitação para app1 ao servidor proxy ou ao IBM HTTP Server dentro da célula, ela será enviada a um dos servidores no cluster1 usando qualquer política de balanceamento de cargas em vigor.
As políticas de balanceamento de cargas típicas são round-robin e aleatórias. Uma política de balanceamento round-robin é determinística e se baseia nos pesos dos servidores atribuídos e na taxa de chegada de pedidos; assim, é possível apurar facilmente o próximo servidor no cluster a processar um pedido; com o balanceamento de cargas aleatório, deduzir o próximo servidor que processará um pedido não é tarefa fácil para o administrador do sistema. Se um dos servidores no cluster falhar, os demais continuarão a processar os pedidos de entrada sem que o usuário saiba da falha, apenas incorrendo na latência de determinar se o servidor de destino está inativo e se os pedidos devem ser encaminhados para o próximo servidor disponível.
Armazenamento em cluster horizontal
Esta topologia é um tipo de armazenamento em cluster em que os membros estão dispersos em sistemas físicos diferentes dentro da célula. O número dos servidores se iguala ao número de nós no cluster. A vantagem dessa topologia é que, se um dos sistemas físicos falhar, os outros ainda estarão disponíveis para processar os pedidos de entrada. Essa disponibilidade significa que um pedido para o cluster só falhará se, e somente se, todos os servidores físicos estiverem inativos. Como a probabilidade disso acontecer é baixa e, caso viesse ocorrer, a maioria dos outros sistemas também ficariam inativos; esse tipo de armazenamento em cluster fornece maior disponibilidade e failover.
Combinação de tipos de armazenamento em cluster
Também é possível usar uma combinação de armazenamento em cluster horizontal e vertical. Essa topologia fornece alto rendimento, mas requer menos hardware físico na implementação em relação a um armazenamento em cluster horizontal com o mesmo número de servidores de aplicativos, porque mais de um servidor de aplicativo pode ser definido para cada nó.
Cluster de rendição e de sobreposição
Este artigo pressupõe a existência de implementações do IBM SCORE que estejam executando no modo singular, no que se refere aos servidores de rendição e de sobreposição. Para uma nova implementação do IBM SCORE, consulte a documentação IBM Solution for Compliance in a Regulated Environment V5.1.3.2: Guia de Instalação sobre como instalar o SCORE e, depois, leia este arquivo para implementar o armazenamento em cluster de servidores auxiliares. Para implementar o armazenamento em cluster de servidores auxiliares, a célula do WebSphere Application Server V6.1.0.x já deve existir e conter um software distribuidor de cargas (por exemplo, o IBM HTTP Server) para promover a interação entre o servidor IBM SCORE 5.1.3.2 existente e a célula que hospeda o cluster de servidores auxiliares.
As etapas a seguir descrevem as instalações e as configurações necessárias para implementar o armazenamento em cluster para servidores de rendição e de sobreposição. Uma vez concluídas essas etapas, redefina as configurações do sistema de alterações do IBM SCORE, de modo a alterar as URLs dos servidores de rendição e de sobreposição, para ter o nome e a porta do IBM HTTP Server.
Siga estas etapas:
- Instale o WebSphere Application Server Network Deployment no sistema A.
- Instale o WebSphere Application Server no sistema B.
- Crie os perfis – Dmgr01 e AppSrv01.
- Crie o cluster (LCESCluster) e designe os pesos dos servidores.
- Use o Adobe LiveCycle Configuration Manager para configurar e gerar os arquivos enterprise archive (EAR) implementáveis do LiveCycle ES.
- Implemente os seguintes aplicativos corporativos do Adobe LiveCycle ES no cluster LCESCluster:
- adobe-livecycle-websphere.ear
- adobe-livecycle-native-websphere-x86_win32.ear
- adobe-workspace-client.ear
Quando os aplicativos corporativos do Adobe LiveCycle ES estão implementados, estes quatro aplicativos ficam disponíveis no console de administração do WebSphere Application Server, em Enterprise Applications:
- LiveCycle UI
- LiveCycle8
- LiveCycle8Native
- Adobe-lcm-lcvalidator
- Instale o IBM HTTP Server V6.1.0 no sistema C.
- Configure o IBM SCORE 5.1.3.2 no sistema D para usar o cluster. Os detalhes sobre o que configurar serão discutidos em uma seção posterior deste artigo.
 |
Configurando o IBM HTTP Server
O IBM HTTP Server instalado já deve estar configurado com base em uma das três topologias de armazenamento em cluster descritas anteriormente e em suas implementações descritas nas figuras 1-3. Siga as etapas mostradas na seção "Como gerar o plugin-cfg.xml para cada topologia de cluster", mais adiante neste artigo.
Contém definições de cluster, definições de host virtual, entre outras. Cada cluster é definido por um elemento ServerCluster nesse arquivo de configuração. Um dos atributos do elemento ServerCluster é LoadBalance. O atributo LoadBalance pode ter o valor Round Robin ou Random. No caso do Round Robin, o trabalho será distribuído para os servidores de aplicativos no cluster em um modo round-robin com base nos pesos designados aos membros do cluster, mas o primeiro membro do cluster será selecionado aleatoriamente.
Listagem 1. Um plugin-cfg.xml apresentando o atributo LoadBalance do elemento ServerCluster
<ServerCluster CloneSeparatorChange="false" IgnoreAffinityRequests="true"
LoadBalance="Round Robin" Name="LCES_Cluster01" PostBufferSize="64"
PostSizeLimit="-1" RemoveSpecialHeaders="true" RetryInterval="60">
…
</ServerCluster>
|
Durante o teste da configuração, convém definir o atributo LogLevel do elemento Log como Stats; isso permitirá que você veja a distribuição de cargas nos servidores no arquivo de log especificado pelo atributo Name. Depois de se estar satisfeito com a consistência entre a distribuição de cargas e as metas desejadas, será possível alterar o LogLevel novamente para o valor padrão de Error a fim de limitar a geração de log pelo plug-in do servidor da Web.
Figura 1. Um cluster vertical de servidores de rendição e de sobreposição
Figura 2. Um cluster horizontal de servidores de rendição e de sobreposição
Figura 3. Uma combinação de tipos de cluster de servidores de rendição e de sobreposição
Como gerar o plugin-cfg.xml para cada topologia de cluster
Siga estas etapas para gerar o plugin-cfg.xml para cada topologia de cluster:
- Configure a célula de acordo com a figura 1, 2 ou 3.
- Modifique LCESCluster e inclua os membros do cluster para cada topologia.
- Implemente os aplicativos LCES no cluster.
- Salve as alterações para o repositório Master WebSphere Application Server.
- Efetue logon no Console de Administração do WebSphere Application Server e, no painel de navegação, selecione Ambiente-Atualizar plug-in global do Servidor da Web.
- Obtenha o plugin-cfg.xml a partir de <DMGR_PROFILE_HOME>\config\cells, onde DMGR_PROFILE_HOME é o diretório raiz do perfil do gerenciador de implementação.
- Coloque o plugin-cfg.xml da etapa 6 no diretório de plug-ins de configuração do servidor da Web no sistema C. Por exemplo, se o servidor HTTP estiver instalado no diretório padrão, a localização será:
<unidade>:\Arquivos de programas\IBM\HTTPServer\Plugins\config\webserver1
Configurando o IBM SCORE para utilização de armazenamento em cluster
A etapa final no processo é configurar o IBM SCORE para usar o cluster de servidores de rendição e de sobreposição. O administrador do IBM SCORE deve efetuar logon no portlet de administração do IBM SCORE e, na página Alterar Configurações do Sistema, de Terceiros, alterar a URL dos servidores Adobe LiveCycle ES Rendition e Adobe LiveCycle ES Overlay para http://<hostnameOfHttpServer:80>, como mostrado na figura 4.
Figura 4. Alterar as configurações do sistema no portlet de administração do IBM SCORE
Conclusão
Este artigo abordou as diversas topologias de armazenamento em cluster. Você deve determinar a topologia mais adequada para a implementação com base na expectativa da solução. Quando a disponibilidade do servidor é de extrema importância, a topologia de armazenamento em cluster horizontal ou de combinação de tipos de armazenamento em cluster tem mais a oferecer porque garante que a falha de um servidor em um nó não interromperá a entrega do serviço. Quando escalabilidade é a principal meta perseguida, o armazenamento em cluster vertical basta, desde que o sistema tenha capacidade suficiente para hospedar tantos servidores quanto necessários.
A outra determinante é o número de sistemas físicos disponíveis e a capacidade da unidade de disco rígido e da memória. Quando disponibilidade do sistema não é problema, independentemente dos objetivos de desempenho, a topologia de combinação oferece equilíbrio entre a proteção de failover e a solução de alta escalabilidade.
Recursos
Sobre os autores | | | O. Michael Atogi é um desenvolvedor de software no laboratório da IBM Raleigh, em Durham, Carolina do Norte. Ele tem trabalhado com a IBM nos últimos 17 anos e é Mestre em Ciência da Computação pela Universidade de Howard, Washington, D.C. Trabalha, atualmente, no desenvolvimento do IBM Solution for Compliance in a Regulated Environment (SCORE). |
| | | Shyjee Mathai é desenvolvedor de software com a equipe do IBM Life Sciences Solutions Development, no laboratório da IBM Raleigh, em Durham, Carolina do Norte. Trabalha com a IBM desde 2002. Atualmente, está empenhado no desenvolvimento do IBM Solution for Compliance in a Regulated Environment (SCORE). É possível entrar em contato com ele pelo e-mail shyjee@us.ibm.com. |
Avalie esta página
| |
