Skip to Main Content

Hardware

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.

Migrating Oracle WebLogic Server to a SPARC Environment: Part 1

steph-choyer-OracleOct 26 2016 — edited Nov 5 2016

by David Saes and Michelle Szucs

Part 1 of a multipart series about migrating Oracle WebLogic Server environments to Oracle's SPARC servers

Introduction

Oracle software runs on a wide variety of hardware platforms, including many non-Oracle stacks. However, Oracle's full-stack engineering has resulted in an ever-widening gap between the benefits of running a full Oracle stack and the difficulty of optimizing a mismatched stack. Collaboration among Oracle's application, middleware, database, operating system, server, storage, and networking teams has led to innovations in security, performance, simplicity, and cloud-readiness for Oracle solutions.

Using Oracle's SPARC systems has particular benefits for Oracle WebLogic Server applications. End-to-end security can be achieved without degradations in system performance; SPARC T7-1 servers demonstrate only a 3 percent performance difference between encrypted and unencrypted workloads, and SPARC S7-2 servers demonstrate only a 2 percent performance difference. SPARC systems are optimized for Java and database performance—crucial to Oracle WebLogic Server performance—with SPARC S7-2 servers demonstrating 31 percent better SPECjEnterprise2010 EjOPS/core performance than the IBM x3650 server. Additionally, Oracle's Software in Silicon features, such as Silicon Secured Memory and Data Analytic Accelerator (DAX) units, can be leveraged to protect against software bugs and deliver streamlined processing for certain workloads. For more information about the benefits of running Oracle WebLogic Server in a SPARC environment, explore Oracle Optimized Solution for Secure Oracle WebLogic Server.

This article steps through a simple lift-and-shift Oracle WebLogic Server 12.2.1 migration from an x86 machine running Linux to a SPARC machine running Oracle Solaris.

Source and Target Architectures

Figure 1 illustrates the overarching architecture used for the lift-and-shift migration process. Users access Oracle WebLogic Server, which is configured with the Oracle WebLogic Cluster feature, via a load balancer. Any load balancer can be used, including Oracle Traffic Director (which comes with some of the options available for Oracle WebLogic Server, Enterprise Edition), Apache HTTP Server, Oracle HTTP Server, or F5 Big-IP. The application(s) running on x86 Linux machines in the source architecture will be moved to new SPARC servers running Oracle Solaris in the target architecture.

f1.png

Figure 1. Source and target architectures

Validating the Target Environment

Before starting a migration process, consult with official Oracle documentation, services, or partners to ensure the target environment is a valid, supported configuration. Consult the "Oracle Fusion Middleware System Requirements and Specifications" documentation to validate the environment specifications, including hardware configurations and database installations. Consult the Oracle Fusion Middleware Supported System Configurations web page for detailed versioning information including system architecture, Java Virtual Machine versions, Oracle WebLogic Server versions, and requirements for specific applications and features.

Virtualization of the source and target architecture should not impact the migration process. For instance, existing virtual machines can be migrated into Oracle VM Server for SPARC (also called Logical Domains or LDoms), Oracle Solaris Zones, or Oracle Solaris Kernel Zones without changes to the process. Therefore, this article details only the steps of the Oracle WebLogic Server migration, allowing flexibility for any virutalization requirements.

Demonstration Environment Configuration

The configuration of the demonstration environment we used for this article is depicted in Figure 2. One x86 server running Linux was configured with the host name weblogic-linux. One SPARC server running Oracle Solaris was configured with the host name weblogic-solaris. The name of the Oracle WebLogic Server administration domain was wls_domain. This domain contained an administration server called AdminServer and a cluster called cluster1. cluster1 contained one managed server called wls_server1, in which a simple servlet application called HelloWorld was deployed.

f2.png

Figure 2. Configuration of the demonstration environment

The directory that stores all Oracle Fusion Middleware products (the Middleware home), holds the Oracle WebLogic Server 12.2.1 files. In this article, Middleware home is referred to as MW_HOME. In the demonstration environment used in this article, this directory is /u01/oracle/fmw1221 on both the Oracle Solaris machine and the Linux machine.

In this article, the domain directory (the Domain home) is referred to as DOMAIN_HOME. In the demonstration environment, this directory is /u01/oracle/domains/wls_domain.

Migration Process

Obtain the Domain Template

Consider a working Oracle WebLogic Server environment (such as that displayed in Figure 2) in which Oracle WebLogic Server 12.2.1 is already installed, the domain is configured, and at least one application is deployed. If you connect to the load balancer, you should see the application, such as the simple HelloWorld application shown in Figure 3, running.

