Udostępnij za pośrednictwem

Sieć z dostępem prywatnym (integracja sieci wirtualnej) dla usługi Azure Database for PostgreSQL — serwer elastyczny

  • Artykuł

DOTYCZY: Azure Database for PostgreSQL — serwer elastyczny

W tym artykule opisano pojęcia dotyczące łączności i sieci dla usługi Azure Database for PostgreSQL — serwer elastyczny.

Podczas tworzenia serwera elastycznego usługi Azure Database for PostgreSQL należy wybrać jedną z następujących opcji sieciowych:

  • Dostęp prywatny (integracja z siecią wirtualną)
  • Dostęp publiczny (dozwolone adresy IP) i prywatny punkt końcowy

W tym dokumencie opisano opcję sieci dostępu prywatnego (integracja sieci wirtualnej).

Dostęp prywatny (integracja z siecią wirtualną)

Serwer elastyczny usługi Azure Database for PostgreSQL można wdrożyć w sieci wirtualnej platformy Azure przy użyciu iniekcji sieci wirtualnej. Sieci wirtualne platformy Azure zapewniają prywatną i bezpieczną komunikację sieci. Zasoby w sieci wirtualnej mogą komunikować się za pośrednictwem prywatnych adresów IP, które zostały przypisane w tej sieci.

Wybierz tę opcję sieci, jeśli chcesz uzyskać następujące możliwości:

  • Połącz się z zasobów platformy Azure w tej samej sieci wirtualnej z serwerem elastycznym usługi Azure Database for PostgreSQL przy użyciu prywatnych adresów IP.
  • Użyj sieci VPN lub usługi Azure ExpressRoute, aby nawiązać połączenie z zasobów spoza platformy Azure z serwerem elastycznym usługi Azure Database for PostgreSQL.
  • Upewnij się, że serwer elastyczny usługi Azure Database for PostgreSQL nie ma publicznego punktu końcowego dostępnego za pośrednictwem Internetu.

Diagram przedstawiający sposób działania komunikacji równorzędnej między sieciami wirtualnymi, z których jeden obejmuje serwer elastyczny usługi Azure Database for PostgreSQL.

Na powyższym diagramie:

  • Elastyczne serwery usługi Azure Database for PostgreSQL są wstrzykiwane do podsieci 10.0.1.0/24 sieci wirtualnej VNet-1.
  • Aplikacje wdrożone w różnych podsieciach w tej samej sieci wirtualnej mogą uzyskiwać bezpośredni dostęp do serwerów elastycznych usługi Azure Database for PostgreSQL.
  • Aplikacje wdrożone w innej sieci wirtualnej (VNet-2) nie mają bezpośredniego dostępu do serwerów elastycznych usługi Azure Database for PostgreSQL. Aby uzyskać dostęp do serwera elastycznego, należy wykonać komunikację równorzędną sieci wirtualnych dla strefy Prywatna strefa DNS.

Pojęcia dotyczące sieci wirtualnej

Sieć wirtualna platformy Azure zawiera prywatną przestrzeń adresową IP skonfigurowaną do użycia. Sieć wirtualna musi znajdować się w tym samym regionie świadczenia usługi Azure, co serwer elastyczny usługi Azure Database for PostgreSQL. Aby dowiedzieć się więcej o sieciach wirtualnych, zobacz Omówienie usługi Azure Virtual Network.

