Ketersediaan tinggi untuk Azure SQL Managed Instance

  • Artikel

Berlaku untuk:Azure SQL Managed Instance

Artikel ini menjelaskan ketersediaan tinggi di Azure SQL Managed Instance.

Penting

Konfigurasi redundansi zona berada dalam pratinjau publik untuk tingkat layanan Tujuan Umum dan umumnya tersedia untuk tingkat layanan Business Critical.

Gambaran Umum

Tujuan dari arsitektur ketersediaan tinggi di Azure SQL Managed Instance adalah untuk meminimalkan dampak pada beban kerja pelanggan dari operasi manajemen yang dimulai pelanggan yang mengakibatkan waktu henti singkat, operasi pemeliharaan layanan, dan pemadaman yang tidak diencanakan. Untuk informasi selengkapnya mengenai SLA tertentu untuk tingkat layanan yang berbeda, tinjau Azure SQL Managed Instance.

Ketersediaan tinggi melindungi Anda dari dampak pada:

  • Zona ketersediaan yang membentuk pusat data (jika terjadi wilayah multi-zona)
  • Rak tempat simpul yang mendukung layanan Anda berjalan
  • Node itu sendiri
  • Lapisan aplikasi

Untuk meminimalkan dampak jika terjadi pemadaman regional atau lebih besar, Anda dapat menggunakan salah satu teknik yang tersedia yang tercakup dalam gambaran umum kelangsungan bisnis kami.

SQL Managed Instance berjalan pada versi stabil terbaru SQL Server Database Engine pada sistem operasi Windows dengan semua patch yang berlaku. SQL Managed Instance secara otomatis menangani tugas layanan penting, seperti patching, pencadangan, peningkatan mesin Windows dan SQL, dan peristiwa yang tidak diencana seperti perangkat keras, perangkat lunak, atau kegagalan jaringan yang mendasarinya. Saat instans di-patch atau gagal, waktu henti tidak berdampak jika Anda menggunakan logika coba lagi di aplikasi Anda. SQL Managed Instance dapat dengan cepat pulih bahkan dalam keadaan paling penting, memastikan bahwa data Anda selalu tersedia. Sebagian besar pengguna tidak melihat bahwa peningkatan dilakukan terus menerus.

Solusi ketersediaan tinggi dirancang untuk memastikan bahwa data yang diterapkan tidak pernah hilang karena kegagalan, bahwa operasi pemeliharaan tidak memengaruhi beban kerja Anda, dan bahwa instans tidak akan menjadi satu titik kegagalan dalam arsitektur perangkat lunak Anda.

Ada dua model arsitektur ketersediaan tinggi yang berbeda berdasarkan tingkat layanan:

  • Model penyimpanan jarak jauh didasarkan pada pemisahan komputasi dan penyimpanan di tingkat layanan Tujuan Umum dan Tujuan Umum Generasi Berikutnya yang bergantung pada ketersediaan tinggi dan keandalan penyimpanan jarak jauh dan ketersediaan tinggi kluster komputasi yang dikelola oleh Azure Service Fabric. Model ketersediaan tinggi ini menargetkan aplikasi bisnis berorientasi anggaran yang dapat mentolerir beberapa penurunan performa selama aktivitas pemeliharaan.
  • Model penyimpanan lokal didasarkan pada kluster proses mesin database yang mengandalkan kuorum simpul mesin database yang tersedia di tingkat layanan Business Critical yang memiliki penyimpanan lokal. Model penyimpanan lokal ini menargetkan aplikasi penting misi yang memiliki tingkat transaksi tinggi dan membutuhkan performa IO tinggi. Arsitektur ketersediaan tinggi menjamin dampak performa minimal pada beban kerja Anda selama aktivitas pemeliharaan.

Ketersediaan redundan lokal

