Zonas

Las zonas le proporcionan control sobre la colocación de fragmentos. Las zonas son agrupaciones lógicas definidas por el usuario de servidores físicos. A continuación se muestran ejemplos de distintos tipos de zonas: distintos servidores blade, chasis de servidores blade, plantas de un edificio, edificios o distintas ubicaciones geográficas en un entorno de varios centros de datos. Otro caso de uso es en un entorno virtualizado donde muchas instancias de servidor, cada una de ellas con una dirección IP exclusiva, se ejecutan en el mismo servidor físico.

Zonas definidas entre centros de datos

El ejemplo y caso de uso clásico de las zonas es cuando se tienen dos centros de datos geográficamente dispersos. Los centros de datos dispersos distribuyen la cuadrícula de datos entre distintas ubicaciones de recuperación de anomalía de centro de datos. Por ejemplo, es posible que desee asegurarse de que tiene un conjunto completo de fragmentos de réplica asíncrona para la cuadrícula de datos en un centro de datos remoto. Con esta estrategia, puede realizar la recuperación de la anomalía del centro de datos local de forma transparente, sin pérdida de datos. Los propios centros de datos tienen redes de latencia baja y velocidad alta. Sin embargo, la comunicación entre un centro de datos y otro tiene latencia más alta. Las réplicas síncronas se utilizan en cada centro de datos donde la baja latencia minimiza el impacto de la réplica en los tiempos de respuesta. La utilización de réplica asíncrona reduce el impacto sobre el tiempo de respuesta. La distancia geográfica proporciona disponibilidad en caso de anomalía de centro de datos local.

En el ejemplo siguiente, 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

Tres valores de configuración de eXtreme Scale controlan la colocación de fragmentos:

  • Establecer el archivo de despliegue
  • Agrupar contenedores
  • Especificar reglas

Las secciones siguientes explican las distintas opciones, presentadas de forma flexible en orden de complejidad creciente.

Inhabilitar modalidad de desarrollo

En el archivo XML de despliegue, establezca: developmentMode="false".

Este sencillo paso activa la primera política de colocación de fragmentos de eXtreme Scale.

Para obtener más información sobre el archivo XML, consulte Archivo XML de descriptor de política de despliegue.

Política 1: los fragmentos de la misma partición se colocan en servidores físicos distintos.

Considere un ejemplo sencillo de una cuadrícula de datos con un fragmento de réplica. Con esta política, los fragmentos primario y de réplica de cada partición se encuentran en distintos servidores físicos. Si falla un único servidor físico, no se producirá pérdida de datos. Los fragmentos primario o de réplica de cada partición se encuentran en servidores físicos distintos que no han fallado, o ambos se encuentran en algún otro servidor físico que no ha fallado.

La alta disponibilidad y simplicidad de esta política la convierte en el valor más eficaz para todos los entornos de producción. En muchos casos, la aplicación de esta política es el único paso necesario para controlar de forma efectiva la colocación de fragmentos en el entorno.

Al aplicar esta política, se define un servidor físico mediante una dirección IP. Los fragmentos se colocan en servidores de contenedor. Los servidores de contenedor tienen una dirección IP, por ejemplo, el parámetro -listenerHost en el script startOgServer. Varios servidores de contenedor pueden tener la misma dirección IP.

Dado que un servidor físico tiene varias direcciones IP, tenga en cuenta el paso siguiente para tener más control del entorno.

Definir zonas para agrupar servidores de contenedor

Los servidores de contenedor se asignan a zonas con el parámetro -zone en el script startOgServer. En un entorno de WebSphere Application Server, las zonas se definen mediante grupos de nodos con un formato de nombre específico: ReplicationZone<Zona>. De esta forma, puede elegir el nombre y la pertenencia de las zonas. Para obtener más información, consulte Definición de zonas para servidores de contenedor.

Política 2: se colocan fragmentos de la misma partición en zonas distintas.

Considere ampliar el ejemplo de una cuadrícula de datos con un fragmento de réplica desplegándolo en dos centros de datos. Defina cada centro de datos como una zona independiente. Utilice un nombre de zona de DC1 para los servidores de contenedor en el primer centro de datos, y de DC2 para los servidores de contenedor en el segundo centro de datos. Con esta política, los fragmentos primario y de réplica de cada partición estarían en distintos centros de datos. Si un centro de datos falla, no se producirá pérdida de datos. Para cada partición, su fragmento primario o de réplica está en el otro centro de datos.

Con esta política, puede controlar la colocación de fragmentos definiendo zonas. Puede elegir la agrupación o el límite físico o lógico que le interese. A continuación, elija un nombre de zona exclusivo para cada grupo, e inicie los servidores de contenedor en cada una de las zonas con el nombre de la zona correspondiente. Por lo tanto, eXtreme Scale coloca fragmentos de forma que los fragmentos de la misma partición se coloquen en zonas distintas.

Especificar reglas de zona

El nivel más preciso de control sobre la colocación de fragmentos se consigue utilizando reglas de zona. Las reglas de zona se especifican en el elemento zoneMetadata del XML de descriptor de política de despliegue de eXtreme Scale. Una regla de zona define un conjunto de zonas en el que se colocan los fragmentos. Un elemento shardMapping asigna un fragmento a una regla de zona. El atributo de fragmento del elemento shardMapping especifica el tipo de fragmento:
  • P especifica el fragmento primario
  • S especifica fragmentos de réplica síncrona
  • A especifica fragmentos de réplica asíncrona.
