Nätverk med privat åtkomst (integrering av virtuellt nätverk) i Azure Database for PostgreSQL flexibel server

I den här artikeln beskrivs anslutnings- och nätverksbegrepp för Azure Database for PostgreSQL flexibel server.

När du skapar en Azure Database for PostgreSQL flexibel server måste du välja något av följande nätverksalternativ:

• Privat åtkomst (integrering av virtuellt nätverk)
• Offentlig åtkomst (tillåtna IP-adresser) och privat slutpunkt

Det här dokumentet beskriver nätverksalternativet för privat åtkomst (integrering av virtuellt nätverk).

Privat åtkomst (integrering av virtuellt nätverk)

Du kan distribuera en flexibel server för Azure Database for PostgreSQL i ditt Azure-virtuella nätverk med hjälp av injektion i virtuellt nätverk. Virtuella Azure-nätverk tillhandahåller privat och säker nätverkskommunikation. Resurser i ett virtuellt nätverk kommunicerar via privata IP-adresser som du tilldelar i det här nätverket.

Välj det här nätverksalternativet om du vill ha följande funktioner:

• Anslut från Azure resurser i samma virtuella nätverk till din Azure Database for PostgreSQL flexibla server med hjälp av privata IP-adresser.
• Använd ett VPN eller Azure ExpressRoute för att ansluta från icke-Azure resurser till din Azure Database for PostgreSQL flexibla server.
• Kontrollera att den Azure Database for PostgreSQL flexibla servern inte har någon offentlig slutpunkt som är tillgänglig via Internet.

I diagrammet ovan händer följande:

• Azure Database for PostgreSQL Flexibel server distribueras till undernätet 10.0.1.0/24 i det virtuella nätverket VNet-1.
• Program som distribueras i olika undernät i samma virtuella nätverk kan komma åt Azure Database for PostgreSQL flexibel server direkt.
• Program som distribueras i ett annat virtuellt nätverk (VNet-2) har inte direkt åtkomst till Azure Database for PostgreSQL flexibel server. Du måste utföra peering av virtuella nätverk för en privat DNS-zon innan den flexibla servern kan nås.

Begrepp för virtuellt nätverk

Ett virtuellt Azure-nätverk innehåller ett privat IP-adressutrymme som du konfigurerar för din användning. Det virtuella nätverket måste finnas i samma Azure region som din Azure Database for PostgreSQL flexibla servern. Mer information om virtuella nätverk finns i översikten över Azure Virtual Network.

Bekanta dig med dessa begrepp när du använder virtuella nätverk där resurser är integrerade i ett virtuellt nätverk med Azure Database for PostgreSQL flexibel server:

• Delegerat undernät: Ett virtuellt nätverk innehåller undernät (undernät). Med undernät kan du segmentera det virtuella nätverket i mindre adressutrymmen. Du distribuerar Azure-resurser till specifika undernät i ett virtuellt nätverk.

  Din Azure Database for PostgreSQL flexibla server som är integrerad i ett virtuellt nätverk måste finnas i ett undernät som är delegerat. Det innebär att endast Azure Database for PostgreSQL – flexibel server kan använda det undernätet. Inga andra Azure-resurstyper kan finnas i det delegerade undernätet. Du delegerar ett undernät genom att tilldela dess delegeringsegenskap som Microsoft.DBforPostgreSQL/flexibleServers.

  Det minsta CIDR-intervall som du kan ange för undernätet är /28, vilket ger 16 IP-adresser. Den första och sista adressen i något nätverk eller undernät kan inte tilldelas till någon enskild värd. Azure reserverar fem IP-adresser för att användas internt av Azures nätverkstjänster, vilket inkluderar två IP-adresser som inte kan tilldelas till värden, som tidigare nämnts. Den här reservationen lämnar 11 tillgängliga IP-adresser för ett /28 CIDR-intervall. En enda Azure Database for PostgreSQL flexibel server med funktioner med hög tillgänglighet använder fyra adresser.

  För replikering och Microsoft Entra-anslutningar kontrollerar du att routningstabeller inte påverkar trafiken. Ett vanligt mönster är att dirigera all utgående trafik via en Azure Firewall eller en anpassad lokal nätverksfiltreringsenhet.

  Om undernätet har en routningstabell som är associerad med regeln för att dirigera all trafik till en virtuell installation:

  • Lägg till en regel som använder måltjänsttaggen AzureActiveDirectory och nästa hopp Internet.
  • Lägg till en regel där mål-IP-området är detsamma som undernätsintervallet för Azure Database for PostgreSQL Flexible Server och nästa hopp är Virtual Network.

  Viktigt!

  Namnen AzureFirewallSubnet, AzureFirewallManagementSubnet, AzureBastionSubnetoch GatewaySubnet är reserverade i Azure. Använd inte något av dessa namn som undernätsnamn. Dessutom bör virtuella nätverk inte ha överlappande adressutrymme för att skapa repliker mellan regioner.

