Sieć z dostępem prywatnym (integracja sieci wirtualnej) na serwerze elastycznym Azure Database for PostgreSQL

W tym artykule opisano pojęcia dotyczące łączności i sieci dla serwera elastycznego Azure Database for PostgreSQL.

Podczas tworzenia serwera elastycznego 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 Azure Database for PostgreSQL można wdrożyć w sieci wirtualnej Azure za pomocą iniekcji sieci wirtualnej. Sieci wirtualne platformy Azure zapewniają prywatną i bezpieczną komunikację sieci. Zasoby w sieci wirtualnej komunikują się za pośrednictwem prywatnych adresów IP przypisywanych w tej sieci.

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

  • Nawiąż połączenie z zasobów platformy Azure znajdujących się w tej samej sieci wirtualnej z elastycznym serwerem usługi Azure Database for PostgreSQL przy użyciu prywatnych adresów IP.
  • Użyj sieci VPN lub Azure ExpressRoute, aby nawiązać połączenie z zasobów innych niż Azure z serwerem elastycznym Azure Database for PostgreSQL.
  • Upewnij się, że serwer elastyczny 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 zawiera serwer elastyczny Azure Database for PostgreSQL.

Na powyższym diagramie:

  • Elastyczny serwer Azure Database for PostgreSQL jest wdrażany w podsieci 10.0.1.0/24 w sieci wirtualnej VNet-1.
  • Aplikacje wdrożone w różnych podsieciach w tej samej sieci wirtualnej mogą uzyskiwać bezpośredni dostęp do serwera elastycznego Azure Database for PostgreSQL.
  • Aplikacje wdrożone w innej sieci wirtualnej (VNet-2) nie mają bezpośredniego dostępu do serwera elastycznego Azure Database for PostgreSQL. Aby można było uzyskać dostęp do serwera elastycznego, należy najpierw skonfigurować komunikację równorzędną sieci wirtualnej dla prywatnej strefy DNS.

Pojęcia dotyczące sieci wirtualnej

Sieć wirtualna platformy Azure zawiera prywatną przestrzeń adresową IP, którą możesz skonfigurować do własnych potrzeb. Sieć wirtualna musi znajdować się w tym samym regionie Azure co serwer elastyczny Azure Database for PostgreSQL. Aby dowiedzieć się więcej o sieciach wirtualnych, zobacz Omówienie usługi Azure Virtual Network.

