Panduan untuk mengkonfigurasi contoh SQL Server Failover Cluster di Azure

Langkah-demi-Langkah: Cara Mengkonfigurasi Instance Failover Cluster SQL Server 2008 R2 di Azure

Jika Anda memerlukan panduan Mengkonfigurasi Instance Cluster Failover SQL Server di Azure, Anda mungkin masih menggunakan SQL Server 2008/2008 R2. Dan, ingin mengambil keuntungan dari pembaruan keamanan yang diperluas yang ditawarkan Microsoft jika Anda memindahkan SQL Server 2008/2008 R2 ke Azure. Saya sebelumnya menulis tentang topik ini di posting blog ini. Anda mungkin bertanya-tanya bagaimana memastikan contoh SQL Server Failover Cluster Anda tetap tersedia begitu Anda pindah ke Azure. Saat ini, kebanyakan orang memiliki bisnis kritis SQL Server 2008/2008 R2 dikonfigurasi sebagai contoh berkerumun (SQL Server FCI) di pusat data mereka. Saat melihat Azure, Anda mungkin menyadari bahwa karena kurangnya penyimpanan bersama, tampaknya Anda tidak dapat membawa SQL Server FCI ke cloud Azure. Namun, bukan itu masalahnya berkat SIOS DataKeeper. SIOS DataKeeper memungkinkan Anda untuk membangun contoh SQL Server Failover Cluster di Azure, AWS, Google Cloud, atau di mana pun di mana penyimpanan bersama tidak tersedia atau di mana Anda ingin mengonfigurasi cluster multi-situs di mana penyimpanan bersama tidak masuk akal. DataKeeper telah mengaktifkan kluster SANless untuk Windows dan Linux sejak 1999. Microsoft mendokumentasikan penggunaan SIOS DataKeeper untuk contoh SQL Server Failover Cluster dalam dokumentasi mereka: Ketersediaan tinggi dan pemulihan bencana untuk SQL Server di Mesin Virtual Azure. Saya sudah menulis tentang SQL Server FCI yang berjalan di Azure sebelumnya, Tapi saya tidak pernah menerbitkan Panduan Langkah-demi-Langkah khusus untuk SQL Server 2008/2008 R2. Berita baiknya adalah ini berfungsi sama baiknya dengan SQL 2008/2008 R2 seperti halnya dengan SQL 2012/2014/2016/2017 dan segera dirilis 2019. Selain itu, terlepas dari versi Windows Server (2008/2012/2016/2019) atau SQL Server (2008/2012/2014/2016/2017) proses konfigurasinya cukup mirip sehingga panduan ini harus cukup memadai untuk membantu Anda melalui konfigurasi. Jika rasa Anda SQL atau Windows tidak tercakup dalam salah satu panduan saya, jangan takut untuk melompat dan membangun FCI SQL Server dan referensi panduan ini, saya pikir Anda akan mengetahui perbedaan dan jika Anda pernah terjebak hanya menjangkau saya di Twitter @daveberm dan saya akan dengan senang hati membantu Anda. Panduan ini menggunakan SQL Server 2008 R2 dengan Windows Server 2012 R2. Pada saat penulisan ini saya tidak melihat gambar Azure Marketplace dari SQL 2008 R2 pada Windows Server 2012 R2, jadi saya harus mengunduh dan menginstal SQL 2008 R2 secara manual. Secara pribadi saya lebih suka kombinasi ini, tetapi jika Anda perlu menggunakan Windows Server 2008 R2 atau Windows 212 itu bagus. Jika Anda menggunakan Windows Server 2008 R2 jangan lupa untuk menginstal Pembaruan Rollup kb3125574Convenience untuk Windows Server 2008 R2 SP1. Atau jika Anda terjebak dengan Server 2012 (bukan R2), Anda memerlukan perbaikan terbaru di kb2854082. Jangan tertipu oleh artikel ini yang mengatakan Anda harus menginstal kb2854082 pada contoh SQL Server 2008 R2 Anda. Jika Anda mulai mencari pembaruan untuk Windows Server 2008 R2 Anda akan menemukan bahwa hanya versi untuk Server 2012 yang tersedia. Perbaikan terbaru khusus itu untuk Server 2008 R2 yang termasuk dalam rollup pembaruan kenyamanan Rollup untuk Windows Server 2008 R2 SP1.

INSTAN AZURE KETENTUAN

Saya tidak akan membahas detail di sini dengan banyak tangkapan layar, terutama karena Azure Portal UI cenderung berubah cukup sering, sehingga tangkapan layar yang saya ambil akan menjadi sangat cepat. Sebagai gantinya, saya hanya akan membahas topik-topik penting yang harus Anda ketahui.

DOMAIN KESALAHAN ATAU KETERSEDIAAN ZONA?

Untuk memastikan instance SQL Server Anda sangat tersedia, Anda harus memastikan node cluster Anda berada di berbagai Domain Kesalahan (FD) atau di Zona Ketersediaan yang berbeda (AZ). Instance Anda tidak hanya perlu berada di FD atau AZ yang berbeda, tetapi File Share Witness Anda (lihat di bawah) juga perlu berada di FD atau AZ yang berbeda dari yang ada di mana node cluster Anda berada. Ini pendapat saya. AZ adalah fitur Azure terbaru, tetapi mereka hanya didukung di beberapa wilayah sejauh ini. AZ memberi Anda SLA yang lebih tinggi (99,99%) kemudian FD (99,95%), dan melindungi Anda terhadap jenis pemadaman awan yang saya jelaskan dalam posting saya Azure Outage Post-Mortem. Jika Anda dapat menggunakan di wilayah yang mendukung AZ maka saya sarankan Anda menggunakan AZ. Dalam panduan ini saya menggunakan AZ yang akan Anda lihat ketika Anda sampai pada bagian tentang mengkonfigurasi penyeimbang beban. Namun, jika Anda menggunakan FD, semuanya akan persis sama, kecuali konfigurasi penyeimbang beban akan merujuk pada Kumpulan Ketersediaan daripada Zona Ketersediaan.

