Übersicht über Netzwerkkonzepte für Azure Database for PostgreSQL – Flexibler Server mit privatem Zugriff (VNET-Integration)

GILT FÜR: Azure Database for PostgreSQL – Flexible Server

In diesem Artikel werden die Konnektivitäts- und Netzwerkkonzepte für Azure Database for PostgreSQL – Flexible Server beschrieben.

Wenn Sie eine Instanz von Azure Database for PostgreSQL – Flexibler Server erstellen, müssen Sie eine der folgenden Netzwerkoptionen auswählen: Privater Zugriff (VNet-Integration) oder Öffentlicher Zugriff (zulässige IP-Adressen) und privater Endpunkt. In diesem Dokument werden Netzwerkoptionen für Privater Zugriff (VNET-Integration) beschrieben.

Privater Zugriff (VNET-Integration)

Sie können eine Azure Database for PostgreSQL – Flexible Serverinstanz in Ihrem virtuellen Azure-Netzwerk (VNet) mithilfe der VNET-Einfügung bereitstellen. Virtuelle Azure-Netzwerke ermöglichen eine private und sichere Netzwerkkommunikation. Ressourcen in einem VNet können über private IP-Adressen kommunizieren, die in diesem Netzwerk zugewiesen wurden.

Diese Netzwerkoption bietet sich an, wenn Sie die folgenden Funktionen benötigen:

• Verbinden Sie Azure-Ressourcen im gleichen virtuellen Netzwerk über private IP-Adressen mit Ihrer Instanz von „Azure Database for PostgreSQL – Flexible Server“.
• Herstellen einer Verbindung von Azure-externen Ressourcen mit Ihrer Instanz von „Azure Database for PostgreSQL – Flexible Server“ über ein VPN oder eine Azure ExpressRoute-Verbindung.
• Stellen Sie sicher, dass die Azure Database for PostgreSQL – Flexible Serverinstanz keinen öffentlichen Endpunkt aufweist, auf den über das Internet zugegriffen werden kann.

Im obigen Diagramm ist Folgendes zu sehen:

• Azure Databases for PostgreSQL – Flexible Serverinstanzen werden in Subnetz 10.0.1.0/24 des virtuellen VNet-1-Netzwerks eingefügt.
• Anwendungen, die in verschiedenen Subnetzen innerhalb desselben virtuellen Netzwerks bereitgestellt werden, können direkt auf Azure Database for PostgreSQL – Flexible Serverinstanzen von PostgreSQL zugreifen.
• Anwendungen, die in einem anderen virtuellen Netzwerk (VNet-2) bereitgestellt werden, haben keinen direkten Zugriff auf Azure Database for PostgreSQL – Flexible Serverinstanzen. Sie können erst nach einem Peering virtueller Netzwerke für eine private DNS-Zone auf die flexiblen Server zugreifen.

Virtuelle Netzwerke: Konzepte

Ein virtuelles Azure-Netzwerk (VNet) enthält einen privaten IP-Adressraum, der für Ihre Verwendung konfiguriert ist. Ihr virtuelles Netzwerk muss sich in derselben Azure-Region wie Ihre Azure Database for PostgreSQL – Flexible Serverinstanz befinden. Weitere Informationen zu virtuellen Netzwerken finden Sie unter Übersicht über Azure Virtual Network.

Nachstehend werden einige Konzepte erläutert, die Sie kennen sollten, wenn Sie virtuelle Netzwerke verwenden, bei denen Ressourcen mit Azure Database for PostgreSQL – Flexible Servern in das virtuelle Netzwerk integriert sind:

• Delegiertes Subnetz: Ein virtuelles Netzwerk enthält Subnetze (untergeordnete Netzwerke). Subnetze bieten Ihnen die Möglichkeit, Ihr virtuelles Netzwerk in kleinere Adressräume einzuteilen. Azure-Ressourcen werden in bestimmten Subnetzen innerhalb eines virtuellen Netzwerks bereitgestellt.

  Ihre integrierte VNET-Datenbank für Azure Database for PostgreSQL – Flexible Serverinstanz muss sich in einem Subnetz befinden, das delegiert ist. Das heißt, nur Instanzen von Azure Database for PostgreSQL – Flexible Server können dieses Subnetz verwenden. Im delegierten Subnetz können sich keine anderen Azure-Ressourcentypen befinden. Sie delegieren ein Subnetz, indem Sie seine Delegierungseigenschaft mit Microsoft.DBforPostgreSQL/flexibleServers zuweisen. Der kleinste CIDR-Bereich, den Sie für das Subnetz angeben können, ist /28. Er umfasst 16 IP-Adressen. Die erste und die letzte Adresse in jedem Netzwerk oder Subnetz kann jedoch keinem einzelnen Host zugewiesen werden. Azure reserviert fünf IP-Adressen, die intern vom Azure-Netzwerk genutzt werden, davon – wie oben erwähnt – zwei IP-Adressen, die keinem Host zugewiesen werden können. Damit stehen Ihnen elf verfügbare IP-Adressen für den CIDR-Bereich /28 zur Verfügung, während eine einzelne Azure Database for PostgreSQL – Flexible Serverinstanz mit High Availability-Features vier Adressen verwendet. Stellen Sie für Replikations- und Microsoft Entra-Verbindungen sicher, dass Routingtabellen den Datenverkehr nicht beeinflussen. Ein gängiges Muster ist die Weiterleitung des gesamten ausgehenden Datenverkehrs über eine Azure Firewall oder eine benutzerdefinierte lokale Netzwerkfilterungsanwendung. Wenn das Subnetz über eine Routentabelle verfügt, die der Regel zugeordnet ist, den gesamten Datenverkehr an ein virtuelles Gerät weiterzuleiten:

  • Hinzufügen einer Regel mit dem Zieldiensttag „AzureActiveDirectory“ und dem nächsten Hop „Internet“
  • Fügen Sie eine Regel mit Ziel-IP-Bereich wie die Azure Database for PostgreSQL – Flexible Server-Subnetzbereich und den nächsten Hop „Virtuelles Netzwerk“ hinzu.

  Wichtig

  Die Namen AzureFirewallSubnet, AzureFirewallManagementSubnet, AzureBastionSubnet und GatewaySubnet sind in Azure reserviert. Verwenden Sie keinen dieser Namen als Subnetznamen.

• Netzwerksicherheitsgruppen (NSG) Mit Sicherheitsregeln in Netzwerksicherheitsgruppen können Sie den Typ des ein- und ausgehenden Netzwerkdatenverkehrs von VNet-Subnetzen und Netzwerkschnittstellen filtern. Weitere Informationen finden Sie in der Übersicht über Netzwerksicherheitsgruppen.

  Anwendungssicherheitsgruppen (ASGs) vereinfachen die Steuerung der Sicherheit auf Schicht 4 mithilfe von NSGs für flache Netzwerke. Folgendes können Sie damit schnell ausführen:

  • Verknüpfen von VMs mit einer ASG oder Entfernen von VMs aus einer ASG
  • Dynamisches Anwenden von Regeln auf diese VMs oder Entfernen von Regeln für diese VMs

  Weitere Informationen finden Sie in der Übersicht über ASGs.

  Derzeit werden keine NSGs unterstützt, bei denen eine ASG Teil der Regel mit Azure Database for PostgreSQL – Flexible Server ist. Es wird derzeit empfohlen, die IP-basierte Filterung von Quelle oder Ziel in einer NSG zu verwenden.

  Wichtig

  Hochverfügbarkeit und andere Features von delegiertem Azure Database for PostgreSQL – Flexible Server erfordern die Möglichkeit zum Senden/Empfangen von Datenverkehr an die bzw. an den Zielport 5432 im Subnetz des virtuellen Azure-Netzwerks, in dem Azure Database for PostgreSQL – Flexible Server bereitgestellt wird, sowie an Azure Storage zur Protokollarchivierung. Wenn Sie Netzwerksicherheitsgruppen (NSG) erstellen, um den Datenverkehr zu oder von Ihrer Azure Database for PostgreSQL – Flexible Serverinstanz in dem Subnetz, in dem sie bereitgestellt wird, zu unterbinden, sorgen Sie dafür, dass der Datenverkehr zum Zielport 5432 im Subnetz und auch zu Azure Storage zugelassen wird. Zu diesem Zweck müssen Sie das Diensttag „Azure Storage“ als Ziel angeben. Sie können diese Ausnahmeregel weiter filtern, indem Sie Ihre Azure-Region der Bezeichnung wie us-east.storage hinzufügen. Wenn Sie sich außerdem für die Verwendung der Microsoft Entra-Authentifizierung zum Authentifizieren von Anmeldungen bei Ihrer Azure Database for PostgreSQL – Flexible Serverinstanz entscheiden, lassen Sie ausgehenden Datenverkehr an Microsoft Entra ID mithilfe des Microsoft Entra-Diensttags zu. Beim Einrichten von Lesereplikaten über Azure-Regionen hinweg erfordert Azure Database for PostgreSQL – Flexible Server die Möglichkeit, Datenverkehr sowohl für primäre als auch Replikate an den Zielport 5432 zu senden und zu empfangen, und zwar sowohl vom primären Server als auch vom Replikatserver an Azure-Speicher in primären und Replikatregionen.

