Comutatoare PicOS Data Center: EVPN și Ghid de actualizare

Majoritatea deciziilor privind comutarea centrelor de date încă încep cu o foaie de date: numărul de porturi, viteze și preț. Comutatoarele pentru centrele de date PicOS pun mai întâi o altă întrebare. Deoarece sistemul de operare, hardware-ul și straturile de management sunt decuplate, alegerea PicOS este mai puțin o achiziție de hardware și mai mult undecizia de-model de operare- modul în care echipa dvs. va furniza, automatiza și rula materialul pe durata de viață.

Acest ghid explică ce sunt de fapt comutatoarele PicOS pentru centrele de date, cum se potrivesc întrerupătorul, sistemul de operare al rețelei și controlerul AmpCon-DC, unde sunt potrivite și exact ce trebuie validat înainte de lansarea în producție. Scopul este de a ajuta o echipă de rețea să evalueze PicOS pe criterii de inginerie, nu pe limbajul de marketing.

PicOS Switch vs PicOS NOS vs AmpCon-DC: Ce alegi de fapt

Termenul „comutator al centrului de date PicOS” este adesea folosit în mod liber, ceea ce creează confuzie în timpul evaluării. Se referă la trei straturi distincte care sunt cumpărate și operate separat:

• Hardware-ul comutatorului- platforme de rețea deschise („cutie albă” sau „cutie brite”), de obicei construite pe siliciu Broadcom. Un exemplu obișnuit de centru de date este un comutator cu frunză sau coloană 1U, cum ar fi N8550-32C, cu 32 de porturi 100G QSFP28 pe un ASIC Broadcom Trident 3. ASIC-ul, vitezele portului și bufferul determină limitele dure ale ceea ce poate face cutia.
• Sistemul de operare al rețelei PicOS- thePicOS NOS de la Pica8, construit pe un nucleu Debian Linux nemodificat. Furnizează stiva Layer 2/Layer 3, EVPN-VXLAN, MLAG, securitate și telemetrie deschisă (SNMP, sFlow și gNMI). NOS, plus versiunea și nivelul de licență, determină ce caracteristici sunt de fapt disponibile.
• AmpCon-DC- controlerul de management și automatizare. Se ocupă de furnizarea zero-touch provisioning (ZTP), configurația bazată pe șablon-, descoperirea topologiei, telemetria, upgrade-urile și validarea de-a lungul întregului ciclu de viață, de la proiectarea Zilei 0 până la operațiunile Zilei 2+.

Menținerea acestor straturi separate contează în timpul evaluării: un model de comutator poate fi hardware perfect capabil, în timp ce o anumită versiune PicOS sau licență nu activează încă funcția de care aveți nevoie. Evaluați întotdeauna combinația, nu un singur strat izolat.

De ce întreprinderile evaluează PicOS pentru centre de date

Întreprinderile se uită, de obicei, la PicOS atunci când un design existent începe să limiteze performanța, scara sau operațiunile -, de exemplu, trecând de la 10G la 25G sau 100G, ridicând o nouă țesătură a coloanei vertebrale-sau încercând să reducă configurația manuală, comutată-prin-comutator.

Gestionarea traficului de est-vest cu frunze-coloana vertebrală

Arhitecturile vechi au fost reglate pentru trafic previzibil nord{0}}sud. Virtualizarea, stocarea distribuită, platformele de containere și sarcinile de lucru AI generează mult mai mult trafic est-vest între rafturi. O țesătură cu frunză-coloană aplatizează topologia și face latența și lățimea de bandă mai previzibile. Switch-urile bazate pe PicOS-poate prelua roluri de frunză, coloană, partea de sus-de-rack, chenar sau interconectare, cu condiția ca vitezele portului, capacitatea de comutare și caracteristicile de rutare să se potrivească cu designul.

Reducerea blocării furnizorului-în - și cum funcționează de fapt

„Reducerea blocării-in” este ușor de revendicat, așa că merită precizat mecanismul. Într-o stivă tradițională, hardware-ul, NOS, licențele, managementul și asistența sunt incluse într-o singură relație de furnizor. PicOS urmează un model de rețea-deschis, dezagregat: același NOS rulează pe hardware-cutie albă validată de la mai mulți furnizori, cu suport complet pentru viteze de la mai multe-gig până la 400-gig și peste și pentru EVPN-VXLAN. În practică, asta înseamnă că modelul de operare și automatizarea devin partea durabilă a designului tău, în timp ce furnizorul de hardware de bază se poate schimba în timp. Schimbul-este real, totuși - vă asumați mai multă responsabilitate pentru proiectare, validare și proprietate operațională.

Automatizarea Zilei 0 în Ziua 2+ Cu AmpCon-DC

