Hola a todos y bienvenidos de nuevo.
En el vídeo de hoy vamos a hablar del DNS híbrido.
Ahora, en organizaciones más grandes, uno de los patrones de arquitectura comunes que verás es que
se basan en una configuración híbrida.
Así, una parte de la infraestructura puede estar en un centro de datos
local, en Azure, etc.
Ahora bien, cuando se tiene una configuración híbrida, uno de los retos está relacionado con la resolución DNS general.
Y esto es algo de lo que hablaremos en el vídeo de hoy.
Ahora, antes de entender las cosas en detalle, vamos a revisar los fundamentos relacionados con la zona privada alojada
en una visión general de alto nivel.
La zona hospedada privada contiene el registro que especifica cómo desea enrutar el tráfico en una Amazon
VPC.
Por ejemplo, digamos que usted tiene una zona privada alojada y hay cierto conjunto de registros
y hay dos EPCs.
Ahora, por defecto, estas VPC no podrán realizar resoluciones basadas en estos registros.
Así que lo que tienes que hacer es asociar la VPC con una zona alojada privada y sólo después de esta asociación,
los recursos en la VPC podrán seguir adelante y realizar la resolución.
Ahora, en esta etapa, ya que la VPC número dos no está asociada, la CE, dos instancias en esta VPC
no podrán resolver los registros de esta zona alojada privada específica.
Ahora permítanme también mostrarles rápidamente.
Así que en esta etapa tengo una zona privada alojada llamada demo punto interno.
El tipo que ves es privado ahora asociado a esta zona.
Si edito rápidamente la zona, tiene una opción relacionada con la asociación de una VPC con esta zona.
Y en esta etapa se ve que sólo hay una VPC que está asociada.
También tiene la opción de asociar varios conjuntos de VPC asociados a esta zona de forma que todos los
registros que formen parte de esta zona puedan ser resueltos por los recursos asociados
a la VPC.
Ahora, una parte muy importante a recordar es que la Ruta 53 no responde a las consultas
que no se originan en la VPC.
Por ejemplo, digamos que tienes una zona privada alojada y tienes una VPC número uno que está asociada
con esta zona, y también hay una VPC número dos, y hay un peering entre estas dos VPC.
Así, la instancia easy two en VPC two podrá comunicarse con la instancia EC, two en VPC
one y viceversa.
Ahora bien, como la VPC uno tiene acceso a la zona alojada privada, se supone que los recursos de la VPC número
dos a través de esta conexión de peering también podrán resolver los registros que forman parte de la zona
alojada privada.
Sin embargo, no es el caso.
Así que si un fácil dos de la VPC número dos envía la consulta para este registro específico.
Por ejemplo, 01. demo punto interno a la dirección VPC número uno más dos.
No se podrá resolver.
Así que vamos a seguir adelante y también mirar rápidamente en esto.
Ahora, de manera similar a esta arquitectura específica, ya tengo la configuración de la infraestructura en su lugar.
Así que en la cuenta número uno, tengo una instancia easy to que se está ejecutando y tengo otra instancia
easy two que se está ejecutando en la cuenta número dos y ambas VPC en las que se está ejecutando la EC two, estas
VPC aparecen.
Por ejemplo, si nos fijamos en la conexión de peering, se ve que hay un peering entre la cuenta
número uno y la cuenta número dos VPC.
Y similar a este diagrama, hay una zona privada alojada que está asociada con la VPC número
uno.
Permítanme también mostrarles.
Así que si nos fijamos en la asociación, que está asociado con uno de los VPC, que estamos llamando
como VPC número uno.
Ahora, desde el terminal, ya estoy conectado a estas dos instancias de la CE.
Así que la primera instancia EC dos tiene una IP de 1077 cero 172.
Ahora si ves que tienes 1077 cero 172 y el segundo tiene una IP de uno 7231 Y si miras por aquí
tienes uno 7231.
Así que antes de continuar, vamos a seguir adelante y en primer lugar verificar si la conectividad está presente con éxito.
Así que desde la cuenta número dos, EC dos, seguiré adelante y haré un ping en el EC dos asociado con la
cuenta número uno.
Y como era de esperar, en esta etapa, la conectividad ping está allí con éxito.
Ahora, en esta etapa el segundo punto es muy importante donde estábamos discutiendo la dirección VPC más dos.
Así que esta es la dirección relacionada con la resolución global.
Así que en general, permítanme mostrar rápidamente si vamos a la conf resultado ETSI.
Tienes el plus para dirigirte.
Así, si el CIDR de la VPC es 1070 700 16, el servidor de nombres sería 1077 0. 2.
De acuerdo.
Ahora bien, si usted hace una búsqueda en digamos, google. com en esta dirección, 1077 0. 2 otra vez, si no lo mencionas, lo tomará como
predeterminado.
Pero para evitar confusiones, lo añado aquí.
La resolución funciona perfectamente.
Del mismo modo, si prueba la resolución asociada al dominio de la zona privada alojada, vamos a probarlo.
Diré 01. demo punto interno.
Y como ves, la resolución también funciona perfectamente.
Ahora, puesto que ya existe una conectividad entre la VPC uno y la VPC dos, se supone que la instancia
en la VPC dos, si esa instancia también envía esta consulta DNS específica en esta dirección más dos, la resolución
funcionará.
Sin embargo, acabamos de enterarnos de que esto es algo que no está soportado, así que vamos a probarlo.
Así que si ejecuto exactamente el mismo comando aquí, ves, no estamos realmente recibiendo ninguna respuesta aquí.
Y en este punto recibimos un mensaje de que la conexión se ha interrumpido y no se puede acceder a ningún servidor.
Así que esto es lo que significa el primer puntero donde decimos que el Route 53 no responderá a las
consultas que no se originen en la VPC.
Ahora, en esta etapa discutimos sobre el peering VPC.
Sin embargo, puede tratarse de cualquier tipo de montaje.
Por ejemplo, si hablamos de una arquitectura híbrida en la que tienes una VPC y una local
y hay conectividad a través de VPN y conexión directa, incluso en estos casos, si los recursos locales
intentan conectarse a la VPC más dos direcciones IP para su resolución, este tipo de configuración
no es compatible.
Ahora bien, dado que hay muchas organizaciones que utilizan activamente este tipo de configuración, la pregunta
es ¿cuál es la solución probable para que funcione?
Y una de las soluciones probables aquí es introducir un servidor DNS.
Así que si nos fijamos en esta arquitectura probable específico, lo que hará en primer lugar, se alojará
el servidor DNS personalizado en la VPC.
Así que se trata de una instancia fácil.
A continuación, el servidor local envía las consultas al servidor DNS personalizado.
Así que desde el local, en lugar de enviar a la dirección IP más dos, se envía a la dirección IP de este servidor
DNS personalizado.
Ahora, este servidor DNS personalizado reenviará la consulta al resolver Route 53 apropiado.
Y a partir de aquí, cualquier respuesta que reciba este servidor DNS personalizado, la reenviará
al servidor local.
Y esta es una de las arquitecturas más comunes que se suelen ver en las organizaciones.
Funciona bastante bien.
Sin embargo, este tipo de arquitectura plantea ciertos retos.
La primera y principal es que el cliente tiene que gestionar el servidor DNS personalizado, por lo que todo lo relacionado con la alta
disponibilidad, la seguridad y la optimización de la escalabilidad pasa a ser responsabilidad del cliente.
Ahora, lo que sucede debido a alguna razón que esta instancia EC2 relacionada con el servidor DNS personalizado
se cae, toda la resolución DNS dejará de funcionar y esto afectará a la aplicación en general.
Y esta es una de las razones por las que se ha introducido la raíz 53 resolver endpoints que nos permite comunicarnos
con los hosts o dominios privados desde fuera de la VPC.
Así que aquí, en lugar del servidor DNS personalizado, estamos introduciendo el punto final de resolución.
Y el beneficio de este punto final de resolución es que se encarga de toda la infraestructura aquí.
Así que no tienes que preocuparte mucho por la alta disponibilidad, la optimización de la seguridad, etc. Deja que nos ocupemos nosotros.
Todo lo que tienes que hacer es crear un punto final de resolución y enviar la consulta a la dirección IP
asociada con este punto final y toda la configuración DNS está hecha para ti.
Y hoy en día la mayoría de las organizaciones están migrando desde el enfoque de servidor DNS personalizado
del que hablábamos al de este punto final de resolución.
Ahora de nuevo, el conjunto de características del resolver endpoint proporciona mucha flexibilidad.
Hablaremos de ello en el vídeo correspondiente.
Sin embargo, desde el punto de vista arquitectónico, espero que te hayas hecho una idea de cuáles son las soluciones asociadas cuando
tienes una configuración de tipo híbrido.
Con esto concluiremos el vídeo de hoy.