Crear un repositorio de almacenamiento
Puede utilizar el asistente para nuevos repositorios de almacenamiento de XenCenter para crear repositorios de almacenamiento (SR). El asistente lo guía a través de los pasos de configuración. También puede usar la CLI y el comando sr-create
. El comando sr-create
crea un RA en el sustrato de almacenamiento (que puede destruir cualquier dato existente). También crea el objeto de API de SR y un registro PBD correspondiente, lo que permite a las máquinas virtuales utilizar el almacenamiento. Al crear correctamente el SR, el PBD se conecta automáticamente. Si se establece el shared=true
indicador SR, se crea y conecta un registro PBD para cada XenServer 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 dedicada.
Todos los tipos de XenServer SR admiten el cambio de tamaño de la VDI, la clonación rápida y la creación de instantáneas. Los SR basados en el tipo de SR de LVM (local, iSCSI o HBA) proporcionan aprovisionamiento ligero para los nodos primarios ocultos y de instantáneas. Los otros tipos de SR (EXT3/EXT4, NFS, GFS2) admiten el aprovisionamiento controlado completo, incluso para los discos virtuales que están activos.
Advertencias:
Cuando los VDI de VHD no están conectados a una máquina virtual, por ejemplo, para una instantánea de VDI, se almacenan como aprovisionados con poca cantidad de forma predeterminada. Si intenta volver a conectar la VDI, asegúrese de que haya suficiente espacio en disco disponible para que la VDI se aprovisione de manera abundante. Los clones de VDI se aprovisionan en gran medida.
XenServer no admite instantáneas en el nivel de SAN externo de un LUN para ningún tipo de SR.
No intente crear un SR en el que el ID de LUN del LUN de destino sea superior a 255. Asegúrese de que su objetivo exponga el LUN con un ID de LUN inferior o igual a 255 antes de usar este LUN para crear un SR.
Si usa aprovisionamiento controlado en una SR basada en archivos, asegúrese de supervisar el espacio libre en su SR. Si el uso de SR aumenta hasta el 100%, fallan las escrituras posteriores de las VM. Estas escrituras fallidas pueden provocar que la VM se congele o se bloquee.
Los tamaños máximos de VDI admitidos son:
Formato de repositorio de almacenamiento | Tamaño máximo de VDI |
---|---|
EXT3/EXT4 | 2 TiB |
GFS2 (con iSCSI o HBA) | 16 TiB |
XFS | 16 TiB |
LVM | 2 TiB |
LVMoFCOE (en desuso) | 2 TiB |
LVMoHBA | 2 TiB |
LVMoiSCSI | 2 TiB |
NFS | 2 TiB |
SMB | 2 TiB |
LVM local
El tipo LVM local presenta los discos dentro de un grupo de volúmenes conectado localmente.
De forma predeterminada, XenServer usa el disco local del host físico en el que está instalado. El Administrador de volúmenes lógicos de Linux (LVM) se usa para administrar el almacenamiento de VM. Un VDI se implementa en formato VHD en un volumen lógico LVM del tamaño especificado.
Nota:
El tamaño de bloque de un LVM LUN debe ser de 512 bytes. Para usar el almacenamiento con bloques físicos de 4 KB, el almacenamiento también debe admitir la emulación de bloques de asignación de 512 bytes (el tamaño del bloque lógico debe ser de 512 bytes).
Consideraciones de rendimiento de LVM
La funcionalidad de copia instantánea y clonación rápida para los SR basados en LVM conlleva una sobrecarga de rendimiento inherente. Cuando se requiere un rendimiento óptimo, XenServer admite la creación de VDI en formato RAW además del formato VHD predeterminado. La funcionalidad de instantáneas de XenServer no se admite en los VDI sin procesar.
Advertencia:
No intente hacer una instantánea de una máquina virtual que tenga discos
type=raw
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érfanos comprobando el camposnapshot-of
y, a continuación, eliminándolos.
Creación de una SR de LVM local
Una SR de LVM se crea de forma predeterminada en la instalación del host.
Los parámetros de configuración del dispositivo para los SR de LVM son:
Nombre del parámetro | Descripción | ¿Obligatorio? |
---|---|---|
device |
Nombre del dispositivo en el host local que se utilizará para el SR. También puede proporcionar una lista de nombres separados por comas. | Sí |
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
<!--NeedCopy-->
EXT3/EXT4 local
El uso de EXT3/EXT4 permite el aprovisionamiento controlado 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 sobreasignación de almacenamiento. Si usa EXT3/EXT4, es posible que vea un rendimiento reducido en los siguientes casos:
- Al llevar a cabo operaciones del ciclo de vida de VM, como crear y suspender/reanudar VM
- Al crear archivos grandes desde la VM
Los SR EXT3/EXT4 del disco local deben configurarse mediante la CLI de XenServer.
El hecho de que un EXT SR local utilice EXT3 o EXT4 depende de la versión de XenServer que lo haya creado:
- Si creó el EXT SR local en una versión anterior de Citrix Hypervisor o XenServer y, a continuación, lo actualizó a XenServer 8, utilizará EXT3.
- Si creó el EXT SR local en XenServer 8, utilizará EXT4.
Nota:
El tamaño de bloque de un disco EXT3/EXT4 debe ser de 512 bytes. Para usar el almacenamiento con bloques físicos de 4 KB, el almacenamiento también debe admitir la emulación de bloques de asignación de 512 bytes (el tamaño del bloque lógico debe ser de 512 bytes).
Creación de una SR EXT4 local (ext
)
Parámetros de configuración del dispositivo para los SR EXT:
Nombre del parámetro | Descripción | ¿Obligatorio? |
---|---|---|
device |
Nombre del dispositivo en el host local que se utilizará para el SR. También puede proporcionar una lista de nombres separados por comas. | Sí |
Para crear una SR EXT4 local en /dev/sdb
, utilice el siguiente comando:
xe sr-create host-uuid=valid_uuid content-type=user \
name-label="Example Local EXT4 SR" shared=false \
device-config:device=/dev/sdb type=ext
<!--NeedCopy-->
XFS local
El uso de XFS permite un aprovisionamiento ligero en el almacenamiento local. El tipo XFS local permite crear dispositivos de almacenamiento local con bloques físicos de 4 KB sin necesidad de un tamaño de bloque lógico de 512 bytes.
Creación de un SR de XFS local
Parámetros de configuración del dispositivo para los SR de XFS:
Nombre del parámetro | Descripción | ¿Obligatorio? |
---|---|---|
device |
Nombre del dispositivo en el host local que se utilizará para el SR. También puede proporcionar una lista de nombres separados por comas. | Sí |
Para crear un SR de XFS local en /dev/sdb
, use el siguiente comando:
xe sr-create host-uuid=valid_uuid content-type=user \
name-label="Example Local XFS SR" shared=false \
device-config:device=/dev/sdb type=xfs
<!--NeedCopy-->
udev
El tipo udev representa los dispositivos conectados mediante el administrador de dispositivos udev como VDI.
XenServer tiene dos SR de tipo udev que representan almacenamiento extraíble. Una es para el disco CD o DVD de la unidad física de CD o DVD-ROM del host XenServer. La otra es para un dispositivo USB conectado a un puerto USB del host XenServer. Los VDI que representan los medios van y vienen a medida que se insertan y extraen discos o memorias USB.
ISO
El tipo ISO maneja las imágenes de CD almacenadas como archivos en formato ISO. Este tipo de SR es útil para crear bibliotecas ISO compartidas.
Están disponibles los siguientes tipos de ISO SR:
-
nfs_iso
: El tipo NFS ISO SR gestiona las imágenes de CD almacenadas como archivos en formato ISO disponibles como un recurso compartido NFS. -
cifs
: El tipo SR de Windows File Sharing (SMB/CIFS) gestiona las imágenes de CD almacenadas como archivos en formato ISO disponibles como recursos compartidos de Windows (SMB/CIFS).
Si no especifica el tipo de almacenamiento que se va a usar para el SR, XenServer usa el parámetro de configuración del location
dispositivo para decidir el tipo.
Parámetros de configuración del dispositivo para los SR ISO:
Nombre del parámetro | Descripción | ¿Obligatorio? |
---|---|---|
location |
Camino al monte. | Sí |
type |
Tipo de almacenamiento que se utilizará para el SR: cifs o nfs_iso . |
No |
nfsversion |
Para el tipo de almacenamiento NFS, la versión del protocolo NFS que se va a utilizar: 3, 4, 4.0 o 4.1. | No |
vers |
Para el tipo de almacenamiento CIFS/SMB, la versión de SMB que se utilizará: 1.0 o 3.0. El valor predeterminado es 3.0. | No |
username |
Para el tipo de almacenamiento CIFS/SMB, si se requiere un nombre de usuario para el servidor de archivos de Windows. | No |
cifspassword_secret |
(Recomendado) Para el tipo de almacenamiento CIFS/SMB, puede pasar un secreto en lugar de una contraseña al servidor de archivos de Windows. | No |
cifspassword |
Para el tipo de almacenamiento CIFS/SMB, si se requiere una contraseña para el servidor de archivos de Windows. Le recomendamos que utilice el cifspassword_secret parámetro en su lugar. |
No |
Nota:
Al ejecutar el
sr-create
comando, se recomienda utilizar el argumento en lugardevice-config:cifspassword_secret
de especificar la contraseña en la línea de comandos. Para obtener más información, consulte Secretos.
Para los repositorios de almacenamiento que almacenan una biblioteca de ISO, el content-type
parámetro se debe establecer en iso
, por ejemplo:
xe sr-create host-uuid=valid_uuid content-type=iso type=iso name-label="Example ISO SR" \
device-config:location=<path_to_mount> device-config:type=nfs_iso
<!--NeedCopy-->
Puede usar NFS o SMB para montar la ISO SR. Para obtener más información sobre el uso de estos tipos de SR, consulte NFS y SMB .
Le recomendamos que utilice la versión 3 de SMB para montar ISO SR en el servidor de archivos de Windows. La versión 3 se selecciona de forma predeterminada porque es más segura y sólida que la versión 1.0 para pymes. Sin embargo, puede montar ISO SR mediante SMB versión 1 con el siguiente comando:
xe sr-create content-type=iso type=iso shared=true device-config:location=<path_to_mount>
device-config:username=<username> device-config:cifspassword=<password> \
device-config:type=cifs device-config:vers=1.0 name-label="Example ISO SR"
<!--NeedCopy-->
Compatibilidad con iSCSI de software
XenServer admite SR compartidos en los LUNs iSCSI. iSCSI se admite mediante el iniciador iSCSI de software iSCSI abierto o mediante un adaptador de bus de host (HBA) iSCSI compatible. Los pasos para usar HBA iSCSI son idénticos a los pasos para los HBA de canal de fibra. Ambos conjuntos de pasos se describen en Crear un LVM compartido a través de Fibre Channel, Fibre Channel a través de Ethernet/HBA iSCSI o SAS SR.
La compatibilidad con iSCSI compartida mediante el iniciador iSCSI de software se implementa en función de Linux Volume Manager (LVM). Esta función proporciona los mismos beneficios de rendimiento que proporcionan los VDI de LVM en la carcasa del disco local. Los SR iSCSI compartidos que utilizan un iniciador de host basado en software pueden contribuir a la agilidad de las máquinas virtuales mediante la migración en vivo: las máquinas virtuales se pueden iniciar en cualquier host de XenServer de un grupo de recursos y migrar entre ellas sin que se note un tiempo de inactividad.
Los SR iSCSI utilizan todo el LUN especificado en el momento de la creación y no pueden abarcar más de un LUN. Se proporciona soporte CHAP para la autenticación de clientes, tanto durante la inicialización del path de datos como durante las fases de descubrimiento de LUN.
Nota:
El tamaño de bloque de un LUN iSCSI debe ser de 512 bytes. Para usar el almacenamiento con bloques físicos de 4 KB, el almacenamiento también debe admitir la emulación de bloques de asignación de 512 bytes (el tamaño del bloque lógico debe ser de 512 bytes).
Configuración iSCSI del host de XenServer
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 hosts XenServer 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 usar para conectarse a varios destinos iSCSI al mismo tiempo.
Los destinos iSCSI suelen proporcionar control de acceso mediante listas IQN de iniciadores iSCSI. Todos los objetivos o LUNs iSCSI a los que accede el host de XenServer deben estar configurados para permitir el acceso del IQN iniciador del host. Del mismo modo, los objetivos/LUN que se van a utilizar como RA iSCSI compartidos deben configurarse para permitir el acceso de todos los IQN de host en el grupo de recursos.
Nota:
Los destinos iSCSI que no proporcionan control de acceso suelen restringir el acceso del LUN a un único iniciador para garantizar la integridad de los datos. Si se utiliza un LUN iSCSI como SR compartido entre varios hosts de un grupo, asegúrese de que el acceso de varios iniciadores esté habilitado para el LUN especificado.
El valor del IQN del host de XenServer 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
<!--NeedCopy-->
Advertencia:
- Cada objetivo e iniciador iSCSI debe tener un IQN único. Si se utiliza un identificador IQN no único, puede producirse corrupción de datos o denegación de acceso a LUN.
- No cambie el IQN del host de XenServer con los SR iSCSI conectados. Si lo hace, puede provocar fallas en la conexión con nuevos objetivos o SR existentes.
Almacenamiento FCoE de software (en desuso)
El software FCoE proporciona un marco estándar en el 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.
Nota:
El software FCoE está en desuso y se eliminará en una versión futura.
Antes de crear un almacenamiento FCoE de software, complete manualmente la configuración requerida para exponer un LUN al host. Esta configuración incluye la configuración de la estructura FCoE y la asignación de LUN al nombre mundial público (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 usar para acceder al LUN como si fuera un dispositivo SCSI conectado localmente. Para obtener información sobre 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 Linux Bridge como back-end de la red.
Crear una SR de FCoE de software
Antes de crear una SR de FCoE de software, los clientes deben asegurarse de que haya NIC compatibles con FCoE conectadas al host.
Los parámetros de configuración del dispositivo para los SR de FCoE son:
Nombre del parámetro | Descripción | ¿Obligatorio? |
---|---|---|
SCSIid |
El identificador del bus SCSI del LUN de destino | Sí |
Ejecute el siguiente comando para crear una SR de FCoE compartida:
xe sr-create type=lvmofcoe \
name-label="FCoE SR" shared=true device-config:SCSIid=SCSI_id
<!--NeedCopy-->
Adaptadores de bus host (HBA) de hardware
Esta sección cubre varias operaciones necesarias para administrar HBA SAS, Fibre Channel e iSCSI.
Configuración de HBA iSCSI QLogic de ejemplo
Para obtener más información sobre la configuración de los HBAs iSCSI y Fibre Channel QLogic, consulte el sitio web de Cavium.
Una vez que el HBA esté instalado físicamente en el host de XenServer, siga los siguientes pasos para configurar el HBA:
-
Establezca la configuración de redes IP para el HBA. En este ejemplo se asume el puerto DHCP y HBA 0. Especifique los valores adecuados si utiliza direcciones IP estáticas o un HBA multipuerto.
/opt/QLogic_Corporation/SANsurferiCLI/iscli -ipdhcp 0 <!--NeedCopy-->
-
Agregue un destino iSCSI persistente al puerto 0 del HBA.
/opt/QLogic_Corporation/SANsurferiCLI/iscli -pa 0 iscsi_target_ip_address <!--NeedCopy-->
-
Ejecute el comando
sr-probe
xe para forzar un nuevo análisis del Controller HBA y mostrar los LUNs disponibles. Para obtener más información, consulte Probar una SR y Crear una LVM compartida a través de Fibre Channel, Fibre Channel a través de Ethernet/HBA iSCSI o SAS SR.
Eliminar entradas de dispositivos SAS, FC o iSCSI basados 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 ruta de dispositivo global correspondiente en /dev/disk/by-scsibus
en el formato <SCSIid>-<adapter>:<bus>:<target>:<lun>
y una ruta de dispositivo estándar en /dev
. Para eliminar las entradas del dispositivo para los LUN que ya no se utilizan como SR, siga los siguientes pasos:
-
Use
sr-forget
osr-destroy
, según corresponda, para eliminar el SR de la base de datos del host de XenServer. Consulte Eliminar SR para obtener más información. -
Elimine la configuración de zonas dentro de la SAN para el LUN deseado al host deseado.
-
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, sondee una SR. -
Elimine las entradas del dispositivo con el siguiente comando:
echo "1" > /sys/class/scsi_device/adapter:bus:target:lun/device/delete <!--NeedCopy-->
Advertencia:
Asegúrese de que está seguro de qué LUN va a eliminar. La eliminación accidental de un LUN requerido para la operación del host, como el dispositivo de arranque o raíz, hace que el host quede inutilizable.
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. Para usar el almacenamiento con bloques físicos de 4 KB, el almacenamiento también debe admitir la emulación de bloques de asignación de 512 bytes (el tamaño del bloque lógico debe ser de 512 bytes).
Cree un LVM compartido a través de SR iSCSI mediante el iniciador iSCSI de software
Parámetros de configuración del dispositivo para SRs LVMoiSCSI:
Nombre del parámetro | Descripción | ¿Obligatorio? |
---|---|---|
target |
La dirección IP o el nombre de host del destino iSCSI en la SAN que aloja el SR. También puede ser una lista de valores separados por comas para conectarse a varios destinos. | Sí |
targetIQN |
El nombre cualificado (IQN) de iSCSI del destino en la SAN iSCSI que aloja el SR, o * para conectarse a todos los IQN. |
Sí |
SCSIid |
El identificador del bus SCSI del LUN de destino | Sí |
multihomed |
Habilitar multi-homing a este objetivo | No (el valor predeterminado es el mismo que host.other_config:multipathing) |
chapuser |
El nombre de usuario que se utilizará para la autenticación CHAP | No |
chappassword_secret |
(Recomendado) ID secreto de la contraseña que se utilizará para la autenticación CHAP. Pase un secreto en lugar de una contraseña. | No |
chappassword |
La contraseña que se utilizará para la autenticación CHAP. Le recomendamos que utilice el chappassword_secret parámetro en su lugar. |
No |
port |
El número de puerto de red en el que se consultará el destino | No |
usediscoverynumber |
El índice de registros iSCSI específico que se va a utilizar | No |
incoming_chapuser |
El nombre de usuario que el filtro iSCSI utiliza para autenticarse en el host | No |
incoming_chappassword_secret |
(Recomendado) ID secreto para la contraseña que usa el filtro iSCSI para autenticarse en el host. | No |
incoming_chappassword |
La contraseña que usa el filtro iSCSI para autenticarse en el host. Le recomendamos que utilice el incoming_chappassword_secret parámetro en su lugar. |
No |
Nota:
Al ejecutar el
sr-create
comando, se recomienda utilizar el argumento en lugardevice-config:chappassword_secret
de especificar la contraseña en la línea de comandos. Para obtener más información, consulte Secretos.
Para crear una SR iSCSI LVMoiSCSI compartida en un LUN específico de un destino iSCSI, use 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
<!--NeedCopy-->
Cree un LVM compartido a través de Fibre Channel, Fibre Channel a través de Ethernet/HBA iSCSI o SAS SR
Los SR de tipo LVMoHBA se pueden crear y administrar mediante la CLI xe o XenCenter.
Parámetros de configuración del dispositivo para SRs de LVMoHBA:
Nombre del parámetro | Descripción | ¿Obligatorio? |
---|---|---|
SCSIid |
Identificador SCSI del dispositivo | Sí |
Para crear una SR LVMoHBA compartida, lleve a cabo los siguientes pasos en cada host del grupo:
-
Divida uno o más LUNs en cada host de XenServer del grupo. Este proceso es muy específico para el equipo SAN en uso. Para obtener más información, consulte la documentación de su SAN.
-
Si es necesario, utilice la CLI del HBA incluida en el host de XenServer para configurar el HBA:
-
Emulex:
/bin/sbin/ocmanager
-
FC de QLogic:
/opt/QLogic_Corporation/SANsurferCLI
-
iSCSI de QLogic:
/opt/QLogic_Corporation/SANsurferiCLI
Para ver un ejemplo de la configuración de HBA iSCSI de QLogic, consulte Adaptadores de bus de host (HBA) de hardware en la sección anterior. Para obtener más información sobre los HBAs Fibre Channel e iSCSI, consulte los sitios web Broadcom y Cavium.
-
-
Utilice el comando
sr-probe
para determinar la ruta de acceso del dispositivo global del LUN de HBA. El comandosr-probe
obliga a volver a analizar los HBAs instalados en el sistema para detectar los nuevos LUNs que se han asignado a una zona en el host. El comando devuelve una lista de propiedades para cada LUN encontrado. Especifique el parámetrohost-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ámetrodevice-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> <!--NeedCopy-->
-
En el coordinador de agrupaciones, cree el SR. Especifique la ruta de acceso global del dispositivo devuelta en la propiedad
<path>
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 <!--NeedCopy-->
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 operación
sr-create
. Esta función puede resultar valiosa en los casos en que la división en zonas del LUN era incorrecta para uno o más hosts de un grupo cuando se creó el SR. Corrija la división en zonas para los hosts afectados y utilice la función Reparar repositorio de almacenamiento en lugar de eliminar y volver a crear el SR.
Almacenamiento en bloques GFS2 compartido con aprovisionamiento fino
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:
- Quieres aumentar la eficiencia del espacio. Las imágenes están escasamente asignadas y no densamente asignadas.
- Desea reducir la cantidad de operaciones de E/S por segundo en su cabina de almacenamiento. GFS2 SR es el primer tipo de SR que admite el almacenamiento en caché de lectura de almacenamiento en almacenamiento en bloque compartido.
- Se usa una imagen base común para varias máquinas virtuales. Por lo general, las imágenes de las VM individuales utilizarán incluso menos espacio.
- Usas instantáneas. Cada instantánea es una imagen y ahora cada imagen es escasa.
- Su 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. La GFS2 SR admite VDI de hasta 16 TiB de tamaño.
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 SR GFS2 compartido crea un sistema de archivos GFS2 en un LUN iSCSI o HBA. Los VDI se almacenan en el GFS2 SR como archivos en el formato de imagen QCOW2.
Para obtener más información sobre el uso del almacenamiento GFS2, consulte Almacenamiento en bloques GFS2 compartido con aprovisionamiento fino.
NFS y SMB
Los recursos compartidos en servidores NFS (que admiten cualquier versión de NFSv4 o NFSv3) o en servidores SMB (que admiten SMB 3) se pueden usar inmediatamente como SR para discos virtuales. Los VDI solo se almacenan en formato VHD de Microsoft. Además, dado que estos SR se pueden compartir, los VDI almacenados en SR compartidos permiten:
-
Las máquinas virtuales se iniciarán en cualquier host de XenServer de un grupo de recursos
-
Migración de máquinas virtuales entre hosts de XenServer en un grupo de recursos mediante migración en vivo (sin tiempos de inactividad apreciables)
Importante:
- La compatibilidad con SMB3 se limita a la capacidad de conectarse a un recurso compartido mediante el protocolo 3. Las funciones adicionales, como la conmutación por error transparente, dependen de la disponibilidad de las funciones en el núcleo Linux original y no se admiten en XenServer 8.
- XenServer no admite SMB en clúster.
- Para NFSv4, solo
AUTH_SYS
se admite el tipo de autenticación.- El almacenamiento para pequeñas y medianas empresas está disponible para los clientes de XenServer Premium Edition.
- Se recomienda encarecidamente para el almacenamiento NFS y SMB que se utilice una red de almacenamiento dedicada, utilizando al menos dos enlaces conectados, idealmente a conmutadores de red independientes con fuentes de alimentación redundantes.
- Cuando utilice el almacenamiento SMB, no extraiga el recurso compartido del almacenamiento antes de desconectar el SMB SR.
Los VDI almacenados en SR basados en archivos se aprovisionan con poca frecuencia. El archivo de imagen se asigna a medida que la VM escribe datos en el disco. Este enfoque tiene la ventaja considerable de que los archivos de imagen de VM solo ocupan tanto espacio en el almacenamiento como se requiere. Por ejemplo, si se asigna una 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 se pueden encadenar, lo que permite que dos VDI compartan datos comunes. En los casos en que se clona una máquina virtual basada en archivos, las máquinas virtuales resultantes comparten los datos en disco comunes en el momento de la clonación. Cada VM procede a realizar sus propios cambios en una versión aislada de copia en escritura de la VDI. Esta función permite que las VM basadas en archivos se clonen rápidamente a partir de plantillas, lo que facilita el aprovisionamiento y la implementación muy rápidos de nuevas VM.
Nota:
La longitud máxima admitida de las cadenas de VHD es de 30.
Las implementaciones de SR y VHD basadas en archivos en XenServer asumen que tienen el control total sobre el directorio SR del servidor de archivos. Los administradores no deben modificar el contenido del directorio de SR, ya que esta acción puede dañar el contenido de los VDI.
XenServer se ha ajustado para un almacenamiento de clase empresarial que utiliza RAM no volátil para proporcionar un reconocimiento rápido de las solicitudes de escritura y, al mismo tiempo, mantener un alto grado de protección de los datos contra errores. XenServer se ha probado exhaustivamente con dispositivos de almacenamiento FAS2020 y FAS3210 de Network Appliance, mediante Data OnTap 7.3 y 8.1
Advertencia:
Como los VDI en SR basados en archivos se crean como aprovisionamiento controlado, los administradores deben asegurarse de que los SR basados en archivos tengan suficiente espacio en disco para todos los VDI requeridos. Los hosts de XenServer no exigen que haya espacio necesario para los VDI en los SR basados en archivos.
Asegúrese de supervisar el espacio libre en su SR. Si el uso de SR aumenta hasta el 100%, fallan las escrituras posteriores de las VM. Estas escrituras fallidas pueden provocar que la VM se congele o se bloquee.
Crear una SR de NFS compartida (NFS)
Nota:
Si intenta adjuntar una SR de NFS de solo lectura, esta acción falla y aparece el siguiente mensaje de error: “SR_BACKEND_FAILURE_461: no se puede escribir en el sistema de archivos de SR”.
Para crear una SR de NFS, debe proporcionar el nombre de host o la dirección IP del servidor NFS. Puede crear el RA en cualquier ruta de destino válida; use el comando sr-probe
para mostrar una lista de rutas de destino válidas exportadas por el servidor.
En los escenarios en los que XenServer se usa con almacenamiento de gama baja, espera con cautela a que se acuse de recibo de todas las escrituras antes de pasar las confirmaciones a las máquinas virtuales. Este enfoque implica un coste de rendimiento notable y podría resolverse configurando el almacenamiento para que presente el punto de montaje SR como una exportación en modo asíncrono. Las exportaciones asíncronas reconocen escrituras que no están realmente en el disco. Considere cuidadosamente los riesgos de fracaso en estas situaciones.
Nota:
El servidor NFS debe estar configurado para exportar la ruta especificada a todos los hosts del grupo. Si no se realiza esta configuración, se produce un error en la creación de la SR y la conexión del registro PBD.
La implementación de NFS de XenServer usa TCP de forma predeterminada. Si su situación lo permite, puede configurar la implementación para que use UDP en casos en los que pueda haber un beneficio de rendimiento. Para realizar esta configuración, al crear un SR, especifique useUDP=true
en el parámetro device-config
.
Los siguientes parámetros device-config
se utilizan con los SR de NFS:
Nombre del parámetro | Descripción | ¿Obligatorio? |
---|---|---|
server |
Dirección IP o nombre de host del servidor NFS | Sí |
serverpath |
Ruta, incluido el punto de montaje NFS, al servidor NFS que aloja el SR | Sí |
nfsversion |
Especifica la versión de NFS que se va a utilizar. Si especifica nfsversion="4" , el SR usa NFS v4.0, v4.1 o v4.2, según lo que esté disponible. Si quiere seleccionar una versión más específica de NFS, puede especificar nfsversion="4.0" , etc. Solo se puede especificar un valor para nfsversion . |
No |
useUDP |
Configure el SR para que utilice UDP en lugar del TCP predeterminado. | No |
Por ejemplo, para crear un SR de NFS compartido el 192.168.1.10:/export1
, utilizando cualquier versión 4 de NFS que esté disponible en el archivador, 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 \
device-config:nfsversion="4"
<!--NeedCopy-->
Para crear un SR de NFS no compartido 192.168.1.10:/export1
, utilizando específicamente la versión 4.0 de NFS, 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 \
device-config:nfsversion="4.0"
<!--NeedCopy-->
Crear una SR de SMB compartida (SMB)
Para crear una SR de SMB, proporcione el nombre de host o la dirección IP del servidor SMB, la ruta completa del recurso compartido exportado y las credenciales apropiadas.
Parámetros de configuración de dispositivos para SR de SMB:
Nombre del parámetro | Descripción | ¿Obligatorio? |
---|---|---|
server |
Ruta completa para compartir en el servidor | Sí |
username |
Cuenta de usuario con acceso a RW para compartir | Opcional |
password_secret |
(Recomendado) ID secreto para la contraseña de la cuenta de usuario, que se puede usar en lugar de la contraseña. | Opcional |
password |
Contraseña de la cuenta de usuario. Le recomendamos que utilice el parámetro en su lugarpassword_secret . |
Opcional |
Nota:
Al ejecutar el
sr-create
comando, se recomienda utilizar el argumento en lugardevice-config:password_secret
de especificar la contraseña en la línea de comandos. Para obtener más información, consulte Secretos.
Por ejemplo, para crear un RA SMB compartido en 192.168.1.10:/share1
, use 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_secret=valid_password_secret type=smb
<!--NeedCopy-->
Para crear una SR de SMB no compartida, 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_secret=valid_password_secret type=smb
<!--NeedCopy-->
HBA LVM sobre hardware
El tipo de HBA LVM sobre hardware representa los discos como VHD 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 hosts XenServer admiten SAN Fibre Channel a través de adaptadores de bus de host (HBA) Emulex o QLogic. Toda la configuración de canal de fibra requerida para exponer un LUN de canal de fibra al host debe completarse manualmente. Esta configuración incluye los dispositivos de almacenamiento, los dispositivos de red y el HBA dentro del host de XenServer. Una vez completada toda la configuración de FC, el HBA expone al host un dispositivo SCSI respaldado por el LUN de canal de fibra. El dispositivo SCSI se puede usar para acceder al LUN de canal de fibra como si fuera un dispositivo SCSI conectado localmente.
Use el comando sr-probe
para enumerar los dispositivos SCSI respaldados por LUN presentes en el host. Este comando fuerza una exploración en busca de nuevos dispositivos SCSI respaldados por LUN. El valor de la ruta devuelto por sr-probe
un dispositivo SCSI respaldado por LUN es uniforme en todos los hosts con acceso al LUN. Por lo tanto, este valor se debe usar al crear SR compartidas accesibles para 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 SR iSCSI y FC basadas en HBA compartidas.
Nota:
El soporte de XenServer para Fibre Channel no admite la asignación directa de un LUN a una máquina virtual. Los LUN basados en HBA deben asignarse al host y especificarse para su uso en un SR. Los VDI dentro de la SR se exponen a las VM como dispositivos de bloques estándar.
El tamaño de bloque de un LVM sobre HBA LUN debe ser de 512 bytes. Para usar el almacenamiento con bloques físicos de 4 KB, el almacenamiento también debe admitir la emulación de bloques de asignación de 512 bytes (el tamaño del bloque lógico debe ser de 512 bytes).