Bagikan melalui

Ketersediaan melalui redundansi lokal dan zona - Azure SQL Managed Instance

  • Artikel

Berlaku untuk:Azure SQL Managed Instance

Artikel ini menjelaskan arsitektur Azure SQL Managed Instance yang mencapai ketersediaan melalui redundansi lokal, dan ketersediaan tinggi melalui redundansi zona.

Penting

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

Gambaran Umum

SQL Managed Instance berjalan pada versi stabil terbaru mesin database SQL Server pada sistem operasi Windows dengan semua patch yang berlaku. SQL Managed Instance secara otomatis menangani tugas layanan penting, seperti patching, pencadangan, peningkatan mesin database 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.

Secara default, Azure SQL Managed Instance mencapai ketersediaan melalui redundansi lokal, membuat instans Anda tersedia selama:

  • Operasi manajemen yang dimulai pelanggan yang mengakibatkan waktu henti singkat
  • Operasi pemeliharaan layanan
  • Masalah dan pemadaman pusat data dengan:
    • rak tempat mesin yang mendukung layanan Anda berjalan
    • komputer fisik yang menghosting VM yang menjalankan mesin database SQL
    • komputer virtual yang menjalankan mesin database SQL
  • Masalah lain dengan mesin database SQL
  • Potensi pemadaman lokal lain yang tidak dienkripsi

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

Namun, untuk meminimalkan dampak pada data Anda jika terjadi pemadaman ke seluruh zona, Anda dapat mencapai ketersediaan tinggi dengan mengaktifkan redundansi zona. Tanpa redundansi zona, failover terjadi secara lokal dalam pusat data yang sama, yang dapat mengakibatkan instans Anda tidak tersedia sampai pemadaman diselesaikan - satu-satunya cara untuk memulihkan adalah melalui solusi pemulihan bencana, seperti melalui grup failover, atau pemulihan geografis cadangan geo-redundan. Untuk mempelajari lebih lanjut, tinjau gambaran umum kelangsungan bisnis.

Ketersediaan tinggi meningkatkan keandalan layanan Anda dengan melindungi Anda dari dampak pada:

  • Zona ketersediaan yang membentuk pusat data

Ada dua model arsitektur ketersediaan 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 dan keandalan penyimpanan jarak jauh dan ketersediaan kluster komputasi yang dikelola oleh Azure Service Fabric. Model ketersediaan 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.

Untuk informasi selengkapnya mengenai SLA tertentu untuk tingkat layanan yang berbeda, tinjau SLA untuk Azure SQL Managed Instance.

Ketersediaan melalui redundansi 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 dan memeliharanya secara lokal.

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 tinggi melalui redundansi zona

Ketersediaan zona redundan didasarkan pada penempatan replika 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 menempatkan replika yang berbeda di zona ketersediaan yang berbeda di wilayah yang sama. Untuk menghilangkan satu titik kegagalan, cincin kontrol juga diduplikasi di beberapa zona. Lalu lintas sarana kontrol kemudian dirutekan ke load balancer yang juga disebarkan di seluruh zona ketersediaan. Perutean lalu lintas dari sarana kontrol ke penyeimbang muatan dikendalikan oleh Azure Traffic Manager (ATM).

Dengan menggunakan 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 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.

Untuk mulai menggunakan redundansi zona untuk instans terkelola SQL Anda, tinjau Mengonfigurasi redundansi zona.

Tingkat layanan Tujuan Umum

Dalam tingkat layanan Tujuan Umum, redundansi zona dicapai dengan menempatkan simpul komputasi tanpa status di zona ketersediaan yang berbeda dan kemudian bergantung pada penyimpanan redundan zona stateful (ZRS) yang melekat pada simpul mana pun yang saat ini berisi proses Mesin Database SQL aktif. Jika terjadi pemadaman, proses SQL Database Engine menjadi aktif pada salah satu node stateless, yang kemudian mengakses data dalam penyimpanan stateful.

Diagram berikut menunjukkan arsitektur redundansi zona untuk tingkat layanan Tujuan Umum:

Diagram arsitektur redundansi zona di tingkat layanan Tujuan Umum.

Catatan

Redundansi zona saat ini dalam pratinjau untuk tingkat layanan Tujuan Umum.

Tingkat layanan Bisnis Kritis

Di tingkat layanan Business Critical, redundansi zona dicapai dengan menempatkan replika komputasi dan penyimpanan di zona ketersediaan yang berbeda dan kemudian menggunakan teknologi grup ketersediaan AlwaysOn yang mendasarinya untuk mereplikasi perubahan data dari instans utama ke replika siaga di zona ketersediaan lainnya. Jika terjadi pemadaman, ada failover otomatis yang dengan mulus mentransisikan salah satu replika siaga menjadi primer.

Diagram berikut menunjukkan arsitektur redundansi zona untuk tingkat layanan Business Critical:

Diagram arsitektur redundansi zona di tingkat layanan Business Critical.

Menguji ketahanan kesalahan aplikasi

Ketersediaan 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. 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.

Selama failover benar, koneksi ke instans gagal sementara layanan SQL menjadi utama pada node yang berbeda. Untuk mensimulasikan failover, panggil perintah yang memulai ulang proses SQL untuk mensimulasikan memulai layanan seolah-olah ada failover. Namun, koneksi mungkin gagal untuk jangka waktu yang lebih lama selama failover benar dibandingkan dengan failover yang disimulasikan, karena selama failover yang sebenarnya, proses SQL menjadi yang utama pada komputer virtual lain dalam kluster (baik secara lokal, atau di zona lain jika redundansi zona diaktifkan) dan selama failover yang disimulasikan, proses SQL dimulai ulang pada komputer virtual yang ada.

Perintah failover manual di bagian ini bertindak dengan cara yang sama dalam konfigurasi redundan lokal, dan zona-redundan - hanya memulai ulang proses SQL secara lokal, dan tidak memulai failover ke node lain. Failover lokal ini berbeda dengan failover yang terjadi untuk grup failover.

Failover lokal 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