Siapkan pemulihan bencana untuk Oracle JD Edwards dengan EnterpriseOne AWS Elastic Disaster Recovery - AWS Prescriptive Guidance

Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.

Siapkan pemulihan bencana untuk Oracle JD Edwards dengan EnterpriseOne AWS Elastic Disaster Recovery

Thanigaivel Thirumalai, Amazon Web Services

Ringkasan

Bencana yang dipicu oleh bencana alam, kegagalan aplikasi, atau gangguan layanan merugikan pendapatan dan menyebabkan downtime untuk aplikasi perusahaan. Untuk mengurangi dampak dari peristiwa tersebut, perencanaan pemulihan bencana (DR) sangat penting bagi perusahaan yang mengadopsi sistem perencanaan sumber daya EnterpriseOne perusahaan (ERP) JD Edwards dan perangkat lunak mission-critical dan business critical lainnya. 

Pola ini menjelaskan bagaimana bisnis dapat menggunakan AWS Elastic Disaster Recovery sebagai opsi DR untuk aplikasi JD Edwards EnterpriseOne mereka. Ini juga menguraikan langkah-langkah untuk menggunakan failover dan failback Elastic Disaster Recovery untuk membangun strategi DR Lintas wilayah untuk database yang dihosting di instans Amazon Elastic Compute Cloud (Amazon EC2) di AWS Cloud.

catatan

Pola ini mengharuskan Wilayah primer dan sekunder untuk implementasi DR Lintas wilayah untuk di-host di AWS.

Oracle JD Edwards EnterpriseOne adalah solusi perangkat lunak ERP terintegrasi untuk perusahaan menengah hingga besar di berbagai industri.

AWS Elastic Disaster Recovery meminimalkan waktu henti dan kehilangan data dengan pemulihan aplikasi berbasis cloud dan lokal yang cepat dan andal dengan menggunakan penyimpanan yang terjangkau, komputasi minimal, dan pemulihan. point-in-time

AWS menyediakan empat pola arsitektur DR inti. Dokumen ini berfokus pada pengaturan, konfigurasi, dan pengoptimalan dengan menggunakan strategi pilot light. Strategi ini membantu Anda membuat lingkungan DR berbiaya lebih rendah di mana Anda awalnya menyediakan server replikasi untuk mereplikasi data dari database sumber, dan Anda menyediakan server database yang sebenarnya hanya ketika Anda memulai latihan dan pemulihan DR. Strategi ini menghilangkan biaya pemeliharaan server database di Wilayah DR. Sebaliknya, Anda membayar untuk EC2 instance yang lebih kecil yang berfungsi sebagai server replikasi.

Prasyarat dan batasan

Prasyarat

  • Akun AWS yang aktif.

  • EnterpriseOne Aplikasi JD Edwards yang berjalan di Oracle Database atau Microsoft SQL Server dengan database yang didukung dalam keadaan berjalan pada instance terkelola. EC2 Aplikasi ini harus mencakup semua komponen EnterpriseOne dasar JD Edwards (Server Perusahaan, Server HTML, dan Server Database) yang diinstal dalam satu Wilayah AWS.

  • Peran AWS Identity and Access Management (IAM) untuk menyiapkan layanan Elastic Disaster Recovery.

  • Jaringan untuk menjalankan Elastic Disaster Recovery dikonfigurasi sesuai dengan pengaturan konektivitas yang diperlukan.

