Archives

Cara Memperpanjang Instans Failover Cluster SQL Server Anda yang Ada Ke Cloud Untuk Pemulihan Bencana

Juni 17, 2021 by Jason Aw Leave a Comment

Cara Memperpanjang Instans Failover Cluster SQL Server Anda yang Ada Ke Cloud Untuk Pemulihan Bencana

Biasanya saya mengarahkan mereka ke ini Dokumentasi DataKeeper ketika seseorang bertanya kepada saya bagaimana cara memperluas Instans SQL Server Failover Cluster yang ada ke Cloud for Disaster Recovery.

Dokumen pertama ini berbicara tentang memperluas cluster dan menambahkan node ke-3 ke cluster yang ada. Tidak apa-apa jika cluster Anda mendukung tiga node. Tetapi jika Anda menggunakan SQL Server Standard Edition, Microsoft membatasi Anda ke cluster 2-simpul. Dalam kasus cluster 2-simpul. Anda masih dapat mereplikasi ke simpul ke-3. Ingatlah bahwa pemulihan akan lebih merupakan proses manual. Proses ini dijelaskan sini .

Orang biasanya membaca petunjuk ini dan menjadi sedikit khawatir. Mereka merasa seperti akan melakukan operasi jantung terbuka di cluster mereka. Ini benar-benar lebih seperti mengganti baju Anda! Anda cukup mengganti sumber daya Cluster Disk dengan sumber daya Volume DataKeeper. Seperti yang akan Anda lihat dalam video di bawah, prosesnya hanya membutuhkan beberapa detik.

Kode yang ditunjukkan dalam video ditunjukkan di bawah ini.

Stop-ClusterGroup SQLServerGroup Hapus-ClusterResource -Nama "Cluster Disk 1" Set-Disk -Nomor 4 -IsOffline $False Set-Disk -Number 4 -IsReadOnly $False Import-Module -Name Storage Set-Partition -DiskNumber 4 -PartitionNumber 1 - NewDriveLetter X New-DataKeeperMirror -SourceIP 10.0.2.100 -SourceVolume X -TargetIP 10.0.1.10 -TargetVolume X -SyncType Sync New-DataKeeperJob -JobName "x drive" -JobDescription "sql data" -Node1Name primary.datakeeper.localIP 10.0. 2.100 -Node1Volume x -Node2Name dr.datakeeper.local -Node2IP 10.0.1.10 -Node2Volume X -SyncType Sync Add-ClusterResource -Name "DataKeeper Volume X" -ResourceType "DataKeeper Volume" -Group "SQLServerGroup" Get-ClusterResource "DataKeeper Volume X " | Set-ClusterParameter VolumeLetter X Get-ClusterResource -Nama 'SQLServer' | Add-ClusterResourceDependency -Penyedia 'DataKeeper Volume X' Start-ClusterGroup SQLServerGroup

Setelah Anda menjalankan kode itu jangan lupa Anda juga perlu mengklik Kelola Volume Bersama untuk menambahkan node cadangan ke pekerjaan DataKeeper seperti yang ditunjukkan dalam video.

Jika Anda memiliki SQL Server Enterprise Edition maka langkah terakhir adalah menginstal SQL Server di DR node dan pilih add node to existing cluster.

Jika Anda menggunakan SQL Server Standard Edition maka pekerjaan Anda selesai. Anda cukup mengikuti petunjuk ini untuk mengakses data Anda pada simpul ke-3 dan kemudian memasang basis data yang direplikasi.

Petunjuk ini berlaku baik node DR Anda ada di Cloud atau situs DR Anda sendiri.

Tentang Menggunakan Amazon FSX untuk Instans Cluster Failover SQL Server

Februari 14, 2021 by Jason Aw Leave a Comment

Menggunakan Amazon FSX untuk Instans Cluster Failover SQL Server – Yang Perlu Anda Ketahui!

