Salin host Linux ke perangkat keras baru


13

Saya perlu melakukan migrasi host ke host dari perangkat keras lama ke perangkat keras baru. Secara khusus, dari HP BL460G7 ke HP BL460G8. Baik server lama dan baru memiliki drive 2 x 600GB 2,5 "dan dikonfigurasikan untuk RAID1. Saya dapat melakukan downtime 30 menit per server.

Ada empat server untuk dimigrasi, yang terkecil memiliki total 120GB yang dialokasikan dalam volume logis dan yang terbesar memiliki alokasi 510GB. Tiga server menjalankan RHEL5 dan satu menjalankan RHEL6.

Saya telah memeras otak saya tentang bagaimana melakukan ini dalam jangka waktu yang diberikan dan tanpa merusak OS dan data penting.

Satu-satunya pemikiran saya adalah ini:

  • hapus satu drive dari server lama (server dihidupkan)
  • hapus kedua drive dari server baru (server dimatikan)
  • hapus drive G7 dari caddy dan sisihkan
  • hapus drive G8 dari caddy dan instal ke caddy G7
  • instal G8 drive di G7 caddy ke server lama
  • tunggu pengontrol RAID untuk membangun kembali array RAID1
  • ketika selesai shutdown server lama
  • hapus drive G8 di caddy G7
  • instal G8 drive di G8 caddy dan masukkan ke G8 (drive tunggal terpasang)
  • boot server G8
  • tunggu OS untuk boot
  • ketika OS telah boot masukkan sisa drive
  • tunggu array RAID untuk membangun kembali

Apakah ini terdengar waras?

EDIT: The RHEL5 adalah RHEL5.10 dan RHEL6 adalah RHEL6.6

Saya seharusnya juga mencatat bahwa dua sistem adalah bagian dari cluster empat simpul panas yang melakukan replikasi aplikasi "peristiwa" yang konstan (bagian dari sistem infrastruktur kritis). Kami memiliki cadangan tetapi kami hanya menggunakan jika terjadi kegagalan total sistem.

Pengujian sebelumnya telah menunjukkan tentang 'dd' maksimum antara sistem sekitar 50MBps yang terlalu lambat.

EDIT: Saya akan mengandalkan kudzu untuk mengambil dan menangani perubahan perangkat keras.


Versi spesifik RHEL5 dan RHEL6 apa yang digunakan?
ewwhite

Dijawab dalam edit
user1174838

Jangan mencoba memasukkan disk G7 ke dalam server Gen8 - ada lebih banyak perubahan daripada sekadar baki fisik.
Chopper3

Secara sengaja menurunkan RAID dengan data penting tidak terdengar seperti rencana yang bagus.
kasperd

Jawaban:


18

Perlu dicatat, bahwa mungkin ada langkah-langkah lain yang diperlukan, tergantung pada distribusinya. Terutama para pembalap (terima kasih telah menunjukkan bahwa @ewwhite).

  1. Boot server baru dari livecd / usb.
  2. Persiapkan partisi dan bootblock pada drive baru.
    • Tergantung pada pengaturan, ini bisa dilakukan dengan menyalin MBR / bootblock.
  3. Buat sistem file.
  4. Lakukan rsync dari server lama ke yang baru.
    • Anda mungkin ingin melakukannya lagi untuk melihat berapa lama tindak lanjut rsync - jika kurang dari 30 menit, lanjutkan.
    • Inilah saatnya, Anda benar-benar dapat mencoba, jika sistem baru boot. Berhati-hatilah untuk tidak menyebabkan konflik IP (atau lainnya).
  5. Matikan semua layanan yang akan menulis ke sistem file
    • Lebih disukai reboot ke livecd / usb
  6. Rsync data dari server lama ke yang baru lagi
  7. Mulai ulang server baru dan gunakan

Melakukannya dengan cara ini, Anda masih memiliki server asli yang asli, jadi jika ada yang salah, ada cara mudah untuk kembali. Tetapi membutuhkan beberapa pengetahuan (grub / rsync / partisi), jadi saya sarankan melakukan beberapa persiapan dan pengujian terlebih dahulu, sebelum melakukannya secara langsung.


Sebenarnya ada perbedaan driver antara kedua platform, jadi penting untuk mengetahui rilis kecil RHEL yang dia gunakan.
ewwhite

Ah ya, saya seharusnya tidak menjawab apa pun yang terkait dengan distro perusahaan ... maaf soal itu ...
Fox

@Fox: Dihapus oleh permintaan populer. Jawabanmu bagus.
Sven

1
@ user1174838 yang seharusnya tidak menjadi hambatan ... satu-satunya masalah yang saya lihat adalah jumlah file kecil yang sangat besar.
Fox

1
Dan, jangan lupakan solusi yang luar biasa ini, bahwa rsync ganda meminimalkan waktu henti server: karena sebagian besar data ditransfer pada server yang sedang berjalan, rsync kedua (pada server yang sekarang tidak berfungsi) hanya menyalin perbedaan terbaru.
peterh