Zapoznaj się z tymi pojęciami podczas korzystania z sieci wirtualnych, w których zasoby są zintegrowane z siecią wirtualną w usłudze Azure Database for PostgreSQL — serwer elastyczny:

  • 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 Azure Database for PostgreSQL zintegrowany z siecią wirtualną musi znajdować się w delegowanej podsieci. Oznacza to, że tylko Azure Database for PostgreSQL serwer elastyczny może 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. Ta rezerwacja pozostawia 11 dostępnych adresów IP dla zakresu CIDR /28. Pojedynczy serwer Azure Database for PostgreSQL elastyczny z funkcjami wysokiej dostępności używa czterech adresów.

    W przypadku replikacji i połączeń firmy Microsoft Entra upewnij się, że tablice routingu nie wpływają na ruch. Typowym wzorcem jest kierowanie całego ruchu wychodzącego przez usługę Azure Firewall lub niestandardowe lokalne urządzenie filtrowania sieci.

    Jeśli podsieć ma tabelę tras skojarzoną z regułą, aby kierować cały ruch 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 takim samym jak zakres podsieci elastycznego serwera Azure Database for PostgreSQL oraz kolejnym przeskokiem Virtual Network.

    Ważne

    Nazwy AzureFirewallSubnet, AzureFirewallManagementSubnet, AzureBastionSubnet i 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.

  • Grupa zabezpieczeń sieciowych (NSG): Reguły w NSG umożliwiają filtrowanie rodzaju ruchu sieciowego, który może przepływać do i z podsieci sieci wirtualnych oraz interfejsów sieciowych. Aby uzyskać więcej informacji, zobacz Omówienie NSG (sieciowej grupy zabezpieczeń).

    Grupy zabezpieczeń aplikacji (ASG) ułatwiają kontrolowanie zabezpieczeń warstwy 4 przy użyciu sieciowych grup zabezpieczeń (NSG) dla sieci płaskich. Możesz szybko:

    • Przyłącz maszyny wirtualne do grupy 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 usługa Azure Database for PostgreSQL — elastyczny serwer nie obsługuje sieciowych grup zabezpieczeń (NSG), w których częścią reguły jest grupa ASG. Użyj filtrowania źródłowego lub docelowego opartego na adresie IP w NSG.

    Wysoka dostępność i inne funkcje serwera Azure Database for PostgreSQL wymagają możliwości wysyłania i odbierania ruchu do docelowego portu 5432 w podsieci sieci wirtualnej Azure, w której wdrożono serwer elastyczny Azure Database for PostgreSQL i do Azure Storage na potrzeby archiwizacji dzienników. Jeśli utworzysz sieciowe grupy zabezpieczeń, aby zablokować ruch do lub z serwera elastycznego Azure Database for PostgreSQL w podsieci, w której jest on wdrożony, upewnij się, że zezwalasz na ruch do portu docelowego 5432 w obrębie podsieci, a także do usługi Storage, używając 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 Microsoft Entra do logowania do serwera elastycznego Azure Database for PostgreSQL, zezwól na ruch wychodzący do Microsoft Entra ID za pomocą tagu usługi Microsoft Entra service tag.

    Punkt końcowy usługi Microsoft.Storage jest automatycznie konfigurowany w podsieci delegowanej po aprowizacji pierwszego serwera w tej podsieci. Ta konfiguracja zapewnia niezawodny routing ruchu do kont Azure Storage używanych do przesyłania plików dziennika Write-Ahead Log (WAL). Usunięcie tego punktu końcowego może zakłócać łączność i może prowadzić do niezamierzonych konsekwencji dla operacji podstawowych usług.

    Podczas konfigurowania replik do odczytu między regionami platformy Azure serwer elastyczny Azure Database for PostgreSQL musi mieć możliwość wysyłania i odbierania ruchu na porcie docelowym 5432 zarówno dla serwera podstawowego, jak i repliki, a także do Azure Storage w regionach serwera podstawowego i repliki, zarówno z serwera podstawowego, jak i z serwera repliki. 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żyj prywatnej strefy DNS

Prywatna usługa DNS platformy Azure 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 należy podać informacje o prywatnej strefie DNS, aby włączyć rozpoznawanie nazw DNS. W przypadku nowego serwera elastycznego Azure Database for PostgreSQL utworzonego przy użyciu dostępu do sieci prywatnej należy użyć stref Prywatna strefa DNS podczas konfigurowania serwera elastycznego Azure Database for PostgreSQL z dostępem prywatnym.

Ważne

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

W przypadku nowego serwera elastycznego Azure Database for PostgreSQL utworzonego przy użyciu prywatnego dostępu do sieci za pomocą interfejsu API, szablonu Azure Resource Manager (szablonu ARM), narzędzia Bicep lub Terraform utwórz prywatne strefy DNS. Następnie należy ich używać podczas konfigurowania serwera elastycznego 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 portalu Azure lub Azure CLI do tworzenia serwera elastycznego 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, lub domyślną Prywatna strefa DNS strefa jest tworzona automatycznie w ramach subskrypcji.

Jeśli używasz interfejsu API platformy Azure, szablonu usługi ARM, aplikacji Bicep lub narzędzia Terraform, utwórz prywatne strefy DNS, które kończą się na ..postgres.database.azure.com Użyj tych stref podczas konfigurowania serwera elastycznego 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 Azure Database for PostgreSQL lub podczas aprowizacji zostanie wyświetlony komunikat o błędzie. Aby uzyskać więcej informacji, zobacz omówienie prywatnych stref DNS.

