Direccionamiento a zonas según preferencias

Con el direccionamiento a zonas según preferencias, puede definir cómo WebSphere eXtreme Scale direcciona las transacciones a las zonas.

Tiene control sobre dónde se colocan los fragmentos de una cuadrícula de datos. Consulte Configuración de zonas para la colocación de réplicas para obtener más información sobre algunos escenarios básicos y cómo configurar la política de despliegue de la forma correspondiente.

El direccionamiento a zonas según preferencias permite a los clientes de WebSphere eXtreme Scale especificar una preferencia para una zona determinada o un conjunto de zonas. Como resultado, las transacciones de cliente se direccionan a las zonas de preferencia antes de intentar direccionarse a cualquier otra zona.

Requisitos para el direccionamiento a zonas según preferencias

Antes de intentar el direccionamiento a zonas según preferencias, asegúrese de que la aplicación pueda satisfacer los requisitos del escenario.

La colocación de partición por contenedor es necesaria para utilizar el direccionamiento a zonas según preferencias. Esta estrategia de colocación es muy adecuada para las aplicaciones que almacenan datos de sesión en ObjectGrid. La estrategia de colocación de particiones predeterminada de WebSphere eXtreme Scale es fixed-partition. Las claves utilizan el código hash en el momento de confirmar una transacción para determinar qué partición alberga el par de clave-valor de la correlación cuando se utiliza la ubicación de partición fija.

La colocación por contenedor asigna los datos a una partición aleatoria cuando la transacción confirma tiempo mediante el objeto SessionHandle. Debe poder reconstruir el objeto SessionHandle para recuperar los datos de la cuadrícula de datos.

Puede utilizar zonas para tener más control sobre dónde se colocan los fragmentos primarios y de réplica en el dominio. La utilización de varias zonas en el despliegue tiene ventajas cuando los datos se encuentran en varias ubicaciones físicas de datos. La separación geográfica de los fragmentos primarios y de réplica es una forma de asegurarse de que la pérdida catastrófica de un centro de datos no afectará a la disponibilidad de los datos.

Cuando los datos se distribuyen entre varias zonas, es probable que los clientes también se distribuyan a lo largo de la topología. El direccionamiento de clientes a su centro de datos o zona local tiene la obvia ventaja de rendimiento de una menor latencia de red. Direccione los clientes a centros de datos o zonas locales cuando sea posible.

Configuración de la topología para el direccionamiento a zonas según preferencias

Considere el siguiente escenario. Tiene dos centros de datos: Chicago y Londres. Para minimizar el tiempo de respuesta de los clientes, desea que los clientes lean y escriban los datos en su centro de datos local.

Los fragmentos primarios se deben colocar en cada centro de datos de forma que se puedan escribir las transacciones localmente desde cada ubicación. Los clientes deben conocer las zonas para poder direccionar a la zona local.

La colocación por contenedor localiza nuevos fragmentos primarios en cada contenedor que se inicia. Las réplicas se colocan según la zona y las reglas de colocación especificadas por la política de despliegue. De forma predeterminada, una réplica se coloca en una zona distinta a su fragmento primario. Tenga en cuenta la siguiente política de despliegue para este escenario.

<?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 contenedor que se inicia con la política de despliegue recibe tres nuevos fragmentos primarios. Cada fragmento primario tiene una réplica asíncrona. Inicie cada contenedor con el nombre de zona apropiado. Utilice el parámetro -zone si está iniciando los contenedores con el script startOgServer.

Para un servidor de contenedor de Chicago:

  • [Unix][Linux]
    startOgServer.sh s1 -objectGridFile ../xml/universeGrid.xml
    -deploymentPolicyFile ../xml/universeDp.xml
    -catalogServiceEndPoints MyServer1.company.com:2809
    -zone Chicago
  • [Windows]
    startOgServer.bat s1 -objectGridFile ../xml/universeGrid.xml
    -deploymentPolicyFile ../xml/universeDp.xml
    -catalogServiceEndPoints MyServer1.company.com:2809
    -zone Chicago

Si los contenedores se ejecutan en WebSphere Application Server, debe crear un grupo de nodos y nombrarlo con el prefijo ReplicationZone. Los servidores que se ejecutan en los nodos en estos grupos de nodos se colocan en la zona correspondiente. Por ejemplo, los servidores en ejecución en un nodo de Chicago podrían estar en un grupo de nodos denominado ReplicationZoneChicago.

