Menyebarkan kluster SQL Server Big Data dalam mode Direktori Aktif

Artikel ini menjelaskan cara menyebarkan SQL Server Big Data Cluster dalam mode Direktori Aktif. Langkah-langkah dalam artikel ini memerlukan akses ke domain Direktori Aktif. Sebelum melanjutkan, Anda perlu menyelesaikan persyaratan yang dijelaskan dalam Menyebarkan SQL Server Kluster Big Data dalam mode Direktori Aktif.

Penting

Add-on Kluster Big Data Microsoft SQL Server 2019 akan dihentikan. Dukungan untuk Kluster Big Data SQL Server 2019 akan berakhir pada 28 Februari 2025. Semua pengguna SQL Server 2019 yang ada dengan Jaminan Perangkat Lunak akan didukung penuh pada platform dan perangkat lunak akan terus dipertahankan melalui pembaruan kumulatif SQL Server hingga saat itu. Untuk informasi selengkapnya, lihat posting blog pengumuman dan opsi Big data di platform Microsoft SQL Server.

Menyiapkan penyebaran

Untuk penyebaran kluster big data dengan integrasi AD, ada beberapa informasi tambahan yang perlu disediakan untuk membuat objek terkait kluster big data di AD.

Dengan menggunakan kubeadm-prod profil (atau openshift-prod dimulai dengan rilis CU5), Anda akan secara otomatis memiliki tempat penampung untuk informasi terkait keamanan dan informasi terkait titik akhir yang diperlukan untuk integrasi AD.

Selain itu, Anda perlu memberikan kredensial yang akan digunakan Kluster Big Data untuk membuat objek yang diperlukan dalam AD. Kredensial ini disediakan sebagai variabel lingkungan.

Lalu lintas dan port

Verifikasi bahwa firewall atau aplikasi pihak ketiga mengizinkan port yang diperlukan untuk komunikasi Direktori Aktif.

Diagram lalu lintas antara Kluster Big Data dan Direktori Aktif. Pengontrol, Layanan Dukungan Keamanan, dan Layanan Kluster Lainnya berbicara melalui LDAP / Kerberos ke Pengendali Domain. Layanan Proksi Kluster Big Data DNS berbicara melalui DNS ke Server DNS.

Permintaan dibuat pada protokol ini ke dan dari layanan kluster Kubernetes ke domain Direktori Aktif, sehingga harus diizinkan masuk dan keluar di firewall atau aplikasi pihak ketiga apa pun yang mendengarkan port yang diperlukan untuk TCP dan UDP. Nomor port standar yang digunakan Direktori Aktif:

Layanan Port
DNS 53
LDAP
LDAPS
389
636
Kerberos 88
Protokol Perubahan Kata Sandi Kerberos/AD 464
Port Katalog Global
melalui LDAP
melalui LDAPS

3268
3269

Mengatur variabel lingkungan keamanan

Variabel lingkungan berikut memberikan kredensial untuk akun layanan domain Kluster Big Data, yang akan digunakan untuk menyiapkan integrasi AD. Akun ini juga digunakan oleh Kluster Big Data untuk mempertahankan objek AD terkait ke depannya.

export DOMAIN_SERVICE_ACCOUNT_USERNAME=<AD principal account name>
export DOMAIN_SERVICE_ACCOUNT_PASSWORD=<AD principal password>

Menyediakan parameter keamanan dan titik akhir

Selain variabel lingkungan untuk kredensial, Anda juga perlu memberikan informasi keamanan dan titik akhir agar integrasi AD berfungsi. Parameter yang diperlukan secara otomatis merupakan bagian kubeadm-prod/openshift-prod dari profil penyebaran.