APA ITU FILE SHARE SAKSI YANG ANDA TANYAKAN?

Tanpa merinci lebih jauh, Windows Server Failover Clustering (WSFC) mengharuskan Anda mengonfigurasi "Witness" untuk memastikan bahwa failover berperilaku baik. Windows Server Failover Clustering mendukung tiga jenis saksi: Disk, File Share, Cloud. Karena kita berada di Azure, Saksi Disk tidak mungkin. Cloud Witness hanya tersedia dengan Windows Server 2016 dan yang lebih baru, sehingga meninggalkan kami dengan File Share Witness. Jika Anda ingin mempelajari lebih lanjut tentang kuorum klaster, lihat pos saya di Microsoft Press Blog, Dari MVP: Memahami Kuorum Cluster Failover Server Windows di Windows Server 2012 R2

TAMBAHKAN PENYIMPANAN KEPADA INSTAN SQL SERVER ANDA

Saat Anda menyediakan instance SQL Server Anda, Anda akan ingin menambahkan disk tambahan untuk setiap instance. Minimal Anda akan memerlukan satu disk untuk Data SQL dan file Log, satu disk untuk Tempdb. Apakah Anda harus memiliki disk terpisah untuk file log dan data agak diperdebatkan saat berjalan di cloud. Di bagian belakang, penyimpanan semua berasal dari tempat yang sama dan ukuran instance Anda membatasi total IOPS Anda. Menurut pendapat saya benar-benar tidak ada nilai dalam memisahkan log dan file data Anda karena Anda tidak dapat memastikan bahwa mereka berjalan pada dua set fisik disk. Saya akan membiarkan itu untuk Anda putuskan, tetapi saya menaruh log dan data semua pada volume yang sama. Biasanya SQL Server 2008 R2 FCI akan meminta Anda untuk meletakkan tempdb pada disk berkerumun. Namun, SIOS DataKeeper memiliki fitur yang sangat bagus ini disebut DataKeeper Non-Mirrored Volume Resource. Panduan ini tidak mencakup memindahkan tempdb ke sumber daya volume yang tidak dicerminkan ini, tetapi untuk kinerja yang optimal Anda harus melakukan ini. Sebenarnya tidak ada alasan yang baik untuk mereplikasi tempdb karena itu diciptakan pada saat failover. Sejauh penyimpanan terkait Anda dapat menggunakan jenis penyimpanan apa pun, tetapi tentu saja menggunakan Managed Disk kapan pun memungkinkan. Pastikan setiap node dalam gugus memiliki konfigurasi penyimpanan yang identik. Setelah Anda meluncurkan instance, Anda ingin melampirkan disk ini dan memformatnya NTFS. Pastikan setiap instance menggunakan huruf drive yang sama.

JARINGAN

Ini bukan persyaratan yang sulit, tetapi jika mungkin gunakan ukuran instance yang mendukung jaringan yang dipercepat. Juga, pastikan Anda mengedit antarmuka jaringan di portal Azure sehingga instance Anda menggunakan alamat IP statis. Agar pengelompokan berfungsi dengan baik, Anda ingin memastikan Anda memperbarui pengaturan untuk server DNS sehingga menunjuk ke Windows AD / DNS server Anda dan bukan hanya beberapa server DNS publik.

KEAMANAN

Secara default, komunikasi antara node dalam jaringan virtual yang sama terbuka lebar, tetapi jika Anda telah mengunci Grup Keamanan Azure Anda, Anda perlu tahu port apa yang harus terbuka antara node cluster dan menyesuaikan grup keamanan Anda. Dalam pengalaman saya, hampir semua masalah yang akan Anda temui ketika membangun sebuah cluster di Azure disebabkan oleh port yang diblokir. DataKeeper memiliki beberapa port yang harus dibuka antara instance clustered. Port-port itu adalah sebagai berikut: UDP: 137, 138 TCP: 139, 445, 9999, plus port dalam rentang 10000 hingga 10025 Failover cluster memiliki serangkaian persyaratan port sendiri yang bahkan tidak akan saya coba dokumentasikan di sini. Artikel ini sepertinya sudah dibahas. http://dsfnet.blogspot.com/2013/04/windows-server-clustering-sql-server.html Selain itu, Load Balancer yang dijelaskan nanti akan menggunakan port probe yang harus mengizinkan lalu lintas masuk pada setiap node. Port yang umum digunakan dan dijelaskan dalam panduan ini adalah 59999. Dan akhirnya jika Anda ingin klien Anda dapat mencapai contoh SQL Server Anda, Anda ingin memastikan port SQL Server Anda terbuka, yang secara default adalah 1433. Ingat, port ini dapat diblokir oleh Windows Firewall atau Azure Security Groups, jadi pastikan untuk memeriksa keduanya untuk memastikan mereka dapat diakses.

GABUNGKAN DOMAIN

Persyaratan untuk SQL Server 2008 R2 FCI adalah bahwa instance harus berada di Windows Server Domain yang sama. Jadi, jika Anda belum melakukannya, pastikan Anda telah bergabung dengan instance ke domain Windows Anda

AKUN LAYANAN LOKAL

Ketika Anda menginstal DataKeeper, ia akan meminta Anda untuk memberikan akun layanan. Anda harus membuat akun pengguna domain dan kemudian menambahkan akun pengguna itu ke Grup Administrator Lokal pada setiap node. Ketika ditanya selama instalasi DataKeeper, tentukan akun itu sebagai akun layanan DataKeeper. Catatan – Jangan menginstal DataKeeper dulu!

KELOMPOK KEAMANAN DOMAIN GLOBAL

Anda akan diminta untuk menentukan dua Grup Keamanan Domain Global saat Anda menginstal SQL 2008 R2. Anda mungkin ingin melihat ke depan pada petunjuk instalasi SQL dan membuat grup tersebut sekarang. Juga, buat akun pengguna domain dan letakkan di masing-masing akun keamanan ini. Anda akan menentukan akun ini sebagai bagian dari instalasi SQL Server Cluster.

PERSYARATAN LAINNYA

