Cara Menyiapkan Edisi Cluster DataKeeper (Cluster DKCE)

Apa itu klaster DKCE?

DKCE adalah singkatan dariEdisi Cluster DataKeeper. DKCE adalah perangkat lunak SIOS yang menggabungkan penggunaan DataKeeper dengan fiturPengelompokan Failover Windowsuntuk menyediakanketersediaan tinggimelalui replikasi data berbasis migrasi.

Langkah-langkah membuat cluster DKCE

Untuk contoh ini, saya akan menyiapkan cluster tiga node dengan node ketiga mempertahankan mayoritas node.

Langkah 1:Anda harus menginstal DataKeeper di 2/3 sistem Anda untuk menyiapkan klaster DKCE. Klik tautan berikut untuk mengikuti panduan memulai cepat kami untuk menyelesaikan instalasi ini:https://docs.us.sios.com/dkce/8.10.0/en/topic/datakeeper-cluster-edition-quick-start-guide

Langkah 2:Tambahkan server yang ingin Anda kelola di Manajer Server. Ini perlu dilakukan di semua server yang Anda rencanakan untuk ditambahkan ke cluster.

Di server Anda, navigasikan ke Manajer Server

Klik “Tambahkan server lain untuk dikelola”

Saya menambahkan server dengan namanya di sini. Untuk melakukannya dengan cara ini Anda perlu memverifikasi nama sistem dan entri IP Anda di file host, yang terletak di sini: C:\Windows\System32\drivers\etc\hosts

Setelah semua server ditambahkan, Anda dapat memverifikasi dengan membuka “Semua server” di Manajer Server

Langkah 3:Anda mungkin melihat kesalahan winRM, untuk melewatinya jalankan perintah ini di PS sebagai administrator. Jalankan perintah ini untuk menambahkan server di klaster Anda sebagai host tepercaya. Perintah ini harus dijalankan pada setiap sistem di cluster Anda.

Set-Item WSMan:\localhost\Client\TrustedHosts -Nilai ‘<nama server 1>,<nama server 2>’

Langkah 4:Instal Pengelompokan Failover

Mengikutilangkah-langkah ini untuk menginstal pengelompokan failover.

Langkah 5:Navigasikan ke Manajer Kluster Failover

Langkah 6:Klik “Buat Klaster”

Langkah 7:Selanjutnya, tambahkan server yang seharusnya ada di cluster dan klik “Tambah” setelah setiap entri.

Langkah 8:Daftarnya harus serupa dengan yang ada pada gambar berikut

Langkah 9:Pilih “Jalankan semua pengujian” untuk pengujian validasi, dan klik Berikutnya.

Langkah 10:Setelah tes selesai, klik “Selesai”

Langkah 11:Namai cluster anda, saya beri nama cluster ini “Cluster1”, klik “Next”

Langkah 12:Pastikan “Tambahkan semua penyimpanan yang memenuhi syarat ke cluster” dicentang, klik “Berikutnya”

Langkah 13:Setelah langkah 12 selesai, klik “Selesai”

Langkah 14:Di Failover Cluster Manager, cluster pada awalnya akan offline. Saya akan menetapkan IP yang tidak terpakai untuk menjadikannya online. Di “Cluster Core Resources” klik kanan pada sumber daya alamat IP dan pilih Properties.

Di panel properti, subnet mask saya adalah /28, oleh karena itu saya akan memilih IP yang tersedia dalam rentang tersebut, 12.0.0.14. Klik “Terapkan”

Di “Cluster Core Resources” klik kanan pada cluster dan pilih “Bring Online”

Sumber daya sekarang harus online

Langkah 15:Navigasi ke Penjaga Data

Langkah 16:Klik kanan pada Job dan klik “Create Job” untuk mulai membuat mirror pertama kita

Beri nama pekerjaan itu. Saya memberi nama pekerjaan saya “pekerjaan1”, dan klik “Buat Pekerjaan”

Pilih sumber dan volume untuk mereplikasi data. Saya telah memilih Box1 sebagai sumber saya, dan volume D, klik “Berikutnya”

Selanjutnya, pilih server dan volume yang akan dijadikan target. Saya telah memilih Box2, dan volume D.

Sebuah prompt akan muncul meminta Anda untuk mendaftarkan secara otomatis volume yang telah Anda buat sebagai volume WSFC, pilih “Ya” untuk menjadikan volume ini Sangat Tersedia.

