Linux alatt: HW vagy SW (mdadm) RAID?

Hardver

A kérdés nem arra vonatkozik, hogy mit tettél eddig. Hanem arra, hogy mit tennél, ha ma kellene döntened? Én ​​meggyőzhető vagyok bármiről! :)

Környezet: Legyen a költségvetés maximum nettó 2 millió egy szerverre. Raknál bele HW RAID-et vagy használnál inkább SW megoldást (mdadm)?

Véleményem: Utoljára 10 éve vettem szervert (Dell R310 -  most is ez ketyeg), de bevallom ma már nem biztos, hogy egy HW RAID kártyával kockáztatnék. Ugyanis bármit veszek lazán elketyeg 10 évet, de ha lehal a RAID kártya az extra szívás lenne. Azt gondolom ma már nagyobb a kockázat, mint az előny HW RAID. A mai gépek teljesítményesésén egy SW RAID-et észre sem lehet venni.

HW Raid
29% (190 szavazat)
SW Raid
67% (442 szavazat)
Egyén, leírom.
4% (26 szavazat)
Összes szavazat: 658

( trey | 2021. 12. 10., p – 13:29 )

Milyen kockázatot látsz te itt? 10 éves brand vashoz szerviz úton van HW RAID kártya. Care pack kérdése, mikorra van a kezedben. Ráadásul, emlékeim szerint jobb gyártóknál (HP) az újabb RAID kártyák visszafele kompatibilisek.

trey @ gépház

Hát ha fontos, csak van minden fontos alkatrészből a gép szerviz dobozában +1 darab, ugye? +1 alaplap +1 raid kártya, memória modulok, HDD/SSD... :-)

A kérdésre válaszolva a szoftveres RAID is megoldás lehet.

Pontosabb válasz lehetne, ha leírnád, hogy mi a célja a RAID üzemmódnak, mi fog rá kerülni? (adatbázis, virtuális gép image, adatmentés) HDD vagy SSD? RAID 1? RAID 6? RAID 10? Miért az?

Sakk-matt,
KaTT :)

Visszatértem! A hozzászólásom alatt lévő szavazat gomb nem nyomódik meg magától!

Mivel neked lesz, az egyetlen ahol teljesítmény kellhet neked, az az amikor hírleveleket küldesz ki, mert ugye tudtommal webshopokat üzemeltetsz, ahhoz szokott lenni.

a saját ERP-det te ismered, ha jól írtad meg, nem eszi a gépet, amikor meg árat kell emelni, kivárod. 

Egyedül még ha van valami on-premise google analyitics klón, amit használsz, az eheti meg a gépet. Sok múlik azon, miket futtat az a szegény LAMP.

az meg hogy a saját cégeidnél mekkora kiesés egy sw-raid miatti restart, azt megint te tudod kiszámolni. Nyilván ha másnak nyújtasz szolgáltatásban szervert akkor hw-raid mert megígérjük szerződésben a csillagokat is, de nekem az a tippem, a HUP-os előéletedből megismert saját szolgáltatásokhoz kell, amiket abból láttam eddig, ott lehet annyira nem szükséges.

Sajnos mi ebbe egyszer belefutottunk: bevállaltuk a 4 órás rendelkezésre állást, és kb 1 hónap után elszállt a táp (HP szerver - kicsit több, mint 10 éve volt 1.2M nettó).

Gondoltuk semmi baj, mire odaértek a szerverszobába, és kiszedem a régit, már ott lesz az új.

Végül a 4 órából két hét lett... a CHS-ben vettünk hozzá még aznap tápot, utána lett dual tápos :).

Gondolom a "BEST EFFORT" jellegű hibajavítás kifejezést írtad körbe ezzel.

Ahogy használja ezt a kifejezést a kontár IT szakma, előttem mindig egy cinikus szemkacsintás jelenik meg: amennyi pénzt nekünk szapportra fizetsz kedves multigiganagycég g€cisóher menedzsere, azért cserébe megkapod a világklasszis (vissza kell fognia magát miközben ezt mondja, nehogy elröhögje magát) osztott service desk-et. Azaz vmi angolul talán jól beszélő Kumar valóban felkapja a bejelentésedet szinte 1 percen belül, de hogy ha a tökéletesen  beskatulyázható problémáknál akár csak 1 fokkal is bonyolultabb amit akarsz, akkor level2 vagy L3-n mire értelmes és segítőkész mérnököt kapsz, addigra vagy magától megoldódik a gond, vagy kinő a hajad.

Röviden: a best effort az jelenti, h. LÁTSZÓLAG ugyan foglalkozunk a seggfájásoddal, hiszen ITIL szerint a beérkezett hibajegyre a tiketkezelő automata 1 percen belül küldött ki ACK emailt, azaz SLA-t betartottuk. Gyakorlatilag meg ennyi (kevés) pénzért (amit fizetsz nekünk) leszarjuk a megoldást, és különben is mi a fszt vársz tőlünk ennél többet?!

Na ehhez képest a jog (legalábbis angol nyelvterületen) ezzel  homlokegyenest ellentétesen értelmezi a "best effort" lényegét: effektíve akár pénzügyileg csődbe is vihető a felajánló fél ahhoz, hogy ezáltal teljesítse a tőle elvárható MINDENT IS, hogy a másik fél baját megoldja ezáltal.

Ugye mennyivel másabbul hangzik?

Ezt honnan vetted? :)

1) Az a cég, amit csődbe vihet egy HW hibája, az valamit nagyon rosszul tervezett meg.

2) Elég sok nagymulti NBD garijával találkoztam már, legyen az szerver vagy notebook, és rendre jól teljesítettek, nem ültek semmin. Sőt egy mezei switch cserét is very flottul tudtam intézni a magyar üfszolggal, ahol értelmes és segítőkész magyar emberekkel tudtam egyeztetni. Erre a switchre nincs garancia szint, "csak" cseregari, de még így is ők fizették a futárt, úgy hogy előreküldték a cseréket, nekem pedig a dobozba kellett betenni a rosszat,a futárral matricáztunk, és máris szaladtak vissza hozzájuk.

3) Gondolom ismered az ájtivilág csodáit, és elég nehéz garantált hibaelhárítást adni. Jellemzően nem a diszk cserék az izgalmasak, hanem adott esetben egy teljes vasat nekik raktározni kell abból, amire kérted a garit.

Ahol egy gép van, ott pont ezért nyerő a bérléses és valahol ezzel együtt elhelyezett forma, mert nincs kapacitás vele bénázni. Több (mondjuk 3-4+) szerver esetén lehet már az talán, hogy esetleg saját telephelyen, talán cluster jelleggel menjek és a kopó alkatrészekből legalább 1-1 legyen a polcon, úgy, hogy a vasakra minimum NBD gari van.

Lépj hátrébb 3 lépést: a "best effort" leírása nem konkrétan a diszk-cserélő kkv-ra vonatkozott, hanem úgy az egész IT iparban fellelhető szerződési hozzállásra.

 

Írja le aki találkozott már ilyennel:

ügyfél megkéri XY kft-t, hogy az XY kft-vel futó projectje közben felmerült extra teendőkben is legyen a segítségére, természetesen plusz pénzért. De nem annyival több plusz pénzért, mint amennyiért XY kft-nek megérné minden létező erőforrását bedobni ebbe az extra melóba, és ténylegesen XY kft-nek levezényelni ezt az extra melót egymagában. Az XY kft ezt az extra támogatást "best effort" alapon nyújtja. Beüt a gebasz, XY kft-től várják a megoldást. A "best effort" mekkora erőforrás mozgósítást eredményez XY kft project menedzserének a fejében?

