Ketersediaan tinggi untuk Azure SQL Database

  • Artikel

Berlaku untuk:Azure SQL Database

Artikel ini menjelaskan arsitektur ketersediaan tinggi di Azure SQL Database.

Gambaran Umum

Tujuan dari arsitektur ketersediaan tinggi di Azure SQL Database adalah untuk meminimalkan dampak pada beban kerja pelanggan dari operasi pemeliharaan layanan dan pemadaman. Untuk informasi mengenai SLA tertentu untuk tingkat layanan yang berbeda, lihat SLA untuk Azure SQL Database.

SQL Database berjalan pada versi stabil terbaru SQL Server Database Engine pada sistem operasi Windows dengan semua patch yang berlaku. SQL Database 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 database atau kumpulan elastis di SQL Database di-patch atau gagal, waktu henti tidak berdampak jika Anda menggunakan logika coba lagi di aplikasi Anda. SQL Database 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 database tidak akan menjadi satu titik kegagalan dalam arsitektur perangkat lunak Anda.

Ada tiga model arsitektur ketersediaan tinggi:

  • Model penyimpanan jarak jauh yang didasarkan pada pemisahan komputasi dan penyimpanan. Ini bergantung pada ketersediaan tinggi dan keandalan tingkat penyimpanan jarak jauh. Arsitektur ini menargetkan aplikasi bisnis berorientasi anggaran yang dapat menoleransi beberapa penurunan performa selama aktivitas pemeliharaan.
  • Model penyimpanan lokal yang didasarkan pada kluster proses mesin database. Ini bergantung pada fakta bahwa selalu ada kuorum node mesin database yang tersedia. Arsitektur ini menargetkan aplikasi penting misi dengan performa IO tinggi, tingkat transaksi tinggi, dan menjamin dampak performa minimal pada beban kerja Anda selama aktivitas pemeliharaan.
  • Model Hyperscale yang menggunakan sistem terdistribusi dari komponen yang sangat tersedia seperti simpul komputasi, server halaman, layanan log, dan penyimpanan persisten. Setiap komponen yang mendukung database Hyperscale memberikan redundansi dan ketahanannya sendiri terhadap kegagalan. Simpul komputasi, server halaman, dan layanan log berjalan di Azure Service Fabric, yang mengontrol kesehatan setiap komponen dan melakukan failover ke simpul sehat yang tersedia seperlunya. Penyimpanan persisten menggunakan Azure Storage dengan kemampuan ketersediaan tinggi dan redundansi aslinya. Untuk mempelajari lebih lanjut, lihat Arsitektur Hyperscale.

Dalam masing-masing dari tiga model ketersediaan, SQL Database mendukung opsi redundansi lokal dan redundansi zona. Redundansi lokal memberikan ketahanan dalam pusat data, sementara redundansi zona meningkatkan ketahanan lebih lanjut dengan melindungi dari pemadaman zona ketersediaan dalam suatu wilayah.

Tabel berikut ini memperlihatkan opsi ketersediaan berdasarkan tingkat layanan:

Tingkat layanan Model ketersediaan tinggi ketersediaan redundan lokal Ketersediaan zona-redundan
Tujuan Umum (vCore) Penyimpanan Jarak Jauh Ya Ya
Kritis Bisnis (vCore) Penyimpanan lokal Ya Ya
Hyperscale (vCore) Hyperscale Ya Ya
Dasar (DTU) Penyimpanan Jarak Jauh Ya Tidak
Standar (DTU) Penyimpanan Jarak Jauh Ya Tidak
Premium (DTU) Penyimpanan lokal Ya Ya

Ketersediaan redundan lokal

Ketersediaan redundan lokal didasarkan pada penyimpanan database Anda ke penyimpanan redundan lokal (LRS) yang menyalin data Anda tiga kali dalam satu pusat data di wilayah utama dan melindungi data Anda jika terjadi kegagalan lokal, seperti jaringan skala kecil atau kegagalan daya. LRS adalah opsi redundansi berbiaya terendah dan menawarkan durabilitas paling rendah dibandingkan dengan opsi lain. Jika bencana skala besar seperti kebakaran atau banjir terjadi dalam suatu wilayah, semua replika akun penyimpanan yang menggunakan LRS 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. Ini tidak berlaku untuk database Hyperscale, di mana penyimpanan yang sama digunakan untuk file data dan cadangan.

