Jak říká otázka.

Předpokládejme, že chci mít ekvivalent skriptovaného „nouzového tlačítka“ pro svůj fond FreeNAS – něco, na co mohu kliknout a spustit z GUI nebo spustit v konzole/SSH, což velmi rychle zavře vše, co by do něj mohlo číst nebo zapisovat, odpojí systém souborů a – v ideálním případě – uvede disky nebo oddíly, které používá.

Nezajímají mě chyby způsobené jiným softwarem nebo vzdáleným připojením, když to udělám, nebo předčasné přerušení jakýchkoli dlouhých přenosů souborů, jen chci, aby byly offline fond nejrychlejším způsobem, který je v souladu se zachováním jeho konzistence a případně mu dá pár sekund, aby byly dokončeny všechny čekající zápisy a fond byl v konzistentním stavu pro datové účely.

Možnosti navrhované příkazy ZFS nevypadají slibně:zpool offline funguje pouze na jednotlivých zařízeních, takže pokud k zápisu dojde, když jsou disky jeden po druhém odstraňovány, může dojít ke sporu; zpool export vyžaduje volbu -f, pokud se používá, a nese varování, že -f může přijít i o data. Dalo by se zkontrolovat všechny otevřené file descriptors pomocí poolu nebo jeho zařízení (je jich tisíce nebo statisíce?) a ručně vynutit uzavření každého, ale to by mohlo zasáhnout podmínky závodu, protože to nezastaví vytváření nových fd ve stejnou dobu. Také bych neměl předpokládat, že veškerá aktivita ZFS je zprostředkována seznamem vzdálených démonů pro obsluhu souborů, kterým se mají odeslat výstupní signály, protože některá aktivita souborů bude pravděpodobně lokální (cron/CLI/odpojené relace).

Když se tedy podíváme na to, jak nejlépe bezpečně a rychle odpojit celý fond offline, vypadá to jako umount může být moje nejlepší sázka – funguje na úrovni souborového systému a dokáže rychle offline celý souborový systém a jako monolitická jednotka, poté zpool export vypadá to, že by pak bylo možné skutečně dokončit a uklidit jakoukoli interní aktivitu bezpečným způsobem bez -f možnost, udržování samotných dat v zaručeně konzistentním stavu. Pokud probíhá nezpracovaná disková aktivita (resilver nebo scrub), předpokládám, že by se obnovila nebo restartovala, až bude fond později znovu online.

Ale i umount nezdá se, že to dělá úplně, protože může existovat iSCSI zvol také používané cíle. Data v nich ze své podstaty nemohou být konzistentní, protože server nezná jejich strukturu, takže vzdálení iniciátoři budou muset provést opravu dat, jak nejlépe dovedou, když se znovu připojí. Jsem s tím v pohodě, ale nejsem si jistý, jestli je potřeba nějaký druh příkazu k vynucení nebo offline ukončení cílů nebo osvědčený postup. (Poznámka:vynucené ukončení spojení má stejné problémy jako uzavření jednotlivých fd’s by.)

Jsem si vědom toho, že dojde k nějaké ztrátě dat nebo problému, pokud je fond náhle vyhozen ze stavu RW, když probíhají zápisy. Ale pokud neztratí konzistenci (na úrovni fondu ZFS a souborového systému), pak je to v pořádku – všechny používané soubory/cíle iSCSI, které se aktualizují, budou muset riskovat, že soubory/bloky budou konzistentní se ZFS. ale stav dat je neplatný kvůli přechodu do režimu offline během zapisování dat. Tomu se nelze vyhnout a není to problém této otázky.

Jaké kroky tedy vlastně musím udělat, abych co nejrychleji odpojil používaný fond v souladu se zaručenou bezpečností a konzistencí fondu – a ručně umount Je používání používaného souborového systému ZFS (jako součást řešení) bezpečné nebo s sebou nese nějaké riziko poškození dat?

Aktualizace: Zmíněno zde pro případ, že by to někdo považoval za užitečné. Přijatá odpověď uvádí, že export -f může mít problémy se zvols (iSCSI atd.). Na základě tohoto náznaku jsem zjistil, že obslužný program iSCSI používaný FreeNAS může násilně odhlásit/ukončit relace a má další užitečné dílčí příkazy, které lze zadat předem – viz man ctladm . Ať už se vaše zvoly používají k čemukoli, pravděpodobně na nich bude nějaký příkaz k ukončení relací.)

