Citrix_XenServer_5_Design_Template

<Client Logo>

Client_NameProject_Name

Citrix® XenServer™ 5 Design

[Insert Date, 2008]

Prepared by:Project_Lead[Title]PartnerABC

[Name] [Title]PartnerABC

Revision History

Revision Change Description Updated By Date

- i -

How to use the Citrix XenServer 5 Design Template

This is just a template and should be modified as you see fit. That includes adding and/or removing sections and subsections to fit the needs of the client and project.

All text written in orange should be removed. Orange is used to provide the writer with tips and tricks and is information only.

All text written in blue should be replaced with applicable verbiage. Blue is used to provide sample verbiage and should not be used as is.

Before you are finished, please double check: Properties of document (in particular, check custom tab)

o Note: As stated on the cover page, several variable fields such as client and project are automatically entered based on the Properties entry. To automatically update all variable fields, click EditSelect All and F9.

Confirm that all reviewer changes and comments in Track Changes have been addressed

Update fields and page numbers in Table of Contents Review all headers and footers

o To update the footers with variable fields, highlight the footer text and press F9. Please note that there are two sets of footers in the document: one for the Table of Contents section and one for the main body of the document.

Review overall formatting Remove all orange and blue text

- ii -

Deliverable Signoff

The signatures below indicate Client_Name’s and PartnerABC’s agreement to the contents of the Citrix® XenServer™ 5 Design.

Client_Name PartnerABC

Name: Name:

Signature: Signature:

Title: Title:

Date: Date:

- iii -

Table of Contents

1. Executive Summary............................................................................................11.1 Project Overview.......................................................................................................................... 11.2 Deliverable Overview...................................................................................................................11.3 Deliverable References................................................................................................................11.4 Consulting_Organization Resources............................................................................................11.5 Next Steps.................................................................................................................................... 1

2. Architectural Design...........................................................................................12.1 Overview...................................................................................................................................... 12.2 Design Summary.......................................................................................................................... 12.3 Design Concerns.......................................................................................................................... 1

XENSERVER...............................................................................................13. Host Configuration..............................................................................................1

3.1 Description................................................................................................................................... 13.2 Key Decisions............................................................................................................................... 13.3 Design.......................................................................................................................................... 13.4 XenServer Host Parameters.........................................................................................................1

4. Resource Pools...................................................................................................14.1 Description................................................................................................................................... 14.2 Key Decisions............................................................................................................................... 14.3 Design.......................................................................................................................................... 14.4 Resource Pool Design..................................................................................................................1

5. XenMotion & High Availability............................................................................15.1 Description................................................................................................................................... 15.2 Key Decisions............................................................................................................................... 15.3 Design.......................................................................................................................................... 15.4 XenMotion Configuration..............................................................................................................15.5 High Availability Configuration......................................................................................................1

6. Storage Infrastructure.........................................................................................16.1 Description................................................................................................................................... 16.2 Terminology.................................................................................................................................. 16.3 Key Decisions............................................................................................................................... 16.4 Design.......................................................................................................................................... 16.5 Boot Storage Configuration..........................................................................................................16.6 Virtual Disk Storage Configuration...............................................................................................16.7 ISO Library Configuration.............................................................................................................1

7. Network Infrastructure........................................................................................17.1 Description................................................................................................................................... 17.2 Terminology.................................................................................................................................. 17.3 Key Decisions............................................................................................................................... 17.4 Design.......................................................................................................................................... 17.5 Physical NIC Configuration..........................................................................................................17.6 Management Interface Configuration...........................................................................................17.7 Host Networks.............................................................................................................................. 17.8 XenServer IP Address Table........................................................................................................17.9 Network Communications............................................................................................................1

8. Server Hardware Environment...........................................................................18.1 Description................................................................................................................................... 18.2 Key Decisions............................................................................................................................... 18.3 Design.......................................................................................................................................... 1

- iv -

8.4 Server Hardware Configuration....................................................................................................18.5 Aggregated Capacity.................................................................................................................... 1

SYSTEMS MANAGEMENT.........................................................................19. Systems Management.........................................................................................1

9.1 Description................................................................................................................................... 19.2 Key Decisions............................................................................................................................... 19.3 Design.......................................................................................................................................... 1

10. XenCenter Configuration....................................................................................110.1 Description................................................................................................................................. 110.2 Key Decisions............................................................................................................................. 110.3 Design........................................................................................................................................ 110.4 XenCenter Hardware Requirements..........................................................................................110.5 XenCenter Configuration............................................................................................................110.6 Email Notification Settings..........................................................................................................110.7 XenServer System Alert Configuration.......................................................................................110.8 Custom Fields, Searching and Tagging.....................................................................................110.9 Software Updates....................................................................................................................... 1

11. Backup and Recovery.........................................................................................111.1 Description................................................................................................................................. 111.2 Key Decisions............................................................................................................................. 111.3 XenServer Host Backup.............................................................................................................111.4 Virtual Machine Metadata Backup..............................................................................................111.5 Virtual Machine Backup..............................................................................................................111.6 Virtual Machine Snapshots.........................................................................................................111.7 Disaster Recovery...................................................................................................................... 1

VIRTUAL MACHINES..................................................................................112. Virtual Machine Design.......................................................................................1

12.1 Description................................................................................................................................. 112.2 Key Decisions............................................................................................................................. 112.3 Design........................................................................................................................................ 112.4 Virtual Machine Configuration....................................................................................................112.5 Virtual Machine Templates.........................................................................................................112.6 Virtual Machine HA Configuration..............................................................................................112.7 Workload Migration Process.......................................................................................................1

13. Workload Matrix..................................................................................................113.1 Description................................................................................................................................. 113.2 Key Decisions............................................................................................................................. 113.3 Citrix Server Virtualization Assessment (SVA)...........................................................................113.4 Desktop Workload...................................................................................................................... 1

SECURITY...................................................................................................114. Security................................................................................................................1

14.1 Description................................................................................................................................. 114.2 Key Decisions............................................................................................................................. 114.3 Design........................................................................................................................................ 1

- v -

APPENDICES..............................................................................................115. Appendix A: XenServer Networking Explained................................................1

15.1 Internal Networks....................................................................................................................... 115.2 External Networks...................................................................................................................... 115.3 Bonded Interfaces...................................................................................................................... 115.4 VLAN’s....................................................................................................................................... 115.5 Virtual Network Combinations....................................................................................................1

- vi -

1. Executive Summary

1.1 Project Overview

Client_Name . . .

Currently,

The business drivers for this effort revolve around . . .

1.2 Deliverable Overview

This Architectural Design document is the result of collaboration with . . .

Based on those collaborative discussions, the architecture described within this document represents the design decisions made in conjunction with PartnerABC during the course of this engagement.

This Architectural Design is organized as follows:

Citrix XenServer 5.0 Design

Section Topics Covered

Executive Overview and Architectural Design

This section provides an overview of the project, including critical design considerations. It details the fundamental architecture of the new XenServer design. High-level decisions are summarized as related to the overall architecture of the solution.

XenServer

Host Configuration This section defines the general configuration and installation parameters for the XenServer deployment. The XenServer host consists of a Xen-enabled Linux operating system, a management agent, VM templates, and a local storage repository reserved for VMs.

Resource Pools This section defines the planned architecture of the XenServer Resource Pool. Within this section Resource Pools, number of XenServer hosts, number of pools, networking, shared storage, XenMotion and High Availability (HA) options are defined.

XenMotion and High Availability

This section defines how the Resource Pool and respective XenServer hosts will be configured to accommodate XenMotion and High Availability (HA) features to provide availability and protection to the guest virtual machines. It includes information regarding XenMotion requirements, as well as HA protection levels.

