SQL Server Always On Availability Groups adalah teknologi terbaru Microsoft untuk memenuhi kebutuhan High Availability dan Disaster Recovery organisasi yang menggunakan SQL Server. Satu keuntungan besar dari AlwaysOn adalah kemampuan untuk menangani HA dan DR dalam satu implementasi. Kami merasakan manfaat utama AlwaysOn berikut:
Kami dapat mengelompokkan database terkait sebagai bagian dari Grup Ketersediaan tunggal dan menggabungkannya ke failover jika diperlukan. Ini sangat berguna untuk aplikasi yang bergantung pada lebih dari satu database, seperti Microsoft Office SharePoint, Microsoft Lync, dan Sage.
Bila dibandingkan dengan Instance Cluster Failover SQL Server, kami menemukan bahwa penyimpanan sebagai satu titik kegagalan telah dihilangkan karena setiap instance yang merupakan replika diberikan penyimpanannya sendiri.
Dengan AlwaysOn, dimungkinkan untuk mengonfigurasi HA dan DR sekaligus. Ini dicapai dengan membuat Kluster Failover Windows Multi-situs sebagai dasar dari konfigurasi AlwaysOn Anda. Melakukan Pergantian Peran saat menggunakan AlwaysOn jauh lebih sederhana daripada melakukannya saat menggunakan Pengiriman Log Transaksi.
Objek Komputer
Active Directory (AD) adalah topik besar dan kami tidak akan membahas detailnya di artikel ini. Seperti yang bisa Anda tebak, Active Directory adalah layanan direktori Microsoft. Dalam istilah jaringan komputer, layanan direktori adalah fasilitas yang memungkinkan kita untuk mendaftar, mengidentifikasi, dan mengelola semua objek dalam jaringan secara terpusat. Entri dalam layanan direktori memetakan nama perangkat jaringan ke Alamat IP yang sesuai dan properti lain di direktori. Objek yang paling umum dalam layanan direktori (dan di Microsoft AD) adalah Pengguna dan Komputer. Sama seperti setiap pengguna di domain dapat didaftarkan dan dikelola dari Active Directory, setiap komputer di domain juga dapat dikelola dari Active Directory. Sama seperti setiap pengguna diharapkan memiliki akun unik di Active Directory, demikian juga setiap komputer.
Dalam Active Directory, tidak semua Objek Komputer dipetakan ke komputer fisik. Objek Komputer dapat mewakili komputer fisik (stasiun kerja atau server) tetapi juga dapat mewakili sesuatu yang bertindak seperti komputer seperti nama perwakilan untuk Cluster Windows atau nama virtual untuk Layanan Cluster (Peran). Representasi seperti itu juga unik di Active Directory seperti nama komputer biasa.
CNO dan VNO di WSFC
Saat Anda menginstal Windows Failover Cluster, penginstal membuat entitas di Direktori Aktif yang disebut Objek Nama Komputer (CNO). CNO ini adalah entitas utama yang dibuat di Active Directory untuk cluster dan mewakili "Nama Server" dari seluruh cluster. Selanjutnya, objek lain yang dikenal sebagai Objek Nama Virtual dibuat oleh CNO saat melakukan aktivitas seperti membuat Peran Cluster, Grup Ketersediaan, atau Pendengar Grup Ketersediaan . CNO dan VNO ini memiliki Alamat IP yang terkait dengannya. Anda dapat menentukan alamat ini saat menginstal cluster atau membuat peran Cluster baru atau Listener. Untuk setiap cluster, role, dan listener yang Anda buat, Anda memerlukan nama komputer yang unik dan Alamat IP yang unik. Gbr. 1 menunjukkan langkah di mana Anda menentukan Objek Nama Cluster dan Alamat IP-nya saat mengonfigurasi sebuah cluster.
Nama yang Anda gunakan saat mengonfigurasi kluster benar-benar arbitrer. Mereka hanya perlu menjadi unik. Namun, disarankan untuk mengikuti konvensi penamaan organisasi Anda untuk komputer biasa saat membuat CNO atau VNO – ini membantu pengelolaan lebih mudah. Masuk akal juga untuk menggunakan blok Alamat IP tertentu yang akan mencakup semua kebutuhan pengalamatan untuk seluruh cluster Anda – CNO dan semua VNO (peran) yang ingin Anda buat.
Gbr. 1 Pemetaan Nama ke Alamat dalam Cluster
Izin Domain Utama
DBA atau Admin Sistem yang melakukan instalasi cluster harus memiliki izin untuk Membuat Objek Komputer dalam domain Direktori Aktif. Pada gilirannya, setelah membuat Objek Nama Komputer, administrator domain harus memberikan izin berikut ke Objek Nama Komputer sehingga peran (yang menghasilkan Objek Nama Virtual) dapat berhasil dibuat di Cluster:
Buat Objek Komputer
Baca Semua Properti
Tanpa izin ini, Anda mungkin mendapatkan pesan kesalahan yang serupa dengan yang di bawah ini saat mencoba membuat peran (dalam kasus AlwaysOn FCI ) atau Pendengar (dalam kasus AlwaysOn AG ):
Error selama instalasi MS SQL Server Cluster:
Sumber daya nama jaringan cluster 'Nama Jaringan SQL (EUK-SCCM-01)' gagal membuat objek komputer terkaitnya di domain 'domainname.com' karena alasan berikut:Tidak dapat membuat akun komputer.
Teks untuk kode kesalahan terkait adalah:Akses ditolak.
Pesan kesalahan ini diamati di Peraga Peristiwa karena SQL Server tidak dapat diakses saat ini. Anda juga akan dapat melihat ini jika Anda menavigasi ke file SQL Error Log di folder LOG yang berada di direktori instalasi SQL Server. Frasa kuncinya adalah “Akses Ditolak ”.
Persyaratan Lainnya
Saya harus menyebutkan konsep Pengontrol Domain. Kontroler domain, atau lebih tepatnya, satu set pengontrol domain menyediakan layanan utama untuk Direktori Aktif seperti mendaftarkan objek dan mengotentikasi pengguna dan komputer. Agar berhasil mengkonfigurasi cluster atau AlwaysOn Listener, pengontrol domain harus dapat dijangkau dari komputer tempat Anda melakukan konfigurasi. Ini berarti komunikasi dari komputer ke pengontrol domain harus dibuka pada berbagai port TCP dan UDP. Microsoft mendokumentasikan ini dengan sangat rinci di artikel ini . Ini mungkin diberikan dalam banyak kasus, tetapi saat memecahkan masalah konektivitas, ada baiknya mengetahui apa yang sebenarnya dibutuhkan.
Dalam artikel sebelumnya , Saya juga menyebutkan bahwa perlu untuk memberikan izin kepada CNO klaster saat mengonfigurasi Kuorum Berbagi File.
Gbr. 2 Izin untuk berbagi File
Catatan tentang Resolusi Nama
Menjadi Objek Komputer, CNO, dan VNO bergantung pada Layanan Nama Domain untuk menyelesaikan nama yang ditunjukkan saat menginstal cluster, membuat peran, atau membuat AlwaysOn Listener. Biasanya klien diberi nama komputer ini untuk membuat sambungan ke cluster. Dengan kata lain, Alamat IP transparan bagi mereka, membuat konfigurasi klien menjadi sederhana dan mengabstraksi failover dari pengguna akhir.
Gbr. 3 Properti Pendengar AG untuk Pendengar dengan Dua Alamat IP
Dalam artikel sebelumnya, saya menyebutkan kasus di mana skenario ini dapat menyebabkan masalah. Di cluster multi-situs kami, kami memiliki satu pendengar untuk AlwaysOn Availability Group kami. Listener ini dikonfigurasi untuk menyelesaikan ke dua Alamat IP. Ini diperlukan untuk cluster multi-situs yang mencakup beberapa subnet. Dalam konfigurasi seperti itu, server nama akan mengembalikan kedua Alamat IP yang dipetakan ke pendengar setelah mengeluarkan nslookup periksa (lihat Gambar 4). Namun, saat menghubungkan, Anda hanya dapat mengakses salah satu Alamat IP tersebut dalam satu waktu. Cluster Manager akan menampilkan Alamat IP lainnya sebagai Offline (lihat Gambar 5).
Gbr. 4 Properti Pendengar AG untuk Pendengar dengan Dua Alamat IP
Gbr. 5 Properti untuk Peran Cluster dengan Dua Alamat IP di Subnet terpisah
Ini normal. Jika ada failover ke situs alternatif, Server DNS mulai menyelesaikan Alamat IP alternatif setelah beberapa menit. Implikasinya adalah bahwa komunikasi klien dengan situs alternatif harus dimungkinkan. Gambar 6 dan Gambar 7 menyoroti hal ini lebih lanjut.
Gbr. 6 Jalur Komunikasi dengan Replika Utama di Dakar
Mari kita perhatikan baik-baik jalur yang akan dilalui paket dari komputer klien ke cluster. Ketika Replika Utama ada di Dakar, nama Pendengar SQL-SVR-LNR diselesaikan ke alamat IP 192.168.1.20 dan WFCS, pada gilirannya, mengarahkan permintaan ke server 192.168.1.22 (perhatikan bahwa server ini juga memiliki sendiri nama komputer). Jika terjadi failover ke Nairobi, kami memiliki jalur komunikasi melalui 192.168.2.20 dan kemudian ke 192.168.2.22. Implikasinya adalah untuk pengalaman pelanggan yang lancar, semua klien di semua pusat data harus memiliki komunikasi yang diizinkan di semua firewall yang terlibat menggunakan port 1433.
Gbr. 7 Jalur Komunikasi dengan Replika Utama di Nairobi
Kesimpulan
Sementara Windows Failover Clustering, Active Directory, dan Domain Name Service mungkin berada di luar peran Database Administrator, ada baiknya untuk memiliki pemahaman dasar tentang cara kerja teknologi ini untuk dapat membangun dan memecahkan masalah AlwaysOn Instans Failover Cluster dan Grup Ketersediaan AlwaysOn. Beberapa organisasi memiliki pemisahan tugas yang ketat antara Administrator Sistem dan Administrator Basis Data, tetapi jika tidak demikian, Administrator Basis Data harus mampu memahami konsep Windows ini agar berhasil sebagai DBA.
Referensi
Ringkasan Grup Ketersediaan AlwaysOn
Pengelompokan Failover Windows dengan SQL Server
Ikhtisar Layanan dan Persyaratan Port Jaringan untuk Windows
Mengatur Objek Komputer
