El DNS desempeña el papel de «guía telefónica» en el mundo de Internet. A medida que la configuración de múltiples nubes se ha vuelto cada vez más frecuente para los clientes empresariales. La integración de redes locales de propiedad del cliente con infraestructuras basadas en la nube para proporcionar una experiencia de resolución de nombres de dominio perfecta es vital para los entornos empresariales de los clientes.

enlace a la guía para Azure: aquí

enlace a la guía para AWS: aquí

Descripción del problema

En este artículo, abordamos estos escenarios, en los que los clientes de SAP RISE tienen sus cargas de trabajo de SAP alojadas en un entorno de nube administrado por SAP (en Azure, AWS, GCP o SAP Data Center), mientras que también pueden tener uno o ambos: el suyo propio en -Centros de datos locales y su propia suscripción a hiperescaladores (Azure, AWS o GCP). Y cada entorno de red tiene su propia configuración de DNS. El caos podría ocurrir si los nombres de dominio o los rangos de IP no se enrutaran correctamente.

Por lo tanto, estamos proponiendo una arquitectura de referencia para tales escenarios para resolver las solicitudes de DNS provenientes de todas las fuentes (entornos administrados de SAP RISE, servidores DNS del centro de datos en las instalaciones y servicios DNS de hiperescaladores propios del cliente), considerando la recuperación ante desastres.

Terminologías y abreviaturas

DNS: abreviatura de sistema de nombres de dominio. Se traduce entre nombres de dominio (como *.ecs.sap.com) y direcciones IP (como 192.168.1.1 en IPv4, 2400:cb00:2048:1::c629:d7a2 en IPv6) en ambos sentidos.

Transferencia de zona DNS: [SAP RISE preferred] uno de los mecanismos para replicar bases de datos DNS en un conjunto de servidores DNS. SAP RISE recomienda esto debido a: su alta disponibilidad; proporciona redundancia y mayor SLA, especialmente para escenarios DR; puede establecer un monitoreo de estado confiable. La desventaja es: los notificadores de DNS deben estar en su lugar para garantizar el retraso TTL de DNS completo.

Reenvío condicional de DNS (o el llamado ‘Reenvío de IP’): servidores DNS que solo reenvían consultas para nombres de dominio específicos. La ventaja es que, si no es necesario el tráfico saliente de SAP RISE, los clientes no tienen que configurar su propio DNS para su tráfico entrante. Las desventajas son: el OP DNS del cliente puede sufrir retrasos debido a la caché de reenvío (pero configurable); también debido a la caché de reenvío, la conmutación por error podría llevar más tiempo, por lo tanto, disminuir el SLA; monitoreo de estado limitado.

Delegación Zonal: un proceso de asignación de autoridad sobre un dominio o subdominio a diferentes servidores DNS para mantener actualizados los registros. La ventaja es que los clientes pueden administrar OP DNS a través de SAP RISE como un único punto. Las desventajas son: la configuración es onerosa; menor rendimiento debido al aumento del tráfico de DNS; SLA disminuido.

Consenso / Prerrequisitos

• Solo los servidores DNS del lado del servidor se han considerado en esta arquitectura de referencia, el DNS del lado del cliente (si corresponde) no se aborda aquí.
• No se ha considerado la recuperación ante desastres en el centro de datos del cliente
• Las conexiones de red para emparejar redes virtuales o conectar redes locales con la nube (como emparejamiento de VPC, emparejamiento de VNet, VPN, .etc) y otros componentes de red (como equilibrador de carga, .etc.) no se abordan en esta arquitectura de referencia. . Se crearán arquitecturas de referencia separadas en series de blogs posteriores.
• Los servidores DNS de SAP RISE se consideran recursos, y cada clúster de DNS virtualizado estándar implementado dentro de una zona contiene 2 servidores DNS para HA.
• Los servicios de DNS en los propios hiperescaladores del cliente se consideran servicios, y los clientes deben asegurarse de que HA/DR esté habilitado en el nivel de servicio
• En los casos de DR, lo llamamos por zona, en lugar de región, ya que los clientes de RISE pueden implementar SDDR (diferentes zonas dentro de la misma región) o LDDR (en diferentes regiones)
• Las ofertas de los hiperescaladores (Azure, AWS y GCP) se basan en la disponibilidad general de los servicios de la documentación oficial en línea de los proveedores de hiperescaladores (Microsoft, Amazon y Google), a partir de la fecha de publicación de este blog. Las ofertas de SAP RISE son basado en la guía de servicio de SAP ECS a la fecha de publicación de este blog