Storage Infrastructure This section defines the planned architecture for the storage infrastructure for individual XenServer hosts and the shared storage required for hosts configured in Resource Pools. Within this section, storage hardware, the underlying disk sub-system, RAID types, dynamic multipathing, ISO library settings, virtual disk images (VDI) types and virtual machine storage are defined.

Network Infrastructure

This section defines the physical network interface cards (NICs), virtual switches and associated virtual machine networks, VLAN information, and NIC bonding configuration used on XenServer hosts and virtual machines to enable networking.

Citrix XenServer 5.0 Design

Server Hardware Environment

This section defines the underlying server hardware platform for the XenServer host. Within this section, hardware configuration such as CPU, memory, NICs, disk, host bus adapters (HBAs) and the aggregate server capacity within the XenServer Resource Pool are defined.

Systems Management

Systems Management

This section discusses design decisions related to managing the XenServer environment. The selection of appropriate management tools, delegation of tasks based upon user and group assignment and security of available management tools are all discussed.

XenCenter Configuration

This section defines the configuration settings for the XenCenter management console, client requirements, software updates, searching and tagging, email notifications, alerts and monitoring requirements.

Backup and Recovery

This section describes the backup and recovery requirements for the XenServer environment including XenServer host backup, Resource Pool requirements, and snapshotting and guest virtual machine metadata. Backup and recovery procedures and technologies implemented are also defined to ensure the XenServer environment is protected.

Virtual Machines

Virtual Machine Design

The Virtual Machine section defines the guest virtual machines which will be hosted in the XenServer infrastructure. Within this section, characteristics of the virtual machines, including virtual hardware configuration, template configuration, home server settings, high availability protection levels and P2V methodology are discussed.

Workload Matrix This section details the planned desktop and server workloads that will be hosted as guest virtual machine on the XenServer infrastructure. Information gathered as a result of the Citrix Server Virtualization Assessment, if it was conducted, will also be discussed.

Security

Security This section discusses the security related aspects of the XenServer design. Physical server security, along with encryption and enclave networking are analyzed.

Section Approach

Each design topic is organized into three subsections:

Overview. This subsection provides an overview of the key concepts within the Key Decisions and Design Sections.

Key Decisions. This subsection provides a decision matrix for Client_Name based on line items. Client_Name can use the decision matrices as quick reference guides to identify settings and configuration decisions to be implemented in the environment.

Design. This subsection provides justification and additional information related to the Key Decisions and discusses their relevance to Client_Name’s virtual desktop environment.

- 2 -

1.3 Deliverable References

The deliverable provides guidelines for the implementation. However, it does not provide step-by-step instructions on how to install the components discussed. Therefore, PartnerABC recommends that administrators involved in the implementation review the following documents, articles, and guides prior to building and implementing the production environment. All of these documents are available from the Document Center or online Citrix Knowledge Base.

Citrix XenServer Administrators guide

Citrix XenServer Installation Guide

Citrix XenServer Virtual Machine Installation Guide

The following icons will be used throughout the document in order to highlight important information:

Symbol Description

This icon indicates that a decision is required based on the environment specific information.

This icon indicates important notes that need to be considered as part of the further planning process.

1.4 PartnerABC Resources

The following PartnerABC associates contributed to this project:

PartnerABC

Project_LeadTitleAddressTel:Mobile: [email protected]

Staff ConsultantTitleAddressTel:Mobile: [email protected]

1.5 Next Steps

Based on the Statement of Work dated xx xx, 2008, this document represents the architectural design for the Citrix XenServer environment. Following this, . . .

- 3 -

Tarkan Kocoglu, 04/12/08,

This icon should be used to highlight areas in the design that requires a decision, which could not be accomplished during the design process (missing information, other dependencies).

Tarkan Kocoglu, 04/12/08,

This icon should be used to highlight areas with important information that needs to be considered during further planning.

mailto:[email protected]


2. Architectural DesignThis section provides a high-level description of the proposed implementation based on requirements and risks identified as part of the Server Virtualization Assessment, as well as the information gathered during the course of the design discussions.

2.1 Overview

The architecture for the Citrix XenServer environment that has been designed . . .

This design takes into account . . .

The following diagram depicts the planned environment for . . .

[Include Visio diagram detailing the XenServer architecture]

2.2 Design Summary

In summation, this design is based on the following components designated as follows:

XenServer

XenCenter

Virtual Machines

2.3 Design Concerns

During the preceding assessment, as well as the development of this design, the PartnerABC team found the following items to be risks or unknown factors associated with this project and therefore represent concerns that may impact success:

[Item1]

[Item2]

[Item3]

- 4 -

XenServer

- 5 -

3. Host ConfigurationThis section defines the general configuration and installation parameters for the XenServer deployment. The XenServer host consists of a Xen-enabled Linux operating system, a management agent, VM templates, and a local storage repository reserved for VMs.

3.1 Description

Citrix XenServer. XenServer is the platform virtualization solution which enables the creation of virtual x86 guest computers running on Xen, the open-source paravirtualizing hypervisor with near-native performance.

VM Support. Windows Virtual Machines (VMs) can be created only on XenServer hosts equipped with 64-bit Intel VT-enabled or AMD-V CPUs. Linux VMs do not require XenServer hosts that are equipped with Intel VT-enabled or AMD-V CPUs.

3.2 Key DecisionsDecision Point Design Decision Justification

XenServer Version

4.15.0

XenServer Edition

EnterprisePlatinumOEM

Hotfix Level List hotfixes here

Type of Deployment

NewUpgrade

Deployment Scenario

CDHTTP….etc

Deployment Location

Naming Convention

Server naming convention

Server Hardware Specifications

Overview of server specs…

Storage Configuration

Type of storage used locally, SAN, iSCSI, NFS…etc

Networking Configuration

ManagementVirtual machine networking

NIC Bonding

Number of XenServer Hosts

- 6 -

3.3 Design

The configuration settings of XenServer are detailed below. These settings…..

Within this section, you should explain any details that require additional verbiage; it is not necessary to simply restate any items that are contained within the Design Decisions table unless it is a lead-in to a more detailed explanation.

Where possible, include screen shots, diagrams, tables, or graphical depictions to explain the design. A picture is worth 1,000 words (and reads a lot easier)! There are some tables included for your convenience, but these should be modified, appended, or deleted as necessary.

Remember that blue text is sample text only!

3.4 XenServer Host Parameters

This section details the XenServer deployment parameters required during the server installation process.

Configuration Option Value

Keyboard Mapping Qwerty, US

Installation type New Install UpgradePre-installed (OEM)

Hardware Virtualization Assist Enabled Disabled

Installation Source CDHTTP or FTPNFSUSB (OEM)

Linux Pack enabled Yes or No

Root Password

Primary Disk /dev/hdaSize in GB

Management Interface eth1MAC AddressNIC Type/Model

Networking Configuration StaticDHCPIP Address details

Hostname Configuration

DNS Configuration

Time Zone Australia | Sydney

System Time Configuration Using NTPManual Time Entry

NTP Server/s NTP Server 1NTP Server 2NTP Server 3

- 7 -

4. Resource Pools This section defines the planned architecture of the XenServer Resource Pool. Within this section Resource Pools, number of XenServer hosts, number of pools, networking, shared storage, XenMotion and High Availability (HA) options are defined.

4.1 Description

A resource pool comprises multiple XenServer host installations, bound together into a single managed entity which can host VMs. Features which provide guest availability and resiliency such as XenMotion and HA are only available through a XenServer Resource Pool. A resource pool is an aggregate of one or more homogeneous XenServer hosts, up to a maximum of 16. The definition of homogeneous is:

each CPU is from the same vendor (in particular AMD-V and Intel VT CPUs cannot be mixed)

each CPU is the same model (except for stepping)

each CPU has the same feature flags

all hosts are running the same version of XenServer software

In addition to being homogeneous, an individual XenServer host can only join a resource pool if:

an Enterprise license is installed on the host

it has a static IP address (either manually assigned or via DHCP);

it is not a member of an existing resource pool

its clock is synchronized to the same time source as the pool master (for example, via NTP)

it has no shared storage configured

there are no running or suspended VMs on the XenServer host which is joining

there are no active operations on the VMs in progress, such as one shutting down

the management NIC of the XenServer host which is joining is not part of a NIC bond


Number of Resource Pools

Number of XenServers per Resource Pool

Decision for separate pools

Administration point, number of guests…etc

Resource Pool Locations

Dedicated Pool Master

- 8 -

Decision Point Design Decision Justification

Number of Guest Virtual Machines

Resource Pool Storage

4.3 Design

The configuration settings of XenServer Resource Pools are detailed below. These settings…..

Multiple Resource Pools are required because…..

4.4 Resource Pool Design

The following section defines the settings for Resource Pool 1.


Pool Name XEN Pool 1

Pool Description

Location Sydney

Number of XenServer Hosts 16 (Maximum number of hosts)

Assigned Pool Master Server YesXEN01

Pool Slave/Member Servers XEN02XEN03….

Number of guest VMs hosted 100

Guest OS types

Assigned Storage Repositories

Assigned Pool Networks

XenMotion Enabled Yes

HA Enabled Yes

The following section defines the settings for Resource Pool 2.


Pool Name XEN Pool 2

Pool Description

Location Sydney

Number of XenServer Hosts 16 (Maximum number of hosts)

Assigned Pool Master Server YesXEN01

Pool Slave/Member Servers XEN02XEN03….

Number of guest VMs hosted 11

- 9 -


Guest OS types Windows XPWindows 2003 Server

Assigned Storage Repositories

Assigned Pool Networks

XenMotion Enabled Yes

HA Enabled Yes

- 10 -

5. XenMotion & High AvailabilityThis section defines how the Resource Pool and respective XenServer hosts will be configured to accommodate XenMotion and High Availability (HA) features to provide availability and protection to the guest virtual machines. It includes information regarding XenMotion requirements, as well as HA protection levels.

5.1 Description

XenMotion. XenMotion is the live migration of guest VMs across different XenServer hosts without any noticeable downtime. A Resource Pool combined with shared storage enables VMs to be dynamically migrated on any host.

High Availability (HA). XenServer adds automated high availability (HA) with resource-based placement of VMs in the event of host server failures. HA includes dynamic fail-over planning based on available resources to help ensure that VMs are restarted on the appropriate physical server.

HA Heartbeat. XenServer HA utilizes a storage and network heartbeat mechanism to check and absolutely guarantee that a host is unreachable.


XenMotion Enabled Resource Pool/s

All XenServer Pools will be XenMotion enabled

HA Enabled Resource Pool/s

HA enabled pools include Pool1 and Pool2 only

HA Network Heartbeat

Management interface will be bonded for redundancy

HA Storage Heartbeat

An FC based SR will provide as storage SR

HA Protection Levels

Servers will be protected with differing priorities while desktops will be set to Best Effort level only

Unprotected VMs

The remaining VMs will be unprotected, including the following…..

- 11 -


HA Capacity The planned HA capacity will provide up to 2 XenServer host failures as per the server hardware design

5.3 Design

XenMotion has been configured……

HA has been configured….

5.4 XenMotion Configuration

Using XenMotion Live Relocation, you can move a running virtual machine from one server to another server in the same Resource Pool with no service interruption. A VM can only be migrated if it is using shared storage resources within the pool.

The following table defines the Resource Pool and the respective XenServer hosts configured with XenMotion.

XenServer Host Resource Pool XenMotion

XEN01 Pool1 Enabled

XEN02 Pool1 Enabled

XEN03 Pool1 Enabled

XEN10 Pool2 Enabled

XEN20 Pool2 Enabled

XEN30 Stand-alone Host Not Configured

XEN40 Stand-alone Host Not Configured

5.5 High Availability Configuration

With the XenServer HA feature enabled, XenServer continually monitors the health of the host servers in the pool. The HA mechanism automatically moves protected VMs to a healthy host if the current XenServer host fails. Additionally, if the host that fails is the master, HA selects another host to take over the master role automatically.

The following table illustrates the HA configuration settings available on…..

For more detail on each VMs HA restart priority, refer to Section 11. Virtual Machine HA Configuration.


Resource Pool Name

Resource Pool Master Server

Resource Pool Member Servers

- 12 -


HA Enabled YesNo

Heartbeat Storage Repository

Heartbeat SR Type Shared storage limited to iSCSI LUN or FC LUN

Heartbeat SR Size 400MB(Minimum size is 356MB)

HA Protection Levels Protected Priority 1: Server 1 to 3 Priority 2: VM 11 to VM20.etc Priority 3:

Priority Level: 1, 2 and 3Best-effortDo not restart

- 13 -

6. Storage InfrastructureThis section defines the planned architecture for the storage infrastructure for individual XenServer hosts and the shared storage required for hosts configured in Resource Pools. Within this section, storage hardware, the underlying disk sub-system, RAID types, dynamic multipathing, ISO library settings, virtual disk images (VDI) types and virtual machine storage are defined.

6.1 Description

Storage Repository (SR). Storage Repositories are storage targets containing homogeneous virtual disks. A XenServer host defines a container called a Storage Repository to describe a particular storage target, in which Virtual Disk Images (VDIs) are stored.

Virtual Disk Images (VDIs). A VDI is an on-disk representation of a virtual disk provided to a VM and is the fundamental unit of virtualized storage in XenServer.

Shared Storage. A shared SR is required for Resource Pool creation and XenMotion functionality. Shared SR includes the following storage types: iSCSI, Fibre Channel and NFS storage.

ISO Library. CD and DVD image files represented as ISO files can be stored on CIFS or NFS based storage repositories. The ISO files can them be mounted o the guest virtual machines and used during the operating installation.

6.2 Terminology

Citrix XenServer uses specific terminology to define various aspects of the storage architecture, the following table explains this terminology, which is used throughout the remainder of the document.

XenServer Acronym

Explanation Description

SR Storage Repository A container where VDIs are stored. The SR types supported are IDE, SAS, SCSI, SATA on Local disks, and FC, NFS and iSCSI on shared storage. A XenServer host can have access to multiple SR types.

PBD Physical Block Device

The interface between the Storage Repository and the physical host. A PBD is basically a connector that attaches an SR to a XenServer host. PBDs store device configuration information used to connect to a storage system. For example, for NFS it contains the IP address of FQDN of the NFS server and the export path that gets mounted by the XenServer host.

VBD Virtual Block Device

The interface between the VDI and the virtual machines. VBDs map VDIs to VMs. They also provide for QoS for a given VDI.

- 14 -

XenServer Acronym


VDI Virtual Disk A VDI is a disk abstraction where the contents of virtual disks are stored. There are 4 VDI types: VHD, Logical Volume Manager, NetApp and EqualLogic Managed LUNs. The difference between Logical Volume Manager and NetApp/EqualLogic Managed LUNs is that LUNs are put under Linux LVM control whereas NetApp and EqualLogic Managed LUNs are not.

The four VDI Types can be defined as follows: VHD: This format can be used with local disk on

top of an ext3 file system or over NFS. VDIs stored on VHDs by default are thin provisioned.

LVM: This format can be used with local disk or shared storage. When a LUN is put under LVM control, its split into multiple Logical Volumes each of which will store a VDI.

NetApp: Managed NetApp LUNs are accessible via the NetApp SR driver type, and are hosted on a Network Appliance device running a version of ONTAP 7.0 or greater. LUNs are allocated and mapped dynamically to the host via the XenServer host management framework.

