Gerencie um Aplicativo J2EE com Extensões TSAM

Compare a aquisição de recursos, release e cargas de trabalho para um aplicativo em nuvem de três camadas

IBM ® Tivoli® Service Automation Manager (TSAM) V7.2.2 apresenta o conceito da extensão, um conjunto de componentes de software do Tivoli Service Automation Manager que pode implementar uma nova solução de automação de serviço de TI (conhecida como uma definição de serviço) ou incluir recursos para definições existentes de serviço. Neste artigo, os autores explicam como ajustar a política de balanceador de carga às necessidades do seu sistema, como incluir e remover servidores de aplicativo como a carga de trabalho das mudanças de aplicativo de negócios e como modificar as regras de firewall e por que pode ser necessário fazer isso. Na introdução deste artigo, os autores definiram um cenário no qual o resultado desejado é implementar de forma segura um aplicativo J2EE de três camadas na nuvem e demonstraram como configurar e fornecer extensões no Tivoli Service Automation Manager para concluir a implementação.

Michele Crudele, Software Architect, IBM

Michele Crudele é arquiteto de software e trabalha no Laboratório Tivoli do Grupo IBM Software em Roma. Ele possui 20 anos de experiência em TI. A maior parte, com ênfase no desenvolvimento de produtos e soluções de gerenciamento de sistemas. Michele possui ampla experiência técnica de trabalho em diferentes disciplinas, como gerenciamento de configuração e mudança, monitoramento e gerenciamento de disponibilidade, tecnologias de computação autônoma IBM e gerenciamento de ativo digital para o setor de mercado de publicação. Atualmente, Michele está concentrado nas soluções de computação em nuvem e é o arquiteto líder das extensões do TSAM.



Fabio Cerri, Software Designer, IBM

Fabio Cerri é designer de software e trabalha no Laboratório Tivoli do Grupo IBM Software em Roma. Ele possui 12 anos de experiência em TI, na maior parte, com ênfase no desenvolvimento de produtos e soluções de gerenciamento de sistemas. Fabio possui ampla experiência técnica de trabalho em diferentes disciplinas, como gerenciamento de mudança/configuração, gerenciamento de licença de software e soluções de computação em nuvem como designer líder da rede TSAM e extensões de armazenamento.



30/Mar/2012

O Tivoli Service Automation Manager 7.2.2 apresenta o conceito de extensão, um conjunto de componentes de software do TSAM que inclui mais recursos na plataforma TSAM. Uma extensão normalmente (mas não se limita a):

  • Pode implementar uma nova solução de automação de serviço de TI, o que no TSAM é chamado de definição de serviço; por exemplo, uma solução de armazenamento como um serviço para oferecer diretórios iniciais aos alunos de uma universidade.
  • Pode incluir recursos nas definições de serviço existentes; por exemplo, estenda o TSAM pronto para uso como uma solução de serviço permitindo a conexão de discos extras em máquinas virtuais além do disco de boot.

As extensões são desenvolvidas e liberadas fora do ciclo de desenvolvimento de TSAM pela IBM ou por Equipes de Serviços de Atendimento ao Cliente. As extensões desenvolvidas pela IBM são liberadas na Integrated Service Management Library sem encargo algum para clientes TSAM; elas são fornecidas com documentação para instalação e configuração e um guia de usuário que segue os padrões IBM. O Centro de Informações do IBM Tivoli Service Automation Manager é o ponto de entrada para documentação on-line das extensões liberadas pela IBM. (Consulte Recursos.)

Entre outras, a IBM liberou duas extensões que permitem gerenciar a configuração de dispositivos de rede para incluir segurança, escalabilidade e redundância de projetos de servidores virtuais criados com o TSAM:

  • Extensão do IBM Tivoli Service Automation Manager 7.2.2 para Firewall Juniper SRX
  • Extensão do IBM Tivoli Service Automation Manager 7.2.2 para F5 BIG-IP Load Balancer

