Pastikan Ketersediaan Tinggi untuk SQL Server di Amazon Web Services

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 ini, dengan satu instance server aktif dan dua siaga, dapat menangani dua kegagalan bersamaan dengan downtime minimal dan tanpa kehilangan data.

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

Opsi untuk Saat Tingkat Layanan Cloud Publik Gagal

Mengelola Biaya Cloud untuk Aplikasi dengan Ketersediaan Tinggi

Biaya Cloud untuk Aplikasi dengan Ketersediaan Tinggi

Segera setelah kontrak dengan penyedia layanan cloud, tagihan tiba yang menyebabkan guncangan stiker. Ada tuduhan tak terduga dan tampaknya berlebihan. Mereka yang bertanggung jawab tampaknya tidak dapat menjelaskan bagaimana ini bisa terjadi. Situasi ini mendesak karena jumlahnya mengancam untuk menghancurkan anggaran TI kecuali perubahan penghematan biaya dilakukan segera. Jadi bagaimana kita mengelola Biaya Cloud untuk Aplikasi yang Ketersediaan Tinggi? Guncangan stiker layanan cloud ini sering disebabkan oleh aplikasi basis data mission-critical. Terutama ini cenderung menjadi yang paling mahal karena berbagai alasan. Aplikasi ini perlu dijalankan 24/7. Mereka membutuhkan redundansi, yang melibatkan replikasi data dan penyediaan instance server siaga. Replikasi data membutuhkan perpindahan data, termasuk lintas jaringan area luas (WAN). Dan menyediakan ketersediaan tinggi dapat menghasilkan biaya yang lebih tinggi untuk melisensikan Windows untuk mendapatkan Clustering Failover Windows Server (dibandingkan menggunakan open source Linux), atau untuk lisensi Enterprise Edition dari SQL Server untuk mendapatkan Grup Ketersediaan Selalu Ada. Sebelum menawarkan saran untuk mengelola Biaya Cloud untuk Aplikasi dengan Ketersediaan Tinggi, penting untuk dicatat bahwa tujuannya di sini bukan untuk meminimalkan biaya-biaya tersebut. Melainkan untuk mengoptimalkan harga / kinerja untuk setiap aplikasi. Dengan kata lain, adalah tepat untuk membayar lebih banyak ketika menyediakan sumber daya untuk aplikasi yang membutuhkan waktu kerja dan kinerja throughput yang lebih tinggi. Penting juga untuk dicatat bahwa infrastruktur cloud hybrid — dengan aplikasi yang berjalan secara keseluruhan atau sebagian di cloud pribadi dan publik — kemungkinan akan menjadi cara terbaik untuk mencapai harga / kinerja yang optimal.

Memahami Model Bisnis Dan Harga Penyedia Layanan Cloud

Pengalaman guncangan stiker menunjukkan perlunya memahami secara menyeluruh bagaimana harga layanan cloud dan mengelola Biaya Cloud untuk Aplikasi yang Ketersediaan Tinggi. Hanya dengan demikian layanan yang tersedia dapat digunakan dengan cara yang paling hemat biaya. Semua penyedia layanan cloud (CSP) mempublikasikan harganya. Kecuali ditentukan dalam perjanjian layanan, harga itu terus berubah. Semua sumber daya berbasis perangkat keras, termasuk komputasi fisik dan virtual, penyimpanan, dan layanan jaringan, pasti memiliki biaya langsung atau tidak langsung. Ini semua didasarkan sampai batas tertentu pada ruang, daya, dan pendinginan yang dikonsumsi sistem ini. Untuk perangkat lunak, open source umumnya gratis. Tetapi semua sistem operasi komersial dan / atau perangkat lunak aplikasi akan dikenakan biaya lisensi. Dan harus diingatkan sebelumnya bahwa beberapa perizinan perangkat lunak dan model penetapan harga bisa sangat rumit. Jadi pastikan untuk mempelajarinya dengan cermat. Selain biaya dasar untuk perangkat keras dan perangkat lunak, ada potensi biaya à la carte untuk berbagai layanan bernilai tambah. Ini termasuk ketentuan keamanan, keseimbangan beban, dan perlindungan data. Mungkin juga ada biaya "tersembunyi" untuk I / O untuk penyimpanan atau di antara layanan mikro terdistribusi, atau untuk pemanfaatan puncak yang jarang terjadi selama "semburan." Karena setiap CSP memiliki model bisnis dan harga yang unik, diskusi di sini harus digeneralisasi . Dan, secara umum, sumber daya yang paling mahal melibatkan komputasi, perizinan perangkat lunak, dan perpindahan data. Bersama-sama mereka dapat mencapai 80% atau lebih dari total biaya. Pergerakan data mungkin juga menimbulkan biaya WAN terpisah yang tidak termasuk dalam tagihan dari CSP. Penyimpanan dan jaringan dalam infrastruktur CSP biasanya merupakan sumber daya yang paling murah. Solid state drive (SSDs) biasanya berharga lebih dari media pemintalan berdasarkan per-terabyte. Tetapi SSD juga memberikan kinerja yang superior, sehingga harga / kinerjanya mungkin sebanding atau bahkan lebih baik. Dan walaupun memindahkan data kembali ke perusahaan bisa jadi mahal, memindahkan data dari perusahaan ke cloud publik biasanya dapat dilakukan dengan biaya gratis (terlepas dari biaya WAN yang terpisah).

