Memastikan Akses Terhadap Aplikasi Pendidikan Kritis

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

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

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

Wilayah Ibu Kota Nasional AS Melindungi Layanan Pengiriman Darurat Kritis dengan SIOS DataKeeper

Wilayah Ibu Kota Nasional AS Melindungi Layanan Pengiriman Darurat Kritis dengan SIOS DataKeeper

SIOS DataKeeper Melindungi Perangkat Lunak CAD-EX CAD2CAD Penting di SQL Server di Azure

Sampai saat ini, petugas operator menggunakan sistem pengiriman berbantuan komputer (CAD) yang memperkirakan kemungkinan keberadaan dan ketersediaan unit di yurisdiksi tetangga, namun untuk meminta pengiriman, mereka harus menghubungi lembaga tetangga tersebut melalui saluran telepon khusus untuk memvalidasi lokasi dan ketersediaan unit sebenarnya. . Proses ini memperlambat waktu respons dan tidak memberikan akses kepada responden pertama terhadap rincian insiden penting yang mungkin tersedia dari lembaga pengirim.

Untuk meningkatkan efisiensi, pimpinan lembaga NCR dan Emerging Digital Concepts (EDC) berkolaborasi untuk menciptakan Data Exchange Hub (DEH) – pertukaran data dan platform interoperabilitas fungsional yang dirancang untuk memberikan akses aman ke data dan aplikasi kepada lembaga layanan darurat anggota NCR. Mereka menggunakan Model Pertukaran Informasi Nasional (NIEM) untuk memastikan interoperabilitas sistem, komunikasi, dan prosedur.

DEH telah menjadi model nasional kerjasama regional yang efisien dalam tanggap darurat. Memastikan Layanan Pengiriman Darurat yang Efisien untuk Wilayah Ibu Kota Nasional SIOS DataKeeper Melindungi Perangkat Lunak CAD-EX CAD2CAD yang Penting di SQL Server di Azure.

Pertukaran informasi DEH yang utama adalah Pertukaran CAD-ke-CAD (C2C), yang memungkinkan operator di semua lembaga NCR DEH untuk segera memahami lokasi sumber daya garis depan, ketersediaan sumber daya, dan untuk berbagi informasi terkini tentang insiden terkait di semua sistem CAD yang terhubung dengan C2C Exchange di yurisdiksi anggota.

NCR DEH C2C Exchange menggunakan database Microsoft SQL Server yang beroperasi di Server Windows dan disebarkan di Azure Commercial Cloud. Mengingat sifat kritis dari sistem ini, DEH menuntut perlindungan data ketersediaan tinggi untuk platform C2C ​​Exchange. Failover Clustering tanpa Kompleksitas Tambahan. Dalam lingkungan ketersediaan tinggi (HA) Windows tradisional yang melibatkan database, dua atau lebih node instance database dikonfigurasikan dalam kluster failover Windows Server dengan penyimpanan bersama (biasanya SAN).

Basis data beroperasi pada node utama dengan perangkat lunak failover HA yang memantau operasinya. Jika masalah terdeteksi, perangkat lunak HA mengatur failover operasi database ke node sekunder siaga di cluster. Di cloud dan lingkungan lain di mana penyimpanan bersama tidak tersedia dan tidak hemat biaya, replikasi digunakan untuk membuat klaster SANless dengan menyinkronkan penyimpanan lokal di setiap node klaster sehingga, jika terjadi failover, node sekunder dapat melanjutkan untuk beroperasi dengan data saat ini.

Pada tahap awal proyek, tim IT NCR telah menerapkan platform C2C ​​Exchange di sejumlah lingkungan. Hal ini mencakup pusat data lokal Fairfax County dan kemudian di beberapa lingkungan penyedia hosting pihak ketiga, nasional dan lokal. Dalam lingkungan ini, arsitektur penyebaran database C2C Exchange menggunakan Microsoft SQL Server Enterprise Edition dan Grup Ketersediaan Always On.

Seiring dengan perluasan proyek, tim TI NCR terdorong untuk memanfaatkan kemajuan teknologi cloud dan menerapkan platform C2C ​​ke Azure Commercial Cloud. Cloud menawarkan fleksibilitas dan tingkat layanan yang diperlukan untuk mengelola platform C2C ​​di lingkungan yang lebih virtual.

Azure Cloud juga memungkinkan NCR untuk menyebarkan solusi pengelompokan database yang lebih hemat biaya dan ketersediaan tinggi untuk mengirimkan data aplikasi C2C Exchange dengan percaya diri sekaligus mengurangi biaya lisensi yang lebih tinggi yang terkait dengan SQL Server Enterprise Edition.

Solusinya

NCR DEH C2C Exchange mulai menggunakan perangkat lunak SIOS DataKeeper Cluster Edition untuk membuat kluster SANless guna melindungi ketersediaan data C2C Exchange mereka di Azure Commercial Cloud. Perangkat lunak ini berjalan pada konfigurasi cluster Windows Server Failover dua node aktif-pasif yang menggunakan SQL Server Standard Edition dengan Always On Failover Clustering.

Perangkat lunak SIOS DataKeeper menggunakan replikasi tingkat blok yang hemat bandwidth, berbasis host, untuk menyinkronkan penyimpanan lokal di semua node cluster database. Jika masalah ketersediaan aplikasi terdeteksi, operasi secara otomatis dipindahkan ke node sekunder tanpa memerlukan intervensi manual. Tingkat layanan yang dijamin oleh vendor cloud memastikan pengoperasian perangkat keras tetapi tidak mencakup penyebab downtime aplikasi yang terkait dengan perangkat lunak dan jaringan.