Přijatá odpověď:

Zřeknutí se odpovědnosti:V tuto chvíli nemám po ruce mnoho odkazů a referencí k zálohování všech níže uvedených položek a nijak jsem to rozsáhle netestoval. Toto je jen shrnutí věcí, které jsem za posledních pět až sedm let četl o ZFS a jak funguje, a některé omezené vlastní testování (ne koordinované, ale většinou náhodné restarty).

Vše níže je také řečeno bez ohledu na katastrofické události (úplně shoří server), softwarové chyby (chyby v ZFS a hlavním operačním systému i hardwarových řadičích) a aktivní zlomyslnost (nečestný admin, chyby administrace). Pro všechny tyto případy stále potřebujete mít pravidelné a obnovitelné zálohy!

Neaktivní data / konzistence na disku

Nezajímají mě chyby způsobené jiným softwarem nebo vzdáleným připojením, když to udělám, nebo předčasné přerušení jakýchkoli dlouhých přenosů souborů, jen chci, aby byly offline fond nejrychlejším způsobem, který je v souladu se zachováním jeho konzistence a případně mu dá pár sekund, aby byly dokončeny všechny čekající zápisy a fond byl v konzistentním stavu pro datové účely.

Za prvé, dobrá zpráva:protože ZFS používá CoW a atomické transakce, vaše již existující data budou v bezpečí i v případě náhlého výpadku napájení. To zahrnuje rozložení fondu a metadata. Protože se stará data nikdy nepřesouvají, dokud nejsou úplně zapsána nová data (ve skutečnosti se nepřesouvají vůbec, pouze přerozdělují), tato data nemohou být v žádném případě ohrožena, pokud je zápis náhle přerušen.

Související:Grep – proč závorky ve vzoru grep odstraňují proces grep z výsledků ps?

Kontrolní součty (Merkle hash stromy) navíc pomáhají potvrdit, že se během restartu nestalo nic špatného, ​​což můžete zkontrolovat pročištěním fondu. Pokud máte redundantní vdevs, ZFS automaticky opraví všechny chyby, které najde ze známé dobré kopie. Pokud by byly některé bloky jakýmkoli způsobem poškozeny (například nečestným diskovým řadičem, který nezapisuje, ale tvrdí, že ano), jejich kontrolní součty by se neshodovaly s kontrolními součty z jiných vdev a zobrazily by se chyby.

Data v režimu letu / zápisu a ztráta posledních n sekund

Synchronizace a asynchronní zápisy

Normálně ZFS shromažďuje více transakcí, aby urychlil nákladné zápisy na rotující disky – umístění zapisovací hlavy na HDD zabere mnohem více času než samotný zápis, takže budete chtít zařadit do fronty co nejvíce a pak to zapisovat postupně (rychleji). !) objednat (nezapomeňte, že máme CoW, tady to funguje zcela přirozeně).

Nevýhodou je, že čím déle shromažďujete, tím déle by vaše aplikace musely čekat na zprávu „úspěšný zápis“ – což znamená, že váš systém by se na několik sekund zablokoval, což je nepřijatelné. Ještě horší je, že v případě výpadku napájení ztratíte všechna data, která mají být zapsána na disk, ale ještě nebyla zapsána. Pokud si s tím vaše aplikace neporadí, může dojít k poškození aplikační vrstvy.

Aby se tomu zabránilo, byl přidán ZIL (záznam záměrů ZFS). Všechny synchronizační transakce jsou shromažďovány v tomto protokolu (který je ve výchozím nastavení uložen na disku pomalého fondu, ale lze jej ukládat na rychlejší, zrcadlené disky SSD, které se nazývají zařízení SLOG) a po jejich uložení se do protokolu vrátí zpráva „úspěšný zápis“ aplikace, která může pokračovat ve svých úkolech (už žádné dlouhé zámky). Všechny asynchronní transakce se navíc provádějí bez ZIL, takže mohou být rychlejší – za předpokladu, že aplikace zavolá správné operace zápisu pro svá data (synchronizace vs asynchronní).

Vlastnosti ZFS