• Integration privater DNS-Zonen: Mit der Integration privater Azure-DNS-Zonen können Sie das private DNS innerhalb des aktuellen VNet oder eines beliebigen Peer-VNet in derselben Region auflösen, in dem die private DNS-Zone verknüpft ist.

Verwenden einer privaten DNS-Zone

Privates DNS von Azure bietet einen zuverlässigen und sicheren DNS-Dienst für Ihr virtuelles Netzwerk. Privates Azure-DNS verwaltet Domänennamen im virtuellen Netzwerk und löst diese auf, ohne dass eine benutzerdefinierte DNS-Lösung konfiguriert werden muss.

Wenn Sie den privaten Netzwerkzugriff mit einem virtuellen Azure-Netzwerk verwenden, ist die Bereitstellung der Informationen zur privaten DNS-Zone obligatorisch, um die DNS-Auflösung durchführen zu können. Bei der Erstellung einer neuen Instanz von Azure Database for PostgreSQL – Flexible Server mit privatem Netzwerkzugriff müssen private DNS-Zonen verwendet werden, während die Azure Database for PostgreSQL – Flexible Serverinstanzen mit privatem Zugriff konfiguriert werden. Erstellen Sie daher für die Erstellung einer neuen Azure Database for PostgreSQL – Flexible Serverinstanz mit privatem Netzwerkzugriff mit API, ARM oder Terraform private DNS-Zonen und verwenden Sie diese beim Konfigurieren der Azure Database for PostgreSQL – Flexible Serverinstanzen mit privatem Zugriff. Weitere Informationen finden Sie unter REST-API-Spezifikationen für Microsoft Azure. Wenn Sie das Azure-Portal oder Azure CLI zum Erstellen von Azure Database for PostgreSQL – Flexible Serverinstanzen verwenden, können Sie den Namen einer privaten DNS-Zone angeben, die Sie zuvor in demselben oder einem anderen Abonnement erstellt haben, oder es wird automatisch eine private DNS-Standardzone in Ihrem Abonnement erstellt.

Wenn Sie eine Azure-API, eine Azure Resource Manager-Vorlage (ARM-Vorlage) oder Terraform verwenden, erstellen Sie private DNS-Zonen, die auf .postgres.database.azure.com enden. Verwenden Sie diese Zonen beim Konfigurieren von Azure Database for PostgreSQL – Flexible Serverinstanzen mit privatem Zugriff. Verwenden Sie beispielsweise das Formular [name1].[name2].postgres.database.azure.com oder [name].postgres.database.azure.com. Wenn Sie das Formular [name].postgres.database.azure.com verwenden, kann der Name nicht der Name sein, den Sie für eine Ihrer Azure Databases for PostgreSQL – Flexible Serverinstanzen verwenden, oder während der Bereitstellung wird eine Fehlermeldung angezeigt. Weitere Informationen finden Sie in der Übersicht über private DNS-Zonen.

Im Azure Portal, über die API, die Befehlszeilenschnittstelle oder mit ARM können Sie auch die beim Erstellen einer Azure Database for PostgreSQL – Flexible Serverinstanz angegebene private DNS-Zone in eine andere private DNS-Zone ändern, die im selben oder in einem anderen Abonnement vorhanden ist.

Wichtig

Die Möglichkeit, die private DNS-Zone von der, die Sie beim Erstellen Ihrer Azure Database for PostgreSQL – Flexible Serverinstanz angegeben haben, in eine andere private DNS-Zone zu ändern, ist derzeit für Server mit aktivierter Funktion für hohe Verfügbarkeit deaktiviert.

Nachdem Sie eine private Azure DNS-Zone erstellt haben, müssen Sie ein virtuelles Netzwerk damit verknüpfen. Nach der Verknüpfung können in diesem virtuellen Netzwerk gehostete Ressourcen auf die private DNS-Zone zugreifen.

Wichtig

