Vue d’ensemble de la mise en réseau pour Azure Database pour PostgreSQL - Serveur flexible avec accès privé (intégration au réseau virtuel)

  • Article

S’APPLIQUE À : Azure Database pour PostgreSQL – Serveur flexible

Cet article décrit les concepts de connectivité et de réseau pour le serveur flexible Azure Database pour PostgreSQL.

Lorsque vous créez une instance du serveur flexible Azure Database pour PostgreSQL, vous devez choisir l’une des options de mise en réseau suivantes : Accès privé (intégration au réseau virtuel) ou Accès public (adresses IP autorisées) et point de terminaison privé. Ce document décrit l’option de mise en réseau de l’Accès privé (intégration au réseau virtuel).

Accès privé (intégration au réseau virtuel)

Vous pouvez déployer une instance de serveur flexible Azure Database pour PostgreSQL sur votre réseau virtuel Azure à l’aide de l’injection VNET. Les réseaux virtuels Azure offrent des communications réseau privées et sécurisées. Les ressources dans un réseau virtuel peuvent communiquer via des adresses IP privées qui ont été attribuées sur ce réseau.

Choisissez cette option de mise en réseau si vous souhaitez bénéficier des capacités suivantes :

  • Connexion à partir de ressources Azure du même réseau virtuel à votre instance de serveur flexible Azure Database pour PostgreSQL en utilisant des adresses IP privées.
  • Utilisation d’un VPN ou du service Azure ExpressRoute pour vous connecter à partir de ressources non-Azure à votre instance de serveur flexible Azure Database pour PostgreSQL.
  • Garantie que l’instance du serveur flexible Azure Database pour PostgreSQL n’a pas de point de terminaison public accessible via Internet.

Diagramme montrant le fonctionnement du Peering entre réseaux virtuels, dont l’un comprend une instance Azure Database pour PostgreSQL – Serveur flexible.

Dans le diagramme ci-dessus :

  • Les instances de serveur flexible Azure Database pour PostgreSQL sont injectées dans un sous-réseau 10.0.1.0/24 du réseau virtuel VNet-1.
  • Les applications qui sont déployées sur différents sous-réseaux au sein du même réseau virtuel peuvent accéder directement aux instances de serveur flexible Azure Database pour PostgreSQL.
  • Les applications qui sont déployées sur un autre réseau virtuel (VNet-2) n’ont pas d’accès direct aux instances du serveur flexible Azure Database pour PostgreSQL. Vous devez effectuer un appairage de réseaux virtuels pour une zone DNS privée avant qu’elles puissent accéder au serveur flexible.

Concepts de réseau virtuel

Un réseau virtuel Azure contient un espace d’adressage IP privé configuré pour votre usage. Votre réseau virtuel doit se trouver dans la même région Azure que votre instance de serveur flexible Azure Database pour PostgreSQL. Pour en savoir plus sur les réseaux virtuels, consultez la vue d’ensemble de Réseau virtuel Azure.

