SQL Server 2008 Hyber V Unleashed - p 9 pdf

ptg6432687
60
2 Best Practices at Planning, Prototyping, Migrating, and Deploying Windows
Server 2008 Hyper-V
. Documentation Required from Prototype
. Pilot Phase(s) Detailed
. Migration/Upgrade Detailed
. Support Phase Detailed
. Support Documentation Detailed
9. Budget Estimate
. Labor Costs for Prototype Phase
. Labor Costs for Pilot Phase
. Labor Costs for Migration/Upgrade Phase
. Labor Costs for Support Phase
. Costs for Training
10. Project Schedule
The Executive Summary Section
The executive summary should set the stage and prepare the audience for what the docu-
ment will contain, and it should be concise. It should outline, at the highest level, the
scope of the work. Ideally, the executive summary also positions the document in the
decision-making process and clarifies that approvals of the design are required to move
forward.
The Goals and Objectives Section
The goals and objectives section might seem redundant because the design documents
documented the objectives in great detail, but it is important to consider which specific
goals and objectives are important to the success of the migration project that might not
have been included in the design document. For example, although the design document
outlined what the final server configuration will look like, it might not have outlined the
tools needed to migrate key user data or the order that physical servers will be migrated to
virtual servers. So, the goals and objectives in the migration document will be very process
specific.

The Background Section
A summary of the migration-specific decisions should be provided to answer questions
such as “Why are we doing it that way?” because there is always a variety of ways to
convert a physical server to a virtual server session, such as using tools provided by
Microsoft, using third-party tools, or rebuilding a server from scratch in a virtual environ-
ment. Because a number of conversations will have taken place during the planning phase
to compare the merits of one method versus another, it is worth summarizing them early
in the document for anyone who wasn’t involved in those conversations.
Download at www.wowebook.com
ptg6432687
61
The Migration Planning Phase: Documenting the Process for Migration
The Risks and Assumptions Section
Risks pertaining to the phases of the migration should be detailed, and typically are more
specific than in the design document. For example, a risk of the prototype phase might be
that the hardware available won’t perform adequately and needs to be upgraded.
Monitoring, virus protection, or backup software might not meet the requirements of the
design document and therefore need upgrading. Custom-designed applications or applica-
tions that may direct calls to hardware devices might turn out not to work properly in a
virtual environment.
The Roles and Responsibilities Section
In the roles and responsibilities section, the teams that will do the work should be identi-
fied in detail. If an outside company will be performing portions of the work, you should
document which tasks it will be responsible for and which ones internal resources will
take ownership of.
The Timeline and Milestones Section
Specific target dates can be listed, and should be available directly from the project sched-
ule already created. This summary can prove very helpful to executives and managers,
whereas the Gantt chart contains too much information. Constraints that were identified
in the discovery process need to be kept in mind here because there might be important

dates (such as the end of the fiscal year), seasonal demands on the company that black
out certain date ranges, and key company events or holidays. Again, be aware of other
large projects going on in your environment that might impact your timeline. There’s no
point trying to deploy new servers on the same weekend that the data center will be
powered off for facility upgrades.
The Training Plan Section
It is useful during the planning of any upgrade to examine the skill sets of the people who
will be performing the upgrade and managing the new environment to see whether any
gaps need to be filled with training. Often, training will happen during the prototype
testing process in a hands-on fashion for the project team with the alternate choice being
classroom-style training, often provided by an outside company. Also ask yourself whether
the end users will require training to use new client-side tools being installed during a
parallel application upgrade process. Also pay attention to how the new environment will
integrate into existing systems such as backup or monitoring. Determine whether those
groups will need any training specific to interacting with the new virtual servers.
The Migration Process Section
The project schedule Gantt chart line items should be included and expanded upon so
that it is clear to the resources doing the work what is expected of them. The information
does not need to be on the level of step-by-step instructions, but it should clarify the
process and results expected from each task. For example, the Gantt chart might indicate
that a Windows 2008 server needs to be configured; and in the migration document,
information would be added about how the hard drives are to be configured, how virtual
network segments are to be connected to physical segments, and which additional appli-
cations (virus protection, tape backup, network management) need to be installed.
2
Download at www.wowebook.com
ptg6432687
62
2 Best Practices at Planning, Prototyping, Migrating, and Deploying Windows
Server 2008 Hyper-V

