Branch Repeater VPX Best Practice and Deployment Guide-V1.3

BR VPX Deployment Guide | Citrix BR & AG Marketing
Branch Repeater VPX

Best Practice and
Deployment Guide
Citrix Security & Acceleration Group
www.citrix.com
Citrix Systems, Inc. © 2011 Confidential Page i of 33

Branch Repeater VPX Deployment Guide
Document revision history
Version Date Author Comments

1.0 Feb-10-11 Andreas Zindel Initial Document Creation
1.1 Mar-28-11 Andreas Zindel Incorporated Feedback
1.3 April-17-11 Andreas Zindel Finalized Document
Contents
1. Introduction .......................................................................................................................................................2
2. VPX systems requirements ..............................................................................................................................3
3. Considerations and Best Practices ...................................................................................................................5

3.1. When to use VPX ........................................................................................................................................................... 5
3.2. When to use hardware appliances ................................................................................................................................ 5
3.3. Mapping Branch Repeater network interfaces considerations ..................................................................................... 6
3.4. Determining how many Virtual Machines per server .................................................................................................. 10
3.5. Workload Balancing .................................................................................................................................................... 10
3.6. XenMotion Requirements and Live Migration............................................................................................................. 10
3.7. vMotion Requirements and Live Migration ................................................................................................................. 11
3.8. Hypervisor Shared Storage .......................................................................................................................................... 12
3.9. High Availability .......................................................................................................................................................... 13
3.10. Network redundancy ............................................................................................................................................... 14
3.11. How to setup within established VMware environments ........................................................................................ 15
4. Use cases .......................................................................................................................................................17

4.1. Accelerated datacenter servers ................................................................................................................................... 17
4.2. Branch‐office accelerator ............................................................................................................................................ 17
4.3. VPN accelerator ........................................................................................................................................................... 18
4.4. Accelerate ICA Proxy Mode in Citrix Access Gateway ................................................................................................. 18
4.5. Accelerated branch‐office server ................................................................................................................................. 19
4.6. Multiple Branch Repeater VPX Instances .................................................................................................................... 19
5. Step by step configuration guide ....................................................................................................................20

5.1. Management ............................................................................................................................................................... 20
5.2. HA ................................................................................................................................................................................ 31
1. Introduction
IT departments at enterprises of all sizes always remain concerned with the topic of ensuring acceptable
application delivery to branch office and mobile employees. A decade ago, they were satisfied with any solution
in any form, fit and function that met their needs and allowed them to check that box next to application
acceleration for all. That was then. Fast forward to today where application acceleration for all is given. The
quest is to make it more flexible than an acrobat, more standard than a school uniform, more elastic than a
rubber band and at a price points that keep concerned business units smiling all the way.

Today, enterprises of all sizes are clamoring to standardize user experience and improve productivity across their
employee pool by delivering applications via exciting technologies like Citrix XenDesktop and Citrix XenApp no
matter where these employees are – in branch offices, in regional offices or even on the road. Their IT
departments are building private clouds to deliver metered IT services to business units within enterprises. On
the other side, service providers such as Amazon and Microsoft are eager to satisfy unmet needs of enterprises
by building public cloud infrastructures. Especially for SMB segment, these service providers are their only IT
departments. It is a tall order for enterprises and service providers to pull these off without sacrificing flexibility,
standardization, elasticity and the cost advantage that they have come to expect of this age.

Broadly speaking, WAN Optimization controllers (WOC) are the linchpin of application delivery infrastructure in
scenarios such as but not limited to datacenter to branches, private cloud of an enterprise, service provider
operated public cloud or a hybrid cloud that connects both – enterprises and cloud providers.

While Citrix Branch Repeater appliance offers robust WAN Optimization solution, Citrix Branch Repeater VPX
takes the center stage when flexibility, standardization, elasticity and cost advantage is of paramount
importance.

Citrix Branch Repeater (BR) VPX is a virtualized software product that delivers the same features as the Repeater
85xx series hardware appliances, with a few caveats that are detailed within this document. BR VPX can be
deployed in any datacenter (either on‐premise or hosted by a service provider) that allows access to the
hypervisor. As a virtual machine, Branch Repeater VPX can be deployed exactly where and when you need it, and
can be combined with other virtual machines such as servers, security units, other networking devices or other
virtual appliances, to create a virtualized server unit that suits your business and IT needs.

For the purpose of this document, acceleration works on TCP/IP connections and packets that pass through any
supported combination of two acceleration units:
• Any combination of Repeater hardware, Branch Repeater hardware, and Branch Repeater VPX appliances
• One Repeater hardware appliance and one Repeater Plug‐in.
• One Branch Repeater VPX appliance and one Repeater Plug‐in.
• Traffic in both directions must pass through both acceleration units.

Once these criteria are met, acceleration is automatic.

A successful deployment of Branch Repeater VPX is neither elaborate nor difficult; the purpose of this document
is to provide some guidance on best practices for deploying Branch Repeater VPX ensuring successful
deployments that accelerate and optimize network traffic as expected.
Please note that improper deployments may cause network‐ (and/or bandwidth‐) related issues and may also
result in inadequate acceleration. Follow the guidelines in this document for the best possible results. While the
document provides some configuration steps, this is not an end‐to‐end training guide. The document assumes
that the reader has a basic understanding of Repeater concepts, technology and terminology. For additional
information, please refer to the Branch Repeater Administrator guide, which is available on Citrix Support Site in
the Branch Repeater Product Section. http://support.citrix.com/product/brrepeat
Citrix Systems, Inc. © 2011 Page 2 of 33

2. VPX systems requirements

