
Una de las frases que oyes asociados a la computación en nube es "arquitectura de fracaso." En lugar de construir en una gran cantidad de redundancia a nivel de hardware - energía, disco, red, etc ... - la idea es que se espera que falle y puede simplemente reemplazar la aplicación (que es lo que importa, ¿no?) Con un clonar ejecutando en el mismo hardware barato en otro lugar del centro de datos.
Idea Impresionante, ¿verdad?
Pero cuando se llega a esto, los entornos de cloud computing están diseñada para la escala, nunca faltan.
Escala frente FALLO
La mayoría de clase empresarial de los centros de datos han sido diseñados con la falla en la mente, nos llaman a estos de alta disponibilidad (HA) arquitecturas. El objetivo es asegurar que si algún elemento de la ruta de datos falla que otro puede casi de inmediato tomar su lugar. Dentro de una plataforma de hardware, esto implica dos fuentes de alimentación, un nivel de RAID de alta y gestión de apagar las luces. En la red y de nivel superior, esto requiere elementos de red redundantes - de los equilibradores de carga a los conmutadores a los routers a los cortafuegos, servidores, todos los elementos deben ser duplicados para garantizar una conmutación (cerca) inmediata en el caso de un fallo. Esto generalmente requiere de configuraciones y de apoyo para las direcciones IP flotantes (compartidos) a través de elementos redundantes, lo que permite la redirección de inmediato después de la detección de un fallo de aguas arriba.
En el nivel de aplicación / servidor, el concepto de direcciones compartida todavía se aplica pero se hace así en el equilibrio de carga de capa, donde VIP (direcciones IP virtuales) actuar como instancia virtual de la aplicación. Un nodo principal (servidor) es designado que se activa con un ser secundario designado como el "backup" instancia que permanece inactivo en * modo "standby".
Si la instancia primaria falla - ya sea por hardware o software o fallo de la red - el secundario, se activará inmediatamente, y la continuidad del servicio está asegurada por el hecho de que las sesiones existentes son gestionados por el servicio de equilibrio de carga, no el servidor. En el caso de un elemento de red falla, la continuidad (de alta disponibilidad) se consigue gracias a la duplicación (replicación) de esas mismas sesiones entre el activo (primario) y de reserva (elementos secundarios).
![]()
¿Es perfecto? No, pero proporciona menos de un segundo la respuesta al fracaso, lo que significa que los niveles muy altos dedisponibilidad(o como me gusta llamarlo, failability).
Eso está diseñada para " FALLA ".
Ahora, la mayoría de los entornos de computación nube tienen una arquitectura no con fallo en mente, pero con escala en mente - es decir, que están diseñados para permitir elasticidad (fuera de escala, en escala) que es, en parte, basado en la capacidad para obtener rápidamente los recursos requerida.
Un ejemplo de equilibrio de carga que se requiere y que funciona de la misma manera que una arquitectura de alta disponibilidad (menos la redundancia).El servicio de equilibrio de carga actúa como la aplicación virtual, con al menos una instancia detrás de él. A medida que aumenta la demanda, las nuevas instancias se aprovisionan y se añade al servicio para garantizar que el rendimiento y la disponibilidad no se vean afectados. Cuando este proceso también es capaz de escalar de nuevo en forma automática la supresión de las situaciones cuando los contratos de demanda se llama "elasticidad".
Si la instancia disponible sólo falla, esta arquitectura no va a proporcionar una alta disponibilidad de la aplicación, ya que se necesita tiempo para iniciar una instancia de reemplazarlo. Incluso si hay diez instancias activas y no uno, el rendimiento y / o disponibilidad para algunos clientes puede verse afectado porque, como ya se ha señalado, se necesita tiempo para iniciar una instancia de reemplazarlo.
Del mismo modo, si un elemento aguas arriba falla, como el balanceo de carga de trabajo, la disponibilidad puede verse negativamente afectada - porque se necesita tiempo para reemplazarlo.
Sin embargo, cuando se considera qué tan bien el sistema responde a los cambios en la demanda de recursos, funciona bien. Esa es la escalabilida
|
No hay comentarios:
Publicar un comentario