Poniżej przedstawiono kilka pojęć, które należy znać podczas korzystania z sieci wirtualnych, w których zasoby są zintegrowane z siecią wirtualną z elastycznymi serwerami usługi Azure Database for PostgreSQL:

  • Podsieć delegowana: sieć wirtualna zawiera podsieci (podsieci). Podsieci umożliwiają segmentowanie sieci wirtualnej na mniejsze przestrzenie adresowe. Zasoby platformy Azure są wdrażane w określonych podsieciach w sieci wirtualnej.

    Serwer elastyczny usługi Azure Database for PostgreSQL zintegrowany z siecią wirtualną musi znajdować się w delegowanej podsieci. Oznacza to, że tylko serwery elastyczne usługi Azure Database for PostgreSQL mogą używać tej podsieci. W podsieci delegowanej nie mogą znajdować się żadne inne typy zasobów platformy Azure. Delegujesz podsieć, przypisując jej właściwość delegowania jako Microsoft.DBforPostgreSQL/flexibleServers.

    Najmniejszy zakres CIDR, który można określić dla podsieci to /28, który zapewnia 16 adresów IP. Nie można przypisać pierwszego i ostatniego adresu w żadnej sieci lub podsieci do żadnego pojedynczego hosta. Platforma Azure rezerwuje pięć adresów IP, które mają być używane wewnętrznie przez sieć platformy Azure, w tym dwa adresy IP, których nie można przypisać do hosta, jak wspomniano. Pozostawia to 11 dostępnych adresów IP dla zakresu CIDR /28. Jeden serwer elastyczny usługi Azure Database for PostgreSQL z funkcjami wysokiej dostępności używa czterech adresów.

    W przypadku replikacji i połączeń firmy Microsoft Entra upewnij się, że tabele tras nie wpływają na ruch. Typowym wzorcem jest kierowanie całego ruchu wychodzącego za pośrednictwem usługi Azure Firewall lub niestandardowego lokalnego urządzenia filtrowania sieci.

    Jeśli podsieć ma tabelę tras skojarzona z regułą w celu kierowania całego ruchu do urządzenia wirtualnego:

    • Dodaj regułę z tagiem AzureActiveDirectory usługi docelowej i następnym przeskokiem Internet.
    • Dodaj regułę z docelowym zakresem adresów IP tak samo jak zakres podsieci usługi Azure Database for PostgreSQL — serwer elastyczny i następny przeskok Virtual Network.

    Ważne

    AzureFirewallSubnetNazwy , AzureFirewallManagementSubnet, AzureBastionSubneti GatewaySubnet są zarezerwowane na platformie Azure. Nie używaj żadnej z tych nazw jako nazwy podsieci. Ponadto sieci wirtualne nie powinny mieć nakładających się przestrzeni adresowych do tworzenia replik między regionami.

  • Sieciowa grupa zabezpieczeń: reguły zabezpieczeń w sieciowych grupach zabezpieczeń umożliwiają filtrowanie typu ruchu sieciowego, który może przepływać w podsieciach sieci wirtualnych i interfejsach sieciowych i wychodzących z sieci. Aby uzyskać więcej informacji, zobacz Omówienie sieciowej grupy zabezpieczeń.

    Grupy zabezpieczeń aplikacji ułatwiają kontrolowanie zabezpieczeń warstwy 4 przy użyciu sieciowych grup zabezpieczeń dla sieci prostych. Umożliwia on szybkie wykonywanie następujących zadań:

    • Przyłącz maszyny wirtualne do usługi ASG lub usuń maszyny wirtualne z grupy asg.
    • Dynamiczne stosowanie reguł do tych maszyn wirtualnych lub usuwanie reguł z tych maszyn wirtualnych.

    Aby uzyskać więcej informacji, zobacz Omówienie usługi ASG.

    Obecnie nie obsługujemy sieciowych grup zabezpieczeń, w których grupa zabezpieczeń jest częścią reguły z usługą Azure Database for PostgreSQL — serwer elastyczny. Obecnie zalecamy używanie filtrowania źródłowego lub docelowego opartego na adresach IP w sieciowej grupie zabezpieczeń.

    Wysoka dostępność i inne funkcje usługi Azure Database for PostgreSQL — serwer elastyczny wymagają możliwości wysyłania/odbierania ruchu do docelowego portu 5432 w podsieci sieci wirtualnej platformy Azure, w której wdrożono usługę Azure Database for PostgreSQL — serwer elastyczny i do usługi Azure Storage na potrzeby archiwizacji dzienników. Jeśli tworzysz sieciowe grupy zabezpieczeń w celu odmowy przepływu ruchu do lub z serwera elastycznego usługi Azure Database for PostgreSQL w podsieci, w której jest wdrożona, upewnij się, że ruch do portu docelowego 5432 znajduje się w podsieci, a także do usługi Storage przy użyciu tagu usługi Storage jako miejsca docelowego.

    Tę regułę wyjątku można dodatkowo filtrować , dodając region świadczenia usługi Azure do etykiety, takiej jak us-east.storage. Ponadto jeśli zdecydujesz się używać uwierzytelniania entra firmy Microsoft do uwierzytelniania logów na serwerze elastycznym usługi Azure Database for PostgreSQL, zezwól na ruch wychodzący do identyfikatora Entra firmy Microsoft przy użyciu tagu usługi Microsoft Entra.

    Podczas konfigurowania replik do odczytu w różnych regionach platformy Azure usługa Azure Database for PostgreSQL — serwer elastyczny wymaga możliwości wysyłania lub odbierania ruchu do portu docelowego 5432 dla zarówno podstawowego, jak i repliki, oraz do usługi Azure Storage w regionach podstawowych i repliki zarówno z serwerów podstawowych, jak i replikowych. Wymagany docelowy port TCP dla magazynu to 443.

  • integracja strefy Prywatna strefa DNS: integracja strefy usługi Azure Prywatna strefa DNS umożliwia rozpoznawanie prywatnego systemu DNS w bieżącej sieci wirtualnej lub dowolnej równorzędnej sieci wirtualnej w regionie, w której jest połączona strefa Prywatna strefa DNS.

