Pemecahan Masalah AlwaysOn – Terkadang dibutuhkan banyak mata

Beberapa minggu yang lalu, saya mulai mengonfigurasi lingkungan demo dengan beberapa konfigurasi Grup Ketersediaan AlwaysOn. Saya memiliki cluster WSFC 5-node – setiap node memiliki instance SQL Server 2012 yang berdiri sendiri, dan ada juga dua Failover Cluster Instances (FCI) yang dipasang di atas node ini. Diagram cepat:

Jadi Anda dapat melihat ada 5 instance bernama standalone (.\AGDEMO pada setiap node), dan kemudian dua FCI – satu dengan kemungkinan pemilik VM-AARON-1 dan VM-AARON-2 (AGFCI1\AGFCI1 ), dan kemudian satu dengan kemungkinan pemilik VM-AARON-3, VM-AARON-4 dan VM-AARON-5 (AGFCI2\AGFCI2 ). Sekarang, membuat diagram secara manual harus menjadi jauh lebih kompleks (lebih lanjut tentang itu nanti), jadi saya akan menghindarinya karena alasan yang jelas. Pada dasarnya persyaratannya adalah memiliki beberapa jenis konfigurasi AG:

• Utama pada FCI dengan replika pada satu atau beberapa instans mandiri
• Utama pada FCI dengan replika pada FCI yang berbeda
• Utama pada instans mandiri dengan replika pada satu atau beberapa FCI
• Utama pada instans mandiri dengan replika pada satu atau beberapa instans mandiri
• Utama pada instans mandiri dengan replika pada instans mandiri dan FCI

Dan kemudian kombinasi (jika memungkinkan) komit sinkron vs. asinkron, failover manual vs. otomatis, dan sekunder hanya-baca. Ada beberapa batasan teknis yang akan membatasi kemungkinan permutasi di sini, misalnya:

• Pengalihan manual diperlukan dengan replika apa pun yang ada di FCI
• Tidak ada node WSFC yang dapat menghosting – atau bahkan mungkin menjadi pemilik – beberapa instans, baik yang berdiri sendiri atau berkelompok, yang terlibat dalam Grup Ketersediaan yang sama. Anda mendapatkan pesan kesalahan ini:Gagal membuat, bergabung, atau menambahkan replika ke grup ketersediaan 'MyGroup', karena node 'VM-AARON-1' adalah pemilik yang mungkin untuk replika 'AGFCI1\AGFCI1' dan 'VM-AARON-1\ AGDEMO'. Jika satu replika adalah instance kluster failover, hapus node yang tumpang tindih dari kemungkinan pemiliknya dan coba lagi. (Microsoft SQL Server, Kesalahan:19405)

Sebagian besar skenario yang saya coba wakili tidak praktis dalam skenario dunia nyata, tetapi sebagian besar dan secara teoritis mungkin . Jika Anda belum menebaknya sekarang, lingkungan ini sedang disiapkan secara eksplisit untuk menguji fungsionalitas baru di sekitar Grup Ketersediaan yang kami rencanakan untuk ditawarkan dalam versi SQL Sentry yang akan datang. Kami memberikan sedikit cuplikan dari beberapa teknologi ini selama keynote kami dengan Fusion-io pada konferensi SQL Intersection baru-baru ini di Las Vegas.

Hambatan #1

Menyiapkan Grup Ketersediaan menggunakan wizard di SSMS cukup mudah. Kecuali, misalnya, Anda memiliki jalur file yang heterogen. Wisaya memiliki validasi yang memastikan bahwa data yang sama dan jalur log ada di semua replika. Ini bisa merepotkan jika Anda menggunakan jalur data default untuk dua instance bernama berbeda, atau jika Anda memiliki konfigurasi huruf drive yang berbeda (yang akan sering terjadi saat FCI terlibat).

Lokasi folder berikut tidak ada di instance server yang menghosting replika sekunder VM-AARON-1\AGDEMO:

P:\MSSQL11.AGFCI2\MSSQL\DATA;
(Microsoft.SqlServer.Management.HadrTasks)