Branch Repeater: Virtual Appliances
Trial
Branch Repeater VPX2
Version1
VPX VPX 45 VPX 45
Model VPX 2 VPX 10
Express 4GB RAM 8GB RAM
Max WAN Speed 512Kbps 2Mbps 10Mbps 45 Mbps 45 Mbps
Max Accelerated Connections 10 1000 10000 15000 25000
Max Repeater Plugins 5 50 250 400 500
Minimum System Requirements (per VM)
XenServer 5.6 or later
Hypervisor
VMware vSphere vSphere
Dual Core Intel or AMD 64-bit x86 (Citrix XenServer)
Processor
Dual Core Intel VTx or AMD-V 64-bit x86 (VMware vSphere)
Memory 2 GB 2 GB 4 GB 4 GB 8 GB
Hard drive 60 GB 100 GB 250 GB 250 GB 500 GB
Network interface 2 virtual NICs
1 for Citrix XenServer 2 for Citrix XenServer
Virtual CPUs
2 for VMware vSphere 2 for VMware vSphere
1
VPX Express is a 12 month free trial license that includes 5 Repeater Plug-in licenses and limits usage to 10
accelerated connections
2
The maximum number of accelerated connections and Repeater Plug-ins depends on the resources allocated to
the VPX. For more details refer to product documentation at MyCitrix (www.mycitrix.com)
Table 1

Branch Repeater VPX runs under XenServer 5.5 and vSphere 4.1. As depicted in the table above Branch Repeater
VPX supports only the following configurations.
1,4 or 8 GB of RAM, 60, 100, 250 or 500 GB of disk, and 1‐2 virtual CPUs. The intermediate, 4 GB RAM/250 GB
disk configuration is similar to the Repeater 8500 Series.
Repeater VPX does not require hardware virtualization support in the CPU (though this is desirable).
Minimum Resources:
 XenServer 5.5 or vSphere 4.1
 1 CPU
 1 GB RAM
 60 GB disk (local disks will give maximum performance)
 2 virtual NICs (Ethernet ports)
Maximum Resources:
The maximum resources that a single Branch Repeater VPX VM can use effectively:
 2 CPUs
 8 GB RAM
 500 GB disk
 4 virtual NICs


The absolute minimum (60 GB disk) configuration is not for production environments, but can be useful for ad
hoc testing and demonstrations on machines with inadequate resources. The minimum system requirements for
production systems can be found in table 1.
The server hosting Branch Repeater VPX needs resources greater than or equal to these, with the exception of
Ethernet ports. Possible Ethernet options include:

1. Mapping Branch Repeater VPX’s two virtual ports to two physical ports, rendering its operation equivalent to
a stand‐alone branch repeater inline.

2. Mapping one of Branch Repeater VPX’s virtual ports to a physical port, and the other to a virtual network
containing one or more virtual machines on the same server, thus creating an accelerated server.

3. Mapping each of Branch Repeater VPX’s virtual ports to a virtual network, thus chaining Branch Repeater
VPX between two sets of virtual machines on the same server.

3. Considerations and Best Practices

There is no “one size shoe fits all” answer to the everlasting question “When should I use a purpose built
hardware appliance and when could (or should) I use a virtual appliance?” This section highlights some
considerations when deciding whether to use a hardware appliance or VPX as well as some information specific
to deploying VPX.
3.1. When to use VPX

Flexibility
 Dynamically provision or de‐provision VPX instances
 Deploy VPX on shared servers with other VM workloads
 Deploy in minutes without changes to network topology
 Deploy in remote offices without locally present IT staff (assuming the target server hardware is
connected and available)
Server standardization
 Standardize on preferred server vendor’s platforms
 Manage using preferred server or hypervisor management tools
Elasticity & Agility

 Build hybrid or private cloud datacenters
Low cost
 Leverage low‐priced virtual appliances for branch offices with <45Mbps
3.2. When to use hardware appliances

Simplicity
 Dedicated hardware for WAN Optimization Controller (WOC) in branches or datacenters
 Don’t want to disrupt an existing shared virtualized server for deploying BR VPX
 In general, managing a virtual server (hardware + hypervisor + VPX) is more complex than managing a
purpose‐built physical appliance
Scalability
 Datacenters aggregating traffic from multiple branches generally require more than 45 Mbps
 Branches or datacenters with >45Mbps WAN links exceed the maximum throughput for BR VPX
 Receiver plug‐in exceed the maximum connections of 500 users for BR VPX
Availability
 Hardware appliances have built‐in HA and Fail‐to‐Wire for business continuity in branches or datacenters
Predictability
 Purpose‐built hardware appliances provide more consistency than VPX. The predictability of VPX
performance depends on other factors including server sizing & resources (especially disk subsystem
performance) when sharing them with other VM workloads. Physical appliances may be highly desirable
where WOC Service Level Agreements (SLAs) are extremely important.
Branch IT Consolidation
 Use Branch Repeater with Windows Server (CBRwWS) hardware appliances to consolidate or eliminate
branch servers but maintain critical Windows services (file, print, etc.) in branches
 Managed CBRwWS appliances using familiar Microsoft SCCM/SCOM

3.3. Mapping Branch Repeater network interfaces considerations

This section describes considerations when mapping the Branch Repeaters network interfaces to physical
network cards or virtual network interfaces on the Hypervisor.
NOTE: The Branch Repeater will use the first two virtual network adapters on the hypervisor as accelerated pair
and any other virtual network adapters can be configured during the import process
3.3.1. Enabling Promiscuous Mode

When the Branch Repeater VPX’s virtual port is mapped to a virtual network interface on VMware vSphere
server you must enable Promiscuous Mode on the VMware vSphere server’s virtual interface or no traffic will
pass through the Branch Repeater.
1. Go to the vSphere server’s Network Configuration

