Software-Defined Disaster Avoidance – The Proper Way

VMware vSAN metro cluster implementation

PREVIOUS      NEXT

Software-Defined Disaster Avoidance – The Proper Way

VMware vSAN metro cluster implementation

In my first blog post, the topic I write about, Software Defined Disaster Avoidance – The Proper Way, is a story that we at Braineering have successfully turned into reality twice so far. The two stories have different participants (clients), but they both face the same fundamental challenges. The stories occur in two distinct periods, the first in 2019 and the second one in 2020.

 

Introduction

 

Both clients are from Novi Sad and belong to the public sector. Both provide IT products to many public services, administrations, and bodies without which life in Novi Sad would not run smoothly. Over 3000+ users use IT products and services hosted in their Datacenters daily. Business applications such as Microsoft Exchange, SharePoint, Lync, MS SQL, and Oracle are just some of the 400+ virtual servers that their IT staff takes care of, maintains, or develops daily.

 

Key Challenges

 

At the time, both users’ IT infrastructure was more or less the standard IT infrastructure we see in most clients. It consists of a primary Datacenter and a Disaster Recovery Datacenter located at another physically remote location.

The primary and DR site is characterized by traditional 3-Tier architecture (compute, storage, and network) Figure 1.

The hardware located on the DR site usually operates using more modest resources and older generation equipment than the primary site. It is replicated to a smaller number of the most critical virtual servers. Both clients had storage base replication between Datacenters, and VMware SRM was used to solve automatic recovery.

 

Figure 1.

 

Even though the clients are different, they had common vital challenges:

  • Legacy hardware 
    • different server generations: G7, G8, G9
    • storage systems End of service life.

 

  • Inability to keep up with the latest versions because of legacy hardware.
    • vSphere
    • VMware SRM
    • Storage OS or microcode

 

  • Weak and, for today’s standards, modest performance
    • 8 Gb SAN, 1Gb LAN
    • Slow storage system disks (SATA and SAS)
    • Storage system fragmentation
    • vCPU: pCPU ratio

 

  • Expensive maintenance – again due to legacy hardware
    • Refurbished disks
    • EOSL (End of service life), EOGS (End of general support)

 

  • Limited scalability, the expansion of CPU, memory, or storage resources

 

When new projects and daily dynamic user requests to upgrade existing applications are also considered, both clients were aware that something urgent needed to be done about this issue.

 

Requirements for the Future Solution

 

The future solution was required to be performant, with low latency and easy scaling with high availability. The goal is to reduce any unavailability to a minimum with low RTO and RPO. The future solution must also be simple to maintain, and migration, i.e., switching to it, should be as painless as possible. If possible, remove/reduce overprovisioning and long-term planning and doubts when the need for expansion (by adding new resources) arises.

And, of course, the future solution must support all those business and in-house applications hosted on the previous IT infrastructure.

 

The Chosen Solution

 

After considering different options and solutions, both users eventually opted for VMware vSAN. As the user opted for vSAN as their future solution in both cases, we at Braineering IT Solutions suggested vSAN in the Stretched Cluster configuration to maximize all the potential and benefits that such a configuration brings. To our delight, both users accepted our proposal.

 

Figure 2.

 

Stretched Cluster

 

What is the vSAN Stretched Cluster? It is an HCI cluster that stretches between two distant locations. (Figure 2)

The chosen future solution fully meets all the requirements mentioned above: it supports all clients’ business and in-house applications. In the All-Flash vSAN configuration, they can deliver a vast number of low-latency IOPS. The Scale-Up and Scale-Out architecture allow you to quickly expand resources by adding additional resources to existing nodes (Scale-Up) or adding new nodes to the cluster (Scale-Out).

It is easy to manage; everything is operated from a single vCenter. Existing backup and DR software solutions are supported and work seamlessly. And finally, as the most significant benefit of vSAN in the Stretched Cluster configuration, we have disaster avoidance and planned maintenance.

 

The benefits of the vSAN Stretched Cluster configuration are:

  • Site-level high availability to maintain business continuity.
  • Disaster avoidance and planned maintenance
  • Virtual server mobility and load-balancing between sites
  • Active-Active Datacenter
  • Easy to manage – a single vSphere vCenter.
  • Automatic recovery in the case of one of the sites’ unavailability
  • Simple and faster implementation compared to the Stretched cluster of traditional storage systems.

 

The Advantages of the Implemented Solution

 

The most important advantages:

New servers: The possibility of tracking new versions of VMware platform solutions. A better degree of consolidation and faster execution of virtual machines

Network 10Gbps: 10Gbps datacenter network infrastructure raises network communications to a higher level and degree of speed.

HCI: Scale-out platform, infrastructure growth by adding nodes. Compute, network, and storage resources are converted into building blocks. Replacement of existing storage systems with the vSAN platform in All-flash configuration.

SDDC: A platform that introduces new solutions such as network virtualization, automation systems, day-two operations …

DR site: New DR site dislocated to a third remote location. It is retaining existing VMware SRM and vSphere Replication technology.

Saving: Consolidation of all VMware licenses, consolidation of hardware maintenance of new equipment. Savings have been achieved in the maintenance of old HW systems.