EqualLogic: EqualLogic storage is accessible via the EqualLogic SR driver type, and are hosted on an EqualLogic storage array. LUNs are allocated and mapped dynamically to the host via the XenServer host management framework.

Via the XenCenter GUI, each VM can be configured with up to 8 Virtual Disks including the CDROM. This can be extended to 24 via the command line.

VHD Virtual Hard Disk The VHD format is a Microsoft open format for virtual disk storage. In XenServer terms, a VHD file can only be used on ext3 or NFS storage.

VHD files are sparse and extended in 2Mb chunks.

VHD files can also be chained.

The following diagram shows a graphical overview of storage repositories and related objects.

- 15 -


XenServer Boot Storage

LocalBoot from SAN

Local Storage IDESCSISATASASUSB

Local Storage Configuration

RAID-1 across 2 x 72GB disks @ 15,000 rpm

Virtual Machine Storage

LocalShared

Shared Storage Configuration

VDI Type VHDLVMNetAppEqualLogic

SAN Storage Details

EMC CX300

HBA Type HardwareSoftware

Dynamic Multipathing

Enabled across QLogic HBAs

Heartbeat SR iSCSI LUNFC LUN

Virtual Machine Metadata

- 16 -


ISO Library Settings

CIFS share on Windows 2003 server FNP01

Virtual Disk QoS

Enabled for….

Data Deduplicaton

Enabled

Thin Provisioning

Enabled

6.4 Design

The XenServer OS will be installed on….

The shared storage configured for the XenServer Resource Pools will leverage…..

The Storage Repository…..

The virtual machines disk images…..

Server virtual machines will reside on SR X which is backed on RAID-10 FC LUNs……

Desktop virtual machines will reside on SRY which is backed on RAID-5 FC LUNs….

[Insert Visio diagram detailing the overall storage configuration, logical and/or physical connections]

6.5 Boot Storage Configuration

The following section defines the storage configuration of the XenServer boot volume which will be used for the Xen OS binary installation.

[Insert Visio diagram detailing the Boot Storage configuration]


Boot Volume Storage Type IDESCSISATASASBoot from SANUSB

Number of Disks 2

Disk Size 72GB

Disk Speed 15,000 RPM

RAID Configuration RAID-1 (Mirror)

Crash Dump SR LocalShared Storage

Suspend SR LocalShared Storage

- 17 -

6.6 Virtual Disk Storage Configuration

The guest virtual machine disk files represented as VDIs will be stored using ….

[Insert Visio diagram detailing the SR and VDI configuration]


Storage Repository Type Local Storage

Storage Repository Size

Storage Repository Name

VDI Type EXTVHD

Local Storage Configuration 5 x 72GB 15,000 rpm SCSI disks, RAID-5


Storage Repository Type NFS


Hosts Attached

Storage Repository Name

NFS Path

Advanced Options

NFS Storage Vendor

NFS Storage Model


Storage Repository Type iSCSI


Hosts Attached

SR Name

Target Host

iSCSI Port 3260

CHAP Enabled Yes/NoCHAP UserCHAP Secret

Target IQN

Dynamic Multipathing EnabledDisabled

Number of Paths

iSCSI Storage Vendor

iSCSI Storage Model


Storage Repository Type NetApp


Hosts Attached

- 18 -

Dale Abalos, 10/09/08,

Select and complete the applicable SR that will be used for VDI






SR Name

NetApp Filer IP Address

Username

Password


Number of FlexVols in SR 8 (default)

Aggregate

FAS Thin Provisioning EnabledDisabled

FAS Deduplicaton EnabledDisabled


Number of Paths

FAS Model NetApp FAS3020c

Ontap Version 7.2.2

FAS Storage Capacity


Storage Repository Type Hardware HBA


Hosts Attached

SR Name

HBA Type FCiSCSI

HBA Vendor

HBA Model

Password


Number of FlexVols

FAS Thin Provisioning EnabledDisabled

FAS Deduplicaton EnabledDisabled


Number of Paths


Storage Repository Type Dell EqualLogic

- 19 -







Hosts Attached

SR Name

Dell EqualLogic Filer IP Address

Username

Password


Storage Pool Name

Thin Provisioning EnabledDisabled


Number of Paths

Dell Storage Model

Dell Storage Capacity

6.7 ISO Library Configuration

The following section details the storage repository configuration of the ISO library.


Storage Repository Type CIFS


Name

Share Name

CIFS Authentication

User name

Password

Advanced Options

Available ISO files


Storage Repository Type NFS


Name

NFS Path

Advanced Options

Available ISO files

- 20 -



7. Network InfrastructureThis section defines the physical network interface cards (NICs), virtual switches and associated virtual machine networks, VLAN information, and NIC bonding configuration used on XenServer hosts and virtual machines to enable networking.

7.1 Description

Physical Interface (PIF). A PIF represents a physical network interface on a XenServer host. PIF objects have a name and description, a globally unique UUID, the parameters of the NIC that they represent, and the network and server they are connected to.

Virtual Interface (VIF). A VIF represents a virtual interface on a Virtual Machine. VIF objects have a name and description, a globally unique UUID, and the network and VM they are connected to.

Host Network. A host network is a virtual Ethernet switch on a XenServer host. Network objects have a name and description, a globally unique UUID, and the collection of VIFs and PIFs connected to them. Host networks can include the network switch allocated for management or guest virtual machine traffic.

NIC bonds. NIC bonds can improve XenServer host resiliency by using two PIFs as if they were one. If one NIC within the bond fails the host's network traffic will automatically be routed over the second NIC. NIC bonds work in an active/active mode, with traffic balanced between the bonded NICs.

7.2 Terminology

Citrix XenServer uses specific terminology to define various aspects of the network architecture. The following table explains this terminology, which is used throughout the remainder of the document.

XenServer Acronym


PIF Physical Interface A PIF represents a physical network interface on a XenServer host. PIF objects have a name and description, a globally unique UUID, the parameters of the NIC that they represent, and the network and server they are connected to.

VIF Virtual Interface A VIF represents a virtual interface on a Virtual Machine. VIF objects have a name and description, a globally unique UUID, and the network and VM they are connected to.

Network The term network is used to describe a virtual Ethernet switch (vSwitch) on a XenServer host. Network objects have a name and description, a globally unique UUID, and the collection of VIFs and PIFs connected to them.

Further details are described in Appendix A: XenServer Networking Explained.

- 21 -


Number of Physical NICS per Host

XS supports up to 6 physical NICs or 6 pairs of bonds

NIC Configuration

Broadcom1Gbit Full-Duplex

NIC Bonding Configuration

Active/Active Bonds

External Networks

ProductionDMZTest/Dev

Internal Networks

NA

VLAN Configuration

Production (VLAN1)…..etc

Management Interface Configuration

Bonded Management NIC for redundancy

Storage Network Interface

NA

Promiscuous Mode

Enabled on DMZ network

Virtual Switch QoS

Enabled for….

Physical Switch Details

Dual Cisco 24-port managed switch with hardcoded speeds

IP Address Settings

Refer to IP address table….

DNS Configuration

DMZ Configuration

7.4 Design

Each of the XenServer hosts will be configured with ….

The Management Interface used for XenCenter and XenMotion traffic will be …..

A dedicated Storage Interface will be used for …….

The Virtual Machine network include…..

NIC bonding will be configured to provide network redundancy ……

VLAN tagging at the virtual switch is used ….

- 22 -

[Insert Visio diagram detailing XenServer physical and logical network connections]

7.5 Physical NIC Configuration

This section defines the physical network interfaces and the associated host networks configured on each of the XenServer hosts.

Physical NIC

Host Network

NICBonding

Speed/Duplex

Vendor Device

NIC0 mgmt_xenmotion

No 1Gigabit/Full-Duplex

Intel 8254 Gigabit Adapter

NIC1 iscsi No 1Gigabit/Full-Duplex


