RISC to IA migration – Rising to the Proof of Concept

Running a Proof of Concept (PoC) may seem like a slam dunk.  You know your application, you know your users and it should be easy to test the application out on new hardware.   All I need to do is copy it to the new hardware and we’re set to go.  But there have been many failures of PoC’s when this has been the extent of the high level planning.

How do we avoid PoC failure?  How do we get it done without analysis paralysis?

Many RISC to IA methodologies have elaborate analysis tasks prior to starting the PoC.  This is also often a path to failure as the analysis becomes the focus rather than the opportunity to reduce costs by migrating an application from an expensive RISC server to a commodity IA based server.  All that analysis takes the excitement and fun out of the process.  People get bored without results and interest turns elsewhere.   This is especially true today when business conditions demand immediate response to changing conditions.

But we don’t want to jump right into the PoC either.    So let’s look for the middle path, somewhere between the analysis paralysis and the unexamined response to management directives.  This middle path includes a measure of planning and a careful execution methodology that assumes that ‘there is more here than meets the eye’.   For instance, I haven’t done a PoC that didn’t uncover something new about the application.  This ‘something new’ is an aspect of the application that the staff supporting the application either didn’t know about or didn’t think was important.

Here’s my offering for a middle path.  For a database application migration the following steps (at 10,000 feet) should be taken.

  • Document the critical characteristics of the application.
    • Storage requirements
    • CPU requirements
    • Memory requirements
    • Network requirements
    • SLA requirements
      • These are the performance targets that you have to meet.
  • External application linkages
  • Identify the data source(s) for the application that you’ll use
    • Could be database back up
    • Source code for custom aspects to the application
    • Download and stage the IA port for the application (if applicable)
  • Size and acquire the target hardware and configure it in the lab
    • Connect it to the dev-test or lab subnet
    • Tune the operating system for the application
  • Size and acquire the appropriate storage for the application
    • Sometimes this can be high capacity SSD’s in a PCIe slot or a SAN/NAS array of hard disks.
  • In parallel select the PoC team from the team that supports the application and get them a break from their ‘day jobs’.

    • This is critical.  The staff needs to have skin in the game.  Without the staff commitment you won’t get answers to your questions.
  • Identify your regression test harness.
    • Be sure you have the ancillary hardware to run the test harness at the levels required.  (You need servers to simulate users for the test harness)

Now you’re ready to set up the application on the server.

Set up the IA port of the application on your new server.  If you’re moving a database you’ll want to set it up first and test it running on the target server.   The first step after setting up the application server is to back it up.  (It’ll be easier to restore this configuration after each test than to re-install it.)

Once you’ve completed the back-up begin the installation of the application from the designated source server.  This can be an active QA or UAT server or a back-up of the application.  With an Oracle database this can be done using RMAN restore, Data Pump import, or Oracle Streams.   With Sybase, you can use Replication Server.

For Oracle Data Pump or Export Import the following graphically presents the process:

Migration Methodologies Data Pump.jpg

For the Oracle Streams process the following demonstrates the configuration graphically:

Migration Methodologies - Oracle Streams.jpg

Regardless of the tool you are using you want to determine which tool is least likely to cause errors and move the data over within the maintenance window for the production application.  The PoC is your chance to determine the best methodology for the data transfer.   (Again, the data has to be transferred as character data across the wire as the endian configuration has to be corrected.  RISC processors read the data in ‘big endian’ format and IA processors read the data in ‘little endian’ format and this has to be converted.  Currently it can only be converted when represented as character data.)

Now that you have restored the application it needs to be hooked up with the web servers for the testing and the data feeds if necessary.  Again, back-up at this point or use flashback to create a restore point.

After the restore point is set, fire up the test harness and see what happens.  Also try to get some users to run their functions in the test mode.  What do the users think?

Even if you followed carefully the setup of the application on the source server the performance could be bad, or it could scream.   One company (unnamed) got such good performance at this point they shut down the PoC and began implementing the application in production.  For them the application was a Web server and the PoC was more like a pilot than a PoC like the one I’m describing here.   If you are moving a production, mission critical server, DO NOT skip the subsequent steps of the methodology.  Higher performance may be tempting to implement right away but the next steps are there to ensure that the production application is migrated seamlessly without a serious interruption in the business.

After the testing is done it’s time to clean up and document the steps and results.  Cleaning up includes restoring the database on the target server to the original installation before the application was ported.  The documentation includes not only the performance numbers of the tests but also the steps needed to get the application to be ready to run the testing.   An important part of the documentation is to determine which steps in the set up can be run in parallel.  If you’re using Data Pump, while it runs in parallel maybe you can run multiple Data Pumps, each one moving a different Oracle schema or one focused on moving the largest database table while the others move the smaller tables.  (I don’t want to get lost in the weeds here but this is what I’ve done with Oracle Export and Import)  The point is, what can be run in parallel that is on the critical path so that the application can be migrated more quickly.

The final step is a team meeting to review the experiences during the PoC.  You’re looking for what could have been done easier?  What could have been done quicker?  What new components of the application have we found?   All this turns into the project plan for the next step of the migration of the production application, the rehearsal where you are going to practice the actual migration of the production application.

This has been a long write up but it is very important.  The next entries will cover the next steps in the migration process.