Pastikan Ketersediaan Tinggi untuk SQL Server di Amazon Web Services

Administrator basis data dan sistem telah lama memiliki berbagai pilihan untuk memastikan bahwa aplikasi basis data yang sangat penting tetap tersedia. Infrastruktur cloud publik, seperti yang disediakan oleh Amazon Web Services, menawarkan sendiri, opsi ketersediaan tinggi tambahan yang didukung oleh perjanjian tingkat layanan. Tetapi konfigurasi yang berfungsi baik di cloud pribadi mungkin tidak dimungkinkan di cloud publik. Pilihan yang buruk dalam layanan AWS yang digunakan dan / atau bagaimana ini dikonfigurasikan dapat menyebabkan ketentuan failover gagal ketika sebenarnya dibutuhkan. Artikel ini menguraikan berbagai opsi yang tersedia untuk memastikan Ketersediaan Tinggi untuk SQL Server di cloud AWS.

Pilihan

Untuk aplikasi basis data, AWS memberi administrator dua pilihan dasar. Masing-masing memiliki ketentuan ketersediaan tinggi (HA) dan pemulihan bencana (DR) yang berbeda: Amazon Relational Database Service (RDS) dan Amazon Elastic Compute Cloud (EC2).

RDS

RDS adalah layanan yang dikelola sepenuhnya cocok untuk aplikasi mission-critical. Ini menawarkan pilihan enam mesin database yang berbeda, tetapi dukungannya untuk SQL Server tidak sekuat itu untuk pilihan lain seperti Amazon Aurora, My SQL dan MariaDB. Berikut adalah beberapa masalah umum yang dimiliki administrator tentang penggunaan RDS untuk aplikasi SQL Server yang sangat penting:

• Hanya satu instance siaga cermin yang didukung,
• Pekerjaan Agen tidak dicerminkan dan oleh karena itu, harus dibuat secara terpisah dalam keadaan siaga,
• Kegagalan yang disebabkan oleh perangkat lunak aplikasi database tidak terdeteksi,
• Contoh basis data dalam-memori yang dioptimalkan kinerja tidak didukung,
• Bergantung pada penugasan Zona Ketersediaan (di mana pelanggan tidak memiliki kendali) kinerja dapat terpengaruh,
• SQL Server Enterprise Edition yang lebih mahal diperlukan untuk fitur mirroring data yang hanya tersedia dengan Always On Availability Groups.

Cloud Hitung Elastik

Pilihan dasar lainnya adalah Elastic Compute Cloud dengan kemampuannya yang jauh lebih besar. Ini menjadikannya pilihan yang lebih disukai ketika HA dan DR sangat penting. Keuntungan utama EC2 adalah kontrol penuh yang diberikannya kepada admin atas konfigurasi, dan yang memberi admin beberapa pilihan tambahan.

Memilih Sistem Operasi

Mungkin pilihan yang paling penting adalah sistem operasi mana yang akan digunakan: Windows atau Linux. Windows Server Failover Clustering adalah kemampuan yang kuat, terbukti dan populer yang datang standar dengan Windows. Tetapi WSFC membutuhkan penyimpanan bersama, dan itu tidak tersedia di EC2. Karena Multi-AZ, dan bahkan Multi-Wilayah, konfigurasi diperlukan untuk perlindungan HA / DR yang kuat, perangkat lunak khusus komersial atau kustom diperlukan untuk mereplikasi data di seluruh cluster instance server. Ruang Penyimpanan Langsung Microsoft (S2D) bukanlah opsi di sini, karena tidak mendukung konfigurasi yang menjangkau Zona Ketersediaan. Kebutuhan akan ketentuan HA / DR tambahan bahkan lebih besar untuk Linux, yang tidak memiliki kemampuan pengelompokan mendasar seperti WSFC. Linux memberikan admin dua pilihan yang sama buruknya untuk ketersediaan tinggi: Entah membayar lebih untuk SQL Server Enterprise Edition yang lebih mahal untuk mengimplementasikan Grup Selalu Ada Ketersediaan; atau berjuang untuk membuat konfigurasi HA Linux do-it-yourself yang rumit menggunakan perangkat lunak sumber terbuka bekerja dengan baik.

Perbandingan

