Virtual Appliance Sizing Guide

The following information is meant to aid administrators when determining the number and locations of Umbrella virtual appliances (VAs) in their environment. The key factors are ensuring the hardware prerequisites are met, the network latencies between hops, as well as the overall number of Umbrella Sites and users for each VA.

Table of Contents

• Network Prerequisites
• What is an Umbrella Virtual Appliance?
• Connector Sizing Guidelines
• Deployment Considerations
  • Overall Latency
  • Number of Umbrella Sites
  • Number of Users per VA

Network Prerequisites

In order for the VAs to properly communicate with Umbrella for information and updates, review the applicable network prerequisites.

What is an Umbrella Virtual Appliance?

The VA is a non-caching conditional DNS forwarder. It is a virtualized machine that uses Ubuntu as its OS and lives in a virtualized environment. Its purpose is to append identity information to external queries sent up to the Umbrella servers.

Minimum virtualized hardware requirements:

• Number of dedicated CPU cores per VA: 1
• Amount of memory per VA: 512MB (1GB recommended)
• Hard drive space per VA: 7GB

For sizing guidance, increasing the number of CPU cores on a VA will improve its performance, but the amount of RAM allocated to the machine must scale along with the number of CPU cores present. It is required that at least 512MB of RAM be allocated per CPU core on the VA. For example, a VA deployed with two CPU cores should have a minimum of 1GB of RAM allocated to it. While this is the minimum requirement, it is recommended that you configure 1GB of RAM per core.

VAs deployed on platforms such as Amazon Web Services and Google Cloud Platform require a minimum of 1GB RAM per CPU core.

A high-traffic site is one that has more than 500 DNS queries per second coming from clients pointed at the pair of VAs.

High-traffic sites with VAs should use multiple virtual CPUs and corresponding RAM per VA as per the following sizing table.

Connector Sizing Guidelines

For Active Directory integration with Umbrella virtual appliances, the Umbrella Active Directory connector needs to be sized depending on the number of virtual appliances and domain controllers it is communicating with.

In the table above, each domain controller is assumed to process a maximum of 400 AD events a second. If any of your domain controllers are processing more events, make sure to increment the number of domain controllers accordingly. For example, if you have a domain controller that processes around 1000 AD events a second at peak load, count that as three domain controllers in the sizing table above.

If a connector is run on a system with lower CPU and memory specifications, the connector will continue to function. Some optimizations, such as parallel synchronization of login events to virtual appliances, will not be turned on.

Deployment Considerations

The number and location of VAs deployed in your environment will depend on the following:

• Overall latency:
  • Latency between VA and the Umbrella Anycast DNS resolvers
  • Latency between users and the VAs
• Number of Umbrella Sites
• Number of users served by the VAs

Overall Latency

In general, clients on the network have the best web browsing experience when the total time to retrieve web resources is under 300ms. This total time to obtain web resources (such as documents, images, and stylesheets) includes both the time to retrieve a DNS response and the time needed to establish a connection with the server indicated in the DNS response. Umbrella aims to minimize the distance that a DNS packet must travel from a client device to our DNS resolvers. However, we do not control the responsiveness of those web servers or how traffic from various locations on the Internet is routed.

TOTAL TIME = Time to retrieve DNS response + Time to retrieve a web resource

There are two factors to consider when optimizing DNS response time: the distance between the VA and the Umbrella Anycast DNS resolvers, and the distance between the client and the VA.

The VA, when deployed, will forward all externally-bound DNS requests to the Umbrella DNS resolvers, 208.67.222.222 and 208.67.220.220. Therefore, when determining the latency between the VA and the closest Umbrella data center, we recommend an average DNS response time under 150ms for the best user experience.

When determining where to deploy VAs in your environment, you will want to take into account the distance between the clients that will utilize the VAs and the VAs themselves. For optimal performance, an average ping time between a client and the VM host on which the VA lives should not exceed 50ms.

Number of Umbrella Sites

Umbrella's sites allow administrators to segregate their Umbrella deployments. Each Umbrella Site is an isolated deployment in which the components will only communicate with other components in the same Umbrella Site. This is primarily useful in environments containing locations with high-latency connections or in environments with locations whose internal IP space overlaps.

We require each Umbrella site to have at least two VAs deployed. This ensures high availability and that VAs are receiving timely updates from Umbrella.

Number of Users per VA

A typical VA deployed with minimum hardware requirements has a tested throughput of at least 2000 queries per second.

Taking into account these metrics, a single VA can handle DNS requests from at least 57,000 concurrent users. Umbrella defines a single user as a client that generates an average of 3000 DNS requests in a typical eight-hour work day. Therefore, Umbrella defines concurrent users as the number of users or devices sending DNS requests to a VA at the same time.

If the VA specifications are increased to two virtual CPUs and 1GB RAM, a single VA will be able to handle DNS requests from at least 115,000 concurrent users. The number of users on the network likely will NOT be the limiting factor when determining the number of VAs to deploy.

---

Update Virtual Appliances < Virtual Appliance Sizing Guide > SNMP Monitoring