Az automata ACK email ha másra nem is jó, mindenképpen csökkenti a megrendelő oldalán az esélyét annak, hogy egy szerencsétlenebb incidens újra kelljen aktiválni a LinkedIn prémiumot.

Na ehhez képest a jog (legalábbis angol nyelvterületen) ezzel  homlokegyenest ellentétesen értelmezi a "best effort" lényegét: effektíve akár pénzügyileg csődbe is vihető a felajánló fél ahhoz, hogy ezáltal teljesítse a tőle elvárható MINDENT IS, hogy a másik fél baját megoldja ezáltal.

Hiszek neked, de ilyet a büdös életben nem láttam. Elképzelni is nehéz ilyesmit.

van egy nagy raktar amibol minden eladott eszkozbol van +1 hidegtartalek, es ha felhivod oket, jon a mernok, autoba ul, felpakolja, es hozza, igen.

Cisco 9508-ra (ami nem egy egyedul berakom az autoba meretu eszkoz...) kaptunk ilyenre ajanlatot, vagyhat kaptunk volna, de a cisconak nem volt 4 oras korzetben raktara hozzank:)

Node 10 évig? 7-ről tudok a Fujitsunál, mint alkatrész utánpótlás, és 5 év gariról, mint megvehető carepack. Azóta is Fujtisuzunk, bár már újabb vasakkal, nagyon jók. :) Egyébként alapvetően szerverekről szóltam fentebb, nem storage-ről, ami azért spécibb dolog.

Hát, tőlünk anno jelképes áron megvették a DX80-at miután leköltöztünk róla, lehet az volt valahol a szervíz vonal. :) A 12 diszkből már 3 kihalt, relatív gyors egymás utánban, de akkor már nem számított, de egyébként a vezérlők és tápok jók voltak, azokkal sosem volt gond. Ha jól számolom, akkor 6+ éve húzott le, és hát nem pont ideális az a szerverszoba, mert elég poros, és a hűtésnél voltak nehézségeink.

( uid_6201 v | 2021. 12. 10., p – 13:45 )

Hardver RAID kártya ha kell az extrém nagy diszk performancia, de akkor is csak RAM+saját akkus verzió tudja ezt hozni. Ugyanis ekkor saját I/O puffere van, amit PC felöl nem észlelsz csak azt hogy gyors.
Normál esetben szerintem a szoftver RAID Linux alatt rugalmasabb.
 

meg akkor se art, ha nemcsak a raid0/1/10 a kivanalom. raid5/6-nal mar jobb ha a kartya checksumolgat, es nem a cpu eroforrast veszi el (persze ha a cpu csak all, mert nincs feladat akkor jo lehet az sw is)

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

Egy 15 wattos laptop proci (modprobe raid5; dmesg -T):
[p dec 10 14:11:16 2021] raid6: using algorithm avx2x2 gen() 22784 MB/s

Végülis ha lenne benne 10 Gbps tempójú kártya és tolod ezen keresztül a fájlokat ami a csövön kifér, akkor 5%-ot el is fog vinni a CPU-ból a checksumolgatás.
És ez csak egy laptop. :)

Valószínüleg ez az MD5SUM bonyolultságú checksumolgatás ASIC-ből 20 éve volt nagy szám. Ma meg egy 6-8magos desktop cpu is lazán 1% alatti extra terhelés szintjén érzi csak meg. Hasonlóan a FDE (full disk encryption-höz). Ami mellett pedig a SED (self encrypted drive)-ok a nagy lutri: minden hónapban jön hír valamelyik nagy HDD/SSD gyártóról, h. kb a 0x00000000 volt a szuper szekjur kulcs az összes termékükben. Mikroszoft is lekapcsolta a diszk belső hw támogatású eltitkosítását a bitlockerben pár éve.

A másik kulcs az adatpárhuzamosítás. Lásd AVX, amely egyetlen művelete során 8 darab u32 csatornával számol párhuzamosan. Sőt erre rájön még egy OoO utasítás párhuzamosítás és a CPU aritmetikai tempója azonos órajel mellett N*8 (N=2..4) lett mára a régi in-order skalár számításhoz képest.

( okarika | 2021. 12. 10., p – 13:45 )

Hát én nagyot szívtam egy hp szerverrel, a support is csak próbálkozott a megoldással (fw gond volt) napokba telt életre lehelni. Nyilván volt mentés stb, de az hogy ez ennyi energiát elvitt, elvette a kedvünket a hw raid-től. A mdadm megoldás pedig sok-sok éve kiválóan működik rengeteg környezetben, sosem volt gondunk vele. 

Igazából valami rejtelyes ok miatt a disk re írt raid konfig adatok (ne kérdezd pont hol vannak és hogy néznek ki, 10+éve volt) a tömb diszkjei között inkonzisztensek voltak és ezért nem indult el a tömb. Az a baj, hogy régen volt :( 

De mivel úgy gondoltuk, hogy ez nem normális (helló pont ezek az adatok nem redundánsak és hibajavitottak? Hát ez foglalja a legkevesebb helyet) így hagytuk a supportot dolgozni, később ki is jött javításként. Menet közben elpöttyintette a support, hogy bocsi, fw hiba miatt írt a kártya hülyeséget a saját nyilvántartásába. Na persze ezt soha nem láttuk írásban.

Így van. A hardveres RAID-nak akkor volt utoljára értelme, amikor a procik gyengébbek voltak és a disk interface sávszélessége meg szerény. De mára a modern prociknak és modernebb interface-eknek (NVMe SSD-k) olyan nagy teljesítménye van, hogy érdemben nem vesz le a teljesítményből sehol, ha a RAID szoftveres, ráadásul az mdadm már egy mindenki által sok éve tesztelt, kitapasztalt, jól dokumentált megoldás. Így ha mindenképp RAID kell, én annál maradnék, annak ellenére, ha nekem saját szerverem lenne, akkor eleinte kísérleteznék ZFS poollal helyette, állítólag az se egy rossz szoftveres megoldás.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Te tudod. Ha ezt eldöntötted úgy is, nem tudom miért nyitod a topikot. Egyébként meg ha az lenne mérvadó, hogy nagyvállalati rendszerben mit használnak, akkor Windowst kéne használni, egy csomó bloat menedzsment bullshittel.

Egyébként meg nem azt mondom, hogy a hardveres RAID-del valami baj lenne, csak épp az előnyét nem látom sehol. De ha jobban tudod, fejtsd ki, hátha mégis tanulok valamit.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

vSAN, Ceph, S2D, Nutanix, EMC PowerFlex (volt ScaleIO), vagy éppen a zfs. Ugyanez fizikai storage vonalon: Dell/EMC csomó storage terméke, HPE Nimble, Hitachi, NetApp több terméke, meg a fene tudja mik nem (ide lehetne írni egy 20-as listát legalább, de hirtelen ennyi ugrik csak be fejből), mind mind "szoftveres raid". Enterprise storage termékeknél kb. onnét tudhatod, hogy az előadásaikon, brossúrájukban nagyon tolják az "ez már szoftver difájnd" dumát. Ezt kb. úgy kell lefordítani hogy a kontrollerben már x86 alapon Linuxot futtatunk, és szoftveres úton oldjuk meg a redundanciát. De ide sorolhatjuk bármelyik nagyobb cloudszolgáltatót is, náluk sincs nagyon hw raid.

Azt nem állítom, hogy nincs sehol, én is napi szinten dolgozok vele, de a hwraid tényleg éppen a szemünk előtt hal ki, csak ki kell nyitni kicsit jobban :)

