I server RHEL6 possono essere "copiati"?

La mia azienda deve configurare un server di sviluppo e abbiamo già 2 server RHEL 6 di produzione che funzionano con uno switch L4.

Una delle soluzioni per configurare il server dev era quella di copiare semplicemente tutti i file da uno dei server di produzione e modificarlo un po '.

Non l'ho mai fatto prima, ma sembra simile all'immagine fantasma ... si può fare? È raccomandato? Sarebbe soggetto a errori?

La copia di tutti i file potrebbe funzionare. Dipenderà dal sistema operativo e dal tipo di metodo di copia.

Un problema generale sta provando a copiare il sistema mentre è in esecuzione. In genere almeno alcuni dei file verranno bloccati e quindi non verranno copiati correttamente. L'uso di un qualche tipo di software di imaging mentre il sistema è spento è generalmente più sicuro (hai menzionato Ghost, che ne è un esempio)

Perché non convertire i sistemi in esecuzione in macchine virtuali? Molti hypervisor come VMware o Hyper-V dispongono di uno strumento per convertire facilmente un sistema in esecuzione in una macchina virtuale.

È quindi possibile lavorare con un sistema non di produzione come desiderato prima di eseguire qualsiasi operazione su un server di produzione.

Grazie a @WernerCD

Vmware

Hyper-V

Si può fare?

Decisamente sì. Ho copiato un intero server Linux semplicemente impacchettando i file tared estraendoli nuovamente sul server di destinazione. L'unica avvertenza che ricordo era dover ricordare di usare --numeric-ownerdurante l'estrazione. Non posso parlare per altri sistemi operativi e altri strumenti, ma immagino sia fattibile con tutti i principali sistemi operativi.

Dovrebbe essere fatto?

Questa domanda è un po 'più complicata a cui rispondere. Non consiglierò semplicemente la clonazione di un sistema di produzione ai fini dello sviluppo. Potrebbe contenere molti dati utente e materiale chiave, che non si desidera avere presente nei sistemi di sviluppo.

Ma la clonazione del sistema di produzione può essere una buona idea per altri scopi.

L'approccio che consiglierei per creare un clone del sistema di produzione è il ripristino dal backup. È possibile evitare l'impatto delle prestazioni sul sistema di produzione ripristinando da un backup e si può testare la procedura di ripristino, il che è positivo.

È importante mantenere il clone ripristinato dal backup isolato dal resto del mondo. Poiché è stato ripristinato da un backup di un sistema di produzione, potrebbe contenere lavori automatizzati, che comunicheranno con altri sistemi di produzione e che disporranno delle credenziali per farlo.

Potresti potenzialmente causare molti danni se il clone potesse comunicare con sistemi di produzione reali.

Ma se lo tieni isolato, ti dà l'opportunità di verificare che il sistema ripristinato funzioni come previsto. Inoltre, un sistema così ripristinato potrebbe essere un ambiente utile per l'ultimo test del nuovo codice prima che venga distribuito alla produzione. Questa potrebbe essere la tua unica opportunità di testare il codice su dati utente reali, prima che sia effettivamente in grado di rompere il sistema di produzione.

Fattibilità

Certo, è possibile, perché non è difficile "installare" Linux usando mezzi non convenzionali. Ad esempio, è possibile replicare il server utilizzando rsync su SSH.

1. Avvia il computer di destinazione in un'immagine di "ripristino", sia che utilizzi un DVD Red Hat, un avvio live di Ubuntu, Knoppix, qualunque cosa.
2. Partizionare e formattare la macchina di destinazione e montare i filesystem in a /target.
3. rsync tutti i file system rilevanti oltre SSH (saltando /proc, /sys, swap).
4. Risolto /target/etc/fstab, soprattutto se le partizioni sono indicate dall'UUID.
5. Modificare il nome host e la configurazione di rete come appropriato.
6. Installa il boot loader.

Il passaggio 3 potrebbe consistere in più passaggi rsync, eventualmente aiutati da istantanee LVM sul computer di origine, l'ultimo passaggio con tutti i servizi sul computer di origine è stato interrotto per garantire la coerenza dei dati.

Desiderabilità e migliori pratiche

Solo perché puoi non significa che dovresti. Ho consigliato il processo sopra come un modo per eseguire una migrazione del data center. Tuttavia, il tuo caso d'uso è piuttosto diverso. Il ricorso alla clonazione evidenzia alcune carenze:

• La virtualizzazione sarebbe una buona capacità e renderebbe semplice la replica.
• Hai dei backup dei tuoi server di produzione? Perché non ripristinarli? Questo sarebbe un buon test della procedura di ripristino del backup.
• Hai documentazione su come riprodurre tutto da zero? Alla fine, probabilmente dovrai installarlo da zero, forse quando aggiorni il sistema operativo. Questa sarebbe una buona validazione per la tua documentazione.
• Meglio ancora, hai un'automazione che ti aiuta a riprodurre la tua configurazione? Uno script di shell potrebbe funzionare; una soluzione di gestione della configurazione come CFengine, Puppet, Chef o Ansible sarebbe ancora migliore.

Se cloni ciecamente il server di produzione, perderai una preziosa opportunità per chiarire esattamente cosa è in esecuzione su di esso.