Merumuskan Strategi Untuk Mengoptimalkan Harga / Kinerja

Menutup Biaya Cloud untuk Aplikasi yang Ketersediaan Tinggi membutuhkan pemeriksaan yang cermat. Berikut adalah beberapa saran untuk mengelola pemanfaatan sumber daya di cloud publik dengan cara yang dapat menurunkan biaya sambil mempertahankan tingkat layanan yang sesuai untuk semua aplikasi. Ini termasuk yang membutuhkan misi kritis, waktu kerja tinggi dan throughput. Secara umum, ukuran-kanan adalah prinsip dasar untuk mengelola pemanfaatan sumber daya untuk harga / kinerja yang optimal. Ketika Willie Sutton konon bertanya mengapa dia merampok bank, dia menjawab, "Karena di situlah uang itu berada". Di cloud, uang berada dalam sumber daya komputasi, sehingga harus menjadi prioritas tertinggi untuk ukuran-kanan. Untuk aplikasi baru, mulailah dengan konfigurasi mesin virtual minimal untuk sumber daya komputasi. Tambahkan inti CPU, memori dan / atau I / O hanya sesuai kebutuhan untuk mencapai kinerja yang memuaskan. Semua mesin virtual untuk aplikasi yang ada pada akhirnya harus berukuran tepat. Mulailah dengan yang paling mahal harganya. Kurangi alokasi secara bertahap sambil memantau kinerja terus-menerus hingga mencapai pengembalian yang menurun. Perlu dicatat bahwa risiko utama yang terkait dengan pengukuran-ukuran-kanan adalah potensi untuk kekurangan-ukuran. Namun itu dapat menghasilkan kinerja yang sangat buruk. Sayangnya, cara terbaik untuk menilai kinerja aktual aplikasi adalah dengan beban kerja produksi, menjadikan dunia nyata tempat yang tepat untuk ukuran yang tepat. Untungnya, cloud memitigasi risiko ini dengan membuatnya dengan mudah mengubah ukuran konfigurasi berdasarkan permintaan. Jadi ukuran kanan agresif di mana dibutuhkan. Namun bersiaplah untuk bereaksi cepat dalam menanggapi setiap perubahan. Penyimpanan, berbeda langsung dengan komputasi, umumnya relatif murah di cloud. Tapi hati-hati menggunakan penyimpanan murah, karena I / O mungkin menimbulkan biaya yang terpisah — dan mahal — pada beberapa layanan. Jika demikian, gunakan teknologi yang berpotensi meningkatkan kinerja yang berpotensi lebih hemat biaya seperti penyimpanan bertingkat, caching, dan / atau database dalam memori, jika tersedia, untuk mengoptimalkan pemanfaatan semua sumber daya. Lisensi perangkat lunak dapat menjadi pengeluaran yang signifikan baik untuk cloud privat maupun publik. Untuk alasan ini, banyak organisasi bermigrasi dari Windows ke Linux, dan dari SQL Server ke database komersial dan / atau open source yang lebih murah. Tetapi untuk aplikasi yang sistem operasinya "premium" dan / atau perangkat lunak aplikasi dijamin, periksa berbagai CSP untuk melihat apakah ada model penetapan harga yang mungkin menghemat penghematan untuk konfigurasi yang diperlukan. Akhirnya, semua CSP menawarkan diskon, dan kombinasi dari ini kadang-kadang dapat mencapai penghematan hingga 50%. Contohnya termasuk pra-bayar untuk layanan, membuat komitmen layanan, dan / atau memindahkan aplikasi ke wilayah lain.

