Freigeben über

Netzwerk mit privatem Zugriff (Virtual Network Integration) für Azure-Datenbank für PostgreSQL

In diesem Artikel werden Konnektivitäts- und Netzwerkkonzepte für Azure Database für flexible Serverinstanzen von PostgreSQL beschrieben.

Wenn Sie eine Azure-Datenbank für eine flexible Serverinstanz für PostgreSQL erstellen, müssen Sie eine der folgenden Netzwerkoptionen auswählen:

  • Privater Zugriff (VNet-Integration)
  • Öffentlicher Zugriff (zulässige IP-Adressen) und privater Endpunkt

In diesem Dokument werden Netzwerkoptionen für Privater Zugriff (Virtual Network-Integration) beschrieben.

Privater Zugriff (VNet-Integration)

Sie können eine Azure-Datenbank für PostgreSQL flexible Server-Instanz in Ihrem virtuellen Azure-Netzwerk bereitstellen, indem Sie eine virtuelle Netzwerk-Injektion verwenden. 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 selben virtuellen Netzwerk mit Ihrer Azure Database for PostgreSQL Flexible Server-Instanz über private IP-Adressen.
  • Verwenden Sie ein VPN oder Azure ExpressRoute, um eine Verbindung von Nicht-Azure-Ressourcen mit Ihrer Azure-Datenbank für flexible Serverinstanz von PostgreSQL herzustellen.
  • Stellen Sie sicher, dass die flexible Serverinstanz der Azure-Datenbank für PostgreSQL keinen öffentlichen Endpunkt aufweist, auf den über das Internet zugegriffen werden kann.

Diagramm, das zeigt, wie Peering zwischen virtuellen Netzwerken funktioniert, eines davon enthält eine Azure-Datenbank für PostgreSQL flexible Serverinstanz.

Im obigen Diagramm ist Folgendes zu sehen:

  • Azure Database 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 für flexible Serverinstanzen von PostgreSQL zugreifen.
  • Anwendungen, die in einem anderen virtuellen Netzwerk (VNet-2) bereitgestellt werden, haben keinen direkten Zugriff auf Azure Database für flexible Serverinstanzen von PostgreSQL. Sie müssen virtuelles Netzwerk-Peering für eine private DNS-Zone durchführen, bevor sie auf die flexible Serverinstanz zugreifen können.

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-Datenbank für flexible Serverinstanz von PostgreSQL befinden. Weitere Informationen zu virtuellen Netzwerken finden Sie unter Übersicht über Azure Virtual Network.

