Un switch puede morir y su storage sigue sirviendo
El disco de su VM vive en una cabina dedicada, accesible por dos redes de storage que no comparten nada. Las dos están vivas en todo momento, así que un switch muerto, un cable arrancado o una red entera retirada para mantenimiento no es un acontecimiento para la carga de trabajo.
En este artículo 4 secciones
- Cada host de nuestra SAN llega a su storage por dos fabrics Fibre Channel completamente independientes, con switches separados, en modo activo/activo.
- Un switch, un cable o un puerto pueden fallar y su LUN sigue sirviendo por el otro camino. Los dos caminos llevan I/O de producción en todo momento, así que no hay ningún standby que despertar ni ningún cutover que sobrevivir.
- El RAID dentro de un solo servidor cubre un fallo, un disco muerto. Cualquier otra cosa de esa caja se lleva su storage con ella.
- El diseño permite retirar un fabric entero del servicio con todas las máquinas virtuales ejecutándose aún en el otro.
El disco en el que escribe su carga de trabajo no vive dentro del servidor que la ejecuta. Vive en una cabina de storage a una red de distancia, y esa red puede fallar como cualquier otra cosa: los switches mueren, los cables se arrancan, los puertos empiezan a hacer flapping. Lo que decide si su carga de trabajo llega a notarlo es si existe un segundo camino hasta el disco, y si ese segundo camino está de verdad separado del primero.
El multipath da a cada host dos caminos vivos hasta su LUN
Un LUN es el dispositivo de bloques que su máquina virtual ve como su disco. En una SAN, ese disco vive fuera del servidor que ejecuta su carga de trabajo, en una cabina all-flash dedicada de doble controladora, y el servidor llega a él por una red de storage. Multipath significa que el servidor mantiene más de una ruta física hacia el mismo LUN al mismo tiempo, por puertos distintos, cables distintos y switches distintos.
Activo/activo significa que las dos rutas llevan tráfico cada segundo del día. Un camino en standby que solo despierta durante un fallo es un camino que nunca ha probado de verdad, y el fallo es el peor momento posible para su primera prueba. Cuando los dos caminos llevan I/O en vivo de forma continua, perder uno simplemente deja al otro haciendo todo el trabajo del que ya hacía la mitad. La carga de trabajo no ve nada, porque desde donde está, no ha pasado nada.
Dos puertos HBA en el host
Dos cables, por dos tendidos separados
Dos switches, uno por fabric
Dos fabrics Fibre Channel, ambos activo/activo
Los dos fabrics no comparten ningún switch, así que un fallo no puede cruzar de uno a otro
Dos caminos por el mismo switch son un solo camino con dos etiquetas. Lo que mate al switch mata a los dos. La independencia real significa que los dos fabrics se construyen como dos redes separadas con switches separados, y nada en la ruta de datos entre el host y la cabina aparece en ambos. Un fallo en un fabric, ya sea un switch muerto, un puerto que hace flapping o un enlace congestionado, no tiene por dónde propagarse. El segundo fabric no se entera.
Un fabric Fibre Channel es la red conmutada entre los servidores y las cabinas de storage, el equivalente para storage de su LAN. Operar dos de ellos, totalmente separados, significa que el tráfico de storage siempre tiene una segunda red en la que vivir. Los fallos caros en redes de storage rara vez son muertes limpias. Son enlaces que siguen levantados pero se atascan, y la independencia es lo que mantiene ese tipo de enfermedad confinada a un lado.
El RAID dentro de un servidor muere con el servidor
El RAID en una tarjeta controladora dentro de su servidor le protege de exactamente una cosa, un disco muerto, y lo hace bien. Pero los discos, la tarjeta RAID, el backplane, las fuentes de alimentación y la placa base viven todos en la misma caja, y la caja es el dominio de fallo. Cuando cualquier otra cosa de dentro muere, su storage se va con ella, y vuelve cuando vuelve el servidor. Si falla la propia tarjeta RAID, los discos más sanos del mundo quedan inaccesibles.
Una SAN saca el disco del dominio de fallo de la máquina que lo usa. Su servidor puede morir y el LUN en el que escribía un segundo antes sigue ahí, intacto y sirviendo, listo para que la carga de trabajo vuelva a levantarse en otro host. El diseño de doble fabric extiende la misma idea al camino entre ambos: a la ruta hasta su storage también se le permite fallar, por eso construimos dos.
| Qué falla | Qué ven sus cargas de trabajo |
|---|---|
| Un cable o un puerto | El LUN sigue sirviendo por el otro camino. Sin cutover, sin reinicio. |
| Un switch entero | El segundo fabric lo lleva todo. Nada despierta ni conmuta. |
| Un fabric entero, retirado para mantenimiento | Cada host conserva un camino bueno por el fabric sano mientras se hace el trabajo. |
| Un nodo controlador de storage | La segunda controladora sigue sirviendo mientras se cambia el hardware. |
| El propio servidor | El LUN le sobrevive. La carga de trabajo se reinicia en otro host y encuentra su disco donde lo dejó. |
Retirar un fabric entero del servicio con cargas de trabajo en vivo
Cuando un fabric necesita mantenimiento, el procedimiento no tiene nada de espectacular: confirmamos que cada host conserva un camino bueno por el otro fabric, retiramos el fabric del servicio, hacemos el trabajo y después lo reintroducimos de forma deliberada. Las máquinas virtuales se ejecutan en un fabric mientras se hace el trabajo y no ven nada. Esa es la cantidad correcta de dramatismo para el mantenimiento de storage.
La misma postura se aplica en el lado de la cabina. Las cabinas son de doble controladora: una controladora puede recibir mantenimiento mientras la otra sigue sirviendo. En nuestra SAN el hardware se mantiene como debería mantenerse en todas partes: mientras aquello a lo que pertenece sigue haciendo su trabajo.
Respuestas directas
¿Activo/activo es solo una palabra más bonita para failover?+
No. Un diseño de failover mantiene un segundo camino inactivo hasta que muere el primero, y entonces intenta un cutover en las peores condiciones del día. Activo/activo significa que los dos fabrics llevan I/O de producción en todo momento, así que un fallo retira un camino que funcionaba mientras el otro camino que funcionaba continúa. No hay ningún evento de cutover que sobrevivir ni ningún standby pasando su primera prueba durante su incidente.
Mi servidor tiene RAID-10. ¿Es la misma protección?+
El RAID dentro del servidor protege sus datos de un disco muerto, y solo de eso. La tarjeta RAID, el backplane, las fuentes de alimentación y el propio servidor siguen siendo puntos únicos de fallo, y su storage comparte su suerte. En una SAN el storage sobrevive a la muerte del servidor que lo usa, y con fabrics dobles sobrevive también a la muerte del camino intermedio.
¿Y si falla toda la cabina, o todo el sitio?+
Otra clase de fallo, otras herramientas. Este artículo cubre los caminos entre un host sano y una cabina sana, que es donde viven los fallos cotidianos. Sobrevivir a la pérdida de una cabina o de un sitio es una conversación de recuperación, y la hemos escrito por separado: cuánta pérdida de datos y cuánto downtime puede tolerar honestamente su empresa.
¿Cómo sé que los dos caminos funcionan realmente antes de que falle uno?+
Porque los dos fabrics llevan I/O en vivo de forma continua, un camino muerto no es una condición silenciosa: en el momento en que un lado deja de mover tráfico, aparece en la monitorización. Y cada mantenimiento empieza igual, confirmando que cada host conserva un camino bueno por el fabric que queda, antes de retirar nada del servicio.
Pregunte a un ingeniero sobre qué se apoya realmente su storage
Las personas que diseñan y operan los fabrics son las mismas que responden. Traiga su infraestructura actual y le diremos con claridad qué sobrevive a qué.
Hable con un ingenieroSwitches muertos, cables arrancados y mantenimiento de controladoras son los fallos que este diseño retira. Perder una cabina entera o un sitio entero es otra clase de fallo, y esa empieza en la conversación de recuperación. Si está evaluando proveedores, las preguntas sobre storage que merece la pena hacer a cualquiera, nosotros incluidos, están en el secreto sucio de su proveedor es su storage.
Ha llegado al final.
Ponga la lectura a trabajar
¿Qué está ejecutando?
Cuéntenos la carga de trabajo, el tráfico y los requisitos de recuperación. Empiece por el configurador de servidores o repase los detalles con un ingeniero.
Escrito por los ingenieros que construyen y operan la infraestructura que describe.Hable con un ingeniero