Pemodelan kesehatan untuk beban kerja misi penting
Pemantauan aplikasi dan infrastruktur adalah bagian penting dari penyebaran infrastruktur apa pun. Untuk beban kerja misi penting, pemantauan adalah bagian penting dari penyebaran. Memantau kesehatan aplikasi dan metrik utama sumber daya Azure membantu Anda memahami apakah lingkungan berfungsi seperti yang diharapkan.
Untuk sepenuhnya memahami metrik ini dan mengevaluasi kesehatan keseluruhan beban kerja, memerlukan pemahaman holistik tentang semua data yang dipantau. Model kesehatan dapat membantu evaluasi status kesehatan keseluruhan dengan menampilkan indikasi yang jelas tentang kesehatan beban kerja alih-alih metrik mentah. Status ini sering disajikan sebagai indikator "lampu lalu lintas" seperti merah, hijau, atau kuning. Representasi model kesehatan dengan indikator yang jelas membuatnya intuitif bagi operator untuk memahami kesehatan keseluruhan beban kerja dan merespons masalah yang muncul dengan cepat.
Pemodelan kesehatan dapat diperluas ke dalam tugas operasional berikut untuk penyebaran misi penting:
Application Health Service - Komponen aplikasi pada kluster komputasi yang menyediakan API untuk menentukan kesehatan stempel.
Pemantauan - Pengumpulan kinerja dan penghitung aplikasi yang mengevaluasi kesehatan dan performa aplikasi dan infrastruktur.
Pemberitahuan - Pemberitahuan masalah atau pemadaman yang dapat ditindakkan di infrastruktur dan aplikasi.
Analisis kegagalan - Perincian dan analisis kegagalan apa pun termasuk dokumentasi akar penyebab.
Tugas-tugas ini membentuk model kesehatan yang komprehensif untuk infrastruktur misi penting. Pengembangan model kesehatan dapat dan harus menjadi bagian lengkap dan integral dari setiap penyebaran misi penting.
Untuk informasi selengkapnya, lihat Pemodelan kesehatan dan pengamatan beban kerja misi penting di Azure.
Layanan Kesehatan Aplikasi
Application Health Service (HealthService) adalah komponen aplikasi yang berada di Layanan Katalog (CatalogService) dan Prosesor Latar Belakang (BackgroundProcessor) dalam kluster komputasi. HealthService menyediakan REST API untuk panggilan Azure Front Door guna menentukan kesehatan stempel. HealthService adalah komponen kompleks yang mencerminkan status dependensi, selain miliknya sendiri.
Ketika kluster komputasi tidak berfungsi, layanan kesehatan tidak akan merespons. Ketika layanan aktif dan berjalan, layanan melakukan pemeriksaan berkala terhadap komponen berikut dalam infrastruktur:
Ini mencoba melakukan kueri terhadap Azure Cosmos DB.
Ini mencoba mengirim pesan ke Azure Event Hubs. Pesan difilter oleh pekerja latar belakang.
Ini mencari file status di akun penyimpanan. File ini dapat digunakan untuk mematikan wilayah, bahkan saat pemeriksaan lainnya masih beroperasi dengan benar. File ini dapat digunakan untuk berkomunikasi dengan proses lain. Misalnya, jika stempel akan dikosokkan untuk tujuan pemeliharaan, file dapat dihapus untuk memaksa status yang tidak sehat dan mengalihkan lalu lintas.
Ini meminta model kesehatan untuk menentukan apakah semua metrik operasional berada dalam ambang yang telah ditentukan. Ketika model kesehatan menunjukkan stempel tidak sehat, lalu lintas tidak boleh dirutekan ke stempel meskipun pengujian lain yang dilakukan HealthService berhasil dikembalikan. Model Kesehatan memperhitungkan tampilan status kesehatan yang lebih lengkap.
Semua hasil pemeriksaan kesehatan di-cache dalam memori untuk jumlah detik yang dapat dikonfigurasi, secara default 10. Operasi ini berpotensi menambahkan latensi kecil dalam mendeteksi pemadaman, tetapi memastikan tidak setiap kueri HealthService memerlukan panggilan backend, sehingga mengurangi beban pada kluster dan layanan hilir.
Pola penembolokan ini penting, karena jumlah kueri HealthService tumbuh secara signifikan saat menggunakan router global seperti Azure Front Door: Setiap simpul tepi di setiap pusat data Azure yang melayani permintaan akan memanggil Layanan Kesehatan untuk menentukan apakah memiliki koneksi backend fungsional. Penembolokan hasil mengurangi beban kluster tambahan yang dihasilkan oleh pemeriksaan kesehatan.
Konfigurasi
HealthService dan CatalogService memiliki pengaturan konfigurasi yang umum antara komponen kecuali untuk pengaturan berikut yang digunakan secara eksklusif oleh HealthService:
| Pengaturan | Nilai |
|---|---|
HealthServiceCacheDurationSeconds |
Mengontrol waktu kedaluwarsa cache memori, dalam hitungan detik. |
HealthServiceStorageConnectionString |
String koneksi untuk Akun Penyimpanan tempat file status harus ada. |
HealthServiceBlobContainerName |
Kontainer Penyimpanan tempat file status harus ada. |
HealthServiceBlobName |
Nama file status - pemeriksaan kesehatan akan mencari file ini. |
HealthServiceOverallTimeoutSeconds |
Batas waktu untuk seluruh pemeriksaan - default menjadi 3 detik. Jika pemeriksaan tidak selesai dalam interval ini, layanan melaporkan tidak sehat. |
implementasi
Semua pemeriksaan dilakukan secara asinkron dan paralel. Jika salah satu dari mereka gagal, seluruh stempel akan dianggap tidak tersedia.
Hasil pemeriksaan di-cache dalam memori, menggunakan ASP.NET Core MemoryCachestandar yang tidak terdistribusi. Kedaluwarsa cache dikontrol oleh SysConfig.HealthServiceCacheDurationSeconds dan diatur ke 10 detik secara default.
Catatan
SysConfig.HealthServiceCacheDurationSeconds Pengaturan konfigurasi mengurangi beban tambahan yang dihasilkan oleh pemeriksaan kesehatan karena tidak setiap permintaan akan mengakibatkan panggilan hilir ke layanan dependen.
Tabel berikut merinci pemeriksaan kesehatan untuk komponen dalam infrastruktur:
| Komponen | Pemeriksaan kondisi |
|---|---|
| Blob akun penyimpanan | Pemeriksaan blob saat ini melayani dua tujuan: 1. Uji apakah mungkin untuk mencapai Blob Storage. Akun penyimpanan digunakan oleh komponen lain dalam stempel dan dianggap sebagai sumber daya penting. 2. "Matikan" wilayah secara manual dengan menghapus file status. Keputusan desain dibuat bahwa pemeriksaan hanya akan mencari keberadaan file status dalam kontainer blob yang ditentukan. Konten file tidak diproses. Ada kemungkinan untuk menyiapkan sistem yang lebih canggih yang membaca konten file dan mengembalikan status yang berbeda berdasarkan konten file. Contoh kontennya adalah SEHAT, TIDAK SEHAT, dan PEMELIHARAAN. Penghapusan file status akan menonaktifkan stempel. Pastikan file kesehatan ada setelah menyebarkan aplikasi. Tidak adanya file kesehatan akan menyebabkan layanan selalu merespons dengan TIDAK SEHAT. Front Door tidak akan mengenali backend sebagai tersedia. File dibuat oleh Terraform dan harus ada setelah penyebaran infrastruktur. |
| Pusat Aktivitas | Pelaporan kesehatan Azure Event Hubs ditangani oleh EventHubProducerService. Layanan ini melaporkan sehat jika dapat mengirim pesan baru ke Azure Event Hubs. Untuk pemfilteran, pesan ini memiliki properti identifikasi yang ditambahkan ke dalamnya: HEALTHCHECK=TRUEPesan ini diabaikan pada akhir penerimaan. Pengaturan AlwaysOn.BackgroundProcessor.EventHubProcessorService.ProcessEventHandlerAsync() konfigurasi memeriksa HEALTHCHECK properti . |
| Azure Cosmos DB | Pelaporan kesehatan Azure Cosmos DB ditangani oleh CosmosDbService, yang melaporkan sehat jika: 1. Dapat menyambungkan ke database Azure Cosmos DB dan melakukan kueri. 2. Dapat menulis dokumen pengujian ke database. Dokumen pengujian memiliki set Time-to-Live yang singkat, Azure Cosmos DB secara otomatis menghapusnya. HealthService melakukan dua pemeriksaan terpisah. Jika Azure Cosmos DB berada dalam status di mana baca berfungsi dan tulis tidak, kedua pemeriksaan memastikan pemberitahuan dipicu. |
Kueri Azure Cosmos DB
Untuk kueri Baca-saja, kueri berikut sedang digunakan, yang tidak mengambil data apa pun dan tidak memiliki efek besar pada beban keseluruhan:
SELECT GetCurrentDateTime ()
Kueri tulis membuat dummy ItemRating dengan konten minimum:
var testRating = new ItemRating()
{
Id = Guid.NewGuid(),
CatalogItemId = Guid.NewGuid(), // Create some random (=non-existing) item id
CreationDate = DateTime.UtcNow,
Rating = 1,
TimeToLive = 10 // will be auto-deleted after 10sec
};
await AddNewRatingAsync(testRating);
Pemantauan
Azure Log Analytics digunakan sebagai penyimpanan pusat untuk log dan metrik untuk semua komponen aplikasi dan infrastruktur. Azure Application Insights digunakan untuk semua data pemantauan aplikasi. Setiap stempel dalam infrastruktur memiliki ruang kerja Analitik Log khusus dan instans Application Insights. Ruang kerja Analitik Log terpisah digunakan untuk sumber daya yang dibagikan secara global seperti Front Door dan Azure Cosmos DB.
Semua stempel berumur pendek dan terus diganti dengan setiap rilis baru. Ruang kerja Log Analytics per stempel disebarkan sebagai sumber daya global dalam grup sumber daya pemantauan terpisah sebagai sumber daya Log Analytics stempel. Sumber daya ini tidak berbagi siklus hidup stempel.
Untuk informasi selengkapnya, lihat Sink data terpadu untuk analisis berkorelasi.
Pemantauan: Sumber data
Pengaturan diagnostik: Semua layanan Azure yang digunakan untuk Azure Mission-Critical dikonfigurasi untuk mengirim semua data Diagnostik mereka termasuk log dan metrik ke Ruang Kerja Analitik Log khusus penyebaran (global atau stempel). Proses ini terjadi secara otomatis sebagai bagian dari penyebaran Terraform. Opsi baru akan diidentifikasi secara otomatis dan ditambahkan sebagai bagian
terraform applydari .Pemantauan Kubernetes: Pengaturan diagnostik digunakan untuk mengirim log dan metrik Azure Kubernetes Service (AKS) ke Analitik Log. AKS dikonfigurasi untuk menggunakan Container Insights. Container Insights menyebarkan OMSAgentForLinus melalui Kubernetes DaemonSet pada setiap node di kluster AKS. OMSAgentForLinux mampu mengumpulkan log dan metrik tambahan dari dalam kluster Kubernetes dan mengirimkannya ke ruang kerja Log Analytics yang sesuai. Log dan metrik tambahan ini berisi data yang lebih terperinci tentang pod, penyebaran, layanan, dan kesehatan kluster secara keseluruhan. Untuk mendapatkan lebih banyak wawasan dari berbagai komponen seperti ingress-nginx, cert-manager, dan komponen lain yang disebarkan ke Kubernetes di samping beban kerja yang sangat penting, Anda dapat menggunakan scraping Prometheus. Pengikisan Prometheus mengonfigurasi OMSAgentForLinux untuk mengikis metrik Prometheus dari berbagai titik akhir dalam kluster.
Telemetri Application Insights: Application Insights digunakan untuk mengumpulkan data telemetri dari aplikasi. Kode telah diinstrumentasikan untuk mengumpulkan data tentang performa aplikasi dengan Application Insights SDK. Informasi penting, seperti kode status yang dihasilkan dan durasi panggilan dan penghitung dependensi untuk pengecualian yang tidak tertangani dikumpulkan. Informasi ini digunakan dalam Model Kesehatan dan tersedia untuk pemberitahuan dan pemecahan masalah.
Pemantauan: Pengujian ketersediaan Application Insights
Untuk memantau ketersediaan stempel individu dan solusi keseluruhan dari sudut pandang luar, Pengujian Ketersediaan Application Insights disiapkan di dua tempat:
Pengujian ketersediaan regional: Pengujian ini disiapkan di instans Application Insights regional dan digunakan untuk memantau ketersediaan stempel. Pengujian ini menargetkan kluster dan akun penyimpanan statis stempel secara langsung. Untuk memanggil titik masuk kluster secara langsung, permintaan perlu membawa header ID Front Door yang benar, jika tidak, mereka ditolak oleh pengontrol ingress.
Uji ketersediaan global: Pengujian ini disiapkan dalam instans Application Insights global dan digunakan untuk memantau ketersediaan solusi keseluruhan dengan ping Front Door. Dua pengujian digunakan: Satu untuk menguji panggilan API terhadap CatalogService dan satu untuk menguji halaman beranda situs web.
Pemantauan: Kueri
Azure Mission-Critical menggunakan kueri Bahasa Kueri Kusto (KQL) yang berbeda untuk menerapkan kueri kustom sebagai fungsi untuk mengambil data dari Analitik Log. Kueri ini disimpan sebagai file individual di repositori kode kami, dipisahkan untuk penyebaran global dan stempel. Mereka diimpor dan diterapkan secara otomatis melalui Terraform sebagai bagian dari setiap eksekusi alur infrastruktur.
Pendekatan ini memisahkan logika kueri dari lapisan visualisasi. Kueri Analitik Log dipanggil langsung dari kode, misalnya dari HEALTHService API. Contoh lain adalah dari alat visualisasi seperti Dasbor Azure, Buku Kerja Monitor, atau Grafana.
Pemantauan: Visualisasi
Untuk memvisualisasikan hasil kueri kesehatan Analitik Log kami, kami telah menggunakan Grafana dalam implementasi referensi kami. Grafana digunakan untuk menampilkan hasil kueri Analitik Log dan tidak berisi logika itu sendiri. Tumpukan Grafana bukan bagian dari siklus hidup penyebaran solusi, tetapi dirilis secara terpisah.
Untuk informasi selengkapnya, lihat Visualisasi.
Memperingatkan
Pemberitahuan adalah bagian penting dari strategi operasi keseluruhan. Pemantauan proaktif seperti penggunaan dasbor harus digunakan dengan pemberitahuan yang meningkatkan perhatian langsung pada masalah.
Pemberitahuan ini membentuk ekstensi model kesehatan, dengan memperingatkan operator terhadap perubahan status kesehatan, baik ke status terdegradasi/kuning atau ke status tidak sehat/merah. Dengan mengatur pemberitahuan ke node akar Model Kesehatan, operator segera mengetahui pengaruh tingkat bisnis apa pun terhadap status solusi: Setelah semua, simpul akar ini akan berubah menjadi kuning atau merah jika salah satu alur pengguna atau sumber daya yang mendasar melaporkan metrik kuning atau merah. Operator dapat mengarahkan perhatian mereka ke visualisasi Model Kesehatan untuk pemecahan masalah.
Untuk informasi selengkapnya, lihat Respons insiden otomatis.
Analisis kegagalan
Menyusun analisis kegagalan sebagian besar adalah latihan perencanaan teoritis. Latihan teoritis ini harus digunakan sebagai input untuk injeksi kegagalan otomatis yang merupakan bagian dari proses validasi berkelanjutan. Dengan mensimulasikan mode kegagalan yang ditentukan di sini, kami dapat memvalidasi ketahanan solusi terhadap kegagalan ini untuk memastikan mereka tidak akan menyebabkan pemadaman.
Tabel berikut mencantumkan contoh kasus kegagalan dari berbagai komponen implementasi referensi Azure Mission-Critical.
| Layanan | Risiko | Dampak/Mitigasi/Komentar | Penghentian |
|---|---|---|---|
| Microsoft Entra ID | ID Microsoft Entra menjadi tidak tersedia. | Saat ini tidak ada kemungkinan mitigasi di tempat. Pendekatan multi-wilayah tidak akan mengurangi pemadaman apa pun karena ini adalah layanan global. Layanan ini adalah dependensi yang keras. MICROSOFT Entra ID digunakan untuk operasi sarana kontrol seperti pembuatan simpul AKS baru, menarik gambar kontainer dari ACR atau untuk mengakses Key Vault pada startup pod. Diharapkan komponen yang sudah ada dan berjalan harus dapat terus berjalan saat ID Microsoft Entra mengalami masalah. Kemungkinan pod atau node AKS baru tidak akan dapat bertelur. Dalam operasi skala diperlukan selama waktu ini, hal ini dapat menyebabkan penurunan pengalaman pengguna dan berpotensi terhadap pemadaman. | Sebagian |
| DNS Azure | Azure DNS menjadi tidak tersedia dan resolusi DNS gagal. | Jika Azure DNS menjadi tidak tersedia, resolusi DNS untuk permintaan pengguna dan di antara komponen aplikasi yang berbeda kemungkinan akan gagal. Saat ini tidak ada kemungkinan mitigasi yang berlaku untuk skenario ini. Pendekatan multi-wilayah tidak akan mengurangi pemadaman apa pun karena ini adalah layanan global. Azure DNS adalah dependensi keras. Layanan DNS eksternal sebagai cadangan tidak akan membantu, karena semua komponen PaaS yang digunakan mengandalkan Azure DNS. Melewati DNS dengan beralih ke IP bukanlah opsi. Layanan Azure tidak memiliki alamat IP statis dan terjamin. | Penuh |
| Front Door | Pemadaman Front Door Umum. | Jika Front Door turun sepenuhnya, tidak ada mitigasi. Layanan ini adalah dependensi yang keras. | Ya |
| Front Door | Kesalahan konfigurasi perutean/frontend/backend. | Dapat terjadi karena ketidakcocokan dalam konfigurasi saat menyebarkan. Harus ditangkap dalam tahap pengujian. Konfigurasi frontend dengan DNS khusus untuk setiap lingkungan. Mitigasi: Mengembalikan ke konfigurasi sebelumnya harus memperbaiki sebagian besar masalah. Karena perubahan membutuhkan waktu beberapa menit di Front Door untuk disebarkan, perubahan akan menyebabkan pemadaman. | Penuh |
| Front Door | Sertifikat TLS/SSL terkelola dihapus. | Dapat terjadi karena ketidakcocokan dalam konfigurasi saat menyebarkan. Harus ditangkap dalam tahap pengujian. Secara teknis situs masih akan berfungsi, tetapi kesalahan sertifikasi TLS/SSL akan mencegah pengguna mengaksesnya. Mitigasi: Menerbitkan ulang sertifikasi dapat memakan waktu sekitar 20 menit, ditambah memperbaiki dan menjalankan kembali alur.. | Penuh |
| Azure Cosmos DB | Database/koleksi diganti namanya. | Dapat terjadi karena ketidakcocokan dalam konfigurasi saat menyebarkan - Terraform akan menimpa seluruh database, yang dapat mengakibatkan kehilangan data. Kehilangan data dapat dicegah dengan menggunakan kunci tingkat database/koleksi. Aplikasi tidak akan dapat mengakses data apa pun. Konfigurasi aplikasi perlu diperbarui dan pod dimulai ulang. | Ya |
| Azure Cosmos DB | Pemadaman regional | Azure Mission-Critical mengaktifkan penulisan multi-wilayah. Jika ada kegagalan pada baca atau tulis, klien mencoba kembali operasi saat ini. Semua operasi di masa mendatang dirutekan secara permanen ke wilayah berikutnya dalam urutan preferensi. Jika daftar preferensi memiliki satu entri (atau kosong) tetapi akun memiliki wilayah lain yang tersedia, itu akan merutekan ke wilayah berikutnya dalam daftar akun. | No |
| Azure Cosmos DB | Pembatasan yang luas karena kurangnya RU. | Tergantung pada jumlah RU dan penyeimbangan beban yang digunakan di tingkat Front Door, stempel tertentu dapat berjalan panas pada pemanfaatan Azure Cosmos DB sementara stempel lain dapat melayani lebih banyak permintaan. Mitigasi: Distribusi beban yang lebih baik atau lebih banyak RU. | No |
| Azure Cosmos DB | Partisi penuh | Batas ukuran partisi logis Azure Cosmos DB adalah 20 GB. Jika data untuk kunci partisi dalam kontainer mencapai ukuran ini, permintaan tulis tambahan akan gagal dengan kesalahan "Kunci partisi mencapai ukuran maksimum". | Parsial (penulisan DB dinonaktifkan) |
| Azure Container Registry | Pemadaman regional | Registri kontainer menggunakan Traffic Manager untuk melakukan failover antar wilayah replika. Permintaan apa pun harus secara otomatis dialihkan ke wilayah lain. Paling buruk, gambar Docker tidak dapat ditarik selama beberapa menit oleh simpul AKS saat failover DNS terjadi. | No |
| Azure Container Registry | Gambar dihapus | Tidak ada gambar yang dapat ditarik. Pemadaman ini seharusnya hanya memengaruhi simpul yang baru diluncurkan/di-boot ulang. Simpul yang ada harus memiliki gambar yang di-cache. **Mitigasi: Jika terdeteksi dengan cepat menjalankan ulang alur build terbaru harus membawa gambar kembali ke registri. | No |
| Azure Container Registry | Pembatasan | Pembatasan dapat menunda operasi peluasan skala yang dapat mengakibatkan penurunan performa sementara. Mitigasi: Azure Mission-Critical menggunakan SKU Premium yang menyediakan 10k operasi baca per menit. Gambar kontainer dioptimalkan dan hanya memiliki sejumlah kecil lapisan. ImagePullPolicy diatur ke IfNotPresent untuk menggunakan versi yang di-cache secara lokal terlebih dahulu. Komentar: Menarik gambar kontainer terdiri dari beberapa operasi baca, tergantung pada jumlah lapisan. Jumlah operasi baca per menit terbatas dan tergantung pada ukuran SKU ACR. | No |
| Azure Kubernetes Service | Peningkatan kluster gagal | Peningkatan Simpul AKS harus terjadi pada waktu yang berbeda di seluruh stempel. jika satu peningkatan gagal, kluster lain tidak boleh terpengaruh. Peningkatan kluster harus disebarkan secara bergulir di seluruh simpul untuk mencegah semua node menjadi tidak tersedia. | No |
| Azure Kubernetes Service | Pod aplikasi dimatikan saat melayani permintaan. | Ini dapat mengakibatkan pengguna akhir menghadapi kesalahan dan pengalaman pengguna yang buruk. Mitigasi: Kubernetes secara default menghapus pod dengan cara yang anggun. Pod dihapus dari layanan terlebih dahulu dan beban kerja menerima SIGTERM dengan masa tenggang untuk menyelesaikan permintaan terbuka dan menulis data sebelum mengakhiri. Kode aplikasi perlu memahami SIGTERM dan masa tenggang mungkin perlu disesuaikan jika beban kerja membutuhkan waktu lebih lama untuk dimatikan. | No |
| Azure Kubernetes Service | Kapasitas komputasi tidak tersedia di wilayah untuk menambahkan lebih banyak simpul. | Operasi peningkatan/keluar skala akan gagal, tetapi seharusnya tidak memengaruhi simpul yang ada dan operasinya. Idealnya lalu lintas harus bergeser secara otomatis ke wilayah lain untuk penyeimbangan beban. | No |
| Azure Kubernetes Service | Langganan mencapai kuota inti CPU untuk menambahkan simpul baru. | Operasi peningkatan/keluar skala akan gagal, tetapi seharusnya tidak memengaruhi simpul yang ada dan operasinya. Idealnya lalu lintas harus bergeser secara otomatis ke wilayah lain untuk penyeimbangan beban. | No |
| Azure Kubernetes Service | Mari Enkripsi sertifikat TLS/SSL tidak dapat dikeluarkan/diperpanjang. | Kluster harus melaporkan tidak sehat ke Front Door dan lalu lintas harus bergeser ke stempel lain. Mitigasi: Selidiki akar penyebab masalah/kegagalan perpanjangan. | No |
| Azure Kubernetes Service | Ketika permintaan/batas sumber daya salah dikonfigurasi, pod dapat mencapai pemanfaatan CPU 100% dan permintaan gagal. Mekanisme coba lagi aplikasi harus dapat memulihkan permintaan yang gagal. Percobaan ulang dapat menyebabkan durasi permintaan yang lebih lama, tanpa memunculkan kesalahan ke klien. Beban yang berlebihan pada akhirnya akan menyebabkan kegagalan. | Tidak (jika beban tidak berlebihan) | |
| Azure Kubernetes Service | Citra/registri kontainer pihak ke-3 tidak tersedia | Beberapa komponen seperti cert-manager dan ingress-nginx memerlukan pengunduhan gambar kontainer dan bagan helm dari registri kontainer eksternal (lalu lintas keluar). Jika satu atau beberapa repositori atau gambar ini tidak tersedia, instans baru pada simpul baru (di mana gambar belum di-cache) mungkin tidak dapat dimulai. Kemungkinan mitigasi: Dalam beberapa skenario, masuk akal untuk mengimpor gambar kontainer pihak ke-3 ke dalam registri kontainer per solusi. Ini menambahkan kompleksitas tambahan dan harus direncanakan dan diopsisalisasikan dengan hati-hati. | Sebagian (selama operasi skala dan pembaruan/peningkatan) |
| Pusat Aktivitas | Pesan tidak dapat dikirim ke Azure Event Hubs | Stempel menjadi tidak dapat digunakan untuk operasi tulis. Layanan kesehatan harus secara otomatis mendeteksi ini dan mengambil stempel keluar dari rotasi. | No |
| Pusat Aktivitas | Pesan tidak dapat dibaca oleh BackgroundProcessor | Pesan akan mengantre. Pesan tidak boleh tersesat karena masih ada. Saat ini, kegagalan ini tidak tercakup oleh Layanan Kesehatan. Harus ada pemantauan/pemberitahuan di tempat pada pekerja untuk mendeteksi kesalahan dalam membaca pesan. Mitigasi: Stempel harus dinonaktifkan secara manual hingga masalah diperbaiki. | No |
| Akun penyimpanan | Akun penyimpanan menjadi tidak dapat digunakan oleh pekerja untuk titik pemeriksaan Azure Event Hubs | Stempel tidak akan memproses pesan dari Azure Event Hubs. Akun penyimpanan juga digunakan oleh HealthService. Masalah yang diharapkan dengan penyimpanan harus dideteksi oleh HealthService dan stempel harus diambil dari rotasi. Diharapkan bahwa layanan lain dalam stempel akan terpengaruh secara bersamaan. | No |
| Akun penyimpanan | Situs web statis mengalami masalah. | Jika penyajian situs web statis mengalami masalah, kegagalan ini harus dideteksi oleh Front Door. Lalu lintas tidak akan dikirim ke akun penyimpanan ini. Penembolokan di Front Door juga dapat meringankan masalah ini. | No |
| Key Vault | Key Vault tidak tersedia untuk GetSecret operasi. |
Pada awal pod baru, driver AKS CSI akan mengambil semua rahasia dari Key Vault dan gagal. Pod tidak akan dapat dimulai. Saat ini ada pembaruan otomatis setiap 5 menit. Pembaruan akan gagal. Kesalahan harus muncul di kubectl describe pod tetapi pod terus berfungsi. |
No |
| Key Vault | Key Vault tidak tersedia untuk GetSecret operasi atau SetSecret . |
Penyebaran baru tidak dapat dijalankan. Saat ini, kegagalan ini dapat menyebabkan seluruh alur penyebaran berhenti, bahkan jika hanya satu wilayah yang terpengaruh. | No |
| Key Vault | Pembatasan Key Vault | Key Vault memiliki batas 1000 operasi per 10 detik. Karena pembaruan otomatis rahasia, Anda dapat secara teori mencapai batas ini jika Anda memiliki banyak (ribuan) pod dalam stempel. Kemungkinan mitigasi: Kurangi frekuensi pembaruan lebih jauh atau matikan sepenuhnya. | No |
| Aplikasi | Salah konfigurasi | Salah string koneksi atau rahasia yang disuntikkan ke aplikasi. Harus dimitigasi oleh penyebaran otomatis (konfigurasi penanganan alur secara otomatis) dan peluncuran pembaruan biru-hijau. | No |
| Aplikasi | Kredensial kedaluwarsa (sumber daya stempel) | Jika misalnya, token SAS event hub atau kunci akun penyimpanan diubah tanpa memperbaruinya dengan benar di Key Vault sehingga pod dapat menggunakannya, komponen aplikasi masing-masing akan gagal. Kegagalan ini kemudian harus memengaruhi Layanan Kesehatan, dan stempel harus diambil dari rotasi secara otomatis. Mitigasi: Gunakan autentikasi berbasis ID Microsoft Entra untuk semua layanan yang mendukungnya. AKS mengharuskan pod untuk mengautentikasi menggunakan ID Beban Kerja Microsoft Entra (pratinjau). Penggunaan Identitas Pod dipertimbangkan dalam implementasi referensi. Ditemukan bahwa Identitas Pod saat ini tidak cukup stabil dan diputuskan untuk digunakan untuk arsitektur referensi saat ini. Identitas Pod bisa menjadi solusi di masa mendatang. | No |
| Aplikasi | Kredensial yang kedaluwarsa (sumber daya bersama global) | Jika misalnya, kunci API Azure Cosmos DB diubah tanpa memperbaruinya dengan benar di semua Key Vault stempel sehingga pod dapat menggunakannya, masing-masing komponen aplikasi akan gagal. Kegagalan ini akan menurunkan semua stempel pada saat yang sama dan menyebabkan pemadaman di seluruh beban kerja. Untuk kemungkinan cara mengatasi kebutuhan akan kunci dan rahasia menggunakan autentikasi Microsoft Entra, lihat item sebelumnya. | Penuh |
| Jaringan virtual | Ruang alamat IP subnet habis | Jika ruang alamat IP pada subnet habis, tidak ada operasi peluasan skala, seperti membuat simpul atau pod AKS baru, yang dapat terjadi. Ini tidak akan menyebabkan pemadaman tetapi dapat mengurangi performa dan berdampak pada pengalaman pengguna. Mitigasi: tingkatkan ruang IP (jika memungkinkan). Jika itu bukan pilihan, mungkin membantu meningkatkan sumber daya per Simpul (SKU VM yang lebih besar) atau per pod (lebih banyak CPU/memori), sehingga setiap pod dapat menangani lebih banyak lalu lintas, sehingga mengurangi kebutuhan akan peluasan skala. | No |
Langkah berikutnya
Sebarkan implementasi referensi untuk mendapatkan pemahaman penuh tentang sumber daya dan konfigurasinya yang digunakan dalam arsitektur ini.
Saran dan Komentar
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat: https://aka.ms/ContentUserFeedback.
Kirim dan lihat umpan balik untuk