Voici quelques concepts à connaître lorsque vous utilisez des réseaux virtuels dans lesquels les ressources sont intégrées dans le réseau virtuel avec des instances de serveur flexible Azure Database pour PostgreSQL :

  • Sous-réseau délégué. Un réseau virtuel contient des sous-réseaux. Les sous-réseaux vous permettent de segmenter votre réseau virtuel en espaces d’adressage plus petits. Les ressources Azure sont déployées sur des sous-réseaux spécifiques au sein d’un réseau virtuel.

    Votre instance de serveur flexible Azure Database pour PostgreSQL intégrée au réseau virtuel doit se trouver dans un sous-réseau délégué. Autrement dit, seules les instances du serveur flexible Azure Database pour PostgreSQL peuvent utiliser ce sous-réseau. Aucun autre type de ressource Azure ne peut se trouver dans le sous-réseau délégué. Pour déléguer un sous-réseau, définissez sa propriété de délégation sur Microsoft.DBforPostgreSQL/flexibleServers. La plus petite plage CIDR que vous pouvez spécifier pour le sous-réseau est /28, ce qui fournit 16 adresses IP. Cependant, la première et la dernière adresse d’un réseau ou sous-réseau ne peuvent être attribuées à un hôte spécifique. Azure réserve cinq adresses IP à utiliser en interne à des fins de mise en réseau Azure, incluant deux adresses IP qui ne peuvent pas être affectées à l’hôte, mentionnées ci-dessus. Cela vous laisse 11 adresses IP disponibles pour la plage CIDR /28, tandis qu’une instance de serveur flexible Azure Database pour PostgreSQL unique dotée de fonctionnalités de haute disponibilité utilise 28 quatre adresses. Pour la réplication et les connexions Microsoft Entra, vérifiez que les tables de routage n'affectent pas le trafic. Un modèle courant consiste à router tout le trafic sortant via un pare-feu Azure ou une appliance de filtrage réseau personnalisée locale. Si le sous-réseau a une table de routage associée à la règle pour acheminer tout le trafic vers une appliance virtuelle :

    • Ajouter une règle avec l’étiquette de service de destination « AzureActiveDirectory » et le tronçon suivant « Internet »
    • Ajouter une règle avec la même plage d’adresses IP de destination que la plage de sous-réseaux du serveur flexible Azure Database pour PostgreSQL et le tronçon suivant « Réseau virtuel »

    Important

    Les noms AzureFirewallSubnet, AzureFirewallManagementSubnet, AzureBastionSubnet et GatewaySubnet sont réservés à Azure. N’utilisez aucun d’entre eux comme nom de sous-réseau.

  • Groupe de sécurité réseau. Les règles de sécurité dans les groupes de sécurité réseau permettent de filtrer le type de trafic qui peut circuler vers et depuis les interfaces réseau et les sous-réseaux de réseau virtuel. Pour plus d’informations, consultez la présentation des groupes de sécurité réseau.

    Les groupes de sécurité d’application facilitent le contrôle de la sécurité de couche 4 en utilisant des groupes de sécurité réseau pour les réseaux plats. Vous pouvez rapidement :

    • Joindre des machines virtuelles à un groupe de sécurité d’application ou supprimer des machines virtuelles d’un groupe de sécurité d’application.
    • Appliquer dynamiquement des règles à ces machines virtuelles ou supprimer des règles de ces machines virtuelles.

    Pour plus d’informations, consultez la présentation des groupes de sécurité d’application.

    À ce stade, le serveur flexible Azure Database pour PostgreSQL ne prend pas en charge les groupes de sécurité réseau dans lesquels un groupe de sécurité d’application fait partie de la règle. Nous conseillons actuellement d’utiliser le filtrage de la source ou de la destination basé sur l’adresse IP dans un groupe de sécurité réseau.

    Important

    La fonctionnalité de haute disponibilité et d’autres fonctionnalités du serveur flexible Azure Database pour PostgreSQL nécessitent la possibilité d’envoyer ou de recevoir du trafic sur le port de destination 5432 au sein d’un sous-réseau de réseau virtuel Azure là où le serveur flexible Azure Database pour PostgreSQL est déployé, ainsi que sur le stockage Azure pour l’archivage des journaux. Si vous créez des groupes de sécurité réseau (NSG) pour refuser le trafic à destination ou en provenance de l’instance du serveur flexible Azure Database pour PostgreSQL au sein du sous-réseau sur lequel il est déployé, autorisez le trafic vers le port de destination 5432 au sein du sous-réseau ainsi que vers le stockage Azure en utilisant l’étiquette de service Stockage Azure comme destination. Vous pouvez filtrer davantage cette règle d’exception en ajoutant votre région Azure à l’étiquette telle que us-east.storage. De plus, si vous choisissez d'utiliser l'authentification Microsoft Entra pour authentifier les connexions à votre instance du serveur flexible Azure Database pour PostgreSQL, autorisez le trafic sortant vers Microsoft Entra ID à l'aide de l'étiquette de service Microsoft Entra. Lors de la configuration de réplicas en lecture à travers des régions Azure, le serveur flexible Azure Database pour PostgreSQL exige la possibilité d’envoyer ou de recevoir du trafic vers le port de destination 5432 pour les serveurs principaux et les réplicas, ainsi que vers le stockage Azure dans les régions principales et des réplicas, à partir des serveurs principaux et de réplicas.

  • Intégration d’une zone DNS privée. L’intégration de zones DNS privées Azure permet de résoudre le DNS privé au sein du réseau virtuel actuel ou de tout réseau virtuel appairé dans la région où la zone DNS privée est liée.

Utilisation d’une zone DNS privée

Azure Private DNS fournit un service DNS fiable et sécurisé pour votre réseau virtuel. Azure Private DNS gère et résout les noms de domaine dans le réseau virtuel sans nécessiter la configuration d’une solution DNS personnalisée.

