2.1 Topologia
A quantidade de instâncias de cada subsistema principal e as maneiras como eles podem ser conectados são bastante numerosas. Contudo, nem todos os layouts possíveis têm suporte. É importante compreender não apenas as possibilidades, mas também as razões pelas quais algumas configurações prevalecem sobre outras.
2.1.1 Design mínimo
A configuração lógica mais simples do aplicativo de usuário é a instalação que tem um pouco de tudo e consiste em uma árvore do cofre de identidade, uma instância dos drivers e do mecanismo do Identity Manager e uma instância do JBoss que executa uma instância única do aplicativo de usuário. Em termos de implementação física, teoricamente, você pode executar todos esses componentes em uma configuração. Contudo, há vários motivos (segurança, manutenção e desempenho são os principais) para que você não o faça. Ao escolher o número de computadores necessários para uma instalação real e prática, convém considerar pelo menos o seguinte:
- Servidor Novell Audit: esse item é responsável pela captura de informações de evento (e, possivelmente, muitos outros tipos de informações) do ambiente do aplicativo de usuário em tempo de execução. Ele também pode servir como armazenamento persistente para outros aplicativos da empresa. Por diversos motivos, provavelmente você incluirá outros itens importantes do sistema do Identity Manager (por exemplo, JBoss ou o cofre de identidade) na mesma máquina do servidor Audit.
- Cofre de identidade: esse é um componente de uso intenso e requer bom desempenho e boa escalabilidade. É bem provável que você considere instalar o cofre de identidade em uma máquina dedicada. Em outras palavras, não convém ter outro sistema de tráfego intenso, como o JBoss com uma distribuição do aplicativo de usuário, sendo executado em conjunto com o cofre de identidade na mesma máquina.
- Banco de dados: se essa instância do MySQL (ou outro banco de dados que tenha suporte) também for seu banco de dados do Novell Audit, ela provavelmente estará em uma máquina dedicada. Lembre-se de que esse item é usado pelo aplicativo de usuário das seguintes maneiras:
- Como armazenamento persistente de dados de configuração do portal
- Como o armazenamento persistente de informações sobre estado de workflows em andamento (se o Módulo de Aprovisionamento estiver instalado)
- Opcionalmente, como o armazenamento de registro do Novell Audit.
- JBoss: por questões de desempenho e capacidade, é recomendável executar esse item em uma máquina dedicada.
Essas considerações sugerem a seguinte configuração mínima com três computadores:
2.1.2 Design de alta disponibilidade
O uso de clusters para alta disponibilidade/capacidade será discutido detalhadamente em uma seção posterior deste capítulo. No momento, é importante saber que:
- O Identity Manager permite alta disponibilidade do cofre de identidade, mecanismo e drivers por meio de uma instalação de vários nós e mecanismos de armazenamento compartilhado, descritos no capítulo sobre “Alta disponibilidade” do principal Guia de Administração do Identity Manager. Há instruções detalhadas sobre a configuração de um sistema desse tipo usando o SUSE Linux no artigo em:
http://support.novell.com/cgi-bin/search/searchtid.cgi?/10093317.htm
- A alta disponibilidade do aplicativo de usuário pode ser obtida por meio dos clusters do JBoss. Você pode configurar um cluster do JBoss de forma que cada nó execute uma instância do aplicativo de usuário. As instâncias estarão no mesmo nível (sem hierarquia). No entanto, não haverá replicação de sessões entre as instâncias. Cada instância será responsável por sua própria unidade de trabalho e não encerrará sessões iniciadas em um nó irmão.
- Pelos motivos já expostos, não há suporte para failover automático. Contudo, um workflow interrompido poderá prosseguir após a perda de um nó do cluster, caso seja colocado online um novo nó com o mesmo ID de mecanismo de workflow. (Nesse caso, o workflow continuará automaticamente assim que o novo mecanismo de workflow for iniciado.)
Consulte a Seção 2.4, Clusters (mais adiante) para obter informações mais detalhadas sobre essas questões.
2.1.3 Limitações de design
Em geral, as duas limitações de arquitetura mais importantes que você deve ter em mente são:
- Nenhuma instância de aplicativo de usuário pode atender (pesquisar/consultar, adicionar usuários e assim por diante) a mais de um container de usuário. Além disso, após a associação de um container de usuário ao aplicativo, essa associação é tida como permanente.
- Nenhum Driver de Aplicativo do Usuário pode ser associado a mais de um aplicativo de usuário, exceto quando os aplicativos de usuário estão instalados em nós irmãos no mesmo cluster do JBoss. Em outras palavras, não há suporte ao mapeamento de um driver para muitos aplicativos de usuário.
O primeiro container assegura o uso obrigatório de um alto grau de encapsulação no projeto de aplicativo de usuário.
Suponha que você tenha a seguinte estrutura organizacional:
Durante a instalação do aplicativo de usuário, você é solicitado a especificar o container de usuário de nível superior que sua instalação deverá pesquisar no cofre de identidade. Nesse caso, você poderia especificar ou=Marketing,o=ACME ou (como alternativa) ou=Finance,o=ACME. Você não poderá especificar ambos. Todas as pesquisas e consultas de aplicativo de usuário (e logins de administrador) terão como escopo o container que você especificou.
NOTA:Teoricamente, você poderia especificar o escopo o=ACME a fim de englobar Marketing e Finance. Contudo, em organizações grandes com possivelmente muitos containers ou (em vez de apenas dois associados a Marketing e Finanças), isso não seria conveniente.
Obviamente, é possível criar duas instalações independentes do aplicativo de usuário (sem recursos em comum), uma para Marketing e outra para Finanças. Cada instalação teria seu próprio banco de dados, bem como seu próprio Driver de Aplicativo do Usuário corretamente configurado, e cada aplicativo de usuário seria administrado separadamente e, se possível, teria um tema exclusivo.
Caso seja absolutamente necessária a instalação dos containers Marketing e Finance no mesmo escopo em uma instalação do aplicativo de usuário, há duas possíveis estratégias a serem consideradas. Uma delas é inserir um novo objeto container (por exemplo, ou=MarketingAndFinance) na hierarquia, acima dos dois nós irmãos e, em seguida, apontar para o novo container como a raiz do escopo. A outra estratégia é criar uma réplica filtrada (um tipo especial de árvore do eDirectory) que combine as partes necessárias da árvore ACME, e apontar o aplicativo de usuário em direção ao container raiz da réplica. (Consulte o eDirectory Administration Guide (Guia de Administração do eDirectory) para obter mais informações sobre réplicas filtradas.)
Se tiver dúvidas sobre um layout de sistema em particular, entre em contato com seu representante da Novell para obter assistência ou orientação.