CLI manual este tolerabil pentru o mână de comutatoare și riscant pentru zeci sau sute. AmpCon-DC este locul în care PicOS câștigă o mare parte din valoarea sa operațională: integrarea ZTP, șabloanele de configurare bazate pe Jinja-, manualele Ansible și API-urile REST reduc munca repetitivă și deviația de configurare. Obiectivul nu este automatizarea de dragul ei -, ci este integrarea repetabilă, modificarea auditabilă și recuperarea mai rapidă.

Capabilități cheie de evaluare

EVPN-VXLAN și IP Fabric Readiness

Țesăturile moderne extind în mod obișnuit stratul 2 peste un strat de bază stratul 3 direcționat folosind două standarde împreună:VXLAN, încapsularea suprapusă definită în RFC 7348, șiEVPN, planul de control bazat pe BGP-standardizat în RFC 7432. Atunci când modelul de comutare și versiunea PicOS îl acceptă, PicOS poate fi evaluat pentru țesături scalabile leaf-coloana vertebrală care servesc medii virtualizate și în stil cloud-, cu mai multe rafturi. Tratați asistența EVPN-VXLAN ca versiune- și model-specific și confirmați-l pe platforma exactă pe care intenționați să o cumpărați.

MLAG și înaltă disponibilitate

MLAG permite ca două comutatoare fizice să prezinte un singur punct de agregare logic către dispozitivele din aval, menținând toate legăturile active și eliminând dependența de design-urile grele -arboresc-. Pentru rolurile de top-de-rack și de agregare, aceasta oferă legături în sus redundante pentru servere și stocare, fără golurile de failover comune stivuirii tradiționale. Validați linkul-peer, keepalive, sincronizarea ratei erorii și comportamentul port-orfan înainte de a vă baza pe el.

Programabilitate și telemetrie

Un comutator de centru de date ar trebui să fie ușor de automatizat-în mod prestabilit. PicOS expune interfețele bazate pe Ansible, Python și standard-și oferă vizibilitate prin telemetria de streaming SNMP, sFlow și gNMI. Beneficiul practic este consecvența: configurații șablon, monitorizare de bază și detectarea derivei pe întreg materialul.

Managementul ciclului de viață și vizibilitate

Capacitatea de comutare este doar o parte a operațiunilor. De asemenea, echipele au nevoie de topologie, starea interfeței, starea dispozitivului și vizibilitatea-derivei configurației. Cu AmpCon-DC, mediile PicOS pot fi furnizate, monitorizate, modificate și validate dintr-o singură consolă - care, pentru echipele cu personal de inginerie limitat, poate conta la fel de mult ca debitul brut.

PicOS vs NOS închis vs NOS comunitar

Diferența semnificativă dintre aceste opțiuni este modelul de operare, nu specificațiile hardware principale. Tabelul de mai jos compară o stivă închisă tradițională, un NOS deschis condus de comunitate-și PicOS cu AmpCon-DC.

Cele mai bune scenarii de-potrivire și de slabă-potrivire

PicOS este o alegere puternică în unele medii și una slabă în altele. A fi sincer cu ambele protejează implementarea.

Potrivire puternică atunci când:

• Construiți țesături leaf-coloana vertebrală sau EVPN-VXLAN și doriți o sursă de hardware deschisă.
• Echipa este gata de automatizare-(sau dorește să devină așa) și valorează operațiuni repetabile, conform șablonului.
• Doriți să standardizați un singur NOS și un model de management pe mai multe switch-uri.
• Hardware-ul țintă se află pe lista de compatibilitate validată, iar versiunea PicOS acceptă caracteristicile necesare.

Mai puțin potrivit când:

• Echipa nu are nicio capacitate de automatizare și nici un plan de a o construi.
• Depindeți foarte mult de TAC-ul unui singur furnizor pentru operațiunile zilnice--.
• Nu există posibilitatea de a valida-materialul înainte de producție.
• Hardware-ul preferat sau setul de caracteristici necesare nu se află în matricea acceptată.

Cazuri de utilizare comună

Actualizări de la 10G/25G la 100G

O cale frecventă este creșterea accesului la server la 25G și construirea frunzei 100G-la-legături în sus. Dincolo de comutatorul în sine, upgrade-ul depinde de stratul fizic: pentru rulările multimode, gradul de fibră pe care îl implementați determină acoperirea, deci confirmați devreme distanțele acceptate - diferențele dintreFibră multimod de la OM1 la OM5 și limitele de distanță ale acestoraafectează direct dacă o legătură 100G va funcționa în instalația dvs. de cablare.

Leaf-Spine Data Center Fabrics

Comutatoarele Leaf conectează serverele și stocarea; comutatoarele coloanei vertebrale asigură materialul-de mare viteză între frunze. PicOS se potrivește acestor roluri atunci când vitezele, numărul de porturi și caracteristicile de rutare se potrivesc cu designul. Cablajul structurat face ca această planificare să fie mult mai curată -Trunchi MPO/MTP și cablare breakoutîn față menține conexiunile cu densitate mare-frunza-la-coloana vertebrală pe măsură ce materialul crește.

