Skenario 1 - Arsitek berskala global dan akses aman
Di pelajaran sebelumnya, Anda mengerjakan skenario tentang skala global untuk jaringan pengiriman konten. Di pelajaran ini, Anda akan mengulas satu solusi potensial dan beberapa item untuk dipertimbangkan.
Saat mengulas, Anda harus membandingkan solusi yang disediakan dengan yang Anda kembangkan di pelajaran sebelumnya. Sering kali, terdapat ebih dari satu solusi yang benar untuk masalah apa pun, tetapi selalu ada tradeoff. Item mana dalam solusi Anda yang berbeda dari yang diusulkan? Adakah hal dalam solusi Anda yang perlu dipikirkan kembali? Adakah hal dalam solusi yang tersedia yang menurut Anda bertujuan secara lebih menyeluruh dalam solusi Anda?
Opsi dan konfigurasi penyebaran
Keputusan pertama yang perlu dipertimbangkan adalah opsi penyebaran Azure SQL mana yang harus Anda pilih. Meskipun SQL Server dalam komputer virtual Azure (VM) akan berfungsi, PaaS mungkin memberikan kesesuaian yang lebih baik dengan overhead manajemen yang lebih sedikit.
Pelanggan menggunakan runtime bahasa umum (CLR), yang merupakan fitur cakupan instans. Azure SQL Managed Instance adalah satu-satunya opsi penyebaran PaaS yang mendukung fitur cakupan instans seperti CLR, Broker Layanan, dan Email Database. Untuk alasan ini, Azure SQL Managed Instance dapat memungkinkan pelanggan untuk pindah ke penawaran PaaS tanpa harus meregenerasi aplikasi CLR-nya menjadi solusi yang kompatibel dengan Azure SQL Database (seperti pekerjaan database elastis).
Keputusan berikutnya yang harus dibuat melibatkan tingkat layanan. Karena pelanggan ingin mengisolasi beban kerja baca dan tulisnya, menggunakan tingkat layanan Business Critical akan menjadi cara paling sederhana untuk mencapainya. Tingkat layanan Business Critical memiliki grup ketersediaan Always On yang berjalan di belakang layar. Salah satu replika sekunder tersebut dapat digunakan untuk beban kerja baca-saja.
Business Critical hanya setengah dari konfigurasi di sini untuk memisahkan beban kerja baca dan tulis. Skenario menyatakan bahwa pelanggan harus dapat menskalakan lebih dari beberapa wilayah dengan beberapa kueri terjadi pada saat yang sama, sambil mengisolasi beban kerja baca dan tulis.
Dua opsi yang berpotensi mengatasi tantangan ini adalah grup replikasi geografis dan kegagalan otomatis. Namun, replikasi geografis saat ini tidak didukung di Azure SQL Managed Instance. Oleh karena itu, menggunakan grup kegagalan otomatis adalah satu-satunya opsi yang dapat membantu skenario ini dalam mendapatkan skala baca global.
Karena pelanggan menggunakan grup kegagalan otomatis, seberapa perlu tingkat layanan Business Critical akan tergantung pada berapa banyak titik akhir baca-saja yang diperlukan beban kerja analitiknya. Dengan grup kegagalan otomatis di tingkat layanan Business Critical, pelanggan akan mendapatkan tiga titik akhir yang dapat dibaca:
- Satu replika sekunder berasal dari grup ketersediaan wilayah utama
- Sekunder dari grup kegagalan (yang merupakan replika utama database di wilayah sekunder)
- Satu replika sekunder berasal dari grup ketersediaan wilayah utama
Jika beban kerja analitik tidak memerlukan semua replika yang dapat dibaca ini, menggunakan Tujuan Umum mungkin merupakan solusi yang lebih hemat biaya.
Memilih metode autentikasi yang paling tepat
Bagian lain dari skenario ini melibatkan penentuan cara terbaik bagi setiap aplikasi atau orang untuk terhubung ke solusi, mengingat kebutuhan untuk membuat dan menggunakan teknologi yang paling aman. Jika Anda menguraikan skenario, empat klien terpisah akan memerlukan akses ke Azure SQL Managed Instance:
- Aplikasi yang berjalan pada Azure VM
- Aplikasi pada komputer non-Azure yang tergabung dengan domain
- DBAs atau pengguna lain alat admin SQL (SQL Server Management Studio, Azure Data Studio, PowerShell) dari komputer non-Azure yang tidak tergabung dengan domain
- Aplikasi lama yang berjalan pada komputer non-Azure yang tidak memungkinkan Anda untuk mengubah driver atau string koneksi
Mari kita lihat klien ini dalam hal bagaimana Anda dapat memilih metode autentikasi dan beberapa pertimbangan dan batasan tambahan.
Aplikasi yang berjalan pada Azure VM
Identitas terkelola untuk sumber daya Azure, secara umum, adalah bentuk autentikasi tanpa kata sandi yang direkomendasikan untuk aplikasi yang berjalan di komputer virtual Azure.
Aplikasi pada komputer non-Azure yang tergabung dengan domain
Untuk kompueter non-Azure, menggunakan identitas terkelola bukanlah pilihan. Autentikasi terintegrasi melalui ID Microsoft Entra adalah metode autentikasi yang direkomendasikan untuk aplikasi yang berjalan pada komputer yang bergabung dengan domain di luar Azure, dengan asumsi bahwa domain telah digabungkan dengan ID Microsoft Entra.
Jika komputer non-Azure tidak tergabung dengan domain, Anda bisa:
- Buat identitas aplikasi untuk aplikasi Anda di ID Microsoft Entra.
- Mengaitkan sertifikat dengan identitas aplikasi.
- Mengubah aplikasi Anda untuk memperoleh token untuk Azure SQL Database dengan memberikan ID klien dan sertifikat.
Meskipun sertifikat harus berisi kunci pribadi dan harus disebarkan pada komputer yang menghosting aplikasi Anda, Anda setidaknya menghindari hard-coding rahasia aplikasi dalam kode aplikasi atau konfigurasi. (Anda harus mengonfigurasikan aplikasi dengan thumbprint sertifikat.)
DBAs atau pengguna lain alat admin SQL dari komputer non-Azure yang tidak bergabung dengan domain
Untuk pengguna di luar Azure, menghilangkan penggunaan kata sandi adalah yang terbaik jika memungkinkan. Anda dapat menghilangkan penggunaan kata sandi dengan alat SQL dengan menggunakan autentikasi terintegrasi Microsoft Entra. Namun, alat harus berjalan pada komputer yang bergabung dengan domain, dan domain harus digabungkan dengan ID Microsoft Entra, yang tidak terjadi untuk skenario ini.
Karena lingkungan tidak memenuhi prasyarat untuk autentikasi terintegrasi, kami sarankan Anda menggunakan autentikasi interaktif Microsoft Entra dengan autentikasi multifaktor, yang didukung sebagian besar alat SQL.
Aplikasi lama yang berjalan pada komputer non-Azure yang tidak memungkinkan Anda untuk mengubah driver atau string koneksi
Dalam skenario ketika driver atau string koneksi tidak dapat diubah, opsi untuk menghilangkan kata sandi tidak ada hari ini. Aplikasi lama ini harus terus menggunakan autentikasi SQL. Anda mungkin mempertimbangkan untuk mempelajari lebih detail terkait pembatasan dan cara untuk mencabut batasan agar dapat menggunakan pendekatan yang lebih aman dan terlindungi bagi aplikasi untuk mengautentikasi.