Memigrasi sistem TI bukanlah tugas yang mudah. Tetapi kesulitan khusus adalah situasi ketika Anda tidak hanya perlu beralih dari besi lama ke baru, tetapi untuk pindah ke sistem operasi baru pada peralatan yang ada, dan tanpa memigrasikan data produktif. Satu langkah seperti itu berlangsung sekitar satu tahun, yang sebagian besar membutuhkan persiapan.
Klien memiliki dua situs di kota yang berbeda, dan masing-masing memiliki dua sistem penyimpanan data yang terhubung. Informasi dari satu sistem penyimpanan menggunakan alat replikasi bawaan dikirim ke yang kedua. Manajemen dilakukan dengan menggunakan sistem cadangan eksternal. Di satu kota, dua sistem NetApp 3250 diinstal, di yang lain - NetApp 6220 utama dan cadangan NetApp 3250. Klien berencana untuk memperluas kompleks ini di masa mendatang, menambah disk, dan meningkatkan pengontrol.
Fig. 1 Skema interaksi sistem penyimpanan dan IBSDan masalah utama terhubung dengan ini - akhir dukungan. Untuk Sistem Operasi 7-Mode Data ONTAP 8.2 yang diinstal pada sistem penyimpanan, belum ada pembaruan besar selama beberapa tahun, dan rilis koreksi kesalahan kritis akan berhenti pada tahun 2021. Drive dan pengontrol yang lebih baru tidak kompatibel dengan sistem operasi lama.
Solusinya adalah transisi ke sistem cluster ONTAP 9.1 sebagai yang didukung terakhir untuk pengontrol penyimpanan ini. Keuntungan utamanya adalah:
- Penskalaan horizontal dengan menggabungkan ke dalam satu kluster toleransi-kesalahan, yang akan memungkinkan Anda untuk membuat sistem tunggal berdasarkan penyimpanan produktif dan SRK.
- Load balancing antara pengontrol, disk, serta memindahkan data di dalam sistem penyimpanan tanpa mengganggu layanan dan menghentikan akses ke aplikasi.
- Pemeliharaan perangkat keras dan perangkat lunak sistem penyimpanan data tanpa gangguan pekerjaan mereka dan gangguan layanan.
- Kemampuan untuk membuat konfigurasi cluster heterogen, termasuk pengontrol dan disk dari berbagai jenis, termasuk sistem penyimpanan pihak ketiga, tunduk pada penggunaan lisensi untuk virtualisasi kapasitas disk mereka.
- Kemampuan untuk menggunakan SSD sebagai lapisan cache untuk agregat.
- Dioptimalkan operasi mekanisme Pemadatan Data (kompresi dan deduplikasi).
Ada 3 opsi untuk bermigrasi dari 7 mode ke Mode Cluster:
- Bermigrasi dengan replikasi data menggunakan Netapp 7-Mode Transition Tool (7MTT) dan transisi berbasis salinan (CBT). Untuk ini, diperlukan sistem penyimpanan kedua dengan ruang disk yang lebih kecil dan replikasi bertahap berdasarkan SnapMirror. Untuk setiap layanan, switching dikoordinasikan dan dilakukan pada waktu tertentu.
Di salah satu pelanggan kami, kami sudah melakukan prosedur ini di metro cluster. Karena banyaknya volume, LUN (> 400) dan koordinasi panjang detail, waktu henti, dll. migrasi memakan waktu sekitar 3 bulan, tidak termasuk pelatihan. - Bermigrasi tanpa memindahkan data menggunakan Netapp 7-Mode Transition Tool (7MTT) dan transisi bebas salinan (CFT). Untuk melakukan ini, Anda memerlukan sistem penyimpanan kedua dengan jumlah disk minimum, yang setelah persiapan awal akan mengganti subsistem disk produktif. Untuk semua layanan, satu downtime besar disepakati.
- Migrasi dengan menyalin data menggunakan alat host. Ini adalah jalur migrasi tradisional antara sistem penyimpanan setiap produsen.
Karena sistem penyimpanan yang ada masih di bawah dukungan vendor, dan kinerja pengendali dalam waktu dekat sudah cukup, anggaran untuk pembelian pengendali baru tidak dialokasikan. Dalam hal ini, diputuskan untuk melakukan migrasi pengendali ke Mode Cluster menggunakan 7MTT CFT. Salah satu persyaratan utama adalah tidak adanya gangguan nyata dalam pengoperasian sistem penyimpanan: sebagian besar sistem harus bekerja dengan lancar pada hari kerja. Oleh karena itu, pekerjaan utama tentang migrasi pada sistem penyimpanan produktif dijadwalkan untuk akhir pekan.
Tahap persiapan dimulai dengan pengumpulan informasi dari sistem penyimpanan dan pelaksanaan pemeriksaan pendahuluan. Perangkat lunak NetApp 7MTT khusus menghasilkan daftar peringatan yang dapat mengganggu migrasi atau gagal menyelesaikannya. Misalnya, untuk salah satu sistem, daftar ini terdiri dari lebih dari 200 item. Penting untuk memperbarui semua sistem ke versi OS terbaru yang didukung, memperbarui firmware pengontrol, rak disk, dan disk itu sendiri. Juga, sistem operasi baru memiliki logika operasi yang berbeda, yang membutuhkan alamat IP tambahan dan koneksi antara sistem penyimpanan.
Faktor berhenti ditemukan cukup cepat - klien menggunakan teknologi yang tidak didasarkan pada replikasi volume keseluruhan, tetapi pada replikasi qtree (subbagian yang akses, volume, dll. Pembatasan berlaku) Dan tidak mungkin untuk memigrasikan hubungan SnapVault seperti itu ke OS baru . Akibatnya, sebelum mulai bekerja, perlu untuk menghapus semua salinan replikasi. Untuk memastikan bahwa klien setelah pindah tidak dibiarkan tanpa cadangan, cadangan berdasarkan seluruh replikasi volume dimulai sebelum migrasi. Menggunakan SnapMirror, cadangan baru dibuat di sebelah yang lama, dan log perubahan diakumulasikan selama empat minggu. Dan jika di salah satu situs ada ruang yang cukup untuk ini, maka pada ruang kedua terbatas, perlu secara bertahap membuat salinan dari salah satu volume. Setelah empat minggu, hubungan lama dihapus dan yang baru dibuat. Proses bertahap yang cukup panjang, yang memakan waktu sekitar 1,5 bulan untuk satu lokasi, dan lebih dari 3 di lokasi kedua. Selain itu, saya ingin mencatat bahwa prosedur untuk menghentikan hubungan Snapvault disertai dengan penghapusan qtree target dan kecepatan eksekusi sangat tergantung pada jumlah file dan pada tingkat yang lebih kecil pada ukurannya. Misalnya, qtree dengan 4 juta file dan ukuran 500GB telah dihapus dalam waktu 24 jam.
Dalam prosesnya, berbagai kesulitan muncul. Birokratisasi proses pembuatan perubahan pada sistem klien meningkatkan persyaratan koordinasi kerja. Untungnya, kami berhasil menyetujui untuk menyelesaikan masalah teknis secara langsung, membahas pada tingkat yang lebih tinggi hanya masalah "ideologis" yang penting, seperti menyepakati rencana kerja dan memilih tanggal tertentu untuk migrasi.
Kesulitan disebabkan oleh penggunaan penyimpanan sementara. Di bawah panduan 7MTT, kami mengkonfigurasi kedua sistem penyimpanan sesuai dengan persyaratan dan pra-pemeriksaan. Kemudian mereka mematikan penyimpanan lama dan menghubungkan rak disk ke yang baru. Memeriksa semuanya lagi. Dari sudut pandang perangkat lunak NetApp, proses migrasi selesai dan semua orang menyebar di
belakang sampanye . Tetapi langkah selanjutnya adalah mengembalikan semuanya ke pengendali klien lama. Faktanya adalah transisi seperti itu - dari pengontrol baru ke yang lama - tidak didukung secara resmi. Setelah beralih kembali, OS mulai menuangkan kesalahan dan mengeluh tentang masalah dengan cluster. Setelah penelitian, saya dapat mengetahui bahwa masalahnya adalah karena fakta bahwa cluster tiba-tiba beralih ke mode yang diaktifkan dan tidak ingin kembali ke switchless. Butuh waktu lama untuk memperbaiki kesalahan. Masalah dengan peluncuran cluster diselesaikan dengan tidak menghubungkan kabel yang mengarah ke jaringan tempur saat start-up, jaringan intra-cluster diangkat pada satu kabel, kemudian yang kedua ditambahkan. Ngomong-ngomong, harus diingat bahwa pada pengontrol lama dan versi OS yang lebih lama, jaringan intra-kluster hanya dapat dinaikkan pada port tertentu dari rangkaian adaptor terbatas, misalnya, pada FAS3250 itu adalah e1a dan e2a (pelanggan harus membeli kartu Ethernet 10GB).
Mereka meluangkan waktu ekstra untuk bekerja di situs kedua, berharap untuk menghindari setidaknya beberapa masalah, tetapi ini tidak membantu - sistem operasi berperilaku tak terduga. Grafik digeser dua kali. Dalam kasus pertama, ketika kami bekerja dengan FAS3250, tidak mungkin untuk memigrasikan sistem tempur yang beroperasi 24/7 karena kesalahan dalam pengaturan yang baru-baru ini berubah dari infrastruktur jaringan pelanggan (walaupun ketika menguji migrasi seminggu sebelum pekerjaan dimulai, semuanya terbang). vMotion menyalin mesin virtual dengan kecepatan kurang dari 1 Mbps ke sistem penyimpanan jarak jauh.
Selama migrasi, klien mengubah sebagian arsitektur. Volume yang didistribusikan ke infrastruktur VMware vSphere mereka sebelumnya dikeluarkan melalui NFS Ethernet. Klien redid mereka, dan mereka pindah ke Fibre Channel. Selama proses migrasi, ternyata LUN benar-benar mengubah ID-nya dan, karenanya, VMware melihat LUN baru yang ditujukan kepadanya dengan data lama, dan menolak untuk menghubungkannya secara permanen. Akibatnya, berkat bantuan spesialis VMware, dimungkinkan untuk menghubungkan LUN ini melalui konsol secara berkelanjutan, menunjukkan bahwa ini adalah snapshot dari datastore lama. Kemudian saya harus me-reboot host VMware. Akibatnya, mereka berhasil melihat mesin virtual dan meningkatkan infrastruktur virtual. Dan jika klien terus menggunakan NFS, maka masalah seperti itu tidak akan muncul - alamat IP dan nama DNS tetap sama seperti sebelumnya.
Rencana kerja langsung pada hari-hari migrasi:
Jumat: bekerja dengan sistem penyimpanan dan IBS
- Mereka menghentikan semua hubungan antara SnapVault dan SnapMirror, beralih penyimpanan sementara dan memeriksa apakah sistem siap untuk migrasi. Kami memulai prosedur untuk memigrasi penyimpanan ke 7MTT menggunakan metode Salin Transisi Gratis. Resimen tempur disk yang terhubung kembali ke pengontrol sementara.
- Bermigrasi ke 7MTT, memigrasi volume root dari pengontrol pengganti ke rak disk sistem penyimpanan SRK. Kami memasang adapter Ethernet baru, meluncurkan sistem penyimpanan SRK, menghapus konfigurasi, dan mengunduh gambar OS melalui jaringan dari server HTTP. Kami memasang versi baru firmware dan OS (pada tahap ini ada masalah yang tidak dapat dijelaskan dengan mengunduh gambar melalui jaringan. Pada akhirnya, itu diunduh langsung dari laptop).
- Kami mengganti controller di cluster dengan yang lama dan menghubungkan rak-rak disk pertempuran ke sistem penyimpanan menggunakan peningkatan dengan memindahkan prosedur penyimpanan. Kami memulihkan cluster, mengkonfigurasi ulang antarmuka jaringan (saya harus menyelesaikan masalah yang terkait dengan operasi cluster yang salah) dan menginstal kunci lisensi.
Sabtu: bekerja dengan penyimpanan utama
- Kami menghubungkan rak disk sementara ke penyimpanan sementara dan mengaturnya kembali.
- Mesin virtual penting dimigrasikan ke penyimpanan ke pusat data jarak jauh menggunakan VMware vMotion.
- Sistem penyimpanan utama dimigrasikan ke 7MTT menggunakan metode CFT. Mereka mematikan penyimpanan tempur utama, menghubungkan rak-rak disk-nya ke controller dan mengonversikan metadata OS ke 7MTT. Volume akar pengontrol swap bermigrasi ke rak disk sistem penyimpanan SRK.
- Kami memasang adapter Ethernet baru dan meluncurkan penyimpanan pertempuran dalam konfigurasi tanpa disk, menghapus pengaturan, dan kemudian mengunduh melalui jaringan dari server HTTP. Menginstal firmware dan versi OS baru. Kami mengganti controller di cluster, menghubungkan rak-rak disk tempur ke sistem penyimpanan menggunakan peningkatan dengan memindahkan prosedur penyimpanan.
- Mengembalikan cluster, antarmuka jaringan yang dikonfigurasi ulang (bermain-main dengan cluster yang bekerja secara salah karena antarmuka jaringan tempur yang terhubung). Kunci lisensi yang diinstal.
- Kami memulihkan koneksi penyimpanan ke server VMware, mengubah zonasi di jaringan SAN, mengkonfigurasi pemetaan LUN, memindahkan volume ke SVM terpisah untuk bekerja dengan akses FC. LUN terhubung ke ESXi. Karena fakta bahwa LUN ID telah berubah, datastore tidak muncul dalam mode otomatis, saya harus secara konsisten me-restart server ESXi dan menghubungkan LUN dengan perintah melalui esxcli.
- Antarmuka pertempuran yang dikonfigurasi ulang, berganti nama menjadi server CIFS dan mendapatkan kembali akses ke bola CIFS dan ekspor NFS.
Minggu: Pemecahan Masalah dan Pengaturan Perangkat Lunak IBS
- Mesin virtual bermigrasi kembali dari sistem penyimpanan ke sistem penyimpanan tempur.
- Kami memecahkan masalah dengan mengakses folder dalam mode perekaman dari host Linux. Kami menyebarkan versi terbaru Netapp onCommand Unified Manager 7.3 perangkat lunak pemantauan dan menghubungkan kedua sistem penyimpanan itu.
- Kami menganalisis data tentang beban saat ini pada unit menggunakan perangkat lunak Unified Manager, menggunakan SSD kami menghubungkan lapisan caching ke unit disk yang ada (Flash / Storage Pool).
- Mereka mematikan sistem penyimpanan alternatif, membuat tautan kluster (Peering peering, SVM peering) sehingga replikasi dapat digunakan. Kami membuat hubungan SnapMirror baru antara penyimpanan utama dan penyimpanan SRK berdasarkan volume yang ada (yang digunakan dalam hubungan mode SnapMirror 7) dengan sinkronisasi ulang dari data yang diubah, dan kemudian mengonversi hubungan SnapMirror ke hubungan SnapVault (SnapMirror XDP).
- Kami menghubungkan kedua sistem penyimpanan ke perangkat lunak Commvault SRC dalam mode Replikasi Terbuka NetApp menggunakan dukungan teknis Commvault, itu tidak bekerja secara berbeda, meskipun kami melakukan segalanya sesuai dengan instruksi. Konfigurasi pengiriman log Autosupport dari sistem penyimpanan dan penyimpanan SRK.
Senin: penggilingan
- Verifikasi operasi penyimpanan produktif utama dan sistem penyimpanan sistem penyimpanan. Memecahkan kemungkinan masalah dan malfungsi.
- Melepaskan dan membongkar peralatan sementara.
Migrasi itu sendiri hanya membutuhkan dua hari. Langkah itu berhasil, semua data pelanggan aman dan sehat. Sistem manajemen cadangan dan integrasi dengan perangkat lunak SRK yang ada juga dipertahankan. Jika sebelumnya Anda menggunakan bundel Commvault dengan OnCommand Unified Manager, maka setelah beralih ke Mode Cluster, diputuskan untuk mengabaikannya demi Netapp Open Replication untuk menghubungkan Commvault langsung ke pengontrol penyimpanan.
Rekomendasi utama yang dapat saya berikan berdasarkan hasil migrasi ini: beralih dari 7 mode ke Mode Cluster bersamaan dengan mengganti pengendali. Jika Anda masih berencana untuk pindah ke pengontrol kedua, seperti dalam kasus yang dijelaskan di atas, maka Anda perlu merencanakan waktu yang cukup untuk menyelesaikan berbagai masalah yang perlu muncul ketika kembali ke pengontrol lama. Menggunakan migrasi tanpa memindahkan data menggunakan 7MTT CFT adalah prosedur yang sepenuhnya aman, jika dipercaya oleh para profesional.
Panduan bermanfaat yang digunakan selama migrasi ini:
Dmitry Kostryukov, Insinyur Desain Utama Sistem Penyimpanan
Pusat Desain untuk Kompleks Komputer "Jet Infosystems"