Azure Native Qumulo ahora disponible en la UE, el Reino Unido y Canadá: Más información

Un enfoque más simple y confiable para la alta disponibilidad en la nube

Escrito por:

La infraestructura de nube pública ha transformado muchos aspectos de la estrategia de TI, pero una cosa permanece constante: la importancia vital de alta disponibilidad en las nubes. Cuando los datos son su negocio, como es el caso de todos los negocios en la actualidad, cualquier pérdida puede tener consecuencias nefastas. Debe hacer todo lo posible para minimizar ese riesgo. Naturalmente, la alta disponibilidad es un área clave de enfoque para los proveedores de almacenamiento tanto en las instalaciones como en la nube, pero no todos los proveedores adoptan el mismo enfoque. Comprender cuáles son las diferencias y por qué son importantes es esencial para tomar la decisión correcta para sus datos y su negocio.

La alta disponibilidad se basa en ingeniosos trucos de red

En las instalaciones, la alta disponibilidad generalmente se basa en algunos trucos de red inteligentes. Uno de ellos es el concepto de direcciones IP flotantes: una o más direcciones IP que no pertenecen únicamente a un dispositivo, sino que se comparten entre un grupo de dispositivos. Los clientes utilizan estas direcciones IP flotantes para acceder al contenido servido por los dispositivos agrupados, por lo que, en caso de falla del dispositivo, la conexión del cliente puede cambiar sin problemas de un dispositivo a otro. Hay algunos mecanismos diferentes que se pueden utilizar para alejar las direcciones IP flotantes de los dispositivos fallidos. Por ejemplo, tanto la plataforma BIG-IP de F5 Networks como Qumulo Archivo de tela utilice una técnica llamada ARP gratuito para hacerse cargo de una dirección IP flotante que anteriormente era servida por otro nodo. Otros sistemas usan enrutamiento asincrónico para que solo un dispositivo en vivo reciba tráfico. En ambos casos, es la propia red la que habilita la funcionalidad para la conmutación por error sin problemas desde un nodo con problemas a un nodo que está funcionando.

In entornos de nube pública, usted no posee ni controla la red. Aquí, son Amazon, Microsoft o Google quienes pueden dictar qué funciones habilitar. Para Amazon Web Services (AWS), estas opciones incluyen la desactivación de ARP para evitar el riesgo de abusos como el envenenamiento de la caché de ARP (también conocido como suplantación de ARP o enrutamiento de envenenamiento de ARP). Eso significa que cualquier dispositivo local que haya estado usando y que se basó en ARP para obtener alta disponibilidad no funcionará. Como resultado, los proveedores de infraestructura deben encontrar un enfoque diferente para la alta disponibilidad de la nube.

Pruebe Qumulo para que AWS experimente el almacenamiento de archivos en la nube.

Opciones de alta disponibilidad en la nube

Las opciones de alta disponibilidad en la nube se reducen a dos enfoques básicos: puede encontrar una solución que sea esencialmente similar a lo que ha hecho en las instalaciones o puede escribir un nuevo método específico de la nube para la conmutación por error de IP.

Un ejemplo de una solución alternativa es el método Usos de NetApp ONTAP para la conmutación por error de IP en AWS. Como arquitectura clásica de almacenamiento escalable, NetApp se basa en nodos emparejados donde los datos se reflejan constantemente de un nodo a otro. En este caso, está manteniendo efectivamente dos copias de su almacén de datos, incurriendo en costos de computación, almacenamiento y software tanto para el nodo usado como para el no usado. Piense en ello como una forma de seguro de automóvil en el que, en lugar de pagar una tarifa mensual relativamente baja, cubre su riesgo comprando un segundo automóvil completo en caso de que algo salga mal con el primero. Estas implementaciones se pueden ejecutar en configuraciones activas / en espera o activas / activas; ambos requieren que los datos se repliquen por completo. Ahora bien, esta implementación en sí misma no proporciona conmutación por error de IP; para ello, debe implementar un tercer sistema informático llamado NetApp Cloud Manager.

Cloud Manager es una instancia t2.micro (mostrada como el "mediador" arriba) dedicada a manejar la configuración de los sistemas ONTAP y proporcionar failover. El administrador de la nube observa si hay una falla y luego cambia el enrutamiento IP del activo al modo de espera según sea necesario. Eso suena muy bien hasta que analizamos más de cerca el t2.micro, un tipo de instancia AWS EC2 con solo 1 vCPU y 1 GB de RAM. Hacer de eso el eje de su estrategia de alta disponibilidad significa pasar de un único punto de falla del nodo activo a un único punto de falla aún más pequeño en el propio mecanismo de conmutación por error.