Korzystając z portalu Azure, interfejsów API, interfejsu wiersza polecenia platformy Azure (Azure CLI) lub szablonu ARM, można również zmienić prywatną strefę DNS z tej wskazanej podczas tworzenia serwera Azure Database for PostgreSQL Flexible Server na inną prywatną strefę DNS istniejącą w 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 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 sprawdzamy już obecności połączenia z siecią wirtualną podczas tworzenia serwera Azure Database for PostgreSQL Flexible Server z prywatną siecią. Podczas tworzenia serwera za pośrednictwem portalu udostępniamy klientowi możliwość stworzenia linku do serwera za pomocą pola wyboru Połącz prywatną strefę DNS z Twoją siecią wirtualną w portalu Azure.

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. Usługa Azure Prywatna strefa DNS to podstawowa usługa strefy dostępności z nadmiarowością strefową. 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, należy użyć usługi przesyłania dalej DNS, aby rozpoznać nazwę FQDN serwera elastycznego Azure Database for PostgreSQL. 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 uzyskać więcej informacji, zobacz Rozpoznawanie nazw, które korzysta z własnego serwera DNS.

Ważne

Zaplanowane uaktualnienia konserwacji automatycznie odświeżają Twoje niestandardowe ustawienia serwera DNS. Aby rozpoznać i zastosować zaktualizowane niestandardowe ustawienia DNS przed następnym zaplanowanym uaktualnieniem, firma Microsoft musi wykonać odświeżanie wewnętrznie, ponieważ ta funkcja nie jest uwidoczniona za pośrednictwem interfejsów API lub kontrolek dostępnych dla klientów. Jeśli chcesz, aby zmiany zaczęły obowiązywać wcześniej, skontaktuj się z pomocą techniczną firmy Microsoft.

Prywatna strefa DNS i peering sieci wirtualnych

Ustawienia prywatnej strefy DNS i peering sieci wirtualnych są niezależne od siebie. Jeśli chcesz połączyć się z elastycznym serwerem Azure Database for PostgreSQL z klienta aprowizowanego w innej sieci wirtualnej w tym samym regionie lub w innym regionie, musisz połączyć prywatną strefę DNS z siecią wirtualną. Aby uzyskać więcej informacji, zobacz Łączenie sieci wirtualnej.

Uwaga / Notatka

Można połączyć tylko nazwy prywatnych stref DNS, które kończą się ciągiem postgres.database.azure.com. Nazwa strefy DNS nie może być taka sama jak nazwa serwera elastycznego Azure Database for PostgreSQL. W przeciwnym razie rozpoznawanie nazw kończy się niepowodzeniem.

Aby zamapować nazwę serwera na rekord DNS, uruchom polecenie nslookup w usłudze Azure Cloud Shell, korzystając z Azure PowerShell lub Bash. Zastąp nazwę swojego serwera dla parametru <server_name> w poniższym przykładzie:

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

Zastosowanie układu gwiaździstego w projektowaniu sieci prywatnej

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

Koncentrator 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 różne zadania. Koncentrator koordynuje całą komunikację do i od ramion. 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 z odgałęzieniami. Podsieć obwodowa działa następnie jako urządzenie zabezpieczające.

Użyj szprych, aby odizolować poszczególne obciążenia. Połącz siedzibę lokalną i Azure za pośrednictwem usługi ExpressRoute lub sieci VPN typu lokacja-lokacja połączonej z siecią wirtualną koncentratora. Skonfiguruj komunikację równorzędną sieci wirtualnych z sieci satelitarnych do sieci centralnej i umożliw komunikację z zasobami lokalnymi. Wdróż hub i każdy spoke w oddzielnych subskrypcjach lub grupach zasobów.

Istnieją trzy główne wzorce łączenia ze sobą sieci wirtualnych typu 'spoke':

  • Sieci typu spoke są bezpośrednio połączone ze sobą: utwórz komunikację równorzędną między sieciami wirtualnymi lub tunele VPN między sieciami wirtualnymi typu spoke, aby zapewnić bezpośrednią łączność bez kierowania ruchu przez centralną sieć wirtualną.
  • Wirtualne sieci "spokes" komunikują się za pomocą urządzenia sieciowego: każda wirtualna sieć typu "spoke" ma peering z wirtualną siecią WAN lub z wirtualnym hubem sieciowym. 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 centralnej i korzysta z tras zdefiniowanych przez użytkownika: umożliwia komunikację między odgałęzieniami.

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 wirtualnych w układzie gwiazdy i szprych do centralnego zarządzania łącznością i mechanizmami kontroli zabezpieczeń.

Komunikacja z klientami w prywatnych sieciach w różnych regionach

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