A extensão do Firewall Juniper SRX fornece a possibilidade de confinar automaticamente os servidores virtuais fornecidos com um projeto do TSAM em uma VLAN/sub-rede protegida pelo firewall corporativo Juniper SRX usando um conjunto de regras padrão. As regras de firewall podem ser redefinidas posteriormente pelos administradores da nuvem durante o ciclo de vida do projeto usando uma oferta de serviço fornecida pela extensão Modificar Regras de Firewall. As regras padrão podem ser customizadas durante a configuração inicial da extensão, baseadas nas necessidades do cliente.

A extensão para F5 BIG-IP Load Balancer oferece a possibilidade de por um "balanceador de carga virtual" por trás dos servidores virtuais fornecidos com um projeto TSAM para aumentar a escalabilidade e a redundância dos aplicativos instalados nos servidores: um aplicativo pode ser anunciado em um endereço IP virtual público (VIP) na VLAN/sub-rede do projeto do TSAM criando uma Política de Balanceador de Carga. Uma Política de Balanceador de Carga é identificada pelo VIP:Port para alcançar o aplicativo e pelo cluster de servidores virtuais do projeto do TSAM que executa o aplicativo.

Esses recursos possibilitam a capacidade de um cliente corporativo em fornecer aplicativos de negócios em camadas (como um aplicativo J2EE) a seus escritórios filiais, parceiros de negócios e clientes de uma forma rápida, reproduzível, segura, escalável e redundante.

No primeiro artigo sobre este tópico, é definido um cenário em que o resultado desejado é implementar de forma segura um aplicativo J2EE de três camadas na nuvem e demonstrar como configurar e fornecer extensões no TSAM para concluir a implementação; recomendamos que leia esse artigo a fim de entender melhor os métodos esclarecidos no artigo.

Este artigo explica como ajustar a política de balanceador de carga às necessidades do seu sistema; como incluir e remover os servidores do aplicativo como a carga de trabalho das mudanças do aplicativo de negócios e como modificar as regras de firewall e por que pode ser necessário fazer isso.

Uma Rápida Visita ao Cenário

O cliente ABC é uma empresa que está operando em uma solução de nuvem privada (no local) baseada no TSAM 7.2.2 e nas extensões para o Firewall Juniper SRX e BIG-IP F5 Load Balancer. Ele fornece serviços a escritórios filiais, parceiros de negócios e clientes por meio da plataforma do TSAM. Em especial, ele conta com os recursos prontos para uso da plataforma para fornecer aplicativos da web a clientes acessíveis por protocolos padrão http/https.

Um aplicativo da web típico que o ABC usa é um aplicativo J2EE de três camadas com um servidor http, servidor de aplicativos e servidor de banco de dados. Em uma implementação tradicional, esses servidores são isolados logicamente um do outro por roteadores e firewalls que limitam a conectividade de rede e o acesso aos servidores. O servidor de banco de dados geralmente acessa seus dados a partir de uma zona de armazenamento segura.

Sem fazer o download das extensões para Firewall e Balanceador de Carga, o ABC teria de configurar seus próprios processos para isolar os servidores em diferentes segmentos de rede e balancear as solicitações aos servidores de aplicativo que geralmente são implementados para formar um cluster. Mas o ABC é um cliente sábio, portanto, como já possui os dispositivos de rede BIG-IP F5 e Juniper SRX, ele decide configurar as extensões de TSAM a fim de padronizar o layout de seus aplicativos da web.

Para obter uma análise mais detalhada deste cenário, leia o primeiro artigo sobre este tópico.

Agora, vamos explorar o balanceamento de carga e a adaptação a regras de firewall de rede.


Apresentando o Balanceamento de Carga

A Extensão do TSAM para BIG-IP F5 Load Balancer fornece ofertas de serviço para balanceamento de carga de trabalho entre os servidores de aplicativo do aplicativo de negócios. O artigo que acompanha descreve a etapa necessária para fazer isso durante a implementação inicial (na seção Fornecimento, etapa 4). Entretanto, ele não oferece muitas informações sobre os atributos de uma política de balanceador de carga.

Embora possa deixar valores padrão selecionados quando implementar o aplicativo de negócios em seu laboratório de teste, é importante ter um melhor entendimento do significado desses atributos ao implementá-lo para seus clientes, porque escolher a política correta do balanceador de carga pode fazer a diferença em termo de desempenho e consumo de recursos.

