Dela via

Nätverk med privat åtkomst (integrering av virtuellt nätverk) för Azure Database for PostgreSQL – flexibel server

  • Artikel

GÄLLER FÖR: Azure Database for PostgreSQL – flexibel server

Den här artikeln beskriver anslutnings- och nätverksbegrepp för Azure Database for PostgreSQL – flexibel server.

När du skapar en flexibel Azure Database for PostgreSQL-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 Azure Database for PostgreSQL-server till ditt virtuella Azure-nätverk med hjälp av en virtuell nätverksinmatning. Virtuella Azure-nätverk tillhandahåller privat och säker nätverkskommunikation. Resurser i ett virtuellt nätverk kan kommunicera via privata IP-adresser som har tilldelats 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 flexibla Azure Database for PostgreSQL-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 flexibla Azure Database for PostgreSQL-server.
  • Se till att den flexibla Azure Database for PostgreSQL-servern inte har någon offentlig slutpunkt som är tillgänglig via Internet.

Diagram som visar hur peering fungerar mellan virtuella nätverk, varav ett innehåller en flexibel Azure Database for PostgreSQL-server.

I diagrammet ovan händer följande:

  • Flexibla Azure Database for PostgreSQL-servrar matas in i undernätet 10.0.1.0/24 i det virtuella VNet-1-nätverket.
  • Program som distribueras i olika undernät i samma virtuella nätverk kan komma åt azure database for PostgreSQL– flexibla servrar direkt.
  • Program som distribueras på ett annat virtuellt nätverk (VNet-2) har inte direkt åtkomst till flexibla Azure Database for PostgreSQL-servrar. Du måste utföra peering för virtuella nätverk för en Privat DNS zon innan de kan komma åt den flexibla servern.

Begrepp för virtuellt nätverk

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

Här följer några begrepp som du bör känna till när du använder virtuella nätverk där resurser är integrerade i ett virtuellt nätverk med flexibla Azure Database for PostgreSQL-servrar:

  • 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. Azure-resurser distribueras till specifika undernät i ett virtuellt nätverk.

    Din flexibla Azure Database for PostgreSQL-server som är integrerad i ett virtuellt nätverk måste finnas i ett undernät som är delegerat. Det vill: endast Azure Database for PostgreSQL flexibla servrar 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 som ska användas internt av Azure-nätverk, vilket inkluderar två IP-adresser som inte kan tilldelas till värden, som nämnts. Detta ger dig 11 tillgängliga IP-adresser för ett /28 CIDR-intervall. En enda flexibel Azure Database for PostgreSQL-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 med måltjänsttaggen AzureActiveDirectory och nästa hopp Internet.
    • Lägg till en regel med mål-IP-intervallet på samma sätt som Undernätsintervallet Azure Database for PostgreSQL – Flexibel server och nästa hopp 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 vi inte NSG:er där en ASG ingår i regeln med Azure Database for PostgreSQL – flexibel server. Vi rekommenderar för närvarande att du använder IP-baserad käll- eller målfiltrering i en NSG.

    Hög tillgänglighet och andra funktioner i Azure Database for PostgreSQL – Flexibel server kräver möjligheten att skicka/ta emot trafik till målport 5432 i det virtuella Azure-nätverksundernätet där 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 flexibla Azure Database for PostgreSQL-server i undernätet där den distribueras ser du till att tillåta trafik till målport 5432 i undernätet och även till Lagring med hjälp av 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. Om du väljer att använda Microsoft Entra-autentisering för att autentisera inloggningar till din flexibla Azure Database for PostgreSQL-server tillåter du utgående trafik till Microsoft Entra-ID med hjälp av en Microsoft Entra-tjänsttagg.

    När du konfigurerar läsrepliker i Azure-regioner kräver Azure Database for PostgreSQL – flexibel server möjligheten att skicka eller ta emot trafik till målport 5432 för både primär och replik och till Azure Storage i primära regioner och replikregioner från både primära servrar och replikservrar. Den nödvändiga TCP-målporten för Lagring är 443.

  • Privat DNS zonintegrering: Med Azure Privat DNS zonintegrering kan du matcha den privata DNS:en i det aktuella virtuella nätverket eller i ett peer-kopplat virtuellt nätverk i regionen där Privat DNS-zonen är länkad.

Använda en Privat DNS zon

Azure Privat 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 är det obligatoriskt att ange Privat DNS zoninformation för att kunna utföra DNS-matchning. För att skapa en ny flexibel Azure Database for PostgreSQL-server med hjälp av åtkomst till privata nätverk måste Privat DNS zoner användas när du konfigurerar flexibla Azure Database for PostgreSQL-servrar med privat åtkomst.

Viktigt!

När du använder en privat DNS-zon i en annan prenumeration måste den prenumerationen även ha microsoft.DBforPostgreSQL-resursprovidern registrerad, annars slutförs inte distributionen av Azure Database for PostgreSQL– flexibel server.

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

Om du använder Azure Portal eller Azure CLI för att skapa flexibla Azure Database for PostgreSQL-servrar kan du ange ett Privat DNS zonnamn som du tidigare skapade i samma prenumeration eller en annan prenumeration, eller så skapas en standardzon för Privat DNS automatiskt i din prenumeration.

Om du använder ett Azure API, en ARM-mall eller Terraform skapar du Privat DNS zoner som slutar med .postgres.database.azure.com. Använd dessa zoner när du konfigurerar flexibla Azure Database for PostgreSQL-servrar 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 flexibla Azure Database for PostgreSQL-servrar, eller så får du ett felmeddelande under etableringen. Mer information finns i översikten över Privat DNS zoner.

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

Viktigt!

