Architecting the Target Solaris Environment

The architect phase involves two essential tasks: assessing the current environment and designing a migration solution for moving to the new environment. In this section, we describe the assessment and design tasks for an example migration from Red Hat Linux to the Solaris OS.

Assessing the Current Linux Environment

Assessing our case study's environment is a straightforward process. At the acquired company, approximately 20 servers were being used: 10 production machines, 5 development and test boxes, and 5 standard office servers. The production application was mostly Java based, with an Oracle database. Significant shell scripting has also been used as utilities in the product, and a few Linux open source tools were also deployed. For internal IT services, the company supported file sharing and printing through the open source Samba package, intranet web applications built on PHP, and MySQL database as well extensive use of email (based on the venerable Sendmail).

We start this assessment by inventorying the hardware and software on each server. Because the acquired company standardized on RPM package management and one Linux vendor, there is a single process for assessing each server. The process consists of a few RPM and Linux utility commands that are scripted and executed on each server. This provides a high-level baseline of the configuration of each server.

From this baseline, we start to delve into the configuration of each server. For the production servers, this means identifying the actual programs and scripts that provide service to their customers. While most of the scripts are simple shell or Perl scripts, most of the open source tools are C coded. The shell scripts will need to be run through ScriptTrans for verification of their portability to Solaris, and the C code will be analyzed with the JScore tool. A sample JScore report and analysis is provided in Appendix A.

Along with this hardware and software analysis, we also assess the data. The majority of the production system's data is held in an Oracle database (several hundred gigabytes), and the internal systems have data in a MySQL database and files on the file servers. There is also the matter of the precious source code that is being held on the development servers. The source code resides in a file-based concurrent versioning system (CVS) repository.

Before the assessment is completed, skills and process factors are assessed for the proposed migration. This assessment primarily entails surveying the technical staff for the skills required to work on the Solaris OS (or the lack therefore). However, we also make sure that we look at some of the configuration and change management processes because improving them is one of our objectives.

Designing a Migration Solution

With the assessment completed, it is now time to choose migration strategies appropriate to each of our applications and apply them in a holistic way to create our new environment. This will involve decomposing each of the current server's needs separately, but creating a solution that integrates their needs in total. While this sounds difficult, it is really the same process used to architect any environment.

Analyzing the data collected in our assessment activities, we start to formulate a strategy for our migration to the Solaris environment. Because most of the applications that we are currently using internally and externally exist on the Solaris platform, we believe that we can use a straight rehosting strategy for most of our migrations. It is the least expensive and least time-consuming strategy. Because it also fulfills the primary aim of this project (to migrate to and standardize on the Solaris OS) and we are satisfied with our current applications functionality and performance, we decide that we will follow this strategy whenever possible. We will follow this strategy for the applications listed in the following table.

Table 9-3. Actions Required to Support Specific Applications

Application	Rehosting Action
Samba	Recompile open source code or obtain compiled package. Eventually, migrate to PCNetlink (another project).
MySQL	Recompile open source code or obtain compiled package. Eventually, migrate to Oracle (another project).
PHP	Recompiled version included in Solaris.
PHP code	Run under newly recompiled PHP interpreter.
Oracle	Purchase and install new Oracle for Solaris binaries.
GCC (compiler)	Either recompile open source code or obtain a compiled package. Eventually migrate to Forte ¢ (a different project).
Apache	Recompiled version included in Solaris.
Sendmail	Recompiled version included in Solaris. Eventually, migrate to Sun ONE Mail Server.
Production java applications	Run under a virtual machine for the Java platform (Java ¢ Virtual Machine) on the Solaris OS.

Now that we have decided on a rehosting strategy for most of the applications, we still have another decision: Do we rehost the applications on Solaris/x86 or Solaris/SPARC? Solaris/x86 will run on the organization's current hardware (with possibly a few modifications and upgrades), whereas Solaris/SPARC will require the purchase of new hardware. However, Solaris/SPARC will allow us to purchase much more powerful equipment that enables us to scale our production environment vertically. After weighing the costs of buying new hardware versus the benefits of scaling, we decided to upgrade the production environment to Solaris/SPARC while reusing the internal server's hardware for Solaris/x86.

