Multitenancy dan Azure Resource Manager

Azure Resource Manager adalah layanan manajemen sumber daya inti untuk Azure. Setiap sumber daya di Azure dibuat, dikelola, dan akhirnya dihapus melalui Resource Manager. Ketika Anda membangun solusi multitenant, Anda sering bekerja dengan Resource Manager untuk menyediakan sumber daya secara dinamis untuk setiap penyewa. Pada halaman ini, kami menjelaskan beberapa fitur Resource Manager yang relevan dengan solusi multitenant. Kami juga akan menyediakan tautan ke panduan yang dapat membantu Anda saat Anda berencana menggunakan Resource Manager.

Fitur Resource Manager yang mendukung multitenancy

Infrastruktur sebagai kode

Resource Manager menyediakan alat untuk mendukung infrastruktur sebagai kode, kadang-kadang disebut sebagai IaC. Infrastruktur sebagai kode penting untuk semua solusi di cloud, tetapi ketika bekerja dengan solusi multitenant, hal tersebut menjadi sangat penting. Solusi multipenyewa sering mengharuskan Anda untuk menskalakan penyebaran, dan untuk menyediakan sumber daya baru saat Anda onboard penyewa baru. Jika Anda membuat atau mengonfigurasi sumber daya secara manual, maka Anda memperkenalkan risiko dan waktu ekstra untuk proses tersebut. Hal ini menghasilkan proses penyebaran yang kurang andal secara keseluruhan.

Saat menyebarkan infrastruktur Anda sebagai kode dari pipa penyebaran, kami menyarankan Anda menggunakan Bicep , yang merupakan bahasa yang dirancang khusus untuk menyebarkan dan mengelola sumber daya Azure dengan cara deklaratif. Anda juga dapat menggunakan template JSON Azure Resource Manager (template ARM), Terraform, atau produk pihak ketiga lainnya yang mengakses API Resource Manager yang mendasarinya.

Spesifikasi template dapat berguna untuk penyediaan sumber daya baru, stempel penyebaran, atau lingkungan dari template tunggal dan parameter yang baik. Dengan menggunakan spesifikasi templat, Anda dapat membuat repositori pusat templat yang Anda gunakan untuk menyebarkan infrastruktur khusus penyewa Anda. Templat disimpan dan dikelola dalam Azure itu sendiri, dan Anda dapat menggunakan kembali spesifikasi templat kapan pun Anda perlu menyebarkannya.

Dalam beberapa solusi, Anda mungkin memilih untuk menulis kode khusus untuk menyediakan atau mengonfigurasi sumber daya secara dinamis, atau untuk memulai penyebaran templat. SDK Azure dapat digunakan dari kode Anda sendiri, untuk mengelola lingkungan Azure Anda. Pastikan Anda mengikuti praktik yang baik sekeliling mengelola autentikasi aplikasi Anda ke Resource Manager, dan gunakan identitas terkelola untuk menghindari penyimpanan dan pengelolaan kredensial.

Kontrol Akses Berbasis Peran

Kontrol akses berbasis peran (Azure RBAC) memberi Anda pendekatan terperinci untuk mengelola akses ke sumber daya Azure Anda. Dalam solusi multitenant, pertimbangkan apakah Anda memiliki sumber daya yang harus menerapkan kebijakan Azure RBAC tertentu. Misalnya, Anda mungkin memiliki beberapa penyewa dengan data yang sangat sensitif, dan Anda mungkin perlu menerapkan RBAC untuk memberikan akses ke individu tertentu, tanpa menyertakan orang lain di organisasi Anda. Demikian pula, penyewa mungkin meminta untuk mengakses sumber daya Azure mereka secara langsung, seperti selama audit. Jika Anda memilih untuk mengizinkan izin RBAC yang terlingkup halus ini dapat memungkinkan Anda memberikan akses ke data penyewa, tanpa menyediakan akses ke data penyewa lain.

Tag

Tag memungkinkan Anda menambahkan metadata khusus ke sumber daya, Azure, grup sumber daya, dan langganan. Pertimbangkan untuk menandai sumber daya khusus penyewa Anda dengan mengidentifikasi penyewa sehingga Anda dapat dengan mudah melacak dan mengalokasikan biaya Azure Anda, dan untuk menyederhanakan manajemen sumber daya Anda.

Kelola kuota sumber daya

Resource Manager adalah salah satu poin di Azure yang memberlakukan batas dan kuota. Kuota ini penting untuk dipertimbangkan selama proses desain Anda. Semua sumber daya Azure memiliki batasan yang perlu dipatuhi, dan batasan ini mencakup jumlah permintaan yang dapat dibuat terhadap Resource Manager dalam periode waktu tertentu. Jika Anda melebihi batas ini, Resource Manager membatasi permintaan.

Saat Anda membangun solusi multitenant yang melakukan penyebaran otomatis, Anda dapat mencapai batas ini lebih cepat daripada pelanggan lain. dengan cara yang sama, solusi multitenant yang menyediakan infrastruktur dalam jumlah besar dapat memicu batasan tersebut.

Setiap layanan Azure dikelola oleh penyedia sumber daya, yang juga dapat menentukan batasnya sendiri. Misalnya, Azure Compute Resource Provider mengelola penyediaan mesin virtual, dan mendefinisikan batasan jumlah permintaan yang dapat dibuat dalam waktu singkat. Beberapa batas penyedia sumber daya lainnya didokumentasikan dalam batas penyedia Sumber daya.

Jika Anda berisiko melebihi batas yang ditentukan oleh Resource Manager atau penyedia sumber daya, pertimbangkan mitigasi berikut:

  • Pecahkan beban kerja Anda di beberapa langganan Azure.
  • Gunakan beberapa grup sumber daya dalam langganan.
  • Kirim permintaan dari perwakilan Microsoft Entra yang berbeda.
  • Mintalah alokasi kuota tambahan. Secara umum, permintaan alokasi kuota diajukan dengan membuka kasus dukungan, meskipun beberapa layanan menyediakan API untuk permintaan ini, seperti untuk instans yang dipesan mesin virtual.

Mitigasi yang Anda pilih harus sesuai dengan batas spesifik yang Anda temui.

Model isolasi

Dalam beberapa solusi multitenant, Anda mungkin memutuskan untuk menyebarkan sumber daya terpisah atau khusus untuk setiap penyewa. Azure Resource Manager menyediakan beberapa model yang dapat Anda gunakan untuk mengisolasi sumber daya, tergantung pada kebutuhan Anda dan alasan Anda memilih untuk mengisolasi sumber daya. Lihat Organisasi sumber daya Azure dalam solusi multipenyewa untuk panduan tentang cara mengisolasi sumber daya Azure Anda.

Kontributor

Artikel ini dikelola oleh Microsoft. Ini awalnya ditulis oleh kontributor berikut.

Penulis utama:

  • John Downs | Teknisi Pelanggan Utama, FastTrack untuk Azure

Kontributor lainnya:

Untuk melihat profil LinkedIn non-publik, masuk ke LinkedIn.

Langkah berikutnya

Tinjau pendekatan penerapan dan konfigurasi untuk multitenancy.