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

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

Al crear una instancia de 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 se comunican a través de direcciones IP privadas que se asignan 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 una 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 a través de 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 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 privado 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.

Familiarícese con estos conceptos al usar 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 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. Esta reserva le deja 11 direcciones IP disponibles para un intervalo CIDR /28. Una única instancia de 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 es enrutar todo el tráfico saliente a través de 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 la instancia 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 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, las instancias de servidor flexible de Azure Database for PostgreSQL no admiten NSG donde un ASG forma parte de la regla. Use el filtrado de destino o origen basado en IP en un grupo de seguridad de red.

  La alta disponibilidad y otras características del servidor de Azure Database for PostgreSQL requieren la capacidad de enviar y recibir tráfico al puerto de destino 5432 dentro de la subred de red virtual de Azure donde se implementa una instancia de servidor flexible de Azure Database for PostgreSQL y en Azure Storage para el archivado de registros. Si crea NSG (grupos de seguridad de red) para denegar el flujo de tráfico hacia o desde su instancia de servidor flexible de Azure Database for PostgreSQL en la subred en la que está implementada, asegúrese de permitir el tráfico al puerto de destino 5432 dentro de la subred y también a Storage, utilizando la etiqueta de servicio Storage como destino. Para lograr una alta disponibilidad, el procedimiento recomendado es agregar un Microsoft. Punto de conexión de servicio de almacenamiento, ya que garantiza el correcto enrutamiento del tráfico a la cuenta de almacenamiento de Azure que se utiliza para cargar archivos de registros de escritura anticipada (WAL).

  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 de Microsoft Entra.

  Al configurar réplicas de lectura entre regiones de Azure, la instancia de 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 las 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

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

Al usar el acceso de red privada con una red virtual de Azure, debe proporcionar la información de la zona DNS privada para habilitar la resolución DNS. Para las nuevas instancias de servidor flexible de Azure Database for PostgreSQL creadas mediante el acceso a la red privada, debe usar zonas DNS privadas al configurar instancias de servidor flexible de Azure Database for PostgreSQL con acceso privado.

Importante

Al usar una zona DNS privada en otra suscripción, esa suscripción también debe tener registrado el proveedor de recursos Microsoft.DBforPostgreSQL. De lo contrario, la implementación de una instancia de servidor flexible de Azure Database for PostgreSQL no se completará.

Para las nuevas instancias de servidor flexible de Azure Database for PostgreSQL creadas mediante el acceso a la red privada con una API, una plantilla de Azure Resource Manager (plantilla de ARM), Bicep o Terraform, cree zonas DNS privadas. Después, úselas mientras configura 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 privado que creó anteriormente en la misma suscripción o en otra, o bien se crea automáticamente una zona DNS privada predeterminada en la suscripción.

Si usa una API de Azure, una plantilla de ARM, Bicep o Terraform, cree zonas DNS privadas que terminen con .postgres.database.azure.com. Use esas zonas mientras configura 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 formulario [name].postgres.database.azure.com, el nombre no puede ser el nombre que usa para una de las instancias de servidor flexible de Azure Databases for PostgreSQL o recibirá un mensaje de error durante el aprovisionamiento. Para más información, vea Información general sobre zonas DNS privadas.

Al usar Azure Portal, las API, la CLI de Azure o una plantilla de ARM, también puede cambiar la zona DNS privada de la que proporcionó al crear la instancia de servidor flexible de Azure Database for PostgreSQL a otra zona DNS privada que exista en la misma suscripción o en otra suscripción diferente.

Importante

La capacidad de cambiar una zona DNS privada de la que proporcionó al crear la instancia de servidor flexible de Azure Database for PostgreSQL a otra zona DNS privada está deshabilitada actualmente para los servidores con la característica de alta disponibilidad habilitada.

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.

Importante

Ya no se valida la presencia de vínculos de red virtual en la creación del servidor para instancias de servidor flexibles de Azure Database for PostgreSQL con redes privadas. Al crear un servidor desde el portal, se proporciona al cliente la opción de crear un vínculo al crear el servidor mediante la casilla Vincular zona DNS privada a la red virtual de Azure Portal.

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 fundamental de zona de disponibilidad y con redundancia de zona. Para más información, consulte Servicios de Azure con compatibilidad con zonas de disponibilidad.

