Configurando Zonas para a Colocação de Réplica

O suporte à zona permite configurações sofisticadas para posicionamento de réplica nos datacenters. Com esse recurso, as grades de milhares de partições podem ser facilmente gerenciadas utilizando algumas regras de localização opcionais. Um datacenter pode estar em diferentes andares de um prédio, diferentes prédios ou até mesmo cidades diferentes ou outras distinções, conforme configurado com as regras de zonas.

Flexibilidade de Zonas

É possível colocar shards em zonas. Esta função permite que você tenha mais controle sobre como o eXtreme Scale coloca shards em uma grade. A Java Virtual Machines que hospeda um servidor eXtreme Scale pode ser identificada com um identificador de zona. O arquivo de implementação agora pode incluir uma ou mais regras de zonas e estas regras de zonas estão associadas com um tipo shard. A seção a seguir fornece uma visão geral de uso da zona. Para obter mais detalhes, consulte Controlando o Posicionamento de Shard com Zonas. .

Controle de zonas de disposição de como o eXtreme Scale designa primários e réplicas para configurar topologias avançadas.

Um Java Virtual Machine pode ter vários contêineres, mas apenas 1 servidor. Um contêiner pode hospedar vários shards a partir de um único ObjectGrid.

Este recurso é útil para certificar-se de que as réplicas e os primários sejam colocados em diferentes locais ou zonas para obter uma melhor alta disponibilidade. Normalmente, o eXtreme Scale não coloca um shard primário e de réplica na Java Virtual Machines com o mesmo endereço IP. Esta regra simples normalmente evita que dois servidores eXtreme Scale sejam colocados no mesmo computador físico. Entretanto, pode ser necessário um mecanismo mais flexível. Por exemplo, você pode estar utilizando dois chassis blade e desejar que os shards primários sejam divididos em ambos os chassis e que a réplica para cada shard primário seja colocada no outro chassi a partir do primário.

Dividido significa que os shards primários são colocados em cada zona e a réplica para cada primário está localizada na zona oposta. O primário 0, por exemplo, poderia estar na zoneA, a réplica síncrona 0 poderia estar na zoneB. O primário 1 poderia estar na zoneB, e a réplica síncrona 1 poderia estar na zoneA.

O nome do chassi poderia ser o nome da zona neste caso. Alternativamente, você pode chamar as zonas de acordo com os andares em um prédio e utilizar as zonas para ter certeza de que os primários e as réplicas para os mesmos dados estejam em andares diferentes. Prédios e datacenter também são possíveis. Foram feitos testes em datacenters utilizando zonas como um mecanismo para garantir que os dados sejam adequadamente replicados entre os datacenters. Se você estiver utilizando o HTTP Session Manager para eXtreme Scale, também é possível utilizar zonas. Com este recurso, é possível implementar um aplicativo da Web único em três datacenters e garantir que as sessões HTTP para usuários sejam replicas nos datacenters para que as sessões possam ser recuperadas, mesmo se um datacenters inteiro falhar.

O WebSphere eXtreme Scale está ciente da necessidade de gerenciar uma grade grande sobre vários datacenters. Isso pode assegurar que os primários e os backups da mesma partição estejam localizados em datacenters diferentes, se isto for necessário. Ele pode colocar todos os primários no datacenter 1 e todas as réplicas no datacenter 2, ou pode fazer um round robin com os primários e as réplica em ambos os datacenters. As regras são flexíveis de modo que muitos cenários são possíveis. O eXtreme Scale também pode gerenciar milhares de servidores, que juntos com a disposição completamente automática e o reconhecimento do datacenter tornam tais grades grandes financeiramente suportáveis de um ponto de vista administrativo. Os administradores podem especificar o que desejam fazer de maneira simples e eficiente.

Como um administrador, utilize zonas de disposição para controlar onde os shards primários e de réplica são colocados, o que permite a configuração de topologias avançadas de alto desempenho e altamente disponíveis. É possível definir uma zona para qualquer agrupamento lógico de processos do eXtreme Scale, conforme observado acima: Estas zonas podem corresponder a locais de estação de trabalho físicas, tais como um datacenter, um andar de um datacenter ou um chassi blade. É possível dividir dados em zonas, o que fornece aumento de disponibilidade ou você dividir os primários e as réplicas em zonas separadas quando um hot standby é necessário.

Associando um Servidor eXtreme Scale com um Zona que não está utilizando o WebSphere Extended Deployment

Se o eXtreme Scale for utilizado com Java Standard Edition ou um servidor de aplicativos que não seja baseado no WebSphere Extended Deployment versão 6.1, um JVM que é um contêiner de shard pode ser associado a uma zona se estiver utilizando as seguintes técnicas.

Aplicativos utilizando o script startOgServer

