Bagikan melalui

Gambaran umum operasi manajemen di Azure SQL Managed Instance

Berlaku untuk:Azure SQL Managed Instance

Artikel ini memberikan gambaran umum tentang berbagai operasi yang terjadi saat mengelola Azure SQL Managed Instance. Operasi manajemen adalah operasi yang dilakukan pada backend saat Anda membuat, memperbarui, atau menghapus instans.

Untuk deskripsi terperinci tentang langkah-langkah dan perkiraan durasi setiap operasi manajemen, tinjau Durasi operasi Manajemen.

Apa itu operasi manajemen?

Mengelola Azure SQL Managed Instance melibatkan operasi berikut:

  • Buat: Operasi yang terjadi saat Anda pertama kali membuat instans terkelola SQL baru. Ini termasuk membuat grup komputer virtual (VM) yang mendasar, dan menyebarkan proses Mesin Database SQL.
  • Pembaruan: Operasi yang terjadi saat Anda mengubah properti instans terkelola SQL yang ada, seperti menskalakan komputasi atau penyimpanan, mengubah tingkat layanan, atau memperbarui konfigurasi instans. Membuat pembaruan sering melibatkan mengubah ukuran grup VM, serta menyemai data, lalu melakukan failover, ke proses Mesin Database SQL baru.
  • Hapus: Operasi yang terjadi saat Anda menghapus instans terkelola SQL yang ada, termasuk pembersihan sumber daya seperti grup VM yang terkait dengan instans.

Untuk deskripsi terperinci tentang langkah-langkah dan perkiraan durasi setiap operasi manajemen, tinjau Durasi operasi Manajemen.

Operasi manajemen SQL Managed Instance dicapai melalui proses yang mendasar berikut:

  • Operasi grup komputer virtual (VM): Operasi yang melibatkan pembuatan dan pengelolaan grup VM yang mendasar yang menghosting instans terkelola SQL. Ini termasuk mengubah ukuran grup VM, membuat grup VM baru, dan mengelola komputer virtual dalam grup tersebut.
  • Seeding: Inisialisasi dan sinkronisasi data pada proses SQL Database Engine, biasanya untuk mempersiapkan failover.
  • Failover: Operasi yang terlibat dalam failover lalu lintas ke proses SQL Database Engine lain, baik dalam grup VM yang sama, atau di grup VM baru.

Operasi grup VM

Untuk mendukung penerapan dalam jaringan virtual Azure dan memberikan isolasi serta keamanan bagi pelanggan, Azure SQL Managed Instance mengandalkan kluster virtual. Kluster virtual mewakili sekumpulan komputer virtual (VM) terisolasi khusus yang disebarkan di dalam subnet jaringan virtual Anda dan diatur dalam grup VM. Pada dasarnya, setiap instans terkelola SQL yang disebarkan ke subnet kosong menghasilkan kluster virtual baru yang membangun grup VM pertama.

Operasi manajemen berikutnya pada instans terkelola SQL dapat memengaruhi grup VM yang mendasar. Perubahan yang memengaruhi grup VM yang mendasar dapat memengaruhi durasi operasi manajemen, karena menyebarkan lebih banyak komputer virtual ke kluster virtual dilengkapi dengan overhead yang perlu Anda pertimbangkan ketika Anda merencanakan penyebaran atau pembaruan baru ke instans yang ada.

Untuk informasi terperinci tentang arsitektur kluster virtual, lihat Arsitektur kluster virtual.

Pemberian benih

Penyemaian memainkan peran penting dalam pengoperasian Azure SQL Managed Instance, terutama selama penyiapan dan replikasi database. Penyemaian adalah proses yang menginisialisasi dan menyinkronkan data di seluruh proses SQL Database Engine, yang merupakan bagian penting dari manajemen instans. Meskipun seringkali langkah yang paling memakan waktu dalam operasi yang panjang tetapi berhasil, penyemaian berfungsi sebagai landasan untuk membangun lingkungan instans terkelola SQL yang sehat dan fungsional.

Untuk perkiraan durasi operasi penyemaian, lihat Durasi operasi manajemen.

Proses penyemaian biasanya melibatkan tahapan berikut, terlepas dari tingkat layanan:

  • Inisialisasi: Sistem mengidentifikasi database sumber dan tujuan dan memulai sejumlah tugas yang menyiapkan proses Mesin Database SQL untuk transfer data.
  • Transfer Data: Paket data aktual ditransfer dari sumber ke proses Mesin SQL Database target, yang mencakup salinan lengkap atau sebagian database, tergantung pada skenarionya.
  • Sinkronisasi: Setelah transfer data awal selesai, sistem menyinkronkan pembaruan atau perubahan berikutnya melalui replikasi blok log transaksi untuk memastikan integritas data.
  • Validasi dan finalisasi: Proses diselesaikan, dan proses Mesin SQL Database target divalidasi untuk mengonfirmasi keberhasilan replikasi dan penyemaian. Failover terjadi sehingga lalu lintas dirutekan ke proses Mesin Database SQL baru.

