Dengan asumsi Anda perlu memastikan aplikasi Anda yang mengandalkan SQL Server 2012 sebagai backend database tersedia sepanjang waktu, bahkan jika satu mesin server gagal.

Sebagai pengembang dan bukan DBA, saya berjuang untuk memahami kapan harus menggunakan skenario mana untuk failover / ketersediaan tinggi saya:

• Dua (atau lebih) server di cluster Windows Failover, SQL Server sebagai contoh berkerumun
• Dua (atau lebih) contoh SQL Server yang diperbarui dengan replikasi transaksional
• Dua (atau lebih) Server SQL dalam Grup Ketersediaan Server SQL, yang dikonfigurasi dalam mode komit sinkron

Manakah dari masing-masing skenario yang berfungsi untuk jenis beban kerja apa, dan kegagalan / pemadaman seperti apa yang dapat ditangani oleh skenario tersebut? Apakah mereka dapat dibandingkan / dipertukarkan?

Cara saya selalu memvisualisasikan solusi ketersediaan tinggi adalah sebagai berikut:

Contoh SQL Server Failover Cluster (FCI)

Apa yang sangat tersedia? Seluruh contoh. Itu termasuk semua objek server (login, pekerjaan SQL Server Agent, dll.). Ini juga termasuk basis data dan entitas yang mengandungnya. Ini adalah solusi yang bagus untuk instance SQL Server yang sangat tersedia, karena itu akan menjadi level penahanan dengan solusi yang diberikan ini.

Bagaimana dengan pelaporan? Tidak ada, NULL, tidak ada. Sebuah instance kluster failover memiliki simpul aktif yang memberikan grup kluster yang berisi instance, VNN, dll. Dan semua node lainnya adalah pasif, duduk diam (sejauh menyangkut grup kluster saat ini) dan menunggu failover.

Apa yang terjadi ketika ada failover? Downtime untuk FCI akan ditentukan oleh jumlah waktu yang dibutuhkan node pasif untuk mengambil sumber daya cluster dan membawa contoh SQL Server dalam keadaan berjalan. Ini biasanya minimal dalam waktu.

Adakah abstraksi klien? Ya, ini akan bawaan bawaan dengan nama jaringan virtual untuk instance failover cluster. Ini akan selalu mengarah ke node aktif yang saat ini memberikan sumber daya gugus SQL Server.

Grup Ketersediaan AlwaysOn

Apa yang sangat tersedia? Grup ketersediaan akan menjadi penahanan logis ketersediaan tinggi di sini, sedangkan grup ketersediaan terdiri dari sejumlah database dan nama jaringan virtual (pendengar, sumber daya gugus opsional). Perlu dicatat bahwa objek server seperti login dan pekerjaan SQL Server Agent tidak akan menjadi bagian dari solusi HA, dan pertimbangan khusus perlu diambil untuk memastikan bahwa ini diterapkan dengan benar dengan grup ketersediaan. Bukan persyaratan yang terlalu membebani, tetapi perlu dirawat.

Bagaimana dengan pelaporan? Ini adalah solusi yang bagus untuk pelaporan, walaupun saya mungkin tidak akan menggunakan replika sinkron sebagai contoh pelaporan saya. Ada dua hubungan komit, sinkron dan asinkron. Menurut pendapat saya dan dari apa yang saya lihat dalam praktik, adalah bahwa replika sekunder sinkron Anda ada di sana menunggu bencana. Anggap saja sebagai replika yang siap untuk menerima kegagalan tanpa kehilangan data jika terjadi masalah. Lalu ada replika asinkron yang dapat menangani beban kerja pelaporan itu. Anda tidak menggunakan replika ini sebagai solusi yang disebutkan di atas, tetapi lebih untuk hal-hal seperti pelaporan. Melaporkan beban kerja dapat diarahkan ke replika ini (baik secara langsung, atau tidak langsung melalui perutean baca-saja melalui pendengar).

Apa yang terjadi ketika ada failover? Untuk replika sekunder yang dilakukan secara sinkron yang dipasangkan dengan failover otomatis, ini akan menjadi perubahan status peran replika dari SECONDARY_NORMAL ke PRIMARY_NORMAL. Agar terjadi failover otomatis, Anda harus memiliki replika sekunder sinkron yang saat ini disinkronkan, dan apa yang diterapkan adalah Kebijakan Kegagalan Failover untuk menentukan kapan sebenarnya kegagalan ini harus terjadi. Kebijakan itu memang dapat dikonfigurasi.

Adakah abstraksi klien? Ya, Anda dapat secara opsional mengkonfigurasi pendengar Grup AlwaysOn Availability. Ini pada dasarnya hanya nama jaringan virtual (dapat dilihat melalui WSFC sebagai sumber daya klaster dalam kelompok klaster AG) yang menunjuk ke replika primer saat ini. Ini adalah bagian penting dari pengalihan beban kerja pelaporan Anda, serta menyiapkan daftar perutean hanya-baca pada server apa pun yang Anda inginkan untuk mengarahkan lalu lintas ReadOnly (ini ditetapkan melalui string koneksi, dengan .NET Framework Provider untuk SQL Server, ini akan menjadi parameter Intent Aplikasi , diatur ke ReadOnly ). Anda juga perlu menetapkan URL perutean hanya-baca untuk setiap replika yang ingin Anda terima beban kerja pelaporan ini saat berada di peran replika sekunder.

