In a XenServer-only implementation,
virtual disk files for each virtual machine are stored in a storage location.
Organizations with a significant number of virtual machines incur an increase
in storage cost, as well as maintenance costs.
Provisioning Services complements
XenServer by providing simplified virtual machine management and reduced
storage requirements. Provisioning Services allows an engineer to create one
standard virtual machine image that is stored and updated. This standard image
is streamed to server or desktop target devices. Resource mappings stored on a Provisioning
Services server identify which virtual machine images are assigned to each
target device. Workloads can easily be repurposed by updating a vDisk mapping
and rebooting the target device.
Provisioning Services vDisk changes
can be stored in a cache file. Storing changes for each target device that
shares a common virtual machine image requires far less storage space than
individual virtual machine files in an environment that utilizes server or
desktop provisioning.
Traditional
Disk Architecture
In a traditional disk architecture,
input, such as key strokes or mouse clicks, is passed to the server and is
stored on the server RAM. The processor requests instructions from the hard
disk controller; these are then passed to the hard disk. The hard disk finds
the requested data then passes it to the hard disk controller which then passes
it back to the RAM. The RAM sends the data and instructions to the processor
where it is processed into output that is sent to the user in the form of
screen updates
Provisioning
Services Disk Architecture
In a Provisioning Services architecture, input,
such as keystrokes or mouse clicks, is passed to the target device and is
stored in the server RAM. Unlike a traditional disk architecture, the request
for instructions from the hard drive is sent to the NIC on the target device.
The request is then sent to the hard disk controller, which in this case is the
Provisioning Services server. The Provisioning Services server then locates the
appropriate hard disk for that target device from a storage device and forwards
the data request. The correct data is found on the hard disk, sent back to the
Provisioning Services server, and then sent back to the NIC on the target
device. That data is sent back to the RAM, then processed into output in the
form of screen updates
Provisioning
Services Farm Layout
Although a Provisioning Services
farm layout can vary based on individual organization requirements, a farm
always consists of a grouping of Provisioning Services servers, target devices
and vDisks that are connected to the same database and license server.
Provisioning Services servers maintain constant database connectivity to stream
vDisks to target devices; therefore the database should be located in physical proximity
to the Provisioning Services servers to minimize latency and ensure optimal
target device performance.
The database can be placed on a LAN
or WAN as long as all Provisioning Services servers can access it. However,
streaming vDisks to target devices requires a robust data link between all
Provisioning Services servers and target devices in a farm, such as a LAN, to
ensure optimal performance.
Traffic
Isolation
When possible, vDisk streaming
traffic should be isolated from normal production network traffic, such as
Internet browsing, printing and file sharing. It is best to use multiple NICs—a
single NIC for PXE traffic and bonded NICs for streaming the vDisks to target
devices. This separation provides more consistent performance to the streamed
operating systems and also prevents conflicts between the streaming traffic and
the production network traffic.
Configuring
NICs to Separate Stream Service from LAN Traffic
An engineer can use the following
procedure to connect separate NICs to a PXE network and a LAN.
- Verify that the network interfaces are on isolated
subnets so that the PXE and LAN traffic are routed separately and do not
conflict with each other.
- Run the Provisioning Services Configuration Wizard to
bind the Stream Service to the network interface that will be used for
vDisk streaming.
- Specify the network interface that will be used for the
PXE services from the Provisioning Services server
NIC
Teaming
Network I/O on the Provisioning
Services server can be a limiting factor in server scalability. Teaming two
NICs for throughput provides the server with a maximum of 2Gb of network I/O,
which increases the network performance and helps alleviate a potential
bottleneck.
Additionally, teaming the NICs
eliminates a single point of failure, which occurs when only one NIC is
available.
The following NIC teaming
considerations should be taken into account:
- Provisioning Services supports Broadcom and Intel NIC
teaming drivers.
- A target device will only failover to Provisioning
Services servers that are in the same subnet as the PXE boot server.
- Load balancing is not supported in NIC teaming
implementations.
This must
be taken into account for large scale Provisioning Services implementations.
For a virtualized Provisioning
Services server, it is recommended to create a NIC bond at the host server
level to mitigate the load balancing limitation and decrease the complexity of
the Provisioning Services configuration because the NIC teaming requirements do
not have to be met on the virtual machine.
Write
Cache Location
A vDisk write cache can be stored in
any of the following locations:
- Target device RAM
- Target device local storage
- Target device shared storage
- Provisioning Services local storage
- Provisioning Services shared storage
The decision for where to place the
target device write cache will impact server and target device performance,
server scalability and overall cost. The following descriptions provide
benefits and considerations for each write cache location that can help
engineers determine the most appropriate location for it in the environment
Target
Device RAM
Selecting this write cache location
sets aside a portion of the RAM on the target device for the write cache.
|
Benefits
|
Considerations
|
|
Fastest type of write cache
|
|
Target
Device Local Storage
Selecting this write cache location
dedicates a portion of the target device local storage for the write cache. The
local storage can be either a physical or virtual disk drive.
|
Benefits
|
Considerations
|
|
|
Target
Device Shared Storage
Selecting this write cache location
places the write cache on a shared storage device attached to the target
device. This write cache type is usually only valid in environments that use
virtual target devices, such as Citrix XenServer. The storage is assigned to
each virtual machine from a shared storage repository.
|
Benefits
|
Considerations
|
|
|
Provisioning
Services Local Storage
Selecting this write cache location
stores the write cache on the physical disks on the Provisioning Services
server.
|
Benefits
|
Considerations
|
|
|
Provisioning
Services Shared Storage
Selecting this write cache location
places the write cache on a shared storage solution that is connected to the
Provisioning Services server.
|
Benefits
|
Considerations
|
|
|