És a másik fele? A vsan és az utána felsoroltak sem hwraid-ek, a cloudszolgáltatóknál sem jellemző a hwraid. Tárolóknál meg az asic-ek helyett lesz szép lassan mindenhol software definied megoldás. Persze az ügyfél szemszögből rá lehet mondani, hogy hwraid, de valójában akár egy zfs is dolgozhat rajta (lásd pl. az Oracle tárolóit), max nem tudod, vagy nem érdekel, sőt, nem is kell hogy érdekeljen a legtöbb esetben. Egyébként ezen logika alapján meg minden hwraid :)

Nem értem, ezzel mit akarsz mondani. Pont, hogy "minden hardver RAID" kijelentésig nem tudunk elmenni, mert például az mdadm biztosan nem hardver megoldás. A felhőszolgáltatás (és virtuális gépek) másik absztrakciós szint: egy fizikai szerverre telepített adatbázis motor sem foglalkozik a RAID-del, legfeljebb elvárásai vannak, amit az OS biztosít számára.

Legfeljebb a "minden szofver RAID" kijelentésig tudunk elmenni, legalábbis a látókörömben eddig megjelent megoldások/technológiák kapcsán.

Mondjuk az állítás inkább ott borul meg, hogy nagyvállalati környezetben nem tipikus az egy szerveres felállás, egy tároló netán felhőszolgáltató infrastruktúrája nem a téma indító kérdés súlycsoportja.

De ha vállalati környezetbe szóló szerver kerül (vagy nem VSAN jellegű lemezkezelés), akkor ott jó eséllyel lesz egy RAID vezérlő hardver elem (amiben szintén szoftver van, nyilván szerényebb funkcionalitással, mint egy 2U+ tároló).

( msandor v | 2021. 12. 10., p – 13:46 )

Mindkét megoldást használom, ha a szerverre telepített OS nem ismeri a SW RAID-et, akkor eldőlt a kérdés.

Ha valamilyen Linux lesz a vason, akkor én nem költenék HW RAID kártyára, inkább RAM-ot vennék az árából.

( Nyosigomboc v | 2021. 12. 10., p – 13:56 )

Egyetemen egyik prof. amikor felsorolt 3-4 dolgot, es megkerdezte, hogy "melyik a legjobb", altalaban az "attol fugg" volt a helyes megoldas. Ugye ha valamelyiknek nem lenne valami elonye a tobbihez kepest, akkor nem lett volna ott a 3-4 lehetoseg kozott.

Szoval itt is attol fugg, de ha a a performancia nem annyira kritikus, en is inkabb a SW-t valasztanam. (mondjuk nem vagyok rendszergazda)

A strange game. The only winning move is not to play. How about a nice game of chess?

"de ha a a performancia nem annyira kritikus, en is inkabb a SW-t valasztanam"

A linux kernelbeli sw raid aka "mdraid" minden hw raid kártyát outperformál. Még az enterprise csilivili méregdrága dedikált storage rendszereket is. HW raid indoka valami funkcionalitás lehet: pl. ESX csak azt támogatja, kell a kártyán lévő BBCU mert raid6 -hoz kell az elvi crash-proof jóság, vagy azért, mert nem akrsz linux alatt konfigurálgatni.

jó jó, tudom, "elméleti" a dolog, de néztél már úgy írási sebességet, hogy kikapcsolod a write cache-t a vinyón?
mert hogy a BBU-val rendelkező HW raid kártyák ezzel kezdenek...

Ha kihúzod a gépből az áramot, szerinted melyiken marad meg az az adat ami még nem került lemezre írásra?

( x-daemon | 2021. 12. 10., p – 14:05 )

ha lehet inkabb mdraid, ha nem lehet mert pl. 16 disk kellene akkor hwraid

neked aztan fura humorod van...

( joco01 v | 2021. 12. 10., p – 14:05 )

Mióta van ZFS, semmilyen más RAID nem kellene nekem (de ilyen alapon a SW-hez állok közelebb).

A kicserélem az összes driveot egyesével nagyobbra és nagyobb lesz a hely most is megy.

A "hozzáadok mégegy driveot és nagyobb lesz a hely" verzió az OpenZFS 3.0-ban lesz benne nagy valószínűséggel jövő nyáron. 

 

PS: Most találtam, és szerintem nagyon érdekes: ZFS on Object Store (S3): https://youtu.be/opW9KhjOQ3Q

( uid_2030 | 2021. 12. 10., p – 14:17 )

Komolyabb gyártók (pl. High Point) cuccai visszafelé kompatibilisek. Lehal, kidobod, berakod az újat, felhúzza a konfigot és megy tovább...

( Zsugabubus | 2021. 12. 10., p – 14:18 )

Hot-swap az jobban működik és egyszerűbb HW RAID-del (ha villog a piros, cseréld ki).

Intelnek van újabban hibrid megoldása, megoldja a hot-swap témát, valamint a RAID tömbről bootolást (VROC), miközben mdraidet használ, igaz, csak NVMe SSD-nél.

Lehet felrertettem a kerdest.

Ha a VROC licenced megvan akkor az mdraid nem software raidet csinal hanem Intel VMD RAID-et, tehat a workloadot is a VMD controller viszi. 
 

Szerk: mar nem emlekszem minden reszletre, reszletesen:

https://www.intel.com/content/www/us/en/support/articles/000024550/memo…

https://www.intel.com/content/dam/support/us/en/documents/memory-and-st…

Szerintem nincs olyan, hogy "VMD controller", sima software RAID az, csak bootolható a tömb, meg a a hotswap kényelmesebb.

A sok BS mellett ott van a FAQ-ban:

"HBAs do have on-card silicon to perform RAID calculations, so typically they use fewer CPU cores. However, from a system perspective, Intel Xeon Scalable processors are efficient CPUs and RAID calculations with VROC typically use a small fraction of the total cores available. Additionally, it is important to look at the work those cores are doing while being utilized, such as IOPS/CPU utilization."

A teljesitmeny kulonbseg erdekel. Gondolom azt fogod mondani, hogy nincs az standard modu mdadm-hoz kepest semmi.

En meg visszakerdezek, hogy tudod, vagy sejted? Az elobbire keresek bizonyitekot meres formajaban, de semmit nem talalok.

 

A sejtesem miatt egyebkent epp azert, mert nincs ertelme merni, a ketto ugyanaz pepitaban.

( turul16 v | 2021. 12. 10., p – 14:34 )

HW raid akkor ha van flash vagy battery backed cachet tud, egybekent nem sok haszna.

Egyebkent meg attol fugg, mit csinal a masina..

 

Amit nem lehet megirni assemblyben, azt nem lehet megirni.

segits nekem, erre hol kéne rábeszélni? mert nekem nem "hajta ki" mindegyik lemezt by default.

1 lemezről olvasva:
dd if=/dev/sda2 of=/dev/null bs=1M count=4096
4294967296 bytes (4.3 GB) copied, 34.2882 s, 125 MB/s

mdraid(1)ről olvasva:
dd if=/dev/md1 of=/dev/null bs=1M count=8192
8589934592 bytes (8.6 GB) copied, 76.6966 s, 112 MB/s

közben néztem, iostat szerint tényleg olvasott mindkét lemezről egyszerre - de ~60MB/s körüli sebességgel...

Eközben HP SA esetén nekem mindíg összeadódtak az olvasási sebességek...

mdadm -t LVM-el szokás használni,
pl.: 10TB nálam 6db diszkből van ami 3db raid1 (2db diszk ), ezek vanak felfűzve LVM-be, azon van létrehozva a fájlrendszer.

LVM "linear vs striped"
A linear esetében van az amit írsz, át kell kapcsolni, akkor egyszerre fogja használni a tömböket/diszkeket.
$> lvs --segments
root@proxmox2:~# lvs --segments
  LV   VG     Attr       #Str Type    SSize
  NAS  NetApp -wi-ao----    3 striped 10.92t

