![Fechar [x]](http://dw1.s81c.com/i/c.gif){kind=small}
O IBM WebSphere Business Events (daqui em diante chamado de Business Events) ajuda a detectar, avaliar e responder ao impacto de eventos com base na descoberta de padrões de eventos acionáveis. Permite definir e gerenciar eventos, de forma que seja possível executar as ações oportunas. Isso resulta na redução do custo total de propriedade por meio de implementação sem código. Para assegurar que a implementação do Business Events seja altamente disponível, sua implementação deve usar os recursos existentes de alta disponibilidade do WebSphere Application Server Network Deployment (daqui em diante chamado de Application Server ND).
Atualmente, é necessária configuração adicional para usar essa funcionalidade do Application Server no WebSphere Business Events. Neste artigo, você saberá como é possível desenvolver uma arquitetura altamente disponível usando a funcionalidade inerente do Application Server ND junto com configurações específicas do aplicativo no WebSphere Business Events e no WebSphere MQ (daqui em diante chamado de MQ), a fim de oferecer alta disponibilidade.
O termo "alta disponibilidade" tem muitas definições mas, na maioria das vezes, refere-se a um sistema que está disponível na maior parte do tempo, por exemplo, um sistema com indisponibilidade mínima, como uma indisponibilidade programada, necessária para atualizações ou manutenção. A disponibilidade é medida com o percentual de tempo de atividade dividido pelo tempo total. Alta disponibilidade é quando esse número é superior a 99,x, em que x representa entre uma e três posições de precisão (por exemplo, a disponibilidade de 99,999% é chamada de "disponibilidade cinco noves").
Os termos disponibilidade e alta disponibilidade podem ter diferentes significados dependendo do público. Esses termos descrevem diversas metas de negócio e requisitos técnicos, desde metas de disponibilidade somente de hardware a metas críticas da missão.
Um sistema disponível é aquele formado por um conjunto de recursos compartilhados que abrangem todo o sistema e colaboram para o fornecimento de serviços essenciais. Sistemas de alta disponibilidade combinam o uso de software e hardware padrões do setor para minimizar a indisponibilidade restaurando rapidamente os serviços quando um sistema, componente ou aplicativo falha. Embora a restauração não ocorra instantaneamente, os serviços são restaurados rapidamente -- muitas vezes em menos de um minuto.
Uma solução de alta disponibilidade assegura que o sistema conseguirá se recuperar automaticamente no caso de uma falha de software ou de hardware. O objetivo de alcançar a alta disponibilidade é eliminar a indisponibilidade programada e minimizar a indisponibilidade não programada. Frequentemente, as organizações têm expectativas inapropriadas em relação às metas de disponibilidade e possivelmente exigem níveis de disponibilidade superiores àqueles pelos quais estão realmente dispostas a pagar. Uma vez que as organizações compreendem o custo total de implementação, muitas delas reavaliam suas exigências. A implementação de uma solução de alta disponibilidade inclui, sem limitação, os seguintes custos:
- Hardware
- Software
- Infraestrutura de rede
- Treinamento
- Funcionalidade do serviço
- Operações
A alta disponibilidade como meta
Conforme a indisponibilidade se aproxima de 0, a alta disponibilidade se aproxima de 100%. A indisponibilidade inclui indisponibilidade planejada e não planejada.
Tabela 1. Médias de indisponibilidade
| Percentual | Horas de indisponibilidade semanal | Minutos de indisponibilidade semanal | Média de indisponibilidade anual |
| 90.000% | 10 | 600 | 28080 minutos |
| 99.000% | 1 | 60 | 3089 minutos |
| 99.900% | 0.1 | 6 | 526 minutos |
| 99.990% | 0.01 | 0.6 | 53 minutos |
| 99.999% | 0 | 0.06 | 5 minutos |
De acordo com Nota da Gartner Research, Número de ID: AV-13-9472, as causas da indisponibilidade e suas probabilidades associadas são as seguintes:
Tabela 2. Causas e probabilidade de indisponibilidade
| Causas de indisponibilidade | Probabilidade |
| Falhas de software (não planejadas) | 40% |
| Falhas de hardware (não planejadas) | 10% |
| Erros humanos (não planejados) | 15% |
| Problemas ambientais (não planejados) | 5% |
| Indisponibilidade planejada | 30% |
Como visto na Tabela 2, existem duas categorias de indisponibilidade: não planejada e planejada. As falhas de hardware e aquelas relacionadas ao ambiente são as menos prováveis, enquanto as falhas de software e a indisponibilidade planejada contribuem com até 70% da indisponibilidade do sistema.
Com base na tabela acima e na alta disponibilidade desejada de 99,99%, a indisponibilidade permitida para as várias causas é mostrada na Tabela 3:
Tabela 3. Indisponibilidade permitida para várias causas
| Causas de indisponibilidade | Indisponibilidade em um ano |
| Falhas de software (não planejadas) | 21 minutos |
| Falhas de hardware (não planejadas) | 5 minutos |
| Erros humanos (não planejados) | 8 minutos |
| Problemas ambientais (não planejados) | 3 minutos |
| Indisponibilidade planejada | 16 minutos |
Minimizando o tempo de recuperação
É possível minimizar os tempos de recuperação de falha do hardware fazendo o seguinte:
- Tratando a redundância de hardware: A redundância de hardware inclui itens como roteadores, servidores, discos e fontes de alimentação redundantes. O hardware redundante não se limita apenas a máquinas físicas nas quais a arquitetura está sendo executada, mas também inclui a infraestrutura associada, como instalações de alimentação e resfriamento.
- Fornecendo detecção automatizada de falhas: Para fornecer uma verdadeira recuperação de hardware, é necessária alguma forma de detecção automatizada de falhas. Isso pode ser fornecido por meio de softwares como High Availability Cluster Multi-Processing (HACMP), Application Server ND e de várias outras soluções de alta disponibilidade, dependendo da plataforma que está sendo implementada e da complexidade da solução.
- Usando recursos de hardware de hot swap: O tempo de recuperação de hardware pode ser minimizado usando recursos de hardware de hot swap, como discos, placas de rede a assim por diante.
- Fornecendo um ambiente estável e seguro para a localização física do sistema: Problemas relacionados ao ambiente podem ser minimizados usando um ambiente estável e seguro para a localização física do sistema. Por exemplo, se o servidor estiver sob a mesa de alguém, a chance de falha será maior do que se estiver um local seguro.
É possível minimizar erros humanos fazendo o seguinte:
- Oferecendo uma interface simples para o gerenciamento do sistema: Um dos maiores obstáculos relacionados a erros humanos para a alta disponibilidade é a falta de uma interface simples para o gerenciamento do sistema. Se a sua equipe de suporte tiver de usar vários consoles para gerenciar um processo ou detectar uma condição de erro, as ocorrências de erro humano aumentam.
- Oferecendo um procedimento simples de operação do sistema: O segundo problema que causa ainda mais indisponibilidade em uma condição de falha é a falta de um procedimento simples de operação do sistema. Isso pode ser tão complexo quando um plano contra desastres no nível da empresa ou tão simples como um processo definido para um aplicativo específico. Em qualquer um desses casos, é necessário armazenar esses planos em um local conveniente para fins de recuperação. Esses documentos também podem ser chamados de documento de procedimento operacional. É possível minimizar a indisponibilidade planejada e não planejada por meio do uso de um procedimento de operação do sistema que seja simples e bem definido.
Outras formas de aumentar a disponibilidade incluem:
- Tratar a redundância de software
- Fornecer detecção automática de falha de software
- Oferecer recuperação automática de serviços de software
- Fornecer configuração específica de software
- Tratar de projetos específicos de aplicativos
Compreendendo a solução de alta disponibilidade do Business Events
Com o Business Events V6.2 e V7.0, a capacidade de fornecer um ambiente de alta disponibilidade aumentou drasticamente desde os releases iniciais do produto. Com o Business Events, a IBM fornece uma solução completamente escalável e disponível explorando a funcionalidade natural do Application Server ND. No entanto, os conectores de tecnologia não aproveitam essa funcionalidade, por isso precisam contar com outro método de fornecimento de alta disponibilidade.
O Service Integration Bus (daqui em diante chamado de SiBus) é uma entidade lógica que é criada e configurada após a instalação do WebSphere Application Server por meio do console administrativo ou da linguagem de script wsadmin. É possível configurar o SiBus em dois modos ou em um cluster do Application Server, dependendo dos requisitos da implementação. Devido ao fato de o SiBus ser uma entidade lógica baseada na implementação física de um bean acionado por mensagens (MDB), nem a alta disponibilidade nem a funcionalidade do gerenciamento da carga de trabalho são inerentes. É necessário configurar independentemente a implementação física subjacente antes da criação.
O restante deste artigo mostrará uma infraestrutura altamente disponível do Business Events usando o WebSphere MQ como barramento externo de mensagens. Novamente, tenha em mente que os adaptadores de tecnologia não são, por natureza, projetados para a alta disponibilidade. No entanto, eles podem ser executados em modo ativo/passivo para fornecer um nível mais alto de disponibilidade a esses aplicativos alimentadores. O Business Events, por natureza, são itens temporários e geralmente se tornam inválidos após algum período. Dessa forma, por padrão, todos os eventos são não-persistentes por natureza. Além disso, é necessário definir para persistente o estado de qualquer evento que precise sobreviver a uma falha, assim como é preciso definir tais eventos como eventos duráveis no Business Events.
Visão geral das configurações do cluster.
A configuração do cluster de alta disponibilidade é a configuração padrão criada quando é criado um cluster de servidores de aplicativo em uma célula. Quando o SiBus é criado, há apenas um mecanismo do sistema de mensagens ativo em um dos servidores do cluster, e todas as solicitações de serviço aos membros do cluster são roteadas através desse único mecanismo. Por isso, para um cluster de n servidores, haverá uma ação put da mensagem local para rotear a solicitação de serviço no servidor com o mecanismo do sistema de mensagens ativo, e (n-1) ações put da mensagem remota para cada servidor com mecanismos do sistema de mensagens inativos.
A vantagem dessa configuração é que, quando há uma falha do mecanismo do sistema de mensagens, outro servidor torna-se ativo e todas as ações put remotas são roteadas através do mecanismo do sistema de mensagens recentemente ativado. Além disso, por haver apenas um único servidor roteando mensagens para o serviço de destino, qualquer sequência de mensagem é persistida através do barramento.
A desvantagem dessa configuração está relacionada ao desempenho, pois efetivamente há um gargalo de mensagens dentro da configuração do cluster, e (n-1) de todas as solicitações de serviço são puts remotos para o mecanismo do sistema de mensagens ativo.
Alta disponibilidade e failover do WebSphere MQ
Usando o MQ junto com um aplicativo de serviço de alta disponibilidade, como o HACMP, Microsoft™ Cluster Service ou Veritas Cluster Server, é possível aprimorar ainda mais a disponibilidade dos gerenciadores de fila do MQ alimentando os mecanismos do Business Events juntamente com os conectores de tecnologia.
Um conjunto de serviço deve conter todos os processos e recursos necessários para fornecer um serviço altamente disponível e, em condições ideais, deve conter somente esses processos e recursos. Recomenda-se usar o gerenciador de filas e o adaptador JMS como unidade de failover do MQ, já que o Application Server ND identificará o failover do aplicativo usando a alta disponibilidade do Application Server. Consequentemente, para otimizar a configuração, posicione cada gerenciador de filas em um pacote separado, junto com os recursos dos quais ele depende. Dessa forma, o conjunto de serviços deve conter os discos compartilhados usados por um gerenciador de filas, que deve estar em um grupo de volumes reservado exclusivamente ao pacote, ao endereço IP usado para estabelecer conexão com o gerenciador de filas (o endereço IP do pacote) e a um servidor de aplicativos, que representa o gerenciador de filas.
O gerenciador de filas que será usado em um cluster de alta disponibilidade precisa ter seus logs e dados em discos compartilhados, de forma que possam ser acessados por um nó sobrevivente no caso de uma falha de nó. O nó executado em um gerenciador de filas deve também manter uma determinada quantidade de arquivos em discos internos. Esses arquivos incluem arquivos relacionados a todos os gerenciadores de filas no nó, como /var/mqm/mqs.ini, e arquivos específicos do gerenciador de filas que são usados para gerar informações de controle interno. Os arquivos relacionados a um gerenciador de filas são, dessa forma, divididos entre discos internos e compartilhados. Use um único disco compartilhado para todos os dados de recuperação (logs e dados) relacionados a um gerenciador de filas.
A Figura 1 ilustra uma típica configuração ativa/passiva. Em cada servidor de sistema de mensagens, existe um conjunto de códigos do aplicativo que consiste no servidor MQ, no adaptador JMS para o Business Events e no pacote de conexão do cliente para o Application Server. Quando ocorre um evento de alta disponibilidade, esse grupo de recursos executará failover para a máquina secundária e continuará processando a partir de onde parou.
Figura 1. Típica configuração ativa/passiva
A Figura 2 ilustra a solução de alta disponibilidade do Business Events. Ela consiste em um cluster do MQ e em um cluster do Business Events. O cluster do Business Events comunica-se com o cluster do MQ por meio do uso de pontos de ação e pontos de evento do JMS ou de fila de ações e fila de eventos. Cada um desses tipos de filas é definido de forma diferente e tem suas limitações. A Figura 2 mostra a configuração que pode ser usada para fluxos de eventos.
Figura 2. Configuração do fluxo de eventos
A configuração padrão para um servidor do Business Events é usar pontos de assinatura. Essa configuração tem um problema inerente, como qualquer solução que use assinatura a um tópico de eventos duplicados em cada assinante. É possível solucionar esse problema com um único mecanismo de eventos do gateway, mas isso causa um ponto único de falha ou uma camada adicional de complexidade que pode não ser necessária em todos os casos.
O segundo método de conectividade é usar conectores de tecnologia, que usam parâmetros definidos dentro das ferramentas dos pontos de contato. Usando filas ponto a ponto e fazendo com que a carga do fluxo de eventos seja balanceada pelo MQ a partir do lado interno, é possível assegurar que não haja eventos duplicados sendo recebidos pelo Business Events.
O terceiro método é configurar o Business Events para usar uma fila estática para seus eventos. A limitação desse método é que não há segregação de eventos no servidor de eventos. Todos os eventos são recebidos nessa única fila, processados e vão para uma fila de ação única. Essa configuração exige um broker externo para rotear a ação até seu destino definitivo.
Neste ponto, é necessário que você esteja ciente de que quaisquer eventos dinâmicos não-persistentes e não-duráveis serão perdidos no caso de uma falha. No caso de dados contextuais, esses dados devem ser persistidos para a tabela de etapas e devem estar disponíveis para o novo nó do Business Events quando ele sofrer failover. Essa configuração tem uma limitação conhecida: No caso do conector de tecnologia JMS, a segurança não deve estar ativada. Todos os outros conectores de tecnologia não podem se tornar altamente disponíveis nesse momento devido a uma limitação da Estrutura do Conector de Tecnologia. Trataremos disso mais adiante. Caso seja necessária a alta disponibilidade para outros conectores de tecnologia, recomendamos que você use alguma forma de barramento de integração, como WebSphere Message Broker ou WebSphere Process Server, em vez do conector de tecnologia associado.
O armazenamento em cluster do MQ fornecerá balanceamento de carga para todos os eventos de entrada, e o adaptador JMS e o gerenciador de filas executarão failover como um par para o nó passivo no cluster de disponibilidade. No entanto, o uso de armazenamento em cluster do MQ causará vários hops no cluster de servidor do Business Events para eventos baseados em contexto, como um objeto de contexto ou um objeto contextual intermediário de resumo, já que esses eventos são associados a um único nó do Business Events. Consequentemente, espere alguma latência adicional com objetos desse tipo.
Quando for necessário um ambiente de alta disponibilidade mais robusto
Quando for necessário um ambiente de alta disponibilidade mais robusto, configure um contêiner inativo secundário em cada instância do Application Server para que a rolagem não ocorra. Quando o evento for recebido no mecanismo do Business Events, ocorrerá um balanceamento adicional de carga, pois isso faz parte da funcionalidade base do armazenamento em cluster do Business Events. Configure a tabela de etapas para usar ObjectGrid para replicação; a tabela deve ser submetida a backup por um armazenamento de dados como DB2® ou Oracle®. Com essa configuração, os dados serão replicados em todos os nós do cluster. Esses dados de contexto serão, em seguida, usados para recuperação a partir do ponto de falha, quando eventos duráveis são usados no caso de um evento de falha. Essas replicações não estarão ativas no cluster até que o nó contextual de um evento não esteja mais disponível. Nesse momento, ObjectGrid atribui um novo manipulador de contexto ao evento e o processamento continua. Para um determinado evento, somente um manipulador de contexto está disponível no cluster por vez. É isso que causa os vários hops mencionados acima.
Figura 3. Arquitetura robusta de alta disponibilidade
Quando você estiver planejando sua infraestrutura de eventos de alta disponibilidade, tenha em mente que somente eventos duráveis serão preservados em um evento de failover. Depois que um evento tiver consumido a fila, esses eventos não são recuperados.
Arquitetura de alta disponibilidade
A configuração a seguir define uma instância para cada nó dos nós do Business Event que está sendo executado em um cluster do Application Server ND, juntamente com uma máquina passiva pareada para cada nó do cluster. Essa separação permite que um nó seja submetido à manutenção padrão enquanto o outro nó continua o processamento. Além disso, a criação de pares do nó de failover permite que o nó e todos os seus recursos, incluindo o MQ, executem failover como unidade exclusiva para a máquina passiva. As filas do MQ, que são usadas para mensagens de entrada e saída, serão armazenadas em uma rede de array de armazenamento comum e podem ser usados procedimentos padrão de alta disponibilidade para o failover. A Figura 4 mostra o layout comum de plataforma para uma região de produção.
Observação: Como os conectores de eventos não são usados nessa configuração, o tráfego JMS de entrada é limitado a uma única fila para eventos duráveis e não-duráveis.
Figura 4. Arquitetura sem uso de Conectores de Tecnologia
Observação: A segurança do MQ não pode estar ativada, já que os conectores de energia atualmente não suportam essa ativação de maneira a fornecer alta disponibilidade. As mensagens da solução podem tornar-se isoladas se o MQ e o conector de tecnologia não forem submetidos a failover como par junto com os logs e filas armazenados em uma unidade de rede de array de armazenamento para failover. O Diagrama abaixo mostra como essa arquitetura deve funcionar.
Configurando com o uso de conectores de tecnologia
A configuração a seguir define uma máquina para cada nó dos nós do Business Event que está sendo executado em um cluster do Application Server ND, juntamente com uma máquina passiva única. Essa separação permite que um nó seja submetido à manutenção padrão enquanto o outro nó continua o processamento. Quando ocorrer um evento, a máquina passiva será iniciada, o nó de processamento se unirá ao cluster do MQ e começará a receber eventos. Isso permite que seja executado processamento adicional, conforme necessário, iniciando e interrompendo a instância e permitindo que ela se una ao cluster.
Outra variação no esquema acima é colocar o MQ e os conectores de tecnologia em um grupo de servidores de alta disponibilidade e fazer com que executem failover como par na caixa passiva. Isso exige que o conector de tecnologia seja configurado para publicar em um tópico do Business Events que não esteja necessariamente na mesma máquina. Também é necessário que o MQ coloque suas filas e logs em uma rede de array de armazenamento, de forma bastante semelhante à solução primária mostrada para produção.
Observação: A segurança do MQ não pode estar ativada, já que os conectores de energia atualmente não suportam essa ativação de maneira a fornecer alta disponibilidade. As mensagens da solução podem tornar-se isoladas se o MQ e o conector de tecnologia não forem submetidos a failover como par junto com os logs e filas armazenados em uma unidade de rede de array de armazenamento para failover.
Figura 5. Alta disponibilidade do conector de tecnologia
Configurações de interesse do JMS para o Business Events
Tabela 4. Configurações de JMS do WebSphere ND para o Business Events.
É possível encontrar as seguintes configurações de fila na caixa de diálogo de configuração do JMS, no console administrativo do Business Events. Como mostra a Tabela 4, todas essas entradas do JMS podem ser do tipo publicar-assinar ou fila estática. Por padrão, as entradas são do tipo publicar-assinar. Se os conectores de tecnologia não forem usados, será necessário configurar manualmente essas entradas do JMS para usar filas estáticas no lugar. Além disso, observe que todas as mensagens precisam estar no formato do Business Events V6.2, conforme descrito no Centro de Informações do WebSphere Business Events V6.2. Você também está limitado a duas filas de entrada e duas filas de saída, uma durável e uma não-durável. Se você desejar usar essas filas diretamente, recomendamos que coloque o WebSphere Message Broker ou o WebSphere Process Server na sua arquitetura para identificar a transformação e o roteamento de eventos para dentro e para fora do servidor do Business Events.
Este artigo demonstrou como é possível utilizar o Business Events em um ambiente de alta disponibilidade usando a funcionalidade integrada do Application Server, além de configurações adicionais e opções de configuração para possibilitar uma infraestrutura empresarial do evento que seja altamente disponível.
- Centro de Informações do WebSphere Business Events V7: Obtenha a documentação completa do produto.
-
Área do developerWorks BPM: Obtenha os mais recentes recursos técnicos de soluções IBM BPM, incluindo downloads, demos, artigos, tutoriais, eventos, webcasts e mais.
Índice
- Introdução
- O que é alta disponibilidade?
- A alta disponibilidade como meta
- Minimizando o tempo de recuperação
- Compreendendo a solução de alta disponibilidade do Business Events
- Visão geral das configurações do cluster.
- Alta disponibilidade e failover do WebSphere MQ
- Quando for necessário um ambiente de alta disponibilidade mais robusto
- Arquitetura de alta disponibilidade
- Configurando com o uso de conectores de tecnologia
- Configurações de interesse do JMS para o Business Events
- Resumo
- Recursos
- Sobre o autor
- Comentários
Conheça a IBM da sua cidade
Tags
Use a barra de rolagem para ver mais ou menos tags.
Tags populares mostra as principais tags para esta zona de conteúdo em particular (por exemplo, Java technology, Linux, WebSphere).
Minhas tags mostra suas tags para esta zona de conteúdo em particular (por exemplo, Java technology, Linux, WebSphere).
Tags de artigo populares |
Minhas tags de artigoIr para lista de tags
Tags de artigo populares |
Minhas tags de artigo