2. Click on Properties for the virtual interface to which the Branch Repeater is connected

3. Select the vSwitch and click on Edit


4. Under the Security tab select Accept from the Promiscuous Mode dropdown menu

5. Click OK until all dialog windows are closed

3.3.2. Avoiding Network Loops

When uploading / importing two Branch Repeater VPX instances onto the same server make sure that one of the
virtual NIC’s on the second Branch Repeater is either not bonded to an interface at all or is bonded to a different
interface. If both virtual interfaces on both Branch Repeater VPX instances are bonded to the same interfaces on
the server a network loop is created when the second VM is powered on and no traffic will flow through the
network i.e. this will BREAK the network).
NOTE: Please see the High Availability chapter of this document for more details on how to avoid this problem.

Before enabling the bridging, please make sure to assign the two Branch Repeater bridge ports (accelerated pair
ports) to different virtual and physical Ethernet segments. Only when the Bridging is enabled can packets pass
through the BR VPX for acceleration.


3.3.3. Fail to wire workaround

With Branch Repeater VPX the bypass card (fail‐to‐wire feature) is not an option. To avoid a network outage in
case of hypervisor failure Citrix recommends configuring an alternate connection or bypass option. This is
accomplished by connecting an alternate network cable, bypassing the hypervisor and using Spanning Tree
Protocol or static route priority. In this configuration a parallel network connection bypassing the Branch
Repeater VPX (Hypervisor layer) would be activated if the connection through the Branch Repeater failed. In this
configuration a second network cable would connect the two networks, thus bypassing the hypervisor. With
Spanning Tree Protocol or a static route priority configuration one port of the bypassing connection would be
disabled as long as traffic is flowing through the Branch Repeater VPX. If traffic fails to flow through the Branch
Repeater VPX the blocked port would be activated thus allowing the traffic to bypass the failed hypervisor.

The second option to avoid outage in case of hypervisor failure is to deploy Branch Repeater VPX using WCCP
mode.
WCCP mode is recommended when inline mode is not practical. Supported by most routers, WCCP only requires
three lines of router configuration code. To use WCCP mode on a Cisco router, it should be running at least IOS
version 12.0(11)S or 12.1(3)T.
(WCCP stands for “Web Cache Communications Protocol,” but the protocol was greatly expanded with version
2.0 to support a wide variety of network devices.)


3.3.4. Considerations for connecting XenServer servers to a switch

Switch ports must be configured differently for a XenServer server as opposed to a standard workstation. The
following considerations are recommended when connecting a XenServer‐based virtual server to a switch. Below
are five switch changes for XenServer ports:
1. Enable PortFast on XenServer connected ports
PortFast allows a switch port running Spanning Tree Protocol (STP) to go directly from blocking to
forwarding mode; skipping learning and listening. PortFast should only be enabled on ports connected to
a single server. Port cannot be a trunk port and port must be in access mode. Ports used for storage
should have PortFast enabled.
NOTE: It is important that you enable PortFast with caution, and only on ports that do not connect to
multi‐homed devices such as hubs or switches .
2. Disable Port Security on XenServer connected ports
Port security prevents multiple MACs from being presented to the same port. In a virtual environment,
you see multiple MACs presented from VMs to the same port causing your port to shut down if you have
Port Security enabled.
3. Disable Spanning Tree Protocol on XenServer connected ports
Spanning Tree Protocol should be disabled if you are using Bonded or teamed NICs in a virtual
environment. Because of the nature of Bonds and NIC teaming, Spanning Tree Protocol should be
disabled to avoid failover delay issues when using bonding.
4. Disable BPDU guard on XenServer connected ports
BPDU is a protection setting part of the STP that prevents you from attaching a network device to a switch
port. When you attach a network device the port shuts down and has to be enabled by an administrator.
A PortFast port should never receive configuration BPDUs.
NOTE: When BPDUs are received by a PortFast port, this reception indicates another bridge is somehow
connected to the port, and it means that there is a possibility of a bridging loop forming during the
Listening and Learning phases. In a valid PortFast configuration, configuration BPDUs should never be
received, so Cisco switches support a feature called PortFast BPDU Guard, which is a feature that shuts
down a PortFast‐enabled port in the event a BPDU is received. This feature ensures that a bridging loop
cannot form, because the switch's shutting down the port removes the possibility for a loop forming.
5. It is recommended to always change port speed and duplex settings to static with any switch.


3.4. Determining how many Virtual Machines per server

The hypervisor’s CPU, memory and other hardware components as well as the type and amount of other virtual
machines running on the same hypervisor along with BR VPX may affect the BR VPX’s performance. If you are
running multiple BR VPX appliances on the same hypervisor they will compete for hard disk access time and
other resources. Unfortunately there is no formula to calculate or no rule to apply to figure out the BR VPX’s
performance in the presence of other virtual machines. To gain optimum performance the best practice is to use
a dedicated hypervisor‐based server for BR VPX.

BR VPX performs best with very fast, very low‐latency hard disks. In the case of network disks, which in addition
to BR VPX are accessed by other devices, the performance of BR VPX as well as other devices accessing the
network disks could suffer. To obtain optimum performance Citrix strongly recommends using the virtual server’s
local hard disk. However, one drawback of using local hard disks is that advanced hypervisor features like
migration and failover are unobtainable.
3.5. Workload Balancing