Membuat Dan Menegakkan Kontrol Penahanan Biaya

Penyediaan sendiri untuk layanan cloud mungkin populer dengan pengguna. Tetapi tanpa kontrol yang tepat, kenyamanan ini membuatnya terlalu mudah untuk memanfaatkan sumber daya secara berlebihan, termasuk yang paling mahal harganya. Mulailah upaya untuk mendapatkan kontrol yang lebih baik dengan memanfaatkan sepenuhnya alat pemantauan dan manajemen yang ditawarkan semua CSP. Ini tentu saja akan menghadapi kurva pembelajaran. Karena alat CSP mungkin sangat berbeda dari, dan berpotensi lebih canggih daripada, yang digunakan di cloud pribadi. Salah satu alat penahanan biaya yang lebih berguna melibatkan penandaan sumber daya. Tag terdiri dari pasangan kunci / nilai dan metadata yang terkait dengan sumber daya individual. Dan beberapa bisa sangat terperinci. Misalnya, setiap mesin virtual, bersama dengan CPU, memori, I / O, dan sumber daya yang dapat ditagih lainnya yang digunakannya, mungkin memiliki tag. Tag berguna lainnya mungkin menunjukkan aplikasi mana yang berada dalam lingkungan produksi versus pengembangan, atau ke pusat biaya atau departemen mana masing-masing ditugaskan. Secara kolektif, tag ini dapat merupakan pemanfaatan total sumber daya yang tercermin dalam tagihan. Organisasi yang menggunakan banyak layanan cloud publik mungkin juga dilayani dengan baik untuk membuat skrip. Sertakan memuat informasi dari semua alat pemantauan, manajemen, dan penandaan yang tersedia ke dalam spreadsheet atau aplikasi serupa untuk analisis terperinci dan penggunaan lainnya, seperti pengembalian tagihan, kepatuhan, dan tren / anggaran. Idealnya, informasi dari semua CSP dan cloud pribadi akan dinormalisasi untuk dimasukkan dalam pandangan holistik untuk memungkinkan optimalisasi harga / kinerja untuk semua aplikasi yang berjalan di seluruh cloud hybrid.

Menangani Kasing Kasus Penggunaan Terburuk: Aplikasi Ketersediaan Tinggi

Selain alasan yang dikutip dalam pengantar mengapa aplikasi ketersediaan tinggi sering kali paling mahal, ketiga CSP utama — Google, Microsoft, dan Amazon — setidaknya memiliki beberapa keterbatasan terkait ketersediaan tinggi. Contohnya termasuk failover yang biasanya dipicu hanya oleh pemadaman zona dan bukan oleh banyak kegagalan umum lainnya; contoh master hanya mampu membuat replika failover tunggal; dan penggunaan event log untuk mereplikasi data, yang menciptakan "replikasi lag" yang dapat mengakibatkan pemadaman sementara selama failover. Tak satu pun dari batasan ini yang tidak dapat diatasi, tentu saja — dengan anggaran yang cukup besar. Tantangannya adalah menemukan solusi umum dan hemat biaya untuk menerapkan ketersediaan tinggi di awan publik, pribadi, dan hibrid. Di antara solusi yang paling fleksibel dan terjangkau adalah kluster failover jaringan area penyimpanan (SAN). Solusi ketersediaan tinggi ini diimplementasikan sepenuhnya dalam perangkat lunak yang dibuat khusus untuk dibuat. Seperti yang tersirat dari namanya, sekelompok server dan penyimpanan yang tidak berbagi apa-apa dengan failover otomatis di seluruh jaringan area lokal dan / atau WAN untuk memastikan ketersediaan tinggi pada tingkat aplikasi. Sebagian besar solusi ini memberikan kombinasi replikasi data tingkat blok waktu-nyata, pemantauan aplikasi berkelanjutan, dan kebijakan pemulihan failover / failback yang dapat dikonfigurasi. Beberapa kluster failover SAN-less yang lebih kuat juga menawarkan kemampuan canggih. Misalnya optimasi WAN untuk memaksimalkan kinerja dan meminimalkan pemanfaatan bandwidth, dukungan kuat untuk Edisi Standar SQL Server yang lebih murah. Dan jangan lupa peralihan manual penugasan server primer dan sekunder untuk pemeliharaan terencana, dan kemampuan untuk melakukan pencadangan rutin tanpa mengganggu aplikasi.

Mempertahankan Perspektif Yang Tepat