NIC2 prod_lan Yes 1Gigabit/Full-Duplex


NIC3 prod_lan Yes 1Gigabit/Full-Duplex


[Insert Visio diagram detailing physical network connections and actual physical ports on the XenServer server hardware]

7.6 Management Interface Configuration

This section defines the Management Interface settings and configuration types used for each XenServer host. Dedicated storage network interfaces used for NFS or iSCSI storage repositories are also defined below.

Type Host Network

NICs IP Address

DNS Settings VLAN Comments

Management Interface

mgmt_xenmotion

NIC 0 10.0.0.1 10.0.0.1010.0.0.11

VLAN1 Used for XenCenter and XenMotion traffic

Storage interface

iscsi NIC4 192.168.2.1 NA VLAN10 Used for iSCSI storage traffic

7.7 Host Networks

This section details the host networks configured on the XenServer hosts and Resource Pool to allow the guest virtual machine network connectivity.

Host Network

Network Type

NIC VLAN AutoConnected

Comments

Management External NIC 0 1 No Used for XenCenter and XenMotion traffic

Production BondedExternal

NIC 2NIC 3

NA Yes Used for

DMZ External NIC 4 99 No

- 23 -

7.8 XenServer IP Address Table

This section details the IP address settings for each f the XenServer hosts configured for the Resource Pools.

Resource Pool

Hostname IP Address

Subnet Mask Gateway DNS1DNS2

Location

Pool 1 XEN01 10.0.0.1 255.255.255.0 10.0.0.254 10.0.0.10 Sydney

Pool 2 XEN99 Melbourne

7.9 Network Communications

This section details the commutation traffic between the different components of the XenServer architecture.

[Insert Visio diagram detailing network communications and associated ports]

The following table describes the TCP port configurations for the Citrix XenServer environment.

Purpose Default port number

Port Number to be Used

SSH – XenCenter to XenServer TCP 22 Default

HTTPS – XenCenter to XenServer TCP 443 Default

RDP – XenCenter to VM (Windows) TCP 3389 Default

VNC – XenCenter to VM (Linux) TCP 5900 Default

- 24 -

8. Server Hardware EnvironmentThis section defines the underlying server hardware platform for the XenServer host. Within this section, hardware configuration such as CPU, memory, NICs, disk, host bus adapters (HBAs) and the aggregate server capacity within the XenServer Resource Pool are defined.

8.1 Description

The XenServer host is a 64-bit x86 server-class machine devoted to hosting multiple VMs. This machine runs a stripped-down Linux operating system with a Xen-enabled kernel which controls the interaction between the virtualized devices seen by VMs and the physical hardware. The following are the system requirements for the XenServer host:

CPU. One or more 64-bit x86 CPUs at 1.5 GHz minimum; 2 GHz or a faster multi-core CPU is recommended. Windows VMs can be created only on XenServer hosts equipped with Intel VT-enabled or AMD-V CPUs

Memory. A minimum of 1GB memory; 2 GB or more is recommended

Storage. Locally attached storage including IDE, PATA, SATA or SCSI, with at least 16GB of disk space; 60GB of disk space is recommended.

Network. At least two 100 Mbit/seconds or faster network interface card (NIC) for redundancy; however a Gigabit NIC is recommended for faster P2V migrations and export/import data transfers and for live relocation of VMs.


Server Hardware Vendor

DellHPIBM

Server Model ProLiant 380 Server

Number of CPUs

2 sockets

Number of Cores

Quad-Core Intel at 2GHz

Total Server Memory

64GB

Number of NICs 8 x Gbit NICs

Local Storage 2 x 72GB SCSI disks RAID-1

Host Bus Adapters

QLogic xxx

Shared Storage EMC CX300 SAN with FC SCSI disks at RAID-10 shared LUN presented to XenServer hosts

Redundant Power Supply Nits

Yes, two PSUs cabled to separate power rails

- 25 -


Aggregated Capacity

16 x XenServer Hosts thereby a total of ….

Server Build Process

Manual installation from CD

8.3 Design

The server hardware platform that will be used for the XenServer……

CPU…..

The physical memory configured ….

Shared storage will be configured using ….

Redundant components will be configured to provide….

[Insert Visio diagrams displaying the front and back views of the server hardware platform detailing the disks, NIC ports, FC cabling to FC switches…etc – more detail the better or use multiple diagrams to depict different hardware components]

8.4 Server Hardware Configuration

The following section details the hardware specifics of the XenServer hosts for the solution.

Hardware Value

Hardware Vendor

Server Model

Hardware Virtualization Support Yes, enabled

CPU

Number of CPU Sockets

Number of Cores per Socket

Total number of CPUs

CPU Vendor

CPU Model

CPU Speed

Memory

Allocated RAM

Server RAM Capacity

Type of RAM

Network

Number of NICs

NIC Speed

Total number of network interfaces

- 26 -

Hardware Value

Onboard/PCI Slot NIC0 - onboardNIC1 - onboardNIC2 – PCI slot 1NIC2 – PCI slot 2

Refer to Visio diagram

Local Storage

Number of Disks

Disk Size

Disk Speed

Disk Type

RAID Card

RAID Type

Shared Storage

Host Bus Adapter (HBA)Type iSCSIFC

HBA Vendor QLogic

HBA Model

Number of HBAs 2 configured for multipathing

Fibre Channel Switches Brocade Silkworm FCRefer to Visio diagram for FC physical connections

Other Devices

CD/DVD-ROM

Number of Power Supply Units (PSU) 2 x Redundant PSUs patched to separate power rails

8.5 Aggregated Capacity

The below table illustrated the aggregated XenServer capacity available from the configured Resource Pool compromising of ….hosts.

Resource Pool Number of XenServer Hosts

Total CPU (MHz)

Total Memory(GB)

Total Storage(TB)

Total Network(Gbps)

Pool 1 10 10GHz 640GB 2TB of SAN Storage available

- 27 -

Systems Management

- 28 -

9. Systems ManagementThe Systems Management section discusses design decisions related to managing the XenServer environment. The selection of appropriate management tools, delegation of tasks based upon user and group assignment and security of available management tools are all discussed.

9.1 Description

Designing and implementing a structured systems management solution for Citrix XenServer will help to maintain the consistency and reliability of the XenServer infrastructure. As each XenServer host will typically run several concurrent virtual workloads, the impact of an administrative error which results in a systems outage will be magnified. The design should provide an overview of the common management tasks which need to be undertaken in a typical XenServer environment, discuss the most appropriate toolset for each task and make recommendations regarding how administrative tasks should be delegated.

Management Tool Selection. Selecting the most appropriate tool for each management process will ensure that common tasks are carried out in a consistent manner. This should help to ensure that each administrative task results in a predictable outcome, optimizing the stability of the XenServer environment.

Management Tool Access. The use of XenCenter where firewall traversal is necessary requires specific thought. Port 443 needs to be open to allow general console access while 3389 and 5900 are required for RDP and VNC access to virtual machines.

Management Tool Security. Selected tools should only be made available to relevant personnel. The ability to download, launch and connect to servers using unauthorized copies of support tools should be minimized wherever possible.

Delegation of Administrative Processes. The design will need to focus on the proposed management and support structure for the XenServer environment in order to recommend an effective administrative model. Ensuring that each administrative tier is available only to authorized personnel will ensure that unauthorized changes, intentional or otherwise, which could affect the stability of both physical and virtual hosts and the associated cost of resulting systems outage, can be avoided.


Administrative Tools

XenCenter

Administrative Security

Trust based.

9.3 Design

- 29 -

10. XenCenter ConfigurationThis section defines the configuration settings for the XenCenter management console, client requirements, software updates, searching and tagging, email notifications, alerts and monitoring requirements.

10.1 Description