Ketersediaan redundan lokal tersedia untuk semua database di semua tingkat layanan dan Tujuan Titik Pemulihan (RPO) yang menunjukkan jumlah kehilangan data adalah nol.

Tingkat layanan Dasar, Standar, dan Tujuan Umum

Tingkat layanan Dasar, Standar, dan Tujuan Umum menggunakan model ketersediaan penyimpanan jarak jauh untuk komputasi tanpa server dan yang disediakan. 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. 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 Premium dan Bisnis Penting

Tingkat layanan Premium dan 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 mendasari (.mdf/.ldf) ditempatkan pada penyimpanan SSD yang dilampirkan untuk menyediakan IO latensi yang sangat rendah ke 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-menerus mendorong perubahan pada replika sekunder secara berurutan dan memastikan bahwa data disimpan pada jumlah replika sekunder yang memadai sebelum melakukan setiap transaksi. Proses ini menjamin bahwa jika replika utama atau crash replika sekunder yang dapat dibaca karena alasan apa pun, selalu ada replika yang sepenuhnya disinkronkan untuk gagal. Kegagalan 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.

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.

Tingkat layanan Hyperscale

Arsitektur tingkat layanan Hyperscale dijelaskan dalam arsitektur Fungsi terdistribusi.

Diagram memperlihatkan arsitektur fungsional Hyperscale.

Model ketersediaan di Hyperscale mencakup empat lapisan:

  • Lapisan komputasi stateless yang menjalankan proses mesin database dan hanya berisi data sementara dan cache, seperti cache RBPEX yang tidak mencakup, tempdb dan model database, dll. pada SSD yang terpasang, dan cache rencana, kumpulan buffer, dan kumpulan penyimpanan kolom dalam memori. Lapisan stateless ini mencakup replika komputasi utama, dan secara opsional sejumlah replika komputasi sekunder, yang dapat berfungsi sebagai target failover.
  • Lapisan penyimpanan stateless yang dibentuk oleh server halaman. Lapisan ini adalah mesin penyimpanan terdistribusi untuk proses mesin database yang berjalan pada replika komputasi. Setiap server halaman hanya berisi data sementara dan cache, seperti mencakup cache RBPEX pada SSD yang dilampirkan, dan halaman data yang di-cache di memori. Setiap server halaman memiliki server halaman yang dipasangkan dalam konfigurasi aktif-aktif untuk memberikan keseimbangan beban, redundansi, dan ketersediaan tinggi.
  • Lapisan penyimpanan log transaksi berstatus yang dibentuk oleh node komputasi yang menjalankan proses layanan Log, zona landasan log transaksi, dan penyimpanan jangka panjang log transaksi. Zona landasan dan penyimpanan jangka panjang menggunakan Azure Storage, yang menyediakan ketersediaan dan redundansi untuk log transaksi, sehingga memastikan durabilitas data untuk transaksi yang diterapkan.
  • Lapisan penyimpanan data stateful dengan file database (.mdf/.ndf) yang disimpan di Azure Storage dan diperbarui oleh server halaman. Lapisan ini menggunakan fitur ketersediaan data dan redundansi Azure Storage. Ini menjamin bahwa setiap halaman dalam file data akan dipertahankan bahkan jika proses di lapisan lain dari arsitektur Hyperscale mengalami crash, atau jika node komputasi gagal.

Node komputasi di semua lapisan Hyperscale berjalan pada Azure Service Fabric, yang mengontrol kondisi setiap node dan melakukan kegagalan ke node sehat yang tersedia jika perlu.

Untuk informasi selengkapnya tentang ketersediaan tinggi di Hyperscale, lihat Ketersediaan Tinggi Database di Hyperscale.

Ketersediaan zona-redundan

