Home > Blogs > VMware Consulting Blog > Tag Archives: Eric Monjoin

Tag Archives: Eric Monjoin

Planning a DRP Solution for VMware Mirage Infrastructure

Eric_MonjoinBy Eric Monjoin

When I first heard about VMware Mirage in 2012—when Wanova was acquired by VMware and Mirage was integrated into our portfolio—it was seen more as a backup solution for desktops, or a tool for migrating from Windows XP to Windows 7. And, with an extension, it was possible to easily migrate a physical desktop to a virtual one, so most of the time when we had to design a Mirage solution, the question of DRP or HA came up as, “Why backup a backup solution?” Mirage was not seen as a strategic tool.

This has changed, and VMware Mirage is now totally integrated as an Extended UNIX Code tool to manage user desktops through different use cases. Of course, we still have backup and migration use cases, but we also have more and more customers who are using it to ensure desktops conform to IT rules and policies to ensure infrastructure reliability for Mirage. In this post we’ll describe how to design a reliable infrastructure, or at least give the key points for different scenarios.

Let’s first have a look at the different components of a Mirage infrastructure:

EMonjoin Basic Mirage Components

Figure 1 – Basic VMware Mirage Components

  1. Microsoft SQL Database—The MS SQL database contains all the configurations and settings of the Mirage infrastructure. This component is critical; if the Microsoft DB fails, then all Mirage transactions and services—Mirage Management Server service and Mirage Server service—
  2. SMB Shared Volumes—These could be any combination of NAS, Windows Server, desktop files, apps, base layers, or USMT files—all stored on theses volumes (except small files and meta-data.)
  3. Mirage Management Server—This is used to manage the Mirage infrastructure, but also acts as a MongoDB server instance on Mirage V5.4 and beyond. If it fails, administration is not possible until a new one is installed, but there’s no way to recover desktops since small files stored in the MongoDB are no longer available.
  4. Mirage Server—This is used by Mirage clients to connect into. Often, many Mirage servers are installed and placed behind load-balancers to provide redundancy and scalability.
  5. Web Management—A standard Web server service can be used to manage Mirage using a Web interface instead of the Mirage Management Console. The installation is quite simple and does not require extra configuration, but note that data is not stored on the Web management server.
  6. File Portal—Similar to Web management above, it is a standard Web server service used by end users to retrieve their files using a Web interface, and again, data is not stored on the file portal server.
  7. Mirage Gateway—This is used by end users to connect to Mirage infrastructure from an external network.

Now, let’s take a look at the different components of VMware Mirage and see which components can be easily configured for a reliable and redundant solution:

  • Mirage Management Server—This is straightforward, and actually mandatory, because with MongoDB, we need to install at least one more management server, and the MongoDB will synchronize automatically. The last point is to use a VIP on a load-balancer to connect to, and to route traffic to any available management server. The maximum number of Mirage management servers is seven due to MongoDB restrictions. Keep in mind that more than two members can reduce performance as you must wait for acknowledgement from all members for each writing operation to the database. The recommended number of management servers is two.
  • Mirage Server—By default we install at least two Mirage servers or more; one Mirage server per 1,000 centralized virtual desktops (CVDs) or 1,500 (depending on the hardware configuration), plus one for redundancy and use load-balancers to route client traffic to any available Mirage server.
  • Web Management and File Portal—Since these are just Web applications installed over Microsoft IIS servers, we can deploy them on two or more Web servers and use load-balancers in order to provide the required redundancy.
  • Mirage Gateway—This is an appliance and is the same as the previous component; we just have to deploy a new appliance and configure load-balancers in front of them. Like the Mirage server, there is a limitation concerning the number of connections per Mirage gateway, so do not exceed one appliance per 3,000 endpoints, and add one for resiliency.

Note: Most components can be used with a load-balancer in order to get the best performance and prevent issues like frequent disconnection, so it is recommended to the set load-balancer to support the following:

  • Two TCP connections per endpoint, and up to 40,000 TCP connections for each Mirage cluster
  • Change MSS in FastL4 protocol (F5) from 1460 to 900
  • Increase timeout from five minutes to six hours

