Mengapa SIOS HANA Multitarget Automation adalah Kesepakatan Lebih Besar Daripada yang Anda Pikirkan

Larry (bukan nama sebenarnya) adalah pelanggan SIOS yang telah menerapkan solusi replikasi untuk ketersediaan tinggi dan pemulihan bencana (HA/DR) di masa lalu. Saat dia meluncurkan PoC untuk menguji solusi replikasi dua node untuk Linux, menggunakanPenjaga Kehidupan SIOSdan replikasi DataKeeper, prioritas utamanya adalah perlindungan integritas data. Daftar pengujian PoC Larry menyertakan item standar termasuk: mulai / berhenti basis data, memigrasikan basis data ke node cadangan, aktivitas pemeliharaan, dan kegagalan server hanya untuk beberapa nama. Larry bersikukuh bahwa solusinya mampu melakukan peralihan server yang cepat, (yaitu, migrasi yang anggun), dan cepatfailover(yaitu, migrasi mendadak dan paksa), aplikasi, database, penyimpanan, dan layanan dari satu server ke server lainnya. Tapi, dia bahkan lebih kuat dan bersemangat agar aktivitas seperti itu tidak menyebabkan hilangnya data.

Lindungi Integritas Data Dengan Menghindari Otak Terbelah

Selain tes standar ini, Larry menambahkan tes khusus untuk mencoba memaksakan “otak terbelahskenario. Split brain adalah suatu kondisi yang terjadi ketika anggota cluster tidak dapat berkomunikasi satu sama lain, tetapi dalam keadaan berjalan dan beroperasi, dan kemudian mengambil kepemilikan sumber daya bersama secara bersamaan. Akibatnya, Anda memiliki dua pengemudi bus yang memperebutkan kemudi. Karena sifatnya yang merusak, otak terbelah, dapat menyebabkan kehilangan data atau kerusakan data dan sebaiknya dihindari melalui penggunaan mekanisme untuk menentukan node mana yang harus tetap aktif (mengemudikan bus) dan node mana yang harus berhenti menulis ke disk.

Sementara skenario otak terbelah relatif tidak umum dalam kelompok yang menerapkan penggunaan kuorum dan kuorum plus kemampuan saksi, kesulitan resolusi otak terbelah meningkat secara eksponensial dengan setiap node ditambahkan ke konfigurasi kelompok. Dalam konfigurasi multitarget dengan tiga node atau lebih, perangkat lunak pengelompokan tidak hanya harus mengatur failover ke node yang benar, tetapi juga harus secara otomatis mengalihkan replikasi dari node primer baru ke node tersier untuk mempertahankan perlindungan DR sambil memastikan untuk menengahi dengan benar antara node. Dalam solusi pengelompokan lainnya, tindakan kompleks tersebut harus ditulis secara manual dan diperbarui secara manual jika terjadi kegagalan dan sekali lagi untuk memulihkan operasi normal, dan itu semakin sulit ketika otak terbelah terjadi.

Karena fitur dan peningkatan di SIOS LifeKeeper danKit Pemulihan Aplikasi SAP HANA(ARK), Larry mengalami kesulitan memperkenalkan skenario otak terbelah. Namun, ketika dia akhirnya dapat membuatnya, dia mendapat manfaat besar dari memahami logika yang digunakan produk SIOS untuk melindungi datanya. Larry menyadari kecanggihan tingkat tinggi yang dirancang ke dalam perlindungan data yang disediakan oleh perangkat lunak pengelompokan SIOS. Dia memilih SIOS LifeKeeper.

Perbedaan Otomasi Multitarget SIOS HANA

Skenario seperti Larry hanyalah salah satu dari sembilan alasan otomatisasi multitarget HANA SIOS adalah masalah yang lebih besar daripada yang Anda pikirkan. Inilah kesembilannya:

1. Perlindungan yang Ditingkatkan
   Solusi SIOS menyederhanakan perlindungan sumber daya database HANA dalam skenario multitarget. Opsi berbasis wizard dengan cepat mendeteksi konfigurasi saat ini dan secara tepat menambahkan informasi ke konfigurasi LifeKeeper. Deteksi kesalahan ringkas dan informatif untuk membantu pengguna menyelesaikan masalah apa pun dan selanjutnya menghemat waktu.
2. Administrasi yang disederhanakan
   Natalie (bukan nama sebenarnya) bertanggung jawab atas konfigurasi multinode HANA. Saat server gagal atau memerlukan pemeliharaan, Natalie memanfaatkan berbagai skrip dan alat untuk melakukan tindakan yang diperlukan. Namun, ini tidak dapat diskalakan. Setelah pindah ke SIOS LifeKeeper, Natalie dan tim memiliki UI sederhana untuk melakukan semua tugas inti seperti menghentikan dan memulai ulang replikasi sistem HANA dan HANA. Selain itu, jika terjadi bencana, tim dapat menggunakan UI SIOS tunggal yang disederhanakan alih-alih mencari runbook terbaru, menemukan salinan skrip yang tepat, atau menelepon Natalie pada pukul 02.00. .