With XenServer Enterprise and Platinum editions BR VPX supports dynamic workload balancing. Dynamic
workload balancing maximizes and optimizes server performance by intelligently placing and rebalancing server
workloads based on user‐defined thresholds. Workload balancing is a XenServer feature and thus outside the
scope of this document. For details on deploying and configuring workload balancing please refer to the Citrix
knowledge base:
CTX127328 ‐‐ Readme for Citrix XenServer Workload Balancing 2.1
CTX127330 ‐‐ Citrix XenServer Workload Balancing Administrator's Guide
CTX127329 ‐‐ Citrix XenServer Workload Balancing Installation Guide
3.6. XenMotion Requirements and Live Migration

XenMotion is a feature of Citrix XenServer Enterprise and Platinum that gives an administrator the ability to
move a running virtual machine (including BR VPX) between two XenServers in the same resource pool. To use
XenMotion, the processors of the two XenServers within the resource pool must be the same type, but can have
slight differences (such as CPU speed). For example, all the systems would need to have Intel Xeon 51xx series
processors. They could be different speeds, so you can mix systems with Xeon 5130 and Xeon 5140 processors.
The same is true of AMD processors that are similar, but you cannot move a virtual machine between AMD and
Intel CPU based systems.
While you do need to have the same type of processor in each system, other components can differ. You can
have different amounts of memory, different storage controllers, and different network controllers in each
system.
All virtual machines must be stored on an external shared storage system such as NFS or iSCSI ideally with a
Gigabit connection between the servers. When all requirements are met virtual machines can be moved from
server to server with virtually no service interruption for zero‐downtime server maintenance.
Administrators can move running application workloads to take advantage of available compute power by
moving virtual machines to less utilized systems. The actual downtime during a XenMotion event is generally
100‐150ms. This downtime is so slight that services running in the VM are not interrupted. Most of the 100‐
150ms downtime is caused by your network switching equipment moving traffic to a new port.


3.7. vMotion Requirements and Live Migration

VMware vMotion technology leverages the complete virtualization of servers, storage and networking to move
an entire running virtual machine instantaneously from one server to another. VMware vMotion uses VMware’s
cluster file system to control access to a virtual machine’s storage. During a vMotion, the active memory and
precise execution state of a virtual machine is rapidly transmitted over a high speed network from one physical
server to another and access to the virtual machines disk storage is instantly switched to the new physical host.
Since the network is also virtualized by the VMware host, the virtual machine retains its network identity and
connections, ensuring a seamless migration process.

To be configured for VMotion, each server in the cluster must meet the following requirements.
1. Shared Storage: Ensure that the managed servers use shared storage. Shared storage is typically on a
storage area network (SAN). See the VMware SAN Configuration Guide for additional information on
SAN and the Server Configuration Guide for information on other shared storage. Both guides can be
found by searching for either SAN or Server Configuration Guide on www.vmware.com
2. Shared VMFS Volume: Configure all managed servers to use shared VMFS volumes.
 Place the disks of all virtual machines on VMFS volumes that are accessible by both source and target
servers.
 Set access mode for the shared VMFS to public.
 Ensure the VMFS volume is sufficiently large to store all virtual disks for your virtual machines.
 Ensure all VMFS volumes on source and destination servers use volume names, and all virtual
machines use those volume names for specifying the virtual disks.
NOTE: Virtual machine swap files also need to be on a VMFS accessible to both source and destination
servers (just like .vmdk virtual disk files). Swap files are placed on a VMFS by default, but administrators
might override the file location using advanced virtual machine configuration options.

3. Processor Compatibility: Ensure that the source and destination servers have a compatible set of
processors. VMotion compatibility means that the processors of the target server must be able to
resume execution using the equivalent instructions where the processors of the source server were
suspended. Processor clock speeds and cache sizes might vary, but processors must come from the
same vendor class (Intel versus AMD) and the same processor family to be compatible.
 In most cases, different processor versions within the same family are similar enough to maintain
compatibility.
 In some cases, processor vendors have introduced significant architectural changes within the same
processor family (such as 64‐bit extensions and SSE3). VMware vSphere Hypervisor identifies these
exceptions if it cannot guarantee successful migration with VMotion.
NOTE: VMware is working on maintaining VMotion compatibility across the widest range of processors
through partnerships with processor and hardware vendors. For current information, contact your
VMware representative.

4. Other Requirements
 VMotion does not currently support raw or undoable virtual disks or migration of applications
clustered using Microsoft Cluster Service (MSCS).
 VMotion requires a Gigabit Ethernet network between servers.
 VMotion requires a private Gigabit Ethernet migration network between all of the VMotion‐enabled
managed servers. When VMotion is enabled on a managed server, configure a unique network
identity object for the managed server and connect it to the private migration network.

For more information please visit VMware’s vMotion product page
http://www.vmware.com/products/vmotion/index.html
 www.VMware.com
 vMotion Product Page
 VirtualCenter VMotion Requirements


3.8. Hypervisor Shared Storage

In a virtualized environment where Branch Repeater VPX will be deployed, most hypervisor enabled features
such as High Availability and Live Migration require shared storage. In the physical Branch Repeater appliance
local storage is used for disk‐based compression. But since Branch Repeater VPX may require the use of shared
storage, this could have an effect on disk‐based compression and the overall BR VPX system performance based
on the performance of the shared storage.
3.8.1. Network Storage Requirements

 Latency should not exceed 5ms between server hosting BR VPX and the shared storage
 A dedicated NIC should be used to connect to the shared storage
NOTE: The same NIC should not be used for the accelerated pair – LAN and WAN ports)
 The bandwidth of the network connecting the server hosting BR VPX and the shared storage should be at‐
