Red con acceso privado (integración de red virtual) para Azure Database for PostgreSQL: servidor flexible

SE APLICA A: Azure Database for PostgreSQL con servidor flexible

En este artículo se describen los conceptos de conectividad y redes para Servidor flexible de Azure Database for PostgreSQL.

Al crear un servidor flexible de Azure Database for PostgreSQL, debe elegir una de las siguientes opciones de red:

• Acceso privado (integración de red virtual)
• Acceso público (direcciones IP permitidas) y punto de conexión privado

En este documento se describe la opción de red de acceso privado (integración con red virtual).

Acceso privado (integración de red virtual)

Puede implementar una instancia de servidor flexible de Azure Database for PostgreSQL en la red virtual de Azure mediante la inserción de red virtual. Las redes virtuales de Azure proporcionan una comunicación de red privada y segura. Los recursos de una red virtual pueden comunicarse a través de direcciones IP privadas que se asignaron en esta red.

Elija la opción de red si quiere las funcionalidades siguientes:

• Conéctese desde recursos de Azure de la misma red virtual a la instancia de servidor flexible de Azure Database for PostgreSQL mediante direcciones IP privadas.
• Use VPN o Azure ExpressRoute para conectarse desde recursos que no son de Azure a la instancia de servidor flexible de Azure Database for PostgreSQL.
• Asegúrese de que la instancia de servidor flexible de Azure Database for PostgreSQL no tenga ningún punto de conexión público accesible desde Internet.

En el diagrama anterior:

• Las instancias de servidor flexible de Azure Database for PostgreSQL se insertan en la subred 10.0.1.0/24 de la red virtual VNet-1.
• Las aplicaciones que se implementan en subredes diferentes dentro de la misma red virtual pueden acceder directamente a instancias de servidor flexible de Azure Database for PostgreSQL.
• Las aplicaciones que se implementan en una red virtual diferente (VNet-2) no tienen acceso directo a instancias de servidor flexible de Azure Database for PostgreSQL. Debe realizar el emparejamiento de la red virtual con una zona DNS privada para que las aplicaciones puedan acceder al servidor flexible.

Conceptos de redes virtuales

Una red virtual de Azure contiene un espacio de direcciones IP privadas que se configura para su uso. La red virtual debe estar en la misma región de Azure que la instancia de servidor flexible de Azure Database for PostgreSQL. Para más información sobre las redes virtuales, vea la Información general sobre Azure Virtual Network.

Estos son algunos conceptos con los que familiarizarse cuando se usan redes virtuales en las que los recursos se integran en una red virtual con instancias de servidor flexible de Azure Database for PostgreSQL:

• Subred delegada: una red virtual contiene subredes. Las subredes permiten segmentar la red virtual en espacios de direcciones más pequeños. Los recursos de Azure se implementan en subredes específicas dentro de una red virtual.

  La instancia de servidor flexible de Azure Database for PostgreSQL integrada en una red virtual debe estar en una subred que esté delegada. Es decir, solo las instancias de servidor flexible de Azure Database for PostgreSQL pueden usar esa subred. No puede haber otros tipos de recursos de Azure en la subred delegada. Para delegar una subred, asigne su propiedad de delegación como Microsoft.DBforPostgreSQL/flexibleServers.

  El menor intervalo de CIDR que se puede especificar para la subred es /28, lo que proporciona 16 direcciones IP. La primera y la última dirección de cualquier red o subred no se pueden asignar a ningún host individual. Azure reserva cinco direcciones IP para que las redes de Azure las usen internamente, que incluyen dos direcciones IP que no se pueden asignar al host, como se ha mencionado. Esto deja 11 direcciones IP disponibles para un intervalo CIDR /28. Un único servidor flexible de Azure Database for PostgreSQL con características de alta disponibilidad usa cuatro direcciones.

  Para la replicación y las conexiones de Microsoft Entra, asegúrese de que las tablas de rutas no afectan al tráfico. Un patrón común consiste en enrutar todo el tráfico saliente mediante Azure Firewall o un dispositivo de filtrado de red local personalizado.

  Si la subred tiene una tabla de rutas asociada a la regla para enrutar todo el tráfico a una aplicación virtual:

  • Agregue una regla con la etiqueta de servicio de destino AzureActiveDirectory y el próximo salto Internet.
  • Agregue una regla con el intervalo IP de destino igual que el intervalo de subredes de servidor flexible de Azure Database for PostgreSQL y el próximo salto Virtual Network.

  Importante

  Los nombres AzureFirewallSubnet, AzureFirewallManagementSubnet, AzureBastionSubnet y GatewaySubnet están reservados en Azure. No use ninguno de estos nombres para el nombre de la subred. Además, las redes virtuales no deben tener un espacio de direcciones superpuesto para crear réplicas entre regiones.

