Topologie de rețea (centru de date)

De la Wikipedia, enciclopedia liberă.
Salt la navigare Salt la căutare

Topologia rețelei unui centru de date este tipul de interconectare între server și comutator și este aleasă în funcție de nevoile companiei sau ale afacerii. Topologia rețelei trebuie să fie scalabilă și eficientă în conectarea a zeci sau chiar sute de mii de servere pentru a satisface cererea tot mai mare de cloud computing .

Clasificare fixă ​​/ flexibilă a unei topologii

Clasificarea topologiei rețelei unui centru de date.

O posibilă clasificare pentru o topologie de rețea de centru de date distinge rețelele fixe de cele flexibile după ce este construită fizic. Arhitecturile sunt clasificate ca arhitecturi cu topologie fixă ​​sau arhitecturi cu topologie flexibilă [1] pe baza capacității de a modifica rețeaua odată ce aceasta este operațională. Arhitecturile de topologie fixe pot fi de tipul arborelui gras, cum ar fi arhitectura propusă de Al-Fares [2] sau arhitecturile PortLand [3] și Hedera [4] . Alte arhitecturi de topologie fixă ​​sunt rețelele Clos [5] și topologiile recursive precum DCell [6] și BCube [7] , MDCube [8] sau FiConn [9] . Arhitecturile cu o topologie flexibilă pot exista, de exemplu, de tipul c-Through [10] , Helios [11] și OSA [12] .

Rețelele flexibile de topologie se pot baza pe tehnologia optică [12] (arhitectura rețelei Proteus este un exemplu): acestea oferă o lățime de bandă mai mare decât cele bazate pe cabluri electrice și topologia lor poate fi modificată și în timpul funcționării centrului de date. Alte topologii flexibile utilizează o tehnologie hibridă, adică bazată atât pe un protocol de comutare electrică cât și optică de pachete [10] . Există, de asemenea, rețele flexibile de centre de date numite Meduze care adoptă topologia unui grafic aleatoriu [13] .

În majoritatea acestor arhitecturi, punctul de plecare este alegerea topologiei, astfel încât să se evite implementarea unui protocol de rutare ; de fapt, fiecare nod poate executa un algoritm specific pentru a determina portul de ieșire al unui pachet pe baza adresei de destinație. Un protocol de rutare multipath sau alte tehnici pot fi implementate pentru a îmbunătăți performanța rețelei [1] .

Topologii de copaci

Arborele de bază

topologie de bază a rețelei centrului de date al copacului

Topologia de bază a arborelui este o topologie de arbore constând din două sau trei niveluri de switch-uri / routere având serverele ca frunze (noduri terminale ale arborelui). Într-o topologie cu două niveluri, există un comutator de nivel de bază la rădăcina arborelui, conectat la un nivel de comutatoare de nivel de margine conectate la rândul lor la servere. Într-o topologie cu 3 niveluri, un comutator de nivel de agregare este interpus între nivelul de bază și nivelul de margine. Fiecare nivel al arborelui este conectat doar la nivelurile superioare și inferioare, prin urmare, comunicarea între nivelurile neadiacente este posibilă numai datorită nivelurilor intermediare. Deoarece switch-urile de nivel superior trebuie să asigure comunicarea între un număr mare de servere, trebuie să ofere performanțe și fiabilitate ridicate. Acest lucru creează probleme de scalabilitate care pot fi rezolvate folosind alte topologii de rețea.

Arborele gras

topologia rețelei pentru centrele de date ale arborelui de grăsime

Topologia rețelei arborelui gras a fost introdusă de Charles E. Leirson în 1985 [14] . Într-o topologie a rețelei de arbori de grăsime, ramurile (vârfurile) de lângă nivelul miezului sunt „mai groase”, adică permit o lățime de bandă mai mare decât arborele de bază prin utilizarea unui număr mai mare de comutatoare.

Topologia rețelei arborelui gras se bazează pe un arbore binar complet ale cărui noduri sunt comutatoare cu n porturi. Fiecare comutator de margine este conectat la server în timp ce restul porturile sunt conectate la altele comutați porturile aparținând nivelului de agregare. The porturile comutatoarelor de nivel de agregare, porturi de comutare la nivel de margine și resetări conectate la servere formează o celulă elementară a arborelui de grăsime numit pod. Fiecare păstăi are legături la nivelul de bază, adică căi pentru fiecare dintre comutator de margine pod. În nivelul de bază există comutator având porturi, fiecare conectat la fiecare dintre pod-urile care fac parte din rețea.

Topologii recursive

DCell

Topologie rețea centru de date DCell, n = 4

O topologie DCell este o topologie a rețelei centrelor de date propusă de Chuanxiong Guo în 2008 [6] . DCell este o structură definită recursiv în care un DCell de nivel înalt este construit din mai multe celule DC de nivel scăzut; fiecare dintre acestea este complet conectat cu celelalte. În arhitectura DCell, un server are mai multe controlere de interfață de rețea (NIC). De obicei, cea mai mare provocare într-o rețea de centru de date este cum să interconectați eficient un număr exponențial de servere. Din acest motiv, există trei obiective de proiectare [15] pentru rețeaua de centre de date:

  • Scalabilitate
  • Toleranță la erori
  • Capacitatea generală de transmitere a informațiilor

