Nätverksöversikt för Azure Database for PostgreSQL – flexibel server med privat åtkomst (VNET-integrering)

  • Artikel

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

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

När du skapar en flexibel Azure Database for PostgreSQL-serverinstans måste du välja något av följande nätverksalternativ: Privat åtkomst (VNet-integrering) eller Offentlig åtkomst (tillåtna IP-adresser) och Privat slutpunkt. Det här dokumentet beskriver nätverksalternativet Privat åtkomst (VNet-integrering).

Privat åtkomst (VNet-integrering)

Du kan distribuera en flexibel Azure Database for PostgreSQL-serverinstans till ditt virtuella Azure-nätverk (VNet) med hjälp av VNET-inmatning. 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-serverinstans med hjälp av privata IP-adresser.
  • Använd VPN eller Azure ExpressRoute för att ansluta från icke-Azure-resurser till azure database for PostgreSQL– flexibel serverinstans.
  • Se till att Azure Database for PostgreSQL– flexibel serverinstans 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-serverinstans.

I diagrammet ovan händer följande:

  • Azure Databases for PostgreSQL– flexibla serverinstanser 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 serverinstanser direkt.
  • Program som distribueras i ett annat virtuellt nätverk (VNet-2) har inte direkt åtkomst till Azure Database for PostgreSQL– flexibla serverinstanser. 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. Det virtuella nätverket måste finnas i samma Azure-region som din flexibla Serverinstans för Azure Database for PostgreSQL. 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 virtuella nätverk med Azure Database for PostgreSQL– flexibla serverinstanser:

  • 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.

    Den VNET-integrerade azure database for PostgreSQL-instansen för flexibel server måste finnas i ett undernät som är delegerat. Det vill: endast Azure Database for PostgreSQL– flexibla serverinstanser 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, men 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, som innehåller två IP-adresser som inte kan tilldelas till värden, som nämns ovan. Det ger dig 11 tillgängliga IP-adresser för /28 CIDR-intervall, medan en enda Azure Database for PostgreSQL flexibel serverinstans med funktioner för 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 dirigeras 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-intervall på samma sätt som Azure Database for PostgreSQL– flexibelt serverundernät och nästa hopp "Virtuellt nätverk"

    Viktigt!

    Namnen AzureFirewallSubnet, AzureFirewallManagementSubnet, AzureBastionSubnetoch GatewaySubnet är reserverade i Azure. Använd inte något av dessa som undernätsnamn.

  • 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 är en del av regeln med en flexibel Azure Database for PostgreSQL-server. Vi rekommenderar för närvarande att du använder IP-baserad käll- eller målfiltrering i en NSG.

    Viktigt!

    Hög tillgänglighet och andra funktioner i Azure Database for PostgreSQL – flexibel server kräver möjlighet att skicka/ta emot trafik till målport 5432 i azure-undernätet för virtuella nätverk där azure database for PostgreSQL– flexibel server distribueras, samt till Azure Storage för loggarkivering. Om du skapar nätverkssäkerhetsgrupper (NSG) för att neka trafikflödet till eller från azure database for PostgreSQL-instansen för flexibel server i undernätet där den distribueras ska du se till att tillåta trafik till målport 5432 i undernätet och även till Azure Storage med hjälp av tjänsttaggen Azure Storage 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-serverinstans tillåter du utgående trafik till Microsoft Entra-ID med hjälp av Microsoft Entra-tjänsttaggen. När du konfigurerar skrivskyddade repliker i Azure-regioner kräver Azure Database for PostgreSQL flexibel server möjligheten att skicka/ta emot trafik till målport 5432 för både primär och replik, samt till Azure Storage i primära regioner och replikregioner från både primära servrar och replikservrar.

  • Privat DNS zonintegrering. Med integreringen av den privata DNS-zonen i Azure kan du matcha den privata DNS i det aktuella virtuella nätverket eller ett peer-kopplat virtuellt nätverk i regionen där den privata 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 tillhandahålla information om den privata DNS-zonen för att kunna utföra DNS-matchning. För att skapa en ny flexibel Azure Database for PostgreSQL-serverinstans med åtkomst till privata nätverk måste privata DNS-zoner användas när azure Database for PostgreSQL-flexibla serverinstanser konfigureras med privat åtkomst. Om du vill skapa en ny flexibel Azure Database for PostgreSQL-serverinstans med åtkomst till privata nätverk med API, ARM eller Terraform skapar du privata DNS-zoner och använder dem samtidigt som du konfigurerar flexibla serverinstanser i Azure Database for PostgreSQL med privat åtkomst. Se mer information om REST API-specifikationer för Microsoft Azure. Om du använder Azure-portalen eller Azure CLI för att skapa flexibla Azure Database for PostgreSQL-serverinstanser kan du antingen ange ett privat DNS-zonnamn som du tidigare har skapat i samma eller en annan prenumeration eller så skapas en privat DNS-standardzon automatiskt i din prenumeration.

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

