Penerapan Azure Resource Manager vs. klasik: Memahami model penyebaran dan status sumber daya Anda

Catatan

Informasi yang diberikan dalam artikel ini hanya digunakan saat Anda melakukan migrasi dari penerapan klasik ke Azure Resource Manager.

Dalam artikel ini, Anda mempelajari tentang model penerapan Azure Resource Manager dan klasik. Model penyebaran Resource Manager dan klasik mewakili dua cara berbeda dalam menyebarkan dan mengelola solusi Azure Anda. Anda bekerja dengan mereka melalui dua set API yang berbeda, dan sumber daya yang diterapkan dapat berisi perbedaan yang penting. Dua model tersebut tidak sepenuhnya kompatibel satu sama lain. Artikel ini menjelaskan perbedaan tersebut.

Untuk menyederhanakan penerapan dan pengelolaan sumber daya, Microsoft menyarankan agar Anda menggunakan Resource Manager untuk semua sumber daya baru. Jika memungkinkan, Microsoft menyarankan agar Anda melakukan penerapan ulang sumber daya yang ada melalui Resource Manager. Jika anda telah menggunakan Cloud Services, Anda dapat memigrasikan solusi Anda ke Cloud Services (dukungan yang diperluas).

Jika Anda baru menggunakan Resource Manager, Anda mungkin ingin terlebih dahulu meninjau terminologi yang ditentukan dalam Ringkasan Azure Resource Manager.

Riwayat model penerapan

Azure awalnya hanya menyediakan model penerapan klasik. Dalam model ini, setiap sumber daya ada secara independen; tidak ada cara untuk mengelompokkan sumber daya terkait bersama-sama. Sebaliknya, Anda harus melacak sumber daya mana yang terdiri dari solusi atau aplikasi Anda secara manual, dan ingat untuk mengelolanya dalam pendekatan terkoordinasi. Untuk menerapkan solusi, Anda harus membuat setiap sumber daya satu per satu melalui portal atau membuat skrip yang diterapkan semua sumber daya dalam urutan yang benar. Untuk menghapus solusi, Anda harus menghapus setiap sumber daya satu per satu. Anda tidak dapat dengan mudah menerapkan dan memperbarui kebijakan kontrol akses untuk sumber daya terkait. Terakhir, Anda tidak dapat menerapkan tag ke sumber daya untuk melabelinya dengan istilah yang membantu Anda memantau sumber daya dan mengelola penagihan Anda.

Pada tahun 2014, Azure memperkenalkan Resource Manager, yang menambah konsep grup sumber daya. Grup sumber daya adalah kontainer untuk sumber daya yang berbagi siklus hidup secara umum. Model penerapan Resource Manager memberikan beberapa manfaat:

  • Anda dapat menerapkan, mengelola, dan memantau semua layanan untuk solusi Anda sebagai grup, daripada menangani layanan ini satu per satu.
  • Anda dapat menerapkan kembali solusi Anda sepanjang siklus hidupnya dan memiliki keyakinan bahwa sumber daya Anda disebarkan dalam kondisi yang konsisten.
  • Anda dapat menerapkan kontrol akses ke semua sumber daya di grup sumber daya Anda, dan kebijakan tersebut diterapkan secara otomatis saat sumber daya baru ditambahkan ke grup sumber daya.
  • Anda dapat menerapkan tag ke sumber daya untuk menata semua sumber daya dalam langganan Anda secara logis.
  • Anda dapat menggunakan JavaScript Object Notation (JSON) untuk menentukan infrastruktur untuk solusi Anda. File JSON dikenal sebagai template Resource Manager.
  • Anda dapay menentukan dependensi antar sumber daya sehingga disebarkan dalam urutan yang benar.

Ketika Resource Manager ditambahkan, semua sumber daya ditambahkan secara retroaktif ke grup sumber daya default. Jika Anda membuat sumber daya melalui penerapan klasik sekarang, sumber daya secara otomatis dibuat dalam grup sumber daya default untuk layanan tersebut, meskipun Anda tidak menentukan grup sumber daya tersebut saat penerapan. Namun, hanya ada dalam grup sumber daya tidak berarti bahwa sumber daya telah dikonversi ke model Resource Manager.

Memahami dukungan untuk model

