Zonas

As zonas fornecem um controle sobre o posicionamento de shard. As zonas são agrupamentos lógicos definidos pelo usuário de servidores físicos. A seguir há exemplos de diferentes tipos de zonas: servidores blade diferentes, chassi de servidores blade, pisos de um prédio, edifícios ou diferentes locais geográficas em um ambiente de diversos datacenters. Outro caso de uso está em um ambiente virtualizado onde muitas instâncias do servidor, cada uma com um endereço IP exclusivo, são executadas no mesmo servidor físico.

Zonas Definidas Entre os Datacenters

O exemplo e o caso de uso clássicos para zonas é quando você possui dois ou mais datacenters dispersos geograficamente. Os datacenters dispersos propagam sua grade de dados para diferentes locais para recuperação de falha do datacenter. Por exemplo, você pode querer garantir ter um conjunto completo de shards de réplica assíncronos para sua grade de dados em um datacenter remoto. Com essa estratégia, é possível recuperar-se da falha do datacenter local de modo transparente, sem perda de dados. Os datacenters em si possuem redes de alta velocidade e de baixa latência. No entanto, a comunicação entre um datacenter e outro tem latência mais alta. As réplicas síncronas são usadas em cada datacenter onde a baixa latência minimiza o impacto da replicação nos tempos de resposta. Usar a replicação assíncrona reduz o impacto no tempo de resposta. A distância geográfica fornece disponibilidade no caso de falha de um datacenter local.

No exemplo a seguir, os shards primários para a zona Chicago possui réplicas na zona London. Os shards primários para a zona London possuem réplicas na zona Chicago.

Figura 1. Primários e Réplicas em Zonas
Primários e Réplicas em Zonas

Três definições de configuração no eXtreme Scale controlam o posicionamento do shard:

  • Configurar o arquivo de implementação
  • Grupo de contêineres
  • Especificar regras

As seções a seguir explicam as diferentes opções, apresentadas das mais simples até as mais complicadas.

Modo Desativar Desenvolvimento

No seu arquivo XML de implementação, configure: developmentMode="false".

Esta etapa simples ativa a primeira política de posicionamento de shard do eXtreme Scale.

Para obter mais informações sobre o arquivo XML, consulte Arquivo Descritor XML de Política de Implementação.

Política 1: Os shards para a mesma partição são colocados em servidores físicos separados.

Considere um exemplo simples de uma grade de dados com um shard de réplica. Com esta política, os shards primários e de réplica para cada partição estão em servidores físicos diferentes. Se um único servidor físico falhar, nenhum dado será perdido. Os shards primários ou de réplica de cada partição estão em servidores físicos diferentes que não falhou, ou estão em algum outro servidor físico que também não falhou.

A alta disponibilidade e simplicidade dessa política torna a configuração mais eficiente para todos os ambientes de produção. Em muitos casos, aplicar essa política é a única etapa necessária para controlar efetivamente o posicionamento de shard em seu ambiente.

Para aplicar essa política, um servidor físico é definido por um endereço IP. Os shards são colocados em servidores de contêiner. Os servidores de contêiner possuem um endereço IP, por exemplo, o parâmetro -listenerHost no script startOgServer. Diversos servidores de contêiner podem ter o mesmo endereço IP.

Como um servidor físico possui diversos endereços IP, considere a próxima etapa para obter mais controle de seu ambiente.

Defina Zonas para Agrupar Servidores de Contêiner

Os servidores de contêiner são designados à zonas com o parâmetro -zone no script startOgServer. Em um ambiente do WebSphere Application Server, as zonas são definidas por meio de grupos de nós com um formato de nome específico: ReplicationZone<Zone>. Neste modo, você escolhe o nome e a associação de suas zonas. Para obter informações adicionais, consulte Definindo Zonas para Servidores de Contêiner.

Política 2: Os shards da mesma partição são colocados em zonas separadas.

Considere estender o exemplo de uma grade de dados com um shard de réplica ao implementá-lo entre dois datacenters. Defina cada datacenter como uma zona independente. Use um nome de zona de DC1 para os servidores de contêiner no primeiro datacenter e o nome DC2 para os servidores de contêiner no segundo datacenter. Com esta política, os shards primários e de réplica para cada partição estariam em datacenters diferentes. Se um datacenter falhar, nenhum dado será perdido. Para cada partição, o shard primário ou de réplica está no outro datacenter.

Com esta política, é possível controlar o posicionamento do shard ao definir zonas. Pode-se também escolher seu limite físico ou lógico ou um agrupamento desejado. Em seguida, escolha um nome de zona exclusivo para cada grupo e inicie os servidores de contêiner em cada uma de suas zonas com o nome da zona apropriado. Assim, o eXtreme Scale coloca shards de modo que os shards da mesma partição sejam colocados em zonas separadas.

Especificar Regras da Zona

O nível de controle mais fino sobre o posicionamento de shard é alcançado usando regras de zona. As regras de zona são especificadas no elemento zoneMetadata do descritor XML da política de implementação do eXtreme Scale. Uma regra de zona define um conjunto de zonas no qual os shards são colocados. Um elemento shardMapping designa um shard para uma regra de zona. O atributo shard do elemento shardMapping especifica o tipo de shard:
  • P especifica o shard primário
  • S especifica shards de réplica síncronos
  • A especifica shards de réplica assíncronos.