Kedua pilihan ini merusak alasan penghematan biaya untuk menggunakan perangkat lunak open source pada perangkat keras komoditas dalam layanan cloud publik. SQL Server untuk Linux hanya tersedia untuk versi yang lebih baru (dan lebih mahal), mulai tahun 2017. Dan alternatif HA DIY bisa sangat mahal bagi sebagian besar organisasi. Memang, membuat Distributed Replicated Block Device, Corosync, Pacemaker dan, secara opsional, perangkat lunak open source lainnya berfungsi seperti yang diinginkan pada level aplikasi di bawah semua skenario kegagalan yang mungkin bisa menjadi sangat sulit. Itulah sebabnya hanya organisasi yang sangat besar yang memiliki sarana (keahlian dan staf) yang diperlukan untuk mempertimbangkan untuk mengambil tugas. Karena kesulitan yang terlibat dalam mengimplementasikan ketentuan HA / DR yang sangat penting untuk Linux, AWS merekomendasikan menggunakan kombinasi Penimbangan Beban Elastis dan Penskalaan Otomatis untuk meningkatkan ketersediaan. Tetapi layanan ini memiliki keterbatasan sendiri yang serupa dengan yang ada di Layanan Database Relasional yang dikelola. Semua ini menjelaskan mengapa admin semakin memilih untuk menggunakan solusi cluster failover yang dirancang khusus untuk memastikan perlindungan HA dan DR di lingkungan cloud.

Tujuan Clustering Failover-Dibangun untuk Cloud

Semakin populernya awan privat, publik dan hibrida telah menyebabkan munculnya solusi pengelompokan failover yang dibangun khusus untuk lingkungan cloud. Solusi HA / DR ini sepenuhnya diimplementasikan dalam perangkat lunak yang menciptakan, seperti tersirat dengan nama, sekelompok server dan penyimpanan dengan failover otomatis untuk memastikan ketersediaan tinggi di tingkat aplikasi. Sebagian besar solusi ini menyediakan solusi HA / DR lengkap yang mencakup kombinasi replikasi data tingkat blok waktu-nyata, pemantauan aplikasi terus-menerus dan kebijakan pemulihan failover / failback yang dapat dikonfigurasi. Beberapa solusi yang lebih canggih juga menawarkan kemampuan canggih seperti dukungan untuk Mesin Virtual Selalu di Failover Cluster dalam Edisi Standar SQL Server yang lebih murah untuk Windows dan Linux. Mereka juga menawarkan optimasi WAN untuk memaksimalkan kinerja multi-wilayah. Ada juga peralihan manual tugas server primer dan sekunder untuk memfasilitasi pemeliharaan yang direncanakan. Termasuk kemampuan untuk melakukan backup reguler tanpa gangguan ke aplikasi. Sebagian besar perangkat lunak failover clustering adalah agnostik aplikasi, yang memungkinkan organisasi memiliki solusi HA / DR tunggal universal. Kemampuan yang sama ini juga memberikan perlindungan untuk seluruh aplikasi SQL Server. Dan itu termasuk basis data, log masuk, pekerjaan agen, dll., Semuanya terintegrasi. Meskipun solusi ini umumnya juga agnostik penyimpanan, memungkinkan mereka untuk bekerja dengan jaringan area penyimpanan bersama, pengelompokan failover SANless yang tidak dibagi biasanya lebih disukai karena kemampuannya untuk menghilangkan titik kegagalan tunggal yang potensial. Dukungan untuk Mesin Virtual Cluster Selalu Aktif (FCI) dalam SQL Server Edisi Standar yang lebih murah, tanpa kompromi terhadap ketersediaan atau kinerja, adalah keuntungan utama. Dalam lingkungan Windows, sebagian besar perangkat lunak pengelompokan failover mendukung FCI dengan memanfaatkan fitur WSFC bawaan. Itu membuat implementasi cukup mudah untuk administrator database dan sistem. Linux menjadi semakin populer untuk SQL Server dan banyak aplikasi perusahaan lainnya. Beberapa solusi cluster failover sekarang membuat penerapan ketentuan HA / DR semudah itu untuk Windows dengan menawarkan integrasi khusus aplikasi.

Cluster Failover Tiga Node SANless Khas