Batasan

  • Anda dapat menggunakan pola ini untuk mereplikasi semua tingkatan, kecuali database di-host di Amazon Relational Database Service (Amazon RDS), dalam hal ini kami menyarankan Anda menggunakan fungsionalitas salinan lintas wilayah Amazon RDS.

  • Elastic Disaster Recovery tidak kompatibel dengan CloudEndure Disaster Recovery, tetapi Anda dapat meningkatkan dari CloudEndure Disaster Recovery. Untuk informasi selengkapnya, lihat FAQ di dokumentasi Elastic Disaster Recovery.

  • Amazon Elastic Block Store (Amazon EBS) membatasi tingkat di mana Anda dapat mengambil foto. Anda dapat mereplikasi jumlah maksimum 300 server dalam satu akun AWS dengan menggunakan Elastic Disaster Recovery. Untuk mereplikasi lebih banyak server, Anda dapat menggunakan beberapa akun AWS atau beberapa Wilayah AWS target. (Anda harus mengatur Elastic Disaster Recovery secara terpisah untuk setiap akun dan Wilayah.) Untuk informasi selengkapnya, lihat Praktik terbaik dalam dokumentasi Pemulihan Bencana Elastis.

  • Beban kerja sumber ( EnterpriseOne aplikasi dan database JD Edwards) harus di-host pada instance. EC2 Pola ini tidak mendukung beban kerja yang ada di tempat atau di lingkungan cloud lainnya.

  • Pola ini berfokus pada komponen JD Edwards EnterpriseOne . DR lengkap dan rencana kelangsungan bisnis (BCP) harus mencakup layanan inti lainnya, termasuk:

    • Jaringan (cloud pribadi virtual, subnet, dan grup keamanan)

    • Direktori Aktif

    • Amazon WorkSpaces

    • Penyeimbang Beban Elastis

    • Layanan database terkelola seperti Amazon Relational Database Service (Amazon RDS)

Untuk informasi tambahan tentang prasyarat, konfigurasi, dan batasan, lihat dokumentasi Pemulihan Bencana Elastis.

Versi produk

  • Oracle JD Edwards EnterpriseOne (versi yang didukung Oracle dan SQL Server berdasarkan Persyaratan Teknis Minimum Oracle)

Arsitektur

Tumpukan teknologi target

  • Wilayah tunggal dan cloud pribadi virtual tunggal (VPC) untuk produksi dan non-produksi, dan Wilayah kedua untuk DR

  • Zona Ketersediaan Tunggal untuk memastikan latensi rendah antar server

  • Application Load Balancer yang mendistribusikan lalu lintas jaringan untuk meningkatkan skalabilitas dan ketersediaan aplikasi Anda di beberapa Availability Zone

  • Amazon Route 53 untuk menyediakan konfigurasi Sistem Nama Domain (DNS)

  • Amazon WorkSpaces untuk menyediakan pengguna dengan pengalaman desktop di cloud

  • Amazon Simple Storage Service (Amazon S3) untuk menyimpan backup, file, dan objek

  • Amazon CloudWatch untuk pencatatan aplikasi, pemantauan, dan alarm

  • Amazon Elastic Disaster Recovery untuk pemulihan bencana

Arsitektur target

Diagram berikut menunjukkan arsitektur pemulihan bencana lintas wilayah untuk JD Edwards EnterpriseOne menggunakan Elastic Disaster Recovery.

Arsitektur untuk JD Edwards EnterpriseOne Lintas wilayah DR di AWS

Prosedur

Berikut adalah tinjauan tingkat tinggi dari proses tersebut. Untuk detailnya, lihat bagian Epik.

  • Replikasi Elastic Disaster Recovery dimulai dengan sinkronisasi awal. Selama sinkronisasi awal, AWS Replication Agent mereplikasi semua data dari disk sumber ke sumber daya yang sesuai di subnet area pementasan.

  • Replikasi berkelanjutan berlanjut tanpa batas waktu setelah sinkronisasi awal selesai.

  • Anda meninjau parameter peluncuran, yang mencakup konfigurasi khusus layanan dan templat EC2 peluncuran Amazon, setelah agen diinstal dan replikasi dimulai. Ketika server sumber ditunjukkan sebagai siap untuk pemulihan, Anda dapat memulai instance.

  • Saat Elastic Disaster Recovery mengeluarkan serangkaian panggilan API untuk memulai operasi peluncuran, instans pemulihan segera diluncurkan di AWS sesuai dengan pengaturan peluncuran Anda. Layanan ini secara otomatis memutar server konversi selama startup.

  • Instans baru diputar di AWS setelah konversi selesai dan siap digunakan. Status server sumber pada saat peluncuran diwakili oleh volume yang terkait dengan instance yang diluncurkan. Proses konversi melibatkan perubahan pada driver, jaringan, dan lisensi sistem operasi untuk memastikan bahwa instans melakukan booting secara native di AWS.

  • Setelah peluncuran, volume yang baru dibuat tidak lagi disinkronkan dengan server sumber. AWS Replication Agent terus secara rutin mereplikasi perubahan yang dilakukan pada server sumber Anda ke volume area pementasan, tetapi instance yang diluncurkan tidak mencerminkan perubahan tersebut.

  • Saat Anda memulai contoh bor atau pemulihan baru, data selalu tercermin dalam keadaan terbaru yang telah direplikasi dari server sumber ke subnet area pementasan.

  • Ketika server sumber ditandai sebagai sedang dipersiapkan untuk pemulihan, Anda dapat memulai instance.