Stretched cluster: Disaster-avoidance system that protects services and data, and recovers with automated procedures, even in a complete site failure scenario

 

The End Solution

 

Today’s IT infrastructure for both clients is shown in Figure 3.

 

Figure 3.

 

The preferred site and Secondary site, the Active-Active cluster, use one common stretched vSAN datastore. All I/O operations on this stretched datastore are synchronized. VMware Replication replicates the 25 most critical virtual servers on the DR site, and that replication is asynchronous. For automated and orchestrated recovery on the DR site in the event of a disaster on a stretched cluster, both users retained the solutions they had previously implemented, VMware SRM.

 

 

 

 

 

 

 

PREVIOUS      NEXT

Before you continue...
Subscribe to our monthly content digest and stay up-to-date on everything industry related!

Automation for Better Company Culture

Ansible Automation Platform Overview

PREVIOUS      NEXT

Automation for Better Company Culture

Ansible Automation Platform Overview

If we want to do it justice, we could not say that Ansible is just an IT automation platform. Also, if we say that it only saves time making repetitive tasks automated, we will reduce the significance of a project like this. Therefore, I like to say that every part of the IT industry should pay close attention to what Ansible offers.

Why is that? Well, Ansible provides a framework for significant improvements in company culture by eliminating points of misunderstanding between different teams, which leads to better communication and greater employee satisfaction over time. Development, testing, and QA teams, for example, being typical consumers of OS builds, can be sure that they are constantly working on proper base OS configurations while doing their jobs. And this is just the start of Ansible benefits.

 

 

So what is Ansible?

 

We can define it as a configuration management, deployment, and orchestration tool. It aims to be a more productive replacement for many core capabilities in other automation solutions. But, I think the most beneficial aspect of Ansible is portrayed in its endeavors to provide clear orchestration of complex multi-tier workflows, unify OS configuration, and unify application software deployment under a single framework.

 

Who can use Ansible?

 

I think anybody who likes elegant solutions on which you can build creatively. This simplicity is shown chiefly in its extremely low learning curve for administrators, developers, and IT managers. Ansible seeks simplicity in building descriptions of IT, and the goal is to make them easy to understand. This practically means that new users can be quickly brought into a new IT project. Likewise, if somebody is away from a project for a long time, longstanding automation content can be easily understood.

Let’s dive into a more in-depth explanation of Ansible architecture!

 

Platform Components

 

Ansible Engine – The engine that moves Ansible, relied on the massive, global community behind the Ansible project. It adds the capabilities and assurance from Red Hat to help businesses adopt automation at any scale across the organization.

 

 

Ansible Tower – The enterprise foundation of Ansible Automation Platform, helping organizations scale IT automation, manage complex deployments, and govern automation. It allows users to centralize and control their IT infrastructure with a visual dashboard, role-based access control, and more.

 

 

Content Collections – Make it easier for Ansible users to get up and running with precomposed roles and modules. Backed by a robust partner network of certified modules, requires less upfront work by the customer.

 

 

Automation Hub – The official location to discover and understand Red Hat-supported Ansible content and Ansible Certified Partner content. Find precomposed content written by Ansible Certified Partner organizations and quickly share that content with other users.

 

 

 

Automation Analytics – runs analytics across multiple Ansible Tower clusters, analyzing usage, uptime, and execution patterns across different teams running Ansible. Users can analyze, aggregate, and report on data around their automation and how that automation is running in their environment.

 

 

How does Ansible look from the inside?

 

The keyword here is Playbook. Ansible uses Playbooks to automate IT ecosystems. Essentially, Playbooks are YAML definition of automation tasks, and they describe how a particular segment of automation should be done, and it is human readable. Playbook clearly states what each individual component of your IT infrastructure should behave but still allows components to react to discovered information and to operate dynamically with one another. This responsiveness of Playbooks plays a significant role when you use Ansible for large-scale automation.

 

 

If we zoom in and look into Playbooks in more detail, they consist of plays that define automation across a set of hosts, and those set of hosts is called inventory. Each play is composed of various tasks that can target one, a few, or all the hosts in the inventory. A task is a call to Ansible modules, and a module is a small piece of code for doing a specific task. Ansible includes hundreds of modules, from simple configuration management to managing network devices and maintaining infrastructure on major cloud providers. This means that tasks can span from placing a simple configuration file to target machines, to spinning up the entire public cloud infrastructure.

Those included modules in Ansible have a specific idempotency feature, and that means that they check if a particular task needs to be done before executing it. It means that if, for example, we want to start a web server, the configuration is only done if the server is not already started. This ensures that the configuration can be applied repeatedly without side effects.

 

 

On top of this, the user can encapsulate the Playbook into a reuseable role. Thus, it can be used if a user wants to apply a standard configuration in different scenarios. I already talked about this at the beginning of this blog. This is the feature that can eliminate a point of misunderstanding between various teams in a company because you can provide the same server configuration role that can be used in the development, test, and production automation. Check out the Ansible Galaxy community site for thousands of customizable roles to build your Ansible Playbook.

 

Additional benefits: performance and security

 