Nem rosszabb, csak vannak bizonyos esetek amikor ez probléma.

Példa:
Bővíteni akarod mondjuk az egyik "ext4 partíció méretét", akkor a te esetedben mdadm-tömböt kell bővítened nagyobb diszkekkel, ellenben az LVM esetében csak LV-t kiterjeszted az adott tömbre ( bővíted ), majd a VG-t megnöveled és ext4 partíciót kiterjeszted és készen vagy.

gyors teszt (4 diszk, RAID5):

# dd if=/dev/sda of=/dev/null bs=1M count=4096  
4096+0 beolvasott rekord
4096+0 kiírt rekord
4294967296 bájt (4,3 GB) másolva, 38,0692 mp, 113 MB/s

# dd if=/dev/md5 of=/dev/null bs=1M count=4096
4096+0 beolvasott rekord
4096+0 kiírt rekord
4294967296 bájt (4,3 GB) másolva, 19,4068 mp, 221 MB/s
 

Pontosabb lenne, ha minden daemont leállítanék, ami a diszket piszkálja...

Na jó, leállítottam mindent, ennyit változott:

# dd if=/dev/sda of=/dev/null bs=1M count=4096    
4096+0 beolvasott rekord
4096+0 kiírt rekord
4294967296 bájt (4,3 GB) másolva, 22,8932 mp, 188 MB/s

# dd if=/dev/md5 of=/dev/null bs=1M count=4096    
4096+0 beolvasott rekord
4096+0 kiírt rekord
4294967296 bájt (4,3 GB) másolva, 8,39011 mp, 512 MB/s
 

"wpeople"-nek igaza van mdadm RAID1 esetében:
-"egyszálon" olvasásnál lassabb a sebesség mint RAID0-ban,
-"többszálon" olvasásnál hozza csak RAID0 körüli sebességét,

Van rá megoldás "RAID10f2" (layout=f2) -nek hívják, tehát RAID10 hoz létre 2db diszkel, ehhez szét kell szedni a RAID1 tömböt és nulláról indulni:

A 2-disk RAID10 is useful for one, and only one, kind of access: single-threaded, sequential, large-block IO read requests. In that specific scenario, it behave similarly to a RAID0 setup.

EDIT*

  • túl kicsi a read-ahead kernelben a HW raidhoz képest ( blockdev --setra ... /dev/md1)
  • nem azonos PCI-SATA-útvonalat hasonlítasz össze (vagyis egyik esetben valahol a hardverben van szűk)
  • különösen szerencsétlen kerneled van, és különösen szerencsés HW kártyád
  • a raid partíción van, és annak igazítása nem túl szerencsés
  • különbözők a diszkek geometriái és fordulatszámai

Próbálkozz:

for BS in 1 2 4 8 ; do
   dd .... bs=${BS}M
done

Vagy próbálkozz egyszerre több párhuzamos olvasással.

Általában el lehet érni a diszkek nyers sebességét a raid-nál. Nézd meg a hw szűk keresztmetszetet:

dd if=/dev/sda of=/dev/null bs=1M &
dd if=/dev/sdb of=/dev/null bs=1M &

Ha így lassabb az sda olvasása, mint magában, akkor van valami HW szűk dolog, vagy az adatok mozgatásánál, vagy az interruptok szállításánál.

ééés.. ne olvass ilyen pici adatot teljesítménytesztre. Egy teljesítményteszt tartson percekig.

( mauzi v | 2021. 12. 10., p – 16:01 )

Szerencsére több enterprise terméknél kizárólag a HW RAID támogatott, így fel sem merül a SW RAID-del való buherálás :)

( _ventura_ v | 2021. 12. 10., p – 16:07 )

Amennyiben az alkalmazás nem kéri nem eröltetem. Viszont van olyan hypervisor ami hw raidet szereti, szóval oda azt.

Fedora 42, Thinkpad x280

( pirate | 2021. 12. 10., p – 18:02 )

Ha a szerver le lesz cserelve miutan lejar a tamogatasa akkor HW RAID, ha nem akkor SW RAID.

"Már nem csak tehetségekből, de a hülyékből is kifogytunk..."

( hory v | 2021. 12. 10., p – 21:09 )

RAID jelentosege ma mar nem olyan nagy. Alapvetoen nem csak diszk tud meghalni egy gepben. Clustert kell futtatni, sima olcso, raid nelkuli node-okkal. Ha valamelyik meghal, kidobjak a clusterbol es megy tovabb az elet.

Plane kubernetes/docker koraban, ujrahuzni se kell, csak az alaprendszert, a tobbit a kubernetes/docker megcsinalja.

És az adat, ami a RAID nélküli meghalt node-on volt, az honnan kerül elő?

Ja hogy mégiscsak kell valami redundás storage ahova pakoljuk az adatokat. Nyilván lehet a RAID nélküli node-okból redundáns storage-et építeni, mint pl. a Longhorn (https://rancher.com/products/longhorn), de sokkal komplexebb üzemeltetni, mint ami megtérülne a kérdezőnek. (1 db szerver + akár több offsite backup, relatíve kevés adattal)

> Ja hogy mégiscsak kell valami redundás storage ahova pakoljuk az adatokat.

De azt nem biztos, hogy meregdraga szervervinyora kell tenni. Lehet, hogy egy halozati NAS is eleg backupnak.

En most nem olcsojanososkodni akarok, de megiscsak egy 10 eves szerver szolgalja ki a terhelest. Innen nezve megvan a felso korlat.

Egy szerver ssd nem olcso dolog, a 2MFt-os keretbol maris elvitt 600kHUF-ot, es ez csak 3x1.9TB, ami raid-5-ben szuk 4TB.

(pl: https://www.bluechip.hu/termek/intel-d3-s4510-1-9tb)

En most vettem konzumer 4TB-os ssd-t 110khuf/db-ert (samsung QVO 4TB) NAS-ba.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Szep a mongodb, a ceph, a longhorn, a glusterfs stb. Csak birjad a megfelelo eroforrasokkal.

A raid-et arra talaltak ki, hogy egy szamitogepes rendszernek a legserulekenyebb reszere, az adattarolasra ad nagy megbizhatosagu megoldast. Ez a topic errol szol.

Egy cluster az adattarolas mellett meg sokminden mas service-nek a megbizhatosagaval is foglalkozik. Raadasul ugy, hogy az adattarolas megbizhatosaga meg akar csokkenhet is ahhoz kepest, mintha a gepen belul oldod meg a redundanciat.

Ez igy kb. 3 darab hamis allitas.

Mongodb pont, hogy nem hasznal kulonosebb eroforrast, jobbat mondok, a training alatt direkt a sajat laptopodon kell inditanod egy cluster-t 9 mongodb instance-el.

A raid semmire se jo a kubernetes koraban. NEM a szamitogep legsebezhetobb resze, mert az adatod termeszetesen nem egy helyen tarolod.

Az adattarolas megbizhatosaga pont attol csokken, hogy SPOF-t csinalsz egy geppel. Memoriahiba, controller-hiba, kernel-hiba, es bamm, ennyi volt, mehetsz backup tape-t vadaszni es bekesziteni a kavet ejszakara. Ugyanez egy mongo clusterben 1 masodperces fennakadas, amig uj master-t valasztanak, vagy meg az se, ha slave esett ki.

Nincs cluster. Felthetőleg egy db, feltehetően egy monolitikus, régi php-s megoldás van egy db gépen, esetleg funkció szerint szétválasztva

Van viszont pl. relációs db, megintcsak feltehetőéeg. Nem értem, miért jössz a mongodb-vel, meg barki miért jön a hasonló clusterezési megoldásokkal. Totál másik dimenzió. Más a scope.

( khiraly | 2021. 12. 10., p – 21:21 )

Nem tudom melyik egyénre gondol a kolto, de leirom en is:

Ugye egy 10 eves gep elviszi a terhelest. Ezt cserelne a kerdezo egy mostani gepre. Teljesen tokeletesen mindegy milyen raid.

Ugy nezem 3 db raspberry pi 4-es tudja azt a teljesitmenyt, amit anno az a dell 310-es.

dell 310:

 memoria: 1-24GB (6db slot),

 cpu: xeon x3400-as sorozat,

itt egy benchmark:

https://www.cpubenchmark.net/compare/Intel-Xeon-X3430-vs-BCM2711/1287vs…

 

Felig vicc, de nem teljesen.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Jelenlegi proci plusz az új versenyzők r340,r350:
https://www.cpubenchmark.net/compare/Intel-Xeon-X3450-vs-Intel-Xeon-E-2…

Nem igazán motivál a  cserére. Az újabb gépekben 1 proci van az enyémben még 2. A LAMP miatt az egyszálas teljesítmény számít. 

Mondjuk most senki nincs rajta, de munka közben sincs széthajtva.

:free -h
              total        used        free      shared  buff/cache   available
Mem:          7,8Gi       2,3Gi       293Mi        50Mi       5,2Gi       5,1Gi
Swap:          22Gi       138Mi        22Gi

:uptime 
 21:57:47 up xxx days,  2:54,  xx user,  load average: 0,23, 0,16, 0,06

Inkabb legyel zold. A tied 200-350W kozott eszik 0-24. Oldd meg 50W-bol.

Ezzel mented meg a vilagot a pusztulastol, a maradekkal meg toltsd a Tesladat:)

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Az X3450 -es cpuval se esznek annyit emlékeim szerint, olyan 80-100W körül egy C2Q elment szépen, pláne ha nem volt load. A másik pedig, hogy éppen azzal zöld, hogy nem fejleszt hanyatthomlok, és nem generál ehulladékot.

Szerk: Az X3450 már Core i7 alapú, azok pláne nem fogyasztottak sokat.

( kris | 2021. 12. 10., p – 23:54 )

Ledobom a nukleáris opciót... szerintem érdemes megfontolni a cloud-ba tenni (ha nem vagy teljesen helyhez kötve). Ha aláírod egy évre (vagy többre) előre, akkor már egészen jó árak vannak. Persze a RAID-del való senyvedés helyett kapsz mást :) de ki tudja. Én ma már csak különleges esetben vennék saját/dedikált szervert.

