Many enterprises have multiple, often interdependent, Java applications running on a combination of different Java platforms, often with legacy versions of IBM WebSphere Application Server (WAS). Upgrading applications to current versions of WAS or to another application server requires significant up-front investment and lead times.
Migrate Java applications running on legacy versions of IBM WebSphere Application Server (WAS) to the cloud with little impact on the applications and even provision development environments to upgrade applications to newer versions of WAS.
The IBM WebSphere architecture insulates applications from the operating system and the bare metal servers in the lower part of the technology stack. Migrating WAS7 and Java6 from the P-Series servers under AIX operating system to a current version of RedHat Enterprise Linux or Oracle Linux running on x86 servers doesn’t affect the applications in a significant way. The migration of the enterprise applications to a different web application platform likely requires more up-front investment and a substantially longer lead times.
The IBM WebSphere architecture defines the deployment in terms of cells, profiles, nodes, and application servers. The software to create the base platform is packaged separately as a single archive file. When this distribution is mapped on an enterprise network, other components such as load balancers, DMZ proxies, and HTTP servers are used. These additional building blocks come as a part of the network deployment edition.
This architecture deploys IBM WebShere on Oracle Cloud Infrastructure.
The following options are the two primary IBM WebSphere platform configurations:
- Active and hot standby with two, single-node virtual machines (VMs), one active and one in hot standby mode.
- Multi-node, with multiple virtual machine cells.
In both cases, an Oracle database system serializes the transactions in the backend and ensures data persistence.
The first option is the easiest approach for preserving IBM WebSphere native capabilities. This simple deployment pattern supports both horizontal scale-out and vertical scale-up.
The following diagram illustrates this reference architecture.
The architecture has the following components:
An Oracle Cloud Infrastructure region is a localized geographic area that contains one or more data centers, called availability domains. Regions are independent of other regions, and vast distances can separate them (across countries or even continents).
- Availability domain
Availability domains are standalone, independent data centers within a region. The physical resources in each availability domain are isolated from the resources in the other availability domains, which provides fault tolerance. Availability domains don’t share infrastructure such as power or cooling, or the internal availability domain network. So, a failure at one availability domain is unlikely to affect the other availability domains in the region.
- Fault domain
A fault domain is a grouping of hardware and infrastructure within an availability domain. Each availability domain has three fault domains with independent power and hardware. When you distribute resources across multiple fault domains, your applications can tolerate physical server failure, system maintenance, and power failures inside a fault domain.
- Virtual cloud network (VCN) and subnet
A VCN is a customizable, software-defined network that you set up in an Oracle Cloud Infrastructure region. Like traditional data center networks, VCNs give you complete control over your network environment. A VCN can have multiple non-overlapping CIDR blocks that you can change after you create the VCN. You can segment a VCN into subnets, which can be scoped to a region or to an availability domain. Each subnet consists of a contiguous range of addresses that don't overlap with the other subnets in the VCN. You can change the size of a subnet after creation. A subnet can be public or private.
- Load balancer
The Oracle Cloud Infrastructure Load Balancing service provides automated traffic distribution from a single entry point to multiple servers in the back end.
- Security list
For each subnet, you can create security rules that specify the source, destination, and type of traffic that must be allowed in and out of the subnet.
- Route table
Virtual route tables contain rules to route traffic from subnets to destinations outside a VCN, typically through gateways.
- Internet gateway
The internet gateway allows traffic between the public subnets in a VCN and the public internet.
- NAT gateway
The NAT gateway enables private resources in a VCN to access hosts on the internet, without exposing those resources to incoming internet connections.
- VPN Connect
VPN Connect provides site-to-site IPSec VPN connectivity between your on-premises network and VCNs in Oracle Cloud Infrastructure. The IPSec protocol suite encrypts IP traffic before the packets are transferred from the source to the destination and decrypts the traffic when it arrives.
- Dynamic routing gateway (DRG)
The DRG is a virtual router that provides a path for private network traffic between a VCN and a network outside the region, such as a VCN in another Oracle Cloud Infrastructure region, an on-premises network, or a network in another cloud provider.
- Service gateway
The service gateway provides access from a VCN to other services, such as Oracle Cloud Infrastructure Object Storage. The traffic from the VCN to the Oracle service travels over the Oracle network fabric and never traverses the internet.
Oracle Cloud Infrastructure FastConnect provides an easy way to create a dedicated, private connection between your data center and Oracle Cloud Infrastructure. FastConnect provides higher-bandwidth options and a more reliable networking experience when compared with internet-based connections.
- Bastion host
The bastion host is a compute instance that serves as a secure, controlled entry point to the topology from outside the cloud. The bastion host is provisioned typically in a demilitarized zone (DMZ). It enables you to protect sensitive resources by placing them in private networks that can't be accessed directly from outside the cloud. The topology has a single, known entry point that you can monitor and audit regularly. So, you can avoid exposing the more sensitive components of the topology without compromising access to them.
- Database system
The database system offers autonomous and co-managed Oracle database systems. Autonomous databases are pre-configured, fully managed environments that are suitable for either transaction processing or for data warehouse workloads. Co-managed database systems are bare metal, VM-based deployment, and Exadata database systems that you can customize with the resources and settings that meet your needs. You can deploy fault-tolerant Oracle RAC on the VMs and provision them on the Exadata bare metal servers.
Use the following recommendations as a starting point to deploy IBM WebShere on Oracle Cloud Infrastructure.
When you create a VCN, determine the number of CIDR blocks required and the size of each block based on the number of resources that you plan to attach to subnets in the VCN. Use CIDR blocks that are within the standard private IP address space.
Select CIDR blocks that don't overlap with any other network (in Oracle Cloud Infrastructure, your on-premises data center, or another cloud provider) to which you intend to set up private connections.
After you create a VCN, you can change, add, and remove its CIDR blocks.
When you design the subnets, consider your traffic flow and security requirements. Attach all the resources within a specific tier or role to the same subnet, which can serve as a security boundary.
- Security lists
Use security lists to define ingress and egress rules that apply to the entire subnet.
- Load balancer
Depending on the WAS platform deployment choice, active-standby or multinode, configure the respective load balancer to a fail-over or round-robin distribution.
IBM WebSphere uses an Oracle database as a data source that is configured after IBM WebSphere is installed.
- Capacity planning and performance
The VMs in the Oracle Cloud Infrastructure come in various shapes with explicitly specified virtual CPU, IOPS, and RAM.
For example, the VM.Standard2.X compute instance shapes covers a wide range of CPU resources, RAM, and I/O speeds. Scaling the shape up or down takes a matter of minutes. IBM P-Series servers including a 4-core IBM P770, a 3-core IBM E880, a 6-core S922, a 20-core E980, or a 27-core E880 are in the range of the VM.Standard2.X lineup. In rare situations when an enterprise application requires even more powerful configurations, bare metal servers deliver configurations of up to 128 OCPU and 2048 GB of RAM. If the results of performance testing indicate that the VM is overloaded, you can upgrade to a more powerful VM shape in a few minutes.
- IBM WebSphere installation
Although you can install a GUI on the target VM and then install IBM WebSphere for an interactive installation, you can also use the included silent install parameter files as a starting point for automation using DevOps tools, such as Ansible. We recommend using the silent install and DevOps automation tools.
WAS 7 installation is available for registered partners and existing customers. It comes as a tar.gz file and includes the IBM installer and a file that defines (but does not activate) all the parameters that are required for the silent install.
To install WAS9, download and install the IBM Installation Manager and use it to deploy IBM WebSphere in Oracle Cloud Infrastructure.
IBM makes a rich set of sample applications available. We recommend adding them during the WAS installation. One such application is Plants by IBM WebSphere storefront. Its customers can open accounts, browse for items to purchase, view product details, and place orders. Plants by IBM WebSphere uses container-managed persistence (CMP), container-managed relationships (CMR), stateless session beans, a stateful session bean, JSP pages, and servlets.
IBM Java 6 comes with the WAS7 distribution. We recommend using IBM-provided Java JRE.
- Operating system for IBM WebSphere platform
Oracle Linux 64-bit 7.8 is the base OS for the IBM WebSphere Application Server (WAS) installation.
- Privileged access over SSH tunnel
The systems and web platform administrators require a separate secure access to the deployed solution. You can set it up using virtual machine console capability of Oracle Cloud Infrastructure. If you want X11 access, you can provision it through SSH tunneling and port forwarding. This optional part of the solution was implemented based on the use of the GNOME Display Manager (GDM) with a listener that can support multiple sessions. The SSH tunnel is maintained through the bastion server.
When deploying IBM Websphere on Oracle Cloud Infrastructure, consider the following:
The load balancers, instances, and databases systems in this architecture can be scaled up and down. Depending on the IBM WebSphere platform deployment you choose, you can expand it horizontally by adding instances.
Access is tightened by strict security lists and privileged access is granted only through the bastion host.
IBM WebSphere 7 documentation for Linux deployment suggests disabling SELinux before installation. It doesn’t suggest reenabling it after the installation. IBM WebSphere 9 may have resolved this issue. The security impact of that process is not within the scope of this reference architecture and should be addressed with the vendor.
- Reduced risk deployment of WAS 7, 8, and 9
In Oracle Cloud Infrastructure, you can quickly and reliably create various IBM WebSphere deployment footprints using the Oracle Linux (OL) or Red Hat Enterprise Linux (RHEL) images, load-balancer-as-a-service, and a range of Oracle database solutions. You can deploy the environments based on OL7.8 in Oracle Cloud Infrastructure to support IBM WebSphere installations dating back to the WAS 22.214.171.124 and Java 6. You need multiple development, test, quality assurance, and production environments and can easily deploy upgrades of the WAS 7 and WAS 8 applications to WAS 9.X. The approach in this reference architecture helps to expedite the provisioning of numerous non-production and production environments required for the IBM-recommended software development life cycle (SDLC).
IBM WebSphere uses an Oracle database as a data source that is configured after IBM WebSphere is installed. You can access the database using Oracle JDBC. The version you select must match the Java environment used for IBM WebSphere. For example, WAS 126.96.36.199 with Java 6 requires the OJDBC6 driver.
Version compatibility of the OJDBC driver limits the use of the newer versions of Oracle with older versions of IBM WebSphere.
The architecture as presented is distributed across multiple fault domains. In regions with multiple availability domains, the architecture can take advantage of those domains for increased availability.
The pre-built OL7.8 VMs are IBM WebSphere-ready but don’t contain any licensed IBM software. You can procure the necessary license from many resellers or directly from IBM.
The Terraform code for this reference architecture is available on GitHub.
- Go to GitHub.
- Follow the instructions in the
Learn more about the features of this architecture and about related resources.