Colocação e Partições

Há duas estratégias de posicionamento disponíveis para WebSphere eXtreme Scale: partição fixa e por contêiner. A escolha da estratégia de posicionamento afeta a forma como sua configuração de implementação coloca as partições na grade de dados remota.

Colocação de Partições Fixas

É possível configurar a estratégia de colocação no arquivo XML de política de implementação. A estratégia de disposição padrão é uma colocação de partição fixa, ativada pela configuração FIXED_PARTITION. O número de shards primários que são colocados entre os contêineres disponíveis é igual ao número de partições configurado com o atributo numberOfPartitions. Se você tiver configurado réplicas, o número mínimo total de shards é definido pela seguinte fórmula:((1 shard primário + mínimo de shards síncrono) * partições definidas). O número máximo total de shards colocados é definido pela seguinte fórmula: ((1 shard primário + mínimo de shards síncrono + máximo de shards assíncronos) * partições). A implementação do WebSphere eXtreme Scale propaga esses shards para os contêineres disponíveis. As chaves de cada mapa são submetidas a hash nas partições designadas com base no total de partições definido. Eles efetuam hash da chave para a mesma partição, mesmo se a partição mover devido ao failover ou alterações do servidor.

Por exemplo, se o valor de numberPartitions for 6 e o valor minSync for 1 para MapSet1, o total de shards para esse conjunto de mapas será 12 porque cada uma das 6 partições requer uma réplica síncrona. Se três contêineres forem iniciados, o WebSphere eXtreme Scale colocará quatro shards por contêiner para o MapSet1.

Colocação por Contêiner

A estratégia de posicionamento alternativa é um posicionamento por contêiner, que é ativado com a configuração PER_CONTAINER para o atributo placementStrategy no elemento de conjunto de mapas no arquivo XML de implementação. Com essa estratégia, o número de shards primários colocados em cada novo contêiner é igual ao número de partições P configuradas. O ambiente de implementaçãoWebSphere eXtreme Scale colocaP réplicas de cada partição para cada contêiner restante. A configuração numInitialContainers é ignorada quando estiver usando uma colocação por contêiner. As partições ficam maiores conforme os contêineres crescem. As chaves para os mapas não são fixas em uma determinada partição nessa estratégia. O cliente é roteado para uma partição e usa um primário aleatório. Se um cliente desejar se reconectar à mesma sessão usada para localizar uma chave mais uma vez, um manipulador de sessão deverá ser usado.

Para obter mais informações, consulte SessionHandle para Roteamento.

Para servidores com failover ou interrompidos, o ambiente WebSphere eXtreme Scale mudará os shards primários na estratégia de colocação por contêiner se ainda contiverem dados. Se os shards estiverem vazios, eles serão descartados. Na estratégia por contêiner, os shards primários antigos não são mantidos porque os novos shards primários são colocados em cada contêiner.

O WebSphere eXtreme Scale permite posicionamento por contêiner como uma alternativa para o que puder ser chamado de estratégia de posicionamento "típica", uma abordagem de partição fixa com a chave de um Mapa com hash para uma dessas partições. No caso por contêiner (que é configurado com PER_CONTAINER), sua implementação coloca as partições no conjunto de servidores de contêiner on-line e, automaticamente, efetua scale out ou scale in deles conforme os contêineres são incluídos ou removidos da grade de dados do servidor. Uma grade de dados com a abordagem de partição fixa funciona bem para grades baseadas em chave, na qual o aplicativo usa um objeto chave para localizar dados na grade. A seguir está uma discussão sobre a alternativa.

Exemplo de uma Grade de Dados por Contêiner

As grades de dados PER_CONTAINER são diferentes. Você especifica que a grade de dados usa a estratégia de posicionamento PER_CONTAINER com o atributo placementStrategy em seu arquivo XML de implementação. Em vez de configurar o número total de partições que você deseja na grade de dados, especifique quantas partições deseja por contêiner que for iniciado.

Por exemplo, se configurar cinco partições por contêiner, cinco novas partições anônimas primárias serão criadas quando iniciar esse servidor de contêiner e as réplicas necessárias serão criadas nos outros servidores de contêiner implementados.

A seguir há uma possível sequência em um ambiente por contêiner conforme a grade de dados cresce.

  1. Iniciar contêiner C0 hospedando 5 primárias (P0 - P4).
    • C0 hospeda: P0, P1, P2, P3, P4.
  2. Iniciar contêiner C1 hospedando mais 5 primárias (P5 - P9). As réplicas são balanceadas nos contêineres.
    • C0 hospeda: P0, P1, P2, P3, P4, R5, R6, R7, R8, R9.
    • C1 hospeda: P5, P6, P7, P8, P9, R0, R1, R2, R3, R4.
  3. Iniciar contêiner C2 hospedando mais 5 primárias (P10 - P14). As réplicas são mais balanceadas.
    • C0 hospeda: P0, P1, P2, P3, P4, R7, R8, R9, R10, R11, R12.
    • C1 hospeda: P5, P6, P7, P8, P9, R2, R3, R4, R13, R14.
    • C2 hospeda: P10, P11, P12, P13, P14, R5, R6, R0, R1.

O padrão continua conforme mais contêineres são iniciados, criando cinco novas partições primárias toda vez e reequilibrando as réplicas nos contêineres disponíveis na grade de dados.

Nota: O WebSphere eXtreme Scale não move os shards primários quando usa a estratégia PER_CONTAINER, ele move apenas réplicas.

Lembre-se de que os números de partições são arbitrários e não têm nada a ver com chaves, portanto, não é possível utilizar roteamento baseado em chave. Se um contêiner parar, os IDs de partição criados para esse contêiner não serão mais utilizados, portanto, haverá um intervalo nos IDs de partição. No exemplo, não haveria mais as partições P5 - P9 se o contêiner C2 falhasse, deixando apenas P0 - P4 e P10 - P14, por isso o hash baseado em chave é impossível.

