Memigrasi instans SQL Server lokal ke Mesin Virtual Azure (VM) adalah metode umum untuk bermigrasi ke Azure. Profesional TI sudah familiar dengan pelingkupan ukuran VM berkaitan dengan vCPU, memori, dan kapasitas penyimpanan. Microsoft menawarkan beberapa jenis dan ukuran VM untuk kebutuhan organisasi. Anda akan melihat jenis yang dirujuk sebagai Family di Portal Azure saat mengukur VM.
Jenis dan Ukuran VM
Microsoft telah membantu menyederhanakan berbagai hal dengan membuat beberapa jenis mesin virtual. Jenis diarahkan untuk mendefinisikan mesin dengan tujuan. Berbagai jenisnya adalah:
- Tujuan umum – Rasio CPU-ke-memori yang seimbang, database kecil hingga menengah
- Komputasi dioptimalkan – Rasio CPU-ke-memori tinggi, server web dengan lalu lintas sedang, dan server aplikasi
- Memori dioptimalkan – Rasio memori-ke-CPU tinggi, server database relasional, cache sedang hingga besar, dan analitik dalam memori
- Penyimpanan dioptimalkan – Throughput dan IO disk tinggi
- GPU – Render grafis berat dan pengeditan video
- Komputasi performa tinggi – Mesin virtual CPU tercepat dan tercanggih
Dalam setiap jenis/keluarga ada banyak ukuran untuk dipilih. Ukuran menawarkan opsi untuk jumlah vCPU, RAM, dan disk data. Jumlah disk data akan menentukan IOPS maksimum (IOPS singkatan dari input/output operations per second.) dan ukuran keseluruhan akan menentukan jumlah penyimpanan sementara yang tersedia. Ukuran tertentu juga mendukung penyimpanan premium, yang seharusnya menjadi persyaratan untuk SQL Server produksi.
Opsi Gambar VM
Saat memilih gambar untuk SQL Server, Anda memiliki beberapa opsi. Anda dapat memilih untuk memilih OS saja, seperti Linux atau Windows, atau Anda dapat memilih untuk memilih gambar dengan OS dan SQL Server yang sudah diinstal. Saat ini saya lebih suka memilih gambar hanya dengan OS sehingga saya dapat menginstal SQL Server dan mengkonfigurasinya sesuai keinginan saya. Saat Anda memilih gambar galeri dengan SQL Server yang telah diinstal sebelumnya, semua komponen yang disertakan dalam ISO untuk versi tersebut akan diinstal, dan saya tidak selalu memerlukan Layanan Integrasi atau Layanan Analisis.
Pertimbangan Ukuran VM
Memilih Azure VM mungkin tampak mudah, dengan memilih ukuran berdasarkan jumlah vCPU, memori, dan penyimpanan yang cukup untuk menampung database Anda, namun saya melihat pelanggan mengalami masalah kinerja terkait penyimpanan. Kecenderungan umum adalah memilih VM yang didasarkan secara eksklusif pada vCPU, memori, dan kapasitas penyimpanan tanpa membandingkan persyaratan IO dan throughput saat ini. Saat Anda membuat VM Azure di Portal Azure, Anda dapat memfilter opsi berdasarkan berikut ini:
- Ukuran
- Generasi
- Keluarga
- RAM/memori
- Dukungan penyimpanan premium
- Jumlah vCPU
- Disk OS Ephemeral
Setelah Anda memilih opsi filter, jika ada, Anda akan melihat daftar server yang tersedia. Dalam daftar ini menampilkan Ukuran VM, penawaran, keluarga, vCPU, RAM, jumlah disk data yang didukung, IOPS maks, penyimpanan sementara (D :), jika disk premium didukung, dan perkiraan biaya. Saya telah memfilter berikut ini pada disk premium yang didukung dan ukurannya dimulai dengan huruf E untuk memori yang dioptimalkan.
Namun, yang tidak ditampilkan adalah jumlah throughput yang diizinkan per VM. Throughput mengukur kecepatan transfer data ke dan dari media penyimpanan dalam megabyte per detik.
Throughput dapat dihitung menggunakan rumus berikut
MB/s =IOPS * KB per IO / 1.024
Dengan menggunakan rumus ini, KB per IO akan menjadi ukuran blok Anda. Jika Anda memformat data dan drive log pada 64k, maka rumus untuk VM E2s_v3, E4-2s_v3, dan E8-2s_v3 dengan 3.200, 6.400, dan 12.800 IOPS adalah:
MB/dtk =3.200 * 64/1.024 atau 200 MB/dtk
MB/dtk =6.400 * 64/1.024 atau 400 MB/dtk
MB/dtk =12.800 * 64/1.024 atau 800 MB/dtk
Perhitungan throughput berdasarkan IOPS setiap VM dengan ukuran blok 64k tidak terlalu buruk. Angka-angka ini tidak mempertimbangkan hukuman tulis apa pun untuk RAID. Saya menguji masing-masing VM ini menggunakan CrystalDiskMark. Angka yang saya dapatkan untuk throughput tidak mendekati perkiraan perhitungan.
Uji Tolok Ukur
Saya menyediakan tiga mesin virtual dari keluarga yang sama, namun ukurannya berbeda, dan masing-masing dengan 2 vCPU. Spesifikasi dari mesin virtual adalah:
- E2s_v3 – 2 vCPU – RAM 16GB – 3.200 IOPS – Mendukung hingga 4 disk data
- E4-2s_v3 – 2 vCPU – RAM 32GB – 6.400 IOPS – Mendukung hingga 8 disk data
- E8-2s_v3 – 2 vCPU – RAM 64GB – 12.800 IOPS – Mendukung hingga 16 disk data
- Disk data P60 – SSD Premium – 16.000 IOPS
Di setiap VM, saya menyediakan disk premium P60 dengan kapasitas 8TB. Disk ini mengiklankan 16.000 IOPS yang dengan ukuran blok 64k dapat mendukung throughput 1.000 MBps, namun dokumentasi Azure menyatakan disk menyediakan throughput 500 MBps.
CrystalDiskMark adalah alat benchmark drive disk sumber terbuka untuk Windows, dan didasarkan pada alat Diskspd Microsoft. Alat ini mengukur kinerja membaca dan menulis secara berurutan dan acak.
Di bagian atas alat ada beberapa drop down. Angka 5 merupakan jumlah iterasi dari pengujian yang akan dijalankan. Berikutnya adalah 1GiB, ini adalah ukuran file tes. Untuk uji produksi nyata, ini harus cukup besar untuk membantu menghindari cache. Versi 7.0 mendukung hingga file 64 GiB. Terakhir adalah drive yang ingin Anda uji.
Setelah Anda menentukan pilihan, Anda dapat mengklik Semua untuk memulai rangkaian tes. Tes akan mengulang melalui berbagai operasi baca/tulis berurutan dan acak. Berhati-hatilah jika Anda berencana untuk membandingkan server produksi nyata. Tes ini membebani disk Anda dan dapat berdampak drastis pada beban kerja produksi. Lebih disukai setelah jam kerja atau selama periode pemeliharaan.
Saya memilih untuk menjalankan 5 iterasi pengujian dengan file 32 GiB pada disk P60 yang merupakan drive E:.
VM E2s_v3 maksimal di bawah 50 MBps, jauh lebih kecil dari 200 MB yang kami hitung.
VM E4-2s_v3 maksimal di bawah 100 MBps, bukan 400 MBps.
VM E8-2s_v3 maksimal di bawah 200 MBps daripada yang diperkirakan 800 MBps.
Mengapa Throughput Lebih Rendah?
Berdasarkan perhitungan saya sebelumnya, 3.200 IOPS pada ukuran blok 64k harus menghasilkan throughput 200MB, namun saya tidak melihat angka yang mendekati itu sampai saya memiliki disk 16.000 IOPS pada VM yang mendukung hingga 12.800 IOPS. Alasannya adalah bahwa setiap ukuran VM memiliki batas throughput. Jika Anda melihat dokumentasi untuk keluarga VM yang dioptimalkan memori, Anda akan menemukan bahwa throughput disk yang tidak di-cache maksimal E2s adalah 3.200 IOPS /48 MBps, throughput disk yang tidak di-cache maksimal E4s adalah 6.400 IOPS / 96 MBps, dan disk yang tidak di-cache maks E8s throughput adalah 12.800 IOPS / 192 MBps. Angka-angka ini sesuai dengan hasil yang saya peroleh menggunakan CrystalDiskMark.
Meskipun Anda dapat mengalokasikan disk yang sangat besar yang memiliki banyak IOPS dan yang mendukung jumlah throughput yang tinggi, ukuran VM dapat sangat membatasi throughput Anda.
Membandingkan kebutuhan throughput Anda saat ini harus menjadi prioritas besar sebelum memigrasikan beban kerja SQL Server ke Azure.
Kesimpulan
Saya mengerti bahwa IOPS adalah unit pengukuran yang disediakan oleh produsen disk dan vendor penyimpanan, dan itu tidak masalah. Namun, dalam hal pengujian penyimpanan, kami cenderung lebih fokus pada jumlah throughput. Ini hanya masalah matematika, tetapi kecuali Anda berada dalam bisnis benchmarking penyimpanan dan melakukan perhitungan dari IOPS hingga throughput berdasarkan ukuran blok, ini bisa membingungkan.
Apa yang mengganggu saya adalah kenyataan bahwa pembatasan throughput tidak jelas ketika Anda memilih ukuran VM. Satuan pengukuran untuk IO penyimpanan adalah IOPS. Pada 3.200 IOPS dengan ukuran blok 64k, saya bisa menjadi sekitar 200 MBps namun VM saya terbatas pada 48 MBps. Banyak profesional TI telah menemukan bahwa mereka memiliki masalah kinerja disk dan menskalakan penyimpanan mereka ke disk yang lebih besar dan lebih cepat (lebih banyak IOPS) mengharapkan kinerja yang lebih baik, hanya untuk menemukan bahwa itu tidak menyelesaikan masalah mereka. Masalahnya adalah ukuran VM membatasi throughputnya. Meningkatkan ke ukuran VM yang lebih tinggi akan menyelesaikan masalah, tetapi itu membutuhkan biaya. Dalam contoh saya, E4 dua kali lebih mahal dari E2, namun memori dan throughputnya dua kali lipat, sambil mempertahankan vCPU yang sama. E8 menggandakan biaya E4 dan menggandakan throughput dan memori, sambil mempertahankan vCPU yang sama. Mempertahankan jumlah vCPU yang sama berarti saya tidak akan mengalami peningkatan biaya lisensi SQL Server inti.
Pada akhirnya, Anda perlu membandingkan persyaratan throughput Anda saat ini dan memastikan ukuran Azure VM, atau VM apa pun sesuai dengan kebutuhan Anda. Jangan hanya fokus pada tolok ukur penyimpanan lokal Anda, analisis sesuai kebutuhan dan ukuran beban kerja Anda.