3. Pemantauan Sederhana
   Laporan status intuitif SIOS di UI memberi tim cara cepat untuk menentukanreplikasistatus. Menggunakan satu alat, versus kumpulan papan pemantauan dan skrip buatan sendiri, menyederhanakan administrasi dan menghemat waktu.
4. Pemulihan Otomatis
   Beberapa solusi HANA HSR mampu melakukan failover replikasi HANA antara kedua node tersebut. Namun, administrator sering kali harus mendaftarkan ulang replikasi setelah kegagalan sistem. Dalam kasus tiga node atau lebih, apakah administrator memahami cara memperbarui pendaftaran pada node ketiga atau keempat? Apakah mereka akan ingat untuk menggunakan sinkronisasi dan asinkron dengan tepat? Solusi SIOS, yang mampu menangani tiga atau bahkan empat node untuk replikasi multitarget, akan secara mulus mengotomatiskan pendaftaran node target setelah kegagalan.
5. Fleksibilitas dan Skalabilitas
   Kemampuan untuk melindungi klaster HANA dalam dua, tiga, atau empat kombinasi node berarti pelanggan memiliki fleksibilitas untuk meningkatkan tingkat ketersediaan dan pemulihan bencana mereka. Pelanggan dua node, dengan kuorum, dapat memberikan perlindungan ketersediaan terhadap bencana dan menangani aktivitas pemeliharaan dengan downtime hampir nol memanfaatkan pengambilalihan HANA dengan fitur jabat tangan. Pelanggan yang menerapkan tiga node dapat memanggil fungsionalitas pemulihan bencana tambahan dengan menerapkan node ketiga dengan replikasi asinkron di pusat data atau wilayah yang berbeda. Untuk manfaat tambahan, pelanggan tiga node dapat menggunakan node keempat, dengan kuorum penyimpanan, untuk mengaktifkanketersediaan tinggiDanpemulihan bencanajika terjadi kehilangan seluruh pusat data.
6. Perlindungan data
   Mari kita kembali ke masalah Larry. Dia menjalankan HANA di node utama A dengan replikasi multitarget ke Node B dan C. Apa yang terjadi jika upaya manual Anda berakhir dengan bencana? Node mana yang primer? Apakah semuanya sinkron saat node A mogok? Bagaimana saya menghindari memunculkan node yang salah? Selain menambahkan dukungan untuk tiga node atau lebih dalam konfigurasi HSR multi-target, HANA ARK yang baru menyertakan alat admin tambahan untuk membantu jika terjadi bencana atau kejadian otak terbelah yang tidak menguntungkan.

   Bendera HANA_DATA_OUT_OF_SYNC_<tag> mencegah pengguna mengembalikan database secara tidak sengaja pada sistem yang salah. Bendera HANA_LAST_OWNER_<tag> membantu administrator mengetahui kapan suatu tindakan diambil pada sistem utama saat node siaga tidak sinkron. Bendera ini memberi tahu administrator bahwa node ini adalah pemilik terakhir dan harus menjadi tempat replikasi dilanjutkan. HANA_DATA_CONSISTENTCY_UNKNOWN_<tag> membantu SIOS untuk secara otomatis menyelesaikan dan memulihkan replikasi ketika semua komunikasi antara standby terputus untuk sementara dan kemudian dipulihkan. Saat digunakan dengan praktik terbaik, penerapan kuorum, dan penyetelan yang tepat, alat ini memungkinkan administrator seperti Larry untuk menghindari otak terbelah dan memulihkan dengan aman jika dan saat itu terjadi.

7. Pelaporan, Kinerja dan Pemulihan Bencana
   Tentu saja manfaat sebenarnya dari multi-target ada di node ekstra dan fungsionalitas yang dibuka oleh node ini. Menggunakan tiga node di pusat data yang sama dapat membuka potensi lebih banyak pelaporan melalui parameter logreplay_readaccess, sambil tetap mempertahankan node di situs DR. Selain itu, dukungan SIOS untuk berbagai mode replikasi memberi pengguna opsi untuk memiliki node sinkronisasi dan node async untuk kinerja yang lebih baik di seluruh pusat data (atau wilayah).