If the Gantt chart lists a task of, for example, “Configure and web services access,” the
migration document gives a similar level of detail: Which image should be used to config-
ure the base system configuration, which additional applications should be loaded, how is
the system to be locked down, and what testing process should be followed (is it scripted
or will an administrator perform the testing)?
Documentation also should be described in more detail. The Gantt chart might simply list
“Create as-built documents,” with as built defined as “document containing key server
configuration information and screenshots so that a knowledgeable resource can rebuild
the system from scratch.”
Sign-off conditions for the prototype phase are important and should be included. Who
needs to sign off on the results of the prototype phase to indicate that the goals were all
met and that the design agreed upon is ready to be created in the production environment?
Similar levels of information are included for the pilot phase and the all-important migra-
tion itself. Typically during the pilot phase, all the upgraded functionality needs to be
tested, including remote access, file encryption access, and access to shared folders. Be
aware that pilot testing might require external coordination. For example, if you are
testing remote access through a VPN connection, you might need to acquire an additional
external IP address and arrange to have an address record created in DNS to allow your
external testers to reach it without having to disturb your existing remote access systems.
The migration plan should also account for support tasks that need to occur after the
Hyper-V infrastructure is fully in place. If you are using an outside consulting firm for
assistance in the design and implementation, make sure that they will leave staff onsite
for a period of time immediately after the upgrade to be available to support user issues or
to troubleshoot any technical issues that crop up.
If documentation is specified as part of the support phase, such as Windows maintenance
documents, disaster-recovery plans, or procedural guides, expectations for these docu-
ments should be included to help the technical writers make sure the documents are satis-
factory.
The Budget Section
With regard to the budget information, although a great amount of thought and planning

has gone into the design and migration documents, and the project plan, there are still
variables. No matter how detailed these documents are, the later phases of the project
might change based on the results of the earlier phases. For instance, the prototype testing
might go flawlessly, but during the pilot implementation, performing data migration
simply takes longer than anticipated; this extra time will require modifications to the
amount of time required and the associated costs. Note that changes in the opposite direc-
tion can happen, too, if tasks can occur more quickly than anticipated. Often, the imple-
mentation costs can be reduced by keeping an eye on ways to improve the process during
the prototype and pilot phases.
Download at www.wowebook.com
ptg6432687
63
The Prototype Phase: Creating and Testing the Plan
The Project Plan Section
Whereas the project plan provides the high-level details of the steps, or tasks, required in
each phase, the approach sections of the migration document can go into more detail
about each step of the project plan, as needed. Certain very complex tasks are represented
with one line on the project plan, such as “Configure Hyper-V Host #1,” but might take
several pages to describe in sufficient detail in the migration document.
Data-availability testing and disaster-recovery testing should be discussed. In the design
document, you might have decided that clustering will be used, as will a particular tape
backup program, but the migration plan should outline exactly which scenarios should be
tested in the prototype lab environment.
Documents to be provided during the migration should be defined so that it is clear what
they will contain.
The Prototype Phase: Creating and Testing the Plan
The main goal of the prototype phase is to create a lab environment in which the key
elements of the design as defined in the design document can be configured and tested.
Based on the results of the prototype, you can determine whether any changes are needed
to the implementation and support phases as outlined in the migration document.

The prototype phase is also a training phase, in which the members of the deployment
team get a chance to get their hands dirty with the new hardware and software technolo-
gies to be implemented. If an external consulting firm is assisting with the prototype
testing, knowledge transfer should occur and be expected during this process. Even if the
deployment team has attended classroom training, the prototype process is an environ-
ment that will more closely reflect the end state of the network that needs to be
supported, and will involve technologies and processes not typically covered in classroom-
style training. The deployment team can also benefit from the real-world experience of
the consultants if they are assisting in this phase.
This environment should be isolated from the production network so that problems
created by or encountered in the process don’t affect the user community.
The design details of testing applications, confirming hardware performance, testing fault-
tolerance failover, and the like should be verified in a safe lab environment. If changes are
needed to the design document, make them now.
How Do You Build the Lab?
Although the details of the project will determine the specifics of exactly what will be in
the prototype lab, certain common elements will be required. The migration document
2
Download at www.wowebook.com
ptg6432687
64
2 Best Practices at Planning, Prototyping, Migrating, and Deploying Windows
Server 2008 Hyper-V
should clearly outline the components of the lab and which applications and processes
should be tested. A typical environment will consist of an initial Windows 2008 host
server required for the implementation, network switches, and sample physical servers
that will be converted from the production environment. Connectivity to the outside
world should be available for testing purposes.
A key decision to make is whether the lab will be implemented into the environment or
stay as a lab. Some companies proceed from the prototype phase to the pilot phase with