Di DataKeeper Anda sekarang dapat melihat bahwa volume sedang dicerminkan.

Langkah 17:Di Failover Cluster Manager, navigasikan ke Penyimpanan, lalu Disk. Anda akan melihat volume yang Anda daftarkan secara otomatis adalah WSFC.

Langkah 18:Mari kita verifikasi Pemilik yang harus diperiksa. Klik kanan pada volume, dan klik “Properti”

Karena saya membutuhkan orang ketiga untuk menjadi saksi dan mempertahankan mayoritas node, Box3 harus tidak dicentang/tetap tidak dicentang.

Langkah 19:Sekarang kita dapat menguji migrasi melalui Failover Cluster Manager. Navigasikan ke File Explorer dan buat file teks baru dalam volume yang saat ini sedang dicerminkan. Lakukan ini di Sumber Anda.

Navigasikan ke Failover Cluster Manager, klik “DataKeeper Volume D” dan pilih “Move Available Storage” dari panel Actions.

Klik kanan “Node Terbaik”. Ini secara otomatis akan bermigrasi ke target Anda.

Di Failover Cluster Manager verifikasi pemilik “DataKeeper Volume D” sekarang menjadi node target

Navigasikan ke DataKeeper untuk memverifikasi bahwa target Anda sekarang adalah Sumbernya, dan sebaliknya.

Penyiapan Klaster DKCE berhasil

Anda telah menyelesaikan penyiapan klaster DKCE.

SIOS menyediakansumber dayaDanpelatihanuntuk semua produk kami.

Direproduksi dengan izin dariSIOS

Memastikan Akses Terhadap Aplikasi Pendidikan Kritis

Pendidikan dan teknologi informasi (TI) semakin tidak dapat dipisahkan. Apakah TI yang dimaksud adalah aplikasi yang mendukung papan tulis kelas, database yang mendukung sistem pendaftaran universitas, sistem manajemen pembelajaran (LMS), atau sistem pemeliharaan gedung yang mengontrol akses siswa ke laboratorium, asrama, dan ruang makan — jika merupakan komponen utama infrastruktur TI Anda tiba-tiba menjadi gelap, baik guru, administrator, maupun siswa tidak dapat mencapai apa yang ingin mereka capai. Misi institusi tersebut terganggu. Jika interupsi terlalu sering terjadi, jika pengalaman siswa, guru, dan administrator terganggu, maka reputasi institusi itu sendiri juga akan terpuruk.

Infrastruktur TI yang dirancang untuk memastikan ketersediaan tinggi (HA) aplikasi yang penting bagi pengalaman pendidikan dapat meminimalkan risiko gangguan dan hilangnya reputasi yang dapat terjadi jika karena alasan apa pun sistem menjadi tidak responsif. Dalam hal ini, infrastruktur HA didefinisikan sebagai infrastruktur yang mampu memastikan ketersediaan aplikasi utama tidak kurang dari 99,99% setiap saat. Dengan kata lain, ini berarti aplikasi penting Anda tidak akan offline secara tiba-tiba selama lebih dari empat menit per bulan.

Bagaimana cara mencapai HA? Pertanyaan itu sudah mudah dijawab, tapi itu bukan satu-satunya pertanyaan yang perlu Anda tanyakan. Hal yang sama pentingnya adalah: Aplikasi manakah yang sangat penting sehingga memerlukan konfigurasi HA? Intinya, infrastruktur TI yang dikonfigurasi untuk HA memiliki satu atau lebih rangkaian server sekunder dan subsistem penyimpanan yang ditempatkan di lokasi yang berbeda secara geografis (yang dapat berupa pusat data jarak jauh jika server utama Anda berada di lokasi atau dalam ketersediaan terpisah. zona [AZ] jika server Anda berada di cloud). Jika ada sesuatu yang menyebabkan aplikasi yang berjalan di server utama berhenti merespons, perangkat lunak HA yang mengelola aplikasi Anda akan segera mengalihkan aplikasi ke server sekunder, di mana aplikasi penting Anda akan dimulai kembali dari titik di mana server utama berhenti merespons. Bergantung pada ukuran dan karakteristik kinerja server utama yang ingin Anda replikasi, server sekunder tersebut mungkin mahal, jadi kecil kemungkinannya Anda akan mengonfigurasi semua aplikasi akademis Anda untuk HA. Setelah Anda menentukan aplikasi mana yang memerlukan investasi pada HA, Anda akan mengetahui di mana Anda perlu membangun lingkungan HA.

