Új hozzászólás Aktív témák

• #1 Dißnäëß veterán

  Új Válasz 2023-08-31 23:36:24 #1

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Dißnäëß

  veterán

  A ZFS egy fejlett fájlrendszer, logikai kötetkezelő és (nagyon gyakran) raid megoldás is egyben, amely számos előnyös funkciót kínál, mint például említett raid, adat integritás ellenőrzés, megfelelő "raid" verzió esetén öngyógyulás (self-healing), óriási kapacitás (egybe vagy csoportokba, ún. pool-okba és dataset-ekbe rendezve), pillanatképek (snapshots) képessége, bizonyos műveletek on-the-fly elvégzése, tömörítés, deduplikáció, titkosítás és még sok más.

  A ZFS CoW (Copy on Write) típusú fájlrendszer és mint ilyen, SSD barát akár bekapcsolt TRIM funkció nélkül is.

  A ZFS egyik legérdekesebb jellemzője - az adatintegritáson túl - az olvasási és írási gyorsítótárazás mikéntje.

  A ZFS mögött álló csapat úgy véli, hogy a szabad és a fel nem használt memória elvesztegetett memória. Tehát úgy tervezték a ZFS-t, hogy az adatokat nagyon agresszívan gyorsítótárazza. A ZFS a lehető legtöbb adatot megpróbálja a memóriában (RAM) tárolni , hogy gyorsabban hozzáférjen a fájlrendszerhez.

  Sajnos a memória (RAM) nagyon költséges. Így született az ötlet és képesség, miszerint a ZFS lehetővé teszi gyors SSD-k használatát az adatok gyorsítótárazására. A memóriában tárolt adatok 1. szintű gyorsítótárnak, az SSD-n lévő gyorsítótár pedig 2. szintű gyorsítótárnak minősül.

  
  A ZFS adatainak több szintű gyorsítótárazása

  A ZFS gyorsítótárának első szintje az Adaptive Replacement Cache (ARC). Miután az ARC teljes kapacitását kihasználta, a ZFS a legutóbbi és leggyakrabban használt adatokat a 2. szintű adaptív gyorsítótárba (L2ARC) helyezi el.

  Az ARC és az L2ARC, valamint a ZIL (ZFS Intent Log) és a SLOG (külön napló) esetében némi zűrzavar van azzal kapcsolatban, hogy valójában milyen szerepet töltenek be.

  Az ARC és kiterjesztése, az L2ARC olvasási gyorsítótárak. Azért léteznek, hogy felgyorsítsák az olvasást a kiszolgálón, hogy a rendszernek ne kelljen lassabb merevlemezeken keresgélnie minden alkalommal, amikor adatot kell találnia.

  Az írások esetében a ZIL egy napló, és valójában nem egy írási gyorsítótár (bár gyakran ilyennek nevezik), még akkor sem, ha egy külön naplóeszközön (SLOG) létezik. A ZFS alapértelmezés szerint a pool egy kis részét lefoglalja az írási gyorsítótárnak. Ezt ZIL-nek vagy ZFS Intent Log-nak hívják. Mielőtt az adatokat a fizikai merevlemezre írná, azokat a ZIL-ben tárolja. Az írási műveletek számának minimalizálása és az adatok töredezettségének csökkentése érdekében az adatok tehát a ZIL-ben vannak csoportosítva és egy bizonyos küszöb elérésekor a fizikai merevlemezre kerülnek, vagy ha nincs külön ZIL számára allokált SSD-nk, akkor a ZIL mint olyan, lassítja magát a pool-t ezen másolási műveletekkel. Inkább írási pufferként kell rá gondolni, mint tényleges gyorsítótárra. Egy köztes ideiglenes tároló.

  Ekkor jön képbe az SLOG (másodlagos napló).
  Mivel a ZFS a pool egy kis részét használja a ZIL tárolására, megosztja a ZFS pool sávszélességét, ami negatív hatással van a teljesítményre alapesetben. A probléma megoldásához használhatunk gyors SSD-t SLOG-eszközként. Ha egy SLOG eszköz létezik egy ZFS-poolban, akkor a ZIL átkerül a SLOG eszközre. A ZFS többé nem tárolja a ZIL-adatokat a poolban (fizikailag), így nincs a ZIL-re feleslegesen elvesztegetett sávszélesség.

  De vannak más előnyök is. Ha egy alkalmazás a hálózaton keresztül ír a ZFS pool-ra (azaz VMware ESXi, NFS stb..), a ZFS gyorsan be tudja írni az adatokat a SLOG-ba, és visszaigazolást küld az alkalmazásnak, hogy az adatok a lemezre vannak írva. Ezután a szokásos módon lassabb merevlemezekre ki tudja írni az adatokat. Így ezek az alkalmazások összességében jobban reagálnak az alájuk adott ZFS storage műveletekre.

  Érdemes észben tartani, hogy általában a ZFS nem olvas be a SLOG-ból. A ZFS csak áramkimaradás vagy írási hiba esetén olvas adatokat a SLOG-ból. A nyugtázott írások csak ideiglenesen tárolódnak ott, amíg a lassabb merevlemezekre át nem teszi őket. Csak arra szolgál, hogy áramkimaradás vagy írási hiba esetén a nyugtázott írások ne vesszenek el, és a lehető leggyorsabban az állandó tárolóeszközökre kerüljenek.

  Illetve azt is érdemes figyelembe venni, hogy SLOG eszköz hiányában a ZIL-t ugyanerre a célra használja.

  Írás
  Amikor a ZFS írási kérést kap, nem csak azonnal elkezdi a lemezre írást, hanem a RAM-ba gyorsítótárazza azt, mielőtt meghatározott időközönként (alapértelmezett 5 másodperc) elküldi a tranzakciós csoportokba (TXG). Ezt tranzakciós fájlrendszernek hívják.

  Ez javítja a teljesítményt, mivel a lemezre kerülő írások jobban meg vannak szervezve és ez a merevlemezek számára is optimálisabb feldolgozást tesz lehetővé. Az adatkonzisztenciát is előnyben részesíti, mivel áramkimaradás esetén nem történik részleges írás. Részleges írás helyett – a TXG-ben lévő összes adat el lesz dobva.

  A ZFS íráskezelési alapjainak megértéséhez meg kell érteni a különbséget a szinkron és az aszinkron írások között.

  Aszinkron írások: az adatok azonnal gyorsítótárazásra kerülnek a RAM-ban, és az írás befejezettnek jelentett a kliens irányába, az adat pedig majd később lemezre íródik.

  Amikor a kliens írási kérést küld, az azonnal a RAM-ban tárolódik. A szerver ezután nyugtázza a kliensnek, hogy az írás befejeződött. A RAM-ban való tárolás után a szerver további kéréseket fogad el anélkül, hogy bármit is írna a lemezekre, amíg a tranzakciócsoport együtt ki nem íródik a lemezre. Az aszinkron írás nagyon gyors folyamat a végfelhasználók szemszögéből, mivel az adatokat csak nagy sebességű RAM-ban kell tárolni, hogy befejezettnek lássák az írási műveletet.

  A kérdés? Bár az adatok továbbra is konzisztensek maradnak, ha áramkimaradás történik, akkor a tranzakciócsoportban minden elvész, mivel az csak a memóriában létezik. A szinkron írás az adatok konzisztenciáját hivatott biztosítani, de ennek a teljesítmény ára van.

  Szinkron írások (külön naplózó eszköz nélkül): nyugtázni kell, hogy a tartós adathordozóra ki lett írva az adat, mielőtt az írás befejezettnek tekinthető.

  Amikor a kliens írási kérelmet küld egy szinkron íráshoz, ez akkor is először a RAM-ban landol, csakúgy, mint egy aszinkron írás, de a szerver nem veszi tudomásul, hogy az írás befejeződött, amíg nem frissíti a ZIL-t (ZFS Intent Log). A ZIL frissítése után kerül az írási művelet nyugtázásra. A ZIL alapértelmezés szerint a storage pool részeként létezik, ami azt jelenti, hogy a merevlemez fejeinek fizikailag mozogniuk kell a ZIL frissítése során a ZIL területe és a tényleges adatterület között, ami nem feltétlen optimális teljesítmény szempontból, a HDD-re való várakozás bizonyos teljesítményproblémákat okoz, különösen a kis véletlenszerű írások miatt.

  A ZFS megoldása a lassulásokra és a szinkron írásból származó nemkívánatos adatvesztésre az, hogy a ZIL-t egy külön, gyorsabb és állandó tárolóeszközre (SLOG) helyezi el, jellemzően SSD-re.

  Szinkron SLOG írások
  Ha a ZIL egy SSD-n található, a kliensek szinkron írási kérelmei sokkal gyorsabban naplózódnak a ZIL-ben. Így ha a RAM-ban lévő adatok elvesztek áramkimaradás miatt, a rendszer a következő újra induláskor ellenőrzi a ZIL-t, és megtalálja a keresett adatokat.
  Alternatív megoldásként az adatok azonnal lemezre írhatók a ZIL-en mentett mutatókkal együtt. Az adatok metaadatai a következő TXG elküldése után frissülnek, hogy a megfelelő helyre mutassanak. Áramkimaradás esetén a szerver ellenőrzi a ZIL-t, és megtudja, hol vannak az adatok. A rendszer valójában nem volt tisztában azzal, hogy hol vannak az adatok, amíg a következő tranzakciócsoport át nem ment, és ellenőriznie kell a ZIL-t, mert a metaadatok nem mutatják, hol vannak. Az egyik dolog, amit meg kell jegyezni az SLOG-nál, hogy általában a legjobb a tükrözés (mirror), hogy lehetővé tegye az adatok konzisztenciájának biztosítását áramkimaradás esetén.

  Hogy egy SLOG mennyiben segíti a teljesítményt?
  Az SLOG hatása a teljesítménye az alkalmazástól függ. A kisméretű IO-k esetében jelentős javulás várható, és a szekvenciális IO-nál is tisztességes javulás lehet. Sok szinkron írás esetén, például adatbázis-kiszolgálók vagy virtuális gépek üzemeltetése esetén is hasznos lehet. Az SLOG elsődleges funkciója azonban nem a teljesítmény javítása, hanem az adatok mentése, amelyek egyébként áramkimaradás esetén elvesznének. A kritikus alkalmazások esetében meglehetősen költséges lehet egy 5 másodpercnyi adat elvesztése, amelyet a következő tranzakciócsoportban továbbítottak volna. Ezért is van az, hogy a SLOG nem egy gyorsítótár, hanem egy napló, ahogy a neve is sugallja. A SLOG csak váratlan áramszünet esetén van "felkeresve".
  Ha az 5 másodpercnyi adatvesztés elkerülése létfontosságú, akkor lehetőség van arra, hogy az összes írást szinkronban hajtsák végre a teljesítményvesztésért cserébe. Ha ezen adatok egyike sem kritikus, akkor a szinkronizálás letiltható, és az összes írás egyszerűen a RAM-ot használhatja gyorsítótárként, azzal a kockázattal, hogy elveszíthet az ember egy tranzakciócsoportot. A szabványos szinkronizálás az alapértelmezett, amelyet az alkalmazás és a ZFS határoz meg minden írásnál.

  A SLOG-hoz való eszköz kiválasztásának nem hivatalos követelménye, hogy olyan meghajtókat válasszunk, amelyek jól működnek egyetlen queue depth-el. Mivel a szinkron írások nem - a legtöbb SSD számára legmegfelelőbb - nagyobb tételekben jönnek át, szabványos SSD használatakor ténylegesen teljesítménycsökkenés léphet fel. Fontos, hogy a SLOG-ban legyen akkumulátor, ha azt szeretnénk, hogy az adatmentésre biztonságosan használható legyen, tehát áramszünet esetén még akkuról kiírja a neki küldött információt.

  Olvasás
  Csakúgy, mint az írás, a ZFS az olvasást is gyorsítótárazza a rendszer RAM-jában. Az olvasási gyorsítótárat "adaptív helyettesítő gyorsítótárnak" (ARC) hívják. Ez az IBM ARC módosított változata, és az ARC által használt összetettebb algoritmusok miatt intelligensebb az átlagos olvasási gyorsítótáraknál.

  ARC
  Az ARC úgy működik, hogy a RAM-ban tárolja a legutóbb használt és leggyakrabban használt adatokat. Ez egy valódi gyorsítótár a ZIL-lel ellentétben, mivel a memóriában lévő ARC-ban található adatok a lemezeken a pool-ban is léteznek. Az ARC csak segít felgyorsítani az olvasási teljesítményt, amiben általában kiváló munkát végez. Egy nagy ARC sok RAM-ot elfoglalhat, de ezt a ZFS ha szükséges, feladja mivel más alkalmazásoknak szüksége lehet rá.

  Az ARC a legutóbb használt és a leggyakrabban használt adatok változó részét használja fel úgy, hogy cache "hideg találat" esetén több helyet foglal az egyiknek vagy a másiknak. Hideg találat akkor következik be, amikor olyan adatot kérnek, amely korábban gyorsítótárban volt, de már ki lett téve onnan, hogy az ARC új adatokat tárolhasson. A ZFS nyomon követi a gyorsítótárban tárolt adatokat az eltávolítás után, hogy lehetővé tegye a hideg találatok felismerését. Amint új adatok érkeznek, azok az adatok, amelyeket egy ideje nem használtak, vagy amelyeket nem használtak annyiszor, mint az új adatok, kikerülnek.

  Minél több RAM-mal rendelkezik a rendszer, annál jobb, mivel ez csak jobb olvasási teljesítményt nyújt. Az alaplapi RAM slot-ok és a költségvetési korlátok miatt több ARC hozzáadásának fizikai és költségkorlátai lesznek. Ha az ARC megtelt anélkül, hogy elég magas lenne a találati aránya, és a rendszerünk már nagy mennyiségű RAM-mal rendelkezik, érdemes lehet egy 2. szintű ARC (L2ARC) hozzáadásában gondolkodni.
  L2ARC
  Az L2ARC SSD-n létezik a sokkal gyorsabb RAM helyett. Még mindig sokkal gyorsabb, mint a pörgő lemezek, így amikor az ARC találati aránya alacsony, az L2ARC hozzáadása bizonyos teljesítményelőnyökkel járhat. Ahelyett, hogy a merevlemezeken keresne adatokat a ZFS, a rendszer a RAM-ot és az SSD-t nézi a teljesítmény javítása érdekében először. Az L2ARC-ot általában akkor veszi figyelembe, ha az ARC találati aránya 90% alatt van, miközben pl. 64+ GB RAM-mal rendelkezünk.

  Az L2ARC csak akkor fog megtelni, amikor az ARC megtelt, és amikor az ARC felszabadít helyet, hogy teret adjon az algoritmusa által fontosabbnak ítélt új adatoknak. Ezek a felszabadított helyek (adatok) átkerülnek az L2ARC-ba. Sok időbe telhet, amíg az L2ARC megtelik.

  Érdekesség, hogy az L2ARC-ot nem szükséges tükrözni, ahogy egy SLOG-nak ajánlott mondjuk, mivel az L2ARC által tárolt összes adat továbbra is megtalálható a pool-ban.

  Ezenkívül az L2ARC bizonyos mennyiségű helyet használ a RAM-ban annak nyomon követésére, hogy milyen adatok vannak ott tárolva, így általában jobb a RAM bővítése az L2ARC beállítása és használata előtt. Az SSD-k drágábbak, mint a HDD-k, de jóval olcsóbbak, mint a RAM, így a döntés meghozatalakor bizonyos ár/teljesítmény kompromisszum is adódhat.

  Összegzésként elmondható, hogy adatbázis szerver, virtuális gépek, stb. szinkron műveletekhez érdemes SLOG mirror eszközöket is használni, viszont otthoni átlagos fájltárolásra és nagyméretű read cache-elésre elég egy szimpla SSD mirror nélkül is, L2ARC számára. Mivel ez csak olvasási cache, ha tönkremegy, meghibásodik, nem történik adatvesztés, minden a pool-on van, amíg viszont működik és jó, nagyon hatékonyan gyorsítja a többször ill. gyakran elért adatok olvasását. Alternatív opció az is lehet, hogy 2db SSD-t veszünk, melyeket egyformán particionálva, mondjuk 25% SLOG / 75% L2ARC felosztásban, odaadjuk ezeket SLOG esetén mirror módban, L2ARC esetén akár stripe módban ("raid 0", méret+sebesség előny) a pool-nak szíves használatra, így gyorsítva a mindennapokat.

  To be continued..

  Lá lá lá lá lááá lááá.. Lá lá lá lá lááá lááá .. Lá lá lá lá lááá lá lááá lá lá lá lááááá láááá

Új hozzászólás Aktív témák