catatan

Prosesnya bekerja dua arah: untuk failover dari Wilayah AWS utama ke Wilayah DR, dan gagal kembali ke situs utama, ketika telah dipulihkan. Anda dapat mempersiapkan failback dengan membalikkan arah replikasi data dari mesin target kembali ke mesin sumber dengan cara yang diatur sepenuhnya.

Manfaat dari proses ini yang dijelaskan dalam pola ini meliputi:

  • Fleksibilitas: Server replikasi skala dan skala berdasarkan dataset dan waktu replikasi, sehingga Anda dapat melakukan tes DR tanpa mengganggu beban kerja sumber atau replikasi.

  • Keandalan: Replikasi kuat, tidak mengganggu, dan berkelanjutan.

  • Otomatisasi: Solusi ini menyediakan proses terpadu dan otomatis untuk pengujian, pemulihan, dan kegagalan kembali.

  • Optimalisasi biaya: Anda hanya dapat mereplikasi volume yang dibutuhkan dan membayarnya, dan membayar sumber daya komputasi di situs DR hanya ketika sumber daya tersebut diaktifkan. Anda dapat menggunakan instance replikasi yang dioptimalkan biaya (sebaiknya gunakan jenis instans yang dioptimalkan komputasi) untuk beberapa sumber atau satu sumber dengan volume EBS yang besar.

Otomatisasi dan skala

Ketika Anda melakukan pemulihan bencana dalam skala besar, EnterpriseOne server JD Edwards akan memiliki dependensi pada server lain di lingkungan. Misalnya:

  • Server EnterpriseOne aplikasi JD Edwards yang terhubung ke database yang EnterpriseOne didukung JD Edwards saat boot memiliki dependensi pada database itu.

  • EnterpriseOne Server JD Edwards yang memerlukan otentikasi dan perlu terhubung ke pengontrol domain saat boot untuk memulai layanan memiliki ketergantungan pada pengontrol domain.

Untuk alasan ini, kami menyarankan Anda mengotomatiskan tugas failover. Misalnya, Anda dapat menggunakan AWS Lambda atau AWS Step Functions untuk mengotomatiskan skrip EnterpriseOne startup JD Edwards dan perubahan penyeimbang beban untuk mengotomatiskan proses failover. end-to-end Untuk informasi selengkapnya, lihat posting blog Membuat rencana pemulihan bencana yang dapat diskalakan dengan AWS Elastic Disaster Recovery.

Alat

Layanan AWS

  • Amazon Elastic Block Store (Amazon EBS) menyediakan volume penyimpanan tingkat blok untuk digunakan dengan instans. EC2

  • Amazon Elastic Compute Cloud (Amazon EC2) menyediakan kapasitas komputasi yang dapat diskalakan di AWS Cloud. Anda dapat meluncurkan server virtual sebanyak yang Anda butuhkan dan dengan cepat meningkatkannya ke atas atau ke bawah.

  • AWS Elastic Disaster Recovery meminimalkan waktu henti dan kehilangan data dengan pemulihan aplikasi berbasis cloud dan lokal yang cepat dan andal menggunakan penyimpanan yang terjangkau, komputasi minimal, dan pemulihan. point-in-time

  • Amazon Virtual Private Cloud (Amazon VPC) memberi Anda kontrol penuh atas lingkungan jaringan virtual Anda, termasuk penempatan sumber daya, konektivitas, dan keamanan.