Möjligheten att ändra en Privat DNS zon från den som du angav när du skapade din flexibla Azure Database for PostgreSQL-server till en annan Privat DNS zon är för närvarande inaktiverad för servrar med funktionen hög tillgänglighet aktiverad.

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.

Viktigt!

Vi validerar inte längre förekomsten av virtuella nätverkslänkar när servern skapas för Azure Database for PostgreSQL – flexibel server med privata nätverk. När du skapar en server via portalen ger vi kunden möjlighet att skapa en länk när servern skapas via kryssrutan Länka en Privat DNS zon till ditt virtuella nätverk i Azure Portal.

Privata DNS-zoner är motståndskraftiga mot regionala avbrott eftersom zondata är globalt tillgängliga. Resursposter i en privat zon replikeras automatiskt mellan regioner. Azure Privat DNS är en grundläggande tjänst för tillgänglighetszonen, zon-reduntant. 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 anpassad DNS-server måste du använda en DNS-vidarebefordrare för att matcha FQDN för Azure Database for PostgreSQL – flexibel 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 Namnmatchning 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 flexibla Azure Database for PostgreSQL-servern från en klient som etableras i ett annat virtuellt nätverk från samma region eller en annan region måste du länka Privat DNS-zonen med det virtuella nätverket. Mer information finns i Länka det virtuella nätverket.

Kommentar

Endast Privat DNS zonnamn som slutar med postgres.database.azure.com kan länkas. Dns-zonnamnet får inte vara samma som dina flexibla Azure Database for PostgreSQL-servrar. Annars misslyckas namnmatchningen.

Om du vill mappa ett servernamn till DNS-posten kan du köra nslookup 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ända design för nav-och-eker-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 är också värd för 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 ekrarna. Ett perimeterundernät fungerar sedan som en säkerhetsinstallation.

Ekrarna är också virtuella nätverk i Azure som används för att isolera enskilda arbetsbelastningar. Trafikflödet mellan det lokala huvudkontoret och Azure är anslutet via Azure ExpressRoute eller plats-till-plats-VPN som är anslutet till det virtuella hubbnätverket. De virtuella nätverken från ekrarna till hubben peerkopplas och möjliggör kommunikation till lokala resurser. Du kan implementera navet och de olika ekrarna i separata prenumerationer eller resursgrupper.

Det finns tre huvudsakliga mönster för att ansluta virtuella ekernätverk till varandra:

  • Ekrar är direkt anslutna till varandra: Peerings för virtuella nätverk eller VPN-tunnlar skapas mellan de virtuella ekernätverken för att tillhandahålla direktanslutning utan att passera 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 installation dirigerar trafik från eker till eker. 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.

Diagram som visar grundläggande hub-and-spoke-arkitektur med hybridanslutning via en expresshubb.

Använd Azure Virtual Network Manager för att skapa nya (och registrera befintliga) hub-and-spoke-topologier för virtuella nätverk för central hantering av anslutnings- och säkerhetskontroller.

Kommunikation med privat nätverksklienter i olika regioner

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

Det finns flera sätt att uppnå en sådan anslutning, inklusive:

  • Global peering för virtuella nätverk. 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 virtuella nätverk peerkopplas hanterar Azure även routningen 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. Nätverks-till-nätverksanslutningen upprättas 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ätverksinstallationer för att vidarebefordra trafik mellan ekrar. 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 – Flexibel server erbjuder två metoder för replikering: fysisk (d.v.s. direktuppspelning) via den inbyggda read replica-funktionen och logisk replikering. Båda är idealiska för olika användningsfall, och en användare kan välja det ena framför det andra beroende på slutmålet.

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

Som standard är DNS-namnmatchning begränsad till ett virtuellt nätverk. En klient i ett virtuellt nätverk (VNET1) kan inte matcha Azure Database for PostgreSQL – FQDN för flexibel server i ett annat virtuellt nätverk (VNET2).

För att lösa det här problemet måste du se till att klienter i VNET1 kan komma åt Azure Database for PostgreSQL – flexibel server Privat DNS zon. Lägg till en virtuell nätverkslänk till Privat DNS zonen för din flexibla Azure Database for PostgreSQL-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 en flexibel Azure Database for PostgreSQL-server har distribuerats 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.
  • Det går inte att öka storleken på undernätet (adressutrymmen) när resurser redan finns i undernätet.
  • Inmatade resurser i virtuella nätverk kan inte interagera med Private Link som standard. Om du vill använda Private Link för privata nätverk kan du läsa Azure Database for PostgreSQL – flexibelt servernätverk med Private Link.

Viktigt!

Azure Resource Manager stöder möjligheten att låsa resurser som en säkerhetskontroll. Resurslås tillämpas på resursen och är effektiva för alla användare och roller. Det finns två typer av resurslås: CanNotDelete och ReadOnly. Dessa låstyper kan tillämpas antingen på en Privat DNS zon eller på en enskild postuppsättning.

Att använda ett lås av någon typ mot en Privat DNS zon eller en enskild postuppsättning kan påverka möjligheten för Azure Database for PostgreSQL – Flexibel server att uppdatera DNS-poster. Det kan också orsaka problem under viktiga åtgärder i DNS, till exempel redundans med hög tillgänglighet från primär till sekundär. Av dessa skäl kontrollerar du att du inte använder en privat DNS-zon eller postlås när du använder funktioner med hög tillgänglighet med Azure Database for PostgreSQL – flexibel server.

Värdnamn

Oavsett vilket nätverksalternativ du väljer rekommenderar vi att du alltid använder ett FQDN som värdnamn när du ansluter till din flexibla Azure Database for PostgreSQL-server. Serverns IP-adress är inte garanterad att förbli statisk. Med hjälp av FQDN kan du undvika att göra ändringar i dina anslutningssträng.

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