Formatos de repositorio de almacenamiento

Puede utilizar el Asistente para nuevo repositorio de almacenamiento de XenCenter para crear repositorios de almacenamiento. El asistente le guía a través de los pasos de configuración. Alternativamente, utilice la CLI y el comando sr-create. El comando sr-create crea un SR en el sustrato de almacenamiento (potencialmente destruyendo cualquier dato existente). También crea el objeto API SR y un registro PBD correspondiente, lo que permite a las VM utilizar el almacenamiento. Al crear correctamente el SR, el PBD se enchufa automáticamente. Si se establece el shared=true indicador SR, se crea un registro PBD y se conecta para cada Citrix Hypervisor del grupo de recursos.

Si está creando un SR para almacenamiento basado en IP (iSCSI o NFS), puede configurar una de las siguientes opciones como red de almacenamiento: La NIC que administra el tráfico de administración o una NIC nueva para el tráfico de almacenamiento. Para asignar una dirección IP a una NIC, consulte Configurar una NIC de almacenamiento dedicado.

Todos los tipos de Citrix Hypervisor SR admiten el cambio de tamaño de VDI, la clonación rápida y la instantánea. SRs basados en el tipo LVM SR (local, iSCSI o HBA) proporcionan Provisioning ligero para instantáneas y nodos principales ocultos. Los otros tipos de SR (EXT3, NFS, GFS2) admiten Provisioning ligero completo, incluso para discos vDisk activos.

Advertencias:

• Cuando los VHD VDI no están conectados a una máquina virtual, por ejemplo, para una instantánea de VDI, se almacenan como aprovisionamiento fino de forma predeterminada. Si intenta volver a conectar el VDI, asegúrese de que hay suficiente espacio en disco disponible para que el VDI se aprovisione de forma gruesa. Los clones de VDI se aprovisionan con gran densidad.

• Citrix Hypervisor no admite instantáneas externas a nivel de SAN de un LUN para ningún tipo de SR.

Los tamaños de VDI máximos admitidos son:

LVM local

El tipo LVM local presenta discos dentro de un grupo de volúmenes conectado localmente.

De forma predeterminada, Citrix Hypervisor utiliza el disco local en el host físico en el que está instalado. El Administrador de volúmenes lógicos de Linux (LVM) se utiliza para administrar el almacenamiento de VM. Un VDI se implementa en formato VHD en un volumen lógico LVM del tamaño especificado.

Consideraciones de performance de LVM

La funcionalidad de instantánea y clonación rápida para SRs basados en LVM viene con una sobrecarga de rendimiento inherente. Cuando se requiere un rendimiento óptimo, Citrix Hypervisor admite la creación de VDI en formato raw además del formato VHD predeterminado. La funcionalidad de instantáneas de Citrix Hypervisor no se admite en los VDI sin procesar.

Advertencia:

no intente realizar copias instantáneas de una máquina virtual que tengatype=raw discos conectados. Esta acción puede provocar la creación de una instantánea parcial. En esta situación, puede identificar los VDI de instantáneas huérfanas mediante la comprobación delsnapshot-of campo y, a continuación, eliminarlos.

Creación de una SR LVM local

Una SR LVM se crea de forma predeterminada en la instalación del host.

Los parámetros de Device-config para LVM SRs son:

Para crear una SR LVM local en /dev/sdb, utilice el siguiente comando.

    xe sr-create host-uuid=valid_uuid content-type=user \
    name-label="Example Local LVM SR" shared=false \
    device-config:device=/dev/sdb type=lvm

EXT3 local

El uso de EXT3 permite el Provisioning ligero en almacenamiento local. Sin embargo, el tipo de repositorio de almacenamiento predeterminado es LVM, ya que proporciona un rendimiento de escritura consistente y evita la sobreconfirmación del almacenamiento. Si utiliza EXT3, es posible que vea un rendimiento reducido en los siguientes casos:

• Al llevar a cabo operaciones de ciclo de vida de VM, como creación y suspensión/reanudación de VM
• Al crear archivos grandes desde dentro de la VM

Los SRs de EXT de disco local deben configurarse mediante la CLI de Citrix Hypervisor.

Creación de un SR EXT3 local (ext)

