Um cluster grande do IBM® WebSphere Application Server
é composto de servidores HTTP de front-end e de servidores proxy com um balanceador
de carga que direciona pedidos em torno do cluster.
Restrição: Para criar e usar um cluster de servidores de aplicativos, você deve ter o
IBM WebSphere Application Server Network
Deployment (ND), que não está incluso em pacote configurável com o
IBM Rational Asset Manager.
É possível escalonar o WebSphere Application Server tanto
vertical quanto horizontalmente. Use um servidor de banco de dados e um servidor de arquivos
dedicado. O grau de escalabilidade do WebSphere Application Server
e o número de servidores que podem ser usados depende do
tipo e da magnitude de pedidos do servidor e do número de ativos.
- IBM HTTP Server
- A primeira camada é o servidor HTTP, que manipula solicitações de Web clients
e desobriga o servidor de aplicativos de atender o conteúdo estático. Ele fornece uma URL lógica que abrange
aplicativos auxiliares, como o aplicativo IBM Rational Asset Manager,
o aplicativo Help do Rational Asset Manager
e o aplicativo Asset Based Development do
Rational Asset Manager. Observe que, em uma configuração grande,
um servidor de cache é implementado na frente do servidor HTTP.
- Balanceador de Carga
- Um balanceador de carga distribui carga entre
vários sistemas. Se você tiver mais de um servidor HTTP, deverá
usar um balanceador de carga.
Para implementações moderadas, use um balanceador de carga
baseado em software, como o Edge Component. Para implementações maiores, que
suportam um grande número de usuários simultâneos, use um balanceador de carga baseado em
hardware.
- Proxy do Cache
- Um sistema proxy de armazenamento em cache de
encaminhamento armazena dados do
aplicativo de clientes em um cache e diminui a carga de outros sistemas servidores. Se o servidor Rational Asset Manager
suportar um número moderado de usuários simultâneos, você precisará de apenas um
sistema proxy de encaminhamento. Se o servidor Rational Asset Manager
suportar um número grande de usuários simultâneos, talvez sejam necessários vários
sistemas proxy.
- Application Server
- O arquivo EAR do Rational Asset Manager
é composto de dois arquivos WAR: o arquivo de repositório e do aplicativo da
Web e o arquivo de serviços da Web. Implemente o arquivo EAR do Rational Asset Manager
em cada instância do WebSphere Application Server
em um cluster. O Rational Asset Manager também
inclui arquivos WAR da Ajuda e do IBM Rational Unified Process (RUP); não é necessário
implementar esses arquivos WAR. Se a alta disponibilidade não for necessária para
as funções de suporte da Ajuda e do RUP,
implemente-as em uma única instância do WebSphere Application Server
ou em um contêiner externo do WebSphere Application Server.
- Aplicativo do Rational Asset Manager
- O repositório do Rational Asset Manager
é normalizado para procuras e recuperação de dados para que os dados sejam armazenados
para serem projetados para tornar a procura de dados, a navegação pelos
artefatos e os ativos de download mais eficientes. Para isso, cada instância do servidor Rational Asset Manager
constrói um índice local para ativos e um índice local para artefatos.
Isso otimiza o desempenho da procura, diminui a carga do banco de dados e aprimora a
escalabilidade em um ambiente em cluster. A execução dos diretórios de índice
local pode ser melhor que a de um índice compartilhado entre os nós.
- Servidor de
banco de dados
- As considerações mais importantes na
escolha do hardware do banco de dados são o número de discos na máquina
e o esquema RAID usado pela máquina. Uma matriz RAID deve conter
pelo menos de 6 a 10 unidades para cada processador. Embora a memória seja importante,
não há diferença significativa entre as configurações de servidor de banco de dados
com 4 GB e 8 GB de memória para 1.000 usuários e 50.000 ativos.
- Os requisitos
de espaço em disco do banco de dados dependem de vários fatores: o número de ativos,
o número de artefatos para cada ativo, o número de espaços da equipe,
o número de funções, o número de revisões, o número de tipos de ativos,
o número de usuários, a quantidade de transações no servidor (métricas do
usuário) e a quantidade de discussões do fórum.
- Servidor de arquivos
- Os ativos devem ser compartilhados nas instâncias do WebSphere Application Server.
Use um sistema de arquivos acessado simultaneamente. O Rational Asset Manager acessa
esses arquivos apenas durante uploads, downloads, indexação de artefato e
mudanças significativas no modelo do Rational Asset Manager
que requeiram uma atualização no manifesto do ativo.
Topologias em
Cluster
Armazenar em cluster é combinar
um grupo de máquinas em uma entidade lógica que possa ser referenciada como
se fosse uma máquina. Esta seção descreve várias configurações de cluster
e as principais vantagens e desvantagens de cada uma.
- Armazenamento em cluster horizontal
- Armazenamento em cluster horizontal, referido,
às vezes, como adição de escalabilidade, é a inclusão de máquinas físicas para aumentar
o desempenho ou a capacidade de um conjunto de clusters. Geralmente a
escalabilidade horizontal aumenta a disponibilidade do aplicativo em cluster às
custas de maior manutenção.
O armazenamento em cluster horizontal pode incluir capacidade
e maior rendimento em um aplicativo em cluster; use esse tipo
de armazenamento em cluster na maioria das instâncias.
- Armazenamento em cluster vertical
- Armazenamento em
cluster vertical, referido, às vezes,
como aumento de escalabilidade, é a inclusão de instâncias do WebSphere Application Server
na mesma máquina. A escalabilidade vertical é útil para aproveitar
recursos não usados em grandes servidores SMP. O armazenamento em cluster vertical pode ser usado
para criar vários processos da JVM que, juntos, podem usar toda a energia de
processamento disponível.
- Armazenamento em cluster horizontal e vertical híbrido
- O armazenamento em cluster híbrido
é uma combinação de armazenamento em cluster horizontal e vertical. Nesta configuração,
diferentes configurações de hardware são membros do mesmo cluster. Máquinas maiores e mais capazes podem conter várias instâncias do WebSphere Application Server;
máquinas menores podem ter um armazenamento em cluster horizontal e conter apenas
uma instância do WebSphere Application Server.
- Ao
usar o armazenamento em cluster vertical, tome cuidado. A única maneira de determinar
o que é correto para seu ambiente e aplicativo é ajustar uma
única instância de um servidor de aplicativos para obter o rendimento e o desempenho e,
em seguida, incluí-la em um cluster e adicionar, aos poucos, membros do
cluster. Teste o desempenho e o rendimento conforme for incluindo cada membro
no cluster. Ao configurar uma topologia de escalabilidade vertical, sempre
monitore o uso de memória cuidadosamente; não exceda a quantidade de espaço endereçável
do usuário ou a quantidade de memória física disponível em uma máquina.
Escalabilidade
Escalabilidade
é a facilidade de expansão
de um site. O número de usuários, ativos e comunidades de
uma determinada instalação do Rational Asset Manager
deve ser capaz de expandir-se para suportar uma carga maior. O aumento na
carga pode ter várias origens, como a inclusão de equipes ou departamentos
adicionais no conjunto de usuários do Rational Asset Manager
ou a importação de conjuntos grandes de ativos históricos para o Rational Asset Manager.
Escalabilidade
é uma consideração arquitetural que conduz o design de sua arquitetura.
Embora seja possível melhorar a escalabilidade incluindo hardware adicional
no sistema, ele pode não melhorar o desempenho e o rendimento.
A
opção entre aumento de escalabilidade (armazenamento em cluster vertical) e adição de escalabilidade (armazenamento
em cluster horizontal) é geralmente uma decisão de preferência, custo e de acordo com a natureza
de seu ambiente. No entanto, problemas de resiliência do aplicativo podem mudar
suas preferências.
- O aumento de escalabilidade implementa a escalabilidade vertical em um pequeno número de máquinas
com vários processadores e grandes quantidades de memória de espaço endereçável do usuário.
Isso pode apresentar pontos únicos de falha (SPOF) significativos porque
seu ambiente é composto por uma quantidade menor de máquinas grandes.
- A adição de escalabilidade usa um número maior de máquinas menores. Neste
cenário, é improvável que a falha de um servidor pequeno possa
criar uma interrupção completa do aplicativo. No entanto, a adição de escalabilidade cria
maiores necessidades de manutenção.
Disponibilidade
Também
referida como tolerância a falhas
ou resiliência, disponibilidade é a capacidade de um sistema de fornecer
continuidade operacional apesar de componentes e sistemas falhos.
Decisões arquiteturais, como escalabilidade horizontal versus vertical
e o uso de balanceadores de carga de backup (isto é, dispatchers), podem afetar
a disponibilidade do aplicativo Rational Asset Manager.
Considere a disponibilidade de todos os recursos, redes e sistemas de armazenamento
em disco compartilhados que compõem o ambiente do Rational Asset Manager.
Em um design tolerante a falhas, se um aplicativo ou servidor falhar, outros
membros do cluster podem continuar a atender os clientes.
Há
duas categorias de failover: failover do servidor e failover de sessão.
Quando ocorre failover do servidor, as sessões no membro de cluster falho
são perdidas (um usuário terá que efetuar login novamente), mas os serviços continuam
disponíveis aos clientes. No failover de sessão, as sessões existentes
continuam com os outros membros do cluster como se o membro de cluster
não tivesse falhado (embora a última transação possa ter sido perdida).
Se uma infraestrutura redundante for configurada para suportar failover do servidor, o Rational Asset Manager
a suportará.