Caso de uso de Example Corp. Automotive
En esta sección del documento técnico se muestra cómo se utilizan las consideraciones, las preguntas de definición de requisitos y los árboles de decisiones para ayudarlo a decidir el diseño de red híbrida óptimo. Es importante identificar y capturar los requisitos, ya que se utilizan como información para los árboles de decisiones. Al capturar los requisitos por adelantado, se evitan iteraciones de diseño posteriores. Detener un proyecto por completo si hay que revisar el diseño y tener recursos valiosos en espera puede minimizarse e, idealmente, evitarse cuando los requisitos se conocen por adelantado.
En esta sección se utilizará Example Corp. Automotive como cliente ilustrativo. Desea implementar inicialmente su primer proyecto de análisis en AWS. El proyecto de análisis se centra en analizar los datos de los automóviles fabricados por la empresa y otros conjuntos de datos que ya existen en los centros de datos de la empresa. Inicialmente, el grupo de arquitectura de la empresa cree que necesitará una Cuenta de AWS, una Amazon VPC y unas cuantas subredes para alojar los entornos de producción y desarrollo. El equipo de proyecto está impaciente por empezar y ha solicitado acceso al entorno de desarrollo lo antes posible. Su objetivo es pasar a producción dentro de tres meses.
Example Corp. Automotive también tiene previsto utilizar AWS para varios proyectos adicionales, como la migración de sus sistemas ERP, la infraestructura de escritorios virtuales (VDI) y otras 20 aplicaciones desde las instalaciones a AWS en los próximos 6 meses. Todavía se están definiendo algunos requisitos para proyectos adicionales, pero está claro que su uso de Nube de AWS va a aumentar.
El equipo de arquitectura decidió aprovechar el enfoque descrito en este documento técnico. Utilizó las preguntas de definición de requisitos esbozadas en cada consideración para captar las aportaciones que lo permitieran tomar sus decisiones de diseño.
Comienza con los requisitos relacionados con el tipo de conectividad que se resumen en la siguiente tabla.
Table 4. Entradas de fiabilidad de Example Automotive Corp
| Consideraciones sobre la selección del tipo de conectividad | Preguntas sobre la definición de requisitos | Respuestas |
|---|---|---|
| Momento de implementación | ¿Cuál es el plazo requerido para la implementación? ¿Horas, días, semanas o meses? |
|
| Seguridad | ¿Permiten sus requisitos y políticas de seguridad utilizar conexiones cifradas a través de Internet para conectarse a AWS u obligan a utilizar conexiones de red privada? |
|
| Cuando se aprovechan las conexiones de red privada, ¿la capa de red tiene que proporcionar cifrado en tránsito? | No, se utilizará el cifrado de la capa de aplicación. | |
| SLA | ¿Se requiere un SLA de conectividad híbrida con créditos de servicio? |
|
| ¿Cuál es el objetivo de tiempo de actividad? |
|
|
| ¿Cumple toda la red híbrida el objetivo de tiempo de actividad? |
|
|
| Rendimiento | ¿Cuál es el rendimiento requerido? |
|
| ¿Cuál es la latencia máxima aceptable entre AWS y la red en las instalaciones? |
|
|
| ¿Cuál es la fluctuación de red máxima aceptable? |
|
|
| Costo | ¿Cuántos datos enviaría a AWS al mes? |
|
| ¿Cuántos datos enviaría desde AWS al mes? |
|
|
| ¿Esta conectividad es permanente? | Sí |
En función de los requisitos recibidos, el equipo de arquitectura siguió el árbol de decisiones del tipo de conectividad de la figura 9. Permitió al equipo de arquitectura decidir el tipo de conectividad para el desarrollo y los entornos de prueba y producción. Para el entorno de producción, tuvo en cuenta tanto los requisitos inmediatos como los futuros. Para el desarrollo y las pruebas Example Corp. Automotive establecerá una VPN de sitio a sitio a través de Internet. Para la producción, va a trabajar con un proveedor de servicios para conectar su red corporativa con AWS Direct Connect. Example Corp. Automotive consideró inicialmente utilizar una conexión alojada de Direct Connect. No obstante, debido a los requisitos de un SLA proporcionado por AWS
Tras decidir el tipo de conectividad, el siguiente paso consiste en captar los requisitos que influyen en la selección del diseño de conectividad. Esto está relacionado con el diseño lógico, por ejemplo, cómo se configuran las conexiones y qué servicios de AWS utilizar para respaldar los requisitos empresariales y técnicos.
Para captar los requisitos de escalabilidad y del modelo de comunicación, el equipo de arquitectura utilizó las preguntas de definición de requisitos de las secciones asociadas de este documento técnico. Los requisitos relacionados con esas dos consideraciones se resumen en la siguiente tabla.
Tabla 5. Preguntas sobre la definición de requisitos
| Consideraciones sobre la selección del diseño de conectividad | Preguntas sobre la definición de requisitos | Respuestas |
|---|---|---|
| Escalabilidad | ¿Cuál es el número actual o previsto de VPC que requieren conectividad con los sitios en las instalaciones? | 2 inicialmente, hasta 30 en 6 meses |
| ¿Se implementan estas VPC en una única Región de AWS o en varias? | Región única | |
| ¿Cuántos sitios en las instalaciones deben conectarse a AWS? | 2 centros de datos | |
| ¿Cuántos dispositivos de puerta de enlace de cliente tiene por sitio que necesita conectar a AWS? | 2 enrutadores por centro de datos | |
| ¿Cuántas rutas se espera que se anuncien a AWS VPC, así como el número de rutas que se espera recibir desde AWS? |
|
|
| ¿Hay algún plan para tener en cuenta el aumento del ancho de banda de la conexión a AWS en un futuro próximo? |
|
|
| Modelos de diseño de conectividad | ¿Es necesario habilitar la comunicación entre VPC (en una región o entre regiones)? | Sí, en una Región de AWS |
| ¿Existe un requisito para acceder a los servicios de puntos de conexión públicos de AWS directamente desde las instalaciones? | Sí | |
| ¿Existe algún requisito para acceder a los servicios de AWS mediante puntos de conexión de VPC desde las instalaciones? | No |
Basándose en las aportaciones, el equipo de arquitectura siguió el árbol de decisiones de la sección Diseño de conectividad. Tras prever que el número de VPC va a crecer de 2 a 30 en los próximos 6 meses, el equipo de arquitectura decidió utilizar AWS Transit Gateway como puerta de enlace de terminación de la conexión y el enrutamiento entre VPC. AWS Transit Gateways independientes terminarán la conexión de VPN utilizada para el desarrollo y las pruebas, y para la conectividad de producción con AWS Direct Connect. El uso de AWS Transit Gateway independientes simplifica la administración de los cambios y proporciona una demarcación clara entre los entornos de desarrollo/pruebas y producción. Para la producción, se requiere puerta de enlace de AWS Direct Connect debido a AWS Transit Gateway. Se utilizará una VIF pública para acceder a los servicios de puntos de conexión públicos de AWS. En la figura 14 se ilustra el recorrido realizado en el árbol de decisiones a partir de los requisitos recopilados.
Figura 14. Árbol de decisiones de diseño de conexiones de Example Corp. Automotive
Una vez decidida la solución para cumplir los requisitos de escalabilidad y modelo de comunicación, el siguiente paso es captar los requisitos asociados a la fiabilidad. Esto está relacionado con el nivel requerido de disponibilidad y resiliencia.
Para captar los requisitos de fiabilidad, el equipo de arquitectura utilizó las preguntas de definición de requisitos de la sección asociada de este documento técnico. Los requisitos se resumen en la siguiente tabla.
Tabla 6. Preguntas sobre los requisitos de fiabilidad
| Consideraciones sobre la selección del diseño de conectividad | Preguntas sobre la definición de requisitos | Respuestas |
|---|---|---|
| Fiabilidad | ¿Cuál es la magnitud del impacto en la empresa en caso de un error de conectividad a AWS? |
|
| Desde un punto de vista empresarial, ¿el costo de seguir un error de conectividad a AWS compensa el costo de implementar un modelo de conectividad de alta fiabilidad a AWS? |
|
Basándose en las aportaciones recibidas, el equipo de arquitectura siguió el árbol de decisiones de las secciones sobre consideraciones de fiabilidad tratadas anteriormente en este documento técnico. Tras considerar el objetivo de tiempo de actividad del 99,99 % para la conectividad de producción y el elevado impacto empresarial si se producía una interrupción del servicio, el equipo de arquitectura decidió utilizar dos ubicaciones de Direct Connect y disponer de dos enlaces desde cada centro de datos en las instalaciones a cada ubicación de Direct Connect (cuatro enlaces en total). La conexión de VPN utilizada para el desarrollo y las pruebas también utilizará dos conexiones de VPN para una redundancia adicional. Mediante las técnicas de ingeniería de rutas comentadas en la sección de fiabilidad, la conectividad se configurará de la siguiente manera:
-
Para el desarrollo y las pruebas, el tráfico va a tener una carga equilibrada mediante ECMP a través de los dos túneles que van al centro de datos principal. Esto permite un mayor rendimiento. Los túneles que van al centro de datos secundario se van a utilizar en caso de error de los túneles principales.
-
Para la producción, la latencia entre las instalaciones y AWS a través de cualquiera de las ubicaciones de Direct Connect es muy similar. En este caso, se ha decidido equilibrar la carga del tráfico entre AWS y en las instalaciones a través de las dos conexiones que van al centro de datos principal para los sistemas en las instalaciones implementados en el centro de datos principal. Del mismo modo, para los sistemas en las instalaciones que se ejecutan en el centro de datos secundario, el tráfico va a tener una carga equilibrada entre las dos conexiones al centro de datos secundario. En caso de error en las conexiones, BGP facilitará una conmutación por error automatizada.
En la figura 15 se ilustra el recorrido realizado en el árbol de decisiones a partir de los requisitos recopilados.
Figura 15. Árbol de decisiones de fiabilidad de Example Corp. Automotive
