Arsitektur referensi ini menyediakan panduan untuk menyebarkan beban kerja misi penting yang menggunakan layanan bersama terpusat, membutuhkan konektivitas lokal, dan terintegrasi dengan beban kerja lain dari perusahaan. Panduan ini ditujukan untuk pemilik beban kerja yang merupakan bagian dari tim aplikasi dalam organisasi.
Anda mungkin menemukan diri Anda dalam situasi ini ketika organisasi Anda ingin menyebarkan beban kerja di zona pendaratan aplikasi Azure yang mewarisi grup Manajemen Corp. Beban kerja diharapkan terintegrasi dengan sumber daya bersama yang telah disediakan sebelumnya di zona pendaratan platform Azure yang dikelola oleh tim terpusat.
Penting
Apa itu zona arahan Azure? Zona pendaratan aplikasi adalah langganan Azure tempat beban kerja berjalan. Ini terhubung ke sumber daya bersama organisasi. Melalui koneksi tersebut, ia memiliki akses ke infrastruktur dasar yang diperlukan untuk menjalankan beban kerja, seperti jaringan, manajemen akses identitas, kebijakan, dan pemantauan. Zona pendaratan platform adalah kumpulan berbagai langganan, masing-masing dengan fungsi tertentu. Misalnya, langganan Koneksi ivity menyediakan resolusi DNS terpusat, konektivitas lokal, dan appliance virtual jaringan (NVA) yang tersedia untuk digunakan oleh tim aplikasi.
Sebagai pemilik beban kerja, Anda mendapat manfaat dengan membongkar manajemen sumber daya bersama kepada tim pusat dan fokus pada upaya pengembangan beban kerja. Organisasi mendapat manfaat dengan menerapkan tata kelola yang konsisten dan mengamortisasi biaya di beberapa beban kerja.
Kami sangat menyarankan Agar Anda memahami konsep zona pendaratan Azure.
Dalam pendekatan ini, keandalan maksimum adalah tanggung jawab bersama antara Anda dan tim platform. Komponen yang dikelola secara terpusat harus sangat dapat diandalkan agar beban kerja misi penting beroperasi seperti yang diharapkan. Anda harus memiliki hubungan tepercaya dengan tim platform sehingga masalah tidak tersedia dalam layanan terpusat, yang memengaruhi beban kerja, dimitigasi di tingkat platform. Tapi, tim Anda bertanggung jawab atas persyaratan mengemudi dengan tim platform untuk mencapai target Anda.
Arsitektur ini dibangun berdasarkan arsitektur garis besar misi-penting dengan kontrol jaringan. Disarankan agar Anda terbiasa dengan arsitektur garis besar sebelum melanjutkan artikel ini.
Catatan
Panduan ini didukung oleh implementasi contoh tingkat produksi yang menampilkan pengembangan aplikasi misi penting di Azure. Implementasi ini dapat digunakan sebagai dasar untuk pengembangan solusi lebih lanjut sebagai langkah pertama Anda menuju produksi.
Strategi desain utama
Terapkan strategi ini di atas garis besar misi-kritis:
Jalur kritis
Tidak semua komponen arsitektur harus sama-sama dapat diandalkan. Jalur kritis mencakup komponen-komponen yang harus tetap berfungsi sehingga beban kerja tidak mengalami waktu henti atau performa yang terdegradasi. Menjaga jalur itu tetap ramping akan meminimalkan titik kegagalan.
Siklus hidup komponen
Pertimbangkan siklus hidup komponen penting karena berdampak pada tujuan Anda mencapai hampir nol waktu henti. Komponen dapat berupa sumber daya sementara atau berumur pendek yang dapat dibuat dan dihancurkan sesuai kebutuhan; sumber daya non-sementara atau berumur panjang yang berbagi masa pakai dengan sistem atau wilayah.
Dependensi eksternal
Minimalkan dependensi eksternal pada komponen dan proses, yang dapat memperkenalkan titik kegagalan. Arsitektur ini memiliki sumber daya yang dimiliki oleh berbagai tim di luar tim Anda. Komponen tersebut (jika penting) berada dalam cakupan untuk arsitektur ini.
Topologi langganan
Zona pendaratan Azure tidak menyiratkan topologi langganan tunggal. Rencanakan jejak langganan Anda terlebih dahulu dengan tim platform Anda untuk mengakomodasi persyaratan keandalan beban kerja di semua lingkungan.
Pengamatan otonom ke jalur kritis
Memiliki sumber daya pemantauan khusus yang memungkinkan tim untuk dengan cepat mengkueri pengumpulan data mereka (terutama jalur penting) dan bertindak berdasarkan remediasi.
Arsitektur
Unduh file Visio arsitektur ini.
Komponen arsitektur ini sama dengan arsitektur garis besar misi-kritis dengan kontrol jaringan. Deskripsinya singkatan dari brevity. Jika Anda memerlukan informasi selengkapnya, lihat artikel tertaut. Untuk dokumentasi produk tentang layanan Azure, lihat Sumber daya terkait.
Sumber daya global
Sumber daya ini hidup di langganan zona pendaratan aplikasi. Sumber daya global bersifat non-sementara dan berbagi masa pakai sistem. Layanan Azure dan konfigurasinya tetap sama dengan sumber daya global garis besar.
Sumber daya jaringan regional
Sumber daya ini hidup di seluruh langganan zona pendaratan platform dan langganan zona pendaratan aplikasi. Arsitektur garis besar menyebarkan semua sumber daya yang Anda miliki. Namun dalam arsitektur ini, sumber daya jaringan disediakan melalui langganan Koneksi ivity disediakan sebagai bagian dari zona pendaratan platform.
Dalam artikel ini, lihat bagian Jaringan virtual hub regional.
Sumber daya stempel regional
Sumber daya ini hidup di langganan zona pendaratan aplikasi. Sumber daya ini tidak berbagi apa pun dengan sumber daya lain, kecuali sumber daya global.
Sebagian besar layanan Azure dan konfigurasinya tetap sama dengan arsitektur stempel garis besar, kecuali untuk sumber daya jaringan, yang telah disediakan sebelumnya oleh tim platform.
Dalam artikel ini, lihat bagian Jaringan virtual spoke regional.
Sumber daya eksternal
Beban kerja berinteraksi dengan sumber daya lokal. Beberapa di antaranya berada di jalur penting untuk beban kerja, misalnya database lokal. Sumber daya dan komunikasi ini dengan mereka diperhitungkan dalam Perjanjian Tingkat Layanan (SLA) komposit keseluruhan dari beban kerja. Semua komunikasi melalui langganan Koneksi ivity. Ada sumber daya eksternal lain yang mungkin dijangkau beban kerja tetapi tidak dianggap penting.
Sumber daya alur penyebaran
Membangun dan merilis alur untuk aplikasi misi-penting harus sepenuhnya otomatis untuk menjamin cara yang konsisten untuk menyebarkan stempel yang divalidasi. Sumber daya ini tetap sama dengan alur penyebaran dasar.
Sumber daya pemantauan regional
Sumber daya ini hidup di langganan zona pendaratan aplikasi. Data pemantauan untuk sumber daya global dan sumber daya regional disimpan secara independen. Layanan Azure dan konfigurasinya tetap sama dengan sumber daya pemantauan garis besar.
Dalam artikel ini, lihat bagian Pertimbangan pemantauan.
Sumber daya manajemen
Untuk mendapatkan akses ke kluster komputasi privat dan sumber daya lainnya, arsitektur ini menggunakan agen build privat dan instans komputer virtual jump box. Azure Bastion menyediakan akses aman ke jump box. Sumber daya di dalam stempel tetap sama dengan sumber daya manajemen garis besar.
Pertimbangan jaringan
Dalam desain ini, beban kerja disebarkan di zona pendaratan aplikasi dan membutuhkan konektivitas ke sumber daya federasi di zona pendaratan platform. Tujuannya bisa untuk mengakses sumber daya lokal, mengontrol lalu lintas keluar, dan sebagainya.
Topologi jaringan
Tim platform memutuskan topologi jaringan untuk seluruh organisasi. Topologi hub-spoke diasumsikan dalam arsitektur ini. Alternatifnya bisa azure Virtual WAN.
Jaringan virtual hub regional
Langganan Koneksi ivity berisi jaringan virtual hub dengan sumber daya, yang dibagikan oleh seluruh organisasi. Sumber daya ini dimiliki dan dikelola oleh tim platform.
Dari perspektif misi-kritis, jaringan ini non-ephemeral, dan sumber daya ini berada di jalur kritis.
| Sumber daya Azure | Tujuan |
|---|---|
| Azure ExpressRoute | Menyediakan konektivitas privat dari infrastruktur lokal ke Azure. |
| Azure Firewall | Bertindak sebagai NVA yang memeriksa dan membatasi lalu lintas keluar. |
| DNS Azure | Menyediakan resolusi nama lintas tempat. |
| Gateway VPN | Koneksi cabang organisasi jarak jauh melalui internet publik ke infrastruktur Azure. Juga bertindak sebagai alternatif konektivitas cadangan untuk menambahkan ketahanan. |
Sumber daya disediakan di setiap wilayah dan di-peering ke jaringan virtual spoke (dijelaskan berikutnya). Pastikan Anda memahami dan menyetujui pembaruan untuk NVA, aturan firewall, aturan perutean, ExpressRoute failover ke VPN Gateway, infrastruktur DNS, dan sebagainya.
Catatan
Manfaat utama dalam menggunakan hub federasi adalah bahwa beban kerja dapat diintegrasikan dengan beban kerja lain baik di Azure atau lintas tempat dengan melintasi hub jaringan yang dikelola organisasi. Perubahan ini juga menurunkan biaya operasional Anda karena bagian dari tanggung jawab digeser ke tim platform.
Jaringan virtual spoke regional
Zona pendaratan aplikasi memiliki setidaknya dua Azure Virtual Network yang telah disediakan sebelumnya, per wilayah, yang dirujuk oleh stempel regional. Jaringan ini non-ephemeral. Satu melayani lalu lintas produksi dan yang lain menargetkan penyebaran vNext. Pendekatan ini memberi Anda kemampuan untuk melakukan praktik penyebaran yang andal dan aman.
Jaringan virtual operasi
Lalu lintas operasional diisolasi dalam jaringan virtual terpisah. Jaringan virtual ini non-ephemeral dan Anda memiliki jaringan ini. Arsitektur ini mempertahankan desain yang sama dengan arsitektur garis besar dengan kontrol jaringan.
Tidak ada peering antara jaringan operasi dan jaringan spoke. Semua komunikasi melalui Private Links.
Tanggung jawab bersama
Memiliki pemahaman yang jelas tentang tim mana yang bertanggung jawab untuk setiap elemen desain arsitektur. Berikut adalah beberapa area utama.
Perencanaan alamat IP
Setelah Anda memperkirakan ukuran yang diperlukan untuk menjalankan beban kerja Anda, bekerja dengan tim platform sehingga mereka dapat menyediakan jaringan dengan tepat.
Tim platform
Berikan alamat berbeda untuk jaringan virtual yang berpartisipasi dalam peering. Alamat yang tumpang tindih, misalnya jaringan lokal dan beban kerja, dapat menyebabkan gangguan yang menyebabkan pemadaman.
Alokasikan ruang alamat IP yang cukup besar untuk berisi sumber daya runtime dan penyebaran, menangani failover, dan mendukung skalabilitas.
Jaringan virtual dan peering yang telah disediakan sebelumnya harus dapat mendukung pertumbuhan beban kerja yang diharapkan. Anda harus mengevaluasi pertumbuhan tersebut dengan tim platform secara teratur. Untuk informasi selengkapnya, lihat Koneksi ke Azure.
Subnet jaringan spoke regional
Anda bertanggung jawab untuk mengalokasikan subnet di jaringan virtual regional. Subnet dan sumber daya di dalamnya bersifat ephemeral. Ruang alamat harus cukup besar untuk mengakomodasi potensi pertumbuhan.
Subnet titik akhir privat Setelah lalu lintas mencapai jaringan virtual, komunikasi dengan layanan PaaS dalam jaringan, dibatasi dengan menggunakan titik akhir privat, sama seperti arsitektur garis besar dengan kontrol jaringan. Titik akhir ini ditempatkan di subnet khusus. Alamat IP privat ke titik akhir privat ditetapkan dari subnet tersebut.
Subnet kluster Persyaratan skalabilitas beban kerja memengaruhi berapa banyak ruang alamat yang harus dialokasikan untuk subnet. Saat simpul dan pod AKS diperluas skalanya, alamat IP ditetapkan dari subnet ini.
Segmentasi jaringan
Pertahankan segmentasi yang tepat sehingga keandalan beban kerja Anda tidak disusupi oleh akses yang tidak sah.
Arsitektur ini menggunakan Network Security Groups (NSGs) untuk membatasi lalu lintas di seluruh subnet dan langganan Koneksi ivity. NSG menggunakan ServiceTags untuk layanan yang didukung.
Tim platform
Menerapkan penggunaan NSG melalui Kebijakan Azure Network Manager.
Waspadai desain beban kerja. Tidak ada lalu lintas langsung antara stempel. Juga tidak ada alur antar-wilayah. Jika jalur tersebut diperlukan, lalu lintas harus mengalir melalui langganan Koneksi ivity.
Cegah lalu lintas hub yang tidak perlu berasal dari beban kerja lain ke dalam beban kerja misi penting.
Lalu lintas keluar dari stempel regional
Semua lalu lintas keluar dari setiap jaringan spoke regional dirutekan melalui Azure Firewall terpusat di jaringan hub regional. Ini bertindak sebagai hop berikutnya yang memeriksa dan kemudian mengizinkan atau menolak lalu lintas.
Tim platform
Buat UDR untuk rute kustom tersebut.
Tetapkan kebijakan Azure yang akan memblokir tim aplikasi untuk membuat subnet yang tidak memiliki tabel rute baru.
Berikan izin kontrol akses berbasis peran (RBAC) yang memadai kepada tim aplikasi sehingga mereka dapat memperluas rute berdasarkan persyaratan beban kerja.
Redundansi multi-wilayah
Beban kerja misi penting Anda harus disebarkan di beberapa wilayah untuk menahan pemadaman regional. Bekerja sama dengan tim platform untuk memastikan infrastruktur dapat diandalkan.
Tim platform
Menyebarkan sumber daya jaringan terpusat per wilayah. Metodologi desain misi-kritis membutuhkan isolasi regional.
Bekerja sama dengan tim aplikasi untuk mengungkap dependensi regional tersembunyi sehingga sumber daya platform yang terdegradasi di satu wilayah tidak memengaruhi beban kerja di wilayah lain.
Penyelesaian DNS
Langganan Koneksi ivity menyediakan zona DNS privat. Namun, pendekatan terpusat itu mungkin tidak memperhitungkan kebutuhan DNS yang mungkin spesifik untuk kasus penggunaan Anda. Sediakan zona DNS Anda sendiri dan tautkan ke stempel regional. Jika tim aplikasi tidak memiliki DNS, manajemen tautan privat menjadi tantangan bagi sumber daya global, seperti Azure Cosmos DB.
Tim platform
Delegasikan zona DNS Privat Azure ke tim aplikasi untuk mencakup kasus penggunaannya.
Untuk jaringan hub regional, atur nilai server DNS ke Default (disediakan Azure) untuk mendukung zona DNS privat yang dikelola oleh tim aplikasi.
Pertimbangan desain lingkungan
Ini adalah praktik umum untuk menempatkan beban kerja di lingkungan terpisah untuk produksi, pra-produksi, dan pengembangan. Berikut adalah beberapa pertimbangan utama.
Bagaimana isolasi dipertahankan?
Lingkungan produksi harus diisolasi dari lingkungan lain. Lingkungan yang lebih rendah juga harus mempertahankan tingkat isolasi. Hindari berbagi sumber daya milik aplikasi antar lingkungan.
Satu lingkungan produksi diperlukan untuk sumber daya global, regional, dan stempel yang dimiliki oleh tim aplikasi. Lingkungan pra-produksi, seperti penahapan dan integrasi, diperlukan untuk memastikan aplikasi diuji di lingkungan yang mensimulasikan produksi, sebanyak mungkin. Lingkungan pengembangan harus menjadi versi produksi yang diturunkan skalanya.
Apa siklus hidup yang diharapkan?
Lingkungan pra-produksi dapat dihancurkan setelah pengujian validasi selesai. Disarankan agar lingkungan pengembangan berbagi masa pakai fitur dan dihancurkan ketika pengembangan selesai. Tindakan tersebut dilakukan oleh otomatisasi integrasi berkelanjutan/penyebaran berkelanjutan (CI/CD).
Apa saja pertukarannya?
Pertimbangkan tradeoff antara isolasi lingkungan, kompleksitas manajemen, dan pengoptimalan biaya.
Tip
Semua lingkungan harus mengambil dependensi pada instans produksi sumber daya eksternal termasuk sumber daya platform. Misalnya, hub regional produksi dalam langganan Koneksi ivity. Anda akan dapat meminimalkan delta antara lingkungan pra-produksi dan produksi.
Topologi langganan untuk infrastruktur beban kerja
Langganan diberikan kepada Anda oleh tim platform. Bergantung pada jumlah lingkungan, Anda akan meminta beberapa langganan hanya untuk satu beban kerja. Bergantung pada jenis lingkungan, beberapa lingkungan mungkin memerlukan langganan khusus sementara lingkungan lain mungkin dikonsolidasikan ke dalam satu langganan.
Terlepas dari itu, bekerja samalah dengan tim platform untuk merancang topologi yang memenuhi target keandalan keseluruhan untuk beban kerja. Ada manfaat untuk berbagi sumber daya yang disediakan platform antar lingkungan dalam langganan yang sama karena akan mencerminkan lingkungan produksi.
Catatan
Menggunakan beberapa langganan untuk berisi lingkungan dapat mencapai tingkat isolasi yang diperlukan. Langganan zona pendaratan diwariskan dari grup manajemen yang sama. Jadi, konsistensi dengan produksi dipastikan untuk pengujian dan validasi.
Langganan produksi
Mungkin ada batas sumber daya pada langganan yang diberikan kepada Anda. Jika Anda mengkolokasikan semua sumber daya tersebut dalam satu langganan, Anda mungkin mencapai batas tersebut. Berdasarkan unit skala dan skala yang diharapkan, pertimbangkan model yang lebih terdistribusi. Contohnya,
Satu langganan yang berisi agen build Azure DevOps dan sumber daya global.
Satu langganan, per wilayah. Ini berisi sumber daya regional, sumber daya stempel, dan jump box untuk stempel regional.
Berikut adalah contoh topologi langganan yang digunakan dalam arsitektur ini.
Langganan pra-produksi
Setidaknya satu langganan diperlukan. Namun, ini dapat menjalankan banyak lingkungan independen, yang direkomendasikan untuk memiliki beberapa lingkungan dalam langganan khusus. Langganan ini mungkin juga tunduk pada batas sumber daya seperti langganan produksi, yang dijelaskan di atas.
Langganan pengembangan
Setidaknya satu langganan diperlukan. Langganan ini mungkin tunduk pada batas sumber daya jika menjalankan semua lingkungan independen. Jadi, Anda dapat meminta beberapa langganan. Direkomendasikan memiliki lingkungan individual dalam langganan khusus mereka.
Cobalah untuk mencocokkan topologi produksi sebanyak mungkin.
Pertimbangan penyebaran
Penyebaran yang gagal atau rilis yang salah adalah penyebab umum pemadaman aplikasi. Uji aplikasi Anda (dan fitur baru) secara menyeluruh sebagai bagian dari siklus hidup aplikasi. Saat menyebarkan beban kerja di zona pendaratan, Anda harus mengintegrasikan desain Anda dengan sumber daya dan tata kelola yang disediakan platform.
Lihat: Beban kerja misi penting yang dirancang dengan baik: Penyebaran dan pengujian.
Infrastruktur penyebaran
Keandalan infrastruktur penyebaran, seperti agen build dan jaringannya, seringkali sama pentingnya dengan sumber daya runtime beban kerja.
Arsitektur ini menggunakan agen build privat untuk mencegah akses tidak sah yang dapat memengaruhi ketersediaan aplikasi.
Mempertahankan isolasi antara sumber daya penyebaran sangat disarankan. Infrastruktur penyebaran harus terikat dengan langganan beban kerja Anda untuk lingkungan tersebut. Jika Anda menggunakan beberapa lingkungan dalam langganan pra-produksi, buat pemisahan lebih lanjut dengan membatasi akses hanya ke lingkungan individual tersebut. Sumber daya penyebaran per wilayah dapat dipertimbangkan untuk membuat infrastruktur penyebaran lebih andal.
Penyebaran waktu henti nol
Pembaruan pada aplikasi dapat menyebabkan pemadaman. Memberlakukan penyebaran yang konsisten akan meningkatkan keandalan. Pendekatan ini direkomendasikan:
- Memiliki alur penyebaran otomatis sepenuhnya.
- Sebarkan pembaruan di lingkungan pra-produksi pada stempel bersih.
Untuk informasi selengkapnya, lihat Panduan penyebaran dan pengujian misi-kritis.
Dalam arsitektur garis besar, strategi tersebut diterapkan dengan membatalkan provisi dan kemudian merobohkan stempel dengan setiap pembaruan. Dalam desain ini, pembatalan penyediaan lengkap tidak dimungkinkan karena tim platform memiliki beberapa sumber daya. Jadi model penyebaran diubah.
Model Penyebaran
Arsitektur garis besar menggunakan model Blue-Green untuk menyebarkan pembaruan aplikasi. Stempel baru dengan perubahan disebarkan bersama stempel yang ada. Setelah lalu lintas dipindahkan ke stempel baru, stempel yang ada dihancurkan.
Dalam hal ini, jaringan virtual yang di-peering yang diberikan bersifat non-ephemeral. Stempel tidak diizinkan untuk membuat jaringan virtual atau peering ke hub regional. Anda harus menggunakan kembali sumber daya tersebut di setiap penyebaran.
Model kenari dapat mencapai penyebaran yang aman dengan opsi untuk menggulung balik. Pertama, stempel baru disebarkan dengan perubahan kode. Alur penyebaran mereferensikan jaringan virtual yang telah disediakan sebelumnya dan mengalokasikan subnet, menyebarkan sumber daya, menambahkan titik akhir privat. Kemudian, ini mengalihkan lalu lintas ke subnet ini di jaringan virtual yang telah disediakan sebelumnya ini.
Ketika stempel yang ada tidak lagi diperlukan, semua sumber daya stempel dihapus oleh alur, kecuali untuk sumber daya milik platform. Jaringan virtual, pengaturan diagnostik, peering, ruang alamat IP, konfigurasi DNS, dan kontrol akses berbasis peran (RBAC) dipertahankan. Pada titik ini, stempel dalam keadaan bersih, dan siap untuk penyebaran baru berikutnya.
Kebijakan Azure DINE (deploy-if-not-exists)
Zona pendaratan aplikasi Azure mungkin memiliki kebijakan Azure DINE (deploy-if-not-exists). Pemeriksaan tersebut memastikan bahwa sumber daya yang disebarkan memenuhi standar perusahaan di zona pendaratan aplikasi, bahkan ketika mereka dimiliki oleh tim aplikasi. Mungkin ada ketidakcocokan antara penyebaran Anda dan konfigurasi sumber daya akhir.
Pahami dampak semua kebijakan DINE yang akan diterapkan pada sumber daya Anda. Jika ada perubahan pada konfigurasi sumber daya, masukkan niat kebijakan ke dalam penyebaran deklaratif Anda di awal siklus pengembangan beban kerja. Jika tidak, mungkin ada penyimpangan yang mengarah ke delta antara status yang diinginkan dan status yang disebarkan.
Manajemen akses langganan penyebaran
Perlakukan batas langganan sebagai batas keamanan Anda untuk membatasi radius ledakan. Ancaman dapat memengaruhi keandalan beban kerja.
Tim platform
- Berikan otorisasi tim aplikasi untuk operasi dengan izin yang tercakup dalam langganan zona pendaratan aplikasi.
Jika Anda menjalankan beberapa penyebaran dalam satu langganan, pelanggaran akan memengaruhi kedua penyebaran. Menjalankan penyebaran dalam langganan khusus disarankan. Buat perwakilan layanan per lingkungan untuk mempertahankan pemisahan logis.
Perwakilan layanan harus memberikan otonomi atas sumber daya beban kerja. Selain itu, harus memiliki batasan yang akan mencegah manipulasi sumber daya platform yang berlebihan dalam langganan.
Pertimbangan pemantauan
Platform zona pendaratan Azure menyediakan sumber daya pengamatan bersama sebagai bagian dari langganan Manajemen. Tim operasi terpusat mendorong tim aplikasi untuk menggunakan model federasi. Tetapi untuk beban kerja misi-kritis, penyimpanan observabilitas terpusat tunggal tidak disarankan karena berpotensi menjadi satu titik kegagalan. Beban kerja misi penting juga menghasilkan telemetri yang mungkin tidak berlaku atau dapat ditindak lanjuti untuk tim operasi terpusat.
Jadi, pendekatan otonom untuk pemantauan sangat disarankan. Operator beban kerja pada akhirnya bertanggung jawab atas pemantauan dan harus memiliki akses ke semua data yang mewakili kesehatan secara keseluruhan.
Arsitektur garis besar mengikuti pendekatan tersebut dan dilanjutkan dalam arsitektur referensi ini. Azure Log Analytics dan Azure Application Insights disebarkan secara regional dan global untuk memantau sumber daya dalam cakupan tersebut. Menggabungkan log, membuat dasbor, dan pemberitahuan berada dalam cakupan untuk tim Anda. Manfaatkan kemampuan Diagnostik Azure yang mengirim metrik dan log ke berbagai sink untuk mendukung persyaratan platform untuk pengumpulan log & metrik.
Model kesehatan
Metodologi desain misi penting membutuhkan model kesehatan sistem. Saat Anda menentukan skor kesehatan keseluruhan, sertakan alur zona pendaratan platform dalam cakupan yang bergantung pada aplikasi. Buat kueri log, kesehatan, dan pemberitahuan untuk melakukan pemantauan lintas ruang kerja.
Tim platform
Berikan kueri kontrol akses berbasis peran (RBAC) dan sink log baca untuk sumber daya platform yang relevan yang digunakan di jalur penting aplikasi misi penting.
Mendukung tujuan organisasi keandalan terhadap beban kerja misi-kritis dengan memberi tim aplikasi izin yang cukup untuk melakukan operasi mereka.
Dalam arsitektur ini, model kesehatan mencakup log dan metrik dari sumber daya yang disediakan dalam langganan Koneksi ivity. Jika Anda memperluas desain ini untuk menjangkau sumber daya lokal seperti database, model kesehatan harus menyertakan konektivitas jaringan ke sumber daya tersebut, termasuk batas keamanan seperti appliance virtual jaringan di Azure dan lokal. Informasi ini penting untuk dengan cepat menentukan akar penyebab dan memulihkan dampak keandalan. Misalnya, apakah kegagalan terjadi saat mencoba merutekan ke database, atau apakah ada masalah dengan database?
Lihat: Beban kerja misi penting yang dirancang dengan baik: Pemodelan kesehatan.
Integrasi dengan kebijakan dan aturan yang disediakan platform
Langganan zona arahan aplikasi mewarisi kebijakan Azure, aturan Azure Network Manager, dan kontrol lainnya dari grup manajemennya. Tim platform menyediakan pagar pembatas tersebut.
Untuk penyebaran, jangan bergantung pada kebijakan yang disediakan platform secara eksklusif, karena:
- Mereka tidak dirancang untuk memenuhi kebutuhan beban kerja individu.
- Kebijakan dan aturan mungkin diperbarui atau dihapus di luar tim Anda, sehingga dapat memengaruhi keandalan.
Sangat disarankan agar Anda membuat dan menetapkan kebijakan Azure dalam penyebaran Anda. Upaya ini mungkin menyebabkan beberapa duplikasi tetapi itu dapat diterima, mengingat dampak potensial pada keandalan sistem. Jika ada perubahan dalam kebijakan platform, kebijakan beban kerja masih akan berlaku secara lokal.
Tim platform
- Libatkan tim aplikasi dalam proses manajemen perubahan kebijakan saat berkembang.
- Ketahui kebijakan yang digunakan oleh tim aplikasi. Evaluasi apakah harus ditambahkan ke grup manajemen.
Menyebarkan arsitektur ini
Aspek jaringan arsitektur ini diimplementasikan dalam implementasi mission-critical Koneksi ed.
Catatan
Implementasi yang Koneksi dimaksudkan untuk mengilustrasikan beban kerja misi penting yang bergantung pada sumber daya organisasi, terintegrasi dengan beban kerja lain, dan menggunakan layanan bersama. Implementasi mengasumsikan bahwa langganan Koneksi ivity sudah ada.
Langkah berikutnya
Tinjau area desain jaringan dan konektivitas di Azure Well-architected Framework.
Sumber daya terkait
Selain layanan Azure yang digunakan dalam arsitektur garis besar, layanan ini penting untuk arsitektur ini.