în mitologia greacă, titanul Prometeu a fost înlănțuit de o stâncă. În fiecare zi, un vultur zbura în jos și îi mânca o parte din ficat. Organul s-a regenerat în timpul nopții, alimentând sursa de hrană. Ficatul este unul dintre puținele organe din corpul uman care se pot regenera spontan. Chiar mai impresionant, este faptul că, în timp ce ficatul se regenerează și se fixează, este încă funcțional. Grecii antici știau de această capacitate și au încorporat-o în mitologia lor cu aproape 3000 de ani în urmă.

funcționalitate continuă

când proiectăm rețele, dorim ca acestea să fie funcționale, chiar și atunci când există o întrerupere a sistemului. Se întâmplă defecțiuni Hardware, tăieturi de fibre, erori software și chiar veverițe care mestecă cabluri. Suntem preocupați de modul în care livrarea aplicațiilor și infrastructura de rețea răspund la aceste probleme. Noi arhitect tehnologii în infrastructura noastră IT pentru a minimiza impactul daunelor.

la fel ca ficatul nostru, rețeaua trebuie să funcționeze chiar dacă vindecă daunele cauzate. Cererile trebuie să fie livrate și întreprinderile au încă de lucru să fie făcut. La început, am dezvoltat protocoale de rețea dinamice, cum ar fi spanning tree protocol (STP) pentru topologiile layer 2 și routing information protocol (rip) pentru topologiile layer 3. De-a lungul timpului am avansat aceste protocoale pentru a include layer 2-based rapid spanning tree protocol (RSTP) și Layer 3 protocoale de rutare, inclusiv OSPF, ISIS, și BGP.

trecând pe stiva OSI

trebuie să oferim în continuare mecanisme pentru disponibilitatea aplicațiilor și livrarea aplicațiilor în întreaga infrastructură de rețea. Acest lucru este în cazul în care am introdus server load balancing (SLB) și manipulare DNS dinamic prin global server load balancing (GSLB). Acestea oferă mecanismele de detectare a eșecurilor serverului de aplicații și a eșecurilor complete ale Centrului de date.

rețeaua mea ideală (un fel de)

dacă ar fi să proiectez o rețea astăzi, la un nivel înalt, ar arăta foarte mult ca diagrama de mai sus. Redundanța este încorporată în fiecare aspect al arhitecturii. Există mai multe servere, site-uri diverse din punct de vedere geografic și mai multe căi de rețea către diferitele componente. Nu există un singur punct de eșec. Dacă un aspect eșuează, tehnologiile dinamice se vor reconversia automat pentru a determina o nouă cale optimă între client și serverul de aplicații.

există o mulțime de detalii fine pe care nu le acopăr în acest articol. Designul real al conectivității rețelei și dispozitivului layer 2/3 depinde de asigurarea îndeplinirii diferitelor cerințe de livrare a aplicațiilor pentru a asigura asigurarea nivelului de servicii pentru aplicații (SLA) pentru toate aplicațiile. Deoarece nu știm care sunt aplicațiile, nu putem face această determinare. Celălalt motiv este că ar trebui să scriu o carte pentru a discuta toate aspectele necesare pentru a construi această rețea.

punctele cheie de reținut atunci când vă proiectați propria auto-vindecare, regenerând infrastructura IT sunt:

• construiți redundanță în arhitectură
• folosiți tehnologii dinamice care se adaptează automat la condițiile în schimbare
• amintiți-vă că obiectivul final critic este de a asigura aplicația SLA

în continuare, vom lua această rețea și vom rupe diverse componente pentru a vedea cum afectează livrarea aplicației și ce percep utilizatorul final.

citiți ” păstrați-l simplu; faceți-l scalabil: 6 caracteristici ale Futureproof Load Balancer ” pentru a afla mai multe.

Descarcă acum