Ansible has one differentiating feature that separates it from other automation tools: agentless architecture. It runs in a “push” model, so no software must be installed on remote machines to make them manageable. Ansible uses remote management frameworks that already exist natively on Linux, Unix, and Windows. And now, we have a performance benefit because no resources are consumed on managed machines when Ansible is not controlling them. This ensures Ansible is a go-to solution for automating large environments with concerns about stability or performance. Additionally, this increases security because only Ansible “modules” are passed to remote machines, and thus those machines can’t see or affect how other machines are configured.

Ansible features remoteness on an even higher level because it has elevated security on a higher level. It leverages sudo, su, and other privilege escalation methods on request when necessary. Additionally, it does not require dedicated users or credentials because it respects credentials user supplies when running Ansible. And this is important because those with access to the control server, for example, cannot make content be pushed out to remote systems without also having credentials on remote systems.

 

 

Advanced user?

 

If you intend to be an advanced user of Ansible and want to use it to automate and orchestrate complex environments, there are a set of features that can make your life easier. To name just a few, I like to mention the conditional execution of tasks, the ability to gather variables and information from the remote systems, the ability to spawn long-running asynchronous actions, the ability to operate in push or pull configuration, a check mode to test for pending changes without applying the change and the ability to tag certain plays and tasks so that only certain parts of the configuration can be applied, etc. The best thing about Ansible is that all these features provide a logical framework for automation and orchestration at scale. It can be understood by anyone from the developers to operators to CIOs.

 

One theoretical example of complex automation

 

Ansible would not be what it is if it could not do more than just one stream automation tool. Complex orchestration with Ansible can be achieved with zero downtime by combining different tasks into a Playbook. For example, let’s say that the infrastructure consists of:

  • Application servers
  • Database servers
  • Content servers
  • Load balancers
  • Monitoring system

For example, we want to update the whole system, a live and running environment, and we can’t afford downtime. In this case, Ansible can be used to implement a complex cluster-wide rolling update consisting of:

  • Consulting a configuration/settings repository,
  • Configuring the base OS on all machines and enforcing the desired state,
  • Identifying a portion needed to update
  • Signaling the monitoring system
  • Signaling load balancers
  • Stopping the web application server
  • Deploying or updating the web application server code, data, and content
  • Starting the server
  • Running tests
  • Repeating this process for other components or tiers
  • Sending email reports and logging

This is, of course, an exemplary model intended to show one possible Ansible use case. The good thing about Ansible is its modular nature, its ability to extend and cover potentially unlimited automation use-cases. So the question is not how to use Ansible correctly; the question is how you can extend it to apply its features to just the proper case and in just the right way for you.

 

 

How to extend Ansible?

 

It is possible that Ansible module database mentioned above does not contain just the suitable module you need. But, Ansible can accept any code as long as it can take JSON as input and produce JSON as output. That means Ansible is a potent tool for developing new ways of orchestrating and automating infrastructures and has unlimited extensibility potential. So its limitations are pretty much the limitations of the user who uses it for automation.

There is also an extension possibility through support for dynamic inventory. It lets Ansible Playbooks be run against a set of machines and infrastructure discovered at runtime rather than statistically defined. Even the runtime behavior of Ansible can be easily extended by the plugin mechanism. New callback plugins can log to log aggregators, send messages to notification services; new connection plugins can be written to access managed nodes in new ways, etc. So, no matter how custom the environment, you can make it work with Ansible.

 

Understood by everyone

 

I’m always for making things simpler and more efficient at the same time. But one important thing in making engineers’ life easier is often overlooked. Of course, we always look for powerful tools that simplify our jobs on a logical level. That is ok and true if we border our view to a single operations team or even an operations department. But we rarely think about how to raise efficiency on the level of the whole organization. This is done by increasing understandability between organization branches or departments, and this is often overlooked. Processes can indeed be simplified, and productivity can rise if all IT teams and departments in a firm have a common language that they can understand.

 

 

Ansible can help with this because it can accomplish all types of automation tasks. Yet, it doesn’t resemble software programming languages but rather basic textual descriptions of desired states and processes while being neutral to the types of processes described. Thus, it can be understood even by those untrained in reading those configurations. This is the beginning of, if not the solutions, to the communication issue I mention above, and undoubtedly a good start to implement a DevOps culture in your organization.

 

Capabilities overview

 

Now, for the end, let’s dive into a quick tour around basic Ansible capabilities. Red Hat Ansible Automation Platform allows users to take three simple actions with their enterprise automation journey:

  • Create – by using Ansible’s massive open source community and prebuilt Ansible Content Collections of the most-used Ansible roles, plugins, and modules. Codify your infrastructure and share it across teams and individuals.
  • Scale – by easy transfer of your automation into multiple domains and across different use cases.
  • Engage – by taking your automation even further with analytics, policy and governance, and content management with the SaaS-based tools in Ansible Automation Platform. These tools include:
    • Content Collections, a new packaging format that streamlines the management, distribution, and consumption of Ansible content.
    • Automation Hub, a repository for certified content via Ansible Content Collections.
    • Automation Analytics for improving automation efficiencies across Red Hat Ansible Automation Platform deployments.

 

 

Breadth of integrations

 