Anda harus mengaktifkan Failover Clustering dan .Net 3.5 pada setiap instance dari dua instance cluster. Ketika Anda mengaktifkan Failover Clustering, pastikan juga untuk mengaktifkan "Server Failover Cluster Automation" opsional. Ini diperlukan untuk SQL Server 2008 R2 cluster di Windows Server 2012 R2.

BUAT SUMBER DAYA CLUSTER DAN DATAKEEPER

Kami sekarang siap untuk mulai membangun cluster. Langkah pertama adalah membuat basis cluster. Karena cara Azure menangani DHCP, kami HARUS membuat cluster menggunakan Powershell dan bukan Cluster UI. Kami menggunakan Powershell karena itu akan memungkinkan kami menentukan alamat IP statis sebagai bagian dari proses pembuatan. Jika kami menggunakan UI, itu akan melihat bahwa VM menggunakan DHCP dan itu akan secara otomatis menetapkan alamat IP duplikat. Karena itu untuk menghindari situasi itu, mari kita gunakan Powershell seperti yang ditunjukkan di bawah ini.

New-Cluster -Name cluster1 -Node sql1, sql2 -StaticAddress 10.0.0.100 -NoStorage

Setelah cluster membuat, jalankan Test-Cluster. Ini diperlukan sebelum SQL Server akan menginstal.

Test-Cluster

Anda akan mendapatkan peringatan tentang Penyimpanan dan Jaringan. Untungnya, Anda dapat mengabaikannya seperti yang diharapkan pada kluster SANless di Azure. Namun, atasi peringatan atau kesalahan lainnya sebelum melanjutkan. Setelah cluster dibuat, Anda perlu menambahkan File Share Witness. Pada server ketiga kami tentukan sebagai saksi berbagi file, buat berbagi file dan berikan izin Baca / Tulis ke objek komputer cluster yang baru saja kita buat di atas. Dalam hal ini $ Cluster1 akan menjadi nama objek komputer yang membutuhkan izin Baca / Tulis di tingkat keamanan berbagi dan NTFS. Setelah berbagi dibuat, Anda dapat menggunakan panduan kuorum konfigurasi Cluster seperti yang ditunjukkan di bawah ini untuk mengkonfigurasi File Share Witness.

INSTAL DATAKEEPER

Penting untuk menunggu hingga klaster dasar dibuat sebelum kita menginstal DataKeeper, karena instalasi DataKeeper mendaftarkan tipe Sumber Daya Volume DataKeeper dalam kluster failover. Jika Anda melompat pistol dan sudah menginstal DataKeeper tidak apa-apa. Cukup jalankan pengaturan lagi dan pilih Perbaiki Instalasi. Screenshot di bawah ini memandu Anda melalui instalasi dasar. Mulai dengan menjalankan Pengaturan DataKeeper.

Akun yang Anda tentukan di bawah ini harus akun domain. Itu harus menjadi bagian dari grup Administrator Lokal pada setiap node cluster.

Ketika disajikan dengan manajer Kunci Lisensi SIOS, Anda dapat menelusuri kunci sementara Anda. Atau jika Anda memiliki kunci permanen, Anda dapat menyalin ID Host Sistem dan menggunakannya untuk meminta lisensi permanen Anda. Jika Anda perlu menyegarkan kunci, SIOS License Key Manager adalah program yang akan diinstal yang dapat Anda jalankan secara terpisah untuk menambahkan kunci baru.

BUAT SUMBER DATAKEEPER VOLUME

Setelah DataKeeper diinstal pada setiap node, Anda siap membuat Sumber Daya Volume DataKeeper pertama Anda. Langkah pertama adalah membuka UI DataKeeper dan menghubungkan ke masing-masing node cluster.

Jika semuanya dilakukan dengan benar, Laporan Ikhtisar Server akan terlihat seperti ini.

Anda sekarang dapat membuat Pekerjaan pertama Anda seperti yang ditunjukkan di bawah ini.

Setelah Anda memilih Sumber dan Target, Anda akan diberikan opsi berikut. Untuk target lokal di wilayah yang sama, satu-satunya yang perlu Anda pilih adalah Sinkron.

Pilih Ya dan daftarkan otomatis volume ini sebagai sumber daya klaster.

Setelah Anda menyelesaikan proses ini, buka Failover Cluster Manager dan cari di Disk. Anda harus melihat sumber daya Volume DataKeeper di Penyimpanan yang Tersedia. Pada titik ini WSFC memperlakukan ini seolah-olah itu adalah sumber daya disk cluster yang normal.

SLIPSTREAM SP3 ONTO SQL 2008 R2 INSTALL MEDIA

SQL Server 2008 R2 hanya didukung pada Windows Server 2012 R2 dengan SQL Server SP2 atau yang lebih baru. Sayangnya, Microsoft tidak pernah merilis media instalasi SQL Server 2008 R2 yang menyertakan SP2 atau SP3. Sebagai gantinya, Anda harus memasukkan paket layanan ke media instalasi sebelum Anda melakukan instalasi. Jika Anda mencoba melakukan instalasi dengan media SQL Server 2008 R2 standar, Anda akan mengalami semua jenis masalah. Saya tidak ingat kesalahan pasti yang akan Anda lihat. Tapi saya ingat mereka tidak benar-benar menunjukkan masalah yang sebenarnya. Anda akan menghabiskan banyak waktu untuk mencari tahu apa yang salah. Pada tanggal penulisan ini, Microsoft tidak memiliki Windows Server 2012 R2 dengan penawaran SQL Server 2008 R2 di Azure Marketplace. Jangan membawa lisensi SQL Anda sendiri jika Anda ingin menjalankan SQL 2008 R2 pada Windows Server 2012 R2 di Azure. Jika mereka menambahkan gambar itu nanti, atau jika Anda memilih untuk menggunakan SQL 2008 R2 pada gambar Windows Server 2008 R2, Anda harus terlebih dahulu menghapus instalan contoh mandiri SQL Server yang ada sebelum melanjutkan. Saya mengikuti panduan dalam Opsi 1 artikel ini untuk memasukkan SP3 ke media instalasi SQL 2008 R2 saya. Anda tentu saja harus menyesuaikan beberapa hal karena artikel ini merujuk SP2 daripada SP3. Pastikan Anda memasukkan SP3 pada media instalasi yang akan kami gunakan untuk kedua node cluster. Setelah selesai, lanjutkan ke langkah berikutnya.