Ketersediaan redundan lokal didasarkan pada penyimpanan simpul dan data komputasi Anda dalam satu pusat data di wilayah utama dan melindungi data Anda jika terjadi kegagalan lokal, seperti jaringan skala kecil atau kegagalan daya. Jika bencana skala besar seperti kebakaran atau banjir terjadi dalam suatu wilayah, semua replika akun penyimpanan atau data pada simpul komputasi mungkin hilang atau tidak dapat dipulihkan. Dengan demikian, untuk melindungi data Anda lebih lanjut saat menggunakan opsi ketersediaan redundan secara lokal, pertimbangkan untuk menggunakan opsi penyimpanan yang lebih tangguh untuk cadangan database Anda.

Tingkat layanan Tujuan Umum

Tingkat layanan Tujuan Umum menggunakan arsitektur ketersediaan penyimpanan jarak jauh. Gambar berikut menunjukkan empat node yang berbeda dengan lapisan komputasi dan penyimpanan yang dipisahkan.

Diagram memperlihatkan pemisahan komputasi dan penyimpanan.

Model ketersediaan penyimpanan jarak jauh mencakup dua lapisan:

  • Lapisan komputasi stateless yang menjalankan proses mesin database dan hanya berisi data sementara dan cache, seperti tempdb database dan model pada SSD yang terpasang, dan cache paket, kumpulan buffer, dan kumpulan penyimpan kolom dalam memori. Simpul stateless ini dioperasikan oleh Azure Service Fabric yang menginisialisasi mesin database, mengontrol kesehatan simpul, dan melakukan failover ke simpul lain jika perlu.
  • Lapisan data stateful dengan file database (.mdf dan .ldf) yang disimpan di Azure Blob Storage. Azure Blob Storage memiliki ketersediaan data bawaan dan fitur redundansi. Ketersediaan redundan lokal didasarkan pada penyimpanan data Anda pada penyimpanan redundan lokal (LRS) yang menyalin data Anda tiga kali dalam satu pusat data di wilayah utama. Ini menjamin bahwa setiap rekaman dalam file log atau halaman dalam file data akan dipertahankan bahkan jika proses mesin database crash.

Setiap kali mesin database atau sistem operasi ditingkatkan, atau kegagalan terdeteksi, Azure Service Fabric akan memindahkan proses mesin database stateless ke simpul komputasi stateless lain dengan kapasitas bebas yang memadai. Data di penyimpanan Azure Blob tidak terpengaruh oleh pemindahan, dan file data/log dilampirkan ke proses mesin database yang baru diinisialisasi. Proses ini menjamin ketersediaan tinggi, tetapi beban kerja yang berat mungkin mengalami beberapa penurunan performa selama transisi karena proses mesin database baru dimulai dengan cache dingin.

Tingkat layanan Tujuan Umum generasi berikutnya

Catatan

Peningkatan tingkat layanan Tujuan Umum Next-gen saat ini dalam pratinjau.

Tujuan Umum next-gen adalah peningkatan arsitektur ke tingkat layanan Tujuan Umum yang ada yang menggunakan lapisan penyimpanan jarak jauh yang ditingkatkan yang menyimpan data instans dan file log pada disk terkelola alih-alih blob halaman.

Tingkat layanan Bisnis Kritis

Tingkat layanan Business Critical menggunakan model ketersediaan penyimpanan lokal, yang mengintegrasikan sumber daya komputasi (proses mesin database) dan penyimpanan (SSD yang terpasang secara lokal) pada satu simpul. Ketersediaan tinggi dicapai dengan mereplikasi komputasi dan penyimpanan ke simpul tambahan.

Diagram kluster simpul mesin database.

