Información general sobre redes para Azure Database for PostgreSQL con la opción Servidor flexible con acceso privado (Integración con red virtual)

SE APLICA A: Azure Database for PostgreSQL: servidor flexible

En este artículo se describen los conceptos de conectividad y redes para el 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 con red virtual) o acceso público (direcciones IP permitidas) y punto de conexión privado. En este documento se describe la opción de red acceso privado (integración con red virtual).

Acceso privado (integración con red virtual)

Puede implementar una instancia de servidor flexible de Azure Database for PostgreSQL en la red virtual (VNet) 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 a través de Internet.

En el diagrama anterior:

• Las instancias de servidor flexible de Azure Databases 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 la red virtual con instancias de servidor flexible de Azure Database for PostgreSQL:

• Subred delegada. Una red virtual contiene subredes (redes secundarias). 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 la 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 intervalo CIDR más pequeño que se puede especificar para la subred es /28, que proporciona 16 direcciones IP. Aun así, 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. Entre ellas hay dos direcciones IP que no se pueden asignar a ningún host, que acabamos de mencionar. Esto le deja 11 direcciones IP disponibles para el intervalo CIDR /28, mientras que una única instancia de servidor flexible de Azure Database for PostgreSQL con características de alta disponibilidad utiliza 4 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 un 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:

  • Agregar 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 virtual Network de próximo salto “.”

  Importante

  Los nombres AzureFirewallSubnet, AzureFirewallManagementSubnet, AzureBastionSubnet y GatewaySubnet están reservados en Azure. No use ninguno de ellos para el nombre de la subred.

• Grupo de seguridad de red (NSG) . Las reglas de seguridad de los grupos de seguridad de red 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 se admiten grupos de seguridad de red en los que un ASG forma parte de la regla con el servidor flexible de Azure Database for PostgreSQL. Actualmente se recomienda usar el filtrado de origen o de destino basado en IP en un NSG.

  Importante

  Las características de alta disponibilidad y otras características de la opción de servidor flexible de Azure Database for PostgreSQL requieren 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 grupos de seguridad de red (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 implementó, asegúrese de permitir el tráfico al puerto de destino 5432 dentro de la subred y también a Azure Storage mediante la etiqueta de servicio de Azure Storage como destino. Puede filtrar aún más esta regla de excepción agregando 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 la etiqueta de servicio Microsoft Entra. Al configurar réplicas de lectura en regiones de Azure, el servidor flexible de Azure Database for PostgreSQL requiere 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 principal y de réplica.

• Integración de la zona DNS privada. La integración de la zona DNS privada de Azure 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 nueva 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 la creación de una nueva instancia de servidor flexible de Azure Database for PostgreSQL mediante el acceso de red privada con API, ARM o Terraform, cree zonas DNS privadas y úselas al configurar instancias de servidor flexible de Azure Database for PostgreSQL con acceso privado. Consulte más información sobre las Especificaciones de la API REST para Microsoft Azure. Si usa el 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 creó anteriormente en la misma suscripción o en una suscripción diferente o una zona DNS privada predeterminada se crea automáticamente en la suscripción.

Si usa una API de Azure, una plantilla de Azure Resource Manager (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 formulario [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 la información general sobre las zonas DNS privadas.

Con Azure Portal, API, CLI o 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 en otra zona DNS privada que exista la misma suscripción o diferente.

Importante

La capacidad de 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 está deshabilitada actualmente para los servidores con la característica alta disponibilidad habilitada.

Después de crear una zona DNS privada en Azure, debe vincular una red virtual a ella. Una vez vinculados, los recursos hospedados en esa red virtual 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 el servidor flexible de Azure Database for PostgreSQL con redes privadas. Al crear un servidor a través del portal, proporcionamos la opción del cliente de crear un vínculo en la creación del servidor mediante la casilla "Vincular zona DNS privada a la red virtual" en 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 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 un servidor DNS personalizado, debe usar un reenviador DNS para resolver el FQDN del 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 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.

Nota

Solo se pueden vincular los nombres de zonas DNS privadas que terminen 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 producirá un error en la resolución de nombres.

Para asignar un nombre de servidor al registro DNS, puede ejecutar el comando nslookup en Azure Cloud Shell mediante Azure PowerShell o Bash, sustituyendo el nombre del servidor por 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 a través de ExpressRoute o VPN de sitio a sitio, que a su vez se conecta a la red virtual del centro de conectividad. 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í:

• Radios conectados directamente entre sí. Los emparejamientos de red virtual o túneles VPN se crean entre las redes virtuales radiales para proporcionar conectividad directa sin atravesar la red virtual del centro de conectividad.
• Los radios se comunican mediante un dispositivo de red. Cada red virtual radial tiene un emparejamiento con Virtual WAN o con una red virtual de centro de conectividad. 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 (UDR), para habilitar la comunicación entre los radios.

Use Azure Virtual Network Manager (AVNM) para crear topologías de red virtual hub-and-spoke (e incorporar 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 diferentes regiones de Azure. En concreto, esta pregunta suele reducirse a cómo conectar dos redes virtuales (una de las cuales tiene Azure Database for PostgreSQL: servidor flexible y otro cliente de aplicación) que se encuentran en regiones diferentes. Hay varias maneras de lograr esta conectividad, algunas de las cuales son:

• Emparejamiento de red virtual global. La metodología 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 a través de la red troncal de Azure directamente entre las dos redes virtuales emparejadas. Esto proporciona el mejor rendimiento de red y latencias más bajas para la conectividad mediante este método. Cuando las redes virtuales están emparejadas, Azure también controlará el enrutamiento automáticamente. Estas redes virtuales pueden comunicarse con todos los recursos de la red virtual emparejada, establecidas en una puerta de enlace de VPN.
• Conexión de red virtual a red virtual. Una conexión de red virtual a red virtual es básicamente una VPN entre las dos ubicaciones de Azure diferentes. La conexión de red virtual a red virtual se establece en una puerta de enlace de VPN. Esto significa que 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 a través del 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, mientras que 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) a través de 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.

La replicación entre regiones de Azure, con redes virtuales (VNet) independientes en cada región, requiere conectividad entre los límites de redes virtuales regionales que se pueden proporcionar a través del emparejamiento de redes virtuales o en arquitecturas de concentrador y radio a través del dispositivo de red.

De forma predeterminada, la resolución de nombres DNS está limitada a una red virtual. Esto significa que cualquier cliente de una red virtual (VNET1) no puede resolver el FQDN de 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. Esto se puede lograr agregando 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

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 bloqueos de recursos: CanNotDelete y ReadOnly. Estos tipos de bloqueos pueden aplicarse a una zona DNS privada o a un conjunto de registros individual. La aplicación de un bloqueo de tipo en la zona DNS privada o en un conjunto de registros individuales puede interferir con la capacidad de un servidor flexible de Azure Database for PostgreSQL para actualizar los registros DNS y causar problemas durante las 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 que no usa bloqueos de registro o zona privada DNS al usar características de alta disponibilidad con el servidor flexible de Azure Database for PostgreSQL.

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).

Pasos siguientes

• Aprenda a crear una instancia del servidor flexible de Azure Database for PostgreSQL mediante la opción Acceso privado (integración con red virtual) en Azure Portal o la CLI de Azure.