• Grupo de seguridad de red (NSG): las reglas de seguridad de los NSG le permiten filtrar el tipo de tráfico de red que puede fluir dentro y fuera de las interfaces de red y las subredes de redes virtuales. Para más información, vea la información general sobre los grupos de seguridad de red.

  Los grupos de seguridad de aplicaciones (ASG) facilitan el control de la seguridad de nivel 4 mediante el uso de grupos de seguridad de red para redes planas. Puede hacer las siguientes acciones de forma rápida:

  • Unir máquinas virtuales a un ASG o quitar máquinas virtuales de un ASG.
  • Aplicar dinámicamente reglas a esas máquinas virtuales o quitar las reglas de esas máquinas virtuales.

  Para más información, vea la información general sobre los grupos de seguridad de aplicaciones.

  En este momento, no admitimos los NSG donde un ASG forma parte de la regla mediante Azure Database for PostgreSQL con la opción Servidor flexible. Actualmente se recomienda usar el filtrado de origen o de destino basado en IP en un NSG.

  La alta disponibilidad y otras características del servidor flexible de Azure Database for PostgreSQL necesitan la capacidad de enviar y recibir tráfico al puerto de destino 5432 dentro de la subred de la red virtual de Azure donde se ha implementado el servidor flexible de Azure Database for PostgreSQL, así como a Azure Storage para el archivado de registros. Si crea NSG para denegar el flujo de tráfico hacia o desde la instancia de servidor flexible de Azure Database for PostgreSQL dentro de la subred donde se ha implementado, asegúrese de permitir el tráfico al puerto de destino 5432 dentro de la subred y también a Storage mediante la etiqueta de servicio Storage como destino.

  Puede filtrar aún más esta regla de excepción si agrega la región de Azure a la etiqueta como us-east.storage. Además, si decide usar la autenticación de Microsoft Entra para autenticar inicios de sesión en la instancia de servidor flexible de Azure Database for PostgreSQL, permita el tráfico saliente a Microsoft Entra ID mediante una etiqueta de servicio Microsoft Entra.

  Al configurar réplicas de lectura entre regiones de Azure, el servidor flexible de Azure Database for PostgreSQL necesita la capacidad de enviar y recibir tráfico al puerto de destino 5432 tanto para réplicas como para Azure Storage en regiones principal y de réplica desde servidores principales y de réplica. El puerto TCP de destino necesario para Storage es 443.

• Integración de zona DNS privada: la integración de la zona DNS privada de Azure le permite resolver el DNS privado dentro de la red virtual actual o en cualquier red virtual emparejada en la región en la que esté vinculada la zona DNS privada.

Uso de una zona DNS privada

Azure Private DNS proporciona un servicio DNS confiable y seguro para la red virtual. Azure Private DNS administra y resuelve los nombre de dominio en la red virtual sin necesidad de configurar una solución DNS personalizada.

Al usar el acceso a la red privada con la red virtual de Azure, proporcionar la información de la zona DNS privada es obligatorio para poder realizar la resolución DNS. Para la creación de una instancia de servidor flexible de Azure Database for PostgreSQL mediante el acceso a la red privada, es necesario usar zonas DNS privadas al configurar instancias de servidor flexible de Azure Database for PostgreSQL con acceso privado.

Para crear un servidor flexible de Azure Database for PostgreSQL mediante el acceso de red privada con una API, una plantilla de Azure Resource Manager (plantilla de ARM) o Terraform, cree zonas de DNS privado. Después, use esas zonas al configurar instancias de servidor flexible de Azure Database for PostgreSQL con acceso privado. Para más información, vea Especificaciones de la API REST para Azure.

Si usa Azure Portal o la CLI de Azure para crear instancias de servidor flexible de Azure Database for PostgreSQL, puede proporcionar un nombre de zona DNS privada que haya creado antes en la misma suscripción o en otra, o bien una zona DNS privada predeterminada creada automáticamente en la suscripción.

Si usa una API de Azure, una plantilla de ARM o Terraform, cree zonas DNS privadas que terminen con .postgres.database.azure.com. Use esas zonas al configurar instancias de servidor flexible de Azure Database for PostgreSQL con acceso privado. Por ejemplo, use el formato [name1].[name2].postgres.database.azure.com o [name].postgres.database.azure.com. Si decide usar el formato [name].postgres.database.azure.com, el nombre no puede ser el que use para una de las instancias de servidor flexible de Azure Databases for PostgreSQL o se mostrará un mensaje de error durante el aprovisionamiento. Para más información, vea Información general sobre zonas DNS privadas.