Usar números como cinco, ou mais provavelmente dez, para a quantia de partições por contêiner funcionará melhor se as consequências de uma falha do contêiner forem consideradas. Para propagar uniformemente o carregamento de shards hosting em toda a grade de dados, mais do que apenas uma partição será necessária para cada contêiner. Se você tivesse uma única partição por contêiner, quando um contêiner falhasse, apenas um contêiner (aquele hospedando o shard de réplica correspondente) deveria suportar o carregamento total da primária perdida. Nesse caso, o carregamento é duplicado imediatamente para o contêiner. No entanto, se tiver cinco partições por contêiner, então cinco contêineres selecionarão o carregamento do contêiner perdido, diminuindo o impacto em oitenta por cento em cada um. O uso de várias partições por contêiner geralmente diminui o possível impacto em cada contêiner substancialmente. Mais diretamente, considere o caso em que um contêiner para inesperadamente - o carregamento da replicação desse contêiner é espalhado sobre os 5 contêineres em vez de apenas um.

Utilizando a Política por Contêiner

Vários cenários tornam a estratégia por contêiner uma configuração ideal, como com a replicação da sessão HTTP ou o estado da sessão de aplicativo. Nesse caso, um roteador HTTP designa uma sessão a um contêiner do servlet. O contêiner do servlet precisa criar uma sessão HTTP e escolher uma das 5 partições locais primárias para a sessão. O "ID" da partição escolhida é armazenado em um cookie. O contêiner do servlet agora tem acesso local ao estado da sessão que significa acesso de latência zero aos dados para esse pedido, contanto que você mantenha a afinidade da sessão. E o eXtreme Scale replica quaisquer mudanças para a partição.

Na prática, lembre-se da repercussão do caso no qual você tem várias partições por contêiner (por exemplo, 5 novamente). Certamente, com cada novo contêiner iniciado, você tem mais 5 partições primárias e mais 5 réplicas. Com o tempo, mais partições devem ser criadas, e elas não devem ser movidas ou destruídas. Mas não é assim que os contêineres se comportam de fato. Quando um contêiner é iniciado, ele hospeda 5 shards primários, que podem ser chamados de primários "iniciais", existentes nos respectivos contêineres que os criaram. Se o contêiner falhar, as réplicas se tornarão primárias e o eXtreme Scale criará mais 5 réplicas para manter a alta disponibilidade (a menos que você desative o reparo automático). Os novos primários estão em um contêiner diferente daquele que os criou, que podem ser chamados de primários "estrangeiros". O aplicativo nunca deve colocar novos estados ou sessões em um primário estrangeiro. Eventualmente, o primário estrangeiro não tem entradas, e o eXtreme Scale o exclui automaticamente, junto com suas réplicas associadas. O propósito dos primários estrangeiros é permitir que sessões existentes continuem disponíveis (mas não as novas sessões).

Um cliente ainda pode interagir com uma grade de dados que não depender de chaves. O cliente apenas inicia uma transação e armazena dados na grade de dados independentes de quaisquer chaves. Ele solicita a Session um objeto SessionHandle, um identificador serializável que permite que o cliente interaja com a mesma partição quando necessário. O WebSphere eXtreme Scale escolhe uma partição para o cliente da lista de partições primárias iniciais. Ele não retorna uma partição primária estrangeira. O SessionHandle pode ser serializado em um cookie HTTP, por exemplo, e depois converter o cookie novamente em um SessionHandle. Em seguida, as APIs do WebSphere eXtreme Scale podem obter um Session ligado à mesma partição novamente, usando SessionHandle.

Nota: Não é possível usar agentes para interagir com uma grade de dados PER_CONTAINER.

Vantagens

A descrição anterior é diferente de FIXED_PARTITION ou da grade de dados hash normal porque o cliente por contêiner armazena dados em um local na grade, obtém um identificador para eles e usa o identificador para acessá-los novamente. Não existe uma chave fornecida por aplicativo como existe no caso de uma partição fixa.

Sua implementação não cria uma nova partição para cada Session. Portanto, em uma implementação por contêiner, as chaves utilizadas para armazenar dados na partição devem ser exclusivas dentro dessa partição. Por exemplo, é possível fazer o cliente gerar um SessionID exclusivo e depois utilizá-lo como chave para localizar informações em Mapas nessa partição. Várias sessões do cliente interagem com a mesma partição, portanto o aplicativo precisa utilizar chaves exclusivas para armazenar dados da sessão em cada partição fornecida.

Os exemplos anteriores utilizaram 5 partições, mas o parâmetro numberOfPartitions no arquivo XML de objectgrid pode ser utilizado para especificar as partições conforme necessário. Em vez de ser por grade de dados, a configuração é por contêiner. (O número de réplicas é especificado da mesma maneira que com a política de partição fixa.)

A política por contêiner também pode ser utilizada com várias zonas. Se possível, o eXtreme Scale retorna um SessionHandle para uma partição cuja primária está localizada na mesma zona que esse cliente. O cliente pode especificar a zona como um parâmetro para o contêiner ou utilizando uma API. O ID da zona do cliente pode ser configurado por meio de serverproperties ou clientproperties.

A estratégia PER_CONTAINER para uma grade adéqua os aplicativos que armazenam o estado do tipo de conversação e não os dados orientados por banco de dados. A chave para acessar os dados seria um ID de conversa e não tem relação com um registro do banco de dados específico. Ela fornece melhor desempenho (porque as partições primárias podem ser colocadas junto com os servlets, por exemplo) e configuração mais fácil (sem precisar calcular partições e contêineres).