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 (HA). Cuando los datos son su negocio, como es el caso de todos los negocios hoy en día, cualquier pérdida puede tener consecuencias nefastas. Tienes que hacer todo lo posible para minimizar ese riesgo. Naturalmente, HA 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.
En las instalaciones, HA 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 que sirven los dispositivos agrupados, por lo que, en caso de que falle el dispositivo, la conexión del cliente puede cambiar sin problemas de un dispositivo a otro. Hay algunos mecanismos diferentes que se pueden usar para alejar las direcciones IP flotantes de los dispositivos defectuosos. Por ejemplo, tanto la plataforma BIG-IP de F5 Networks como Qumulo File Fabric utilizan una técnica llamada ARP gratuito para hacerse cargo de una dirección IP flotante que anteriormente atendía otro nodo. Otros sistemas utilizan el enrutamiento asincrónico para que solo un dispositivo vivo reciba tráfico. En ambos casos, es la propia red la que habilita la funcionalidad para una conmutación por error sin problemas desde un nodo con problemas a un nodo que está funcionando.
En entornos de nube pública, usted no posee ni controla la red. Aquí, son Amazon, Microsoft o Google quienes dictan 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 caché de ARP (también conocido como suplantación de identidad de ARP o enrutamiento de envenenamiento de ARP). Eso significa que cualquier dispositivo local que haya estado usando y que dependa de ARP para HA no funcionará. Como resultado, los proveedores de infraestructura necesitan encontrar un enfoque diferente para la alta disponibilidad en la nube.
Pruebe Qumulo para que AWS experimente el almacenamiento de archivos en la nube.
Las opciones para HA 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 que usa ONTAP de NetApp para la conmutación por error de IP en AWS. Como arquitectura clásica de almacenamiento ampliable, NetApp se basa en nodos emparejados donde los datos se duplican constantemente de un nodo a otro. En este caso, está manteniendo efectivamente dos copias de su almacén de datos, incurriendo en costos de cómputo, almacenamiento y software tanto para el nodo usado como para el no usado. Piense en ello como una forma de seguro de automóvil donde, 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 activa/en espera o activa/activa; ambos requieren que los datos se repliquen completamente. Ahora bien, esta implementación en sí no proporciona conmutación por error de IP; para eso, debe implementar un tercer sistema informático llamado NetApp Cloud Manager.
Cloud Manager es una instancia de t2.micro (que se muestra como el "mediador" arriba) dedicada a manejar la configuración de los sistemas ONTAP y proporcionar conmutación por error. Cloud Manager observa si hay una falla y luego cambia el enrutamiento de IP de activo a standby según sea necesario. Eso suena muy bien hasta que echamos un vistazo más de cerca a t2.micro, un tipo de instancia AWS EC2 con solo 1 vCPU y 1 GB de RAM. Convertirlo en el eje de su estrategia HA 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 una empresa de software ágil, Qumulo está en condiciones de pensar realmente en la solución correcta para cada problema, sin importar cuán difícil sea, y construirla para nuestros clientes. Teniendo en cuenta la complejidad y el riesgo del enfoque de HA en la nube de ONTAP, 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, usamos las API de AWS de cualquier miembro activo del clúster para cambiar una dirección IP flotante de un miembro del clúster inactivo a un miembro funcional. De esta manera, evitamos agregar otra capa de complejidad y también evitamos introducir un único punto de falla que fácilmente puede convertirse en un cuello de botella. Como beneficio adicional, nuestro enfoque elimina la necesidad de un clúster en espera redundante, lo que reduce en gran medida el costo de HA.
Ahora, es posible que se pregunte por qué debería preocuparse por HA en la nube pública dadas 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.
ONTAP de NetApp sirve como advertencia sobre el traslado de 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 las fallas del disco y del nodo sin introducir mayor complejidad y sin un costo excesivo. Al tomarnos el tiempo para hacer las cosas de la manera correcta para cada tipo de infraestructura (en las instalaciones y en la nube pública), podemos proporcionar la alta disponibilidad simple y confiable que necesita para los datos de los que depende su empresa.