Vamos começar aprendendo a customizar a política de balanceador de carga.


Customizando a Política do Balanceador de Carga

Após a implementação inicial, é possível modificar a forma como a carga de trabalho é gerenciada pelo balanceador de carga a qualquer momento usando a oferta de serviço Modificar Política de Balanceador de Carga que basicamente requer os mesmos parâmetros de Criar Política de Balanceador de Carga (com a exceção dos atributos nome e VIP:port da política que não podem ser alterados).

A política do balanceador de carga é um artefato interno definido pela Extensão do TSAM para BIG-IP F5 Load Balancer que compõe as informações necessárias para configurar melhor o dispositivo BIG-IP. sua tarefa é simplificar a tarefa do solicitante do aplicativo de negócios o quanto for possível e depois ocultar a complexidade do dispositivo BIG-IP por trás de alguns parâmetros intuitivos que permitem que o código de extensão automatize as etapas de configuração do BIG-IP.

Para ter uma ideia do tipo de consideração que o solicitante de seu aplicativo de negócios precisaria ter sem a abstração da política do balanceador de carga, pense no perfil de configuração como um contêiner de configurações para definir o comportamento do tráfego de rede (por exemplo, http) no dispositivo BIG-IP, cada configuração permitindo um determinado recurso. Exemplos desses recursos são:

  • A inserção dos cabeçalhos em solicitações HTTP
  • A compactação de respostas de servidor HTTP
  • Autenticação de aplicativo
  • definição do conjunto de conexões definição do conjunto de conexões e assim por diante.

A abstração da política do balanceador de carga define automaticamente os melhores perfis de configuração a aplicar para configuração do dispositivo BIG-IP baseado em:

  • O tipo de tráfego (Protocolo na Figura 1) entre HTTP, HTTPS, TCP e UDP.
  • O tipo de endereço IP virtual (Tipo de Servidor Virtual na Figura 1) entre Padrão e Desempenho. Desempenho especifica um VIP do qual deseja aumentar a velocidade de processamento de HTTP ou solicitações de 4 camadas.
  • Se desejar reutilizar a conexão entre o BIG-IP e os servidores virtuais balanceados (Conjunto de Conexão na Figura 1) que reduz a carga do servidor virtual minimizando a configuração de conexão e derrubando (ativar esta opção ativará o recurso F5 Networks OneConnect que otimiza o uso de conexões de rede ao manter abertas conexões do lado do servidor e agrupando-as para reutilização).
  • Se desejar que as solicitações de cliente sejam direcionadas para o mesmo servidor virtual no projeto em toda a vida de uma sessão ou durante sessões subsequentes (Persistência de Sessão na Figura 1).
Figura 1. Atributos da Política de Balanceador de Carga
Atributos da Política de Balanceador de Carga

Para o aplicativo de negócios padronizado definido neste artigo e o acompanhante, configure uma política de balanceador de carga com:

  • Protocolo: HTTP.
  • Tipo de Servidor Virtual: Use Padrão ao testar o aplicativo; use Desempenho ao implementá-lo em seus clientes.
  • Conjunto de Conexões: Esta opção é selecionada automaticamente se selecionar um VIP Desempenho embora possa decidir usá-lo ou não em caso de um VIP Padrão.
  • Persistência de Sessão: Este parâmetro depende das características do aplicativo de negócios. Se precisar configurá-lo, lembre-se de que o código de extensão configura o perfil de persistência de cookies no dispositivo BIG-IP que usa um cookie HTTP armazenado no computador de um cliente para permitir que o cliente se reconecte ao mesmo servidor virtual balanceado visitado anteriormente em um website.

