Considerations for Moving to the Cloud

Oracle provides a baseline architecture that takes best advantage of the Oracle Cloud Infrastructure capabilities, and also addresses most of the important technical and business requirements. This allows you to be confident in achieving your deployment objectives without investing in a long analysis project. Your strategy for moving your on-premises JD Edwards EnterpriseOne to the cloud depends on your environment, customized configurations, and the applications that use your data sources. For any special requirements that are not covered by this reference architecture, other design choices are possible. Oracle expects that the design process for those changes is much easier when starting from a reference architecture.

Key Workload Requirements

When you're evaluating to migrate your on-premises JD Edwards EnterpriseOne to the cloud, you can discuss with your Oracle account team.

The architectures that Oracle provides help you address these requirements:

• Designing for high availability and disaster recovery
• Deploying a secure architecture.
• Matching your high-performance and highly isolated network model.
• Migrating your application and database environments into the cloud.
• Maintaining visibility over costs and usage.
• Monitoring infrastructure health and performance.

Network and Connectivity

The primary objectives for the networking and connectivity architecture is to provide secure, high-speed connectivity between your cloud resources and any users and/or systems that would need to access those resources.

When running JD Edwards on Oracle Cloud Infrastructure, the networking and connectivity architecture meets these objectives:

• Access from corporate campuses to the application via private network links
• Encrypted links over the public internet
• Public internet end-points
• Private network connectivity to other systems or services hosted on Oracle Cloud Infrastructure
• Network-level isolation between application tiers
• Monitoring and management access to all application and database tiers
• Load-balancing across multiple application nodes for performance and availability
• Isolation from other customers and your other workloads
• Low network latency in remote datacenter

The following figure illustrates the networking and connectivity reference architecture:
Description of the illustration single_availability_domain_jd_edwards_deployment_withcallouts-networking.png

• Dedicated Network Access via FastConnect : Multiple partners in regions across the world offer dedicated network connections between your premises and Oracle datacenters. This allows you to access the JD Edwards implementation as if it was running in your own datacenter.
• Secure Network Access via IPSec VPN : For lower cost, but still secure access over the internet, you can use an encrypted Internet Protocol Security (IPsec) virtual private network (VPN) tunnel to connect from your HQ or on-premises data center to your JD Edwards resources in Oracle Cloud Infrastructure. From your on-premises environment, you can access your cloud instances in a private subnet by connecting through a Dynamic Routing Gateway (DRG). The DRG is the gateway that connects your on-premises network to your cloud network.
• Built-in, Pre-Configured Oracle Cloud Infrastructure Load Balancing : Pre-configured, redundant load-balancers are available on private and public subnets to balance traffic within the implementation and from external connections, respectively.
• Secure Access to Any Tier via the Bastion host : The bastion host is an optional component that can be used as a jump server to access Oracle Cloud Infrastructure instances in the private subnet. You can also access the instances in the private subnet by using dynamic SSH tunneling.
• On-Cloud Network Isolation via Virtual Cloud Network : A Virtual Cloud Network (VCN) is basically your own private network within Oracle Cloud Infrastructure. It provides isolation for your JD Edwards workload from any other workload on Oracle Cloud Infrastructure, including your other workloads in a different VCN. You can subdivide your VCN using subnets to ensure resource isolation and apply security rules to enforce secure access. You can also add route tables and rules to send traffic out of your VCN, similar to traditional network route rules.

  You can create instances in a private or a public subnet based on whether you want to permit access to the instances from the internet. Instances that you create in a public subnet are assigned a public IP address and you can access these instances from the public internet. Conversely, you cannot assign a public IP address to instances created in a private subnet therefore you can’t access these instances over the internet. You can, however, add a NAT gateway to your VCN to give instances in a private subnet the ability to initiate connections to the internet and receive responses for the purposes of applying OS and application updates. NAT gateways will not receive inbound connections initiated by the internet.

  We recommend creating separate subnets for each tier, such as bastion host, database, application, and load balancing, to ensure that appropriate security requirements can be implemented across the different tiers.
