This article summarizes our three primary methods of deploying Virtual Edge.
Virtual Edge Deployed at the Aggregation Layer (Switch Hosted)
In this design, Elisity Virtual Edge code runs within a container on supported switches that offer application hosting. The Virtual Edge container is used to establish control and data connections to onboarded access layer switches. This enables multiple access layer switches to be controlled by the same Virtual Edge instance, contained on your aggregation layer switches, without the need for external compute resources. The Virtual Edge code can glean identity information by receiving copies of particular protocol messages and metadata while enforcing policy at the edge using security functions native to the switch operating system.
Virtual Edge Deployed at the Access Layer (Switch Hosted)
In this design, the Virtual Edge code is ran as a container directly on compatible access layer switches. Each access layer switch has its own instance of the Virtual Edge, which maintains a persistent connection to Cloud Control Center. This eliminates single point of failure, as each switch is independently controlled from Cloud Control Center.
Further details on how Virtual Edge integrates and operates, as well as deployment strategy, can be found in the Virtual Edge Deployment Guide.
Virtual Edge VM (Hypervisor Hosted)
Elisity Virtual Edge VM code runs as a virtual machine on any hypervisor anywhere in your network. Similarly to Virtual Edge code that is ran directly on switches, it can glean identity information by receiving copies of particular protocol messages and metadata while enforcing policy at the edge using security functions native to the switch operating system. The Virtual Edge VM maintains a persistent connection to Cloud Control Center as well as connections to the edge switches it actively manages.
Further details on how Virtual Edge VM integrates and operates, as well as deployment strategy, can be found in the Virtual Edge VM Deployment Guide.