Clever Geek Handbook

Integrasi Rosplatform hyperconverged di HPE Synergy dengan sistem penyimpanan 3PAR



Entah bagaimana, Rosplatform (R-Virtualization dan R-Storage) perlu diintegrasikan dengan sistem penyimpanan perangkat keras ( 3PAR ), dan ini bisa sangat berguna dalam berbagai skenario.

 

Konfigurasi sinergi



Sebelumnya, integrasi semacam ini telah diuji pada bilah (Blade CH121 v5) dari blade tengah Huawei dengan sistem penyimpanan Dorado 5000 v3, di mana SDS (penyimpanan yang ditentukan perangkat lunak) dari P-Storage Rosplatforma di atas sistem penyimpanan menunjukkan dirinya cukup baik karena semua flash, tetapi dengan Synergy , jika tersedia Disk JBOD dari modul D3940, semuanya jauh lebih menarik dan fleksibel.



3 Server Blades (Synergy 480 Gen10 (871940-B21)):



  • Masing-masing memiliki dua CPU Intel® Xeon® Platinum 8270.
  • Jaringan dua port 20 Gb / s.
  • RAM 256 GB.
  • Tidak ada hard drive di bilahnya.
  • Dalam modul disk Synergy 2HDD, 900GB dalam RAID1 untuk setiap OS / hypervisor dan 3SSD HPE VK0960GFDKK 960GB untuk peran metadata + cache (masing-masing untuk satu server), serta 9HDD EG0900JFCKB untuk 900GB.


OS dimuat melalui saluran melalui pengontrol RAID dari modul disk Synergy.

SDS lokal digunakan melalui saluran JBOD dari modul disk Synergy.



Konfigurasi 3PAR



3PAR (FC16 Gb / s) terhubung ke Synergy:

One LUN (one to many) RAID6 dari SSD dengan kapasitas 200GB. 9 LUN RAID6 dari HDD, masing-masing dengan kapasitas 150GB (tiga LUN per blade).





Angka: 1 Tata letak bangku uji.





Deskripsi skenario



Kami menguji beberapa opsi untuk integrasi dengan 3PAR, yang juga dapat digunakan secara bersamaan sekaligus dalam konfigurasi campuran.



Skenario dengan penyebaran SDS dari Rosplatform pada LUN terpisah masing-masing 150GB dari 3PAR:





Gambar. 2 Skenario dengan penyebaran SDS dari Rosplatform pada LUN terpisah

dengan sistem penyimpanan untuk setiap node dari ketiganya diberikan FC dengan 3 LUN 150GB.



Pada sistem penyimpanan, mereka dikonfigurasi dalam RAID6 dari disk HDD. Pada Gambar. Gambar 2 menunjukkan secara skematis 10 Gb dan sebuah sakelar, tetapi implementasinya berada pada level sakelar Synergy dengan port 20 Gb, di mana satu antarmuka untuk manajemen dan virtualisasi, dan yang lainnya untuk penyimpanan SDS.



Skenario ini telah diuji untuk memverifikasi bahwa opsi berikut berfungsi:



  • SDS Rosplatform bekerja di atas 3PAR.
  • Memperkuat SDS Rosplatforma melalui 3PAR dengan menambahkan cache SSD lokal.
  • Dengan membuat platform SDS kecil untuk menyimpan file konfigurasi VM, di mana VM itu sendiri dibuat di LUN 3PAR.
  • Menguji SDS Rosplatforma di atas 3PAR, menentukannya dengan tanda hubung yang sedikit lebih lambat daripada setrip disk lokal.


2) Skenario dengan membuat VM pada LUN dari 3PAR:





Gbr. 3 Skenario dengan membuat VM pada LUN dari 3PAR.



LUN 200GB RAID6 dari SSD untuk VM disajikan dengan penyimpanan. Konfigurasi LUN adalah satu ke banyak.

Skenario ini telah diuji untuk memverifikasi kapabilitas:



  • Lampirkan ke VM LUN dari 3PAR secara langsung.
  • Menggunakan VM LUN yang terpasang sebagai disk utama tanpa menggunakan qcow2.
  • Menggunakan beberapa VM dengan 200 GB LUN yang sama yang terpasang untuk penginstalan selanjutnya dari sistem file cluster tamu.
  • Memigrasi VM dengan 200 GB LUN dari 3PAR dan node mengalami error saat memulai ulang VM ini di node yang tersisa.
  • Menggunakan SDS dari 3PAR sebagai penyimpanan file konfigurasi VM, dan OS tamu dengan penerapan ke LUN dari 3PAR secara langsung.
  • Menggunakan SDS pada disk lokal modul Synergy sebagai penyimpanan file konfigurasi VM, dan OS tamu dengan penerapan pada LUN 200GB dari 3PAR secara langsung.