O script startOgServer é utilizado para iniciar um aplicativo eXtreme Scale quando ele não está sendo integrado em um servidor existente. O parâmetro -zone é utilizado para especificar a zona a utilizar para todos os contêineres no servidores.

Especificando a zona ao iniciar um contêiner utilizando APIs

O nome da zona para um contêiner pode ser especificado conforme descrito na documentação do API do Servidor Integrado.

Associando Nós do WebSphere Extended Deployment com Zonas

Se você estiver usando eXtreme Scale com aplicativos WebSphere Extended Deployment Java EE, será possível usar grupos de nós do WebSphere Extended Deployment para posicionar servidores em zonas específicas.

No eXtreme Scale, um JVM só pode ser membro de uma única zona. Entretanto, o WebSphere permite que um nó faça parte de vários grupos de nós. É possível utilizar essa funcionalidade de zonas do eXtreme Scale se tiver certeza de que cada um de seus nós esteja em apenas um grupo de nós da zona.

Utilize a seguinte sintaxe para nomear o grupo de nós para declará-lo em uma zona: ReplicationZone<UniqueSuffix>. Servidores em execução em um nó que faz parte desse grupo de nós são incluídos nas zonas especificadas pelo nome do grupo de nós. A seguir está uma descrição de uma topologia de exemplo.

Primeiro, você configura 4 nós: node1, node2, node3 e node4, cada um com 2 servidores. Em seguida, você cria um grupo de nós denominado ReplicationZoneA e um grupo de nós denominado ReplicationZoneB. Em seguida, você inclui node1 e node2 em ReplicationZoneA e inclui node3 e node4 em ReplicationZoneB.

Quando os servidores no node1 e node2 são iniciados, eles se tornam parte de ReplicationZoneA; da mesma forma, os servidores em node3 e node4 se tornarão parte de ReplicationZoneB.

Uma JVM membro da grade verifica a associação da zona apenas na inicialização. A inclusão de um novo grupo de nós ou a mudança da associação têm impacto apenas nas JVMs recém iniciadas ou reiniciadas.

Regras de Zonas

Uma partição do eXtreme Scale possui um shard primários e zero ou mais shards de réplica. Para este exemplo, considere a seguinte convenção de nomenclatura para estes shards. P é o shard primário, S é uma réplica assíncrona e A é uma réplica assíncrona. Uma regra de zona possui três componentes:

  • Um nome de regra
  • Uma lista de zonas
  • Um sinalizador inclusivo ou exclusivo
O nome da zona para um contêiner pode ser especificado conforme descrito na documentação do API do Servidor Integrado. Uma regra de zona especifica o possíveis conjuntos de zonas nos quais um shard pode ser colocado. O sinalizador inclusivo indica que após um shard ser colocado na lista, então, todos os outros shards também são colocados em tal zona. Uma configuração exclusiva indica que cada shard para uma partição é colocada em uma zona diferente na lista de zonas. Por exemplo, utilizar uma configuração exclusiva significa que se houver três shards (um primário e duas réplicas síncronas), então, a lista de zonas deve ter três zonas.

Cada shard pode ser associado com uma regra de zona. Uma regra de zona pode ser compartilhada entre dois shards. Quando uma regra é compartilhada, então o sinalizador inclusivo ou exclusivo é estendido pelos shards de todos os tipos compartilhando uma regra única.

Exemplos

A seguir, está um conjunto de exemplos mostrando diversos cenários e a configuração de implementação para implementar os cenários.

Dividindo primários e réplicas entre zonas

É possível ter três chassis blade e desejar primários distribuídos para os três, com uma réplica síncrona única colocada em um chassi diferente do primário. Defina cada chassis como uma zona com nomes de chassi ALPHA, BETA e GAMMA. A seguir, está um exemplo de XML de implementação:

<?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="library">
			<mapSet name="ms1" numberOfPartitions="37" minSyncReplicas="1"
				maxSyncReplicas="1" maxAsyncReplicas="0">
			<map ref="book" />
			<zoneMetadata>
				<shardMapping shard="P" zoneRuleRef="stripeZone"/>
				<shardMapping shard="S" zoneRuleRef="stripeZone"/>
				<zoneRule name ="stripeZone" exclusivePlacement="true" >
					<zone name="ALPHA" />
					<zone name="BETA" />
					<zone name="GAMMA" />
				</zoneRule>
			</zoneMetadata>
		</mapSet>
	</objectgridDeployment>
</deploymentPolicy>

