Overzicht van netwerken voor Azure Database for PostgreSQL - Flexibele server met privétoegang (VNET-integratie)

  • Artikel

VAN TOEPASSING OP: Azure Database for PostgreSQL - Flexibele server

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

Wanneer u een exemplaar van een flexibele Azure Database for PostgreSQL-server maakt, moet u een van de volgende netwerkopties kiezen: privétoegang (VNet-integratie) of openbare toegang (toegestane IP-adressen) en privé-eindpunt. In dit document worden de netwerkopties voor privétoegang (VNet-integratie) beschreven.

Privétoegang (VNet-integratie)

U kunt een exemplaar van een flexibele Azure Database for PostgreSQL-server implementeren in uw virtuele Azure-netwerk (VNet) met behulp van VNET-injectie. 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:

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

Diagram dat laat zien hoe peering werkt tussen virtuele netwerken, waaronder een exemplaar van een flexibele Azure Database for PostgreSQL-server.

In het bovenstaande diagram:

  • Azure Databases 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 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 Server-exemplaar van Azure Database for PostgreSQL. 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 serverexemplaren 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 met VNET geïntegreerde azure Database for PostgreSQL flexibele serverexemplaren moeten zich in een subnet bevinden dat is gedelegeerd. Dat wil gezegd, alleen 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, maar 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 kunnen worden toegewezen aan de host, zoals hierboven wordt vermeld. Hierdoor hebt u 11 beschikbare IP-adressen voor /28 CIDR-bereik, terwijl één flexibele Azure Database for PostgreSQL-serverinstantie met functies voor hoge beschikbaarheid vier adressen gebruikt. Zorg ervoor dat routetabellen geen invloed hebben op verkeer voor replicatie en Microsoft Entra-verbindingen. Een gemeenschappelijk patroon wordt al het uitgaande verkeer gerouteerd via een Azure Firewall of een aangepast on-premises netwerkfilterapparaat. Als aan 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 van de flexibele Azure Database for PostgreSQL-server en de volgende hop 'Virtueel netwerk'

    Belangrijk

    De namenAzureFirewallSubnet, AzureFirewallManagementSubneten AzureBastionSubnetGatewaySubnet zijn gereserveerd in Azure. Gebruik deze niet als uw subnetnaam.

  • Netwerkbeveiligingsgroep (NSG). Met beveiligingsregels in NSG's kunt u filteren op het type netwerkverkeer dat naar en van 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:

    • Voeg virtuele machines toe aan een ASG of verwijder virtuele machines 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 Azure Database for PostgreSQL-server. We adviseren momenteel om ip-gebaseerde bron- of doelfilters te gebruiken in een NSG.

    Belangrijk

    Hoge beschikbaarheid en andere functies van azure Database for PostgreSQL flexibele server vereisen de mogelijkheid om verkeer te verzenden/ontvangen naar doelpoort 5432 binnen het subnet van het virtuele Azure-netwerk waar Azure Database for PostgreSQL flexibele server wordt geïmplementeerd, evenals naar Azure Storage voor logboekarchivering. Als u netwerkbeveiligingsgroepen (NSG) maakt om de verkeersstroom naar of van uw flexibele Azure Database for PostgreSQL-serverexemplaren te weigeren binnen het subnet waar deze is geïmplementeerd, moet u ervoor zorgen dat verkeer naar doelpoort 5432 binnen het subnet en ook naar Azure Storage wordt toegestaan met behulp van servicetag Azure 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 exemplaar van flexibele Azure Database for PostgreSQL-server, staat u uitgaand verkeer naar Microsoft Entra-id toe met behulp van de ServiceTag van Microsoft Entra. Bij het instellen van leesreplica's tussen Azure-regio's, vereist azure Database for PostgreSQL flexibele server de mogelijkheid om verkeer te verzenden/ontvangen naar doelpoort 5432 voor zowel primaire als replica's, evenals naar Azure-opslag in primaire en replicaregio's van zowel primaire als replicaservers.

  • Privé-DNS zone-integratie. Met azure-privé-DNS-zoneintegratie kunt u de privé-DNS omzetten binnen het huidige virtuele netwerk of een virtueel netwerk in de regio waaraan 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, is het verstrekken van de informatie over de privé-DNS-zone verplicht om DNS-omzetting te kunnen uitvoeren. Voor het maken van nieuwe flexibele Azure Database for PostgreSQL-serverexemplaren met privénetwerktoegang moeten privé-DNS-zones worden gebruikt tijdens het configureren van azure Database for PostgreSQL flexibele serverexemplaren met privétoegang. Voor het maken van een exemplaar van een flexibele Azure Database for PostgreSQL-server met behulp van privénetwerktoegang met API, ARM of Terraform maakt u privé-DNS-zones en gebruikt u deze tijdens het configureren van exemplaren van flexibele Azure Database for PostgreSQL-servers met privétoegang. Zie meer informatie over REST API-specificaties voor Microsoft Azure. Als u Azure Portal of Azure CLI gebruikt voor het maken van exemplaren van flexibele Azure Database for PostgreSQL-servers, 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 (Azure Resource Manager) of Terraform gebruikt, maakt u privé-DNS-zones die eindigen op .postgres.database.azure.com. Gebruik deze zones tijdens het configureren van azure Database for PostgreSQL flexibele serverexemplaren 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 Databases for PostgreSQL-serverexemplaren of wordt er een foutbericht weergegeven tijdens het inrichten. Zie het overzicht van privé-DNS-zones voor meer informatie.

