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

www.citrix.com

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

BR VPX Deployment Guide | Citrix BR & AG Marketing

Branch Repeater VPX Best Practice and Deployment Guide

Citrix Security & Acceleration Group

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


Citrix Systems, Inc. © 2011 Page 2 of 33

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



2. VPX systems requirements

Branch Repeater: Virtual Appliances

Trial

Version1 Branch Repeater VPX2

Model VPX

Express VPX 2 VPX 10

VPX 45 4GB RAM

VPX 45 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)

Hypervisor XenServer 5.6 or later

VMware vSphere vSphere

Processor Dual Core Intel or AMD 64-bit x86 (Citrix XenServer)

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

Virtual CPUs 1 for Citrix XenServer 2 for VMware vSphere

2 for Citrix XenServer 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

Documents

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