Úspěšné nasazení cloudu často zahrnuje dobře navržené cloudové sítě, které dokáží splnit současný i budoucí růst složitosti. Propojení různých virtuálních cloudových sítí (VCN) a jejich rozšíření do místních datových center nebo datových center jiných poskytovatelů cloudu již není něco, co by bylo dobré mít, ale je to jeden ze základních požadavků. Využitím směrování tranzitu umožňuje Oracle Cloud Infrastructure (OCI) konektivitu VCN napříč regiony a místními úložišti zákazníků.
Příklad projektu POC pro více regionů OCI pro zákazníka, který vyžadoval směrování provozu mezi místním datovým centrem a úlohami nasazenými v regionech OCI Phoenix a Chicago.
Architektura musela podporovat:
- Konektivita VCN typu Hub-and-spoke v oblasti Phoenix.
- Směrování tranzitu z místních sítí do regionů OCI a VCN.
- Budoucí meziregionální provoz mezi regionem OCI Chicago přes Phoenix jako uzel.
Aby zjednodušili konfiguraci s minimálními změnami v místním datovém centru zákazníka, simulovali místní prostředí, nasadili VPN zařízení LibreSwan v regionu Ashburn a připojili ho k regionu Phoenix prostřednictvím služby IPSec site-to-site VPN. Proč to dělají? Zjistili, že simulace místního provozu pomocí skutečné VPN založené na Linuxu je flexibilnější než spoléhání se na nativní testovací nástroje, zejména pokud jde o validaci směrování. Eliminuje to další faktory, které nesouvisejí s POC, a udržuje konfiguraci přímočarou. Zároveň to pomáhá odhalit předpoklady ohledně šíření tras a návratových cest.
Začali jako typický návrh sítě OCI s využitím VCN a podsítí s výchozími směrovacími tabulkami. Rychle se ale proměnili v hlubší zkoumání směrovacích možností OCI, zejména v oblasti vylepšené dynamické směrovací brány (DRG). Tento příspěvek se věnuje praktickým poznatkům a architektonickým poznatkům, nejen tomu, co fungovalo, ale i tomu, proč by jedna cesta mohla být lepší než jiná.
O co jde při plánování trasy veřejné dopravy?
Směrování tranzitu umožňuje propojení napříč VCN nasazenými ve více regionech a s lokální sítí zákazníka prostřednictvím centrální VCN nasazené v topologii hub-and-spoke. Využíváme komponenty jako Local Peering Gateway (LPG), Dynamic Routing Gateway (DRG), směrovací tabulky, DRG a distribuce tras k propojení těchto cest. Toto je také něco, co byste měli mít na paměti při návrhu sítě směrování tranzitu, protože OCI vyvíjí svou síťovou architekturu, a to znamená, že existuje více způsobů, jak vyřešit stejný problém.
Dva přístupy
Aby umožnili tok provozu mezi simulovaným lokálním pracovištěm v oblasti Ashburn a úlohami ve Phoenixu, experimentovali se dvěma odlišnými modely směrování.
1. Klasické lokální peeringové připojení založené na LPG
Tento model využívá lokální peeringové brány OCI (LPG) k propojení VCN ve stejné oblasti. K DRG se připojuje pouze centrální VCN a paprskové VCN se do něj připojují přes LPG.
I když je tento přístup technicky v pořádku, vyžadoval poměrně dost práce:
- Explicitní nastavení LPG a směrování mezi jednotlivými VCN a směrovacími tabulkami.
- Směrovací tabulky DRG, které znají všechny paprskové CIDR a jak se k nim dostat prostřednictvím LPG.
- Pečlivé řízení šíření trasy mezi přípojkami DRG a LPG.
I když to fungovalo – ale působilo to trochu křehce. Každý nový paprsek vyžadoval ruční aktualizace v několika VCN a směrovacích tabulkách.
2. Vylepšený DRG s připojením VCN
Dne 17. května 2021 společnost OCI vydala aktualizovanou verzi Dynamic Routing Gateway, ke které lze připojit mnoho VCN v rámci stejného regionu. Provoz mezi lokálními VCN může procházet přes vzájemně propojený DRG namísto lokální peeringové brány. Díky této aktualizované verzi DRG lze eliminovat potřebu LPG. Konfigurace peeringu VCN ve stejném regionu je zjednodušena díky jedinému DRG a jeho VCN připojením.
Přiřazením vyhrazené přílohy DRG ke každé síti VCN a propojením s ní směrovací tabulky DRG můžete jasně definovat, jak by měl provoz mezi jednotlivými přílohami proudit. Ještě lepší je, že distribuce tras umožňuje přílohám dynamicky se o sobě učit – což snižuje potřebu statické konfigurace.
V důsledku toho:
- Nejsou potřeba žádné LPG.
- Žádné závislosti napříč zdroji mezi VCN.
- Lepší přehlednost a ovladatelnost s rostoucím škálováním prostředí.
Směrovací tabulka DRG a distribuce importních tras
Funkce směrování tranzitu se ve své podstatě spoléhá na DRG, aby se naučila trasy mezi VCN a externím připojením k lokalitám, tj. IPSec VPN. V tradičních lokálních prostředích by to mohlo být řešeno pomocí MPLS, BGP tras nebo softwarově definovaných WAN kontrolérů. V OCI však používáme import distribuce tras, která se připojuje k tabulce tras DRG v připojení tunelu IPSec VPN.
Distribuce tras se importují pomocí příkazu, který definuje, jakou akci provést pro zadaný typ shody s určitou prioritou.
- Priorita: Číslo mezi 1 a 65535 ve vzestupném pořadí, nižší čísla mají vyšší prioritu.
- Typ shody: Typ přílohy, Příloha nebo Shoda vše. Při použití Typu přílohy zahrnuje distribuce tras importu trasy ze všech příloh pro vybraný typ přílohy, kde Příloha vybírá konkrétní přílohu.
Tento přístup nejen splňoval funkční potřeby, ale také usnadnil rozšíření směrovacích politik v budoucnu, zejména s ohledem na propojení více regionů.
Věci, které je třeba mít na paměti
Pokud dnes pracujete v OCI a budujete cokoli, co se podobá multi-VCN nebo hybridní síti, je třeba mít na paměti několik věcí:
- Kdykoli je to možné, upřednostňujte nový model DRG – snižuje architektonickou složitost a lépe se škáluje.
- LPG považujte za záložní možnost – v některých kontextech stále platnou, ale pro větší konstrukce méně optimální.
- Testujte s realistickými toky provozu – zejména při simulaci lokálních tras používejte skutečné toky paketů (ICMP, TCP) k ověření chování mezi koncovými body.
Pro více in formací o produktech Oracle, nás neváhejte kontaktovat.
Zdroj: Oracle
