Share via

Preparación del entorno para un escenario híbrido y multinube

  • Artículo

La metodología de preparación de Cloud Adoption Framework guía a los clientes mientras preparan su entorno para la adopción en la nube. En la metodología se incluyen aceleradores técnicos como zonas de aterrizaje de Azure, que son los bloques de creación de cualquier entorno de adopción de la nube de Azure.

Esta guía puede ayudarle a elegir la zona de aterrizaje adecuada que implementar para su organización.

Escenario híbrido y multinube en las zonas de aterrizaje

Las zonas de aterrizaje de Azure son la salida de un entorno de Azure con varias suscripciones que tiene en cuenta lo siguiente:

  • Escala
  • Gobernanza de la seguridad
  • Redes
  • Identidad
  • Administración de costos
  • Supervisión

Las consideraciones sobre el entorno podrían ser ligeramente diferentes al preparar una implementación híbrida y multinube. Un entorno coherente para cualquier implementación híbrida y multinube requiere que tenga en cuenta lo siguiente:

  • Topología de red y conectividad
  • Controles unificados de procesos operativos para operaciones, gobernanza, seguridad y cumplimiento
  • Materias de automatización, experiencia de desarrollo y prácticas de DevOps unificadas y coherentes en todos los entornos heterogéneos

Azure Arc permite arquitecturas híbridas y multinube y contiene un conjunto de tecnologías. Cada una de las arquitecturas que permite incluye todas las áreas de diseño críticas y las consideraciones que necesita para crear una implementación correcta.

Evaluación de la combinación de la nube

La elección de un entorno híbrido y multinube implica una serie de decisiones en lugar de una sola decisión binaria. Antes de configurar el entorno de Azure, identifique cómo admitirá el entorno en la nube su combinación específica de opciones de hospedaje en la nube. En el diagrama siguiente se incluyen algunos ejemplos de combinaciones de nube habituales:

Diagrama que muestra tres ilustraciones sobre cómo diferentes clientes distribuyen cargas de trabajo entre proveedores de la nube.

En este diagrama, cada punto azul oscuro es una carga de trabajo, y cada círculo azul claro es un proceso empresarial, admitido por un entorno distinto.

Todas las combinaciones de nube requieren una configuración del entorno de Azure diferente. Puede verlo con nuestros tres clientes de referencia:

  • Cliente de híbrida en primer lugar: La mayoría de las cargas de trabajo se mantienen en el entorno local, a menudo en una combinación de modelos de hospedaje de recursos tradicionales, híbridos y portables. Se implementan algunas cargas de trabajo específicas en el perímetro, en Azure o en otros proveedores de nube.

    • Fabrikam es un cliente híbrido en primer lugar con una gran inversión en centros de datos envejecidos. Sus prioridades más altas son el costo y la gobernanza. Las prioridades de TI heredadas y la infraestructura tecnológica antigua dificultan la innovación de Fabrikam, lo que lleva a una adopción temprana de la nube.

  • Cliente de Azure en primer lugar: la mayoría de las cargas de trabajo se migran a Azure, mientras que algunas permanecen en el entorno local. Debido a las decisiones estratégicas, algunas cargas de trabajo residen en el perímetro o en entornos multinube.

    • Contoso es un cliente Azure en primer lugar. Al igual que Fabrikam, completó su primera ola de transformación digital, adquirió algunas empresas y sumó clientes en sectores regulados. Su mayor prioridad sigue siendo la innovación, pero, con su entorno multinube, se centra en la administración de operaciones. Necesita operaciones eficaces y escalables para continuar con su estrategia de adquisición.

  • Cliente multinube en primer lugar: la mayoría de las cargas de trabajo se hospedan en una nube pública diferente, como Google Cloud Platform (GCP) o Amazon Web Services (AWS). Debido a las decisiones estratégicas, algunas cargas de trabajo residen en Azure o en el perímetro. Los clientes suelen pasar de una combinación híbrida en primer lugar a una combinación de Azure en primer lugar a medida que madura su estrategia de la nube, pero también apoyamos a los clientes que deciden que las combinaciones híbrida o multinube sean su prioridad. Azure desempeña un papel en cada tipo de combinación.

    • Tailwind Traders es un cliente multinube en primer lugar. Igual que Contoso, se ha pasado a la nube, pero no usó Azure para hacerlo. Tiene algunos recursos de centro de datos locales y dispositivos perimetrales. Tailwind Traders es uno de los usuarios pioneros en adoptar otras nubes en una fase inicial y su mayor prioridad es el crecimiento. Los requisitos minoristas de los clientes y la necesidad de operaciones mejoradas que habiliten un escalado eficaz impulsan el crecimiento de los entornos híbrido y multinube.

