Abbiamo un'applicazione in esecuzione su alcune caselle (circa 5 e crescerà). L'hardware è identico in tutte le macchine e idealmente lo sarebbe anche il software. Finora li gestisco a mano e non ne ho più voglia (indirizzi IP statici, disabilitazione di tutti i servizi necessari, installazione dei pacchetti richiesti ...). Qualcuno può bilanciare i pro e i contro delle seguenti opzioni o suggerire qualcosa di più intelligente?

1: Installa individualmente centos su tutte le scatole e gestisci le configurazioni con chef / cfengine / burattino. Questo sarebbe positivo, poiché volevo una scusa per imparare a utilizzare una delle applicazioni, ma non so se questa sia effettivamente la soluzione migliore.

2: Rendi perfetta una scatola e immaginala. Servire l'immagine su PXE e ogni volta che voglio apportare modifiche, posso semplicemente riavviare le caselle da una nuova immagine. Come fanno normalmente i ragazzi del cluster a gestire cose come avere indirizzi mac nei file / etc / sysconfig / network-scripts / ifcfg *? Usiamo anche infiniband e si rifiuta anche di avviarsi se hwaddr è sbagliato. Questi possono essere generati correttamente all'avvio?

Mi sto orientando verso la soluzione PXE, ma penso che il monitoraggio con Munin o Nagios sarà un po 'più complicato con questo. Qualcuno ha esperienza con questo tipo di problema?

Tutti i server hanno SSD e sono veloci e potenti.

Grazie, opaco.

Il tuo cluster suona più come un cluster HPC che uno OLTP come il mio, ma penso che l'installazione che sto usando funzionerebbe anche per te. Lo chiamo "mpdehaan trifecta" perché questo è l'ircnick del ragazzo che ha scritto o gestisce i tre strumenti coinvolti.

1.) Cobbler per il provisioning di build di base. Cobbler è un progetto che mira ad essere l'intersezione dei sistemi kickstart, pxe, yum-repo, dhcp, dns, ecc. È di gran lunga il modo più semplice per avviare e avviare una configurazione kickstart e puoi aumentare le altre funzionalità secondo necessità.

2.) Puppet per la gestione della configurazione. Idealmente il vostro calzolaio costruito padroni di casa sono molto barebone configurazioni che sanno appena sufficiente per telefonare a casa al server fantoccio all'avvio. Puppet applicherà quindi le impostazioni di configurazione e le manterrà per sempre coerenti nel tuo ambiente.

3.) Func per comandi ad hoc su più macchine in parallelo. Ad esempio "distribuisci un nuovo checkout svn del codice e riavvia apache". È abbastanza facile usare solo func per chiamare lo stesso comando bash su un gruppo di server come cluster-ssh. Se vuoi davvero entrarci, puoi scrivere i tuoi moduli con un pitone davvero semplice.

Tutti e tre questi strumenti hanno buoni wiki e canali irc attivi per aiuto su freenode.

Panoramica

In un certo senso, hai due domande qui ...

• Come posso creare e gestire server standard?
• Come posso mantenere la configurazione standard e apportare modifiche in seguito?

Ho diviso la mia risposta qui sotto affrontando queste due cose separatamente ma sono strettamente correlate. Sto affrontando le soluzioni tecnologiche qui e non nessuna delle migliori pratiche correlate, come il controllo delle modifiche.

Se ciò non copre l'ambito della tua domanda, ti preghiamo di chiarire e sarò felice di elaborare. Questa è la base necessaria, fondamentale per un'infrastruttura tecnologica ben gestita.

Server di costruzione

Non mi piacciono le immagini nel mondo UNIX; questo è più di un approccio in stile Windows. Anche alcune persone di Windows sembrano ora concentrarsi nuovamente sugli script per build standard.

Il satellite sembra diventare un po 'popolare nel mondo RHEL. Spacewalk è la controparte Open Source. Devi assolutamente acquistare l'approccio RHEL per usarlo. Questo serve sia per la creazione di server che per la gestione della configurazione.

Idealmente, si desidera stabilire mirror e repository locali su un file server per tutto il software necessario.

Innanzitutto, sfrutta l'automazione della tua distribuzione, come Kickstart in RHEL / CentOS. Il kickstart sarebbe una base con variazioni, a seconda delle tue esigenze. Le build di Kickstart possono essere avviate da un server PXE.

Per la parte più avanzata della build e tutto ciò che non era adatto per un file Kickstart, puoi scrivere i tuoi script personalizzati. Tuttavia, potresti trovare burattino o cfengine che funziona bene per te invece di script personalizzati. Ho scoperto che gli script personalizzati sono i più flessibili e non si limitano a nessun singolo approccio.

Se scegli di scrivere i tuoi script, ti consiglio uno script di base per la configurazione universale. Si tratterebbe di configurazione della sicurezza, protezione e tutto ciò che si applica a tutte le build. Quindi uno script finale per finalizzare il ruolo del server. Ad esempio, un server Web o un server di database.

Mantenimento degli standard

