Síť s privátním přístupem (integrace virtuální sítě) pro Azure Database for PostgreSQL

Tento článek popisuje koncepty připojení a sítě pro instance flexibilních serverů Azure Database for PostgreSQL.

Při vytváření instance flexibilního serveru Azure Database for PostgreSQL musíte zvolit jednu z následujících možností sítě:

  • Privátní přístup (integrace virtuální sítě)
  • Veřejný přístup (povolené IP adresy) a privátní koncový bod

Tento dokument popisuje možnost privátního přístupu (integrace virtuální sítě).

Privátní přístup (integrace virtuální sítě)

Instanci flexibilního serveru Azure Database for PostgreSQL můžete nasadit do virtuální sítě Azure pomocí injektáže virtuální sítě. Virtuální sítě Azure poskytují privátní a zabezpečenou síťovou komunikaci. Prostředky ve virtuální síti komunikují prostřednictvím privátních IP adres, které v této síti přiřadíte.

Tuto možnost sítě zvolte, pokud chcete mít následující možnosti:

  • Připojte se z prostředků Azure ve stejné virtuální síti k instanci flexibilního serveru Azure Database for PostgreSQL pomocí privátních IP adres.
  • Pomocí sítě VPN nebo Azure ExpressRoute se připojte z prostředků mimo Azure k instanci flexibilního serveru Azure Database for PostgreSQL.
  • Ujistěte se, že instance flexibilního serveru Azure Database for PostgreSQL nemá žádný veřejný koncový bod, který je přístupný přes internet.

Diagram znázorňující, jak funguje partnerský vztah mezi virtuálními sítěmi, z nichž jedna zahrnuje instanci flexibilního serveru Azure Database for PostgreSQL

V předchozím diagramu:

  • Instance flexibilního serveru Azure Database for PostgreSQL se vloží do podsítě 10.0.1.0/24 virtuální sítě VNet-1.
  • Aplikace nasazené v různých podsítích ve stejné virtuální síti mají přímý přístup k instancím flexibilního serveru Azure Database for PostgreSQL.
  • Aplikace nasazené v jiné virtuální síti (VNet-2) nemají přímý přístup k instancím flexibilního serveru Azure Database for PostgreSQL. Než budou mít přístup k instanci flexibilního serveru, musíte pro zónu privátního DNS provést spárování virtuální sítě.

Koncepty virtuální sítě

Virtuální síť Azure obsahuje privátní adresní prostor IP adres, který nakonfigurujete pro použití. Vaše virtuální síť musí být ve stejné oblasti Azure jako instance flexibilního serveru Azure Database for PostgreSQL. Další informace o virtuálních sítích najdete v přehledu služby Azure Virtual Network.