Integrasi AD memerlukan parameter berikut. Tambahkan parameter ini ke control.json file dan bdc.json menggunakan config replace perintah yang ditunjukkan lebih lanjut di artikel ini. Semua contoh di bawah ini menggunakan domain contoso.localcontoh .

  • security.activeDirectory.ouDistinguishedName: nama khusus unit organisasi (OU) di mana semua akun AD yang dibuat oleh penyebaran kluster akan ditambahkan. Jika domain disebut contoso.local, nama yang dibedakan unit organisasi adalah: OU=BDC,DC=contoso,DC=local.

  • security.activeDirectory.dnsIpAddresses: berisi daftar alamat IP server DNS domain.

  • security.activeDirectory.domainControllerFullyQualifiedDns: Daftar FQDN pengendali domain. FQDN berisi nama komputer/host pengendali domain. Jika Anda memiliki beberapa pengontrol domain, Anda bisa menyediakan daftar di sini. Contoh: HOSTNAME.CONTOSO.LOCAL.

    Penting

    Saat beberapa pengendali domain melayani domain, gunakan pengendali domain utama (PDC) sebagai entri pertama dalam domainControllerFullyQualifiedDns daftar dalam konfigurasi keamanan. Untuk mendapatkan nama PDC, ketik netdom query fsmo, pada prompt perintah, lalu tekan ENTER.

  • security.activeDirectory.realmParameter opsional: Dalam sebagian besar kasus, realm sama dengan nama domain. Untuk kasus di mana mereka tidak sama, gunakan parameter ini untuk menentukan nama realm (misalnya, CONTOSO.LOCAL). Nilai yang disediakan untuk parameter ini harus sepenuhnya memenuhi syarat.

  • security.activeDirectory.netbiosDomainNameParameter opsional: Ini adalah nama NETBIOS dari domain AD. Dalam kebanyakan kasus, ini akan menjadi label pertama dari nama domain AD. Untuk kasus yang berbeda, gunakan parameter ini untuk menentukan nama domain NETBIOS. Nilai ini tidak boleh berisi titik apa pun. Biasanya nama ini digunakan untuk memenuhi syarat akun pengguna di domain. Misalnya, CONTOSO\user, di mana CONTOSO adalah nama domain NETBIOS.

    Catatan

    Dukungan untuk konfigurasi di mana nama domain Direktori Aktif berbeda dari nama NETBIOS domain Direktori Aktif menggunakan security.activeDirectory.netbiosDomainName diaktifkan dimulai dengan SQL Server 2019 CU9.

  • security.activeDirectory.domainDnsName: Nama domain DNS Anda yang akan digunakan untuk kluster (misalnya, contoso.local).

  • security.activeDirectory.clusterAdmins: Parameter ini mengambil satu grup AD. Cakupan grup AD harus universal atau global. Anggota grup ini akan memiliki bdcAdmin peran kluster yang akan memberi mereka izin administrator dalam kluster. Ini berarti bahwa mereka memiliki sysadmin izin di SQL Server, superuser izin dalam HDFS, dan izin admin saat tersambung ke titik akhir pengontrol.

    Penting

    Buat grup ini di AD sebelum penyebaran dimulai. Jika cakupan untuk grup AD ini adalah penyebaran lokal domain gagal.

  • security.activeDirectory.clusterUsers: Daftar grup AD yang merupakan pengguna reguler (tanpa izin administrator) di kluster big data. Daftar ini dapat mencakup grup AD yang terlingkup sebagai grup universal atau global. Mereka tidak boleh menjadi grup lokal domain.

Grup AD dalam daftar ini dipetakan ke bdcUser peran kluster big data dan mereka perlu diberikan akses ke SQL Server (lihat izin SQL Server) atau HDFS (lihat Panduan izin HDFS). Saat tersambung ke titik akhir pengontrol, pengguna ini hanya dapat mencantumkan titik akhir yang tersedia di kluster menggunakan azdata bdc endpoint list perintah .

Untuk detail tentang cara memperbarui grup AD untuk pengaturan ini lihat Mengelola akses Kluster Big Data dalam mode Direktori Aktif.

Tip