Como pode ver na Figura 1, informações adicionais são transportadas pela política do balanceador de carga:

  • O algoritmo de roteamento usado pelo dispositivo BIG-IP a balancear a carga de trabalho entre os servidores virtuais (Algoritmo na Figura 1) pode ser round robin, conexões least ou previsível. Para qualquer solicitação do cliente, o BIG-IP executa o algoritmo para selecionar o servidor virtual apropriado ao qual rotear a solicitação. Para fazer isso, são necessárias algumas informações de monitoramento e disponibilidade sobre os servidores virtuais balanceados, informações que são coletadas periodicamente por um monitor assim chamado.
  • Os parâmetros de verificação de funcionamento (Protocolo de Análise, Intervalo de Verificação e Tempo Limite na Figura 1) são usados pelo código de extensão para configurar o monitor BIG-IP. O intervalo de verificação especifica a frequência na qual o BIG-IP analisa os servidores virtuais e o tempo limite especifica o número de segundos que o servidor virtual possui, nos quais responderá à solicitação do monitor. Após isto, é considerado inativo e não usado como destino para a nova conexão.

Qual é o algoritmo mais adequado a se usar para o aplicativo de negócios definido neste artigo, você pode se perguntar? Bem, isso depende das características do aplicativo.

  • O algoritmo mais simples é round robin. Esse é o local em que BIG-IP seleciona o próximo servidor virtual em uma lista circular dos que respondem ao monitor.
  • Um algoritmo mais eficiente é least connections. Esse é o local em que BIG-IP mantém uma estatística das conexões manipuladas por cada servidor virtual balanceado e passa uma nova conexão ao membro do conjunto que tinha menos conexões com o tempo.
  • O melhor algoritmo que pode ser usado é preditivos; é onde o BIG-IP usa o mesmo método de classificação, mas a tendência também é analisada para entender se os desempenhos do nó estão melhorando ou declinando.

Quanto melhor o algoritmo, mais recursos ele requer do BIG-IP para executar cálculos. Então, talvez queira selecionar o round robin ao testar o aplicativo de negócios, alterando a política de balanceador de carga posteriormente para previsível ao anunciá-la aos seus clientes.

A política de balanceador de carga pertence a um único Projeto do TSAM e pode abranger servidores virtuais de um único projeto. Mais políticas podem ser implementadas em um único projeto, mas cada uma requer um par VIP:port dedicado para acesso externo.

Agora, vamos examinar como incluir servidores de aplicativos conforme a carga de trabalho crescer e removê-los conforme a carga de trabalho diminuir.


Incluindo e Removendo Servidores de Aplicativos

Conforme o número de ocorrências para o aplicativo de negócios aumenta, seus clientes podem perceber uma degradação no tempo de resposta. É possível prever este efeito ao executar relatórios de análise de tendência periódicos e incluir servidor de aplicativos de uma forma adequada.

O administrador responsável por seu aplicativo de negócios faz isso usando essas ofertas de serviços:

  1. Oferta de serviço do TSAM Incluir Servidor ao Projeto: use este serviço para solicitar outro servidor de aplicativos para o projeto do aplicativo de negócios.
  2. Oferta de serviço Modificar Política de Balanceador de Carga: após o TSAM fornecer o novo servidor de aplicativos, use este serviço para incluir o servidor no balanceador de carga. Na janela Criar Política de Balanceador de Carga, inclua uma marca de seleção no nome do host do novo servidor (consulte a Figura 2).
Figura 2. Conjunto de Política do Balanceador de Carga de Servidores Virtuais
Conjunto de Política do Balanceador de Carga de Servidores Virtuais

Quando ocorre o contrário (seus relatórios de análise de tendência falam sobre uma diminuição na utilização de seus aplicativos de negócios), provavelmente você vai querer liberar recursos para outros usos em seu ambiente de TI ou reduzir o consumo de energia em seu datacenter. É possível decidir se desativará alguns dos servidores de aplicativos ou se os liberará, o que também libera espaço de armazenamento nos armazenamentos de dados dos hypervisors.

Se o administrador do aplicativo de negócios decidir desativar o servidor de aplicativos, a oferta de serviço Parar Servidor do TSAM será usada e é isso — o balanceador de carga logo detecta que o servidor não responde (por meio do monitor) e para as conexões de roteamento. Ele começa a rotear novamente as conexões assim que o servidor é reiniciado.