• Nätverkssäkerhetsgrupp (NSG): Med säkerhetsregler i NSG:er kan du filtrera den typ av nätverkstrafik som kan flöda in och ut från virtuella nätverksundernät och nätverksgränssnitt. Mer information finns i NSG-översikten.

  Programsäkerhetsgrupper (ASG: er) gör det enkelt att styra Layer-4-säkerhet med hjälp av NSG:er för platta nätverk. Du kan snabbt:

  • Anslut virtuella datorer till en ASG eller ta bort virtuella datorer från en ASG.
  • Tillämpa regler dynamiskt på dessa virtuella datorer eller ta bort regler från dessa virtuella datorer.

  Mer information finns i ASG-översikten.

  För närvarande stöder Azure Database for PostgreSQL flexibla servern inte NSG:er där en ASG är en del av regeln. Använd IP-baserad käll- eller målfiltrering i en NSG.

  Hög tillgänglighet och andra funktioner i Azure Database for PostgreSQL server kräver möjligheten att skicka och ta emot trafik till målport 5432 i Azure undernät för virtuellt nätverk där en Azure Database for PostgreSQL flexibel server distribueras och till Azure Storage för loggarkivering. Om du skapar NSG:er för att neka trafikflödet till eller från din Azure Database for PostgreSQL flexibla server i undernätet där det distribueras ser du till att tillåta trafik till målporten 5432 i undernätet och även till Lagring genom att använda tjänsttaggen Lagring som mål.

  Du kan filtrera den här undantagsregeln ytterligare genom att lägga till din Azure-region i etiketten som us-east.storage. Dessutom, om du väljer att använda Microsoft Entra-autentisering för att autentisera inloggningar till din Azure Database for PostgreSQL – flexibel server, tillåt utgående trafik till Microsoft Entra ID med hjälp av en Microsoft Entra-tjänsttagg.

  Tjänstslutpunkten Microsoft.Storage konfigureras automatiskt i det delegerade undernätet när den första servern etableras i undernätet. Den här konfigurationen säkerställer tillförlitlig routning av trafik till De Azure Storage-konton som används för att ladda upp wal-filer (Write-Ahead Log). Att ta bort den här slutpunkten kan störa anslutningen och kan leda till oavsiktliga konsekvenser för kärntjänståtgärder.

  När du konfigurerar läsrepliker över Azure-regioner måste din flexibla Azure Database for PostgreSQL-server kunna skicka eller ta emot trafik till målport 5432 för både den primära servern och repliken samt till Azure Storage i de primära regionerna och replikregionerna från både den primära servern och replikservern. Den nödvändiga TCP-målporten för Lagring är 443.

• Integration av privat DNS-zon: Azure Privat DNS-zon integration möjliggör att du kan lösa den privata DNS:en inom det aktuella virtuella nätverket eller i ett peer-kopplat virtuellt nätverk inom regionen där den privata DNS-zonen är länkad.

Använda en Privat DNS zon

