Jelajahi ketersediaan tinggi dan opsi pemulihan bencana
Untuk membayangkan solusi untuk komputer virtual (VM), Anda harus terlebih dahulu memahami opsi ketersediaan untuk penyebaran berbasis IaaS.
Infrastruktur-sebagai-Layanan melawan Platform-sebagai-Layanan
Dalam hal ketersediaan, pilihan IaaS atau PaaS akan membuat perbedaan. Dengan IaaS, Anda memiliki komputer virtual, yang berarti ada sistem operasi dengan instalasi SQL Server. Administrator atau grup yang bertanggung jawab untuk SQL Server akan memiliki pilihan solusi ketersediaan tinggi dan pemulihan bencana (HADR) dan banyak kendali atas bagaimana solusi itu dikonfigurasikan.
Dengan penerapan berbasis PaaS seperti Azure SQL Database, solusi HADR dibangun ke dalam fitur dan seringkali hanya perlu diaktifkan. Ada opsi minimal yang dapat dikonfigurasi.
Karena perbedaan ini, memilih IaaS atau PaaS dapat mempengaruhi desain akhir dari solusi HADR Anda.
Fitur SQL Server HADR untuk Komputer Virtual Azure
Saat menggunakan IaaS, Anda dapat menggunakan fitur yang disediakan oleh SQL Server untuk meningkatkan ketersediaan. Dalam beberapa kasus, mereka dapat digabungkan dengan fitur tingkat Azure untuk meningkatkan ketersediaan lebih jauh.
Fitur-fitur yang tersedia di SQL Server ditunjukkan pada tabel di bawah ini
| Nama Fitur | Melindungi |
|---|---|
| Instans Failover Kluster Grup Ketersediaan AlwaysOn (FCI) | Instans |
| Grup Ketersediaan AlwaysOn (AG) | Database |
| Pengiriman Log | Database |
Sebuah instans dari SQL Server adalah seluruh instalasi SQL Server (binary, semua objek di dalam instans termasuk hal-hal seperti login, pekerjaan SQL Server Agent, dan database). Perlindungan tingkat instans berarti bahwa seluruh instans diperhitungkan dalam fitur ketersediaan.
Database di SQL Server berisi data yang digunakan oleh pengguna akhir dan aplikasi. Ada database sistem yang diandalkan oleh SQL Server, serta database yang dibuat untuk digunakan oleh pengguna akhir dan aplikasi. Sebuah instance dari SQL Server selalu memiliki database sistem sendiri. Perlindungan tingkat database berarti bahwa segala sesuatu yang ada dalam database, atau ditangkap dalam log transaksi untuk database pengguna atau aplikasi, telah diperhitungkan sebagai bagian dari fitur ketersediaan. Apa pun yang ada di luar database atau yang tidak diambil sebagai bagian dari log transaksi seperti pekerjaan SQL Server Agent dan server yang ditautkan harus ditangani secara manual untuk memastikan server tujuan dapat berfungsi seperti yang utama jika ada peristiwa failover yang direncanakan maupun tidak.
Baik FCI dan AG membutuhkan mekanisme kluster yang mendasarinya. Untuk penyebaran SQL Server yang berjalan di Server Windows, ini adalah Kluster Failover Windows Server (WSFC) dan untuk Linux adalah Pacemaker.
Instans Kluster Failover Grup Ketersediaan AlwaysOn
FCI dikonfigurasikan ketika SQL Server diinstal. Sebuah instans tunggal dari SQL Server tidak dapat dikonversi ke FCI. FCI tersebut diberi nama unik serta alamat IP yang berbeda dari server yang mendasarinya, atau simpul, yang berpartisipasi dalam kluster. Nama dan alamat IP juga harus berbeda dari mekanisme kluster yang mendasarinya. Aplikasi dan pengguna akhir akan menggunakan nama unik FCI untuk akses. Abstraksi ini memungkinkan aplikasi untuk tidak perlu mengetahui di mana instance sedang berjalan. Satu perbedaan utama antara FCI berbasis Azure versus FCI lokal, adalah bahwa untuk Azure, saldo beban internal (ILB) diperlukan. ILB digunakan untuk membantu memastikan aplikasi dan pengguna akhir dapat terhubung ke nama unik FCI.
Ketika FCI gagal ke simpul lain dari sebuah kluster, walaupun itu dimulai secara manual atau terjadi karena masalah, seluruh instans terhidup ulang pada simpul lain. Hal itu berarti proses failover adalah perhentian penuh dan awal dari SQL Server. Semua aplikasi atau pengguna akhir yang tersambung ke FCI akan terputus selama failover dan hanya aplikasi yang dapat menangani dan memulihkan dari gangguan ini yang dapat terhubung kembali secara otomatis.
Setelah memulai di simpul lain, instans akan segera melewati proses pemulihan. FCI sangatlah konsisten hingga mencapai titik kegagalan, jadi secara teknis tidak akan ada kehilangan data tetapi setiap transaksi yang perlu digulung balik akan dilakukan sebagai bagian dari pemulihan. Seperti catatan di atas, karena ini adalah perlindungan tingkat instans, semua yang diperlukan (login, pekerjaan SQL Server Agent, dll.) sudah ada di sana sehingga bisnis dapat dilanjutkan seperti biasa setelah database siap.
FCI memerlukan satu salinan database, tetapi itu juga merupakan satu-satunya titik kegagalannya. Untuk memastikan simpul lain dapat mengakses database, FCI memerlukan beberapa bentuk penyimpanan berbagi. Untuk arsitektur berbasis Server Windows, hal ini dapat dicapai melalui berbagi file premium Azure, iSCSI, Disk Berbagi Azure, Storage Spaces Direct (S2D), atau solusi pihak ketiga yang didukung seperti SIOS DataKeeper. FCI yang menggunakan Edisi Standar SQL Server dapat memiliki hingga dua simpul. FCI juga memerlukan penggunaan Active Directory Domain Services (AD DS) dan Layanan Nama Domain (DNS), sehingga berarti AD DS dan DNS harus diterapkan di suatu tempat di Azure agar FCI berfungsi.
Menggunakan Windows Server 2016 atau yang lebih baru, FCI dapat menggunakan Replika Penyimpanan untuk membuat solusi pemulihan bencana lokal untuk FCI tanpa harus menggunakan fitur lain seperti pengiriman log atau AG.
Grup Ketersediaan AlwaysOn
AG diperkenalkan di Edisi Perusahaan SQL Server 2012 dan pada SQL Server 2016, juga dalam Edisi Standar. Dalam Edisi Standar, AG dapat berisi satu database sedangkan di Edisi Perusahaan, AG dapat memiliki lebih dari satu database. Sementara AG memiliki beberapa kesamaan dengan FCI, dalam banyak hal mereka berbeda.
Perbedaan terbesar antara FCI dan AG adalah bahwa AG menyediakan perlindungan tingkat database. Replika utama adalah instans yang berpartisipasi dalam AG yang berisi database baca/tulis. Replika sekunder adalah tempat utama mengirim transaksi melalui transpor log agar tetap tersinkron. Pergerakan data antara replika utama bisa sinkron atau asinkron. Database pada replika sekunder mana pun berada dalam kondisi pemuatan, yang berarti mereka dapat menerima transaksi tetapi tidak dapat menjadi salinan yang dapat ditulis sepenuhnya hingga replika tersebut menjadi yang utama. AG dalam Edisi Standar dapat memiliki paling banyak dua replika (satu primer, satu sekunder) sedangkan Edisi Perusahaan mendukung hingga sembilan (satu primer, delapan sekunder). Replika sekunder diinisialisasi baik dari cadangan database, atau pada SQL Server 2016, Anda dapat menggunakan fitur yang disebut 'penyemaian otomatis'. Penyemaian otomatis menggunakan transportasi aliran log untuk mengalirkan cadangan ke replika sekunder untuk setiap database grup ketersediaan menggunakan titik akhir yang dikonfigurasi.
AG menyediakan abstraksi dengan pendengar. Fungsi pendengar seperti nama unik yang ditetapkan untuk FCI dan memiliki nama dan alamat IP sendiri yang berbeda dari yang lain (WSFC, simpul, dll.). Pendengar juga membutuhkan ILB dan juga melewati bagian berhenti dan mulai. Aplikasi dan pengguna akhir dapat menggunakan pendengar untuk menyambungkan, tetapi tidak seperti FCI, jika diinginkan, pendengar tidak harus digunakan. Sambungan langsung ke instans dapat terjadi. Dengan Edisi Perusahaan, replika sekunder di Edisi Perusahaan juga dapat dikonfigurasi untuk akses hanya baca jika diinginkan dan dapat digunakan untuk fungsi lain seperti pemeriksaan konsistensi database (DBCC) dan pencadangan.
AG dapat memiliki waktu failover yang lebih cepat dibandingkan dengan FCI, yang merupakan salah satu alasan daya tarik mereka. Meskipun AG tidak memerlukan penyimpanan berbagi, setiap replika memiliki salinan data, yang meningkatkan jumlah total salinan database dan biaya penyimpanan keseluruhan. Penyimpanan bersifat lokal untuk setiap replika. Misalnya, jika jejak data database pada replika utama adalah 1 TB, setiap replika juga akan memiliki hal yang sama. Jika ada lima replika, itu berarti Anda membutuhkan ruang 5 TB.
Ingat bahwa objek apa pun yang ada di luar database atau tidak diambil dalam log transaksi database harus dibuat dan diperhitungkan secara manual pada instans SQL Server lainnya jikalau instans tersebut perlu menjadi replika utama baru. Contoh objek yang akan menjadi tanggung jawab Anda mencakup pekerjaan SQL Server Agent, login tingkat instans, server yang ditautkan. Jika Anda dapat menggunakan autentikasi Windows atau menggunakan database mandiri dengan AG, hal itu akan menyederhanakan akses.
Banyak organisasi mungkin menghadapi tantangan dalam mengimplementasikan arsitektur yang banyak tersedia, dan mungkin hanya memerlukan ketersediaan tinggi yang disediakan oleh platform Azure, atau menggunakan solusi PaaS seperti Azure SQL Managed Instance. Sebelum kita melihat solusi platform Azure, ada satu fitur SQL Server lain yang harus Anda ketahui yaitu: pengiriman log.
Pengiriman log
Pengiriman log telah ada sejak awal SQL Server. Fitur ini didasarkan pada pencadangan, penyalinan, dan pemulihan dan juga merupakan salah satu metode paling sederhana untuk mencapai HADR untuk SQL Server. Pengiriman log terutama digunakan untuk pemulihan bencana, tetapi juga dapat digunakan untuk meningkatkan ketersediaan lokal.
Pengiriman log, seperti AG, memberikan perlindungan tingka tdatabase, yang berarti Anda masih perlu memperhitungkan pekerjaan SQL Server Agent, server yang ditautkan, login tingkat instans, dll. Tidak ada abstraksi yang disediakan secara ;lokal oleh pengiriman log, jadi peralihan ke server lain yang berpartisipasi dalam pengiriman log harus dapat mentolerir perubahan nama. Jika itu tidak memungkinkan, ada metode seperti alias DNS, yang dapat dikonfigurasi pada lapisan jaringan untuk mencoba mengurangi masalah perubahan nama.
Mekanisme dalam pengiriman log adalah sederhana: pertama, ambil cadangan penuh dari database sumber di server utama, pulihkan dalam keadaan memuat (STANDBY atau NORECOVERY) pada instans lain yang dikenal sebagai server sekunder atau siaga siap. Salinan baru dari database ini dikenal sebagai database sekunder. Proses otomatis yang dibangun ke dalam SQL Server kemudian akan secara otomatis mencadangkan log transaksi database utama, menyalin cadangan ke server siaga, dan akhirnya, memulihkan cadangan ke siaga.
Fitur SQL Server HADR bukan satu-satunya opsi untuk meningkatkan ketersediaan IaaS. Ada beberapa fitur di Azure yang juga harus dipertimbangkan.