Ezt biztos nem. Már csak jogbiztonság miatt sem. Valamint nekem nem az átlagos terhelés + pár százalék kell fixen, hanem szolgáljon ki azonnal és pihenhet a következő kérésig.

ps.: ilyen kis összegeket mi egyben fizetünk alapból 1 évet előre. Olcsóbb, mint genyázni a számlákkal.

10 éve én is ezt mondtam volna, ma már nem feltétlenül ragaszkodnék a fizikai vashoz vagy akár eleve a saját üzemeltetésű DB, email, stb-hez. Pont a "mi van, ha lerohad a vas" kérdésköre miatt. Persze, ha valami jogi oka van az más. (Egyébként kifefjted, hogy mi?)

Ha jól sejtem az átlagos terhelést, kb. egy mobiltelefon kiszolgálja, aztán néha van valami komolyabb kérés az ERP-ben, mikor valami nagyobb kimutatás kell.

Pár szolgáltatót már kirántott az élet alólam. Volt aki csődbe ment és lefoglalták az összes szervert, alig bírtam kihozni a sajátom. Ezzel a szerverrel már a Doclernél vagyok.  (Vele vagyok kb hasonló cipőben. Ismerem hazai basztatás formáit és meg van a megfelelő jogi védelmem ellene,)

Az én cuccom egy felhős cégnél legyen havi 50-100 dollár értékű semmiség. Pont leszarják mi van vele. Ha jönne egy laza megkeresés, akkor simán törölnék miután kiadták az image-t. Értsd: nem számítasz. Nemrég töröltek a yt-ről is, amiről később kiderült, hogy alaptalan (vélelmezett jogsértés), de  a useremet már nem adják vissza. Ezek után azt mondom, hülye aki ilyen cégekre bízza az életét. Én nem akarok egy értéktelen image fájl lenni másnak a tulajdonán. Amit összeraktam az több száz millát termel nekem évente. Nem akarom magamat öncenzúrázni a szolgáltató érzelmei szerint.

Aki ezt a kiszolgáltatottságot nem érti, annak hiába magyarázom. A felhőhöz kell egyfajta naivság, ami nekem nincs meg. Hinni kell a nagyfelhőben és abban, hogy tényleg fontos vagy a szolgáltatónak. nem vagy az, csak a hívásod az. :)

Érdemes elolvasni: https://hup.hu/comment/2709332#comment-2709332
Ügyvédi megkeresés alapján? Normálisak ezek? Ha a versenytársam náluk van, akkor felszólíttatom az ügyvédemmel erre majd ők lezúzzák a szerverről? Jézusom! Mekkora csicskafasznak kell ehhez lenni! Legalább egy első fokot megvárhatnának. kell ennél lazább hack az ellenség ellen? Elég ha fasz a szolgáltatója és full legálisan lelövöm.

Persze értem én a modernség és az elméleti technológiai előnyöket, de azok eltörpülnek e probléma felett.

Olyan hibrid megoldásban nem gondolkoztál, hogy van fizikai hw és van felhő is? Az egyik a hw spare-t oldja meg, a másik meg véd a felhős kitettség ellen. Cserébe dupla költség...viszont a felhők közti migráció is könnyebb talán.

"The only valid measurement of code quality: WTFs/min"

Nemrég töröltek a yt-ről is

Na, azért egy CSP meg egy Youtube nem egészen ugyanaz a kategória.

Nem akarom magamat öncenzúrázni a szolgáltató érzelmei szerint.

Ugyanúgy lehúzhatják a fizikai vasat is a netről, villanyról. Az ellen nem véd. Ha nem nálad van a vas, akkor végképp kevés különbség van. Vannak dolgok vagy körülmények, amikor én sem tennék cloudba dolgokat.* Viszont egyre inkább látom értelmét annak, hogy kicsiben miért nem éri meg kifizetni a pénzt a vasra és az üzemeltetésre (tudom, magad csinálod), főleg, ha van egy normális deployment folyamat. Kvázi, akár automatikusan át lehet állni másik cloud providerre is.

Nyilván értem én, hogy kockázat, de ugyanúgy a vas is az, valamint az idő, amit az üzemeltetéssel töltesz. Gondolom majd úgy is kimatekolod, hogy hogy éri meg neked.

* (pl. előző munkahelyemnél lévő dolgoknál továbbra sem változtatnék a telephelyeken lévő dolgokon, ellenben a webszervert ma már cloudra cserélném, sokkal jobban lehetett volna méretezni a terheléshez. Illetve már akkor is volt olyan terv, hogy bizonyos dolgokat kitettünk volna cloudba, jellemzően burst jellegű terhelést okozó dolgok, csak időközben váltottam munkahelyet aztán nem tudom, hogy lett-e a projektből valami. Mondjuk mostani munkahelyemen pont van ilyen is, amikor burst jellegűen kell akár 8-10 órára +10-20 16 magos gép, változó, hogy havonta mennyiszer, de még mindig sokkal-sokkal olcsóbban jövünk ki, mintha vettünk volna fél racknyi gépet és azt üzemeltetnék folyamatosan).