Ada tiga skenario yang harus diperhatikan:

  1. Cloud Services (klasik) tidak mendukung model penerapan Resource Manager. Cloud Services (dukungan perpanjangan) mendukung model penerapan Resource Manager.
  2. Komputer virtual, akun penyimpanan, dan jaringan virtual mendukung keduanya yakni model penerapan Resource Manager dan klasik.
  3. Semua layanan Azure lainnya mendukung Resource Manager.

Untuk komputer virtual, akun penyimpanan, dan jaringan virtual, jika sumber daya dibuat melalui penerapan klasik, Anda harus terus mengoperasikannya melalui operasi klasik. Jika komputer virtual, akun penyimpanan, atau jaringan virtual dibuat melalui penerapan Resource Manager, Anda harus terus menggunakan operasi Resource Manager. Perbedaan ini bisa membingungkan ketika langganan Anda berisi campuran sumber daya yang dibuat melalui penerapan Resource Manager dan klasik. Kombinasi sumber daya ini dapat membuat hasil yang tidak terduga karena sumber daya tidak mendukung operasi yang sama.

Dalam beberapa kasus, perintah Resource Manager dapat mengambil informasi tentang sumber daya yang dibuat melalui penerapan klasik, atau dapat melakukan tugas administratif seperti memindahkan sumber daya klasik ke grup sumber daya lain. Tapi, kasus-kasus ini seharusnya tidak memberikan kesan bahwa jenis tersebut mendukung operasi Resource Manager. Contohnya, misal, Anda memiliki grup sumber daya yang berisi komputer virtual yang dibuat dengan penerapan klasik. Jika Anda menjalankan perintah PowerShell Resource Manager berikut ini:

Get-AzResource -ResourceGroupName ExampleGroup -ResourceType Microsoft.ClassicCompute/virtualMachines

Ini mengembalikan komputer virtual:

Name              : ExampleClassicVM
ResourceId        : /subscriptions/{guid}/resourceGroups/ExampleGroup/providers/Microsoft.ClassicCompute/virtualMachines/ExampleClassicVM
ResourceName      : ExampleClassicVM
ResourceType      : Microsoft.ClassicCompute/virtualMachines
ResourceGroupName : ExampleGroup
Location          : westus
SubscriptionId    : {guid}

Namun, cmdlet Resource Manager Get-AzVM hanya mengembalikan komputer virtual yang diterapkan melalui Resource Manager. Perintah berikut ini tidak mengembalikan komputer virtual yang dibuat melalui penerapan klasik.

Get-AzVM -ResourceGroupName ExampleGroup

Hanya sumber daya yang dibuat melalui tag dukungan Azure Resource Manager. Anda tidak dapat menerapkan tag ke sumber daya klasik.

Perubahan untuk komputasi, jaringan, dan penyimpanan

Diagram berikut menampilkan sumber daya komputasi, jaringan, dan penyimpanan yang diterapkan melalui Resource Manager.

Diagram that shows Resource Manager architecture with SRP, CRP, and NRP.

SRP: Penyedia Sumber Penyimpanan, CRP: Penyedia Sumber Komputasi, NRP: Penyedia Sumber Jaringan

Untuk diagram solusi komputer virtual yang diperbarui yang menggunakan disk terkelola, lihat Menjalankan VM Windows di Azure.

Perhatikan hubungan antar sumber daya berikut:

  • Semua sumber daya ada dalam grup sumber daya.
  • Mesin virtual bergantung pada akun penyimpanan tertentu yang ditentukan dalam penyedia sumber Penyimpanan untuk menyimpan disk-nya dalam penyimpanan blob (diperlukan).
  • Komputer virtual mereferensikan kartu antarmuka jaringan tertentu yang ditentukan dalam penyedia sumber Jaringan (diperlukan) dan set ketersediaan yang ditentukan dalam penyedia sumber Komputasi (opsional).
  • Kartu antarmuka jaringan mereferensikan alamat IP yang ditetapkan komputer virtual (diperlukan), subnet jaringan virtual untuk komputer virtual (diperlukan), dan ke Kelompok Keamanan Jaringan (opsional).
  • Subnet dalam jaringan virtual mereferensikan Kelompok Keamanan Jaringan (opsional).
  • Instans load balancer mereferensikan kumpulan backend alamat IP yang menyertakan kartu antarmuka jaringan komputer virtual (opsional) dan mereferensikan load balancer alamat IP publik atau privat (opsional).

Berikut adalah komponen dan hubungannya pada penerapan klasik:

Diagram that shows classic architecture for hosting a virtual machine.