O structură DCell cu un grad redus de conexiune poate suporta câteva milioane de servere. Structura DCell este tolerantă la erori, deoarece nu are un singur punct de eșec, iar protocolul său de rutare efectuează cea mai scurtă rutare de cale chiar și în prezența unor eșecuri severe de nod sau legătură. DCell oferă o capacitate de rețea mai mare decât o structură tradițională de copac, deoarece traficul de rețea este distribuit uniform între servere și între legăturile de pe un server.

Structura fizică și construcția recursivă a unei rețele DCell

Cel mai elementar element al unui DCell se numește DCell . Un DCell compus de server și un switch n-port; fiecare server din DCell este conectat la comutator în același DCell . Un DCell de nivel înalt este construit din alte celule DC de nivel inferior. Să luăm în considerare un DCell aparținând celui de-al k-lea nivel al întregului DCell. Primul pas este construirea unui DCell începând de la alte DCell . Fiecare DCell are DCell și fiecare server din fiecare DCell în interiorul unui DCell este conectat la un alt server DCell . DCell sunt conectate la toate celelalte datorită unei conexiuni între fiecare pereche de DCell . Pentru a construi DCell putem aplica aceeași procedură folosind diferite celule DC s. Într-un DCell , fiecare server va avea conexiuni: prima conexiune sau nivelul-0 se conectează la un comutator care formează un DCell , iar nivelurile i sunt conectate la server în același DCell dar cu un DCelli diferit . Presupunând că fiecare DCell are servere, o vom duce la DCell va consta din DCell s și, în consecință servere. În cele din urmă vom avea: servere. Numărul de servere din DCell crește de două ori exponențial, iar numărul total de niveluri din DCell este limitat de numărul de NIC-uri din acesta. Cadrul DCell are capacitatea de a scala un număr foarte mare de servere folosind switch-uri și servere cu foarte puține porturi.

BCube

BCube topologie rețea centru de date

Arhitectura rețelei BCube adoptă o abordare centrată pe server pentru producerea unui centru de date modular folosind switch-uri [16]. Elementul principal al unui BCube, numit BCube , este foarte asemănător cu un DCell : serverele sunt conectate la n-porturi ale switch-urilor. Principala diferență între BCube și DCell este modul lor diferit de scalare: BCube folosește mai mult comutatoarele atunci când construiește o structură la nivel înalt. În timpul construcției unui BCube , Sunt folosite comutatoare suplimentare conectate la exact un server în fiecare BCube . Prin urmare un BCube conține n BCube Și comutator suplimentar (dacă comutatoarele din BCube sunt luate în calcul, sunt în total comutatoare în BCube ). Mai general, un BCube este construit de BCube ro comutator suplimentar de la n-porturi. Aceste switch-uri suplimentare sunt conectate la exact un server din BCube . în k-layer BCube, fiecare strat nu are nevoie de switch-uri (fiecare dintre ele fiind un switch n-port). Topologia BCube folosește mai mult comutatoarele în construcția unei structuri de nivel înalt, spre deosebire de topologia DCell care folosește doar un nivel 0 al comutatoarelor cu n-porturi. Oricum, amândoi au nevoie de servere NIC. Consecința este că serverele vor fi implicate în trecerea mai multor pachete în topologia DCell decât BCube. Numărul nivelurilor BCube depinde de numărul de porturi de pe servere. Numărul de servere din BCube crește exponențial cu niveluri la o rată mult mai lentă decât în ​​DCell. Având în vedere că BCube este o arhitectură concepută pentru centrele de date mobile bazate pe containere, acest nivel de scalabilitate este mai mult decât suficient.

Topologii optice

Proteus (arhitectura rețelei)

Compararea topologiilor fixe

Comparația scalei de mărime

Pentru a compara scala de dimensiuni a unui grafic care reprezintă rețeaua unui centru de date, se pot varia următoarele: numărul de porturi ale unui comutator n (gradul de conexiune al nodului asociat comutatorului), numărul de porturi ale unui server k (gradul numărului de conexiune al nodului asociat comutatorului) și numărul total de servere N din centrul de date. Următorul tabel analizează gradul de conectare a unui server, diametrul rețelei (cea mai lungă dintre toate cele mai scurte căi existente între două servere), numărul de comutatoare și numărul de cabluri (arcurile graficului) în raport cu parametrii n , k și N ai topologiei fixe specifice.

Arborele de bază Arborele gras DCell BCube
Gradul de conexiune la server 1 1 k + 1 k + 1
Diametrul net 6
Număr de comutatoare
Numărul de cabluri (arcuri)
Numărul de servere

Următorul tabel raportează numărul de servere dintr-o rețea per centru de date cu numărul de porturi ale unui comutator n (gradul de conexiune al nodului asociat cu comutatorul) și numărul de porturi ale unui server k (gradul de conexiune al nod asociat comutatorului).

