Acesta se vrea a fi unul dintre articolele ce ar putea face parte dintr-o serie “revisited”. Cu ceva timp în urmă scriam ceva despre datacenter, și începeam totul cu o alăturare între un centru de date și un sughiț. Nu s-a schimbat în principiu nimic din ceea ce spuneam la vremea respectivă, dar de atunci am mai învățat câte ceva.

Spuneam atunci că rolul principal al unui datacenter este să funcționeze, non-stop dacă acest lucru este posibil. Deși asta nu s-a schimbat în nici un fel, percepția despre cum poți ajunge la asta. Reciteam mai deunăzi împărțirea făcuta de Uptime Institute pentru data-centere. Primul dintre cele 4 niveluri spune că uptime-ul țintit e de 99,671% ceea ce ar totaliza aproape 29 de ore permise ca downtime într-un an. Deși pare destul de mult, situația poate scăpa ușor de sub control iar aceste 28 de ore pot deveni brusc extrem de puține.
Ceea ce am aflat de la momentul scrierii acelui articol este că există foarte multe datacentere construite pentru a servi unui scop precis și nu pentru a respecta standarde. Cum de cele mai multe ori, respectarea scopului include și un cost cât mai scăzut, am observat că, cel puțin aici la Allied Telesis, avem o gamă de echipamente de datacenter extrem de variată.

În general, când te gândești la datacenter te gândești la arhitecturi de o complexitate ridicată, cu un accent foarte mare pus pe redundanță precum și clasa echipamentelor folosite acolo. Am văzut cazuri în care nimic nu e mai departe de adevăr. Am văzut însă
că un datacenter construit pentru procesare distribuită are foarte puțin în comun cu o arhitectură clasică pentru centre de date, și mult mai mullte similitudini cu o rețea de tip enterprise unde accentul principal cade pe prețul per port.
Am văzut de asemeni datacentere ce rulează aplicații de bursă, folosind switch-uri ce fac parte din gamele de acces și nicidecum ceva ce ne-am gândi să punem într-un datacenter.
Mai mult chiar, am văzut datacentere ce oferă software as a service folosind echipamente de comunicații din seriile websmart puse în
arhitecturi redundante.

Există câteva puncte comune în toate cele de mai sus:
• Centrele cu pricina au fost contruite pentru o cerință de business specifică
• Inventivitatea umană este o metodă sigură de a optimiza costuri
• Nimeni nu a previzionat un uptime pentru ele
• Toate funcționează peste parametrii minimi impuși
• Echipamentele ce le compun funcționează fără probleme.

Asta îmi amintește de unul dintr trainingurile făcute în anii trecuți. Tocmai terminasem un modul de proiectare de rețele, și dat fiind că mai rămăsesem cu ceva timp la dispoziție, am împărțit oamenii în trei echipe separate, le-am desenat o arhitectură de rețea pe tablă și i-am rugat să facă în așa fel încât o stație conectată într-o extremitate a rețelei să poată comunica cu o alta situată diametral opus. Rezultatul a fost că am obținut 3 configurații total diferite ale echipamentelor, și bineînțeles toate diferite de ce aveam eu în cap când am făcut desenul. Toate soluțiile aveau însă în comun ceva, funcționau!

Cu alte cuvinte, ceea ce am învățat în ultimul an umblând prin diverse locuri, stând de vorbă cu diverși oameni și văzând ce au construit, este că nu există soluții greșite atâta timp căt aplicația dorită funcționează. Există soluții ce nu sunt optime, soluții ce nu scalează bine, soluții prea complexe sau pur și simplu exotice, dar nu sunt greșite, nici una dintre ele.
Ceea ce înseamnă că pentru un proiect de datacenter, citiți definițiile, guide-line-uri, vedeți ce au făcut alții, dar dupa aceea aruncați manualele și construiți ceea ce vă trebuie de fapt în situația respectivă.

Un switch de datacenter este extrem de rapid, dar în cazul în care nu aveți nevoie de o latență mică acolo, s-ar putea să fie mai
ieftin să folosiți un stack de echipamente încadrate la mediul enterprise altfel.
Un echipament modular de mare capacitate ar putea fi depășit în situația în care are de gestionat o rețea “flat” de dimensiuni mari, și ar putea fi mai eficient să folosiți un set de echipamente L3 care să segmenteze rețeaua cu pricina la o fracțiune din prețul modularului. Un stack oferă un timp de recuperare extrem de scurt în urma unei avarii, dar dacă nu ăsta este scopul principal, un inel
făcut din echipamente ce nu au această funcționalitate ar putea deservi scopul cel puțin la fel de bine.

Dacă tot acest articol v-a făcut să vă gândiți că întotdeauna pot fi folosite echipamentele mai ieftine, există și un revers al medaliei însă: switch-urile websmart au capacități SNMP reduse și s-ar putea să aveți probleme când vine vorba de managementul lor. La fel cum ați putea avea probleme la managementul configurațiilor lor.
Switch-urile de acces au limite destul de drastice la dimensiunie tabelelor de adrese, limite ce pot fi atinse destul de ușor chiar în medii virtualizate. Un echipament de rezervă aflat într-o cutie ar putea fi o alternativă ieftină pentru folosirea unui stack sau a unui
echipament cu două surse de alimentare, dar tot în cutie va rămâne dacă cumva se strică ceva sâmbătă noaptea sau când sunteți în concediu.

Ideea ce ar trebui să se desprindă de aici este, după cum ar spune americanii, “să gândiți în afara cutiei”. Căutați soluția pentru nevoia dvs și căutați în întreaga gamă de echipamente a producătorilor, nu doar între echipamentele încadrate la datacenter. Ar fi mai presus de toate, indiferent de ce gamă de echipamente alegeți, aveți grijă totuși să folosiți echipamente de calitate, fiindcă un
switch de 10G care se blochează o dată pe săptămână ar putea fi mai rău decat un switch FastEthernet ce funcționează fără probleme.

de Alexandru Gaiu, Solutions Enginner la Allied Telesis