Basically, all Mirage components can be easily deployed in a redundant way, but they rely on two other external components, both of which are key: the Microsoft SQL database and the SMB shared volumes, both of which work jointly. This means we have to pay special attention to which scenario is privileged:

  • Simple backup
  • Database continuity
  • Or full disaster recovery

The level of effort required is not the same and depends on the RPO/RTO required.

So let’s have a look on the different scenarios available:

  1. Backup and RestoreThis solution consists of performing a backup and restore of both Microsoft SQL database and storage volumes in case a major issue occurs on either component. This solution seems relatively simple to implement and looks inexpensive as well. It could be implemented if the attending RPO/RTO is not high. In this case, you have a few hours to restore the service, and there is no need to restore data that has been recently backed up. Restoring lost data backed up in the last couple of hours is automatic and quick. Remember, even if you lose your Mirage storage, all data is still available on the end-users’ desktop; it will just take time to centralize them again. However, this is not an appropriate scenario for large infrastructures with thousands of CVDs as it can take months to re-centralize all the desktops. If you want to use this solution, make sure that both the Microsoft SQL database and the SMB volumes are backed up at the same time. Basically, this means stopping Mirage services, performing a backup of the database using SQL Manager to get a snapshot of the storage volumes, and stopping MongoDB from backing up files. In case of failure, you have to stop Mirage (if it has not already done that by itself) and restore the last database backup and revert to the latest snapshot on the storage side. Keep in mind you must follow this sequence: first, stop all mirage services, and then the MongoDB services.
  1. Protect Microsoft SQL DatabaseSome customers are more focused on keeping the database intact, and this implies using Microsoft SQL clustering. However, VMware Mirage does not use ODBC connections, so it is not aware of having to move to a different Microsoft SQL instance if the main one has failed. The solution resides in using Microsoft SQL AlwaysOn technology, which is a combination of the Microsoft SQL clustering and the Microsoft failover cluster. It provides synchronization between “non-shared” volumes among nodes, but is also a virtual IP and virtual network name that will move to the remaining node in case of disaster, or during a maintenance period.
  2. Full Disaster Recovery/Multisite Scenario—This last scenario concerns customers who require a full disaster recovery scenario between two data centers with a high level of RPO/RTO. All components are duplicated at each data center with load-balancers to route traffic to a Mirage management server, Mirage server, or Web management/File portal IIS server. This implies using the second scenario in order to provide Microsoft SQL high availability, and also to perform a synchronous replication between two storage nodes. Be aware that synchronous replication can highly affect storage controller performance. While this is the most expensive of the scenarios since it requires extra licenses, it is the fastest way to recover from a disaster. An intermediate scenario could be to have two Mirage management servers (one per data center), but to shut down Mirage services, and replicate SQL database and storage volumes during the weekend.

EMonjoin Multi-Site Mirage

Figure 2 – E.g. Multi-Site Mirage Infrastructure

For scenario two and three, the installation and configuration of Microsoft SQL AlwaysOn in a VMware Mirage infrastructure is explained further in the white paper.


Eric Monjoin joined VMware France in 2009 as PSO Senior Consultant after spending 15 years at IBM as a Certified IT Specialist. Passionate for new challenges and technology, Eric has been a key leader in the VMware EUC practice in France. Recently, Eric has moved to the VMware Professional Services Engineering organization as Technical Solutions Architect. Eric is certified VCP6-DT, VCAP-DTA and VCAP-DTD and was awarded vExpert for the 4th consecutive year.

Manually Uploading Dedup Files on Mirage Branch Reflector

Eric MonjoinBy Eric Monjoin

Mirage is a great desktop administration tool; it not only makes it easier to backup and restore user data easily and conveniently via a web interface, or backup all or part of the system by the IT department, but it also ensures the compliance of the user’s workstation by sending and applying operating system or applications updates through “Base Layers” and “Application Layers.”

One problem that arises for IT managers is how to update workstations located at remote locations and connected to the data center via a low-bandwidth network or saturated by other network services.