INSTAL SQL SERVER PADA NODE PERTAMA

Menggunakan media SQL Server 2008 R2 dengan SP3 slipstream, jalankan setup dan instal node pertama dari cluster seperti yang ditunjukkan di bawah ini.

Jika Anda menggunakan selain dari contoh Default SQL Server, Anda akan memiliki beberapa langkah tambahan yang tidak tercakup dalam panduan ini. Perbedaan terbesar adalah Anda harus mengunci port yang digunakan SQL Server karena secara default contoh bernama SQL Server TIDAK menggunakan 1433. Setelah Anda mengunci port, Anda juga perlu menentukan port itu alih-alih 1433 setiap kali kami merujuk port 1433 dalam panduan ini, termasuk pengaturan firewall dan pengaturan Load Balancer.

Di sini pastikan untuk menentukan alamat IP baru yang tidak digunakan. Ini adalah alamat IP yang sama yang akan kita gunakan nanti ketika kita mengkonfigurasi Internal Load Balancer nanti.

Seperti yang saya sebutkan sebelumnya, SQL Server 2008 R2 menggunakan Grup Keamanan AD. Jika Anda belum membuatnya, silakan dan buat sekarang seperti yang ditunjukkan di bawah ini sebelum Anda melanjutkan ke langkah berikutnya dalam instalasi SQL

Tentukan Grup Keamanan yang Anda buat sebelumnya.

Pastikan akun layanan yang Anda tentukan adalah anggota Grup Keamanan terkait.

Tentukan administrator SQL Server Anda di sini.

Jika semuanya berjalan dengan baik, Anda sekarang siap untuk menginstal SQL Server pada node kedua cluster.

INSTAL SQL SERVER PADA DATA KEDUA

Satu simpul kedua, jalankan SQL Server 2008 R2 dengan SP3 instal dan pilih Add Node ke SQL Server Failover Clustering Instance.

Lanjutkan dengan instalasi seperti yang ditunjukkan pada tangkapan layar berikut.

Dengan asumsi semuanya berjalan dengan baik, Anda sekarang harus memiliki dua node SQL Server 2008 R2 cluster yang dikonfigurasi yang terlihat seperti berikut ini.

Namun, Anda mungkin akan melihat bahwa Anda hanya bisa menyambungkan ke contoh SQL Server dari node cluster aktif. Masalahnya adalah bahwa Azure tidak mendukung ARP serampangan. Klien Anda mungkin tidak dapat terhubung langsung ke Alamat IP Cluster. Sebagai gantinya, klien harus terhubung ke Azure Load Balancer, yang akan mengarahkan ulang koneksi ke node aktif. Untuk membuat ini bekerja ada dua langkah: Buat Load Balancer dan Perbaiki SQL Server Cluster IP untuk menanggapi Load Balancer Probe dan gunakan subnet mask 255.255.255.255. Langkah-langkah tersebut dijelaskan di bawah ini.

BUAT BALANCER LOAD AZURE

Saya akan menganggap klien Anda dapat berkomunikasi langsung ke alamat IP internal SQL cluster. Mari kita lanjutkan untuk membuat Internal Load Balancer (ILB) dalam panduan ini. Jika Anda perlu mengekspos Instance SQL Anda di internet publik, gunakan Public Load Balancer sebagai gantinya. Di portal Azure, buat Load Balancer baru mengikuti tangkapan layar seperti yang ditunjukkan di bawah ini. UI portal Azure berubah dengan cepat. Tapi tangkapan layar ini akan memberi Anda informasi yang cukup untuk melakukan apa yang perlu Anda lakukan. Saya akan memanggil pengaturan penting saat kita melanjutkan. Di sini kita membuat ILB. Yang penting untuk dicatat pada layar ini adalah Anda harus memilih "Penugasan alamat IP statis". Tentukan alamat IP yang sama yang kami gunakan selama instalasi SQL Cluster juga. Karena saya menggunakan Zona Ketersediaan, saya melihat Zone Redundant sebagai opsi. Jika Anda menggunakan Set Ketersediaan, pengalaman Anda akan sedikit berbeda.

Di kolam Backend pastikan untuk memilih dua contoh SQL Server. Anda TIDAK ingin menambahkan File Share Witness Anda di pool.

Di sini kita mengkonfigurasi Probe Kesehatan. Sebagian besar dokumentasi Azure menggunakan port 59999, jadi kami akan tetap menggunakan port itu untuk konfigurasi kami.

Kemudian kita akan menambahkan aturan load balancing. Dalam kasus kami, kami ingin mengarahkan semua lalu lintas SQL Server ke port TCP 1433 dari simpul aktif. Penting juga bahwa Anda memilih Floating IP (Direct Server Return) sebagai Diaktifkan.

JALANKAN POWERSHELL SCRIPT UNTUK MEMPERBARUI POINT AKSES KLIEN SQL

Sekarang kita harus menjalankan skrip Powershell di salah satu node cluster untuk memungkinkan Load Balancer Probe mendeteksi node mana yang aktif. Script juga menetapkan Subnet Mask dari SQL Cluster IP Address ke 255.255.255.255.255 sehingga ia menghindari konflik alamat IP dengan Load Balancer yang baru saja kita buat.

# Tentukan variabel
$ ClusterNetworkName = "" 
nama jaringan kluster (Gunakan Get-ClusterNetwork di Windows Server 2012 of 
lebih tinggi untuk menemukan nama)
$ IPResourceName = "" 
# nama sumber daya Alamat IP 
$ ILBIP = "" 
# Alamat IP Internal Load Balancer (ILB) dan SQL Cluster
Impor-Modul FailoverClusters
# Jika Anda menggunakan Windows Server 2012 atau lebih tinggi:
Dapatkan-ClusterResource $ IPResourceName | Set-ClusterParameter 
-Multiple @ {Alamat = $ ILBIP; ProbePort = 59999; SubnetMask = "255.255.255.255";
Network = $ ClusterNetworkName; EnableDhcp = 0}
# Jika Anda menggunakan Windows Server 2008 R2 gunakan ini: 
#cluster res $ IPResourceName / priv enabledhcp = 0 address = $ ILBIP probeport = 59999  
subnetmask = 255.255.255.255