Praktik terbaik

Praktik terbaik umum

  • Miliki rencana tertulis tentang apa yang harus dilakukan jika terjadi peristiwa pemulihan yang nyata.

  • Setelah Anda mengatur Elastic Disaster Recovery dengan benar, buat CloudFormation template AWS yang dapat membuat konfigurasi sesuai permintaan, jika diperlukan. Tentukan urutan di mana server dan aplikasi harus diluncurkan, dan catat ini dalam rencana pemulihan.

  • Lakukan latihan biasa ( EC2 tarif Amazon standar berlaku).

  • Pantau kesehatan replikasi yang sedang berlangsung dengan menggunakan konsol Elastic Disaster Recovery atau secara terprogram.

  • Lindungi point-in-time snapshot dan konfirmasikan sebelum menghentikan instance.

  • Buat peran IAM untuk instalasi AWS Replication Agent.

  • Aktifkan perlindungan terminasi untuk instance pemulihan dalam skenario DR nyata.

  • Jangan gunakan tindakan Putuskan sambungan dari AWS di konsol Elastic Disaster Recovery untuk server tempat Anda meluncurkan instans pemulihan, bahkan dalam kasus peristiwa pemulihan nyata. Melakukan pemutusan akan menghentikan semua sumber daya replikasi yang terkait dengan server sumber ini, termasuk titik pemulihan point-in-time (PIT) Anda.

  • Ubah kebijakan PIT untuk mengubah jumlah hari penyimpanan snapshot.

  • Edit template peluncuran di pengaturan peluncuran Elastic Disaster Recovery untuk mengatur subnet, grup keamanan, dan jenis instans yang benar untuk server target Anda.

  • Otomatiskan proses end-to-end failover dengan menggunakan Lambda atau Step Functions untuk mengotomatiskan skrip startup JD Edwards EnterpriseOne dan perubahan penyeimbang beban.

EnterpriseOne Optimalisasi dan pertimbangan JD Edwards

  • Pindah PrintQueueke database.

  • Pindah MediaObjectske database.

  • Kecualikan log dan folder temp dari server batch dan logika.

  • Kecualikan folder temp dari WebLogic Oracle.

  • Buat skrip untuk startup setelah failover.

  • Kecualikan tempdb untuk SQL Server.

  • Kecualikan file temp untuk Oracle.

Epik

TugasDeskripsiKeterampilan yang dibutuhkan

Siapkan jaringan replikasi.

Terapkan EnterpriseOne sistem JD Edwards Anda di Wilayah AWS utama dan identifikasi Wilayah AWS untuk DR. Ikuti langkah-langkah di bagian persyaratan jaringan Replikasi pada dokumentasi Pemulihan Bencana Elastis untuk merencanakan dan menyiapkan replikasi dan jaringan DR Anda.

Administrator AWS

Tentukan RPO dan RTO.

Identifikasi tujuan waktu pemulihan (RTO) dan tujuan titik pemulihan (RPO) untuk server aplikasi dan database Anda.

Arsitek awan, arsitek DR

Aktifkan replikasi untuk Amazon EFS.

Jika berlaku, aktifkan replikasi dari AWS primer ke Wilayah DR untuk sistem file bersama seperti Amazon Elastic File System (Amazon EFS) dengan menggunakan AWS DataSync, rsync, atau alat lain yang sesuai.

Administrator awan

Kelola DNS dalam kasus DR.

Identifikasi proses untuk memperbarui Sistem Nama Domain (DNS) selama latihan DR atau DR.

Administrator awan

Buat peran IAM untuk penyiapan.

Ikuti petunjuk di bagian inisialisasi dan izin Pemulihan Bencana Elastis pada dokumentasi Pemulihan Bencana Elastis untuk membuat peran IAM guna menginisialisasi dan mengelola layanan AWS.

Administrator awan

Siapkan pengintip VPC.