Bei der Servererstellung für Azure Database for PostgreSQL – Flexible Server mit privatem Netzwerkzugriff wird das Vorhandensein von virtuellen Netzwerkverknüpfungen nicht mehr überprüft. Beim Erstellen eines Servers über das Portal bieten wir die Möglichkeit, eine Verknüpfung zur Servererstellung über das Kontrollkästchen Private DNS-Zone mit Ihrem virtuellen Netzwerk verknüpfen im Azure Portal zu erstellen.

Private DNS-Zonen sind resilient gegenüber regionalen Ausfällen, da die Zonendaten global verfügbar sind. Die Ressourcendatensätze in einer privaten Zone werden automatisch regionsübergreifend repliziert. Azure Privates DNS ist ein grundlegender, zonenredundanter Verfügbarkeitszonendienst. Weitere Informationen dazu finden Sie unter Unterstützung von Verfügbarkeitszonen für Azure-Dienste.

Integration mit einem benutzerdefinierten DNS-Server

Wenn Sie einen benutzerdefinierten DNS-Server verwenden, müssen Sie eine DNS-Weiterleitung verwenden, um den FQDN von Azure Database for PostgreSQL – Flexible Server aufzulösen. Die IP-Adresse der Weiterleitung sollte 168.63.129.16 sein.

Der benutzerdefinierte DNS-Server sollte sich innerhalb des VNet befinden oder über die DNS-Servereinstellung des VNet erreichbar sein. Weitere Informationen finden Sie unter Namensauflösung mithilfe eines eigenen DNS-Servers.

Private DNS-Zone und Peering virtueller Netzwerke

Die Einstellungen für private DNS-Zonen und das Peering virtueller Netzwerke sind voneinander unabhängig. Wenn Sie eine Verbindung mit der Azure Database for PostgreSQL – Flexible Serverinstanz von einem Client herstellen möchten, der in einem anderen virtuellen Netzwerk aus derselben Region oder einer anderen Region bereitgestellt wird, müssen Sie Verknüpfung der privaten DNS-Zone mit dem virtuellen Netzwerk herstellen. Weitere Informationen finden Sie unter Verknüpfen des virtuellen Netzwerks.

Hinweis

Es können ausschließlich private DNS-Zonen verknüpft werden, deren Namen auf postgres.database.azure.com enden. Ihr DNS-Zonenname kann nicht mit Ihrer/en Azure Database for PostgreSQL – Flexible Serverinstanz/en identisch sein, andernfalls schlägt die Namensauflösung fehl.

Um dem DNS-Eintrag einen Servernamen zuzuordnen, können Sie den Befehl nslookup in Azure Cloud Shell ausführen, indem Sie Azure PowerShell oder Bash verwenden. Ersetzen Sie dabei den Parameter <server_name> im folgenden Beispiel durch den Namen Ihres Servers:

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

Verwenden des Entwurfs für private Hub-and-Spoke-Netzwerke

Hub-and-Spoke ist ein beliebtes Netzwerkmodell für die effiziente Verwaltung von allgemeinen Kommunikations- oder Sicherheitsanforderungen.

Der Hub ist ein virtuelles Netzwerk, das als Zentrale für die Verwaltung externer Konnektivitäts- und Hostingdienste dient. Er hostet außerdem Dienste, die von mehreren Workloads verwendet werden. Der Hub koordiniert die gesamte Kommunikation zwischen den Spokes. IT-Regeln oder Prozesse wie die Sicherheit können den Datenverkehr überprüfen, routen und zentral verwalten. Die Spokes sind virtuelle Netzwerke, die Workloads hosten und sich über ein Peering virtueller Netzwerke mit dem zentralen Hub verbinden. Gemeinsame Dienste werden in ihren eigenen Subnetzen zur gemeinsamen Nutzung mit den Spokes gehostet. Ein Umkreissubnetz fungiert dann als Sicherheitsappliance.

Die Spokes sind ebenfalls virtuelle Netzwerke in Azure, mit denen einzelne Workloads isoliert werden. Der Datenverkehrsfluss zwischen dem lokalen Hauptsitz und Azure erfolgt über ExpressRoute oder Site-to-Site-VPN, das mit dem virtuellen Netzwerk des Hubs verbunden ist. Die virtuellen Netzwerke von den Spokes zum Hub sind per Peering verbunden und ermöglichen die Kommunikation mit lokalen Ressourcen. Sie können den Hub und jede Spoke in separaten Abonnements oder Ressourcengruppen implementieren.

Es gibt drei Hauptmuster für die Verbindung von virtuellen Spoke-Netzwerken untereinander:

• Direkt miteinander verbundene Spoke-Instanzen. Peerings virtueller Netzwerke oder VPN-Tunnel werden zwischen den virtuellen Spoke-Netzwerken erstellt, um eine direkte Konnektivität zu ermöglichen, ohne das virtuelle Hubnetzwerk zu durchqueren.
• Spokes kommunizieren über ein Netzwerkgerät. Jedes virtuelle Spoke-Netzwerk verfügt über ein Peering zum Virtual WAN oder zu einem virtuellen Hubnetzwerk. Eine Appliance leitet den Datenverkehr von Spoke zu Spoke weiter. Die Appliance kann von Microsoft (wie bei Virtual WAN) oder von Ihnen selbst verwaltet werden.
• Virtuelles Netzwerkgateway, das an das Hubnetzwerk angefügt ist und benutzerdefinierte Routen (USER Defined Routes, UDR) verwendet, um die Kommunikation zwischen den Spokes zu ermöglichen.

Mithilfe von Azure Virtual Network Manager (AVNM) können Sie für die zentrale Verwaltung von Konnektivitäts- und Sicherheitskontrollen neue Hub-and-Spoke-Topologien von virtuellen Netzwerken erstellen (bzw. für solche bereits vorhandenen Topologien ein Onboarding durchführen).

Kommunikation mit privat vernetzten Clients in verschiedenen Regionen

Häufig müssen Kunden eine Verbindung mit Clients in verschiedenen Azure-Regionen herstellen. Genauer gesagt: Diese Frage bezieht sich in der Regel auf das Verbinden von zwei VNETs (einer davon verfügt über Azure Database for PostgreSQL – Flexible Server und einen anderen Anwendungsclient), die sich in verschiedenen Regionen befinden. Es gibt mehrere Möglichkeiten, diese Konnektivität zu erreichen. Einige davon sind:

• Globales VNET-Peering. Die häufigste, da einfachste Methode, Netzwerke in verschiedenen Regionen miteinander zu verbinden. Das globale VNET-Peering erstellt eine Verbindung über den Azure-Backbone direkt zwischen den beiden gepeerten VNETs. Dies bietet den besten Netzwerkdurchsatz und die niedrigsten Latenzen für die Konnektivität mit dieser Methode. Wenn VNETs gepeert werden, verarbeitet Azure das Routing auch automatisch für Sie, diese VNETs können mit allen Ressourcen im gepeerten VNET kommunizieren, die auf einem VPN-Gateway eingerichtet sind.
• VNET-zu-VNET-Verbindung. Eine VNET-zu-VNET-Verbindung ist im Wesentlichen ein VPN zwischen den beiden verschiedenen Azure-Standorten. Die VNET-zu-VNET-Verbindung wird auf einem VPN-Gateway hergestellt. Dies bedeutet, dass Ihr Datenverkehr zwei zusätzliche Datenverkehrs-Hops im Vergleich zum globalen VNET-Peering verursacht. Im Vergleich zu dieser Methode gibt es auch zusätzliche Latenz und geringere Bandbreite.
• Kommunikation über Netzwerk-Appliance in der Hub- und Spoke-Architektur. Anstatt virtuelle Spoke-Netzwerke direkt miteinander zu verbinden, können Sie Netzwerkgeräte zur Weiterleitung des Datenverkehrs zwischen Spokes verwenden. Netzwerkgeräte bieten zusätzliche Dienste im Netzwerk wie eingehende Paketuntersuchung und Segmentierung oder Überwachung des Datenverkehrs, können aber Wartezeiten und Leistungsengpässe verursachen, wenn sie nicht richtig dimensioniert sind.

Replikation zwischen Azure-Regionen und virtuellen Netzwerken mit privatem Netzwerk

Bei der Datenbankreplikation werden Daten von einem zentralen oder primären Server auf mehrere Server kopiert, die als „Replikate“ bezeichnet werden. Der primäre Server akzeptiert Lese- und Schreibvorgänge, während die Replikate schreibgeschützte Transaktionen ausführen. Der primäre Server und die Replikate bilden gemeinsam ein Datenbankcluster. Ziel der Datenbankreplikation ist es, Redundanz, Konsistenz, hohe Verfügbarkeit und Barrierefreiheit von Daten sicherzustellen, insbesondere in besonders datenverkehrsintensiven, unternehmenskritischen Anwendungen.

Azure Database for PostgreSQL – Flexible Server bietet zwei Methoden für Replikationen: Physische Replikation (d. h. Streaming) über integriertes Feature für „Lesereplikate“ und logische Replikation. Beide Methoden sind ideal für unterschiedliche Anwendungsfälle, und ein Benutzer kann je nach dem Endziel eine vor der anderen auswählen.

