Instans Terkelola Database Azure SQL tersedia secara umum pada akhir 2018. Sejak saat itu, banyak organisasi mulai bermigrasi ke Instans Terkelola untuk memanfaatkan lingkungan terkelola. Organisasi memanfaatkan cadangan terkelola, banyak fitur keamanan bawaan, SLA waktu aktif 99,99%, dan lingkungan yang selalu terbaru di mana mereka tidak lagi bertanggung jawab untuk menambal SQL Server atau sistem operasi.
Satu ukuran tidak selalu cocok untuk semua. Instans Terkelola menyediakan dua tingkat kinerja. Tujuan Umum tier dirancang untuk aplikasi dengan kinerja khas dan persyaratan latensi I/O dan menyediakan HA bawaan. Kritis Bisnis tier dirancang untuk aplikasi yang memerlukan latensi I/O rendah dan persyaratan HA yang lebih tinggi. Business Critical juga menyediakan dua sekunder yang tidak dapat dibaca dan satu sekunder yang dapat dibaca. Sekunder yang dapat dibaca adalah cara yang bagus untuk mendistribusikan beban kerja dari primer, yang dapat menurunkan tingkat layanan yang diperlukan untuk primer — mengurangi pengeluaran keseluruhan untuk instans.
Saat Instans Terkelola pertama kali dirilis, Anda dapat memilih antara prosesor Gen4 dan Gen5. Gen4 masih dijelaskan dalam dokumentasi, tetapi opsi ini sebagian besar tidak tersedia sekarang. Untuk artikel ini, saya hanya akan membahas konfigurasi menggunakan prosesor Gen5.
Setiap tingkat layanan mendukung mulai dari 4 hingga 80 CPU logis — juga dikenal sebagai inti virtual, atau vCores. Memori dialokasikan sekitar 5,1 GB per vCore. Tujuan Umum menyediakan hingga 8 TB penyimpanan Azure Blob berkinerja tinggi, sementara Business Critical menyediakan hingga 4 TB penyimpanan SSD lokal super cepat.
Memori
Dengan hanya memiliki 5,1 GB memori per vCore, sebuah instance dengan vCore yang lebih sedikit dapat mengalami kesulitan. Pilihan untuk konfigurasi vCore adalah 4, 8, 16, 24, 32, 40, 64, dan 80 vCore. Jika Anda menghitung setiap opsi vCore ((number of vCores) × (5.1 GB) ), Anda akan mendapatkan kombinasi inti / memori berikut:
4 vCores = 20.4 GB 8 vCores = 40.8 GB 16 vCores = 81.6 GB 24 vCores = 122.4 GB 32 vCores = 163.2 GB 40 vCores = 204.0 GB 64 vCores = 326.4 GB 80 vCores = 408.0 GB
Untuk banyak organisasi yang telah saya bantu transisi dari Instans lokal ke Instans Terkelola, saya telah melihat pengurangan memori yang signifikan. Konfigurasi umum di tempat adalah 4 vCore dan memori 32 GB, atau 8 vCore dan 64 GB. Keduanya menyumbang lebih dari 30% pengurangan memori. Jika instans sudah berada di bawah tekanan memori, ini dapat menyebabkan masalah. Dalam kebanyakan kasus, kami dapat mengoptimalkan instans lokal untuk membantu mengurangi tekanan memori sebelum pindah ke Instans Terkelola, tetapi dalam beberapa kasus, pelanggan harus menggunakan instans vCore yang lebih tinggi untuk mengurangi tekanan memori .
Penyimpanan
Penyimpanan sedikit lebih sulit untuk direncanakan dan dipertimbangkan, karena harus mempertimbangkan banyak faktor. Untuk penyimpanan, Anda perlu memperhitungkan keseluruhan kebutuhan penyimpanan untuk ukuran penyimpanan, dan kebutuhan I/O. Berapa GB atau TB yang diperlukan untuk instans SQL Server dan seberapa cepat penyimpanan yang diperlukan? Berapa banyak IOPS dan berapa banyak throughput yang digunakan instans lokal? Untuk itu, Anda harus mendasarkan beban kerja Anda saat ini menggunakan perfmon untuk menangkap rata-rata dan maks MB/s dan/atau mengambil snapshot dari sys.dm_io_virtual_file_stats untuk menangkap pemanfaatan throughput. Ini akan memberi Anda gambaran tentang jenis I/O dan throughput yang Anda butuhkan di lingkungan baru. Beberapa pelanggan yang pernah bekerja dengan saya melewatkan bagian penting dari perencanaan migrasi ini dan mengalami masalah kinerja karena memilih tingkat instans yang tidak mendukung beban kerja mereka.
Hal ini penting untuk baseline karena dengan server lokal, penyimpanan yang disediakan dari SAN super cepat dengan kemampuan throughput tinggi ke mesin virtual berukuran lebih kecil merupakan hal yang umum. Di Azure, batas IOPS dan throughput Anda ditentukan oleh ukuran node komputasi, dan dalam kasus Kelola Instans, itu ditentukan oleh jumlah vCore yang dialokasikan. Untuk Tujuan Umum ada batas 30-40k IOPS per instans atau 500 hingga 12.500 IOPS per file tergantung pada ukuran file. Throughput per file juga didasarkan pada ukuran mulai dari 100 MiB/s hingga 128 GB file, dan hingga 480 MiB/s untuk 4 TB dan file yang lebih besar. Dalam Business Critical, IOPS berkisar dari 5,5K – 110K per instans atau 1.375 IOPS per vCore.
Konsumen juga harus memperhitungkan throughput penulisan log untuk instance. Tujuan Umum adalah 3 MB/dtk per vCore dengan maksimum 22MB/dtk untuk instans dan Kritis Bisnis adalah 4 MB/dtk per vCore dengan maksimum 48 MB/dtk untuk seluruh instans. Dalam pengalaman saya bekerja dengan pelanggan, banyak yang jauh melampaui batas ini untuk throughput tulis. Untuk beberapa itu telah menjadi showstopper, dan untuk yang lain, mereka telah mampu mengoptimalkan dan memodifikasi sistem mereka untuk mengurangi beban.
Selain perlu mengetahui keseluruhan throughput dan persyaratan I/O, ukuran penyimpanan juga terkait dengan jumlah vCore yang dipilih. Untuk Tujuan Umum:
4 vCores = 2 TB max
8 - 80 vCores = 8 TB max
Untuk Bisnis Penting:
4 – 16 vCores = 1 TB
24 vCores = 2 TB
32 - 80 vCores = 4 TB
Untuk Tujuan Umum, setelah Anda mencapai 8 vCores, Anda dapat memaksimalkan penyimpanan yang tersedia, yang bekerja dengan baik untuk mereka yang hanya membutuhkan Tujuan Umum. Tetapi ketika Anda membutuhkan Business Critical, segalanya bisa lebih menantang. Saya telah bekerja dengan banyak pelanggan yang memiliki banyak TB yang dialokasikan untuk VM dengan 4, 8, 16, dan 24 prosesor logis. Untuk setiap pelanggan ini, mereka harus meningkatkan setidaknya 32 vCore hanya untuk memenuhi kebutuhan penyimpanan mereka, opsi yang mahal. Azure SQL Database memiliki masalah serupa dengan ukuran basis data maksimal, dan Microsoft membuat opsi Hyperscale. Kami berharap ini menjadi opsi untuk Instans Terkelola di beberapa titik untuk mengatasi batas penyimpanan dengan cara yang sama.
Ukuran tempdb juga berkorelasi dengan jumlah vCores. Di tingkat Tujuan Umum, Anda mendapatkan 24 GB per vCore (hingga 1.920 GB) untuk file data, dengan batas ukuran file log tempdb 120 GB. Untuk tingkat Kritis Bisnis, tempdb dapat berkembang hingga ukuran penyimpanan instans yang tersedia saat ini.
OLTP dalam memori
Bagi mereka yang saat ini memanfaatkan OLTP Dalam Memori (atau berencana untuk), perhatikan bahwa ini hanya didukung di tingkat layanan Kritis Bisnis. Jumlah ruang yang tersedia untuk tabel In-Memory juga dibatasi oleh vCores:
4 vCores = 3.14 GB
8 vCores = 6.28 GB
16 vCores = 15.77 GB
24 vCores = 25.25 GB
32 vCores = 37.94 GB
40 vCores = 52.23 GB
64 vCores = 99.90 GB
80 vCores = 131.86 GB
Kesimpulan
Saat merencanakan migrasi ke Azure SQL Managed Instance, ada beberapa pertimbangan yang harus dipertimbangkan sebelum memutuskan untuk bermigrasi. Pertama, Anda perlu memahami sepenuhnya persyaratan memori, CPU, dan penyimpanan Anda, karena ini akan menentukan ukuran instans. Sama pentingnya adalah mengetahui apa persyaratan I/O penyimpanan Anda. IOPS dan throughput untuk tingkat Tujuan Umum terkait langsung dengan vCores dan ukuran file database. Untuk Kritis Bisnis, ini terkait dengan jumlah vCores. Jika Anda memiliki beban kerja I/O yang sangat intensif, Business Critical adalah tingkat layanan yang lebih menarik karena memberikan IOPS dan angka throughput yang lebih tinggi. Tantangan dengan Business Critical adalah kapasitas penyimpanan yang lebih rendah dan hanya mendukung 1TB untuk seluruh instans hingga 16 vCore.
Dengan perencanaan yang tepat, dan kemungkinan dekonsolidasi instans yang lebih besar ke Instans Terkelola yang lebih kecil, penawaran ini dapat menjadi opsi migrasi yang sangat layak untuk banyak organisasi. Daya tariknya adalah manfaat memiliki cadangan terkelola, HA bawaan dengan SLA 99,99%, fitur dan opsi keamanan tambahan, dan tidak perlu khawatir tentang menambal OS atau instance SQL Server.
