Transcript
<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.email@email.com
Staff ConsultantTitleAddressTel:Mobile: Email.email@email.com
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 -
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
4.2 Key DecisionsDecision Point Design Decision Justification
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.
Configuration Option Value
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.
Configuration Option Value
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 -
Configuration Option Value
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.
5.2 Key DecisionsDecision Point Design Decision Justification
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 -
Decision Point Design Decision Justification
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.
Configuration Option Value
Resource Pool Name
Resource Pool Master Server
Resource Pool Member Servers
- 12 -
Configuration Option Value
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
Explanation Description
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 -
6.3 Key DecisionsDecision Point Design Decision Justification
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 -
Decision Point Design Decision Justification
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]
Configuration Option Value
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]
Configuration Option Value
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
Configuration Option Value
Storage Repository Type NFS
Storage Repository Size
Hosts Attached
Storage Repository Name
NFS Path
Advanced Options
NFS Storage Vendor
NFS Storage Model
Configuration Option Value
Storage Repository Type iSCSI
Storage Repository Size
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
Configuration Option Value
Storage Repository Type NetApp
Storage Repository Size
Hosts Attached
- 18 -
Configuration Option Value
SR Name
NetApp Filer IP Address
Username
Password
CHAP Enabled Yes/NoCHAP UserCHAP Secret
Number of FlexVols in SR 8 (default)
Aggregate
FAS Thin Provisioning EnabledDisabled
FAS Deduplicaton EnabledDisabled
Dynamic Multipathing EnabledDisabled
Number of Paths
FAS Model NetApp FAS3020c
Ontap Version 7.2.2
FAS Storage Capacity
Configuration Option Value
Storage Repository Type Hardware HBA
Storage Repository Size
Hosts Attached
SR Name
HBA Type FCiSCSI
HBA Vendor
HBA Model
Password
CHAP Enabled Yes/NoCHAP UserCHAP Secret
Number of FlexVols
FAS Thin Provisioning EnabledDisabled
FAS Deduplicaton EnabledDisabled
Dynamic Multipathing EnabledDisabled
Number of Paths
Configuration Option Value
Storage Repository Type Dell EqualLogic
- 19 -
Configuration Option Value
Storage Repository Size
Hosts Attached
SR Name
Dell EqualLogic Filer IP Address
Username
Password
CHAP Enabled Yes/NoCHAP UserCHAP Secret
Storage Pool Name
Thin Provisioning EnabledDisabled
Dynamic Multipathing 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.
Configuration Option Value
Storage Repository Type CIFS
Storage Repository Size
Name
Share Name
CIFS Authentication
User name
Password
Advanced Options
Available ISO files
Configuration Option Value
Storage Repository Type NFS
Storage Repository Size
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
Explanation Description
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 -
7.3 Key DecisionsDecision Point Design Decision Justification
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
Intel 8254 Gigabit Adapter
NIC2 prod_lan Yes 1Gigabit/Full-Duplex
Intel 8254 Gigabit Adapter
NIC3 prod_lan Yes 1Gigabit/Full-Duplex
Intel 8254 Gigabit Adapter
[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.
8.2 Key DecisionsDecision Point Design Decision Justification
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 -
Decision Point Design Decision Justification
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.
9.2 Key DecisionsDecision Point Design Decision Justification
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.
10.2 Key DecisionsDecision Point Design Decision Justification
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 -
Decision Point Design Decision Justification
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 xenalert@domain.com
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.
11.2 Key DecisionsDecision Point Design Decision Justification
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 -
Decision Point Design Decision Justification
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 -
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.
12.2 Key DecisionsDecision Point Design Decision Justification
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 -
Decision Point Design Decision Justification
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
Protected:Priority 2
Protected:Priority 3
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.
13.2 Key DecisionsDecision Point Design Decision Justification
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 -
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.
14.2 Key DecisionsDecision Point Design Decision Justification
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 -
Decision Point Design Decision Justification
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 -