Utilice el archivo XML de descriptor de política de despliegue y el archivo XML de descriptor ObjectGrid para gestionar la topología.
La información de punto final no está preconfigurada en el entorno dinámico. En la política de despliegue no hay ningún nombre de servidor ni información de topología física. El servicio de catálogo coloca automáticamente todos los fragmentos de una cuadrícula de datos en servidores de contenedor. El servicio de catálogo utiliza las restricciones definidas por la política de despliegue para gestionar automáticamente la colocación de fragmentos. Esta colocación automática de fragmentos permite una fácil configuración para cuadrículas de datos grandes. También puede añadir servidores al entorno según sea necesario.
Se pasa un archivo XML de política de despliegue al servidor de contenedor durante el inicio. Se debe utilizar una política de despliegue junto con un archivo XML de ObjectGrid. La política de despliegue no es necesaria para iniciar un servidor de contenedor, aunque se recomienda. La política de despliegue debe ser compatible con el archivo XML de ObjectGrid que se utiliza con ella. Para cada elemento objectgridDeployment de la política de despliegue, debe incluir un elemento objectGrid correspondiente en el archivo XML de ObjectGrid. Las correlaciones en objectgridDeployment deben ser coherentes con los elementos backingMap encontrados en el XML de ObjectGrid. Se debe hacer referencia a cada backingMap dentro de un solo un elemento mapSet.
companyGridDpReplication.xml
<?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="CompanyGrid">
<mapSet name="mapSet1" numberOfPartitions="11"
minSyncReplicas="1" maxSyncReplicas="1"
maxAsyncReplicas="0" numInitialContainers="4">
<map ref="Customer" />
<map ref="Item" />
<map ref="OrderLine" />
<map ref="Order" />
</mapSet>
</objectgridDeployment>
</deploymentPolicy>
companyGrid.xml
<?xml version="1.0" encoding="UTF-8"?>
<objectGridConfig xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://ibm.com/ws/objectgrid/config ../objectGrid.xsd"
xmlns="http://ibm.com/ws/objectgrid/config">
<objectGrids>
<objectGrid name="CompanyGrid">
<backingMap name="Customer" />
<backingMap name="Item" />
<backingMap name="OrderLine" />
<backingMap name="Order" />
</objectGrid>
</objectGrids>
</objectGridConfig>
El archivo companyGridDpReplication.xml tiene un elemento mapSet dividido en 11 particiones. Cada partición debe tener, exactamente, una réplica síncrona. El número de réplicas síncronas viene especificado por los atributos minSyncReplicas y maxSyncReplicas. Puesto que el atributo minSyncReplicas está establecido en 1, cada partición del elemento mapSet debe tener, como mínimo, una réplica síncrona disponible para procesar transacciones de escritura. Dado que el atributo maxSyncReplicas se establece en 1, cada partición no puede sobrepasar de una réplica síncrona. Las particiones de este elemento mapSet no tiene réplicas asíncronas.
El atributo numInitialContainers indica al servicio de catálogo que difiera la colocación hasta que estén disponibles cuatro servidores de contenedor para soportar esta instancia de ObjectGrid. El atributo numInitialContainers se ignora después que se haya alcanzado el número especificado de servidores de contenedor.
También puede utilizar la propiedad placementDeferralInterval y el mandato xscmd -c suspendBalancing para retardar la colocación de fragmentos en los servidores de contenedor.
Aunque el archivo companyGridDpReplication.xml es un ejemplo básico, una política de despliegue le puede ofrecer control total sobre el entorno.
WebSphere eXtreme Scale equilibra automáticamente los servidores. Puede incluir servidores adicionales sin reiniciar WebSphere eXtreme Scale. La adición de servidores adicionales sin tener que reiniciar eXtreme Scale le permite tener despliegues sencillos y, también, despliegues grandes de terabytes en los que son necesarios cientos de servidores.
Esta topología de despliegue es flexible. Mediante el servicio de catálogo, puede añadir y eliminar servidores para utilizar mejor los recursos sin eliminar toda la memoria caché. Puede utilizar los mandatos startOgServer y stopOgServer para iniciar y detener los servidores de contenedor. Estos dos parámetros requieren que especifique la opción -catalogServiceEndPoints. Todos los clientes de la topología distribuida se comunican con el servicio de catálogo a través del protocolo IIOP (Internet Interoperability Object Protocol). Todos los clientes utilizan la interfaz de ObjectGrid para comunicarse con los servidores.
La prestación de la configuración dinámica de WebSphere eXtreme Scale facilita la adición de recursos al sistema. Los contenedores alojan los datos y el servicio de catálogo permite a los clientes comunicarse con la cuadrícula de servidores de contenedor. El servicio de catálogo reenvía las solicitudes, asigna espacio en los servidores de contenedor de host y gestiona el estado y la disponibilidad del sistema en general. Los clientes se conectan a un servicio de catálogo, recuperan una descripción de la topología de servidor de contenedor y, a continuación, se comunican directamente con cada servidor según sea necesario. Cuando la topología del servidor cambia debido a la adición de nuevos servidores, o debido a la anomalía de otros, el servicio de catálogo direcciona automáticamente las solicitudes del cliente al servidor apropiado que aloja los datos.
Normalmente, un servicio de catálogo existe en su propia cuadrícula de Máquinas virtuales Java. Un solo servidor de catálogo puede gestionar varios servidores. Puede iniciar un servidor de contenedor en una JVM solo o cargar el servidor de contenedor en una JVM arbitraria con otros servidores de contenedor para distintos servidores. Un cliente puede existir en cualquier JVM y comunicarse con uno o más servidores. Un cliente también puede existir en la misma JVM que un servidor de contenedor.
También puede crear una política de despliegue mediante el programa al incorporar un servidor de contenedor en una aplicación o un proceso Java existente. Para obtener más información, consulte la documentación de la API DeploymentPolicy.