Taką łączność można osiągnąć na wiele sposobów, w tym:

  • Globalne łączenie peeringowe sieci wirtualnych. Ta metodologia jest najbardziej powszechna, ponieważ jest to najprostszy sposób łączenia sieci w różnych regionach. Globalne łączenie równorzędne sieci wirtualnych tworzy bezpośrednie połączenie za pośrednictwem szkieletu Azure między dwiema równorzędnymi sieciami wirtualnymi. Ta metoda zapewnia najlepszą przepływność sieci i najmniejsze opóźnienia łączności. Podczas łączenia sieci wirtualnych, Azure automatycznie zarządza routingiem za Ciebie. Te sieci wirtualne mogą komunikować się ze wszystkimi zasobami w równorzędnej sieci wirtualnej, które są zestawiane za pomocą bramy 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. Należy ustanowić połączenie typu sieć-sieć w bramie sieci VPN. Ruch wiąże się z dwoma dodatkowymi przeskokami w porównaniu z globalnym równorzędnym połączeniem 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. Aplikacje sieciowe zapewniają więcej usług sieciowych, takich jak głęboka inspekcja pakietów, segmentacja ruchu i 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 oferuje dwie metody replikacji: fizyczne (czyli przesyłanie strumieniowe) za pośrednictwem wbudowanej funkcji repliki do odczytu i replikacji logicznej. Oba są idealne dla różnych przypadków użycia i można 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 przez peering sieci wirtualnych lub architektury typu piasta i szprychy 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 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 Prywatny DNS serwera elastycznego Azure Database for PostgreSQL. Dodaj link do sieci wirtualnej do strefy Prywatna strefa DNS serwera elastycznego 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 serwera elastycznego 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 zasoby istnieją w podsieci.
  • Domyślnie wstrzyknięte zasoby sieci wirtualnej nie mogą wchodzić w interakcje z usługą Private Link. Jeśli chcesz użyć usługi Private Link do sieci prywatnej, zobacz Azure Database for PostgreSQL networking with Private Link (Sieć usługi Azure Database for PostgreSQL z usługą Private Link).
  • Niestandardowe konfiguracje sieciowe kierujące cały ruch do usługi Microsoft Azure Storage za pośrednictwem wirtualnego urządzenia sieciowego (WUS) nie są obsługiwane. Na przykład użycie trasy typu catch-all (0.0.0.0/0 → NVA) w celu wymuszenia skierowania całego ruchu wychodzącego przez NVA może zakłócać niezbędną łączność z platformą. Może to spowodować nieoczekiwane błędy w operacjach krytycznych, w tym scenariusze wysokiej dostępności. Domyślnie usługa dodaje punkt końcowy usługi Micosoft.Storage, gdy pierwszy serwer jest aprowizowany w podsieci delegowanej, która zapewnia bezpieczną i bezpośrednią łączność z usługą Azure Storage za pośrednictwem sieci szkieletowej platformy Azure. Usunięcie tego punktu końcowego może prowadzić do niezamierzonych konsekwencji dla operacji podstawowych usług.

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 obowiązują dla wszystkich użytkowników i ról. Istnieją dwa typy blokady zasobów: CanNotDelete i ReadOnly. Te typy blokad można zastosować do prywatnej strefy DNS lub do pojedynczego zestawu rekordów.

Zastosowanie blokady dowolnego z tych typów dla strefy Prywatna strefa DNS lub pojedynczego zestawu rekordów może zakłócić zdolność serwera elastycznego usługi Azure Database for PostgreSQL do aktualizowania rekordów DNS. Może to również powodować problemy podczas ważnych operacji w systemie DNS, takich jak przełączenie awaryjne o wysokiej dostępności z serwera podstawowego na serwer pomocniczy. Z tych powodów upewnij się, że nie używasz strefy prywatnej lub blokad rekordów DNS w przypadku korzystania z funkcji wysokiej dostępności z serwerem elastycznym Azure Database for PostgreSQL.

Nazwa hosta

Niezależnie od wybranej opcji sieciowej, zawsze używaj w pełni kwalifikowanej nazwy domeny (FQDN) jako nazwy hosta podczas nawiązywania połączenia z serwerem elastycznym Azure Database for PostgreSQL. Adres IP serwera może ulec zmianie. Korzystając z nazwy FQDN, nie trzeba aktualizować ciągu znaków 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).

Treści powiązane

  • Last updated on