Im Folgenden finden Sie einige Konzepte, mit denen Sie vertraut sind, wenn Sie virtuelle Netzwerke verwenden, in denen Ressourcen in ein virtuelles Netzwerk mit Azure Database für flexible Serverinstanzen von PostgreSQL integriert sind:

  • Delegiertes Subnetz: Ein virtuelles Netzwerk enthält Subnetze. 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 Azure-Datenbank für PostgreSQL flexible Serverinstanz, die in ein virtuelles Netzwerk integriert ist, muss sich in einem subnetz befinden, das delegiert ist. Das heißt, nur Azure Database für flexible Serverinstanzen von PostgreSQL kann 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 angeben können, ist /28, der 16 IP-Adressen für das Subnetz bereitstellt. Die erste und letzte Adresse in einem Netzwerk oder Subnetz kann 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. Dadurch bleiben 11 verfügbare IP-Adressen für einen CIDR-Bereich /28 verfügbar. Eine einzelne Azure-Datenbank für eine flexible PostgreSQL-Serverinstanz mit Hochverfügbarkeitsfunktionen verwendet vier Adressen.

    Stellen Sie bei Replikations- und Microsoft Entra-Verbindungen sicher, dass Routingtabellen keinen Einfluss auf den Datenverkehr haben. Ein gängiges Muster besteht darin, den gesamten ausgehenden Datenverkehr über eine Azure-Firewall oder eine benutzerdefinierte lokale Netzwerkfilterungs-Appliance weiterzuleiten.

    Wenn das Subnetz über eine Routentabelle verfügt, die der Regel zugeordnet ist, den gesamten Datenverkehr an ein virtuelles Gerät weiterzuleiten:

    • Fügen Sie eine Regel mit dem Ziel-Diensttag AzureActiveDirectory und dem nächsten Hop hinzu Internet.
    • Fügen Sie eine Regel mit dem Ziel-IP-Bereich hinzu, der mit dem Subnetzbereich der flexiblen Serverinstanz von Azure Database for PostgreSQL übereinstimmt, und den nächsten Hop Virtual Network.

    Wichtig

    Die Namen AzureFirewallSubnet, AzureFirewallManagementSubnet, AzureBastionSubnet und GatewaySubnet sind in Azure reserviert. Verwenden Sie keinen dieser Namen als Ihren Subnetznamen. Darüber hinaus sollten virtuelle Netzwerke keinen überlappenden Adressraum zum Erstellen von regionsübergreifenden Replikaten aufweisen.

  • Netzwerksicherheitsgruppe (NSG): Mit Sicherheitsregeln in Netzwerksicherheitsgruppen können Sie den Typ des ein- und ausgehenden Netzwerkdatenverkehrs von Subnetzen virtueller Netzwerke 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 NSGs, bei denen eine ASG Teil der Regel mit flexiblen Serverinstanzen von Azure Database for PostgreSQL ist, nicht unterstützt. Es wird derzeit empfohlen, die IP-basierte Filterung von Quelle oder Ziel in einer NSG zu verwenden.

    Hohe Verfügbarkeit und andere Features von Azure Database für PostgreSQL-Server erfordern die Möglichkeit, Datenverkehr an den Zielport 5432 innerhalb des virtuellen Azure-Netzwerksubnetz zu senden/empfangen, in dem eine flexible Azure-Serverinstanz für PostgreSQL bereitgestellt und an Azure Storage für die Protokollarchivierung bereitgestellt wird. Wenn Sie NSGs erstellen, um den Datenverkehr zu oder von Ihrer Azure-Datenbank für PostgreSQL Flexible Server in dem Subnetz zu verweigern, in dem sie bereitgestellt wird, stellen Sie sicher, dass der Datenverkehr innerhalb des Subnetzes zum Zielport 5432 und auch zum Speicher zugelassen wird, indem Sie das Service-Tag Storage als Ziel verwenden. Für hohe Verfügbarkeit empfiehlt es sich, einen Microsoft.Storage-Dienstendpunkt hinzuzufügen, da dadurch das richtige Datenverkehrsrouting auf das Azure-Speicherkonto sichergestellt wird, das zum Hochladen von Write Ahead Log(WAL)-Dateien verwendet wird.

    Sie können diese Ausnahmeregel weiter filtern, indem Sie Ihre Azure-Region der Bezeichnung wie us-east.storage hinzufügen. Wenn Sie auch die Microsoft Entra-Authentifizierung verwenden, um Anmeldungen bei Ihrer flexiblen Azure-Datenbank für PostgreSQL zu authentifizieren, ermöglichen Sie ausgehenden Datenverkehr an Microsoft Entra-ID mithilfe eines Microsoft Entra-Diensttags.

    Wenn Sie Lesereplikate über Azure-Regionen hinweg einrichten, muss Ihre flexible Serverinstanz von Azure Database for PostgreSQL in der Lage sein, Datenverkehr an den Zielport 5432 sowohl für den Primär- als auch für den Replikatserver und an Azure Storage in Primär- und Replikatsregionen sowohl vom Primär- als auch vom Replikatserver zu senden oder zu empfangen. Der erforderliche TCP-Zielport für Storage ist 443.

  • Integration einer privaten DNS-Zone: Durch die Integration einer privaten Azure-DNS-Zone können Sie das private DNS innerhalb des aktuellen virtuellen Netzwerks oder eines beliebigen virtuellen Netzwerks in der Region auflösen, mit dem die private DNS-Zone verbunden 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. Zur Erstellung einer neuen Azure Database for PostgreSQL Flexible Server-Instanz mit privatem Netzwerkzugang müssen private DNS-Zonen verwendet werden. Dies gilt während der Konfiguration von Azure Database for PostgreSQL Flexible Server-Instanzen mit privatem Zugriff.