Este XML de implementação contém uma grade chamada library com um Mapa único denominado book. Ele utiliza quatro partições com uma única réplica síncrona. A cláusula de metadados de zona mostra a definição de uma única regra de zona e a associação das regras de zona com os shards. Os shards primários e síncronos estão ambos associados com a regra de zona "stripeZone". A regra de zona possui as três zonas e utiliza a disposição exclusiva. Esta regra significa que se o primário para a partição 0 for colocado no ALPHA, então, a réplica para a partição 0 será colocada no BETA ou GAMMA. De maneira semelhante, os primários para outras partições são colocados em outras zonas e as réplicas serão colocadas.

Réplica assíncrona em uma zona diferente da primária e réplica síncrona

Neste exemplo, existem dois prédios com uma alta conexão de latência entre eles. Você não deseja alta disponibilidade de perda de dados para todos os cenários. Entretanto, o impacto de desempenho da replicação síncrona entre os prédios o leva a um dilema. Você deseja um primário com réplica síncrona em um prédio e uma réplica assíncrona em outro prédio. Normalmente, as falhas são paralisações da JVM ou falhas de computador ao invés de problemas de larga escala. Com esta topologia, é possível sobrevier a falhas normais sem nenhuma perda de dados. A perda de um prédio é rara o suficiente que alguma perda de dados é aceitável neste caso. É possível criar duas zonas, uma para cada prédio. A seguir, está o arquivo XML de implementação:

<?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="library">
		<mapSet name="ms1" numberOfPartitions="13" minSyncReplicas="1"
			maxSyncReplicas="1" maxAsyncReplicas="1">
			<map ref="book" />
			<zoneMetadata>
				<shardMapping shard="P" zoneRuleRef="primarySync"/>
				<shardMapping shard="S" zoneRuleRef="primarySync"/>
				<shardMapping shard="A" zoneRuleRef="aysnc"/>
				<zoneRule name ="primarySync" exclusivePlacement="false" >
						<zone name="BldA" />
						<zone name="BldB" />
				</zoneRule>
				<zoneRule name="aysnc" exclusivePlacement="true">
						<zone name="BldA" />
						<zone name="BldB" />
				</zoneRule>
			</zoneMetadata>
		</mapSet>
	</objectgridDeployment>
</deploymentPolicy>

O primário e a réplica síncrona compartilham uma regra de zona primaySync com uma configuração de sinalizador exclusivo de false. Portanto, após o primário ou síncrono ser colocado em uma zona, então o outro também é colocado na mesma zona. A réplica assíncrona utiliza uma segunda regra de zona com as mesmas zonas que a regra de zona primarySync, mas ela utiliza o atributo exclusivePlacement configurado como true. Este atributo indica que um shard não pode ser colocado em uma zona com outro shard a partir da mesma partição. Como resultado, a réplica assíncrona não é colocada na mesma zona que o primário e as réplicas síncronas.

Colocar todos os primários em uma zona e todas réplicas em outra zona

Aqui, todos os primários estão em uma zona específica e todas as réplicas em uma zona diferente. Teremos um primário e uma réplica assíncrona única. Todas as réplicas estarão na zona A e os primários na B.

	<?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="library">
			<mapSet name="ms1" numberOfPartitions="13" minSyncReplicas="0"
				maxSyncReplicas="0" maxAsyncReplicas="1">
				<map ref="book" />
				<zoneMetadata>
					<shardMapping shard="P" zoneRuleRef="primaryRule"/>
					<shardMapping shard="A" zoneRuleRef="replicaRule"/>
					<zoneRule name ="primaryRule">
						<zone name="A" />
					</zoneRule>
					<zoneRule name="replicaRule">
						<zone name="B" />
							</zoneRule>
						</zoneMetadata>
					</mapSet>
			</objectgridDeployment>
	</deploymentPolicy>
Aqui, você pode ver duas regras, uma para os primários (P) e outra para a réplica (A).

Zonas sobre Wide Area Networks (WAN)

Você pode desejar implementar um eXtreme Scale único em vários prédios ou datacenters com interconexõ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. O eXtreme Scale aborda este ambiente severo das seguintes maneiras.

Pulsação limitada entre zonas

As Java Virtual Machines agrupadas em grupos principais realizam pulsação uma com a outra. Quando o serviço de catálogo organiza as Java Virtual Machines nos grupos, tais grupos não se estendem sobre zonas. Um líder neste grupo executa o push das informações de associação no serviço de catálogo. O serviço de catálogo verifica quaisquer falhas relatadas antes de tomar a ação. Ele faz isto ao tentar conectar-se às Java Virtual Machines suspeitas. Se o serviço de catálogo visualiza uma falsa detecção de falha, então, ele não executa nenhuma ação já que a partição do grupo principal irá resolver o problema em um curto período de tempo.

O serviço de catálogo também executar pulsação nos líderes do grupo principal periodicamente em uma taxa mas baixa para tratar o caso de isolamento do grupo principal.