Met behulp van Azure Portal, API, CLI of ARM 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 hetzelfde of een ander abonnement heeft.

Belangrijk

De mogelijkheid om de privé-DNS-zone te 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, is momenteel uitgeschakeld voor servers waarvoor de functie Hoge beschikbaarheid is ingeschakeld.

Nadat u een privé-DNS-zone in Azure hebt gemaakt, moet u er een virtueel netwerk aan koppelen . Zodra de koppeling is gemaakt, hebben resources die in dat virtuele netwerk worden gehost toegang tot de privé-DNS-zone.

Belangrijk

We valideren de aanwezigheid van virtuele netwerkkoppelingen niet meer bij het maken van servers voor flexibele Azure Database for PostgreSQL-server met privénetwerken. Bij het maken van een server via de portal bieden we de klant de keuze om een koppeling te maken bij het maken van de server via het selectievakje Koppeling Privé-DNS Zone your virtual network 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-naam van flexibele Azure Database for PostgreSQL-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 het flexibele serverexemplaren van Azure Database for PostgreSQL vanuit 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 eindigen op 'postgres.database.azure.com' kunnen worden gekoppeld. De naam van uw DNS-zone mag niet hetzelfde zijn als uw flexibele serverexemplaren van Azure Database for PostgreSQL, anders mislukt de naamomzetting.

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

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

Ontwerp voor privénetwerken van 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 spokes zijn virtuele netwerken waarop workloads 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 ExpressRoute of site-naar-site-VPN, verbonden met het virtuele hubnetwerk. De virtuele netwerken van de spokes naar de hub worden via peering samengevoegd; hierdoor is communicatie naar 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 die rechtstreeks met elkaar zijn 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 Virtual WAN of naar een virtueel hubnetwerk. Een apparaat stuurt verkeer van spoke naar spoke. Het apparaat kan worden beheerd door Microsoft (zoals met Virtual WAN) of door u.
  • Virtuele netwerkgateway die is gekoppeld aan het hubnetwerk en gebruikmaakt van door de gebruiker gedefinieerde routes (UDR) om communicatie tussen de spokes mogelijk te maken.

Diagram met eenvoudige hub- en spoke-architectuur met hybride connectiviteit via Express Hub.