Używanie strefy Prywatna strefa DNS

Usługa Azure Prywatna strefa DNS zapewnia niezawodną i bezpieczną usługę DNS dla sieci wirtualnej. Usługa Azure Prywatna strefa DNS zarządza i rozpoznaje nazwy domen w sieci wirtualnej bez konieczności konfigurowania niestandardowego rozwiązania DNS.

W przypadku korzystania z dostępu do sieci prywatnej z siecią wirtualną platformy Azure podanie informacji o strefie Prywatna strefa DNS jest obowiązkowe w celu przeprowadzenia rozpoznawania nazw DNS. W przypadku nowego elastycznego tworzenia serwera usługi Azure Database for PostgreSQL przy użyciu dostępu do sieci prywatnej należy używać stref Prywatna strefa DNS podczas konfigurowania elastycznych serwerów usługi Azure Database for PostgreSQL z dostępem prywatnym.

Ważne

W przypadku korzystania z prywatnej strefy DNS w innej subskrypcji ta subskrypcja musi mieć zarejestrowanego dostawcę zasobów Microsoft.DBforPostgreSQL. W przeciwnym razie wdrożenie serwera elastycznego usługi Azure Database for PostgreSQL nie zostanie ukończone.

W przypadku nowego elastycznego tworzenia serwera usługi Azure Database for PostgreSQL przy użyciu dostępu do sieci prywatnej za pomocą interfejsu API, szablonu usługi Azure Resource Manager (szablonu usługi ARM) lub narzędzia Terraform utwórz strefy Prywatna strefa DNS. Następnie należy ich używać podczas konfigurowania elastycznych serwerów usługi Azure Database for PostgreSQL z dostępem prywatnym. Aby uzyskać więcej informacji, zobacz Specyfikacje interfejsu API REST dla platformy Azure.

Jeśli używasz witryny Azure Portal lub interfejsu wiersza polecenia platformy Azure do tworzenia serwerów elastycznych usługi Azure Database for PostgreSQL, możesz podać nazwę strefy Prywatna strefa DNS, która została wcześniej utworzona w tej samej lub innej subskrypcji, albo domyślna strefa Prywatna strefa DNS zostanie automatycznie utworzona w ramach subskrypcji.

Jeśli używasz interfejsu API platformy Azure, szablonu usługi ARM lub narzędzia Terraform, utwórz strefy Prywatna strefa DNS kończące się na ..postgres.database.azure.com Użyj tych stref podczas konfigurowania elastycznych serwerów usługi Azure Database for PostgreSQL z dostępem prywatnym. Na przykład użyj formularza [name1].[name2].postgres.database.azure.com lub [name].postgres.database.azure.com. Jeśli zdecydujesz się użyć formularza [name].postgres.database.azure.com, nazwa nie może być nazwą używaną dla jednego z serwerów elastycznych usługi Azure Database for PostgreSQL lub podczas aprowizacji zostanie wyświetlony komunikat o błędzie. Aby uzyskać więcej informacji, zobacz omówienie stref Prywatna strefa DNS.

W przypadku korzystania z witryny Azure Portal, interfejsów API, interfejsu wiersza polecenia platformy Azure lub szablonu usługi ARM można również zmienić strefę Prywatna strefa DNS z tej, która została podana podczas tworzenia elastycznego serwera usługi Azure Database for PostgreSQL na inną strefę Prywatna strefa DNS, która istnieje dla tej samej lub innej subskrypcji.

Ważne

