Doresc să partajez date între mai multe instanțe AWS într-o manieră de înaltă performanță, cu latență scăzută.Oferirea tuturor instanțelor de acces numai în citire (cu excepția unei instanțe care ar gestiona scrierile) este în regulă. Două puncte despre acest caz de utilizare:
- Nodurile atașate la volum pot veni și pleca în orice moment (pornire, oprire, terminare etc.).
- Datele partajate includ 1000 de fișiere potențial mici care trebuie listate și să aibă metadatele verificate.
Așa că am încercat inițial EFS, dar este destul de lent pentru operațiunile care trebuie să enumere sau să modifice 100 sau 1000 de fișiere mici.
Așa că acum mă gândesc la EBS multi-attach. Cu toate acestea, pentru a preveni coruperea datelor, AWS recomandă utilizarea numai a unui sistem de fișiere în cluster, cum ar fi GFS2 sau OCFS. Ambele par a fi complexe și complicate de configurat, precum și fragile pentru cazul de utilizare a unui cluster în care nodurile ar putea veni și pleca în orice moment. De exemplu, GFS2 necesită repornirea software-ului cluster pe toate nodurile dacă numărul de noduri trece de la mai mult de 2 la exact 2; sau, adăugarea unui nou nod implică conectarea la un nod curent, rularea unor comenzi și, eventual, redistribuirea unui fișier de configurare actualizat către toate celelalte noduri. Pur și simplu pare cu adevărat inflexibil, precum și o mulțime de cheltuieli suplimentare.
Dar dacă eram sigur că doar o instanță va scrie pe disc (sau, eventual, fiecare instanță ar putea scrie doar în propriul subfolder sau chiar în partiția de disc), aș putea folosi un sistem de fișiere obișnuit precum XFS pentru acest volum și aș putea scăpa de el. ? Sau ar exista probleme subtile de corupție a datelor, chiar dacă din punct de vedere tehnic accesul este doar în citire sau accesul în scriere este limitat la subfolderele sau partițiile specifice instanței?
Sau există o soluție complet diferită care îmi lipsește?