Jika Anda sedang mempertimbangkan untuk menerapkan instans Microsoft SQL Server Anda sendiri di AWS EC2, Anda harus mengambil beberapa keputusan terkait ketahanan solusi. Tentu, AWS akan menawarkan 99,99% SLA pada sumber daya Compute Anda jika Anda menerapkan dua atau lebih instans di zona ketersediaan yang berbeda. Namun jangan tertipu, ada banyak faktor lain yang perlu Anda pertimbangkan saat menghitung ketersediaan aplikasi Anda yang sebenarnya. Baru-baru ini saya membuat blog tentang cara menghitung ketersediaan aplikasi Anda di cloud. Anda mungkin harus membaca artikel itu dengan cepat sebelum melanjutkan.

Ketika datang untuk memastikan instans Microsoft SQL Server Anda sangat tersedia, itu benar-benar tergantung pada dua pilihan dasar: Always On Availability Group (AG) atau SQL Server Failover Cluster Instance (FCI). Jika Anda membaca artikel ini, saya berasumsi bahwa Anda sangat memahami kedua opsi ini dan secara serius mempertimbangkan untuk menggunakan Instans Cluster Failover SQL Server, bukan SQL Server Always On AG.

Manfaat Instans Cluster Failover Microsoft SQL Server

Daftar berikut meringkas apa yang dikatakan AWS sebagai manfaat dari SQL Server FCI:

FCI umumnya lebih disukai daripada AG untuk penerapan ketersediaan tinggi SQL Server ketika berikut ini adalah masalah prioritas untuk kasus penggunaan Anda:

Efisiensi biaya lisensi: Anda memerlukan lisensi Edisi Perusahaan dari SQL Server untuk menjalankan AG, sedangkan Anda hanya memerlukan lisensi Edisi Standar untuk menjalankan FCI. Ini biasanya 50–60% lebih murah daripada Edisi Perusahaan. Meskipun Anda dapat menjalankan AG versi Dasar pada Edisi Standar mulai dari SQL Server 2016, versi ini memiliki batasan untuk hanya mendukung satu database per AG. Ini bisa menjadi tantangan saat berhadapan dengan aplikasi yang membutuhkan banyak database seperti SharePoint.

Perlindungan tingkat instance versus perlindungan tingkat database: Dengan FCI, seluruh instance dilindungi – jika node utama tidak tersedia, seluruh instance akan dipindahkan ke node standby. Ini menangani login SQL Server, pekerjaan Agen Server SQL, sertifikat, dll. Yang disimpan di database sistem, yang secara fisik disimpan di penyimpanan bersama. Sebaliknya, dengan AG, hanya database dalam grup yang dilindungi, dan database sistem tidak dapat ditambahkan ke AG – hanya database pengguna yang diizinkan. Ini adalah tanggung jawab administrator database untuk mereplikasi perubahan ke objek sistem pada semua replika AG. Ini menyisakan kemungkinan kesalahan manusia yang menyebabkan database menjadi tidak dapat diakses oleh aplikasi.

Dukungan fitur DTC: Jika Anda menggunakan SQL Server 2012 atau 2014, dan aplikasi Anda menggunakan Distributed Transaction Coordinator (DTC), Anda tidak dapat menggunakan AG karena tidak didukung. Gunakan FCI dalam situasi ini.

https://aws.amazon.com/blogs/storage/simplify-your-microsoft-sql-server-high-availability-deployments-using-amazon-fsx-for-windows-file-server/

Tantangan Dengan FCI In The Cloud

Tentu saja. Tantangan dalam membangun FCI yang mencakup zona ketersediaan adalah kurangnya perangkat penyimpanan bersama yang biasanya diperlukan. Karena node cluster didistribusikan di beberapa pusat data, SAN tradisional bukanlah pilihan yang layak untuk penyimpanan bersama. Itu membuat kami memiliki dua pilihan untuk penyimpanan klaster: sumber daya kelas penyimpanan pihak ketiga seperti SIOS DataKeeper atau Amazon FSx baru.

Mari kita lihat apa yang perlu Anda ketahui sebelum Anda membuat pilihan.

PERSETUJUAN TINGKAT LAYANAN

Seperti yang saya tulis di cara menghitung ketersediaan aplikasi Anda, SLA aplikasi Anda secara keseluruhan hanya sebagus tautan terlemah Anda. Dalam hal ini, FSx SLA 99,9%.

