Unidad 5.1: Almacenamiento de bloques y de archivos

Introducción

La capa de datos comienza con una decisión que es fácil de tomar incorrectamente: quién necesita leer y escribir los mismos bytes. Un volumen de Block Storage es un disco privado que pertenece a exactamente un servidor a la vez; es la respuesta correcta para un disco de arranque o para los datos de una sola aplicación, y la unidad 4.2 ya cubrió cómo adjuntar uno. En el momento en que dos o más máquinas deben ver los mismos archivos al mismo tiempo, ese modelo se rompe, y la plataforma ofrece un producto administrado separado, Network File Storage, en lugar de cualquier truco de bloques compartidos. Esta unidad traza esa línea, pone de manifiesto una asimetría de colocación que sorprende a los arquitectos, y luego construye la unidad de almacenamiento de archivos compartida que la capa de aplicaciones de FinCorp necesita.

1. Block Storage para una sola VM frente a acceso compartido a archivos gestionado

Block Storage presenta un dispositivo de bloque iSCSI a una sola máquina virtual. Lo adjunta, el sistema operativo invitado lo formatea y se comporta como un disco local. Ese disco está vinculado a su servidor: no es un medio de acceso concurrente y no transfiere bytes entre máquinas. Para los datos persistentes de una sola aplicación, esto es exactamente lo que se desea, y es donde reside la mayor parte de la capacidad de la capa de datos.

Network File Storage resuelve el problema diferente de un sistema de archivos montado simultáneamente por muchos clientes. Es un producto gestionado: IONOS CLOUD opera un clúster de dos servidores de almacenamiento en una configuración de alta disponibilidad activa-pasiva a nivel de servicio, exporta los datos mediante NFSv4.2 y se monta desde las VM. Los clientes ven un sistema de archivos POSIX compartido; la durabilidad, el conmutación por error entre los dos servidores y el sistema de archivos ZFS subyacente se gestionan por su cuenta. NFSv3 no está soportado, por lo que debe planificarse únicamente para clientes NFSv4.2.

Los dos productos también difieren en la entrega de rendimiento. Network File Storage se basa en la clase de rendimiento Block Storage SSD Standard, por lo que una partición hereda el comportamiento de clase SSD, pero su ruta de escritura está limitada por una latencia de escritura síncrona de aproximadamente 20 ms. Alcanzar un alto número de IOPS de escritura agregados requiere, por lo tanto, muchos escritores concurrentes, y la tabla de ranuras RPC del cliente NFS predeterminada de una sola montaje (típicamente 64 a 128) puede convertirse en el límite antes que el almacenamiento. La orientación documentada es explícita en que no es adecuado para cargas de trabajo de escritura síncrona con requisitos de tiempo de espera estrictos. Debe interpretarse como almacenamiento de archivos compartidos para activos, directorios de inicio, registros y zonas de aterrizaje para copias de seguridad, no como un disco transaccional de baja latencia. Un hecho estructural más importa en el momento del diseño: el tamaño de un clúster se elige en TiB mediante un control deslizante, el mínimo es 2 TiB, el máximo es 42 TiB, y el tamaño no puede reducirse después de la aprovisionamiento, por lo que es un mecanismo de solo aumento.

La siguiente tabla de la documentación del producto enumera los casos de uso para los que se ha creado Network File Storage:

Para FinCorp, la capa de aplicación ejecuta varias VM sin estado detrás de un equilibrador de carga, y necesitan un directorio compartido para documentos subidos y plantillas compartidas. Eso es precisamente la primera fila anterior: una sola partición montada en modo lectura-escritura por cada nodo de aplicación, en lugar de una copia de los activos integrada en cada imagen de VM.

1.1 Alcance regional y privado, y dónde Object Storage toma el relevo

Network File Storage es regional y privado. El clúster está asociado con una LAN de un centro de datos y es alcanzable mediante una dirección IPv4 o IPv6 privada dentro de ese VDC; no hay un punto de acceso público, y una partición no abarca regiones. Los clientes lo montan a través de la LAN privada, lo que mantiene el tráfico fuera de internet y significa que la transferencia de datos a sus VM no se cobra. La compensación es el alcance: si FinCorp necesita los mismos datos disponibles entre regiones, o accesibles mediante herramientas de tipo S3, el sistema de archivos compartido es la capa equivocada. Para datos compartidos entre regiones, utilice Object Storage en su lugar (unidad 5.2), que es el almacenamiento de la plataforma con alcance geográfico y direccionable por API. Elija Network File Storage cuando muchas máquinas en una región necesiten un sistema de archivos POSIX en vivo; elija Object Storage cuando el alcance, la escala o el acceso programático sean predominantes.