Lors de l’utilisation de l’accès au réseau privé avec le réseau virtuel Azure, la mise à disposition des informations de zone DNS privée est obligatoire pour pouvoir effectuer une résolution DNS. Pour créer une instance de serveur flexible Azure Database pour PostgreSQL en utilisant un accès réseau privé, utilisez des zones DNS privées pour configurer des instances de serveur flexible Azure Database pour PostgreSQL avec un accès privé. Pour créer une instance du serveur flexible Azure Database pour PostgreSQL en utilisant un accès réseau privé avec l’API, ARM ou Terraform, créez des zones DNS privées et utilisez-les pour configurer des instances du serveur flexible Azure Database pour PostgreSQL avec un accès privé. Obtenez plus d’informations sur les spécifications de l’API REST pour Microsoft Azure. Si vous utilisez le portail Azure ou Azure CLI pour créer des instances du serveur flexible Azure Database pour PostgreSQL, vous pouvez soit fournir un nom de zone DNS privée que vous avez créé précédemment dans le même abonnement ou un autre abonnement, soit une zone DNS privée par défaut est automatiquement créée dans votre abonnement.

Si vous utilisez une API Azure, un modèle Azure Resource Manager (modèle ARM) ou Terraform, créez des zones DNS privées qui se terminent par .postgres.database.azure.com. Utilisez ces zones lors de la configuration d'instances du serveur flexible Azure Database pour PostgreSQL avec accès privé. Par exemple, utilisez le formulaire [name1].[name2].postgres.database.azure.com ou [name].postgres.database.azure.com. Si vous choisissez d’utiliser la forme [name].postgres.database.azure.com, le nom ne peut pas être celui que vous utilisez pour l’une de vos instances de serveur flexible Azure Database pour PostgreSQL, sinon un message d’erreur s’affiche lors de l’approvisionnement. Pour plus d’informations, consultez la présentation des zones DNS privées.

À l’aide du portail, de l’API, de la CLI ou de l’ARM Azure, vous pouvez également modifier la zone DNS privée de celle que vous avez fournie lors de la création de votre instance du serveur flexible Azure Database pour PostgreSQL vers une autre zone DNS privée du même abonnement ou d’un abonnement différent.

Important

Possibilité de modifier la zone DNS privée de celle vous avez fournie lors de la création de votre instance du serveur flexible Azure Database pour PostgreSQL en une autre zone DNS privée qui est actuellement désactivée pour les serveurs avec la fonctionnalité haute disponibilité activée.

Après avoir créé une zone DNS privée dans Azure, vous devez lier un réseau virtuel à celle-ci. Après liaison, les ressources hébergées dans ce réseau virtuel peuvent accéder à la zone DNS privée.

Important

Nous ne validons plus la présence de liaison de réseau virtuel lors de la création de serveurs pour le serveur flexible Azure Database pour PostgreSQL avec mise en réseau privée. Lors de la création d’un serveur via le portail, nous fournissons au client le choix de créer un lien lors de la création du serveur via la case à cocher « Lier la zone de DNS privé à votre réseau virtuel » dans le portail Azure.

Les zones privées DNS résistent aux pannes régionales car les données de la zone sont disponibles au niveau mondial. Les enregistrements de ressources dans une zone privée sont répliqués automatiquement entre les régions. Azure DNS privé est un service de base redondant de zone de disponibilité. Pour plus d’informations, consultez Services Azure prenant en charge les zones de disponibilité.

Intégration avec un serveur DNS personnalisé

Si vous utilisez un serveur DNS personnalisé, vous devez utiliser un redirecteur DNS pour résoudre le FQDN du serveur flexible Azure Database pour PostgreSQL. L’adresse IP du redirecteur doit être 168.63.129.16.

Le serveur DNS personnalisé doit se trouver à l’intérieur du réseau virtuel ou être accessible via le paramètre de serveur DNS du réseau virtuel. Pour en savoir plus, consultez Résolution de noms utilisant votre propre serveur DNS.

Zone DNS privée et appairage de réseaux virtuels

Les paramètres de zone DNS privée et l’appairage de réseaux virtuels sont indépendants les uns des autres. Si vous voulez vous connecter à l’instance du serveur flexible Azure Database pour PostgreSQL depuis un client approvisionné dans un autre réseau virtuel de la même région ou d’une autre région, vous devez lier la zone DNS privée au réseau virtuel. Pour plus d’informations, consultez Lier le réseau virtuel.

Notes

Seules les zones DNS privées dont le nom se termine par « postgres.database.azure.com » peuvent être liées. Le nom de votre zone DNS ne peut pas être le même que celui de votre ou vos instances du serveur flexible Azure Database pour PostgreSQL. Sinon, la résolution de noms échoue.

Pour mapper un nom de serveur à l’enregistrement DNS, vous pouvez exécuter la commande nslookup dans Azure Cloud Shell avec Azure PowerShell ou Bash, en remplaçant le paramètre <server_name> par le nom de votre serveur dans l’exemple ci-dessous :

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