Integración con un servidor DNS personalizado

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

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

Importante

Las actualizaciones de mantenimiento programadas actualizan automáticamente la configuración personalizada del servidor DNS. Para reconocer y aplicar la configuración de DNS personalizada actualizada antes de la siguiente actualización programada, Microsoft debe realizar la actualización internamente, ya que esta funcionalidad no se expone a través de ninguna API o controles orientados al cliente. Si necesita que el cambio surta efecto antes, póngase en contacto con el soporte técnico de Microsoft.

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 desea conectarse a la instancia de servidor flexible de Azure Database for PostgreSQL desde un cliente que aprovisione 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.

Nota:

Solo puede vincular nombres de zona DNS privado que terminan con postgres.database.azure.com. El nombre de la zona DNS no puede ser el mismo que las instancias de servidor flexible de Azure Database for PostgreSQL. De lo contrario, se produce un error en la resolución de nombres.

Para asignar un nombre de servidor al registro DNS, ejecute el nslookup comando en Azure Cloud Shell mediante Azure PowerShell o Bash. Sustituya el nombre del servidor para el <server_name> parámetro 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 se conectan directamente entre sí: se crean emparejamientos de redes virtuales o túneles VPN entre las redes virtuales de los radios para proporcionar conectividad directa sin atravesar la red virtual del hub.
• 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.

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

Comunicación con clientes de red privada en diferentes regiones

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

Puede lograr esta conectividad de varias maneras, entre las que se incluyen:

• 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. Al emparejar redes virtuales, 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. Estableces la conexión de red a red 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.

Azure Database for PostgreSQL ofrece dos métodos para las replicaciones: físicas (es decir, streaming) a través de la característica de réplica de lectura integrada y la replicación lógica. Ambos son ideales para diferentes casos de uso y puede elegir uno sobre el otro en función del objetivo final.

La replicación a través de regiones de Azure, con redes virtuales independientes en cada región, requiere conectividad a través de los límites de red virtual regionales que puede proporcionar el emparejamiento de redes virtuales o en arquitecturas de tipo hub-and-spoke mediante 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 de la instancia de servidor flexible de Azure Database for PostgreSQL en otra red virtual (VNET2).

Para resolver este problema, asegúrese de que los clientes de VNET1 puedan acceder a la instancia flexible de Azure Database for PostgreSQL en la zona DNS privada. 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 puede aumentar el tamaño de subred (espacios de direcciones) después de que existan recursos en la subred.
• De forma predeterminada, los recursos insertados en la red virtual no pueden interactuar con Private Link. Si quiere usar Private Link para redes privadas, vea Redes de Azure Database for PostgreSQL con Private Link.

Importante

Azure Resource Manager admite la capacidad de bloquear recursos como control de seguridad. Los bloqueos de recursos se aplican al recurso y están en vigor en todos los usuarios y roles. Existen dos tipos de bloqueo de recursos: CanNotDelete y ReadOnly. Puede aplicar estos tipos de bloqueo a una zona DNS privada o a un conjunto de registros individual.

La aplicación de un bloqueo de cualquier tipo en una zona DNS privada o en un conjunto de registros individual podría interferir con la capacidad de una instancia de servidor flexible de Azure Database para PostgreSQL para actualizar los registros DNS. También puede causar problemas durante operaciones importantes en DNS, como la conmutación por error de alta disponibilidad de la base de datos principal a la secundaria. Por estos motivos, asegúrese de no usar una zona privada DNS o bloqueos de registro cuando use características de alta disponibilidad con una instancia de servidor flexible de Azure Database for PostgreSQL.

Nombre del anfitrión

Independientemente de la opción de red que elija, use siempre un nombre de dominio completo (FQDN) como nombre de host al conectarse a la instancia de servidor flexible de Azure Database for PostgreSQL. La dirección IP del servidor puede cambiar. Con el FQDN, no es necesario actualizar 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
• Azure CLI