Stage 2: Define the Lab Strategy and Build the Test Bed


Although not much documentation is needed for this stage, it is critical to definea lab strategy and to create one or more test beds. It is advantageous to have a controlled and dedicated lab for both the migrated application and the native UNIX application. The number of servers and clients that must be added to the network depends on the application.

Defining a Lab Strategy

The lab strategy is an approach to setting up and configuring the lab with the available resources, and accounting for what additional resources must be added. The following questions cover some of the issues involved in defining a lab strategy:

  • Does the test environment already exist?

  • Does a new lab need to be built?

  • What are the hardware configuration requirements for the migrated application and for the UNIX application?

  • Does the application need interoperability?

  • What is the functional nature of the application considered for migration?

  • Does the migrated application require performance testing? Does the lab have resources for performing high-end performance testing?

Determining Network Requirements

To define a lab strategy, you must determine the network requirements for the lab. Most of the requirements should be derived from the assessment process. (For details about assessment, see Chapter 4, Assessment and Analysis. ) However, the following questions can also help you determine network requirements:

  • Do the resources in the lab require domain configuration?

  • What network configuration is required?

  • Does the lab require any network support?

  • Does the application need any backup plans?

  • What kind of support do you need for the test computers?

  • Is there any database configuration? Do the databases need any specific network protocol?

  • What is the operating system of the migrated application and the UNIXapplication?

  • Does the application require Microsoft Windows 2000 Services for UNIX(SFU) and interoperability options?

Determining Hardware Requirements

The majority of the resources allocated for the lab fall under hardware requirements. If the migrated application is intended for a single user workstation, hardware requirements may not be a significant issue; however, if the application is intended for a client/server system, planning for hardware requirements must occur during the initial stages.

You must determine what server configuration the application requires, and whether the test lab must include any special requirements. Many times, applications that are installed on a server may require special configurations, such as a separate Internet Protocol (IP) address or service package. Often, vendors themselves recommend the minimum platform requirements for their applications; some vendors even provide application engineers to help configure and optimize the server platform for the applications.

You must follow a similar approach to determine the client configuration that the application requires. A low-end system can be used as the clients during testing to reduce the cost of production. Sometimes, even workstations can be used as clients.

Interoperability requirements are another important consideration. If the application needs password synchronization, resource sharing, and data sharing, you must plan separate interoperability requirements based on the testing requirements. For example, to set up password synchronization, you might require SFU user name mapping in conjunction with single sign-on daemon (SSOD) and password authentication module (PAM) modules on UNIX. Similarly, for data sharing, you mightuse a Samba client for Windows or a network file system (NFS) server for SFU.

Determining Software Requirements

The software requirements for the test phase are normally included in the initial plan for the migration project. The software list includes the following:

  • Operating system, utilities, and scripting language (such as Windows 2000 Professional or Advanced Server, Microsoft Windows XP, SFU 3.0, andActive Perl)

  • Any additional software packages and libraries, such as Interix and TrolltechQt or RogueWave Software

  • Test management and automation tools (such as Rational Rose, SilkTest, or Winrunner) and Assessment tools (such as MigraTEC 32Direct or PorteNT)

Building the Test Bed

With the help of system support engineers, you can plan and implement the test bed. During this stage, the operating system is installed and servers are configured, as indicated in the lab strategy. There can be multiple test beds, and each test bed can have multiple hardware configurations and systems. For example, if the application is a UNIX application running on Linux 7.1 and Solaris 8.0, and if the migrated application must be tested on both Windows 2000 Advanced Server and Windows XP, you may need to prepare four systems that have these operating systems installed.

In general, take the following steps to build a test bed:

  1. Build, configure, and test the physical network.

  2. Build, configure, and test the server or servers.

  3. Build, configure, and test any data sources.

  4. Build, configure, and test the clients.

  5. Perform a final check of all lab components and overall system readiness.

Note  

For more information about creating a test lab, see Chapter 4: Building a Windows 2000 Test Lab, in the Windows 2000 Server Resource Kit Deployment Planning Guide , available online as a downloadable document at http://www.microsoft.com/windows2000/techinfo/reskit/dpg/default.asp .




UNIX Application Migration Guide
Unix Application Migration Guide (Patterns & Practices)
ISBN: 0735618380
EAN: 2147483647
Year: 2003
Pages: 134

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net