Replikasi Transaksional

Apa yang sangat tersedia? Ini bisa diperdebatkan, tetapi saya tidak akan mengatakan apa-apa . Saya tidak melihat replikasi sebagai solusi ketersediaan tinggi apa pun. Ya, modifikasi data sedang didorong ke pelanggan tetapi kami sedang berbicara di tingkat publikasi / artikel. Ini akan menjadi himpunan bagian dari data (dapat mencakup semua data, tetapi itu tidak akan diberlakukan. Yaitu Anda membuat tabel baru dalam database penerbit, dan yang tidak akan secara otomatis didorong ke pelanggan). Sejauh HA berjalan, ini adalah bottom-of-the-barrel dan saya tidak akan mengelompokkannya di sana dengan solusi HA yang solid.

Bagaimana dengan pelaporan? Solusi hebat untuk melaporkan subset data, tidak ada pertanyaan tentang itu. Jika Anda memiliki basis data 1 TB yang sangat transaksional dan Anda ingin menjaga agar beban kerja pelaporan dari basis data OLTP, replikasi transaksional adalah cara yang bagus untuk mendorong subset data ke pelanggan (atau pelanggan) untuk beban kerja pelaporan. Apa yang terjadi jika dari 1 TB data, beban kerja pelaporan Anda hanya sekitar 50 GB? Ini adalah solusi cerdas, dan relatif dapat dikonfigurasi untuk memenuhi kebutuhan bisnis Anda.

Ringkasan

Apa yang muncul adalah beberapa pertanyaan yang perlu dijawab (sebagian oleh bisnis):

1. Apa yang perlu tersedia sangat tinggi ?
2. Apa yang ditentukan oleh SLA untuk HA / DR?
3. Apa jenis pelaporan akan berlangsung dan latency apa yang diterima?
4. Apa yang perlu kita tangani dengan HA yang tersebar secara geografis ? (replikasi penyimpanan mahal, tetapi harus dengan FCI. AG tidak memerlukan penyimpanan bersama dari contoh mandiri, dan Anda dapat menggunakan saksi berbagi file untuk kuorum yang berpotensi menghilangkan kebutuhan penyimpanan bersama)

dua (atau lebih) server di Windows Failover cluster, SQL Server sebagai contoh berkerumun

1. Jenis pekerjaan apa? "Tergantung" - tetapi serius, ini berguna untuk aplikasi online di mana Anda perlu memiliki data lokal di pusat Ketersediaan Tinggi. Anda terlindungi dari kegagalan satu mesin, atau satu sistem operasi. Login, pekerjaan, database baru, pemeliharaan, dll. Semua secara otomatis disimpan dalam sinkronisasi oleh fakta bahwa itu adalah cluster dengan dua node yang persis sama berbagi penyimpanan yang sama sehingga mereka memiliki semua database sistem yang sama. Failover sangat cepat, tetapi masih ada cegukan yang tampak seperti SQL Server restart ketika failover terjadi.

2. Kekurangan / Kekhawatiran - Satu-satunya titik kegagalan adalah penyimpanan Anda dan semua komponennya. Vendor SAN selalu mengatakan "SAN tidak gagal" tetapi ada banyak bagian yang bergerak dalam jaringan area penyimpanan dan seperti yang saya blog di sini , mereka bisa. Juga - Anda membayar untuk server sekunder yang tidak bisa melakukan apa-apa selain menunggu dan menunggu .. Sekarang Anda dapat melakukan Active / Active / Multi-Node dan memiliki dua instance aktif yang dapat failover di kedua arah dan menggunakan node kedua.

3. Kegagalan Otomatis? Otomatis "paling". Tidak perlu saksi, ini cluster. Ini adalah tugas dari sebuah cluster, untuk membuatnya semulus mungkin. Sekarang dengan semua ini, ketika failover terjadi Anda akan "merasakannya", karena SQL harus memulai atau koneksi harus menunjuk. Di sini ketika itu terjadi, pada dasarnya Anda akan merasa seperti restart SQL, DB kembali dan menjalankan recovery / etc.

Jika saya memiliki klien mengatakan "Saya ingin sepenuhnya dengan semua database, semua login, dll" di lingkungan Ketersediaan Tinggi di pusat data lokal saya karena saya memiliki toleransi yang sangat rendah untuk downtime, saya akan mempertimbangkan Failover Cluster Instances (meskipun Opsi terakhir yang Anda sebutkan adalah pesaing yang kuat, kecuali karena harus melakukan beberapa overhead manajemen). Saya mungkin akan melakukan FCI lokal dan AG async sekunder untuk melindungi terhadap kegagalan situs atau kegagalan SAN.

dua (atau lebih) contoh SQL Server yang diperbarui dengan replikasi transaksional

