layout: doc—
Nota:
Aún no se admite el uso de XenCenter aaaa.x.x con Citrix Hypervisor 8.2 CU1 en entornos de producción. Para administrar el entorno de producción de Citrix Hypervisor 8.2 CU1, use XenCenter 8.2.7. Para obtener más información, consulte la documentación de XenCenter 8.2.7.
Puede instalar XenCenter 8.2.7 y XenCenter aaaa.x.x en el mismo sistema. La instalación de XenCenter aaaa.x.x no sobrescribe la instalación de XenCenter 8.2.7.
El Provisioning ligero utiliza mejor el almacenamiento disponible al asignar espacio de almacenamiento en disco a los VDI a medida que los datos se escriben en el disco vDisk, en lugar de asignar el tamaño virtual completo del VDI por adelantado. El Provisioning ligero le permite reducir significativamente la cantidad de espacio necesario en un arreglo de discos de almacenamiento compartido y, con ello, su coste total de propiedad (TCO).
El aprovisionamiento controlado para el almacenamiento en bloque compartido es de particular interés en los siguientes casos:
Nota:
Recomendamos no usar una SR de GFS2 con una VLAN debido a un problema conocido por el que no se pueden agregar ni quitar hosts en una agrupación en clústeres si la red del clúster está en una VLAN que no es de administración.
El tipo GFS2 compartido representa los discos como un sistema de archivos creado en un LUN iSCSI o HBA. Los VDI almacenados en una SR GFS2 se almacenan en el formato de imagen QCOW2.
Para ofrecer las ventajas del aprovisionamiento ligero en el almacenamiento en bloques compartidos sin riesgo de pérdida de datos, su grupo debe ofrecer un buen nivel de confiabilidad y conectividad. Es crucial que los hosts de la agrupación de recursos que usa GFS2 puedan comunicarse entre sí de manera confiable. Para garantizar esto, XenServer requiere que utilice un grupo agrupado en clústeres con su GFS2 SR. También le recomendamos que diseñe su entorno y configure las funciones de XenServer para proporcionar la mayor capacidad de recuperación y redundancia posible.
Antes de configurar el grupo de XenServer para que funcione con los SR de GFS2, revise los siguientes requisitos y recomendaciones para un entorno GFS2 ideal:
Recomendado: configure una infraestructura de red redundante.
Recomendado: Cree una red enlazada dedicada
Obligatorio: configurar un grupo agrupado
Recomendado: configurar múltiples rutas de almacenamiento
Obligatorio: crear un GFS2 SR
Un grupo agrupado con SR de GFS2 tiene algunas diferencias de comportamiento con respecto a otros tipos de grupo y SR. Para obtener más información, consulte Restricciones.
Una red enlazada conecta dos o más NIC para crear un único canal para el tráfico de la red. Le recomendamos que utilice una red enlazada para el tráfico de su grupo agrupado. Sin embargo, antes de configurar la red enlazada, asegúrese de que la configuración del hardware de la red promueva la redundancia en la red enlazada. Considere la posibilidad de implementar tantas de estas recomendaciones como sea posible para su organización y su entorno.
Las siguientes prácticas recomendadas agregan resiliencia frente a fallos de software, hardware o alimentación que pueden afectar a los conmutadores de red.
Es importante asegurarse de que los hosts de un grupo agrupado en clústeres puedan comunicarse entre sí de forma fiable. La creación de una red enlazada para el tráfico de este grupo aumenta la resiliencia del grupo agrupado.
Una red enlazada crea un vínculo entre dos o más NIC para crear un único canal de alto rendimiento que el grupo agrupado en clústeres puede utilizar para el tráfico de latidos del clúster. Recomendamos encarecidamente que esta red enlazada no se utilice para ningún otro tráfico. Cree una red independiente para que el grupo la utilice para el tráfico de administración.
Nota:
Si tiene un firewall entre los hosts de su grupo, asegúrese de que los hosts puedan comunicarse en la red del clúster mediante los siguientes puertos:
- TCP: 8892, 8896, 21064
- UDP: 5404, 5405
Para obtener más información, consulte Puertos de comunicación utilizados por XenServer.
Para crear una red enlazada para utilizarla como red de agrupamiento:
En el modo Fianza , elige el tipo de fianza:
Notas:
- Para poder ver las opciones de enlace LACP en XenCenter y crear un enlace LACP, configure vSwitch como pila de red. Además, los conmutadores deben admitir el estándar IEEE 802.3ad.
- Los tipos de enlace activo-activo y activo-pasivo están disponibles tanto para el puente vSwitch como para el puente Linux.
- Puede unir dos, tres o cuatro NIC cuando vSwitch es la pila de red. Sin embargo, solo puede unir dos NIC cuando el puente de Linux es la pila de red.
Después de crear la red enlazada en el coordinador del grupo, al unir otros hosts XenServer al grupo, la información de red y enlace se replica automáticamente en el servidor que se une.
Para obtener más información, consulte Configuración de NIC.
Notas:
- Para cambiar la dirección IP de la red de clústeres mediante XenCenter, es necesario inhabilitar temporalmente la agrupación en clústeres y GFS2.
- No cambie la vinculación de la red de clústeres mientras el clúster está activo y tiene máquinas virtuales en ejecución. Esta acción puede provocar que los hosts del clúster se reinicien por completo (valla).
- Si tiene un conflicto de direcciones IP (varios hosts que tienen la misma dirección IP) en su red de clústeres que implica al menos un host con la agrupación en clústeres habilitada, el clúster no se forma correctamente y los hosts no pueden cercarlo cuando es necesario. Para solucionar este problema, resuelva el conflicto de direcciones IP.
Para usar el almacenamiento GFS2 compartido, el grupo de recursos de XenServer debe ser un grupo agrupado en clústeres. Habilite la agrupación en clústeres en su grupo antes de crear una SR GFS2.
Para crear un grupo agrupado:
Asegúrese de que las rutas múltiples de almacenamiento estén configuradas entre su grupo en clúster y su SR GFS2.
Las rutas múltiples enrutan el tráfico de almacenamiento a un dispositivo de almacenamiento a través de múltiples rutas para lograr redundancia. Todas las rutas pueden tener tráfico activo durante el funcionamiento normal, lo que se traduce en un aumento del rendimiento.
Antes de habilitar las rutas múltiples, compruebe que se cumplen estas afirmaciones:
Su conmutador Ethernet o de fibra está configurado para que varios destinos estén disponibles en su servidor de almacenamiento.
Por ejemplo, un back-end de almacenamiento iSCSI consultado por sendtargets
en un portal determinado devuelve varios destinos, como en el siguiente ejemplo:
iscsiadm -m discovery --type sendtargets --portal 192.168.0.161
192.168.0.161:3260,1 iqn.strawberry:litchie
192.168.0.204:3260,2 iqn.strawberry:litchie
Sin embargo, puede realizar una configuración adicional para habilitar rutas múltiples iSCSI para arreglos que solo exponen un único destino. Para obtener más información, consulte Rutas múltiples iSCSI para arreglos que solo exponen un único objetivo.
Solo para iSCSI, el dominio de control (dom0) tiene una dirección IP en cada subred utilizada por el almacenamiento de rutas múltiples.
Asegúrese de que para cada ruta al almacenamiento tenga una NIC y que haya una dirección IP configurada en cada NIC. Por ejemplo, si quiere cuatro rutas a su almacenamiento, debe tener cuatro NIC que tengan una dirección IP configurada cada una.
Solo para iSCSI, cada objetivo e iniciador iSCSI tiene un IQN único.
Solo para iSCSI, los puertos de destino iSCSI funcionan en modo portal.
Solo para HBA, hay varios HBA conectados a la estructura del conmutador.
Si es posible, utilice varios conmutadores redundantes.
Para habilitar las rutas múltiples:
Complete los siguientes pasos para cada servidor de su grupo:
Asegúrese de habilitar las rutas múltiples en todos los hosts del grupo. Todas las configuraciones de cableado y, en el caso de iSCSI, de subred deben coincidir con las NIC correspondientes de cada host.
Cree su GFS2 SR compartido en un LUN iSCSI o HBA que esté visible para todos los hosts de XenServer de su agrupación de recursos. No recomendamos usar un LUN de aprovisionamiento fino con GFS2. Sin embargo, si elige esta configuración, debe asegurarse de que el LUN siempre tenga suficiente espacio para permitir que XenServer escriba en él.
Puede agregar hasta 62 SR de GFS2 a un grupo agrupado.
Nota:
Antes de realizar los siguientes pasos, asegúrese de que el IQN del iniciador iSCSI esté configurado correctamente para todos los hosts del grupo. Para obtener más información, consulte Cambiar las propiedades del servidor.
En la página Ubicación, especifique los detalles del objetivo iSCSI:
Host de destino: la dirección IP o el nombre DNS del destino iSCSI. También puede ser una lista de valores separados por comas.
Utilice CHAP: esto no es compatible con los SR de GFS2. Deje esta opción sin seleccionar.
IQN de destino: Para especificar el IQN de destino iSCSI, haga clic en el botón Discover IQN y, a continuación, elija un IQN de la lista IQN de Target.
Importante:
El destino iSCSI y todos los servidores del grupo no deben tener el mismo IQN establecido. Cada objetivo e iniciador iSCSI debe tener un IQN único. Si se utiliza un identificador IQN no único, se pueden producir daños en los datos, se puede denegar el acceso al destino o ambas cosas.
LUN de destino: Para especificar el LUN en el que crear el repositorio de almacenamiento, haga clic en el botón Descubrir LUNs. Elija un LUN de la lista de LUN de destino.
Cada repositorio de almacenamiento iSCSI individual debe estar contenido en su totalidad en un único LUN. El SR no puede abarcar más de un LUN. Si el LUN ya contiene un SR, elija utilizar el SR existente o reemplazar el SR existente por una nueva. Reemplazar el SR existente destruye todos los datos presentes en el disco.
El asistente busca los LUNs disponibles y, a continuación, muestra una página con todos los LUNs encontrados. Seleccione un LUN de la lista y haga clic en Crear.
Nota:
Se muestra un mensaje de advertencia si hay SR existentes en el LUN que ha seleccionado. Revisa los detalles y elige una de las siguientes opciones.
- Para usar el existente, haga clic en Readjuntar.
- Para eliminar el SR existente y crear un SR, haga clic en Formato.
- Si prefiere seleccionar un LUN diferente, haga clic en Cancelar y seleccione un LUN de la lista.
El almacenamiento GFS2 compartido tiene actualmente las siguientes restricciones:
Al igual que con cualquier SR de aprovisionamiento ligero, si el uso de SR de GFS2 aumenta hasta el 100%, fallan las escrituras posteriores de las VM. Estas escrituras fallidas pueden provocar fallos en la máquina virtual, posibles daños en los datos o ambas cosas.
XenCenter muestra una alerta cuando el uso de SR aumenta hasta un 80%. Asegúrese de supervisar su GFS2 SR para detectar esta alerta y tomar las medidas apropiadas si lo ve. En una GFS2 SR, el uso elevado provoca una degradación del rendimiento. Le recomendamos que mantenga su uso de SR por debajo del 80%.
La migración de máquinas virtuales con migración de almacenamiento (en vivo o sin conexión) no es compatible con las máquinas virtuales cuyas VDI están en un SR GFS2. Tampoco puede migrar VDI de otro tipo de SR a un SR GFS2.
El transporte de FCoE no es compatible con los SR GFS2.
Recortar/desasignar no se admite en los SR de GFS2.
Los SR de GFS2 no admiten CHAP.
El seguimiento de bloques modificados no es compatible con los VDI almacenados en SRs de GFS2.
No puede exportar VDI de más de 2 TiB como VHD u OVA/OVF. Sin embargo, puede exportar máquinas virtuales con VDI de más de 2 TiB en formato XVA.
No recomendamos usar un LUN de aprovisionamiento fino con GFS2. Sin embargo, si elige esta configuración, debe asegurarse de que el LUN siempre tenga suficiente espacio para permitir que XenServer escriba en él.
No puede tener más de 62 SR GFS2 en su agrupación.
Los grupos agrupados solo admiten hasta 16 hosts por grupo.
Para el tráfico de clústeres, le recomendamos encarecidamente que utilice una red enlazada que utilice al menos dos conmutadores de red diferentes. No utilice esta red para ningún otro propósito.
Para cambiar la dirección IP de la red de clústeres mediante XenCenter, es necesario inhabilitar temporalmente la agrupación en clústeres y GFS2.
No cambie la vinculación de la red de clústeres mientras el clúster está activo y tiene máquinas virtuales en ejecución. Esta acción puede provocar que los hosts del clúster se reinicien por completo (valla).
Si tiene un conflicto de direcciones IP (varios hosts que tienen la misma dirección IP) en su red de clústeres que implica al menos un host con la agrupación en clústeres habilitada, el clúster no se forma correctamente y los hosts no pueden cercarlo cuando es necesario. Para solucionar este problema, resuelva el conflicto de direcciones IP.