Red Hat Ansible Automation Platform supports a variety of platforms across servers, clouds, networks, containers, and more to meet you where you are in your automation journey:

  • Operating systems and virtualization: Red Hat Enterprise Linux®, Windows and Windows Server, VMware
  • Networks: Arista, Cisco, F5, Infoblox, Juniper, Palo Alto
  • Cloud: Amazon Web Services, Google Cloud Platform, Microsoft Azure, OpenStack®
  • DevOps tools: Atlassian, Check Point, CyberArk, Datadog, IBM, Splunk
PREVIOUS      NEXT

Before you continue...
Subscribe to our monthly content digest and stay up-to-date on everything industry related!

How Desktop Virtualization Works II

End-User Computing – Simple and Secure

PREVIOUS      NEXT

How Desktop Virtualization Works II

End-User Computing – Simple and Secure

VDI Access

Users access VDI with different types of devices:

  • Thin or zero clients
  • Mobile devices (smartphones and tablets)
  • standard PC platforms (Windows, macOS, Linux)

If clients are outside of the corporate network, using WAN, secure access is provided by an additional component – Unified Access Gateway (UAG).

User authentication is done through Active Directory integration, including additional security features such as Single-Sign-On (SSO) and Two-Factor-Authentication.

 

Figure 1. LAN access

 

Figure 2. WAN access

 

Figure 3. Various client devices

 

Thin/Zero clients

 

Thin and zero clients are designed for VDI, reliable and straightforward, with low power consumption. They also have a small footprint, which reduces space requirements. These clients are cheaper than standard desktops or laptops, with minimum maintenance required.

  • Zero Clients – contain no operating system, local disk, CPU, or memory resources. With only a PCoIP chip installed, they are extremely energy efficient and easy to administer. No data is ever stored on the device, which makes them suitable for high-security environments. Some of them are configured for specific protocols only, which could be a problem, especially in large environments. Besides, the configuration and use of USB devices can be complicated in some cases.
  • Thin Clients – contain an operating system, disk, CPU, and memory resources. It brings more capabilities but also more challenges in both hardware and software maintenance. These clients support VPN connections and a variety of USB devices.

Optimal device choice depends on many parameters, including the type of work, financials, and overall VDI environment. Some of the crucial factors are:

  • protocol (PCoIP, Blast, etc.)
  • Wi-Fi connectivity
  • VPN support
  • VoIP support
  • maximum resolution and number of monitors
  • graphical processing capabilities
  • security features
  • number and type of ports
  • centralized management capabilities
  • ease of configuration

 

Mobile devices and standard PC platforms

 

Users access VDI using Horizon Client software or browser if client installation is not possible (VMware Horizon HTML Access).

Standard PC platforms provide outstanding performance, but that comes with higher costs and more complicated maintenance. One way to lower costs is repurposing older devices at the end of their lifecycle. Both standard platforms and mobile devices are an excellent choice for remote user’s access to corporate VDI.

 

User profile management

 

All user environments, huge ones, fully benefit from VDI implementation if the whole process is automated as much as possible. It means the resources are dynamically assigned as needed, at the right point in time, with minimum static, pre-allocated workload capacities. The user logs in and gets the first available virtual machine, which can be different each time. It raises the question of user’s specific data and application settings management.

There are several ways to manage user profiles, depending on specific VDI implementation, Horizon 7 edition, and licensing model:

  • VMware Dynamic Environment Manager (DEM)
  • VMware Persona Management
  • VMware App Volumes Writable Volumes
  • Microsoft FSLogix

Profile management is done through Active Directory integration, using group policies and dedicated administrative templates for Horizon 7. A newer version of DEM can work without AD.

 

VMware Dynamic Environment Manager (DEM)

 

Specific settings are kept on the application level rather than complete profile, which provides better granular control. Configurations are kept in separate .zip files for each application (Figure 4). This way, they can be applied on various operating systems, unlike most standard solutions tied to a specific OS. Horizon 7 Enterprise edition is required.

 

 

Figure 4. Configuration files (DEM)

 

VMware Persona Management

 

This solution keeps the entire user profile, similar to standard Microsoft Roaming Profile solutions. It is available in all Horizon 7 editions, but it doesn’t support RDSH agents and newer versions of Windows 10.

 

VMware App Volumes – Writable Volumes

 

Profiles are kept on separate virtual disks and attached to various virtual machines, as needed. Horizon 7 Enterprise edition is required and separate infrastructure for App Volumes (servers, agents, etc.). Virtual disks are in standard .vmdk format, which eases their administration and data backup/recovery. App volumes can be combined with DEM to get a wide range of profile management options.

 

Microsoft FSLogix

 

This solution is handy for users without Horizon 7 Enterprise edition who can’t use advanced VMware profile management features. Profiles are kept on network share in VHD(X) format and added to VMs as virtual disks. This way, profile content is not copied at log on, which often caused significant start-up delays. Besides, there are several more optimization features:

  • Filter Driver is used for redirection, so applications see the profile as it was on the local disk; this is important because many applications don’t work well with profiles located on network drives
  • Cloud Cache technology enables part of user data to be stored on local disk and multiple network paths for profiles to be defined; this increases redundancy and availability in case of an outage
  • Application Masking can efficiently control resources based on the number of parameters (e.g., username, address range).