least 650 Mbps (1 Gbps is preferred) which is the bandwidth typically required to support XenMotion or
vMotion.
 A dedicated NIC should be used to connect to the LAN port of the accelerated pair
 A dedicated NIC should be used to connect to the WAN port of the accelerated pair
 The number of BR VPX VMs on the Server is also a consideration as the bandwidth requirements will go
up with additional BR VPX
3.8.2. Network Storage Disk Performance Requirements

To achieve to appliance comparable performance the Network Storage Read/Write performance should be at‐
least 80‐100 IOPS.
Before deploying it is recommended that a third party tool (Liquidware Labs or Lakeside Software) is used to
measure IOPS to verify that the network storage has acceptable performance.
In addition, before deploying BR VPX, a simple way to check whether the performance is acceptable is to achieve
the required system throughput for the bandwidth required is to see how the network storage read/write
performance compares with local storage read write performance.

3.8.3. VMware vSphere Requirements

 With an external data store VMware does not support thin provisioning for Branch Repeater VPX.
 The performance tests were run with the following VMware hypervisor parameters changed:
o Net.VmxnetTxCopySize 2048 (default value is 256)
o Net.VmxnetCopyTxRunLimt 256 (Default is 16)
o Net.CoalesceDefaultOn 0 (Default is 1)
3.8.4. Test results

Some limited tests were done to compare how a BR VPX on VMware vSphere using local storage performs
compared to a BR VPX using a NetApp FAS2000 using iSCSI.
Assuming the network storage requirements are met, the performance with external storage is similar to the
performance with BR VPX using the hypervisors local storage. Our tests have shown the performance difference
between internal and external storage is negligible.


3.9. High Availability

Traditionally High Availability (HA) is configured between two hardware appliances. For virtual appliances it
remains recommended to establish high availability across two physical servers – there is no benefit to applying
HA across two virtual instances on the same server hardware. Rather than leverage the BR‐level HA mechanism
across two instances the best practice is to configure redundancy on the hypervisor level. In a hypervisor HA
configuration two or more servers are configured to be in a common resource pool with a shared external
storage and in the case of hypervisor failure the virtual machine would started on one of the other servers within
the shared resource pool using the common shared storage to bring up the virtual appliance with the same
settings as the previous server.

3.9.1. XenServer / vSphere Server HA Requirements

 Shared storage with less than 5ms latency and 80‐100 IOPS, including at least one iSCSI or Fiber Channel
LUN of size 356MiB or greater ‐‐ the heartbeat storage repository (SR). The HA mechanism creates two
volumes on the heartbeat SR, a 4MiB heartbeat volume used for heartbeat and a 256MiB metadata
volume used to store pool master metadata to be used in the case of master failover.
 NOTE: If you are using a NetApp or EqualLogic SR, then you should manually provision an iSCSI LUN on
 NOTE: MiB means MebiByte (1 MiB equals 1,048,576 bytes)the array to use for the heartbeat SR
 A XenServer pool must be configured with at least two or more servers in the same resource pool
 For XenServer Enterprise or Platinum licenses must be installed on all servers that are joined into the
resource pool
 XenServer Essentials for version 5.5 or XenServer Supplemental packs for version 5.7 and newer must be
installed
 Servers must be configured to have access to the same virtual machine networks, shared storage, and
other resources
 For vSphere VMware infrastructure suite Standard or Enterprise must be installed on all servers
 NOTE: See the VMware Infrastructure Server Configuration Guide. Also see the VMware SAN
Configuration Guide for additional information

 NOTE: To use DRS with HA for load balancing, the servers in the cluster must be part of a VMotion
network. If the servers are not in the VMotion network, however, DRS can still make initial placement
recommendations
3.9.2. HA Failover
Since HA is accomplished by starting a new Branch Repeater virtual machine within the hypervisor resource pool
the failover differs significantly from the failover between two Branch Repeater appliances. Our testing has
shown it will take 2 – 5 min for the new Branch Repeater virtual machine to be operational. Each hypervisor has
multiple parameters like failure detection time, heart beat interval, etc. which can be fine‐tuned based on the
best practices guidelines for the corresponding hypervisors. Those parameters value depends on the factors like
number of VMs present in a pool, machine hardware, network infrastructure, disk storage, etc. Changing these
hypervisor specific parameters, will have impact to detect the HA failures and changes the time taken for the BR
VPX VM to be up on a different server within the same resource pool.
One big benefit of using the hypervisor’s HA functionality is that the disk compression history is not lost in the
case of a failover due to shared storage of the virtual machines. The BR VPX virtual machine booting on the
second hypervisor is using the exact same image on the shared storage as the previously failed BR VPX virtual
machine, hence no compression history is lost.

3.10. Network redundancy

To protect against outages caused by NIC failure it is suggested to connect the hypervisor using multiple
connections. To set up redundancy, you need two physical network adapters on each server.

 Connecting each network adapter to a corresponding network interface

 Connecting two bonded network adapters to a single network interface


 Connecting two network adapters to a single network interface
NOTE: To prevent network loops in this configuration the upstream networking device has to have
STP configured on the ports to which the hypervisor connects
3.11. How to setup within established VMware environments

As mentioned in chapter 3.4, there is no formula to calculate or rule to apply to figure out the Branch Repeaters
performance if installed along side of other virtual machines on already populated hypervisor. It is suggested to
use a dedicated hypervisor server for the Branch Repeater. Since most existing hypervisors environments are
parallel in the network it is most likely required to deploy additional hardware to accommodate all servers.
3.11.1. Deploying Branch Repeater on a new server using WCCP

Pros: Deployment can be accomplished with minimal impact to the existing network environment. No additional
bypass wiring as workaround for fail to wire is required.
Cons: An additional hypervisor server for the Branch Repeater has to be commissioned. The upstream router has
to support WCCP and changes to its configuration have to be made. WCCP is only recommended when inline is
not an option or practical.


