Este tópico descreve os diferentes ambientes do Compute Grid, fatores a serem considerados ao tomar decisões sobre eles, além de considerações que ajudarão a projetá-lo para melhor atender às suas necessidades.
Antes de construir seu ambiente do Compute Grid, considere cuidadosamente o que deseja construir para tomar a melhor decisão. Por exemplo, você pode construir um Compute Grid em uma célula existente do WebSphere ou construir uma nova célula do WebSphere para hospedar esse ambiente. Além disso, o ambiente do Compute Grid pode ser construído para executar tarefas em lote do WebSphere, tarefas de execução nativa, ou ambos. Também é possível decidir sobre qual banco de dados relacional utilizar, a segurança necessária e seus requisitos de disponibilidade. Se estiver planejando controlar a carga de trabalho do Compute Grid por meio de um planejador de carga de trabalho externo, como o TWS (Tivoli Workload Scheduler), deverá planejar a configuração do JMS e do WSGridNotification SPI. As seções a seguir descrevem todas essas considerações.
Não há motivo básico para se construir uma célula nova ou utilizar uma existente. A escolha dependerá de você desejar um novo ambiente isolado de qualquer ambiente existente do WebSphere, ou de você desejar incluir os recursos do Compute Grid em um ambiente existente do WebSphere. Se optar por incluir o Compute Grid em uma célula existente do WebSphere, observe que o WebSphere Extended Deployment Compute Grid V6.1 requer o WebSphere Application Server V6.1. Portanto, talvez seja necessário migrar uma célula existente para a V6.1 antes de incluir o Compute Grid. Consulte os Requisitos de Sistema Detalhados do WebSphere Extended Deployment para obter os requisitos de cada componente.
O Compute Grid só precisará ser instalado nesses nós do WebSphere onde você desejar ativar o planejador de tarefa ou a funcionalidade do contêiner de lote. Apenas esses nós deverão estar no nível do WebSphere V6.1.
As etapas de construção de um ambiente do Compute Grid em uma nova célula do WebSphere são quase as mesmas. As única diferença é que os nós do WebSphere que compõem a célula do WebSphere devem ser construídos primeiro. Faça isso instalando o WebSphere e criando os perfis necessários para criar a célula do WebSphere.
Executa aplicativos em lote transacionais gravados em Java e implementa um modelo de programação do WebSphere. Eles são compactados como arquivos EAR (Enterprise Archive) e implementados no contêiner de lote hospedado em um WebSphere Application Server ou cluster.
O modelo de programação de lote transacional fornece um mecanismo de ponto de verificação/reinício gerenciado por contêiner que permite que a tarefa de Compute Grid seja reiniciada a partir do último ponto de verificação se parada por uma interrupção planejada ou não planejada.
Executa aplicativos de cálculo intenso gravados em Java e implementa um modelo de programação do WebSphere. Eles são compactados como arquivos EAR (Enterprise Archive) e implementados no contêiner de lote hospedado em um WebSphere Application Server ou cluster.
O modelo de programação de cálculo intenso fornece um modelo de execução reduzido baseado na estrutura comum
Executa aplicativos de execução nativa que podem ser gravados em qualquer linguagem e modelo de programação suportado pelo nó de destino no qual esses aplicativos são implementados. A técnica de compactação e implementação desses aplicativos está fora do controle administrativo do WebSphere.
O modelo de execução nativa fornece uma maneira de executar e controlar programas preexistentes não-interativos como tarefas em lote.
Todos os ambientes do Compute Grid requerem a implementação do planejador de tarefa em um servidor ou cluster do Websphere. Um ambiente para hospedar tipos de tarefas de lote transacional ou de cálculo intenso requer a implementação do contêiner de lote em pelo menos um servidor ou cluster do Websphere. Os aplicativos de lote transacional e/ou de cálculo intenso são instalados no mesmo servidor ou cluster do Websphere. Para hospedar tipos de tarefas de execução nativa, faça-o nos nós do WebSphere na célula de destino por meio do agente do nó de cada nó. No entanto, se quiser fornecer nós adicionais nos quais executar tarefas de execução nativa e não precisar do WebSphere neles, deverá instalar e configurar o agente de middleware nesses nós de destino.
O planejador de tarefa e o contêiner de lote do Compute Grid requerem acesso a um banco de dados relacional. O banco de dados relacional utilizado é conectado pelo JDBC. O Compute Grid depende dos recursos de gerenciamento de conexão subjacentes do WebSphere Application Server para obter acesso. Os bancos de dados relacionais suportados são os mesmos suportados pelo WebSphere Application Server, incluindo o DB2, o Oracle e outros.
Por padrão, o Compute Grid configura automaticamente um banco de dados Derby simples baseado em arquivo para ajudá-lo a obter, rapidamente, um ambiente funcional do Compute Grid totalmente operacional. No entanto, o banco de dados Derby não é recomendado para uso na produção. Além disso, o banco de dados Derby padrão não suporta um planejador de tarefa em cluster, nem um contêiner de lote em cluster.
Um ambiente altamente disponível do Compute Grid inclui um planejador de tarefa em cluster, assim como um ou mais contêineres de lote em cluster. O armazenamento em cluster requer um banco de dados em rede. Os bancos de dados da grade de produção, como o DB2 e outros, são recomendados com esta finalidade. O Network Derby ou o Cloudscape também funcionam, mas não apresentam a robustez necessária para fins de produção, não sendo recomendáveis.
Limitação: Todos os contêineres de lote na mesma célula devem utilizar o mesmo tipo de banco de dados relacional.
As funções do Compute Grid são designadas por meio da página de configuração do planejador de tarefa no console administrativo do WebSphere.
Utilize o armazenamento em cluster para alta disponibilidade de componentes do Compute Grid. Tanto o planejador de tarefa quanto o contêiner de lote devem ser implementados e operados em clusters para fornecer alta disponibilidade.
As técnicas comuns de armazenamento em cluster de aplicativos devem ser utilizadas com o planejador de tarefa para garantir que é altamente disponível. O planejador de tarefa suporta vários métodos de acesso a suas APIs: aplicativo da Web, linha de comandos, serviço da Web e EJB (Enterprise JavaBean). Garantir acesso altamente disponível à rede para um planejador de tarefa em cluster depende do método de acesso da API do planejador de tarefa. Essas opções incluem o uso de plug-ins do WebSphere ou do roteador on demand do recurso WebSphere Extended Deployment Operations Optimization. O contêiner de lote torna-se altamente disponível simplesmente por sua implementação em um cluster. O planejador de tarefa reconhece automaticamente que o contêiner de lote está armazenado em cluster e utiliza isso para garantir um ambiente de execução altamente disponível para as tarefas em lote executadas lá.