Biasanya 99,99% ketersediaan mewakili titik awal dari apa yang dianggap "sangat tersedia". Inilah yang dijanjikan AWS untuk sumber daya komputasi Anda ketika dua atau lebih disebarkan di zona ketersediaan yang berbeda.

Jika Anda tidak tahu perbedaan antara tiga sembilan dan empat sembilan…

Ketersediaan 99,9% memungkinkan waktu henti 43,83 menit per bulan
Ketersediaan 99,99% hanya memungkinkan waktu henti 4,38 menit per bulan

Dengan menghosting penyimpanan cluster Anda di FSx terlepas dari 99,99% ketersediaan komputasi Anda, ketersediaan aplikasi Anda secara keseluruhan akan menjadi 99,9%. Sebaliknya, volume EBS yang menjangkau zona ketersediaan, seperti dalam penerapan DataKeeper, memenuhi syarat untuk 99,99% SLA di lapisan penyimpanan dan komputasi. Ini berarti ketersediaan aplikasi Anda secara keseluruhan adalah 99,99%.

LOKASI PENYIMPANAN

Saat mengonfigurasi FSx untuk ketersediaan tinggi, Anda mungkin ingin mengaktifkan dukungan multi-AZ. Dengan mengaktifkan multi-AZ Anda memiliki AZ "pilihan" dan AZ "siaga" secara efektif. Saat Anda menerapkan node SQL Server FCI, Anda akan ingin mendistribusikan node tersebut ke AZ yang sama.

Sekarang dalam situasi normal, Anda ingin memastikan node cluster aktif berada di AZ yang sama dengan node penyimpanan FSx pilihan. Ini untuk meminimalkan jarak dan latensi ke penyimpanan Anda. Tetapi juga untuk meminimalkan biaya yang terkait dengan transfer data di seluruh AZ. Sebagaimana ditentukan dalam panduan harga FSx, "Biaya transfer data standar berlaku untuk akses antar-AZ atau antar-wilayah ke sistem file."

Dalam keadaan yang tidak menguntungkan di mana Anda mengalami kegagalan SQL Server FCI, tetapi bukan kegagalan FSx, tidak ada mekanisme untuk mengikat penyimpanan dan penghitungan bersama. Jika FSx gagal, secara otomatis gagal kembali ke zona ketersediaan utama. Namun, praktik terbaik menentukan SQL FCI tetap berjalan di node sekunder hingga analisis akar masalah dilakukan dan kegagalan kembali biasanya dijadwalkan untuk terjadi selama periode pemeliharaan. Ini membuat Anda berada dalam situasi di mana penyimpanan Anda berada di AZ yang berbeda, yang akan menimbulkan biaya tambahan. Saat ini biaya untuk mentransfer data di seluruh AZ, baik masuk maupun keluar, adalah $ 0,01 / GB.

Tanpa memperhatikan status FSx dan SQL Server FCI Anda, Anda bahkan mungkin tidak menyadari bahwa keduanya berjalan di wilayah yang berbeda hingga Anda melihat biaya transfer data di akhir bulan.

Sebaliknya, dalam konfigurasi yang menggunakan SIOS DataKeeper, penyimpanan failover adalah bagian dari pemulihan SQL Server FCI, memastikan bahwa penyimpanan selalu gagal dengan contoh SQL Server. Ini memastikan SQL Server selalu membaca dan menulis ke volume EBS yang langsung terpasang ke node aktif. Perlu diingat, DataKeeper akan dikenakan biaya transfer data terkait dengan operasi tulis yang direplikasi antara AZ atau wilayah. Biaya transfer data ini dapat diminimalkan dengan penggunaan kompresi yang tersedia di DataKeeper.

MENGONTROL KEGAGALAN

Dalam konfigurasi multi-subnet FSx, terdapat zona ketersediaan pilihan dan ketersediaan siaga. Jika server file FSx di zona ketersediaan yang disukai mengalami kegagalan, server file di AZ siaga akan pulih. AWS melaporkan bahwa waktu pemulihan ini membutuhkan waktu sekitar 30 detik dengan pembagian standar. Dengan penggunaan berbagi file yang tersedia secara terus menerus, Microsoft melaporkan waktu failover ini dapat mendekati 15 detik. Selama waktu failover ini, terjadi penurunan yang terjadi saat pembacaan dan penulisan dijeda, tetapi akan berlanjut setelah pemulihan selesai.