Parámetros de Device-config para SRs ext:

Para crear un local ext SR en /dev/sdb, utilice el siguiente comando:

    xe sr-create host-uuid=valid_uuid content-type=user \
       name-label="Example Local EXT3 SR" shared=false \
       device-config:device=/dev/sdb type=ext

udev

Eludev tipo representa los dispositivos conectados mediante el administrador deudev dispositivos como VDI.

Citrix Hypervisor tiene dos SRs de tipoudev que representan almacenamiento extraíble. Uno es para el disco CD o DVD de la unidad física de CD o DVD-ROM del servidor Citrix Hypervisor. El otro es para un dispositivo USB conectado a un puerto USB del servidor Citrix Hypervisor. Los VDI que representan los medios van y vienen a medida que se insertan y eliminan discos o memorias USB.

ISO

El tipo ISO maneja las imágenes de CD almacenadas como archivos en formato ISO. Este tipo SR es útil para crear bibliotecas ISO compartidas. Para los repositorios de almacenamiento que almacenan una biblioteca de ISOs, el content-type parámetro debe establecerse en iso.

Por ejemplo:

    xe sr-create host-uuid=valid_uuid content-type=iso \
      type=iso name-label="Example ISO SR" \
      device-config:location=nfs server:path

Recomendamos que utilice SMB versión 3.0 para montar ISO SR en el servidor de archivos de Windows. La versión 3.0 está seleccionada de forma predeterminada porque es más segura y robusta que la versión 1.0 de SMB. Sin embargo, puede montar ISO SR mediante SMB versión 1.0 con el siguiente comando:

     xe sr-create content-type=iso type=iso shared=true device-config:location=valid location
     device-config:username=username device-config:cifspassword=password
     device-config:type=cifs device-config:vers=Choose either 1.0 or 3.0 name-label="Example ISO SR"

Nota:

Al ejecutar el comando sr-create, puede usar el argumento device-config:cifspassword_secret en lugar de especificar la contraseña en la línea de comandos. Para obtener más información, consulte Secretos.

Compatibilidad con iSCSI de software

Citrix Hypervisor admite SRs compartidos en LUNs iSCSI. iSCSI se admite mediante el iniciador iSCSI del software Open-iSCSI o mediante un adaptador de bus host (HBA) iSCSI compatible. Los pasos para usar HBAs iSCSI son idénticos a los pasos para HBAs Fibre Channel. Ambos conjuntos de pasos se describen en Crear un LVM compartido a través de Fibre Channel/Fibre Channel over Ethernet/iSCSI HBA o SAS SR.

El soporte iSCSI compartido mediante el iniciador iSCSI de software se implementa basado en Linux Volume Manager (LVM). Esta función proporciona las mismas ventajas de rendimiento que ofrecen los VDI LVM en el caso del disco local. Los SRs iSCSI compartidos que utilizan el iniciador de host basado en software pueden admitir la agilidad de VM mediante la migración en vivo: Las máquinas virtuales se pueden iniciar en cualquier servidor Citrix Hypervisor en un grupo de recursos y migrar entre ellas sin un tiempo de inactividad notable.

Los SRs iSCSI utilizan todo el LUN especificado en el momento de la creación y no pueden abarcar más de un LUN. Se proporciona compatibilidad con CHAP para la autenticación del cliente, tanto durante la inicialización del path de datos como en las fases de descubrimiento de LUN.

Nota:

El tamaño de bloque de un LUN iSCSI debe ser de 512 bytes.

Configuración iSCSI del servidor Citrix Hypervisor

Todos los iniciadores y destinos iSCSI deben tener un nombre único para garantizar que se puedan identificar de forma única en la red. Un iniciador tiene una dirección de iniciador iSCSI y un destino tiene una dirección de destino iSCSI. En conjunto, estos nombres se denominan nombres calificados iSCSI o IQN.

Los servidores Citrix Hypervisor admiten un único iniciador iSCSI que se crea y configura automáticamente con un IQN aleatorio durante la instalación del host. El iniciador único se puede utilizar para conectarse simultáneamente a varios destinos iSCSI.

