Tips on Designing Horizon View Desktops

Main layer:

This layer includes an optimized operating system configured and created based on your business needs and requests. Agents like View Agent and AV (Antivirus) are installed on the original image. It's up to you to decide what programs should be on the Image Base. Programs must meet the needs of the organization or be installed on the basis of your desired pool. Software packages such as Microsoft Office and PDF reader and browsers, etc. Note the nature of the software. There are programs that can not be virtualized by ThinApp. Some of these programs communicate directly with the system drivers or run in shell. These categories of apps should be installed on the base image. If you use linked clones or instances, you need to be sure of the correctness of your base image. When the base image is healthy, you can safely create hundreds of healthy desktops with great speed. Do not forget that if you have a problem with your original image, you will encounter hundreds of corrupted desktops!

Application:

Specify the strategy for the programs. This strategy includes the details of the delivery of the program to the user. Some programs are introduced as the main operating system, while others may use ThinApp or App Volume. (We'll talk about the two later), Workspace ONE can also provide your applications as a Web-base portal. The methods for delivering programs to the user are very different. Do not forget that there are methods in Citrix XenApp or SaaS-based that are used on other platforms.

User Profiles and Management Context:

Finally, take a look at the presentation with Persona or UroProfile on the desktop. Think of it as having a person can have everything on a personal desktop. For example, the program settings, the contents of all the documentation and icons available on the desktops are all. There are many ways to get these things. For example, redirect profiles, Group Policy, View Persona Management, VMware UEM and other third party applications), such as LiquidWare Lab's Profile Umity, wherever possible, use simple solutions and third party production in the direction get comfortable with things. By using the methods described, you reduce system overhead. Depending on the level of optimization intended, users may have different requirements for using products in order to optimize View Persona Management and Redirect user profiles by Group Policy to a file server. User profile issues are received by Group Policy after being logged in to VDI and placed on the user's virtual desktop. A file is called from the profile and cached on the local desktop for use. Any changes to the profile are stored locally on the VDI desktop. But uploaded to the file server at certain intervals and goes back to it.

Disaster Recovery and backup:

As with any proposed solution, Backup and Disaster Recovery discussions are one of  the  most  important  options. With Horizon View, you have to make backups of different parts. Below is a general reference to these.

Backup and recovery options: In the Viewer, there are some basic things that you should surely have to make a backup of. These are:

* View Connection Servers

* View Security Servers

* Microsoft Lightweight Directory Service

* View Composer Database

* vCenter Database

* vCenter

* File servers containing ThinApp and View Persona Data

* Golden images

* Full clone and persistent desktop images

As you can see, there are a lot of things that you need to take back to make sure your layers of protection are safe and reliable. Specify the backup scheduler through Horizon View Administrator. This section contains backup scheduling settings from LDAP and View Composer Database. This backup is taken from the View Connection server.

C:\Program data\VMWare\VDMbackups 

Make sure the backup files are organized in a regular external storage space. Our strong recommendation is to back up all of the server's captions by a trusted software. Programs such as Veeam Backup & Replication or VMware Data Protection are approved. As mentioned earlier, protecting and maintaining Full Clones using the Horizon Mirage.

Disaster Recovery Option:

Due to the integration of Horizon View with View Composer and vCenter Server, the replication from the operating environment with a DR site is not recommended. Similarly, Horizon View is not supported for use with the VMware SRM feature. There are several ways to set up DR in the Horizon View. We just explain a case. First, important components of the Horizon View environment should be identified. Often, the following are important:

* User's Persona

* ThinApp application

* Golden images

* Full clone desktops

If the above components are in DR, then you can declare that your View environment is fully recoverable in the event of a Disaster. The DR site is configurable with a proprietary view and has all the components needed, such as vCenter Server, View Connection Server, and so on. Note that during the disaster, specify the items you need to restore quickly to minimize the incidence of your organization's business.

Things like User's Persona, ThinApp apps, and App Volume are all on file servers. You can use significant technologies such as Microsoft Distributed File System Replication (DRFS) or similar. This feature allows you to have a copy of the data in both operating and DR sites. You can even make an OVF such as the Golden Image and send it to DR. You can easily recompile Pool Pools through the Golden Image on the DR site. Depending on the nature of the Full Clone desktop, which is like standard VMs, you can easily directly replicate the operation between the SANs and transfer it from the site to the DR site. Finally, think about how to connect users in case of an error or fail on the DR site.