Sekarang tidak perlu dikatakan lagi bahwa Anda tidak ingin mengatur skenario ini di lingkungan apa pun yang perlu bertahan dalam ujian waktu. Segalanya akan berjalan cepat jika, misalnya, nanti Anda menambahkan file baru ke salah satu database. Namun untuk lingkungan uji / demo, bukti konsep, atau lingkungan yang Anda harapkan stabil untuk waktu yang cukup lama, jangan khawatir:Anda masih dapat melakukannya tanpa wizard.

Sayangnya, untuk menambahkan penghinaan pada cedera, wizard tidak mengizinkan Anda membuat skrip. Anda tidak dapat melewati kesalahan validasi dan tidak ada Script tombol:

Jadi ini berarti Anda perlu mengkodekannya sendiri (karena DDL tidak melakukan validasi "membantu" untuk Anda). Jika Anda memiliki contoh lain di mana jalur yang sama ada, Anda dapat melakukannya dengan mengikuti wizard yang sama, melewati layar validasi, lalu mengklik Script alih-alih Finish , dan ubah nama server dan tambahkan dengan WITH MOVE opsi untuk pemulihan awal. Atau Anda bisa menulis sendiri dari awal, seperti ini (skrip mengasumsikan Anda sudah memiliki titik akhir dan izin yang dikonfigurasi, dan semua instance mengaktifkan fitur Grup Ketersediaan):

-- Gunakan mode SQLCMD dan batalkan komentar pada :perintah CONNECT-- atau jalankan saja dua segmen secara terpisah / ubah koneksi-- :CONNECT Server1 CREATE AVAILABILITY GROUP [GroupName] WITH (AUTOMATED_BACKUP_PREFERENCE =SECONDARY) UNTUK DATABASE [Database1] -- , ... REPLIKA AKTIF -- primer:N'Server1' WITH (ENDPOINT_URL =N'TCP://Server1:5022', FAILOVER_MODE =MANUAL, AVAILABILITY_MODE =ASYNCHRONOUS_COMMIT, BACKUP_PRIORITY =50, SECONDARY_ROLE(ALLOW_CONNECTIONS =NO)), - - sekunder:N'Server2' WITH (ENDPOINT_URL =N'TCP://Server2:5022', FAILOVER_MODE =MANUAL, AVAILABILITY_MODE =ASYNCHRONOUS_COMMIT, BACKUP_PRIORITY =50, SECONDARY_ROLE(ALLOW_CONNECTIONS =NO)); ALTER AVAILABILITY GROUP [GroupName] ADD LISTENER N'ListenerName' (DENGAN IP ((N'10.x.x.x', N'255.255.255.0')), PORT=1433); CADANGAN DATABASE Database1 TO DISK ='\\Server1\Share\db1.bak' DENGAN INIT, COPY_ONLY, COMPRESSION; BACKUP LOG Database1 TO DISK ='\\Server1\Share\db1.trn' DENGAN INIT, KOMPRESI; -- :CONNECT Server2ALTER AVAILABILITY GROUP [GroupName] GABUNG; RESTORE DATABASE Database1 FROM DISK ='\\Server1\Share\db1.bak' DENGAN REPLACE, NORECOVERY, NOUNLOAD, PINDAHKAN 'data_file_name' KE 'P:\path\file.mdf', PINDAHKAN 'log_file_name' KE 'P:\path \file.ldf'; RESTORE LOG Database1 FROM DISK ='\\Server1\Share\db1.trn' DENGAN NORECOVERY, NOUNLOAD; ALTER DATABASE Database1 SET HADR AVAILABILITY GROUP =[GroupName];

Hambatan #2

Jika Anda memiliki beberapa instans di server yang sama, Anda mungkin menemukan bahwa kedua instans tidak dapat berbagi port 5022 untuk titik akhir pencerminan database mereka (yang merupakan titik akhir yang sama yang digunakan oleh Grup Ketersediaan). Ini berarti Anda harus menghapus dan membuat ulang titik akhir untuk menyetelnya ke port yang tersedia.

