Článek přečtěte do 4 min.

Rozšíření konektivity napříč více regiony

Po ověření směrování tranzitu v rámci jednoho regionu (Phoenix) bylo dalším cílem propojit další region – Chicago – a zároveň zachovat Phoenix jako centrální uzel. Toto nastavení napodobuje to, co dnes dělá mnoho organizací: ukotvení cloudové sítě v primárním regionu a zároveň rozšíření pracovních zátěží a možností do dalších geografických oblastí.

Potřebujeme zajistit, aby provoz mezi simulovaným lokálním prostředím (hostovaným v Ashburnu), Phoenixu a Chicagu probíhal předvídatelně a bezpečně pomocí vzdálených peeringových připojení (RPC) od společnosti Oracle.

Směrování více regionů tranzitní dopravy

Simulace lokálního prostředí s VPN v Ashburnu

Abychom se vyhnuli narušení skutečné produkční sítě zákazníka, simulovali jsme lokální pracoviště v regionu OCI Ashburn pomocí VPN zařízení LibreSwan. To nám poskytlo plnou kontrolu nad logikou směrování a umožnilo nám kontrolovat a manipulovat s pakety v obou směrech.

Připojením VPN sítě LibreSwan k systému Phoenix přes tunel IPSec jsme efektivně emulovali lokální prostředí bez nepředvídatelnosti nebo závislosti na skutečných podnikových routerech nebo okruhách.

Toto nastavení se ukázalo být více než jen pouhým řešením – pomohlo navrhnout okrajové případy, jako jsou překrývání CIDR a trasy, které by jinak v abstraktnějších simulacích mohly zůstat bez povšimnutí.

IPSec VPN s LibreSwan

Vytvoření vzdáleného peeringového připojení (RPC)

Aby propojili Phoenix (hub) s Chicagem (spoke networking network), navázali vzdálené peeringové připojení (RPC) mezi jejich příslušnými DRG. Každý DRG měl svá vlastní připojení a směrovací tabulky DRG a RPC sloužil jako logický most mezi regiony.

Logika směrování vyžadovala pečlivou pozornost. Ve Phoenixu musela směrovací tabulka DRG pro RPC přílohu znát chicagské CIDR a naopak. Naštěstí nám v tomto pomohlo rozdělení importních tras od OCI – k šíření pouze nezbytných tras mezi přílohami jsme použili typy shody a priority.

Výkazy distribuce tras

Hlavní body trasy:

  • Tunel IPSec z Ashburnu končil na Phoenix DRG a trasy do CIDR Ashburnu byly importovány do směrovacích tabulek Phoenix DRG.
  • Směrovací tabulky Phoenix DRG poté šířily vybrané trasy do přílohy RPC, čímž efektivně rozšířily místní zobrazení do Chicaga.
  • Chicago DRG po obdržení tras prostřednictvím RPC zpřístupnilo tyto trasy svým připojeným VCN prostřednictvím přidružených směrovacích tabulek DRG.

Díky tomu mohly chicagské virtuální cloudové sítě (VCN) komunikovat se simulovanou místní sítí v Ashburnu, aniž by bylo nutné používat přímé tunely IPSec nebo překrývající se konfigurace tras.

Pravidla pro víceregionální směrování a tabulku tras

Ponaučení z víceregionálního designu

Jak rozšiřovali architekturu, začali jsi uvědomovat, jak vylepšený model DRG od OCI přináší přehlednost a kontrolu nad tím, co by jinak mohlo být spletí statických tras. To ale neznamená, že design je bez zvláštností.

Zde je několik praktických poznatků, které z toho vyplynuly:

  • Viditelnost tras je důležitá. Používejtetracerouteprotokolování na úrovni systému uvnitř VPN zařízení k ověření, které trasy se skutečně používají.
  • DRG a jeho podporované přílohy: Pochopte každý typ příloh na DRG pro definování směrovací tabulky pro každou přílohu a směrování provozu. (Viz obrázek: Přílohy DRG a směrovací tabulka)
  • Priority směrovací tabulky DRG jsou účinné. Použijte je k definování záložních cest a k zamezení konfliktů tras – zejména v případech, kdy je stejná CIDR dosažitelná prostřednictvím více příloh.
  • RPC neprovádějí NAT. Je třeba dbát na překrývající se adresní prostory a zajistit konzistentní plánování CIDR napříč regiony.

Dynamická směrovací brána a přílohy

Závěrečné myšlenky

Směrování tranzitu napříč regiony není jen o propojování teček na diagramu. Jde o navrhování s ohledem na provozní jednoduchost, kontrolu politik a škálovatelnost. Naštěstí nám nástroje pro směrování od OCI – přílohy DRG, směrovací tabulky, politiky importu/exportu a peering – poskytují flexibilitu k dosažení těchto výsledků, ale pochopení toho, jak a kdy je aplikovat, vyžaduje iteraci a experimentování.

Toto POC nám pomohlo ověřit, že model hub-and-spoke v kombinaci se směrováním založeným na DRG a vzdáleným peeringem poskytuje silný základ pro hybridní a víceregionální architektury.

Pro více informací o produktech Oracle, nás neváhejte kontaktovat.

Zdroj: Oracle