Topologie de retea hub si spite – Cloud Adoption Framework

• 10.05.2019
• 5 minute de citit

In acest articol

Hub and speak este un model de retea pentru gestionarea eficienta a cerintelor comune de comunicare sau securitate. De asemenea, ajuta la evitarea limitarilor de abonament Azure. Acest model abordeaza urmatoarele preocupari:

• Economii de costuri si eficienta de gestionare. Centralizarea serviciilor care pot fi partajate de mai multe sarcini de lucru, cum ar fi dispozitivele virtuale de retea (NVA) si serverele DNS, intr-o singura locatie permite IT sa minimizeze resursele redundante si efortul de gestionare.
• Depasirea limitelor abonamentului. Sarcinile de lucru mari bazate pe cloud ar putea necesita utilizarea mai multor resurse decat sunt permise intr-un singur abonament Azure. Peeringul retelelor virtuale de incarcare de lucru de la diferite abonamente la un hub central poate depasi aceste limite. Pentru mai multe informatii, consultati Limitele abonamentului Azure.
• Separarea preocuparilor. Puteti implementa sarcini de lucru individuale intre echipele IT centrale si echipele de sarcini de lucru.

Este posibil ca proprietatile cloud mai mici sa nu beneficieze de structura si capacitatile adaugate pe care le ofera acest model. Dar eforturile mai mari de adoptare a cloud-ului ar trebui sa ia in considerare implementarea unui hub si a unei arhitecturi de retea in retea, daca au oricare dintre preocuparile enumerate anterior.

Prezentare generala

Figura 1: Exemplu de topologie de retea hub si spita.

Asa cum se arata in diagrama, Azure accepta doua tipuri de design hub si spite. Accepta comunicarea, resursele partajate si politica de securitate centralizata (etichetata ca hub VNet in diagrama) sau un design bazat pe WAN virtual Azure (etichetat ca WAN virtual in diagrama) pentru ramura la ramura si ramura la scara larga comunicatii catre Azure.

Un hub este o zona centrala de retea care controleaza si inspecteaza traficul de intrare sau iesire intre zone: internet, local si spite. Topologia hub si vorbire ofera departamentului IT un mod eficient de a aplica politicile de securitate intr-o locatie centrala. De asemenea, reduce potentialul de configurare gresita si expunere.

Hubul contine adesea componentele comune de serviciu pe care le consuma spitele. Urmatoarele exemple sunt servicii centrale comune:

• Infrastructura Windows Server Active Directory, necesara pentru autentificarea utilizatorilor de terte parti care obtin acces din retele de incredere inainte de a obtine acces la incarcarile de lucru din spita. Include Serviciile de federatie Active Directory (AD FS) aferente.
• Un serviciu DNS pentru a rezolva denumirea volumului de lucru in spite, pentru a accesa resurse locale si pe internet daca DNS Azure nu este utilizat.
• O infrastructura cu cheie publica (PKI), pentru a implementa conectarea unica la sarcinile de lucru.
• Controlul fluxului de trafic TCP si UDP intre zonele de retea cu vorbe si internet.
• Controlul debitului intre spite si local.
• Daca este necesar, controlul fluxului intre un spitel si altul.

Puteti minimiza redundanta, simplifica gestionarea si reduce costurile globale utilizand infrastructura hub-ului partajat pentru a sprijini mai multe spite.

Rolul fiecarei vorbe poate fi de a gazdui diferite tipuri de sarcini de lucru. Spitele ofera, de asemenea, o abordare modulara pentru implementari repetabile ale acelorasi sarcini de lucru. Exemple includ dev / test, testarea acceptarii utilizatorilor, organizarea si productia.

Spitele pot, de asemenea, sa separe si sa activeze diferite grupuri din cadrul organizatiei dvs. Un exemplu sunt grupurile Azure DevOps. In interiorul unei spite, este posibil sa implementati o sarcina de lucru de baza sau sarcini de lucru complexe pe mai multe niveluri cu control al traficului intre niveluri.

Limite de abonament si hub-uri multiple

In Azure, fiecare componenta, indiferent de tip, este implementata intr-un abonament Azure. Izolarea componentelor Azure in diferite abonamente Azure poate satisface cerintele diferitelor linii de activitate, cum ar fi stabilirea nivelurilor diferentiate de acces si autorizare.

O singura implementare de hub si spita poate ajunge la un numar mare de spite. Dar, ca in cazul oricarui sistem IT, exista limite de platforma. Implementarea hub-ului este legata de un abonament Azure specific, care are restrictii si limite. Un exemplu este un numar maxim de interactiuni de retea virtuala. Pentru mai multe informatii, consultati Abonamentul Azure si limitele serviciilor.

In cazurile in care limitele ar putea fi o problema, puteti extinde arhitectura in continuare extinzand modelul dintr-un singur hub si vorbind cu un grup de hub-uri si spite. Puteti interconecta mai multe hub-uri intr-una sau mai multe regiuni Azure utilizand peeringul retelei virtuale, Azure ExpressRoute, Azure Virtual WAN sau un VPN de la un site la altul.

Figura 2: Un grup de butucuri si spite.

Introducerea mai multor hub-uri mareste costurile si costurile generale de gestionare ale sistemului. Acest lucru este justificat doar de scalabilitate, limite de sistem sau redundanta si replicare regionala pentru performanta utilizatorului sau recuperarea in caz de dezastru. In scenariile care necesita hub-uri multiple, toate hub-urile ar trebui sa se straduiasca sa ofere acelasi set de servicii pentru o usurinta operationala.

Interconectarea intre spite

Este posibil sa implementati sarcini de lucru complexe pe mai multe niveluri intr-o singura spita. Puteti implementa configuratii pe mai multe niveluri utilizand subretele (una pentru fiecare nivel) in aceeasi retea virtuala si utilizand grupuri de securitate a retelei pentru a filtra fluxurile.

Un arhitect ar putea dori sa implementeze o sarcina de lucru pe mai multe niveluri pe mai multe retele virtuale. Cu ajutorul peeringului de retea virtuala, spitele se pot conecta la alte spite din acelasi hub sau in hub-uri diferite.

Un exemplu tipic al acestui scenariu este cazul in care serverele de procesare a aplicatiilor se afla intr-o retea cu un spit sau virtual. Baza de date se desfasoara intr-o retea diferita sau virtuala. In acest caz, este usor sa interconectati spitele cu peeringul retelei virtuale si sa evitati tranzitul prin hub. Solutia este sa efectuati o analiza atenta a arhitecturii si securitatii pentru a va asigura ca ocolirea hub-ului nu ocoleste punctele importante de securitate sau de audit care ar putea exista doar in hub.

Figura 3: Spite care se conecteaza intre ele si un hub.

Spitele pot fi, de asemenea, interconectate cu un spita care actioneaza ca un hub. Aceasta abordare creeaza o ierarhie pe doua niveluri: spita din nivelul superior (nivelul 0) devine centrul spitelor inferioare (nivelul 1) al ierarhiei. Spitele unui hub si a unei implementari de spite sunt necesare pentru a redirectiona traficul catre hub-ul central, astfel incat traficul sa poata tranzita la destinatia sa fie in reteaua locala, fie in internetul public. O arhitectura cu doua niveluri de hub-uri introduce o rutare complexa care elimina beneficiile unei relatii simple de hub si vorbire.