|
Produse - Stocare Media
|
|||
| Sisteme de stocare EFS Gama de servere pentru stocare EFS |
Sisteme de stocare SNS Gama de servere pentru stocare SNS |
||
|
Articole - Stocare Media
|
|||
| Sistemul de stocare EFS Tehnologiile utilizate |
|||
Tehnologiile si solutiile tehnice utilizate in sistemele de stocare EditShare
Hydra livreaza toata gama de produse de EditShare la comanda.
Acest articol prezinta tehnologiile si solutiile tehnice care stau la baza sistemului de stocare EditShare.
Sistemele de stocare EditShare sunt special construite pentru a fi utilizate in aplicatii de productie sau post-productie video cu fluxuri de lucru in echipa.
Pentru acest tip de aplicatii, sistemul de stocare trebuie sa indeplineasca anumite cerinte pe care un sistem de stocare “traditional” din industria IT nu le poate indeplini (nefiind construit ca sa indeplinesca aceste cerinte).
| Cerinta 1. Rezilienta pe multiple planuri a sistemului de stocare |
Sistemul de stocare trebuie sa aiba la baza un mecanism de rezilienta care sa permita metinerea integritatii datelor stocate in doua scenarii importante:
- defectarea de discuri in interiorul nodului de stocare
sau
- defectarea unui intreg nod de stocare aflat intr-un grup de noduri de stocare.
Protectia la nivel de nod de stocare
Serverul de stocare EditShare ofera rezilienta datelor utilizand o schema de redundanta de tip RAID 6 toleranta la defectarea a maxim 2 discuri HDD (permitand mentinerea performantelor si a integritatii datelor stocate in cazul avarierii a 2 discuri).
Protectia la nivel de sistem de stocare
Rezilienta la nivelul intregului sistem de stocare este posibila in sistemele EditShare de dimensiuni medii care contin cel putin 3 noduri (servere) de stocare si unul sau doua servere de control.
Fiecare componenta din sistem are rolul sau specific:
- serverul de control (numit si EFS Controller) este un server cu rol de control al traficului in sistemul EFS (EditShare File System), gestionand cererile de citire/scriere ale clientilor EFS care solicita acces la nodurile de stocare si la locatiile in care si din care se fac tranzactiile de citire/scriere (contine metadata sistemului de fisiere)
- noduri de stocare – servere performante care acomodeaza numeroare discuri de tehnologie HDD, SSD sau NVMe (in functie de modelul si performantele nodului de stocare) in care se face stocarea efectiva a fisierelor si care sunt responsabile cu operatiunile de scriere si citire pe discuri sub controlul altor elemente din sistem (EFS Controller)
- sistemul de fisiere EFS care include tehnologii software care maresc semnificativ performantele si rezilienta storage-ului. Specific sistemului de fisiere EFS este utilizarea unui Namespace unic care se poate extinde ca si capacitare de stocare odata cu adaugarea de noi noduri. Intr-o explicatie simplista, existenta unui Namespace inseamna ca nu se poate afla concret pe care server de stocare este stocat un anume fisier (de exemplu un material video) care a fost transferat in sistem. Acest lucru este intentionat, astfel ca diferite bucati din acest material video sunt “imprastiate” pe toate serverele de stocare din sistem.
Protectia sistemului la pierderea (defectarea) unui intreg nod de stocare
Se face utilizand tehnologia XOR.
XOR este o operatie booleana care mai poarta denumirea de “SAU Exclusiv”. Operatia XOR care utilizeaza 2 valori de intrare este denumita si XOR2:
| Valoare 1 | 1 | 0 | 1 | 0 |
| Valoare 1 | 1 | 1 | 0 | 0 |
| XOR2 | 0 | 1 | 1 | 0 |
| Regula de calcul: - daca intrarile sunt identice, rezultatul este “0” - daca intrarile sunt diferite, rezultatul este “1” |
||||
Operatia XOR are urmatoarea proprietate:
- daca XOR (Valoare 1, Valoare 2) = Valoare 3, atunci sunt valabile si urmatoarele:
| XOR (Valoare 1, Valoare 3) = Valoare 2 |
| XOR (Valoare 2, Valoare 3) = Valoare 1 |
Cu alte cuvinte, daca se pierde oricare valoare din cele trei, ea poate fi recuperata din celelalte doua.
XOR se poate aplica pentru mai mult de 2 valori de intrare. In exemplul de mai jos este prezentata operatia XOR pentru 3 valori de intrare (adica operatie de tip XOR3):
| Valoare 1 | 1 | 1 | 1 | 0 | 1 | 0 | 0 | 0 |
| Valoare 2 | 1 | 1 | 0 | 1 | 0 | 1 | 0 | 0 |
| Valoare 3 | 1 | 0 | 1 | 1 | 0 | 0 | 1 | 0 |
| XOR3 | 1 | 0 | 0 | 0 | 1 | 1 | 1 | 0 |
| Regula de calcul: - daca numarul de valori “1” este 1 sau 3, atunci rezultatul este “1” - daca numarul de valori “1” este 0 sau 2, atunci rezultatul este “0” |
||||||||
Operatia XOR este valabila si in cazul lucrului cu octeti ca valori de intrare.
Din exemplele de mai sus se pot trage urmatoarele concluzii:
- operatia booleeana XOR necesita cel putin 2 valori de intrare
- se aplica atat bitilor, cat si octetilor
- permite recuperarea oricareia din valorile originale
Implementare in sistemul de fisiere EFS (EditShare File System):
- EFS utilizeaza noduri de stocare in grupuri de stocare cu XORn unde n = 2, 3 sau 4
- acest lucru inseamna ca datele stocate sunt distribuite in 3, 4 sau respectiv 5 noduri (servere de stocare)
Astfel se distribuie datele stocate cu valorile XOR asociate pe mai multe noduri din grup.
Motivul pentru care un sistem de stocare EFS (cu rezilienta la pierderea unui nod) trebuie sa aiba cel putin 3 noduri este ca pentru o operatie de tip XOR trebuie sa existe cel putin 2 valori de intrare.
XOR2 inseamna ca datele stocate impreuna cu valorile XOR asociate sunt distribuite pe 3 noduri.
Situatia de functionare normala (toate cele 3 noduri de stocare functioneaza corect):
![]() |
- din punct de vedere al distributiei de date, in cazul XOR2, al 3-lea nod poate fi considerat ca “nod de paritate” - la operatia de scriere, sistemul de fisiere EFS va alege in mod aleator 2 noduri (va scrie prima bucata de fisier in nodurile 1 si 2, apoi a 2-a bucata de fisier in nodurile 1 si 3, apoi a 3-a bucata de fisier in nodurile 2 si 3 si asa mai departe |
Cu schema de rezilienta XOR2 se poate pierde un nod de stocare (din cele 3) fara a fi afectate datele stocate in sistem.
Functionarea sistemului in cazul unui nod avariat (in sistemul de stocare implementat cu XOR2)
Prin nod avariat se intelege una din urmatoarele situatii: cablu de retea sau fibra intrerupte, lipsa alimentare pentru nod sau avarie a serverului.
In exemplul de mai jos se presupune ca s-a defectat nodul 3:

XOR recupereaza datele care lipsesc (care erau stocate in nodul 3), acest proces realizandu-se in timp real.
Mai mult decat atat, EditShare a perfectionat aceasta tehnica prin introducerea tehnologiei care poata denumirea de SwiftRead.
SwiftRead monitorizeaza timpul de raspuns al nodurilor. Daca un nod nu raspunde intr-un interval de timp prestabilit, SwiftRead reconstruieste datele din nodul care nu raspunde utilizand datele si paritatea din celelalte noduri de stocare ale sistemului.
Tehnologia SwiftRead isi dovedeste eficienta in urmatoarele situatii:
- atunci cand nodul are o avarie permanenta
sau
- atunci cand ar aparea o congestie sau un blocaj datorat unei situatii de disputa – adica un numar mare de clienti conectati care solicita simultan informatie din acelasi nod, iar nodul nu raspunde in intervalul de timp prestabilit la aceasta solicitare. In acest caz SwiftRead ia decizia de reconstructie a datelor din acest nod pentru a gestiona eficient aceasta situatie de disputa.
Asa cum s-a mentionat si mai sus, sistemul de stocare EFS poate fi configurat in clustere (grupuri de stocare) cu XOR2, XOR3 sau XOR4.
Exemplu de grup de stocare in configuratie XOR4

- numarul minim de noduri pentru XOR4 este de 5 noduri
- din punct de vedere al distributiei de date, al 5-lea nod poate fi considerat ca “nod de paritate” pentru XOR4
- la operatia de scriere, sistemul de fisiere EFS va alege in mod aleator 4 noduri (va scrie prima bucata de fisier in nodurile 1, 2, 3 si 4, apoi a 2-a bucata de fisier in nodurile 1 ,2, 3 si 5 si asa mai departe
Indiferent de ordinul XOR-ului folosit, cu cat numarul de noduri din cluster este mai mare, cu atat situatiile de disputa intre clienti care solicita citirea datelor stocate din acelasi nod se reduc din ce in ce mai mult.
Protectia sistemului la pierderea (defectarea) unui server de control
Asa cum s-a mentionat mai sus, rolul serverelor de control din sistemele de stocare EditShare este de a controla traficul in sistemul EFS, gestionand cererile de citire/scriere ale clientilor EFS care solicita acces la nodurile de stocare.
Arhitecturile sistemelor EditShare care suporta si protectie la pierderea (defectarea) unui server de control (in arhitecturi care utilizeaza 2 servere de control) sunt tolerante la defectarea unuia dintre ele, nefiind afectate in niciun fel performantele sistemului si integritatea datelor stocate.
Insa utilizarea a 2 servere de control nu rezolva de la sine situatia defectarii unuia dintre ele.
In defectarea unui server de control poate aparea situatia foarte probabila ca acesta sa functioneze intermitent, caz in care cele 2 servere de control vor lucra unul impotriva celuilalt incercand sa preia controlul asupra sistemului.
In terminologia IT aceasta situatie poarta denumirea de “Split Brain”, doua jumatati ale creierului care functioneaza independent.
Este de la sine inteles ca alegerea serverului care functioneaza corect nu este posibila fara contributia unui element suplimentar.
De aceea in procesul de votare a serverului de control defect intervine si un nod de cvorum, care este de fapt unul din nodurile de stocare pe care este instalat suplimentar un software de cvorum care permite acestui nod sa voteze serverul de control defect impreuna cu serverul de control care functioneaza normal:

In urma rezultatului votului, in sistemul EditShare sunt implementate 2 actiuni distincte care asigura izolarea completa a serverului de control defect de restul sistemului.
Actiunea de separare completa a serverului de control poarta si denumirea de Fencing (in traducere libera “ingradire”).
Prima etapa a Fencing-ului: oprirea serverului de control defect prin intermediul de comenzi software via interfata IPMI.
A doua etapa a Fencing-ului: daca prima etapa nu are succes, se aplica o comanda directa asupra panoului de distributie alimentare din rack care intrerupe alimentarea serverului de control defect.
In acest fel sistemul EditShare asigura izolarea completa a serverului de control defect de restul sistemului.
Prin implementarea tuturor mecanismelor descrise mai sus se asigura rezilienta sistemului Edithare la defectarea oricarei componente din sistem, fara a afecta performanta sistemului sau integritatea datelor stocate.
| Cerinta 2. Asigurarea unei largimi de banda garantate si a unei latente deterministice in toate situatiile, indiferent de aparitia unor evenimente interioare sau exterioare sistemului. |
In aceasta privinta sunt putine sistemele care pot garanta banda si latenta deterministica necesare in aplicatiile de productie video unde este necesara asigurarea benzii in cazul accesului simultan la multiple fisiere video.
Un flux de lucru tipic este cel al mai multor editoare NLE care lucreaza simultan pe acelasi sistem de stocare centralizat si care acceseaza simultan acelasi fisier video. Prin asigurarea parametrilor de largime de banda si latenta se asigura aceesi experienta de utilizare pe statiile de editare NLE ca si cand acel material video ar fi stocat local pe statia de editare. In exemplul de fata, daca toti editorii acceseaza simultan acelasi fisier video si fac de exemplu scrubbing pe timeline, nu vor exista simptome precum pierdere de frame-uri sau latente in timpul acestei operatii.
Un alt exemplu este un flux de lucru in timp real cum ar fi mai multe canale de playout care redau materiale video aflate in sitemul de stocare centralizat (situatie in care nu trebuie sa existe latente la redare sau pierdere de frame-uri).
In cazul sistemelor de stocare EditShare, largimea de banda garantata este determinata intrinsec de larginea de banda individuala a fiecarui nod (server) de stocare. Astfel, utilizarea a 2 noduri dubleaza largime de banda, utilizarea a 3 noduri de stocare tripleaza banda si asa mai departe.
Pe langa aceasta, asa cum s-a mentionat si mai sus, tehnologia SwiftRead are un rol important in gestionarea eficienta a situatiilor de disputa, in situatiile cand mai multi clienti acceseaza simultan acelasi material aflat in sistemul de stocare, eliminand comportamentul unui nod de stocare “lent” (care nu raspunde in timp util la cererile clientilor de a citi date din acesta).
SwiftRead permite ca cererile de citire sa fie efectuate cu o viteza mai mare decat cea normala in situatiile accesarii simultane a aceluiasi fisier de catre mai multi clienti.
SwiftRead nu ajuta numai la combaterea disputei, ci mareste in acelasi timp si toleranta la defectare a intregului sistem de stocare (luand masuri imediate la defectarea unui nod si facand acest lucru fara a afecta performantele globale ale storage-ului).
Indiferent de situatie, disputa intre resurse limiteaza performantele sistemului de stocare.
Strategia EditShare si a sistemului de fisiere EFS este minimizarea situatiilor de disputa acolo unde este posibil si gestionarea acesteia acolo unde este inevitabila.
Astfel, pe langa tehnologia SwiftRead, un rol important il au si serverele de control (EFS controller).
Cererile clientilor pentru a accesa sistemul de stocare se face printr-un subsistem care gestioneaza metadata specifica sistemului de fisiere care spune clientului unde sa faca scrierea si citirea.
Viteza cu care opereaza sub-sistemul de metadata determina viteza de acces in sistemul de stocare.
O metadata neoptimizata incetineste viteza de raspuns la cererile de citire/scriere.
Strategii EditShare pentru optimizarea metadatei sistemului de fisiere
Cererile de acces si fisierele de metadata sunt gestionate de un server dedicat (in cazul de fata serverul de control denumit si EFS controller sau metadata controller).
In consecinta, metadata nu este stocata pe acelasi disc impreuna cu materialele video.
Serverul de control stocheaza metadata in memoria RAM
Nu exista latenta HDD, limitari de banda sau de trafic I/O (tipic latenta unui HDD de clasa “Enterprise” este de 50 – 150ms). Un metadata controller poate gestiona spatii de stocare pana la 5PB si pana la 500 milioane de fisiere. Numarul maxim de fisiere este determinat de capacitatea RAM-ului existent in metadata controller.
Protocolul EFS este gandit sa aiba o intensitate scazuta a tranzactiilor de metadata
- clientii EFS nu tranzactioneaza cu controller-ul de metadata pentru fiecare bloc de citire/scriere, ci efectueaza tranzactii periodic
- se utilizeaza blocuri de date media mari care implica in consecinta mai putine blocuri de date si implicit mai putine blocuri de metadata per fisier media
- la fel ca multe alte sisteme de stocare, EFS distribuie datele si paritatea la nivelul nodului de stocare pe toate discurile care formeaza aria RAID, realizand o viteza de N ori mai mare decat vireza unui disc individual (N fiind numarul de discuri din aria RAID a nodului de stocare respectiv), iar contoller-ul hardware al ariei RAID maximizeaza resursele CPU pentru gestionarea spatiului de stocare
- in acelasi timp, EFS distribuie datele in toate nodurile (date efective + paritate)
Toate aceste solutii tehnice asigura o banda garantata si o latenta deterministica a sistemului de stocare EditShare, indiferent de arhitectura sa.
| Cerinta 3. Scalabilitatea sistemului de stocare prin adaugarea de noi noduri de stocare la sistemul existent |
Scalarea sistemului de stocare trebuie sa poata fi efectuata in timpul regimului normal de lucru al sistemului, neafectand functionarea normala a acestuia.
Rezultatul scalarii (prin adaugarea de noi noduri de stocare) trebuie sa duca la marirea performantelor sistemului (pe langa marirea capacitatii de stocare). Aceste conditii sunt indeplinite de catre sistemele de stocare EditShare.
Mai jos este prezentat un exemplu concret de adaugare a unui nod de stocare la un sistem de stocare EditShare existent compus din 3 noduri:
![]() |
![]() |
| Initial, la conectarea noului nod nu exista date stocate pe acesta | Sistemul de fisiere EFS redistribuie datele (existente initial in cele 3 noduri ) in toate cele 4 noduri |
Operatia de redistribuire a datelor se executa intr-un proces care ruleaza in fundal (daca nu s-ar face aceasta redistribuire, atunci datele stocate in noul nod vor genera mai tarziu dispute intre clientii EFS care ar accesa in acelasi timp datele stocate in acesta).
Se poate stabili /limita numarul de resurse alocate operatiei de redistribuire astfel incat sa nu afecteze functionarea normala a nodurilor, ci sa ruleze in fundal si sa nu impacteze performanta nodurilor.
Nota: a nu se confunda redistribuirea cu reconstructia datelor (utilizata la avarierea unui disc dintr-o arie RAID, proces cunoscut si sub denumirea de “Rebuild”).
| Cerinta 4. Sistemul de stocare trebuie sa poata lucra nativ cu majoritatea sistemelor de editare neliniara existente la ora actuala |
EditShare poate lucra nativ cu majoritatea sistemelor de editare neliniara utilizate in prezent (Avid, Adobe Premiere, DaVinci Resolve, FCP X, Edius, Pro Tools si altele) permitand fluxuri de lucru in echipa, astfel ca materialele stocate pe sistemul centralizat de stocare sa poata fi accesate simultan si instantaneu de catre statiile de editare NLE.
In cazul sistemelor EditShare, acest lucru se realizeaza concret prin crearea de spatii media specifice fiecarui tip de sistem NLE in parte, astfel ca acest spatiu media inglobeaza nativ proprieratile si regulile fluxului de lucru specifice editorului NLE respectiv.
| Cerinta 5. Monitorizarea avansata si o analiza in timp real a intregului sistem de stocare |
Prin intermediul aplicatiei integrate numita Guardian se poate monitoriza in timp real telemetria sistemului de stocare EditShare.
Monitorizarea in timp real a parametrilor hardware permite vizualizarea performantelor sub forma grafica putand verifica buna functionare a intregului sistem in intervalul de timp in care se doreste a fi facuta verificarea (cu ore, zile sau saptamani in urma). Astfel se pot identifica varfurile de utilizare ale sistemului si daca in acel interval de timp au fost afectate sau nu performantele globale ale acestuia.
Guardian asigura o intelegere rapida si completa a informatiei rezultate din sistem.
| Cerinta 6. Securizarea fluxurilor de lucru cu sistemul de stocare |
EditShare asigura securizarea fluxurilor de lucru prin alocarea de drepturi granulare pentru fiecare utilizator care acceseaza spatiul de stocare. Cateva exemple: crearea si accesul la spatii media, drepturi de scriere/citire sau numai citire si multe alte drepturi care depind de natura fluxului de lucru.
| Cerinta 7. Intarirea securitatii sistemului de stocare prin auditarea fisierelor |
Utilizand aplicatia Guardian se realizeaza inregistrarea in timp real a tuturor evenimentelor care au survenit in sistem in urma actiunilor utilizatorilor (operatii de citire, scriere, copiere, redenumire, stergere, mount/unmount de volume si spatii partajate). In acest fel se pot idenifica rapid scenariile de utilizare anormala a sistemului si actiuni efectuate de utilizatori care au facut (in mod voit sau nu) operatii nedorite precum stergerea sau redenumirea de fisiere si cand au efectuat aceste operatii.
| Cerinta 8. Abilitatea de a sincroniza mai multe sisteme de stocare aflate in locatii geografice diferite |
In suita aplicatiilor software incluse cu sistemul de stocare EditShare exista aplicatiile Swift Sync si Flex Sync.
Swift Sync realizeaza sincronizarea materialelor stocate intre doua sau mai multe sisteme de stocare locale aflate in locatii geografice diferite.
Flex Sync realizeaza sincronizarea materialelor stocate intre un sistem de stocare local si o alta locatie de stocare aflata in Cloud.
Toate aceste solutii tehnice si tehnologii din sistemele de stocare EditShare asigura cerintele necesare unui sistem de stocare destinat aplicatiilor de productie sau post-productie video cu fluxuri de lucru in echipa sau pentru aplicatii de playout, asigurand o functionare garantata si predictibila in regim de lucru 24/7.
Pe langa aceste aspecte prezentate mai sus care se refera strict la sistemul de stocare, EditShare dispune de sistemul nativ de gestionare a resurselor media (aflate in acest sistem de stocare) care poarta denumirea de Flow.