Ketersediaan zona redundan memastikan data Anda tersebar di tiga zona ketersediaan Azure di wilayah utama. Setiap zona ketersediaan merupakan lokasi fisik terpisah dengan daya independen, pendinginan, dan jaringan.

Ketersediaan zona-redundan tersedia untuk database di tingkat layanan Premium, Business Critical, General Purpose dan Hyperscale, dan bukan tingkat layanan Dasar dan Standar dari model pembelian berbasis DTU. Setiap tingkat layanan menerapkan ketersediaan zona redundan secara berbeda. Lihat detail untuk setiap tingkat layanan di bagian berikut. Semua implementasi memastikan Tujuan Titik Pemulihan (RPO) dengan tidak ada kehilangan data yang diterapkan setelah failover.

Tingkat layanan Tujuan Umum

Konfigurasi zona-redundan untuk tingkat layanan Tujuan Umum ditawarkan untuk komputasi tanpa server dan tersedia untuk database dalam model pembelian vCore. Konfigurasi ini menggunakan Zona Ketersediaan Azure untuk mereplikasi database di beberapa lokasi fisik dalam wilayah Azure. Dengan memilih redundansi zona, Anda dapat membuat database tunggal dan kumpulan elastis tanpa server dan General Purpose diprovisikan yang baru dan yang sudah ada yang tahan terhadap serangkaian kegagalan yang jauh lebih besar, termasuk pemadaman pusat data besar-besaran, tanpa perubahan pada logika aplikasi.

Konfigurasi zona-redundan untuk tingkat Tujuan Umum memiliki dua lapisan:

  • Lapisan data yang stateful dengan file database (.mdf/.ldf) yang disimpan dalam ZRS (penyimpanan redundansi zona). Dengan ZRS, data dan file log disalin secara sinkron di tiga zona ketersediaan Azure yang terisolasi secara fisik.
  • Lapisan komputasi stateless yang menjalankan proses sqlservr.exe dan hanya berisi data sementara dan cache, seperti tempdb database dan model pada SSD terlampir, dan cache paket, kumpulan buffer, dan kumpulan penyimpan kolom dalam memori. Node tanpa status ini dioperasikan oleh Microsoft Azure Service Fabric yang menginisialisasi sqlservr.exe, mengontrol kondisi node, dan melakukan kegagalan ke node lain jika perlu. Untuk database Tujuan Umum tanpa server dan tersedia zona-redundan, simpul dengan kapasitas cadangan tersedia di Zona Ketersediaan lain untuk failover.

Versi zona redundan dari arsitektur ketersediaan tinggi untuk tingkat layanan Tujuan Umum diilustrasikan oleh diagram berikut:

Diagram konfigurasi zona redundan untuk Tujuan Umum.

Pertimbangkan hal berikut saat mengonfigurasi database Tujuan Umum Anda dengan redundansi zona:

  • Untuk tingkat Tujuan Umum, konfigurasi zona-redundan Umumnya Tersedia di wilayah berikut:
    • (Afrika) Afrika Selatan Utara
    • (Asia Pasifik) Australia Timur
    • (Asia Pasifik) Asia Timur
    • (Asia Pasifik) Jepang Timur
    • (Asia Pasifik) Korea Tengah
    • (Asia Pasifik) Asia Tenggara
    • (Asia Pasifik) India Tengah
    • (Asia Pasifik) Tiongkok Utara 3
    • (Asia Pasifik) UEA Utara
    • (Eropa) Prancis Tengah
    • (Eropa) Jerman Barat Tengah
    • (Eropa) Italia Utara
    • (Eropa) Eropa Utara
    • (Eropa) Norwegia Timur
    • (Eropa) Polandia Tengah
    • (Eropa) Eropa Barat
    • (Eropa) UK Selatan
    • (Eropa) Swiss Utara
    • (Eropa) Swedia Tengah
    • (Timur Tengah) Israel Tengah
    • (Timur Tengah) Qatar Tengah
    • (Amerika Utara) Kanada Tengah
    • (Amerika Utara): US Timur
    • (Amerika Utara): US Timur 2
    • (Amerika Utara) US Tengah Selatan
    • (Amerika Utara): US Barat 2
    • (Amerika Utara): US Barat 3
    • (Amerika Selatan) Brasil Selatan
  • Untuk ketersediaan zona redundan, memilih jendela pemeliharaan selain default saat ini tersedia di wilayah tertentu.
  • Konfigurasi zona-redundan hanya tersedia di SQL Database saat perangkat keras seri standar (Gen5) dipilih.
  • Redundansi zona tidak tersedia untuk tingkat layanan Dasar dan Standar dalam model pembelian DTU.

