Utilize o arquivo XML do descritor de política de implementação e o arquivo XML do descritor de ObjectGrid para gerenciar sua topologia.
As informações de terminal não estão pré-configuradas no ambiente dinâmico. Não há nomes de servidor ou informações de topologia física localizadas na política de implementação. Todos os shards em uma grade de dados são posicionados automaticamente nos servidores de contêiner pelo serviço de catálogo. O serviço de catálogo usa as restrições que são definidas pela política de implementação para gerenciar automaticamente o posicionamento de shard. Esse posicionamento automático de shard facilita a configuração de grades de dados grandes. Também é possível incluir servidores no seu ambiente, conforme necessário.
Um arquivo XML de política de implementação é passado para o servidor de contêiner durante a inicialização. Uma política de implementação deve ser usada junto com o arquivo XML de ObjectGrid. A política de implementação não é necessária para iniciar um servidor de contêiner, mas é recomendada. A política de implementação deve ser compatível com o arquivo XML do ObjectGrid que é utilizado com ela. Para cada elemento objectgridDeployment na política de implementação, você deve incluir um elemento objectGrid correspondente no arquivo XML de ObjectGrid. Os mapas no objectgridDeployment devem ser consistentes com os elementos backingMap localizados no XML do ObjectGrid. Cada backingMap deve ser referenciado dentro somente de um elemento mapSet.
companyGridDpReplication.xml
<?xml version="1.0" encoding="UTF-8"?>
<deploymentPolicy xmlns:xsi="http://www.w3.org./2001/XMLSchema-instance"
xsi:schemaLocation="http://ibm.com/ws/objectgrid/deploymentPolicy ../deploymentPolicy.xsd"
xmlns="http://ibm.com/ws/objectgrid/deploymentPolicy">
<objectgridDeployment objectgridName="CompanyGrid">
<mapSet name="mapSet1" numberOfPartitions="11"
minSyncReplicas="1" maxSyncReplicas="1"
maxAsyncReplicas="0" numInitialContainers="4">
<map ref="Customer" />
<map ref="Item" />
<map ref="OrderLine" />
<map ref="Order" />
</mapSet>
</objectgridDeployment>
</deploymentPolicy>
companyGrid.xml
<?xml version="1.0" encoding="UTF-8"?>
<objectGridConfig xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://ibm.com/ws/objectgrid/config ../objectGrid.xsd"
xmlns="http://ibm.com/ws/objectgrid/config">
<objectGrids>
<objectGrid name="CompanyGrid">
<backingMap name="Customer"/>
<backingMap name="Item" />
<backingMap name="OrderLine" />
<backingMap name="Order"/>
</objectGrid>
</objectGrids>
</objectGridConfig>
O arquivo companyGridDpReplication.xml tem um elemento mapSet que é dividido em 11 partições. Cada partição deve ter exatamente uma réplica síncrona. O número de réplicas síncronas é especificado pelos atributos minSyncReplicas e maxSyncReplicas. Como o atributo minSyncReplicas é configurado como 1, cada partição no elemento mapSet deve ter pelo menos uma réplica síncrona disponível para processar transações de gravação. Como o atributo maxSyncReplicas é configurado para 1, cada partição não pode exceder uma réplica síncrona. As partições nesse elemento mapSet não têm réplicas assíncronas.
O atributo numInitialContainers instrui o serviço de catálogo a adiar o posicionamento até quatro servidores de contêiner estarem disponíveis para suportar esta instância do ObjectGrid. O atributo numInitialContainers é ignorado após o número especificado de servidores de contêiner ter sido atingido.
Também é possível usar a propriedade placementDeferralInterval e o comando xscmd -c suspendBalancing para atrasar o posicionamento de shards nos servidores de contêiner.
Embora o arquivo companyGridDpReplication.xml seja um exemplo básico, uma política de implementação pode oferecer um controle total sobre seu ambiente.
O WebSphere eXtreme Scale equilibra automaticamente os servidores. É possível incluir servidores adicionais sem reiniciar o WebSphere eXtreme Scale. Incluir servidores adicionais sem precisar reiniciar o eXtreme Scale permite executar implementações simples e implementações que atingem terabytes em que milhares de servidores são necessários.
Essa topologia de implementação é flexível. Utilizando o serviço de catálogo, é possível incluir e remover servidores para utilizar melhor os recursos sem remover o cache inteiro. É possível os comandos startOgServer e stopOgServer para iniciar e parar os servidores de contêiner. Esses dois comandos requerem especificar a opção -catalogServiceEndPoints. Todos os clientes de topologia distribuída se comunicam com o serviço de catálogo através do Internet Interoperability Object Protocol (IIOP). Todos os clientes utilizam a interface ObjectGrid para comunicar-se com servidores.
O recurso de configuração dinâmica do WebSphere eXtreme Scale facilita incluir recursos no sistema. Os contêineres hospedam os dados e o serviço de catálogo permite que os clientes se comuniquem com a grade de servidores de contêineres. O serviço de catálogo encaminha solicitações, aloca espaço nos servidores de contêiner do host e gerencia o funcionamento e a disponibilidade do sistema geral. Os clientes se conectam a um serviço de catálogo, recuperam uma descrição da topologia do servidor de contêiner e, então, comunicam-se diretamente com cada servidor conforme necessário. Quando a topologia do servidor muda devido à inclusão de novos servidores, ou devido à falha de outros, o serviço de catálogo roteia automaticamente os pedidos do cliente para o servidor apropriado que hospeda os dados.
Um serviço de catálogo normalmente existe na sua própria grade do Java Virtual Machines. Um único servidor de catálogos pode gerenciar vários servidores. É possível iniciar um servidor de contêiner sozinho em uma JVM ou carregar o servidor de contêiner em uma JVM arbitrária com outros servidores de contêiner para diferentes servidores. Pode existir um cliente em alguma JVM e comunicar-se com um ou mais servidores. Um cliente também pode existir na mesma JVM que um servidor de contêiner.
Também é possível criar uma política de implementação programaticamente quando você está integrando um servidor de contêiner em um processo ou aplicativo Java existente. Para obter mais informações, consulte a documentação da API DeploymentPolicy.