8. Pengujian Berkelanjutan
   Seberapa sering tim Anda menguji skrip buatan sendiri? Seberapa sering runbook Anda ditinjau sehubungan dengan skenario konfigurasi, administrasi, dan pukul 2 pagi. Solusi multi-target HANA tidak hanya terus diuji oleh teknisi SIOS, QA, dan pakar Pengalaman Pelanggan, tetapi solusi tersebut juga terus diuji dan divalidasi untuk proses failover dan pemulihan HANA dengan setiap rilis dan pembaruan.
9. Dokumentasi Luas
   Beberapa waktu lalu tim kami bekerja dengan pelanggan untuk administrasi cluster. Sementara pendahulunya sangat berpengetahuan tentang lingkungan mereka, promosi dan reorganisasi staf telah membuat banyak orang TI bertanggung jawab atas sistem yang hanya sedikit mereka ketahui. Saat ditanya tentang runbook dan dokumentasi konfigurasinya, pelanggan tidak dapat menemukan detail dari tim sebelumnya atau administrator sebelumnya. Selain otomatisasi, administrasi, pemantauan, pemulihan, dan perlindungan data yang kokoh, solusi multi-target SIOS mencakup dokumentasi terperinci dan mudah digunakan tentang implementasi, pengoperasian, dan pengelolaan sistem multitarget HANA yang dikendalikan oleh LifeKeeper.

Memanfaatkan solusi total SIOS berarti pelanggan dapat memperoleh manfaat dari pemantauan dan deteksi yang konsisten dan tepat waktu, pemulihan yang cepat, andal, dan efisien, serta solusi yang sepenuhnya otomatis yang menjamin ketersediaan tinggi dan perlindungan pemulihan bencana.Hubungi kamiuntuk informasi lebih lanjut tentang otomatisasi multitarget SAP HANA.

-Oleh Cassius Rhue, Pengalaman Pelanggan VP

Direproduksi dengan izin dariSIOS

Video: Bagaimana SIOS Membuat Ketersediaan Tinggi & Pemulihan Bencana Mudah Di Lingkungan SAP HANA

Dalam video ini,Todd Doane, Arsitek Solusi di SIOS, berbicara tentang bagaimana SIOS menyediakan ketersediaan tinggi dan pemulihan bencana (HA/DR) di lingkungan SAP HANA.

Sorotan dari wawancara video ini:

• SAP HANA adalah lingkungan yang kompleks dengan tiga lapisan: presentasi, aplikasi, dan basis data. Meskipun lapisan presentasi mudah untuk dilindungi, dua lainnya menghadirkan tantangan. Ada berbagai proses yang berjalan, ada data yang berpindah antar lapisan dan antar server, ada replikasi yang terjadi. Ada banyak kemungkinan skenario kegagalan dan banyak hal yang harus dipantau, selain mengikuti praktik terbaik SAP. Untuk memastikan tujuan titik pemulihan (RPO) dari kehilangan data mendekati nol adalah tugas yang menakutkan.
• Kuncinya adalah mengurangi satu titik kegagalan, banyak server di setiap lapisan, dengan replikasi ke server pasif dan siaga serta server pemulihan bencana. Dan itu perlu didistribusikan melalui beberapa pusat data.
• Penyebab kegagalan terbesar adalah ketika ada banyak tugas dan skrip yang perlu dijalankan dan seseorang melakukannya secara manual. Ini meningkatkan kemungkinan kesalahan manusia. Oleh karena itu, untuk dapat menyediakan lingkungan HA/DR yang baik, Anda memerlukan 1) otomatisasi, dan 2) perencanaan dan pengujian yang sering dilakukan untuk memastikan bahwa HA berfungsi seperti yang diharapkan, database Anda didaftarkan, dan failover benar-benar lancar.
• Setelah lingkungan SAP HANA diatur, fileSuite Perlindungan SIOSinstalasi dan konfigurasi dapat dilakukan melalui wizard GUI, yang memakan waktu sekitar satu jam. Itu mengatur dan mengotomatisasi untuk membuat failover menjadi sangat mudah. Itu mematuhi semua praktik terbaik SAP untuk operasi lanjutan yang cepat dan andal. Ini juga menampilkan “pengambilalihan dengan jabat tangan” dari database SAP HANA.
• SIOS baru-baru ini menambahkan dukungan node ketiga SAP HANA. SIOS selalu dapat melakukannya di lapisan aplikasi tetapi sekarang, SIOS juga dapat mendukungnya di lapisan basis data.

Direproduksi dengan izin dariSIOS

tes terjemahan dua

Daftar Istilah: Pengelompokan SQL Server

Definisi: Pengelompokan server SQL menyediakan ketersediaan tinggi dan perlindungan dari bencana setiap kali server yang menghosting instance SQL Server gagal.

Direproduksi dari SIOS