Tingkat layanan Premium dan Bisnis Penting

Ketika Redundansi Zona diaktifkan untuk tingkat layanan Premium atau Bisnis Penting, replika ditempatkan di zona ketersediaan yang berbeda di wilayah yang sama. Untuk menghilangkan satu titik kegagalan, cincin kontrol juga diduplikasi di beberapa zona sebagai tiga cincin gateway (GW). Perutean ke cincin gateway tertentu dikontrol oleh Azure Traffic Manager. Karena konfigurasi zona-redundan di tingkat layanan Premium atau Business Critical menggunakan replika yang ada untuk ditempatkan di zona ketersediaan yang berbeda, Anda dapat mengaktifkannya tanpa biaya tambahan. Dengan memilih konfigurasi zona-redundan, Anda dapat membuat database Premium atau Business Critical dan kumpulan elastis tahan terhadap serangkaian kegagalan yang jauh lebih besar, termasuk pemadaman pusat data bencana, tanpa perubahan apa pun pada logika aplikasi. Anda juga dapat mengonversi database Premium atau Business Critical atau kumpulan elastis yang ada ke konfigurasi zona redundan.

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

Diagram arsitektur ketersediaan tinggi zona-redundan.

Pertimbangkan hal berikut saat mengonfigurasi database Premium atau Bisnis Penting Anda dengan redundansi zona:

Tingkat layanan Hyperscale

Dimungkinkan untuk mengonfigurasi redundansi zona untuk database di tingkat layanan Hyperscale. Untuk mempelajari lebih lanjut, tinjau Membuat database Hyperscale zona-redundan.

Aktivasi konfigurasi ini memastikan ketahanan tingkat zona melalui replikasi di seluruh Zona Ketersediaan untuk semua lapisan Hyperscale. Dengan memilih zona-redundansi, Anda dapat membuat database Hyperscale Anda tahan terhadap serangkaian kegagalan yang jauh lebih besar, termasuk pemadaman pusat data yang fatal, tanpa perubahan apa pun pada logika aplikasi. Semua wilayah Azure yang memiliki Zona Ketersediaan mendukung database Hyperscale zona redundan.

Ketersediaan redundansi zona didukung dalam database mandiri Hyperscale dan kumpulan elastis Hyperscale. Untuk informasi selengkapnya, lihat Kumpulan elastis Hyperscale.

Diagram berikut menunjukkan arsitektur yang mendasari untuk database Hyperscale zona redundan:

Diagram memperlihatkan arsitektur yang mendasari database Hyperscale zona redundan.

Pertimbangkan batasan berikut:

  • Konfigurasi redundan zona hanya dapat ditentukan selama pembuatan database. Pengaturan ini tidak dapat dimodifikasi setelah sumber daya disediakan. Gunakan Salinan Database, pemulihan titik waktu, atau buat replika-geografis untuk memperbarui konfigurasi redundan zona pada database Hyperscale yang ada. Ketika menggunakan salah satu opsi pembaruan ini, jika database target berada di wilayah yang berbeda dari sumber atau jika redundansi penyimpanan pencadangan database dari target berbeda dengan database sumber, operasi penyalinan akan menjadi ukuran operasi data.

  • Untuk ketersediaan zona redundan, memilih jendela pemeliharaan selain default saat ini tersedia di wilayah tertentu.

  • Saat ini tidak ada opsi untuk menentukan redundansi zona saat memigrasikan database ke Hyperscale menggunakan portal Azure. Namun, redundansi zona dapat ditentukan menggunakan Azure PowerShell, Azure CLI, atau REST API saat memigrasikan database yang ada dari tingkat layanan Azure SQL Database lain ke Hyperscale. Berikut adalah contoh dengan Azure CLI:

    az sql db update --resource-group "myRG" --server "myServer" --name "myDB" --edition Hyperscale --zone-redundant true

  • Setidaknya 1 replika komputasi ketersediaan tinggi dan penggunaan penyimpanan cadangan zona-redundan atau geo-zona-redundan diperlukan untuk mengaktifkan konfigurasi zona redundan untuk Hyperscale.