• Multiple Internal Firewalls : A security list provides a virtual firewall for each tier, with ingress and egress rules that specify the types of traffic allowed in and out.

Resiliency and High Availability

Oracle Cloud Infrastructure's resiliency and high availability architecture builds resiliency, redundancy, and high availability (HA) into the cloud infrastructure that is supporting JD Edwards EnterpriseOne and its backend datasets.

When running JD Edwards EnterpriseOne on Oracle Cloud Infrastructure, the resiliency and high availability architecture meets these objectives:

• Multiple active-active nodes at each application tier
• System resilience – using multiple fault domains
• Backup strategy for non-database tiers
• Redundancy strategy for database tier
• Backup strategy for database tier

The following figure illustrates the resiliency and high availability reference architecture for deploying JD Edwards EnterpriseOne in a single availability domain:

Description of the illustration single_availability_domain_jd_edwards_deployment_withcallouts-ha.png

• Active-Active Server Redundancy : To ensure high availability within an availability domain (AD), deploy redundant instances of every component making use of fault domains. All instances are active and they receive traffic from the load balancer and middle tier.
• System Resilience : Fault domains are a grouping of hardware and infrastructure that is distinct from other fault domains in the same AD. Each AD has three fault domains. By properly leveraging fault domains, you can increase the availability of applications running on Oracle Cloud Infrastructure.
• Database Redundancy : For performance and HA requirements, Oracle recommends that you use two-node, Oracle Real Application Clusters (Oracle RAC) database systems, or an Oracle Database Exadata Cloud Service system in Oracle Cloud Infrastructure.
• Backup Strategy Application Tier : Backup of the application tiers can be configured by using the policy-based backup feature of Oracle Cloud Infrastructure Block Volumes. Oracle Cloud Infrastructure Block Volumes provides you with the capability to perform volume backups automatically based on a schedule and retain them based on the selected backup policy.
• Backup Strategy Database Tier : Use of Oracle Cloud Infrastructure Object Storage to perform a backup by using Oracle Recovery Manager (RMAN). To back up or patch the database to Oracle Cloud Infrastructure Object Storage, the DB system's VCN must be configured with either a service gateway or an Internet gateway. It is recommended that you use a service gateway rather than an Internet gateway for backup and patching.

Disaster Recovery

Oracle Cloud provides JD Edwards EnterpriseOne implementations that ensure you can build disaster recovery (DR) into your deployment in unforeseen events that would require you to failover and still keep JD Edwards up and running.

• Disaster recovery within a single region:
  • Active-active components across ADs
  • Active-passive components across ADs
  • Regional subnets across ADs
  • Load-balancing across ADs
  • Storage synchronization across ADs
  • Database DR across ADs
• Disaster recovery across multiple regions:
  • Application replication between regions
  • Storage replication between regions
    • Cross-region copy lets you asynchronously copy Object Storage
    • Cross-region backup copy for Oracle Cloud Infrastructure block volumes
• Database protection between regions

Understand the Reference Architecture for Deploying JD Edwards in a Single Region

The following figure illustrates the reference architecture for deploying JD Edwards in a single region.
Description of the illustration multi_availability_domain_jd_edwards_domain_withcallouts.png

• Active-Active components across ADs : Clustering of supported services across ADs provides protection from an AD failure. For an Active-Passive architecture, synchronize application servers across availability domains using rsync.
• Regional subnets across ADs : Regional subnets span the entire region, providing resilience against AD network failure, and simplified JDE service deployment and management.
• Load-balancing across ADs : Oracle Cloud Infrastructure Public Load Balancing distributes traffic across JD Edwards servers across all configured ADs. Providing protection from an AD failure.
• Storage synchronization across ADs : Block Volume backups (boot and block) are replicated across all the ADs within a region, and can be restored to any AD within the same region. Object Storage is a regional service. Data is stored redundantly across multiple storage servers and across multiple ADs automatically.
• Database DR across ADs : Data Guard or Active Data Guard may be selected dependent on your use case and database edition. Active Data Guard requires Enterprise Edition – Extreme Performance.