Gateway și interconectare pentru centrul de date

Unele modele extind comutarea între site-uri, zone sau domenii, unde rutarea scalabilă Layer 3 și vizibilitatea centralizată a ciclului de viață contează cel mai mult. Aceste curse mai lungi necesită, de obicei, optică cu un singur-mod, așa că potriviți raza transceiver-ului la linkul - examinând diferențele dintreFibră mono-OS1 și OS2ajută la confirmarea că o anumită distanță de interconectare este acceptată.

AI, HPC și Ethernet fără pierderi

Materialele AI și HPC nu se referă doar la lățime de bandă brută. Traficul RDMA (RoCEv2) are nevoie de o țesătură Ethernet fără pierderi sau aproape-fără pierderi, care depinde de controlul fluxului, cum ar fi PFC și semnalizarea congestiei, cum ar fi ECN, plus buffer-uri de comutare adecvate și telemetrie curată. Switch-urile PicOS pentru centre de date acceptă transport fără pierderi bazat pe PFC/ECN-pe platforme compatibile, iar designurile-cu lățime de bandă mare folosesc din ce în ce mai mult interfețe 400G - atunci când planifică legăturile în sus pentru coloana vertebrală sau GPU-, confirmă optica și factorul de formă, inclusiv400G QSFP-DD. Validați comportamentul de congestie, dimensionarea bufferului și compatibilitatea NIC în raport cu volumul dvs. de lucru specific înainte de a vă angaja.

Cum să planificați o implementare PicOS

O implementare de succes începe de la cerințele de proiectare, nu de la o listă de produse. Lista de verificare de mai jos mapează fiecare cerință cu ceea ce trebuie verificat, de ce este important și ce nu merge bine dacă este omisă.

Două elemente din această listă provoacă cele mai evitabile întârzieri. În primul rând, decideți din timp mediul de acces la server: dacă să standardizațiOptică 10GBASE-T sau SFP+modifică ipotezele de cablare, putere și acoperire în fiecare rack. În al doilea rând, planificați în mod deliberat cablarea de tip breakout -, de exemplu, spargerea unui singur port 100G în 4 x conexiuni de server 25G - folosind dreaptaCablajul MPO breakoutastfel încât harta portului și alocările de fibră se aliniază înainte de ziua instalării.

Înainte de producție, validați designul într-un laborator sau pilot: convergența rutei, comportamentul rutei EVPN, failover-ul MLAG, șabloane de automatizare, monitorizare și rollback. Apoi, desfășurați în faze, în loc să tăiați întreaga rețea deodată, cu excepția cazului în care este o construcție controlată. Puteți revizuiPortofoliul de comutare a centrelor de date Pica8 și platforme validatepentru a confirma ce combinații de hardware și caracteristici sunt acceptate pentru designul țintă.

Greșeli frecvente de evitat

Alegerea numai după viteza portului.Viteza contează, dar funcțiile de rutare, suportul de automatizare, dimensionarea bufferului, compatibilitatea optică, nivelul de licență, modelul de asistență și calea de actualizare fac parte din decizie.

Ignorarea funcției NOS și a cerințelor de licență.Sistemul de operare, versiunea și licența acestuia determină ce poate face de fapt rețeaua. Confirmați acoperirea L2/L3, EVPN-VXLAN, MLAG, telemetrie și securitate față de platforma exactă înainte de a cumpăra.

Subestimarea schimbării operaționale.O rețea pregătită pentru automatizare-are nevoie de noi procese: cine deține șabloanele, cine aprobă modificările, cum se face backup pentru configurații și cum este gestionată derularea.

Sari peste validarea laboratorului.Pentru modificări importante ale centrului de date, un test de laborator nu este opțional. Validați cel puțin funcțiile de bază ale fabricii, redundanța, monitorizarea și recuperarea erorilor înainte ca orice trafic să depindă de acestea.

PicOS este potrivit pentru centrul dvs. de date?

Switch-urile pentru centrele de date PicOS se potrivesc întreprinderilor care doresc o țesătură scalabilă, operațiuni gata de automatizare, aprovizionare hardware deschisă și un ciclu de viață structurat - în special echipele care planifică design de frunze-copii, upgrade-uri de la 10G/25G la 100G, EVPN-materiale VXLAN sau medii în care nu mai este manuală de comutare{{{- durabil. Acestea sunt o potrivire mai slabă acolo unde nu există nicio capacitate de automatizare, o dependență puternică de asistența unui singur-furnizor, niciun laborator de validare sau hardware în afara matricei acceptate.

Un următor pas practic: documentați-vă punctele dificile de proiectare și operaționale actuale, definiți arhitectura țintă și setul de caracteristici necesare, confirmați compatibilitatea cu versiunea hardware și PicOS și testați materialul într-un mediu controlat înainte de a începe producția.