Untuk mengaktifkan pengalaman penjelajahan HDFS saat terhubung ke master SQL Server di Azure Data Studio, pengguna dengan peran bdcUser harus diberikan izin VIEW SERVER STATE karena studio Data Azure menggunakan sys.dm_cluster_endpoints DMV untuk mendapatkan titik akhir gateway Knox yang diperlukan untuk terhubung ke HDFS.

Penting

Buat grup ini di AD sebelum penyebaran dimulai. Jika cakupan untuk salah satu grup AD ini adalah penyebaran lokal domain gagal.

Penting

Jika pengguna domain Anda memiliki sejumlah besar keanggotaan grup, Anda harus menyesuaikan nilai untuk pengaturan httpserver.requestHeaderBuffer gateway (nilai defaultnya adalah 8192) dan pengaturan hadoop.security.group.mapping.ldap.search.group.hierarchy.levels HDFS (nilai defaultnya adalah 10), menggunakan file konfigurasi penyebaran bdc.json kustom. Ini adalah praktik terbaik untuk menghindari batas waktu koneksi ke gateway dan/atau respons HTTP dengan kode status 431 (Bidang Header Permintaan Terlalu Besar). Berikut adalah bagian dari file konfigurasi yang menunjukkan cara menentukan nilai pengaturan ini dan apa nilai yang direkomendasikan untuk jumlah keanggotaan grup yang lebih tinggi:

{
    ...
    "spec": {
        "resources": {
            ...
            "gateway": {
                "spec": {
                    "replicas": 1,
                    "endpoints": [{...}],
                    "settings": {
                        "gateway-site.gateway.httpserver.requestHeaderBuffer": "65536"
                    }
                }
            },
            ...
        },
        "services": {
            ...
            "hdfs": {
                "resources": [...],
                "settings": {
                  "core-site.hadoop.security.group.mapping.ldap.search.group.hierarchy.levels": "4"
                }
            },
            ...
        }
    }
}
  • security.activeDirectory.enableAES Optional parameterParameter opsional: Nilai Boolean yang menunjukkan apakah AES 128 dan AES 256 harus diaktifkan pada akun AD yang dihasilkan secara otomatis. Nilai defaultnya adalah false. Ketika parameter ini diatur ke true, bendera berikut 'Akun ini mendukung enkripsi Kerberos AES 128 bit' dan 'Akun ini mendukung enkripsi Kerberos AES 256 bit' akan diperiksa pada objek AD yang dibuat secara otomatis selama penyebaran kluster big data.

Catatan

Parameter security.activeDirectory.enableAES tersedia dimulai dengan SQL Server Kluster Big Data CU13. Jika kluster big data adalah versi sebelum CU13, langkah-langkah berikut diperlukan:

  1. azdata bdc rotate -n <your-cluster-name> Jalankan perintah , perintah ini akan memutar tab kunci di kluster yang diperlukan untuk memastikan bahwa entri AES dalam tab kunci sudah benar. Untuk informasi selengkapnya, lihat azdata bdc. Selain itu, azdata bdc rotate akan memutar kata sandi objek AD yang dibuat secara otomatis selama penyebaran awal di unit organisasi yang ditentukan.
  2. Atur bendera berikut 'Akun ini mendukung enkripsi Kerberos AES 128 bit' dan 'Akun ini mendukung enkripsi Kerberos AES 256 bit' pada setiap objek AD yang dibuat secara otomatis di OU yang Anda berikan selama penyebaran kluster big data awal. Ini dapat dicapai dengan menjalankan skrip Get-ADUser -Filter * -SearchBase '<OU Path>' | Set-ADUser -replace @{ 'msDS-SupportedEncryptionTypes' = '24' } PowerShell berikut pada pengendali domain Anda yang mengatur bidang AES pada setiap akun dalam unit organisasi yang diberikan dalam <OU Path> parameter.

Penting

