Per quanto dice la domanda.
Supponiamo di voler avere l'equivalente di un "pulsante di emergenza" con script per il mio pool FreeNAS, qualcosa su cui posso fare clic per eseguire da una GUI o eseguire in console/SSH, che chiude molto rapidamente tutto ciò che potrebbe essere in lettura o scrittura su di esso, smonta il file system e, idealmente, interrompe i dischi o le partizioni che sta utilizzando.
Non mi interessano gli errori derivanti da altri software o connessioni remote in questo modo o interrompendo prematuramente eventuali trasferimenti di file lunghi, voglio solo che metta offline il pool nel modo più veloce, coerente con il mantenimento della sua coerenza e possibilmente dandone alcuni secondi per il completamento di eventuali scritture in sospeso e per il pool in uno stato coerente ai fini dei dati.
Le opzioni suggerite dai comandi ZFS non sembrano promettenti:zpool offline funziona solo su singoli dispositivi, quindi si potrebbe avere una race condition se la scrittura avviene mentre i dischi vengono rimossi uno alla volta; zpool export richiede l'opzione -f se in uso e contiene un avviso che -f può anche perdere dati. Si potrebbe controllare tutti i file descriptors aperti utilizzando la piscina o i suoi dispositivi (migliaia o centinaia di migliaia?) e forzando la chiusura manuale di ciascuno, ma ciò potrebbe influire sulle condizioni di gara in quanto non impedisce la creazione di nuovi fd contemporaneamente. Inoltre, non dovrei presumere che tutta l'attività ZFS sia mediata da un elenco di daemon di server di file remoti a cui inviare segnali di uscita, perché è probabile che alcune attività dei file siano locali (cron/CLI/sessioni separate).
Quindi, guardando al modo migliore per offline un intero pool in modo sicuro e veloce, sembra umount potrebbe essere la soluzione migliore:funziona a livello di file system e può offline un intero file system rapidamente e come unità monolitica, dopodiché zpool export sembra che sarebbe quindi in grado di terminare e sospendere effettivamente qualsiasi attività interna in modo sicuro senza il -f opzione, mantenendo i dati stessi in uno stato coerente garantito. Se è in corso un'attività del disco grezzo (resilver o scrub), immagino che riprenderà o si riavvierà quando il pool verrà successivamente riportato online.
Ma anche umount non sembra farlo completamente, perché potrebbe esserci iSCSI zvol anche gli obiettivi in uso. I dati all'interno di quelli intrinsecamente non possono essere mantenuti coerenti poiché il server non conosce la sua struttura, quindi gli iniziatori remoti dovranno eseguire la riparazione dei dati nel miglior modo possibile quando si riconnetteranno. A me va bene, ma non sono sicuro se sia necessario un qualche tipo di comando per terminare forzatamente o offline gli obiettivi o le migliori pratiche. (Nota:connessioni con terminazione forzata ha gli stessi problemi della chiusura di singoli fd.)
Sono consapevole che è inevitabile che si verifichi una sorta di perdita o problema di dati se il pool viene espulso bruscamente dallo stato RW durante le scritture. Ma fintanto che non perde consistenza (a livello di pool ZFS e file system), allora va bene:qualsiasi file in uso/bersaglio iSCSI aggiornato dovrà correre il rischio che file/blocchi siano coerenti con ZFS ma lo stato dei dati non è valido a causa della disconnessione in corso durante la scrittura dei dati. Questo è inevitabile e non è un problema per la domanda.
Quindi quali passaggi devo effettivamente fare per offline un pool in uso il più velocemente possibile coerentemente con la sicurezza e la coerenza garantite del pool e umount manualmente ing un file system ZFS in uso (come parte di una soluzione) essere al sicuro o comportare il rischio di danni ai dati?
Aggiornamento: Citando qui nel caso qualcun altro lo trovi utile. La risposta accettata afferma che export -f potrebbe avere problemi con zvols (iSCSI ecc.). Sulla base di questo suggerimento, ho scoperto che il gestore iSCSI utilizzato da FreeNAS può disconnettersi/terminare le sessioni forzatamente e ha altri utili sottocomandi che potrebbero essere emessi in anticipo – vedere man ctladm . Qualunque sia il motivo per cui vengono utilizzati i tuoi zvol, è probabile che ci sia qualche comando per terminare le sessioni su di essi.)
Risposta accettata:
Dichiarazione di non responsabilità:al momento non ho molti collegamenti e riferimenti per eseguire il backup di tutto ciò che segue e non l'ho testato in modo approfondito. Questo è solo un riassunto delle cose che ho letto negli ultimi cinque o sette anni su ZFS e su come funziona, e alcuni test limitati (non coordinati, ma per lo più riavvii casuali).
Inoltre, tutto ciò che segue viene detto senza considerare eventi catastrofici (il server si brucia completamente), bug del software (bug in ZFS e nel sistema operativo principale, nonché controller hardware) e malizia attiva (amministratore canaglia, errori di amministrazione). Per tutti questi casi è comunque necessario disporre di backup regolari e ripristinabili!
Dati inattivi/coerenza su disco
Non mi interessano gli errori derivanti da altri software o connessioni remote in questo modo o interrompendo prematuramente eventuali trasferimenti di file lunghi, voglio solo che metta offline il pool nel modo più veloce, coerente con il mantenimento della sua coerenza e possibilmente dandone alcuni secondi per il completamento di eventuali scritture in sospeso e per il pool in uno stato coerente ai fini dei dati.
Innanzitutto, la buona notizia:poiché ZFS utilizza CoW e transazioni atomiche, i tuoi dati già esistenti saranno al sicuro anche in caso di improvvisa interruzione di corrente. Ciò include il layout del pool e i metadati. Poiché i vecchi dati non vengono mai spostati prima che i nuovi dati siano stati completamente scritti (infatti, non vengono mai spostati, ma solo riallocati), questi dati non possono essere in alcun modo in pericolo se la scrittura viene interrotta improvvisamente.
Correlati:Grep:perché le parentesi nel modello grep rimuovono il processo grep dai risultati di ps?Inoltre, i checksum (alberi di hash Merkle) aiutano a certificare che non è successo nulla di male durante il riavvio, che puoi controllare strofinando il pool. Se si dispone di vdev ridondanti, ZFS correggerà automaticamente tutti gli errori rilevati da una copia valida nota. Se alcuni blocchi fossero stati danneggiati in qualche modo (ad esempio da un controller del disco canaglia che non scrive ma dice di farlo), i loro checksum non corrisponderebbero a quelli di altri vdev e verrebbero visualizzati gli errori.
Dati in modalità volo/scrittura e perdita degli ultimi n secondi
Sincronizza e scritture asincrone
Normalmente, ZFS raccoglie più transazioni per velocizzare le costose scritture su unità rotanti:il posizionamento della testina di scrittura dell'HDD richiede molto più tempo della scrittura effettiva, quindi ti consigliamo di metterti in coda il più possibile e quindi scriverlo in sequenza (più veloce !) ordine (ricorda, abbiamo CoW, qui funziona in modo del tutto naturale).
Lo svantaggio di questo è che più a lungo raccogli, più a lungo le tue applicazioni dovrebbero attendere per un messaggio di "scrittura riuscita", il che significa che il tuo sistema si bloccherebbe per diversi secondi, il che è inaccettabile. Ancora peggio:perderai tutti i dati che devono essere scritti su disco ma non sono stati ancora scritti in caso di interruzione di corrente. Se le tue applicazioni non sono in grado di farcela, potrebbe verificarsi un danneggiamento del livello dell'applicazione.
Per combattere questo, è stato aggiunto lo ZIL (ZFS intent log). Tutte le transazioni di sincronizzazione vengono raccolte in questo registro (che è archiviato per impostazione predefinita sul disco del pool lento, ma può essere archiviato su SSD più veloci e con mirroring, denominati dispositivi SLOG) e dopo che sono stati archiviati, "scrittura riuscita" viene restituito al applicazione che può svolgere i suoi compiti (non si blocca più a lungo). Inoltre, tutte le transazioni asincrone vengono eseguite senza ZIL, quindi possono essere più veloci, a condizione che l'applicazione chiami le operazioni di scrittura corrette per i suoi dati (sincronizzazione o asincrona).
Proprietà ZFS
Ora per la parte più interessante:cosa succede ai tuoi scritti? Lì dobbiamo discernere la modalità operativa per il file system (è una proprietà ZFS e può essere impostata individualmente per ciascun file system). Le tre modalità possibili sono (dalle manpage):
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.
Lo noterai anche se disabled viene scelto, il layout della tua piscina/coerenza interna non viene influenzato:perderai solo gli ultimi 5 secondi di dati e questo potrebbe mettere i tuoi file in uno stato errato (ad esempio, perché hai una VM in cima che prevede scritture di sincronizzazione ma hai fornito solo uno zvol asincrono come archivio dati di supporto).
D'altra parte, se non vuoi perdere niente , imposta tutti i tuoi file system su always e passare a SSD ad alte prestazioni, almeno per il dispositivo SLOG (o subirne i tempi di attesa).
standard è un compromesso e il più flessibile:l'applicazione stessa decide di quale modalità di scrittura ha bisogno. Se le tue applicazioni non funzionano, potresti riscontrare una perdita di dati. Se si comportano bene, avrai le migliori prestazioni possibili con una determinata base di sicurezza.
Esportazione/importazione pool:
Dalla documentazione su zpool export :
Il comando tenta di smontare tutti i file system montati all'interno del pool prima di continuare. Se uno qualsiasi dei file system non riesce a smontare, puoi smontarlo forzatamente usando l'opzione -f.
Se i dispositivi non sono disponibili al momento dell'esportazione, i dispositivi non possono essere identificati come esportati correttamente. Se uno di questi dispositivi viene successivamente collegato a un sistema senza nessuno dei dispositivi funzionanti, viene visualizzato come "potenzialmente attivo".
Se i volumi ZFS sono in uso nel pool, il pool non può essere esportato, anche con l'opzione -f. Per esportare un pool con un volume ZFS, assicurati innanzitutto che tutti i consumer del volume non siano più attivi.
Questo significa all'incirca tre cose:
-fforza l'esportazione del pool tramite lo smontaggio forzato di tutti i file system, anche se sono attivi (senza tener conto dei blocchi o delle applicazioni che vi scrivono)- Questo non funziona con
zvols - Non dovresti dividere i pool e usarli su sistemi diversi (fai attenzione alle situazioni di failover)
Riepilogo:
- Se tutto ciò che ti interessa è la coerenza su disco, sei a posto con
export -fo uno spegnimento completo - Se ti interessano tutti i dati, usa
sync=alwayse veloci SSD - Per quanto riguarda iSCSI/NFS come datastore per VM, anche questa panoramica può essere utile (estratto:usa NFS o disabilita la cache di writeback iSCSI sul guest/host di macchine virtuali; disattiva la VM prima di eseguire uno snapshot ZFS, ZFS andrà comunque bene, ma la macchina virtuale guest sarà coerente solo con gli arresti anomali)
In risposta alle domande di follow-up dei commenti (domande omesse per le quali non ho risposte utili):
(1) "buone notizie/COW" – e se i blocchi di livello superiore stessero per aggiornarsi – troverà sempre un blocco di livello superiore utilizzabile (anche se punta a versioni leggermente vecchie dell'albero dei metadati)? Quanto può peggiorare?
Il caso peggiore sarebbe che l'uberblock (quello in cima a tutti gli altri) sia danneggiato su tutti i dispositivi ridondanti. Poiché non c'è un blocco sopra di esso, non puoi ricostruirlo dall'alto, quindi esistono diverse copie di ogni uberblock (IIRC era circa 3 o 4), quindi uno può essere perso e una copia sostitutiva è ancora lì.
(2) Ho familiarità con i TXG e utilizzo ESXi. Usando APC UPS + buona PSU/hw + P3700 NVMe ZIL quindi è potenza decente + ZIL veloce. Ma è improbabile che le scritture correnti siano tutte sincronizzate e, come dici tu, sync=always è lento. Ma la tua risposta fa sorgere un pensiero, potrei fare alcuni test delle prestazioni. Sto usando dedup (risparmio 4x, ne vale la pena), quindi write=slow comunque (deve cercare DDT). Il motivo per cui sincronizza =influisce sempre solo sulla scrittura che è comunque lenta a causa del DDT. Ma l'impostazione di sync=sempre forza ZIL, ZIL è molto veloce e ciò rende sicuri i TXG lunghi, il che potrebbe significare che l'accesso al disco è più efficiente. O potrebbe uccidere la latenza. Non ho idea di quale! Potrebbe essere necessario provare!
Non ho una vera esperienza con la deduplicazione, quindi non posso dire nulla di utile qui, tranne per il fatto che hai già fatto buone scelte nell'hardware (bassa latenza, IOPS di scrittura casuale a 64k elevato, interfaccia NVMe). Potrebbe essere più veloce solo se investi in un'unità RAM permanente davvero costosa (ZeusRAM et al.).
(6) Per "coerenza su disco" intendi che ZFS è felice e il pool è autoconsistente? Non preoccupatevi se alcuni file/dir. finiscono con contenuti non validi o non vengono spostati/eliminati il pool scompare improvvisamente o il file system come NTFWS/VMFS su uno zvol viene danneggiato internamente (cioè come ZFS zvol va bene ma dal punto di vista del client ha bisogno di fsck/chkdsk), pool fornito è sicuro/coerente come lo vede ZFS
Sì. Essenzialmente "la mia piscina non è incasinata, yay!" in una configurazione multiutente – anche se un utente ha problemi con i suoi file, gli altri non ne soffrono.
(7) Per "crash consistent" intendi quello che intendo (penso che tu lo faccia) - che ZFS andrà bene, il pool per quanto ZFS vede andrà bene, ma i dati del client remoto potrebbero essere alterati da quelli di quel client in modo simile a come se il client avesse avuto un improvviso errore di I/O del disco e le scritture fossero andate perse? ==il pool andrà bene, il client potrebbe avere dati persi/incoerenti e potrebbe aver bisogno di aiuto per il ripristino, come con qualsiasi altro errore di I/O del disco o arresto anomalo del sistema?
Sì, essenzialmente uno spegnimento forzato della VM invece di uno spegnimento pulito e POI scattare un'istantanea – se la si accende in seguito, fsck o simili a seconda del file system verrà eseguito e potrebbe lamentarsi di un arresto non pulito. Ciò è in contrasto con gli snapshot ESXi, che riprendono nel momento esatto come se nulla fosse, ma richiedono l'interazione con il sistema guest (aggiunte guest installate) e includono la memoria virtuale della VM.
Puoi combinare entrambi a tuo vantaggio:prima fai uno snapshot ESXi, poi uno snapshot ZFS del datastore (ESXi memorizza i suoi snapshot insieme alla VM). Quindi elimina il tuo snapshot ESXi, ma mantieni quello ZFS (occupa molto meno spazio a causa delle copie a livello di blocco). Durante il ripristino, ripristina prima lo snapshot ZFS, quindi ripristina lo snapshot ESXi (salvato) e riprenderai da dove eri rimasto. napp-it (eccellente sistema di gestione ZFS con interfaccia Web) ha questo concetto integrato (almeno per i datastore NFS, non ho verificato iSCSI ma presumo che sia simile).