Diseño arquitectónico

en el lado de la suscripción de GCP del cliente:

Opción 1: el DNS de GCP es un servidor implementado en el motor de cómputo de GCP (ver Figura 1 y Figura 2)

• se aplica la transferencia de zona (enfoque de integración de DNS preferido de SAP RISE)

Opción 2: DNS de GCP es un servicio de GCP (ver Fig. 3 y Fig. 4), y SAP RISE no está en GCP

• Reenvío condicional de DNS se ha utilizado para integrar RISE DNS y OP DNS
• en el caso de DR, Cloud DNS es compartido por 2 VPC de la zona principal y la zona DR

Opción 3: DNS de GCP es un servicio de GCP (ver Fig. 3 y Fig. 4), y SAP RISE está en GCP

• Emparejamiento de DNS se utiliza para emparejar el DNS en la nube de GCP en SAP RISE y el DNS en la nube de GCP en el propio DNS en la nube de GCP del cliente
• el DNS en la nube de GCP interconectado en SAP RISE hará el reenvío condicional de DNS con el clúster DNS de SAP RISE

en el lado de la suscripción de SAP RISE:

• El clúster RISE DNS (que contiene 2 servidores DNS) se implementó dentro de la misma nube privada virtual que las máquinas virtuales administradas por SAP
• RISE DNS comparte información con OP DNS a través de la transferencia de zona DNS
• En el caso de DR, se implementa un clúster de DNS en cada zona, los 2 clústeres de DNS comparten información a través de la transferencia de zona de DNS

en el lado del centro de datos del cliente:

• OP DNS puede opcionalmente compartir alguna información con RISE DNS a través del reenvío condicional de DNS

Fig. 1: Arquitectura de referencia para la integración de DNS cuando el DNS de GCP del cliente es un servidor en GCP

Fig. 2: Arquitectura de referencia para la integración de DNS con DR considerada cuando el DNS de GCP del cliente es un servidor en GCP

Fig. 3: Arquitectura de referencia para la integración de DNS cuando el DNS de GCP del cliente es un servicio de GCP y SAP RISE no está en GCP

Fig. 4 Arquitectura de referencia para la integración de DNS con DR considerada cuando el DNS de GCP del cliente es un servicio de GCP y SAP RISE no está en GCP

Fig. 5: Arquitectura de referencia para la integración de DNS cuando el DNS de GCP del cliente es un servicio de GCP y SAP RISE está en GCP

Fig. 6 Arquitectura de referencia para la integración de DNS con DR considerada cuando el DNS de GCP del cliente es un servicio de GCP y SAP RISE está en GCP

Descargo de responsabilidad

• SAP no se responsabiliza de la gestión y operación del propio centro de datos de los clientes, ni de la suscripción del propio hiperescalador de los clientes.
• Los clientes de RISE deben proporcionar la información de DNS correspondiente, con respecto a la guía de SAP ECS
• Los clientes de RISE deben conocer los pros y los contras del enfoque de integración de DNS seleccionado

Agradecimiento a los colaboradores/revisores/asesores:

Ke Ma (también conocido como Mark), consultor sénior, SAP IES AI CoE/RISE con el grupo SAP RA

Jyothi Prakash Lakshmi, ingeniero de redes, SAP ECS

Richard Traut, experto en arquitectura de la nube, SAP RISE CAA

Kevin Flanagan, jefe de SAP RISE CAA EMEA Norte

Murad Mursalov, experto en arquitectura de la nube, SAP RISE CAA

Luc DUCOIN, experto en arquitectura de la nube, SAP RISE CAA

Sven Bedorf, Director de SAP RISE CAA MEE

Jires Sahakian Khongi, arquitecto de la nube, SAP RISE CAA

franco gong, Gerente de Compromiso con el Cliente DigitalSAP ECS