Apart from being the management console for a single stand-alone XenServer host to multiple Resource Pools, XenCenter also includes some powerful tools for searching, sorting and grouping your resources.

Tags. Tags can be added to your managed resources to help you organize them. Tags are like keywords or labels, and they allow you to rearrange your view of resources within XenCenter depending on criteria such as purpose or geographic location.

Custom Fields. Custom fields can be added to any of the resources within XenCenter which can then be used in building search queries.

Searching. The built-in Search box within XenCenter enables the administrator to search and locate resources quickly.

Monitoring server performance. Performance data from the XenServer hosts and individual guest virtual machines such as CPU, memory and network I/O usage is monitored by XenCenter.

System Alerts. Alerts may be generated to keep you informed of system events including performance alerts, HA (high availability) status alerts and software update alerts. Email notification is sent to the administrator when a preconfigured system event is triggered.


XenCenter Version

5.0.0

Build Number Build 10918

Software Patches Applied

NA

Configured Pools

Pool1Pool2

Management Computer

Server01

Management Computer Location

Same datacenter as XenServers

Authorized Users of Management Computer

Limited to Domain Administrators Group

Proxy ServerSettings

proxy.domian.com Port 8080

Log Destination LocalRemote

Email Alerts and Monitoring

Default alerts configured

- 30 -


SMTP Server mail1.domain.com

Custom Fields NA

Automatic Software Updates

Enabled

10.3 Design

XenCenter will be installed on ….

Access to the XenCenter management computer located at the datacentre s limited to …..

XenCenter will be configured with ……

Default XenCenter alerts and event notifications will be delivered via SMTP using….

[Insert Visio diagram detailing the location of the XenServer hosts, XenCenter with respect to data center locations and connections]

10.4 XenCenter Hardware Requirements

The XenCenter application for managing the XenServer host and Resource Pools can be installed and run on desktops, laptops or servers which satisfy the following requirements:

Operating system. Windows XP, Windows Server 2003, or Windows Vista

Software. .Microsoft NET Framework version 2.0 or above

CPU. Minimum of 750MHz; 1GHz or faster is recommended

Memory. Minimum of 1GB; 2GB or more is recommended

Storage. Minimum of 100MB

Network. 100Mb NIC or faster

Configuration Value

Computer Name (FQDN) ManagementPC.domain.com

Hardware Type HP Desktop

Function Dedicated management terminal

IP Address Details 192.168.2.100255.255.255.0192.168.2.254

Management Network A separate VLAN for management traffic exists on VLAN1

CPU Single Intel

Memory 2GB

NIC 1 x Gigabit NIC

Operating System Windows XP Pro

Software Installed .NET Framework Version 3.5

- 31 -

10.5 XenCenter Configuration

The following section defines the configuration parameters for the XenCenter client.

Configuration Value

XenCenter Version

Build Number

Management Computer

Authorized Users/Groups

Proxy Server Connection Don’t use proxy serverUse proxy settings from IEUse specific proxy server

Graphic Console Type Windows VMs – VNC or RDPLinux – vncterm (text) or VNC

Connection Timeout 20 seconds (Default)

Performance Graphs AreaLine

Log Destination LocalRemote

SSH Enabled

Console Auto-Logout Timeout 5 minutes (default)

10.6 Email Notification Settings

Email notifications will be sent when system alerts are generated from the servers and the VMs configured within the resource pools or hosted on the stand-alone XenServer. The following settings defined the email notification parameters for XenCenter.

Configuration Value

Email alert notification enabled Yes/No

Email Address [email protected]

SMTP Server Mail.domain.com

SMTP Port 25 (Default)

Performance Graphs AreaLine

10.7 XenServer System Alert Configuration

XenServer and XenCenter provide access to alerts that are generated when noteworthy events happen. XenCenter provides various mechanisms of grouping and maintaining metadata about managed VMs, hosts, storage repositories, and other actions. The following settings defined the system alert configuration settings for XenCenter.

Configuration Value Monitored XenServers

Alert Repeat Interval 60 minutes (default) XEN01

CPU Usage Alerts

CPU Threshold 50% (default)

- 32 -


Configuration Value Monitored XenServers

Sustained Usage 1 minute (default)

Network Usage Alerts

Network Threshold 100 Bytes/second (default)

Sustained Usage 1 minute (default)

10.8 Custom Fields, Searching and Tagging

XenCenter supports the creation of tags and custom fields, which allows for organization and quick searching of VMs, storage, network and other objects. XenCenter supports the creation of customized searches. Searches can be exported and imported, and the results of a search can be displayed in the navigation pane. The following section defines the customer fields and searches that will be implemented on XenCenter.

Add list of custom fields here…

10.9 Software Updates

XenCenter is configured by default to periodically check for XenServer updates. The automatic update searches out and allows you to download new versions and patches for XenServer and XenCenter. Updates to the XenServer product family, including critical updates, hotfixes, and security updates can be downloaded automatically and quickly deployed to specific pools or servers.

Configuration Value

Check for new versions of XenServer Enabled

Check for XenServer updates Enabled

Check for new XenCenter versions Enabled

- 33 -

11. Backup and RecoveryThis section describes the backup and recovery requirements for the XenServer environment including XenServer host backup, Resource Pool requirements, snapshotting, and guest virtual machine metadata. Backup and recovery procedures and technologies implemented are also defined to ensure the XenServer environment is protected.

11.1 Description

XenServer Host Backup. The XenServer host configuration data specific to the host is required for a stand-alone server recovery process.

Resource Pool Backup. A backup of pool meta-data using command line tools is possible; however this is a manual process. Individual storage repositories can be restored to new pools if portable SR’s are used, this process can be automated.

Exporting/Importing Virtual Machines. A complete copy of a virtual machine including disk images can be stored in a single file for backup or for migration purposes, with a .xva file extension

Portable Storage Repository. A Portable SR is a Local, NFS, FC or ISCSI based storage repository which contains all of the information necessary to recreate all the guest virtual machines with Virtual Disk Image (VDIs) in the XenServer environment.

Virtual Machine Backup. Although Virtual Machine virtual disk (VDI) data and configuration meta-data can be backed up as part of a XenServer backup process, the application data on each guest also needs to be backed up. Traditional backup practices can be followed for each virtual workload but the impact of backing up multiple workloads on a single standalone host needs to be quantified.


Backup Software

Symantec NetBackup version….

Backup Media Used

Backup to Disk then to Tape

Frequency XenServer Host Backup

Monthly

Frequency of Pool Data Backup

Weekly

Frequency of VM Backups

Weekly

Frequency of Data Backups

File data is backed up using Agent based backups using tape media

File Server for VM Export

FNP01.domain

File Share for VM Exports

\\FNP01\VMExport

SAN Replication FC backed LUNS

- 34 -


are replicated using EMC SRM

VM Cloning or Snapshotting

Crash consistent backups of VMs using SAN level cloning is performed

Frequency of Data Restorations

Every 3 months

Disaster Recovery Plan

No DR plan at this stage

Hardware Support

HP 24/7 Support Agreement

11.3 XenServer Host Backup

The section below details the configuration details of the XenServer backup and associated schedule.

Configuration Value

Backup Server

Backup File path

Backup Frequency

11.4 Virtual Machine Metadata Backup

XenServer hosts use a per-host database to store metadata about VMs and associated resources such as storage and networking. When combined with storage repositories, this database forms the complete view of all VMs available across the pool. When a metadata backup is first taken, a special backup VDI is created on a SR. This VDI has an ext3 file-system which stores the following versioned backups:

A full pool-database backup.

Individual VM metadata backups, partitioned by the SRs in which the VM has disks.

SR-level metadata which can be used to recreate the SR description when the storage is reattached.

Configuration Value

Backup Schedule DailyWeeklyMonthlyNever

Backup Storage Repository Location Local StorageShared Storage