Wichtig

Bei der Verwendung einer privaten DNS-Zone in einem anderen Abonnement muss in diesem Abonnement ebenfalls der Ressourcenanbieter „Microsoft.DBforPostgreSQL” registriert sein, andernfalls kann die Bereitstellung einer flexiblen Serverinstanz von Azure Database for PostgreSQL nicht abgeschlossen werden.

Erstellen Sie private DNS-Zonen für eine neue Azure-Datenbank für PostgreSQL zur Erstellung flexibler Serverinstanzen über privaten Netzwerkzugriff mithilfe einer API, einer Azure Resource Manager-Vorlage (ARM-Vorlage), Bicep oder Terraform. Verwenden Sie sie dann, während Sie die Azure Database für PostgreSQL-Flexible Serverinstanzen mit privatem Zugriff konfigurieren. Weitere Informationen finden Sie in den REST-API-Spezifikationen für Azure.

Wenn Sie das Azure-Portal oder die Azure CLI zum Erstellen der Azure-Datenbank für flexible Serverinstanzen von PostgreSQL verwenden, können Sie einen privaten DNS-Zonennamen angeben, den Sie zuvor in demselben oder einem anderen Abonnement erstellt haben, oder eine standardmäßige private DNS-Zone wird automatisch in Ihrem Abonnement erstellt.

Wenn Sie eine Azure-API, eine ARM-Vorlage, Bicep oder Terraform verwenden, erstellen Sie Private DNS-Zonen, die auf .postgres.database.azure.com enden. Verwenden Sie diese Zonen, während Sie Azure Database für flexible Serverinstanzen mit privatem Zugriff konfigurieren. 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.comverwenden, kann der Name nicht der Name sein, den Sie für eine Ihrer flexiblen Azure-Serverinstanzen für PostgreSQL verwenden, oder Sie erhalten während der Bereitstellung eine Fehlermeldung. Weitere Informationen finden Sie in der Übersicht über private DNS-Zonen.

Wenn Sie das Azure-Portal, apIs, die Azure CLI oder eine ARM-Vorlage verwenden, können Sie auch die Private DNS-Zone von der Zone ändern, die Sie bei der Erstellung Ihrer Azure-Datenbank für PostgreSQL flexible Serverinstanz in eine andere private DNS-Zone für dasselbe oder andere Abonnement angegeben haben.

Wichtig

Die Möglichkeit, eine private DNS-Zone von der Zone zu ändern, die Sie beim Erstellen Ihrer Azure-Datenbank für die flexible Serverinstanz für PostgreSQL in eine andere private DNS-Zone angegeben haben, ist derzeit für Server mit aktivierter Hochverfügbarkeitsfunktion deaktiviert.

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

Wichtig

Bei der Servererstellung für flexible Serverinstanzen von Azure Database for PostgreSQL mit privatem Netzwerk 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 Ihrer flexiblen Serverinstanz von Azure Database for PostgreSQL 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-Datenbank für PostgreSQL-Flexiblen Serverinstanz von einem Client herstellen möchten, der in einem anderen virtuellen Netzwerk in derselben oder einer anderen Region bereitgestellt wird, müssen Sie die Private DNS-Zone mit dem virtuellen Netzwerk verknüpfen. 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 Azure-Datenbank für flexible Serverinstanzen von PostgreSQL übereinstimmen. Andernfalls schlägt die Namensauflösung fehl.

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

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 Azure 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:

  • Spokes sind direkt miteinander verbunden: 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 eine Netzwerk-Appliance: Jedes virtuelle Spoke-Netzwerk verfügt über ein Peering zu einem virtuellen 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.
  • Ein virtuelles Netzwerkgateway, das an das Hubnetzwerk angefügt ist und benutzerdefinierte Routen verwendet: Ermöglicht die Kommunikation zwischen den Spokes.

Das Diagramm zeigt die grundlegende Hub-and-Spoke-Architektur mit Hybridkonnektivität über Express Hub.

