Your SlideShare is downloading. ×
Comparação entre XenServer 6.2 e VMware VSphere 5.1 - Comparison of Citrix XenServer 6.2 And VMware vSphere 5.1
Comparação entre XenServer 6.2 e VMware VSphere 5.1 - Comparison of Citrix XenServer 6.2 And VMware vSphere 5.1
Comparação entre XenServer 6.2 e VMware VSphere 5.1 - Comparison of Citrix XenServer 6.2 And VMware vSphere 5.1
Comparação entre XenServer 6.2 e VMware VSphere 5.1 - Comparison of Citrix XenServer 6.2 And VMware vSphere 5.1
Comparação entre XenServer 6.2 e VMware VSphere 5.1 - Comparison of Citrix XenServer 6.2 And VMware vSphere 5.1
Comparação entre XenServer 6.2 e VMware VSphere 5.1 - Comparison of Citrix XenServer 6.2 And VMware vSphere 5.1
Comparação entre XenServer 6.2 e VMware VSphere 5.1 - Comparison of Citrix XenServer 6.2 And VMware vSphere 5.1
Comparação entre XenServer 6.2 e VMware VSphere 5.1 - Comparison of Citrix XenServer 6.2 And VMware vSphere 5.1
Comparação entre XenServer 6.2 e VMware VSphere 5.1 - Comparison of Citrix XenServer 6.2 And VMware vSphere 5.1
Comparação entre XenServer 6.2 e VMware VSphere 5.1 - Comparison of Citrix XenServer 6.2 And VMware vSphere 5.1
Comparação entre XenServer 6.2 e VMware VSphere 5.1 - Comparison of Citrix XenServer 6.2 And VMware vSphere 5.1
Comparação entre XenServer 6.2 e VMware VSphere 5.1 - Comparison of Citrix XenServer 6.2 And VMware vSphere 5.1
Comparação entre XenServer 6.2 e VMware VSphere 5.1 - Comparison of Citrix XenServer 6.2 And VMware vSphere 5.1
Comparação entre XenServer 6.2 e VMware VSphere 5.1 - Comparison of Citrix XenServer 6.2 And VMware vSphere 5.1
Comparação entre XenServer 6.2 e VMware VSphere 5.1 - Comparison of Citrix XenServer 6.2 And VMware vSphere 5.1
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Comparação entre XenServer 6.2 e VMware VSphere 5.1 - Comparison of Citrix XenServer 6.2 And VMware vSphere 5.1

4,066

