Looking Through the (Cloud)Lens with Ixia

As data centers evolve, utilizing multiple cloud locations is becoming more common place. Whether its on-premises, hybrid cloud, or public cloud, monitoring this data is becoming a more difficult task. Cloud providers do not allow packet level inspection due to their architecture. Direct access to the hardware is prevented as well. Ixia looks to address these issues with their public cloud monitoring tool CloudLens.
Ixia CloudLens is a two part solution that offers end to end monitoring, down to the packet level, in multi cloud environments. CloudLens SaaS management pane runs in the cloud on  serverless architecture. The management portal is coupled with either a CloudLens Sensor Container, running on a Docker container, or CloudLens Sensor Agent for Windows based solutions. 
How Does CloudLens Work?
Starting with installation of the CloudLens Containers or agents, metadata about the cloud environment is collected. This data includes what cloud provider the sensor is running on, the resources being utilized by the instances, regions, and applications running on the instance. After this information is categorized by CloudLens, collection and tracking of relevant information will begin while disregarding unnecessary data. 
Configuring visibility into cloud traffic utilizes an easy 5 step workflow:

  • Identify source instances

  • Create source groups based on metadata

  • Identify tool instances

  • Create tool group based on metadata

  • Create secure visibility path from source to tools with intelligent filtering

In the above example, source groups are broken down into a typical 3 tier application use case, and the tool groups are the various methods utilized to monitor the health of the application.

In the above example, source groups are broken down into a typical 3 tier application use case, and the tool groups are the various methods utilized to monitor the health of the application.

Connections are made to each group utilizing drag and drop via the CloudLens Dashboard. This creates a secure peer to peer VPN connection. These connections can be one to one, or one to many. By utilizing groups, new instances created in the cloud are automatically detected and added to their corresponding group within CloudLens. No extra configuration is necessary, making scaling easy.
As the Ixia CloudLens is a container and SasS based model, the solution can be ran on AWS, Azure, GCP, IBM Bluemix, Alibaba Cloud, CentryLink, and the on-premises datacenter. Sensor agents and containers can be spun up in the in house datacenter and report back to the same dashboard as the public cloud solutions. Another benefit to the deployment model of CloudLens is that no additional security configuration is necessary. As the components live in the cloud environment, they ingest the existing security profiles.

One final benefit of CloudLens is container visibility. Docker container network namespaces map to the same host network namespace, but they operate independently to each other. This proves to be troublesome for traffic monitoring. By invoking the host namespace for the CloudLens Sensor namespace, the traffic can be easily monitored as it passes through the Docker host to the external network. The CloudLens Container namespace can also be configured to share the same namespace as the desired application. The "sidecar container" configuration allows for traffic monitoring of a single app given the shared network namespace. 

For more information on CloudLens, and other Ixia offerings, take a look at their Tech Field Day 15 Presentations, or visit Ixiacom.com 

Disclaimer: I was invited to participate as a Tech Field Day Delegate as a guest of Gestalt IT. All expenses, including food, transportation, and hotel were covered by Gestalt IT. I did not receive any compensation to write this post, nor was I requested to write this post. The above post is written of my opinion and not that of Gestalt IT. 

Previous
Previous

Top 3 Features of Nutanix AOS 5.6

Next
Next

Riverbed Steel Fusion: A New Approach to Remote Office Infrastructure