Pastikan bahwa sumber dan target VPCs diintip dan dapat diakses satu sama lain. Untuk petunjuk konfigurasi, lihat dokumentasi Amazon VPC.

Administrator AWS
TugasDeskripsiKeterampilan yang dibutuhkan

Inisialisasi Pemulihan Bencana Elastis.

Buka konsol Elastic Disaster Recovery, pilih Wilayah AWS target (tempat Anda akan mereplikasi data dan meluncurkan instans pemulihan), lalu pilih Setel pengaturan replikasi default.

Administrator AWS

Siapkan server replikasi.

  1. Di panel Siapkan server replikasi, masukkan subnet area pementasan dan tipe instance server replikasi. Pilih tipe instans t3.small yang dipilih secara default. Konfigurasikan setelan ini berdasarkan kebutuhan Anda, dan ingatlah untuk mempertimbangkan harga instans. Untuk informasi selengkapnya, lihat EC2 harga Amazon.

  2. Di bagian Akses layanan, pilih Lihat detail untuk meninjau peran terkait layanan dan kebijakan tambahan yang dibuat selama inisialisasi layanan.

  3. Pilih Berikutnya.

Administrator AWS

Konfigurasikan volume dan grup keamanan.

  1. Di panel Volume dan grup keamanan, pilih jenis volume EBS untuk server replikasi dan setel enkripsi Amazon EBS ke Default.

  2. Pilih Selalu gunakan grup keamanan AWS Elastic Disaster Recovery sehingga Elastic Disaster Recovery secara otomatis melampirkan dan memantau grup keamanan default.

  3. Pilih Berikutnya.

Administrator AWS

Konfigurasikan pengaturan tambahan.

  1. Di panel Pengaturan tambahan, konfigurasikan perutean dan pelambatan data, kebijakan PIT, dan tag.

    • Data routing dan throttling mengontrol bagaimana data mengalir dari server eksternal ke server replikasi. Pilih Gunakan IP pribadi untuk replikasi data. Jika tidak, server replikasi akan secara otomatis diberi IP publik, dan data akan mengalir melalui internet publik.

    • Di bagian kebijakan Point in time (PIT), konfigurasikan kebijakan retensi yang menentukan durasi setelah snapshot tidak diperlukan. Periode penyimpanan default adalah tujuh hari.

    • Di bagian Tag, tambahkan tag khusus ke sumber daya yang dibuat oleh Elastic Disaster Recovery di akun AWS Anda.

  2. Pilih Berikutnya, tinjau pengaturan di panel berikutnya, lalu pilih Buat default untuk membuat templat default.

Administrator AWS
TugasDeskripsiKeterampilan yang dibutuhkan

Buat peran IAM.

Buat peran IAM yang berisi AWSElasticDisasterRecoveryAgentInstallationPolicy kebijakan. Di bagian Select AWS Access Type, aktifkan akses terprogram. Perhatikan ID kunci akses dan kunci akses rahasia. Anda akan memerlukan informasi ini selama penginstalan AWS Replication Agent.

Administrator AWS

Periksa persyaratan.

Periksa dan lengkapi prasyarat dalam dokumentasi Elastic Disaster Recovery untuk menginstal AWS Replication Agent.

Administrator AWS

Instal AWS Replication Agent.

Ikuti instruksi penginstalan untuk sistem operasi Anda dan instal AWS Replication Agent.

  • Untuk Microsoft Windows: Unduh file pengaturan dan jalankan file.exe sebagai administrator.  Tanggapi petunjuk untuk menyelesaikan instalasi.

  • Untuk Linux: Salin perintah berikut (dalam urutan yang disajikan) dan tempelkan ke sesi Secure Shell (SSH) Anda. Perintah pertama mengunduh penginstal dan perintah kedua menjalankannya.

    wget -O ./aws-replication-installer-init.py https://aws-elastic-disaster-recovery-us-west-2.s3.amazonaws.com/latest/linux/aws-replication-installer-init.py
    sudo python3 aws-replication-installer-init.py

    Tanggapi petunjuk untuk menyelesaikan instalasi.

    catatan

    Ubah URL untuk mencerminkan Wilayah Anda.