Deskripsi pengaturan



Untuk semua skenario di setiap node, sebelum penerapan cluster biasa, pengaturan yang sama telah dibuat sebelumnya, yang dilakukan segera setelah menginstal tiga node dari image Rosplatform. Panduan penginstalan singkat, menyiapkan cluster itu sendiri tersedia di artikel sebelumnya .



1. mengaktifkan layanan multipath untuk memuat otomatis: 



#chkconfig multipathd on


2. mengaktifkan pemuatan modul: 



#modprobe dm-multipath
#modprobe dm-round-robin


3. menyalin template konfigurasi ke folder untuk konfigurasi yang berfungsi: 



#cp /usr/share/doc/device-mapper-multipath-0.4.9/multipath.conf /etc/


4. periksa pola inklusi di bawah parameter berikut: 



defaults {
        user_friendly_names yes
        find_multipaths yes
}


5. menambahkan alias untuk disk bersama untuk VM: 



multipaths {
        multipath {
#               wwid                    3600508b4000156d700012000000b0000
#               alias                   yellow
#               path_grouping_policy    multibus
#               path_selector           "round-robin 0"
#               failback                manual
#               rr_weight               priorities
#               no_path_retry           5
#       }
        multipath {
                wwid                    360002ac0000000000000000f000049f4
                alias                   test3par
        }
}


6. centang untuk memulai layanan: 



#systemctl start multipathd


7. Memeriksa layanan dan menampilkan perangkat dengan mpath: 



#multipath –ll


8. Reboot wajib: 



#reboot


9. Memeriksa layanan dan menampilkan perangkat dengan mpath: 



#multipath –ll


Selanjutnya, pengaturan cluster standar dilakukan.





Angka: 4 UI web sebelum mengaktifkan layanan multipath.





Angka: 5 Setelah mengaktifkan layanan multipath, perangkat dm muncul.



Tangkapan layar setelah membuat kluster Rosplatforma, di mana 200 GB LUN untuk VM secara khusus dengan peran yang belum ditetapkan:





Gbr. 6 Screenshot setelah membuat cluster Rosplatforma.



Tangkapan layar menunjukkan dua tingkat0 dan tingkat1, di mana tingkat0 adalah SDS lokal, dan tingkat1 adalah SDS di atas 3PAR:





Gambar. 7 SDS lokal dan lebih dari 3PAR.



Selanjutnya, VM dibuat tanpa disk lokal dengan LUN 200 GB dari 3PAR terpasang sebagai gantinya: 



#prlctl set testVM --device-add hdd --device /dev/mapper/ test3par


VM dibuat dengan parameter berikut:



  • Ketik - CentOS Linux
  • vCPU - 4
  • RAM - 8
  • OS Tamu - Centos 7 (1908)


Tes migrasi



Tes migrasi dilakukan dengan atau tanpa alat tamu terpasang.

Dalam semua kasus, VM berhasil bermigrasi tanpa henti.





Angka: 8 Hasil dan waktu migrasi VM.



Test1 - VM normal dengan parameter yang sama hanya dengan gambar disk lokal QCOW2 64 GB dan Migrasi langsung dari VM test10 dengan LUN 200 GB dari 3PAR.



Waktu migrasi lebih sedikit karena fakta bahwa selama proses tidak ada langkah untuk beralih ke salinan image disk VM di node lain, hanya file konfigurasi yang disalin dengan link ke LUN 200GB, yang dapat dilihat dari node cluster mana pun.





Angka: 9 Hasil Ping.



Selama migrasi langsung, ping dilakukan ke VM dengan LUN 200 GB dari 3PAR.



Hilangnya hanya satu paket dicatat, hal yang sama terjadi dengan VM biasa di SDS, tetapi VM tetap dapat diakses melalui jaringan dan terus bekerja.



Tes pemadaman darurat



Ketika server dimatikan, di mana ada VM dengan LUN 200 GB dari 3PAR, dan setelah layanan HA mendeteksi node yang hilang, VM yang diuji berhasil dimulai ulang pada node lain yang dipilih sesuai dengan algoritme drs default, round robin, terus bekerja. Selama ping, 7 paket hilang. Saat beralih, hanya file konfigurasi VM yang diluncurkan, dan OS tamu selalu dapat diakses melalui jalur terlampir ke LUN.



Kami juga menguji pembuatan cadangan, di mana file konfigurasi VM berhasil dicadangkan dan saat memulihkan dari salinan VM ini, file tersebut berhasil dimulai.







Pengujian penulisan berurutan ke VM dengan 200 GB LUN dari 3PAR, yang menunjukkan performa LUN ini dari 3PAR, di mana Rosplatforma bukan merupakan lapisan perantara, dan pengujian tersebut menunjukkan pengoperasian OS tamu dan sistem penyimpanan 3PAR.



Parameter fio yang digunakan di dalam VM dengan 200GB LUN dari 3PAR: 



[seqwrite]
rw=write
size=4g
numjobs=4
bs=1m
ioengine=libaio
iodepth=32
time_based
#runtime=60
direct=1
filename_format=__testfile'$jobnum'
thread
directory=/sdb/


Menguji dengan sistem file berkerumun di dalam OS tamu





Angka: 10 Sistem file cluster di dalam OS tamu.



Skenario dengan satu LUN 200 GB yang terhubung ke dua VM telah berhasil diuji, di mana sistem file kluster GFS2 diinstal di dalam VM menggunakan OS tamu. Selama pengujian, salah satu VM atau host dimatikan, setelah itu VM lain terus bekerja dengan LUN ini dan menulis / membaca file dari sana. Di bawah ini adalah tangkapan layar dengan pengaturan GFS2 di dalam VM, output dari perintah alat pacu jantung juga ditampilkan:







SDS lebih lanjut dari Rosplatform melalui LUN:





Gbr. 11 Konfigurasi dengan SDS Rosplatform yang diterapkan pada 3PAR LUN.



Skenario yang sama berhasil diuji dengan satu LUN 200 GB yang terhubung ke dua VM, di mana sistem file klaster diinstal di dalam VM melalui OS tamu, tetapi datastore dari SDS Rosplatforma yang dibuat di LUN dari 3PAR digunakan sebagai lokasi VM. Selama pengujian, salah satu VM atau host dimatikan, setelah itu VM lain terus bekerja dengan LUN ini dan menulis / membaca file dari sana.





Angka: 12 Uji dengan menambahkan SSD untuk peran cache dari modul disk Synergy.



Skenario yang sama berhasil diuji dengan satu LUN 200 GB yang terhubung ke dua VM, di mana sistem file klaster diinstal di dalam VM melalui OS tamu, tetapi datastore dari SDS Rosplatforma yang dibuat di LUN dari 3PAR digunakan sebagai lokasi VM. Plus, datastore ini telah ditingkatkan kinerjanya dengan menambahkan SSD sebagai cache dari modul disk Synergy. Selama pengujian, salah satu VM atau host dimatikan, setelah itu VM lain terus bekerja dengan LUN ini dan menulis / membaca file dari sana.



Pengujian sistem file cluster pada node Rosplatform





Angka: 13 Uji dengan file konfigurasi VM yang terletak di SDS Rosplatforma, dari 3PAR LUN 200GB disajikan.



Skenario dengan penyimpanan bersama dari 3PAR telah diuji untuk image disk VM pada sistem file cluster, yang diinstal pada node Rosplatforma, dan file konfigurasi VM ini terletak di SDS Rosplatforma. Selama pengujian, salah satu host dinonaktifkan, setelah itu VM harus terus bekerja dengan image disk mereka karena pekerjaan dua host lainnya sesuai dengan replika 3 pada kluster SDS untuk file konfigurasi VM dan 3 log dari sistem file kluster untuk image disk VM.





Angka: 14 SDS dibawa ke LUN dari 3PAR.



Sebuah skenario diuji dengan penyimpanan bersama dari 3PAR untuk image disk VM pada sistem file cluster, yang diinstal pada node Rosplatforma, dan file konfigurasi VM ini terletak di SDS Rosplatforma, tempat SDS dinaikkan ke LUN dari 3PAR. Selama pengujian, salah satu host dinonaktifkan, setelah itu VM harus terus bekerja dengan image disk mereka karena pekerjaan dua host lainnya sesuai dengan replika 3 pada kluster SDS untuk file konfigurasi VM dan 3 log dari sistem file kluster untuk image disk VM.





Angka: 15 SDS tier0 pada LUN dari 3PAR, SDS tier1 pada disk dari modul Synergy.



Sebuah skenario diuji dengan penyimpanan bersama dari 3PAR untuk image disk VM pada sistem file cluster, yang diinstal pada node Rosplatforma, dan file konfigurasi VM ini terletak di SDS Rosplatform, di mana SDS tier0 dinaikkan di LUN dari 3PAR dan SDS tier1 kedua pada disk dari modul Sinergi. Selama pengujian, salah satu host dimatikan, setelah itu VM harus bekerja dengan image disk mereka karena pekerjaan dua host lain sesuai dengan replika 3 pada kluster SDS untuk file konfigurasi VM dan 3 log dari sistem file kluster untuk image disk VM. Tetapi ada masalah dengan pengoperasian kvm-qemu dengan GFS2, setelah penyelidikan yang lama, pengelola kunci dari GFS2 gagal dan Rosplatforma tidak dapat memulai VM di host lain dari kluster karena hal ini. Pertanyaannya tetap terbuka. Hal yang sama dengan opsi pada Gambar 13 dan 14.Masalah yang mungkin terjadi dengan skenario ini terletak pada cara kvm-qemu bekerja dengan qcow2 dan gambar mentah, di mana operasi tulis sinkron, dan manajer kunci GFS2 terbatas untuk operasi semacam itu.



Kesimpulan



Pilihan dari SDS ke LUN dari 3PAR dan presentasi LUN dari 3PAR cukup berfungsi dan dapat digunakan untuk bekerja di bidang infrastruktur, namun tentunya memiliki beberapa kekurangan.



Misalnya, dalam kasus SDS di bulan, kinerja akan selalu sedikit lebih rendah daripada SDS pada disk lokal, ini dapat ditingkatkan dengan SSD lokal dengan peran cache, tetapi SDS biasa akan selalu lebih cepat. Sebagai pilihan, SDS di penyimpanan dapat dikonfigurasi di galeri pemotretan terpisah. Kekurangan lain yang tidak penting adalah toleransi kesalahan, pada SDS setiap node adalah pengontrol, di mana setidaknya sebuah cluster dimulai dengan tiga node, maka dalam kasus sistem penyimpanan selalu ada dua pengontrol per rak. Untuk SDS, ini adalah satu titik kegagalan, namun terlepas dari kekurangannya, skenario tersebut terjadi selama transisi bertahap dari penyimpanan eksternal ke SDS atau saat membuang sistem penyimpanan yang ada. Selain itu, ada kemampuan sistem penyimpanan itu sendiri, seperti deduplikasi, kompresi, yang, karena kekhasan pendekatan arsitektural.Rosplatforma tidak ada di SDS, tetapi 3PAR memilikinya, dan berkat skenario yang dijelaskan di atas, mereka dapat digunakan di tingkat penyimpanan.



Skenario dengan presentasi LUN untuk VM, untuk sistem tamu dengan sistem clusternya sendiri juga relevan. Dalam kasus presentasi LUN ke setiap VM secara terpisah, kerugian seperti kurangnya otomatisasi selama siklus hidup sejumlah besar VM muncul, yang mungkin disebabkan oleh sistem file cluster pada node Rosplatform, tetapi GFS2 dengan kvm-qemu dalam kasus ini gagal, Jika itu digunakan untuk file lain, lalu semuanya berfungsi bahkan dalam pengujian darurat di Rosplatform, tetapi segera setelah image VM diletakkan di sana, lock manager GFS2 tidak dapat menangani pengujian darurat. Mungkin masalah ini akan teratasi.



Skenario di atas untuk menggunakan multipath dapat berguna untuk menghubungkan perpustakaan tape. Rosplatform memiliki sistem cadangan built-in (SRK), yang dapat menulis salinan ke folder cluster penyimpanan-P atau folder lokal, tetapi tidak dapat bekerja dengan perangkat tape sampai Anda menulis skrip sendiri, atau untuk tujuan ini Anda dapat menggunakan SRK eksternal misalnya rubackup , yang mana selain bekerja dengan tape, ini akan membantu membuat salinan VM dengan LUN terlampir, yang penting saat mengintegrasikan dengan sistem penyimpanan.


More articles:


All Articles