Pilihan untuk Mencapai Ketersediaan Tinggi

Setelah Anda memilih aplikasi yang ingin Anda lindungi, pilihan Anda untuk mencapai HA menjadi lebih jelas. Apakah mereka berjalan di Windows atau Linux? Apakah sistem manajemen basis data (DBMS) Anda memiliki dukungan bawaan untuk konfigurasi HA? Jika ya, apa batasannya? Jika aplikasi penting Anda berjalan di Windows dan SQL Server, misalnya, Anda dapat mengaktifkan HA menggunakan fitur Availability Group (AG) dari SQL Server itu sendiri. Alternatifnya, Anda dapat mengonfigurasi HA menggunakan alat pengelompokan SANless pihak ketiga, yang menawarkan opsi yang tidak ditawarkan oleh layanan AG di SQL Server. Jika Anda mencoba melindungi server database dari beberapa vendor, atau jika beberapa aplikasi penting Anda berjalan di Windows sementara yang lain berjalan di Linux, kemampuan Anda untuk mengelola HA akan difasilitasi dengan penggunaan solusi HA yang mendukung banyak DBMS dan OS platform. Memilih solusi cluster yang mengakomodasi beragam DBMS dan platform OS akan menyederhanakan manajemen, berbeda dengan potensi kompleksitas dan kerumitan dalam menangani beberapa layanan HA asli database secara bersamaan.

Memastikan Ketersediaan Tinggi melalui solusi HA asli database

Jika Anda menggunakan solusi HA asli database, seperti fitur AG pada SQL Server, perangkat lunak akan secara sinkron mereplikasi semua data dalam database SQL Server utama Anda ke instance identik dari database tersebut di server sistem sekunder. Jika terjadi sesuatu yang menyebabkan server utama berhenti merespons, maka fitur monitoring pada komponen AG secara otomatis akan menyebabkan server sekunder mengambil alih. Karena fitur AG telah mereplikasi seluruh data secara real time, server sekunder dapat segera mengambil alih dan hampir tidak ada gangguan layanan atau kehilangan data.

Banyak alat HA asli database beroperasi dengan cara yang sama. Namun ada beberapa peringatan ketika mempertimbangkan pendekatan database-native: Jika layanan HA digabungkan ke dalam DBMS itu sendiri, layanan tersebut hanya dapat mereplikasi data yang terkait dengan DBMS tersebut. Jika data penting lainnya berada di server utama Anda, data tersebut tidak akan direplikasi ke server sekunder dalam skenario HA asli database. Mungkin ada batasan lain mengenai apa yang juga akan direplikasi oleh layanan asli database. Jika Anda menggunakan fungsionalitas AG Dasar yang digabungkan ke dalam SQL Server Standard Edition, misalnya, setiap AG hanya dapat mereplikasi satu database SQL ke satu lokasi sekunder. Anda dapat membuat beberapa AG Dasar jika aplikasi Anda melibatkan beberapa database SQL, namun Anda tidak dapat mengontrol apakah setiap AG melakukan failover pada saat yang sama dalam situasi failover — dan masalah mungkin timbul jika tidak dilakukan. Salah satu cara mengatasi keterbatasan ini adalah dengan menggunakan fungsionalitas Always On AG yang digabungkan ke dalam SQL Server Enterprise Edition, yang memungkinkan replikasi beberapa database SQL ke beberapa server sekunder, namun hal ini bisa menjadi sangat mahal dari sudut pandang lisensi jika aplikasi Anda tidak melakukannya. jika tidak, gunakan salah satu fitur SQL Server Enterprise Edition.

Solusi HA asli database lainnya mungkin memiliki kendala serupa, jadi pastikan untuk memahaminya sebelum berinvestasi dalam pendekatan tersebut.

Memastikan Ketersediaan Tinggi melalui SANless Clustering

Sebagai alternatif terhadap pendekatan database-asli terhadap HA, Anda dapat menggunakan alat pihak ketiga untuk membuat klaster SANless. Sama seperti konfigurasi AG yang dijelaskan di atas, perangkat lunak pengelompokan SANless mengotomatiskan replikasi data yang sinkron dari server primer ke server sekunder; itu juga mengatur failover langsung ke server sekunder jika server utama menjadi tidak responsif. Karena failover hanya membutuhkan waktu beberapa detik, akses administrator, dosen, dan mahasiswa ke aplikasi penting Anda akan tetap tidak terganggu.