Seznamte se s těmito koncepty při používání virtuálních sítí, ve kterých jsou prostředky integrované do virtuální sítě s instancemi flexibilního serveru Azure Database for PostgreSQL:

  • Delegovaná podsíť: Virtuální síť obsahuje podsítě (podsítě). Podsítě umožňují segmentovat virtuální síť do menších adresních prostorů. Prostředky Azure nasadíte do konkrétních podsítí v rámci virtuální sítě.

    Instance flexibilního serveru Azure Database for PostgreSQL, která je integrovaná ve virtuální síti, musí být v delegovaném podsíti. To znamená, že tuto podsíť můžou používat pouze instance flexibilního serveru Azure Database for PostgreSQL. V delegované podsíti nemůžou být žádné jiné typy prostředků Azure. Delegujete podsíť přiřazením jeho vlastnosti delegování jako Microsoft.DBforPostgreSQL/flexibleServers.

    Nejmenší rozsah CIDR, který můžete zadat pro podsíť, je /28, který poskytuje 16 IP adres. První a poslední adresa v žádné síti nebo podsíti se nedá přiřadit k žádnému jednotlivému hostiteli. Azure si pro interní použití sítí Azure vyhrazuje pět IP adres, které zahrnují dvě IP adresy, které není možné přiřadit k hostiteli, jak je uvedeno. Máte k dispozici 11 dostupných IP adres pro rozsah CIDR /28 díky této rezervaci. Jedna instance flexibilního serveru Azure Database for PostgreSQL s funkcemi vysoké dostupnosti používá čtyři adresy.

    Ujistěte se, že směrovací tabulky nemají vliv na provoz při replikaci a připojení Microsoft Entra. Běžným vzorem je směrování veškerého odchozího provozu přes Azure Firewall nebo vlastní místní zařízení pro filtrování sítě.

    Pokud má podsíť přidruženou směrovací tabulku k pravidlu pro směrování veškerého provozu do virtuálního zařízení:

    • Přidejte pravidlo se značkou cílové služby AzureActiveDirectory a dalším bodem přeskoku Internet.
    • Přidejte pravidlo s cílovým rozsahem IP adres stejným jako rozsah podsítí instance flexibilního serveru Azure Database for PostgreSQL a dalším směrovacím uzlem Virtual Network.

    Důležité

    Názvy AzureFirewallSubnet, AzureFirewallManagementSubnetAzureBastionSubnet, a GatewaySubnet jsou vyhrazeny v rámci Azure. Jako název podsítě nepoužívejte žádný z těchto názvů. Kromě toho by virtuální sítě neměly mít překrývající se adresní prostor pro vytváření replik mezi oblastmi.

  • Skupina zabezpečení sítě (NSG): Pravidla zabezpečení v skupinách zabezpečení sítě umožňují filtrovat typ síťového provozu, který může proudit do podsítí a síťových rozhraní virtuální sítě a z těchto podsítí. Další informace najdete v přehledu NSG.

    Skupiny zabezpečení aplikací (ASG) usnadňují řízení zabezpečení na vrstvě 4 pomocí skupin zabezpečení sítě (NSG) pro rovinné sítě. Můžete rychle:

    • Připojte virtuální počítače k ASG nebo odeberte virtuální počítače z asG.
    • Dynamicky aplikujte pravidla na tyto virtuální počítače nebo odeberte pravidla z těchto virtuálních počítačů.

    Další informace najdete v přehledu asg.

    V tuto chvíli instance flexibilního serveru Azure Database for PostgreSQL nepodporují skupiny zabezpečení sítě, ve kterých je skupina asG součástí pravidla. Použijte filtrování zdroje nebo cíle založené na IP ve skupině zabezpečení sítě.

    Vysoká dostupnost a další funkce serveru Azure Database for PostgreSQL vyžadují možnost odesílat a přijímat provoz na cílový port 5432 v podsíti virtuální sítě Azure, kde je nasazená instance flexibilního serveru Azure Database for PostgreSQL a do Azure Storage pro archivaci protokolů. Pokud vytvoříte NSGs pro odepření toku provozu do nebo z instance flexibilního serveru Azure Database for PostgreSQL v podsíti, ve které je nasazená, nezapomeňte povolit provoz na port 5432 jako cíl v rámci podsítě a také do úložiště pomocí služby značky Storage jako cíle.

    Toto pravidlo výjimky můžete dále filtrovat přidáním oblasti Azure do popisku, jako je us-east.storage. Pokud se rozhodnete použít ověřování Microsoft Entra pro autentizaci přihlášení k instanci flexibilního serveru Azure Database for PostgreSQL, povolte odchozí provoz do Microsoft Entra ID pomocí značky služby Microsoft Entra.

    Koncový bod služby Microsoft.Storage se automaticky nakonfiguruje v delegované podsíti při zřízení prvního serveru v této podsíti. Tato konfigurace zajišťuje spolehlivé směrování provozu do Azure úložišť, které se používají k nahrávání souborů protokolu Write-Ahead (WAL). Odebrání tohoto koncového bodu může narušit připojení a vést k nezamýšleným důsledkům pro základní operace služby.

    Když nastavíte repliky pro čtení v různých oblastech Azure, vyžaduje instance flexibilního serveru Azure Database for PostgreSQL možnost odesílat nebo přijímat provoz na cílový port 5432 pro primární i replikační server a k úložišti Azure Storage v primární a replikační oblasti z obou těchto serverů. Požadovaný cílový port TCP pro úložiště je 443.

  • Integrace zóny Azure Privátní DNS: Integrace zóny Azure Privátní DNS umožňuje přeložit privátní DNS v rámci aktuální virtuální sítě nebo jakékoli virtuální sítě spojené v rámci oblasti, kde je zóna Privátní DNS propojená.