Ini akan terlihat seperti apa hasil jika dijalankan dengan benar.

Anda mungkin memperhatikan bahwa akhir skrip itu memiliki baris kode komentar untuk digunakan jika Anda menjalankan Windows Server 2008 R2. Menjalankan Windows Server 2008 R2? Pastikan Anda menjalankan kode khusus untuk Windows Server 2008 R2 pada prompt perintah, itu bukan Powershell.

LANGKAH SELANJUTNYA

Anda bukan yang pertama jika Anda sampai pada titik ini dan Anda masih tidak dapat terhubung ke cluster dari jarak jauh. Ada banyak hal yang bisa salah dalam hal keamanan, load balancer, port SQL, dll. Saya menulis panduan ini untuk membantu memecahkan masalah koneksi. Bahkan, saya mengalami beberapa masalah aneh dalam hal SQL Server TCP / IP Properties di SQL Server Configuration Manager. Ketika saya melihat properti saya tidak melihat alamat IP SQL Server Cluster sebagai salah satu alamat yang didengarkan. Karena itu saya harus menambahkannya secara manual. Saya tidak yakin apakah itu anomali. Meskipun itu tentu saja merupakan masalah yang harus saya selesaikan sebelum saya bisa terhubung ke cluster dari klien jarak jauh. Seperti yang saya sebutkan sebelumnya, satu perbaikan lain yang dapat Anda lakukan untuk instalasi ini adalah dengan menggunakan DataKeeper Non-Mirrored Volume Resource untuk TempDB. Jika Anda mengaturnya, harap perhatikan dua masalah konfigurasi berikut yang biasa dialami orang. Masalah pertama adalah jika Anda memindahkan tempdb ke folder pada simpul ke-1, Anda harus yakin untuk membuat struktur folder yang sama persis pada simpul kedua. Jika Anda tidak melakukan itu, ketika Anda mencoba untuk gagal SQL Server akan gagal untuk online karena tidak dapat membuat TempDB. Masalah kedua terjadi kapan saja Anda menambahkan Sumber Daya Volume DataKeeper lain ke SQL Cluster setelah cluster dibuat. Anda harus masuk ke properti sumber daya gugusan SQL Server dan membuatnya tergantung pada sumber daya Volume DataKeeper baru yang Anda tambahkan. Ini berlaku untuk volume TempDB dan volume lainnya yang dapat Anda putuskan untuk ditambahkan setelah cluster dibuat. Jika Anda memiliki pertanyaan tentang konfigurasi ini atau konfigurasi cluster lainnya, jangan ragu untuk menghubungi saya di Twitter @DaveBerm.

Mencapai SQL Server Pemulihan Bencana Ketersediaan Tinggi Dengan DataKeeper

Mencapai SQL Server Ketersediaan Tinggi, Pemulihan Bencana Dengan Campuran Grup Selalu Tersedia dan SANless SQL Server Failover Cluster Instances

pengantar

Topik pencampuran SQL Server Failover Cluster Instances (FCI) dengan Always On Availability Groups (AG) didokumentasikan dengan cukup baik. Namun, sebagian besar konfigurasi dokumen dokumentasi yang tersedia yang mengasumsikan bagian SQL Server FCI dari solusi menggunakan penyimpanan bersama. Bagaimana jika saya ingin membangun SANless SQL Server FCI menggunakan Storage Spaces Direct (S2D), apakah saya masih dapat menambahkan SQL Server AG ke dalam campuran? Sayangnya, jawaban untuk pertanyaan ini adalah tidak. Sampai hari ini, kombinasi S2D berbasis SQL Server FCI dan Always On AG ini tidak didukung. Saya sebelumnya menulis blog tentang batasan S2D ini di sini. Namun, kabar baiknya adalah Anda BISA membangun SANless SQL Server FCI dengan SIOS DataKeeper dan masih memanfaatkan Always On AG untuk hal-hal seperti sekunder yang dapat dibaca. Anda masih harus mematuhi aturan yang sama yang berlaku ketika mencampur SQL Server FCI tradisional berbasis SAN dan Always On AGs, tetapi sebagian besar untuk mencapai SQL Server ketersediaan tinggi hampir sama. Replikasi Sinkronisasi DataKeeper umumnya digunakan antara node di pusat data atau wilayah cloud yang sama, tetapi Anda mungkin ingin mereplikasi secara tidak sinkron ke node tambahan di wilayah berbeda untuk pemulihan bencana. Dalam hal ini, jika Anda harus membawa DR node online setelah kegagalan tak terduga, Anda harus menghapus konfigurasi Always On AG dan mengkonfigurasi ulang mereka. Persyaratan ini sangat mirip dengan apa yang Microsoft terbitkan di sini sehubungan dengan mengembalikan snapshot asinkron dari SQL Server Always On AG yang berjalan di dalam VM.

Grup yang Tersedia