Azure Private DNS tillhandahåller en tillförlitlig och säker DNS-tjänst för ditt virtuella nätverk. Azure Privat DNS hanterar och löser domännamn i det virtuella nätverket utan att behöva konfigurera en anpassad DNS-lösning.

När du använder privat nätverksåtkomst med ett virtuellt Azure-nätverk måste du ange information om den privata DNS-zonen för att aktivera DNS-matchning. För nya Azure Database for PostgreSQL flexibel server som skapats med åtkomst till privata nätverk måste du använda Private DNS zoner samtidigt som du konfigurerar Azure Database for PostgreSQL flexibel server med privat åtkomst.

För en ny flexibel server för Azure Database for PostgreSQL som skapas med privat nätverksåtkomst med hjälp av ett API, en Azure Resource Manager-mall (ARM-mall), Bicep eller Terraform skapar du privata DNS-zoner. Använd dem sedan när du konfigurerar Azure Database for PostgreSQL flexibel server med privat åtkomst. Mer information finns i REST API-specifikationer för Azure.

Om du använder Azure-portalen eller Azure CLI för att skapa Azure Database for PostgreSQL flexibel server kan du ange ett Private DNS zonnamn som du skapade tidigare i samma prenumeration eller en annan prenumeration, eller en standard Private DNS skapas automatiskt i din prenumeration.

Om du använder ett Azure API, en ARM-mall, Bicep eller Terraform skapar du privata DNS-zoner som slutar med .postgres.database.azure.com. Använd dessa zoner när du konfigurerar Azure Database for PostgreSQL flexibel server med privat åtkomst. Använd till exempel formuläret [name1].[name2].postgres.database.azure.com eller [name].postgres.database.azure.com. Om du väljer att använda formuläret [name].postgres.database.azure.comkan namnet inte vara det namn som du använder för en av dina Azure Databases for PostgreSQL – flexibel server, eller så får du ett felmeddelande under etableringen. Mer information finns i översikten över Privat DNS zoner.

När du använder Azure-portalen, API:er, Azure CLI eller en ARM-mall kan du också ändra Private DNS-zonen från den som du angav när du skapade din Azure Database for PostgreSQL flexibla server till en annan Private DNS zonen som finns i samma eller en annan prenumeration.

När du har skapat en Privat DNS zon i Azure måste du länka ett virtuellt nätverk till den. Resurser som finns i det länkade virtuella nätverket kan sedan komma åt Privat DNS-zonen.

Privata DNS-zoner är motståndskraftiga mot regionala avbrott eftersom zondata är globalt tillgängliga. Resursposter i en privat zon replikeras automatiskt över regioner. Azure Private DNS är en grundläggande tjänst med stöd för tillgänglighetszoner och zonredundans. Mer information finns i Azure-tjänster med stöd för tillgänglighetszoner.

Integrering med en anpassad DNS-server

Om du använder en egen DNS-server måste du använda en DNS-vidarebefordrare för att lösa upp FQDN för din Azure Database for PostgreSQL Flexible Server. Vidarebefordrarens IP-adress ska vara 168.63.129.16.

Den anpassade DNS-servern ska finnas i det virtuella nätverket eller nås via det virtuella nätverkets DNS-serverinställning. Mer information finns i Namnupplösning som använder din egen DNS-server.

Privat DNS zon och peering för virtuella nätverk

Privat DNS zoninställningar och peering för virtuella nätverk är oberoende av varandra. Om du vill ansluta till den Azure Database for PostgreSQL flexibla servern från en klient som du etablerar i ett annat virtuellt nätverk från samma region eller en annan region måste du länka Private DNS-zonen med det virtuella nätverket. Mer information finns i Länka det virtuella nätverket.

Om du vill mappa ett servernamn till DNS-posten kör nslookup du kommandot i Azure Cloud Shell med hjälp av Azure PowerShell eller Bash. Ersätt namnet på servern med parametern <server_name> i följande exempel:

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

Använd nav-och-ekersdesign för privata nätverk