Saat mencoba beberapa saran ini di cloud hybrid Anda, berusahalah untuk menjaga tagihan CSP bulanan dalam perspektif yang tepat. Dengan cloud publik, semua biaya muncul dalam satu faktur. Sebaliknya, total biaya untuk mengoperasikan cloud pribadi jarang disajikan dengan cara yang begitu lengkap dan terkonsolidasi. Dan jika ya, total biaya itu juga dapat menyebabkan guncangan stiker. Latihan yang berguna, oleh karena itu, mungkin untuk memahami semua biaya dalam pengoperasian cloud pribadi — tidak menerima apa pun yang diberikan — seolah-olah itu adalah bisnis mandiri seperti penyedia layanan cloud. Maka tagihan-tagihan dari CSP untuk aplikasi-aplikasi penting Anda mungkin tampaknya tidak begitu mengejutkan. Artikel dari www.dbta.com

Tantangan dalam Ketersediaan Tinggi Untuk Aplikasi Misi-Penting di SME

Mengelola Pemulihan Real-Time dalam Pemadaman Awan Besar

Mengelola Pemulihan Real-Time Dalam Pemadaman Awan Besar

Bencana terjadi, membuat kenyataan downtime tiba-tiba. Tetapi ada hal-hal yang dapat dilakukan oleh semua pelanggan untuk bertahan hidup dari pemadaman cloud apa pun. Banyak hal terjadi. Kegagalan — besar dan kecil — tidak bisa dihindari. Apa yang tidak bisa dihindari adalah periode downtime yang diperpanjang. Pertimbangkan hari ketika awan Azure Wilayah Microsoft Tengah Selatan AS mengalami kegagalan yang dahsyat. Sebuah badai ganas menyebabkan serangkaian masalah yang akhirnya meruntuhkan seluruh pusat data. Dalam apa yang oleh beberapa orang disebut "Hari Azure Cloud Jatuh dari Langit," kebanyakan pelanggan offline, tidak hanya selama beberapa detik atau menit, tetapi untuk satu hari penuh. Beberapa offline selama lebih dari dua hari. Sementara Microsoft sejak itu telah menangani banyak masalah yang menyebabkan pemadaman, insiden itu akan lama diingat oleh para profesional TI. Itu berita buruknya. Berita baiknya adalah: Ada hal-hal yang bisa dilakukan pelanggan Azure untuk bertahan hidup dari hampir semua gangguan. Itu bisa dari satu server gagal ke seluruh pusat data menjadi offline. Faktanya, pelanggan Azure yang menerapkan ketersediaan tinggi dan / atau ketentuan pemulihan bencana, lengkap dengan replikasi data real-time dan failover otomatis yang cepat, dapat berharap tidak mengalami kehilangan data, dan sedikit atau tidak ada downtime ketika bencana terjadi. Lihat juga: Nutanix melihat cloud perusahaan memenangkan perlombaan cloud

Mengelola Pemadaman Awan

Artikel ini membahas empat opsi untuk menyediakan perlindungan pemulihan bencana (DR) dan ketersediaan tinggi (HA) dalam konfigurasi cloud hybrid dan Azure murni. Dua opsi khusus untuk database Microsoft SQL Server, yang merupakan aplikasi populer di Azure cloud; dua opsi lainnya adalah agnostik aplikasi. Keempat opsi, yang juga dapat digunakan dalam berbagai kombinasi, dibandingkan dalam tabel dan termasuk:

• Layanan Azure Site Recovery (ASR)
• Contoh SQL Server Failover Cluster dengan Ruang Penyimpanan Langsung
• SQL Server Selalu Di Ketersediaan Grup
• Perangkat Lunak Failover Clustering pihak ketiga

RTO dan RPO 101