Pada dasarnya, Instance SQL Server Failover Cluster Instance dengan DataKeeper terlihat seperti turunan tunggal dari SQL Server sejauh yang selalu ada pada Wizard Grup Ketersediaan. Konfigurasi Selalu Aktif AG persis sama seperti jika Anda hanya membuat Selalu Aktif AG antara dua contoh SQL Server Standalone (non-clustered). Kebingungan nyata muncul pada kenyataan bahwa dalam konfigurasi ini semua server berada di kluster failover yang sama. Tetapi SQL Server FCI hanya dikonfigurasi untuk berjalan hanya pada node cluster di mana SQL Server diinstal sebagai SQL Server Clustered. Node lain berada di cluster yang sama. Namun, SQL diinstal pada node tersebut sebagai Mesin Virtual SQL Server Standalone, bukan Mesin Virtual Clustered. Agak membingungkan. Pada dasarnya apa yang terjadi adalah bahwa Always On AG memanfaatkan model kuorum dan pendengar WSFC. Dengan demikian semua Replika AG harus berada di WSFC yang sama, meskipun mereka biasanya tidak menjalankan contoh SQL Server yang dikelompokkan. Jika Anda benar-benar bingung tidak apa-apa, kebanyakan orang bingung ketika mereka pertama kali mencoba membungkus kepala mereka dengan konfigurasi hybrid ini. Manfaat nyata dalam konfigurasi seperti ini adalah bahwa SQL Server Failover Cluster Instance dapat menjadi lebih baik dan lebih hemat biaya (lebih lanjut tentang ini nanti *) Solusi Ketersediaan Tinggi daripada Selalu Di AG dalam banyak keadaan, tetapi tidak memiliki kemampuan untuk menawarkan replika sekunder yang dapat dibaca. Menambahkan replika sekunder Always On AG yang dapat dibaca menjadi opsi yang layak untuk mengatasi kebutuhan ini. Dan menggunakan SIOS DataKeeper menghilangkan kebutuhan untuk SAN untuk SQL Server FCI, yang membuka kemungkinan mengkonfigurasi SQL Server FCI di mana node berada di pusat data yang berbeda, yang juga berarti dukungan untuk SQL Server FCI yang menjangkau Zona Ketersediaan di Azure dan AWS. Harap perhatikan bahwa gambar di bawah ini hanya satu konfigurasi yang memungkinkan. Beberapa node cluster FCI, beberapa AG, dan beberapa Replika semuanya didukung. Anda hanya dibatasi oleh batasan yang diberlakukan oleh versi SQL Server Anda. Artikel ini sepertinya mendokumentasikan langkah-langkah pengaturan dengan cukup baik. Tentu saja, alih-alih penyimpanan bersama untuk SQL FCI, Anda akan menggunakan SIOS DataKeeper untuk membangun FCI seperti yang saya dokumentasikan di sini.

Grup Ketersediaan Dasar

Pada SQL Server 2016 yang diperkecil "Kelompok Ketersediaan Dasar" menjadi tersedia di SQL Server Edisi Standar, membuat konfigurasi ini mungkin bahkan dalam SQL Server Edisi Standar. AG Dasar terbatas pada basis data tunggal per Grup yang Tersedia, Replika Tunggal (2-simpul). Namun, mereka tidak mendukung replika sekunder yang dapat dibaca sehingga kasus penggunaannya dalam konfigurasi hibrid ini sangat terbatas.

Grup Ketersediaan yang Didistribusikan

AG terdistribusi yang diperkenalkan di SQL Server 2016 juga didukung dalam konfigurasi hibrid ini. AG terdistribusi sangat mirip dengan AG biasa, tetapi Replika tidak perlu berada di cluster yang sama, atau bahkan di Domain Windows yang sama. Microsoft mendokumentasikan kasus penggunaan utama dari Grup Ketersediaan Terdistribusi sebagai berikut:

• Pemulihan bencana dan konfigurasi multi-situs yang lebih mudah
• Migrasi ke perangkat keras atau konfigurasi baru, yang mungkin termasuk menggunakan perangkat keras baru atau mengubah sistem operasi yang mendasarinya
• Meningkatkan jumlah replika yang dapat dibaca melebihi delapan dalam satu kelompok ketersediaan tunggal dengan menjangkau beberapa kelompok ketersediaan

Ringkasan

Jika Anda menyukai gagasan SQL Server FCI untuk SQL Server ketersediaan tinggi, tetapi menginginkan fleksibilitas replika sekunder hanya baca, solusi hibrid ini mungkin hanya hal yang Anda cari. FCI SQL Server tradisional berbasis FCI, dan bahkan FCI berbasis Storage Spaces Direct (S2D), membatasi Anda untuk pusat data tunggal. SIOS DataKeeper membebaskan Anda dari batas SAN Anda dan memungkinkan konfigurasi seperti SQL Server FCI yang menjangkau Zona Ketersediaan atau Wilayah Cloud. Ini juga menghilangkan ketergantungan pada SAN, memungkinkan Anda untuk memanfaatkan perangkat penyimpanan berkecepatan tinggi yang terpasang secara lokal tanpa melepaskan SQL Server Failover Cluster Instance Anda.

* Cara Menghemat Uang

Sebelumnya saya berjanji saya akan memberitahu Anda bagaimana cara menghemat uang dengan melakukan ini semua dengan SQL Server Standard Edition. Jika Anda dapat hidup dengan replika yang dapat dibaca yang merupakan snapshot berbasis waktu, Anda dapat melewati Always On AGs sepenuhnya dan cukup gunakan fitur snapshot sisi target SIOS DataKeeper untuk secara berkala mengambil snapshot konsisten volume aplikasi di server target tanpa memengaruhi replikasi yang sedang berlangsung atau ketersediaan. Begini caranya …

Buat 2-node SQL Server FCI dengan SQL Server Standard Edition dan hemat sejumlah uang pada lisensi SQL. Namun masih mereplikasi data ke simpul ke-3 di luar cluster untuk tujuan pelaporan atau DR. Jika Anda mengambil snapshot dari volume di server ketiga ini, snapshot ini dapat diakses dengan benar. Dengan cara ini, Anda dapat me-mount database tersebut dari instance SQL Server mandiri untuk menjalankan laporan akhir bulan, menyalin ke arsip, atau Anda bahkan mungkin ingin menggunakan snapshot itu untuk secara cepat dan mudah memperbarui lingkungan QA dan Test / Dev Anda dengan SQL terbaru data. Saya harap Anda menemukan panduan untuk membuat untuk mencapai SQL Server ketersediaan tinggi, pemulihan bencana dengan campuran Grup Ketersediaan Selalu dan Instan SQL Server Failover Failover Cluster berguna.

Perangkat Lunak SIOS Memberikan Perlindungan Data Ketersediaan Tinggi

Perangkat Lunak SIOS Menghadirkan Perlindungan Data Ketersediaan Tinggi di Lingkungan Awan yang Ramah Pengguna