Al usar Azure Portal, la API, la CLI de Azure o una plantilla de ARM, también puede cambiar la zona DNS privada que ha proporcionado al crear el servidor flexible de Azure Database for PostgreSQL por otra zona DNS privada que exista en la misma suscripción o en otra distinta.

Después de crear una zona DNS privada en Azure, debe vincularle una red virtual. Los recursos hospedados en la red virtual vinculada después pueden acceder a la zona DNS privada.

Las zonas DNS privadas son resistentes a interrupciones regionales porque los datos de zona están disponibles de manera global. Los registros de recursos de una zona privada se replican entre regiones de forma automática. DNS privado de Azure es un servicio básico con redundancia de zona y zona de disponibilidad. Para más información, consulte Servicios de Azure con compatibilidad con zonas de disponibilidad.

Integración con un servidor DNS personalizado

Si usa el servidor DNS personalizado, debe usar un reenviador DNS para resolver el FQDN de Azure Database for PostgreSQL con la opción Servidor flexible. La dirección IP del reenviador debe ser 168.63.129.16.

El servidor DNS personalizado debe estar dentro de la red virtual o bien debe poder accederse a él a través de la configuración del servidor DNS de la red virtual. Para más información, vea Resolución de nombres con su propio servidor DNS.

Zona DNS privada y emparejamiento de red virtual

La configuración de la zona DNS privada y el emparejamiento de red virtual son independientes entre sí. Si quiere conectarse a la instancia de servidor flexible de Azure Database for PostgreSQL desde un cliente que se aprovisiona en otra red virtual desde la misma región o una región diferente, debe vincular la zona DNS privada con la red virtual. Para más información, vea Vincular la red virtual.

Para asignar un nombre de servidor al registro DNS, puede ejecutar el comando nslookup en Azure Cloud Shell mediante Azure PowerShell o Bash. Sustituya el nombre del servidor para el parámetro <server_name> en el ejemplo siguiente:

nslookup -debug <server_name>.postgres.database.azure.com | grep 'canonical name'

Uso del diseño de redes privadas en estrella tipo hub-and-spoke

La red en estrella tipo hub-and-spoke es un popular modelo de red que permite la administración eficaz de los requisitos habituales de comunicación o seguridad.

El centro de conectividad es una red virtual que actúa como ubicación central para administrar la conectividad externa. También hospeda los servicios usados por varias cargas de trabajo. El centro de conectividad coordina todas las comunicaciones hacia y desde los radios. El tráfico se puede inspeccionar, enrutar y administrar de forma centralizada mediante reglas de TI o procesos como los de seguridad. Los radios son redes virtuales que hospedan las cargas de trabajo y se conectan al centro de conectividad central a través del emparejamiento de redes virtuales. Los servicios compartidos se hospedan en sus propias subredes para compartir con los radios. A continuación, una subred perimetral actúa como un dispositivo de seguridad.

Los radios también son redes virtuales de Azure que se usan para aislar cargas de trabajo individuales. El flujo de tráfico entre la oficina central local y Azure se conecta mediante Azure ExpressRoute o VPN de sitio a sitio, que se conecta a la red virtual del centro. Las redes virtuales de los radios al centro de conectividad están emparejadas y permiten la comunicación con los recursos locales. Puede implementar el centro de conectividad y cada radio en suscripciones o grupos de recursos independientes.

Hay dos modelos principales para conectar redes virtuales radiales entre sí:

• Los radios están directamente conectados entre ellos: se crean emparejamientos de red virtual o túneles VPN entre las redes virtuales de radio para proporcionar conectividad directa sin recorrer la red virtual del centro.
• Los radios se comunican mediante un dispositivo de red: cada red virtual de radio tiene un emparejamiento con una WAN virtual o con una red virtual de concentrador. Un dispositivo enruta el tráfico de radio a radio. El dispositivo lo puede administrar Microsoft (como con Virtual WAN) o el usuario.
• Puerta de enlace de red virtual conectada a la red central y uso de rutas definidas por el usuario: habilita la comunicación entre los radios.

Use Azure Virtual Network Manager para crear topologías de red virtual en estrella tipo hub-and-spoke (e incorporar las ya existentes) para la administración central de los controles de conectividad y seguridad.

Comunicación con clientes de red privada en diferentes regiones

Con frecuencia, los clientes tienen la necesidad de conectarse a clientes en diferentes regiones de Azure. En concreto, esta pregunta suele reducirse a cómo conectar dos redes virtuales (una de las cuales tiene el servidor flexible de Azure Database for PostgreSQL y la otra un cliente de aplicación) que se encuentran en regiones diferentes.

