Unidad 5.1: Almacenamiento en bloque y de archivos

Introducción

El nivel de datos comienza con una decisión que es fácil de tomar de manera incorrecta: quién necesita leer y escribir los mismos bytes. Un Block Storage Volume 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 gestionado separado, Network File Storage, en lugar de cualquier truco de bloque compartido. Esta unidad dibuja esa línea, saca a la superficie una asimetría de colocación que atrapa a los arquitectos, y luego construye el compartido de archivos que la aplicación de FinCorp necesita.

1. Single-VM Block Storage Versus Managed Shared File Access

Block Storage presenta un dispositivo de bloque iSCSI a una máquina virtual. Usted lo conecta, 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 mueve bytes entre máquinas. Para los datos persistentes de una sola aplicación, esto es exactamente lo que usted quiere, y es donde vive la mayor parte de la capacidad de la capa de datos.

Network File Storage resuelve el problema diferente de un sistema de archivos montado por muchos clientes al mismo tiempo. Es un producto gestionado: IONOS ejecuta un Cluster de dos servidores de almacenamiento en una configuración de alta disponibilidad activa-pasiva en la capa de servicio, exporta los datos a través de NFSv4.2 y usted lo monta desde sus máquinas virtuales. Los clientes ven un sistema de archivos POSIX compartido; la durabilidad, el failover entre los dos servidores y el sistema de archivos subyacente ZFS son operados por usted. No se admite NFSv3, así que planifique solo 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 estándar SSD de Block Storage, por lo que una compartición hereda el comportamiento de clase SSD, pero su ruta de escritura está limitada por la latencia de escritura síncrona de alrededor de 20 ms. Para alcanzar un alto rendimiento de escritura agregado, se necesitan muchos escritores concurrentes, y la tabla de ranuras RPC de cliente NFS predeterminada de una sola montura (normalmente 64 a 128) puede convertirse en el límite antes de que lo haga el almacenamiento. La guía documentada es explícita en que no es adecuada para cargas de trabajo de escritura síncrona con requisitos de tiempo de espera ajustados. Léalo como almacenamiento de archivos compartidos para assets, directorios de inicio, registros y zonas de aterrizaje de copias de seguridad, y no como un disco transaccional de baja latencia. Un hecho estructural más es importante en el momento del diseño: el tamaño de un Cluster se elige en TiB con un control deslizante, el mínimo es 2 TiB, el máximo es 42 TiB, y el tamaño no se puede disminuir después de la provisión, por lo que es un mecanismo de palanca hacia arriba.

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

Para FinCorp, la capa de aplicación ejecuta varias máquinas virtuales sin estado detrás de un Load Balancer, y necesitan un directorio compartido para documentos cargados y plantillas compartidas. Eso es precisamente la primera fila de arriba: una sola compartición montada en lectura-escritura por cada Node de aplicación, en lugar de una copia de los assets integrada en cada imagen de VM.

1.1 Alcance regional y privado, y dónde Object Storage se hace cargo

Network File Storage es regional y privado. El Cluster está asociado con un centro de datos LAN y es accesible en una dirección privada IPv4 o IPv6 dentro de ese centro de datos virtual; no hay un punto de conexión público, y una compartición no abarca regiones. Los clientes la montan sobre la red privada LAN, lo que mantiene el tráfico fuera de internet y significa que la transferencia de datos a sus máquinas virtuales no se factura. El intercambio es el alcance: si FinCorp necesita los mismos datos disponibles en varias regiones, o accesibles mediante herramientas de estilo S3, el sistema de archivos compartido es la capa incorrecta. Para datos compartidos entre regiones, use Object Storage en su lugar (unidad 5.2), que es el almacenamiento geo-que-abarca la plataforma, direccionable API. Elija Network File Storage cuando muchas máquinas en una región necesitan un sistema de archivos POSIX en vivo; elija Object Storage cuando el alcance, la escala o el acceso programático dominan.

El acceso también es Linux-only y se controla por compartición a través de grupos de clientes. Cada grupo de clientes empareja una lista de redes IP (las redes privadas autorizadas, en notación CIDR) con un modo de aplastamiento que asigna la identidad raíz y de usuario remota a una identidad anónima. La configuración de redes IP siempre tiene prioridad sobre la lista de hosts, y la documentación recomienda en contra de la opción de no-aplastamiento por razones de seguridad. Esto es el equivalente a nivel de archivo de la postura privada-por-defecto que sigue la REST de la arquitectura.

