Ketersediaan dan kontinuitas bisnis di Azure Cognitive Search

Dalam Cognitive Search, ketersediaan dicapai melalui beberapa replika, sedangkan kontinuitas bisnis (dan pemulihan dari bencana) dicapai melalui beberapa layanan pencarian. Artikel ini menyediakan panduan yang dapat Anda gunakan sebagai titik awal untuk mengembangkan strategi yang memenuhi persyaratan bisnis Anda untuk ketersediaan dan operasi berkelanjutan.

Ketersediaan tinggi

Dalam Cognitive Search, replika adalah salinan indeks Anda. Memiliki beberapa replika memungkinkan Azure Cognitive Search melakukan reboot komputer dan pemeliharaan terhadap satu replika, sementara eksekusi kueri berlanjut pada replika lain. Untuk informasi selengkapnya tentang menambahkan replika, lihat Menambah atau mengurangi replika dan partisi.

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 beban kerja baca-tulis yang tinggi (kueri dan pengindeksan)

Tidak ada SLA yang disediakan untuk tingkat Gratis. Untuk informasi selengkapnya, lihat SLA untuk Azure Cognitive Search.

Residensi Data

Azure Cognitive Search tidak akan menyimpan data pelanggan di luar wilayah yang ditentukan pelanggan tanpa otorisasi Anda.

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. Jika Anda menggunakan Zona Ketersediaan untuk Cognitive Search, replika individual adalah unit untuk penetapan zona. Layanan pencarian berjalan dalam satu wilayah; replikanya berjalan di zona yang berbeda.

Anda dapat menggunakan Zona Ketersediaan dengan Azure Cognitive Search dengan menambah dua replika atau lebih ke layanan pencarian Anda. Setiap replika akan ditempatkan di Zona Ketersediaan yang berbeda di wilayah tersebut. Jika Anda memiliki lebih banyak replika daripada Zona Ketersediaan, replika akan didistribusikan di seluruh Zona Ketersediaan secara merata. Tidak ada tindakan khusus di pihak Anda, kecuali untuk membuat layanan pencarian di wilayah yang menyediakan Zona Ketersediaan, lalu mengonfigurasi layanan untuk menggunakan beberapa replika.

Azure Cognitive Search saat ini mendukung Zona Ketersediaan untuk layanan pencarian tingkat standar atau yang lebih tinggi yang dibuat di salah satu wilayah berikut:

  • Australia Timur (dibuat 30 Januari 2021 atau lebih baru)
  • Brasil Selatan (dibuat 2 Mei 2021 atau yang lebih baru)
  • Kanada Tengah (dibuat 30 Januari 2021 atau yang lebih baru)
  • AS Tengah (dibuat 4 Desember 2020 atau yang lebih baru)
  • AS Timur (dibuat 27 Januari 2021 atau yang lebih baru)
  • AS Timur 2 (dibuat 30 Januari 2021 atau yang lebih baru)
  • Prancis Tengah (dibuat 23 Oktober 2020 atau yang lebih baru)
  • Jerman Barat Tengah (dibuat 3 Mei 2021, atau yang lebih baru)
  • Jepang Timur (dibuat 30 Januari 2021 atau lebih baru)
  • Eropa Utara (dibuat 28 Januari 2021 atau lebih baru)
  • AS Tengah Selatan (dibuat 30 April 2021 atau yang lebih baru)
  • Asia Tenggara (dibuat 31 Januari 2021 atau lebih baru)
  • Inggris Raya Selatan (dibuat 30 Januari 2021 atau yang lebih baru)
  • US Gov Virginia (dibuat 30 April 2021 atau yang lebih baru)
  • Eropa Barat (dibuat 29 Januari 2021 atau lebih baru)
  • AS Barat 2 (dibuat 30 Januari 2021 atau yang lebih baru)

Zona Ketersediaan tidak memengaruhi Perjanjian Tingkat Layanan Azure Cognitive Search. Anda masih memerlukan 3 replika atau lebih untuk ketersediaan tinggi kueri.

Beberapa layanan di wilayah geografis terpisah

Meskipun sebagian besar pelanggan hanya menggunakan satu layanan, redundansi layanan mungkin diperlukan jika persyaratan operasional meliputi hal berikut:

  • Kontinuitas bisnis dan pemulihan dari bencana (BCDR) (Cognitive Search tidak memberi failover instan jika terjadi pemadaman).
  • Aplikasi yang disebar secara global. Jika permintaan kueri dan pengindeksan berasal dari seluruh dunia, pengguna yang paling dekat dengan pusat data host akan memiliki kinerja yang lebih cepat. Membuat layanan tambahan di wilayah yang dekat dengan pengguna ini dapat menyeimbangkan kinerja untuk semua pengguna.
  • Arsitektur multi-penyewa terkadang memanggil dua layanan atau lebih.

