¿Cómo debería diseñarse un DNS híbrido multicloud para dar soporte a las migraciones a la nube sin crear un caos de reenvíos inestable?
migraciones a la nuberedes híbridas/BlueCat/
Updated
El DNS híbrido multicloud funciona cuando una DDI centralizada, una gobernanza clara y los servicios integrados de los proveedores de nube sustituyen a los reenviadores ad hoc y a las copias de zonas por una arquitectura deliberada y observable.
· 01 — Reconocer los retos del DNS híbrido multicloud en las primeras fases de las migraciones a la nube
¿Qué nuevos retos de DNS y conectividad plantea la red híbrida multicloud durante las migraciones a la nube?
Las redes híbridas multicloud introducen redes virtuales segmentadas,
a solapamientos en el espacio de IP, a espacios de nombres DNS fragmentados y a nuevas fronteras de seguridad que hacen que la conectividad, la seguridad y la observabilidad sean significativamente más complejas que en las redes tradicionales de los centros de datos.
Las redes en la nube sustituyen los conocidos dominios de Capa 2 y los límites claros entre lo público y lo privado por VPC, enlaces de peering, puertas de enlace y puntos finales privados repartidos entre distintos proveedores. Los microservicios y Kubernetes aumentan el número de servicios y nombres DNS, mientras que los diseños multinube crean un espacio IP superpuesto y espacios de nombres fragmentados que superan las competencias habituales de los equipos de nube.
La seguridad en estos entornos depende del uso coherente de herramientas de microsegmentación, listas de control de acceso a la red y controles más amplios, como SASE y «zero trust», que abarquen tanto la nube como las instalaciones locales. Una observabilidad eficaz requiere una agregación coordinada de la telemetría, incluidos los datos de DNS, entre equipos y plataformas porque, como se ha señalado, «una observabilidad eficaz requiere la recopilación, la agregación y el análisis coordinados de datos procedentes de numerosas fuentes».
Collaboration is the key to gaining control over the cloud networking challenges of connectivity, security, and observability. Learn more with BlueCat.
8 min·Blog
Leer más →
· 02 — Recuperar la visibilidad de DDI a medida que los equipos de la nube y de DevOps crean su propio DNS
¿Cómo pueden los equipos de DDI recuperar el control cuando los equipos de la nube y de DevOps gestionan su propio DNS y espacio IP?
Los equipos de DDI recuperan el control al establecer una única fuente de información fiable para el DNS, el DHCP y el IPAM
en entornos locales y en la nube, junto con una visibilidad completa de las consultas de DNS y un descubrimiento automatizado que sustituye a las estructuras de reenvío manuales.
La adopción de la nube híbrida suele dejar a los equipos centrales de DDI sin visibilidad sobre el uso del DNS y las direcciones IP en la nube, lo que crea silos, un espacio de direcciones fragmentado y rangos superpuestos que aumentan el riesgo de conflictos y de interrupciones del servicio. Como señala Andrew Wertkin, «es necesaria una única fuente de verdad para impulsar con éxito cualquier nivel de automatización», ya que la creación de scripts a partir de datos parciales genera fallos de forma fiable.
Depender de redireccionadores condicionales y zonas stub mantenidos manualmente para unir el DNS en la nube y el local da lugar a configuraciones frágiles y difíciles de escalar que degradan la experiencia del usuario. Para recuperar el control es necesario disponer de un descubrimiento automatizado de las asignaciones de DNS e IP en la nube, además de visibilidad a nivel de consulta —«Tenemos que poder ver cada una de las consultas DNS»— de modo que las rutas de resolución híbridas, las políticas y la automatización puedan gestionarse de forma centralizada.
In an ONUG webinar, BlueCat’s Andrew Wertkin explains how DNS, DHCP, and IPAM visibility is key to automation and taming four hybrid cloud challenges.
6 min·Blog
Leer más →
· 03 — Integrar el DNS de la empresa y el del proveedor de la nube sin un «salvaje oeste» de zonas
¿Cómo deberían integrarse el DNS de la empresa y el del proveedor de la nube para que los entornos híbridos multinube eviten un «salvaje oeste» de zonas duplicadas?
Los entornos híbridos multinube deberían utilizar una arquitectura DNS integrada que combine deliberadamente el DNS de la empresa y el del proveedor de nube,
evita la duplicación de zonas y los reenvíos ad hoc, y aplica una gobernanza rigurosa en materia de nomenclatura, RBAC y seguridad entre los distintos proveedores.
Las empresas no pueden, en la práctica, estandarizarse únicamente en un DNS local o únicamente en uno en la nube; «deben diseñar una arquitectura integrada que utilice ambos cuando sea necesario». Permitir que cada equipo de la nube copie registros, duplique zonas y cree redireccionadores puntuales da lugar a un«salvaje oeste» que socava la visibilidad y aumenta la complejidad operativa.
Dado que el DNS de cada proveedor de servicios en la nube se comporta de forma diferente, los arquitectos necesitan patrones específicos para cada proveedor que, al mismo tiempo, se integren en una estrategia global coherente de nomenclatura y seguridad. Los diseños híbridos de DNS deben crearse explícitamente para hacer frente a los cambios y los fallos, con planes claros para la pérdida de conectividad, el almacenamiento en caché local y las rutas de reenvío cambiantes, de modo que los cambios y las interrupciones del DNS no afecten a las aplicaciones dependientes.
Networking pros explore integrating enterprise and cloud DNS during the fifth Critical Conversation on Critical Infrastructure hosted in Network VIP.
67 min·Blog
Leer más →
· 04 — Sustituir los reenviadores condicionales, que son poco fiables, por un DDI híbrido unificado
¿Cómo puede el DNS híbrido multicloud ir más allá de un frágil mosaico de redireccionadores condicionales?
El DNS híbrido multinube va más allá de los reenviadores condicionales, que son poco fiables, al estandarizarse en una única fuente de verdad DDI empresarial
que se integre con el DDI nativo de la nube o lo sustituya, y gestionando la resolución de DNS de múltiples rutas de forma centralizada en lugar de mediante reglas ad hoc por entorno.
La centralización en una plataforma DDI empresarial que actúe como plano de datos y control de referencia permite gestionar las rutas de resolución de DNS híbridas de una sola vez, al tiempo que se integra con los servicios nativos de la nube cuando sea necesario. La implementación de la resolución de DNS multipath con redireccionamiento automático en NXDOMAIN mejora la fiabilidad, la visibilidad y el control operativo, ya que el mismo sistema que conoce los registros también controla cómo las consultas atraviesan el entorno local y la nube.
Public clouds handle their own DDI. But problems arise when applications have to access data or services through the native DDI of multiple environments.
5 min·Blog
Leer más →
· 05 — Reducir la proliferación de reglas de reenvío condicionales en el DNS de la nube híbrida
¿Cómo pueden los equipos de DNS de la nube híbrida reducir el riesgo y el esfuerzo que supone gestionar miles de reglas de reenvío condicionales?
Los equipos de DNS de la nube híbrida reducen la proliferación de reglas de reenvío mediante la estandarización en una plataforma DDI centralizada
que sustituya los reenviadores condicionales individuales por una resolución multipath automatizada y priorizada, gestionada desde una única interfaz IPAM.
a miles dede servidores de reenvío
a miles de de servidores de reenvío
Los entornos de nube híbrida acumulan habitualmente miles de reglas de reenvío de DNS condicionales, lo que concentra el riesgo y la carga operativa en un pequeño grupo de expertos en DNS.
«Los entornos de nube híbrida suelen obligar a los equipos de red a gestionar miles de reglas condicionales de reenvío de DNS para salvar las brechas de resolución de nombres entre la nube y las instalaciones locales». Esta complejidad concentra el conocimiento tribal en unos pocos especialistas, retrasa la prestación del servicio y aumenta el riesgo de interrupciones, al tiempo que empuja a los equipos de DevOps y de la nube hacia soluciones alternativas de TI en la sombra, al margen de la gobernanza de la red.
· 06 — Ampliar el control centralizado de DDI a entornos nativos de la nube
¿Cómo pueden los equipos de redes ampliar el control centralizado de DDI al DNS nativo de la nube sin ralentizar a los desarrolladores?
Los equipos de redes amplían el control centralizado de DDI a los entornos nativos de la nube mediante el uso de una plataforma DDI coherente que se sincroniza con los recursos DNS e IP asignados por la nube,
ofrece servicios de DNS localizados y admite la administración delegada, de modo que los equipos de la nube conservan su agilidad bajo políticas compartidas.
«Un DNS en la nube aislado y una infraestructura local gestionada por separado merman el control centralizado de DDI», lo que da lugar a conflictos, una fiabilidad reducida y una responsabilidad poco clara. No basta con añadir simplemente el registro de eventos; los equipos de infraestructura necesitan una plataforma de DDI centralizada y coherente que «amplíe las capacidades locales a los entornos en la nube» para proporcionar servicios DNS locales al tiempo que se aplica la política global.
When cloud and on-premises DNS are separate, enterprise-wide control is out of reach. Learn how BlueCat can provide a single source of truth for DNS.
5 min·Blog
Leer más →
· 07 — Caminos a seguir
¿Qué modelo híbrido de DNS multicloud tiene sentido para las redes que deben modernizarse sin interrumpir los servicios existentes?
La estrategia adecuada para un DNS híbrido multicloud depende de si la prioridad inmediata es ganar visibilidad, imponer un orden arquitectónico, reducir la carga operativa o ampliar el control centralizado a plataformas en la nube que evolucionan rápidamente; la mayoría de las organizaciones avanzan por estas etapas de forma iterativa, en lugar de mediante un único proceso de migración.
PATH 01
Cuando la expansión de la nube híbrida ha superado la visibilidad centralizada.
Establecer visibilidad de DDI y una única fuente de verdad
Empiece por consolidar los datos de DNS, DHCP e IP, tanto en las instalaciones como en la nube, en un único sistema autoritativo y por habilitar la visibilidad del DNS a nivel de consulta. Esto reduce los conflictos y sienta las bases para una automatización y una gobernanza seguras. Es el requisito previo para cualquier rediseño arquitectónico más profundo.
Cuando los comportamientos del DNS local y del CSP divergen.
Definir una arquitectura DNS integrada entre la empresa y la nube
Diseña un único modelo de DNS híbrido que combine de forma intencionada el DNS empresarial y el del proveedor, con patrones específicos para cada nube, normas de nomenclatura compartidas y planes explícitos de gestión de fallos y cambios. Esto evita un «salvaje oeste» de zonas gestionadas de forma independiente, al tiempo que preserva la agilidad de los equipos de aplicaciones.
Cuando los reenviadores condicionales se han vuelto inmanejables.
Sustituir los redireccionadores ad hoc por un DDI híbrido unificado
Implemente una plataforma DDI centralizada como plano de datos y control para el DNS, que se integre con los servicios nativos de la nube o los sustituya. Utilícela para definir de forma centralizada la resolución multipath, reducir la proliferación de reglas de reenvío y restablecer un comportamiento predecible en las redes locales y en la nube.
Cuando los equipos de DevOps y de la nube necesitan rapidez bajo políticas compartidas.
Ampliar el control centralizado de DDI a los flujos de trabajo nativos de la nube
Sincronice el DDI central con los recursos asignados en la nube e implemente la administración delegada para que los equipos de la nube puedan aprovisionar el DNS y las direcciones IP bajo un marco de gobernanza. De este modo, se mantiene una única fuente de verdad al tiempo que se ofrecen servicios DNS localizados y de alto rendimiento, alineados con los requisitos de «confianza cero» y de cumplimiento normativo.
Estas preguntas reflejan cómo los equipos de red, nube y seguridad suelen evaluar las opciones de DNS híbrido multicloud durante proyectos de migración reales.
El enfoque más seguro consiste en diseñar una arquitectura DNS híbrida e integrada que trate el DNS de la empresa y el del proveedor de la nube como componentes coordinados, en lugar de como islas separadas. El DNS central debe seguir siendo la autoridad para los espacios de nombres corporativos, mientras que los patrones de reenvío a Route 53 y Azure DNS se estandarizan y se someten a pruebas. Los escenarios de fallo explícitos, el almacenamiento en caché local y los planes de gestión de cambios mantienen estables las dependencias de las aplicaciones durante la transición.
Permitir que cada equipo de la nube gestione el DNS de forma independiente casi siempre da lugar a zonas duplicadas, registros incoherentes y rutas de resolución difíciles de depurar. Un modelo de DNS tipo «salvaje oeste» merma la visibilidad y la seguridad a medida que el entorno crece. Una mejor práctica consiste en definir normas globales de nomenclatura y gobernanza, para luego delegar la administración controlada a los equipos de aplicaciones y de la nube dentro de ese marco.
Los reenviadores condicionales se convierten en un problema cuando se acumulan en miles de reglas que abarcan múltiples nubes y entornos locales. A esa escala, centralizan el conocimiento en unos pocos expertos, ralentizan los cambios y aumentan el riesgo de interrupciones cuando las reglas entran en conflicto o quedan obsoletas. La resolución multipath centralizada impulsada por DDI logra el mismo objetivo con una carga operativa mucho menor.
El DDI centralizado no requiere abandonar el DNS nativo de la nube; requiere definir qué sistema es la fuente de verdad y cómo se integran. Muchos diseños mantienen el DNS del proveedor de servicios en la nube (CSP) para el descubrimiento de servicios dentro de la nube, al tiempo que utilizan una plataforma DDI empresarial para definir las zonas corporativas, el espacio de direcciones y la resolución entre entornos. La clave es que el reenvío y las políticas se orquestan desde la plataforma central, no se crean de forma ad hoc.
La gobernanza del DNS puede favorecer la velocidad si se implementa como medidas de seguridad compartidas, en lugar de un control manual. Una plataforma DDI centralizada con API y administración delegada permite que los flujos de trabajo de DevOps creen y actualicen registros DNS dentro de espacios y políticas predefinidos. Esto mantiene una única fuente de verdad y la postura de seguridad, al tiempo que preserva el autoservicio para los equipos de aplicaciones.
El DNS debe revisarse tan pronto como las cargas de trabajo abarquen tanto el entorno local como al menos una nube, y antes de las implementaciones multicloud o de microservicios a gran escala. Las migraciones iniciales suelen basarse en redireccionadores condicionales rápidos que más tarde se convierten en deuda técnica. Invertir en visibilidad, arquitectura integrada y control centralizado de DDI durante las primeras fases evita interrupciones y trabajos de reelaboración cuando el entorno se amplía.
¿Todavía tienes dudas?
Obtén respuestas reales de un representante de BlueCat.
We’re using cookies on this website to improve your experience. Cookies help us learn how you interact with our website and remember you when you come back so we can tailor it to your interests.
To learn more about cookies and how we use them, read our cookie notice.
Some cookies are essential, while others help us to improve your experience by giving us insight into how you are using our website. You may adjust your preferences for non-essential cookies below.
To learn more about cookies and how we use them, read our cookie notice. You can also review our privacy policy for more details on the personal data we collect, use, hold, and disclose when you visit our website or use our products and services.
Functional cookies
Functional cookies are essential cookies that allow us to remember choices or changes you have made (such as to language settings or your choices regarding the use of cookies). These cookies cannot be turned off since they are essential for the operation of our Websites.
Analytics cookies
Analytics cookies are non-essential cookies that collect information on how visitors use our Websites. We use this information with your consent to measure the number of visitors to our Websites, determine whether specific content or communication has been viewed, and to help us improve our Websites and communication. These cookies can be turned off.
Personalisation Storage
Personalisation cookies are non-essential cookies that collect information when you fill out a form on this website. We only use this information with your consent to pre-fill other forms on the site. These cookies can be turned off.
Marketing cookies
Marketing cookies are cookies that are placed by third parties to collect information about your visits and actions on our Websites so that they or we can deliver ads to you later, such as when you are on certain third-party sites or platforms. These cookies may be used by those third parties to build a profile of your interests and show you relevant ads on other websites. These cookies also enable visitors to our Websites to share content on social networks and to enable and evaluate interactions with our communication and social media tools. These cookies can be turned off.
