tárhely bővítés

Linux-kezdő

Hello,

Adott egy webszerver, ami tegyük fel, hogy /var/www/ helyen van tárolva, viszont úgy néz ki, hogy rohamosan fogy a tárhely a nagy igénybevétel miatt. 

A tervem az, hogy veszek egy nagyobb SSD-t és a mappa helyére felcsatolom. Hogyy tudom ezt abszolválni úgy, hogy minden kiesés nélkül megmaradjon? Valamint a fáljrendszert mire és mivel formázzam?

 

Köszi.

  • 1017 megtekintés

( tibyke | 2023. 09. 26., k – 10:32 )

pl. atsynceled az uj SSD-re (mountra), aztan remountolod oda, a regit meg elotte atnevezed.

( bazso | 2023. 09. 26., k – 10:58 )

Hozzácsapod a vg-hez, megnöveled a vol és a fájlrenszer méretét, örülsz. Reméljük sokáig, mert ugye egy SSD csak egy SSD, gondolom az alap is egyke volt, így concat lesz belőle, bármelyik meghal, az egész megy a lecsóba.

Cserében röptében működik

mert alap esetben egy ilyen megoldás az ördögtől való. :)

És mivel ez egy kezdő fórum, úgy gondolom itt napi felhasználásról lenne szó, és nem speciális esetekről, ahol adott esetben akár még ez lehet az optimális átmeneti megoldás.

A write-only scenarion kívül minden mást gyorsít ha ssd is van, más kérdés, hogy az "átmenetileg rohadt gyorsan kell, és nincs más" use case-en kívül én nem látok más helyzetet, amikor egy raid1-be keverném a hdd-t és ssd-t.

1 db ssd-t lehet read cache-ként használni hdd-k mellett, vagy akár önmagában olyan adatok tárolására, amik átmenetiek, nem fontosak, de kell az iops. hdd mellé tükrözni napi használatra viszont szerintem pazarlás.

Pontosítok, az írási sebesség lesz azonos. Ennek az az oka, mert azt várod a tükörtől, hogy ha az egyik példánnyal gáz van, akkor a másikon ép legyen az utolsó tranzakció, ezért nem maradhat le. Persze ha van battery backup-pal szerelt cache előtte, el tudja fedni rövid burst írásnál a különbséget, de a post alapján ilyet nem feltételezem. Ha bármi más módon cache-elsz és engedsz aszinkron elcsúszást, akkor hirtelen tápelvételkor pont a tükör lényege sérül, kb lutri melyik láb milyen állapotban van, nem is beszélve az akár full elveszett tranzakció(k)ról

( d3xt3r | 2023. 09. 26., k – 20:11 )

egy kérdés volt. 

Jelenleg vegyes, van SSD és HDD is bent, mind más dologra van használva. 

Ha mondjuk a RAID 1-ben menne a dolog akkor gondolom a HDD sebességét érném el maximálisan. Itthon van több szabad merevlemezem de mindegyik sima HDD és lehet akkor nem raid-ben gondolkodok hanem backup-ban és akkor rögtön elég a sebessége. (Gondolom).

Nem mindegy, hogy kiadok érte sok 10 ezret vagy előveszek a fiókból egyet. (Egy olyan projekthez ami teszt fázis alatt van)

Hozzáteszem se nem rendszergazda, se nem tapasztalt webfejlesztő se nem informatikus nem vagyok, csak lelkes amatőr akinek épp van "építve" egy saját szerver ami jelenleg több hasznos funkció mellett ellát teszt fázisban levő dolgokat is amiket (később ha beválik -akkor-) komolyabban meg kell tervezni és kivitelezni.

Az ssd sebessége (iops) akár 3 nagyságrendel is nagyobb lehet mint a hdd.  egy 7200RPM-es sata hdd nagyjából 75 IO műveletet tud másodpercenként,  egy SSD meg akár 75 000-et is.

Kissé pongyola megfogalmazással ugyan, de így működik a raid1:

- Íráskor a tükrözött kötet mindkét tagjára kimegy az io művelet, és addig nem megy ki a következő, míg mind a 2 tag vissza nem igazolta. Ez esetben íráskor a hdd sebességével lesz egyenlő a raid kötet sebessége.

  Sok kis fájl írása esetén, vagy adatbázis műveletkor (8k random io) ez akár 8KB*75= 600kb/sec írási sebesség. Ha mindkét tagod ssd, akkor ez a szám 5-600MB/sec. (ez nyilván csak elméleti érték)