Hay varias maneras de lograr esta conectividad, incluidas las siguientes:

• Emparejamiento global de redes virtuales. Esta metodología es la más común, ya que es la manera más fácil de conectar redes en diferentes regiones. El emparejamiento de red virtual global crea una conexión en la red troncal de Azure directamente entre las dos redes virtuales emparejadas. Este método proporciona el mejor rendimiento de red y las latencias más bajas para la conectividad. Cuando las redes virtuales están emparejadas, Azure también controla automáticamente el enrutamiento. Estas redes virtuales se pueden comunicar con todos los recursos de la red virtual emparejada que se establecen en una puerta de enlace de VPN.
• Conexión de red a red. Una conexión entre redes virtuales (conexión VPN de red a red) es básicamente una VPN entre las dos ubicaciones de Azure. La conexión de red a red se establece en una puerta de enlace de VPN. El tráfico incurre en dos saltos de tráfico adicionales en comparación con el emparejamiento de red virtual global. También hay latencia adicional y menor ancho de banda en comparación con ese método.
• Comunicación mediante el dispositivo de red en la arquitectura hub-and-spoke. En lugar de conectar redes virtuales radiales directamente entre sí, puede usar dispositivos de red para reenviar el tráfico entre los radios. Los dispositivos de red proporcionan más servicios de redes, como la inspección profunda de paquetes y la segmentación o supervisión del tráfico, pero pueden generar cuellos de botella de latencia y rendimiento si no tienen el tamaño correcto.

Replicación entre regiones y redes virtuales de Azure con redes privadas

La replicación de bases de datos es el proceso de copiar datos desde un servidor central o principal a varios servidores conocidos como réplicas. El servidor principal acepta operaciones de lectura y escritura, pero las réplicas sirven transacciones de solo lectura. El servidor principal y las réplicas forman colectivamente un clúster de base de datos. El objetivo de la replicación de bases de datos es garantizar la redundancia, la coherencia, la alta disponibilidad y la accesibilidad de los datos, especialmente en aplicaciones críticas de alto tráfico.

El servidor flexible de Azure Database for PostgreSQL ofrece dos métodos para las replicaciones: física (es decir, streaming) mediante la característica Réplica de lectura integrada y la replicación lógica. Ambos son ideales para diferentes casos de uso y un usuario puede elegir uno sobre el otro según el objetivo final.

Para la replicación entre regiones de Azure, con redes virtuales independientes en cada región, se necesita conectividad entre los límites de redes virtuales regionales que se puede proporcionar mediante el emparejamiento de redes virtuales o en arquitecturas de concentrador y radio con un dispositivo de red.

De manera predeterminada, la resolución de nombres DNS está limitada a una red virtual. Cualquier cliente de una red virtual (VNET1) no puede resolver el FQDN del servidor flexible de Azure Database for PostgreSQL en otra red virtual (VNET2).

Para resolver este problema, debe asegurarse de que los clientes de VNET1 puedan acceder a la zona DNS privada del servidor flexible de Azure Database for PostgreSQL. Agregue un vínculo de red virtual a la zona DNS privada de la instancia de servidor flexible de Azure Database for PostgreSQL.

Escenarios de red virtual no admitidos

Estas son algunas limitaciones para trabajar con redes virtuales creadas a través de la integración con redes virtuales:

• Después de implementar una instancia de servidor flexible de Azure Database for PostgreSQL en una red virtual y una subred, no se puede mover a otra red virtual o subred. No se puede trasladar la red virtual a otro grupo de recursos o suscripción.
• No se puede aumentar el tamaño de la subred (espacios de direcciones) después de que existan recursos en la subred.
• Los recursos insertados en la red virtual no pueden interactuar con Private Link de forma predeterminada. Si quiere usar Private Link para redes privadas, vea Redes de servidor flexible de Azure Database for PostgreSQL con Private Link.

Nombre de host

Independientemente de la opción de red que elija, se recomienda usar siempre un FQDN como nombre de host al conectarse a la instancia de servidor flexible de Azure Database for PostgreSQL. No se garantiza que la dirección IP del servidor permanezca estática. El uso del FQDN le ayuda a evitar realizar cambios en la cadena de conexión.

Un ejemplo que usa un FQDN como nombre de host es hostname = servername.postgres.database.azure.com. Siempre que sea posible, evite usar hostname = 10.0.0.4 (una dirección privada) o hostname = 40.2.45.67 (una dirección pública).

Contenido relacionado

• Azure Portal
• CLI de Azure