Both 32-bit and 64-bit architecture is supported, including all OS starting from Windows 7 and Windows Server 2008 R2. It is available for all users with any of the following licenses:

  • Microsoft 365 E3/E5
  • Microsoft 365 A3/A5/ Student Use Benefits
  • Microsoft 365 F1
  • Microsoft 365 Business
  • Windows 10 Enterprise E3/E5
  • Windows 10 Education A3/A5
  • Windows 10 VDA per user
  • Remote Desktop Services (RDS) Client Access License (CAL)
  • Remote Desktop Services (RDS) Subscriber Access License (SAL)

 

Advanced VDI solutions – Teradici PCoIP Remote Workstation

 

Global data growth requires more and more resources for fast and reliable data processing. Some specific business areas also require very intensive calculations and simulations, as well as complex graphical processing. Standard VDI solutions can’t cope with these demands, and usually, that kind of processing is not moved outside the data centers. On the other hand, many companies need their employees to access corporate resources from any place, at any time.

It can be handled by keeping all processes inside data centers and only transferring display information (in the form of pixels) to remote clients, using the Teradici PCoIP Remote Workstation solution (Figure 5). It is composed of three main components:

  • remote workstation host
  • remote workstation client
  • LAN/WAN

 

 

Figure 5. Teradici PCoIP Remote Workstation solution

 

The host can be any standard Windows or Linux platform which does the data processing. The host’s display information is then processed on pixel level by specific PCoIP techniques, encrypted, and sent over a network to the client. The host must have the following components installed:

  • Graphical card (GPU)
  • PCoIP Remote Workstation Card – receives data from GPU and does pixel-level processing, compression, and encoding. This component has three main types, depending on specific requirements and host configuration (Figure 6).

 

 

Figure 6. PCoIP Remote Workstation Card

 

Due to various display information types (text, images, video, etc.), special algorithms are used to recognize each type and apply appropriate compression methods. Moreover, the compression ratio can be adjusted to network fluctuations.

Image from the host is decompressed and displayed on the client side. Clients can be standard PC platforms (desktop/laptop) or dedicated devices (thin/zero clients), with 4 displays maximum, depending on the resolution.

Regardless of client type, security is at a very high level because data never leaves the data center – only encrypted pixels are transmitted. The use of dedicated devices, such as zero clients, additionally decreases the risk of potential attacks and data loss.

 

Implementation

 

As mentioned, every infrastructure is unique, and each implementation depends on many factors. However, some typical scenarios can be used for approximate resource planning and calculation.

 

Scenario 1. Small and medium environments

 

The basic option assumes infrastructure for 50 users, scalable up to 200 virtual machines by adding hardware resources and appropriate licenses.

Licensing model is based on Horizon 7 Advanced Add-on (Named/CCU) with separate licensing for vSAN, vSphere and vCenter.

Virtual desktops are created as linked clones which significantly reduces the disk space and eases administration. User data are kept on a network share, with 100 GB per user allocation.

Compute resources consist of 4 hosts in the vSAN cluster with RAID-5 configuration. ESXi operating system is installed on separate M2 disks with RAID-1 protection. Table 1 shows approximate calculation details for the vSAN cluster, and Table 2 shows the host specifications. Licenses are defined in Table 3.

 

 

Table 1. vSAN cluster calculation (50 VMs)

 

 

Table 2. Host specifications (50 VMs)

 

 

Table 3. Licenses (50 VMs)

 

Scenario 2. Large environments

 

Besides additional hardware resources, large infrastructures usually need extra features for management, control, and integration. In addition, a certain level of automation is desirable.

This scenario is based on the following presumptions:

  • The number of users is 200, with a possible scale-up to 500
  • Up to 100 GB of data per user
  • Ability to use RDS Published applications
  • Ability to virtualize applications with App Volumes
  • Ability to manage user profiles

The features mentioned above require Horizon 7 Enterprise edition, including vSAN, vSphere, and vCenter licenses. Besides, it enables instant clones for VM deployment, which significantly increases system agility and VM creation speed (compared to linked clones). Licensing model can be both Named or CCU.

User profile management can be done using Writable Volumes – virtual disks assigned to every user, containing all installed applications, data, and specific settings. These disks are attached to VM during logon, so the user profile is always available, regardless of VM assigned. Combined with VMware Dynamic Environment Manager, it can offer a high level of granularity in data and profile management.

The servers used are the same as for Scenario 1, with additional hardware resources installed. All details are listed in Tables 4, 5, and 6.

 

 

Table 4. vSAN cluster calculation (200 VMs)

 

 

Table 5. Host specifications (200 VMs)

 

 

Table 6. Licenses (200 VMs)

 

 

PREVIOUS      NEXT

Before you continue...
Subscribe to our monthly content digest and stay up-to-date on everything industry related!

How Desktop Virtualization Works II

End-User Computing – Simple and Secure

PREVIOUS      NEXT

How Desktop Virtualization Works II

End-User Computing – Simple and Secure

VDI Access

Users access VDI with different types of devices:

  • Thin or zero clients
  • Mobile devices (smartphones and tablets)
  • standard PC platforms (Windows, macOS, Linux)