Utilisation de la conception de réseau privé hub-and-spoke

Hub-and-spoke est un modèle de réseau populaire qui permet de gérer efficacement les besoins courants en matière de communication ou de sécurité.

Le hub est un réseau virtuel qui joue le rôle d’emplacement central pour gérer la connectivité externe. Il héberge également les services utilisés par plusieurs charges de travail. Le hub coordonne toutes les communications vers et depuis les spokes. Les règles ou les processus informatiques comme la sécurité peuvent inspecter, acheminer et gérer de manière centralisée le trafic. Les spokes sont les réseaux virtuels qui hébergent les charges de travail et se connectent au hub central à l’aide du peering de réseaux virtuels. Les services partagés sont hébergés dans leurs propres sous-réseaux pour être partagés avec les spokes. Un sous-réseau de périmètre fait ensuite office d’appliance de sécurité.

Les spokes sont aussi des réseaux virtuels dans Azure utilisés pour isoler les charges de travail individuelles. Le flux de trafic entre le siège local et Azure est connecté via ExpressRoute ou un VPN site à site connecté au réseau virtuel du hub. Les réseaux virtuels des spokes au hub sont appairés et permettent la communication avec les ressources locales. Vous pouvez implémenter le hub et chaque spoke dans des abonnements ou des groupes de ressources distincts.

Il existe trois modèles principaux pour connecter les réseaux virtuels spoke les uns aux autres :

  • Les spokes sont directement reliés les uns aux autres. Des appairages de réseaux virtuels ou des tunnels VPN sont créés entre les réseaux virtuels spoke pour établir une connectivité directe sans traverser le réseau virtuel hub.
  • Les spokes communiquent sur une appliance réseau. Chaque réseau virtuel spoke est appairé à Virtual WAN ou à un réseau virtuel hub. Une appliance achemine le trafic de spoke en spoke. L’appliance peut être gérée par Microsoft (comme avec Virtual WAN) ou par vous-même.
  • Passerelle de réseau virtuel rattachée au réseau hub et utilisant des itinéraires définis par l'utilisateur (UDR) pour permettre la communication entre les spokes.

Diagramme montrant l’architecture hub-and-spoke de base avec une connectivité hybride via Express Hub.

Utilisez Azure Virtual Network Manager (AVNM) pour créer des topologies de réseau virtuel hub-and-spoke (et intégrer les topologies existantes) pour la gestion centralisée des contrôles de connectivité et de sécurité.

Communication avec des clients en réseau privé dans différentes régions

Les clients ont souvent besoin de se connecter à des clients dans différentes régions Azure. Plus précisément, cette question se résume généralement à la façon de connecter deux réseaux virtuels (dont l’un a Azure Database pour PostgreSQL - Serveur flexible et un autre client d’application) qui se trouvent dans différentes régions. Il existe plusieurs façons d’obtenir une telle connectivité, notamment :

  • Appairage de réseaux virtuels mondial. La méthodologie la plus courante, car il s’agit du moyen le plus simple pour connecter des réseaux dans différentes régions. L’appairage de réseaux virtuels mondial crée une connexion sur le réseau principal Azure directement entre les deux réseaux virtuels appairés. Cela offre un meilleur débit réseau et les latences les plus faibles pour la connectivité à l’aide de cette méthode. Lorsque des réseaux virtuels sont appairés, Azure gère également le routage automatiquement pour vous. Ces réseaux virtuels peuvent communiquer avec toutes les ressources du réseau virtuel appairé, par le biais d’une passerelle VPN.
  • Connexion de réseau virtuel à réseau virtuel. Une connexion de réseau virtuel à réseau virtuel est essentiellement un VPN entre les deux localisations Azure différentes. La connexion de réseau virtuel à réseau virtuel est établie sur une passerelle VPN. Cela signifie que votre trafic entraîne deux tronçons de trafic supplémentaires par rapport à l’appairage de réseaux virtuels mondial. Il existe également une latence supplémentaire et une bande passante inférieure, comparé à cette méthode.
  • Communication via une appliance réseau dans une architecture Hub-and-Spoke. Au lieu de connecter directement les réseaux virtuels spokes entre eux, vous pouvez utiliser des appliances réseau pour transférer le trafic entre les spokes. Les appliances réseau fournissent des services réseau supplémentaires tels que l’inspection approfondie des paquets et la segmentation ou le monitoring du trafic, mais elles peuvent introduire des goulots d’étranglement en termes de latence et de performances si elles ne sont pas correctement dimensionnées.

Réplication entre les régions Azure et les réseaux virtuels avec réseau privé