Ketersediaan redundan zona database

Di Azure SQL Database, server adalah konstruksi logis yang bertindak sebagai titik administratif pusat untuk kumpulan database. Di tingkat server, Anda dapat mengelola login, metode autentikasi, aturan firewall, aturan audit, kebijakan deteksi ancaman, dan grup failover. Data yang terkait dengan beberapa fitur ini, seperti login dan aturan firewall, disimpan dalam master database. Demikian pula, data untuk beberapa DMV, misalnya sys.resource_stats, juga disimpan dalam master database.

Ketika database dengan konfigurasi zona-redundan dibuat di server logis, master database yang terkait dengan server juga secara otomatis dibuat zona-redundan. Ini memastikan bahwa dalam pemadaman zona, aplikasi yang menggunakan database tetap tidak terpengaruh karena fitur tergantung pada master database, seperti login dan aturan firewall, masih tersedia. master Membuat zona-redundan database adalah proses asinkron dan akan memakan waktu untuk menyelesaikan di latar belakang.

Ketika tidak ada database di server yang redundan zona, atau ketika Anda membuat server kosong, maka master database yang terkait dengan server tidak zona-redundan.

Anda dapat menggunakan Azure PowerShell atau Azure CLI atau REST API untuk memeriksa ZoneRedundant properti untuk master database:

Gunakan perintah contoh berikut untuk memeriksa nilai properti "ZoneRedundant" untuk master database.

Get-AzSqlDatabase -ResourceGroupName "myResourceGroup" -ServerName "myServerName" -DatabaseName "master"

Menguji ketahanan kesalahan aplikasi

Ketersediaan tinggi adalah bagian mendasar dari platform SQL Database 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 database, atau kumpulan elastis. Dalam kasus database atau kumpulan elastis General Purpose tanpa server atau diprovisikan yang bersifat redundan zona, panggilan API akan mengalihkan 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 database atau kumpulan elastis.

Untuk informasi selengkapnya tentang ketersediaan tinggi dan pemulihan bencana Azure SQL Database, tinjau Daftar Periksa KETERSEDIAAN TINGGI/DR.

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

Jenis penyebaran PowerShell REST API Azure CLI
Database Invoke-AzSqlDatabaseFailover Kegagalan database az rest mungkin digunakan untuk memanggil panggilan REST API dari Azure CLI
Kumpulan elastis Invoke-AzSqlElasticPoolFailover Kegagalan kumpulan elastis az rest mungkin digunakan untuk memanggil panggilan REST API dari Azure CLI

Penting

Perintah Kegagalan tidak tersedia untuk replika sekunder database Hyperscale yang dapat dibaca.

Kesimpulan

Azure SQL Database memiliki solusi ketersediaan tinggi bawaan yang terintegrasi secara mendalam dengan platform Azure. Ini tergantung pada Service Fabric untuk deteksi dan pemulihan kegagalan, pada penyimpanan Azure Blob untuk perlindungan data, dan pada Zona Ketersediaan untuk toleransi kesalahan yang lebih tinggi. Selain itu, SQL Database menggunakan teknologi grup ketersediaan AlwaysOn dari SQL Server untuk sinkronisasi dan failover data. Kombinasi teknologi ini memungkinkan aplikasi untuk sepenuhnya mewujudkan manfaat model penyimpanan campuran dan mendukung SLA yang paling menuntut.

Konten terkait