Hasil

NCR DEH C2C Exchange telah menggunakan perangkat lunak SIOS DataKeeper Cluster Edition di Azure Commercial Cloud selama lebih dari dua tahun. Partisipasi dalam program interoperabilitas telah meningkat. Selain anggota awal, program ini sekarang mencakup Otoritas Bandara Metro Washington (MWAA), Virginia County of Loudoun dan Prince William, dan Maryland County of Montgomery dan Prince George’s. Pertukaran C2C mengelola beberapa ribu unit bersama dan berbagi data tentang ratusan ribu insiden per tahun di antara para peserta ini.

Membangun klaster database ketersediaan tinggi di Cloud dapat dilakukan dengan cepat dan mudah menggunakan SIOS DataKeeper Cluster Edition. “Kami cukup menginstal SIOS DataKeeper ke node Windows Server Failover Cluster kami, mengonfigurasi penyimpanan node lokal sebagai penyimpanan terkelola SIOS untuk replikasi, dan beroperasi dengan lancar,” kata Greg Crider, Chief Technical Officer dan Co-Founder EDC. “Manfaat tambahan dari perangkat lunak pengelompokan SIOS DataKeeper adalah memungkinkan kami melakukan pemeliharaan perangkat lunak secara rutin dan berkelanjutan pada database dengan mentransisikan node kluster, sesuai permintaan, tanpa memerlukan waktu henti yang direncanakan atau gangguan layanan.”

Sejak penerapan SIOS DataKeeper di NCR C2C Exchange, tidak ada masalah waktu henti yang melibatkan database atau kehilangan data antar node. Chris Wiseman, Presiden, CEO, dan Co-Founder EDC menambahkan, “Ada beberapa masalah jaringan yang tidak terduga dan tidak terkendali, namun database gagal dengan cepat dan operasi C2C Exchange terus berlanjut tanpa pengguna akhir terpengaruh oleh pengurangan layanan yang berkepanjangan. Perangkat lunak SIOS DataKeeper memungkinkan kami memberikan tingkat perlindungan dan pengiriman data yang lebih tinggi tanpa memerlukan lisensi SQL Server Enterprise Edition yang lebih mahal. Hal ini menambah penghematan tahunan yang signifikan dan berkelanjutan bagi para pemangku kepentingan kami.”

NCR C2C Exchange dengan perlindungan SIOS DataKeeper ditampilkan oleh DHS/SAFECOM dalam tautan video). Baru-baru ini diuji ketika tiga kebakaran besar terjadi secara bersamaan di sebuah bank, kompleks apartemen, dan panti jompo. Interoperabilitas antar sistem CAD memainkan peran penting dalam memastikan respons yang cepat dan efisien terhadap insiden ini.

EDC memperluas adopsi C2C Exchange di seluruh Amerika Serikat di pasar lain dengan produk NG-CAD-X C2C Exchange yang tersedia secara komersial. Penawaran C2C yang canggih secara fungsional ini diterapkan di Wilayah Semua Bahaya Tengah Utara Kota Denver dan Florida Tenggara. NG-CAD-X adalah pesan yang kompatibel dengan NCR C2C Exchange, diterapkan di Azure Government Cloud untuk kepatuhan CJIS dan adopsi penegakan hukum selain kebakaran dan EMS ESF, dan juga mengimplementasikan SIOS DataKeeper Cluster Edition ke dalam arsitektur databasenya untuk semua alasan operasional dan hemat biaya yang disoroti di atas. “Kemitraan strategis memainkan peran penting dalam menyediakan solusi teknologi terbaik di pasar kepada pelanggan kami. SIOS DataKeeper merupakan bagian integral dari sistem kami dan merupakan mitra EDC yang berharga.” kata Kevin Konczal, Wakil Presiden, EDC.

Unduh pdfnya

Direproduksi dengan izin dariSIOS

Webinar: Amankan SAP dan SAP S/4HANA Anda di Azure: Praktik Terbaik Pemulihan Bencana

Webinar: Amankan SAP dan SAP S/4HANA Anda di Azure: Praktik Terbaik Pemulihan Bencana

Dalam lanskap digital saat ini, mengamankan aplikasi bisnis penting seperti SAP dan SAP S/4HANA sangat penting untuk melindungi terhadap potensi bencana yang dapat berdampak pada kelangsungan bisnis. Memanfaatkan kekuatan komputasi awan, Azure menyediakan solusi pemulihan bencana yang kuat untuk lingkungan SAP dan SAP S/4HANA. Sesi simposium sesuai permintaan ini membahas praktik terbaik untuk mengamankan sistem SAP dan SAP S/4HANA Anda di Azure, termasuk strategi untukreplikasi data, pencadangan dan pemulihan, ketersediaan tinggi, dan failover. Harikrishna Madathala, Insinyur Pelanggan Senior Microsoft untuk Jalur Cepat di SAP di cloud Azure, berbagi wawasan, tips praktis, dan contoh dunia nyata untuk membantu menerapkan praktik terbaik pemulihan bencana untuk melindungi penerapan SAP dan SAP S/4HANA di Azure, memastikan tingkat tertinggi keamanan, ketahanan, dan ketersediaan untuk aplikasi bisnis penting.

Direproduksi dengan izin dariSIOS