the same equipment, whereas others prefer to keep a lab set up for future use. The advan-
tages of having a lab environment for a Windows 2008 Hyper-V environment are many,
and include testing application updates, upgrades, and patches and having hardware avail-
able for replacement of failed components in the production environment.
Real data and applications should be installed and tested. Data can be copied from live
production servers, or data from tape can be restored to a test server. Applications should
be installed on the servers according to a manufacturer’s installation instructions; in addi-
tion, however, compatibility validation with Hyper-V virtualization should be conducted.
After the software applications have been installed, representative users from the different
company departments could be brought into the lab to put the applications through their
paces. These users will be best able to do what they normally do in the lab environment
to ensure that their requirements will be met by the new configuration. Areas that don’t
meet their expectations should be recorded and identified as either “showstoppers” that
need to be addressed immediately or issues that won’t harm the implementation plan.
Results of the Lab Testing Environment
In addition to the valuable learning that takes place, a number of other things come out of
the lab testing process. If time permits, and there is room in the budget, a variety of docu-
ments can be produced to facilitate the pilot and implementation process. Another key
result of the lab is hard evidence of the accuracy and completeness of the design and
migration documents.
Some of the documents that can be created will assist the deployment team during the
migration process. One key document is the “as-built” document, which provides a snap-
shot of the key configuration details of the primary servers that have been configured and
tested. Whereas the design document outlines many of the key configuration details, the
as-built document contains actual screenshots of the server configurations and contains
the output from the Hyper-V Administration tool, which provides important details, such
as physical and logical disk configuration, system memory and processor information,
services installed and in use on the system, and so on.
Another important document is the disaster-recovery document (or DR document). This
document should outline exactly which types of failures were tested and the process for

rectifying these situations. Keep in mind that a complete disaster-recovery plan should
include offsite data and application access, so the DR document that comes out of the
prototype phase will, in most cases, be more of a hardware-failure document that
Download at www.wowebook.com
ptg6432687
65
The Pilot Phase: Validating the Plan on an Initial Set of Servers
discusses how to replace failed components, such as hard drives and power supplies, and
how to restore the server configuration from tape backup or restore data sets.
If you need to implement multiple servers in the pilot and implementation phases, you
can document checklists for the step-by-step processes in the prototype phase. Bear in
mind that creating step-by-step documents takes a great deal of time (and paper!), and a
change in process requires drastic changes to these documents. Typically, creating a step-
by-step “recipe” for server builds is not worth the time unless task-focused resources need
to build a large number in a short period of time.
When the testing is complete, revisit the migration plan to confirm that the timeline and
milestones are still accurate. Ideally, there should be no major surprises during the proto-
type phase, but adjustments might be needed to the migration plan to ensure the success
of the project.
Depending on the time frame for the pilot and implementation phases, the hardware and
software that will be needed for the full implementation might be ordered at this point.
Because the cost of server hardware has decreased over the past several years, many
companies “over-spec” the hardware they think they need, and they might determine
during the prototype phase that lesser amounts of RAM or fewer processors will still
exceed the needs of the technologies to be implemented, so the hardware requirements
might change.
The Pilot Phase: Validating the Plan on an Initial
Set of Servers
Now that the prototype phase has been completed, the deployment team is raring to go
and gain hands-on experience migrating servers to virtual sessions. The process docu-

mented in the migration document and migration plan will have been tested in the lab
environment as completely as practical, and documentation detailing the steps to be
followed during the pilot implementation will be on hand.
Although the pilot process will vary in complexity based on the extent of the changes to be
made to the network infrastructure, the process should be well documented at this point.
It is important to identify the first group of servers that will be moved to the new
Windows 2008 Hyper-V environment. Systems that have redundancy throughout the
environment (domain controllers, DNS servers) are a better choice for initial migration
than highly critical business application servers that have no existing failover or redun-
dancy configurations.
2
Download at www.wowebook.com
ptg6432687
66
2 Best Practices at Planning, Prototyping, Migrating, and Deploying Windows
Server 2008 Hyper-V
NOTE
In many virtualization projects, a critical business application may be a good opera-
tional candidate to be virtualized if the hardware the system is running on is having
problems and evacuating the physical hardware to a virtual system can alleviate exist-
ing physical system problems. However, be ver y careful in migrating a critical applica-
tion first. Consider migrating a couple of simple servers to a virtualized state, so that
you can get familiar with managing, monitoring, and administering the simple server
configurations first. Then schedule the migration of the critical application server.
A rollback strategy should be clarified, just in case.
Test the disaster-recovery and redundancy capabilities thoroughly at this point with live
data but on a limited number of servers to make sure everything works as expected.
Migration processes can be fine-tuned during this process, and time estimates can be
nailed down.
The First Server in the Pilot