Nyní k té zajímavější části – co se stane s vašimi texty? Zde musíme rozeznat provozní režim pro souborový systém (je to vlastnost ZFS a lze ji nastavit individuálně pro každý souborový systém). Tři možné režimy jsou (z manuálových stránek):

sync=standard
  This is the default option. Synchronous file system transactions
  (fsync, O_DSYNC, O_SYNC, etc) are written out (to the intent log)
  and then secondly all devices written are flushed to ensure
  the data is stable (not cached by device controllers).

sync=always
  For the ultra-cautious, every file system transaction is
  written and flushed to stable storage by a system call return.
  This obviously has a big performance penalty.

sync=disabled
  Synchronous requests are disabled.  File system transactions
  only commit to stable storage on the next DMU transaction group
  commit which can be many seconds.  This option gives the
  highest performance.  However, it is very dangerous as ZFS
  is ignoring the synchronous transaction demands of
  applications such as databases or NFS.
  Setting sync=disabled on the currently active root or /var
  file system may result in out-of-spec behavior, application data
  loss and increased vulnerability to replay attacks.
  This option does *NOT* affect ZFS on-disk consistency.
  Administrators should only use this when these risks are understood.

Všimnete si toho, i když je disabled je vybráno, rozložení/vnitřní konzistence vašeho fondu to neovlivní – ztratíte pouze posledních 5 sekund dat a toto může uvést vaše soubory do nesprávného stavu (například proto, že máte nahoře virtuální počítač, který očekává synchronizační zápisy, ale dodali jste pouze asynchronní zvol jako záložní datové úložiště).

Na druhou stranu, pokud nechcete ztratit vůbec nic , nastavte všechny systémy souborů na always a přejít na vysoce výkonné SSD, alespoň pro zařízení SLOG (nebo trpět čekací dobou).

standard je kompromisní a nejflexibilnější – aplikace sama rozhodne, jaký režim zápisu potřebuje. Pokud jsou vaše aplikace špatné, může dojít ke ztrátě dat. Pokud se budou chovat, budete mít nejlepší možný výkon s danou základní úrovní bezpečnosti.

Export/import fondu:

Z dokumentace o zpool export :

Než bude příkaz pokračovat, pokusí se odpojit všechny připojené systémy souborů v rámci fondu. Pokud se některý ze souborových systémů nepodaří odpojit, můžete jej násilně odpojit pomocí volby -f.

Pokud jsou zařízení v době exportu nedostupná, nelze je identifikovat jako čistě exportovaná. Pokud je jedno z těchto zařízení později připojeno k systému bez jakéhokoli funkčního zařízení, zobrazí se jako „potenciálně aktivní“.

Pokud se ve fondu používají svazky ZFS, fond nelze exportovat, a to ani s volbou -f. Chcete-li exportovat fond se svazkem ZFS, nejprve se ujistěte, že všichni uživatelé svazku již nejsou aktivní.

To znamená zhruba tři věci:

• -f vynutí export fondu vynuceným odpojením všech souborových systémů, i když jsou aktivní (bez ohledu na zámky nebo aplikace, které tam píšou)
• Toto nefunguje s zvol s
• Neměli byste rozdělovat fondy a používat je na různých systémech (buďte opatrní v situacích převzetí služeb při selhání)

Související:Jak vypsat n’th nejmladší soubor (bez analýzy ls!)?

Shrnutí:

• Pokud vše, co vás zajímá, je konzistence na disku, je dobré použít export -f nebo úplné vypnutí
• Pokud vám záleží na všech datech, použijte sync=always a rychlé SSD
• Pokud jde o iSCSI/NFS jako datová úložiště pro virtuální počítače, může být tento přehled také užitečný (výňatek:použijte NFS nebo deaktivujte mezipaměť zpětného zápisu iSCSI na hostu/hostiteli virtuálního počítače; před pořízením snímku ZFS uveďte VM do klidu, ZFS bude každopádně v pořádku, ale hostující virtuální počítač bude pouze konzistentní s pády)

V odpovědi na doplňující otázky z komentářů (vynechané otázky, na které nemám žádné užitečné odpovědi):

(1) „dobré zprávy/kráva“ – co kdyby se bloky nejvyšší úrovně měly aktualizovat – najde vždy použitelný blok nejvyšší úrovně (i když ukazuje na mírně staré verze stromu metadat)? Jak špatné to může být?