Możliwość zmiany strefy Prywatna strefa DNS z tej, która została podana podczas tworzenia serwera elastycznego usługi Azure Database for PostgreSQL na inny serwer Prywatna strefa DNS, jest obecnie wyłączona dla serwerów z włączoną funkcją wysokiej dostępności.

Po utworzeniu strefy Prywatna strefa DNS na platformie Azure należy połączyć z nią sieć wirtualną. Zasoby hostowane w połączonej sieci wirtualnej mogą następnie uzyskiwać dostęp do strefy Prywatna strefa DNS.

Ważne

Nie weryfikujemy już obecności łącza sieci wirtualnej podczas tworzenia serwera dla usługi Azure Database for PostgreSQL — serwer elastyczny z siecią prywatną. Podczas tworzenia serwera za pośrednictwem portalu udostępniamy klientowi możliwość utworzenia linku do tworzenia serwera za pomocą pola wyboru Połącz strefę Prywatna strefa DNS z siecią wirtualną w witrynie Azure Portal.

Strefy prywatne DNS są odporne na awarie regionalne, ponieważ dane strefy są globalnie dostępne. Rekordy zasobów w strefie prywatnej są automatycznie replikowane w różnych regionach. Azure Prywatna strefa DNS to podstawowa, strefowo nadmiarowa usługa strefy dostępności. Aby uzyskać więcej informacji, zobacz Usługi platformy Azure z obsługą stref dostępności.

Integracja z niestandardowym serwerem DNS

Jeśli używasz niestandardowego serwera DNS, musisz użyć usługi przesyłania dalej DNS, aby rozpoznać nazwę FQDN usługi Azure Database for PostgreSQL — serwer elastyczny. Adres IP usługi przesyłania dalej powinien mieć wartość 168.63.129.16.

Niestandardowy serwer DNS powinien znajdować się w sieci wirtualnej lub osiągalny za pośrednictwem ustawienia serwera DNS sieci wirtualnej. Aby dowiedzieć się więcej, zobacz Rozpoznawanie nazw używające własnego serwera DNS.

Prywatna strefa DNS strefy i komunikacji równorzędnej sieci wirtualnych

Prywatna strefa DNS ustawienia strefy i komunikacja równorzędna sieci wirtualnych są niezależne od siebie. Jeśli chcesz nawiązać połączenie z serwerem elastycznym usługi Azure Database for PostgreSQL z poziomu klienta aprowizowanego w innej sieci wirtualnej z tego samego regionu lub innego regionu, musisz połączyć strefę Prywatna strefa DNS z siecią wirtualną. Aby uzyskać więcej informacji, zobacz Łączenie sieci wirtualnej.

Uwaga

Można łączyć tylko Prywatna strefa DNS nazw stref kończących się ciągiem postgres.database.azure.com . Nazwa strefy DNS nie może być taka sama jak serwery elastyczne usługi Azure Database for PostgreSQL. W przeciwnym razie rozpoznawanie nazw kończy się niepowodzeniem.

Aby zamapować nazwę serwera na rekord DNS, możesz uruchomić nslookup polecenie w usłudze Azure Cloud Shell przy użyciu programu Azure PowerShell lub powłoki Bash. Zastąp nazwę serwera parametru <server_name> w poniższym przykładzie:

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

Korzystanie z projektu sieci prywatnej piasty i szprych

Piasta i szprycha to popularny model sieci umożliwiający efektywne zarządzanie typowymi wymaganiami dotyczącymi komunikacji lub zabezpieczeń.

Piasta to sieć wirtualna, która działa jako centralna lokalizacja do zarządzania łącznością zewnętrzną. Hostuje również usługi używane przez wiele obciążeń. Piasta koordynuje całą komunikację do i ze szprych. Reguły i procesy IT, takie jak zabezpieczenia, umożliwiają inspekcję i kierowanie ruchu oraz centralne zarządzanie ruchem. Szprychy to sieci wirtualne, które obsługują obciążenia i łączą się z centralną piastą za pomocą komunikacji równorzędnej sieci wirtualnej. Usługi udostępnione są hostowane we własnych podsieciach do udostępniania szprych. Podsieć obwodowa działa następnie jako urządzenie zabezpieczające.

Szprychy są również sieciami wirtualnymi na platformie Azure, które są używane do izolowania poszczególnych obciążeń. Przepływ ruchu między siedzibą lokalną a platformą Azure jest połączony za pośrednictwem usługi Azure ExpressRoute lub sieci VPN typu lokacja-lokacja połączonej z siecią wirtualną koncentratora. Sieci wirtualne ze szprych do piasty są równorzędne i umożliwiają komunikację z zasobami lokalnymi. Piastę i poszczególne szprychy można implementować w osobnych subskrypcjach lub grupach zasobów.

