Bagikan melalui

Keandalan dalam Azure AI Search

  • Artikel

Di seluruh Azure, keandalan berarti ketahanan dan ketersediaan jika ada pemadaman atau degradasi layanan. Di Azure AI Search, keandalan dapat dicapai dalam satu layanan atau melalui beberapa layanan pencarian di wilayah terpisah.

  • Sebarkan satu layanan pencarian dan tingkatkan skala untuk ketersediaan tinggi. Anda dapat menambahkan beberapa replika untuk menangani beban kerja pengindeksan dan kueri yang lebih tinggi. Jika layanan pencarian Anda mendukung zona ketersediaan, replika secara otomatis disediakan di pusat data fisik yang berbeda untuk ketahanan ekstra.

  • Sebarkan beberapa layanan pencarian di berbagai wilayah geografis. Semua beban kerja pencarian sepenuhnya terkandung dalam satu layanan yang berjalan di satu wilayah geografis, tetapi dalam skenario multi-layanan, Anda memiliki opsi untuk menyinkronkan konten sehingga sama di semua layanan. Anda juga dapat menyiapkan solusi penyeimbangan beban untuk mendistribusikan ulang permintaan atau failover jika ada pemadaman layanan.

Untuk kelangsungan bisnis dan pemulihan dari bencana di tingkat regional, rencanakan topologi lintas regional, yang terdiri dari beberapa layanan pencarian yang memiliki konfigurasi dan konten yang identik. Skrip atau kode kustom Anda menyediakan mekanisme "failover" ke layanan pencarian alternatif jika tiba-tiba menjadi tidak tersedia.

Ketersediaan tinggi

Di Azure AI Search, replika adalah salinan indeks Anda. Layanan pencarian ditugaskan dengan setidaknya satu replika, dan dapat memiliki hingga 12 replika. Menambahkan replika memungkinkan Azure AI Search melakukan reboot dan pemeliharaan mesin terhadap satu replika, sementara eksekusi kueri berlanjut pada replika lain.

Untuk setiap layanan pencarian individu, Microsoft menjamin setidaknya 99,9% ketersediaan untuk konfigurasi yang memenuhi kriteria berikut:

  • Dua replika untuk ketersediaan tinggi beban kerja baca-saja (kueri)

  • Tiga replika atau lebih untuk ketersediaan tinggi beban kerja baca-tulis (kueri dan pengindeksan)

Sistem ini memiliki mekanisme internal untuk memantau kesehatan replika dan integritas partisi. Jika Anda menyediakan kombinasi replika dan partisi tertentu, sistem memastikan tingkat kapasitas tersebut untuk layanan Anda.

Tidak ada SLA yang disediakan untuk tingkat Gratis. Untuk informasi selengkapnya, lihat SLA untuk Pencarian Azure AI.

Dukungan zona ketersediaan

Zona ketersediaan adalah kemampuan platform Azure yang membagi pusat data wilayah menjadi grup lokasi fisik yang berbeda untuk menyediakan ketersediaan tinggi, dalam wilayah yang sama. Di Azure AI Search, replika individual adalah unit untuk penetapan zona. Layanan pencarian berjalan dalam satu wilayah; replikanya berjalan di pusat data fisik (atau zona) yang berbeda dalam wilayah tersebut.

Zona ketersediaan digunakan saat Anda menambahkan dua replika atau lebih ke layanan pencarian Anda. Setiap replika ditempatkan di zona ketersediaan yang berbeda dalam wilayah tersebut. Jika Anda memiliki lebih banyak replika daripada zona yang tersedia di wilayah layanan pencarian, replika didistribusikan di seluruh zona secara merata. Tidak ada tindakan khusus di bagian Anda, kecuali untuk membuat layanan pencarian di wilayah yang menyediakan zona ketersediaan, lalu untuk mengonfigurasi layanan untuk menggunakan beberapa replika.

Prasyarat

  • Tingkat layanan harus Standar atau lebih tinggi.
  • Wilayah layanan harus berada di wilayah yang memiliki zona yang tersedia (tercantum di bagian berikut).
  • Konfigurasi harus mencakup beberapa replika: dua untuk beban kerja kueri baca-saja, tiga untuk beban kerja baca-tulis yang mencakup pengindeksan.

Wilayah yang didukung