Therein Mirage provides a first solution by using “Branch Reflectors,” which can be either a PC dedicated to this task or any PC on the remote site as long as it has sufficient disk space and it stays on constantly to receive all Base Layers and Application Layers. This is used to apply updates to workstations located on the same local network, thus avoiding all desktops receiving tedious updates from central Mirage servers.

But sometimes—despite the use of reflector Branch—it appears that the necessary bandwidth is too small for an update, even if it is for only one desktop. The solution that will be developed—which is shown below—explains how to manually update a Branch Reflector from extracted Base Layers or Application Layers.

So, the first thing to do is export layers. This is achieved using a command line from the management servers, but before exporting this layer you need to know its ID and version.

From the MMC or the Web Management Console, look at the Image Composer\Base Layer or Image Composer\App Layer and note the ID and Version of the layer you want to extract.

EMonjoin Dedup 1

 

Then, open a command line in your Mirage Management Server or Mirage Server and run the following command:

# “c:\Program Files\Wanova\Mirage Management Server\Wanova.Server.Tools.exe” LayerExtract \\MirageStorage ID Version Path Target_Path

EMonjoin Dedup 2

Once you export the layers, copy all files to an appropriate storage device, such as an external HDD or USB stick, send it or bring it to your remote location, and copy all files to a folder in your branch reflector.

Note: If the branch reflector is not dedicated but runs on a user desktop, I would recommend hiding the folder where you put the files.

In the meantime, we have to configure the factory policy to scan for this folder so Mirage will know that files are already on the Branch Reflector and will not try to push them again.

  1. On the Mirage Management Server, open a Command Prompt and type the following command:
# “c:\Program Files\Wanova\Mirage Management Server\Wanova.Server.Cli.exe” 127.0.0.1
  1. In the CLI type: GetFactoryPolicy c:\factory_policy.xml
  1. Open and edit the file: c:\factory_policy.xml
  1. Find the “ExtraDedupArea” area and modify the section to add the directory used to receive all dedup files on the Branch Reflector:
  <ExtraDedupArea>
    <IncludeList>
      <Directory path="%windows%.old" recursive="true" filter="*" />
       <Directory path="%systemvolume%\MirageDedup" recursive="true" filter="*" />     <<= Line added
    </IncludeList>
    <ExcludeList />
  </ExtraDedupArea>
  1. Import the new rules to add them in the Factory Policy by typing in the CLI: setFactoryPolicy c:\factory_policy.xml

This generally needs to be done only once, unless you have a really big update with new applications to push to desktops.


Eric Monjoin joined VMware France in 2009 as PSO Senior Consultant after spending 15 years at IBM as a Certified IT Specialist. Passionate for new challenges and technology, Eric has been a key leader in the VMware EUC practice in France. Recently, Eric has moved to the VMware Professional Services Engineering organization as Technical Solutions Architect. Eric is certified VCP6-DT, VCAP-DTA and VCAP-DTD and was awarded vExpert for the 4th consecutive year.

Use Horizon View to Access Virtual Desktops Remotely – Without a VPN

 

By Eric Monjoin and Xavier Montaron

VMware Horizon View enables you to access a virtual desktop from anywhere, anytime. You can work remotely from your office or from a cybercafé, or anywhere else as long as there is a network connection to connect you to Horizon View infrastructure. It’s an ideal solution – but external connections can be risky.

So, how do you protect and secure your data? How do you authorize only some users—or groups of users—to connect from an external network without establishing a VPN connection?

You can achieve this by relaying into an external solution like F5 Networks’ BIG-IP Access Policy Manager (APM). It can perform pre-authentication checks to end-points based on criteria like user rights, desktop compliancy, antivirus up-to-date, and more. Or, you can simply use the built-in capabilities of Horizon View, which is perfect if you are a small or medium company with a limited budget.

There are two ways to achieve this with Horizon View:

  •  Pool tagging
  •  Two-factor authentication

Pool Tagging

Pool tagging consists of setting one or more tags on each View Connection Server (see Figure 1) and restricting desktop pools using those tags to specific brokers (see Figure 2).

EMonjoin Figure 1

Figure 1. View Connection Server tagging