Perbedaan penting antara pengelompokan SANless dan pendekatan database-native terletak pada detail praktisnya. Pendekatan pengelompokan SANless adalah basis data agnostik. Ini mereplikasi data apa pun pada volume penyimpanan yang ditentukan. Itu bisa mencakup banyak database dari beberapa vendor, file teks, file video, atau aset pendidikan lainnya yang ketersediaannya penting. Hal ini dapat menghemat banyak uang bagi institusi jika pendekatan database-native terhadap HA memerlukan upgrade ke edisi database yang lebih mahal. Terakhir, seperti disebutkan sebelumnya, jika Anda mencoba melindungi aplikasi dan data yang berjalan di beberapa lingkungan operasi, pendekatan pengelompokan SANless mungkin lebih mudah dikelola dibandingkan pendekatan database-asli individual. Anda dapat menggunakan pengelompokan SANless untuk memastikan HA di lingkungan Windows atau Linux, yang dapat menghilangkan kompleksitas yang mungkin menyertai penerapan pendekatan asli database yang berbeda antar lingkungan operasi.

Direproduksi dengan izin dariSIOS

Webinar: Pemulihan Bencana di Cloud: Memahami Tantangan dan Strategi untuk SQL Server

Daftar untuk Webinar Sesuai Permintaan

Memastikan ketersediaan tinggi (HA) dan pemulihan bencana (DR) di cloud dapat menjadi tantangan bagi banyak organisasi. Tantangan yang terkait dengan HA/DR di cloud mencakup kerumitan dalam memanfaatkan berbagai alat di berbagai vendor cloud, pertimbangan kedaulatan data, tantangan kepatuhan, dan manajemen biaya yang berkelanjutan.

Webinar ini akan membahas cara-cara untuk mengatasi tantangan-tantangan tersebut, menekankan pentingnya redundansi dan failover untuk layanan tanpa gangguan dan perlindungan data serta mengeksplorasi kesalahpahaman umum tentang ketahanan cloud dan perlunya pencadangan yang kuat dan strategi DR.

Direproduksi dengan izin dariSIOS

Bangun Ketersediaan Tinggi dengan Klaster HSR 3-Node HANA di AWS Menggunakan SIOS LifeKeeper

Pendahuluan: Cara Memastikan HA dan DR di Database Anda

Menciptakan lingkungan SAP HANA dengan ketersediaan tinggi di AWS adalah tugas penting bagi banyak bisnis. Panduan ini memberikan panduan mendetail untuk menyiapkan kluster Replikasi Sistem HANA (HSR) 3-node menggunakanPenjaga Kehidupan SIOSdi AWS, memastikan databaseketangguhanDanketersediaan tinggi.

Prasyarat

• Akun AWS dengan kemampuan untuk menerapkan instans EC2.
• Perangkat lunak SIOS LifeKeeper
• Evaluasi SIOS LifeKeeper atau lisensi permanen
• Perangkat lunak SAP HANA
• Keakraban dengan layanan AWS dan SAP HANA.

Langkah 1: Mempersiapkan Lingkungan AWS Anda

Penerapan Instans EC2

Terapkan tiga instans EC2 di AWS. Instans ini akan bertindak sebagai node primer, sekunder, dan tersier klaster HANA Anda. Pastikan mereka memenuhi persyaratan perangkat keras dan perangkat lunak untuk SAP HANA dan SIOS LifeKeeper. Pastikan Anda mengikuti pedoman ukuran SAP HANA saat membangun instans Anda.

konfigurasi jaringan

Konfigurasikan VPC, subnet, dan grup keamanan Anda untuk memungkinkan komunikasi antar node dan untuk memungkinkan akses ke layanan yang diperlukan.

Saat mengonfigurasi node HANA di wilayah berbeda, Anda dapat melindungi nama DNS menggunakan SIOS LifeKeeper untuk Linux Route53 Application Recovery Kit atau ARK. Berikut adalah arsitektur untuk database HANA 3 node di AWS:

Saat menyiapkan penyimpanan, gunakan volume EBS terpisah untuk /usr/sap, /hana/data, /hana/log, dan /hana/shared.