Se o administrador decide remover definitivamente o servidor de aplicativos do projeto do aplicativo de negócios, essas ofertas de serviços serão usadas:

  1. Oferta de serviço Modificar Política do Balanceador de Carga: use este serviço para remover o servidor de aplicativos do balanceador de carga. Vá diretamente à segunda tela (Figura 2 novamente) e remova a marca de seleção para o nome do host do servidor.
  2. Oferta de serviço do TSAM Remover Servidor do Projeto: use este serviço para desprover o servidor.

Um dos melhores recursos que o TSAM oferece para tornar a computação em nuvem mais fácil é a capacidade de automatizar tarefas de gerenciamento incluindo provisão e desprovimento de servidores conforme a carga de trabalho se alterar. Veremos isso mais adiante.


Automatize a Provisão e o Desprovimento de Servidor de Aplicativos

Esta é a parte divertida... é como a seção anterior, mas não é necessário o administrador toda vez que uma mudança na carga de trabalho ocorrer. A quantia de recursos computacionais necessários por um aplicativo da web de uso pela produção pode variar muito — tanto a frequência da mudança quanto a quantia de recursos necessários — a quantia depende do tipo real de serviço fornecido. Aqui estão alguns cenários de exemplo.

  1. Um aplicativo de armazenamento eletroeletrônico on-line tem um aumento significativo de transações durante o período de Natal embora seja o restante do ano, a carga de trabalho é estável mesmo se aumentar de ano para ano.
  2. Um aplicativo corporativo que controla os picos de presença dos funcionários nos primeiros dias de cada mês e mostra uma linha quase plana durante os dias restantes do mês.
  3. Uma biblioteca on-line geralmente passa por uma redução significativa de empréstimos no verão.
  4. Um website de jornal on-line internacional passa por picos imprevisíveis quando eventos importantes acontecem no mundo.

A reação repentina e exata do sistema para adaptar os recursos de computação disponíveis para os requisitos reais do aplicativo é essencial para manter o acordo de nível de serviço (SLA) com os clientes e otimizar o uso dos recursos.

O TSAM e a Extensão do TSAM para BIG-IP F5 Load Balancer fornecem as ofertas de serviço necessárias para responder a mudanças de carga de trabalho conforme descrito nas seções anteriores; no entanto, essas ofertas não fornecem uma solução autônoma ou de autoajuste que é capaz de reconfigurar o aplicativo de negócios sem a intervenção manual do administrador. Isto é algo que deve ser criado de propósito pelo cliente.

O objetivo nesta seção é explicar como tal automação pode ser criada aproveitando as APIs públicas TPAE (Tivoli Process Automation Engine) e TSAM, assim como outras ferramentas. Algumas abordagens são ilustradas para incluir recursos de autoajuste na solução do TSAM, embora não esteja no escopo deste artigo para se aprofundar nos detalhes das soluções — ao contrário, os ponteiros são dados a diferentes tecnologias disponíveis e uma arquitetura comum usada para realizar a tarefa.

Primeiro, descreveremos a abordagem para a solução e os componentes necessários para implementá-la. Depois, converteremos essa abordagem genérica em duas implementações concretas diferentes que contam com diferentes tecnologias.

A Figura 3 resume os componentes da solução:

Figura 3. Os Componentes de uma Solução de Autoajuste para Balanceamento de Carga de Trabalho
Os Componentes de uma Solução de Autoajuste para Balanceamento de Carga de Trabalho
  • O Controlador orienta as operações de autoajuste do sistema comparando o SLA desejado do aplicativo de negócios com o comportamento atual observado e decidindo as medidas a tomar: ele decide quando fornecer ou desprover servidores de aplicativos, quando alternar em servidores de aplicativos inativos e quando desativar os ociosos.
  • O monitor Recursos é o componente que coleta o status do aplicativo da web e dos servidores virtuais subjacentes. Estes são os dados de entrada principais para iniciar o processamento do controlador. O padrão para alimentar o controlador pode ser baseado em uma verificação periódica dos recursos ou pode ser orientado por eventos; a escolha entre os dois depende das tecnologias reais adotadas para o monitor.
  • O gerente de recursos é o atuante, o componente a cargo de prover/desprover servidores de aplicativos e atualizar a política de balanceador de carga. É o TSAM com a Extensão para o BIG-IP F5 Load Balancer no cenário discutido neste artigo.