Mithilfe von Azure Virtual Network Manager 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 virtuellen Netzwerken (einer davon verfügt über eine flexible Azure-Datenbank für PostgreSQL-Serverinstanz und einen anderen über einen Anwendungsclient), die sich in verschiedenen Regionen befinden.

Es gibt mehrere Möglichkeiten, diese Konnektivität zu erreichen, einschließlich:

  • Globales Peering virtueller Netzwerke. Die häufigste, da einfachste Methode, Netzwerke in verschiedenen Regionen miteinander zu verbinden. Das globale Peering virtueller Netzwerke erstellt eine Verbindung über den Azure-Backbone direkt zwischen den beiden Virtual Networks mit Peering. Diese Methode bietet den besten Netzwerkdurchsatz und die niedrigsten Latenzen für die Konnektivität. Wenn ein Peering virtueller Netzwerke erfolgt, verarbeitet Azure auch das Routing automatisch für Sie. Diese virtuellen Netzwerke können mit allen Ressourcen im virtuellen Peernetzwerk kommunizieren, die auf einem VPN-Gateway eingerichtet sind.
  • Netzwerk-zu-Netzwerk-Verbindung. Eine Verbindung zwischen virtuellen Netzwerken (Netzwerk zu Netzwerk-Verbindung) ist im Wesentlichen ein VPN zwischen den beiden verschiedenen Azure-Standorten. Die Netzwerk zu Netzwerk-Verbindung wird für ein VPN-Gateway eingerichtet. Ihr Datenverkehr verursacht zwei zusätzliche Datenverkehrs-Hops im Vergleich zum globalen Peering virtueller Netzwerke. 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 bietet zwei Methoden für Replikationen: physische (d. h. Streaming) über die integrierte Read Replica-Funktion und logische Replikation. Beide Methoden sind ideal für unterschiedliche Anwendungsfälle, und ein Benutzer kann je nach dem Endziel eine der beiden auswählen.

Die Replikation über Azure-Regionen hinweg mit separaten virtuellen Netzwerken in jeder Region erfordert Konnektivität über regionale virtuelle Netzwerkgrenzen hinweg, die über das 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. Kein Client in einem virtuellen Netzwerk (VNET1) kann den FQDN der flexiblen Serverinstanz von Azure Database for PostgreSQL in einem anderen virtuellen Netzwerk (VNET2) auflösen.

Um dieses Problem zu beheben, müssen Sie sicherstellen, dass Clients in VNET1 auf die private DNS-Zone der flexiblen Serverinstanz von Azure Database for PostgreSQL zugreifen können. Fügen Sie eine virtuelle Netzwerkverbindung zur privaten DNS-Zone Ihrer Azure-Datenbank für flexible Serverinstanz von PostgreSQL hinzu.

Nicht unterstützte virtuelle Netzwerkszenarios

Hier finden Sie einige Einschränkungen bei der Arbeit mit virtuellen Netzwerken, die über die Virtual Network-Integration erstellt werden:

  • Nachdem eine flexible Serverinstanz von Azure Database für PostgreSQL in einem virtuellen Netzwerk und Subnetz bereitgestellt wurde, können Sie sie 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 virtuellen Netzwerken eingefügte Ressourcen können standardmäßig nicht mit Private Link interagieren. Wenn Sie private Verknüpfungen für private Netzwerke verwenden möchten, lesen Sie Azure Database for PostgreSQL Networking with Private Link.

Wichtig

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 auf eine private DNS-Zone oder einen einzelnen Datensatz kann die Fähigkeit einer flexiblen Azure-Datenbank für eine PostgreSQL-Serverinstanz 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 aus diesen Gründen sicher, dass Sie keine private DNS-Zone oder Eintragssperren verwenden, wenn Sie Hochverfügbarkeitsfeatures mit einer Azure-Datenbank für flexible Serverinstanz von PostgreSQL verwenden.

Hostname

Unabhängig von der von Ihnen gewählten Netzwerkoption wird empfohlen, immer einen FQDN als Hostnamen zu verwenden, wenn Sie eine Verbindung mit Ihrer Azure-Datenbank für flexible Serverinstanz von PostgreSQL herstellen. 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).

Verwandte Inhalte

  • Last updated on