Dukungan untuk zona ketersediaan tergantung pada infrastruktur dan penyimpanan. Saat ini, dua zona yang diumumkan pada Oktober 2023 memiliki penyimpanan yang tidak mencukupi dan tidak menyediakan zona ketersediaan untuk Azure AI Search:

  • Israel Tengah
  • Italia Utara

Jika tidak, zona ketersediaan untuk Azure AI Search didukung di wilayah berikut:

Wilayah Peluncuran
Australia Timur 30 Januari 2021 atau yang lebih baru
Brasil Selatan 2 Mei 2021 atau yang lebih baru
Kanada Tengah 30 Januari 2021 atau yang lebih baru
India Tengah 20 Januari 2022 atau yang lebih baru
AS Tengah 4 Desember 2020 atau yang lebih baru
Tiongkok Utara 3 7 September 2022 atau yang lebih baru
Asia Timur 13 Januari 2022 atau yang lebih baru
AS Timur 27 Januari 2021 atau yang lebih baru
US Timur 2 30 Januari 2021 atau yang lebih baru
Prancis Tengah 23 Oktober 2020 atau yang lebih baru
Jerman Barat Tengah 3 Mei 2021, atau yang lebih baru
Jepang Timur 30 Januari 2021 atau yang lebih baru
Korea Tengah 20 Januari 2022 atau yang lebih baru
Eropa Utara 28 Januari 2021 atau yang lebih baru
Norwegia Timur 20 Januari 2022 atau yang lebih baru
Qatar Tengah 25 Agustus 2022 atau yang lebih baru
Afrika Selatan Utara 7 September 2022 atau yang lebih baru
US Tengah Selatan 30 April 2021 atau yang lebih baru
Asia Tenggara 31 Januari 2021 atau yang lebih baru
Swedia Tengah 21 Januari 2022 atau yang lebih baru
Swiss Utara 7 September 2022 atau yang lebih baru
Arab Saudi Utara 9 September 2022 atau yang lebih baru
UK Selatan 30 Januari 2021 atau yang lebih baru
US Gov Virginia 30 April 2021 atau yang lebih baru
Eropa Barat 29 Januari 2021 atau yang lebih baru
US Barat 2 30 Januari 2021 atau yang lebih baru
US Barat 3 02 Juni 2021 atau yang lebih baru

Catatan

Zona ketersediaan tidak mengubah ketentuan Perjanjian Tingkat Layanan Pencarian Azure AI. Anda masih memerlukan tiga replika atau lebih untuk mengkueri ketersediaan tinggi.

Beberapa layanan di wilayah geografis terpisah

Redundansi layanan diperlukan jika persyaratan operasional Anda meliputi:

  • Persyaratan kelangsungan bisnis dan pemulihan bencana (BCDR) (Azure AI Search tidak memberikan failover instan jika ada pemadaman).

  • Performa cepat untuk aplikasi yang didistribusikan secara global. Jika permintaan kueri dan pengindeksan berasal dari seluruh dunia, pengguna yang paling dekat dengan pusat data host mengalami performa yang lebih cepat. Membuat lebih banyak layanan di wilayah dengan kedekatan dengan pengguna ini dapat menyamakan performa untuk semua pengguna.

Jika Anda memerlukan dua atau beberapa layanan pencarian, membuatnya di wilayah yang berbeda dapat memenuhi persyaratan aplikasi untuk kelangsungan dan pemulihan, dan waktu respons yang lebih cepat untuk basis pengguna global.

Azure AI Search tidak menyediakan metode otomatis untuk mereplikasi indeks pencarian di seluruh wilayah geografis, tetapi ada beberapa teknik yang dapat membuat proses ini mudah diterapkan dan dikelola. Teknik ini diuraikan dalam beberapa bagian berikutnya.

Tujuan dari serangkaian layanan pencarian yang didistribusikan secara geografis adalah untuk memiliki dua atau lebih indeks yang tersedia di dua wilayah atau lebih, di mana pengguna dirutekan ke azure AI layanan Pencarian yang memberikan latensi terendah:

Cross-tab of services by region

Anda dapat menerapkan arsitektur ini dengan membuat beberapa layanan dan merancang strategi untuk sinkronisasi data. Secara opsional, Anda dapat menyertakan sumber daya seperti Azure Traffic Manager untuk permintaan perutean.

Tip

Untuk bantuan dalam menyebarkan beberapa layanan pencarian di beberapa wilayah, lihat sampel Bicep ini di GitHub yang menyebarkan solusi pencarian multi-regional yang dikonfigurasi sepenuhnya. Sampel memberi Anda dua opsi untuk sinkronisasi indeks, dan meminta pengalihan menggunakan Traffic Manager.