6

Dua hal:

  • Saya akan membangun data baru dan rsync.
  • Penjatahan / jendela waktu henti Anda tampaknya terlalu pendek. 30 menit dapat bekerja dalam situasi tertentu, tetapi bukankah ANDA harus mendikte persyaratan downtime yang realistis berdasarkan apa yang diperlukan untuk benar-benar menyelesaikan pekerjaan?

Bergantung pada data yang terkandung dalam setiap server, jumlah churn data , dan skema penyediaan Anda, mungkin masuk akal untuk menginstal OS yang diperlukan ke Gen8 ProLiant baru dan menyinkronkan pengaturan dan bagian data lainnya pada titik di mana Anda dapat menghentikan data.

Mungkin membuat salinan seed dan mendapatkan persyaratan downtime Anda dari jumlah waktu yang diperlukan untuk mengambil perubahan file pada rsyncs berikutnya. Jika Anda perlu mempercepat proses transfer atau memiliki banyak file kecil, ada teknik yang dapat membantu .

Saya sering membuat transisi semacam ini. Dengan instalasi Linux yang serupa, Anda jarang membutuhkan lebih dari sekadar daftar paket yang akurat (mudah didapat melalui Yum atau RPM), direktori konfigurasi (mis. /etc) Dan partisi data Anda. Jika Anda belum memiliki sistem penyediaan kickstart, Anda dapat memanfaatkan /root/anaconda-ks.cfgfile untuk mendapatkan ide tentang bagaimana sistem G7 dibangun.

Untuk menjawab pertanyaan Anda tentang hanya memindahkan disk, berdasarkan versi RHEL spesifik yang Anda sebutkan, ini sangat mungkin. Anda dapat memindahkan disk / caddies dan metadata HP Smart Array kompatibel antara pengontrol P410 dan P420 yang mungkin ada di sistem Anda. Namun, saya tidak akan melakukan ini tanpa memperbarui sepenuhnya firmware drive dan komponen dalam sistem baru terlebih dahulu.


Beberapa komentar yang sangat bagus di utas ini, terima kasih semua. Saya akan kembali ke PM dan meminta jendela perubahan yang lebih besar.
user1174838

1

Jika versi OS Anda sebelumnya dapat menangani Perangkat Keras baru (kebanyakan pengontrol RAID), Anda dapat mencoba CloneZilla .

Untuk memeriksa apakah mungkin untuk berpindah dari satu perangkat keras ke perangkat lain, Anda harus meneruskan semua data dari server lama ke server baru melakukan beberapa trik dengan dd.

Boot server baru dengan distro langsung seperti SystemRescueCD , konfigurasikan dengan alamat IP dan perintah dd seperti ini:

nc -l 8000 | dd of=/dev/sda

Di server saat ini melakukan

dd if=/dev/sda | nc ${newserverip} 8000

Ini akan membuat salinan mentah dari server / dev / sda Anda ke server baru / dev / sda. Dengan cara ini Anda dapat melakukan tes tanpa downtime di server asli Anda dan mengambil risiko hampir nol.


2
Jika Anda membiarkan proses berjalan pada server lama yang menulis ke file pada disk lama, terutama server database dan sejenisnya, kemungkinan sangat tinggi bahwa ini akan meninggalkan Anda dengan sistem file korup (disalin) dan data korup dalam file Anda (disalin). Jangan pernah disk mentah kecuali itu di-mount atau di-mount hanya-baca.
Guntram Blohm mendukung Monica

@ GuntramBlohm saya tahu, itu hanya untuk memeriksa apakah Anda dapat mengkloning server lama ke yang baru, tanpa donwtime. Setelah diuji, Anda dapat mengkloning server, tentu saja mematikannya atau menghentikan layanan utama.
alphamikevictor

CloneZilla dan teknik terkait akan membutuhkan waktu lebih dari 30 menit untuk menyalin data antar sistem.
user1174838

0

Manajer proyek telah menolak permintaan saya untuk jendela pemadaman yang lebih besar.

Prosedur yang diusulkan yang dijabarkan dalam pertanyaan tersebut bekerja dengan baik dalam pengujian. Waktu henti adalah di bawah 20 menit. Saya menggunakan utilitas hpacucli untuk memantau kemajuan pada G7 dan kemudian Gen8, itu sangat berguna untuk ini.

Saya belum melakukan ini dengan marah tetapi sebagaimana dinyatakan ini telah bekerja dengan baik dalam pengujian untuk RHEL 5.10 pada BL460G7 hingga BL460 Gen8.

Saya tidak memperbarui firmware.

RAID1 awal yang disinkronkan di G7 membutuhkan waktu lebih dari satu jam. Sinkronisasi ulang di Gen8 berlangsung di bawah 50 menit. Ini membuat saya khawatir tetapi saya tidak dapat menemukan masalah.

Sekali lagi terima kasih atas semua komentar dan saran yang bermanfaat.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.