Se mais de uma réplica síncrona ou assíncrona existir, você deverá fornecer elementos shardMapping do tipo de shard apropriado. O atributo exclusivePlacement do elemento zoneRule determina o posicionamento dos shards na mesma partição em zonas. Os valores do atributo exclusivePlacement são:
  • true (um shard não pode ser colocado na mesma zona do outro shard da mesma partição).

    Lembre-se: Para o caso "true", você deve ter pelo menos tantas zonas na regra quanto possui shards usando-a. Fazer isso assegura que cada shard esteja em sua própria zona.

  • false (os shards da mesma partição podem ser colocados na mesma zona.
A configuração padrão é true.

Para obter informações adicionais, consulte Exemplo: Definições de Zona no Arquivo Descritor XML de Política de Implementação.

Casos de Uso Estendidos

A seguir há vários casos de uso para estratégias de posicionamento de shard:

Upgrades contínuos

Considere um cenário no qual você deseja aplicar upgrades contínuos nos seus servidores físicos, incluindo a manutenção que requer o reinício de sua implementação. Neste exemplo, suponha que você tenha uma grade de dados espalhada por 20 servidores físicos, definida com uma réplica síncrona. Você deseja encerrar 10 dos servidores físicos de uma vez para manutenção.

Quando você encerra grupos de 10 servidores físicos, nenhuma partição possui shards primário e de réplica nos servidores que estão sendo encerrados. Caso contrário, os dados dessa partição são perdidos.

A solução mais fácil é definir uma terceira zona. Em vez de duas zonas de 10 servidores físicos cada, use três zonas, duas com sete servidores físicos e uma com seis. Espalhar os dados em mais zonas permite melhor disponibilidade de failover.

Em vez de definir outra zona, a outra abordagem é incluir uma réplica.

Fazendo Upgrade do eXtreme Scale

Quando você estiver fazendo upgrade do software do eXtreme Scale de forma contínua com grades de dados contendo dados ativos, considere as seguintes questões. A versão do software de serviço de catálogo deve ser maior ou igual às versões do software do servidor de contêiner. Primeiro faça upgrade de todos os servidores de catálogos com uma estratégia contínua. Leia mais sobre como fazer upgrade de sua implementação no tópico Atualizando Servidores eXtreme Scale.

Alterando o Modelo de Dados

Uma questão relacionada é como alterar o modelo de dados ou o esquema de objetos que são armazenados na grade de dados sem causar tempo de inatividade. Seria problemático alterar o modelo de dados ao parar a grade de dados e reiniciar com as classes do modelo de dados atualizadas no caminho de classe do servidor de contêiner e recarregando a grade de dados. Uma alternativa seria iniciar uma nova grade de dados com o novo esquema, copiar os dados da grade de dados antiga para a nova grade de dados e, em seguida, encerrar a grade de dados antiga.

Cada um desses processos é problemático e resulta em tempos de inatividade. Para alterar o modelo de dados sem causar tempo de inatividade, armazene o objeto em um destes formatos:
  • Use o XML como o valor
  • Use um blob feito com protocolo de buffers Google
  • Use o JavaScript Object Notation (JSON)
Grave serializadores para ir desde o plain old Java object (POJO) até um desses formatos facilmente no lado do cliente. As mudanças de esquema se tornam mais fáceis.

Virtualização

Computação em nuvem e virtualização são tecnologias populares emergentes. Por padrão, o eXtreme Scale garante que dois shards da mesma partição nunca sejam colocados no mesmo endereço IP, conforme descrito na Política 1. Quando você estiver implementando as imagens virtuais, tais como VMware, muitas instâncias do servidor, cada uma com um endereço IP exclusivo, podem ser executadas no mesmo servidor físico. Para assegurar que as réplicas sejam colocadas em servidores físicos separados, é possível usar zonas para resolver o problema. Agrupe seus servidores físicos nas zonas e use as regras de posicionamento de zona para manter os shards primários e de réplica em zonas separadas.

Zones para redes remotas

Você pode querer implementar uma única grade de dados do eXtreme Scale em várias construções ou datacenters com conexões de rede mais lentas. Conexões de rede mais lentas levam a uma largura da banda menor e mais conexões de latência. A possibilidade de partições de rede também aumenta neste modo devido ao congestionamento de rede e outros fatores.

Para lidar com esses riscos, o serviço de catálogo do eXtreme Scale organiza os servidores de contêiner em grupos principais que trocam pulsações para detectar uma falha do servidor de contêiner. Esses grupos principais não se estendem pelas zonas. Um líder dentro de cada grupo principal envia informações de associação no serviço de catálogo. O serviço de catálogo verifica quaisquer falhas relatadas antes de responder a uma informação de associação pela pulsação do servidor de contêiner em questão. Se o serviço de catálogo visualizar uma falsa detecção de falha, o serviço de catálogo não executará nenhuma ação. A partição do grupo principal se recompõe rapidamente. O serviço de catálogo também faz pulsações dos líderes do grupo principal periodicamente a uma taxa mas baixa para tratar o caso de isolamento do grupo principal.