Použití privátní DNS zóny

Privátní DNS Azure poskytuje spolehlivou a zabezpečenou službu DNS pro vaši virtuální síť. Azure Privátní DNS spravuje a překládá názvy domén ve virtuální síti bez nutnosti konfigurace vlastního řešení DNS.

Pokud používáte přístup k privátní síti s virtuální sítí Azure, musíte zadat informace zóny privátního DNS, aby bylo možné povolit rozlišení DNS. Pro nové instance flexibilního serveru Azure Database for PostgreSQL vytvořené pomocí privátního síťového přístupu je potřeba použít privátní zóny DNS při konfiguraci instancí flexibilních serverů Azure Database for PostgreSQL s privátním přístupem.

Důležité

Pokud používáte privátní zónu DNS v jiném předplatném, musí mít zaregistrovaného i poskytovatele prostředků Microsoft.DBforPostgreSQL. Jinak se vaše nasazení instance flexibilního serveru Azure Database for PostgreSQL nedokončí.

Pro nové instance flexibilního serveru Azure Database for PostgreSQL vytvořené pomocí privátního síťového přístupu pomocí rozhraní API, šablony Azure Resource Manageru (šablony ARM), Bicep nebo Terraformu vytvořte privátní zóny DNS. Pak je použijte při konfiguraci instancí flexibilního serveru Azure Database for PostgreSQL s privátním přístupem. Další informace najdete v tématu Specifikace rozhraní REST API pro Azure.

Pokud k vytváření instancí flexibilních serverů Azure Database for PostgreSQL používáte Azure Portal nebo Azure CLI , můžete zadat název privátní zóny DNS, který jste předtím vytvořili ve stejném nebo jiném předplatném, nebo se ve vašem předplatném automaticky vytvoří výchozí zóna privátního DNS.

Pokud používáte rozhraní Azure API, šablonu ARM, Bicep nebo Terraform, vytvořte privátní zóny DNS, které končí .postgres.database.azure.com. Tyto zóny použijte při konfiguraci instancí flexibilního serveru Azure Database for PostgreSQL s privátním přístupem. Například použijte formulář [name1].[name2].postgres.database.azure.com nebo [name].postgres.database.azure.com. Pokud se rozhodnete použít formulář [name].postgres.database.azure.com, název nemůže být název, který používáte pro jednu z instancí flexibilního serveru Azure Database for PostgreSQL, nebo se během zřizování zobrazí chybová zpráva. Další informace najdete v tématu Přehled privátních DNS zón.

Pokud používáte Azure Portal, rozhraní API, Azure CLI nebo šablonu ARM, můžete také změnit zónu privátního DNS z zóny, kterou jste zadali při vytváření instance flexibilního serveru Azure Database for PostgreSQL, na jinou zónu privátního DNS, která existuje ve stejném nebo jiném předplatném.

Důležité

Možnost změnit zónu privátního DNS z zóny, kterou jste zadali při vytváření instance flexibilního serveru Azure Database for PostgreSQL na jinou zónu privátního DNS, je aktuálně zakázaná pro servery s povolenou funkcí vysoké dostupnosti.

Po vytvoření Privátní DNS zóny v Azure je potřeba s ní propojit virtuální síť. Prostředky hostované v propojené virtuální síti pak můžou přistupovat k Privátní DNS zóně.

Důležité