Si desea más información, consulte Configuración de zonas para la colocación de réplicas.

Los fragmentos primarios de la zona de Chicago tienen réplicas en la zona de Londres. Los fragmentos primarios de la zona de Londres tienen réplicas en la zona de Chicago.

Figura 1. Primarios y réplicas en las zonas
Primarios y réplicas en las zonas

Establezca las zonas preferidas para los clientes. Proporcione un archivo de propiedades de cliente a la máquina virtual Java (JVM) de cliente. Cree un archivo denominado objectGridClient.properties y asegúrese de que este archivo esté en la classpath.

Incluya la propiedad preferZones en el archivo. Establezca el valor de propiedad en la zona apropiada. Los clientes de Chicago deben tener el siguiente valor en el archivo objectGridClient.properties:

preferZones=Chicago

El archivo de propiedades de los clientes de Londres debe contener el siguiente valor:

preferZones=London

Esta propiedad indica a cada cliente que direccione las transacciones a su zona local, si es posible. La topología replica de forma asíncrona los datos insertados en un fragmento primario de la zona local en la zona foránea.

Utilización de la interfaz SessionHandle para direccionar a la zona local

La estrategia de colocación por contenedor no utiliza un algoritmo basado en hash para determinar la ubicación de los pares clave-valor de la cuadrícula de datos. Debe utilizar objetos SessionHandle para asegurarse de que las transacciones se direccionan a la ubicación correcta cuando se utiliza esta estrategia de colocación. Cuando se confirma una transacción, se enlaza un objeto SessionHandle a la sesión, si no se ha establecido aún uno. También se puede enlazar el objeto SessionHandle a la sesión llamando al método Session.getSessionHandle antes de confirmar la transacción. El fragmento de código siguiente muestra el enlace de un SessionHandle antes de confirmar la transacción.

Session ogSession = objectGrid.getSession();

// enlazando SessionHandle
SessionHandle sessionHandle = ogSession.getSessionHandle();

ogSession.begin();
ObjectMap map = ogSession.getMap("planet");
map.insert("planet1", "mercury");

// la transacción se direcciona a la partición especificada por SessionHandle
ogSession.commit();

Supongamos que el código anterior se ejecutaba en un cliente en el centro de datos de Chicago. El atributo preferZones se establece en Chicago para este cliente. Como resultado, el despliegue direccionaría las transacciones a una de las particiones primarias de la zona de Chicago: partición 0, 1, 2, 6, 7 u 8.

El objeto SessionHandle proporciona una vía de acceso a la partición que está almacenando estos datos confirmados. El objeto SessionHandle se debe reutilizar o reconstruir y establecer en la sesión para volver a la partición que contiene los datos confirmados.

ogSession.setSessionHandle(sessionHandle);
ogSession.begin();

// el valor devuelto será "mercury "
String value = map.get("planet1");
ogSession.commit();

La transacción de este código reutiliza el objeto SessionHandle creado durante la transacción de inserción. A continuación, la transacción get direcciona a la partición que contiene los datos insertados. Sin el objeto SessionHandle, la transacción no puede recuperar los datos insertados.

Cómo afectan los errores de contenedor y zona en el direccionamiento basado en zonas

Normalmente, un cliente con la propiedad preferZones establecida direcciona todas las transacciones a la zona o zonas especificadas. Sin embargo, la pérdida de un contenedor causa que un fragmento de réplica pase a ser un fragmento primario. Un cliente que direccionaba anteriormente a las particiones de la zona local debe recuperar los datos insertados anteriormente de la zona remota.

Considere el siguiente escenario. Se ha perdido un contenedor de la zona de Chicago. Previamente, contenía los primarios para las particiones 0, 1 y 2. A continuación, los nuevos fragmentos primarios de estas particiones se colocan en la zona de Londres ya que la zona de Londres alojaba las réplicas de estas particiones.

Cualquier cliente de Chicago que utilice un objeto SessionHandle que apunte a una de las particiones que se ha migrado tras el error ahora se direccionará a Londres. Los clientes de Chicago que utilizan nuevos objetos SessionHandle se direccionarán a fragmentos primarios basados en Chicago.

De forma similar, si se pierde toda la zona de Chicago, todas las réplicas de la zona de Londres pasarán a ser fragmentos primarios. En este escenario, todos los clientes de Chicago direccionan sus transacciones a Londres.