If clients are outside of the corporate network, using WAN, secure access is provided by an additional component – Unified Access Gateway (UAG).

User authentication is done through Active Directory integration, including additional security features such as Single-Sign-On (SSO) and Two-Factor-Authentication.

 

Figure 1. LAN access

 

Figure 2. WAN access

 

Figure 3. Various client devices

 

Thin/Zero clients

 

Thin and zero clients are designed for VDI, reliable and straightforward, with low power consumption. They also have a small footprint, which reduces space requirements. These clients are cheaper than standard desktops or laptops, with minimum maintenance required.

  • Zero Clients – contain no operating system, local disk, CPU, or memory resources. With only a PCoIP chip installed, they are extremely energy efficient and easy to administer. No data is ever stored on the device, which makes them suitable for high-security environments. Some of them are configured for specific protocols only, which could be a problem, especially in large environments. Besides, the configuration and use of USB devices can be complicated in some cases.
  • Thin Clients – contain an operating system, disk, CPU, and memory resources. It brings more capabilities but also more challenges in both hardware and software maintenance. These clients support VPN connections and a variety of USB devices.

Optimal device choice depends on many parameters, including the type of work, financials, and overall VDI environment. Some of the crucial factors are:

  • protocol (PCoIP, Blast, etc.)
  • Wi-Fi connectivity
  • VPN support
  • VoIP support
  • maximum resolution and number of monitors
  • graphical processing capabilities
  • security features
  • number and type of ports
  • centralized management capabilities
  • ease of configuration

 

Mobile devices and standard PC platforms

 

Users access VDI using Horizon Client software or browser if client installation is not possible (VMware Horizon HTML Access).

Standard PC platforms provide outstanding performance, but that comes with higher costs and more complicated maintenance. One way to lower costs is repurposing older devices at the end of their lifecycle. Both standard platforms and mobile devices are an excellent choice for remote user’s access to corporate VDI.

 

User profile management

 

All user environments, huge ones, fully benefit from VDI implementation if the whole process is automated as much as possible. It means the resources are dynamically assigned as needed, at the right point in time, with minimum static, pre-allocated workload capacities. The user logs in and gets the first available virtual machine, which can be different each time. It raises the question of user’s specific data and application settings management.

There are several ways to manage user profiles, depending on specific VDI implementation, Horizon 7 edition, and licensing model:

  • VMware Dynamic Environment Manager (DEM)
  • VMware Persona Management
  • VMware App Volumes Writable Volumes
  • Microsoft FSLogix

Profile management is done through Active Directory integration, using group policies and dedicated administrative templates for Horizon 7. A newer version of DEM can work without AD.

 

VMware Dynamic Environment Manager (DEM)

 

Specific settings are kept on the application level rather than complete profile, which provides better granular control. Configurations are kept in separate .zip files for each application (Figure 4). This way, they can be applied on various operating systems, unlike most standard solutions tied to a specific OS. Horizon 7 Enterprise edition is required.

 

 

Figure 4. Configuration files (DEM)

 

VMware Persona Management

 

This solution keeps the entire user profile, similar to standard Microsoft Roaming Profile solutions. It is available in all Horizon 7 editions, but it doesn’t support RDSH agents and newer versions of Windows 10.

 

VMware App Volumes – Writable Volumes

 

Profiles are kept on separate virtual disks and attached to various virtual machines, as needed. Horizon 7 Enterprise edition is required and separate infrastructure for App Volumes (servers, agents, etc.). Virtual disks are in standard .vmdk format, which eases their administration and data backup/recovery. App volumes can be combined with DEM to get a wide range of profile management options.

 

Microsoft FSLogix

 

This solution is handy for users without Horizon 7 Enterprise edition who can’t use advanced VMware profile management features. Profiles are kept on network share in VHD(X) format and added to VMs as virtual disks. This way, profile content is not copied at log on, which often caused significant start-up delays. Besides, there are several more optimization features:

  • Filter Driver is used for redirection, so applications see the profile as it was on the local disk; this is important because many applications don’t work well with profiles located on network drives
  • Cloud Cache technology enables part of user data to be stored on local disk and multiple network paths for profiles to be defined; this increases redundancy and availability in case of an outage
  • Application Masking can efficiently control resources based on the number of parameters (e.g., username, address range).

Both 32-bit and 64-bit architecture is supported, including all OS starting from Windows 7 and Windows Server 2008 R2. It is available for all users with any of the following licenses:

  • Microsoft 365 E3/E5
  • Microsoft 365 A3/A5/ Student Use Benefits
  • Microsoft 365 F1
  • Microsoft 365 Business
  • Windows 10 Enterprise E3/E5
  • Windows 10 Education A3/A5
  • Windows 10 VDA per user
  • Remote Desktop Services (RDS) Client Access License (CAL)
  • Remote Desktop Services (RDS) Subscriber Access License (SAL)

 

Advanced VDI solutions – Teradici PCoIP Remote Workstation

 

Global data growth requires more and more resources for fast and reliable data processing. Some specific business areas also require very intensive calculations and simulations, as well as complex graphical processing. Standard VDI solutions can’t cope with these demands, and usually, that kind of processing is not moved outside the data centers. On the other hand, many companies need their employees to access corporate resources from any place, at any time.

