Dată fiind perioada relativ tulbure, din punct de vedere politic, pe care o traversăm, m-am trezit angrenat și eu, cu sau fără de voie, într-o discuție pe temele cu pricina. Nu de alta, dar român sunt, la fotbal nu mă pricep, iar Dacia nu mai are nevoie de reparații de ceva timp încoace, așa că nu mi-a mai rămas altceva de făcut. Firul unei discuții mi-a readus aminte o perioadă veche și nu foarte luminoasă din trecutul meu, cursul de termotehnică din anul 3. Profesorul de pe vremea aceea ne povestea la un moment dat despre revoluții ca fiind evenimente ce duc la apariția unor puncte de inflexiune pe graficele unor procese ce altfel ar stagna, și ar intra inevitabil în declin.
Ce legătură are asta cu povestea mea de azi? Am început să lucrez în rețelistică acum 12 ani, pe vremea aceea aveam switch-uri, routere, IP, spanning tree, link aggregation, OSPF și altele asemenea. De ce avem parte astăzi? Fix de aceleași lucruri, uneori cu un NG în fața și cu mici schimbări cosmetice sau funcționale dar nimic revoluționar.
Am spus 12 ani pentru că de pe atunci mă ocup eu de lucrurile astea, dar ele stau la fel cam de când învățam să merg pe bicicletă. Seamănă cu unul dintre acele procesele ce stagnează în timp ce în jurul nostru avem cloud, bring-your-own-device, virtualizare. Ce e de făcut?
SDN Software Defined Networking. Bun, am aruncat cuvintele de efect, v-am stârnit curiozitatea ( sper ), acum să vedem ce facem cu asta. Despre SDN am mai scris un articol acum câteva luni, dar am senzația că trebuie să reiau subiectul fiindcă între timp ideea prinde din ce în ce mai mult avânt.
Pentru a reuși să fac o punte între teorie pură și ceva practic, voi trece puțin prin modul de lucru al unui echipament de rețea, nu vă temeți, nu va fi foarte tehnic – pentru tehnica hard-core vă invit la training-urile noastre. Să revenim dar, un switch, funcționează ca o organizație; are lucrători – partea care se ocupă de transmisia efectivă a datelor; Data Plane, project manager – cel ce coordonează muncitorii; Control plane – și middle management, partea care se ocupă de comenzile pentru Project manager; Management plane. Dacă vreți să-mi spuneți că lipsește CEO-ul, nu lipsește, acela ar trebui să fie admin-ul de rețea, dar dacă află asta o să ceară un salariu mai consistent.
Switch-ul nostru, dupa cum bine știți se descurcă foarte bine de ani buni, funcționând așa. Toate cele 3 organizații funcționează într-unul și același echipament și totul ar fi bine și frumos dacă ar fi câte unul singur în fiecare rețea, dar, după cum foarte bine știți, nu e nici pe departe așa, ceea ce duce la apariția a două minore neajunsuri ale acestei abordări.
Prima: switch-ul nostru se crede centrul universului și tratează lucrurile într-o manieră individualistă dacă îmi permiteți exprimarea – “Fac asta fiindca eu așa văd lucrurile” Da, există încercări de a lucra în echipă, s-au făcut team-building-uri cu echipamentele prin intermediul diverselor protocoale, dar asta ascunde doar praful sub preș, la bază el așa funcționează.
A doua: CEO-ul nostru nu are timp de micro-management deși, în cazul de față cel puțin, nu ar fi o politică rea, dar este total impractic pentru admin să intervină pe fiecare echipament și să-i explice cum să facă treaba.
Fix aici intervine SDN și răstoarnă tot ce am învățat până acum. “Spargem” organizația, lăsăm data plane la nivel hardware, acolo unde este și acum, dar luăm control plane și management plane și le mutăm într-un singur centru de comandă, probabil pe un server undeva. Rezultatul este că vom avea un echipament hardware distribuit cu o inteligență centralizată. Nu mai avem o vedere egocentrică asupra transmisiei datelor, ci una de ansamblu, un switch nu va mai trimite date pe un port fiindcă acolo știe că se află adresa, ci rețeaua ca întreg poate reacționa la schimbări în tiparele și volumele de trafic. Eu am dat ca exemplu switch-ul, dar principiul se aplică tuturor echipamentelor de rețea. Imaginați-vă cum ar funcționa un load balancer de exemplu dacă inteligența care îl comandă știe deja nivelul de încărcare al echipamentelor din spatele său. Sau cât de rapid ar reacționa un firewall în momentul în care apare un comportament ciudat în rețeaua din spatele său. Cum ar fi dacă nu am mai putea crea bucle în rețea, din simplul fapt că inteligența centralizată își vede topologia și evită furtunile de broadcast permițând în același timp existența a mai multe căi active pentru trafic, și toate astea fără configuratii laborioase.
Pare ceva SF, nu? Da, cam așa sună, dar e bine să aflați că primii pași au fost deja făcuți. Există deja protocoale ce permit comunicarea între un server și echipamentele de comunicații la nivel de DataPlane, există software pentru controllere, aplicațiile ce vor deveni inteligența centralizată și există echipamente compatibile. Mai multi producători de echipamente, printre care și noi, lansează sisteme de operare ce permit funcționarea mixtă a echipamentelor, în regim normal sau SDN. Piesele puzzle-ului sunt aici, trebuie doar puse la muncă.
Dacă paragraful de mai sus v-a dus cumva la ideea că ar trebui să vă grăbiți și să săriți în trenul SDN, atunci înseamnă că sunt un vânzător mai bun decât credeam ( creează un sentiment de urgenă ). Nu ați pierdut nimic încă, după cunoștințele mele nu există încă instalări în mediu de producție a așa ceva. Nu strică însă să vă interesați, citiți despre OpenFlow, mergeți pe pagina noastră web lahttp://www.alliedtelesis.com/videos/whatissdn și vedeți ce spun și inginerii noștri despre asta. Dacă tot sunteți acolo, citiți și mai jos despre AMF, protocolul despre care am vorbit data trecută, modalitatea noastra de a centraliza Management Plane . Dacă după toate astea v-ați hotărât că ați vrea să încercați, dați-ne de știre, avem echipamente compatibile Open Flow, iar dacă sunteți fericiții posesori ai unuia dintre switch-urile noastre de generație nouă, s-ar putea să avem software OpenFlow pentru el.
Ca de obicei, închei reamintindu-vă că puteți lua legătura cu noi fie prin intermediul site-ului,www.alliedtelesis.com , fie la adresa de mail romania@alliedtelesis.com.
Iar ca un PS, SDN este un punct de inflexiune pentru zona mea de lucru, la fel cum cloud sau virtualizare sunt pentru alte domenii ale IT-ului, dar așa cum ne atrăgea atenția profesorul de termotehnică, după un punct de inflexiune, graficul procesului poate merge în sus, dar la fel de bine poate merge și abrupt în jos.