- 35 -

Configuration Value

Portable Storage Repository LocalNFSiSCSIFC

VDI_Backup_SR

Portable Storage Repository Type iSCSI LUN at 100GB replicated to DR site

Protected Virtual Machines All VMs

11.5 Virtual Machine Backup

The section below defines the backup configuration for Virtual Machines and the file data residing within the guest operating systems.

Configuration Value

File Data Backup Type Synthetic full agent based backup using Symantec NetBackup Client

Full Virtual Machine Backup Crash-consistent VM snapshot using…

Virtual Machine Snapshots NetApp FAS3020 snapshotting at the array level

Backup Vendor Symantec for file-based backupsNetApp for VM snapshots

Backup Schedule Weekly

Protected Virtual Machines All VMs are backed up of a regular basis

11.6 Virtual Machine Snapshots

XenServer 5.0.0 provides a convenient snapshotting mechanism that can take a snapshot of a VM's storage and metadata at a given time provided the underlying Virtual Disk Image Storage Repository is based on NFS, NetApp or Dell EqualLogic storage. There are tow type of snapshots which can be used:

Regular Snapshots. These snapshots are crash consistent and can be performed on all types of VMs including Linux

Quiesced Snapshots. These snapshots take advantage of the Windows Volume Shadow Service (VSS) for services that support it to allow the application to flush data to disk prior to taking a snapshot. As a requirement, the Citrix Tools for Virtual Machines need to be installed on the VM.

- 36 -


Only applicable if the storage supports it. i.e. NFS, NetApp or EqualLogic

Configuration Value

Storage Repository Type NFSNetAppEqualLogic

Citrix Tools for VMs Installed on all guest VMs

VM Operating System Types Windows Exchange 2003

Microsoft VSS Supported by guest application

Number of snapshot to maintain 7 daily rotating snapshots with 1 weekly snapshot

11.7 Disaster Recovery

Provide details of the DR plan if it exists. Elaborate on how the backup and recovery process would be conducted including but not limited to the following items:

Portable SRs for full VM metadata and pool copy combined with VDI backup

Export and Import of VMs as a DR plan

SAN replication to DR site – how is this replicated, replication schedules, length of replication, RPO and RTOs, which LUNs are replicated

DR Recovery process – defines the step-by-step recovery scenario

DR testing procedures

- 37 -

Virtual Machines

- 38 -

12. Virtual Machine DesignThe Virtual Machine section defines the guest virtual machines which will be hosted in the XenServer infrastructure. Within this section, characteristics of the virtual machines, including virtual hardware configuration, template configuration, home server settings, high availability protection levels and P2V methodology are discussed.

12.1 Description

Guest virtual machine configuration from a CPU, memory, disk and network perspective should be correctly sized in line with the existing standard operating environment, intended machine usage, and operating system requirements. Virtual machine templates can facilitate rapid deployment of new guests by leveraging predefined and optimized settings.


Type of VMs Hosted

Desktop and Servers

Total Number of VMs

120 VMs in total

VM Operating Systems

Windows XP Pro SP2 and SP3 Windows 2003 R2

No Linux VMs installed

VM Deployment Strategy

Installed using ISO then converted to a template

VM Guest Operating System Initialization

Microsoft SysPrep

Virtual CPU Configuration

All VMs will have default vCPU priority settings

Virtual Memory Configuration

512MB for Desktops

1024MB for Servers

VM Optimization Setting

All VMs will have general Use optimization settings. No XenApp servers deployed.

- 39 -


Boot Order All VMs will default boot from DVDROM.

The following desktop VMs will be streamed with PVS and will default boot from Network….

Virtual NIC Configuration

Virtual Disk Image Configuration

Home Server Setting

HA Protection Configuration

Configured Virtual Machine Templates

Default NTP Server

Sync all VM time with DC1.domain.local

Alert Configuration

Desktop VMs will be configured with CPU….Network….Disk…..

Server VMs will be configured with…..

P2V (Physical-to-Virtual) Conversion Tools

Citrix XenConvertPlateSpin PowerConvert

Machines identified for P2V Migration

The following servers will be P2V migrated:

APP01APP02

12.3 Design

The XenServer infrastructure will support up to…..

All VMs will be based on Windows…..

The default VM configuration is based on …..

- 40 -

HA protection levels for desktops and servers …..

Alerts settings will be……

12.4 Virtual Machine Configuration

The table below illustrates the default virtual machine configuration.

Configuration Item Desktops Servers

Number of vCPUs 1 1

vMemory 512MB 1024MB

Number of vNICs 1 1

Virtual Disk Size 10GB 40GB

DVDROM Empty Empty

Host Network prod_lan prod_lan

NTP Server DC1.domain.local DC1.domain.local

Operating System Windows XP Pro Windows Server 2003 R2

Citrix Tools for Virtual Machines

Installed Installed

Microsoft VSS Driver Enabled

No Yes

12.5 Virtual Machine Templates

A template is a virtual machine encapsulated into a file. Each template contains installation metadata and the setup information needed to create a new VM with a specific guest operating system, and with the optimum storage, CPU, memory and virtual network configuration. Templates make it possible to rapidly deploy new virtual machines in XenCenter. The following section details the configuration settings of the templates that will be implemented in the XenServer environment.

Hardware Template 1 Template 2 Template n

General

Name GoldXPDesktop

Description Template XP

Operating System XP Pro SP3

Application Installed Office 2003

Function Desktop SOE

XenServer Tools Installed Yes

Virtual Storage

CD/DVD-ROM Disabled

Virtual Disk Name XP1

Virtual Disk Size 10GB

Virtual Network Interfaces

Number of Virtual NICs 1

Host Network prod_lan

IP Settings DHCP

Network Limit NA

- 41 -

Hardware Template 1 Template 2 Template n

Virtual Memory and CPU Settings

Virtual Memory 512MB

Number of Virtual CPUs 1

Virtual CPU Priority NA

Startup Options

Boot Order NetworkDVD-DriveHard Disk

Auto-start VM on server boot No

Alerts Configuration

CPU Usage Alerts

Network Usage Alerts

Disk Usage Alerts

Optimization

Optimization Type General Use

Shadow Memory Multiplier NA

High Availability

HA Protection Level ProtectedPriority 1, 2 or 3Best EffortDo No Restart

Additional Configuration

Customizations

12.6 Virtual Machine HA Configuration

The table below defines the HA protection levels for the guest virtual machines in the XenServer infrastructure.

Resource Pool

HA Protection Level

Protected:Priority 1



Best Effort Do Not Restart

Pool 1 DC1DNS1Exchange1

SQL1WEB1

WEB1APP1

XP1XP2…..etc

Al other servers

Pool 2

Pool 3

12.7 Workload Migration Process

The Workload Conversion is the process by which an existing operating system on a physical or virtual machine - its file system, configuration is cast into a virtualized instance of the same operating system and file system, transferred, instantiated, and started as a VM on the XenServer Host.

- 42 -

There are many methods which can be employed to perform a workload migration; these are detailed as follows:

Manual Migration. This migration type would typically be used if there were very few migrations to be performed, making the purchase or use of an automated migration tool unnecessary. This option might also be taken for advanced migrations of physical workloads with complex requirements such as bespoke option cards, peripherals or extremely complex storage requirements.

Advantages:

o Optimization. Workloads are ‘refreshed’. All unnecessary application data (temporary files and log files etc) is removed, workload is optimized.

o Rationalization. This can be taken as an opportunity to rationalize and simplify the workload configuration, such as disk structure and storage requirements.

Disadvantages:

o Speed. A manual process is very time consuming and best suited to small or complex migrations.

o Consistency. For a large number of migrations, maintaining consistency can be challenging when migration tasks are managed manually.

o Reliability. Inconsistent or badly managed migrations can cause application inconsistency and reliability issues following the migration.

