Discos EVS compartidos e instrucciones de uso
¿Qué son los discos EVS compartidos?
Los discos EVS compartidos son dispositivos de almacenamiento en bloque que admiten operaciones de lectura/escritura simultáneas y se pueden conectar a múltiples servidor. Los discos EVS compartidos cuentan con múltiples archivos adjuntos, alta simultaneidad, alto rendimiento y alta confiabilidad. Por lo general, se utilizan para aplicaciones empresariales críticas que requieren la implementación de clústeres para alta disponibilidad (HA). Múltiples servidor pueden acceder al mismo disco EVS compartido al mismo tiempo.
Un disco EVS compartido se puede conectar a un máximo de 16 servidor. Los servidores que admite EVS incluyen ECS y BMS. Para compartir archivos, debe implementar un sistema de archivos compartido o un sistema de gestión de clústeres, como Windows MSCS, Veritas VCS o CFS.
Debe configurar un sistema de archivos compartido o un sistema de gestión de clústeres antes de usar discos EVS compartidos. Si conecta directamente un disco a varios servidors, la función de uso compartido no funcionará y los datos pueden sobrescribirse.
Precauciones de uso
Debido a que la mayoría de las aplicaciones de clúster, como Windows MSCS, Veritas VCS y Veritas CFS, requieren reservas SCSI, se recomienda utilizar discos EVS compartidos con SCSI. Si un disco SCSI EVS está conectado a un ECS de Xen para su uso, debe instalar el controlador. Para más detalles, consulte Tipos de dispositivos e instrucciones de uso.
- Discos EVS VBD compartidos: el tipo de dispositivo de un disco EVS compartido recién creado es VBD de forma predeterminada. Dichos discos se pueden utilizar como dispositivos de almacenamiento de bloques virtuales, pero no admiten reservas SCSI. Si se requieren reservas SCSI para sus aplicaciones, cree discos SCSI EVS compartidos.
- Discos SCSI EVS compartidos: estos discos EVS admiten reservas SCSI.
- Para mejorar la seguridad de los datos, se recomienda utilizar las reservas SCSI junto con la política antiafinidad de un grupo ECS. Dicho esto, asegúrese de que los discos SCSI EVS compartidos solo estén adjuntados a ECSs en el mismo grupo de antiafinidad ECS.
- Si un ECS no pertenece a ningún grupo antiafinidad ECS, se recomienda no adjuntar discos SCSI EVS compartidos a este ECS. De lo contrario, es posible que las reservas SCSI no funcionen correctamente, lo que puede poner en riesgo sus datos.
Conceptos del grupo de antiafinidad ECS y las reservas SCSI:
- La política antiafinidad de un grupo ECS permite crear ECSs en diferentes servidores físicos para mejorar la confiabilidad del servicio.
Para obtener más información acerca de los grupos ECS, consulte Gestión de grupos ECS.
- El mecanismo de reserva de SCSI utiliza un commando de reserva de SCSI para realizar operaciones de reserva de SCSI. Si un ECS envía tal commando a un disco EVS, el disco se muestra como bloqueado a otros ECSs, evitando el daño de datos que puede ser causado por operaciones simultáneas de lectura/escritura en el disco desde múltiples ECSs.
- Los grupos ECS y las reservas SCSI tienen la siguiente relación: Una reserva SCSI en un solo disco EVS no puede diferenciar varios ECSs en el mismo host físico. Por esa razón, si varios ECSs que utilizan el mismo disco EVS compartido se ejecutan en el mismo host físico, las reservas SCSI no funcionarán correctamente. Por lo tanto, se recomienda utilizar las reservas SCSI solo en los ECS que estén en el mismo grupo ECS, por lo que tienen una política antiafinidad de trabajo.
Ventajas
- Múltiples archivos adjuntos: Un disco EVS compartido se puede conectar a un máximo de 16 servidor.
- Alto rendimiento: las IOPS aleatorias de lectura/escritura de un disco de E/S ultra-alto compartido pueden alcanzar hasta 160,000.
- Alta confiabilidad: los discos EVS compartidos admiten copias de respaldo manuales y automáticas, lo que ofrece un almacenamiento de datos altamente confiable.
- Amplio rango de uso: Los discos EVS compartidos se pueden usar para clústeres RHCS de Linux donde solo se necesitan discos VBD EVS. También se pueden utilizar para clústeres MSCS de Windows y VCS de Veritas que requieren reservas SCSI.
Especificaciones y rendimiento
Los discos EVS compartidos tienen las mismas especificaciones y rendimiento que los discos EVS no compartidos. Para más detalles, consulte Tipos de discos y rendimiento.
Principio de uso compartido de datos y errores comunes de uso
Un disco EVS compartido es esencialmente el disco que se puede conectar a múltiples servidor para su uso, que es similar a un disco físico en que el disco se puede conectar a múltiples servidores físicos, y cada servidor puede leer datos y escribir datos en cualquier espacio en el disco. Si las reglas de lectura/escritura de datos, tales como la secuencia de lectura/escritura y el significado, entre estos servidores no están definidas, puede producirse interferencia de lectura/escritura de datos entre servidores u otros errores impredecibles.
Aunque los discos EVS compartidos son dispositivos de almacenamiento en bloque que proporcionan acceso compartido para servidor, los discos EVS compartidos no tienen la capacidad de gestión de clústeres. Por lo tanto, debe implementar un sistema de clúster para gestionar discos EVS compartidos. Los sistemas comunes de gestión de clústeres incluyen Windows MSCS, Linux RHCS, Veritas VCS y Veritas CFS.
- Incoherencia de datos causada por conflictos de lectura/escritura
Cuando un disco EVS compartido está conectado a dos servidor (servidor A y servidor B), servidor A no puede reconocer los espacios de disco asignados a servidor B, viceversa. Dicho esto, un espacio de disco asignado a servidor A puede ser usado ya por servidor B. En este caso, se produce una asignación de espacio en disco repetida, lo que conduce a errores de datos.
Por ejemplo, un disco EVS compartido ha sido formateado en el sistema de archivos ext3 y conectado a servidor A y servidor B. El servidor A tiene metadatos escritos en el sistema de archivos en el espacio R y el espacio G. Entonces servidor B ha escrito metadatos en el espacio E y en el espacio G. En este caso, los datos escritos en el espacio G por servidor A serán reemplazados. Cuando se leen los metadatos en el espacio G, se producirá un error.
- Incoherencia de datos causada por el almacenamiento en caché de datos
Cuando un disco EVS compartido está conectado a dos servidor (servidor A y servidor B), la aplicación en servidor A ha leído los datos en el espacio R y en el espacio G, luego almacenado en caché los datos. En ese momento, otros procesos y subprocesos en servidor A leerían estos datos directamente desde la caché. Al mismo tiempo, si la aplicación en servidor B ha modificado los datos en el espacio R y en el espacio G, la aplicación en servidor A no puede detectar este cambio de datos y todavía lee estos datos de la memoria caché. Como resultado, el usuario no puede ver los datos modificados en servidor A.
Por ejemplo, un disco EVS compartido ha sido formateado en el sistema de archivos ext3 y conectado a servidor A y servidor B. Ambos servidor tienen los metadatos almacenados en caché en el sistema de archivos. A continuación, servidor A ha creado un nuevo archivo (archivo F) en el disco compartido, pero servidor B no puede detectar esta modificación y sigue leyendo datos de sus datos almacenados en caché. Como resultado, el usuario no puede ver el archivo F en servidor B.
Antes de conectar un disco EVS compartido a múltiples servidor, es necesario determinar el tipo de dispositivo de disco. El tipo de dispositivo puede ser VBD o SCSI. Los discos SCSI EVS compartidos admiten reservas SCSI. Antes de utilizar las reservas SCSI, debe instalar un controlador en servidor el sistema operativo y asegurarse de que la imagen del sistema operativo está incluida en la lista de compatibilidad.
Si simplemente adjunta un disco EVS compartido a múltiples servidor, los archivos no se pueden compartir entre servidor ya que los discos EVS compartidos no tienen la capacidad de clúster. Por lo tanto, cree un sistema de archivos compartido o implemente un sistema de gestión de clústeres si necesita compartir archivos entre servidor.