Tidak ada penyemaian data di tingkat layanan Tujuan Umum kecuali ketika Anda mengubah tingkat layanan ke tingkat layanan Business Critical . Operasi manajemen di tingkat layanan Tujuan Umum melibatkan pencopotan penyimpanan jarak jauh dari proses Mesin Database SQL lama dan melampirkannya ke proses Mesin Database SQL baru.

Sebaliknya, lapisan layanan Business Critical, yang dirancang untuk beban kerja berkinerja tinggi, memerlukan penyimpanan lokal dan ketergantungan antara lapisan komputasi dan penyimpanan. Akibatnya, hampir setiap operasi dan skenario dalam tingkat layanan ini memerlukan penyemaian untuk memastikan ketersediaan dan konsistensi data.

Apakah penyemaian dipicu atau tidak tergantung pada skenario dan tingkat layanan tertentu, seperti:

  • Tingkat layanan Tujuan Umum dan Tujuan Umum Generasi Berikutnya :
    • Mengubah ke tingkat layanan Business Critical – data harus ditransfer dari penyimpanan jarak jauh ke penyimpanan lokal yang digunakan di tingkat layanan Tujuan Umum.
    • Mengaktifkan atau menonaktifkan redundansi zona – data harus disalin ke atau dari wilayah zona redundan.
  • Tingkat layanan Bisnis Penting:
    • Penyimpanan penskalaan: Karena penyimpanan secara fisik terpasang ke komputer lokal, setiap perubahan penyimpanan memerlukan pembuatan grup VM baru, sehingga data harus ditransfer dari komputer lama ke komputer baru (pada semua 4 replika).
    • Penskalaan vCore: Setiap operasi penskalaan komputasi memerlukan pembuatan grup VM baru, sehingga data harus disalin dari komputer lama ke komputer baru (pada semua 4 replika).
    • Mengubah jendela perangkat keras atau pemeliharaan: Jika grup VM sudah ada dalam subnet dengan konfigurasi yang cocok, grup VM tersebut akan diubah ukurannya. Jika ini adalah konfigurasi baru, maka grup VM baru dibuat. Data harus disalin dari grup VM lama ke grup VM baru (pada semua 4 replika).
    • Mengubah tingkat layanan: Data harus disalin dari penyimpanan lokal ke penyimpanan jarak jauh yang digunakan di tingkat layanan Tujuan Umum.
    • Mengaktifkan atau menonaktifkan redundansi zona – data harus disalin ke atau dari wilayah zona redundan.

Kecepatan penyemaian

Faktor-faktor berikut memengaruhi durasi proses penyemaian:

  • Ukuran database: Database yang lebih besar memerlukan lebih banyak waktu untuk mentransfer data dan menyinkronkan di seluruh proses SQL Database Engine.
  • Dependensi jaringan: Bandwidth dan latensi jaringan dapat secara signifikan memengaruhi kecepatan penyemaian.
  • Operasi pencadangan dan pemulihan: Operasi pencadangan yang sedang berlangsung pada proses SQL Database Engine sumber dapat memengaruhi persiapan data untuk dikirim ke proses Mesin Database SQL lain.
  • Beban kerja instans: Beban kerja instans selama penyemaian dapat menyebabkan pembatasan kecepatan dan memperpanjang proses secara signifikan.

Meskipun sebagian besar faktor ini berada di luar kendali Anda, Anda dapat mengelola lalu lintas instans untuk mengoptimalkan kecepatan penyemaian secara signifikan. Penyemaian menggunakan sumber daya komputasi instans yang sama yang mengelola lalu lintas instans. Lalu lintas yang berat pada saat penyemaian dapat mengurangi ketersediaan vCore, mengakibatkan kapasitas yang tidak mencukupi untuk proses penyemaian, sehingga menyebabkan penghambatan kinerja.

Lalu lintas tinggi selama penyemaian dapat memengaruhi sinkronisasi karena penyemaian dirancang untuk mengemas dan mentransfer semua data yang saat ini disimpan dalam satu operasi. Perubahan data berikutnya pada proses Mesin Database SQL lama yang tiba setelah penyemaian dimulai harus disinkronkan ke proses Mesin Database SQL baru secara bertahap melalui replikasi blok log transaksi sebelum failover dapat terjadi. Jika instance berada di bawah beban berat, upaya pemancaran data mungkin mengalami kesulitan dalam mengikuti arus data masuk, menyebabkan keterlambatan serta potensi kegagalan pada tahap sinkronisasi. Lalu lintas tinggi berkelanjutan pada proses Mesin Database SQL lama setelah penyemaian dimulai dapat menyebabkan situasi di mana fase sinkronisasi tidak pernah selesai, karena data baru terus tiba dan harus ditransfer. Ini dapat mengakibatkan siklus transfer data abadi yang mencegah failover ke proses SQL Database Engine baru.

Untuk perkiraan durasi operasi penyemaian, lihat Durasi operasi manajemen.

Infrastruktur dan pemberitahuan Azure