Published on

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
4,066
On Slideshare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. White Paper I Citrix XenServer www.citrix.com Comparison of Citrix XenServer 6.2 And VMware vSphere 5.1
  • 2. White Paper I Citrix XenServer Comparison of XenServer 6.2 and vSphere 5.1 Table of contents Introduction...............................................................................................1 Overview and history of server virtualization.........................................1 Why workloads matter..............................................................................3 General-purpose server virtualization .........................................................3 Memory management ..................................................................................................... 3 Storage management...................................................................................................... 4 Infrastructure management ............................................................................................. 6 Desktop virtualization..................................................................................6 Template management ................................................................................................... 6 Storage management...................................................................................................... 7 Graphics optimization...................................................................................................... 7 VM density ...................................................................................................................... 7 Cloud services ............................................................................................8 Advanced network management..................................................................................... 8 VM density ...................................................................................................................... 9 Pricing scenarios....................................................................................10 Traditional server virtualization .................................................................10 Desktop virtualization................................................................................10 Cloud services ..........................................................................................11 Conclusion – The Hypervisor is now a Commodity.............................12
  • 3. White Paper I Citrix XenServer Comparison of XenServer 6.2 and vSphere 5.1 Introduction Over the past several years, server virtualization has become mainstream with analyst estimates that more than fifty percent of all servers are now virtualized. Customers have choice in which hypervisor they wish to choose for their virtualization projects, and there is an increasing trend towards multiple hypervisors in datacenters. In this paper, we’ll compare key functional areas between VMware vSphere 5.1 and Citrix XenServer 6.2, and highlight how each solution compares for the critical workloads being deployed in datacenters today. Overview and history of server virtualization VMware and Citrix are pioneers in the world of x86 server virtualization that currently market their hypervisor solutions as VMware® vSphere® and Citrix® XenServer®, respectively. vSphere was originally developed under the brand name ESX, with its first release in 1998. The primary objective of ESX was to more efficiently utilize the compute capacity of x86 servers, which were typically running at 10 to 20 percent utilization. Consolidation of servers onto a single virtualization host permitted greater utilization of the host server, but also provided significant savings in energy for power and cooling. As a bare-metal hypervisor, ESX is installed on the host server and guest virtual machines (VMs) are created for each server being consolidated on that host, with core ESX management services provided via a service console VM. Given limitations in the x86 instruction set, virtualizing an operating system required the hypervisor to trap specific instructions and then modify the operating system code to emulate the correct instruction behavior. While effective, the use of emulation also imposed a significant performance penalty for the guest VMs. As server consolidation proved effective, ESX was enhanced with several key features including clustering and live VM migration. These features enabled more efficient management of the virtual infrastructure by reducing the downtime associated with key operations such as host maintenance. The server consolidation movement also presented VMware with a series of new, often niche, requirements for classes of server workloads to be consolidated, such as serial port management. It also introduced additional challenges based on increased usage of server consolidation, such as managing the memory utilized by the core operating system of each VM. This evolutionary heritage has defined the modern vSphere hypervisor, and its legacy can be seen in the vSphere feature set as well as the operating systems supported. XenServer is based on the Open Source Xen® Project hypervisor project initiated at the University of Cambridge in the United Kingdom, whose first public release was in 2003, and which is now a collaborative project of the Linux Foundation. In a Xen Project-based deployment, the bare-metal Xen Project hypervisor is installed on the hypervisor host and all VMs are called domains, with core services in the privileged control domain, dom0. Guest VMs run in unprivileged domains and typically access hardware via dom0.
  • 4. White Paper I Citrix XenServer Comparison of XenServer 6.2 and vSphere 5.1 One of the key advancements of the Xen Project hypervisor is paravirtualization, the notion that operating systems become aware they have been virtualized. Without awareness of their virtualization status, operating systems are free to execute CPU instructions which assume direct control of the CPU and thus create performance bottlenecks. Through virtualization awareness, operating system performance bottlenecks can be removed and allow guests VMs to operate more efficiently. While Open Source operating systems can be fully modified to achieve awareness, closed source operating systems such as Microsoft® Windows® can also benefit from paravirtualization through the use of paravirtual drivers on key devices. When combined with advancements in processor technologies such as Intel® VT and AMD- V, XenServer avoids the performance bottlenecks and challenges associated with the emulation model used in ESX. In response to the work on paravirtualization in Xen and the advancements underlying chip technology, VMware adopted paravirtualized device drivers and began to drop its use of emulation. The hypervisor resulting from this work, named ESXi, proved so serviceable that with vSphere 5.0, VMware retired the ESX architecture. Today there are few performance differences between hypervisors, and the hypervisor has become more of a commodity leading the comparison between vendors to be more functional rather than pure performance.
  • 5. White Paper I Citrix XenServer Comparison of XenServer 6.2 and vSphere 5.1 Why workloads matter At the time vSphere was designed, the core requirement for a hypervisor was server consolidation. VM densities associated with that scenario were at most tens per server, and the workloads themselves were largely utilitarian. You can still see this low density design mindset when looking at the “monster VM” capabilities of vSphere, which have increased the capabilities to support very large VM sizes with vSphere 5.1, but with no corresponding increase in VM density. While this model does hint at an understanding that workloads matter, there is minimal evidence that vSphere is designed with the majority of workload types in mind; rather it seems to be designed to perform best for general-purpose workloads while avoiding any optimization for specific workload scenarios. General-purpose server virtualization In a general-purpose server virtualization scenario, the key features of the virtualization infrastructure are memory, storage and infrastructure management. Memory management Memory management functionality, also commonly referred to as memory over-commitment, was implemented at a time when the ability to over-commit the CPU on a virtualization host resulted in RAM becoming the defining element in the cost of the host. To resolve this, it was observed that the operating system memory usage was often a large of the memory allocated to a system, and that within a server consolidation scenario the same operating system was usually present in multiple VMs. Coupled with the understanding that servers were often provisioned with surplus memory due either to an expectation that applications would use available RAM or that servers were only available with discrete RAM values, it became accepted that overcommiting the memory on a virtualization host led to effective management of the overlap and utilization of memory across VMs. Within a vSphere environment, there are three options available for memory management; ballooning, page sharing and swap with compression. Ballooning is used for situations where the VM is configured with more memory than it is actually using. Page sharing is used to address the commonality of operating system memory pages. Swap is only used when the combined VM usage of memory exceeds the available RAM on the host. To minimize inherent performance problems associated with swapping memory, swapped memory is compressed to minimize the IO associated with recovering it. Unfortunately, as is often the case with evolutionary products, the original assumptions are no longer as compelling. Modern operating systems, in an attempt to prevent malicious tampering, now randomize and sign their memory pages. Additionally, in an effort to increase performance, they now implement large memory page layouts and leverage unallocated memory for system caches. Randomization of memory pages and the use of large memory pages can neutralize the benefit of page sharing, while the use of unallocated memory for system caches impacts the degree to
  • 6. White Paper I Citrix XenServer Comparison of XenServer 6.2 and vSphere 5.1 which memory ballooning should be used. Couple these items with cost-effective servers with 128 to 256 GB of RAM and memory over-commitment strategies become less relevant. In recognition of these trends, XenServer uses a balloon memory management model. Administrators select a maximum and minimum value for the memory balloon driver. When a VM starts up on a host with ample memory, the amount of free memory seen by the VM corresponds to the maximum configured value. In the event the memory requirements of additional VMs on the host cause the memory on the host to become oversubscribed, the XenServer host requests that VMs with available free memory release it to the host. This allows XenServer to provide meaningful memory management when host RAM is the limiting factor for VM density, while not imposing performance or security penalties on the use of memory over-commit strategies. Storage management Storage is one of the most crucial factors in determining the overall cost of a virtualization solution, and there are many options that can affect this cost. To allow VM migration between virtualization hosts, a shared storage model is often used. In a shared storage model, a SAN or NAS device is connected to the virtual infrastructure and one or more volumes or LUNs are presented for use. The connections are usually redundant, regardless of whether they are made using iSCSI or NFS or via an HBA. Since server consolidation often involves mission-critical data, multiple storage options are often concurrently in use, and a given LUN may map to a specific VM disk. vSphere addresses this complexity with a proprietary file system, VMFS, which is leveraged over the underlying storage solution. The disk images are then stored on VMFS datastores in a proprietary file format, vmdk. The vmdk specification is updated with each vSphere release; leading to compatibility and portability issues during upgrades. vSphere also supports direct integration with specific arrays using a technology called vStorage APIs for Array Integration (VAAI). When combined, these solutions provide a resilient storage model upon which to build a virtual infrastructure. However, it is important to note that VMware regularly updates the vmdk format, raising portability issues when planning for disaster recovery. XenServer does not impose a proprietary file system for shared storage; rather it leverages the Microsoft open specification for the virtual hard disk (VHD) format to define the actual VM disk and uses the Linux® logical volume manager to handle the underlying disk systems. This adherence to an open standard ensures that portability issues endemic to proprietary file systems are avoided. In situations where a LUN-per-VDI model or direct array integration are required, XenServer has StorageLink. StorageLink provides direct array integration for popular storage solutions from NetApp, Dell and EMC, which provide a high- performance and resilient storage sub-system upon which a virtual infrastructure can be built. Looking beyond the basic topic of storage management, general-purpose server virtualization also has requirements for migration of storage associated with a running VM and for management of storage between disaster recovery sites. One of the most important considerations in migrating storage over general-purpose networks is ensuring the security of the data being transferred
  • 7. White Paper I Citrix XenServer Comparison of XenServer 6.2 and vSphere 5.1 Live storage migration VMware pioneered the technology of live storage migration and branded it Storage vMotion to align with its live virtual machine migration brand, vMotion. This technology allowed administrators to migrate the underlying storage for a VM without incurring significant downtime, and became popular for array maintenance and resizing storage. In its original form, Storage vMotion functionality was limited to migrating the storage within a single vSphere cluster, but with vSphere 5.1 that restriction has been removed and both storage and VM state can be migrated between vSphere clusters. Unlike vSphere, with its heritage of cluster management, storage migration for XenServer was designed with cloud scale in mind. This feature, Storage XenMotion was not designed with an assumed cluster boundary to limit it. One advantage of designing without the confines of a clustering solution was that the realities of datacenter networks versus storage networks were designed in from the start, and one of the most important considerations in migrating storage over general purpose networks is ensuring the security of the data being transferred. Further, the design criteria included migration across all types of native XenServer storage options, resulting in a support matrix including everything from local storage through fiber-based storage arrays. Disaster recovery planning Disaster recovery planning is one of the most common scenarios associated with modern server virtualization project. Features inherent to virtualization, such as hardware independence, become even more important when disconnected datacenters are involved. vSphere includes an optional component called Site Recovery Manager, which facilitates planning and management of a vSphere environment involving multiple sites. Site Recovery Manager assumes that the vSphere product version and the underlying storage in different sites are compatible. Compatibility is required, as Site Recovery Manager automates not only the vSphere environment but also the storage systems’ replication between sites. By performing this level of deep integration, Site Recovery Manager ensures that the vSphere administrator is in control of disaster recovery planning. XenServer also has a disaster recovery planning module, but unlike its vSphere counterpart, the Integrated Disaster Recovery feature is, as its name implies, fully integrated with the XenServer infrastructure. What sets this feature apart from vSphere Site Recovery Manager is the recognition that disaster recovery planning is a complex proposition typically involving many technologies and departments within an IT organization. In a XenServer environment, Integrated Disaster Recovery
  • 8. White Paper I Citrix XenServer Comparison of XenServer 6.2 and vSphere 5.1 takes care of all virtualization aspects including VM disks, VM metadata and the network configuration, while leaving the task of configuring storage replication to the storage system administrators. This ensures that an organization’s disaster recovery runbook and best practices can be implemented without any risk of an accidental override by virtualization administrators. It further ensures that during testing of a disaster recovery plan or recovery from an actual outage, virtualization administrators are working closely with their storage counterparts. Infrastructure management In a vSphere environment, the infrastructure is managed using an external tool called vCenter. vCenter is installed on a dedicated management server and requires an underlying database server to store its configuration information. vCenter is a powerful tool providing management and tuning options for individual vSphere hosts as well as vSphere clusters and groupings of clusters. The health of a vSphere environment is directly related to that of the vCenter management server. To ensure the overall health of the vCenter server, VMware sells a number of add-on products designed to overcome the risks associated with an external management server. One of the more interesting aspects of vCenter is the evidence of its heritage of single-host management in many of the configuration options. For example, configuring network options using the vSphere standard network switch requires administrators to make the configuration change on each host individually, regardless of the clustering options chosen. In contrast, a XenServer environment uses a fully replicated configuration database with a master-slave model, which allows any slave to become a master as required. This model avoids the requirement for external management tools or a management server, and allows a XenServer resource pool to be fully configured from any of the nodes in the pool. When a graphical interface is required, XenCenter can be installed on any Microsoft Windows-based PC. Additionally, the XenServer Web Self Service component provides delegated VM-level access via a web browser. If direct integration within a larger systems management suite is desired, XenServer ships with components supporting Microsoft System Center. Also, other vendors have chosen to integrate using either the XenCenter plugin architecture or the fully documented XenServer APIs. Desktop virtualization Unlike the heterogeneous environment with low VM density typical of traditional server virtualization, desktop virtualization is characterized by comparatively high VM density, use of a limited number of VM templates and high IO requirements, particularly during specific times of day. These attributes require that a hypervisor be optimized for desktop workloads, but the optimizations also include a requirement to understand how users interact with desktops and what they expect from a computing environment. The net result is that a virtualization environment designed to handle general-purpose workloads may not perform optimally in a desktop environment. Template management In a desktop virtualization environment, the desktop broker defines a series of VM templates. When a user requests a new desktop, that desktop is provisioned from the template. One of the provisioning models available in XenDesktop is a template management system called Provisioning Services (PVS), which can be used with the Citrix® XenDesktop® desktop broker. PVS was designed to support the
  • 9. White Paper I Citrix XenServer Comparison of XenServer 6.2 and vSphere 5.1 consistent deployment of a golden machine image in both virtual and physical environments. When used with XenDesktop, the desktop broker creates the VM, and then instructs PVS to stream the golden image into that newly provisioned VM. User and application data generated while using the streamed image can be stored either on the PVS server or the local disk on the target computer. In a XenServer environment, the local disk of the XenServer can be used for this cache, providing a highly scalable solution with minimal IO impact on the network or any shared storage. Storage management XenDesktop also includes a template management system called Machine Creation Services (MCS). Simpler than PVS, MCS is designed for smaller installations. VMs provisioned using it are assigned one or more local disks from shared hypervisor storage. Shared storage allows a template to be cloned using the storage array and then seamlessly provisioned to the hypervisor. While optimizing performance, machine creation services works with XenServer IntelliCache to offload the IO from the storage array and minimize any IOP bottlenecks. This approach helps prevent the desktop virtualization project from becoming blocked by storage array costs associated with provisioning storage for peak IO. Operating together, machine creation services and IntelliCache recognize that within a desktop virtualization environment, the number of templates in use is limited. Upon first use of a template, IntelliCache copies it to local storage on the XenServer host. Subsequent requests for the same template generate a local clone of the original template. This use of local storage can substantially reduce the number of IO operations the shared storage array is required to deliver. Graphics optimization Typically, a desktop virtualization project comprises different classes of users. Some will require only basic graphics support and for them, the embedded graphics chip on the server is sufficient to deliver the desired performance. Other users, such as those in the engineering or medical fields, require significantly greater graphics performance than embedded graphics chips can deliver. To accept desktop virtualization, such users must feel comfortable that a virtual desktop can meet their graphical performance expectations. XenServer achieves delivers high performance graphics through the use of GPU pass-through technology. One or more high-performance GPU cards, such as the NVIDIA GRID K2 or AMD FirePro, are installed in the XenServer host, and then dedicated to the specific users’ VM. Users enjoy secure, remote access to graphics-intensive applications without sacrificing performance. In contrast, the vGPU model employed by vSphere attempts to over-commit the GPU and provide an emulated GPU to the VM, resulting in shared access. Since a GPU is designed with a long command pipeline, and highly parallel non-interruptible thread execution engines, over-committing access reduces a GPU’s overall efficiency. VM density In a virtual desktop project, the number of VMs a host can handle directly impacts return on investment (ROI). Unfortunately, adding more desktops to the host is not without risks. Host failure, for example, will cause the loss of all running virtual desktops, and greater VM density increases the impact of those failures. Careful design allows a balance between ROI and risk with the resultant density being what an organization can realistically absorb in the event of host failure.
  • 10. White Paper I Citrix XenServer Comparison of XenServer 6.2 and vSphere 5.1 The configuration maximums for vSphere and XenServer seem to indicate that vSphere can handle significantly more VMs than XenServer. However, closer scrutiny shows that the vSphere maximum density is in fact a technical limitation which has remained unchanged for many year and which has minimal bearing on the reality of any deployment. In fact, despite the releases of more-capable CPUs from Intel and AMD, the maximum number of VMs vSphere can run has remained constant. Further, there appear to be no performance studies showing deployments even approaching the published maximum. Citrix, by contrast, has never published a value for the maximum number of VMs XenServer can handle. Instead the company publishes a supported limit to provide confidence that, regardless of the server configuration, customers will succeed as long as they choose a server that could reasonably be expected to run the specified number of VMs. The reason for this approach is that decisions relating to storage and network choices, as well as operating system configurations, affect calculation of the maximum number of VMs on a system. With each release, Citrix has increased the published number of VMs XenServer can comfortably handle. Currently, the supported limit for XenServer 6.2 is 225 VMs per host. Cloud services Cloud and cloud services are among the hottest IT topics today. Regardless of whether the aspiration is to offer a public cloud for managed services or something a bit more modest, such as an internal private cloud, cloud is the newest use case for virtualization. What differentiates cloud services from traditional server virtualization is the combination of high VM density with tenant isolation. This latter is key to successfully delivering cloud services, for without tenant isolation customers are concerned their private data is somehow accessible to a competitor and their IT organization will fail a compliance audit. Advanced network management At its most basic level, tenant isolation can be achieved by assigning each tenant a dedicated virtualization host and VLAN. However, even with this model, advanced network management is required. The ability to control and monitor the network performance of each VM and to mirror traffic and control its flow to the VM is vital. Simple network management at the physical network is insufficient in the face of VM agility. For example, defining a network policy on a physical switch port to protect against rogue VM traffic only works as long as the VM itself does not migrate to a different host. The solution to advanced network management in a virtual environment is a virtual switch. vSphere provides three options for virtual networking: standard switch, virtual distributed switch and the virtual distributed switch with an optional extension from either Cisco or IBM. Since the standard switch is configured at each host independently of other hosts, it is not appropriate for use in a cloud environment. This then leaves the virtual distributed switch. In vSphere 5.1 it has been enhanced with some basic access control capabilities as well as NetFlow and RSPAN for monitoring. Full network flexibility relies on the Cisco Nexus 1000v or IBM 5000v. Unlike vSphere, which is late to the virtual networking space and relies on costly third-party add-ons, XenServer has been shipping advanced networking as an available integrated network stack for several years. The XenServer distributed virtual switch relies on the Open vSwitch and supports OpenFlow as its XenServer has been shipping advanced networking as an available integrated network stack for several years
  • 11. White Paper I Citrix XenServer Comparison of XenServer 6.2 and vSphere 5.1 control plane. XenServer supports tenant isolation using ipset, VLAN and cross-host GRE tunnels. The XenServer distributed virtual switch allows network policies to be defined at the VM level, and these policies are automatically migrated when a VM is migrated. They can consist of simple NetFlow or RSPAN definitions and can include both firewall rules and quality of service (QoS) settings. Additionally, the virtual switch supports the creation of LACP networks and uses portfast to minimize the potential for IP spoofing between tenants. VM density As in desktop virtualization, VM density is a key topic for cloud builders. In cloud environments, risk from high VM densities comes from the loss of client workloads, not the loss of a group of users. Unlike desktop virtualization, VMs hosted in a cloud are likely to be diverse and have significant configuration differences. This heterogeneity presents a further challenge to VM density: customers of cloud operators expect performance between workloads to be consistent, despite the potential for one client’s workload to impact the performance of another’s. To solve this, many cloud builders elect not to leverage the over- commit options within a hypervisor in favor of the predictability of workload performance. If resources are over-committed, the degree of over-commitment is minimal. In practice, this means the number of VMs a host can support is more in line with the number of vCPUs that can be scheduled on the host, and VM densities rarely approach the theoretical maximums for any hypervisor.
  • 12. White Paper I Citrix XenServer Comparison of XenServer 6.2 and vSphere 5.1 Pricing scenarios The following pricing scenarios are based on a requirement to provide a fully supported virtual environment featuring:  Graphical management user interface with no single point of failure  VM protection against host failures  VM-level network monitoring  Cluster-level configuration for all virtualization elements, including storage and networks  Workload placement services  Ability to over-commit RAM  Live VM migration  Live VM storage migration without pool/cluster limits Since the cost of virtualization infrastructure is related to the costs of licensing, ongoing software updates and production support, scenarios assume a three-year investment. XenServer is available as a single SKU, and the vSphere product is the Enterprise Plus Edition. The chosen hardware will have dual sockets, but the hardware costs are not included in these scenarios. All prices are USD and accurate as of July 1, 2013. Traditional server virtualization For this pricing scenario, a total of 10 virtualization hosts will be required. XenServer vSphere Host license cost 20 Sockets: $21,000 20 Enterprise Plus: $71,900 Host subscription and support Three years of maintenance: $6,000 Three years of SnS: $52,400 Management license cost XenCenter is free vCenter: $4,995 High availability for management server Not required as XenServer has no single points of failure vCenter Heartbeat: $9,995 Management subscription Included Three years of SnS: $10,343 Total $27,000 $149,163 In this pricing scenario, not only does XenServer have a lower cost of acquisition, but its three-year operating costs, including the cost of acquisition, are less than the three-year subscription costs associated with the vSphere hosts. Desktop virtualization To highlight the pricing associated with the virtualization layer, the desktop broker component must be consistent across hypervisors. XenDesktop virtual desktop infrastructure supports both vSphere and XenServer. Since VMware® View® does not provide cross-hypervisor support, this example uses XenDesktop as its desktop broker. When deploying vSphere without View, customers must either purchase as the Desktop Edition or Enterprise Plus Edition, while XenDesktop includes an entitlement for XenServer. For this pricing scenario, assume a total of 1,000 desktops are required, vSphere Desktop
  • 13. White Paper I Citrix XenServer Comparison of XenServer 6.2 and vSphere 5.1 Edition is priced at 100 desktops per license and requires a separate vCenter installation from any non- desktop vCenter instance. XenServer vSphere Host license cost Included with XenDesktop 10 Desktop Edition: $65,000 Host Subscription Included with XenDesktop Three years of SnS: $9,750 Support Included with XenDesktop Included with SnS Management license cost XenCenter is free vCenter: $4,995 High availability for Management Server Not required as XenServer has no single points of failure vCenter Heartbeat: $9,995 Management subscription Free Three years of SnS: $10,343 Total Free $100,083 Cloud services As with the desktop virtualization example, a cloud orchestration solution supporting both vSphere and XenServer is required to provide a fair pricing comparison. Citrix® CloudPlatform™ also includes an entitlement to XenServer, but to further level the pricing comparison, Apache CloudStack is used. Apache CloudStack fully supports XenServer and vSphere and provides no entitlements to either. CloudStack integrates with vSphere using vCenter, and using this model the pricing example is identical to that of the traditional server virtualization. XenServer vSphere Host license cost 20 Sockets: $21,000 20 Enterprise Plus: $71,900 Host subscription and support Three years of maintenance: $6,000 Three years of SnS: $52,400 Management license cost XenCenter is free vCenter: $4,995 High availability for management server Not required as XenServer has no single points of failure vCenter Heartbeat: $9,995 Management subscription Included Three years of SnS: $10,343 Total $27,000 $149,163
  • 14. White Paper I Citrix XenServer Comparison of XenServer 6.2 and vSphere 5.1 Conclusion – The Hypervisor is now a Commodity Looking back over the history of server virtualization, it is clear that hypervisors were once viewed as a premium tool to extract the most value from a server. Today, virtualization is mainstream with reportedly over 50 percent of servers virtualized, and the hypervisor itself has become a commodity. While VMware may continue in its attempts to maximize the revenue generated by vSphere through complex annual pricing changes, IT organizations are looking at virtualization as a tool to maximize their efficiency and effectiveness. Since these two objectives are at odds, IT has been forced to look at alternate options for virtualization platforms. Considering key features and performance requirements of a virtualization project together with the overall costs of delivering IT services, XenServer warrants a closer look. The following table compares features of the two competing products that were discussed in this paper, plus additional features. Although vSphere is a viable choice for certain workloads, particularly if they are legacy workloads, or rely on features inherent to a product which has evolved to service environments which are becoming increasingly rare today, it no longer is the only meaningful hypervisor option. It is for this reason that datacenter operators globally have adopted a multi-hypervisor approach to operations and those new workloads are increasingly deployed using XenServer rather than vSphere. Feature vSphere 5.1 XenServer 6.2 Bare-metal hypervisor Yes Yes Cluster management Requires vCenter Yes Highly available cluster management Requires vCenter and vCenter Heartbeat Yes Maximum cluster size 32 16 VM density of at least 200 Yes Yes Shared storage options NFS, iSCSI, HBA, VAAI NFS, iSCSI, HBA, StorageLink Live storage migration Yes Yes Local disk cache of templates Yes Yes Disaster recovery services Requires SRM Yes Live VM migration Yes Yes Cross cluster live VM migration Yes Yes Memory over-commit Page sharing, ballooning, host page swap Ballooning NetFlow Requires virtual distributed switch Yes Port mirroring Requires virtual distributed switch RSPAN IPv6 Yes Yes Network encapsulation options None GRE High availability for host infrastructure Yes Yes Operating system support Provides support for legacy versions Currently supported by vendor GPU access Virtual GPU Exclusive with full DirectX10 and OpenGL support
  • 15. White Paper I Citrix XenServer Comparison of XenServer 6.2 and vSphere 5.1 About Citrix Citrix (NASDAQ:CTXS) is the cloud company that enables mobile workstyles—empowering people to work and collaborate from anywhere, easily and securely. With market-leading solutions for mobility, desktop virtualization, cloud networking, cloud platforms, collaboration and data sharing, Citrix helps organizations achieve the speed and agility necessary to succeed in a mobile and dynamic world. Citrix products are in use at more than 260,000 organizations and by over 100 million users globally. Annual revenue in 2012 was $2.59 billion. Learn more at www.citrix.com. ©2013 Citrix Systems, Inc. All rights reserved. Citrix® , XenServer® , XenDesktop® , XenCenter® , Xen® , XenMotion™ and CloudPlatform™ are trademarks or registered trademarks of Citrix Systems, Inc. and/or one or more of its subsidiaries, and may be registered in the United States Patent and Trademark Office and in other countries. All other trademarks and registered trademarks are property of their respective owners.

×