Ke tanah dari awan: memindahkan Proxmox ke komputer di kantor Federasi Rusia

Selamat siang, Habr!



Saya ingin menyampaikan kepada Anda sejarah singkat pemindahan satu server virtualisasi berbasis Proxmox dari Hetzner ke Federasi Rusia ke server virtualisasi yang terletak di rak di kantor perusahaan.

Secara singkat tentang alasan memilih Proxmox, fitur-fiturnya. Wikipedia tentang sistem virtualisasi Proxmox .



Diposting sebagai panduan untuk diri Anda sendiri dan mereka yang ingin, agar tidak memulihkan urutan tindakan dan tidak membuang waktu pada perangkap tersebut, yang sebenarnya dijelaskan dalam artikel di bawah.



Singkatnya, keinginan utamanya adalah tidak perlu mengelola proyek yang sedang berjalan; tidak perlu pembaruan, hanya ketika patch keamanan dirilis; kesederhanaan antarmuka web. Karena fakta bahwa perusahaan tidak memiliki staf ahli linux yang sebenarnya. Jadi, standar Debian praktis memutuskan semua pertanyaan yang mendukung Proxmox. Kelebihan lainnya adalah beban rendah pada prosesor oleh kernel virtualisasi - memang demikian.



Saya memuji sistemnya, saya meminta sisanya dipotong.



Sehubungan dengan pertumbuhan nilai tukar Euro, jasa sewaan untuk penyediaan tempat kerja jarak jauh pada server yang disewa khusus mulai naik harganya. Setelah perhitungan, diputuskan untuk membeli dalam konfigurasi fisik "Prosesor 8 x AMD Ryzen 5 1400 Prosesor Quad-Core (1 Soket)", 2 * SSD M.2 1TB + anak tangga untuk dipasang di port PCI-E, RAM 32 Gb ... Di cloud, CPU mesin yang sama 8 x Intel® Core (TM) i7 CPU 920 @ 2.67GHz (1 Socket), HDD 2 * 2TB, RAM 47,16 Gb.





Pengaturan penyimpanan Proxmox di luar kotak didasarkan pada volume LVM, meskipun dimungkinkan untuk menggunakan folder OS dan opsi sistem file lainnya untuk penyimpanan gambar, dan bahkan sumber daya FTP eksternal (lebih lanjut tentang ini di bawah). Pada mesin ini, partisi LVM dengan nama "data" dikonfigurasi pada disk 1 dan penyimpanan data proxmox bernama "data" terdaftar, ini menyimpan gambar disk mesin virtual. Cadangan (snapshot) mesin virtual disimpan ke disk kedua sesuai dengan jadwal tertentu.



Di cloud, dua node klien diluncurkan dengan 4 CPU masing-masing 16GB RAM dan dengan jenis prosesor core2duo. Disk virtual mereka sepenuhnya 2TB.





Untuk memindahkan, kami menganalisis konfigurasi disk, melihat ukuran cadangan penuh untuk menentukan ukuran node yang dikompresi dan lokasi penyimpanan (ke node baru atau ke penyimpanan kantor):

• Node 1: 200Gb + 400Gb + 200Gb; Ukuran cadangan 175Gb
• Node 2: 200Gb + 500Gb; Ukuran cadangan 7Gb;

Kami meminta klien untuk memberikan akses dan menentukan bahwa Node 2 disk 2 tidak digunakan, meskipun aktif. Oleh karena itu, pada mesin asli di cloud, Anda harus mengonfigurasi OS tamu dengan benar dan menonaktifkan disk 500 GB di antarmuka web Proxmox. Dalam kasus ini, ia akan tetap terikat ke Node 2, tetapi akan "dinonaktifkan", yaitu, Node 2 tidak akan melihatnya.



Di antarmuka web, cadangan dibuat dengan perubahan yang dibuat dengan kompresi maksimum gambar disk di GZip. Kami mendapatkan 6 Gb yang sama di arsip, yang sebenarnya diharapkan.



