Architecture Matters, Part 1: Assessing Application Migration Impact

Версия 5

    by Randal Sagrillo and Larry McIntosh

     

    This article discusses four simple steps customers can take to migrate from IBM's AIX to Oracle Solaris quickly and efficiently.

    Introduction

     

    Oracle applications, middleware, and database software technologies operate on a wide variety of non-Oracle hardware platforms. But it is Oracle's comprehensive applications-to-disk coengineering, end-to-end testing, and documented best practices for running Oracle software on Oracle hardware that help enterprise customers meet greater demands for advanced data security, higher efficiency, and greater performance.

    OOS_Logo_small125.png
    Oracle Optimized Solutions provide tested and proven best practices for how to run software products on Oracle systems. Learn more.

     

    While migrating critical business systems to a new platform can be disruptive for always-on applications, this article, which is Part 1 of a four-part "Architecture Matters" series, discusses four simple steps customers can take to migrate from IBM's AIX to Oracle Solaris quickly and efficiently. Part 2 of this series works through an example of migrating an Oracle Database instance from AIX to Oracle Solaris detailing the steps, effort, duration, and benefits.

     

    All the articles in this "Architecture Matters" series are located here:

     

     

    Overview of Migration Planning

     

    Like any complex IT project, a successful platform migration requires quality planning beforehand. Breaking a migration of business systems from AIX to Oracle Solaris into its key steps can demonstrate that the effort, its risk, and its complexity depend more on the infrastructure of the current system than on the target configuration. So, a successful migration plan needs to start with a comprehensive scoping of the current IT infrastructure to determine what to migrate and where to test. Additionally, setting concrete objectives for each step in the migration process will help make the right planning trade-offs. The simplified planning flow has four main steps, as shown in Figure 1.

     

    f1.png

    Figure 1. Simplified migration—four high-level steps.

     

    Each of these steps is covered in more detail later in this article. But the first decisions to be made is whether to do the planning and migration in-house or use the professional consulting services offered by Oracle, such as Oracle Migration Factory.

     

     

    Step 1: Determining Architectural Readiness

     

    Recognizing that the shared services and common frameworks in use can affect migration effort, duration, and difficulty, the first step is to compare the nature of the system that is being migrated to the new platform. Customers could discover, for example, that their high availability (HA), disaster recovery (DR), storage management, and systems management frameworks and architectures are platform-independent, presenting low impact—or not. Examples of the range of impact are shown in Figure 2.

     

    f2.png

    Figure 2: Assessing impact.

     

    If Oracle Maximum Availability Architecture is currently deployed, the nature of the current system could have nearly a nonexistent impact on the migration effort, because Oracle Maximum Availability Architecture is highly integrated with Oracle software technology and inherently platform-independent.

     

    On the other hand, migration could require updates to some or all of the system technologies and frameworks, which itself could become a major effort requiring its own plan. However, in this case customers will be gaining additional benefits from these updates beyond just migration.

     

    Typically, an enterprise uses third-party products that are well supported on both AIX and Oracle Solaris 11. These third-party products can have an impact on the migration effort and customers need to work with the vendors to determine any dependency, integration, and testing issues that might arise.

     

    Learn more about Oracle's architectures and best practices for backup and disaster recovery.

     

    Step 2: Mapping Operational and Administrative Tasks

     

    This second step prepares for the migration itself. And while it is one of the most pervasive—affecting not only operations but also involving the training of administrative staff—it is also one of the most mechanical, straightforward, and simple steps. There are four reasons why mapping AIX to Oracle Solaris is straightforward:

     

    • Both are RISC UNIX
    • Both are System V–based
    • Both are 64-bit operating systems
    • Both are big-endian operating systems

     

    The common heritage of both AIX and Oracle Solaris ensures that AIX- or Linux-familiar IT staff will find Oracle Solaris easy to learn. Experience has shown that Oracle Solaris is the preferred platform for system management and administration due to the innovations that have made Oracle Solaris the most advanced of various UNIX technologies.

     

    Training Resources

     

    As with any platform change, technical staff will need to become familiar with the following:

     

    • Oracle Solaris distribution, installation, and management
    • Oracle Solaris data management
    • Oracle Solaris virtualization (for example, LPARs to LDoms or Oracle Solaris Zones), availability, and security tools

     

    A good place to start is at the Oracle Learning Library, viewing an excellent 30-minute introduction to the fundamentals of migrating to Oracle Solaris from AIX.

     

    Next, review the "IBM AIX to Oracle Solaris Technology Mapping Guide."

     

    Finally, training and certification from Oracle University covers all aspects of using Oracle Solaris 11.

     

    Step 3: Considering Application Support

     

    The third step involves assessing the business-critical software applications to be migrated. Migrating applications from AIX to Oracle Solaris depends on whether the applications are from Oracle, by third-party vendors, or are home grown, proprietary, and unique to the enterprise. It is worth noting that many times, only the database portion of the application might be on AIX, in which case, only the database needs to be migrated to Oracle Solaris.

     

    All Oracle applications running on AIX are supported on Oracle Solaris. For example, Oracle's global single-instance ERP system runs equally on Oracle Solaris with Oracle's SPARC servers as on IBM AIX.

     

    For third-party applications running on AIX, check the list of applications certified for Oracle Solaris 11.

     

    Oracle has one of the largest independent software vendor (ISV) communities, so many third-party applications could already be certified to run on Oracle Solaris 11.

     

    Finally, if in the past, applications have run on Oracle Solaris, the Oracle Solaris Binary Application Guarantee reflects Oracle's confidence in the compatibility of applications from one release of Oracle Solaris to the next and is designed to make requalification a thing of the past.

     

    If a binary application runs on a release of Oracle Solaris 2.6 or later, including the initial release and all updates, it will run on the latest releases of Oracle Solaris, including their initial releases and all updates, even if the application has not been recompiled for those latest releases. Binary compatibility between releases of Oracle Solaris helps protect customers' long-term investments in the development, training, and maintenance of their applications.

     

    Step 4: Replatforming the Database

     

    The fourth step concerns the enterprise's business-critical data. Great care must be given to this critical task, for which Oracle provides a variety of tools and utilities that migrate Oracle Database between heterogeneous platforms. These tools give customers various choices over how this is done, depending on the size and complexity of the databases being migrated, along with other business requirements such as migration time and restore point objectives for each database. The tools to use will depend on their strengths and limitations for specific data types, time limitations, and potential costs, as shown in Figure 3.

     

    f3.png

    Figure 3. Replatforming options.

     

    Database Migration Methods

     

    Database migration can proceed as part of an Oracle version upgrade, for example, Oracle Database 10g Release 2 to Oracle Database 12c. Similarly, database migration can proceed within the same Oracle version, for example, Oracle Database 11g Release 2 to Oracle Database 11g Release 2. Oracle assumes most migrations will separate database version upgrades from database migrations.

     

    There is no migration utility script or database upgrade assistant to perform a cross-platform migration of Oracle Database. Instead, Oracle provides the following methods for rebuilding the database on the new platform or for moving the data:

     

    • Exporting and importing with Oracle Data Pump. All Oracle Database versions support export and import, but to use Oracle Data Pump Oracle Database 10.1.0.2 or higher is required on AIX. Oracle Data Pump provides fast data and metadata movement between instances of Oracle Database. Administrators can move specific tables or an entire database or set of databases. An example using Oracle Data Pump for migrating between heterogeneous operating systems is detailed in the next article in this series, "Architecture Matters, Part 2: Navigating Database Replatforming—An Example."
    • Using transportable tablespaces. Oracle Database 10g and later versions support the Transportable Tablespaces feature of Oracle Database, which can be used to copy a set of tablespaces from one Oracle Database instance to another.
    • Using Oracle Recovery Manager (Oracle RMAN) to convert database functions. Oracle RMAN can be used with Oracle Database 10g or later to transport tablespaces and entire databases between disparate platforms. Note that the Oracle RMAN "Convert Database" function can be used because AIX and Oracle Solaris are both big-endian operating systems.
    • Replicating Oracle Streams. Replication is the process of sharing database objects and data among multiple databases, and it works well for moving relational data between heterogeneous databases.
    • Using the Create Table As Select (CTAS) statement. Using SQL statements such as Create Table As Select can facilitate the migrations of simpler databases in much the same ways as database administrators use Extract, Transform, and Load (ETL) functions on a daily basis.
    • Using Oracle Active Data Guard for heterogeneous primary and physical standbys. Oracle Active Data Guard can be used to facilitate migration from one platform to another with minimal downtime or risk. If Oracle Active Data Guard is already part of disaster recovery, using it is a good way to support heterogeneous data replication for migration.
    • Using Oracle GoldenGate. Oracle GoldenGate is a comprehensive software package for real-time data integration and replication in heterogeneous IT environments. Assistance with Oracle GoldenGate is available from an Oracle representative. Many times, this is an opportunity to use Oracle Migration Factory to design and deploy a workable real-time migration capability.

     

    Conclusion

     

    Migrating legacy business-critical applications to a new platform is a complex task. But with the proper comprehensive analysis and planning, a successful migration can be done and the overall benefits can be realized immediately. Moreover, the complexity of a migration to Oracle systems and Oracle Solaris is significantly reduced when the current deployment already employs Oracle storage management as well as high availability and disaster recover best practices. Finally, by using the training resources from Oracle University and Oracle Optimized Solutions end-state architectures, an enterprise will have all the tools needed to complete the migration in house or with the assistance of migration experts from Oracle Migration Factory.

     

    To find out more about how to begin migration now and receive the benefits of Oracle hardware and software engineered to work together, see oracle.com/aixtosolaris.

     

    About the Authors

     

    Randal Sagrillo is a solutions architect for Oracle. He has over 35 years of IT experience and is an expert in storage and systems performance, most recently applying this expertise to next-generation data center architectures, integrated systems, and Oracle engineered systems. Randal is also a frequent and well-attended speaker on database platform performance analysis and tuning and has spoken at several industry conferences including Oracle OpenWorld, Collaborate, Computer Measurements Group, and Storage Networking World. In his current role, he is responsible for solution architecture and development around Oracle Optimized Solutions. Before joining Oracle, Randal held a variety of leadership roles in product management, program management, and hardware/software product development engineering.

     

    Lawrence McIntosh is the chief architect within the Oracle Optimized Solutions team. He has designed and implemented highly optimized computing, networking, and storage technologies for both Sun Microsystems and Oracle. Lawrence has over 40 years of experience in the computer, network, and storage industries and has been a software developer and consultant in the commercial, government, education, and research sectors and an information systems professor. He has directly contributed to the product development phases of Oracle Exadata Database Machine and various Oracle Optimized Solution architectures. His most recent contribution has been in the design, development, testing, and deployment of Oracle Optimized Solution for Secure Oracle Database.

     

     

    Revision 1.0, 10/19/2015

     

    Follow us:
    Blog | Facebook | Twitter | YouTube