Solusi klasik untuk menghosting komputer virtual termasuk:

  • Cloud Services (klasik) bertindak sebagai kontainer untuk menghosting komputer virtual (komputasi). Komputer virtual secara otomatis diberikan dengan kartu antarmuka jaringan dan alamat IP yang ditetapkan oleh Azure. Selain itu, layanan cloud berisi instans load balancer eksternal, alamat IP publik, dan titik akhir default untuk memungkinkan lalu lintas desktop jarak jauh dan PowerShell jarak jauh untuk komputer virtual berbasis Windows dan lalu lintas Secure Shell (SSH) untuk komputer virtual berbasis Linux.
  • Akun penyimpanan yang diperlukan yang menyimpan hard disk virtual untuk komputer virtual, termasuk sistem operasi, sementara, dan disk data tambahan (penyimpanan).
  • Jaringan virtual opsional yang bertindak sebagai kontainer tambahan, di mana Anda dapat membuat struktur yang disubnet dan memilih subnet tempat komputer virtual berada (jaringan).

Tabel berikut ini menjelaskan perubahan dalam cara penyedia sumber daya Komputasi, Jaringan, dan Penyimpanan berinteraksi:

Item Klasik Manajer Sumber Daya
Layanan Awan untuk Microsoft Azure Virtual Machines Layanan awan adalah kontainer untuk menahan komputer virtual yang membutuhkan Ketersediaan dari platform dan Load Balancing. Layanan Awan tidak lagi menjadi objek yang diperlukan untuk membuat Komputer Virtual menggunakan model baru.
Virtual Networks Jaringan virtual bersifat opsional untuk komputer virtual. Jika disertakan, jaringan virtual tidak dapat diterapkan dengan Resource Manager. Komputer virtual memerlukan jaringan virtual yang telah diterapkan dengan Resource Manager.
Akun Penyimpanan Komputer virtual memerlukan akun penyimpanan yang menyimpan hard disk virtual untuk sistem operasi, sementara, dan disk data tambahan. Komputer virtual memerlukan akun penyimpanan untuk menyimpan disk-nya dalam penyimpanan blob.
Set ketersediaan Ketersediaan platform ditunjukkan dengan mengonfigurasi "AvailabilitySetName" yang sama di Virtual Machines. Jumlah maksimum domain kesalahan adalah 2. Set Ketersediaan adalah sumber daya yang diekspos oleh Penyedia Microsoft.Compute. Komputer Virtual yang membutuhkan ketersediaan tinggi harus disertakan dalam Set Ketersediaan. Jumlah maksimum domain kesalahan sekarang adalah 3.
Grup Afinitas Grup Afinitas diperlukan untuk membuat Virtual Network. Namun, dengan diperkenalkannya Virtual Network Regional, itu tidak diperlukan lagi. Untuk menyederhanakan, konsep Grup Afinitas tidak ada di API yang diekspos melalui Azure Resource Manager.
Penyeimbangan Beban Pembuatan Layanan Awan menyediakan load balancer implisit untuk Komputer Virtual yang diterapkan. Load Balancer adalah sumber daya yang diekspos oleh penyedia Microsoft.Network. Antarmuka jaringan utama Komputer Virtual yang bebannya perlu diseimbangkan harus mereferensikan load balancer. Load Balancer bisa jadi internal atau eksternal. Instans load balancer mereferensikan kumpulan backend alamat IP yang menyertakan NIC komputer virtual (opsional) dan mereferensikan load balancer alamat IP publik atau privat (opsional).
Alamat IP Virtual Layanan Awan mendapatkan VIP (Alamat IP Virtual) default saat VM ditambahkan ke layanan awan. Alamat IP Virtual adalah alamat yang terkait dengan load balancer implisit. Alamat IP publik adalah sumber daya yang diekspos oleh penyedia Microsoft.Network. Alamat IP publik bisa jadi statis (cadangan) atau dinamis. IP publik dinamis dapat ditetapkan ke Load Balancer. IP Publik dapat diamankan menggunakan Kelompok Keamanan.
Alamat IP yang Dicadangkan Anda dapat mencadangkan Alamat IP di Azure dan mengaitkannya dengan Layanan Awan untuk memastikan bahwa Alamat IP melekat. Alamat IP Publik dapat dibuat dalam mode statis dan menawarkan kemampuan yang sama dengan alamat IP yang dicadangkan.
Alamat IP Publik (PIP) per VM Alamat IP Publik juga dapat dikaitkan dengan VM secara langsung. Alamat IP publik adalah sumber daya yang diekspos oleh penyedia Microsoft.Network. Alamat IP publik bisa jadi statis (cadangan) atau dinamis.
Titik akhir Titik Akhir input perlu dikonfigurasi pada Komputer Virtual untuk membuka konektivitas untuk port tertentu. Salah satu mode umum menghubungkan ke komputer virtual yang dilakukan dengan menyiapkan titik akhir input. Aturan NAT masuk dapat dikonfigurasi pada Load Balancer untuk mencapai kemampuan yang sama dalam mengaktifkan titik akhir pada port tertentu untuk menyambungkan ke VM.
Nama DNS Layanan awan akan mendapatkan Nama DNS implisit yang unik secara global. Sebagai contoh: mycoffeeshop.cloudapp.net. Nama DNS adalah parameter opsional yang dapat ditentukan pada sumber daya Alamat IP Publik. FQDN ada dalam format berikut - <domainlabel>.<region>.cloudapp.azure.com.
Antarmuka Jaringan Antarmuka Jaringan Primer dan Sekunder dan propertinya didefinisikan sebagai konfigurasi jaringan Komputer virtual. Antarmuka Jaringan adalah sumber daya yang diekspos oleh Penyedia Microsoft.Network. Siklus hidup Antarmuka Jaringan tidak terikat dengan Komputer Virtual. Antarmuka Jaringan mereferensikan alamat IP yang ditetapkan komputer virtual (diperlukan), subnet jaringan virtual untuk komputer virtual (diperlukan), dan ke Kelompok Keamanan Jaringan (opsional).