Hubb och eker är en populär nätverksmodell för effektiv hantering av vanliga kommunikations- eller säkerhetskrav.

Hubben är ett virtuellt nätverk som fungerar som en central plats för att hantera externa anslutningar. Den tillhandahåller också tjänster som används av flera arbetsbelastningar. Navet samordnar all kommunikation till och från ekrarna. IT-regler eller -processer som säkerhet kan inspektera, dirigera och centralt hantera trafik. Ekrarna är virtuella nätverk som är värdar för arbetsbelastningar och som ansluter till det centrala navet via peering för virtuella nätverk. Delade tjänster finns i sina egna undernät för delning med anslutna nätverk. Ett perimeterundernät fungerar sedan som en säkerhetsinstallation.

Använd ekrarna för att isolera enskilda arbetsbelastningar. Anslut det lokala huvudkontoret och Azure via ExpressRoute eller plats-till-plats-VPN, anslutet till det virtuella hubbnätverket. Peer-anslut de virtuella nätverken från spokarna till hubben och möjliggör kommunikation med lokala resurser. Distribuera hubben och varje anslutet nätverk i separata prenumerationer eller resursgrupper.

Det finns tre huvudsakliga mönster för att ansluta virtuella "spoke"-nätverk till varandra:

• Spoke-nätverk är direkt anslutna till varandra: Skapa virtuella nätverkspeerings eller VPN-tunnlar mellan spoke-nätverken för att möjliggöra direkt anslutning utan att trafikera det virtuella hubbnätverket.
• Ekrar kommunicerar via en nätverksinstallation: Varje virtuellt ekernätverk har en peering till ett virtuellt WAN eller till ett virtuellt navnätverk. En enhet dirigerar trafik från nod till nod. Installationen kan hanteras av Microsoft (som med ett virtuellt WAN) eller av dig.
• En virtuell nätverksgateway är ansluten till hubbnätverket och använder användardefinierade vägar: Möjliggör kommunikation mellan ekrarna.

Använd Azure Virtual Network Manager för att skapa nya (och registrera befintliga) hubb- och spoke-topologier för virtuella nätverk för central hantering av anslutnings- och säkerhetsåtgärder.

Kommunikation med privat nätverksklienter i olika regioner

Ofta behöver kunderna ansluta till klienter i olika Azure-regioner. Mer specifikt handlar den här frågan vanligtvis om hur du ansluter två virtuella nätverk (varav ett har en Azure Database for PostgreSQL flexibel server och en annan har en programklient) som finns i olika regioner.

Du kan uppnå en sådan anslutning på flera sätt, till exempel:

• Globalt virtuellt nätverkspeering. Den här metoden är den vanligaste eftersom det är det enklaste sättet att ansluta nätverk i olika regioner. Global peering för virtuella nätverk skapar en anslutning via Azure-stamnätet direkt mellan de två peer-kopplade virtuella nätverken. Den här metoden ger det bästa nätverksdataflödet och de lägsta svarstiderna för anslutningen. När du ansluter virtuella nätverk via peering hanterar Azure även routingen automatiskt åt dig. Dessa virtuella nätverk kan kommunicera med alla resurser i det peerkopplade virtuella nätverket som upprättas på en VPN-gateway.
• Nätverks-till-nätverk-anslutning. En anslutning mellan virtuella nätverk (nätverks-till-nätverksanslutning) är i huvudsak ett VPN mellan de två Azure-platserna. Du upprättar nätverks-till-nätverksanslutningen på en VPN-gateway. Trafiken medför ytterligare två trafikhopp jämfört med global peering för virtuella nätverk. Det finns också extra svarstid och lägre bandbredd jämfört med den metoden.
• Kommunikation via nätverksinstallation i hub-and-spoke-arkitektur. I stället för att ansluta virtuella ekernätverk direkt till varandra kan du använda nätverksutrustning för att vidarebefordra trafik mellan ekrarna. Nätverksinstallationer tillhandahåller fler nätverkstjänster som djup paketinspektion och trafiksegmentering eller övervakning, men de kan introducera flaskhalsar för svarstid och prestanda om de inte är korrekt storleksanpassade.