São propostas duas soluções aqui, ambas requerem customização de TPAE e qualificações de integração (Maximo Enterprise Adapter) e qualificações da API baseadas em REST do TSAM:

  1. A primeira solução utiliza os dados coletados pelos monitores de dispositivo BIG-IP para implementar o Controlador. Essa solução também requer qualificações de desenvolvimento para obter dados de monitores do BIG-IP.
  2. A segunda solução é um exemplo de um Controlador orientado a eventos baseado no produto IBM Tivoli Monitoring (ITM). Ela também requer qualificações de ITM para processar eventos (TEC ou Omnibus).

Vamos examinar ambas.

Utilizando BIG-IP

A Figura 4 descreve como a solução genérica é implementada neste caso.

Figura 4. Solução de Autoajuste para Balanceamento de Carga de Trabalho: Utilizar Dados de Monitores BIG-IP
Solução de Autoajuste para Balanceamento de Carga de Trabalho: Utilizar Dados de Monitores BIG-IP

O Controlador é implementado na plataforma TPAE usando uma tarefa planejada (Tarefa Cron do TPAE na imagem) que verifica periodicamente o status dos recursos e depois finalmente toma as ações apropriadas. A verificação nos recursos é enviada para o balanceador de carga BIG-IP, e uma biblioteca de ativação é incluída no Controlador para acessar a interface IControl do dispositivo.

A interface IControl inclui o suporte para diferentes ambientes de programação (como Java®, .NET®, Python, Perl) e permite certa flexibilidade em como implementar a solução. No caso da linguagem de programação Java, a biblioteca de ativação é um arquivo JAR.

Quando o Controlador detecta um valor de alerta para as estatísticas de um aplicativo monitorado, ele decide a ação consequente para manter a eficiência e a disponibilidade do sistema. A ação é executada ao chamar a interface das APIs REST do TSAM e enviar a solicitação de serviço para concluir a tarefa de fornecimento.

Utilizando o IBM Tivoli Monitoring

Conforme ilustrado na Figura 5, a solução conta com os agentes ITM para monitorar o status dos servidores de aplicativos.

Figura 5. Solução de Autoajuste para Balanceamento de Carga de Trabalho: Utilize Eventos do ITM
Solução de Autoajuste para Balanceamento de Carga de Trabalho: Utilize Eventos do ITM

Para esse propósito, você tem que instalar os agentes do ITM nos servidores de aplicativos e configurá-los apropriadamente, o que pode ser feito ao solicitar o Projeto do TSAM do aplicativo de negócios ou integrando o agente do ITM na imagem virtual usada para instanciar os servidores de aplicativos. Os dados estatísticos são transferidos por upload para o servidor ITM e encaminhadas para OMNIbus para processamento de eventos.

Uma vez que o evento alcançar o OMNIbus, é possível chamar a API REST do TSAM usando um procedimento de saída customizado; é até possível utilizar a integração do gerente de solicitação de serviço do OMNIbus para enviar as solicitações de fornecimento.

Agora, vamos observar o outro tópico principal: como adaptar regras de firewall quando é necessário modificar configurações de segurança para um determinado aplicativo corporativo.


Adaptando Regras de Firewall de Rede

A Extensão do TSAM para Firewall Juniper SRX configura automaticamente as regras de firewall quando implementa um aplicativo de negócios baseado em regras padrão que foram definidas ao configurar modelos de rede durante a configuração das Extensões do TSAM. Você não deveria ter que lidar com regras de firewall novamente.

Obviamente, quão realista esse cenário é? Sempre há situações em que é necessário modificar as configurações de segurança para um determinado projeto de aplicativo de negócios. Então você quer poder ver as configurações atuais, certo?

A Extensão do TSAM para Firewall Juniper SRX fornece uma oferta de serviços, Modificar Política de Firewall, que é semelhante à política do balanceador de carga. A política de firewall é um artefato interno definido pela extensão que compõe as regras de firewall que se aplicam a um projeto dos servidores virtuais do TSAM ou mais precisamente ainda, à sub-rede/VLAN do projeto. Cada projeto possui sua própria política de firewall que você pode alterar incluindo, modificando ou removendo regras de firewall individuais, como mostrado na Figura 6.