Los destinos iSCSI suelen proporcionar control de acceso mediante listas IQN del iniciador iSCSI. Todos los destinos iSCSI o LUNs a los que accede el servidor Citrix Hypervisor deben configurarse para permitir el acceso por parte del IQN del iniciador del host. Del mismo modo, los objetivos/LUNs que se utilizarán como SRs iSCSI compartidos deben configurarse para permitir el acceso de todos los IQN de host en la agrupación de recursos.

Nota:

Los destinos iSCSI que no proporcionan control de acceso suelen ser predeterminados para restringir el acceso de LUN a un solo iniciador para garantizar la integridad de los datos. Si se utiliza un LUN iSCSI como SR compartido en varios servidores de un grupo, asegúrese de que el acceso de varios iniciadores esté habilitado para el LUN especificado.

El valor IQN del servidor Citrix Hypervisor se puede ajustar mediante XenCenter o mediante la CLI con el siguiente comando cuando se utiliza el iniciador de software iSCSI:

    xe host-param-set uuid=valid_host_id other-config:iscsi_iqn=new_initiator_iqn

Advertencia:

• 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 o denegación de acceso a LUN.
• No cambie el IQN del servidor Citrix Hypervisor con SRs iSCSI conectados. Si lo hace, se pueden producir fallos en la conexión a nuevos destinos o SRs existentes.

Almacenamiento de software FCoE

Software FCoE proporciona un marco estándar al que los proveedores de hardware pueden conectar su NIC compatible con FCoE y obtener los mismos beneficios de un FCoE basado en hardware. Esta función elimina la necesidad de utilizar costosos HBA.

Antes de crear un almacenamiento FCoE de software, complete manualmente la configuración necesaria para exponer un LUN al host. Esta configuración incluye la configuración de la estructura FCoE y la asignación de LUNs al nombre público mundial (PWWN) de su SAN. Después de completar esta configuración, el LUN disponible se monta en el CNA del host como un dispositivo SCSI. El dispositivo SCSI se puede utilizar para acceder al LUN como si se tratara de un dispositivo SCSI conectado localmente. Para obtener información acerca de cómo configurar el conmutador físico y el arreglo de discos para admitir FCoE, consulte la documentación proporcionada por el proveedor.

Nota:

El software FCoE se puede utilizar con Open vSwitch y el puente Linux como back-end de red.

Crear un software FCoE SR

Antes de crear un software FCoE SR, los clientes deben asegurarse de que existen NIC compatibles con FCOE conectadas al host.

Los parámetros de Device-config para los SRs de FCoE son:

Ejecute el siguiente comando para crear una SR FCoE compartida:

    xe sr-create type=lvmofcoe \
    name-label="FCoE SR" shared=true device-config:SCSIid=SCSI_id

Adaptadores de bus de host (HBAs) de hardware

Esta sección cubre varias operaciones necesarias para administrar HBAs SAS, Fibre Channel e iSCSI.

Ejemplo de configuración del HBA iSCSI de QLogic

Para obtener más información sobre la configuración de HBAs iSCSI y Fibre Channel QLogic, consulte el Cavium sitio web.

Una vez que el HBA esté instalado físicamente en el servidor Citrix Hypervisor, siga los pasos siguientes para configurar el HBA:

1. Establezca la configuración de red IP para el HBA. En este ejemplo se asume el puerto 0 de DHCP y HBA. Especifique los valores apropiados si se utiliza el direccionamiento IP estático o un HBA multipuerto.

   /opt/QLogic_Corporation/SANsurferiCLI/iscli -ipdhcp 0
   

2. Agregue un destino iSCSI persistente al puerto 0 del HBA.

   /opt/QLogic_Corporation/SANsurferiCLI/iscli -pa 0 iscsi_target_ip_address
   

3. Ejecute el comando xe sr-probe para forzar un nuevo análisis del Controller HBA y mostrar los LUNs disponibles. Para obtener más información, consulte Sondear un SR y Crear un LVM compartido a través de Fibre Channel/Fibre Channel over Ethernet/iSCSI HBA o SAS SR.

Eliminar entradas de dispositivos SAS, FC o iSCSI basadas en HBA

Nota:

Este paso no es obligatorio. Recomendamos que solo los usuarios avanzados realicen este proceso si es necesario.