Přestaneme ověřovat přítomnost propojení virtuální sítě při vytváření serveru pro instance flexibilního serveru Azure Database for PostgreSQL s privátními sítěmi. Když vytvoříte server prostřednictvím portálu, poskytneme zákazníkovi možnost vytvořit odkaz na vytvoření serveru pomocí zaškrtávacího políčka Propojit Privátní DNS zónu s virtuální sítí na webu Azure Portal.

Privátní zóny DNS jsou odolné vůči oblastním výpadkům, protože data zón jsou globálně dostupná. Záznamy prostředků v privátní zóně se automaticky replikují napříč regiony. Azure Privátní DNS je základní zónově redundantní služba dostupnosti. Další informace najdete v tématu Služby Azure s podporou zóny dostupnosti.

Integrace s vlastním serverem DNS

Pokud používáte vlastní server DNS, musíte k překladu plně kvalifikovaného názvu domény instance flexibilního serveru Azure Database for PostgreSQL použít nástroj pro předávání DNS. IP adresa služby předávání by měla být 168.63.129.16.

Vlastní server DNS by měl být uvnitř virtuální sítě nebo dostupný prostřednictvím nastavení serveru DNS virtuální sítě. Další informace najdete v tématu Překlad názvů, který využívá váš vlastní server DNS.

Důležité

Upgrady plánované údržby automaticky aktualizují vaše vlastní nastavení serveru DNS. Pokud chcete rozpoznat a použít aktualizovaná vlastní nastavení DNS před dalším plánovaným upgradem, microsoft musí aktualizaci provést interně, protože tato funkce není vystavená prostřednictvím rozhraní API nebo ovládacích prvků, která jsou určená pro zákazníky. Pokud potřebujete, aby se změna projevila dříve, obraťte se na podporu Microsoftu.

Privátní DNS zóna a propojení virtuálních sítí

Nastavení privátní DNS zóny a propojení virtuálních sítí jsou navzájem nezávislé. Pokud se chcete připojit k instanci flexibilního serveru Azure Database for PostgreSQL z klienta, který zřídíte v jiné virtuální síti ze stejné oblasti nebo jiné oblasti, musíte propojit zónu privátního DNS s virtuální sítí. Další informace najdete v tématu Propojení virtuální sítě.

Poznámka:

Můžete propojit pouze názvy privátních zón DNS, které končí .postgres.database.azure.com Název vaší zóny DNS nemůže být stejný jako vaše instance flexibilního serveru Azure Database for PostgreSQL. V opačném případě překlad názvů selže.

Pokud chcete namapovat název serveru na záznam DNS, spusťte nslookup příkaz v Azure Cloud Shellu pomocí Azure PowerShellu nebo bashe. Nahraďte název serveru parametrem <server_name> v následujícím příkladu:

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

Použití návrhu privátní sítě typu hub-and-spoke

Model hvězdy a paprsků je oblíbený síťový model pro efektivní správu běžných požadavků na komunikaci nebo zabezpečení.

Centrum je virtuální síť, která funguje jako centrální umístění pro správu externího připojení. Hostuje také služby používané více úlohami. Toto centrum koordinuje veškerou komunikaci směřující do a z paprsků. IT pravidla nebo procesy, jako je zabezpečení, můžou kontrolovat, směrovat a centrálně spravovat provoz. Paprsky jsou virtuální sítě, které hostují úlohy a připojují se k centrálnímu hubu prostřednictvím propojení virtuálních sítí. Sdílené služby jsou hostované ve vlastních podsítích pro sdílení se sítěmi spoke. Hraniční podsíť pak funguje jako bezpečnostní zařízení.

Paprsky jsou také virtuální sítě v Azure, které používáte k izolaci jednotlivých úloh. Tok provozu mezi místním ústředím a Azure je připojený přes Azure ExpressRoute nebo VPN typu site-to-site připojený k virtuální síti centra. Virtuální sítě z paprsků do centra jsou propojeny a umožňují komunikaci s lokálními prostředky. Centrum a jednotlivé paprsky můžete implementovat v samostatných předplatných nebo skupinách prostředků.