Algunas consideraciones son fundamentales para preparar cualquier entorno en la nube para entornos híbrido y multinube. La estrategia híbrida y multinube para aplicaciones y datos impulsa las respuestas a las preguntas siguientes. Identifique con claridad qué combinación de la nube necesita y, a continuación, considere la mejor configuración para sus entornos.

  • ¿Qué combinación de entornos híbridos, perimetrales y multinube admite hoy?
  • ¿Qué combinación se alinea mejor con su estrategia para el futuro?
  • ¿Quiere usar cada plataforma de forma independiente o a través de un enfoque de operaciones unificadas y un único panel?

Introducción a Azure Arc

Puede que usted quiera simplificar entornos complejos y distribuidos en todos los entornos locales, perimetrales y multinube. Azure Arc permite implementar servicios de Azure en cualquier lugar y extiende la administración de Azure a cualquier infraestructura.

  • Organización y gobernanza en todos los entornos: obtenga las bases de datos, los clústeres de Kubernetes y los servidores que se extienden por los entornos locales, perimetrales y multinube bajo control mediante la organización y el control centralizados desde un único lugar.

  • Administración de aplicaciones de Kubernetes a gran escala: use técnicas de DevOps para implementar y administrar aplicaciones de Kubernetes en entornos. Asegúrese de implementar y configurar las aplicaciones de forma coherente desde el control de código fuente.

  • Ejecución de los servicios de Azure en cualquier lugar: consiga una aplicación automatizada de revisiones, actualizaciones, seguridad y escala a petición en todos los entornos locales, perimetrales y multinube para su patrimonio de datos.

Instantánea de cliente de Azure Arc

Los tres clientes de referencia mencionados anteriormente ejecutan cargas de trabajo en hardware diferente. También ejecutan cargas de trabajo en todos los centros de datos locales y varios proveedores de nube pública y admiten cargas de trabajo de IoT implementadas en el perímetro. Sus cargas de trabajo incluyen varios servicios y se basan en servidores sin sistema operativo, máquinas virtuales, servicios de plataforma como servicio (PaaS) administrados o aplicaciones nativas de nube basadas en contenedores.

Los tres clientes se dan cuenta de que necesitan tener prácticas híbridas y multinube para lograr éxito empresarial. La necesidad de cargas de trabajo modernizadas es crucial para la relevancia de los tres clientes en sus áreas respectivas.

Con Azure Arc como su plano de control híbrido y multinube, estos clientes pueden usar las inversiones de TI existentes y las prácticas operativas actuales de forma no distributiva. Para seguir usando sus prácticas actuales, los clientes incorporan servidores habilitados para Azure Arc, servidores SQL y clústeres de Kubernetes. Usan los servicios de datos habilitados para Azure Arc, los servicios de aplicaciones y los servicios de aprendizaje automático para modernizar sus cargas de trabajo, a la vez que cumplen los requisitos de soberanía de datos.

Azure Arc amplía las API de Azure Resource Manager (ARM) para que usted pueda representar cualquier carga de trabajo como ciudadano de primera clase en Azure. Esta extensión proporciona la base para que implemente operaciones unificadas, administración, cumplimiento, seguridad y gobernanza a gran escala. Se implementa con:

  • Supervisión centralizada
  • Registro
  • Telemetría
  • Directivas
  • Administración de revisiones
  • seguimiento de cambios
  • Administración de inventario
  • Detección de amenazas
  • Administración y auditoría de vulnerabilidades de seguridad

Diagrama que muestra la información general de Azure Arc.

Configuración del entorno de Azure inicial

Para cada una de las combinaciones de nube, necesitará un entorno de Azure para admitir, controlar y administrar los recursos de nube. La metodología de preparación de Cloud Adoption Framework proporciona unos pocos pasos para ayudarle a preparar su entorno:

Azure Arc como acelerador de zona de aterrizaje

Los recursos de Azure Arc pueden formar parte de cualquier aplicación. Algunos ejemplos son:

  • Servidores habilitados para Azure Arc que representan recursos de TI implementados fuera de Azure.
  • Clústeres de Kubernetes administrados por el cliente en un entorno multinube.
  • Servicios de datos, aplicaciones y aprendizaje automático habilitados para Azure Arc que funcionan en el perímetro.

Las suscripciones de zona de aterrizaje de aplicación también pueden contener tanto recursos de Azure Arc como recursos normales de Azure.

Dado que los recursos de Azure Arc se encuentran fuera de Azure, puede considerarlos un recurso de metadatos en la forma en que se representan en Azure. Trate los recursos de Azure Arc como cualquier otro recurso de Azure que pueda formar parte de su zona de aterrizaje. No importa si es una plataforma o aplicación, y sigue los principios de diseño centrados en la aplicación y la democratización de la suscripción y de arquetipo neutro.

Diagrama que muestra un diseño de zona de aterrizaje.

Ejemplos comunes de recursos de Azure Arc en zonas de aterrizaje de Azure

En los ejemplos siguientes se muestra cómo puede proyectar recursos de Azure Arc como recursos de metadatos en zonas de aterrizaje de Azure.

