Netwerk met privétoegang (integratie van virtueel netwerk) voor Azure Database for PostgreSQL

In dit artikel worden connectiviteits- en netwerkconcepten beschreven voor flexibele serverexemplaren van Azure Database for PostgreSQL.

Wanneer u een exemplaar van een flexibele Azure Database for PostgreSQL-server maakt, moet u een van de volgende netwerkopties kiezen:

• Privétoegang (integratie van virtueel netwerk)
• Openbare toegang (toegestane IP-adressen) en privé-eindpunt

In dit document wordt de optie voor privétoegang (integratie van virtuele netwerken) beschreven.

Privétoegang (integratie van virtueel netwerk)

U kunt een exemplaar van een flexibele Azure Database for PostgreSQL-server implementeren in uw virtuele Azure-netwerk met behulp van een virtuele netwerkinjectie. Virtuele Azure-netwerken bieden privé- en beveiligde netwerkcommunicatie. Resources in een virtueel netwerk kunnen communiceren via privé-IP-adressen die op dit netwerk zijn toegewezen.

Kies deze netwerkoptie als u de volgende mogelijkheden wilt:

• Maak vanuit Azure-resources in hetzelfde virtuele netwerk verbinding met uw flexibele Azure Database for PostgreSQL-serverexemplaren met behulp van privé-IP-adressen.
• Gebruik een VPN of Azure ExpressRoute om vanuit niet-Azure-bronnen verbinding te maken met uw Azure Database for PostgreSQL Flexible Server-serverexemplaar.
• Zorg ervoor dat het exemplaar van de flexibele Azure Database for PostgreSQL-server geen openbaar eindpunt heeft dat toegankelijk is via internet.

In het bovenstaande diagram:

• Azure Database for PostgreSQL Flexibele serverexemplaren worden geïnjecteerd in subnet 10.0.1.0/24 van het virtuele VNet-1-netwerk.
• Toepassingen die zijn geïmplementeerd op verschillende subnetten binnen hetzelfde virtuele netwerk, hebben rechtstreeks toegang tot azure Database for PostgreSQL flexibele serverexemplaren.
• Toepassingen die zijn geïmplementeerd in een ander virtueel netwerk (VNet-2) hebben geen directe toegang tot flexibele Server-exemplaren van Azure Database for PostgreSQL. U moet virtuele netwerkpeering uitvoeren voor een privé-DNS-zone voordat ze toegang hebben tot de flexibele serverinstantie.

Concepten van virtuele netwerken

Een virtueel Azure-netwerk bevat een privé-IP-adresruimte die is geconfigureerd voor uw gebruik. Uw virtuele netwerk moet zich in dezelfde Azure-regio bevinden als uw flexibele Server-exemplaar van Azure Database for PostgreSQL. Zie het overzicht van azure Virtual Network voor meer informatie over virtuele netwerken.

Hier volgen enkele concepten die u moet kennen wanneer u virtuele netwerken gebruikt waarin resources zijn geïntegreerd in een virtueel netwerk met flexibele Server-exemplaren van Azure Database for PostgreSQL:

• Gedelegeerd subnet: een virtueel netwerk bevat subnetten (subnetten). Met subnetten kunt u uw virtuele netwerk segmenteren in kleinere adresruimten. Azure-resources worden geïmplementeerd in specifieke subnetten binnen een virtueel netwerk.

  Uw Azure Database for PostgreSQL flexibele serverexemplaar dat is geïntegreerd in een virtueel netwerk, moet zich in een subnet bevinden dat is gedelegeerd. Dat wil zeggen, alleen de Azure Database for PostgreSQL Flexibele Serverexemplaren kunnen dat subnet gebruiken. Er kunnen zich geen andere Azure-resourcetypen in het gedelegeerde subnet bevinden. U delegeert een subnet door de overdrachteigenschap toe te wijzen als Microsoft.DBforPostgreSQL/flexibleServers.

  Het kleinste CIDR-bereik dat u kunt opgeven voor het subnet is /28, dat 16 IP-adressen biedt. Het eerste en laatste adres in een netwerk of subnet kunnen niet worden toegewezen aan een afzonderlijke host. Azure reserveert vijf IP-adressen die intern moeten worden gebruikt door Azure-netwerken, waaronder twee IP-adressen die niet aan de host kunnen worden toegewezen, zoals vermeld. Hierdoor hebt u 11 beschikbare IP-adressen voor een CIDR-bereik van /28. Eén exemplaar van een flexibele Azure Database for PostgreSQL-server met functies voor hoge beschikbaarheid maakt gebruik van vier adressen.

  Zorg ervoor dat routetabellen geen invloed hebben op verkeer voor replicatie en Microsoft Entra-verbindingen. Een veelvoorkomend patroon is het routeren van al het uitgaande verkeer via een Azure Firewall of een aangepast on-premises netwerkfilterapparaat.

  Als voor het subnet een routetabel is gekoppeld aan de regel om al het verkeer naar een virtueel apparaat te routeren:

  • Voeg een regel toe met de doelservicetag AzureActiveDirectory en de volgende hop Internet.
  • Voeg een regel toe met een doel-IP-bereik dat hetzelfde is als het subnetbereik van de Azure Database for PostgreSQL flexibele server en de volgende hop Virtual Network.

  Belangrijk

  De namenAzureFirewallSubnet, AzureFirewallManagementSubneten AzureBastionSubnetGatewaySubnet zijn gereserveerd in Azure. Gebruik geen van deze namen als uw subnetnaam. Daarnaast mogen virtuele netwerken geen overlappende adresruimte hebben voor het maken van replica's tussen regio's.