2. Coincidir el nivel con el patrón de acceso y la asimetría de la zona

La decisión del nivel está impulsada por el patrón de acceso, no por el tamaño. Un disco persistente de un solo escritor para un VM es Block Storage. Un sistema de archivos POSIX de muchos lectores y muchos escritores dentro de una región es Network File Storage. El almacenamiento de archivo y archivo que abarca varias regiones, API, es Object Storage. Dentro de Block Storage, los niveles SSD tienen un piso de rendimiento que vale la pena tener en cuenta aquí porque se repite en el nivel de datos: los volúmenes SSD ofrecen un rendimiento completo por GiB solo a partir de 100 GiB, por lo que un pequeño SSD Volume tiene un rendimiento inferior al de su nivel. Ese piso es la razón por la que se desaconsejan los volúmenes SSD de tamaño insuficiente para las cargas de trabajo exigentes, un punto que se retoma en la unidad 5.3 para las bases de datos.

Hay una asimetría de colocación que sorprende a los arquitectos que provienen de otras plataformas. Las zonas de disponibilidad no son simétricas entre el cómputo y Block Storage. Un Volume de Block Storage se puede colocar en la Zona 1, Zona 2, Zona 3 o Auto. Sin embargo, el cómputo solo ofrece las Zonas 1, 2 y Auto: no hay zona de cómputo 3. La consecuencia práctica es que no puede fijar un servidor en una "Zona 3" para coincidir con un Volume de la Zona 3, porque no existe tal zona de cómputo. Cuando está propagando intencionalmente un par redundante en zonas, diseñe alrededor de la realidad del cómputo de las Zonas 1 y 2, y no suponga que la colocación de la Zona 3 de un Volume le compra un dominio de cómputo correspondiente. Trate la selección de zona como una decisión explícita para cualquier par redundante en lugar de dejarla en Auto, lo que puede colocar recursos que pretendía separar.

DCD Implementación paso a paso

Esta implementación proporciona el almacenamiento de archivos compartidos que necesita la capa de aplicación de FinCorp: un Network File Storage Cluster en la capa de aplicación LAN, una participación y el montaje desde varios clientes Linux. Se realiza la decisión de la sección 1 de mantener una sola copia canónica de activos compartidos en lugar de duplicarlos por VM. El requisito previo es un VDC existente con una capa de aplicación LAN privada (construida en la unidad 3.1) y el privilegio de Acceso y Administración de Network File Storage en su grupo; sin ese privilegio, un usuario tiene acceso de solo lectura y no puede aprovisionar.

Objetivo de construcción: Aprovisionar almacenamiento de archivos compartidos montado por varios clientes.

Pasos (en el Data Center Designer):

1. En el DCD, abra Menú > Almacenamiento y copia de seguridad > Network File Storage, luego seleccione Crear Cluster.
2. Defina las propiedades de Cluster: ingrese un nombre de Cluster; seleccione la Ubicación (la ubicación del servidor donde vivirá el Cluster); establezca el Tamaño en TiB con el control deslizante, recordando el mínimo de 2 TiB y que el tamaño no se puede reducir más tarde; deje la Versión del sistema de archivos en el valor predeterminado NFSv4.2.
3. Asocie el Cluster con un centro de datos: seleccione el Centro de datos (las opciones dependen de la ubicación elegida) y la capa de aplicación LAN del centro de datos, que debe ser la capa de aplicación LAN privada. Ingresa una dirección IPv4 (o IPv6) privada con CIDR para el Cluster, utilizando el panel Encontrar su dirección IP privada en el lado derecho para seleccionar una dirección gratuita que no entre en conflicto con su rango DHCP.
4. Haga clic en Guardar. El Cluster se crea y entra en el estado OCUPADO; espere hasta que esté DISPONIBLE antes de crear participaciones.
5. Desde la lista de Cluster, seleccione Administrar participaciones de la columna OPCIONES (o abra el Cluster y utilice la pestaña Administrar participaciones), luego seleccione Crear participación.
6. Defina las propiedades de la participación: ingrese un nombre de directorio; opcionalmente, establezca una cuota en MiB para limitar la participación (establezca cero para deshabilitar la cuota); opcionalmente, establezca el Id. de grupo y el Id. de usuario que poseen la participación, 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 compresión NFS (mapear raíz a anónimo es la línea de base recomendada; evite no comprimir); en IP Redes, agregue la red privada autorizada en notación CIDR (por ejemplo, la subred de la capa de aplicación LAN) para que solo esos clientes puedan montar.
8. Haga clic en Guardar para crear la participación.
9. En cada cliente Linux, monte la participación utilizando la dirección IP privada del Cluster y el UUID de la participación: mount -t nfs <cluster-ip>:<share-uuid> <local-mount-path>. Cada VM de aplicación que monta la misma dirección IP del Cluster y el UUID ahora ve los mismos archivos.