Istnieją trzy główne wzorce łączenia ze sobą sieci wirtualnych szprych:

  • Szprychy są bezpośrednio połączone ze sobą: komunikacja równorzędna sieci wirtualnych lub tunele VPN są tworzone między sieciami wirtualnymi szprych w celu zapewnienia bezpośredniej łączności bez przechodzenia przez sieć wirtualną piasty.
  • Szprychy komunikują się za pośrednictwem urządzenia sieciowego: każda sieć wirtualna szprychy ma komunikację równorzędną z wirtualną siecią WAN lub z siecią wirtualną piasty. Urządzenie kieruje ruch z szprychy do szprychy. Urządzenie może być zarządzane przez firmę Microsoft (podobnie jak w przypadku wirtualnej sieci WAN) lub przez Ciebie.
  • Brama sieci wirtualnej jest dołączona do sieci piasty i korzysta z tras zdefiniowanych przez użytkownika: umożliwia komunikację między szprychami.

Diagram przedstawiający podstawową architekturę piasty i szprych z łącznością hybrydową za pośrednictwem koncentratora ekspresowego.

Użyj usługi Azure Virtual Network Manager , aby utworzyć nowe (i dołączyć istniejące) topologie sieci wirtualnej piasty i szprych na potrzeby centralnego zarządzania łącznością i mechanizmami kontroli zabezpieczeń.

Komunikacja z klientami sieciowymi prywatnie w różnych regionach

Często klienci muszą łączyć się z różnymi regionami świadczenia usługi Azure klientów. Mówiąc dokładniej, to pytanie zwykle sprowadza się do sposobu łączenia dwóch sieci wirtualnych (z których jedna ma usługę Azure Database for PostgreSQL — serwer elastyczny, a drugi ma klienta aplikacji), które znajdują się w różnych regionach.

Istnieje wiele sposobów osiągnięcia takiej łączności, w tym:

  • Globalna komunikacja równorzędna sieci wirtualnych. Ta metodologia jest najbardziej powszechna, ponieważ jest to najprostszy sposób łączenia sieci w różnych regionach. Globalna komunikacja równorzędna sieci wirtualnych tworzy połączenie za pośrednictwem sieci szkieletowej platformy Azure bezpośrednio między dwiema równorzędną sieciami wirtualnymi. Ta metoda zapewnia najlepszą przepływność sieci i najmniejsze opóźnienia łączności. Gdy sieci wirtualne są równorzędne, platforma Azure obsługuje również routing automatycznie. Te sieci wirtualne mogą komunikować się ze wszystkimi zasobami w równorzędnej sieci wirtualnej, które są ustanawiane w bramie sieci VPN.
  • Połączenie sieciowe-sieć. Połączenie między sieciami wirtualnymi (połączenie między siecią i siecią) jest zasadniczo siecią VPN między dwiema lokalizacjami platformy Azure. Połączenie sieć-sieć jest ustanawiane w bramie sieci VPN. Ruch wiąże się z dwoma większymi przeskokami ruchu w porównaniu z globalną komunikacją równorzędną sieci wirtualnych. Istnieje również dodatkowe opóźnienie i niższa przepustowość w porównaniu z tą metodą.
  • Komunikacja za pośrednictwem urządzenia sieciowego w architekturze piasty i szprych. Zamiast łączyć sieci wirtualne szprychy bezpośrednio ze sobą, można użyć urządzeń sieciowych do przesyłania dalej ruchu między szprychami. Urządzenia sieciowe zapewniają więcej usług sieciowych, takich jak głęboka inspekcja pakietów i segmentacja ruchu lub monitorowanie, ale mogą one wprowadzać opóźnienia i wąskie gardła wydajności, jeśli nie są prawidłowo dopasowane.

Replikacja między regionami i sieciami wirtualnymi platformy Azure przy użyciu sieci prywatnej

Replikacja bazy danych to proces kopiowania danych z serwera centralnego lub podstawowego do wielu serwerów nazywanych replikami. Serwer podstawowy akceptuje operacje odczytu i zapisu, ale repliki obsługują transakcje tylko do odczytu. Serwer podstawowy i repliki tworzą zbiorczo klaster bazy danych. Celem replikacji bazy danych jest zapewnienie nadmiarowości, spójności, wysokiej dostępności i dostępności danych, szczególnie w aplikacjach o dużym natężeniu ruchu i krytycznym znaczeniu.

