|< Day Day Up >|
The first phase in the SunTone migration methodology involves architecting the solution. At this stage, you assess the existing environment and design a first-cut architecture.
Assessing the Current Environment
The next step in the migration is the assessment of the existing application and the associated environment. This will allow you to create a risk list that can be used to identify any areas of the project that might require a proof of concept to ensure that the project can be completed. The outcome of the assessment is a risk list (where appropriate) and a work breakdown structure that details the amount of effort required to migrate the application and the associated environment. This work breakdown structure is then used to create a plan and schedule various activities, overlapping independent subtasks , where appropriate.
For custom-written applications, provide the migration team with a snapshot of the application source and associated infrastructure to serve as a baseline for the migration activity. When possible, you should also acquire a build log for the application. This log will provide the following information:
Although development documentation is welcome, a simple build log can serve as a guide to the "facts on the ground." It will show how the application is actually built.
In the following sections, we explore the assessment process.
Assessing the Application Infrastructure
Scripts provide an easy way for IT staff or administrators to create tools to administer an application, analyze or modify data, and provide functional support for an application. Scripts can leverage utilities that exist elsewhere in the operating environment to perform various administrative tasks . In addition, scripts will identify which utilities are used, as well as the options that are specified.
When the application is migrated, the associated scripts must be migrated to the new environment as well. Although the script tool (for example, Ksh , bash , sh , csh , PERL, or Python) might support the same syntax in the new environment, the location of the programs or files used by the script might be different in the new environment. Additionally, the options of the programs called by the scripts might also require modification.
Ensure that a version of the script tool is available in the new environment.
The Perl utility is becoming popular as a scripting tool because of its power and flexibility. However, the venerable shell is still the script tool of choice for most developers, primarily because of its availability across a variety of platforms and environments.
When assessing shell scripts, check each command for the following conditions:
This check can be done manually or through the use of the scriptran tool.
The following sample presents the analysis of the issues associated with the shell scripting used with the Tru64 example.
alias 27 ar 365 cc 86 colrm 1 df 14 du 1 e 2 ed 1 egrep 68 expr 11 fold 1 get 1 iostat 1 ipcs 45 ld 13 lex 4 ln 177 lpr 2 make 1 mcopy 1 more 12 mt 3 netstat 5 printenv 5 sleep 94 stty 1 style 219 tail 61 tset 1 vmstat 26 w 5 wait 14 whoami 2 xconsole 3 xhost 4 xlsclients 1 xset 14 xsetroot 4 xterm 1 yacc 4 Total: 40 1301
Analyze Build Tools
When working with a custom application, you also have to migrate the tools used to build the application executable. These usually include a compiler, a source code management system, and the build environment used to create the executable. Additionally, any third-party products that were used to build the application must be migrated.
Obtaining a build log created when the application was last built is the best way to ensure that the build process and the tools involved in that process are identified. Be certain that you understand the semantics of the options that were specified when the application was built. Although tools in the new environment will most likely support the required functionality, different options might have to be specified to invoke the desired behavior. For example, static linking, position-independent code, extended symbol table information, and the like might require the use of new and different options.
In this example, the assessment reveals that a number of development tools are currently available on another Sun platform within the enterprise. Although this development environment has not been used to create the Tru64 version of the application you want to port, you can leverage some of the existing tools that are available (for example, compilers and debuggers ). Assume that you have determined that this platform can be used for the migration exercise.
Determine Third-Party Products Usage
While all applications depend on support from the operating environment and associated utilities, many applications are also designed to work with the functionality provided by third-party products that are integrated into the execution architecture. When the application is ported, this supporting software must be ported as well, as part of the application infrastructure. In the example, the most significant piece of third-party software is the Sybase database that is implemented on the Tru64 environment. However, additional third-party software is used to generate reports and administrate the database.
When assessing third-party products, you must ensure that these or similar products are available for both the new OS and the new database.
This migration case study involves the conversion of a Sybase database implemented on the Tru64 platform to an Oracle database running on the Solaris platform. FIGURE 10-1 on page 183 provides an overview of the Sybase implementation.
Figure 10-1. O verview of Application and Supporting Environment
When attempting to assess the database component of the application, be sure to assess the deployment of database technology, not just the database itself. Databases have evolved to become much more than simple repositories for data. Complex logic can be programmed into the database. Database vendors encourage developers and database administrators (DBAs) to store database- related (or data- intensive ) logic inside the database. The program units that are locally stored in databases are often called stored procedures and triggers.
The practice of storing program logic in the database aids in the assessment because the majority of the database-related logic is centralized in a single location, although some interaction with the database will be specified in the programs themselves . For DBAs who are concerned about database performance, storing program logic in the database is encouraged as well, because logic that is locally stored in the database has many positive performance implications. These stored program units are written in a language that is commonly known as the Structured Query Language (SQL).
Regrettably, although there is an SQL standard, the degree of compliance with this standard varies greatly from one database vendor to another. Different database vendors might develop their own extensions to the SQL language to make it more powerful and easier to use and, in some cases, to address specific database performance issues through optimization.
The assessment of the database technology must address the stored procedures as well as database object behavior. Among the different databases, database objects (box 16 in FIGURE 10-1 on page 183) that have the same name behave differently. For example, database objects such as stored procedures, triggers, and temporary tables are supported in both Sybase and Oracle. However, there are no standards for the behavior of these objects. Consequently, procedures, triggers, and temporary tables stored in Sybase behave differently than those stored in Oracle. These differences must be well understood before you can accurately assess the amount of change and effort that will be required in a migration.
Take extra care when migrating application logic from one version of SQL to another. In this example, translating a full-blown Sybase T-SQL application to Oracle's PL/SQL could result in an extensive modification or a total rewrite. You must carefully identify the use of language features that might require the reimplementation of logic on the new deployment because the SQL extensions and their underlying functionality might not be available. For this reason, the conversion of the Sybase implementation will be considered a reengineering or rearchitecture effort.
When assessing the database technology integration with the application, be aware that each database vendor has its own version of SQL and that these versions can vary considerably. Understanding the differences in SQL implementations will help you understand the nature and amount of work that is needed for a project of this nature.
In addition to the Sybase database technology, our example makes use of third-party reporting tools (box 11), and DBA tools (box 13). If the tool vendor supports both source and target databases and platforms, these can most likely be replaced. If a tool cannot be replaced for any reason, then all the components that use it will most likely need to be rewritten. To keep the example simple, assume that you can replace all the third-party tools and libraries.
In the example, all the components that use SQL will be affected in the same manner. These components are:
Problems arise when the data types that are used in the source database cannot be mapped to the target database. If a data type cannot be mapped, you must find a way to mimic its functionality in the target database. This simple data type issue could potentially trigger a chain reaction of changes that need to be made to all components that reference the table. The extent of modifications will depend on the nature of the data type in question and how extensively it is used by all the components that are using the database.
In our example, all data types map from the Sybase implementation to the Oracle implementation without difficulty.
Assess the Application
As detailed previously, you must acquire the code for the application. That code will help you estimate how much effort will be required for the migration. There are two issues to consider when assessing an application:
The following appsurvey output represents the composition of the files under the source code repository of the inventory application.
Module FileType # Lines # of Files # API issues invtry .4 127 1 0 invtry .C 429661 605 44 invtry .H 24570 216 9 invtry .Make_files 20174 126 0 invtry .Msg 6572 24 0 invtry .acf 1916 86 0 invtry .bak 430 8 0 invtry .bld 1914 6 0 invtry .c 656575 415 14 invtry .cat 25 1 0 invtry .cfg 131 11 0 invtry .cl 5070 34 0 invtry .cpp 6017 2 0 invtry .ctl 27908 54 0 invtry .dat 20684 11 0 invtry .def 81 1 0 invtry .h 116618 356 1 invtry .sh 2790 6 0 invtry .sql 301904 699 0 invtry .test 133 1 0 invtry .tidl 4780 51 0 invtry .tmp 453 1 0 invtry .tpl 8169 36 0 invtry .wpm 162 1 0 invtry .zip 146 2 0 TOTAL 2672376 4066 68
Remember that it is possible that not all of these files will be used to create the application. An analysis of the build log will reveal which files are used when the application is created.
In this example, you are considering a custom application written in the C programming language. When implementing this sort of migration, focus on the differences between the APIs provided by the Tru64 environment and those provided by the Solaris OS. The following sample breaks down the APIs differences.
Total Files: 3717 LinesOfCode: 1185289 Statements: 388262 Issues: accept 4 Weight: 5 acosd 2 Weight: 5 asind 4 Weight: 5 atand 5 Weight: 5 bind 33 Weight: 5 bind_to_cpu 1 Weight: 25 connect 5 Weight: 5 cosd 15 Weight: 5 endhostent 2 Weight: 5 exp 1 Weight: 5 fork 28 Weight: 3 freopen 6 Weight: 5 fseek 28 Weight: 5 gethostbyaddr 4 Weight: 5 gethostent 1 Weight: 25 getsockname 2 Weight: 5 getsockopt 15 Weight: 25 getsysinfo 6 Weight: 200 gettimeofday 90 Weight: 5 getuid 1 Weight: 3 htonl 44 Weight: 5 htons 63 Weight: 5 inet_addr 18 Weight: 3 inet_lnaof 1 Weight: 5 inet_netof 1 Weight: 5 inet_network 1 Weight: 3 inet_ntoa 14 Weight: 3 ioctl 104 Weight: 25 kill 26 Weight: 5 listen 4 Weight: 5 log 2 Weight: 5 min 9 Weight: 25 mq_setattr 1 Weight: 5 msgctl 2 Weight: 5 msgrcv 31 Weight: 5 munmap 3 Weight: 5 nint 9 Weight: 5 nintf 4 Weight: 5 ntohl 14 Weight: 25 ntohs 15 Weight: 25 open 6 Weight: 25 opendir 13 Weight: 5 pfopen 1 Weight: 200 pow 22 Weight: 5 pthread_cleanup_pop 3 Weight: 5 pthread_cleanup_push 3 Weight: 5 pthread_delay_np 21 Weight: 25 pthread_get_expiration_np 13 Weight: 25 pthread_lock_global_np 125 Weight: 25 pthread_unlock_global_np 128 Weight: 25 recv 14 Weight: 5 recvfrom 12 Weight: 5 remainder 1 Weight: 5 sched_getscheduler 1 Weight: 5 semctl 4 Weight: 5 semget 1 Weight: 3 semop 8 Weight: 3 send 11 Weight: 5 sendto 8 Weight: 5 sethostent 1 Weight: 5 setsid 3 Weight: 3 setsockopt 20 Weight: 25 setsysinfo 1 Weight: 200 settimeofday 4 Weight: 5 shmat 7 Weight: 3 shmctl 10 Weight: 3 shmdt 5 Weight: 3 shmget 7 Weight: 3 sigaction 5 Weight: 25 sigwait 5 Weight: 25 sind 13 Weight: 5 socket 55 Weight: 5 sqrt 118 Weight: 5 statvfs 2 Weight: 3 strftime 49 Weight: 5 system 2 Weight: 5 table 3 Weight: 200 tand 3 Weight: 5 template 1 Weight: 3 times 2 Weight: 3 ulimit 8 Weight: 25 uswitch 2 Weight: 200 wait 40 Weight: 3 waitpid 2 Weight: 3 write 2 Weight: 5
Assess the Compute and Storage Platform
In the example, the capacity of the existing hardware platform is determined. Based on this information, a replacement platform is chosen from the Sun product line that will provide the required performance, reliability, scalability, and manageability. The details of hardware sizing are outside the scope of this document.
Assess the Network Infrastructure
Next, examine the networking facilities inside the enterprise's data center to determine if they can support the required future capacity and load generated by the migrated environment. Where appropriate, additional capacity might have to be acquired (10BASE-T to 100BASE-T). All aspects of the network must be considered, from the transport technology (FDDI, Token Ring, Ethernet, and the like) to the number of ports that are available on the switch or hub that will be used to cable the Network Interface Card (NIC).
Once you determine the networking technology, you can order the correct NIC for the hardware described above.
In the example, the 100-megabyte network has sufficient capacity, and a port is available on the switch serving the data center. A 100BASE-T NIC is required for the platform, as well as a 10-meter cable to make the connection.
During the next part of the assessment, you assess the facilities and any changes that will be required to support the migrated solution. During this assessment, consider power, space, network connections, door frame size, and similar requirements.
In the example, the new platform is roughly the same in size as the older platform. As a result, it can fit through all the doorways. However, it will have to be installed in a previously unused corner of the data center because the old machine will not be retired for some time.
The newer Sun hardware in this example requires more power but produces less heat than the older platform. However, a new electrical receptacle will be required for compatibility with the new hardware. In this case, the client decides to re-route a cable run for cabling efficiencies with existing machines and to bring power to the new location.
Assess Management Tools
Next, you assess the existing management tools and determine how they can be moved to the target platform. In this case, the client uses BMC Patrol to monitor the old Tru64 environment. This product is also available for the Solaris environment and has already been deployed on other Sun platforms within the data center. Additional ad hoc system monitoring is performed using the cron utility, to schedule scripts that use conventional UNIX utilities such as iostat , vmstat , df , and the like.
Assess People and Process
The skills of the organization must be assessed to determine whether any gaps exist. A curriculum is then developed to address any shortfalls. In our example, the IT staff already supports a number of Sun/Solaris/Oracle environments, which means that no additional training should be required.
Understanding Threading Models
Applications use threads to implement fine-grained parallelism. Thread libraries have been created for most modern operating environments. The most common threading implementations are POSIX threads and Solaris threads, which have similar semantics. The Solaris OS supports both threading models.
DEC's implementation of threads differs slightly from these implementations. In the example, you would use a compatibility library to replace threading APIs that are found in the Tru64 environment, but not found in the Solaris environment.
|< Day Day Up >|