Med hjälp av Azure-portalen, API, CLI eller ARM kan du också ändra den privata DNS-zonen från den som du angav när du skapade azure database for PostgreSQL– flexibel serverinstans till en annan privat DNS-zon som finns i samma eller en annan prenumeration.

Viktigt!

Möjligheten att ändra den privata DNS-zonen från den du angav när du skapade din flexibla Azure Database for PostgreSQL-serverinstans 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. När de är länkade kan resurser som finns i det virtuella nätverket komma åt den privata DNS-zonen.

Viktigt!

Vi validerar inte längre förekomsten av virtuella nätverkslänkar när servern skapas för en flexibel Azure Database for PostgreSQL-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 Privat DNS zon ditt virtuella nätverk" i Azure-portalen.

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 serverinstansen Azure Database for PostgreSQL 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 den privata DNS-zonen till det virtuella nätverket. Mer information finns i Länka det virtuella nätverket.

Kommentar

Endast privata DNS-zonnamn som slutar med "postgres.database.azure.com" kan länkas. Dns-zonnamnet får inte vara samma som azure database for PostgreSQL–instanser av flexibel server, annars misslyckas namnmatchningen.

Om du vill mappa ett servernamn till DNS-posten kan du köra kommandot nslookup i Azure Cloud Shell med hjälp av Azure PowerShell eller Bash och ersätta namnet på servern med <server_name> parameter i exemplet nedan:

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

Använda design för privata nätverk med nav och ekrar

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 ExpressRoute eller plats-till-plats-VPN, anslutet till det virtuella hubbnätverket. De virtuella nätverken från ekrarna till navet peerkopplas, vilket 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 som ä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 Virtual WAN eller till ett virtuellt navnätverk. En installation dirigerar trafik från eker till eker. Installationen kan hanteras av Microsoft (som med Virtual WAN) eller av dig.
  • Virtuell nätverksgateway som är ansluten till hubbnätverket och använder användardefinierade vägar (UDR) för att aktivera kommunikation mellan ekrarna.

Diagram som visar grundläggande hubb- och ekerarkitektur med hybridanslutning via Express Hub.

Använd Azure Virtual Network Manager (AVNM) för att skapa nya (och registrera befintliga) nav- och ekertopologier 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 klienter i olika Azure-regioner. Mer specifikt handlar den här frågan vanligtvis om hur du ansluter två virtuella nätverk (varav en har Azure Database for PostgreSQL – flexibel server och en annan programklient) som finns i olika regioner. Det finns flera sätt att uppnå en sådan anslutning, varav några är:

  • Global VNET-peering. Den vanligaste metoden, eftersom det är det enklaste sättet att ansluta nätverk i olika regioner tillsammans. Global VNET-peering skapar en anslutning via Azure-stamnätet direkt mellan de två peerkopplade virtuella nätverken. Detta ger bästa nätverksdataflöde och lägsta svarstider för anslutning med den här metoden. 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.
  • VNET-till-VNET-anslutning. En VNET-till-VNET-anslutning är i princip ett VPN mellan de två olika Azure-platserna. VNET-till-VNET-anslutningen upprättas på en VPN-gateway. Det innebär att trafiken medför ytterligare två trafikhopp jämfört med global VNET-peering. Det finns också ytterligare svarstider och lägre bandbredd jämfört med den metoden.
  • Kommunikation via nätverksinstallation i hubb- och ekerarkitektur. 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 medan 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 (dvs. direktuppspelning) via inbyggd read replica-funktion 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 (VNET) 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 hubb- och ekerarkitekturer via nätverksinstallation.

Dns-namnmatchning är som standard begränsad till ett virtuellt nätverk. Det innebär att alla klienter i ett virtuellt nätverk (VNET1) inte kan matcha Azure Database for PostgreSQL– flexibel server-FQDN 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 Zone. Detta kan uppnås genom att lägga till en länk för virtuellt nätverk till Privat DNS zonen för din Azure Database for PostgreSQL- flexibla serverinstans.

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 VNET-integrering:

  • När en flexibel Azure Database for PostgreSQL-serverinstans 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.
  • VNET-inmatade resurser kan inte interagera med Private Link som standard. Om du vill använda Private Link för privata nätverk läser du 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. Om du tillämpar ett lås av endera typen mot Privat DNS zon eller enskilda postuppsättningar kan det störa möjligheten för azure database for PostgreSQL flexibel server att uppdatera DNS-poster och orsaka problem under viktiga åtgärder på DNS, till exempel redundansväxling med hög tillgänglighet från primär till sekundär. Av dessa skäl kontrollerar du att du inte använder privata 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-serverinstans. 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).

Nästa steg

  • Lär dig hur du skapar en flexibel Azure Database for PostgreSQL-serverinstans med alternativet Privat åtkomst (VNet-integrering) i Azure-portalen eller Azure CLI.