Usługa Azure Database for PostgreSQL — serwer elastyczny oferuje dwie metody replikacji: fizyczne (czyli przesyłanie strumieniowe) za pośrednictwem wbudowanej funkcji repliki do odczytu i replikacji logicznej. Oba są idealne w różnych przypadkach użycia, a użytkownik może wybrać jeden w zależności od celu końcowego.

Replikacja między regionami platformy Azure, z oddzielnymi sieciami wirtualnymi w każdym regionie, wymaga łączności między regionalnymi granicami sieci wirtualnych, które mogą być udostępniane za pośrednictwem komunikacji równorzędnej sieci wirtualnych lub architektur piasty i szprych za pośrednictwem urządzenia sieciowego.

Domyślnie rozpoznawanie nazw DNS jest ograniczone do sieci wirtualnej. Żaden klient w jednej sieci wirtualnej (VNET1) nie może rozpoznać nazwy FQDN serwera elastycznego usługi Azure Database for PostgreSQL w innej sieci wirtualnej (VNET2).

Aby rozwiązać ten problem, upewnij się, że klienci w sieci VNET1 mogą uzyskać dostęp do strefy usługi Azure Database for PostgreSQL — serwer elastyczny Prywatna strefa DNS. Dodaj link do sieci wirtualnej do strefy Prywatna strefa DNS serwera elastycznego usługi Azure Database for PostgreSQL.

Nieobsługiwane scenariusze sieci wirtualnej

Poniżej przedstawiono pewne ograniczenia dotyczące pracy z sieciami wirtualnymi utworzonymi za pośrednictwem integracji sieci wirtualnej:

  • Po wdrożeniu elastycznego serwera usługi Azure Database for PostgreSQL w sieci wirtualnej i podsieci nie można przenieść go do innej sieci wirtualnej ani podsieci. Nie można przenieść sieci wirtualnej do innej grupy zasobów lub subskrypcji.
  • Nie można zwiększyć rozmiaru podsieci (przestrzeni adresowych), gdy w podsieci istnieją zasoby.
  • Domyślnie wstrzyknięte zasoby sieci wirtualnej nie mogą korzystać z usługi Private Link. Jeśli chcesz używać usługi Private Link do sieci prywatnej, zobacz Azure Database for PostgreSQL — sieć serwera elastycznego z usługą Private Link.

Ważne

Usługa Azure Resource Manager obsługuje możliwość blokowania zasobów jako kontroli zabezpieczeń. Blokady zasobów są stosowane do zasobu i są skuteczne we wszystkich użytkownikach i rolach. Istnieją dwa typy blokady zasobów: CanNotDelete i ReadOnly. Te typy blokad można zastosować do strefy Prywatna strefa DNS lub do pojedynczego zestawu rekordów.

Zastosowanie blokady typu względem strefy Prywatna strefa DNS lub pojedynczego zestawu rekordów może zakłócać możliwość aktualizowania rekordów DNS przez usługę Azure Database for PostgreSQL — serwer elastyczny. Może to również powodować problemy podczas ważnych operacji w systemie DNS, takich jak tryb failover o wysokiej dostępności z podstawowej do pomocniczej. Z tych powodów upewnij się, że nie używasz strefy prywatnej ani blokad rekordów DNS w przypadku korzystania z funkcji wysokiej dostępności z usługą Azure Database for PostgreSQL — serwer elastyczny.

Nazwa hosta

Niezależnie od wybranej opcji sieciowej zalecamy, aby zawsze używać nazwy FQDN jako nazwy hosta podczas nawiązywania połączenia z serwerem elastycznym usługi Azure Database for PostgreSQL. Adres IP serwera nie ma gwarancji, że pozostanie statyczny. Użycie nazwy FQDN pomaga uniknąć wprowadzania zmian w parametry połączenia.

Przykładem użycia nazwy FQDN jako nazwy hosta jest hostname = servername.postgres.database.azure.com. Jeśli to możliwe, unikaj używania hostname = 10.0.0.4 (adresu prywatnego) lub hostname = 40.2.45.67 (adresu publicznego).

Powiązana zawartość