Ejemplo uno: proyección de controladores de dominio fuera de Azure

Muchos clientes tienen implementaciones de Active Directory Domain Services (AD DS) dentro de sus entornos. Los controladores de dominio son un componente crítico de AD DS y la arquitectura general de los clientes.

Dentro de la arquitectura conceptual de la zona de aterrizaje de Azure, hay una suscripción de zona de aterrizaje de identidad dedicada que está diseñada para hospedar recursos basados en identidades. Puede hospedar esta suscripción en Azure mediante máquinas virtuales (VM) del controlador de dominio (DC) de AD DS. También puede proyectarla en Azure desde cualquier otra ubicación a través de servidores habilitados para Azure Arc.

Ejemplo dos: proyección de centros de datos locales en Azure

En la mayoría de los clientes sigue habiendo centros de datos locales presentes en sus entornos. Las superficies de estos centros de datos pueden variar de servidores únicos a entornos virtualizados de gran tamaño.

Los clientes pueden tratar sus centros de datos locales como zonas de aterrizaje normales y colocarlos en zonas de aterrizaje nuevas o existentes si ven que caben. Algunos enfoques comunes incluyen:

  • Movimiento de los recursos del proyecto a suscripciones de zona de aterrizaje dedicadas para los recursos del centro de datos local.
    • En entornos más grandes con varios centros de datos en todo el mundo, es posible que los clientes tengan una zona de aterrizaje por región geopolítica. Estas zonas de aterrizaje también contienen los recursos de esa región para proporcionar una separación lógica de los centros de datos locales en Azure.
    • Este enfoque también puede ayudar con los requisitos de seguridad, gobernanza y cumplimiento para diferentes centros de datos locales.
  • Movimiento de los recursos del proyecto a suscripciones de zona de aterrizaje independientes en función de otros recursos de Azure que admitan la misma aplicación o servicio.

Ejemplo tres: proyección de recursos de aplicación remota en Azure

Los clientes pueden desarrollar aplicaciones sensibles a la latencia o aplicaciones con requisitos de soberanía de datos. Es posible que estas aplicaciones necesiten hospedar recursos que forman parte de su aplicación fuera de Azure. Los clientes siguen queriendo controlar, gobernar, proteger y operar todos los recursos que crean su aplicación de forma centralizada. Azure Arc permite a los clientes lograr este objetivo.

En este escenario, los clientes deben proyectar los recursos de Azure Arc para su aplicación en la misma suscripción de zona de aterrizaje de aplicación en la que implementan recursos de Azure. A continuación, los clientes pueden aplicar un conjunto de controles a todos los recursos desde un solo plano de control independientemente de dónde estén los recursos.

Ejemplo cuatro: proyectar servidores locales que llegaron al final del soporte técnico en Azure para usar las Actualizaciones de seguridad extendidas que se entregan a través de Azure Arc

Muchos clientes tienen versiones de Windows Server que están cerca del final del soporte técnico y no pueden cumplir la fecha límite de finalización del soporte técnico, pero deben permanecer en el entorno local. En este escenario, buscarían comprar Actualizaciones de seguridad extendidas habilitada por Azure Arc.

Si los clientes implementan una zona de aterrizaje de Azure o ya tienen una implementada, los clientes pueden tratar sus centros de datos locales como zonas de aterrizaje normales y colocarlos en zonas de aterrizaje nuevas o existentes según se ajusten. Algunos enfoques comunes incluyen:

  • Movimiento de los recursos del proyecto a suscripciones de zona de aterrizaje dedicadas para los recursos del centro de datos local.

  • En entornos más grandes con varios centros de datos en todo el mundo, es posible que los clientes tengan una zona de aterrizaje por región geopolítica. Estas zonas de aterrizaje también contienen los recursos de esa región para proporcionar una separación lógica de los centros de datos locales en Azure.

  • Este enfoque también puede ayudar con los requisitos de seguridad, gobernanza y cumplimiento para diferentes centros de datos locales.

  • Movimiento de los recursos del proyecto a suscripciones de zona de aterrizaje independientes en función de otros recursos de Azure que admitan la misma aplicación o servicio.

  • Los clientes deben revisar las instrucciones del acelerador de zonas de aterrizaje de servidores habilitados para Azure Arc para revisar las consideraciones y recomendaciones de diseño en las áreas de diseño críticas.

Si los clientes no tienen o no planean implementar una zona de aterrizaje de Azure en este momento:

  • Los clientes deben revisar las instrucciones del acelerador de zonas de aterrizaje de servidores habilitados para Azure Arc para revisar las consideraciones y recomendaciones de diseño en las áreas de diseño críticas.

Diagrama que muestra un gráfico de flujo para las instrucciones de zona de aterrizaje de Azure Arc.

Pasos siguientes

Para más información sobre el recorrido de nube híbrida y multinube, consulte los siguientes artículos.