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

Webinar: Ketahanan SAP di AWS: Praktik Terbaik untuk Mencapai Ketersediaan Tinggi dan Kontinuitas Bisnis

Webinar: Ketahanan SAP di AWS: Praktik Terbaik untuk Mencapai Ketersediaan Tinggi dan Kontinuitas Bisnis

Daftar untuk Webinar Sesuai Permintaan

Sesi simposium berdasarkan permintaan ini berfokus pada praktik terbaik yang ingin dicapaiketersediaan tinggidan kelangsungan bisnis untuk aplikasi SAP dan SAP S/4HANA di AWS. Dengan meningkatnya ketergantungan pada infrastruktur cloud, penting bagi bisnis untuk memiliki sistem SAP yang tangguh dan andal untuk melindungi data dan aplikasi penting mereka dari potensi gangguan.

AWS memberikan gambaran komprehensif tentang komponen utama ketersediaan tinggi dan pemulihan bencana untuk SAP dan SAP S/4HANA di AWS, termasuk pencadangan dan pemulihan, replikasi, dan failover. Dan jelajahi berbagai strategi dan alat yang tersedia di AWS. Dapatkan wawasan tentang cara membuat SAP dan SAP S/4HANA yang tangguh dan andal di AWS.

Direproduksi dengan izin dariSIOS