The pilot phase begins when the first physical server is migrated to a virtual guest session
on Windows 2008 Hyper-V and users access the application on the virtual server in the
production environment. Depending on the scope of the migration project, this first
server might be a simple web server or a SharePoint site, or the first server might be an
Active Directory domain controller.
Just as in the prototype phase, the testing to be conducted in the pilot phase is to verify
successful access to the server or application services the virtual session provides. One of
the best ways to validate functionality is to take the test sequences used in the prototype
phase and repeat the test steps in the pilot production environment.
The major difference between the prototype and pilot phases is interconnectivity and
enterprisewide compatibility. In many lab-based prototype phases, the testing is isolated to
clean system configurations or homogeneous system configurations. In a pilot production
environment, however, the virtual server session is live in a full production environment.
It is the validation that the new setup works with existing users, servers, and systems.
Rolling Out the Pilot Phase
The pilot phase is usually rolled out in subphases, with each subphase growing in number
of servers migrated and the distribution of host servers throughout the organization.
Number of Migrated Servers
The whole purpose of the pilot phase is to migrate servers one by one from physical to
virtual guest sessions to validate that prototype and test assumptions were accurate and
that they can be successful in the production environment. An initial three to five servers
are first to be migrated. These servers test basic migration processes and Hyper-V configu-
rations.
Download at www.wowebook.com
ptg6432687
67
The Pilot Phase: Validating the Plan on an Initial Set of Servers
After successful basic testing, the pilot server group can grow to 5%, then to 10%, and on
to 20% of the servers planned for migration. This phased rollout will help the migration
team test compatibility, connectivity, and communications with existing systems, while

working with a manageable group of systems that won’t overwhelm the administrators
during the pilot and migration process.
The pilot phase is also a time when administrators build the knowledge base of problems
that occur during the migration process. Thus, if or when problems occur again (possibly
in the full rollout phase), lessons have been learned and workarounds already created to
resolve stumbling blocks.
Application Complexity of Pilot Migrations
In addition to expanding the scope of the pilot phase by sheer number, selecting servers
that have different application-usage requirements can provide a level of complexity
across server configuration. Application compatibility and operation are critical to the
administrator’s experience during the migration process. Often, administrators won’t mind
if something runs a little slower during the migration process or that a new process takes a
while to learn. However, end users will get upset if the applications they require and
depend on each day to get their job done are offline, data is lost due to system instability,
or the application just won’t work. So, testing applications is critical in the early pilot
phase of the project.
Geographical Diversity of Pilot Servers
The pilot server group should eventually include servers geographically distributed
throughout the organization. It is important to start the pilot phase with servers that are
local to the IT or help desk operation so that initial pilot support can be done in person or
directly with the initial pilot group of systems. Before the pilot is considered complete,
however, servers in remote sites should be migrated and tested to ensure remote users or
branch office users still have access to migrated servers in the new virtualized networking
environment.
Fixing Problems in the Pilot Phase
No matter how much planning and testing is conducted in the earlier phases of the
project, problems always crop up in the pilot phase of the project. It is important to have
the prototype lab still intact so that any outstanding problems can be re-created in the
lab, tested, and resolved to be tested in the pilot production phase again.
Documenting the Results of the Pilot