Bonfiglioli adalah perusahaan desain, manufaktur, dan distribusi Italia terkemuka yang berspesialisasi dalam otomasi industri, mesin ponsel, dan produk energi angin. Dengan lebih dari 3.600 karyawan di lokasi di seluruh dunia, perusahaan bergantung pada infrastruktur dan aplikasi TI-nya seperti aplikasi Enterprise Resource Planning (ERP) yang kritis untuk menjalankan operasi bisnis dengan lancar. Mereka memilih untuk menggunakan SIOS DataKeeper untuk mengatasi hambatan dalam memindahkan sistem SAP ERP yang penting bagi bisnis ke cloud.

Tantangan

Tim TI perusahaan yang berpandangan ke depan ini mengimplementasikan program untuk memindahkan bagian dari operasi TI mereka ke cloud Microsoft Azure dalam pendekatan bertahap dan metodis. Aspek kunci lainnya adalah memanfaatkan Azure sebagai situs Pemulihan Bencana. Komponen utama dari perencanaan migrasi mereka adalah memastikan bahwa mereka masih dapat memenuhi SLA yang ketat untuk kinerja aplikasi dan menikmati Perlindungan Data Ketersediaan Tinggi di cloud. Operasi di lingkungan di tempat mereka dilindungi oleh VMware clustering yang memungkinkan Windows Server Failover Clustering untuk mengelola failover operasi ke server sekunder jika terjadi kesalahan atau kegagalan infrastruktur. Memberikan jenis perlindungan ini di cloud menimbulkan tantangan karena pengelompokan tamu dengan disk bersama-bus bukanlah solusi yang layak di cloud publik.

Evaluasi

Bonfiglioli mempertimbangkan berbagai opsi untuk melindungi sistem SAP ERP mereka yang sensitif dan kritis terhadap bisnis. Mereka meminta nasihat dari konsultan Manajemen BGP mereka. Berdasarkan pengalaman mereka yang luas dalam membantu perusahaan seperti Bonfiglioli memberikan perlindungan ketersediaan tinggi untuk aplikasi penting di cloud, BGP disarankan menggunakan SIOS DataKeeper Cluster Edition. Perangkat lunak SIOS DataKeeper memiliki beberapa keunggulan utama. Pertama, SIOS DataKeeper adalah satu-satunya solusi pengelompokan ketersediaan tinggi bersertifikat untuk SAP di cloud publik. Kedua, BGP memiliki pengalaman langsung dengan SIOS DataKeeper. Mereka tahu bahwa itu sangat sederhana untuk menginstal, transparan ke OS, dan solusi terbukti, sangat efektif.

Solusinya

Membuat cluster di VMware menggunakan Raw Device Mapping dan shared-bus disk (RDM) sangat menantang dan menciptakan batasan untuk membuat cadangan VM. SIOS DataKeeper menghapus hambatan ini dengan mengaktifkan Bonfiglioli untuk membuat lingkungan cluster tanpa perlu RDM. Mereka hanya membuat cluster dua simpul di VMware. SIOS DataKeeper Cluster Edition ditambahkan untuk menyinkronkan penyimpanan di setiap instance cluster. Penyimpanan yang disinkronkan muncul ke WSFC sebagai disk penyimpanan bersama tunggal di lingkungan di tempat mereka. Perangkat lunak SIOS DataKeeper juga menyediakan perlindungan data ketersediaan tinggi untuk SAP Central Services Instance mereka. Serta menghilangkan satu titik risiko kegagalan arsitektur SAP Netweaver. SIOS DataKeeper mereplikasi partisi disk berjenjang SSD di pusat data lokal perusahaan. Dengan demikian memungkinkan Bonfiglioli untuk memulihkan VM mereka di Microsoft Azure jika terjadi bencana

Hasil

Daniele Bovina, System Architect, Bonfiglioli mengatakan bahwa produk SIOS DataKeeper bersertifikasi SAP. Terbaik dari semua, itu sangat solid dan sangat transparan untuk OS. Ini memungkinkan mereka untuk mengambil keuntungan dari semua kesederhanaan dan manfaat dari Cluster Failover Windows Server. Dan juga efisiensi biaya dan fleksibilitas cloud Microsoft Azure. Untuk mengetahui lebih lanjut tentang produk SIOS, buka di sini Untuk membaca tentang bagaimana SIOS membantu Bonfiglioli mencapai Perlindungan Data Ketersediaan Tinggi, buka di sini

SIOS DataKeeper Cluster Edition Memberikan Perlindungan Ketersediaan Tinggi

SIOS DataKeeper Cluster Edition Menghadirkan Perlindungan Ketersediaan Tinggi, Fleksibilitas Konfigurasi, Efisiensi Bandwidth

Penyedia layanan informasi kesehatan terkemuka melayani lebih dari 10.000 organisasi layanan kesehatan di seluruh Amerika Serikat. Mereka mengandalkan database SQL Server mereka untuk memberikan berbagai layanan. Ini termasuk manajemen pendapatan, layanan mandiri pasien, dan sistem manajemen perawatan pasien. SIOS DataKeeper Cluster Edition menghilangkan masalah bandwidth, meningkatkan perlindungan data, dan secara signifikan mengurangi waktu henti dalam lingkungan jaringan layanan kesehatan yang kritis.

Lingkungan

Perusahaan ini memiliki lebih dari 20 cluster SQL Server yang terletak di dua pusat data yang terpisah secara geografis untuk dukungan data primer dan pemulihan bencana. Mereka juga memiliki server yang lebih kecil di jaringan mereka, serta pengiriman log SQL Server untuk pemulihan bencana. Karena basis pelanggan yang luas dan infrastruktur TI, perusahaan memerlukan solusi Perlindungan Ketersediaan Tinggi yang aman dan andal. Sesuatu yang dapat secara efisien menangani lalu lintas jaringan yang berat, membatasi jumlah data yang berisiko, dan mengurangi waktu henti.

Tantangan