Multi-situs FSx mengaktifkan failback otomatis. Ini berarti bahwa untuk setiap failover FSx yang tidak direncanakan, Anda juga memiliki failback yang tidak direncanakan. Sebaliknya, biasanya saat SQL Server FCI mengalami failover yang tidak direncanakan, Anda akan membiarkannya berjalan di sekunder atau menjadwalkan failback setelah jam kerja atau selama periode pemeliharaan berikutnya.

SQL SERVER ANALYSIS SERVICES CLUSTER TIDAK DIDUKUNG DENGAN FSX

Jika Anda ingin mengelompokkan SSAS, Anda memerlukan sumber daya disk berkerumun seperti SIOS DataKeeper. Buku putih Cara Mengelompokkan SQL Server Analysis Server dengan jelas menyatakan bahwa SMB tidak dapat digunakan dan pengandar kluster dengan huruf kandar harus digunakan. Sebaliknya, sumber daya Volume DataKeeper menampilkan dirinya sebagai disk berkerumun dan dapat digunakan dengan SSAS.

Ringkasan

Meskipun FSx dapat dimengerti untuk penggunaan UKM biasa seperti file pengguna Windows dan layanan non-kritis lainnya di mana 99,9% ketersediaan SLA mencukupi, FSx adalah pilihan yang sangat baik Jika aplikasi Anda membutuhkan ketersediaan tinggi (99,99%) atau solusi HA / DR yang juga mencakup wilayah, SIOS DataKeeper adalah pilihan yang tepat.

Direproduksi dengan izin dari Clusteringformeremortals

Mengkonfigurasi contoh SQL Server Failover Cluster pada mesin virtual Azure

April 4, 2019 by Jason Aw Leave a Comment

Mengkonfigurasi contoh SQL Server Failover Cluster pada mesin virtual Azure dengan Msdtc #Sql #Azure #Msdtc

Anda mungkin tahu bahwa kami telah menyertakan banyak panduan langkah demi langkah untuk membangun SQL Server Failover Cluster Instances (FCI) di Azure, dari SQL Server 2008 hingga yang terbaru. Berikut ini beberapa tautan untuk membantu Anda memulai. Tetapi sebenarnya ada sedikit perbedaan dalam konfigurasi antara versi Windows dan SQL Server yang berbeda. Jadi saya pikir Anda akan dapat mengetahuinya terlepas dari versi apa yang Anda gunakan. LANGKAH-LANGKAH-LANGKAH: CARA MENGONFIGURASI SQL SERVER FAILOVER CLUSTER INSTANCE (FCI) DI MICROSOFT AZURE IAAS #SQLSERVER #AZURE #SANLESS LANGKAH DENGAN-LANGKAH: BAGAIMANA CARA KONFIGURASI SQL SERVER 2008 R2 FAILOVER INSTANCE IN AZURE tidak ditujukan apa yang harus dilakukan tentang MSDTC. Microsoft mengalamatkan hal itu dalam artikel ini yang diposting di sini. https://blogs.msdn.microsoft.com/sql_pfe_blog/2018/07/05/configure-sql-server-failover-cluster-instance-onstaz-viure-virtual-machines-with-msdtc Namun, artikel / video itu saja alamat SQL Server 2016 dan yang lebih baru. Berita baiknya adalah bahwa sebagian besar panduan itu dapat diterapkan ke SQL Server 2008/2012/2014. Sampai saya punya waktu untuk melakukan panduan langkah demi langkah yang tepat, saya ingin menuliskan beberapa catatan dasar, lebih sebagai pengingat bagi diri saya sendiri. Namun, Anda mungkin menemukan informasi ini berguna untuk sementara waktu. Langkah-langkah di bawah ini menganggap Anda telah membuat SQL Server FCI di Azure dan mengelompokkan sumber daya DTC. Referensi panduan di atas untuk perincian tentang langkah-langkah tersebut. Langkah-langkah di bawah ini benar-benar hanya merinci konfigurasi penyeimbang beban yang diperlukan di Azure untuk membuat pekerjaan ini.

