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
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)
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.

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
| Tugas | Deskripsi | Keterampilan 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 |
| Tugas | Deskripsi | Keterampilan yang dibutuhkan |
|---|---|---|
Inisialisasi Pemulihan Bencana Elastis. | Buka konsol Elastic Disaster Recovery | Administrator AWS |
Siapkan server replikasi. |
| Administrator AWS |
Konfigurasikan volume dan grup keamanan. |
| Administrator AWS |
Konfigurasikan pengaturan tambahan. |
| Administrator AWS |
| Tugas | Deskripsi | Keterampilan yang dibutuhkan |
|---|---|---|
Buat peran IAM. | Buat peran IAM yang berisi | 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.
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 |
| Tugas | Deskripsi | Keterampilan yang dibutuhkan |
|---|---|---|
Edit pengaturan peluncuran. | Untuk memperbarui pengaturan peluncuran untuk instance drill dan recovery, pada konsol Elastic Disaster Recovery | Administrator AWS |
Konfigurasikan pengaturan peluncuran umum. | Merevisi pengaturan peluncuran umum sesuai dengan kebutuhan Anda.
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 |
| Tugas | Deskripsi | Keterampilan yang dibutuhkan |
|---|---|---|
Memulai Bor |
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.
| |
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.
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.
Untuk informasi selengkapnya, lihat Melakukan failback dalam dokumentasi Elastic Disaster Recovery. | Administrator AWS |
Mulai komponen JD Edwards EnterpriseOne . |
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). catatanElastic 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
| Isu | Solusi |
|---|---|
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. catatanJika 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. | Sebelum Anda menginstal AWS Replication Agent di RHEL 8, CentOS 8, atau Oracle Linux 8, jalankan:
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
Membuat rencana pemulihan bencana yang dapat diskalakan dengan AWS Elastic Disaster Recovery
(postingan blog AWS) AWS Elastic Disaster Recovery - Pengantar Teknis
(kursus AWS Skill Builder; memerlukan login)