- Olvasáskor alapesetben felváltva olvassa mindkét diszket, így -átlagosan- az ssd teljesítményének felét bukod. A fentebb is említett write-mostly  flag-al az md raid rávehető, hogy ha lehet, csak ssd-ről olvasson, így az olvasási sebesség elvileg az SSD sebességén tud menni. Mondjuk a valóságban nincs olyan környezet, ahol tisztán csak olvas a rendszer, hanem kevert az io, így azért ettől a kapcsolótol sem érdemes csodákat várni.

Átmeneti megoldásnak természetesen használható, amikor muszály a redundanciát gyorsan megoldani (sőt, kimondottan praktikus lehet, ha a kiesett hdd-t SSD-vel pótolja az ember amíg nem tud beszerezni egy hdd-t - mert baromi gyorsan beszinkronizál) hoszabb távon viszont szerintem értelmetlen pénzkidobás.

 

Szerver környezetben, ha már SSD, akkor érdemes kettőt venni, és raid-be rakni. 100-200 GB-s ssd-ket már hulladék áron lehet kapni.
Emellett lehet hdd is a rendszerben, szintén raid-ben. Adatokat IO igény szerint a megfelelő storage-ra pakolni: gyakran használt, nagy írási/olvasási igényű dolgokat (pl. adatbázisok) ssd-re, nagy méretű, ritkbban használt dolgokat (pl. ISO image, archív dolgok stb.) meg hdd-re.

SSD-t akkor érdemes csak tükrözés nélkül használni, ha nem fontos az adat, vagy megfelelően van mentve. Amíg egy hdd sok esetben lassan hal meg, és a teljes adatvesztés előtt még esélyes hogy le tud menteni az ember ezt-at, az ssd gyorsan és látványosan tud elpusztulni, és a legtöbbször kuka az egész, vagy sok pénzért adatmentés.

amit nem teljesen értek: miért tükrözne le gyorsabban egy HDD-t SSD-re a raid, mint egy másik (azonos/hasonló) HDD-re?
fixme, de ilyenkor a limit a forrás olvasási sebessége lesz, ami egy pörgő lemez esetén (szintén fixme, de) azonos annak írási sebességével.

A fentiek mellett (elméletileg) létezik több megoldás arra, hogy az olvasást gyorsítja SSD cache-el (a sűrűn olvasott adatokat oda "gyorstárazza") - valamint létezik hasonló megoldás írásra is: az SSD-t puffernek használva oda betolja az adatokat, majd kiírja lemezre.

olvasási sebessége lesz, ami egy pörgő lemez esetén (szintén fixme, de) azonos annak írási sebességével

hat ha fixme-t kertel akkor mondom: nem lesz ugyanaz a sebessege. jo esetben talalsz olyan disket ahol irasi sebesseg _minden_ korulmenyek kozott azonos, de a gyakorlat inkabb az hogy az iras lassabb, mint az olvasas.

A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

"amit nem teljesen értek: miért tükrözne le gyorsabban egy HDD-t SSD-re a raid, mint egy másik (azonos/hasonló) HDD-re?"

Fentebb is elmondták, hogy az írás sok esetben nagyobb késleltetéssel jár, mint az olvasás. Egyébként nincs rá garancia, hogy íráskor nem kell seek-elni a cél hdd-nek, mivel a tányérok nem szinkronban pörögnek a forrás diszkkel, ami esetleg még eltérő geometriájú is. A storage alrendszerekben többek közt ezért is van saját firmware a diszkeken, amit a kontrollerhez optimalizálnak, hogy a raid kötetben minnél kevesebb idő menjen el el arra, hogy az egyes diszkek össze-vissza seek-elnek.

Másrészt a raid kötet a szinkronizálás alatt is álltalában használatban van (alkalmazások írnak olvasnak), így implementációtol függően az olvasási kéréseket az SSD már szinkronizált része is kiszolgálhatja, így a forrás hdd kevesebbet seek-el, ergo gyorsabb a resync.

( d3xt3r | 2023. 09. 28., cs – 12:52 )

Szerkesztve: 2023. 09. 28., cs – 12:52

ezek után már valóban hétvégén rámegyek és tesztelem. igaz sosem csináltam még RAID-et, de majd most kiderül.