Ulangi langkah-langkah ini untuk server yang tersisa.

Administrator AWS

Pantau replikasi.

Kembali ke panel server Elastic Disaster Recovery Source untuk memantau status replikasi. Sinkronisasi awal akan memakan waktu tergantung pada ukuran transfer data.

Ketika server sumber sepenuhnya disinkronkan, status server akan diperbarui ke Siap. Ini berarti bahwa server replikasi telah dibuat di area pementasan, dan volume EBS telah direplikasi dari server sumber ke area pementasan.

Administrator AWS
TugasDeskripsiKeterampilan yang dibutuhkan

Edit pengaturan peluncuran.

Untuk memperbarui pengaturan peluncuran untuk instance drill dan recovery, pada konsol Elastic Disaster Recovery, pilih server sumber, lalu pilih Actions, Edit launch settings. Atau Anda dapat memilih mesin sumber replikasi Anda dari halaman server Sumber, lalu pilih tab Launch Settings. Tab ini memiliki dua bagian: Pengaturan peluncuran umum dan templat EC2 peluncuran.

Administrator AWS

Konfigurasikan pengaturan peluncuran umum.

Merevisi pengaturan peluncuran umum sesuai dengan kebutuhan Anda.

  • Ukuran kanan tipe instans: Jika Anda memilih Basic, Elastic Disaster Recovery melewati jenis instans yang Anda pilih di template EC2 peluncuran Amazon dan secara otomatis memilih jenis instans berdasarkan sistem operasi, CPU, dan RAM server sumber.

  • Salin IP pribadi: Pilih apakah Anda ingin Elastic Disaster Recovery untuk memastikan bahwa IP pribadi yang digunakan oleh instance bor atau pemulihan cocok dengan IP pribadi yang digunakan oleh server sumber. Jika Anda memilih Ya, pastikan rentang IP subnet yang Anda tetapkan di template EC2 peluncuran Amazon menyertakan alamat IP pribadi.

Untuk informasi selengkapnya, lihat Pengaturan peluncuran umum di dokumentasi Elastic Disaster Recovery.

Administrator AWS

Konfigurasikan template EC2 peluncuran Amazon.

Elastic Disaster Recovery menggunakan template EC2 peluncuran Amazon untuk meluncurkan instans bor dan pemulihan untuk setiap server sumber. Template peluncuran dibuat secara otomatis untuk setiap server sumber yang Anda tambahkan ke Elastic Disaster Recovery setelah Anda menginstal AWS Replication Agent.

Anda harus mengatur template EC2 peluncuran Amazon sebagai template peluncuran default jika Anda ingin menggunakannya dengan Elastic Disaster Recovery.

Untuk informasi selengkapnya, lihat EC2 Luncurkan Template di dokumentasi Elastic Disaster Recovery.

Administrator AWS
TugasDeskripsiKeterampilan yang dibutuhkan

Memulai Bor

  1. Pada konsol Elastic Disaster Recovery, buka halaman server Sumber dan verifikasi bahwa status server sumber sudah Siap.

  2. Pilih semua server sumber yang ingin Anda lakukan latihan DR.

  3. Dari menu Initiate recovery job, pilih Initiate drill dan pilih snapshot yang sesuai point-in-time. Ini memulai pekerjaan pemulihan untuk server sumber yang dipilih. Anda dapat memantau status pekerjaan di tab Riwayat pekerjaan pemulihan.

    Instans bor yang diluncurkan juga muncul di halaman instans Pemulihan.

    catatan

    Perubahan lebih lanjut pada server sumber akan disinkronkan ke server replikasi, bukan ke instance bor.

  4. Uji dan verifikasi instance bor DR.

  5. Pada halaman instans Pemulihan, pilih instans bor, lalu pilih Tindakan, Putuskan sambungan dari AWS. Ini menghapus AWS Replication Agent dari instans pemulihan dan menghapus semua sumber daya yang terkait dengan instans pemulihan dari Elastic Disaster Recovery.

  6. Pilih Hapus instans pemulihan. Ini menghapus representasi instance dari konsol Elastic Disaster Recovery dan sepenuhnya memisahkan instance dari layanan Elastic Disaster Recovery. Itu tidak menghapus EC2 instance yang mendasarinya.

  7. Hentikan instans bor DR dari EC2 konsol Amazon.