• Netwerkbeveiligingsgroep (NSG): Met beveiligingsregels in NSG's kunt u filteren op het type netwerkverkeer dat naar en uit subnetten van virtuele netwerken en netwerkinterfaces kan stromen. Zie het overzicht van de NSG voor meer informatie.

  Met toepassingsbeveiligingsgroepen (ASG's) kunt u laag-4-beveiliging eenvoudig beheren met behulp van NSG's voor platte netwerken. U kunt snel:

  • Virtuele machines toevoegen aan een ASG of virtuele machines verwijderen uit een ASG.
  • Regels dynamisch toepassen op deze virtuele machines of regels verwijderen uit deze virtuele machines.

  Zie het ASG-overzicht voor meer informatie.

  Op dit moment bieden we geen ondersteuning voor NSG's waarbij een ASG deel uitmaakt van de regel met flexibele serverexemplaren van Azure Database for PostgreSQL. We adviseren momenteel om ip-gebaseerde bron- of doelfilters te gebruiken in een NSG.

  Voor hoge beschikbaarheid en andere functies van de Azure Database for PostgreSQL-server is de mogelijkheid vereist om verkeer te verzenden/ontvangen naar doelpoort 5432 binnen het subnet van het virtuele Azure-netwerk waarin een exemplaar van een flexibele Azure Database for PostgreSQL-server wordt geïmplementeerd en in Azure Storage voor logboekarchivering. Als u NSG's maakt om de verkeersstroom naar of van uw flexibele Azure Database for PostgreSQL-serverexemplaar te weigeren binnen het subnet waar deze is geïmplementeerd, moet u zorgen dat verkeer naar doelpoort 5432 binnen het subnet, en ook naar Opslag, wordt toegestaan met behulp van de servicetag Opslag als bestemming. Voor hoge beschikbaarheid is het raadzaam om een Microsoft.Storage-service-eindpunt toe te voegen, omdat het zorgt voor de juiste verkeersroutering naar een Azure-opslagaccount dat wordt gebruikt voor het uploaden van Write Ahead Log-bestanden (WAL).

  U kunt deze uitzonderingsregel verder filteren door uw Azure-regio toe te voegen aan het label, zoals us-east.storage. Als u ervoor kiest om Microsoft Entra-verificatie te gebruiken om aanmeldingen te verifiëren bij uw exemplaar van flexibele Azure Database for PostgreSQL-server, staat u uitgaand verkeer naar Microsoft Entra-id toe met behulp van een Microsoft Entra-servicetag.

  Wanneer u Leesreplica's instelt in meerdere Azure-regio's, moet uw flexibele Azure Database for PostgreSQL-serverinstantie in staat zijn om verkeer naar de bestemmingpoort 5432 te verzenden of te ontvangen, zowel in primaire als replicaregio's, en met Azure Storage in zowel de primaire als de replicaregio's, vanaf zowel de primaire als de replicaservers. De vereiste TCP-doelpoort voor Opslag is 443.

• Privé-DNS zone-integratie: met Azure Privé-DNS zone-integratie kunt u de privé-DNS omzetten binnen het huidige virtuele netwerk of een virtueel netwerk in de regio waar de Privé-DNS zone is gekoppeld.

Een Privé-DNS-zone gebruiken

Azure Privé-DNS biedt een betrouwbare en veilige DNS-service voor uw virtuele netwerk. Azure Privé-DNS beheert en lost domeinnamen op in het virtuele netwerk zonder dat u een aangepaste DNS-oplossing hoeft te configureren.

Wanneer u privénetwerktoegang gebruikt met een virtueel Azure-netwerk, moet u de Privé-DNS zonegegevens opgeven om DNS-omzetting te kunnen uitvoeren. Voor het maken van een nieuwe flexibele Azure Database for PostgreSQL-serverinstantie met behulp van privénetwerktoegang, moeten privé-DNS-zones worden gebruikt terwijl u Azure Database for PostgreSQL flexibele serverexemplaren met privétoegang configureert.

Maak privé-DNS-zones voor het aanmaken van een nieuwe Azure Database for PostgreSQL flexibele serverinstantie met behulp van privénetwerktoegang via een API, Azure Resource Manager-sjabloon (ARM-sjabloon), Bicep of Terraform. Gebruik ze vervolgens om Azure Database for PostgreSQL flexibele serverinstanties met privétoegang te configureren. Zie REST API-specificaties voor Azure voor meer informatie.

Als u Azure Portal of de Azure CLI gebruikt om exemplaren van flexibele Servers voor Azure Database for PostgreSQL te maken, kunt u een privé-DNS-zonenaam opgeven die u eerder hebt gemaakt in hetzelfde of een ander abonnement, of een standaard privé-DNS-zone wordt automatisch gemaakt in uw abonnement.

Als u een Azure-API, een ARM-sjabloon, Bicep of Terraform gebruikt, maakt u Privé-DNS zones die eindigen op .postgres.database.azure.com. Gebruik deze zones tijdens het configureren van flexibele serverexemplaren van Azure Database for PostgreSQL met privétoegang. Gebruik bijvoorbeeld het formulier [name1].[name2].postgres.database.azure.com of [name].postgres.database.azure.com. Als u ervoor kiest om het formulier [name].postgres.database.azure.comte gebruiken, kan de naam niet de naam zijn die u gebruikt voor een van uw flexibele Azure Database for PostgreSQL-serverexemplaren, of krijgt u een foutbericht tijdens het inrichten. Zie het overzicht van Privé-DNS zones voor meer informatie.

Wanneer u Azure Portal, API's, De Azure CLI of een ARM-sjabloon gebruikt, kunt u ook de privé-DNS-zone wijzigen van de zone die u hebt opgegeven bij het maken van uw flexibele Azure Database for PostgreSQL-serverexemplaren naar een andere privé-DNS-zone die voor hetzelfde of een ander abonnement bestaat.

Nadat u een Privé-DNS zone in Azure hebt gemaakt, moet u er een virtueel netwerk aan koppelen. Resources die worden gehost in het gekoppelde virtuele netwerk, hebben vervolgens toegang tot de Privé-DNS zone.

PRIVÉ-DNS-zones zijn tolerant voor regionale storingen omdat zonegegevens wereldwijd beschikbaar zijn. Resourcerecords in een privézone worden automatisch gerepliceerd in verschillende regio's. Azure Privé-DNS is een basisservice voor een beschikbaarheidszone, zone-redundante service. Zie Azure-services met ondersteuning voor beschikbaarheidszones voor meer informatie.

Integratie met een aangepaste DNS-server

Als u een aangepaste DNS-server gebruikt, moet u een DNS-doorstuurserver gebruiken om de FQDN van uw Azure Database voor PostgreSQL flexibele serverinstantie op te lossen. Het IP-adres van de doorstuurserver moet 168.63.129.16 zijn.

De aangepaste DNS-server moet zich in het virtuele netwerk bevinden of bereikbaar zijn via de DNS-serverinstelling van het virtuele netwerk. Zie Naamomzetting die gebruikmaakt van uw eigen DNS-server voor meer informatie.

Privé-DNS zone en peering van virtuele netwerken

Privé-DNS zone-instellingen en peering van virtuele netwerken zijn onafhankelijk van elkaar. Als u verbinding wilt maken met het flexibele Server-exemplaar van Azure Database for PostgreSQL vanaf een client die is ingericht in een ander virtueel netwerk vanuit dezelfde regio of een andere regio, moet u de privé-DNS-zone koppelen aan het virtuele netwerk. Zie Het virtuele netwerk koppelen voor meer informatie.

Als u een servernaam wilt toewijzen aan de DNS-record, kunt u de nslookup opdracht uitvoeren in Azure Cloud Shell met behulp van Azure PowerShell of Bash. Vervang in het volgende voorbeeld de naam van de server door de <parameter server_name> :

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

Ontwerp voor privénetwerken met hub en spoke gebruiken

Hub en spoke is een populair netwerkmodel voor het efficiënt beheren van algemene communicatie- of beveiligingsvereisten.

De hub is een virtueel netwerk dat fungeert als een centrale locatie voor het beheren van externe connectiviteit. Het host ook services die door meerdere workloads worden gebruikt. De hub coördineert alle communicatie van en naar de spaken. IT-regels of -processen zoals beveiliging kunnen verkeer controleren, routeren en centraal beheren. De spaken zijn virtuele netwerken waarop werkbelastingen worden gehost; ze maken verbinding met de centrale hub via peering van virtuele netwerken. Gedeelde services worden gehost in hun eigen subnetten voor delen met de spokes. Een perimetersubnet fungeert vervolgens als een beveiligingsapparaat.

De spokes zijn ook virtuele netwerken in Azure die worden gebruikt om afzonderlijke workloads te isoleren. De verkeersstroom tussen het on-premises hoofdkantoor en Azure is verbonden via Azure ExpressRoute of site-naar-site-VPN, verbonden met het virtuele hubnetwerk. De virtuele netwerken van de spokes naar de hub worden gekoppeld en maken communicatie met on-premises resources mogelijk. U kunt de hub en elke spoke in afzonderlijke abonnementen of resourcegroepen implementeren.

Er zijn drie hoofdpatronen voor het verbinden van virtuele spoke-netwerken met elkaar:

• Spokes zijn rechtstreeks met elkaar verbonden: peerings van virtuele netwerken of VPN-tunnels worden gemaakt tussen de virtuele spoke-netwerken om directe connectiviteit te bieden zonder het virtuele hubnetwerk te doorlopen.
• Spokes communiceren via een netwerkapparaat: elk virtueel spoke-netwerk heeft een peering naar een virtueel WAN of naar een virtueel hubnetwerk. Een apparaat stuurt verkeer van spoke naar spoke. Het apparaat kan worden beheerd door Microsoft (zoals met een virtueel WAN) of door u.
• Een virtuele netwerkgateway wordt gekoppeld aan het hubnetwerk en maakt gebruik van door de gebruiker gedefinieerde routes: maakt communicatie tussen de spokes mogelijk.

Gebruik Azure Virtual Network Manager om nieuwe hub-and-spoke-hub-and-spoke-topologieën te maken voor het centrale beheer van connectiviteits- en beveiligingscontroles.

Communicatie met privénetwerkclients in verschillende regio's

Vaak moeten klanten verbinding maken met de verschillende Azure-regio's van clients. Meer in het bijzonder komt deze vraag meestal neer op het verbinden van twee virtuele netwerken (waarvan één een Azure Database for PostgreSQL flexibele serverinstantie heeft en het andere een applicatieclient) die zich in verschillende regio's bevinden.

Er zijn meerdere manieren om een dergelijke connectiviteit te bereiken, waaronder:

• Wereldwijde peering voor virtuele netwerken. Deze methodologie is de meest voorkomende omdat het de eenvoudigste manier is om netwerken in verschillende regio's met elkaar te verbinden. Globale peering voor virtuele netwerken maakt een verbinding via de Azure-backbone rechtstreeks tussen de twee gekoppelde virtuele netwerken. Deze methode biedt de beste netwerkdoorvoer en laagste latenties voor connectiviteit. Wanneer virtuele netwerken zijn gekoppeld, verwerkt Azure ook automatisch de routering voor u. Deze virtuele netwerken kunnen communiceren met alle resources in het gekoppelde virtuele netwerk dat is ingesteld op een VPN-gateway.
• Netwerk-naar-netwerkverbinding. Een verbinding tussen virtuele netwerken (netwerk-naar-netwerkverbinding) is in feite een VPN tussen de twee Azure-locaties. De netwerk-naar-netwerkverbinding wordt tot stand gebracht op een VPN-gateway. Uw verkeer leidt tot twee meer verkeershops in vergelijking met wereldwijde peering van virtuele netwerken. Er is ook extra latentie en lagere bandbreedte in vergelijking met die methode.
• Communicatie via netwerkapparaat in hub-and-spoke-architectuur. In plaats van virtuele spoke-netwerken rechtstreeks met elkaar te verbinden, kunt u netwerkapparaten gebruiken om verkeer tussen spokes door te sturen. Netwerkapparaten bieden meer netwerkservices, zoals grondige pakketinspectie en verkeerssegmentatie of -bewaking, maar ze kunnen latentie- en prestatieknelpunten veroorzaken als ze niet op de juiste grootte zijn.

Replicatie tussen Azure-regio's en virtuele netwerken met privénetwerken

Databasereplicatie is het proces van het kopiëren van gegevens van een centrale of primaire server naar meerdere servers die replica's worden genoemd. De primaire server accepteert lees- en schrijfbewerkingen, maar de replica's dienen alleen-lezentransacties. De primaire server en replica's vormen gezamenlijk een databasecluster. Het doel van databasereplicatie is om redundantie, consistentie, hoge beschikbaarheid en toegankelijkheid van gegevens te garanderen, met name in bedrijfskritieke toepassingen met veel verkeer.

Azure Database for PostgreSQL biedt twee methoden voor replicaties: fysieke (dat wil gezegd, streaming) via de ingebouwde functieLeesreplica en logische replicatie. Beide zijn ideaal voor verschillende gebruiksscenario's en een gebruiker kan er een voor kiezen, afhankelijk van het einddoel.

Replicatie tussen Azure-regio's, met afzonderlijke virtuele netwerken in elke regio, vereist connectiviteit tussen regionale virtuele netwerkgrenzen die kunnen worden geboden via peering van virtuele netwerken of in hub-and-spoke-architecturen via een netwerkapparaat.

Dns-naamomzetting is standaard ingesteld op een virtueel netwerk. Elke willekeurige client in één virtueel netwerk (VNET1) kan de FQDN van de flexibele serverinstantie van Azure Database for PostgreSQL niet herkennen binnen een ander virtueel netwerk (VNET2).

U kunt dit probleem oplossen door ervoor te zorgen dat clients in VNET1 toegang hebben tot de Private DNS-zone van de Azure Database for PostgreSQL flexibele serverinstantie. Voeg een virtuele netwerkkoppeling toe aan de privé DNS-zone van uw flexibele Azure Database for PostgreSQL-serverinstance.

Scenario's voor niet-ondersteunde virtuele netwerken

Hier volgen enkele beperkingen voor het werken met virtuele netwerken die zijn gemaakt via de integratie van virtuele netwerken:

• Nadat een exemplaar van een flexibele Azure Database for PostgreSQL-server is geïmplementeerd in een virtueel netwerk en subnet, kunt u het niet verplaatsen naar een ander virtueel netwerk of subnet. U kunt het virtuele netwerk niet verplaatsen naar een andere resourcegroep of een ander abonnement.
• U kunt de subnetgrootte (adresruimten) niet vergroten als er resources in het subnet aanwezig zijn.
• In een virtueel netwerk opgenomen resources kunnen niet standaard communiceren met Private Link. Als u Private Link wilt gebruiken voor privénetwerken, raadpleegt u Azure Database for PostgreSQL-netwerken met Private Link.

Hostnaam

Ongeacht de netwerkoptie die u kiest, raden we u aan altijd een FQDN als hostnaam te gebruiken wanneer u verbinding maakt met uw flexibele Server-exemplaar van Azure Database for PostgreSQL. Het IP-adres van de server blijft niet gegarandeerd statisch. Als u de FQDN gebruikt, kunt u voorkomen dat u wijzigingen aanbrengt in uw verbindingsreeks.

Een voorbeeld dat een FQDN als hostnaam gebruikt, is hostname = servername.postgres.database.azure.com. Vermijd waar mogelijk het gebruik hostname = 10.0.0.4 van (een privéadres) of hostname = 40.2.45.67 (een openbaar adres).

Gerelateerde inhoud

• Azure-portal
• Azure-CLI