Como empresa de software ágil, Qumulo está en condiciones de pensar realmente en la solución correcta para cada problema, sin importar lo difícil que pueda ser, y construirla para nuestros clientes. Teniendo en cuenta la complejidad y el riesgo del enfoque de ONTAP para la alta disponibilidad en la nube, comenzamos desde cero y encontramos un método más simple y confiable.

En lugar de intentar forzar el ajuste de un modelo local en un entorno de nube pública, creamos una conmutación por error de IP diseñada específicamente para la nube. La clave es hacer uso de las funciones disponibles en cada una de las plataformas de nube pública. Por ejemplo, utilizamos las API de AWS de cualquier miembro activo del clúster para cambiar una dirección IP flotante de un miembro del clúster caído a un miembro activo. De esta manera, evitamos agregar otra capa de complejidad y también evitamos introducir un solo punto de falla que puede convertirse fácilmente en un cuello de botella. Como beneficio adicional, nuestro enfoque elimina la necesidad de un clúster de reserva redundante, lo que reduce en gran medida el costo de la alta disponibilidad.

Por qué debería preocuparse por la alta disponibilidad en la nube

Ahora, es posible que se pregunte por qué debería preocuparse en absoluto por la alta disponibilidad en la nube pública con garantías como estas de Amazon:

“Los volúmenes de Amazon EBS están diseñados para una tasa de falla anual (AFR) de entre 0.1% y 0.2%, donde la falla se refiere a una pérdida total o parcial del volumen, según el tamaño y el rendimiento del volumen. … Por ejemplo, si tiene 1,000 volúmenes de EBS ejecutándose durante 1 año, debe esperar que 1 o 2 tengan una falla ".

La verdadera pregunta es por qué, cuando evitar la pérdida de datos es un problema resuelto en las instalaciones, aceptaría incluso uno o dos volúmenes de EBS perdidos por año en la nube. No importa en qué negocio se encuentre, ya sean medios y entretenimiento, investigación genómica, conducción autónoma o incluso algo tan simple como carpetas de inicio, sus datos son valiosos. ¿Qué podría haber en esos volúmenes de EBS que está perdiendo cada año? ¿Cómo afectará su pérdida a su negocio? No hay forma de saberlo, y ese es un riesgo que ninguna empresa puede permitirse tomar a la ligera.

Y las garantías de Amazon ni siquiera tienen en cuenta las tasas de fallo de los nodos de cómputo, que pueden ser más altas de lo que cree. Las instancias de EC2 pueden fallar por una variedad de razones interesantes. Un caso común resulta del hecho de que AWS es, en esencia, un centro de datos de hardware compartido. Si una pieza de hardware va a someterse a mantenimiento o se retirará del servicio, será necesario mover su instancia de EC2, y eso provocará un reinicio. Un ejemplo aún más simple es cuando la pieza de hardware subyacente tiene un error que hace que todas las instancias que alberga se desplacen a otra pieza de hardware, lo que a su vez hace que esas instancias se reinicien. Cualquier reinicio hará que el nodo parezca fallar temporalmente, por lo que el tráfico deberá cambiar a un nodo activo.

Si un nodo de cálculo se desactiva, ONTAP conmutará por error desde el nodo activo al nodo sobreviviente. A menos que, por supuesto, sea el Administrador de nube de NetApp t2.micro el que falle. Si esto sucede, ha perdido el control del tráfico aéreo para todo su tráfico de almacenamiento en la nube pública, y no hay nada que mueva a los clientes de un nodo fallido al nodo sobreviviente. Ahora tienes un problema real. Al abordar el riesgo de un nodo fallido, NetApp Cloud Manager termina agregando una nueva condición de falla a la mezcla. Seguramente podemos esperar algo mejor para nuestras arquitecturas empresariales de próxima generación.

Un cuento con moraleja ...

NetApp ONTAP sirve como advertencia sobre trasladar la tecnología heredada a la nube pública sin tener en cuenta las diferencias inherentes en estos entornos. El enfoque nativo de la nube de Qumulo hace posible sobrevivir a fallas de disco y nodo sin introducir una mayor complejidad y sin un costo excesivo. Al tomarnos el tiempo para hacer las cosas de la manera correcta para cada tipo de infraestructura (local y nube pública), podemos brindarle la alta disponibilidad simple y confiable que necesita para los datos de los que depende su negocio.

Artículos Relacionados

Ir al Inicio