Le versioni recenti di RHEL / CentOS (EL6) hanno apportato alcune interessanti modifiche al filesystem XFS da cui ho fatto molto affidamento per oltre un decennio. Ho trascorso parte dell'estate scorsa a inseguire una situazione di file sparsa XFS risultante da un backport del kernel scarsamente documentato. Altri hanno avuto problemi di prestazioni sfortunati o comportamenti incoerenti da quando sono passati a EL6.
XFS era il mio filesystem predefinito per dati e partizioni di crescita, poiché offriva stabilità, scalabilità e un buon incremento delle prestazioni rispetto ai filesystem ext3 predefiniti.
C'è un problema con XFS sui sistemi EL6 emersi nel novembre 2012. Ho notato che i miei server mostravano carichi di sistema anomali, anche quando erano inattivi. In un caso, un sistema senza carico mostrerebbe una media di carico costante di 3+. In altri, c'era un dosso 1+ nel carico. Il numero di filesystem XFS montati sembrava influenzare la gravità dell'aumento del carico.
Il sistema ha due filesystem XFS attivi. Il carico è +2 dopo l'aggiornamento al kernel interessato.
Scavando più a fondo, ho trovato alcuni fili sulla lista XFS che indicava un aumento della frequenza del xfsaildprocesso seduta in STAT D stato. Le voci corrispondenti di CentOS Bug Tracker e Red Hat Bugzilla delineano le specifiche del problema e concludono che questo non è un problema di prestazioni; solo un errore nella segnalazione del carico di sistema nei kernel più recenti di 2.6.32-279.14.1.el6 .
WTF?!?
In una situazione una tantum, capisco che la segnalazione del carico potrebbe non essere un grosso problema. Prova a gestirlo con il tuo NMS e centinaia o migliaia di server! Questo è stato identificato nel novembre 2012 nel kernel 2.6.32-279.14.1.el6 sotto EL6.3. I kernel 2.6.32-279.19.1.el6 e 2.6.32-279.22.1.el6 sono stati rilasciati nei mesi successivi (dicembre 2012 e febbraio 2013) senza alcuna modifica a questo comportamento. C'è stata persino una nuova versione minore del sistema operativo da quando questo problema è stato identificato. EL6.4 è stato rilasciato ed è ora nel kernel 2.6.32-358.2.1.el6 , che presenta lo stesso comportamento.
Ho avuto una nuova coda di build del sistema e ho dovuto aggirare il problema, bloccando le versioni del kernel alla versione precedente a novembre 2012 per EL6.3 o semplicemente non usando XFS, optando per ext4 o ZFS , con una grave riduzione delle prestazioni per l'applicazione personalizzata specifica in esecuzione in cima. L'applicazione in questione si basa fortemente su alcuni degli attributi del file system XFS per tenere conto delle carenze nella progettazione dell'applicazione.
Andando dietro il sito della knowledge base a pagamento di Red Hat , appare una voce che afferma:
Si osserva una media di carico elevato dopo l'installazione del kernel 2.6.32-279.14.1.el6. La media del carico elevato è causata da xfsaild che passa allo stato D per ciascun dispositivo formattato XFS.
Al momento non esiste una soluzione per questo problema. Attualmente è monitorato tramite Bugzilla # 883905. Soluzione alternativa Eseguire il downgrade del pacchetto del kernel installato a una versione precedente alla 2.6.32-279.14.1.
(eccetto il downgrade dei kernel non un'opzione su RHEL 6.4 ...)
Quindi siamo in 4+ mesi in questo problema senza una vera correzione pianificata per le versioni del sistema operativo EL6.3 o EL6.4. C'è una soluzione proposta per EL6.5 e una patch sorgente del kernel disponibile ... Ma la mia domanda è:
A che punto ha senso allontanarsi dai kernel e dai pacchetti forniti dal sistema operativo quando il manutentore a monte ha rotto una funzionalità importante?
Red Hat ha introdotto questo errore. Essi dovrebbero incorporare una correzione in un kernel errata. Uno dei vantaggi dell'utilizzo dei sistemi operativi aziendali è che forniscono un obiettivo di piattaforma coerente e prevedibile . Questo bug ha disturbato i sistemi già in produzione durante un ciclo di patch e ha ridotto la fiducia nella distribuzione di nuovi sistemi. Mentre potrei applicare una delle patch proposte al codice sorgente , quanto è scalabile? Richiederebbe un po 'di vigilanza per essere aggiornato quando il sistema operativo cambia.
Qual è la mossa giusta qui?
- Sappiamo che questo potrebbe essere risolto, ma non quando.
- Supportare il proprio kernel in un ecosistema Red Hat ha un proprio set di avvertimenti.
- Qual è l'impatto sull'idoneità all'assistenza?
- Dovrei semplicemente sovrapporre un kernel EL6.3 funzionante su server EL6.4 di nuova generazione per ottenere la corretta funzionalità XFS?
- Devo solo aspettare che questo sia risolto ufficialmente?
- Cosa dice questo sulla mancanza di controllo sui cicli di rilascio di Linux aziendali?
- Fare affidamento su un filesystem XFS per così tanto tempo un errore di pianificazione / progettazione?
Modificare:
Questa patch è stata incorporata nel più recente CentOSPlus release del kernel ( kernel-2.6.32-358.2.1.el6.centos.plus ). Sto testando questo sui miei sistemi CentOS, ma questo non aiuta molto per i server basati su Red Hat.