n Arborele de bază Arborele gras k DCell BCube
4 64 16 2 420 64
3 176,820 256
4 3 10 1.024
6 216 54 2 1.806 216
3 3.263.442 1.296
4 10 7.776
8 512 128 2 5,256 512
3 27.630.792 4.096
4 7 10 32.768
16 4.096 1.024 2 74.256 4.096
3 5 10 65.536
48 110.592 27.648 2 5.534.256 110.592

Notă

  1. ^ a b Liu, Y., Muppala, JK, Veeraraghavan, M., Lin, D., Hamdi, M., Data Center Networks - Topologies, Architectures and Fault-Tolerance Characteristics , Springer, 2013, capitolul 3, p. 15, ISBN 978-3-319-01948-2
  2. ^ Al-Fares, M., Loukissas, A., Vahdat, A., A scalable, commodity data center architecture network , In: Proceedings of the ACM SIGCOMM 2008 Conference on Data Communication, Seattle, pp. 63-74. ACM (2008)
  3. ^ Niranjan Mysore, R., Pamboris, A., Farrington, N., Huang, N., Miri, P., Radhakrishnan, S., Subramanya, V., Vahdat, A. Portland: a scalable toler-fault tolerant layer 2 rețea de centru de date , ACM SIGCOMM Comput. Comun. Rev. 39 (4), 39-50 (2009)
  4. ^ Al-Fares, M., Radhakrishnan, S., Raghavan, B., Huang, N., Vahdat, A., Hedera: planificarea dinamică a fluxului pentru rețele de centre de date , Proceedings of the 7th USENIX Conference on Networked Systems Design and Implementation , San Jose, p. 19. Asociația USENIX (2010)
  5. ^ Clos, Charles, „ Un studiu al rețelelor de comutare non-blocante ”. Jurnalul tehnic al sistemului Bell. 32 (2): 406-424.
  6. ^ a b Guo, C., Wu, H., Tan, K., Shi, L., Zhang, Y., Lu, S. DCell: o structură de rețea scalabilă și tolerantă la erori pentru centrele de date , ACM SIGCOMM Comput. Comun. Rev. 38 (4), 75-86 (2008)
  7. ^ Guo, C., Lu, G., Li, D., Wu, H., Zhang, X., Shi, Y., Tian, ​​C., Zhang, Y., Lu, S., BCube: o arhitectură de rețea de înaltă performanță, centrată pe server pentru centre de date modulare , ACM SIGCOMM Comput. Comun. Rev. 39 (4), 63-74 (2009)
  8. ^ Wu, H., Lu, G., Li, D., Guo, C., Zhang, Y., MDCube: o structură de rețea de înaltă performanță pentru interconectarea modulară a centrelor de date , lucrările celei de-a cincea conferințe internaționale privind experimentele de rețea emergente și Tehnologii, Roma, pp. 25–36. ACM (2009)
  9. ^ Li, D., Guo, C., Wu, H., Tan, K., Zhang, Y., Lu, S., Ficonn: folosind portul de rezervă pentru interconectarea serverului în centrele de date , IEEE INFOCOM, Rio de Janeiro ( 2009)
  10. ^ a b Wang, G., Andersen, D., Kaminsky, M., Papagiannaki, K., Ng, T., Kozuch, M., Ryan, M., c-Through: optică part-time în centre de date , ACM SIGCOMM Computer Communication Review, New Delhi, vol. 40, pp. 327–338. ACM (2010)
  11. ^ Farrington, N., Porter, G., Radhakrishnan, S., Bazzaz, H., Subramanya, V., Fainman, Y., Papen, G., Vahdat, A., Helios: a hybrid electric / optic switch architecture pentru centre de date modulare , ACM SIGCOMM Computer Communication Review, New Delhi, vol. 40, pp. 339-350.ACM (2010)
  12. ^ a b Chen, K., Singla, A., Singh, A., Ramachandran, K., Xu, L., Zhang, Y., Wen, X., Chen, Y., OSA: o arhitectură de comutare optică pentru rețele de centre de date cu o flexibilitate fără precedent , Proceedings of the 9th USENIX Conference on Networked Systems Design and Implementation, Berkeley, pp. 1-14. Asociația USENIX (2012)
  13. ^ Ankit Singla, Chi-Yao Hong, Lucian Popa, P. Brighten Godfrey, Jellyfish: Networking Data Centres Randomly , University of Illinois at Urbana - Champaign, HP Labs, 2012
  14. ^ Charles E. Leiserson, Fat-trees: universal networks for hardware-efficient supercomputing , IEEE Transactions on Computers, Vol. 34, nr. 10, octombrie 1985, pp. 892-901.
  15. ^ M. Al-Fares, A. Loukissas, A. Vahdat, A scalable, commodity data center 2 network architecture , ACM SIGCOMM 2008 Conference on Data 3 Communication, Seattle, WA, 2008, pp. 63-74.
  16. ^ Lebiednik, B., Mangal, A., Tiwari, N., A Survey and Evaluation of Data Center Network Topologies , arXiv: 1605.01701, 5 mai 2016

Elemente conexe