Ciò che descrivi rientra anche nel mantenimento delle configurazioni. Standard di build, aggiornamenti software e altre cose sono correlati alle build ma in molti modi separati.

Se si sceglie di fare affidamento sui pacchetti di sistema anziché sulla creazione di build basate sul codice sorgente per i ruoli del server più importanti, è possibile gestirne gran parte con utilità di sistema native. Questo può essere un semplice script per eseguire un forciclo sull'elenco dei server ed eseguire un yum -y update package.

Per la gestione della configurazione, è qui che entrano in gioco le marionette, cfengine e altre utility di gestione della configurazione . Queste sono utility molto utili e forniscono le basi necessarie senza scrivere i tuoi script da zero.

Quando aggiorni gli standard di configurazione per i tuoi server, è importante riempire di nuovo questo nelle build del server standard.

Di recente ho concluso un grande progetto per implementare un sistema centralizzato di build / provisioning e gestione della configurazione presso $ WORK. Stiamo eseguendo CentOS.

Il mio design, che mi piace davvero, ci offre un processo di creazione praticamente con un clic (beh, una pagina Web GUI), utilizzando alcuni script PHP personalizzati per collegare tutto insieme attraverso un'interfaccia utente Web semplice ma efficace.

La teoria generale è:

1. Esegui tutte le installazioni da un singolo file KickStart minimalista unificato (bene, OK, uno per x86 e uno per x86-64, ma comunque file praticamente identici con una selezione minima del pacchetto).
2. Bootstrap di script postinstall di KickStat Puppet.
3. Puppet applica tutta la configurazione specifica del nodo / host, l'installazione del pacchetto, ecc.

Sono d'accordo che le immagini non sono un modo Unix di fare le cose ... sono davvero più adatte al mondo di Windows in cui l'installazione e la configurazione tramite script / automatizzate non sono così semplici.

Puppet può essere sostituito con qualsiasi altro sistema di gestione della configurazione adatto al conto, ma mi è capitato di apprezzare la natura dichiarativa di Puppet e il suo concetto di convergenza.

Questo sistema offre numerosi vantaggi:

• Puppet gestisce tutto oltre un'installazione di base generica, quindi tutti i pacchetti e la configurazione richiesti sono in un unico posto.
• I manifesti Puppet servono come ulteriore fonte di documentazione di basso livello.
• Fintanto che rimani con Puppet (cioè non apporta modifiche alla configurazione locale, o ricollegali in Puppet) è banale costruire un duplicato di una macchina.
• Poiché tutti gli host sono creati da una base comune, è possibile preinstallare hardware o VM con il set di pacchetti di base (KickStart) e trasformarli in nodi funzionali semplicemente aggiungendo le classi necessarie.
• Puppet consente di "taggare" gli host per la produzione o lo sviluppo, quindi è incredibilmente facile creare una copia di sviluppo / test di un host, aggiornare i pacchetti o apportare modifiche di configurazione in base alle esigenze, testare e quindi ricollegarli alla produzione.

Se segui il percorso pxe, assicurati di dare un'occhiata

http://etherboot.org/wiki/index.php

Gpxe ti darà maggiore flessibilità con i target di avvio. È abbastanza facile avviare un aoe blade e non c'è niente come l'avvio di un kernel da un server http remoto !!!!!!!!!! :-).

Quali tempi di funzionamento del server sono necessari?

È impossibile creare un'immagine perfetta, poiché sarà sempre necessario applicare patch di sicurezza e aggiornamenti software. Se sono rivolti a Internet, non puoi semplicemente ignorare le patch.

Sul lato pxe, hai alcune opzioni, a seconda dell'I / O dei file del tuo cluster. O basta avviare un kernel e montare il disco in remoto su aoe o iscsi.

Puoi anche fare alcune cose molto intelligenti con la copia su immagini di scrittura. È ottimo per gli aggiornamenti e il rollback di eventuali modifiche che potrebbero essere problematiche.

Ho anche avuto successo usando nfs root, usando una soluzione nfs in cluster. È possibile specificare diversi file da offrire in base agli indirizzi dei client.

Ancora una volta, è necessario verificare se alle proprie applicazioni piace eseguire nfs. Non è adatto per ogni carico di lavoro.

cluster nfs sever può contenere 192.168.0.1:/etc/hostname 192.168.0.2:/etc/hostname

quindi, ogni client fa riferimento allo stesso file, ma viene servito il file rilevante per il client. È roba abbastanza impressionante, tuttavia non è semplice!

Tutto questo ti darà tempi di implementazione più rapidi se centralizzi il file system sulla memoria di rete. L'imaging di un sistema operativo su una rete su un disco remoto richiede tempo !!!!

Se stai usando una di queste soluzioni, assicurati di avere un livello di rete ben progettato e tollerante ai guasti e che il tuo server nfs / SAN sia ben progettato + sicuro!

Perdere la connessione NFS / SAN sarebbe dannoso per la salute del server. :-(

È abbastanza facile creare alcuni script per tftp / pxe per controllare il processo di avvio.

Se sapessi di più cosa stai effettivamente cercando di raggruppare, potrei forse pensare a una soluzione più adatta a te.