Capitolo 12. Storage

Se un percorso non è affidabile - se il collegamento si interrompe spesso - multipathd cercherà di usare quel percorso. Il timeout usato da multipathd per considerare il percorso non più accessibile è 300 secondi. Un periodo di tempo considerevole che può indicare erroneamente che multipathd è entrato in sospensione.

Per correggere questo errore sono state aggiunte due nuove opzioni di configurazione: delay_watch_checks e delay_wait_checks. Impostare delay_watch_checks sul numero di cicli che multipathd deve utilizzare per controllare il percorso dopo uno stato online. Se il percorso fallisce entro il valore assegnato, multipathd non lo utilizzerà, affidandosi a delay_wait_checks per indicare il numero di cicli da passare prima che il percorso venga preso in considerazione (valido). Questa impostazione impedisce l'uso di percorsi non validi appena gli stessi risultano essere online.

Gli utenti non erano in grado di suddividere la propria configurazione tra /etc/multipath.conf e altri file di configurazione. Ciò impediva loro di impostare un file di configurazione principale per tutte le macchine, e mantanere le informazioni sulla configurazione specifiche alle macchine, in file di configurazione separati per ogni macchina

Per risolvere questo problema è stata aggiunta una opzione config_dir nel file multipath.config. A tale scopo è richiesto agli utenti di modificare l'opzione config_dir con una stringa vuota o un fully qualified directory path name. Se impostata su qualsiasi altro valore diverso da una stringa vuota, multipath leggerà tutti i file .conf in ordine alfabetico. Successivamente verranno applicate le configurazioni esatte come se le stesse fossero state aggiunte a /etc/multipath.conf. Se questa modifica non viene apportata, config_dir eseguirà un default su /etc/multipath/conf.d.

Device Mapper (DM) è stato aggiornato alla versione upstream 4.0 e fornisce ora una serie di correzioni e miglioramenti rispetto alla versione precedente, incluso un aggiornamento importante delle prestazioni di cifratura del DM e un aggiornamento per il supporto di Multi-Queue Block I/O Queueing Mechanism (blk-mq).

Il comando dmstats fornisce un supporto dello spazio utente per le statistiche I/O del device-mapper. Ciò consente all'utente di creare, gestire e riportare i contatori I/O, le metriche e i dati di istogramma della latenza, per regioni arbitrarie dei dispositivi del device-mapper. I campi delle statistiche sono disponibili nei riporti dmsetup, il comando dmstats aggiunge alcune nuove modalità di riporto specializzate utilizzabili con le informazioni relative alle statistiche. Per informazioni sul comando dmstats, consultare la pagina man di dmstats(8).

In Red Hat Enterprise Linux 7.2, SCSI T10 DIX è completamente supportato per i seguenti array di storage e HBA e non sulle LUN usate per eseguire l'avvio da un ambiente SAN. T10 DIX è supportato in RHEL 7 solo su hardware nativo e non se eseguito su guest virtualizzati.

* EMULEX LPe16000/LPe16002

* QLOGIC QLE2670/QLE2672

* FUJITSU ETERNUS DX100 S3

* FUJITSU ETERNUS DX200 S3

* FUJITSU ETERNUS DX500 S3

* FUJITSU ETERNUS DX600 S3

* FUJITSU ETERNUS DX8100 S3

* FUJITSU ETERNUS DX8700 S3

* FUJITSU ETERNUS DX8900 S3

* FUJITSU ETERNUS DX200F

* FUJITSU ETERNUS DX60 S3

Il supporto per DIX rimane una Anteprima di tecnologia per array di archiviazione e HBA.

T10 DIX ha bisogno di un database, o di altro software, in grado di generare e verificare i checksum su blocchi a disco. Nessun filesystem di Linux attualmente supportato possiede questa capacità.

La cache in LVM è completamente supportata con l'introduzione di Red Hat Enterprise Linux 7.1. Questa funzione permette agli utenti di creare volumi logici con un dispositivo piccolo ma veloce, il quale si comporta come una cache per dispositivi più grandi e lenti. Consultare la pagina man di lvmcache(7) per informazioni su come creare i volumi logici della cache.

Di seguito sono riportate le restrizioni sull'utilizzo dei volumi logici della cache (LV):

* La cache LV deve essere un dispositivo di livello superiore, non può essere usata come thin-pool LV, immagine di un RAID LV o qualsiasi altro tipo di LV secondario.

* cache LV sub-LV (le LV d'origine, le LV dei metadati e le LV dei dati) possono essere solo lineari, segmentate o RAID.

* Le proprietà di una cache LV non possono essere modificate dopo la creazione. Per la modifica delle proprietà, rimuovere la cache e ricrearla con le proprietà desiderate.

Scritta una nuova politica dm-cache smq per ridurre il consumo di memoria e migliorare le prestazioni nella maggior parte delle situazioni. Questa è ora la politica predefinita per nuovi volumi logici della cache LVM. Gli utenti che preferiscono usare la politica mq precedente, possono farlo utilizzando l'argomento —cachepolicy durante la creazione del volume logico della cache.

Ora i gruppi di volumi LVM possono avere un proprietario. Il proprietario è il system ID di un host. Solo l'host con un system ID dato può utilizzare il VG. Questa impostazione è idonea per i gruppi di volumi che risiedono sui dispositivi condivisi, visibili agli host multipli, i quali potrebbero non essere protetti da un uso simultaneo di host multipli. I gruppi di volumi LVM sui dispositivi condivisi con un system ID, sono posseduti solo da un host e protetti nei confronti di altri host.