Si existe más de una réplica síncrona o asíncrona, debe proporcionar elementos shardMapping del tipo de fragmento correspondiente. El atributo exclusivePlacement del elemento zoneRule determina la colocación de fragmentos en la misma partición en zonas. Los valores del atributo exclusivePlacement son los siguientes:
  • true (un fragmento no se puede colocar en la misma zona que otro fragmento de la misma partición).

    Recuerde: En el caso "true", debe tener como mínimo tantas zonas en la regla como fragmentos que la utilicen. De esta forma se asegura de que cada fragmento puede estar en su propia zona.

  • false (los fragmentos de la misma partición se pueden colocar en la misma zona.
El valor predeterminado es true.

Para obtener más información, consulte Ejemplo: Definiciones de zona en el archivo XML de descriptor de política de despliegue.

Casos de uso ampliados

A continuación se muestran varios casos de uso de estrategias de colocación de fragmentos:

Actualizaciones rotativas

Considere un escenario en el que desea aplicar actualizaciones rotativas en los servidores físicos, incluido mantenimiento que requiere reinicio del despliegue. En este ejemplo, supongamos que tiene una cuadrícula de datos que se distribuye en 20 servidores físicos, definidos con una réplica síncrona. Desea concluir 10 de los servidores físicos simultáneamente para el mantenimiento.

Cuando concluye grupos de 10 servidores físicos, ninguna partición tiene simultáneamente sus fragmentos primario y de réplica en los servidores que está concluyendo. De lo contrario, perderá los datos de esa partición.

La solución más fácil es definir una tercera zona. En lugar de dos zonas de 10 servidores físicos, utilice tres zonas, dos con siete servidores físicos y una con seis. La distribución de los datos en más zonas permite una mejor migración tras error para la disponibilidad.

En lugar de definir otra zona, el otro enfoque es añadir una réplica.

Actualización de eXtreme Scale

Cuando se actualiza el software de eXtreme Scale de forma rotativa con cuadrículas de datos que contienen datos activos, tenga en cuenta los elementos siguientes. La versión del software del servicio de catálogo debe ser mayor o igual que las versiones del software del servidor de contenedor. En primer lugar, actualice todos los servidores de catálogo con una estrategia rotativa. Lea más sobre la actualización del despliegue en el tema Actualización de servidores eXtreme Scale.

Modificación del modelo de datos

Un problema relacionado es cómo modificar el modelo de datos o esquema de objetos almacenados en la cuadrícula de datos sin causar tiempo de inactividad. Causaría una interrupción modificar el modelo de datos deteniendo la cuadrícula de datos y reiniciando con las clases de modelo de datos actualizadas en la classpath del servidor de contenedor y recargando la cuadrícula de datos. Una alternativa sería iniciar una nueva cuadrícula de datos con el nuevo esquema, copiar los datos de la cuadrícula de datos antigua a la nueva cuadrícula de datos y a continuación concluir la cuadrícula de datos antigua.

Cada uno de estos procesos causa interrupción y produce tiempo de inactividad. Para modificar el modelo de datos sin tiempo de inactividad, almacene el objeto en uno de los formatos siguientes:
  • Utilice XML como valor
  • Utilice un blob creado con Google protobuf
  • Utilice JavaScript Object Notation (JSON)
Escriba serializadores para pasar de un POJO (plain old Java object) a uno de estos formatos fácilmente en el lado del cliente. Los cambios de esquema serán más fáciles.

Virtualización

Cloud computing y la virtualización son populares tecnologías emergentes. De forma predeterminada, eXtreme Scale asegura que dos fragmentos de la misma partición nunca se colocan en la misma dirección IP, tal como se describe en la Política 1. Cuando realiza el despliegue en imágenes virtuales, como por ejemplo VMware, muchas instancias de servidor, cada una con una dirección IP exclusiva, se pueden ejecutar en el mismo servidor físico. Para asegurarse de que las réplicas solo se puedan colocar en servidores físicos distintos, puede utilizar zonas para solucionar el problema. Agrupe los servidores físicos en zonas y utilice reglas de colocación para mantener fragmentos primarios y de réplica en zonas distintas.

Zonas para redes de área amplia

Es posible que desee desplegar una única cuadrícula de datos de eXtreme Scale en varios edificios o centros de datos con conexiones 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.

Para tratar estos riesgos, el servicio de catálogo de eXtreme Scale organiza los servidores de contenedor en grupos principales que intercambian pulsaciones para detectar anomalías de servidor de contenedor. Estos grupos principales no se distribuyen en varias zonas. Un líder de cada grupo principal envía la información de pertenencia al servicio de catálogo. El servicio de catálogo comprueba si hay anomalías notificadas antes de responder a la información de pertenencia mediante las pulsaciones al servidor de contenedor en cuestión. Si el servicio de catálogo ve una detección de anomalía falsa, este no realiza ninguna acción. La partición de grupo principal se recupera rápidamente. El servicio de catálogo también envía pulsaciones a líderes de grupo principal periódicamente a velocidad lenta para manejar el caso de aislamiento de grupo principal.