Physical to Virtual (P2V). Physical to Virtual migrations are typically undertaken using bespoke migration tools which integrate closely with the virtualization platform to deliver fast and consistent results.

Advantages:

o Speed. Once the parameters for the migration are supplied it proceeds automatically. Many P2V migrations can be performed in the time it would take to complete a single manual migration. For large scale migrations, a P2V process is the only rational option.

o Integration. Most P2V tools integrate closely with the virtualization platform being used ensuring that virtual workload optimizations, such as the installation of relevant paravirtualization tools, forms part of the migration process.

o Consistency. As P2V migrations are parameter based, similar servers will always be built consistently.

Disadvantages:

o Toolset. A P2V tool must be identified, tested and selected. The tool must support the virtualization platform being used and be capable of handling the majority of the physical workloads to be migrated. All relevant staff must be trained in the use of the new toolset.

o Consistency. Unless closely managed, subtle problems can be quickly introduced into large numbers of newly migrated workload. Application owners must be involved in the migration process to be sure that such changes are identified before each workload is released into production.

Physical to Physical (P2P). Where P2V tools do not exist or do not work for the current virtualization platform, a Physical to Physical, or P2P migration can be ‘emulated’ to achieve a similar result. For example, a virtual server is created which is used to emulate

- 43 -

the destination physical server, the migration is then performed as though both source and destination hosts are physical.

Advantages:

o Speed/Consistency/Repeatability. Most of the advantages are similar to a P2V migration.

Disadvantages:

o Integration. As the destination host is perceived to be a physical server, none of the optimizations are performed which would normally be done on a destination host which is a virtual machine.

The key to a successful migration strategy is in understanding in fine detail the physical estate which needs to be migrated, as detailed above. Once the requirements of the workloads are understood it is easier to identify the best toolset and process to use migrating each environment.

If a third party toolset is to be used, time should be invested in analyzing and understanding that it meets a large percentage of the migration requirements of the physical infrastructure.

[Describe the P2V process and how each of the VMs targeted for P2V will be migrated using the P2V tool specified ….]

- 44 -

13. Workload MatrixThis section details the planned desktop and server workloads that will be hosted as guest virtual machine on the XenServer infrastructure. Information gathered as a result of the Citrix Server Virtualization Assessment, if it was conducted, will also be discussed.

13.1 Description

Individual server capacity and aggregated Resource Pool capacity with respect to virtual machine utilisation should be considered as part of the hosting infrastructure design to ensure the environment and servers are not overcommitted. This is critical in maintaining an acceptable level of end user experience and virtual machine performance. In any cases, additional server resource should be deployed as best practice to provide as buffer for unexpected utilisation peaks or server failures.


Expected VM capacity

120 VMs

Number of Guest Desktop VMs

80 desktop VMs

Number of Guest Server VMs

40 server VMs

Citrix SVA Conducted

No

Expected Host Utilisation

60% CPU and Memory utilisation

Acceptable Number of Host Failures

Up to 2 XenServer host failures can be sustained

XenServer Scalability Model

Scale-out. Additional hosts will be added to the pool to increase VM density.

13.3 Citrix Server Virtualization Assessment (SVA)

The SVA results indicate the following ……

Based on the SVA results, a total of X XenServers will be required to support y number of VMs

The infrastructure is capable of sustaining two XenServer failures…..

- 45 -


If the SVA was conducted as part of the Analysis Phase, include the results here and elaborate on the expected capacity ….etc

13.4 Desktop Workload

The following table is the expected virtual desktop and virtual server workload that will be hosted on the XenServer Resource Pool consisting of XenServers based on SERVER HARDWARE MODEL servers.

Resource Pool Name

XenServerHost

Resource Pool Role

Type of Guest VMs

# Guest VMs

Guest VMs Comments

- 46 -

Security

- 47 -

14. SecurityThis section discusses the security related aspects of the XenServer design. Physical server security, along with encryption and enclave networking are analyzed.

14.1 Description

Corporate security policy should already provide guidelines which dictate how each tier of the XenServer architecture is secured. The design process should follow these corporate guidelines and make recommendations regarding how the XenServer design can meet these security requirements.

The following topics are considered during the design process:

Physical Server Security. Citrix XenServers should be deployed in a secure location where only controlled access is permitted. As each XenServer will typically host several virtual workloads, compromise of a single system can result in outage for many business systems.

Hypervisor Security. The XenServer hypervisor is not generally prone to attack. If the servers are deployed on internal networks, there is very little likelihood of compromise at this level.

Dom0 Password. Dom0 is the first VM created on every XenServer and enables management of all other VM’s. Dom0 passwords should be secured at the highest level, as the root account and password, or equivalent root level accounts, must be used for both console and XenServer access

XenCenter. XenCenter is used to manage most aspects of a XenServer deployment. Restricting access to the Dom0 password will reduce the risk of unauthorized personnel from running and connecting via the XenCenter console. By default XenCenter uses SSL to encrypt all communications with each resource pool.

Virtual Machine Security. Security of virtual workloads can be implemented using traditional methods such as leveraging the security features of Active Directory and using standard anti-virus, anti-spyware and firewall software.

Storage Security. Security for storage should be given serious thought as compromise of a storage repository could result in the corruption or deletion of its contents and the subsequent failure of all virtual workloads which share the SR.


Physical Server Security

All servers will be located in a secure data centre with restricted access.

Resource Pool (Dom0) passwords

Root password for all servers will be given only to support personnel with specific requirements.

- 48 -


Storage Security CompanyABC will use FC-SAN shared storage and will use standard zoning and masking to provide basic security.

Virtual Machine Security

All virtual workloads are Windows servers which are AD domain members.

XenCenter No restrictions will be placed on access to XenCenter

14.3 Design

- 49 -

Appendices

- 50 -

15. Appendix A: XenServer Networking ExplainedThis section details the XenServer Networking and provides insights into each network type that can be used in a XenServer implementation.

15.1 Internal Networks

The simplest network configuration is an internal network. No PIF is required as there is no logical connection to a physical network adapter and therefore no external connectivity. This network is only available to a single XenServer host and cannot be assigned to other pooled hosts. VM’s which are connected to internal only networks cannot be migrated between pooled hosts. VM’s on a common XenServer can share this type of network in order to isolate specific traffic.

15.2 External Networks

The creation of an external network which uses a physical adapter will create the necessary PIF’s required. In this example, two VM’s each with their own VIF are attached to the same virtual switch which in turn is logically connected to the PIF, and therefore the physical network adapter:

Here multiple physical network interfaces are present, more complex virtual networking is possible. In this example, two physical network cards are available. One VM makes use of a single virtual network, whilst the other is logically connected to two separate network segments.

- 51 -

15.3 Bonded Interfaces

The next example shows the introduction of a network bond. Two physical network cards which are connected to the same network segment are used to create a bond for resilience and additional throughput. In the example, two VM’s are connected to the same network segment via this bond.

15.4 VLAN’s

Finally, VLAN’s are introduced which subsume the network bond. Separate vSwitches are created for each VLAN and in the following example; three VM’s are logically connected to separate VLAN’s via the same physical network card.

- 52 -

15.5 Virtual Network Combinations

Many combinations of the above examples are possible in order to achieve a configuration which meets with the requirements of the design.

This example shows a XenServer with 3 NIC’s, eth0 and eth1 are bonded for resilience and this bonded network is used by 5 virtual machines, three of them attach to different VLAN’s which leverage the bond for resilience and a further two attach directly to the bond itself.

A third NIC, seen by XenServer as eth2 provides a non-resilient network which is used by a fifth, single virtual machine.

- 53 -

Citrix_XenServer_5_Design_Template

Documents

design template

design summary

architectural design

design concerns

design insert date

resource pool design

variable fields

update fields