Jika Anda membutuhkan dua layanan pencarian lagi, membuatnya di berbagai wilayah dapat memenuhi persyaratan aplikasi untuk kontinuitas dan pemulihan, serta waktu respons yang lebih cepat untuk basis pengguna global.

Azure Cognitive Search saat ini tidak menyediakan metode otomatis indeks pencarian geo-replikasi di seluruh wilayah, tetapi ada beberapa teknik yang dapat digunakan yang dapat membuat proses ini mudah diterapkan dan dikelola. Ini diuraikan pada beberapa bagian berikutnya.

Tujuan dari serangkaian layanan pencarian yang didistribusikan secara geografis adalah memiliki dua atau lebih indeks yang tersedia di dua wilayah atau lebih, tempat pengguna dialihkan ke layanan Azure Cognitive Search yang memberi latensi terendah:

Tab silang layanan menurut wilayah

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. Untuk informasi selengkapnya, lihat Membuat grup sinkronisasi.

Menjaga data tetap disinkronkan di banyak layanan

Ada dua opsi untuk menjaga dua atau lebih layanan pencarian terdistribusi tetap sinkron, yang terdiri dari menggunakan Azure Cognitive Search Indexer atau Push API (juga disebut sebagai Azure Cognitive Search REST API).

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 sendiri dan indeks target (indeks pencarian Anda tidak dibagikan, yang berarti data diduplikasi), tetapi setiap pengindeks mereferensikan sumber data yang sama.

Berikut adalah visual tingkat tinggi dari seperti apa arsitektur itu.

Sumber data tunggal dengan kombinasi pengindeks dan layanan terdistribusi

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

Jika Anda menggunakan Azure Cognitive Search REST API untuk mendorong konten ke indeks pencarian Anda, Anda dapat menjaga berbagai layanan pencarian Anda 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.

Menggunakan Azure Traffic Manager untuk mengoordinasikan permintaan

Azure Traffic Manager memungkinkan Anda merutekan permintaan ke beberapa situs web berlokasi geografis yang kemudian didukung oleh beberapa layanan pencarian. Salah satu keuntungan dari Traffic Manager adalah dapat menyelidiki Azure Cognitive Search untuk memastikan bahwa itu tersedia dan merutekan pengguna untuk layanan pencarian alternatif jika terjadi downtime. Selain itu, jika Anda merutekan permintaan pencarian melalui Azure Web Sites, Azure Traffic Manager memungkinkan Anda untuk memuat kasus keseimbangan tempat Situs Web aktif tetapi bukan Azure Cognitive Search. Berikut adalah contoh arsitektur mana yang memanfaatkan Traffic Manager.

Layanan lintas tab menurut wilayah, dengan Central Traffic Manager

Pemulihan dari bencana dan pemadaman layanan

Sebagaimana dinyatakan dalam Perjanjian Tingkat Layanan (SLA), kami menjamin tingkat ketersediaan yang tinggi untuk permintaan kueri indeks ketika instans layanan Azure Cognitive Search dikonfigurasi dengan dua atau lebih replika, dan permintaan pembaruan indeks ketika instans layanan Azure Cognitive Search dikonfigurasi dengan tiga atau lebih replika. 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 geo-spesifik yang memanfaatkan 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 redundan secara geografis, ketahuilah bahwa pengindeks Azure Cognitive Search hanya dapat melakukan pengindeksan inkremental (menggabungkan pembaruan dari dokumen baru, dimodifikasi, atau dihapus) dari replika utama. Dalam peristiwa failover, pastikan untuk mengarahkan kembali 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

Karena Azure Cognitive 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 repo sampel Azure Cognitive Search .NET ini untuk mencadangkan definisi indeks dan snapshot 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

Untuk mempelajari selengkapnya tentang tingkat harga dan batas layanan untuk masing-masing tingkatan, lihat Batas layanan. Tinjau Rencana untuk kapasitas untuk mempelajari lebih lanjut tentang kombinasi partisi dan replika, atau lihat Studi Kasus: Menggunakan Cognitive Search untuk Mendukung Skenario AI yang Kompleks untuk tips dunia nyata.