Buat grup yang disediakan untuk pengaturan di bawah ini di AD sebelum penyebaran dimulai. Jika cakupan untuk salah satu grup AD ini adalah penyebaran lokal domain gagal.

  • security.activeDirectory.appOwnersParameter opsional: Daftar grup AD yang memiliki izin untuk membuat, menghapus, dan menjalankan aplikasi apa pun. Daftar ini dapat mencakup grup AD yang terlingkup sebagai grup universal atau global. Mereka tidak boleh menjadi grup lokal domain.

  • security.activeDirectory.appReadersParameter opsional: Daftar grup AD yang memiliki izin untuk menjalankan aplikasi apa pun. Daftar ini dapat mencakup grup AD yang terlingkup sebagai grup universal atau global. Mereka tidak boleh menjadi grup lokal domain.

Tabel di bawah ini memperlihatkan model otorisasi untuk manajemen aplikasi:

Peran yang diotorisasi Perintah Azure Data CLI (azdata)
appOwner buat aplikasi azdata
appOwner pembaruan aplikasi azdata
appOwner, appReader daftar aplikasi azdata
appOwner, appReader azdata app describe
appOwner azdata app delete
appOwner, appReader azdata app run
  • security.activeDirectory.subdomain: Parameter opsional Parameter ini diperkenalkan dalam rilis CU5 SQL Server 2019 untuk mendukung penyebaran beberapa kluster big data terhadap domain yang sama. Dengan menggunakan pengaturan ini, Anda dapat menentukan nama DNS yang berbeda untuk setiap kluster big data yang disebarkan. Jika nilai parameter ini tidak ditentukan di bagian direktori aktif file control.json , secara default, nama kluster big data (sama dengan nama namespace Layanan Kube) akan digunakan untuk menghitung nilai pengaturan subdomain.

    Catatan

    Nilai yang diteruskan melalui pengaturan subdomain bukan domain AD baru tetapi hanya domain DNS yang digunakan oleh kluster big data secara internal.

    Penting

    Anda perlu menginstal atau meningkatkan versi terbaru Azure Data CLI (azdata) pada rilis CU5 SQL Server 2019 untuk memanfaatkan kemampuan baru ini dan menyebarkan beberapa kluster big data di domain yang sama.

    Lihat Konsep: menyebarkan SQL Server Kluster Big Data dalam mode Direktori Aktif untuk detail selengkapnya mengenai penyebaran beberapa kluster big data di domain Direktori Aktif yang sama.

  • security.activeDirectory.accountPrefix: Parameter opsional Parameter ini diperkenalkan dalam rilis CU5 SQL Server 2019 untuk mendukung penyebaran beberapa kluster big data terhadap domain yang sama. Pengaturan ini menjamin keunikan nama akun untuk berbagai layanan kluster big data, yang harus berbeda antara dua kluster. Menyesuaikan nama awalan akun bersifat opsional, secara default, nama subdomain digunakan sebagai awalan akun. Jika nama subdomain lebih panjang dari 12 karakter, 12 karakter pertama dari nama subdomain digunakan sebagai awalan akun. 

    Catatan

    Direktori Aktif mengharuskan nama akun dibatasi hingga 20 karakter. Kluster big data perlu menggunakan 8 karakter untuk membedakan pod dan StatefulSets. Ini membuat kita 12 karakter sebagai batas untuk awalan akun

Periksa cakupan grup AD, untuk menentukan apakah itu DomainLocal.

Jika Anda belum menginisialisasi file konfigurasi penyebaran, Anda dapat menjalankan perintah ini untuk mendapatkan salinan konfigurasi. Contoh di bawah ini menggunakan kubeadm-prod profil , hal yang sama berlaku untuk openshift-prod.

azdata bdc config init --source kubeadm-prod  --target custom-prod-kubeadm

Untuk mengatur parameter di atas dalam control.json file, gunakan perintah Azure Data CLI (azdata) berikut. Perintah menggantikan konfigurasi dan memberikan nilai Anda sendiri sebelum penyebaran.

Penting

Dalam rilis CU2 SQL Server 2019, struktur bagian konfigurasi keamanan di profil penyebaran berubah sedap dipandang dan semua pengaturan terkait Direktori Aktif berada dalam yang baru activeDirectory di pohon json di bawah security dalam control.json file.