Understand the Reference Architecture for Deploying JD Edwards in a Multiple Region

The following figure illustrates the reference architecture for deploying JD Edwards across multiple regions.
Description of the illustration multi_region_jd_edwards_domain.png

• Active-Active components across ADs : Clustering of supported services across ADs provides protection from an AD failure.
• Active-Passive Components Across Regions: If you are using Active-Passive to synchronize application servers across ADs, use rsync.
• Regional subnets across ADs : Regional subnets span the entire region, providing resilience against AD network failure, and simplified JDE service deployment and management.
• VCN Peering Across Regions: VCNs can connect between regions with in a tenancy or even between tenancies. Connectivity is achieved using Oracle’s internal backbone between regions.
• Storage synchronization across ADs: Block volume backups between regions can be done using the console, CLI, SDKs, or REST APIs. Copying block volume backups to another region at regular intervals makes it easier for to rebuild applications and data in the destination region if a region-wide disaster occurs in the source region. You can also easily migrate and expand applications to another region. With Object Storage cross region copy, data asynchronously copies objects between buckets in the same region or to buckets in other regions.
• Database DR across ADs: The use of either Data Guard or Active Data Guard depends on your use case and database edition. Active Data Guard requires Enterprise Edition – Extreme Performance.

Migration

When it comes to migrating a complex, highly customized and deeply integrated application like JD Edwards, it’s important to do it with as little rearchitecture as possible so that there’s limited downtime and the transition is seamless for end users.

Oracle Cloud Infrastructure migration and deployment architecture for JD Edwards meets the following objectives:

• Application-aware migration
• Migration application configuration
• Migration of data
• Conversion from non-Oracle databases
• Conversion from non-Linux servers
• Upgrade from older versions of EnterpriseOne

Application-aware migration tools help organizations move complex applications to Oracle Cloud Infrastructure. With the help of the tools users can reconfigure the applications after the migration is complete.

Oracle Cloud Infrastructure offers an application-aware migration tool for JD Edwards. During an application-aware migration, VMs and physical machines will never be captured or migrated. Only data and specific configuration files are captured and prepared for migration. The migration tool being used will deploy a new instance of the application in the Oracle environment, or use an existing instance of the application in the target environment.

Online Support

It's important to consider bandwidth and security when transporting data, VMs, and files over the wire. Organizations can migrate datasets over the public internet, or set up private connectivity between on-premises data centers and Oracle Cloud Infrastructure. Data should always be encrypted at rest and in transit.

• VPN over Internet- Relatively small datasets, up to approximately 2 terabytes (TBs) can typically be transported over the public internet without problems. Use a virtual private network (VPN) between the source environment and Oracle Cloud Infrastructure to ensure secure connectivity. Internet Protocol Security (IPsec) VPN is the best option in this case.

  The first step to setting up an IPsec VPN between the source environment and Oracle is establishing a dynamic routing gateway (DRG). The DRG should be set up to connect Oracle's cloud with any on-premises routers. Use multiple IPsec tunnels to ensure redundancy.

• FastConnect - Oracle FastConnect is another option for securely connecting on-premises data centers and networks to Oracle Cloud Infrastructure. It's the right choice for organizations that need to transport large datasets. Port speeds are available in 1 Gbps and 10-Gbps increments when working with a third-party connectivity provider, and 10 Gbps increments when co-locating with Oracle.

  FastConnect enables organizations to quickly scale up, scale down, and terminate connections as needed. For example, an organization may choose to set up a 1-Gbps connection to transport a single application with a small dataset during the testing phase, then quickly scale up to a 10-Gbps connection when deploying multiple applications with large datasets. Finally, the organization can quickly terminate the connection once the transfer is complete.

  Several Oracle partners offer solutions for setting up high-speed connections from on-premises data centers or other public clouds to Oracle Cloud Infrastructure.