Menyinkronkan data di beberapa layanan

Ada dua opsi untuk menjaga dua atau beberapa layanan pencarian yang berbeda tetap sinkron:

Untuk mengonfigurasi salah satu opsi, sebaiknya gunakan sampel skrip Bicep di repositori azure-search-multiple-region , yang dimodifikasi ke wilayah Dan strategi pengindeksan Anda.

Opsi 1: Gunakan pengindeks untuk memperbarui konten di beberapa layanan

Jika Anda sudah menggunakan pengindeks pada satu layanan, Anda dapat mengonfigurasi pengindeks kedua pada layanan kedua untuk menggunakan objek sumber data yang sama, menarik data dari lokasi yang sama. Setiap layanan di setiap wilayah memiliki pengindeks dan indeks target sendiri (indeks pencarian Anda tidak dibagikan, yang berarti setiap indeks memiliki salinan datanya sendiri), tetapi setiap pengindeks mereferensikan sumber data yang sama.

Berikut adalah visual tingkat tinggi tentang seperti apa arsitektur itu.

Single data source with distributed indexer and service combinations

Opsi 2: Gunakan REST API untuk mendorong pembaruan konten di beberapa layanan

Jika Anda menggunakan Azure AI Search REST API untuk mendorong konten ke indeks pencarian, Anda dapat menjaga berbagai layanan pencarian tetap sinkron dengan mendorong perubahan ke semua layanan pencarian setiap kali pembaruan diperlukan. Di dalam kode Anda, pastikan untuk menangani kasus di mana pembaruan untuk satu layanan pencarian gagal tetapi berhasil untuk layanan pencarian lainnya.

Permintaan kueri failover atau pengalihan

Jika Anda memerlukan redundansi pada tingkat permintaan, Azure menyediakan beberapa opsi penyeimbangan beban:

  • Azure Traffic Manager, digunakan untuk merutekan permintaan ke beberapa situs web yang terletak secara geografis yang kemudian didukung oleh beberapa layanan pencarian.
  • Application Gateway, digunakan untuk memuat keseimbangan antar server di suatu wilayah di lapisan aplikasi.
  • Azure Front Door, digunakan untuk mengoptimalkan perutean global lalu lintas web dan menyediakan failover global.

Beberapa poin yang perlu diingat saat mengevaluasi opsi penyeimbangan beban:

  • Pencarian adalah layanan backend yang menerima permintaan kueri dan pengindeksan dari klien.

  • Permintaan dari klien ke layanan pencarian harus diautentikasi. Untuk akses ke operasi pencarian, pemanggil harus memiliki izin berbasis peran atau memberikan kunci API atas permintaan.

  • Titik akhir layanan dicapai melalui koneksi internet publik secara default. Jika Anda menyiapkan titik akhir privat untuk koneksi klien yang berasal dari dalam jaringan virtual, gunakan Application Gateway.

  • Azure AI Search menerima permintaan yang ditujukan ke <your-search-service-name>.search.windows.net titik akhir. Jika Anda mencapai titik akhir yang sama menggunakan nama DNS yang berbeda di header host, seperti CNAME, permintaan ditolak.

Azure AI Search menyediakan sampel penyebaran multi-wilayah yang menggunakan Azure Traffic Manager untuk pengalihan permintaan jika titik akhir utama gagal. Solusi ini berguna saat Anda merutekan ke klien yang diaktifkan pencarian yang hanya memanggil layanan pencarian di wilayah yang sama.

Azure Traffic Manager terutama digunakan untuk merutekan lalu lintas jaringan di berbagai titik akhir berdasarkan metode perutean tertentu (seperti prioritas, performa, atau lokasi geografis). Ini bertindak di tingkat DNS untuk mengarahkan permintaan masuk ke titik akhir yang sesuai. Jika titik akhir yang dilayari Traffic Manager mulai menolak permintaan, lalu lintas dirutekan ke titik akhir lain.

Traffic Manager tidak menyediakan titik akhir untuk koneksi langsung ke Azure AI Search, yang berarti Anda tidak dapat menempatkan layanan pencarian langsung di belakang Traffic Manager. Sebaliknya, asumsinya adalah bahwa permintaan mengalir ke Traffic Manager, lalu ke klien web yang diaktifkan pencarian, dan akhirnya ke layanan pencarian di backend. Klien dan layanan terletak di wilayah yang sama. Jika satu layanan pencarian tidak berfungsi, klien pencarian mulai gagal, dan Traffic Manager mengalihkan ke klien yang tersisa.

