¿Hay características o funciones que todas las capas de orquestación en la nube simplemente no tienen, pero sería genial tener?

Hola joe

En primer lugar, gracias por responder a mi pregunta. Me parece que la gente todavía está entrando en el campo de la computación en la nube y que realmente no han pensado demasiado en ella ni en su complejidad ni en su potencial.

De todos modos, mover grandes datos de un área a otra. ¿Quiso decir en un escenario de recuperación de desastres o conmutación por error o quiso decir solo en general?

Recibo esta pregunta mucho en un escenario de conmutación por error y ya es posible, pero no tiene sentido a menos que tenga un equipo y una red muy buenos. Tampoco está integrado en ninguna solución de orquestación en la nube (que sé si).

¿Te refieres a una nube diferente ya que estás ejecutando dos instancias de nube del mismo tipo … es decir? openstack / openstack o diferente como Abiquo / Open Nebula?

Esto último, creo que podría ser un obstáculo porque es difícil para una empresa de código cerrado proporcionar tanta compatibilidad. No es porque no se pueda hacer, sino que requiere muchos recursos.

————————–

En cuanto al traslado de datos de una región a otra en general; la capacidad existe, pero aún no se ha admitido en ninguna capa de orquestación que conozca todavía. La función se llama clonación donde tiene una configuración activa / pasiva de (por ejemplo) una sola VM y esa VM tiene una copia de sí misma en un área diferente, por lo que si algo afecta a la primera VM, la segunda se activa.

La distancia entre máquinas virtuales, si es grande, se verá afectada por la red. Obviamente, la fibra P2P entre zonas, centros de datos o incluso países es la mejor opción y mantener vivo un entorno de múltiples inquilinos significaría la creación de incrementos constantes en el lado pasivo. Siempre habrá un retraso en la replicación. Cuanto más lejos esté, mayor será la diferencia de los posibles datos perdidos.

También debe tener en cuenta que, si se trata de un entorno en vivo que se traslada a otro entorno en vivo, no funcionaría a menos que no tuviera sus propias IP portátiles. Ok, entonces no soy un hombre de redes, pero no creo que pueda transmitir VM desde una red diferente y redirigirla a otra, especialmente si la red original está inactiva. la única forma de evitar esto sería alojar su DNS en otro lugar y empujar físicamente las zonas a la ubicación secundaria.

Estaríamos hablando de más de 2 rangos de IP donde cada rango podría pertenecer a un proveedor diferente … ¿cómo lo haría de otra manera, pero si tuviera sus propias IP portátiles, podría facilitarlo?

ENTONCES, si resulta ser un movimiento continental, estamos hablando de diferentes bloques de IP todos juntos. ARIN / RIPE / APNIC / LACNIC / AFRICNIC etc. etc.

Sé que OnApp ha integrado AnyCast DNS para su nube en caso de que el administrador decida usarlo y aparentemente hace que la zona se empuje sola. OnApp simplemente no admite la clonación todavía. Su DNS es en realidad para la federación CDN integrada, que es otra cosa en conjunto y es solo una parte de su solución IaaS.