Com o roteamento para zonas preferenciais, é possível definir como o WebSphere eXtreme Scale direciona as transações para zonas.
Você tem controle sobre onde os shards em uma grade de dados são colocados. Consulte Configurando Zonas para a Colocação de Réplica para obter mais informações sobre alguns cenários básicos e como configurar sua política de implementação de acordo.
O roteamento preferencial fornece ao clientes do WebSphere eXtreme Scale a capacidade de especificar uma preferência para uma determinada zona ou conjunto de zonas. Como resultado, as transações do cliente são roteadas para zonas preferenciais antes de tentar rotear para qualquer outra zona.
Antes de tentar o roteamento preferencial por zona, certifique-se de que o aplicativo possa atender aos requisitos de seu cenário.
O posicionamento de partição por contêiner é necessário para usar roteamento preferencial por zona. Esta estratégia de posicionamento é uma boa opção para aplicativos que são dados de sessão de armazenamento no ObjectGrid. A estratégia de posicionamento de partição padrão para o WebSphere eXtreme Scale é partição fixa. As chaves são colocadas em hash no momento de consolidação de transação para determinar qual partição hospeda o par chave-valor do mapa ao usar o posicionamento de partição fixa.
O posicionamento por contêiner designa seus dados a uma partição aleatória quando a transação confirma o tempo por meio do objeto SessionHandle. Você deve poder reconstruir o objeto SessionHandle para recuperar seus dados a partir da grade de dados.
É possível usar zonas para ter mais controle sobre onde os shards primário e os shards de réplica são colocados em seu domínio. Usar diversas zonas em sua implementação é vantajoso quando seus dados estiverem em diversos locais físicos. Separar geograficamente os primários e réplicas é uma forma de assegurar que a perda catastrófica de um datacenter não afete a disponibilidade dos dados.
Quando os dados são espalhados em diversas zonas, é mais provável que os clientes também se espalhem pela topologia. O roteamento de clientes para sua zona ou datacenter local possui o benefício de desempenho óbvio de reduzir a latência de rede. Roteie os clientes para zonas ou datacenters locais quando possível.
Considere o seguinte cenário. Você tem dois datacenters: Chicago e Londres. Para minimizar o tempo de resposta dos clientes, você deseja que os clientes leiam e gravem dados em seu datacenter local.
Os shards primários devem ser colocados em cada datacenter para que as transações possam ser gravadas localmente a partir de cada local. Os clientes também deve reconheceras zonas para rotear para a zona local.
O posicionamento por contêiner localiza os novos shards primários em cada contêiner que é iniciado. As réplicas são posicionadas de acordo com as regras da zona e de posicionamento que são especificadas pela política de implementação. Por padrão, uma réplica é colocada em uma zona diferente de seu shard primário. Considere a política de implementação a seguir para este cenário.
<?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="universe">
<mapSet name="mapSet1" placementStrategy="PER_CONTAINER"
numberOfPartitions="3" maxAsyncReplicas="1">
<map ref="planet" />
</mapSet>
</objectgridDeployment>
</deploymentPolicy>
Cada contêiner que inicia com uma política de implementação recebe três novos primários. Cada primário possui uma réplica assíncrona. Inicie cada contêiner com o nome de zona adequado. Use o parâmetro -zone se estiver ativando seus contêineres com o script startOgServer.
Para um servidor de contêineres Chicago:
startOgServer.sh s1 -objectGridFile ../xml/universeGrid.xml
-deploymentPolicyFile ../xml/universeDp.xml
-catalogServiceEndPoints MyServer1.company.com:2809
-zone Chicago
startOgServer.bat s1 -objectGridFile ../xml/universeGrid.xml
-deploymentPolicyFile ../xml/universeDp.xml
-catalogServiceEndPoints MyServer1.company.com:2809
-zone Chicago
Se seus contêineres estiverem em execução no WebSphere Application Server, você deverá criar um grupo de nós e nomeá-lo com o prefixo ReplicationZone. Os servidores que estiverem em execução nos nós nestes grupos de nós são colocados na zona adequada. Por exemplo, os servidores em execução em um nó Chicago podem estar em um grupo de nós denominado ReplicationZoneChicago.
Consulte o Configurando Zonas para a Colocação de Réplica para obter informações adicionais.
Os shards primários para a zona Chicago possuem réplicas na zona London. Os shards primários para a zona London possuem réplicas na zona Chicago.
Configure as zonas preferenciais para os clientes. Forneça um arquivo de propriedades do cliente na Java virtual machine (JVM) do cliente. Crie um arquivo denominado objectGridClient.properties e assegure-se de que esse arquivo esteja em seu caminho de classe.
Inclua a propriedade preferZones no arquivo. Consulte o valor da propriedade para a zona adequada. Os clientes em Chicago devem ter o seguinte valor no arquivo objectGridClient.properties:
preferZones=Chicago
O arquivo de propriedades para clientes London devem conter o seguinte valor:
preferZones=Londres
Esta propriedade instrui cada cliente para rotear transações à sua zona local se possível. A topologia replica assincronamente dados que são inseridos em um shard primário da zona local na zona estrangeira.
A estratégia de posicionamento por contêiner não usa um algoritmo baseado em hash para determinar o local de seus pares de valores de chave na grade de dados. Você deve usar os objetos SessionHandle para assegurar que as transações sejam roteadas para o local correto quando usar esta estratégia de posicionamento. Quando uma transação é confirmada, um SessionHandle é limitado à sessão se uma ainda não tiver sido configurada. O objeto SessionHandle também pode ser limitado ao Session ao chamar o método Session.getSessionHandle antes de confirmar a transação. O fragmento de código a seguir mostra um SessionHandle sendo ligado antes de confirmar a transação.
Session ogSession = objectGrid.getSession();
// binding the SessionHandle
SessionHandle sessionHandle = ogSession.getSessionHandle();
ogSession.begin();
ObjectMap map = ogSession.getMap("planet");
map.insert("planet1", "mercury");
// tran is routed to partition specified by SessionHandle
ogSession.commit();
Suponha que o código anterior estava executando em um cliente em seu datacenter Chicago. O atributo preferZones é configurado para Chicago para este cliente. Como resultado, sua implementação rotearia as transações para uma das partições primárias na zona Chicago: partição 0, 1, 2, 6, 7 ou 8.
O objeto SessionHandle fornece um caminho de volta para a partição que está armazenando os dados confirmados. O objeto SessionHandle deve ser reutilizado ou reconstruído e configurado no Session para voltar para a partição que contém os dados confirmados.
ogSession.setSessionHandle(sessionHandle);
ogSession.begin();
// value returned will be "mercury "
String value = map.get("planet1");
ogSession.commit();
A transação neste código reutiliza o objeto SessionHandle que foi criado durante a transação insert. A transação get é então roteada para a partição que mantém os dados inseridos. Sem o objeto SessionHandle, a transação não pode recuperar os dados inseridos.
Geralmente, um cliente com a propriedade preferZones configurada roteia todas as transações para a zona ou zonas especificadas. No entanto, a perda de um contêiner resulta na promoção de um shard réplica para um shard primário. Um cliente que era roteado anteriormente para partições na zona local deve recuperar os dados inseridos anteriormente a partir da zona remota.
Considere o seguinte cenário. Um contêiner na zona Chicago foi perdido. Ele anteriormente continha primários para partições 0, 1 e 2. O novos shards primários para estas partições são então colocados na zona London porque a zona London hospeda as réplicas para estas partições.
Qualquer cliente Chicago que estiver usando um SessionHandle que aponta para uma das partições com falha agora é roteado novamente para Londres. Os clientes Chicago que usam os novos objetos SessionHandle são roteados para os primários baseados em Chicago.
Da mesma forma, se a zona Chicago inteira for perdida, todas as réplicas na zona London serão promovidas para primárias. Neste cenário, todos os clientes Chicago roteiam suas transações para London.