Search apps connecting through Azure Traffic Manager

Tentang residensi data dalam penyebaran multi-wilayah

Saat Anda menyebarkan beberapa layanan pencarian di berbagai wilayah geografis, konten Anda disimpan di wilayah yang Anda pilih untuk setiap layanan pencarian.

Pencarian Azure AI tidak akan menyimpan data di luar wilayah yang Anda tentukan tanpa otorisasi Anda. Otorisasi bersifat implisit saat Anda menggunakan fitur yang menulis ke sumber daya Azure Storage: cache pengayaan, sesi debug, penyimpanan pengetahuan. Dalam semua kasus, akun penyimpanan adalah akun yang Anda sediakan, di wilayah pilihan Anda.

Catatan

Jika akun penyimpanan dan layanan pencarian berada di wilayah yang sama, lalu lintas jaringan antara pencarian dan penyimpanan menggunakan alamat IP privat dan terjadi melalui jaringan backbone Microsoft. Karena alamat IP privat digunakan, Anda tidak dapat mengonfigurasi firewall IP atau titik akhir privat untuk keamanan jaringan. Sebagai gantinya , gunakan pengecualian layanan tepercaya sebagai alternatif ketika kedua layanan berada di wilayah yang sama.

Tentang pemadaman layanan dan peristiwa bencana

Seperti yang dinyatakan dalam Perjanjian Tingkat Layanan (SLA), Microsoft menjamin ketersediaan tingkat tinggi untuk permintaan kueri indeks saat instans Azure AI layanan Pencarian dikonfigurasi dengan dua replika atau lebih, dan permintaan pembaruan indeks saat instans Azure AI layanan Pencarian dikonfigurasi dengan tiga replika atau lebih. Namun, tidak ada mekanisme bawaan untuk pemulihan bencana. Jika layanan berkelanjutan diperlukan saat terjadi kegagalan luar biasa di luar kontrol Microsoft, kami merekomendasikan untuk menyediakan layanan kedua di wilayah yang berbeda dan menerapkan strategi replikasi geografis untuk memastikan indeks sepenuhnya redundan di semua layanan.

Pelanggan yang menggunakan pengindeks untuk mengisi dan menyegarkan indeks dapat menangani pemulihan bencana melalui pengindeks khusus geografis yang mengambil data dari sumber data yang sama. Dua layanan di berbagai wilayah, masing-masing menjalankan pengindeks, dapat mengindeks sumber data yang sama untuk mencapai redundansi geografis. Jika Anda mengindeks dari sumber data yang juga geo-redundan, ingatlah bahwa pengindeks Azure AI Search hanya dapat melakukan pengindeksan inkremental (menggabungkan pembaruan dari dokumen baru, dimodifikasi, atau dihapus) dari replika utama. Dalam peristiwa failover, pastikan untuk mengalihkan pengindeks ke replika utama baru.

Jika Anda tidak menggunakan pengindeks, Anda akan menggunakan kode aplikasi untuk mendorong objek dan data ke layanan pencarian yang berbeda secara paralel. Untuk informasi selengkapnya, lihat Menjaga data tetap disinkronkan di beberapa layanan.

Mencadangkan dan memulihkan alternatif

Strategi kelangsungan bisnis untuk lapisan data biasanya mencakup langkah pemulihan dari cadangan. Karena Azure AI Search bukan solusi penyimpanan data utama, Microsoft tidak menyediakan mekanisme formal untuk pencadangan dan pemulihan layanan mandiri. Namun, Anda dapat menggunakan kode sampel index-backup-restore dalam repositori sampel Azure AI Search .NET ini untuk mencadangkan definisi indeks dan rekam jepret Anda ke serangkaian file JSON, lalu menggunakan file-file ini untuk memulihkan indeks, jika diperlukan. Alat ini juga dapat memindah indeks antar tingkat layanan.

Jika tidak, kode aplikasi Anda yang digunakan untuk membuat dan mengisi indeks adalah opsi pemulihan de facto jika Anda menghapus indeks secara tidak sengaja. Untuk membangun ulang indeks, Anda akan menghapusnya (dengan asumsi ada), membuat ulang indeks dalam layanan, dan memuat ulang dengan mengambil data dari penyimpanan data utama Anda.

Langkah berikutnya