Existují tři hlavní vzory pro vzájemné propojení paprskových virtuálních sítí:

  • Paprsky jsou vzájemně propojené přímo: Vytvoříte peerování virtuálních sítí nebo VPN tunely mezi paprskovými virtuálními sítěmi, abyste zajistili přímé připojení, aniž byste museli procházet přes virtuální síť rozbočovače.
  • Spoky komunikují přes síťové zařízení: Každá spoková virtuální síť má peering k virtuální síti WAN nebo k virtuální síti rozbočovače. Zařízení směruje provoz od uzlu k uzlu. Zařízení může spravovat Microsoft (stejně jako virtuální síť WAN) nebo vy.
  • Brána virtuální sítě je připojená k centrální síti a využívá trasy definované uživatelem: Umožňuje komunikaci mezi paprsky.

Diagram znázorňující základní architekturu hub-and-spoke s hybridním připojením prostřednictvím express hubu.

Pomocí Azure Virtual Network Manageru můžete vytvořit nové hvězdicové topologie virtuální sítě (a připojit stávající) pro centrální správu připojení a kontrol zabezpečení.

Komunikace s privátními síťovými klienty v různých oblastech

Zákazníci se často potřebují připojovat k klientům v různých oblastech Azure. Konkrétně se tato otázka obvykle omezuje na to, jak připojit dvě virtuální sítě (jednu z nich má instanci flexibilního serveru Azure Database for PostgreSQL a druhou klient aplikace), která je v různých oblastech.

Takové připojení můžete dosáhnout několika způsoby, včetně:

  • Globální propojení virtuálních sítí Tato metodologie je nejběžnější, protože je nejjednodušší způsob, jak propojit sítě v různých oblastech dohromady. Propojení globálních virtuálních sítí vytvoří připojení přímo přes páteřní síť Azure mezi dvěma propojenými virtuálními sítěmi. Tato metoda poskytuje nejlepší propustnost sítě a nejnižší latenci připojení. Když vytvoříte partnerský vztah virtuálních sítí, Azure pro vás automaticky zajišťuje směrování. Tyto virtuální sítě můžou komunikovat se všemi prostředky v připojené virtuální síti, které jsou navázány na bráně VPN.
  • Připojení k síti. Připojení mezi virtuálními sítěmi (síťové propojení) je v podstatě VPN mezi dvěma umístěními Azure. Navážete připojení k síti na bráně VPN. V případě vašeho provozu jsou v porovnání s globálním partnerským propojením virtuálních sítí přidány dvě další skoky. V porovnání s danou metodou je také další latence a nižší šířka pásma.
  • Komunikace přes síťové zařízení v architektuře hvězdice a paprsku Místo přímého propojení paprskových virtuálních sítí můžete pomocí síťových zařízení směrovat provoz mezi paprsky. Síťová zařízení poskytují více síťových služeb, jako je hloubková kontrola paketů a segmentace provozu nebo monitorování, ale pokud nejsou správně dimenzována, můžou zavádět latenci a úzká místa výkonu.

Replikace napříč oblastmi Azure a virtuálními sítěmi s využitím privátních sítí

Replikace databáze je proces kopírování dat z centrálního nebo primárního serveru na více serverů označovaných jako repliky. Primární server přijímá operace čtení a zápisu, ale repliky obsluhují transakce jen pro čtení. Primární server a repliky společně tvoří databázový cluster. Cílem replikace databáze je zajistit redundanci, konzistenci, vysokou dostupnost a přístupnost dat, zejména u vysoce provozních a důležitých aplikací.

Azure Database for PostgreSQL nabízí dvě metody pro replikaci: fyzické (to znamená streamování) prostřednictvím integrované funkce repliky pro čtení a logické replikace. Oba jsou ideální pro různé případy použití a v závislosti na koncovém cíli si můžete vybrat jednu z nich.

Replikace mezi oblastmi Azure, s oddělenými virtuálními sítěmi v každé oblasti, vyžaduje připojení napříč hranicemi regionálních virtuálních sítí, které může zajistit spojení virtuálních sítí nebo architektura hub-and-spoke prostřednictvím síťového zařízení.

