Delen via

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

  • Artikel

VAN TOEPASSING OP: Azure Database for PostgreSQL - Flexibele server

In dit artikel worden de connectiviteits- en netwerkconcepten voor Azure Database for PostgreSQL - Flexible Server beschreven.

Wanneer u 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 flexibele Azure Database for PostgreSQL-server implementeren in uw virtuele Azure-netwerk met behulp van 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-server met behulp van privé-IP-adressen.
  • Gebruik een VPN of Azure ExpressRoute om vanuit niet-Azure-resources verbinding te maken met uw flexibele Azure Database for PostgreSQL-server.
  • Zorg ervoor dat de flexibele Azure Database for PostgreSQL-server geen openbaar eindpunt heeft dat toegankelijk is via internet.

Diagram waarin wordt getoond hoe peering werkt tussen virtuele netwerken, waaronder een flexibele Azure Database for PostgreSQL-server.

In het bovenstaande diagram:

  • Flexibele Servers van Azure Database for PostgreSQL worden opgenomen 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 flexibele Servers van Azure Database for PostgreSQL.
  • Toepassingen die zijn geïmplementeerd in een ander virtueel netwerk (VNet-2) hebben geen directe toegang tot flexibele Servers van Azure Database for PostgreSQL. U moet peering van virtuele netwerken uitvoeren voor een Privé-DNS zone voordat ze toegang hebben tot de flexibele server.

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 Azure Database for PostgreSQL-server. Zie het overzicht van azure Virtual Network voor meer informatie over virtuele netwerken.

Hier volgen enkele concepten waarmee u vertrouwd moet zijn wanneer u virtuele netwerken gebruikt waarin resources zijn geïntegreerd in een virtueel netwerk met flexibele Servers 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 flexibele Azure Database for PostgreSQL-server die is geïntegreerd in een virtueel netwerk, moet zich in een subnet bevinden dat is gedelegeerd. Dat wil gezegd, alleen flexibele Servers van Azure Database for PostgreSQL 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 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 het doel-IP-bereik hetzelfde als het subnetbereik Azure Database for PostgreSQL - Flexible 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 Azure Database for PostgreSQL - Flexible Server. We adviseren momenteel om ip-gebaseerde bron- of doelfilters te gebruiken in een NSG.

    Hoge beschikbaarheid en andere functies van Azure Database for PostgreSQL - Flexible Server vereisen de mogelijkheid om verkeer te verzenden/ontvangen naar doelpoort 5432 binnen het subnet van het virtuele Azure-netwerk waarin Azure Database for PostgreSQL - Flexible Server wordt geïmplementeerd en naar Azure Storage voor logboekarchivering. Als u NSG's maakt om de verkeersstroom naar of van uw flexibele Azure Database for PostgreSQL-server te weigeren binnen het subnet waar deze is geïmplementeerd, moet u verkeer naar doelpoort 5432 binnen het subnet en ook naar Storage toestaan met behulp van de servicetag Storage als bestemming.

    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 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 verschillende Azure-regio's, moet Azure Database for PostgreSQL - Flexible Server verkeer verzenden of ontvangen naar doelpoort 5432 voor zowel primaire als replica en Naar Azure Storage in primaire en replicaregio's van zowel primaire als 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-server met behulp van privénetwerktoegang moeten Privé-DNS zones worden gebruikt terwijl u flexibele Servers van Azure Database for PostgreSQL configureert met privétoegang.

Belangrijk

Wanneer u een privé-DNS-zone in een ander abonnement gebruikt, moet voor dat abonnement ook de Microsoft.DBforPostgreSQL-resourceprovider zijn geregistreerd. Anders wordt uw implementatie van de flexibele Server van Azure Database for PostgreSQL niet voltooid.

Voor het maken van een nieuwe flexibele Azure Database for PostgreSQL-server met behulp van privénetwerktoegang met een API, Azure Resource Manager-sjabloon (ARM-sjabloon) of Terraform, maakt u Privé-DNS zones. Gebruik deze vervolgens tijdens het configureren van flexibele Servers van Azure Database for PostgreSQL met privétoegang. Zie REST API-specificaties voor Azure voor meer informatie.