Cada LUN basado en HBA tiene una entrada de path de dispositivo global correspondiente/dev/disk/by-scsibus en el formato<SCSIid>-<adapter>:<bus>:<target>:<lun> y una ruta de dispositivo estándar en /dev. Para quitar las entradas de dispositivo para los LUNs que ya no se utilizan como SRs, siga los pasos siguientes:

1. Utilicesr-forget osr-destroy, según corresponda, para quitar el SR de la base de datos del servidor Citrix Hypervisor. Para obtener más detalles, consulte Eliminar SRs.

2. Elimine la configuración de zoning dentro de la SAN para el LUN deseado en el host deseado.

3. Ejecute el comando sr-probe para determinar los valores ADAPTER, BUS, TARGET y LUN correspondientes al LUN que se va a quitar. Para obtener más información, Sondear un SR.

4. Elimine las entradas del dispositivo con el siguiente comando:

   echo "1" > /sys/class/scsi_device/adapter:bus:target:lun/device/delete
   

Advertencia:

Asegúrese de que está seguro de qué LUN está quitando. La eliminación accidental de un LUN necesario para el funcionamiento del host, como el dispositivo de arranque o raíz, hace que el host no pueda utilizarse.

Almacenamiento LVM compartido

El tipo LVM compartido representa los discos como volúmenes lógicos dentro de un grupo de volúmenes creado en un LUN iSCSI (FC o SAS).

Nota:

El tamaño de bloque de un LUN iSCSI debe ser de 512 bytes.

Crear un LVM compartido a través de iSCSI SR mediante el iniciador iSCSI de software

Parámetros de Device-config para SRs LVMOiSCSI:

Para crear un SR LVMOiSCSI compartido en un LUN específico de un destino iSCSI, utilice el siguiente comando.

    xe sr-create host-uuid=valid_uuid content-type=user \
    name-label="Example shared LVM over iSCSI SR" shared=true \
    device-config:target=target_ip= device-config:targetIQN=target_iqn= \
    device-config:SCSIid=scsci_id \
    type=lvmoiscsi

Crear un LVM compartido a través de Fibre Channel/Fibre Channel over Ethernet/iSCSI HBA o SAS SR

SRs de tipo LVMOHBA se pueden crear y administrar mediante XE CLI o XenCenter.

Parámetros de Device-config para SRs LVMohBA:

Para crear una SR LVMohBA compartida, lleve a cabo los siguientes pasos en cada host del grupo:

1. Zona en uno o más LUNs a cada servidor Citrix Hypervisor del grupo. Este proceso es altamente específico para el equipo SAN en uso. Para obtener más información, consulte la documentación de su SAN.

2. Si es necesario, utilice la CLI de HBA incluida en el servidor Citrix Hypervisor para configurar el HBA:

   • Emulex:/bin/sbin/ocmanager

   • FC de QLogic:/opt/QLogic_Corporation/SANsurferCLI

   • iSCSI QLogic:/opt/QLogic_Corporation/SANsurferiCLI

   Para obtener un ejemplo de configuración de HBA iSCSI QLogic, consulte Hardware host bus adapters (HBAs) en la sección anterior. Para obtener más información sobre los HBAs iSCSI y Fibre Channel, consulte losBroadcom sitios webCaviumy.

3. Utilice el comando sr-probe para determinar la ruta de acceso del dispositivo global del LUN de HBA. El comando sr-probe obliga a volver a analizar los HBAs instalados en el sistema para detectar los nuevos LUNs que se han zonado en el host. El comando devuelve una lista de propiedades para cada LUN encontrado. Especifique el parámetro host-uuid para asegurarse de que el sondeo se produce en el host deseado.

   La ruta global del dispositivo que se devuelve como propiedad <path> es común en todos los hosts del grupo. Por lo tanto, esta ruta debe utilizarse como valor para el parámetro device-config:device al crear el SR.

   Si hay varios LUN presentes, utilice el proveedor, el tamaño del LUN, el número de serie del LUN o el ID SCSI de la propiedad <path> para identificar el LUN deseado.

       xe sr-probe type=lvmohba \
       host-uuid=1212c7b3-f333-4a8d-a6fb-80c5b79b5b31
       Error code: SR_BACKEND_FAILURE_90
       Error parameters: , The request is missing the device parameter, \
       <?xml version="1.0" ?>
       <Devlist>
           <BlockDevice>
               <path>
                   /dev/disk/by-id/scsi-360a9800068666949673446387665336f
               </path>
               <vendor>
                   HITACHI
               </vendor>
               <serial>
                   730157980002
               </serial>
               <size>
                   80530636800
               </size>
               <adapter>
                   4
               </adapter>
               <channel>
                   0
               </channel>
               <id>
                   4
               </id>
               <lun>
                   2
               </lun>
               <hba>
                   qla2xxx
               </hba>
           </BlockDevice>
           <Adapter>
               <host>
                   Host4
               </host>
               <name>
                   qla2xxx
               </name>
               <manufacturer>
                   QLogic HBA Driver
               </manufacturer>
               <id>
                   4
               </id>
           </Adapter>
       </Devlist>
   