Gebruik Azure Virtual Network Manager (AVNM) om nieuwe (en onboarding van bestaande) hub- en spoke-topologieën voor virtuele netwerken te maken voor het centrale beheer van connectiviteits- en beveiligingscontroles.

Communicatie met privénetwerkclients in verschillende regio's

Vaak moeten klanten verbinding maken met clients in verschillende Azure-regio's. Meer in het bijzonder komt deze vraag meestal neer op het verbinden van twee VNET's (een met Azure Database for PostgreSQL - Flexible Server en een andere toepassingsclient) die zich in verschillende regio's bevinden. Er zijn meerdere manieren om een dergelijke connectiviteit te bereiken, waaronder:

  • Globale VNET-peering. De meest voorkomende methodologie is de eenvoudigste manier om netwerken in verschillende regio's met elkaar te verbinden. Globale VNET-peering maakt een verbinding via de Azure-backbone rechtstreeks tussen de twee gekoppelde VNET's. Dit biedt de beste netwerkdoorvoer en de laagste latenties voor connectiviteit met behulp van deze methode. Wanneer VNET's zijn gekoppeld, verwerkt Azure de routering automatisch voor u, kunnen deze VNET's communiceren met alle resources in het gekoppelde VNET, dat is ingesteld op een VPN-gateway.
  • VNET-naar-VNET-verbinding. Een VNET-naar-VNET-verbinding is in wezen een VPN tussen de twee verschillende Azure-locaties. De VNET-naar-VNET-verbinding wordt tot stand gebracht op een VPN-gateway. Dit betekent dat uw verkeer twee extra verkeershops in rekening brengt in vergelijking met wereldwijde VNET-peering. Er is ook extra latentie en lagere bandbreedte in vergelijking met die methode.
  • Communicatie via netwerkapparaat in hub- en 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, terwijl de replica's alleen-lezentransacties verwerken. 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.

Flexibele Azure Database for PostgreSQL-server biedt twee methoden voor replicaties: fysieke (bijvoorbeeld 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 (VNET's) in elke regio, vereist connectiviteit tussen regionale virtuele netwerkgrenzen die kunnen worden geboden via peering van virtuele netwerken of in hub- en spoke-architecturen via netwerkapparaat.

Dns-naamomzetting is standaard gericht op een virtueel netwerk. Dit betekent dat elke client in één virtueel netwerk (VNET1) de FQDN van de flexibele Azure Database for PostgreSQL-server in een ander virtueel netwerk (VNET2) niet kan omzetten.

Om dit probleem op te lossen, moet u ervoor zorgen dat clients in VNET1 toegang hebben tot de flexibele Azure Database for PostgreSQL-server Privé-DNS Zone. Dit kan worden bereikt door een koppeling naar een virtueel netwerk toe te voegen aan de Privé-DNS Zone van uw flexibele Azure Database for PostgreSQL-serverexemplaren.

Scenario's voor niet-ondersteunde virtuele netwerken

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

  • 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 VNET opgenomen resources kunnen standaard niet communiceren met Private Link. Als u Private Link wilt gebruiken voor privénetwerken, raadpleegt u Azure Database for PostgreSQL Flexibele servernetwerken 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 Privé-DNS zone of afzonderlijke recordset kan de mogelijkheid van flexibele Azure Database for PostgreSQL-server verstoren om DNS-records bij te werken en problemen te veroorzaken tijdens belangrijke bewerkingen op DNS, zoals failover met hoge beschikbaarheid van primaire naar secundaire server. Om deze redenen moet u ervoor zorgen dat u geen dns-privézone of recordvergrendelingen gebruikt bij het gebruik van functies voor hoge beschikbaarheid met flexibele Azure Database for PostgreSQL-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 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).

Volgende stappen

  • Meer informatie over het maken van een exemplaar van een flexibele Azure Database for PostgreSQL-server met behulp van de optie Privétoegang (VNet-integratie) in Azure Portal of de Azure CLI.