Untuk informasi selengkapnya, lihat Mempersiapkan failover dalam dokumentasi Elastic Disaster Recovery.

Administrator AWS

Validasi bor.

Pada langkah sebelumnya, Anda meluncurkan instance target baru di Wilayah DR. Instance target adalah replika server sumber berdasarkan snapshot yang diambil saat Anda memulai peluncuran.

Dalam prosedur ini, Anda terhubung ke mesin EC2 target Amazon Anda untuk mengonfirmasi bahwa mereka berjalan seperti yang diharapkan.

  1. Buka EC2 konsol Amazon.

  2. Pilih Instans (berjalan).

  3. Pilih instance target dan catat IPv4 alamat pribadinya.

  4. Pastikan Anda dapat terhubung ke EC2 instance dan JD Edwards EnterpriseOne dan komponen terkait direplikasi seperti yang diharapkan.

Memulai failover.

Failover adalah pengalihan lalu lintas dari sistem primer ke sistem sekunder. Elastic Disaster Recovery membantu Anda melakukan failover dengan meluncurkan instans pemulihan di AWS. Ketika instans pemulihan telah diluncurkan, Anda mengarahkan lalu lintas dari sistem utama Anda ke instans ini.

  1. Pada konsol Elastic Disaster Recovery, buka halaman server Sumber dan verifikasi bahwa kolom Siap untuk pemulihan untuk server sumber menunjukkan Siap, dan kolom status replikasi data menunjukkan Sehat.

  2. Pilih server sumber. Dari menu Initiate recovery job, pilih Initiate recovery.

  3. Pilih point-in-time snapshot dari mana untuk meluncurkan instance pemulihan, dan kemudian pilih Memulai pemulihan.

    Ini memulai pekerjaan pemulihan. Anda dapat memantau status pekerjaan di halaman instans Pemulihan.

  4. Uji dan verifikasi instance pemulihan. Jika diperlukan, sesuaikan konfigurasi DNS dan hubungkan EnterpriseOne aplikasi JD Edwards Anda ke database.

  5. Anda sekarang dapat memutuskan dan menonaktifkan EnterpriseOne server sumber JD Edwards, karena semua perubahan telah ditulis ke instance pemulihan baru.

  6. Daftarkan instans pemulihan sebagai server sumber di Wilayah DR dengan mengikuti proses yang dijelaskan dalam epik Install the AWS Replication Agent.

Untuk informasi selengkapnya, lihat Melakukan failover dalam dokumentasi Elastic Disaster Recovery.

Administrator AWS

Memulai kegagalan kembali.

Proses untuk memulai failback mirip dengan proses untuk memulai failover.

  1. Buka konsol Elastic Disaster Recovery di Wilayah utama. Arahkan ke halaman instans Pemulihan, pilih instans bor, lalu pilih Tindakan, Putuskan sambungan dari AWS, Hapus instans pemulihan.

  2. Buka konsol Elastic Disaster Recovery di Wilayah DR. Daftarkan server JD Edwards baru Anda sebagai EnterpriseOne server sumber di Wilayah DR dengan menginstal AWS Replication Agent. Data akan disinkronkan dengan server replikasi baru yang disediakan di subnet pementasan baru.

    catatan

    Ketika server JD Edwards baru terdaftar sebagai EnterpriseOne server sumber, Anda mungkin melihat dua server sumber di konsol Elastic Disaster Recovery: satu server yang dibuat dari EC2 instance utama, dan server baru yang dibuat dari instance pemulihan. Kami menyarankan Anda menandai server dengan benar untuk menghindari kebingungan, dan sebaiknya tambahkan server baru ke template peluncuran.

  3. Untuk memulai ulang replikasi DR dari Wilayah utama, lepaskan instans pemulihan yang diluncurkan dari konsol Elastic Disaster Recovery di Wilayah DR, dan daftarkan host sebagai server sumber di Wilayah utama.