DROP ENDPOINT [Hadr_endpoint];GO CREATE ENDPOINT [Hadr_endpoint] STATE =MULAI SEBAGAI TCP ( LISTENER_PORT =5023 ) UNTUK DATABASE_MIRRORING (PERAN =SEMUA);

Sekarang saya dapat menentukan sebuah instance dengan titik akhir pada ServerName:5023 .

Hambatan #3

Namun, setelah saya melakukan ini, ketika saya akan mencapai langkah terakhir dalam skrip di atas, setelah tepat 48 detik – setiap kali – saya akan mendapatkan pesan kesalahan yang tidak membantu ini:

Ini membuat saya mengejar semua jenis masalah potensial - memeriksa firewall dan SQL Server Configuration Manager, misalnya, untuk apa pun yang akan memblokir port di antara instance. Nada. Saya menemukan berbagai kesalahan di log kesalahan SQL Server:

Upaya login Pencerminan Basis Data gagal dengan kesalahan:'Jabat tangan koneksi gagal. Panggilan OS gagal:(80090303) 0x80090303(Target yang ditentukan tidak diketahui atau tidak dapat dijangkau). Negara 66.'.

Batas waktu koneksi telah terjadi saat mencoba membuat koneksi ke replika ketersediaan 'VM-AARON-1\AGDEMO' dengan id [5AF5B58D-BBD5-40BB-BE69-08AC50010BE0]. Ada masalah jaringan atau firewall, atau alamat titik akhir yang disediakan untuk replika bukanlah titik akhir pencerminan database dari instance server host.

Ternyata (dan terima kasih kepada Thomas Stringer (@SQLife)) bahwa masalah ini disebabkan oleh kombinasi gejala:(a) Kerberos tidak diatur dengan benar, dan (b) algoritma enkripsi untuk hadr_endpoint yang saya buat gagal ke RC4. Ini akan baik-baik saja jika semua instance mandiri juga menggunakan RC4, tetapi tidak. Singkat cerita, saya menjatuhkan dan membuat ulang titik akhir lagi , pada semua contoh. Karena ini adalah lingkungan lab dan saya tidak benar-benar membutuhkan dukungan Kerberos (dan karena saya telah menginvestasikan cukup waktu dalam masalah ini sehingga saya tidak ingin mengejar masalah Kerberos juga), saya menyiapkan semua titik akhir untuk menggunakan Negosiasi dengan AES:

DROP ENDPOINT [Hadr_endpoint];PERGI CREATE ENDPOINT [Hadr_endpoint] STATE =DIMULAI SEBAGAI TCP ( LISTENER_PORT =5023 ) UNTUK DATABASE_MIRRORING ( AUTHENTICATION =WINDOWS NEGOTIATE, ENCRYPTION =ALGORITHM YANG DIBUTUHKAN);
 (Ted Krueger (@onpnt) baru-baru ini membuat blog tentang masalah serupa juga.)
 

 Sekarang, akhirnya, saya dapat membuat Grup Ketersediaan dengan semua berbagai persyaratan yang saya miliki, antara node dengan jalur file yang heterogen, dan menggunakan beberapa instance pada node yang sama (hanya saja tidak dalam grup yang sama). Berikut adalah tampilan salah satu tampilan AlwaysOn Management kami (klik untuk memperbesar untuk gambaran yang jauh lebih baik):
 

 
 

 Sekarang, itu hanya sedikit godaan, dan itu sepenuhnya disengaja. Saya akan menulis blog lebih banyak tentang fungsi ini dalam beberapa minggu mendatang!
 
Kesimpulan
 

 Ketika Anda menghabiskan waktu yang cukup lama untuk melihat suatu masalah, Anda dapat mengabaikan beberapa hal yang cukup jelas. Dalam hal ini ada beberapa masalah nyata yang disembunyikan oleh beberapa pesan kesalahan yang benar-benar tidak intuitif. Saya ingin berterima kasih kepada Joe Sack (@JosephSack), Allan Hirt (@SQLHA) dan Thomas Stringer (@SQLife) karena telah memberikan segalanya untuk membantu sesama anggota komunitas yang membutuhkan.