Keandalan dalam Azure AI Search
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 fail over ke layanan pencarian alternatif jika tiba-tiba menjadi tidak tersedia.
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 beban kerja baca-saja yang tinggi (kueri)
Tiga replika atau lebih untuk ketersediaan beban kerja baca-tulis yang tinggi (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 Perjanjian Tingkat Layanan (SLA) yang disediakan untuk tingkat Gratis . Untuk informasi selengkapnya, lihat SLA untuk Azure AI Search.
Zona ketersediaan adalah kemampuan platform Azure yang membagi pusat data wilayah menjadi grup lokasi fisik yang berbeda untuk memberikan 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.
- 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
Dukungan untuk zona ketersediaan tergantung pada infrastruktur dan penyimpanan. Saat ini, zona berikut memiliki penyimpanan yang tidak mencukupi dan tidak menyediakan zona ketersediaan untuk Azure AI Search:
- Jepang Barat
Jika tidak, zona ketersediaan untuk Azure AI Search didukung di wilayah berikut:
Wilayah | Tanggal 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 |
Israel Tengah | 1 April 2024, atau yang lebih baru |
Italia Utara | 1 April 2024, 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 SLA. Anda masih memerlukan tiga replika atau lebih untuk mengkueri ketersediaan tinggi.
Redundansi layanan diperlukan jika persyaratan operasional Anda meliputi:
Persyaratan kelangsungan bisnis dan pemulihan bencana (BCDR). Azure AI Search tidak menyediakan 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:
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.
Ada dua opsi untuk menjaga dua atau beberapa layanan pencarian yang berbeda tetap sinkron:
- Tarik pembaruan konten ke dalam indeks pencarian dengan menggunakan pengindeks.
- Dorong konten ke dalam indeks menggunakan API Tambahkan atau Perbarui Dokumen (REST) atau API setara Azure SDK.
Untuk mengonfigurasi salah satu opsi, sebaiknya gunakan sampel skrip Bicep di repositori azure-search-multiple-region , yang dimodifikasi ke wilayah Dan strategi pengindeksan Anda.
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.
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.
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.
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 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.
Seperti yang dinyatakan dalam SLA, Microsoft menjamin tingkat ketersediaan 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 Menyinkronkan data di beberapa layanan.
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.
- Tinjau Batas layanan untuk mempelajari selengkapnya tentang tingkat harga dan batas layanan.
- Tinjau Rencana kapasitas untuk mempelajari selengkapnya tentang kombinasi partisi dan replika.
- Tinjau Studi Kasus: Gunakan Cognitive Search untuk Mendukung Skenario AI Kompleks untuk panduan konfigurasi lebih lanjut.