Replikasi ke situs pemulihan bencana perusahaan membanjiri bandwidth, yang mengurangi keandalan di seluruh jaringan. Jaringan yang andal sangat penting untuk memelihara dan memproses data pasien dan tagihan untuk rumah sakit dan klien penyedia layanan kesehatan perusahaan. Perusahaan juga membutuhkan Perlindungan Ketersediaan Tinggi yang andal dan efisien untuk meningkatkan sasaran titik pemulihan (RPO). Ini berarti mereka perlu membatasi jumlah data yang berisiko secara signifikan. RPO ditentukan oleh jumlah waktu antara peristiwa perlindungan data dan berapa banyak data yang bisa hilang selama pemulihan bencana. Perusahaan berusaha untuk memperbaiki target waktu pemulihan (RTO), yang merupakan panjang maksimum waktu henti yang dapat ditoleransi setelah bencana atau kegagalan.

Solusinya

Perusahaan memilih SIOS DataKeeper Cluster Edition. Tetapi sebelum mereka menggunakannya, mereka menjalankan proof-of-concept (POC) untuk memastikan itu akan menyediakan fungsionalitas yang diperlukan. POC adalah tes stres di kedua sisi jaringan, menggunakan file data simulasi yang sangat besar. Sepanjang pengujian, staf TI menyaksikan kegagalan SQL Server berhasil dan melanjutkan mirroring dalam lingkungan tingkat perubahan yang tinggi. Menambahkan Fleksibilitas Konfigurasi yang Tak Tertandingi, perangkat lunak SIOS DataKeeper Cluster Edition menyediakan replikasi tingkat blok berbasis host yang efisien untuk menyinkronkan penyimpanan di SAN dengan penyimpanan lokal di situs DR mereka. Itu menambah fleksibilitas konfigurasi untuk membuat lingkungan Windows Server Failover Clustering menggunakan pilihan Anda penyimpanan berbasis SAN, SANless, atau hybrid. Setelah SIOS DataKeeper Cluster Edition lulus pengujian POC ketat perusahaan, mereka menyebarkannya ke lingkungan produksi mereka. Mereka menciptakan cluster tiga simpul. Terdiri dari dua simpul berbasis SAN di pusat data utama, di tempat dan satu simpul SANless di lokasi pemulihan bencana jarak jauh mereka.

Hasil

SIOS DataKeeper Cluster Edition mensinkronisasi replikasi di antara ketiga node dalam cluster. Pada saat yang sama, itu menghilangkan masalah bandwidth di situs pemulihan bencana. Perusahaan melihat peningkatan substansial dalam titik pemulihan dan sasaran waktu pemulihan serta mengurangi biaya bandwidth. Perusahaan sekarang menggunakan SIOS DataKeeper untuk melindungi SQL Server penting mereka di lebih dari 18 node cluster. Untuk mengetahui lebih lanjut tentang produk SIOS, buka di sini Untuk membaca tentang bagaimana SIOS DataKeeper Cluster Edition Memberikan Perlindungan Ketersediaan Tinggi, buka di sini

SIOS DataKeeper Menyediakan Ketersediaan Tinggi untuk Sistem Mission-Critical

SIOS DataKeeper Menyediakan Ketersediaan Tinggi untuk Sistem Mission-Critical

Dengan menambahkan SIOS DataKeeper Cluster Edition ke lingkungan Windows Server Failover Clustering di cloud Amazon Web Services, pengecer global ini memigrasi infrastruktur yang kompleks ke cloud dengan mudah dan tanpa downtime.

Perangkat Lunak SIOS Menghadirkan Perlindungan Data Ketersediaan Tinggi di Lingkungan Awan yang Ramah Pengguna

Sebuah permainan video multichannel global, elektronik konsumen, dan pengecer layanan nirkabel memiliki lebih dari 7.600 toko di seluruh dunia. Ketika pengecer memutuskan untuk memigrasikan infrastrukturnya ke lingkungan Windows di cloud Amazon Web Services (AWS), mereka membutuhkan solusi yang aman dan andal yang dapat menangani ribuan transaksi pelanggan setiap hari dan skala untuk memenuhi permintaan yang meningkat. Migrasi perlu diselesaikan dengan cepat dan mudah tanpa downtime. Menyimpan instance EMS yang ada adalah persyaratan wajib.

Tantangan

Agar migrasi ini berhasil, pengecer membutuhkan cara yang mudah, efisien biaya untuk menyediakan Ketersediaan Tinggi untuk Sistem Misi-Kritis.

Solusinya

Untuk memenuhi persyaratan ini, staf TI pengecer cukup menambahkan SIOS DataKeeper Cluster Edition ke lingkungan Windows Server Failover Clustering di cloud AWS. Perangkat lunak SIOS sepenuhnya terintegrasi dengan WSFC. Ini memberikan panduan konfigurasi yang mudah digunakan untuk pengaturan yang cepat dan efisien. Cluster ini mempertahankan ketersediaan tinggi untuk perangkat lunak misi-kritis pengecer. Jika WSFC gagal ke node cluster jarak jauh, SIOS DataKeeper memastikan aplikasi memiliki akses langsung ke salinan cermin penyimpanan. Operasi pengecer dapat berlanjut setelah kegagalan tanpa downtime atau kehilangan data. Perangkat lunak SIOS menciptakan lingkungan yang tahan terhadap kesalahan yang memenuhi persyaratan ketersediaan tinggi pengecer.

Hasil

SIOS DataKeeper Cluster Edition memberi pengecer Ketersediaan Tinggi untuk Sistem Misi-Kritis yang mereka butuhkan. Dan pada saat yang sama, menghilangkan risiko yang terkait dengan satu titik kegagalan dalam konfigurasi SAN cluster penyimpanan bersama. Proses failover SIOS mengaktifkan pemulihan sistem dan aplikasi otomatis serta mencegah kehilangan data jika server turun. Ini memungkinkan pelanggan pengecer untuk berbelanja dan memesan secara online dengan aman tanpa gangguan. Untuk mengetahui lebih lanjut tentang produk SIOS, buka di sini Untuk membaca tentang secara terperinci bagaimana SIOS menyediakan Ketersediaan Tinggi untuk Sistem Mission-Critical, buka di sini