Kami memiliki 2 VPC, satu untuk setiap wilayah. Kita perlu menyiapkan peering antar VPC dan menambahkan rute ke tabel perutean untuk memastikan server dapat berkomunikasi satu sama lain. Kita juga perlu memodifikasi grup keamanan untuk mengizinkan lalu lintas antar server.

Terakhir, kita perlu membuat zona yang dihosting yang berisi VPC dan menambahkan catatan untuk domain dan nama host yang akan kita gunakan untuk berkomunikasi dengan node HANA yang aktif.

Langkah 2: Menginstal dan Mengonfigurasi SAP HANA

Instalasi pada Setiap Node

Instal SAP HANA pada setiap instans EC2. Pastikan versinya konsisten di semua node untuk menghindari masalah kompatibilitas. Sejauh ini, ini adalah proses yang paling menantang.

Mulailah dengan menentukan pengaturan instalasi Anda. Bagi saya, saya menggunakan yang berikut ini:

SID: D11

• Nomor Instans HANA: 11
• HANA db fqdn di Route53: saphana.sapdemo
• Nama host Node1: sapdemohana1
• Nama host Node2: sapdemohana2
• Nama host Node3: sapdemohana3
• Jenis instans: r5.4xlarge

Penyimpanan Instans Lokal:

• 30GB / (volume akar)
• 15GB /usr/sap
• 60GB /hana/bersama*
• 200GB /hana/data
• 200GB /hana/log

*Untuk instalasi ini, ini adalah penyimpanan yang tidak dibagi antara server database HANA ini. Jika Anda mencoba menggunakan penyimpanan bersama, Anda tidak akan dapat membuat server yang sama karena hdblcm akan mencegah penginstalan dengan kesalahan tentang SID dan instance yang sudah ada.

Instal perangkat lunak server HANA pada setiap node secara independen seolah-olah itu adalah sistem yang berdiri sendiri. Pastikan semua perpustakaan yang diperlukan telah diinstal, untuk RHEL 8 ada di SAP note 2772999. Anda harus memastikan Anda membuat tautan simbolik setelah menginstal compact-sap-c++-9-9.1.1-2.3.el7_6.x86_64.rpm dengan menjalankan: ln -s /opt/rh/SAP/lib64/compat-sap-++-10.so /usr/sap/lib/libstdc++.so.6

• yum install xorg-x11-server-Xorg xorg-x11-xauth -y #untuk GUI LifeKeeper
• yum instal nfs-utils

Buat partisi, format penyimpanan, dan lampirkan. Buat file swap Anda.

Saya membuat kunci RSA di semua host saya dan kemudian mengizinkan login root ssh antara node hana dengan menambahkan kunci publik ke file .ssh/authorized_keys. Ini akan membuat instalasi lebih mudah.

Pasang volume media instalasi HANA Anda.

• yum localinstall compat-sap-c++-10-10.2.1-11.el7_9.x86_64.rpm
• yum localinstall compat-sap-c++-9-9.1.1-2.3.el7_6.x86_64.rpm
• mkdir /usr/sap/lib
• ln -s /opt/rh/SAP/lib64/compat-sap-++-10.so /usr/sap/lib/libstdc++.so.6
• yum instal compat-sap-c++-10 libatomic -y

Jalankan hdblcm dari direktori media instalasi hana yang benar. Setelah Anda berhasil menginstal HANA di semua node, Anda siap untuk langkah berikutnya.

Pengaturan Replikasi Sistem

Anda perlu membuat cadangan sebelum mengaktifkan HSR:

• su – <SID>adm [yaitu. su -d11adm]
• hdbsql -i <nomor instan>adm -u sistem -p <kata sandi> [mis. hdbsql -i 11 -u sistem -p “kata sandi123”]
• DATA CADANGAN MENGGUNAKAN FILE(‘/usr/sap/<SID>/HDB<nomor contoh>’) [mis. CADANGAN DATA MENGGUNAKAN FILE(‘/usr/sap/D11/HDB11’)

Ulangi proses backup di atas pada semua node.

Konfigurasikan Replikasi Sistem HANA di setiap node:

Mulai instans HDB pada Sistem HANA utama jika belum berjalan: sapcontrol -nr <nomor instans> -function StartSystem HDB [yaitu: sapcontrol -nr 11 -function StartSystem HDB]

Mulai HSR di situs utama: hdbnsutil -sr_enable –name=<nama situs utama> [mis. hdbnsutil -sr_enable –nama=sapdemohana1

Hentikan instance HDB pada Sistem HANA sekunder: sapcontrol -nr <nomor instance> -function StopSystem HDB [mis. sapcontrol -nr 11 -fungsi StopSystem HDB]

Di sistem HANA tambahan, buat cadangan file KEY dan DAT dan salin file KEY dan DAT utama ke lokasi yang diperlukan:

• mv /usr/sap/<SID>/SYS/global/security/rsecssfs/data/SSFS_<SID>.DAT /usr/sap/<SID>/SYS/global/security/rsecssfs/data/SSFS_<SID>. DAT.BAK [mis. mv /usr/sap/D11/SYS/global/security/rsecssfs/data/SSFS_D11.DAT /usr/sap/D11/SYS/global/security/rsecssfs/data/SSFS_D11.DAT.BAK]

• mv /usr/sap/<SID>/SYS/global/security/rsecssfs/key/SSFS_<SID>.KEY /usr/sap/<SID>/SYS/global/security/rsecssfs/key/SSFS_<SID>. KUNCI.BAK [mis. mv /usr/sap/D11/SYS/global/security/rsecssfs/key/SSFS_D11.KEY /usr/sap/D11/SYS/global/security/rsecssfs/key/SSFS_D11.KEY.BAK]

• scp root@<simpul utama>:/usr/sap/<SID>/SYS/global/security/rsecssfs/data/SSFS_<SID>.DAT /usr/sap/<SID>/SYS/global/security/rsecssfs/ data/SSFS_<SID>.DAT [yaitu. scp root@sapdemohana1:/usr/sap/D11/SYS/global/security/rsecssfs/data/SSFS_D11.DAT /usr/sap/D11/SYS/global/security/rsecssfs/data/SSFS_D11.DAT]

• scp root@<simpul utama>:/usr/sap/<SID>/SYS/global/security/rsecssfs/key/SSFS_<SID>.KEY /usr/sap/<SID>/SYS/global/security/rsecssfs/ kunci/SSFS_<SID>.KEY [yaitu. scp root@sapdemohana1:/usr/sap/D11/SYS/global/security/rsecssfs/key/SSFS_D11.KEY /usr/sap/D11/SYS/global/security/rsecssfs/key/SSFS_D11.KEY]

Pastikan pemilik file kunci dan data adalah <SID>adm sapsys:

• [root@sapdemohana2 ~]# ls -l /usr/sap/D11/SYS/global/security/rsecssfs/data/
• jumlah 12
• -rw-r–r– 1 d11adm sapsys 2960 3 Jan 22:19 SSFS_D11.DAT
• -rw-r–r– 1 d11adm sapsys 2960 3 Jan 22:15 SSFS_D11.DAT.BAK

Daftarkan sistem HANA tambahan dengan sistem HANA utama – harus dilakukan sebagai pengguna admin:

• hdbnsutil -sr_register –name=<nama HSR sekunder> –remoteHost=<nama host utama sistem SAP HANA> –remoteInstance=<nomor instans jarak jauh> –operationMode=<delta_datashipping | pemutaran ulang log | logreplay_readaccess> –replicationMode=<sinkronisasi | sinkronisasi | asinkron>

[yaitu. hdbnsutil -sr_register –nama=sapdemohana2 –remoteHost=sapdemohana1 –remoteInstance=11 –operationMode=logreplay –replicationMode=sinkronisasi]

Periksa status HSR di semua sistem, jalankan perintah berikut sebagai pengguna admin: d11adm@sapdemohana4:/usr/sap/D11/HDB11>hdbnsutil -sr_state

Setelah semua sistem online, Anda dapat melanjutkan ke langkah berikutnya.

Langkah 3: Menginstal SIOS LifeKeeper

Instalasi AWS CLI

Instal AWS CLI dan konfigurasikan dengan kunci dengan izin berikut:

Konfigurasi Tabel Rute (backend):

• ec2:DescribeRouteTables
• ec2:GantiRute
• ec2:DescribeNetworkInterfaceAttribute
• ec2:ModifyNetworkInterfaceAttribute
• Konfigurasi IP elastis (frontend):
• ec2:DeskripsikanAlamat
• ec2:Alamat Asosiasi
• ec2:DisassociateAddress

Instalasi Penjaga Kehidupan

Instal SIOS LifeKeeper di setiap node. Ini melibatkan menjalankan skrip instalasi dan mengikuti wizard pengaturan, yang memandu Anda melalui langkah-langkah yang diperlukan. Untuk instalasi ini, saya menggunakan jaringan, Route53 ARK dan database, SAP HANA ARK beserta fungsi saksi.

Edit file /etc/selinux/config dan nonaktifkan selinux:

Saya juga mengubah nama host dan mengedit file/etc/hosts. Terakhir edit file /etc/default/LifeKeeper dan tambahkan /usr/local/bin ke PATH:

Ubah NOBCASPING=1:

Saya juga mengubah QUORUM_LOSS_ACTION menjadi osu:

Pastikan Xwindows Anda berfungsi. Saya menghapus alias cp dari .bashrc dan menambahkan /opt/LifeKeeper/bin dan /usr/local/bin ke .bash_profile saya bersama dengan menyalin file .Xauthority pengguna ec2 ke root dan direktori home <SID>adm sehingga Xwindows akan bekerja:

Saya mengubah kata sandi root dan reboot. Sebelum meluncurkan GUI LifeKeeper. pastikan HSR online di semua node dan semua node terdaftar:

Konfigurasi

Luncurkan LifeKeeper GUI: lkGUIapp dan login dengan pengguna root dan kata sandi:

Klik tombol sambungkan untuk masuk ke node tambahan di cluster:

Setelah masuk ke semua node, klik tombol Buat Jalur Komunikasi:

Tekan berikutnya ketika meminta Server Lokal lalu tahan shift dan pilih semua node:

tekan Accept Defaults dan tekan selesai jika sudah selesai. Klik pada tombol Create Comm path lagi dan kali ini ubah ke node kedua:

tekan berikutnya dan pilih node ke-3:

tekan tombol berikutnya hingga Anda dapat menekan tombol Terima Default. Ketika pukulan penuh selesai. Sekarang klik tombol Buat Hierarki Sumber Daya:

Pilih kit IP dan tekan berikutnya:

Tekan berikutnya hingga Anda masuk ke halaman sumber daya IP. Di sini masukkan 0.0.0.0 dan tekan berikutnya:

Tekan berikutnya sampai Anda mendapatkan tombol Buat. Tekan tombol Buat:

Ketika sudah selesai tekan berikutnya: Tekan Accept Defaults dengan Server Target menunjukkan node kedua:

Ketika selesai tekan Server Berikutnya:

Tekan Accept Defaults dengan node ke-3 muncul dan ketika selesai tekan Finish:

Selesai:

Sekarang kita memiliki sumber daya IP, kita dapat menambahkan sumber daya Route53 yang akan mengubah entri dns untuk menyelesaikan fqdn ke alamat IP node aktif. Dalam hal ini saphana.sapdemo akan menyelesaikan ke alamat ip sapdemohana1 (172.31.0.25). Tekan tombol Buat Hierarki Sumber Daya untuk memulai proses:

Pilih Route53 dan tekan berikutnya:

Terus tekan berikutnya sampai Anda mendapatkan Nama Domain. Ini harus diisi sebelumnya dengan nama zona yang di-hosting aktif. Tekan Berikutnya.

Masukkan Nama Host yang akan digunakan semuanya untuk terhubung ke database HANA dan tekan berikutnya:

tekan berikutnya sampai Anda mendapatkan tombol buat dan klik tombol buat. Setelah selesai tekan Berikutnya:

Pada Pre-Extend Wizard tekan Accept Defaults:

Setelah selesai, tekan Server Berikutnya:

Server Target akan menampilkan node ke-3. Tekan Terima Default:

Tekan Selesai setelah selesai. Lalu tekan Selesai. Anda kemudian dapat memperluas pohonnya. Buka sesi terminal ke node ke-2 dan ping fqdn untuk database HANA [mis. ping -c3 saphana.sapdemo]

Klik kanan pada standby atas di bawah sapdemohana3 dan pilih In Service:

Tekan In Service di layar berikutnya lalu tekan Selesai jika sudah selesai:

Buka jendela terminal dan ulangi tes ping:

Anda dapat melihat bahwa nama host sekarang ditetapkan menjadi sapdemohana3. Aktifkan kembali sapdemohana1 sebelum melanjutkan ke langkah berikutnya.

Langkah 4: Mengintegrasikan SAP HANA dengan SIOS LifeKeeper

Penciptaan Hirarki Sumber Daya

Menggunakan GUI LifeKeeper, buat hierarki sumber daya untuk SAP HANA di setiap node. Penyiapan ini sangat penting untuk mengelola proses failover dan pemulihan. Pastikan HSR aktif di node1 dan node tambahan terdaftar:

Klik pada tombol Buat Sumber Daya:

Pilih kit pemulihan SAP HANA dan tekan berikutnya hingga Anda masuk ke layar Alamat IP:

Pilih tidak ada dan tekan berikutnya:

Tekan berikutnya hingga Anda masuk ke layar Buat dan tekan Buat:

Setelah pembuatan, tekan berikutnya dan kemudian Terima Default untuk node2:

Sekali lagi ketika node2 selesai, tekan Server Berikutnya dan Terima Default:

Ketika selesai tekan Selesai, lalu tekan Selesai:

Klik kanan pada Hierarki Hana dan pilih Buat Ketergantungan:

Untuk Tag Sumber Daya anak, pilih sumber daya rute53 dari menu tarik-turun dan tekan berikutnya:

Klik Buat Ketergantungan:

Klik Selesai. Kemudian pilih tampilan Perluas Pohon:

Jika semuanya Hijau, kami siap mengujinya.

Langkah 5: Pengujian dan Validasi

Pengujian Failover/Peralihan

Lakukan pengujian failover menyeluruh untuk memastikan bahwa sistem beralih dengan benar ke node sekunder atau tersier jika terjadi kegagalan node primer. Pengujian ini harus mencakup skenario seperti kegagalan jaringan, masalah perangkat keras, dan kerusakan perangkat lunak.

Tes pertama yang akan kami lakukan adalah peralihan yang akan digunakan untuk melakukan aktivitas pemeliharaan atau jika Anda mengalami pemadaman terjadwal. Klik kanan pada node ke-2 dan pilih In Service – Takeover with Handshake…

Tekan Lakukan Pengambilalihan:

Pengujian ini akan beralih ke node ke-2 dengan waktu henti minimal bagi pengguna. Ketika node ke-2 aktif dan berjalan, tekan selesai:

Setelah beberapa waktu, node1 akan kembali siaga – Dalam Sinkronisasi.

Sekarang kita dapat melakukan tes failover. Buka terminal ke node 2 dan ketik echo c > /proc/sysrq-trigger untuk menyimulasikan kerusakan sistem. Anda akan melihat node 1 mengambil alih karena memiliki prioritas tertinggi 1:

Pada akhirnya, semuanya akan kembali normal:

Ada sejumlah jenis skenario kegagalan tambahan yang mungkin ingin Anda uji. Pastikan saja node siaga Anda sinkron sebelum memulai pengujian.

Verifikasi Sinkronisasi Data

Verifikasi bahwa data direplikasi dengan benar di semua node. Data yang konsisten di seluruh node sangat penting untuk integritas pengaturan HSR.

Pemantauan Kinerja

Pantau secara teratur kinerja instans SAP HANA dan pengaturan LifeKeeper. Periksa anomali atau masalah apa pun yang dapat mengindikasikan potensi masalah. Periksa file /var/log/lifekeeper.log untuk memastikan semuanya berjalan sesuai harapan. Anda mungkin perlu menyesuaikan pengatur waktu Detak Jantung dan jumlah detak jantung yang terlewat berdasarkan kinerja jaringan. Ini dapat dikonfigurasi di file /etc/default/LifeKeeper. Merdunya adalah LCMHBEATTIME dan LCMNUMHBEATS. Anda juga dapat memeriksa status Lifekeeper dari baris perintah dengan perintah lcdstatus -q.

Kesimpulan

Menyiapkan klaster HANA HSR 3-node di AWS dengan SIOS LifeKeeper melibatkan perencanaan dan pelaksanaan yang mendetail. Dengan mengikuti langkah-langkah ini secara cermat, Anda dapat membangun lingkungan SAP HANA yang kuat, tangguh, dan memiliki ketersediaan tinggi di cloud, memastikan data penting Anda tetap dapat diakses dan aman. SIOS LifeKeeper untuk Linux membuat administrasi, pemantauan, dan pemeliharaan SAP HANA menjadi cepat dan mudah.

SIOS menyediakansumber dayaDanpelatihanuntuk semua produk kami.

Direproduksi dengan izin dariSIOS