Sebelum menjelaskan keempat opsi, perlu memiliki pemahaman dasar tentang dua metrik yang digunakan untuk menilai efektivitas ketentuan DR dan HA: Sasaran Waktu Pemulihan dan Sasaran Titik Pemulihan. Mereka yang akrab dengan RTO dan RPO dapat melewati bagian ini. RTO adalah durasi pemadaman maksimum yang dapat ditoleransi. Aplikasi pemrosesan transaksi online umumnya memiliki RTO terendah, dan aplikasi yang sangat kritis sering memiliki RTO hanya beberapa detik. RPO adalah periode maksimum di mana kehilangan data dapat ditoleransi. Jika tidak ada kehilangan data yang dapat ditoleransi, maka RPO adalah nol. RTO biasanya akan menentukan jenis perlindungan HA dan / atau DR yang dibutuhkan. Waktu pemulihan yang rendah biasanya menuntut ketentuan HA yang kuat yang melindungi terhadap kegagalan sistem dan perangkat lunak yang rutin, sementara RTO yang lebih lama dapat puas dengan ketentuan DR dasar yang dirancang untuk melindungi terhadap bencana yang lebih luas, tetapi jauh lebih jarang terjadi. Replikasi data yang digunakan dengan ketentuan HA dan DR dapat menciptakan kebutuhan untuk tradeoff potensial antara RTO dan RPO. Dalam lingkungan LAN latensi rendah, di mana replikasi dapat disinkronkan, kumpulan data primer dan sekunder dapat diperbarui secara bersamaan. Hal ini memungkinkan pemulihan penuh terjadi secara otomatis dan dalam waktu nyata, sehingga memungkinkan untuk memenuhi waktu pemulihan yang paling menuntut dan tujuan titik pemulihan (masing-masing beberapa detik dan nol) tanpa ada tradeoff yang diperlukan. Di seberang WAN, sebaliknya, memaksa primer untuk menunggu sekunder untuk mengkonfirmasi penyelesaian pembaruan untuk setiap transaksi akan berdampak buruk pada kinerja. Untuk alasan ini, replikasi data dalam WAN biasanya tidak sinkron. Ini dapat menciptakan tradeoff antara mengakomodasi RTO dan RPO yang biasanya menghasilkan peningkatan waktu pemulihan. Inilah alasannya: Untuk memenuhi RPO nol, proses manual diperlukan untuk memastikan semua data (misalnya dari log transaksi) telah sepenuhnya direplikasi pada sekunder sebelum kegagalan dapat terjadi. Upaya ekstra ini memperpanjang waktu pemulihan, dan itulah sebabnya konfigurasi seperti itu sering digunakan untuk DR dan bukan HA.

Layanan Pemulihan Situs Azure (ASR)

ASR adalah penawaran DR-as-a-service (DRaaS) Azure. ASR mereplikasi mesin fisik dan virtual ke situs Azure lain, berpotensi di wilayah lain, atau dari instance lokal ke cloud Azure. Layanan ini memberikan pemulihan yang cukup cepat dari pemadaman sistem dan situs, dan juga memfasilitasi pemeliharaan yang direncanakan dengan menghilangkan waktu henti selama pemutakhiran perangkat lunak bergulir. Seperti semua penawaran DRaaS, ASR memiliki beberapa keterbatasan, yang paling serius adalah ketidakmampuan untuk mendeteksi dan gagal secara otomatis dari banyak kegagalan yang menyebabkan downtime tingkat aplikasi. Tentu saja, inilah mengapa layanan ini dikarakterisasi sebagai untuk DR dan bukan untuk HA. Dengan ASR, waktu pemulihan biasanya 3-4 menit tergantung, tentu saja, pada seberapa cepat administrator dapat secara manual mendeteksi dan merespons masalah. Seperti dijelaskan di atas, kebutuhan untuk replikasi data tidak sinkron di WAN selanjutnya dapat meningkatkan waktu pemulihan untuk aplikasi dengan RPO nol.

Contoh SQL Server Failover Cluster dengan Ruang Penyimpanan Langsung

SQL Server menawarkan dua opsi HA / DR-nya sendiri: Mesin Virtual Failover Cluster (dibahas di sini) dan Grup Ketersediaan Selalu Aktif (dibahas berikutnya). FCI memberikan dua keuntungan: Fitur ini tersedia dalam Edisi Standar SQL Server yang lebih murah, dan tidak tergantung pada penyimpanan bersama seperti halnya cluster HA tradisional. Keuntungan yang terakhir ini penting karena penyimpanan bersama tidak tersedia di cloud — dari Microsoft atau penyedia layanan cloud lainnya. Pilihan populer untuk penyimpanan di Azure cloud adalah Storage Spaces Direct (S2D), yang mendukung berbagai aplikasi, dan dukungannya untuk SQL Server melindungi seluruh instance dan bukan hanya database. Kelemahan utama S2D adalah bahwa server harus berada dalam satu pusat data tunggal, membuat opsi ini cocok untuk beberapa kebutuhan HA tetapi tidak untuk DR. Untuk perlindungan multi-situs HA dan DR, replikasi data yang diperlukan harus disediakan oleh pengiriman log atau solusi pengelompokan failover pihak ketiga.

SQL Server Selalu Di Ketersediaan Grup