Untuk informasi selengkapnya, lihat Melakukan failback dalam dokumentasi Elastic Disaster Recovery.

Administrator AWS

Mulai komponen JD Edwards EnterpriseOne .

  1. Mulai EnterpriseOne database JD Edwards dengan masuk ke server database.

  2. Saat database berjalan, mulai EnterpriseOne logika JD Edwards dan server batch.

  3. Mulai WebLogic di server web, dan mulai instance JAS di server JAS.

  4. Mulai WebLogic di server penyediaan dan di server untuk konsol SM.

  5. Mulai SM Agent di server.

  6. Konfirmasikan bahwa login ke JD Edwards EnterpriseOne berfungsi dengan benar.

Anda harus memasukkan perubahan di Route 53 dan Application Load Balancer agar tautan JD Edwards berfungsi EnterpriseOne .

Anda dapat mengotomatiskan langkah-langkah ini dengan menggunakan Lambda, Step Functions, dan Systems Manager (Run Command).

catatan

Elastic Disaster Recovery melakukan replikasi tingkat blok dari volume EBS EC2 instance sumber yang menampung sistem operasi dan sistem file. Sistem file bersama yang dibuat dengan menggunakan Amazon EFS bukan bagian dari replikasi ini. Anda dapat mereplikasi sistem file bersama ke Wilayah DR dengan menggunakan AWS DataSync, seperti yang dicatat dalam epik pertama, dan kemudian memasang sistem file yang direplikasi ini di sistem DR.

JD Edwards CNC EnterpriseOne

Pemecahan Masalah

IsuSolusi

Status replikasi data server sumber terhenti dan replikasi tertinggal. Jika Anda memeriksa detail, status replikasi data menampilkan Agen tidak terlihat.

Periksa untuk mengonfirmasi bahwa server sumber yang macet sedang berjalan.

catatan

Jika server sumber turun, server replikasi secara otomatis dihentikan.

Untuk informasi selengkapnya tentang masalah lag, lihat Masalah lag replikasi dalam dokumentasi Elastic Disaster Recovery.

Instalasi AWS Replication Agent dalam EC2 instance sumber gagal di RHEL 8.2 setelah memindai disk. aws_replication_agent_installer.logmengungkapkan bahwa header kernel hilang.

Sebelum Anda menginstal AWS Replication Agent di RHEL 8, CentOS 8, atau Oracle Linux 8, jalankan:

sudo yum install elfutils-libelf-devel

Untuk informasi selengkapnya, lihat persyaratan instalasi Linux dalam dokumentasi Elastic Disaster Recovery.

Pada konsol Elastic Disaster Recovery, Anda melihat server sumber sebagai Siap dengan lag dan status replikasi data sebagai Stalled.

Bergantung pada berapa lama Agen Replikasi AWS tidak tersedia, statusnya mungkin menunjukkan kelambatan yang tinggi, tetapi masalahnya tetap sama.

Gunakan perintah sistem operasi untuk mengonfirmasi bahwa AWS Replication Agent berjalan di EC2 instance sumber, atau mengonfirmasi bahwa instans sedang berjalan.

Setelah Anda memperbaiki masalah apa pun, Elastic Disaster Recovery akan memulai kembali pemindaian. Tunggu hingga semua data telah disinkronkan dan status replikasi Sehat sebelum Anda memulai latihan DR.

Replikasi awal dengan lag tinggi. Pada konsol Elastic Disaster Recovery, Anda dapat melihat bahwa status sinkronisasi awal sangat lambat untuk server sumber.

Periksa masalah kelambatan replikasi yang didokumentasikan di bagian Masalah lag replikasi pada dokumentasi Elastic Disaster Recovery.

Server replikasi mungkin tidak dapat menangani beban karena operasi komputasi intrinsik. Jika demikian, coba tingkatkan jenis instans setelah berkonsultasi dengan tim AWS Technical Support.

Sumber daya terkait