After the pilot, it is important to document the results. Even with the extensive discovery
and design work, and even though the prototype lab testing and pilot phases have taken
place, problems might recur in the postpilot phases, and any documented information
about how problems were resolved or configurations made to resolve problems in the
pilot phase will help simplify the resolution in future phases. If you take some extra time
to give attention to the pilot users, you can fine-tune the solution to make sure the full
implementation succeeds.
2
Download at www.wowebook.com
ptg6432687
68
2 Best Practices at Planning, Prototyping, Migrating, and Deploying Windows
Server 2008 Hyper-V
The Migration/Implementation Phase: Conducting
the Migration or Installation
By this point in the project, more than 20% of the servers flagged for migration should
have been converted and tested in the pilot phase, applications thoroughly tested, admin-
istrators and support personnel trained, and common problem resolution clearly docu-
mented so that the organization can proceed with the migration of the balance of the
servers identified for virtualization.
Verifying End-User Satisfaction
A critical task you can complete at this point in the project a check of end-user satisfac-
tion. You want to make sure that users are not experiencing any problems access their
applications and that server performance hasn’t diminished. You also want to confirm
that accessibility is not limited, questions are answered, problems are resolved, and most
important, users are being made aware that IT is interested in their feedback during the
backend migration of server systems. Of course, this backend migration should not nega-
tively impact the users at all, but it’s worth checking to make sure.
Not only does this phase of the project focus on the sheer rollout of the technology, it is
also the key public relations and communications phase of the project. Make sure the user

community gets to input their experiences in the process.
Supporting the New Virtualized Environment
Before the last servers are rolled into the new virtualized environment, besides planning
the project-completion party you need to allocate time to verify the ongoing support and
maintenance of the new environment. This step not only includes doing regular backups
of the new servers, but also performing regular maintenance of the virtual host server and
guest sessions (see Chapter 6, “Managing, Administering, and Maintaining Hyper-V Host
Services”).
Disaster recovery and failover should be implemented because there are now fewer servers
hosting multiple application systems (covered in detail in Chapter 12, “Application-Level
Failover and Disaster Recovery in a Hyper-V Environment”). You also want to tune and
optimize the new Hyper-V environment (see Chapter 7, “Optimizing the Hyper-V Host
Server and Guest Sessions”).
Now is the time to begin planning for some of the wish list items that didn’t make sense
to include in the initial migration—for example, implementing new stretched clusters
across a WAN, adding disk-to-disk-to-tape backup and recovery procedures, and the like.
If you have a lab still in place, use it to test these additional services.
Summary
One analogy used in this chapter is that of building a house. Although this analogy
doesn’t stand up to intense scrutiny, the similarities are helpful. When an organization is
Download at www.wowebook.com
ptg6432687
69
Best Practices
planning a server virtualization implementation, it is important to first understand the
goals for the implementation, and not only the 50,000-foot high-level goals, but also the
10,000-foot departmental and 1,000-foot IT staff goals. Then, it is important to more fully
understand the environment that will serve as the foundation for the upgrade. Whether
this work is performed by external resources or by internal resources, a great deal will be
learned about what is really in place, and where there might be areas of risk or exposure.

Collaboration sessions with experienced and effective leadership can then educate the
stakeholders and deployment resources about the technologies to be implemented and
can guide the group through key decision-making areas. Now all this information needs to
be documented in the design document so that the details are clear, and some initial esti-
mates for the resources required, timeline, and budget can be set. This document serves as
a blueprint of sorts, and defines in detail what the “house” will look like when it is built.
When all the stakeholders agree that this is exactly what they want to see, and the time-
line and budget are in line, the migration document can be produced.
The migration document includes a detailed project plan that provides the tasks that need
to take place to produce the results detailed in the design document. The project plan
should not go into step-by-step detail describing how to build each server, but should stick
to summary tasks from 4 hours to a day or more in duration. The migration document
then provides a narrative of the project plan and supplies additional information pertain-
ing to goals, resources, risks, and deliverables, as well as budgetary information accurate in
the 10% to 20% range.
Based on these documents, the organization can now proceed with building the solution
in a lab environment and testing the proposed design with actual company data and
resources involved. The results of the testing might require modifications to the migration
document, and will prepare the deployment team for live implementation. Ideally, a pilot
phase with a limited, noncritical group of users will occur to fine-tune the live implemen-
tation process and put in place key technologies and Windows Server 2008 Hyper-V. Now
the remainder of the implementation process should proceed with a minimum of
surprises, and the result will meet the expectations set in the design phase and verified
during the prototype and pilot phases.
Even the support phase has been considered, and during this phase, the “icing on the
cake” can be applied as appropriate.
Although this process might seem complex, it can be molded to fit all different sizes of
projects and will yield better results.
Best Practices
The following are best practices from this chapter:

. Use a migration methodology consisting of discovery, design, testing, and imple-
mentation phases to meet the needs of your organization.
. Fully understand the business and technical goals and objectives of the upgrade and
the breadth and scope of benefits the implementation will provide before imple-
menting a new application or upgrade.
2
Download at www.wowebook.com