Catatan

Selain memberikan nilai yang berbeda untuk subdomain seperti yang dijelaskan di bagian ini, Anda juga harus menggunakan nomor port yang berbeda untuk titik akhir Kluster Big Data saat menyebarkan beberapa kluster big data di kluster Kubernetes yang sama. Nomor port ini dapat dikonfigurasi pada waktu penyebaran melalui profil konfigurasi penyebaran .

Contoh di bawah ini didasarkan pada penggunaan SQL Server 2019 CU2. Ini menunjukkan cara mengganti nilai parameter terkait AD dalam konfigurasi penyebaran. Detail domain di bawah ini adalah contoh nilai.

azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.ouDistinguishedName=OU\=bdc\,DC\=contoso\,DC\=local"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.dnsIpAddresses=[\"10.100.10.100\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.domainControllerFullyQualifiedDns=[\"HOSTNAME.CONTOSO.LOCAL\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.domainDnsName=contoso.local"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.clusterAdmins=[\"bdcadminsgroup\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.clusterUsers=[\"bdcusersgroup\"]"
#Example for providing multiple clusterUser groups: [\"bdcusergroup1\",\"bdcusergroup2\"]

Secara opsional, hanya mulai SQL Server rilis CU5 2019, Anda dapat mengganti nilai default untuk subdomain pengaturan dan accountPrefix .

azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.subdomain=[\"bdctest\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.accountPrefix=[\"bdctest\"]"

Demikian pula, dalam rilis sebelum SQL Server 2019 CU2, Anda dapat menjalankan:

azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.ouDistinguishedName=OU\=bdc\,DC\=contoso\,DC\=local"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.dnsIpAddresses=[\"10.100.10.100\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.domainControllerFullyQualifiedDns=[\"HOSTNAME.CONTOSO.LOCAL\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.domainDnsName=contoso.local"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.clusterAdmins=[\"bdcadminsgroup\"]"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.clusterUsers=[\"bdcusersgroup\"]"
#Example for providing multiple clusterUser groups: [\"bdcusergroup1\",\"bdcusergroup2\"]

Selain informasi di atas, Anda juga perlu memberikan nama DNS untuk titik akhir kluster yang berbeda. Entri DNS yang menggunakan nama DNS yang Anda berikan akan secara otomatis dibuat di Server DNS Anda saat penyebaran. Anda akan menggunakan nama-nama ini saat menyambungkan ke titik akhir kluster yang berbeda. Misalnya, jika nama DNS untuk instans master SQL adalah mastersql dan mempertimbangkan subdomain akan menggunakan nilai default nama kluster di control.json, Anda akan menggunakan mastersql.contoso.local,31433 atau mastersql.mssql-cluster.contoso.local,31433 (tergantung pada nilai yang Anda berikan dalam file konfigurasi penyebaran untuk nama DNS titik akhir) untuk menyambungkan ke instans master dari alat.

# DNS names for Big Data Clusters services
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.spec.endpoints[0].dnsName=<controller DNS name>.contoso.local"
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.spec.endpoints[1].dnsName=<monitoring services DNS name>.<Domain name. e.g. contoso.local>"
azdata bdc config replace -c custom-prod-kubeadm/bdc.json -j "$.spec.resources.master.spec.endpoints[0].dnsName=<SQL Master Primary DNS name>.<Domain name. e.g. contoso.local>"
azdata bdc config replace -c custom-prod-kubeadm/bdc.json -j "$.spec.resources.master.spec.endpoints[1].dnsName=<SQL Master Secondary DNS name>.<Domain name. e.g. contoso.local>"
azdata bdc config replace -c custom-prod-kubeadm/bdc.json -j "$.spec.resources.gateway.spec.endpoints[0].dnsName=<Gateway (Knox) DNS name>.<Domain name. e.g. contoso.local>"
azdata bdc config replace -c custom-prod-kubeadm/bdc.json -j "$.spec.resources.appproxy.spec.endpoints[0].dnsName=<app proxy DNS name>.<Domain name. e.g. contoso.local>"

Penting

Anda dapat menggunakan nama DNS titik akhir pilihan Anda selama sepenuhnya memenuhi syarat dan tidak bertentangan antara dua kluster big data yang disebarkan di domain yang sama. Secara opsional, Anda dapat menggunakan subdomain nilai parameter untuk memastikan nama DNS berbeda di seluruh kluster. Contohnya:

# DNS names for Big Data Clusters services
azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.spec.endpoints[0].dnsName=<controller DNS name>.<subdomain e.g. mssql-cluster>.contoso.local"

Anda dapat menemukan contoh skrip di sini untuk menyebarkan kluster SQL Server big data pada kluster Kubernetes node tunggal (kubeadm) dengan integrasi AD.

Catatan

Mungkin ada skenario di mana Anda tidak dapat mengakomodasi parameter yang baru diperkenalkan subdomain . Misalnya, Anda harus menyebarkan rilis pra-CU5 dan Anda sudah meningkatkan Azure Data CLI (azdata). Ini sangat tidak mungkin, tetapi jika Anda perlu kembali ke perilaku pra-CU5, Anda dapat mengatur useSubdomain parameter ke false di bagian direktori aktif dari control.json. Berikut adalah perintah untuk melakukannya:

azdata bdc config replace -c custom-prod-kubeadm/control.json -j "$.security.activeDirectory.useSubdomain=false"

Anda sekarang harus mengatur semua parameter yang diperlukan untuk penyebaran Kluster Big Data dengan integrasi Direktori Aktif.

Anda sekarang dapat menyebarkan kluster big data yang terintegrasi dengan Active Directory menggunakan perintah Azure Data CLI (azdata) dan profil penyebaran kubeadm-prod. Untuk dokumentasi lengkap tentang cara menyebarkan Kluster Big Data, lihat Cara menyebarkan SQL Server Kluster Big Data di Kubernetes.

Memverifikasi entri DNS terbalik untuk pengendali domain

Pastikan bahwa ada entri DNS terbalik (catatan PTR) untuk pengendali domain itu sendiri, yang terdaftar di server DNS. Anda dapat memverifikasi ini dengan menjalankan nslookup alamat IP pengendali domain, untuk melihat bahwa itu dapat diselesaikan ke FQDN pengendali domain.

Masalah dan batasan yang diketahui

Batasan yang harus diperhatikan dalam SQL Server 2019 CU5

  • Saat ini, Dasbor Pencarian Log dan Dasbor Metrik tidak mendukung autentikasi AD. Nama pengguna dan kata sandi dasar yang ditetapkan saat penyebaran dapat digunakan untuk autentikasi ke dasbor ini. Semua titik akhir kluster lainnya mendukung autentikasi AD.

  • Mode AD aman hanya akan berfungsi pada kubeadm lingkungan penyebaran dan openshift bukan di AKS atau ARO saat ini. Profil kubeadm-prod penyebaran dan openshift-prod menyertakan bagian keamanan secara default.

  • Sebelum SQL Server rilis CU5 2019, hanya satu kluster big data per domain (Direktori Aktif) yang diizinkan. Mengaktifkan beberapa kluster big data per domain tersedia dimulai dengan rilis CU5.

  • Tidak ada grup AD yang ditentukan dalam konfigurasi keamanan yang dapat dicakup DomainLocal. Anda dapat memeriksa cakupan grup AD dengan mengikuti instruksi ini.

  • Akun AD yang dapat digunakan untuk masuk ke kluster big data diizinkan dari domain yang sama yang dikonfigurasi untuk SQL Server Kluster Big Data. Mengaktifkan login dari domain tepercaya lainnya tidak didukung.

Langkah berikutnya

Menyambungkan SQL Server Kluster Big Data: Mode Direktori Aktif

Memecahkan masalah SQL Server integrasi Direktori Aktif Kluster Big Data

Konsep: menyebarkan SQL Server Kluster Big Data dalam mode Direktori Aktif