Apropó, hozzáteszem, sok szolgáltatásból eleve nem sajátot üzemeltetünk, hanem, mint szolgáltatás vesszük (pl. managed PostgreSQL, SQL Server, storage, stb. akármi. )

( andrej_ v | 2021. 12. 11., szo – 01:00 )

A helyzet, hogy szervere és felhasználása válogatja. Ha olyan vasat veszel, amiben integrált és mondjuk remek hardware raid van, mondjuk HP DL360/380, akkor nem kérdés, hogy hw raid. Ha egy belépő szintű Xeon, mondjuk E-23xx, akkor lehet, hogy néhány datacenter SSD-vel jobban jársz egy Linux sw raiddel. Könnyű eleve tele venni a gépet, és van bőven SATA port az alaplapokon.

Egy új gépnél nem biztos, hogy a nyers CPU lesz neked érezhető, hanem az egész rendszer késleltetése sokkal jobb. Az sem biztos, hogy újat vennék, és lehet, hogy inkább egy DL360 g9 Enterspájz szerverre lőnék. A CPU órajel nem olyan, mint egy single socketnél, viszont jóval több lehet belőle. Menedzsment szinten pedig más szint, és pláne dupla tápos.

Ha single socket, akkor ezt a CPU-t nézd meg: https://ark.intel.com/content/www/us/en/ark/products/212261/intel-xeon-…

( uid_16313 | 2021. 12. 11., szo – 09:07 )

A világ a szoftver felé halad egyre jobban, ha tetszik, ha nem.

( bognarattila | 2021. 12. 11., szo – 09:49 )

Szerkesztve: 2021. 12. 11., szo – 09:51

Néhány kivételtől eltekintve én nem telepítenék Linuxot fizikai vasra, hanem ESXi-t, innentől kezdve csakis a hardver RAID kerül szóba.

Nem érdekes izé a softraid, mert van speciálisabb eset, ahol az van, sokkal inkább az a véleményem, hogy nem értem, miért nem virtualizál valaki 2021-ben. Mindig van legalább 1-2 mellékes VM, ami hasznos lenne, virtualizálás esetén ennek semmi akadálya, egyébként pedig foghúzás. Persze sok szolgáltatást be lehet szuszakolni főleg egy Linuxba, de én inkább a szolgáltatás elkülönítés híve vagyok.

VMware alatt mdraid adattár: az ilyen SPOF tároló vagy tákolt tároló (drbd)? Ha SPOF  tároló, akkor az duplán kockázatos, tényleg minden vagy semmi kategória.

vSAN: műszakilag valóban softraid kategória, de anyagilag pont nem spórolásról szól :-)

VMware alatt mdraid adattár: az ilyen SPOF tároló vagy tákolt tároló (drbd)? Ha SPOF  tároló, akkor az duplán kockázatos, tényleg minden vagy semmi kategória.

Történelmi okokból megtartott, saját magam által épített iSCSI storage-ok. Speciális adatmozgatásokkor használom kizárólag. Pl. van két vCenter, amelyeknek hostjai nem látják egymás datastore-jait. Ilyenkor a kettő vCenter közt ezek a storage-ok az iSCSI összekötők a Storage vMotion idején. Kényelmesebb mint SCP-zni.

vSAN: műszakilag valóban softraid kategória, de anyagilag pont nem spórolásról szól :-)

Az adatbiztonság sosem a spórolásról szólt :D

trey @ gépház

( uid_4263 v | 2021. 12. 11., szo – 10:50 )

Szerkesztve: 2021. 12. 11., szo – 10:53

Én jelen tudásom szerint azt mondanám hogy dobd az összes onprem infrát és költözz a cloudba. Elég jó megoldás van mindenre is. Feltételezem hogy a kis vegyianyagos cégedet szolgálja ki, és nem vagy IT szolgáltató. Úgy érzem időben meg pénzben is veszteséges az egész. Hacsak nem szeretsz magad szórakozására IT megoldásokat kalapálni. Szóval én nem azon gondolkoznék a helyedben hogy hw vagy sw raid legyen, hanem hogy hogyan diverzifikáljam a cloud szolgáltatásaimat, meg hogyan titkositsam le az adataimat, meg hogyan archiváljam, meg hogyan legyen offsite mentésem, stb stb. Szolgáltatásokban kéne gondolkozni, nem vasakban.

Ez a válaszom, nekem is. nettó 2M ft méretben erőforrást bérlünk, nem szervert veszünk. (Ugyanis a (cpu+mem+diszk)/ár aránynak olyan 7M ft értékben kezd minimuma lenni, a 2M ft értékben még nagyon gazdaságtalan.

Ha azonban valami jogi, biztonsági, mobilitási vagy emberi okokból muszáj saját szerver, és van rá ember, Akkor sw raid. Több pénzed marad másra, pl. egy raid kártya árából lehet venni egy külső USB diszket, amire hetente lehet mentést kirakni. Az hasznosabb.

Mármint arra gondolsz, hogy legyen egy stabil RAID megoldás, legyen valamilyen minimum napi szintű egyéb eszköz amire ment (ha teheti mondjuk az épület tulsó felén), és egyébként nem árt, hogy ha 2-3 USB diszkre kiírja a számára fontos adatokat mondjuk hetente, és azt akár vmi fizikailag más helyen lenne jó tárolni. Nem maga a vas lesz a problémás pótlásban, hanem adat maga.

A saját mentés akkor is kell, hogy ha bérel bármit bárhol az illető. Maga a bérlés tényleg jó lehet egyébként, de látod, hogy jogi és tapasztalati kérdések miatt inkább sajátvas jellegű az igény.

( asm v | 2021. 12. 11., szo – 12:04 )

Szerkesztve: 2021. 12. 11., szo – 12:05

mdraid eseten megoldhato konnyeden, hogy ha a bootolasra hasznalt disk (mondjuk sda) esik ki, akkor reboot utan a masodik diskrol (mondjuk sdb) bootoljunk barmifele hack nelkul?

Regen ehhez a /boot particiojat kellett at-dd-zni sda-rol sdb-re minden valtozas utan (tipikusan kernel frissites), ami maceras lehet es hajlamos elfelejteni az ember. Vagy azota mar a /boot is lehet RAID1? Vagy mar kulon boot particiora sincs szukseg?

mar regota a boot is raid1-en van. regen a masodik disk mbr-be kellett kulon beleiratni a grub-ot, mert az installer elfelejtette (root hd1, setup hd1,0). gondolom ezt azota javitottak.

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

Megoldható, amikor a mdadm tömböt létrehozod akkor "--metadata 1.0" -kapcsolóval kell létrehozni ( ez az csinálja hogy nem a diszkek elejére írja a metadatokat hanem a végére ), továbbá az összes diszk elejébe ( MBR ) bele kell rakni GRUB-t, ezek után a boot partíció( initrd, linux fájlok ) már lehet mdadm tömbön, mert a GRUB be tudja olvasni utána.

Példa:
2 lemezes raid1 esetén

parted -s /dev/sda mklabel msdos
parted -s /dev/sda mkpart primary 0% 5G
parted -s /dev/sda mkpart primary 5G 100%

parted -s /dev/sdb mklabel msdos
parted -s /dev/sdb mkpart primary 0% 5G
parted -s /dev/sdb mkpart primary 5G 100%


mdadm --create /dev/md101 --name="BOOTFS" --assume-clean --verbose --metadata 1.0 --level=1 --raid-devices=2 /dev/sda1 /dev/sdb1
mdadm --create /dev/md102 --name="ROOTFS" --assume-clean --verbose --metadata 1.0 --level=1 --raid-devices=2 /dev/sda2 /dev/sdb2

mkfs.ext2 /dev/md101 -L bootfs
mkfs.ext4 /dev/md102 -L rootfs -E lazy_itable_init=0,lazy_journal_init=0


mount /dev/md101 /boot
grub-install --boot-directory=/boot/ /dev/sda
grub-install --boot-directory=/boot/ /dev/sdb

"xxxxxxxxxxxxxxxxxxxx" -> /dev/md101 UUID-je

grub.cfg ( ezt inkább generáltasd )
----------------------------------------
insmod part_msdos
insmod diskfilter
insmod mdraid1x
insmod ext2

set root='mduuid/xxxxxxxxxxxxxxxxxxxx'
    ...
    ...
    ...

----------------------------------------

Biztosan meg lehet csinálni, elvileg az LVM-et is kezeli a grub, csak nekem elsőre nem akart menni így. Ezért inkább csináltam a /boot-nak egy külön partíciót, ezt gond nélkül megette. Mondjuk RAID1 esetén illik is neki...

Az EFI system partition LVM-en tuti nem lehet, de RAID-en talán még lehetne az is.

( r3flow | 2021. 12. 11., szo – 21:28 )

Van már olyan HW RAID ami "véd" a diszken megsérült bitek ellen?

kb. 1,5 éve jártam úgy, hogy 2x4 TB SATA mdraid tükör tömbön amin teszt pgsql volt, olyan hibaüzeneteket kezdett dobálni a pgsql amiket még sosem láttam: sérültek az adatok egyes lapokon. Az egyik HDD adott vissza szemetet néhány szektor esetén amiket az mdraid szépen tükrözött is. Az mdraid a türkörben lévő szektorok tartalmának eltérése esetén pénzfeldobással dönti el, hogy a két szektor közül melyiket tükrözi vissza. Itt most nem jól sikerült a pénzfeldobás. Azóta új telepítéseken ha arra sqldb kerül akkor integrity-t használok SW RAID alatt, nem érdekel hogy emiatt csökken az I/O teljesítmény.

Persze hogy kicsik, hiszen adatsűrűség folyamatosan nő, tehát a redundanciabitek is nagyon kicsik lesznek :)