Die Replikation über Azure-Regionen hinweg mit separaten virtuellen Netzwerken (VNets) in jeder Region erfordert Konnektivität über regionale virtuelle Netzwerkgrenzen hinweg, die über Peering virtueller Netzwerke oder in Hub-and-Spoke-Architekturen über eine Netzwerkappliance bereitgestellt werden kann.

Standardmäßig ist der Bereich für die DNS-Namensauflösung auf ein virtuelles Netzwerk festgelegt. Dies bedeutet, dass ein beliebiger Client in einem virtuellen Netzwerk (VNET1) den FQDN für Azure Database for PostgreSQL – Flexible Server in einem anderen virtuellen Netzwerk (VNET2) nicht auflösen kann.

Zur Behebung dieses Problems müssen Sie sicherstellen, dass Clients in VNET1 auf die private DNS-Zone für Azure Database for PostgreSQL – Flexible Server zugreifen können. Dies können Sie erreichen, indem Sie Ihrer Azure Database for PostgreSQL – Flexible Serverinstanz eine virtuelle Netzwerkverknüpfung mit der privaten DNS-Zone hinzufügen.

Nicht unterstützte virtuelle Netzwerkszenarios

Im Folgenden finden Sie einige Einschränkungen bei der Arbeit mit virtuellen Netzwerken, die über VNET-Integration erstellt werden:

• Nachdem die Azure Database for PostgreSQL – Flexible Serverinstanz in einem virtuellen Netzwerk und Subnetz bereitgestellt wurde, können Sie diese nicht in ein anderes virtuelles Netzwerk oder Subnetz verschieben. Auch das VNet kann in keine andere Ressourcengruppe oder kein anderes Abonnement verschoben werden.
• Die Subnetzgröße (Adressräume) kann nicht mehr erhöht werden, wenn bereits Ressourcen im Subnetz vorhanden sind.
• In VNet eingefügte Ressourcen können standardmäßig nicht mit Private Link interagieren. Wenn Sie Private Link für private Netzwerke verwenden möchten, lesen Sie Azure Database for PostgreSQL – Flexible Servernetzwerke mit Private Link.

Wichtig

Der Azure Resource Manager unterstützt die Möglichkeit, Ressourcen als Sicherheitssteuerung zu sperren. Ressourcensperren werden auf die Ressource angewendet und gelten für alle Benutzer und Rollen. Es gibt zwei Arten von Ressourcensperren: CanNotDelete und ReadOnly. Diese Arten von Sperren können entweder auf eine private DNS-Zone oder auf einen einzelnen Eintragssatz angewendet werden. Das Anwenden einer Sperre von einem der beiden Typen auf private DNS-Zonen oder eine einzelne Datensatzgruppe kann die Fähigkeit von Azure Database for PostgreSQL – Flexible Server beeinträchtigen, DNS-Einträge zu aktualisieren. Darüber hinaus kann dies bei wichtigen Vorgängen im DNS (z. B. Hochverfügbarkeitsfailover vom primären zum sekundären Server) Probleme verursachen. Stellen Sie daher sicher, dass Sie keine Sperren für private DNS-Zonen oder Datensätze verwenden, wenn Sie Hochverfügbarkeitsfeatures mit Azure Database for PostgreSQL – Flexible Server nutzen.

Hostname

Unabhängig von Ihrer Netzwerkoption empfiehlt es sich, beim Herstellen einer Verbindung mit Ihrer Azure Database for PostgreSQL – Flexible Serverinstanz immer einen FQDN als Hostnamen zu verwenden. Es ist nicht gewährleistet, dass die IP-Adresse des Servers statisch bleibt. Mithilfe des FQDN können Sie verhindern, dass Änderungen an der Verbindungszeichenfolge vorgenommen werden.

Ein Beispiel, bei dem ein FQDN als Hostname verwendet wird, ist hostname = servername.postgres.database.azure.com. Vermeiden Sie nach Möglichkeit die Verwendung von hostname = 10.0.0.4 (eine private Adresse) oder hostname = 40.2.45.67 (eine öffentliche Adresse).

Nächste Schritte

• Erfahren Sie, wie Sie eine Instanz für einen flexiblen Azure Database for PostgreSQL-Server mithilfe der Option Privater Zugriff (VNET-Integration) im Azure-Portal oder über die Azure CLI erstellen.