El soporte de zonas permite realizar configuraciones sofisticadas para la colocación de réplicas en centros de datos. Con esta prestación, las cuadrículas de miles de particiones se pueden gestionar fácilmente utilizando un puñado de reglas de colocación opcionales. Un centro de datos puede estar en varias plantas de un edificio, distintos edificios, o incluso en distintas ciudades u otras distinciones, tal como se haya configurado con las reglas de zonas.
Puede colocar fragmentos en zonas. Esta función le permite tener más control sobre cómo eXtreme Scale coloca los fragmentos en una cuadrícula. Máquinas virtuales Java que aloja un servidor eXtreme Scale se puede marcar con un identificador de zona. El archivo de despliegue ahora puede incluir una o más reglas de zona y estas reglas de zona están asociadas con un tipo de fragmento. La siguiente sección proporciona una visión general del uso de la zona. Para obtener información más detallada, consulte Control de la colocación de fragmentos con zonas. .
El control de zonas de colocación de cómo eXtreme Scale asigna primarios y réplicas para configurar topologías avanzadas.
Una Máquina virtual Java puede tener varios contenedores pero sólo 1 servidor. Un contenedor puede alojar varios fragmentos de un solo ObjectGrid.
Esta prestación es útil para asegurarse de que los fragmentos primarios y los fragmentos réplicas se colocan en distintas ubicaciones o zonas para obtener una mejor alta disponibilidad. Normalmente, eXtreme Scale no coloca un fragmento primario y de réplica en la Mäquinas virtuales Java con la misma dirección IP. Esta regla simple normalmente impide que dos servidores eXtreme Scale se coloquen en el mismo sistema físico. No obstante, quizás necesite un mecanismo más flexible. Por ejemplo, es posible que esté utilizando dos chasis blade y desee que los primarios se extiendan por los dos chasis y la réplica de cada primario pueda colocarse en el otro chasis desde el primario.
Primarios extendidos significa que los primarios se colocan en cada zona y la réplica de cada primario se coloca en la zona opuesta. Por ejemplo, el primario 0 estaría en zoneA, y la réplica sinc 0 estaría en zoneB. El primario 1 estaría en zoneB, y la réplica sinc 1 estaría zoneA.
En este caso el nombre del chasis sería el nombre de zona. De forma alternativa, puede especificar nombres para zonas según sus plantas de un edificio y utilizar las zonas para asegurarse de que los primarios y las réplicas para los mismos datos estén en distintas plantas. También es posible edificios y centros de datos. Se han realizado comprobaciones en centros de datos utilizando zonas como mecanismo para asegurarse de que los datos se dupliquen de forma correcta entre los centros de datos. Si utiliza el gestor de sesiones HTTP para eXtreme Scale, también puede utilizar zonas. Con esta característica puede desplegar una sola aplicación web por tres centros de datos y asegurarse de que las sesiones HTTP para los usuarios se dupliquen a lo largo de los centros de datos para que las sesiones se puedan recuperar incluso si falla todo un centro de datos.
WebSphere eXtreme Scale reconoce la necesidad de gestionar una cuadrícula de gran tamaño por varios centros de datos. Si es necesario, puede asegurarse de que los fragmentos primarios y de copia de seguridad para la misma partición estén ubicados en distintos centros de datos. Puede colocar todos los primarios en el centro de datos 1 y todas las réplicas en el centro de datos 2, o puede aplicar un sistema de redondeo en los primarios y las réplicas entre los dos centros de datos. Las reglas son flexibles por lo que hay muchos escenarios posibles. eXtreme Scale también puede gestionar miles de servidores, que junto con la colocación totalmente automática con reconocimiento de centro de datos, hace que esas cuadrículas de gran tamaño sean asequibles desde un punto de vista administrativo. Los administradores pueden especificar lo que desean de forma simple y eficiente.
Como administrador, utiliza zonas de colocación para controlar donde se colocan los fragmentos primarios y de réplica, lo que permite configurar topologías avanzadas de alta disponibilidad y alto rendimiento. Puede definir una zona para cualquier agrupación lógica de procesos de eXtreme Scale, tal como se ha indicado anteriormente: estas zonas pueden corresponder a ubicaciones de estaciones de trabajo físicas, como un centro de datos, una planta de un centro de datos o un chasis de blade. Puede extender datos a través de zonas, que proporciona una mayor disponibilidad, o puede partir los primarios y las réplicas en distintas zonas cuando es necesario una parada activa.
Si se utiliza eXtreme Scale con Java Standard Edition o un servidor de aplicaciones que no se basa en WebSphere Extended Deployment versión 6.1, se puede asociar una JVM que es un contenedor de fragmento con una zona si utiliza las siguientes técnicas.
Aplicaciones que utilizan el script startOgServer
El script startOgServer se utiliza para iniciar una aplicación de eXtreme Scale cuando no se ha incrustado en un servidor existente. El parámetro -zone se utiliza para especificar la zona para utilizar todos los contenedores dentro del servidor.
Especificación de la zona al iniciar un contenedor utilizando las API
El nombre de la zona de un contenedor se puede especificar tal como se describe en la documentación de API de servidor incorporado.
Si utiliza eXtreme Scale con aplicaciones de WebSphere Extended Deployment Java EE, puede utilizar grupos de nodos de WebSphere Extended Deployment para colocar servidores en zonas específicas.
En eXtreme Scale, una JVM puede ser miembro de una sola zona. No obstante, WebSphere permite que un nodo forme parte de varios grupos de nodos. Puede utilizar esta funcionalidad de zonas de eXtreme Scale si se asegura de que cada uno de sus nodos sólo esté en un grupo de nodos de zona.
Utilice la sintaxis siguiente para nombrar su grupo de nodos para declararlo una zona: ReplicationZone<SufijoExclusivo>. Los servidores que se ejecutan en un nodo que forma parte de dicho grupo de nodos se incluyen en la zona especificada por el nombre del grupo de nodos. A continuación se ofrece una descripción de una topología de ejemplo.
En primer lugar, debe configurar 4 nodos: node1, node2, node3 y node4. Cada uno de estos nodos tiene 2 servidores. Luego debe crear un grupo de nodos denominado ReplicationZoneA y un grupo de nodos denominado ReplicationZoneB. A continuación, debe añadir node1 y node2 a ReplicationZoneA y añadir node3 y node4 a ReplicationZoneB.
Cuando se inicien los servidores en node1 y node2, éstos pasarán a formar parte de ReplicationZoneA y, del mismo modo, los servidores en node3 y node4 pasarán a formar parte de ReplicationZoneB.
Una JVM miembro de la cuadrícula comprueba la pertenencia a la zona sólo durante el inicio. Si se añade un nuevo grupo de nodos o se cambia la pertenencia sólo afecta a las JVM recién iniciadas o reiniciadas.
Una partición deeXtreme Scale tiene un fragmento primario y cero o más fragmentos de réplica. Para este ejemplo, considere el siguiente convenio de denominación para estos fragmentos. P es el fragmento primario, S es una réplica síncrona y A es una réplica asíncrona. Una regla de zonas tiene tres componentes:
Cada fragmento puede asociarse a una regla de zonas. Una regla de zonas puede compartirse entre dos fragmentos. Cuando una regla se comparte, el distintivo inclusivo o exclusivo se extiende a través de fragmentos de todos los tipos que comparten una sola regla.
A continuación se proporciona un conjunto de ejemplos que muestran distintos casos de ejemplo y la configuración de despliegue para implementar los casos de ejemplo.
Escritura en bandas de primarios y réplicas a través de zonas
Dispone de tres chasis blade y desea que los primarios se distribuyan a lo largo de los tres, con una sola réplica síncrona colocada en un chasis distinto al primario. Defina cada chasis como una zona con los nombres de chasis ALPHA, BETA y GAMMA. A continuación de proporciona un XML de despliegue de ejemplo:
<?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>
Un XML de despliegue contiene una cuadrícula denominada library con una cola correlación (map) denominada book. Utiliza cuatro particiones con una sola réplica síncrona. La cláusula de metadatos de zona muestra la definición de una sola regla de zonas y la asociación de reglas de zonas a fragmentos. Los fragmentos primario y síncrono están asociados a la regla de zonas "stripeZone". La regla de zonas tiene todas las tres zonas en ellas y utiliza la colocación exclusiva. Esta regla indica que si el primario de la partición 0 se coloca en ALPHA, la réplica de la partición 0 se colocará en BETA o GAMMA. De forma parecida, los primarios para otras particiones se colocan en otras zonas y las réplicas se colocarán.
Réplica asíncrona en una zona distinta a la réplica primaria y síncrona
En este ejemplo, existen dos edificios con una alta conexión de latencia entre ellos. Desea que no se pierdan datos de alta disponibilidad para todos los casos de ejemplo. No obstante, el impacto en el rendimiento de la réplica síncrona entre edificios le lleva a un compromiso. Desea un primario con una réplica síncrona en un edificio y una réplica asíncrona en el otro edificio. Normalmente, las anomalías son cuelgues de la JVM o anomalías en el sistema en lugar de problemas a gran escala. Con esta topología, puede superar anomalías normales sin pérdida de datos. La pérdida de un edificio es tan rato que alguna pérdida de datos es aceptable en ese caso. Puede crear dos zonas, una para cada edificio. A continuación se muestra el archivo XML de despliegue:
<?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>
La réplica primaria y síncrona comparten la regla de zonas primaySync con un valor de distintivo exclusivo de false. Por lo tanto, después de colocar el primario o síncrono en una zona, el otro también se coloca en la misma zona. La réplica asíncrona utiliza una segunda regla de zonas con las mismas zonas que la regla de zonas primarySync pero utiliza el atributo exclusivePlacement establecido en true. Este atributo indica que un fragmento no se puede colocar en una zona con otro fragmento de la misma partición. Como resultado, la réplica asíncrona no se coloca en la misma zona que el primario o las réplicas síncronas.
Colocar todos los primarios en una zona y todas las réplicas en otra zona
Aquí, todos los primarios están en una zona específica y todas las réplicas en una zona distinta. Tendremos un primario y una sola réplica asíncrona. Todas las réplicas estarán en la zona A y los primarios en 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>
Aquí, puede ver dos reglas, una para los primarios
(P) y otra para la réplica (A).Es posible que desee desplegar un solo eXtreme Scale en varios edificios o centros de datos con interconexiones de red más lentas. Las conexiones de red más lentas llevan a un ancho de banda más bajo y a conexiones de latencia más alta. La posibilidad de particiones de red también aumenta en esta modalidad debido a la congestión de la red y otros factores. eXtreme Scale aborda este entorno duro de las siguientes formas:
Pulsaciones limitadas entre zonas
Las Máquinas virtuales Java que están agrupadas en grupos principales se envían pulsaciones entre sí. Cuando el servicio de catálogo organiza las Mäquinas virtuales Java en grupos, estos grupos no abarcan zonas. Un líder dentro de este grupo pasa información de pertenencia al servicio de catálogo. El servicio de catálogo verifica todas las anomalías notificadas antes de realizar alguna acción. Lo lleva a cabo intentando conectarse a las Máquinas virtuales Java sospechosas. Si el servicio de catálogo ve una detección de anomalía falsa no realizará ninguna acción ya que la partición del grupo principal se arreglará en un corto periodo de tiempo.
El servicio de catálogo también enviará pulsaciones a líderes de grupo principal de forma periódica a velocidad baja para manejar el caso de aislamiento de grupo principal.