Ettől még az ECC-nek ki kell szórnia a hibás szektorokat. Természetesen van az a hibamennyiség, ami átcsúszhat észrevétlenül, de csak elvi lehetőségként.

Persze ilyen hiba simán előfordulhat, de én sokkal inkább gyanakodnék rossz firmware-re vagy drive elektronika problémára, mint adathordozó hibára ami észrevétlenül átcsúszik.

Itt van, hogy 4Kn szektorszervezésnél (kb minden modern hdd 1TB méret felett) mennyi bit jut hibajavításra:

https://upload.wikimedia.org/wikipedia/commons/thumb/a/ae/Advanced_form…

The 4K format provides enough space to expand the ECC field from 50 to 100 bytes to accommodate new ECC algorithms. The enhanced ECC coverage improves the ability to detect and correct processed data errors beyond the 50-byte defect length associated with the 512-byte sector legacy format.

Van olyan raid, persze. Csak drága. Olyan is van, ami felismeri az oracle adatfile belső blockjában a belső checksumot, és ha az hibás, akkor nem engedi lettenni a blockot: ezzel véd az adatkábel zaj és a memória szemetelése ellen is. Ja, ez is elég drága. az ilyen trükkök 20M Ft felett kezdődnek.

( egeresz | 2021. 12. 12., v – 00:40 )

Úgy nagyjából 4 évig olyan vasakat rendelek/konfigurálok, amikben linux sw raid van. (valmelyik) Aztán nagyon elegem lesz a linux sw raid apró bosszantásaiból, és akkor rendelek/konigurálok egy HW raid kártyát. Amit fél éven belül nagyon megbánok, és visszatérek a linux sw raidra. Mindennel mindent meg lehet oldani, csak én preferálom azt a szoftvert, amihez van forrás.

Ez így ment 15 évig, mittomén 40 konfigurált/üzemeltetet rendszerig, de mostanában (5 éve?) már csak nagyobb rendszereket konfigurálok, ahol bejátszik egy dedikált "enterprse" storage.

Íme a döntési fám:

  • Mi a megbízhatósági igény?  AS-IS, vagy 7/24 99.99%
  • Mi az adat mennyisége és az IO teljesítmény igény? 20TB , 200TB, 2PiB;  1k IO/s, 10k IO/s, 1M IO/s
  • Mi a párhuzamossági igény? 1 szolgáltatás, 10 szolgáltatás, 100 szolgáltatás
  • Ki fogja üzemeltetni? helyi hozzáértő, vagy senki, vagy nekem kell?

Ha AS-IS ÉS <10k IO/s ÉS helyi hozzáértő => linux sw raid box

Minden más esetben enterprise dedikált diszkalrendszer.

Ha 20TiB ÉS <10 szolgáltatás, akkor raid6 vagy azzal egyenértékű (DDP)

Minden más esetben olyan megoldás, ami képes egyszerre 3 diszk meghibásodását is túlélni.

A konkrét javaslat konkrétan függ a teljesítményigénytől és a párhuzamossági igénytől.

 

A T. ügyfél néha nem fogadja el a javaslatomat ("túl drága") ebben az esetben megoldja nélkülem. Nem adom nevemet egy adatvesztéshez.

 

Otthonra raidet? Minek? Mentsél rendszeresen. A raid "az" ellen úgyse' véd.

Veszel a kisválalkozásodnak egy kisszervert? Minek? bérelj erőforrást, 1000 szolgáltató van. Hagyd az adatbiztonságot a szolgáltatóra.

Közepes vállalkozásod van? Húzz fel egy pár egyforma gépes virtualizációs poolt, és legyen 1 darab "enterprise" storage. (30M huf)

Éppen szeretnél 10PB adatot és 3M IO/s sebességet? Bármely gyártó szívesen segít személyes tanácsadással :-)

"Hagyd az adatbiztonságot a szolgáltatóra." - Ez nagyon nem így megy, és nagyon sokan beleesnek. Senki másra nem tudod az adataid biztonságát bízni, és nem is vállal senki érte felelősséget. Hogyan, meg miez a gondolat úgy egyébként? Kifizetsz mondjuk évi 10k-t egy webhostingért, és ha elvész a millió forintos valami, akkor fizessenek (mondjuk már kipörgött a backupból)? Ha fizetsz mondjuk 200k-t néhány fizikai gépért, meg egy kis backupért, akkor neked kell a backupot konfigolni, de ha üzemeltetnek még az erőforrás bérlet mellé, akkor sem fognak adatért felelősséget vállalni, egyszerűen akkora értéket tud képviselni, hogy képtelenség.

Végül valaki lesz, akin megpróbálható valahogy leverni a dolgot, csak akár alkalmazott, akár egy cég, az nem lesz már örömteli sehogy sem, ha oda jut a helyzet. Ehhez kapcsolódik, amikor 4-5-6 éves dolgokat keresgélnek egy külső szolgáltatón, hogy hát egy ilyenolyan emailről akkor kéne a mentés, mert hát hirtelen nagyon fontos lett. Aha igen. :)

Otthonra simán megéri a RAID, mert izgalom nélkül tudsz rossz diszket cserélni. Ha úgy tetszik szabadidőt veszel, hiszen nem biztos, hogy otthon épp a visszaállítással szeretnél bajlódni.

Ok.

"hagyd a layer1 adatbiztonságot a szolgáltatóra" -> ne te konfigurálj raidet.

