Reference Architecture for Parallels RAS

Understanding Parallels RAS architectural and redundancy options helps administrators run a successful PoC and deployment.

Reference Architectures provide vendor-approved approaches for testing and deployment. In addition to providing a starting point and guidance for common scenarios and considerations. For Parallels RAS, reference architectures provide a blueprint for how to design and deploy a virtual apps and desktops environment.

However, one architecture doesn’t fit all, and IT teams typically have specific requirements based on size, security, scalability, remote access, redundancy/failover, high availability, and other factors. While Parallels RAS is indeed an easy-to-administer virtual apps and desktops solution, having insight about core components and environmental considerations can minimize the time and effort needed for a successful Proof of Concept and full implementation.

If you’re in TL; DR mode, here’s the shortcut: watch the on-demand webinar ‘Reference Architectures for Parallels RAS’

Reference Architectures

Reference Architectures provide vendor-approved approaches for testing and deployment. In addition to providing a starting point and shortcut to success, Reference Architectures are often customized to reflect individual business and technical requirements—whether your intention is to deploy remove PCs, virtual desktops, virtual apps, or Azure Virtual Desktop workloads.

Let’s now focus on the core components, as well as PoC and Production deployments.

Core Components

Parallels RAS has only a few core components and just one admin console. For Parallels RAS components, basic functionality requires only the Connection Broker and Secure Gateway. That’s it.

Connection Broker is the brains of the operation and Secure Gateway provides secure remote access.

Of course, most environmental requirements aren’t this basic; there are additional Parallels RAS components and functionalities available. That’s where Reference Architectures are extremely helpful for providing guidance. The initial step generally starts with a PoC.

Proof of Concept

First, determine success criteria before embarking on a PoC. Success criteria may range from single sign-on to disaster recovery/failover to adherence to a security checklist and more.

Reference Architectures are useful to align the success criteria with the PoC goals and conceptualize what it will look like, as well as determining the needed system resources.

A basic Parallels RAS PoC can be deployed as simply as just one server, and your Parallels Sales Engineer will help define the needed resources. For example, if an administrator just wants to see how Azure Virtual Desktop integration functions or to understand Secure Gateway configuration, a single-server PoC may be all that’s needed. However, most PoCs are based on several servers to test more detailed capabilities.

Production

Once the PoC has been completed, Reference Architectures save time in designing the Production environment. By selecting the Reference Architecture that most closely matches the planned environment, administrators can work with their Parallels Sales Engineer to refine the go-forward plan.

For Production, extended capabilities such as multi-factor authentication, single sign-on, DR/failover, and capacity planning become more relevant. Although Parallels RAS is straightforward, questions such as how much redundancy needs to be incorporated into the layout are best addressed when planning for deployment.

As requirements morph and grow, adjustments can be made. Parallels RAS is flexible and allows for additions and changes with little effort. For example, Azure Virtual Desktop hosts can easily be incorporated to address a seasonal burst requirement. There’s a Reference Architecture for that too!

The best way to learn about Reference Architectures is to watch the ‘Reference Architectures for Parallels RAS’ on-demand webinar.