4. En el host principal del grupo, cree el SR. Especifique la ruta de acceso global del dispositivo devuelta en la <path> propiedad desr-probe. Los PBD se crean y conectan automáticamente para cada host del grupo.

       xe sr-create host-uuid=valid_uuid \
       content-type=user \
       name-label="Example shared LVM over HBA SR" shared=true \
       device-config:SCSIid=device_scsi_id type=lvmohba
   

Nota:

Puede utilizar la función Repair Storage Repair XenCenter para volver a intentar la creación de PBD y la conexión de partes de la sr-create operación. Esta función puede ser valiosa en los casos en que la zonificación de LUN era incorrecta para uno o más hosts de un grupo cuando se creó el SR. Corrija la zonificación de los hosts afectados y utilice la función Reparar repositorio de almacenamiento en lugar de quitar y volver a crear el SR.

Almacenamiento de bloques GFS2 compartido de aprovisionamiento ligero

El aprovisionamiento 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 virtual, en lugar de asignar el tamaño virtual completo del VDI por adelantado. El aprovisionamiento ligero le permite reducir significativamente la cantidad de espacio necesario en un arreglo de discos de almacenamiento compartido y, con ello, su costo total de propiedad (TCO).

El aprovisionamiento ligero para almacenamiento de información en bloque compartido es de particular interés en los siguientes casos:

• Desea una mayor eficiencia del espacio. Las imágenes están escasamente asignadas y no densamente.
• Desea reducir el número de operaciones de E/S por segundo en su arreglo de discos de almacenamiento. El GFS2 SR es el primer tipo SR que admite almacenamiento en caché de lectura en almacenamiento en bloque compartido.
• Utilice una imagen base común para varias máquinas virtuales. Por lo general, las imágenes de máquinas virtuales individuales utilizarán aún menos espacio.
• Utiliza instantáneas. Cada instantánea es una imagen y cada imagen ahora es escasa.
• El almacenamiento no admite NFS y solo admite almacenamiento en bloque. Si su almacenamiento admite NFS, le recomendamos que utilice NFS en lugar de GFS2.
• Desea crear VDI con un tamaño superior a 2 TiB. El GFS2 SR admite VDI de hasta 16 TiB de tamaño.

El tipo GFS2 compartido representa los discos como un sistema de archivos creado en un LUN iSCSI o HBA. Los VDI almacenados en un GFS2 SR se almacenan en el formato de imagen QCOW2.

Para utilizar el almacenamiento compartido de GFS2, el grupo de recursos de Citrix Hypervisor debe ser un grupo agrupado. Habilite la agrupación en clústeres en su grupo antes de crear una SR de GFS2. Para obtener más información, consulte Grupos agrupados.

Asegúrese de que las rutas múltiples de almacenamiento estén configuradas entre el grupo agrupado y el SR de GFS2. Para obtener más información, consulte Múltiples rutas para el almacenamiento.

Los SRs de tipo GFS2 se pueden crear y administrar mediante la CLI xe o XenCenter.

Limitaciones

El almacenamiento compartido de GFS2 actualmente tiene las siguientes restricciones:

• La migración de VM con migración en vivo de almacenamiento no es compatible con las VM cuyos VDI están en un SR de GFS2.
• El protocolo FCoE no es compatible con los SRs GFS2.
• Recortar/unmap no es compatible con los SRs de GFS2.
• Las métricas de rendimiento no están disponibles para los SRs y discos GFS2 en estos SRs.
• El seguimiento de bloques modificado no es compatible con los VDI almacenados en SRs de GFS2.
• No puede exportar VDI mayores de 2 TiB como VHD u OVA/OVF. Sin embargo, puede exportar máquinas virtuales con VDI mayores de 2 TiB en formato XVA.

Nota:

Las operaciones en SRs de GFS2 pueden bloquearse si tiene un conflicto de direcciones IP (varios hosts que tienen la misma dirección IP) en su red de clústeres que involucre al menos un host con clústeres habilitados. En este caso, los anfitriones no vallas. Para solucionar este problema, resuelva el conflicto de direcciones IP.

Crear un GFS2 compartido a través de iSCSI SR mediante el iniciador iSCSI de software

Puede crear GFS2 a través de SRs iSCSI mediante XenCenter. Para obtener más información, consulte Almacenamiento iSCSI de software en la documentación del producto XenCenter.

Alternativamente, puede usar la CLI xe para crear un GFS2 sobre SR iSCSI.

Parámetros de Device-config para SRs de GFS2:

Puede encontrar los valores que se van a utilizar para estos parámetros mediante elxe sr-probe-ext comando.

xe sr-probe-ext type=<type> host-uuid=<host_uuid> device-config:=<config> sm-config:=<sm_config>

1. Comience ejecutando el siguiente comando:

   xe sr-probe-ext type=gfs2 device-config:provider=iscsi
   

   La salida del comando le pide que proporcione parámetros adicionales y proporciona una lista de valores posibles en cada paso.

2. Repita el comando, agregando nuevos parámetros cada vez.

3. Cuando la salida del comando comienza por The following SRs were found:, puede utilizar los parámetros device-config especificados para localizar el SR al ejecutar el comando xe sr-create.

Para crear una SR GFS2 compartida en un LUN específico de un destino iSCSI, ejecute el siguiente comando en un servidor del grupo agrupado en clústeres:

xe sr-create type=gfs2 name-label="Example GFS2 SR" --shared \
   device-config:provider=iscsi device-config:targetIQN=target_iqns \
   device-config:target=portal_address device-config:SCSIid=scsci_id

Si no se puede alcanzar el destino iSCSI mientras se montan los filesystems GFS2, es posible que algunos hosts del grupo agrupado en clústeres se bloqueen.

Para obtener más información sobre cómo trabajar con SRs iSCSI, consulteCompatibilidad con iSCSI de software.

Crear un GFS2 compartido sobre SR de HBA

Puede crear GFS2 a través de SRs de HBA mediante XenCenter. Para obtener más información, consulte Almacenamiento de hardware HBA en la documentación del producto XenCenter.

Alternativamente, puede usar la CLI xe para crear un GFS2 sobre HBA SR.

Parámetros de Device-config para SRs de GFS2:

Puede encontrar los valores que se van a utilizar para el parámetro SCSIID mediante elxe sr-probe-ext comando.

xe sr-probe-ext type=<type> host-uuid=<host_uuid> device-config:=<config> sm-config:=<sm_config>

1. Comience ejecutando el siguiente comando:

   xe sr-probe-ext type=gfs2 device-config:provider=hba
   

   La salida del comando le pide que proporcione parámetros adicionales y proporciona una lista de valores posibles en cada paso.

2. Repita el comando, agregando nuevos parámetros cada vez.

3. Cuando la salida del comando comienza por The following SRs were found:, puede utilizar los parámetros device-config especificados para localizar el SR al ejecutar el comando xe sr-create.

Para crear una SR de GFS2 compartida en un LUN específico de un destino de HBA, ejecute el siguiente comando en un servidor del grupo de clústeres:

xe sr-create type=gfs2 name-label="Example GFS2 SR" --shared \
  device-config:provider=hba device-config:SCSIid=device_scsi_id

Para obtener más información sobre cómo trabajar con SRs de HBA, consulteAdaptadores de bus host de hardware.

NFS y SMB