The simplest connection mode for a user is by entering the server's address in the browser or through the Horizon Client application. You can use the Load Balancer to direct the address to the DR site. As you can see, making DR site in Horizon View is not a straightforward solution. But when everything is out of reach, you can retrieve the items with this level of prediction and forecasting.

Do not forget that you are a strong venture partner named VMware. It's possible for your desktops to be presented as a service called Horizon Air Cloud-Hosted Desktop and Apps Service.

Example of real scenarios: 

The following design is based on a fictitious company called PVO. The company needs to set up a VDI solution. In the below-topology diagram, the status of the current network and the situation is determined:

The company has three offices: a headquarters, two remote sites (outside of the company), remote sites for the software development team. The company has two data centers like the one above. At each data center, there is the ability to stream the data center as a backup if an unexpected event occurs.

Needs of users:

In this example, we conducted an assessment for collecting information, according to which the total number of users is 5,750. A general overview of the user's usage model, its needs,  and  the  location  of  each  user  is specified. More details are shown in the table below. We currently have information on the types of users and their needs.

Application Developer:

In the scenario we've shown, there are two remote sites, but from the Nettop topology, you can see that the sites are connected to Data Center B using WAN. They only use desktops that need to have an Office program and do not have access from the outside. In this scenario, we have created a dedicated pool that has persistent desktops. Another feature we can configure is the floating mode with a non-persistent desktop and the use of App Volume so that we can give users the ability to install programs on the desktop. Depending on the nature of the users, each desktop user needs a specific RAM and CPU.

Office Worker: 

These users are doing public tasks and having a decent desktop for them is enough. (2 CPU & 2 GB memory) These desktops are potentially the perfect candidate for desktop floating, non-persistence. Applications like Office are based on the base image of these desktops, and each side app is provided through App Volume.

Contractors: 

This group of users, due to the nature of the work they do, is unclear on what program they are working on. So it's a bit difficult to choose a specific configuration for this category of users. It's best to always estimate the most counts on the system and assign the desktop according to the same predictions. Note that this group of users needs access from outside.

Engineers:

There are two teams in the engineering unit. The team 1, which has a lot of work with CAD software, is a capable designer, and team 2 who has more training requirements and lighter tasks with the system. Team 1 requires a high- level graphics card with strong releases to run the CAD program without problems. While team 2 does not need to be stated. Of course they differ from standard users and will have more needs than these users. The NVIDIA Accelerated Technology Corner is the perfect solution for the engineering team. As discussed earlier, this solution requires dedicated hardware.

In this design, all office and sales staff are in the same pool desktop. Now, if any of these groups need their own programs, we will give them the ThinApp solution. Using Pod and Block architecture is an advantage. We also use this advantage in this scenario. We create a Pod in Data Center A and one in Data Center B. This will reduce the complexity of the network and lead the scenario to the ease of problem solving and understanding of the subject. Of course, do not forget that CloudPod comes with simplicity by default. Developers move between sites, so we create a generic pool for these users. We should add that we also have a dedicated pool for these users. We can implement floating desktops and use app volumes.

Now that we have a general idea about Pool, we can begin with the Pod design and management blocks.

Estimated Desktop Blocks:

At Data center A, we have about 5,500 virtual machines with Pod1. 2,000 virtual desktops are supported in each block. Given the status quo, we need to have three configurations in each block, with around 1,800 desktops per block. At Data center B, we have about 250 virtual desktops, so a block of our work will run. How many desktop computers do we have  on each server? For this example, for Office users, we put 98 virtual desktops on each   host. For large processing and engineering tasks, we consider 50 virtual desktops for each host. Do not forget that users of the engineering sector need dedicated GPU hardware. In this situation, we will consider a cluster for each section. The number of hosts needed for pod1 is something like the following diagram. Note that users with any amount of use in this example are hosted on a server with two CPUs with 3 GHz operating frequency plus 10 Core.

Pod2 in the Data Center B includes virtual machines for applications developed by the development team, and is similar to the one shown below:

Using Pod1, we have the ability to enter a large number of hosts in the cluster, but the number of hosts on a cluster is 32. So it's best to create two clusters for each desktop with a number of servers that are distributed between the two clusters. One of the clusters is separated and it is the duty of users to support graphics.

The design we considered is something like the following diagram:

Estimate Storage Needs:

As previously explained, it's possible to calculate the IOPS you need. In this scenario, we see a total of 30 IOPS for each virtual machine. 70/30 read / write ratio in a RAID5 with a capacity of 10GB. Regarding variables, we can begin the process as follows:

If you use ThinApp or App Volume in your virtual platform, be sure to calculate the exact capacity and performance required.

Manager Size Blocks:

Configuration and Component Infrastructure are as follows:

Network Requirements:

All one-to-one design and design was made and now it's time for one of the most important elements in this infrastructure. The picture below depicts the status of the network in this design:

By completing this section, the theory of content has ended and I hope you have a general view of the Horizon View infrastructure for you. In the future, we start the operational and installation topics and actually enter the laboratory environment. Hope to accompany us as always.

You may imagine that it's all about designing once and for all! But you are hard on the wrong side. In fact, the novice has started. Your VDI solution, without desktops, is just a virtual infrastructure, desktop design and functionality is important along with successful implementation. There are plenty of options to choose from. You should have a decent design for creating desktops using Horizon View.

Thin Clients:

The important thing to note is that not all thin clients are created in the same way. You need to make sure that to use any item, you need to measure the needs of Thin Clients and select the right thin ones. How to manage Thin Clients is one of the key issues.

Pool Design:

Designed to design desktops that are grouped around in a pool based on similarities. To do this, you should use the information collected in the previous steps. This process is obtained by evaluating the desktops and other sources that you use when you start the design, and determine which desktop polls should be created. When the data is analyzed, you will notice the similarities between the programs you are using and decide how to draw pools based on the information. Your priority is to keep as small as possible the pools and not to be larger so big as the pools make it harder to recompose them and will negatively affect the performance. As you can see, balancing pools are one of the key issues in the implementation phase. We will talk about that in the next section.

Estimate (size) Desktops:

The following list contains some of the basics for estimating desktops. This information is gathered from the published VMware dossier and is based entirely on user experiences. For desktops that are built around programs, the solution is vital and vital. As:

Estimates of Servers to Host Desktops:

One of the most frequently asked questions in all projects is the number of virtual desktops that can be created on a host and serve the user. Or, for example, for each virtual desktop, how many Core CPUs should be considered, as in the previous routine, our only answer is: it depends!

• First, the CPU usage depends on how much your desktop needs. This is also directly related to the multiplicity of programs, so the answer to this question is only possible from the assessment of the data.

• Second, obviously, the number of desktops we can put on a server is directly related to  their repositories. For example, we consider the RAM and CPU for hosts. It's usually hard to choose between price / performance for an employer! Because these two elements have an inverse relationship.

For this part, we can not provide a precise evaluation that can be cited as solid and acceptable, but we use some assumptions and provide CPU-specific requirements for all types of applications. Users who are grouped in light consumer category, medium consumers and heavy consumers. The basis of our computing is on a standard status, a rack-mount server number that is configured with two Intel Xeon E5-2660 CPUs that have 2.6 GHz and 10 cores per CPU, which is a total of 20 cores per host.

In the computational example below, keep in mind that there are fewer than two core hosts, since the Hyperspoker layer (ESXi) itself also needs a CPU repository to execute the executables.

Light User:

The CPU utilization rate is around 300 MHz. At peak time, adding some solutions is an added benefit for you. For this example, we add 10% to 300 MHz. A profile of this type of user can be a person who works in the call center, or is an admin or user that the web collects. These desktops can be unused and consumed at a low rate, and only one or more programs run on them. CPU work requirements are achieved with the following quick calculations:

In this scenario, the user uses the standard server described in the previous sections, and it's about 17 users per Core.

Medium User:

Usual use of about 500 MHz of CPU solutions, plus 10%. This kind of user can have data entry, doctors, students, users of Microsoft programs or a helpdesk in this grouping. These desktops are used extensively in business offices and do not consume much. We use the following method to calculate the amount of CPU consumed:

In the scenario, the user defined by the server uses the standard previously described, and you can have around 85 virtual desktops, which give 4 users per Core.

Heavy User:

Usual use is about 750 MHZ of CPU resolution. Plus 10 percent. This user model can be things like system development, administrator, IT employee, database administrator, or engineering unit. There are plenty of times on the desktop and usually these desktops are used throughout office hours. The CPU usage rate is estimated by the following formula:

In the scenario, a user defined by the standard servers used in the above describes, you can have around 65 virtual desktops giving you 3 users per Core.

Notable Points in RAM Estimates:

Estimating the amount of RAM used by desktops is much easier than the CPU, although the balance between servers must be respected. If you have a virtual desktop that needs 2 GB of memory and look at it with the light user, you can create 141 virtual desktops based on previous examples. This means that the server has a storage capacity of 282 GB for hosting a virtual desktop, as well as the necessary memory for running a hyperlink.

Due to the choice of server hardware, it may not be possible to add this amount of memory to the server, or it is always with you to worry about problems with the development of desktops and the lack of hardware support on the server. Do not forget to never over-commit when sizeing and configuring the memory  for  a  virtual  machine. This will cause the swap file to be stopped and has no good consequences, such as a dramatic downgrade.

Compare Linked Clone and Full Clone:

There are two types of desktop images to use. Linked clone or full clone. In short, linked clones are made by replicating a golden image inside a thin provisioned replica. This VM has a size similar to that used inside the Golden Image. All the reads are from this VM, and the number of desktops  inside the pools does not matter at  all. Each desktop has a delta disk to write data on it that continues to grow until it is recomposed, refresh, or deleted on the linked clone. A full clone is exactly what is present and displayed, a copy of its own golden image and occupies space as much as its capacity. 

If storage space is important to us, we should use linked cloned. There are important points in using Linked Clones, and with this feature you will lose some potential features, such as:

* VMware Mirage integration:

When the linked clone mode is awesome from the outside and gives you the ability to be extensible, you're certainly tempted to use it, but it's not always a great strategy. When using the Full Clone design, you should carefully consider the design of the Storage. There are a lot of storage makers that offer re-duplication, compression, and more, but the choice should be to increase performance and performance.

Persistent versus non-persistent:

When deciding whether to use linked clones or full clones, you need to specify whether you want to use a persistent or non-persistent disk for desktops. With persistence desktops, the user has a dedicated desktop, whether manually or automatically. And when it's connected to the desktop pool, it's redirected to its desktop. With non- persistent desktops, users navigate to the pool desktop. In many designs, there are non-persistent linked clone desktops configured and full desktop clones are persistent Are set. But this is not always the case, and it varies according to your design.

It is recommended to use non-persistent desktops that are built upon request for use of linked clones or instant clones, whenever possible.

User profiles can be presented with View Persona Management and UEM. Group Policy is provided for configuring desktops and app volumes. If the design is appropriate, you can create the easiest way to refresh your desktops with minimal impact on users. If your design is such that it's not possible, try revising it because it's very functional and important. If you have implemented the Desktop Persistence mode, use the Horizon Mirage solution to protect and maintain the features listed in the Full Clone Persistence Desktop, depending on the data values or settings you have set.

Offline Desktop:

Desktops that work when there is no connection to servers (whether they are connected via LAN or WAN). In the previous version, this feature was used. That way the server will move a copy of the user's desktop so that users can use the system offline. When the connection is made, you can sync the desktop changes in the virtual environment. The process of doing this is not very complicated. But downloading and uploading files is very time consuming for users. You should also note that offline mode is often used during PoC implementation. It's rarely seen that this functionality is operational in the operating environment.

Build a hybrid desktop:

Designing a flexible desktop is the ability to build and personalize different layers of the desktop. Layers in this area are provided as part of the desktop such as OS, Persona plus apps.


Want to download this blog as a PDF document, click the links below:
https://drive.google.com/file/d/1nz65h8BeZFyiE4zAo4cH_-iMNhL35-Ox/view
https://drive.google.com/file/d/13qaBXsyPE3Q6pk9e1h5_cTEBROO3QghM/view





Abd El-Rahman Oreiby
Senior Data Center Engineer
Al Thuraya Security Egypt
www.abdelrahmanoreiby.weebly.com