File database yang mendasar (.mdf/.ldf) ditempatkan pada penyimpanan SSD terlampir untuk menyediakan IO latensi yang sangat rendah untuk beban kerja Anda. Ketersediaan tinggi diimplementasikan menggunakan teknologi yang mirip dengan Grup Ketersediaan AlwaysOn SQL Server. Kluster ini mencakup satu replika utama yang dapat diakses untuk beban kerja pelanggan baca-tulis, dan hingga tiga replika sekunder (komputasi dan penyimpanan) yang berisi salinan data. Replika utama terus mendorong perubahan pada replika sekunder secara berurutan untuk memastikan bahwa data bertahan pada jumlah replika sekunder yang memadai sebelum melakukan setiap transaksi. Proses ini menjamin bahwa, jika replika utama atau replika sekunder yang dapat dibaca menjadi tidak tersedia karena alasan apa pun, replika yang disinkronkan sepenuhnya selalu tersedia untuk gagal. Failover dimulai oleh Azure Service Fabric. Setelah replika sekunder menjadi replika utama baru, replika sekunder lainnya dibuat untuk memastikan kluster memiliki jumlah replika yang memadai untuk mempertahankan kuorum. Setelah failover selesai, koneksi Azure SQL secara otomatis dialihkan ke replika utama baru (atau replika sekunder yang dapat dibaca berdasarkan string koneksi).

Sebagai manfaat tambahan, model ketersediaan penyimpanan lokal mencakup kemampuan untuk mengalihkan koneksi Azure SQL baca-saja ke salah satu replika sekunder. Fitur ini disebut Read Scale-Out. Ini menyediakan 100% kapasitas komputasi tambahan tanpa biaya tambahan untuk operasi baca-saja off-load, seperti beban kerja analitis, dari replika utama.

Ketersediaan zona-redundan

Ketersediaan zona redundan didasarkan pada penempatan simpul komputasi dan replika penyimpanan di tiga zona ketersediaan Azure di wilayah utama. Setiap zona ketersediaan merupakan lokasi fisik terpisah dengan daya independen, pendinginan, dan jaringan.

Secara default, kluster simpul untuk model ketersediaan penyimpanan lokal dibuat di pusat data yang sama. Dengan pengenalan Zona Ketersediaan Azure, SQL Managed Instance dapat menempatkan replika instans Business Critical yang berbeda di zona ketersediaan yang berbeda di wilayah yang sama. Dengan cara yang sama, simpul komputasi stateless dari tingkat layanan Tujuan Umum ditempatkan di zona ketersediaan yang berbeda, sementara penyimpanan stateful menggunakan konfigurasi penyimpanan redundan zona (ZRS ).

Untuk menghilangkan satu titik kegagalan, cincin kontrol juga diduplikasi di beberapa zona sebagai tiga cincin gateway (GW). Perutean ke cincin gateway tertentu dikendalikan oleh Azure Traffic Manager (ATM). Dengan memilih konfigurasi zona-redundan, Anda dapat membuat instans Business Critical atau General Purpose tahan terhadap serangkaian kegagalan yang jauh lebih besar, termasuk pemadaman pusat data bencana, tanpa perubahan apa pun pada logika aplikasi. Anda juga dapat mengonversi instans Business Critical atau General Purpose yang ada ke konfigurasi zona-redundan.

Karena instans zona-redundan memiliki replika di pusat data yang berbeda dengan beberapa jarak di antaranya, latensi jaringan yang meningkat dapat meningkatkan waktu penerapan transaksi, dan dengan demikian berdampak pada performa beberapa beban kerja OLTP. Anda selalu bisa kembali ke konfigurasi zona tunggal dengan menonaktifkan pengaturan redundansi zona. Proses ini adalah operasi online yang mirip dengan peningkatan tujuan tingkat layanan reguler. Pada akhir proses, instans dimigrasikan dari cincin zona-redundan ke cincin zona tunggal atau sebaliknya.

Versi redundan zona dari arsitektur ketersediaan tinggi digambarkan oleh diagram berikut:

Diagram arsitektur ketersediaan tinggi zona-redundan.

Pertimbangkan hal berikut saat menggunakan zona-redundansi:

  • Redundansi zona tidak tersedia untuk tingkat layanan Tujuan Umum Next-gen.
  • Untuk informasi terbaru tentang wilayah yang mendukung konfigurasi redundan zona, lihat Dukungan layanan menurut wilayah.
  • Untuk ketersediaan zona redundan, memilih jendela pemeliharaan selain default saat ini tersedia di wilayah tertentu.

