Hvězdicová síťová topologie

Hvězdicová architektura je síťový model pro efektivní správu běžných požadavků na komunikaci nebo zabezpečení. Pomáhá také vyhnout se omezením předplatného Azure. Tento model řeší následující aspekty:

• Úspora nákladů a efektivní správa: Centralizované služby, které je možné sdílet několika úlohami, jako jsou síťová virtuální zařízení (NVA) a servery DNS. S jedním umístěním pro služby může IT minimalizovat redundantní prostředky a úsilí správy.

• Omezení předplatných: Velké cloudové úlohy můžou vyžadovat použití více prostředků než jedno předplatné Azure. Peering úloh virtuálních sítí z různých předplatných do centra může tyto limity překonat. Další informace najdete v tématu Omezení předplatného Azure.

• Vytvoření oddělení obav: Jednotlivé úlohy můžete nasadit mezi centrálními IT týmy a týmy úloh.

Menší cloudové aktiva nemusí využívat výhody plynoucí z přidané struktury a možností, které tento model nabízí. Pokud však plánujete rozsáhlejší přechod na cloud, měli byste zvážit implementaci hvězdicové síťové architektury, pokud se vás týkají některé z výše uvedených aspektů.

Přehled

Obrázek 1: Příklad hvězdicové síťové topologie

Jak je znázorněno v diagramu, Azure podporuje dva typy návrhu hvězdicové topologie. První typ podporuje komunikaci, sdílené prostředky a centralizované zásady zabezpečení. Tento typ je v diagramu označený jako centrum virtuální sítě. Druhý typ je založený na službě Azure Virtual WAN, která je v diagramu označená jako Virtual WAN . Tento typ je určený pro komunikaci mezi velkými větvemi a větevmi do Azure.

Centrum je centrální zóna sítě, která řídí a kontroluje příchozí nebo výchozí provoz mezi zónami: internet, místní síť a paprsky. Hvězdicová topologie poskytuje oddělení IT efektivní způsob, jak vynucovat zásady zabezpečení v centrálním umístění. Také snižuje riziko neoprávněné konfigurace a vystavení hrozbám.

Centrum často obsahuje společné komponenty služby, které využívají paprsky. Mezi běžné centrální služby patří:

• Služba DNS překládá pojmenování úlohy v paprskech pro přístup k prostředkům místně a na internetu, pokud se nepoužívá Azure DNS .
• Infrastruktura veřejného klíče implementuje jednotné přihlašování pro úlohy.
• Tok provozu TCP a UDP se řídí mezi paprskovými síťovými zónami a internetem.
• Tok se řídí mezi paprsky a místním prostředím.
• Tok je v případě potřeby řízen mezi jedním paprskem a druhým.

Pomocí infrastruktury sdíleného centra, které podporuje více paprsků, můžete minimalizovat redundanci, zjednodušit správu a snížit celkové náklady.

Role jednotlivých paprsků může být hostitelem různých typů úloh. Paprsky také poskytují modulární přístup pro opakovaná nasazení stejných úloh. Mezi příklady patří vývoj/testování, testování přijetí uživatelů, příprava a produkce.

Paprsky můžou také oddělit a povolit různé skupiny v rámci vaší organizace. Příkladem jsou skupiny Azure DevOps. V rámci paprsku je možné nasadit základní úlohy nebo složité vícevrstvé úlohu s řízením provozu mezi vrstvami.

Služba Application Gateway zobrazená v diagramu výše může žít v paprsku s aplikací, která slouží k lepší správě a škálování. Firemní zásady ale můžou diktovat umístění služby Application Gateway do centra pro centralizovanou správu a oddělení povinností.

Omezení předplatného a více center

V Azure se každý typ komponenty nasadí v předplatném Azure. Izolace komponent Azure v různých předplatných Azure může uspokojit požadavky různých oborů podnikání, jako je například nastavení odlišných úrovní přístupu a autorizace.

Jedna hvězdicová implementace se může škálovat až na velký počet paprsků, ale stejně jako u každého IT systému existují limity platformy. Nasazení centra je vázáno na konkrétní předplatné Azure, pro které platí omezení a limity. Jedním z příkladů je maximální počet partnerských vztahů virtuálních sítí. Další informace najdete v tématu Omezení předplatného a služeb Azure.

Pokud může být problém s limity, můžete vertikálně navýšit kapacitu architektury rozšířením modelu do clusteru center a paprsků. K připojení více center v jedné nebo více oblastech Azure můžete použít:

• Peering virtuálních sítí
• Azure ExpressRoute
• Azure Virtual WAN
• Site-to-site VPN

Obrázek 2: Cluster rozbočovačů a paprsků

Zavedení více center zvyšuje náklady a nároky na správu systému. Toto zvýšení je odůvodněno pouze:

• Škálovatelnost
• Omezení systému
• Redundance a regionální replikace pro výkon uživatele nebo zotavení po havárii

Ve scénářích, které vyžadují více center, by se všechna centra měla snažit nabídnout stejnou sadu služeb, aby bylo možné snadno pracovat.

Propojení mezi paprsky

Je možné implementovat komplexní vícevrstvé úlohy v jednom paprsku. Konfigurace s více vrstvami můžete implementovat použitím podsítí (jedna pro každou vrstvu) ve stejné virtuální síti a filtrováním toku pomocí skupin zabezpečení sítě.

Architekt může chtít nasadit vícevrstvé úlohy napříč několika virtuálními sítěmi. Pomocí peeringu virtuálních sítí se paprsky můžou připojit k ostatním paprskům ve stejném centru nebo v jiných centrech.

Typickým příkladem tohoto scénáře je případ, kdy se servery pro zpracování aplikací nacházejí v jednom paprsku nebo virtuální síti. Databáze se nasadí v jiném paprsku nebo virtuální síti. V takovém případě je snadné propojit paprsky pomocí peeringu virtuálních sítí a vyhnout se tak přenosu přes centrum. Pečlivě zkontrolujte architekturu a zabezpečení, abyste zajistili, že obcházení centra neobejde důležité body zabezpečení nebo auditování, které jsou pouze v centru.

Obrázek 3: Příklad paprsků, které se vzájemně propojují a rozbočovač

Paprsky je taky možné propojit s paprskem, který funguje jako centrum. Tento přístup vytvoří dvouúrovňovou hierarchii: paprsk na vyšší úrovni, úroveň 0, stane se centrem nižších paprsků nebo úrovní 1 hierarchie. Paprsky jsou potřeba k přesměrování provozu do centrálního centra. Tento požadavek je takový, aby provoz mohl přejíždět do cíle buď v místní síti, nebo ve veřejném internetu. Architektura se dvěma úrovněmi center přináší složité směrování, které odstraňuje výhody jednoduché hvězdicové topologie.

Další kroky

Teď, když jste prozkoumali osvědčené postupy pro sítě, se dozvíte, jak přistupovat k identitám a řízení přístupu.