• Storage Gateway - Once a secure connection has been established, organizations can use the Oracle Cloud Infrastructure Storage Gateway to securely create copies of on-premises files and place them into Oracle Object Storage without the need to modify applications.

Offline Support

For organizations with large, petabyte-scale datasets that are concerned about long upload times, Oracle recommends the Oracle Cloud Infrastructure Data Transfer Service. This service uses commodity hard disks or the Oracle Data Transfer Appliance to quickly and securely transport data to Oracle without going over the wire.

• Data Transfer Appliance - Each Data Transfer Appliance enables organizations to migrate up to 150 TBs of data. Appliances can be requested via the Oracle Cloud Infrastructure management console after creating a transfer job. The appliance should be configured and connected to the on-premises network. Migration teams also need to mount NFS volumes off the appliance and copy the data onto the appliance. After the data is copied, ship the appliance back to Oracle and monitor the status of the data transfer.
• Data Transfer Disk Oracle's Data Transfer Disk is another offline data transfer solution. Organizations send data as files on encrypted disks to an Oracle transfer site. Then site operators upload the files into the organization's designated object storage bucket. Users are free to move the uploaded data into other Oracle Cloud Infrastructure services as needed.

  After all the VMs, data, and files have been securely transported to Oracle Cloud Infrastructure, it's time to provision and deploy the target environment.

Security and Identity

The objective of the security architecture is to enable you to maintain your security posture when running your business-critical applications in Oracle Cloud. Even though you may be reducing the overhead of building and maintaining data center infrastructure, you still need unparalleled control and transparency over what you’re running in the cloud. With the identity access management architecture, you can group and isolate resources according to your organizational structure and hierarchy, control who has access to cloud resources, what type of access a group of users has, and to which specific resources.

Oracle Cloud Infrastructure's security architecture helps you meet these objectives:

• Ensure JD Edwards and associated data assets are isolated
• Protect internet-facing applications
• Data encryption
• Segregate operational responsibilities and restrict access to cloud services
• Use existing and third party security assets
• Audit and monitor actions
• Demonstrate compliance readiness

The following figure illustrates the security reference architecture provided for JD Edwards running on Oracle Cloud Infrastructure.
Description of the illustration single_availability_domain_jd_edwards_deployment_withcallouts-security.png

• Virtual private cloud : Provides isolation for JD Edwards from any other workload on Oracle Cloud. Subdivide using subnets and apply security rules to isolate and control access to resources.
• Internet Firewalls : A security list provides a virtual firewall for each tier, with ingress and egress rules that specify the types of traffic allowed in and out.
• Secure Load Balancing : TLS 1.2 is supported by default to securely balance traffic within the implementation and from external connections.
• Secure Connectivity to Internet : Internet bound traffic to/from a VCN must pass through an Internet Gateway. Virtual routing tables can be implemented with private IP addresses for use with NAT and 3rd party firewall devices.
• Secure Connectivity to Your Data Center : Traffic can be routed through a DRG for private traffic. It is used with an IPSec VPN or FastConnect connection to establish private connectivity to your premises or other cloud network.
• Protect Web Applications : Oracle provides a Web Application Firewall (WAF) service that inspects any request from the web application server to end user.

Cost Management and Governance

When transitioning from a capital expenditure (CapEx) model, where many costs are fixed at the implementation of a project, to an operating expenditure (OpEx) model, where costs scale up and down with the usage, often require cost management tools to understand and control these costs within your organization.

These tools can enable:

• Set and manage cloud budgets
• Prevent overspending
• Ensure accurate cost tracking across departments and projects
• Analyze which departments, services, and projects are contributing to cloud usage over time
• Get granular usage details for invoice reconciliation
• Identify areas to optimize costs