V nejhorším případě by byl uberblock (ten nahoře nad všemi ostatními) poškozen na všech redundantních zařízeních. Protože nad ním není žádný blok, nemůžete ho rekonstruovat shora, takže existuje několik kopií každého uberbloku (IIRC to byly asi 3 nebo 4), takže jeden může být ztracen a náhradní kopie je stále k dispozici.

(2) Znám TXG a používám ESXi. Použití APC UPS + dobrý PSU/hw + P3700 NVMe ZIL, takže je to slušný výkon + rychlý ZIL. Ale je nepravděpodobné, že aktuální zápisy budou všechny synchronizované a jak říkáte, synchronizace =vždy je pomalá. Ale vaše odpověď vyvolává myšlenku, mohl bych provést nějaké testování výkonu. Používám dedup (4x úspora, stojí to za to), takže stejně pište =pomalu (musí hledat DDT). Důvod, proč je synchronizace =vždy, ovlivňuje pouze zápis, který je stejně pomalý kvůli DDT. Ale nastavení sync=vždy vynutí ZIL, ZIL je velmi rychlý a díky tomu jsou dlouhé TXG bezpečné, což může znamenat efektivnější přístup k disku. Nebo to může zabít latenci. Netuším jaký! Možná to budete muset zkusit!

S dedupcí nemám žádné skutečné zkušenosti, takže zde nemohu říci nic užitečného, ​​kromě toho, že jste si již dobře vybrali hardware (nízká latence, vysoké náhodné 64k zápis IOPS, rozhraní NVMe). Mohlo by to být rychlejší, pouze pokud byste investovali do nějaké opravdu drahé permanentní paměti RAM (ZeusRAM a spol.).

(6) Pod pojmem „konzistence na disku“ myslíte, že ZFS je spokojený a fond je konzistentní? Nebojte se, jestli nějaké soubory/adresáře. skončí s neplatným obsahem nebo se nepřesune/neodstraní, fond náhle zmizí nebo se vnitřně poškodí souborový systém, jako je NTFWS/VMFS na zvol (tj. jako ZFS zvol je to v pořádku, ale z pohledu klienta potřebuje fsck/chkdsk), za předpokladu, že fond je bezpečný/konzistentní, jak to ZFS vidí

Ano. V podstatě "můj bazén není v prdeli, yay!" ve víceuživatelském nastavení – i když má jeden uživatel problémy se svými soubory, ostatní tím netrpí.

(7) Termínem „konzistentní selhání“ máte na mysli to, co myslím (myslím, že ano) – že ZFS bude v pořádku, fond, pokud ZFS vidí, že bude v pořádku, ale data vzdáleného klienta mohou být pozměněna z dat tohoto klienta. perspektivu podobně, jako kdyby klient zasáhl náhlou poruchu IO disku a došlo ke ztrátě zápisů? ==fond bude v pořádku, klient mohl ztratit/nekonzistentní data a může potřebovat pomoc s obnovou, jako při jakémkoli jiném selhání IO disku nebo selhání systému?

Ano, v podstatě úplné vypnutí virtuálního počítače namísto čistého vypnutí a POTOM pořízení snímku – pokud jej poté zapnete, fsck nebo podobný v závislosti na souborovém systému poběží a může si stěžovat na nečisté vypnutí. To je na rozdíl od snímků ESXi, které se obnoví v přesném okamžiku, jako by se nic nestalo, ale vyžadují interakci s hostujícím systémem (nainstalované doplňky pro hosty) a zahrnují virtuální paměť virtuálního počítače.

Obojí můžete zkombinovat ve svůj prospěch:nejprve pořiďte snímek ESXi, poté snímek datového úložiště ZFS (ESXi ukládá své snímky vedle virtuálního počítače). Poté smažte svůj snímek ESXi, ale ponechte si snímek ZFS (zabírá mnohem méně místa kvůli kopiím na úrovni bloků). Při obnově nejprve obnovte svůj snímek ZFS a poté se vraťte ke svému (uloženému) snímku ESXi a budete pokračovat tam, kde jste skončili. napp-it (vynikající systém správy ZFS s webovým rozhraním) má tento koncept zabudován (alespoň pro datová úložiště NFS jsem nekontroloval iSCSI, ale předpokládám, že je to podobné).