The final decision to make about our rehosting strategy is to choose which build environment we will use. In this scenario, we could use the current GCC compiler (recompiled for Solaris) or move to Sun's Forte compiler. Sun's compiler is tuned for the Solaris environment, building more optimized binaries for the UltraSPARC ¢ processors. However, it might require changes to the source code, make files, and build environment to use. For this reason, we choose the GNU C/C++/Fortran/Objective C-to-C converter (commonly called GCC2CC). It takes source code written for GCC (our default build environment on Linux), and outputs equivalent C code, which can then be fed into the target ANSI C compiler, like Sun's Forte compiler. (For more information about this free tool, visit http://www.sun.com/migration/linux/gcc2c_tool.html.) In this particular scenario, we decide to use GCC to ease our maintenance tasks for the open-source applications that we will be using. However, this option will be investigated for our in-house written applications. This creates the matrix shown in the following table.

Table 9-4. Platform Selected to Support Specific Applications

Application	Rehosting Action	Platform
Samba	Recompile open source code or obtain compiled package. Eventually, migrate to PCNetlink (another project).	Solaris/x86
MySQL	Recompile open source code or obtain compiled package. Eventually, migrate to Oracle (another project).	Solaris/x86
PHP	Recompiled version included with the Solaris OS.	Solaris/x86
PHP code	Run under newly recompiled PHP interpreter.	Solaris/x86
Oracle	Purchase and install new Oracle for Solaris binaries.	Solaris/SPARC
GCC (compiler)	Either recompile open source code, obtain compiled package. Eventually migrate to Forte (a different project).	Solaris/SPARC
Apache	Recompiled version included with the Solaris OS.	Solaris/x86
Sendmail	Recompiled version included with the Solaris OS. Eventually, migrate to Sun ONE Mail Server.	Solaris/x86
Production Java applications	Run under Java virtual machine (JVM) on the Solaris OS.	Solaris/SPARC

We have identified that at least one C program does not compile on the Solaris OS. This will require a bit more analysis before we can decide on a migration strategy. We have several options to explore on this application:

• Run the Linux binaries under lxrun emulation on Solaris/x86. While this seems like the simplest solution, it will require some configuration on the server, restricts the platform to Solaris/x86, and might cause performance problems stemming from the emulation.

• Search for a replacement application with similar features and performance. Although this seems like a good choice, it will require substantial integration with the current service and extensive regression testing to prove that it will perform.

• Port the code to Solaris and run it under Solaris/x86 or Solaris/SPARC. By examining our JScore output for this application, we see that the report estimates that the porting complexity for this application will be average. Only three system calls will need to be implemented. The rest of the changes will be mostly syntax changes in existing calls. This will also require extensive testing, but little integration work.

• Port the code to Java and run it on either platform with the appropriate Java virtual machine (JVM). This is a very attractive and strategic option but will require substantial work in redeveloping the application from the ground up. Because the application was not designed in an object-oriented model, it will need to be completely rewritten.

After looking at the options and weighing the risks of each option, we decide to port this application to the Solaris OS. This option provides us with many strategic benefits without much of the risk of involved in redeveloping the application in the Java programming language. We expect that this porting work can be accomplished by our developers in about two weeks; however, we make sure and plan for the contingency that they cannot achieve this goal. In this case, our contingency plan is to outsource this activity if we fail to port the code ( assuming that this can be done within budget) or to use the lxrun rehosting (emulation) strategy.

After the strategy has been determined, we start the real work of the architect phase by breaking down the component technologies for all of our servers. At this point, we also decide on the target platform's technology components . Each component in the Red Hat Linux stack is complemented by a Solaris technology component that provides similar or better functionality.

This architecture achieves most of our objectives for the project. However, some careful capacity planning will be needed to size the new servers to realize our goal of vertically scaling the production servers.