Figura 6. As Políticas de Firewall Configuradas para o Projeto de Aplicativo de Negócios
As Políticas de Firewall Configuradas para o Projeto de Aplicativo de Negócios

Uma regra de firewall permite o tráfego de protocolo específico iniciado de uma sub-rede de origem para uma sub-rede de destino. Origem e destino (Figura 6) geralmente são sub-redes inteiras especificadas usando a notação CIDR (endereço de sub-rede/número de bits do endereço IP que identifica a sub-rede). Entretanto, endereços IP únicos podem ser especificados como origem e destino de uma regra de firewall em casos em que se que permitir tráfego para um host específico.

Talvez observe que não é possível especificar uma regra para negar tráfego. Bem, um dos pontos principais da extensão é a sua capacidade de:

  • Simplificar a tarefa do solicitante de um aplicativo de negócios e
  • Reduzir os riscos de segurança o quanto for possível.

Como uma consequência disso, a política de firewall sempre contém uma regra oculta que não pode ser alterada: recuse todo o tráfego. Assim, seus administradores podem apenas permitir tráfego como exceções à regra recusar todos. Esta é uma implementação simples e menos arriscada deste recurso.

Para simplificar a tarefa do administrador ainda mais, há três tipos de regras de firewall:

  • Da regra de Internet: permite tráfego de protocolo específico iniciado do DMZ para a sub-rede/VLAN do projeto. É possível usar a notação 0.0.0.0/0 para indicar qualquer endereço; da regra De Internet a partir de 0.0.0.0/0 a 192.168.0.0/16 então significa que qualquer endereço IP no DMZ pode iniciar uma conexão na sub-rede 192.168.0.0/16.
  • Regra Para Internet: permite tráfego de protocolo específico iniciado a partir de um dos servidores de aplicativo do projeto para o DMZ.
  • Regra De Outro(s) Projeto(s): possibilita abrir um projeto para comunicar com outros projetos, como um projeto que hospeda serviços compartilhados. Você configura a regra De Outro(s) Projeto(s) de 0.0.0.0/0 a 192.170.0.0/16 no projeto de serviços compartilhados, significando que qualquer outro projeto possa iniciar uma conexão e, portanto, possa usar serviços compartilhados. Você conclui a configuração definindo a regra: a regra De Outro(s) Projeto(s) de 192.168.0.0/16 a 192.170.0.0/16 em um projeto que precisa acessar serviços compartilhados (cuja sub-rede é 192.168.0.0/0).

Conclusão

Neste artigo, explicamos como lidar com alguns aspectos do gerenciamento de ciclo de vida de um aplicativo de negócios J2EE implementado na nuvem com a ajuda das Extensões do TSAM para Firewall Juniper SRX e BIG-IP F5 Load Balancer. Explicamos particularmente como ajustar de modo adequado o balanceador de carga para lidar com a carga de trabalho de seu aplicativo de negócios, como responder às variações da utilização de seu aplicativo de negócios incluindo e removendo servidores de aplicativos, e por fim, como usar efetivamente o firewall para bloquear o acesso aos seus servidores.

O fornecimento inicial do aplicativo de negócios está descrito no artigo que o acompanha. Neste artigo, é possível saber mais sobre a criação de um Projeto do TSAM de servidores virtuais que ficam por trás de um balanceador de carga BIG-IP F5 e está confinado em uma VLAN/sub-rede gerenciada pelo firewall Juniper SRX.

Recursos

Aprender

Obter produtos e tecnologias

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que acessar o developerWorks, um perfil será criado para você. Informações do seu perfil (tais como: nome, país / região, e empresa) estarão disponíveis ao público, que poderá acompanhar qualquer conteúdo que você publicar. Seu perfil no developerWorks pode ser atualizado a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Cloud computing, Tivoli, Tecnologia Java
ArticleID=807313
ArticleTitle=Gerencie um Aplicativo J2EE com Extensões TSAM
publish-date=03302012