Contoh konfigurasi EC2 dalam diagram menunjukkan kluster failover SANless tiga simpul yang dikonfigurasikan sebagai Virtual Private Cloud (VPC) dengan ketiga instance SQL Server di Zona Ketersediaan yang berbeda. Untuk menghilangkan potensi pemadaman dalam bencana lokal yang mempengaruhi seluruh wilayah, salah satu AZ terletak di wilayah AWS yang berbeda.

Tiga-simpul SANless failover cluster memberikan perlindungan HA dan DR kelas carrier. Operasi dasarnya sama di LAN dan / atau WAN untuk Windows atau Linux. Server # 1 pada awalnya adalah instance primer atau aktif yang mereplikasi data terus menerus ke kedua server # 2 dan # 3. Itu mengalami masalah. Kemudian memicu failover otomatis ke server # 2, yang sekarang menjadi data replikasi utama ke server # 3.

Kegagalan Terdeteksi

Jika kegagalan itu disebabkan oleh pemadaman infrastruktur, staf AWS akan segera mulai mendiagnosis dan memperbaiki apa pun yang menyebabkan masalah. Setelah diperbaiki, itu dapat dikembalikan sebagai primer, atau server # 2 dapat melanjutkan dalam kapasitas mereplikasi data ke server # 1 dan # 3. Jika server # 2 gagal sebelum server # 1 dikembalikan ke operasi, seperti yang ditunjukkan, server # 3 akan menjadi yang utama setelah kegagalan manual. Tentu saja, jika kegagalan itu disebabkan oleh perangkat lunak aplikasi atau aspek lain dari konfigurasi, terserah kepada pelanggan untuk menemukan dan memperbaiki masalah. Cluster failover SANless dapat dikonfigurasi hanya dengan satu instance standby, tentu saja. Tetapi konfigurasi minimal seperti itu membutuhkan simpul ketiga untuk berfungsi sebagai saksi. Saksi diperlukan untuk mencapai kuorum untuk menentukan penugasan primer. Tugas penting ini biasanya dilakukan oleh pengontrol domain di AZ terpisah. Mempertahankan ketiga simpul (primer, sekunder, dan saksi) di AZ yang berbeda menghilangkan kemungkinan kehilangan lebih dari satu suara jika ada zona yang offline. Juga dimungkinkan untuk memiliki kluster failover SAN dua dan tiga simpul dalam konfigurasi cloud hybrid untuk tujuan HA dan / atau DR. Salah satu konfigurasi tiga simpul tersebut adalah klaster HA dua simpul yang terletak di pusat data perusahaan dengan replikasi data asinkron ke AWS atau layanan cloud lain untuk perlindungan DR — atau sebaliknya. Dalam kelompok dalam satu wilayah, di mana replikasi data sinkron, kegagalan biasanya dikonfigurasi untuk terjadi secara otomatis. Untuk cluster dengan node yang menjangkau beberapa wilayah, di mana replikasi data asinkron, failover biasanya dikontrol secara manual untuk menghindari potensi kehilangan data. Cluster tiga-node, terlepas dari wilayah yang digunakan, juga dapat memfasilitasi pemeliharaan perangkat keras dan perangkat lunak yang direncanakan untuk ketiga server sambil memberikan perlindungan DR berkelanjutan untuk aplikasi dan datanya.

Maksimalkan Ketersediaan Tinggi untuk SQL Server

Dengan menawarkan 55 zona Ketersediaan yang tersebar di 18 Wilayah geografis, Infrastruktur Global AWS memberi peluang besar untuk memaksimalkan Ketersediaan Tinggi untuk SQL Server dengan mengonfigurasi kluster failover SANless dengan banyak, redundansi yang tersebar secara geografis. Jejak global ini juga memungkinkan semua aplikasi dan data SQL Server berada di dekat pengguna akhir untuk memberikan kinerja yang memuaskan. Dengan solusi yang dibangun khusus, ketersediaan tinggi kelas-operator tidak perlu berarti membayar biaya tinggi seperti-carrier. Karena perangkat lunak failover clustering yang dibuat khusus membuat penggunaan sumber daya komputasi, penyimpanan, dan jaringan EC2 yang efektif dan efisien, sementara mudah diimplementasikan dan dioperasikan, solusi ini meminimalkan modal dan semua pengeluaran operasional, sehingga ketersediaan tinggi menjadi lebih kuat dan lebih terjangkau daripada pernah sebelumnya. Direproduksi dari TheNewStack