Minor rewrite

prez.md

@@ -33,6 +33,11 @@ section::after {
 
 Tóth Miklós
 
+<!-- 
+Sziasztok! Örülök, hogy ennyien vagytok itt.
+Pár menő adattárolási technológiáról fogok beszélni, remélem tudok mindenkinek valami újat mutatni.
+-->
+
 ---
 
 ## `whoami`
@@ -43,6 +48,13 @@ Tóth Miklós
 - Storage enthusiast
 - Home lab 😎
 
+<!--
+Mike-ként ismerhettek, a Sysadminban Vezető Rendszergazda vagyok,
+emellett már relatív régóta foglalkozok Linux-szal és DevOps-szal,
+mind munkában, mind homelabban, mind KSZK-ban és természetesen eléggé
+érdekel az adattárolás.
+-->
+
 ---
 
 ## Tartalom
@@ -52,7 +64,13 @@ Tóth Miklós
 - menő technológiák
 - egy konkrét implementáció
 
-
+<!-- 
+Szó lesz arról, hogy miért érdemes ezzel foglalkozni,
+pár alap adattárolási fogalomról és technológiáról,
+eztán vadabb vizekre evezünk és bemutatok pár menő,
+az iparban is használt technológiát és végül azt, hogy
+az új storage szervereinket hogyan setupoltuk a KSZK-ban.
+-->
 
 ---
 <!-- _class: [lead, invert] -->
@@ -73,11 +91,31 @@ Mi lesz, ha megnő a felhasználók száma?
 **OK, akkor egy storage appliance már biztos elég lesz!**  
 Vendor lock-in? 10 év múlva hogyan tovább?
 
+<!--
+Szóval, miért?
+Felvetődhet bennünk pár kérdés, amikor megtervezzük azt, hogy hol is fogjuk tárolni az adatainket.
+(diasor)
+Szóval, röviden, sok más indok mellett emiatt érdemes gondolkodni storage megoldásokon.
+-->
+
 ---
 <!-- _class: [lead, invert] -->
 
 # Alapok
 
+<!-- 
+Először is egy kis közvélemény kutatással kezdeném:
+
+- Ki hallott már RAID-ről? (nem kell mélyen tudni)
+- ZFS-ről?
+- Klaszterekről?
+- Ceph?
+
+(reakció, köszi)
+
+Haladjuk is tovább...
+-->
+
 ---
 
 ## Block device
@@ -87,6 +125,19 @@ Vendor lock-in? 10 év múlva hogyan tovább?
 - lehet máshol fizikailag vagy akár virtuális
 - kernel kezeli
 
+<!-- 
+Párszor használni fogom a block device kifejezést.
+Linuxon block device-nak hívunk általánosságban minden olyan eszközt,
+legyen az valódi vagy virtuális, ami blokkonként írható-olvasható.
+Így az összes diszk blokkonként (akár hívjuk azt szektornak vagy lapnak)
+használható.
+Sok virtuális block device van, például ha LUKS-sal titkosítunk 
+egy diszket vagy partíciót, akkor az feloldott titkosított meghajtó egy külön
+block device-ként jelenik meg.
+Még annyit érdemes megjegyezni, hogy minden block művelet a kernelbe fut be,
+ott van az a logika, ami eldönti, hogy ilyenkor mi történjen.
+-->
+
 ---
 
 ## RAID
@@ -95,6 +146,13 @@ Vendor lock-in? 10 év múlva hogyan tovább?
 - egy diszk sokszor nem elég nagy
 - több diszk kevesebb eséllyel hal meg egyszerre
 
+<!--
+Szóval, RAID.
+Erről már sokan hallottatok, a RAID annyit tud, 
+hogy (akár hardveresen, akár szoftveresen)
+pár standard módon összekombinálunk több diszket egy block device-szá. 
+-->
+
 ---
 
 ### RAID-0
@@ -104,6 +162,12 @@ Vendor lock-in? 10 év múlva hogyan tovább?
 
 ![bg right contain](./img/raid0.svg)
 
+<!--
+RAID-0. Itt nem az adat védelmét részesítjük előnyben, hanem a kapacitást és sebességet.
+Az adatot gyakorlatilag blokkonként félbevágva, egyszerre több diszkre írjuk vagy olvassuk.
+Ennek hátránya, hogy ha bármelyik diszk meghibásodik, minden adatnak annyi.
+-->
+
 ---
 
 ### RAID-1
@@ -112,6 +176,10 @@ Vendor lock-in? 10 év múlva hogyan tovább?
 - n-szer redundánsabb (n-1 diszk eshet ki)
 ![bg right contain](./img/raid1.svg)
 
+<!--
+RAID-1. Ez kvázi egy inverz RAID-0.
+Egy diszknyi területet kapunk, de minél több diszket teszünk bele, annál több meghalhat.
+-->
 
 ---
 
@@ -122,6 +190,15 @@ Vendor lock-in? 10 év múlva hogyan tovább?
 
 ![bg right contain](./img/raid5.svg)
 
+<!--
+A RAID-5 már picit okosabb megoldás, itt van egy diszk paritás,
+amire valamilyen algoritmussal (egy triviális példa az xor)
+számolunk egy értéket, amivel egy másik diszk kiesése mellett 
+vissza tudjuk szerezni az adott blokkot.
+
+Itt egy diszknyi kapacitást vesztünk, és szintén egy diszknyi redundanciát kapunk.
+
+-->
 
 ---
 
@@ -132,6 +209,10 @@ Vendor lock-in? 10 év múlva hogyan tovább?
 
 ![bg right contain](./img/raid6.svg)
 
+<!--
+A RAID-6 pedig ugyanez, de két paritás diszkkel.
+-->
+
 ---
 
 ## Bitrot
@@ -218,9 +299,9 @@ disk1: ...011010<span class="bad">1</span>001100101011011000110110001101111...
 #### Checksumming
 
 - néhány blokkonként számol egy checksum-ot, amit eltárol az adat mellé
-- ha bitrot miatt egy blokkból 2 verzió lesz, akkor amire passzol a checksum, az a jó verzió
+- ha egy blokkból 2 verzió lesz, akkor checksum check
 - minimális overhead
-- scrub: arra utasítja a ZFS-t, hogy nézze át a poolban lévő összes adatot és ahol bitrot volt, javítsa ki (ha tudja)
+- scrub
 - jelzi a hibákat, ebből látható jövőbeni diszk halál
 
 ---
@@ -314,20 +395,50 @@ storage/test                      40.3M  2.32T     40.3M  /storage/test
     - Ceph
     - GlusterFS
     - DRBD (és Linstor)
+- **nem backup**
 - "split brain" probléma; quorum
 
+<!--
+Ha több, mint egy teljes gépnyi redundancia kell, akkor a storage klaszterek
+felé fordulhatunk. Ezek segítségével egy vagy több gép kiesése mellett is
+(akár tervezett, mint egy update, akár nem)
+zavartalanul kezelhetjük az adataink és a gép újjáélesztése után
+visszaszinkronizálódik az adat.
+
+(diasor)
+-->
+
+---
+
+## Quorum
+
+- 2 node:
+  - egyik gép meghal, OK
+  - másik gép meghal, OK
+  - háló problémák?
+
+- szavazótöbbség, tranzakciók
+
+<!-- 
+Felmerül még a split brain probléma is a páros számú gépekből álló klaszterekben.
+Képzeljük el azt, hogy az egyik gép kiesik, ilyenkor a másik gép önmaga átveszi a feladatokat, ugyanez fordítva is megtörténik.
+De mi van akkor, ha egyik gép se hal meg, viszont kettejük között
+hálózati gubanc van. Ekkor mind a két gép megpróbálja egyedül vinni
+az összes feladatot és ekkor divergálni fog az adat.
+Erre egy megoldás a quorum, vagy szavazótöbbség, amikor a gépek több, mint fele
+vissza kell igazolja a műveleteket ahhoz, hogy azok véhez menjenek. Ehhez 3 vagy több gép kell.
+-->
+
 
 ---
 
 ## Ceph
 
-- "state of the art" megoldás, a leggazdagabb feature-ökben
-- objektumokat tárol: blokk, fájl vagy bármi más is lehet
-- a klaszterben minden diszk egyesével szerepel, node szinten nincsen RAID
-- mon: koordináló service; quorum
-- osd: egy-egy diszk
-- CRUSH: az algoritmus ami a klaszterben szétdobja az adatokat
-    - pl: legyen ugyanabban a rackben, de külön gépeken 2 másolat
+- "state of the art" megoldás
+- objektumok, nem blokk vagy file
+- a klaszterben minden diszk egyesével szerepel
+- mon + osd (+ mgr + mds + egyebek)
+- CRUSH
 
 --- 
 
@@ -347,11 +458,10 @@ storage/test                      40.3M  2.32T     40.3M  /storage/test
 
 ## GlusterFS
 
-- nagyon minimalista
-- fájlonként dolgozik, fájlokként is tárolja az adatot
+- minimalista
+- fájlonkat kezel, FS
 - a backing fájlrendszer előnyeit megkapja
-- node és brick van
-- node-on belüli redundancia a backing fájlrendszer feladata
+- node és brick
 
 ---
 
@@ -376,7 +486,7 @@ storage/test                      40.3M  2.32T     40.3M  /storage/test
 - nagyon régóta létezik, robosztus
 - "hálózati RAID-1"
 - node-on belüli redundancia a backing block device feladata
-- diskless node: a quorum része, de adatot nem tárol (viszont elérheti)
+- diskless node
 
 ---
 
@@ -448,12 +558,6 @@ storage/test                      40.3M  2.32T     40.3M  /storage/test
 
 ---
 
-### Demo
-
-TODO
-
----
-
 ### Hova tovább?
 
 - network upgrade