En este documento, se describen los beneficios y el enfoque recomendado para migrar tus cargas de trabajo y tu organización del DNS global al 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
Google Cloud ofrece dos tipos de nombres de DNS internos: zonales y globales.
- DNS zonal
Los nombres de DNS zonales incluyen el nombre de tu 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.com
es único parazone1
y representa una instancia diferente demy-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.
El DNS zonal es el método de resolución de DNS interno predeterminado para las organizaciones que se crearon 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 una desventaja significativa:
- Punto único de fallo: Si el servicio de DNS global tiene problemas, puede afectar a todas tus instancias, independientemente de 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 fallo: Si el servicio de DNS global tiene problemas, puede afectar a todas tus instancias, independientemente de la zona en la que se encuentren. Esto puede causar los siguientes problemas:
Las organizaciones que se incorporaron a Google Cloud antes del 6 de septiembre de 2018 están configuradas para usar el DNS global de forma predeterminada en los proyectos nuevos. Google recomienda enfáticamente migrar estos proyectos al DNS zonal para mejorar la confiabilidad y evitar las interrupciones del servicio mencionadas anteriormente. Además, debes actualizar la política de la organización para aplicar el uso de DNS zonal en todos los proyectos nuevos que se creen dentro de la organización.
Enfoque recomendado para migrar de DNS global a DNS zonal
En general, el proceso de migración del DNS global al DNS zonal tiene dos pasos:
- Configura los proyectos nuevos para que usen 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 internos.
Es posible que algunos proyectos no sean compatibles con el DNS zonal. Estos proyectos requieren análisis y solución de problemas antes de migrar a DNS zonal.
Limitaciones de migración
La evaluación de preparación que proporciona Compute Engine se basa en el historial de consultas de DNS interno de los últimos 30 días. Sin embargo, otros factores pueden afectar tu posibilidad de migrar correctamente al DNS zonal:
Versión de glibc
La migración al DNS zonal agrega un dominio nuevo a la ruta de búsqueda. Las instancias de Compute que ejecutan un SO Linux o Unix y usan glibc
versión 2.25 o anterior tienen un límite de 6 dominios de búsqueda. Si se supera este límite, se pueden generar problemas.
- Instancias afectadas: Esta limitación se aplica a las VMs que usan distribuciones de Linux o Unix anteriores.
- Instancias no afectadas: Instancias que no se ven afectadas por los siguientes sistemas operativos:
- Windows
- Container-Optimized OS
- Debian 10 o una versión posterior
- Fedora CoreOS (versión 27 o posterior)
- RHEL 8 o versiones posteriores
- Ubuntu 18.04 o una versión posterior
- Imágenes personalizadas que usan la versión 2.26 de
glibc
o una posterior
Para verificar la versión de glibc que usa tu instancia, haz lo siguiente:
- Conéctate a tu VM de Linux.
- Ejecuta el comando
ldd --version
.
Si tu instancia usa la versión 2.25 de glibc
o una anterior, verifica los dominios de búsqueda:
- Conéctate a tu VM de Linux.
- Ejecuta el comando
cat /etc/resolv.conf
.
Versión del SO
Algunos sistemas operativos, como Windows Server 2003 y versiones anteriores, tienen un límite de 15 caracteres para los nombres de las instancias de procesamiento. El DNS zonal agrega el calificador zonal al nombre de dominio completamente calificado (FQDN) del DNS interno.
La limitación de nombres en Windows es un resultado de la convención de nombres de NetBIOS que se usó en versiones anteriores del SO. Las versiones más recientes de Windows ya no tienen esta restricción y permiten nombres de instancias más largos.
Si trabajas con sistemas heredados de Windows, ten en cuenta la limitación de nombres cuando realices la migración a DNS zonales, ya que los nombres de DNS zonales más largos podrían exceder este límite de longitud de nombre.
Redes de VPC compartidas
Para resolver nombres de DNS de instancias en proyectos de servicio que usan VPC compartida, debes usar el nombre de dominio zonal completamente calificado (FQDN), que incluye la zona.
¿Qué sigue?
- Revisa la jerarquía de recursos deGoogle Cloud 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.