Ruang kantor memiliki penyimpanan dengan akses FTP, 1TB dialokasikan untuk mengunggah gambar yang diarsipkan dari mesin virtual, jadi diputuskan untuk menghubungkan penyimpanan ini melalui FTP ke folder "/ bkps" dari OS cloud.







Pada server penerima, disk dikonfigurasi sebagai berikut: LVM data1 pada 1TB-> Storage data1; LVM data2 sementara pada SSD 256Gb -> Penyimpanan data2. Setelah mentransfer gambar mesin ke FTP-ball, hubungkan menggunakan metode yang dijelaskan di atas ke direktori / bkps dari server penerima. Di penyimpanan server penerima, hubungkan direktori "/ bkps" sebagai penyimpanan cadangan dan coba pulihkan ke Node 2 yang dibuat sebelumnya dari antarmuka Web. Masalah pertama:

1. Ternyata pengaturan Node sepenuhnya ada di arsip, jadi tidak perlu membuat yang serupa di receiver menggunakan salin-tempel.
2. Ternyata membongkar gambar dalam sistem memerlukan penyimpanan "data", tetapi kami tidak memilikinya, sehingga proses membuka ritsleting berhenti dengan kesalahan.

Upaya untuk mengedit file "2.tar.bz2 Node Archive" di MC gagal. Saya mencoba pada node 2 yang dihentikan dari konsol server virtualisasi menggunakan

dd if=/data/vm-101-disk-0 | grep -9cf > /bkps/vm-101-disk-0.img.gz
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

unggah ke FTP dan terapkan di server penerima dari konsol ke gambar yang dibuat pada data2 LVM bernama "/ dev / data2 / vm-101-disk0" menggunakan perintah:

cd /bkps
ls | grep vm101
gunzip -c vm101-disk-0.img.gz | dd of=/dev/data2/vm101-disk-0
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
    

Di akhir proses, Node 2 dimulai dengan benar, OS tamu mulai bekerja tanpa manipulasi lebih lanjut.



Dengan Node 1, prosesnya menjadi lebih rumit, karena menggunakan DD tidak mungkin untuk memperluas disk 2 ke 400Gb. Apa alasannya masih belum saya ketahui. Ketika waktu hampir habis, keputusan Solomon dibuat: untuk mengganti nama Penyimpanan server penerima dari "data1" menjadi "data" dan menerapkan Node 1 dari cadangan. Dalam konfigurasi ini, proses berjalan dengan baik, mesin memulai dan bekerja dengan benar, melihat semua disk yang terhubung.



Dan sebagai kesimpulan, secara singkat tentang memigrasi disk di dalam server antar penyimpanan.

1. Kami menghentikan simpul.
2. Dalam pengaturan konfigurasi node, kami mengarahkan ke disk yang perlu dimigrasi. Aneh bahwa ini hanya berfungsi pada disk yang terhubung, dan disk yang tidak "terpasang" tidak dapat dimigrasi.
3. Kami memilih penyimpanan target dan sistem memindahkannya ke penyimpanan yang diperlukan.

Berdasarkan kesimpulan, adalah mungkin untuk bergerak seperti ini (cara bonus untuk bergerak bagi pembaca yang paling gigih):

1. di server-in-the-cloud, mulai migrasi ke direktori sembarang drive Node1 dan Node2;
2. mentransfernya dengan menyalin ke FTP (ini bisa saja dikompresi dengan gzip yang sama untuk mengurangi lalu lintas);
3. menyebarkan file disk virtual di server FTP jika kami mentransfer gambar terkompresi;
4. hubungkan (tanpa memulai) ke Node yang diperlukan dan tekan tombol "migrasi".

Manipulasi ini akan menyebabkan migrasi reguler gambar disk virtual ke penyimpanan yang kami butuhkan.



Terima kasih atas perhatian Anda, semoga seseorang akan merasakan manfaat teks ini.