Replikering mellan Azure-regioner och virtuella nätverk med privata nätverk

Databasreplikering är processen att kopiera data från en central eller primär server till flera servrar som kallas repliker. Den primära servern accepterar läs- och skrivåtgärder, men replikerna hanterar skrivskyddade transaktioner. Den primära servern och replikerna bildar tillsammans ett databaskluster. Målet med databasreplikering är att säkerställa redundans, konsekvens, hög tillgänglighet och tillgänglighet för data, särskilt i program med hög trafik och verksamhetskritiska program.

Azure Database for PostgreSQL erbjuder två metoder för replikering: fysisk (d.v.s. direktuppspelning) via den inbyggda funktionen Read Replica och logisk replikering. Båda är idealiska för olika användningsfall, och du kan välja det ena framför det andra beroende på ditt slutmål.

Replikering mellan Azure-regioner, med separata virtuella nätverk i varje region, kräver anslutning över regionala virtuella nätverksgränser som virtuell nätverkspeering eller i hub-and-spoke-arkitekturer via en nätverksinstallation kan tillhandahålla.

Som standard är DNS-namnmatchning begränsad till ett virtuellt nätverk. Ingen klient i ett virtuellt nätverk (VNET1) kan slå upp FQDN:en för Azure Database for PostgreSQL Flexible Server i ett annat virtuellt nätverk (VNET2).

Lös problemet genom att kontrollera att klienter i VNET1 kan komma åt Azure Database for PostgreSQL flexibel server Private DNS zon. Lägg till en länk för virtuellt nätverk till Private DNS zonen för din Azure Database for PostgreSQL flexibla server.

Scenarier för virtuella nätverk som inte stöds

Här följer några begränsningar för att arbeta med virtuella nätverk som skapats via integrering av virtuella nätverk:

• När du har distribuerat en Azure Database for PostgreSQL flexibel server till ett virtuellt nätverk och undernät kan du inte flytta den till ett annat virtuellt nätverk eller undernät. Du kan inte flytta det virtuella nätverket till en annan resursgrupp eller prenumeration.
• Du kan inte öka undernätets storlek (adressutrymmen) när det finns resurser i undernätet.
• Som standard kan inmatade resurser i virtuella nätverk inte interagera med Private Link. Om du vill använda Private Link för privata nätverk kan du läsa Azure Database for PostgreSQL-nätverk med Private Link.
• Anpassade nätverkskonfigurationer som dirigerar all trafik till Microsoft Azure Storage via en virtuell nätverksinstallation (NVA) stöds inte. Till exempel kan användningen av en generell rutt (0.0.0.0/0 → NVA) för att tvinga all utgående trafik via en NVA störa den nödvändiga plattformsanslutningen. Detta kan leda till oväntade fel i kritiska åtgärder, inklusive scenarier med hög tillgänglighet. Som standard lägger tjänsten till en tjänstslutpunkt för Micosoft.Storage när den första servern etableras i det delegerade undernätet, vilket ger säker och direkt anslutning till Azure Storage via Azure-stamnätverket. Om du tar bort den här slutpunkten kan det leda till oavsiktliga konsekvenser för kärntjänståtgärder.

Värdnamn

Oavsett vilket nätverksalternativ du väljer ska du alltid använda ett fullständigt domännamn (FQDN) som värdnamn när du ansluter till din Azure Database for PostgreSQL flexibla servern. Serverns IP-adress kan ändras. Med hjälp av FQDN behöver du inte uppdatera anslutningssträngen.

Ett exempel som använder ett FQDN som värdnamn är hostname = servername.postgres.database.azure.com. Undvik om möjligt att använda hostname = 10.0.0.4 (en privat adress) eller hostname = 40.2.45.67 (en offentlig adress).

Relaterat innehåll

• Azure Portal
• Azure CLI