Los recursos compartidos en servidores NFS (que admiten NFSv4 o NFSv3) o en servidores SMB (que admiten SMB 3.0) se pueden usar inmediatamente como SR para discos vDisk. Los VDI se almacenan únicamente en el formato VHD de Microsoft. Además, dado que estos SRs se pueden compartir, los VDI almacenados en SRs compartidos permiten:

• Máquinas virtuales que se iniciarán en cualquier servidor Citrix Hypervisor en un grupo de recursos

• Migración de VM entre servidores Citrix Hypervisor en un grupo de recursos mediante migración en vivo (sin tiempo de inactividad notable)

Importante:

• La compatibilidad con SMB 3.0 está limitada a la capacidad de conectarse a un recurso compartido mediante el protocolo 3.0. Las funciones adicionales, como la conmutación por error transparente, dependen de la disponibilidad de las funciones en el núcleo de Linux ascendente y no son compatibles con Citrix Hypervisor 8.2.
• Para NFSv4, soloAUTH_SYS se admite el tipo de autenticación.
• El almacenamiento de pequeñas y medianas empresas está disponible para los clientes de Citrix Hypervisor Premium Edition o aquellos clientes que tengan acceso a Citrix Hypervisor a través de su derecho de Citrix Virtual Apps and Desktops.

Los VDI almacenados en SRs basados en archivos se aprovisionan de forma delgada. El archivo de imagen se asigna a medida que la máquina virtual escribe datos en el disco. Este enfoque tiene el beneficio considerable de que los archivos de imagen de VM ocupan solo tanto espacio en el almacenamiento como sea necesario. Por ejemplo, si se asigna un VDI de 100 GB para una máquina virtual y se instala un sistema operativo, el archivo VDI solo refleja el tamaño de los datos del sistema operativo escritos en el disco en lugar de los 100 GB completos.

Los archivos VHD también pueden estar encadenados, lo que permite que dos VDI compartan datos comunes. En los casos en que se clona una VM basada en archivos, las VM resultantes comparten los datos comunes en disco en el momento de la clonación. Cada VM procede a realizar sus propios cambios en una versión aislada de copia en escritura del VDI. Esta función permite clonar rápidamente las máquinas virtuales basadas en archivos a partir de plantillas, lo que facilita el Provisioning y la implementación muy rápidos de nuevas máquinas virtuales.

Nota:

La longitud máxima admitida de las cadenas VHD es 30.

Las implementaciones de SRs y VHD basadas en archivos en Citrix Hypervisor suponen que tienen control total sobre el directorio SR en el servidor de archivos. Los administradores no deben modificar el contenido del directorio SR, ya que esta acción puede corromper el contenido de los VDI.

Citrix Hypervisor se ha ajustado para el almacenamiento de clase empresarial que utiliza RAM no volátil para proporcionar reconocimiento rápido de solicitudes de escritura mientras mantiene un alto grado de protección de datos frente a fallas. Citrix Hypervisor se ha probado exhaustivamente contra el almacenamiento FAS2020 y FAS3210 de Network Appliance mediante Data OnTap 7.3 y 8.1

Advertencia:

Dado que los VDI en SRs basados en archivos se crean como aprovisionamiento ligero, los administradores deben asegurarse de que los SRs basados en archivos tengan suficiente espacio en disco para todos los VDI necesarios. Los servidores Citrix Hypervisor no exigen que el espacio necesario para los VDI en SRs basados en archivos esté presente.

Crear una SR NFS (NFS) compartida

Para crear una SR NFS, debe proporcionar el nombre de host o la dirección IP del servidor NFS. Puede crear el SR en cualquier ruta de destino válida; ejecute el comando sr-probe para mostrar una lista de rutas de destino válidas exportadas por el servidor.

En casos en los que Citrix Hypervisor se utiliza con almacenamiento de gama baja, espera con cautela a que se reconozcan todas las escrituras antes de pasar las confirmaciones a las VM. Este enfoque incurre en un coste de rendimiento notable y podría resolverse configurando el almacenamiento para que presente el punto de montaje SR como una exportación de modo asíncrono. Las exportaciones asincrónicas reconocen escrituras que no están realmente en el disco. Considere cuidadosamente los riesgos de falla en estas situaciones.

Nota:

El servidor NFS debe estar configurado para exportar la ruta especificada a todos los servidores del grupo. Si no se realiza esta configuración, se produce un error en la creación del SR y la conexión del registro PBD.

La implementación de Citrix Hypervisor NFS utiliza TCP de forma predeterminada. Si su situación lo permite, puede configurar la implementación para usar UDP en casos donde puede haber un beneficio de rendimiento. Para realizar esta configuración, al crear un SR, especifique el device-config parámetrouseUDP=true.

Parámetros de Device-config para SRs NFS:

Por ejemplo, para crear una SR NFS compartida en 192.168.1.10:/export1, utilice el siguiente comando:

    xe sr-create content-type=user \
    name-label="shared NFS SR" shared=true \
    device-config:server=192.168.1.10 device-config:serverpath=/export1 type=nfs \
    nfsversion="3", "4"

Para crear una SR NFS no compartida, ejecute el siguiente comando:

    xe sr-create host-uuid=host_uuid content-type=user \
    name-label="Non-shared NFS SR" \
    device-config:server=192.168.1.10 device-config:serverpath=/export1 type=nfs \
    nfsversion="3", "4"

Crear una SR SMB compartida (SMB)

Para crear una SR SMB, proporcione el nombre de host o la dirección IP del servidor SMB, la ruta de acceso completa del recurso compartido exportado y las credenciales apropiadas.

Nota:

SMB SR se ha probado con el almacenamiento de Network Appliance que ejecuta OnTap 8.3 y Windows Server 2012 R2.

Parámetros de Device-config para SRs SMB:

Por ejemplo, para crear una SR SMB compartida en 192.168.1.10:/share1, utilice el siguiente comando:

    xe sr-create content-type=user \
    name-label="Example shared SMB SR" shared=true \
    device-config:server=//192.168.1.10/share1 \
    device-config:username=valid_username device-config:password=valid_password type=smb

Para crear un SR SMB no compartido, ejecute el siguiente comando:

    xe sr-create host-uuid=host_uuid content-type=user \
    name-label="Non-shared SMB SR" \
    device-config:server=//192.168.1.10/share1 \
    device-config:username=valid_username device-config:password=valid_password type=smb

Nota:

Al ejecutar el comando sr-create, puede usar el argumento device-config:password_secret en lugar de especificar la contraseña en la línea de comandos. Para obtener más información, consulte Secretos.

HBA de LVM sobre hardware

El tipo de HBA LVM sobre hardware representa discos como VHDs en volúmenes lógicos dentro de un grupo de volúmenes creado en un LUN de HBA que proporciona, por ejemplo, soporte iSCSI o FC basado en hardware.

Los servidores Citrix Hypervisor admiten SAN Fibre Channel a través de los adaptadores de bus host (HBAs) Emulex o QLogic. Toda la configuración Fibre Channel necesaria para exponer un LUN Fibre Channel al host debe completarse manualmente. Esta configuración incluye dispositivos de almacenamiento, dispositivos de red y el HBA dentro del servidor Citrix Hypervisor. Una vez completada toda la configuración del FC, el HBA expone al host un dispositivo SCSI respaldado por el FC LUN. El dispositivo SCSI se puede utilizar para acceder al LUN FC como si se tratara de un dispositivo SCSI conectado localmente.

Ejecute el comando sr-probe para enumerar los dispositivos SCSI respaldados por LUNs presentes en el host. Este comando obliga a realizar un análisis de los nuevos dispositivos SCSI respaldados por LUNs. El valor de path devuelto porsr-probe para un dispositivo SCSI respaldado por LUNs es coherente en todos los hosts con acceso al LUN. Por lo tanto, este valor debe utilizarse al crear SRs compartidos a los que puedan acceder todos los hosts de un grupo de recursos.

Las mismas funciones se aplican a los HBAs iSCSI QLogic.

Consulte Crear repositorios de almacenamiento para obtener más información sobre la creación de SRs iSCSI y FC basados en HBA compartidos.

Nota:

La compatibilidad con Citrix Hypervisor para Fibre Channel no admite la asignación directa de un LUN a una VM. Los LUNs basados en HBA deben asignarse al host y especificarse para su uso en un SR. Los VDI dentro del SR están expuestos a las VM como dispositivos de bloque estándar.