f3.png

Figure 3. Application running in Linux environment

Complete the following steps to obtain the domain template:

1. To export the domain from the server running Linux, first connect to the weblogic-linux server.

2. Navigate to the directory MW_HOME/oracle_common/common/bin.

3. Execute the config_builder.sh script, which should produce the screen displayed in Figure 4.

f4.png

Figure 4. Template Type screen

4. Select Create Domain Template and Use Domain as a Source.

5. In the Source Location field, ensure DOMAIN_HOME directory is selected.

6. In the Template Location field, enter the path and filename of the JAR file that will be created to store the domain configuration.

7. Provide a name or description to the template, if desired.

8. The last screen of the template creation process is shown in Figure 5. This view allows you to review the managed servers, clusters, and applications that are being included in the template. After reviewing the contents of the template, click Create.

f5.png

Figure 5. Template Summary screen

9. After the process finishes, click Next, and then click Finish on the final summary screen to exit the template builder tool.

Copy the Domain Template to the SPARC Server

Transfer the domain template JAR file that was created from the Linux server to the SPARC server that is running Oracle Solaris. The following command shows using scp from the weblogic-linux session to perform the transfer:

$ scp /u01/oracle/domains/templates/template.jar oracle@weblogic-solaris:/tmp

Password:

template.jar 100% 68KB 68.4KB/s 00:00

Import the Domain Template into the Oracle Solaris Environment

1. Ensure that Oracle WebLogic Server 12.2.1 is installed with the same patches on the SPARC machine as on the Linux machine. If possible, use the same path for MW_HOME and the same Java version. Detailed Oracle WebLogic Server installation instructions can be found here. Do not run the Configuration Wizard after installing Oracle WebLogic Server.

2. Log in to weblogic-solaris.

3. Navigate to MW_HOME/oracle_common/common/bin.

4. Execute the config.sh script, which should produce the screen shown in Figure 6.

f6.png

Figure 6. Configuration Type screen

5. Select Create a new domain.

6. In the Domain Location field, enter the path to where you would like the domain installed. If possible, use the same path as was used on the Linux installation.

7. On page 2 of the wizard (shown in Figure 7), select Create Domain Using Custom Template, and then in the Template location field, select the location of the JAR file copied over from the Linux machine.

f7.png

Figure 7. Templates screen

8. On page 3 of the wizard (shown in Figure 8), in the Application location field, select the DOMAIN_HOME directory.

f8.png

Figure 8. Application Location screen

9. On page 4 of the wizard (shown in Figure 9), enter the domain credentials for the administrator account.

f9.png

Figure 9. Administrator Account screen

10. On page 5 of the wizard (shown in Figure 10), select either Development or Production for the domain mode, depending on what is appropriate for the application you are migrating. The correct JDK path should already be selected if you maintained the same JDK version as was used in the Linux environment.

f10.png

Figure 10. Domain Mode and JDK screen

11. On page 6 of the wizard (the Advanced Configuration screen), we selected the checkboxes for all the options. Selecting these options ensures that any values that default to the old Linux environment can be updated to reflect the new Oracle Solaris environment.

12. On page 7 of the wizard, configure the administration server; the demonstration configuration we used is shown in Figure 11. Ensure that the Listen Port field points to the desired port on the new Oracle Solaris environment, not to the old Linux environment.

Note: In this simple demonstration environment, we did not enable SSL for either the source or target environment; carefully consider the security ramifications before reaching a final decision regarding the use of SSL.

f11.png

Figure 11. Administration Server screen

13. On page 8 of the wizard, configure the node manager. The configuration we used is shown in Figure 12. We used the default location for the node manager. Ensure that the node manager is configured the same way on the Oracle Solaris machine as it was on the Linux machine.

f12.png

Figure 12. Node Manager screen

14. On page 8 of the wizard (shown in Figure 13), configure the managed server. As when configuring the administration server, ensure the port is set appropriately for the Oracle Solaris environment instead of defaulting to the Linux configuration. Again, we did not use SSL in this simplified demonstration environment, but your environment will likely have different security requirements.

f13.png

Figure 13. Manager Servers screen

15. Configure the cluster properties, as shown in Figure 14, ensuring the Cluster Address field is set correctly for the Oracle Solaris environment.

f14.png

Figure 14. Clusters screen