1. Jenis pekerjaan apa? Jujur saya tidak akan pergi ke sini untuk banyak kasus kebutuhan Ketersediaan Tinggi atau Pemulihan Bencana sebagai pilihan pertama. Tidak dalam SQL 2012 pasti. Tetapi pada dasarnya ini bagus jika Anda harus pergi ke pusat data yang tidak dekat, Anda tidak bisa menggunakan AG (mungkin masalah domain yang mencegah Anda menggunakan kluster windows yang diperlukan untuk AG), mungkin Anda ingin menjadi dalam standar SQL Server yang dapat melakukan replikasi, tetapi tidak AG tetapi Anda masih ingin memiliki kemampuan untuk membaca di sisi sekunder dan menjadi tidak sinkron.
2. Kekurangan / Kekhawatiran - Ini replikasi. Ini memiliki overhead, dapat keluar dari sinkronisasi, Anda dapat mengembangkan masalah dengan kinerja di sisi sumber, dll.
3. Kegagalan Otomatis - Tidak. Anda harus mengelolanya sendiri. Baik melalui CNAME yang menunjuk ke satu atau yang lain, dan Anda secara teoritis dapat menulis proses Anda sendiri untuk melakukan ini, tetapi di luar kotak? Catat di sini.

dua (atau lebih) Server SQL dalam Grup Ketersediaan Server SQL, yang dikonfigurasi dalam mode komit sinkron

Inilah yang saya telah membantu orang menerapkan lebih dan lebih belakangan ini, meskipun kadang-kadang saya masih pergi ke pengelompokan.

1. Apa Jenis Beban Kerja? Ini bagus ketika saya memiliki satu set database yang dapat dikelola untuk tetap sinkron, dan sumber daya dan waktu untuk memastikan bahwa pekerjaan, login, database baru, dll tetap sinkron (meskipun tim di SQL Skills telah membangun tambahan yang bagus untuk mengotomatiskan sebagian dari ini untuk Anda membuatnya lebih kuat dari suatu pilihan). Saya suka ini ketika saya ingin menjaga semuanya benar-benar terpisah. Saya melindungi terhadap masalah perangkat keras, masalah OS, masalah instalasi SQL, masalah patching dan masalah SAN / Storage. Saya juga mendapatkan manfaat dari kemampuan memiliki sekunder (Jika saya ingin membayar lisensi perusahaan untuk itu) menjadi sekunder aktif yang dapat saya baca, mengambil cadangan, dll. Plus di masa depan saya dapat menambahkan sepertiga sekunder yang tidak sinkron di situs jarak jauh dan memiliki failover / DR.
2. Cons / Concerns Licensing, jumlah maksimum replika, biaya lisensi untuk mengambil keuntungan dari beberapa manfaat terbesar (aktif sekunder), membutuhkan perusahaan, membutuhkan penyimpanan dua kali lebih banyak daripada clustering.
3. Kegagalan Otomatis - Ya. Ini dapat terjadi dengan pengaturan saksi, dan pengembang aplikasi Anda dapat terhubung ke pendengar alih-alih simpul sehingga kegagalan terjadi dengan tempat pendengar menunjuk dan Anda harus baik di sana. Jadi ya Anda bisa melakukannya di sini - dan harus - tetapi tentu saja Anda harus mengujinya dengan baik.

Ringkasan

HA dan DR berbeda. Dan teknologi ini membantu menyediakan bagian dari keduanya. Ketersediaan Tinggi berarti (bagi saya) bahwa Anda dapat dengan cepat memulihkan jika terjadi sesuatu yang buruk pada satu mesin, Anda memiliki Object Point Pemulihan yang pendek dan Objective Recovery Time Objective. Itu adalah clustering dan AG sinkron.

Disaster Recovery adalah "Anda bisa bangun ketika Anda mengalami kegagalan bahkan dalam solusi HA Anda. Bagi saya itu bisa AGs ketika Anda pergi ke pusat data lain, mirroring atau bahkan replikasi.

Penting juga untuk mempertimbangkan apa yang dibagikan .

Failover Clustering menggunakan dua atau lebih node server yang berbagi satu array disk. Jika array disk turun maka Anda kehilangan layanan, terlepas dari berapa banyak node server yang ada. Jika ruang server di mana array disk berada terkena kebakaran atau banjir maka Anda kehilangan layanan.

Grup Ketersediaan AlwaysOn dan Database Mirroring adalah teknologi pengelompokan "tidak berbagi". Basis data ada pada beberapa array disk di beberapa server. Jika Anda memiliki tautan jaringan yang baik maka beberapa servis dapat berada di beberapa ruang server, melindungi Anda dari kebakaran dan banjir.

Hanya untuk kelengkapan, ada opsi untuk menggunakan mirroring tua biasa. Keuntungannya di sini termasuk memiliki dua salinan database tanpa kerumitan menggunakan Grup Ketersediaan, dan tanpa memerlukan penyimpanan bersama untuk Failover Clustering. Kerugian, meskipun sedikit, mirroring sudah usang.

Waktu kegagalan dengan mirroring berada di urutan 10 detik, meskipun kode aplikasi harus dapat mencoba kembali setiap transaksi yang terjadi pada saat failover.