El acceso también es solo para Linux y se controla por partición mediante grupos de clientes. Cada grupo de clientes asocia una lista de IP Networks (las redes privadas autorizadas, en notación CIDR) con un modo de squash que mapea el root remoto y los usuarios a una identidad anónima. La configuración de IP Networks siempre tiene prioridad sobre la lista de Hosts, y la documentación desaconseja la opción sin squash por razones de seguridad. Esta es la equivalente en la capa de archivos de la postura de privado por defecto que sigue el resto de la arquitectura.

2. Correspondencia entre el nivel y el patrón de acceso, y la asimetría de zonas

La decisión sobre el nivel está determinada por el patrón de acceso, no por el tamaño. Un disco persistente con un único escritor para una VM es Block Storage. Un sistema de archivos POSIX con múltiples lectores y múltiples escritores dentro de una región es Network File Storage. El almacenamiento masivo y de archivo que abarca varias ubicaciones geográficas y es accesible mediante API es Object Storage. Dentro de Block Storage, los niveles SSD tienen un umbral de rendimiento que conviene tener en cuenta aquí, ya que se repite en todo el nivel de datos: los volúmenes SSD ofrecen el rendimiento completo por GiB solo a partir de 100 GiB, por lo que un volumen SSD pequeño no alcanza el rendimiento esperado de su nivel. Ese umbral es la razón por la que se desaconsejan los volúmenes SSD de tamaño insuficiente para cargas de trabajo exigentes, un punto al que la unidad 5.3 vuelve a referirse en el contexto de bases de datos.

Existe una asimetría en la colocación que sorprende a los arquitectos que provienen de otras plataformas. Las zonas de disponibilidad no son simétricas entre la computación y Block Storage. Un volumen de Block Storage puede colocarse en la zona 1, la zona 2, la zona 3 o en Auto. Sin embargo, la computación solo ofrece las zonas 1, 2 y Auto: no existe una zona 3 de computación. La consecuencia práctica es que no puede fijar un servidor en una "zona 3" para que coincida con un volumen de la zona 3, porque no existe tal zona de computación. Cuando distribuye deliberadamente un par redundante entre zonas, diseñe teniendo en cuenta la realidad de la computación en las zonas 1 y 2, y no asuma que la colocación de un volumen en la zona 3 le proporciona un dominio de computación correspondiente. Trate la selección de zona como una decisión explícita para cualquier par redundante, en lugar de dejarla en Auto, lo cual podría colocar en la misma ubicación recursos que usted pretendía separar.

Guía de implementación de DCD

Esta guía provisiona el almacenamiento de archivos compartido que la capa de aplicaciones de FinCorp necesita: un clúster de Network File Storage en la LAN de aplicaciones, una carpeta compartida y el montaje desde múltiples clientes Linux. Materializa la decisión de la sección 1 de mantener una copia canónica única de los activos compartidos en lugar de duplicarlos por cada VM. El requisito previo es un VDC existente con una LAN de aplicaciones privada (construida en la unidad 3.1) y el privilegio de Access and Manage Network File Storage en su grupo; sin ese privilegio, un usuario tiene acceso de solo lectura y no puede provisionar.

Objetivo de construcción: Provisionar almacenamiento de archivos compartido montado por múltiples clientes.

Pasos (en Data Center Designer):

1. En DCD, abra Menú > Storage & Backup > Network File Storage, luego seleccione Create Cluster.
2. Defina las propiedades del clúster: ingrese un nombre de clúster; seleccione la ubicación (la ubicación del servidor donde residirá el clúster); establezca el tamaño en TiB con el control deslizante, recordando el mínimo de 2 TiB y que el tamaño no puede reducirse posteriormente; deje la versión del sistema de archivos en el valor predeterminado NFSv4.2.
3. Asocie el clúster con un centro de datos: seleccione el centro de datos (las opciones dependen de la ubicación elegida) y la LAN del centro de datos, que debe ser la LAN de aplicaciones privada. Ingrese una dirección IPv4 (o IPv6) privada con CIDR para el clúster, utilizando el panel Finding your Private IP a la derecha para elegir una dirección libre que no entre en conflicto con su rango DHCP.
4. Haga clic en Save. El clúster se crea y entra en el estado BUSY; espere hasta que pase a AVAILABLE antes de crear carpetas compartidas.
5. Desde la lista de clústeres, seleccione Manage Shares en la columna OPTIONS (o abra el clúster y use la pestaña Manage Shares), luego seleccione Create Share.
6. Defina las propiedades de la carpeta compartida: ingrese un nombre de directorio; opcionalmente establezca una cuota en MiB para limitar la carpeta compartida (establezca cero para desactivar la cuota); opcionalmente establezca el Group Id y el User Id propietarios, ambos de los cuales tienen un valor predeterminado de 65534.
7. Agregue un grupo de clientes: opcionalmente agregue una descripción; elija un modo de NFS Squash (mapear root a anónimo es la línea base recomendada; evite no-squash); bajo IP Networks, agregue la red privada autorizada en notación CIDR (por ejemplo, la subred de la LAN de aplicaciones) para que solo esos clientes puedan montar.
8. Haga clic en Save para crear la carpeta compartida.
9. En cada cliente Linux, monte la carpeta compartida utilizando la IP privada del clúster y el UUID de la carpeta compartida: mount -t nfs <cluster-ip>:<share-uuid> <local-mount-path>. Cada VM de aplicación que monte la misma IP de clúster y UUID verá ahora los mismos archivos.