Buat Load Balancer Untuk MSDTC

Sumber daya MSDTC akan membutuhkan load balancer-nya sendiri. Alih-alih membuat penyeimbang beban baru, kami akan menambahkan antarmuka baru ke penyeimbang beban yang seharusnya sudah dikonfigurasi untuk SQL Server FCI. Tentu saja alamat IP frontend ini harus cocok dengan alamat IP cluster yang terkait dengan sumber daya MSDTC yang dikelompokkan. Untuk backend pool cukup gunakan kembali pool yang sudah Anda buat yang berisi node cluster SQL. Anda perlu membuat pemeriksaan kesehatan baru yang didedikasikan untuk sumber daya MSDTC. Port yang Anda gunakan harus berbeda dari yang Anda gunakan untuk sumber daya SQL. Jangan gunakan 59999. Mungkin menggunakan sesuatu seperti 49999. Langkah terakhir adalah membuat aturan keseimbangan muatan untuk MSDTC. Buat aturan baru dan referensi frontend MSDTC yang baru saja kita buat dan backend yang ada. Selanjutnya kita perlu membuat aturan keseimbangan beban baru. MSDTC menggunakan porta fana, yang merupakan sejumlah besar porta. Saat Anda membuat aturan, Anda harus memilih kotak yang mengatakan "HA Ports". Akhirnya, pastikan Direct Server Return diaktifkan.

Perbarui MSDTC Cluster IP Resource

Bekerja seperti alamat IP SQL Server Cluster. Kita perlu menjalankan perintah Powershell yang akan untuk sumber daya MSDTC cluster IP untuk menanggapi penyelidikan kesehatan yang baru saja kita buat yang memeriksa port 49999. Itu juga menetapkan subnet mask dari alamat IP MSDTC cluster ke 255.255.255.255 untuk menghindari konflik alamat IP dengan frontend penyeimbang beban yang kami atur yang berbagi alamat yang sama.

# Tentukan variabel $ ClusterNetworkName = ""  
# nama jaringan cluster (Gunakan Get-ClusterNetwork on 
Windows Server 2012 yang lebih tinggi untuk menemukan nama sumber daya MSDTC) 
$ IPResourceName = ""  
# nama sumber daya Alamat IP sumber daya MSDTC $ ILBIP = ""  
# Alamat IP Internal Load Balancer (ILB) dan sumber daya MSDTC 
Impor-Modul FailoverClusters 
# Jika Anda menggunakan Windows Server 2012 atau lebih tinggi: 
Dapatkan-ClusterResource $ IPResourceName | Set-ClusterParameter 
-Multiple @ {Alamat = $ ILBIP; ProbePort = 49999; 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

Konfirmasikan Berhasil!

Anda dapat menggunakan DTCPing atau masuk ke Layanan Komponen dan lihat di bawah Komputer> Komputer Saya> Koordinator Transaksi Terdistribusi di mana Anda akan melihat DTC lokal dan DTC berkerumun. Setiap transaksi terdistribusi harus muncul di DTC berkerumun, bukan DTC lokal. Lihat video ini untuk contoh cara membuat transaksi terdistribusi untuk pengujian.

Langkah selanjutnya

Ini adalah panduan cepat dan kotor. Untuk pengguna yang berpengalaman itu harus membuat sumber daya MSDTC Anda dan berjalan di Azure. Saya akan menerbitkan panduan langkah demi langkah terperinci dalam waktu dekat. Sementara itu, jika Anda buntu jangan ragu untuk menghubungi saya di Twitter @daveberm

Mencapai SQL Server Pemulihan Bencana Ketersediaan Tinggi Dengan DataKeeper

Maret 26, 2019 by Jason Aw Leave a Comment

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

Hasil gambar untuk grup ketersediaan yang didistribusikan

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 …

http://discover.us.sios.com/rs/siostechnology/images/10-Ways-Save-AlwaysOn-vs-Failover-Clustering.pdf

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.