"Possiamo aggiornare i nostri server EL5 di produzione esistenti a EL6?"

Una richiesta semplice da parte di due clienti con ambienti completamente diversi ha portato la mia solita risposta alle migliori pratiche di "sì, ma richiederà una ricostruzione coordinata di tutti i tuoi sistemi " ...

Entrambi i clienti ritengono che una ricostruzione completa dei loro sistemi sia un'opzione inaccettabile per tempi di inattività e motivi di risorse ... Alla domanda sul perché fosse necessario reinstallare completamente i sistemi, non ho avuto una buona risposta oltre ", è così ..."

Non sto cercando di ottenere risposte sulla gestione della configurazione ("Puppetize tutto " non sempre si applica ) o su come i clienti avrebbero dovuto pianificare meglio. Questo è un esempio reale di ambienti che sono cresciuti e prosperati in una capacità di produzione, ma non vedono un percorso pulito per passare alla versione successiva del loro sistema operativo.

Ambiente A:
organizzazione senza fini di lucro con 40 x Red Hat Enterprise Linux 5.4 e 5.5 web, server di database e server di posta, esecuzione di uno stack di applicazioni Web Java, bilanciamento del carico software e database Postgres. Tutti i sistemi sono virtualizzati su due cluster VMWare vSphere in posizioni diverse, ciascuno con HA, DRS, ecc.

Ambiente B:
società di trading finanziario ad alta frequenza con 200 sistemi CentOS 5.x in più strutture di co-location che eseguono operazioni di trading di produzione, supportando lo sviluppo interno e le funzioni di back-office. I server di trading sono in esecuzione su hardware server di metallo bare metal. Hanno numerose sysctl.conf, rtctlinterruzioni di associazione e modifiche al driver per ridurre la latenza della messaggistica. Alcuni hanno kernel personalizzati e / o in tempo reale. Le stazioni di lavoro degli sviluppatori eseguono anche versioni simili di CentOS.

In entrambi i casi, gli ambienti funzionano bene così come sono. Il desiderio di aggiornare deriva dalla necessità di un'applicazione o funzionalità più recente disponibile in EL6.

• Per l'azienda no profit, è legato ad Apache, al kernel e ad alcune cose che renderanno felici gli sviluppatori.
• Nella società di trading, si tratta di alcuni miglioramenti nel kernel, nello stack di rete e nel GLIBC, che renderanno felici gli sviluppatori.

Entrambi sono elementi che non possono essere facilmente impacchettati o aggiornati senza alterare drasticamente il sistema operativo .

Come ingegnere di sistema, apprezzo il fatto che Red Hat raccomandi ricostruzioni complete quando ci si sposta tra le versioni principali. Un inizio pulito ti costringe a refactoring e prestare attenzione alle configurazioni lungo la strada.

Essendo sensibile alle esigenze aziendali dei clienti, mi chiedo perché questo debba essere un compito così oneroso . Il sistema di packaging RPM è più che in grado di gestire gli aggiornamenti sul posto, ma sono i piccoli dettagli che ti ottengono: /bootrichiedere più spazio, nuovi file system predefiniti, RPM che probabilmente interrompe i pacchetti a metà aggiornamento, deprecati e defunti ...

Qual è la risposta qui? Altre distribuzioni (basate su .deb, Arch e Gentoo) sembrano avere questa capacità o un percorso migliore. Diciamo che troviamo i tempi di inattività per svolgere questo compito nel modo giusto :

• Cosa dovrebbero fare questi client per evitare lo stesso problema quando EL7 viene rilasciato e si stabilizza?
• O è un caso in cui le persone hanno bisogno di rassegnarsi alle ricostruzioni complete ogni pochi anni?
• Questo sembra peggiorare con l'evoluzione di Enterprise Linux ... O lo sto solo immaginando?
• Ciò ha dissuaso qualcuno dall'utilizzare Red Hat e i sistemi operativi derivati?

Suppongo che ci sia l'angolo di gestione della configurazione, ma la maggior parte delle installazioni di Puppet che vedo non si traducono bene in ambienti con server applicativi altamente personalizzati (l' ambiente B potrebbe avere un singolo server il cui ifconfigoutput è simile a questo ). Sarei interessante nel sentire suggerimenti su come utilizzare la gestione della configurazione per aiutare le organizzazioni a superare il bump della versione principale di RHEL.