La réplication de base de données est le processus de copie de données d’un serveur central ou principal vers plusieurs serveurs appelés réplicas. Le serveur principal accepte les opérations de lecture et d’écriture, tandis que les réplicas traitent les transactions en lecture seule. Le serveur principal et les réplicas forment ensemble un cluster de base de données. L’objectif de la réplication de base de données est de garantir la redondance, la cohérence, la haute disponibilité et l’accessibilité des données, en particulier dans les applications stratégiques à fort trafic.

Le serveur flexible Azure Database pour PostgreSQL offre deux méthodes de réplication : la réplication physique (c’est-à-dire en streaming) par le biais de la fonctionnalité de réplica en lecture intégrée et la réplication logique. Chaque méthode convient à un cas d’usage particulier, et un utilisateur peut choisir l’une plutôt que l’autre en fonction de l’objectif final.

La réplication dans les régions Azure avec des réseaux virtuels (VNET) distincts dans chaque région nécessite une connectivité à travers les limites des réseaux virtuels régionaux. Elle peut être fournie grâce à l’appairage de réseaux virtuels ou dans les architectures hub-and-spoke grâce à une appliance réseau.

Par défaut, la résolution de noms DNS est limitée à un réseau virtuel. Cela signifie qu’aucun client d’un réseau virtuel (VNET1) ne peut résoudre le nom de domaine complet du serveur flexible Azure Database pour PostgreSQL dans un autre réseau virtuel (VNET2).

Pour résoudre ce problème, vous devez vérifier que les clients de VNET1 peuvent accéder à la zone DNS privé du serveur flexible Azure Database pour PostgreSQL. Pour ce faire, ajoutez un lien de réseau virtuel à la zone DNS privé de votre instance de serveur flexible Azure Database pour PostgreSQL.

Scénarios de réseau virtuel non pris en charge

Voici quelques limitations à l’utilisation de réseaux virtuels créés par le biais d’une intégration au réseau virtuel :

  • Une fois qu’une instance de serveur flexible Azure Database pour PostgreSQL déployée sur un réseau virtuel et un sous-réseau virtuel, vous ne pouvez plus la déplacer vers un autre réseau ou sous-réseau virtuel. Vous ne pouvez pas déplacer le réseau virtuel vers un autre groupe de ressources ou un autre abonnement.
  • Il est impossible d’augmenter la taille d’un sous-réseau (espaces d’adressage) une fois que des ressources existent dans ce sous-réseau.
  • Par défaut, les ressources injectées par réseau virtuel ne peuvent pas interagir avec Private Link. Si vous voulez utiliser Private Link pour la mise en réseau privée, consultez Mise en réseau du serveur flexible Azure Database pour PostgreSQL avec Private Link

Important

Azure Resource Manager prend en charge la capacité de verrouiller des ressources en tant que mesure de sécurité. Un verrou de ressource est appliqué à une ressource et le verrouillage de celle-ci s’étend à l’ensemble des utilisateurs et des rôles qui l’utilisent. Il existe deux types de verrou de ressource : CanNotDelete et ReadOnly. Ces types de verrous peuvent être appliqués à une zone DNS privée ou à un jeu d’enregistrements. L’ajout d’un verrou d’un de ces types sur une zone DNS privée ou un jeu d’enregistrements individuel peut entraver la capacité du serveur flexible Azure Database pour PostgreSQL à mettre à jour les enregistrements DNS. Cela peut ainsi entraîner des problèmes lors d’opérations importantes sur le DNS, comme le basculement de haute disponibilité du principal vers le secondaire. Pour ces raisons, assurez-vous que vous n’utilisez pas de verrous d’enregistrement ni de zone DNS privée lors de l’utilisation des fonctionnalités de haute disponibilité avec le serveur flexible Azure Database pour PostgreSQL.

Nom de l’hôte

Quelle que soit l’option de mise en réseau choisie, nous vous recommandons de toujours utiliser un FQDN comme nom d’hôte lorsque vous vous connectez à votre instance du serveur flexible Azure Database pour PostgreSQL. Il n’est pas garanti que l’adresse IP du serveur reste statique. L’utilisation du nom de domaine complet vous permet d’éviter d’apporter des modifications à votre chaîne de connexion.

Par exemple, hostname = servername.postgres.database.azure.com utilise un FQDN comme nom d’hôte. Dans la mesure du possible, évitez d’utiliser hostname = 10.0.0.4 (adresse privée) ou hostname = 40.2.45.67 (adresse publique).

Étapes suivantes

  • Découvrez comment créer une instance de serveur flexible Azure Database pour PostgreSQL en utilisant l’option Accès privé (intégration au réseau virtuel) dans le Portail Azure ou l’interface Azure CLI.