Wilayah yang didukung untuk instans Kritis Bisnis

Redundansi zona untuk SQL Managed Instance Penting Bisnis didukung di wilayah berikut:

Amerika Eropa Timur Tengah Afrika Asia Pasifik
Brasil Selatan Prancis Tengah Qatar Tengah Afrika Selatan Utara Australia Timur
Kanada Tengah Italia Utara Israel Tengah India Tengah
US Tengah Jerman Barat Tengah Jepang Timur
AS Timur Norwegia Timur Korea Tengah
AS Timur 2 Eropa Utara Asia Tenggara
US Tengah Selatan UK Selatan Asia Timur
US Barat 2 Swedia Tengah
AS Barat 3 Swiss Utara
Polandia Tengah

Wilayah yang didukung untuk instans Tujuan Umum

Catatan

Konfigurasi zona-redundan berada dalam pratinjau publik untuk tingkat layanan Tujuan Umum.

Amerika Eropa Timur Tengah Afrika Asia Pasifik
Brasil Selatan Prancis Tengah Qatar Tengah Afrika Selatan Utara Australia Timur
AS Timur Italia Utara Israel Tengah India Tengah
AS Timur 2 Jerman Barat Tengah Jepang Timur
US Tengah Selatan Norwegia Timur Korea Tengah
US Barat 2 Eropa Utara Asia Tenggara
AS Barat 3 UK Selatan Asia Timur
Swedia Tengah
Swiss Utara
Polandia Tengah

Menguji ketahanan kesalahan aplikasi

Ketersediaan tinggi adalah bagian mendasar dari platform SQL Managed Instance yang berfungsi secara transparan untuk aplikasi database Anda. Namun, kami menyadari bahwa Anda mungkin ingin menguji bagaimana operasi failover otomatis yang dimulai selama peristiwa yang direncanakan atau tidak direncanakan akan memengaruhi aplikasi sebelum Anda menyebarkannya ke produksi. Anda dapat memicu failover secara manual dengan memanggil API khusus untuk memulai ulang instans terkelola. Dalam kasus instans zona-redundan, panggilan API akan mengakibatkan pengalihan koneksi klien ke primer baru di Zona Ketersediaan yang berbeda dari Zona Ketersediaan primer lama. Jadi, selain menguji dampak kegagalan pada sesi database yang ada, Anda juga dapat memverifikasi apakah itu mengubah kinerja menyeluruh karena adanya perubahan latensi jaringan. Karena operasi hidupkan ulang mengganggu dan sejumlah besar dari mereka dapat menekankan platform, hanya satu panggilan failover yang diizinkan setiap 15 menit untuk setiap instans terkelola.

Kegagalan dapat dimulai menggunakan PowerShell, REST API, atau Azure CLI:

PowerShell REST API Azure CLI
Invoke-AzSqlInstanceFailover SQL Managed Instance - Failover az sql mi failover dapat digunakan untuk memanggil panggilan REST API dari Azure CLI

Kesimpulan

Azure SQL Managed Instance menampilkan solusi ketersediaan tinggi bawaan yang terintegrasi secara mendalam dengan platform Azure. Layanan ini tergantung pada Service Fabric untuk mendeteksi kegagalan dan pemulihan, penyimpanan Azure Blob untuk melindungi data, dan pada Zona Ketersediaan untuk toleransi kesalahan yang lebih tinggi. Dan untuk tingkat layanan Business Critical, SQL Managed Instance menggunakan teknologi grup ketersediaan AlwaysOn SQL Server untuk replikasi database dan failover. Kombinasi teknologi ini memungkinkan aplikasi untuk sepenuhnya mewujudkan manfaat model penyimpanan campuran dan mendukung SLA yang paling menuntut.

Langkah berikutnya