Untuk mempelajari tentang menghubungkan jaringan virtual dari model penyebaran yang berbeda, lihat Sambungkan jaringan virtual dari model penyebaran yang berbeda di portal.

Migrasi dari klasik ke Resource Manager

Jika Anda siap untuk memigrasikan sumber daya Anda dari penyebaran klasik ke penyebaran Resource Manager, lihat:

  1. Pembahasan mendalam teknis tentang migrasi yang didukung platform dari klasik ke Azure Resource Manager
  2. Migrasi sumber daya IaaS yang didukung platform dari Klasik ke Azure Resource Manager
  3. Memigrasikan sumber daya IaaS dari klasik ke Azure Resource Manager dengan menggunakan PowerShell
  4. Memigrasikan sumber daya IaaS dari klasik ke Azure Resource Manager dengan menggunakan Azure CLI

Pertanyaan yang Sering Ditanyakan

Dapatkah saya membuat komputer virtual menggunakan Resource Manager untuk diterapkan dalam jaringan virtual yang dibuat menggunakan penyebaran klasik?

Konfigurasi ini tidak didukung. Anda tidak dapat menggunakan Resource Manager untuk menyebarkan komputer virtual ke jaringan virtual yang dibuat menggunakan penyebaran klasik.

Dapatkah saya membuat komputer virtual menggunakan Resource Manager dari gambar pengguna yang dibuat menggunakan model penyebaran klasik?

Konfigurasi ini tidak didukung. Namun, Anda dapat menyalin file hard disk virtual dari akun penyimpanan yang dibuat menggunakan model penyebaran klasik, dan menambahkannya ke akun baru yang dibuat melalui Resource Manager.

Apa dampak pada kuota langganan saya?

Kuota untuk komputer virtual, jaringan virtual, dan akun penyimpanan yang dibuat melalui Azure Resource Manager terpisah dari kuota lainnya. Setiap langganan mendapatkan kuota untuk membuat sumber daya menggunakan API baru. Anda dapat membaca lebih lanjut tentang kuota tambahan di sini.

Dapatkah saya terus menggunakan skrip otomatis saya untuk provisi komputer virtual, jaringan virtual, dan akun penyimpanan melalui API Resource Manager?

Semua otomatisasi dan skrip yang Telah Anda buat terus berfungsi untuk komputer virtual yang ada, jaringan virtual yang dibuat di bawah mode Manajemen Layanan Azure. Namun, skrip harus diperbarui untuk menggunakan skema baru untuk membuat sumber daya yang sama melalui mode Resource Manager.

Di mana saya bisa menemukan contoh template Azure Resource Manager?

Set template pemula yang komprehensif dapat ditemukan di Template Mulai Cepat Azure Resource Manager.

Langkah berikutnya