It can be handled by keeping all processes inside data centers and only transferring display information (in the form of pixels) to remote clients, using the Teradici PCoIP Remote Workstation solution (Figure 5). It is composed of three main components:

  • remote workstation host
  • remote workstation client
  • LAN/WAN

 

 

Figure 5. Teradici PCoIP Remote Workstation solution

 

The host can be any standard Windows or Linux platform which does the data processing. The host’s display information is then processed on pixel level by specific PCoIP techniques, encrypted, and sent over a network to the client. The host must have the following components installed:

  • Graphical card (GPU)
  • PCoIP Remote Workstation Card – receives data from GPU and does pixel-level processing, compression, and encoding. This component has three main types, depending on specific requirements and host configuration (Figure 6).

 

 

Figure 6. PCoIP Remote Workstation Card

 

Due to various display information types (text, images, video, etc.), special algorithms are used to recognize each type and apply appropriate compression methods. Moreover, the compression ratio can be adjusted to network fluctuations.

Image from the host is decompressed and displayed on the client side. Clients can be standard PC platforms (desktop/laptop) or dedicated devices (thin/zero clients), with 4 displays maximum, depending on the resolution.

Regardless of client type, security is at a very high level because data never leaves the data center – only encrypted pixels are transmitted. The use of dedicated devices, such as zero clients, additionally decreases the risk of potential attacks and data loss.

 

Implementation

 

As mentioned, every infrastructure is unique, and each implementation depends on many factors. However, some typical scenarios can be used for approximate resource planning and calculation.

 

Scenario 1. Small and medium environments

 

The basic option assumes infrastructure for 50 users, scalable up to 200 virtual machines by adding hardware resources and appropriate licenses.

Licensing model is based on Horizon 7 Advanced Add-on (Named/CCU) with separate licensing for vSAN, vSphere and vCenter.

Virtual desktops are created as linked clones which significantly reduces the disk space and eases administration. User data are kept on a network share, with 100 GB per user allocation.

Compute resources consist of 4 hosts in the vSAN cluster with RAID-5 configuration. ESXi operating system is installed on separate M2 disks with RAID-1 protection. Table 1 shows approximate calculation details for the vSAN cluster, and Table 2 shows the host specifications. Licenses are defined in Table 3.

 

 

Table 1. vSAN cluster calculation (50 VMs)

 

 

Table 2. Host specifications (50 VMs)

 

 

Table 3. Licenses (50 VMs)

 

Scenario 2. Large environments

 

Besides additional hardware resources, large infrastructures usually need extra features for management, control, and integration. In addition, a certain level of automation is desirable.

This scenario is based on the following presumptions:

  • The number of users is 200, with a possible scale-up to 500
  • Up to 100 GB of data per user
  • Ability to use RDS Published applications
  • Ability to virtualize applications with App Volumes
  • Ability to manage user profiles

The features mentioned above require Horizon 7 Enterprise edition, including vSAN, vSphere, and vCenter licenses. Besides, it enables instant clones for VM deployment, which significantly increases system agility and VM creation speed (compared to linked clones). Licensing model can be both Named or CCU.

User profile management can be done using Writable Volumes – virtual disks assigned to every user, containing all installed applications, data, and specific settings. These disks are attached to VM during logon, so the user profile is always available, regardless of VM assigned. Combined with VMware Dynamic Environment Manager, it can offer a high level of granularity in data and profile management.

The servers used are the same as for Scenario 1, with additional hardware resources installed. All details are listed in Tables 4, 5, and 6.

 

 

Table 4. vSAN cluster calculation (200 VMs)

 

 

Table 5. Host specifications (200 VMs)

 

 

Table 6. Licenses (200 VMs)

 

 

PREVIOUS      NEXT

Before you continue...
Subscribe to our monthly content digest and stay up-to-date on everything industry related!

Software-Defined Disaster Avoidance – The Proper Way

VMware vSAN metro cluster implementation

PREVIOUS      NEXT

Software-Defined Disaster Avoidance – The Proper Way

VMware vSAN metro cluster implementation

In my first blog post, the topic I write about, Software Defined Disaster Avoidance – The Proper Way, is a story that we at Braineering have successfully turned into reality twice so far. The two stories have different participants (clients), but they both face the same fundamental challenges. The stories occur in two distinct periods, the first in 2019 and the second one in 2020.

 

Introduction

 

Both clients are from Novi Sad and belong to the public sector. Both provide IT products to many public services, administrations, and bodies without which life in Novi Sad would not run smoothly. Over 3000+ users use IT products and services hosted in their Datacenters daily. Business applications such as Microsoft Exchange, SharePoint, Lync, MS SQL, and Oracle are just some of the 400+ virtual servers that their IT staff takes care of, maintains, or develops daily.

 

Key Challenges

 

At the time, both users’ IT infrastructure was more or less the standard IT infrastructure we see in most clients. It consists of a primary Datacenter and a Disaster Recovery Datacenter located at another physically remote location.

The primary and DR site is characterized by traditional 3-Tier architecture (compute, storage, and network) Figure 1.