Oracle provides four cloud platform services to meet these needs:

• Compartments: Compartments can be used to ensure isolation of cloud resources between business units. In addition, they are also used to logically group resources for the purposes of measuring usage and billing. We typically recommend creating a compartment for each major part of your organization, that is, business unit or department. Compartments can also be nested to support sub-departments.
• Tagging: Leverage tags to track cost and usage of resources that are associated with a particular project that span multiple departments. In addition, you can streamline resource management by tagging and then scripting bulk actions on exactly the Oracle Cloud Infrastructure resources you want. Tags leverage policies and controls to ensure tagging integrity and to prevent users from creating excessive tags, duplicate tags, and manipulating existing tags.
• Budgets: Once resources are assigned to compartments that match your specific use cases, departments, or regions of operation, you can set budgets, view how spend is tracking against budgets, and configure alerts so that unexpected usage is flagged before a budget is actually exceeded.
• Cost Analysis: The billing cost analysis dashboard can help visualize the big buckets that are contributing to cloud usage and cost. You can analyze costs by cloud service, compartments, and tags. For example, an analyst or administrator can use this tool to identify the difference between increased production or dev/test usage, as well as the difference between increased usage of storage versus networking.
• Detailed Usage Reports: CSV files containing detailed resource-level and hour-by-hour data, including all associated metadata, that is, tags and compartments. Export detailed usage reports as CSV files and import into existing business intelligence tools for invoice reconciliation use cases, to get more granularity into your bill, and to identify areas for cost optimization. For example, you can leverage the detailed usage data and combine with CPU utilization data from the Oracle Cloud Infrastructure Monitoring service to identify instances with low CPU utilization to shut down.

Description of the illustration cost_management_compartments.png

Monitoring

You need to be able to monitor the health and capacity of cloud infrastructure resources in order to optimize JD Edwards performance at all times and in real time. Objectives include ensuring availability and performance of JD Edwards on the cloud and detecting and fixing anomalies before they can impact your business. Additionally, you may require the visibility to identify bottlenecks and under-utilized resources in order to optimize accordingly.

Infrastructure Monitoring

You might already be leveraging monitoring tools like Oracle Enterprise Manager and Oracle Management Cloud for your existing JD Edwards deployment. Oracle Cloud Infrastructure offers infrastructure monitoring natively within the console, but it can also support your existing monitoring tools. Depending on if you plan to migrate all JD Edwards applications and datasets into the Oracle Cloud or will maintain a hybrid cloud environment, Oracle recommends the following monitoring tools.

• Multi-Tier Monitoring of Hybrid/Multi-Cloud Environments: For most multi-tier migration scenarios, we recommend leveraging Oracle Management Cloud. Oracle Management Cloud provides integrated monitoring across hybrid and multi-cloud environments. It performs monitoring through use of agents across various tiers from infrastructure to application performance, security, and even end-user activity. And it integrates with Oracle Enterprise Manager for Oracle Database performance and capacity analytics.
• Oracle Cloud Infrastructure Monitoring: Cost-effective and out-of-the-box metrics and dashboards are provided for IT to monitor cloud resources such as compute instances, block volumes, virtual NICs, load balancers, and object storage buckets natively within the Oracle Cloud Infrastructure console. For example, you can leverage monitoring to track CPU utilization, memory utilization, and integrate with compute autoscaling. You can also integrate with open-source visualization tools, run your own metrics queries, and have your applications emit their own custom metrics, enabling you to visualize, monitor, and alarm on all critical time-series data from one place in the console.

Oracle Cloud Infrastructure performs agentless monitoring. Currently, this native infrastructure monitoring service does not monitor database services. It's recommended to use either Oracle Management Cloud or Oracle Enterprise Manager, depending on if Oracle Database is deployed on-premises or as a cloud service.