3.11.2. Deploying Branch Repeater on a new server inline

Pros: With the Branch Repeater inline optimal performance is achieved. No changes to the upstream router have
to be made (WCCP).
Cons: An additional hypervisor server for the Branch Repeater has to be commissioned. To avoid network outage
in case of hypervisor failure a network bypass has to be configured.

3.11.3. Deploying Branch Repeater on the existing hypervisors

Pros: No additional Hardware has to be commissioned.
Cons: The Branch Repeater VPX’s performance is unpredictable with other virtual machines running on the same
hypervisor.

4. Use cases
4.1. Accelerated datacenter servers
By installing Branch Repeater VPX on every server in the datacenter, you have a solution that scales perfectly as
you add server capacity, while minimizing the number of servers by adding acceleration to the servers
themselves. Once you have more than a few accelerated servers, the aggregate acceleration provided by
multiple Branch Repeater VPX instances will exceed anything that can be provided with a single appliance.
Branch Repeater VPX will accelerate all kinds of network applications, including XenApp, XenDesktop, Citrix
Merchandising Server, network file systems, databases, Web server, and more using HDX IntelliCache.

HDX IntelliCache adaptively orchestrates with Citrix® XenApp™ to disable the native ICA compression used for
optimizing user sessions. It then optimizes XenApp delivery across multiple user sessions by locally caching and
de‐duplicating transmission of commonly accessed data including bitmap graphics, files, print jobs and streamed
media. Branch caching for hosted applications occurs transparently, requiring no additional configuration or
tuning on the Branch Repeater appliance or XenDesktop server. It fully supports basic and advanced ICA
encryption to maintain end‐to‐end security while optimizing traffic delivered to the branch. Users in locations
without Branch Repeater and mobile users working outside the office continue to benefit from Native ICA
compression for individual user sessions. More details about HDX IntelliCache can be found in the Citrix
knowledge base:
CTX120455 ‐‐ Understanding Citrix HDX Technology for Optimizing the Branch Office
4.2. Branch-office accelerator

Branch Repeater VPX can be installed on the server of your choice and deployed just like any other Branch
Repeater appliance, as shown below. With the exception of group mode and high‐availability mode (which are
not supported), Branch Repeater VPX has the same functionality as the Branch Repeater appliance, plus
additional features provided by virtualization and Xen‐Server Essentials.

4.3. VPN accelerator

By installing the VPN of your choice with Repeater VPX, you have an accelerated VPN. (Note that, unlike the
other configurations, the VPN virtual machine is on the WAN side and Branch Repeater VPX is on the LAN side,
because Branch Repeater VPX needs to see the decrypted VPN traffic to achieve compression and application
acceleration). A comprehensive Access Gateway deployment guide as well as a performance report can be found
in Citrix knowledge base
Deployment Guide: http://support.citrix.com/article/CTX121035
Performance Report: http://support.citrix.com/article/CTX121034

4.4. Accelerate ICA Proxy Mode in Citrix Access Gateway

Citrix XenDesktop and Citrix XenApp perform best with HDX WAN Optimization powered by Branch Repeater.
This technology is extended to SSL encrypted ICA, which is the recommended mode when users connect to ICA
servers from a public network. All the benefits such as bandwidth reduction, faster response times and dynamic
priority for interactive traffic are available for basic encryption mode, secure ICA mode, and ICA over SSL.
XenDesktop and XenApp servers automatically detect the presence of Branch Repeater on the network and off‐
load ICA compression and encryption on a per‐session basis. Many deployments use Citrix Access Gateway to
securely access published applications and desktops without connecting to a full VPN, using ICA Proxy Mode (also
known as Secure Gateway Mode). Specifically on private Multiprotocol Label Switching (MPLS) networks and
other branch scenarios where the Access Gateway does not open to the Internet, Branch Repeater may be
deployed on the external facing side of the Access Gateway to optimize ICA traffic. The Branch Repeaters
transparently accelerate ICA traffic – the end‐user device and the Access Gateway are not aware of Branch
Repeater ICA acceleration and require no configuration changes. If there are multiple users in the branch, they
also realize the benefit of the cross‐user nature of the ICA optimization of the Branch Repeater appliance.
More details about HDX IntelliCache can be found in the Citrix knowledge base:
CTX126301 ‐‐ http://support.citrix.com/article/CTX126301


4.5. Accelerated branch-office server

If you take the previous configuration and add another virtual machine, you have an accelerated branch‐office
server, as shown below. Simply assign the virtual networks within the machine so that the path to the WAN
passes through Branch Repeater VPX, and all WAN traffic will be accelerated automatically. In this configuration
the traffic between the branch office server and the datacenter or clients with the receiver plug‐in connection to
the branch office are accelerated. The virtual environment allows you to add whatever functionality you like to
the server unit, with your choice of operating system and features. Whatever you install, Branch Repeater VPX
will accelerate its WAN traffic — network file system access, Web traffic, backups, remote applications, database
queries, and so on. More than that, it will accelerate all the WAN traffic from every system in the branch office.
You can even deploy multiple virtual servers on the same machine, consolidating your branch‐office rack down to
a single unit running multiple virtual machines.
4.6. Multiple Branch Repeater VPX Instances

By putting multiple instances of Branch Repeater VPX on the same server, you can create different types or levels
of acceleration services within the same unit. One VPX instance might be dedicated to a critical application, or
each instance dedicated to an individual remote site or customer.

5. Step by step configuration guide