Errores comunes:

• Sobredimensionar el Cluster el primer día. El tamaño solo aumenta; no se puede reducir, así que comience con el requisito real por encima del mínimo de 2 TiB y crezca cuando sea necesario.
• Dejar el modo de compresión en Ninguno. La documentación lo desaconseja; mapee la raíz (o todos los usuarios) a la identidad anónima en su lugar.
• Olvidar que IP Redes reemplaza la lista de Hosts. Si el acceso es incorrecto, verifique IP Redes CIDR primero, porque siempre gana.
• Suponer que NFSv3 funcionará. Solo se admite NFSv4.2; los clientes más antiguos no pueden montar.
• Esperar acceso entre regiones o acceso público. La participación es privada y regional; si necesita cualquiera de ellos, use Object Storage, no una exportación NFS más amplia.
• Intentar montar desde Windows. El soporte de cliente es solo para Linux.
• Elegir Network File Storage para una Workload de escritura sincrónica con un tiempo de espera ajustado. La latencia de escritura sincrónica de ~20 ms y el techo de ranura RPC por montaje la hacen inadecuada; esos datos pertenecen a un Block Storage Volume conectado al único VM que los posee.

Resumen

Block Storage es un disco privado, único VM iSCSI; Network File Storage es un sistema de archivos privado, regional y gestionado NFSv4.2 que muchos clientes Linux montan al mismo tiempo; Object Storage es el almacenamiento que abarca varias regiones, direccionable por API. El nivel sigue el patrón de acceso, no la capacidad, y la elección deliberada de zona es importante porque Block Storage ofrece la Zona 3, mientras que el cómputo no. El nivel de aplicación sin estado de FinCorp obtiene una participación compartida para sus activos, dimensionada para el crecimiento y bloqueada para la aplicación LAN.

Puntos clave:

• Block Storage = un VM, disco privado (el acoplamiento se cubre en 4.2); Network File Storage = muchos clientes Linux, un sistema de archivos privado regional; Object Storage = almacenamiento que abarca varias regiones, direccionable por API.
• Network File Storage es solo NFSv4.2 (no NFSv3), solo para Linux, construido sobre la clase estándar SSD, con un piso de escritura síncrona de ~20 ms; no es un disco transaccional de baja latencia.
• Un Cluster se dimensiona de 2 a 42 TiB y no se puede reducir después de la provisión; el acceso está controlado por grupos de clientes donde la lista de redes IP siempre tiene prioridad sobre la lista de Hosts.
• Las zonas de disponibilidad de Block Storage son 1, 2, 3 y Auto; las zonas de cómputo son solo 1, 2 y Auto. No hay zona de cómputo 3, por lo que establezca zonas explícitas para cualquier par redundante en lugar de confiar en Auto.

Terminología importante:

• Cluster (Network File Storage): la unidad gestionada de dos servidores, activa-pasiva, que usted provisiona y dimensiona en TiB; contiene una o más participaciones y se conecta a un centro de datos LAN único.
• Participación: un sistema de archivos individual exportado dentro de un Cluster, con su propia cuota, identificadores de propietario y grupos de clientes; varias participaciones pueden vivir en un Cluster.
• Modo squash: el mapeo de la raíz remota o de todos los usuarios a una identidad anónima (UID/GID 65534 por defecto) que limita lo que un cliente que monta puede hacer como usuario privilegiado.