Sementara Always On Availability Groups adalah penawaran SQL Server yang paling mampu untuk HA dan DR, itu membutuhkan lisensi Enterprise Edition yang lebih mahal. Opsi ini dapat memberikan waktu pemulihan 5-10 detik dan titik pemulihan detik atau kurang. Itu juga menawarkan sekunder dibaca untuk query database (dengan lisensi yang sesuai), dan tidak menempatkan batasan pada ukuran database atau jumlah instance sekunder. Konfigurasi Always On Availability Groups yang menyediakan perlindungan HA dan DR terdiri dari pengaturan tiga simpul dengan dua node dalam satu Set Ketersediaan atau Zona, dan yang ketiga di Azure Region terpisah. Satu batasan penting adalah bahwa hanya database yang direplikasi dan bukan seluruh instance SQL, yang harus dilindungi oleh beberapa cara lain. Selain menjadi penghalang biaya untuk beberapa aplikasi database, pendekatan ini memiliki kelemahan lain. Khusus untuk aplikasi memerlukan departemen TI untuk mengimplementasikan ketentuan HA dan DR lainnya untuk semua aplikasi lainnya. Penggunaan beberapa solusi HA / DR dapat secara substansial meningkatkan kompleksitas dan biaya (untuk perizinan, pelatihan, implementasi dan operasi yang sedang berlangsung), menjadikan ini alasan lain mengapa organisasi semakin memilih menggunakan solusi pihak ketiga agnostik aplikasi.

Perangkat Lunak Failover Clustering pihak ketiga

Dengan desain aplikasi-agnostik dan platform-agnostik, perangkat lunak failover clustering mampu memberikan solusi HA dan DR lengkap untuk hampir semua aplikasi di lingkungan cloud pribadi, publik, dan hybrid. Ini termasuk untuk Windows dan Linux. Menjadi agnostik aplikasi menghilangkan kebutuhan untuk memiliki ketentuan HA / DR yang berbeda untuk aplikasi yang berbeda. Menjadi platform-agnostik memungkinkan untuk memanfaatkan berbagai kemampuan dan layanan di Azure cloud, termasuk Fault Domains, Kumpulan dan Zona Ketersediaan, Pasangan Wilayah, dan Pemulihan Situs Azure. Sebagai solusi lengkap, perangkat lunak ini mencakup, sekurang-kurangnya, replikasi data waktu-nyata, pemantauan berkelanjutan yang mampu mendeteksi kegagalan pada tingkat aplikasi, dan kebijakan yang dapat dikonfigurasi untuk failover dan failback. Sebagian besar solusi juga menawarkan berbagai kemampuan bernilai tambah yang memungkinkan cluster failover untuk memberikan waktu pemulihan di bawah 20 detik dengan kehilangan data minimal atau tidak ada sama sekali untuk memenuhi hampir semua kebutuhan HA / DR.

Menjadikannya Nyata

Keempat opsi, apakah beroperasi secara terpisah atau bersamaan, dapat memiliki peran untuk dimainkan dalam membuat kontinum perlindungan DR dan HA lebih efektif dan terjangkau untuk spektrum penuh aplikasi perusahaan. Ini termasuk dari mereka yang dapat mentolerir beberapa kehilangan data dan periode waktu henti yang panjang, hingga mereka yang membutuhkan pemulihan waktu nyata untuk mencapai lima hingga 9 waktu kerja dengan kehilangan data yang minimal atau tidak sama sekali. Untuk selamat dari pemadaman cloud berikutnya di dunia nyata, pastikan bahwa ketentuan DR dan / atau HA apa pun yang Anda pilih dikonfigurasikan dengan setidaknya dua node yang tersebar di dua situs. Pastikan juga untuk memahami seberapa baik ketentuan memenuhi waktu pemulihan masing-masing aplikasi dan tujuan titik pemulihan. Serta segala keterbatasan yang mungkin ada, termasuk kebutuhan akan proses manual yang diperlukan untuk mendeteksi semua kemungkinan kegagalan, dan memicu kegagalan dengan cara yang memastikan kesinambungan aplikasi dan integritas data.

Tentang Jonathan Meltzer

Jonathan Meltzer adalah Direktur, Manajemen Produk, di SIOS Technology. Ia memiliki lebih dari 20 tahun pengalaman dalam manajemen produk dan pemasaran untuk perangkat lunak dan produk SaaS yang membantu pelanggan mengelola, mengubah, dan mengoptimalkan sumber daya manusia dan sumber daya TI mereka. Direproduksi dari RTinsight