(Nota dell'autore: questa risposta si riferisce a RHEL 6 e versioni precedenti. RHEL 7 ora ha un percorso di aggiornamento completamente supportato da RHEL 6, i cui dettagli sono alla fine.)

Per iniziare, dovrei notare che ci sono due modi per eseguire l'aggiornamento sul posto:

1. Inserisci il DVD di installazione (o usa l'immagine del DVD tramite iLO / iDRAC), avvialo da esso e scegli Aggiorna, ad es linux upgradeany.
2. Aggiorna redhat-releasemanualmente RPM, esegui yum distro-sync(questo è un po 'troppo semplificato) e riavvia.

Il metodo 1 è semplicemente non supportato. Il metodo 2 è per i veri cowboy. Oltre alle nuove installazioni consigliate, ho fatto entrambe queste ...

Ho bisogno di supporto?

Il supporto ha due significati complementari nel nostro mondo. Il primo è che un prodotto ha una determinata funzione (ad es. "Postfix supporta SMTP"). Il secondo è che il venditore te ne parlerà. Quale definizione si intende non è sempre chiara dal contesto.

Per compiere un compito, ovviamente hai bisogno di supporto nel primo senso. Il supporto del fornitore è quello di aiutarti a risolvere i problemi e fornire feedback al fornitore sulle funzionalità che devono esistere o migliorare. Molti siti pagano una fortuna per il supporto del fornitore quando hanno le competenze interne per risolvere eventuali problemi che possono sorgere, più velocemente e persino più a buon mercato di quanto il venditore possa fare. Se acquistare il supporto del fornitore è in definitiva una decisione aziendale che dovrete prendere (o consigliare alla direzione).

Perché non eseguire un aggiornamento sul posto?

Ecco cosa dice Red Hat al riguardo :

Red Hat non supporta gli aggiornamenti sul posto tra le versioni principali di Red Hat Enterprise Linux. Una versione principale è indicata da un cambio di versione di numero intero. Ad esempio, Red Hat Enterprise Linux 5 e Red Hat Enterprise Linux 6 sono entrambe versioni principali di Red Hat Enterprise Linux.

Gli aggiornamenti sul posto nelle principali versioni non mantengono tutte le impostazioni di sistema, i servizi o le configurazioni personalizzate. Di conseguenza, Red Hat consiglia vivamente nuove installazioni durante l'aggiornamento da una versione principale all'altra.

Inoltre avvertono:

Tuttavia, tenere presente le seguenti limitazioni prima di scegliere di aggiornare il sistema:

• I singoli file di configurazione del pacchetto potrebbero non funzionare dopo l'esecuzione di un aggiornamento a causa di modifiche in vari formati o layout dei file di configurazione.
• Se è installato uno dei prodotti a strati di Red Hat (come Cluster Suite), potrebbe essere necessario aggiornarlo manualmente dopo il completamento dell'aggiornamento di Red Hat Enterprise Linux.
• Le applicazioni di terze parti o ISV potrebbero non funzionare correttamente dopo l'aggiornamento.

Naturalmente, descrivono quindi come eseguire un aggiornamento sul posto tramite il metodo 1, nel caso in cui si desideri davvero farlo. La funzione esiste e Red Hat inserisce i tempi di sviluppo, quindi è supportata dal fatto che la funzione esiste. Ma se qualcosa va storto, Red Hat ti dirà di installare nuovamente; non forniranno supporto al fornitore per le cose che si rompono a seguito dell'aggiornamento.

Per la cronaca, in realtà non ho mai avuto problemi con un aggiornamento sul posto di un sistema RHEL / CentOS o Fedora che non sono riuscito a risolvere da solo. I problemi tipici derivano dai pacchetti rinominati, dai repository di terze parti e dalla mancata corrispondenza della versione occasionale tra le architetture i386 e x86_64 di un pacchetto. L'installatore è un po 'più bravo a gestirli che yum, credo.

Come devo aggiornare?

Generalmente avverto le persone che dovrebbero pianificare su una finestra di manutenzione ogni 3-4 anni per aggiornare i sistemi RHEL da una versione principale alla successiva. Mentre gli aggiornamenti generalmente procedono senza intoppi, l'imprevisto può sempre accadere.

Per entrambi i tuoi ambienti, mi aspetto che un aggiornamento sul posto funzioni, anche se consiglio vivamente di testarlo per primo. P2V un campione rappresentativo dei server ed esegui l'aggiornamento sul posto sui sistemi virtuali per vedere in quali problemi ti imbatterai. È quindi possibile pianificare l'effettivo aggiornamento della produzione in base a una migliore conoscenza di ciò che accadrà.

Per una distribuzione di grandi dimensioni come quella che hai qui, considera l'utilizzo dell'approccio "uno-alcuni-molti" di Limoncelli. Aggiorna una macchina, vedi quali problemi si verificano, risolvili, quindi utilizza le lezioni apprese durante l'aggiornamento di un piccolo gruppo di macchine, ripeti le lezioni apprese, quindi quando ritieni di aver risolto tutti i nodi, esegui l'upgrade di grandi gruppi di essi.

In un momento come questo, ti consiglio anche di dare una lunga occhiata al processo di distribuzione dell'applicazione. Se non è sufficientemente automatizzato da poterlo dare il via con un solo comando ed essere ragionevolmente sicuro che l'app verrà distribuita correttamente, allora forse gli sviluppatori devono lavorarci su. Avere un tale processo di implementazione renderebbe molto più semplice fare una nuova installazione della versione più recente di EL e quindi distribuirla su di essa.

La commutazione delle distribuzioni aiuterà?

Le distribuzioni basate su Debian hanno un metodo di aggiornamento sul posto supportato e funziona principalmente, ma non è immune da problemi. Molte cose si sono rotte per le persone che eseguivano l'aggiornamento da Ubuntu 10.04 LTS a 12.04 LTS tramite il metodo supportato, ad esempio. Non è chiaro che Debian o Canonical stiano impiegando una quantità sufficiente di tempo di sviluppo per "supportare" questa funzionalità, ovvero assicurarsi che funzioni. E in realtà devi ancora acquistare il supporto del fornitore per questa distribuzione se vuoi che qualcuno ti tenga la mano. Quindi dubito che guadagnerai molto passando a tale distribuzione.

Puoi guadagnare passando a una distribuzione rolling-release come Gentoo o Arch. Tuttavia, anche questo non ti rende immune ai problemi; significa solo che devi affrontare i problemi di aggiornamento continuamente per tutta la vita del server (ad esempio ogni volta che tu o gli sviluppatori decidete di aggiornare qualcosa sul sistema), piuttosto che tutti in una volta in un momento di aggiornamento della distribuzione ben pianificato. Inoltre, non è necessario alcun fornitore per fornire supporto.

Cosa riserva il futuro?

Il progetto Fedora sta lavorando a uno strumento per migliorare gli aggiornamenti sul posto. Avevano uno strumento chiamato preupgradeche fu abbandonato e sostituito con un nuovo strumento chiamato fedup a partire da Fedora 18 . Questo è stato aggiunto a RHEL7 e ora gli aggiornamenti sul posto hanno il pieno supporto , almeno da RHEL 6 a RHEL 7 . Dalla mia esperienza posso dire che, sebbene fedupabbia ancora qualche nodo , si preannuncia uno strumento molto utile.

CentOS sta inoltre sperimentando un tipo di repository a rilascio progressivo, ma si applica solo tra versioni secondarie (ad es. 6.3-6.4).

La mia opinione sul tuo ultimo paragrafo:

Suppongo che ci sia l'angolo di gestione della configurazione, ma la maggior parte delle installazioni di Puppet che vedo non si traducono bene in ambienti con server applicativi altamente personalizzati (l'ambiente B potrebbe avere un singolo server il cui output ifconfig è simile a questo). Sarei interessante nel sentire suggerimenti su come utilizzare la gestione della configurazione per aiutare le organizzazioni a superare il bump della versione principale di RHEL.

Penso che il vero valore dei sistemi di gestione della configurazione, specialmente nel contesto dell'Ambiente B, sia che forniscono gli strumenti per costruire un servizio indipendentemente dai server che lo eseguono. Se un CMS non è stato utilizzato per creare i servizi esistenti, probabilmente non sarà di grande aiuto nel ricreare i servizi.

So che questo non risolve il tuo problema immediato, ma per me deriva dall'organizzazione che pensa in termini di server piuttosto che di servizi. Nel pensiero incentrato sul servizio, la personalità dei singoli server non deve essere mantenuta fintanto che il servizio continua a funzionare. Se un CMS viene utilizzato in modo disciplinato per costruire l'intero servizio, lo spostamento di tale servizio su un altro sistema dovrebbe essere relativamente semplice, poiché tutta la personalità della macchina sarà costruita dal CMS.

PS Non sono esattamente sicuro di cosa significhi l'output di ifconfig in questo contesto: è prodotto da un file di configurazione e da alcuni script (altrimenti non sarebbe presente all'avvio) e, se necessario, possono essere gestiti da un CMS.