Errores comunes:

• Dimensionar el clúster de más desde el primer día. El tamaño solo aumenta; no puede reducirse, por lo que comience con la necesidad real por encima del mínimo de 2 TiB y crezca cuando sea necesario.
• Dejar el modo squash en None. La documentación no lo recomienda; mapee root (o todos los usuarios) a la identidad anónima en su lugar.
• Olvidar que IP Networks tiene prioridad sobre la lista de Hosts. Si el acceso es incorrecto, verifique primero el CIDR de IP Networks, porque siempre prevalece.
• Suponer que NFSv3 funcionará. Solo se admite NFSv4.2; los clientes anteriores fallan al montar.
• Esperar acceso entre regiones o público. La carpeta compartida es privada y regional; si necesita cualquiera de los dos, use Object Storage, no una exportación NFS más amplia.
• Intentar montar desde Windows. La compatibilidad con clientes es solo para Linux.
• Elegir Network File Storage para una carga de trabajo de escritura síncrona con tiempo de espera ajustado. La latencia de escritura síncrona de ~20 ms y el límite de ranuras RPC por montaje lo hacen inadecuado; esos datos deben estar en un volumen de Block Storage adjunto a la VM única que lo posee.

Resumen

Block Storage es un disco iSCSI privado de una sola VM; Network File Storage es un sistema de archivos NFSv4.2 gestionado, regional y privado que muchos clientes Linux montan simultáneamente; Object Storage es el almacén que abarca regiones geográficas y es direccionable mediante API. La jerarquía sigue el patrón de acceso, no la capacidad, y una elección deliberada de zona es importante porque Block Storage ofrece la Zona 3, mientras que la computación no la ofrece. La capa de aplicaciones sin estado de FinCorp recibe una sola unidad compartida para sus activos, dimensionada para el crecimiento y restringida a la LAN de la aplicación.

Puntos clave:

• Block Storage = una VM, disco privado (la conexión se cubre en 4.2); Network File Storage = muchos clientes Linux, un sistema de archivos regional privado; Object Storage = entre regiones, direccionable mediante API.
• Network File Storage es solo NFSv4.2 (sin NFSv3), solo Linux, construido sobre la clase SSD Standard, con un umbral de escritura síncrona de ~20 ms; no es un disco transaccional de baja latencia.
• Un cluster se dimensiona entre 2 y 42 TiB y no puede reducirse después de la aprovisionamiento; el acceso se controla mediante grupos de clientes, donde la lista de IP Networks siempre tiene prioridad sobre la lista de Hosts.
• Las zonas de disponibilidad de Block Storage son 1, 2, 3 y Auto; las zonas de computación son solo 1, 2 y Auto. No existe la Zona 3 de computación, por lo que se deben establecer zonas explícitas para cualquier par redundante en lugar de depender de Auto.

Terminología importante:

• Cluster (Network File Storage): la unidad gestionada de dos servidores, activa-pasiva, que se aprovisiona y dimensiona en TiB; contiene una o más unidades compartidas y se conecta a una sola LAN de centro de datos.
• Share: un sistema de archivos exportado individual dentro de un cluster, con su propia cuota, identificadores de propietario y grupos de clientes; varias unidades compartidas pueden coexistir en un solo cluster.
• Modo squash: el mapeo de root remoto o de todos los usuarios a una identidad anónima (UID/GID 65534 por defecto) que limita lo que un cliente de montaje puede hacer como usuario con privilegios.