5.1. Management
5.1.1. XenCenter
XenCenter is a graphical, Windows‐based user interface to manage XenServer servers, resource pools and shared
storage, and to deploy, manage and monitor VMs from your Windows desktop machine.
To install XenCenter
1. Connect to your XenServer via a Web Browser

2. On the XenServer portal page click on the XenCenter installer link

3. When prompted click on Run to install the XenCenter application

4. Follow the onscreen instructions to complete the installation process


5.1.2. vSphere Client

vSphere Client is a graphical, Windows‐based user interface to manage XenServer servers, shared storage, and
to deploy, manage and monitor VMs from your Windows desktop machine.
To install vSphere Client
1. Connect to your vSphere server via a Web Browser

2. Click on the Download vSPhere Client link

3. When prompted click on Run to install the vSphere client application

4. Follow the onscreen instructions to complete the installation process


5.1.3. How to install / import images on XenServer

The latest BR VPX image for XenServer can be downloaded from Citrix using the link below. You must have a valid
login to access the BR VPX download page

1. Go to https://www.citrix.com/English/ss/downloads/index.asp
2. Click on Log In in the upper right hand corner
3. Select Branch Repeater from the Search Downloads by Product dropdown menu
4. Scroll down to the Virtual Appliance section and click on the latest version for XenServer
NOTE: Make sure the correct version for XenServer is downloaded. XenServer and vSphere versions are
posted together and are confused easily
5. Within the version page scroll to the bottom of the page to the Build section and click on Get Software

NOTE: In the same section you can download the user guide and release notes
6. Save the file to the local hard disk of the same PC with XenCenter installed
7. Un‐compress the zip file you downloaded to your local hard disk
8. Start the XenCenter application and connect to your XenServer

9. Click on File and click on Import



10. In the Import dialog window click on Browse

11. In the Open file dialog window browse to the BR VPX file for XenServer from your local hard disk and click
Open

12. Back in the import dialog window click on Next
13. In the next dialog select the Home Server for the BR and click on Next


14. In the next dialog select the storage for the BR VPX and click on Import
NOTE: If you intent to configure XenServer HA for the BR VPX you MUST select an external storage which is
shared by all servers in the resource pool. At minimum the advanced license must be installed on all servers
within the XenServer resource pool to enable HA. Please see the XenServer user guide for details on how to
configure external storage. The XenServer user guide can be downloaded from http://support.citrix.com

15. In the next dialog window the BR VPX interfaces are mapped to the XenServer interfaces / network cards
NOTE: If both BR VPX interfaces are assigned to the same XenServer network card or virtual network
interface you are creating a loop as described in section Avoiding Network Loops
Interface0 (example)

Interface1 (example)

16. Click on Next to continue
17. On the last screen confirm that all settings are correct and click Finish


18. The import can take anywhere from 1 to 10 min. Do not disconnect the PC from the network or close
XenCenter as the import process would be disrupted. To view the progress of the import click on the BR VPX
within XenCenter and click on the Log tab to the right

19. Within XenCenter click on Start to boot up the BR VPX

20. Click on the Console tab to the see boot up progress and to access the BR VPX CLI

21. Log on to the BR
Username: Admin
Password: password
22. In the console type the following to assign an IP address to the branch repeater (the values below are for
illustration only, you must use values that are applicable to your environment)
admin> set adapter apa ‐ip 172.16.0.213 ‐netmask 255.255.255.0 –gateway 172.16.0.1
admin> restart
23. After the BR VPX is rebooted it will be accessible via WebUI from the address you configured
24. Open your Web browser and enter the same IP address into the address bar to connect to the BR WebUI


5.1.1. How to install / import images on vSphere

The latest BR VPX image for vSphere can be downloaded from Citrix using the link below. You must have a valid
login to access the BR VPX download page

1. Go to https://www.citrix.com/English/ss/downloads/index.asp
2. Click on Log In in the upper right hand corner
3. Select Branch Repeater from the Search Downloads by Product dropdown menu
4. Scroll down to the Virtual Appliance section and click on the latest version for vSphere
NOTE: Make sure the correct version for vSphere is downloaded. XenServer and vSphere versions are
posted together and confused easily
5. Within the version page scroll to the bottom of the page to the Build section and click on Get Software

NOTE: In the same section you can download the user guide and release notes
6. Save the file to the local hard disk of the same PC with vSphere Client installed
7. Un‐compress the zip file you downloaded to your local hard disk
8. Start the vSphere client application and connect to your vSphere server

9. Click on File and select Deploy OVF Template from the dropdown menu

10. In the Deploy OVF Template dialog window click on Browse

11. In the Open file dialog window browse to the BR VPX file for XenServer from your local hard disk and click
Open

12. Back in the import dialog window click on Next
13. Name the BR VPX image and click on Next
14. In the next dialog select the storage for the BR VPX and click on Next
NOTE: If you intent to configure vSphere HA for the BR VPX you MUST select an external storage which is
shared by all servers in the resource pool. At minimum the vSphere essentials Plus license must be installed
on all servers within the vSphere resource pool to enable HA. Please see the vSphere user guide for details
on how to configure external storage and HA. The vSphere user guide can be downloaded from
http://www.vmware.com/support/pubs/


15. In the Disk Format dialog select Thick provisioning format and click on Next

16. In the next dialog window the BR VPX interfaces are mapped to the XenServer interfaces / network cards
NOTE: If both BR VPX interfaces are assigned to the same XenServer network card or virtual network
interface you are creating a loop as described in section Avoiding Network Loops

17. Click on Next to continue
18. On the last screen confirm that all settings are correct and click Finish
19. The import can take anywhere from 1 to 10 min. Do not disconnect the PC from the network or close
vSphere client as the import process would be disrupted.
20. Within vSphere client click on the Play button to boot up the BR VPX