Penyemaian adalah proses yang tidak dapat diukur secara tepat atau diprediksi secara ketat, karena bergantung pada layanan Azure bersama. Operasi transfer dan penyemaian data bergantung pada berbagai layanan dan infrastruktur Azure internal, yang dibagikan di seluruh ekosistem Azure. Layanan ini digunakan oleh banyak layanan lain yang tidak terkait dalam Azure. Semua layanan dalam ekosistem Azure bersaing untuk sumber daya yang tersedia, yang menyebabkan fluktuasi ketersediaan sesaat dipengaruhi oleh beberapa faktor. Meskipun Microsoft dapat menyediakan rentang di mana kapasitas infrastruktur beroperasi, membuat prediksi yang tepat sangat menantang.

Pengalihan Cadangan

Failover instans SQL adalah saat ketika lalu lintas dirutekan dari proses lama Mesin Database SQL ke proses baru Mesin Database SQL di node dalam grup VM yang mencakup instans terkelola SQL. Failover adalah bagian krusial dari sebagian besar operasi manajemen, terutama saat memperbarui instance. Momen singkat koneksi yang rusak saat lalu lintas dialihkan ke proses Mesin Database SQL baru disebut sebagai failover.

Instans Anda hanya tidak tersedia selama failover, ketika lalu lintas dialihkan ke proses SQL Database Engine baru. Di tingkat layanan Business Critical , instans Anda tidak tersedia hingga 20 detik, sementara di tingkat layanan Tujuan Umum , instans Anda dapat tidak tersedia hingga 2 menit. Setiap operasi backend yang dilakukan untuk mempersiapkan failover akibat operasi manajemen, seperti penanaman ulang database di tingkat layanan Business Critical, dilakukan di latar belakang dan tidak memengaruhi ketersediaan instans Anda.

Penting

Untuk operasi pembaruan yang tidak selesai di tempat tetapi mengakibatkan pemasangan ulang database (seperti penskalaan vCore, penskalaan memori, mengubah perangkat keras, atau mengubah jendela pemeliharaan), durasi failover database pada tingkat layanan skala Tujuan Umum Next-gen meningkat dengan jumlah database, hingga maksimum 10 menit. Meskipun instans tersedia setelah 2 menit, beberapa database mungkin tersedia setelah penundaan. Durasi failover diukur sejak database pertama offline, hingga saat database terakhir online. Tingkat layanan Tujuan Umum Next-gen meningkatkan jumlah maksimum database per instans dari 100 menjadi 500.

Perbedaan arsitektur antara tingkat layanan dijelaskan secara mendalam dalam ketersediaan.

Lintas dampak operasi manajemen

Operasi manajemen pada instans terkelola SQL dapat memengaruhi operasi manajemen instans lain yang ditempatkan di dalam subnet yang sama:

  • Operasi pemulihan yang memakan waktu lama dalam kluster virtual menempatkan operasi lain di kluster virtual yang sama dalam keadaan tertunda, seperti operasi pembuatan atau skala.

    Contoh: Jika ada operasi pemulihan yang berjalan lama, dan juga permintaan skala yang menyusutkan grup VM, permintaan penyusutan membutuhkan waktu lebih lama untuk diselesaikan karena menunggu operasi pemulihan selesai sebelum dapat dilanjutkan.

  • Operasi pembuatan atau penskalaan instans berikutnya ditangguhkan oleh pembuatan instans atau skala instans yang dimulai sebelumnya yang memulai perubahan ukuran grup VM.

    Contoh: Jika ada beberapa permintaan untuk membuat dan/atau menskalakan di subnet yang sama di bawah grup VM yang sama, dan salah satunya memulai pengubahan ukuran grup VM, semua permintaan yang dikirimkan lebih dari 1 menit setelah permintaan operasi awal berlangsung lebih lama dari yang diharapkan, karena permintaan ini harus menunggu perubahan ukuran selesai sebelum dilanjutkan.

  • Operasi membuat/menskala yang dikirimkan dalam jendela waktu 1 menit dikelompokkan dan dijalankan secara paralel.

    Contoh: Hanya satu perubahan ukuran kluster virtual yang dilakukan untuk semua operasi yang dikirimkan dalam jendela 1 menit (diukur sejak saat permintaan operasi pertama dikirimkan). Jika permintaan lain dikirimkan lebih dari 1 menit setelah permintaan pertama dikirimkan, permintaan tersebut menunggu perubahan ukuran kluster virtual selesai sebelum eksekusi dimulai.

Penting

Operasi manajemen yang ditangguhkan karena operasi lain yang sedang berlangsung secara otomatis dilanjutkan setelah kondisi untuk melanjutkan terpenuhi. Pengguna tidak perlu melakukan apa pun untuk melanjutkan operasi manajemen yang dijeda sementara.

Memantau operasi manajemen

Untuk mempelajari cara memantau kemajuan dan status operasi manajemen, lihat Memantau operasi manajemen Azure SQL Managed Instance.

Batalkan operasi manajemen

Untuk mempelajari cara membatalkan operasi manajemen, lihat Membatalkan operasi manajemen Azure SQL Managed Instance.

Konten terkait

  • Last updated on