Ho molti server Linux (SUSE 9 e 10) utilizzati per eseguire servizi Web che forniscono dati a griglie di calcolo di grandi dimensioni. Di recente abbiamo avuto delle interruzioni difficili da spiegare (ad es. I registri hardware e software non mostrano alcun errore evidente) e stiamo iniziando a chiederci se il problema sia il tempo di attività prolungato (in genere 200-300 giorni). Dato che questi server sono fortemente utilizzati, dovrei considerare un ciclo di riavvio regolare?
Risposte:
Devi riavviare dopo un aggiornamento del kernel (a meno che tu non stia usando KSplice), qualsiasi altra cosa è facoltativa. Personalmente riavvio su un ciclo mensile durante una finestra di manutenzione per assicurarmi che il server e tutti i servizi tornino come previsto. In questo modo posso essere ragionevolmente certo se devo fare un riavvio fuori programma (ad es. Aggiornamento critico del kernel) che il sistema tornerà correttamente. Anche il monitoraggio automatizzato di server e servizi (ad esempio Nagios) contribuisce notevolmente a questo processo (riavviare, guardare le luci rosse e poi, si spera, tutte di nuovo verdi).
PS se riavvii regolarmente, ti consigliamo di ottimizzare i controlli fsck (ovvero il conteggio massimo dei montaggi tra i controlli in modo appropriato, altrimenti un riavvio rapido di 2 minuti potrebbe richiedere 30 minuti se il server inizia a caricare un paio di terabyte di dati. In genere imposto il conteggio dei montaggi su 0 (tune2fs -c 0) e l'intervallo tra i controlli su circa 6 mesi e poi forza manualmente un fsck di tanto in tanto e resetto il conteggio.
In realtà riavvio i miei server su base abbastanza regolare, ogni volta che vengono apportate importanti modifiche alla configurazione. È importante sapere che in caso di emergenza il software del server si presenterà senza problemi. L'ultima cosa che vuoi è trovarti in una posizione in cui stai provando a recuperare da un'interruzione ma devi fare confusione con la configurazione del tuo server perché non l'hai testato completamente quando lo hai impostato.
I server Linux non devono mai essere riavviati a meno che non sia assolutamente necessario modificare la versione del kernel in esecuzione. La maggior parte dei problemi può essere risolta modificando un file di configurazione e riavviando un servizio con uno script init.
È necessario fare attenzione ai riavvii ... se si è modificato qualcosa "al volo" senza riflettere le modifiche nel file di configurazione di un servizio, tali modifiche non verranno applicate dopo un riavvio.
Di solito, però, riavvio dopo gli aggiornamenti di sistema programmati. In genere non è necessario, ma li faccio quando nessuno è in ufficio, quindi perché no? Ci sono spesso aggiornamenti del kernel quando riesco a fare l'aggiornamento, comunque.
Non è davvero necessario, la gestione della memoria di Linux è eccellente. Ma se hai tempi di attività di quella lunghezza probabilmente stai eseguendo kernel con vulnerabilità conosciute - potresti volerlo guardare.
Penso che dovresti riavviare se c'è stato un recente aggiornamento del kernel O un aggiornamento libc. Molte cose sono collegate a libc e non è davvero possibile scaricare completamente quella lib dalla memoria e sostituirla con la nuova versione a meno che non si riavvii.
Ad esempio, anche cose di base come / bin / ls e altre cose in / bin usano libc. Se stai solo eseguendo una console e usando bash, stai usando libc.
$ ldd /bin/bash
linux-gate.so.1 => (0xffffe000)
libtermcap.so.2 => /lib/libtermcap.so.2 (0xb8029000)
libdl.so.2 => /lib/libdl.so.2 (0xb8025000)
libc.so.6 => /lib/libc.so.6 (0xb7ed9000)
/lib/ld-linux.so.2 (0xb804b000)
$ ldd /bin/ls
linux-gate.so.1 => (0xffffe000)
librt.so.1 => /lib/librt.so.1 (0xb7f3a000)
libacl.so.1 => /lib/libacl.so.1 (0xb7f33000)
libc.so.6 => /lib/libc.so.6 (0xb7de7000)
libpthread.so.0 => /lib/libpthread.so.0 (0xb7dd0000)
/lib/ld-linux.so.2 (0xb7f61000)
libattr.so.1 => /lib/libattr.so.1 (0xb7dcc000)
E sì, se cambiate i file in /etc/init.d che influiscono in qualche modo sull'avvio, consiglierei un riavvio. Non vuoi scoprire di aver fatto un piccolo errore in un file di avvio quando hai bisogno che le cose funzionino e funzionino rapidamente.
Se un server è passato molti giorni senza riavviare, in realtà significa che non c'è modo di essere sicuri che tornerà correttamente. Ancora una volta ciò è dovuto al fatto che molti file di configurazione potrebbero essere stati modificati su di esso e nessuno lo ha riavviato a lungo per assicurarsi che arrivi. Inoltre, se il server ha molti aggiornamenti dovuti e non si è riavviato da molto tempo, riavviare prima di applicare gli aggiornamenti, altrimenti in caso di problemi, non si può essere sicuri che sia stato causato da un errore di configurazione a molto tempo fa o i nuovi aggiornamenti che hai applicato.
Infine, se riavvii un server critico dopo un tempo molto lungo, fsck potrebbe significare che devi aspettare molto tempo prima che ritorni. Puoi usare tune2fs per evitarlo, ma suppongo che sia una buona idea controllarlo regolarmente. Questo è il motivo per cui non dovresti essere in una posizione in cui sei dipendente da un solo server e, se ciò accade, l'intero sito Web è sparito. Dovresti averne un altro in standby.
Un'altra cosa da cercare mentre si hanno questi tempi di inattività imprevisti, è vedere esattamente come vengono utilizzati la memoria e il processore e da quali programmi.
topdovrebbe essere in grado di determinare quali processi sono i colpevoli della perdita di risorse e quindi essere in grado di gestirli direttamente. Un'altra idea sarebbe quella di inizializzare un cronjob per arrestare e riavviare i processi secondo una pianificazione specifica.
Non è una cattiva idea riavviare se è stato così a lungo in modo da poter eseguire un controllo del disco (fsck) sulla partizione di root. Il tuo argomento può essere che questo aiuta a garantire l'integrità dei dati.
Un server Linux correttamente eseguito dovrebbe essere necessario solo riavviare per gli aggiornamenti del kernel. Lo stesso non si può sempre dire per alcuni software, ad esempio a volte devo riavviare apache2 o mailman.
La mia infrastruttura ha due siti di dati, l'alfa (dove le operazioni si svolgono su base giornaliera) e la beta (il sito di backup, nel caso in cui le cose andassero orribilmente male su Alpha). Anche se questo non è attualmente il caso, sto spingendo per programmare i tempi di inattività sul sito alfa ogni 6 mesi, in modo da poter eseguire tutti i servizi dalla beta.
Questo compirà due cose. Innanzitutto, dimostrerà che il nostro sito di ripristino di emergenza è completamente praticabile. In secondo luogo, mi darà una settimana di tempo per rimuovere l'innesto accumulato all'alfa.
Così com'è, non riavvio i miei server così frequentemente come dovrei. Sono d'accordo con gli altri poster che hanno affermato che è importante sapere che i tuoi server torneranno indietro quando ne avrai bisogno. Non vuoi "pensare" che lo faranno, solo per scoprire che hai cambiato qualcosa e non l'hai fatto correttamente, o non documentato.
È inoltre possibile scrivere alcuni script che controlleranno (per quanto è possibile), se lo stato corrente della macchina sarà lo stato della macchina dopo il riavvio.
Quello che voglio dire con questo è ...
/etc/init.d/*
/etc/fstab
/etc/mtab) Abbiano una voce corrispondente in/etc/fstab/etc/fstabsiano attualmente montati.Questo ovviamente non è un controllo completo in alcun modo, ma riduce il rischio di problemi dopo il riavvio.
Oltre a ciò, dovresti (imo) impostare una politica per gli aggiornamenti dei pacchetti server, in un certo ordine ragionevole, ad esempio 1 gruppo a settimana ...
Inoltre ha un piano generale, come "Tutti i server passeranno attraverso un aggiornamento completo del sistema operativo una volta ogni 6 mesi".
Dipende dalle attività in esecuzione sul server. Per alcuni server virtuali utilizziamo spesso il riavvio anziché il riavvio di apachectl e richiede solo 5-10 secondi in più. Ma alcune macchine pesanti vengono riavviate più volte all'anno con un intero team di amministratori che monitora il processo.