diff --git a/prez.md b/prez.md
index 06d5477812ab9a96126b9c569435e88755ca6dd0..a8c156dd768c2b99d5413c5db2ef84a70c010402 100644
--- a/prez.md
+++ b/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?
+<!--
+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)
+<!--
+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?
+<!--
+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?
+<!--
+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