Als u Azure Portal of de Azure CLI gebruikt om 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 automatisch een standaard Privé-DNS zone wordt gemaakt in uw abonnement.

Als u een Azure-API, een ARM-sjabloon of Terraform gebruikt, maakt u Privé-DNS zones die eindigen op.postgres.database.azure.com. Gebruik deze zones terwijl u flexibele Servers van Azure Database for PostgreSQL configureert 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-servers, 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 toen u uw flexibele Azure Database for PostgreSQL-server hebt gemaakt naar een andere Privé-DNS zone die voor hetzelfde of een ander abonnement bestaat.

Belangrijk

De mogelijkheid om een Privé-DNS zone te wijzigen van de zone die u hebt opgegeven bij het maken van uw flexibele Azure Database for PostgreSQL-server naar een andere Privé-DNS zone is momenteel uitgeschakeld voor servers waarvoor de functie voor hoge beschikbaarheid is ingeschakeld.

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.

Belangrijk

De aanwezigheid van virtuele netwerkkoppelingen bij het maken van een server voor Azure Database for PostgreSQL - Flexible Server met privénetwerken wordt niet meer gevalideerd. Wanneer u een server maakt via de portal, bieden we de klant de keuze om een koppeling te maken bij het maken van de server via het selectievakje Een Privé-DNS-zone koppelen aan uw virtuele netwerk in Azure Portal.

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-reduntant. 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 Azure Database for PostgreSQL - Flexible Server om te zetten. 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 de flexibele Azure Database for PostgreSQL-server 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.

Notitie

Alleen Privé-DNS zonenamen die eindigenpostgres.database.azure.com, kunnen worden gekoppeld. De naam van uw DNS-zone mag niet hetzelfde zijn als uw flexibele Servers van Azure Database for PostgreSQL. Anders mislukt de naamomzetting.

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.

Diagram met een eenvoudige hub-and-spoke-architectuur met hybride connectiviteit via een express-hub.

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 specifiek komt deze vraag meestal neer op het verbinden van twee virtuele netwerken (een met Azure Database for PostgreSQL - Flexible Server en een andere heeft een toepassingsclient) 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 - Flexible Server biedt twee methoden voor replicaties: fysieke (dat wil gezegd, streaming) via de ingebouwde functie Leesreplica 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 client in één virtueel netwerk (VNET1) kan de FQDN van Azure Database for PostgreSQL - Flexible Server niet omzetten in een ander virtueel netwerk (VNET2).

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

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 flexibele Azure Database for PostgreSQL-server is geïmplementeerd in een virtueel netwerk en subnet, kunt u deze 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 - Flexible Server-netwerken met Private Link.

Belangrijk

Azure Resource Manager biedt ondersteuning voor de mogelijkheid om resources te vergrendelen als beveiligingsbeheer. Resourcevergrendelingen worden toegepast op de resource en zijn effectief voor alle gebruikers en rollen. Er zijn twee typen resourcevergrendeling: CanNotDelete en ReadOnly. Deze vergrendelingstypen kunnen worden toegepast op een Privé-DNS zone of op een afzonderlijke recordset.

Het toepassen van een vergrendeling van beide typen op een Privé-DNS zone of een afzonderlijke recordset kan de mogelijkheid van Azure Database for PostgreSQL - Flexible Server verstoren om DNS-records bij te werken. Het kan ook problemen veroorzaken tijdens belangrijke bewerkingen op DNS, zoals failover met hoge beschikbaarheid van primair naar secundair. Om deze redenen moet u ervoor zorgen dat u geen privé-DNS-zone of recordvergrendelingen gebruikt wanneer u functies voor hoge beschikbaarheid gebruikt met Azure Database for PostgreSQL - Flexible Server.

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 Azure Database for PostgreSQL-server. 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