In the following example a tag “EXTERNAL” has been created for brokers paired with a View Security Server, and it is dedicated to an external connection with the tag “INTERNAL,” which has been created for brokers dedicated to internal connections only. Only desktop pools assigned with the “EXTERNAL” tag will be available, and will appear in the desktop pool list while connected to a broker used for external connections.

EMonjoin Figure 2

Figure 2. Desktop pools tagging

As shown in Table 1, if you fail to restrict a pool with a tag, that pool will be available on all View Connection Servers. So, as soon as you start using tags, you have to use tags for all of your desktop pools.

Connection to View Connection Server with following tags Desktop pools with following restricted tag set Pool appears in desktop pools list
EXTERNAL EXTERNAL YES
EXTERNAL INTERNAL NO
INTERNAL EXTERNAL NO
INTERNAL INTERNAL YES
INTERNAL or EXTERNAL INTERNAL and EXTERNAL YES
INTERNAL or EXTERNAL “None” YES

Table 1. TAG relationships between VCS and desktop pools

Keep in mind that when using tags, it is implied that the administrator has created specific pools for external connections, and specific pools for internal connections.

 

Two-Factor Authentication

The other method when using Horizon View is two-factor authentication. This requires two separate methods of authentication to increase security.

The mechanism is simple; you first authenticate yourself using a one-time password (OTP) passcode as seen in Figure 3. These are generated approximatively every 45 seconds depending on the solution provider. If the provided credentials are authorized, a second login screen appears (see Figure 4) where you enter your Active Directory login and password used for single sign-on to the hosted virtual desktop.

EMonjoin Figure 3

Figure 3. OTP login screen

EMonjoin Figure 4

Figure 4. Domain login screen

 

The advantages with this solution are:

  • Enhanced security You need to have the OTP passcode (the user’s token) and must know the user’s Active Directory login and password.
  • Simplicity There is no need to create two separate desktop pools – one for external connections and another for internal connections.
  • You can be selective Distribute tokens only to employees who require external access.

The most commonly and widely implemented solution is RSA Security from EMC (see below), but you can also use any solution that is RADIUS-compliant.

For more detailed information you can read the white paper “ How to Set Up 2-Factor Authentication in Horizon View with Google Authenticator.” It describes how to set up FreeRADIUS and Google Authenticator to secure external connections, and authorize only specific users or groups of users to connect to Horizon View. This solution was successfully implemented at no cost at the City Hall in Drancy, France, by its chief information officer, Xavier Montaron.

 

Sources:

F5 BIG-IP Access Policy Manager 

http://www.f5.com/pdf/white-papers/f5-vmware-view-wp.pdf

https://support.f5.com/content/kb/en-us/products/big-ip_apm/manuals/product/apm-vmware-integration-implementations-11-4-0/_jcr_content/pdfAttach/download/file.res/BIG-IP_Access_Policy_Manager__VMware_Horizon_View_Integration_Implementations.pdf

RSA SecureID

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2003455

https://gallery.emc.com/servlet/JiveServlet/download/1971-24-4990/VMware_Horizon_View_52_AM8.0.pdf

 

 


Eric MonjoinEric Monjoin joined VMware France in 2009 as PSO Senior Consultant after spending 15 years at IBM as a Certified IT Specialist. Passionate for new challenges and technology, Eric has been a key leader in the VMware EUC practice in France. Recently, Eric has moved to the VMware Professional Services Engineering organization as Technical Solutions Architect. Eric is certified VCP6-DT, VCAP-DTA and VCAP-DTD and was awarded vExpert for the 4th consecutive year.


Xavier_MontaronXavier Montaron owns a Master in Computer Science from EPITECH school and has a strong developer background. He joined Town Hall of Drancy during December 2007 in the CIO organization, and became the actual CIO since 2010. Town Hall of Drancy has been a long-time IT innovator and user of VMware technology, both for infrastructure servers as well as for VDI, where all desktops have been fully virtualized since 2011 with Horizon View. Town Hall of Drancy recently has decided to externalize all servers and VDI infrastructure and are now hosted by OVH, a global leader in internet hosting based in France.