Az adattulajdonos felelőssége az adatbiztonságon gondolkodni, ebben egyetértek. A méret és a volumen a kérdés. Ha  ő olyan storage szaki, hogy képes évtizedekig adatvesztés és leállás nélkül üzemeltetni egy storage alrendszert, akkor mit keres egy 2M ft gép mellett? Ha pedig nem képes, akkor hagyja azt másra. Oks, teli vagyunk olyan szolgátatóval, ahol szintén hiányzik egy megbízható SRE. De ez még nem jelenti azt, hogy amit valaki egyszemélyben magának összerak, az jó.  A felelős javaslat az, hogy kis méretben hagyja ezt másra. Ha egyébként megteheti, hogy másra hagyja, Oregon nem fogja, de Oregon meg is oldja magának. Mármint remélem.

( thedioda | 2021. 12. 12., v – 07:38 )

  • Alapvetően sw raid leginkább (zfs).
  • Amennyiben van legalább 3 gép meg értelmes hálózat (>= 10Gbps) azonos storage kiépítésel akkor k8s felett rook-ceph vagy openebs, vagy ha valamilyen okból mindenkép kell virtualizáció akkor sima ceph pve-vel.
  • Ha meg sok gép van nagyon vegyes felvágott storage kiépítésel, netán nem is lehetnek egy clusterben akkor hw raid az egyszerübb managelhetőség végett.

( uid_17626 | 2021. 12. 12., v – 07:48 )

Esetemben többször felmerült az üzemeltetés. Ez 10 év alatt 3 db disk volt hw szinten. Sw szinten pedig egy virtuális gép sem kevesebb, sőt. A hosttal is kellhet egyeztetni, ami lassító tényező ami viszont költség. Esetemben ebben a nagyságrendben a költség nem tényező.

Mentés localban van amit szinkronizálok 3 helyre. 

Cloud az jóval több, mint VPS hosting. Ha csak a fizikai vasat váltod ki és a szoftveres infrastruktúrád ugyanúgy üzemeltetni kell, azzal valóban kevesebbet spórol meg az ember munkában. Spórolás ott kezdődik, hogy ha neked kell mondjuk X dolog (pl. egy adatbázis), akkor abból kérsz egy instancet adott paraméterekkel, neked csak annyi a dolgod, hogy fogd a connection stringet, üzemeltetést meg csinálja a cloud provider.

( khiraly | 2021. 12. 12., v – 09:46 )

Szerkesztve: 2021. 12. 12., v – 09:53

Vegigneztem a hozzaszolasokat:

Aki cloud-ra szavaz az miert tenne? Az ar miatt? A rendelkezesre allas miatt? Nem kell hozza szakertelem, hogy osszerakd (wtf?) miatt?

Security update? (mondjuk itt tudni kellene, hogy milyen cloudra szavaznak a legtobben)

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Két fajta üzem van

Az egyikben van "gépkönyv" és pontosan kiolvasható az elmúlt időszak rendelkezésreállása

A másik komolytalan.

 

A "garantálás" mit jelent? Az, hogy 25 éve nem volt adatvesztéesed, sem nagyobb leállásod, az egy rendkivüli érték. A méregdrága contract az nem.

Volt egy Nagy Gyártó, aki 4 órás garantált HW csere kiszállítással, piacvezető storage gyártó, oriási tesztelési kapacitással, mérnökök ezreivel sikerrel eladott (akkori újdonság) 1TB SATA diszket enterprise kategóriában, jó ár érték, archive target, deduplikáció, raid6, hotspare, extended block checksum, minden. Nálam és ügyfeleimnél volt belőle 100.

Másfél év üzem után egyszercsak potyogtak, egyik másik után, potty, hotspare, reconstruct 60%, potty, hotspare, reconstruct 60%, potty. (raid6 meghalt) Sikerült nekik szériahibával gyártani a jóságot. Garancia? Miféle garancia? Ott volt a 4 órás szerződés, küldik a diszket, mindent, megbízható nagy cég, piacvezető gyártó, garancia az volt dögivel. Csak üzem nem.  Ekkor kellett alakítani valamit, amin nem segített a méregdrága szerződés, a 4 órás alkatrészküldés, csak az, hogy "épp kéznél volt" annak a raid6 -nak és a reconstruct algoritmusának pontos ismerete, így megúszta a cég 4 órás leállással, nem volt adatvesztés, sem hetekig tartó mentésből-visszaállunk-csak-elöbb-telepítünk-és-konfigurálunk szokásos sorozata. Aztán az összes ügyfélnel elindítottuk ezen diszkek ütemezett cseréjét, és a gyártónak volt arca megkérdezni, hogy "mi az oka a rendkívül nagyszámú csereigénynek?".

25 év a garancia. Nem a papír.

Service Commitment

AWS will use commercially reasonable efforts to make the Amazon S3 Services each available with a Monthly Uptime Percentage, as described below, during any monthly billing cycle (the “Service Commitment”). In the event an Amazon S3 Service does not meet the Service Commitment, you will be eligible to receive a Service Credit as described below.

Definitions

• “Error Rate” means: (i) the total number of internal server errors returned by the Amazon S3 Service as error status “InternalError” or “ServiceUnavailable” divided by (ii) the total number of requests for the applicable request type during that 5-minute interval. We will calculate the Error Rate for each Amazon S3 Service account as a percentage for each 5-minute interval in the monthly billing cycle. The calculation of the number of internal server errors will not include errors that arise directly or indirectly as a result of any of the Amazon S3 SLA Exclusions.

•  “Monthly Uptime Percentage” is calculated by subtracting from 100% the average of the Error Rates from each 5-minute interval in the monthly billing cycle. If you did not make any requests in a given 5-minute interval, that interval is assumed to have a 0% Error Rate.

•  A “Service Credit” is a dollar credit, calculated as set forth above, that we may credit back to an eligible Amazon S3 Service account.

 

Nekem ez eleg explicit leirja, hogy mit ertenek mukodik v. nem mukodik alatt.

Nem akarlak elkeseríteni, de azt gondolod hogy a nagy gyártó majd mérnökökre meg tesztekre fogja költeni a pénzét? Ugyan. Van helyette 10x annyi product manager, sales meg jogász.

Van egy mondás, hogy mi a különbség a desktop disk meg az enterprise disk között: csak a warranty period. Lásd: https://www.backblaze.com/blog/enterprise-drive-reliability/

Autos pelda johet?

Ne koss biztonsagi ovet, mert a szomszed Geza sogora a multkor kirepult az autobol egy baleset soran es az mentette meg az eletet.

Leforditva nekem gozom nincs, mit akartal mondani.

 

Masreszt valoban, az sem mind1, h mennyire hiteles az, aki a garanciat nyujtja.

Ezzel egyutt is a kedves topicnyito a budos eletben nem fogja garantaltan biztositani a szolgaltatasnak azt a szintjet. Sot ezt o is beismerte, feltehetoen be is arazta. A szavaibol lejott, h neki nem eri meg.

( hnsz2002 v | 2021. 12. 23., cs – 18:36 )

Szerkesztve: 2021. 12. 23., cs – 18:37

Csak mdadm, már évek óta csak azt csinálok, akkor is ha ott a hw raid kártya. Egyrészt észre sem veszed a teljesítményvesztést, másrészt akármilyen linuxra rádugod, össze tudja rakni a tömböt, írható/olvasható, semmilyen hardverhez nem vagy kötött, harmadrészt (ami nekünk szempont) hogy egy toolt kell tudni használni, egyféleképpen kell a tömböt monitorozni, nem mindenféle idióta érhetetlen, külső repóból meg külön rpm-ből meg a tököm tudja honnan felrakott binárissal kell baszakodni, ami raádásul ahány annyiféle. Nem kell várni semennyit a cserehardverre, nem kell izgulni hogy vajon kompatibilis lesz-e vele, megfelelő firmware van-e rajta, stb. stb..

"Sose a gép a hülye."