21. Click on the Console tab to the see boot up progress and to access the BR VPX CLI

22. Log on to the BR
Username: Admin
Password: password
23. In the console type the following to assign an IP address to the branch repeater (the values below are for
illustration only, you must use values that are applicable to your environment)
admin> set adapter apa ‐ip 172.16.0.213 ‐netmask 255.255.255.0 –gateway 172.16.0.1
admin> restart

24. After the BR VPX is rebooted it will be accessible via WebUI from the address you configured
25. Open your Web browser and enter the same IP address into the address bar to connect to the BR WebUI

5.2. HA
5.2.1. XenServer High Availability
To configure XenServer HA please revisit the chapter XenServer / vSphere Server HA Requirements to ensure the
XenServer HA prerequisites are met
To configure XenServer HA
1. Start the XenCenter application and connect to your XenServer
2. Select the Resource Pool at the root and click on the HA tab on the right

3. Within the HA tab click on Enable HA
4. Click Next in the Prerequisite screen
5. Select a heartbeat storage that will be used to monitor the availability and health of servers in the resource
pool. Heartbeat storage must be shared storage. Click on Next

6. If there are more than 3 servers in the resource pool reduce the Number of server failures to allow down to
3

7. Select the BR VPX from the list of virtual machines running in your resource pool and select Restart first
from the Restart priority dropdown menu

8. Click on Next
9. Verify the accuracy of the setting on the last screen and click on Finish to complete the HA wizard
10. XenCenter will change to the log screen automatically where the HA setup status is displayed. The process
will take anywhere between 1 – 5 min
NOTE: Do not close XenCenter or the operation will not complete
5.2.2. vSphere High Availability

It is beyond of the scope of this guide to document VMware HA configuration in detail, please visit VMware’s
product pages for more detail on how to configure HA.
1. High Availability Resource Page
http://www.vmware.com/solutions/business-continuity/highavailability/resources.html
2. vSphere High Availability Page
http://www.vmware.com/products/high-availability/index.html
3. VMware HA Concepts and Best Practice
http://www.vmware.com/resources/techresources/402

Branch Repeater VPX Best Practice and Deployment Guide-V1.3

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Branch Repeater VPX Best Practice and Deployment Guide-V1.3

Загружено:

Авторское право:

Доступные форматы

BR VPX Deployment Guide | Citrix BR & AG Marketing

Branch Repeater VPX

Citrix Security & Acceleration Group

Citrix Systems, Inc. © 2011 Confidential Page i of 33

Document revision history

Version Date Author Comments

1.1 Mar-28-11 Andreas Zindel Incorporated Feedback

1.3 April-17-11 Andreas Zindel Finalized Document

2. VPX systems requirements ..............................................................................................................................3

3. Considerations and Best Practices ...................................................................................................................5

4. Use cases .......................................................................................................................................................17

5. Step by step configuration guide ....................................................................................................................20

Citrix Systems, Inc. © 2011 Page 2 of 33

2. VPX systems requirements

Citrix Systems, Inc. © 2011 Page 3 of 33

Citrix Systems, Inc. © 2011 Page 4 of 33

3. Considerations and Best Practices

3.1. When to use VPX

Elasticity & Agility

3.2. When to use hardware appliances

Citrix Systems, Inc. © 2011 Page 5 of 33

3.3. Mapping Branch Repeater network interfaces considerations

3.3.1. Enabling Promiscuous Mode

Citrix Systems, Inc. © 2011 Page 6 of 33

3.3.2. Avoiding Network Loops

Citrix Systems, Inc. © 2011 Page 7 of 33

3.3.3. Fail to wire workaround

Citrix Systems, Inc. © 2011 Page 8 of 33

3.3.4. Considerations for connecting XenServer servers to a switch

Citrix Systems, Inc. © 2011 Page 9 of 33

3.4. Determining how many Virtual Machines per server

3.5. Workload Balancing

3.6. XenMotion Requirements and Live Migration

Citrix Systems, Inc. © 2011 Page 10 of 33

3.7. vMotion Requirements and Live Migration

Citrix Systems, Inc. © 2011 Page 11 of 33

3.8. Hypervisor Shared Storage

3.8.1. Network Storage Requirements

3.8.2. Network Storage Disk Performance Requirements

3.8.3. VMware vSphere Requirements

3.8.4. Test results

Citrix Systems, Inc. © 2011 Page 12 of 33

3.9. High Availability

3.9.1. XenServer / vSphere Server HA Requirements

Citrix Systems, Inc. © 2011 Page 13 of 33

3.10. Network redundancy

Citrix Systems, Inc. © 2011 Page 14 of 33

3.11. How to setup within established VMware environments

3.11.1. Deploying Branch Repeater on a new server using WCCP

Citrix Systems, Inc. © 2011 Page 15 of 33

3.11.2. Deploying Branch Repeater on a new server inline

3.11.3. Deploying Branch Repeater on the existing hypervisors

Citrix Systems, Inc. © 2011 Page 16 of 33

4.2. Branch-office accelerator

Citrix Systems, Inc. © 2011 Page 17 of 33

4.3. VPN accelerator

4.4. Accelerate ICA Proxy Mode in Citrix Access Gateway

Citrix Systems, Inc. © 2011 Page 18 of 33

4.5. Accelerated branch-office server

4.6. Multiple Branch Repeater VPX Instances

Citrix Systems, Inc. © 2011 Page 19 of 33

5. Step by step configuration guide

Citrix Systems, Inc. © 2011 Page 20 of 33