The hardware located on the DR site usually operates using more modest resources and older generation equipment than the primary site. It is replicated to a smaller number of the most critical virtual servers. Both clients had storage base replication between Datacenters, and VMware SRM was used to solve automatic recovery.

 

Figure 1.

 

Even though the clients are different, they had common vital challenges:

  • Legacy hardware 
    • different server generations: G7, G8, G9
    • storage systems End of service life.

 

  • Inability to keep up with the latest versions because of legacy hardware.
    • vSphere
    • VMware SRM
    • Storage OS or microcode

 

  • Weak and, for today’s standards, modest performance
    • 8 Gb SAN, 1Gb LAN
    • Slow storage system disks (SATA and SAS)
    • Storage system fragmentation
    • vCPU: pCPU ratio

 

  • Expensive maintenance – again due to legacy hardware
    • Refurbished disks
    • EOSL (End of service life), EOGS (End of general support)

 

  • Limited scalability, the expansion of CPU, memory, or storage resources

 

When new projects and daily dynamic user requests to upgrade existing applications are also considered, both clients were aware that something urgent needed to be done about this issue.

 

Requirements for the Future Solution

 

The future solution was required to be performant, with low latency and easy scaling with high availability. The goal is to reduce any unavailability to a minimum with low RTO and RPO. The future solution must also be simple to maintain, and migration, i.e., switching to it, should be as painless as possible. If possible, remove/reduce overprovisioning and long-term planning and doubts when the need for expansion (by adding new resources) arises.

And, of course, the future solution must support all those business and in-house applications hosted on the previous IT infrastructure.

 

The Chosen Solution

 

After considering different options and solutions, both users eventually opted for VMware vSAN. As the user opted for vSAN as their future solution in both cases, we at Braineering IT Solutions suggested vSAN in the Stretched Cluster configuration to maximize all the potential and benefits that such a configuration brings. To our delight, both users accepted our proposal.

 

Figure 2.

 

Stretched Cluster

 

What is the vSAN Stretched Cluster? It is an HCI cluster that stretches between two distant locations. (Figure 2)

The chosen future solution fully meets all the requirements mentioned above: it supports all clients’ business and in-house applications. In the All-Flash vSAN configuration, they can deliver a vast number of low-latency IOPS. The Scale-Up and Scale-Out architecture allow you to quickly expand resources by adding additional resources to existing nodes (Scale-Up) or adding new nodes to the cluster (Scale-Out).

It is easy to manage; everything is operated from a single vCenter. Existing backup and DR software solutions are supported and work seamlessly. And finally, as the most significant benefit of vSAN in the Stretched Cluster configuration, we have disaster avoidance and planned maintenance.

 

The benefits of the vSAN Stretched Cluster configuration are:

  • Site-level high availability to maintain business continuity.
  • Disaster avoidance and planned maintenance
  • Virtual server mobility and load-balancing between sites
  • Active-Active Datacenter
  • Easy to manage – a single vSphere vCenter.
  • Automatic recovery in the case of one of the sites’ unavailability
  • Simple and faster implementation compared to the Stretched cluster of traditional storage systems.

 

The Advantages of the Implemented Solution

 

The most important advantages:

New servers: The possibility of tracking new versions of VMware platform solutions. A better degree of consolidation and faster execution of virtual machines

Network 10Gbps: 10Gbps datacenter network infrastructure raises network communications to a higher level and degree of speed.

HCI: Scale-out platform, infrastructure growth by adding nodes. Compute, network, and storage resources are converted into building blocks. Replacement of existing storage systems with the vSAN platform in All-flash configuration.

SDDC: A platform that introduces new solutions such as network virtualization, automation systems, day-two operations …

DR site: New DR site dislocated to a third remote location. It is retaining existing VMware SRM and vSphere Replication technology.

Saving: Consolidation of all VMware licenses, consolidation of hardware maintenance of new equipment. Savings have been achieved in the maintenance of old HW systems.

Stretched cluster: Disaster-avoidance system that protects services and data, and recovers with automated procedures, even in a complete site failure scenario

 

The End Solution

 

Today’s IT infrastructure for both clients is shown in Figure 3.

 

Figure 3.

 

The preferred site and Secondary site, the Active-Active cluster, use one common stretched vSAN datastore. All I/O operations on this stretched datastore are synchronized. VMware Replication replicates the 25 most critical virtual servers on the DR site, and that replication is asynchronous. For automated and orchestrated recovery on the DR site in the event of a disaster on a stretched cluster, both users retained the solutions they had previously implemented, VMware SRM.

 

 

 

 

 

 

 

PREVIOUS      NEXT

Before you continue...
Subscribe to our monthly content digest and stay up-to-date on everything industry related!

PREVIOUS      NEXT

PREVIOUS      NEXT

Before you continue...
Subscribe to our monthly content digest and stay up-to-date on everything industry related!

PREVIOUS      NEXT

PREVIOUS      NEXT

Before you continue...
Subscribe to our monthly content digest and stay up-to-date on everything industry related!

PREVIOUS      NEXT

PREVIOUS      NEXT

Before you continue...
Subscribe to our monthly content digest and stay up-to-date on everything industry related!