En este documento, se describen los beneficios y el enfoque recomendado para migrar tus cargas de trabajo y tu organización de DNS global a DNS zonal.
El DNS zonal mitiga el riesgo de interrupciones interregionales y mejora la confiabilidad general de tus proyectos en Compute Engine.
Beneficios de usar nombres de DNS zonales
Cloud de Confiance by S3NS ofrece dos tipos de nombres de DNS internos: zonales y globales.
- DNS zonal
Los nombres de DNS zonales incluyen el nombre de la instancia de Compute Engine, la zona en la que se encuentra y el proyecto al que pertenece. Estos nombres se resuelven dentro de una zona específica. Como resultado,
my-vm.zone1.google.comes único parazone1y representa una instancia diferente amy-vm.zone2.google.com. Este aislamiento proporciona un beneficio clave:- Disponibilidad mejorada: Si una zona experimenta una interrupción, no afecta la resolución de DNS en otras zonas, lo que genera una mayor disponibilidad para tus aplicaciones.
Este es el método de resolución de DNS interno predeterminado para las organizaciones creadas después del 6 de septiembre de 2018.
- DNS global
Los nombres de DNS globales no incluyen la zona en la que se encuentra la instancia. Esto significa que cada instancia debe tener un nombre de DNS único en todas las zonas de tu proyecto. Este enfoque tiene un inconveniente importante:
- Punto único de falla: Si el servicio de DNS global experimenta problemas,
puede afectar a todas tus instancias, sin importar la zona en la que se encuentren. Esto puede causar los siguientes problemas:
- No se pueden crear instancias nuevas: Es posible que no puedas crear instancias nuevas en ninguna región que experimente fallas del plano de control.
- Interrupciones del servicio: Es posible que los servicios esenciales de Compute Engine, como el ajuste de escala automático o la reparación automática para grupos de instancias administrados (MIG), no funcionen correctamente.
- Punto único de falla: Si el servicio de DNS global experimenta problemas,
puede afectar a todas tus instancias, sin importar la zona en la que se encuentren. Esto puede causar los siguientes problemas:
Enfoque recomendado para migrar de DNS global a DNS zonal
En general, el proceso de migración de DNS global a DNS zonal tiene dos pasos:
- Configura proyectos nuevos para usar DNS zonal de forma predeterminada.
- Migra los proyectos existentes del uso de DNS global a DNS zonal cambiando la configuración de metadatos de dns interno.
Es posible que algunos proyectos no sean compatibles con el DNS zonal. Estos proyectos requieren análisis y solución de problemas antes de migrarlos al DNS zonal.
Guía de compatibilidad de proyectos
Compute Engine verifica tu historial de DNS interno de los 30 días anteriores para determinar si puedes migrar a DNS zonal sin realizar ningún cambio de código. Incluso si se recomienda migrar tu proyecto, Google te recomienda que verifiques que la configuración específica de tu carga de trabajo esté lista para el cambio a DNS zonal. Para asegurarte de que todo funcione sin problemas después de la migración, revisa los siguientes factores ambientales:
1. Dominios de búsqueda de DNS (solo para Linux o Unix)
Cuando cambias a DNS zonal, Compute Engine agrega un dominio nuevo a la ruta de búsqueda de la instancia.
- Cuándo verificar: Si ejecutas distribuciones de Linux o Unix más antiguas que usan la versión 2.25 o anterior de
glibc, el sistema tiene un límite máximo de seis dominios de búsqueda. Cuándo omitir: Si la instancia ejecuta alguno de los siguientes sistemas operativos, no necesitas verificar nada:
- Windows
- Container-Optimized OS
- Debian 10 o una versión posterior
- Fedora CoreOS 27 o una versión posterior
- RHEL 8 o una versión posterior
- Ubuntu 18.04 o una versión posterior
- Imágenes personalizadas con la versión 2.26 o posterior de
glibc
Cómo verificar tu entorno:
Conéctate a tu instancia de Linux y verifica la versión de
glibcejecutando el siguiente comando:ldd --versionSi usas la versión 2.25 o anterior de
glibc, ejecuta el siguiente comando para ver tus dominios de búsqueda actuales:cat /etc/resolv.confLa línea
searchen el resultado muestra los dominios de búsqueda actuales. No debes tener más de cinco dominios para agregar un dominio de búsqueda nuevo de forma segura y evitar exceder el límite del SO de seis.
Mitiga el problema
Si tu instancia excede el límite de dominio de búsqueda en una versión afectada del SO, puedes resolver la limitación con cualquiera de los siguientes enfoques:
- Crea una instancia nueva: Crea una instancia de reemplazo con una imagen de SO compatible (como Debian 10+ o RHEL 8+).
- Actualiza la instancia existente: Actualiza el SO invitado en tu instancia de procesamiento para que ejecute un sistema operativo compatible.
2. Longitud del nombre de la instancia (sistemas operativos heredados)
El DNS zonal agrega un calificador zonal al nombre de dominio completamente calificado (FQDN) interno, lo que hace que el nombre general sea más largo.
- Cuándo verificar: Los sistemas heredados, como Windows Server 2003 o versiones anteriores, tienen un límite de nombre de 15 caracteres debido a convenciones NetBIOS más antiguas.
- Qué hacer: Si usas estos sistemas heredados, verifica que los nombres de DNS zonales más largos no excedan este límite de caracteres.
Las imágenes modernas del SO Windows no se ven afectadas.
Mitiga el problema
Si un nombre de instancia en un SO heredado excede los 15 caracteres después de agregar el calificador zonal, puedes solucionar el problema con cualquiera de los siguientes métodos:
- Cambia el nombre de la instancia: Detén la instancia y cambia su nombre para que el FQDN combinado permanezca dentro del límite de NetBIOS de 15 caracteres.
- Actualiza el sistema operativo: Actualiza el SO invitado de la instancia de procesamiento a una imagen moderna del sistema operativo Windows para la que ya no se aplican las restricciones de nombres de NetBIOS.
3. Redes de VPC compartidas
Si tu infraestructura usa proyectos de servicio conectados mediante una VPC compartida, la resolución de nombres se comporta de manera ligeramente diferente después de que cambias al uso de DNS zonal.
- Qué hacer: Para garantizar una comunicación fluida en tu VPC compartida, verifica que tus aplicaciones resuelvan los nombres de las instancias dentro de esos proyectos de servicio con el FQDN zonal. El FQDN zonal incluye el nombre de zona específico.
¿Qué sigue?
- Revisa la Cloud de Confiance by S3NS jerarquía de recursos para obtener información sobre la relación entre organizaciones, carpetas y proyectos.
- Obtén más información sobre el DNS interno para Compute Engine.
- Implementa una política de la organización para garantizar que todos los proyectos nuevos de tu organización usen automáticamente el DNS zonal.
- Migra los proyectos actuales al DNS zonal.