Ve výchozím nastavení je překlad názvů DNS omezen na virtuální síť. Žádný klient v jedné virtuální síti (VNET1) nemůže vyřešit FQDN instance flexibilního serveru Azure Database for PostgreSQL v jiné virtuální síti (VNET2).

Pokud chcete tento problém vyřešit, ujistěte se, že klienti ve virtuální síti 1 mají přístup k zóně privátního DNS instance flexibilního serveru Azure Database for PostgreSQL. Přidejte propojení virtuální sítě do zóny privátního DNS vaší instance flexibilního serveru Azure Database for PostgreSQL.

Nepodporované scénáře virtuálních sítí

Tady jsou některá omezení pro práci s virtuálními sítěmi vytvořenými prostřednictvím integrace virtuální sítě:

  • Po nasazení instance flexibilního serveru Azure Database for PostgreSQL do virtuální sítě a podsítě ji nemůžete přesunout do jiné virtuální sítě nebo podsítě. Virtuální síť nemůžete přesunout do jiné skupiny prostředků ani předplatného.
  • Jakmile existují prostředky v podsíti, nemůžete zvětšit velikost adresního prostoru podsítě.
  • Ve výchozím nastavení nemůžou prostředky vložené do virtuální sítě komunikovat se službou Private Link. Pokud chcete použít službu Private Link pro privátní sítě, přečtěte si téma Sítě Azure Database for PostgreSQL se službou Private Link.
  • Vlastní síťové konfigurace, které směrují veškerý provoz do Služby Microsoft Azure Storage prostřednictvím virtuálního síťového zařízení (NVA), se nepodporují. Například použití trasy catch-all (0.0.0.0/0 → NVA) k zajištění, že veškerý odchozí provoz prochází přes NVA, může narušit požadované připojení platformy. To může vést k neočekávaným chybám v kritických operacích, včetně scénářů s vysokou dostupností. Ve výchozím nastavení služba přidá koncový bod služby Micosoft.Storage při zřízení prvního serveru v delegované podsíti, která poskytuje zabezpečené a přímé připojení ke službě Azure Storage přes páteřní síť Azure. Odebrání tohoto koncového bodu může vést k nezamýšleným důsledkům pro základní operace služby.

Důležité

Azure Resource Manager podporuje možnost uzamknout prostředky jako bezpečnostní prvek. Zámky prostředků se aplikují na prostředek a jsou platné pro všechny uživatele a role. Existují dva typy zámku prostředku: CanNotDelete a ReadOnly. Tyto typy zámků můžete použít buď pro privátní zónu DNS, nebo pro jednotlivou sadu záznamů.

Použití zámku jakéhokoli typu pro zónu privátního DNS nebo jednotlivé sady záznamů může interferovat se schopností instance flexibilního serveru Azure Database for PostgreSQL aktualizovat záznamy DNS. Může také způsobit problémy během důležitých operací na DNS, jako je převzetí služeb při selhání z hlavního na záložní server s vysokou dostupností. Z těchto důvodů se ujistěte, že nepoužíváte privátní zónu DNS nebo zámky záznamů, pokud používáte funkce s vysokou dostupností s instancí flexibilního serveru Azure Database for PostgreSQL.

Název hostitele

Bez ohledu na zvolenou možnost sítě vždy při připojování k instanci flexibilního serveru Azure Database for PostgreSQL používejte jako název hostitele plně kvalifikovaný název domény (FQDN). IP adresa serveru se může změnit. Pomocí FQDN nemusíte aktualizovat řetězec připojení.

Příkladem, který používá plně kvalifikovaný název domény jako název hostitele, je hostname = servername.postgres.database.azure.com. Pokud je to možné, nepoužívejte hostname = 10.0.0.4 (soukromou adresu) nebo hostname = 40.2.45.67 (veřejnou adresu).

Související obsah

  • Last updated on