16. Assign servers to the appropriate clusters, as shown in Figure 15.

f15.png

Figure 15. Assign Servers to Clusters screen

17. The machine configuration is shown in Figure 16. Configure the Name and Node Manager Listen Address fields for the local Oracle Solaris machine, not for the settings of the Linux server.

f16.png

Figure 16. Machines screen

18. Ensure the assignment of servers to machines is correct, as displayed in Figure 17.

f17.png

Figure 17. Assign Servers to Machines screen

19. The configuration we used did not require virtual targets or partitions, so we clicked Next without making changes on the Virtual Targets or the Partitions screens.

20. On the Deployments Targeting screen shown in Figure 18, ensure that the targets are correctly configured.

f18.png

Figure 18. Deployments Targeting screen

21. Review the Configuration Summary screen shown in Figure 19. When you are satisfied that the environment is configured correctly, click Create. After the creation process completes, click Next and then Finish to exit the wizard.

f19.png

Figure 19. Configuration Summary screen

Configure the Load Balancer

After the domain has been created on the Oracle Solaris machine, start the administration server, node manager, and managed server as you usually did on the Linux machine, via scripts or the Oracle WebLogic Server Administration Console.

Configure your load balancer to point to the Oracle Solaris installation, and try to access the application. The result should be the same as was previously seen in the Linux installation; Figure 20 shows the simple HelloWorld servlet successfully running in Oracle Solaris.

f20.png

Figure 20. Application running in Oracle Solaris environment

Conclusion

This simple lift-and-shift migration strategy quickly and easily moves applications from x86 Linux environments to environments using SPARC servers that run Oracle Solaris. Moving to a new environment allows applications to take advantage of new features in Oracle Fusion Middleware, Oracle Solaris, and Oracle's SPARC servers. Software in Silicon technology on the SPARC microprocessor offers extreme performance and outstanding end-to-end security, making Oracle's SPARC servers running Oracle Solaris the best environment for Oracle WebLogic Server.

About the Authors

David Saes is a solution architect in the Systems division of Oracle. He specializes in Oracle's middleware products, and has served as a middleware consultant for more than seven years.

Michelle Szucs is a product manager on the Oracle Optimized Solutions team in the Systems division of Oracle. She is the solution manager for Oracle Optimized Solution for Secure Oracle WebLogic Server.

Follow us:
Blog | Facebook | Twitter | YouTube

Comments

Great article and project! I have a simple question. When you say:

Non-blocking request processing emerges as an effective way to address the problem. Instead of one blocking thread to handle one request, a small number of threads is used to handle a large number of requests asynchronously. This results in more efficient use of CPUs and better scalability, albeit at the cost of increased complexity.

Would you say then that we should not use server-side non-blocking processing if performance is not an issue? For the applications I work on, load is very predictable and low. It seems to me that in these cases the increased complexity is not worth it. (I contrast this to AJAX. AJAX enables web applications to do more work faster and responsively, but even if your web application has very little work to do, the user experience of AJAX applications is often superior to applications that do not use AJAX due to full page refreshes.)

Antón R. Yuste

Superb article, thanks!

user11017489

Thank you for this beautiful summary.

Re Lai-Oracle

Great article and project! I have a simple question. When you say:

Non-blocking request processing emerges as an effective way to address the problem. Instead of one blocking thread to handle one request, a small number of threads is used to handle a large number of requests asynchronously. This results in more efficient use of CPUs and better scalability, albeit at the cost of increased complexity.

Would you say then that we should not use server-side non-blocking processing if performance is not an issue? For the applications I work on, load is very predictable and low. It seems to me that in these cases the increased complexity is not worth it. (I contrast this to AJAX. AJAX enables web applications to do more work faster and responsively, but even if your web application has very little work to do, the user experience of AJAX applications is often superior to applications that do not use AJAX due to full page refreshes.)

Thank you. And yes, I'd think so. Asynchronous programming is harder to reason about.

lprimak

There is more hype in asynchronous / non-blocking programing than is proven by benchmarks or common sense:

Mohan Basavarajappa

Hi @"Yolande Poirier-Oracle"

informative article contributed. provides information on what all NIO frameworks are available and what is the high-level difference. More over it provides the advancements and where platform is headed. Nice samples too to get kick started with learning.

We are in the process of fixing the code layout. Sorry for the convenience.

Redfred Garett

Excellent article. Really very useful. Thanks !!!

1 - 8

Post Details

Added on Oct 26 2016
0 comments
3,674 views