cloudshell lab as a service 3 - quali | automation for … · 2017-07-12 · components 4 4....

By Hans Ashlock,Technical Marketing Manager

www.qualisystems.com

CloudShellLab as a Service Technical Solution Guide

systemsCloudShell Lab as a Service Technical Solution Guide

Contents

1. Transform your Lab into a Self Service Cloud 3

2. What is a Self Service Cloud? 3

3. Deploying CloudShell 4

Components 4

4. Managing Network/Security Zones 5

5. Sizing Your Deployment 5

6. Import Your Inventory 5

7. Customize your Data Model 6

8. Con�gure Physical Connections 7

9. Create Your Automation Library 7

10. Create Your Self-Service Catalog 8

a. Create Environment 8

b. Add Resources and services 9

c. Create Orchestration Flows 10

11. Monitoring, Reporting and Bi 11

12. Your Lab, your Cloud 11

2


Transform your Lab into a Self Service CloudWhether you manage a test lab, support lab, demo/PoC center, security cyber range, dev/R&D lab, or any other lab, you’re managing a complex and sophisticated data center that constitutes a substantial ongoing investment and opportunity for signi�cant savings. However, lab environments are often under-utilized and largely manually driven. Equipment is scheduled using ticketing systems or spreadsheets; con�icts between users vying for the same equipment are di�cult to resolve and often see critical devices reserved for weeks or months; complex end to end con�gurations are often inadvertently overwritten by others. Furthermore, many organizations are seeking to consolidate multiple lab sites into central, shared data centers that can be used by many remote user groups.

Transforming your lab into a self-service cloud not only delivers impressive CAPEX and OPEX savings, but leveraging the full breadth of an open automation system like CloudShell leads to additional business bene�ts such as faster time to market, agility in responding to market and customer changes, as well as increased competitiveness.

This guide provides a technical overview of how to use CloudShell to transform your lab infrastructure into a self-service Cloud Sandbox.

What is a Self Service Cloud?Transforming your lab into a self-service cloud means that your end customers – whether internal or external – are given the ability to model and provision complex infrastructure environments that consist of any combination of physical, virtual, and logical components. In a self-service cloud, end users can browse from a catalog of environments that are available to them. Selecting and activating an environment in a self-service cloud will reserve and orchestrate all the infrastructure in the environment, which can include making connections, creating networks, launching virtual machines, con�guring equipment, or running other complex automation tasks. Managing and resolving shared and exclusive access to resources by multiple users is handled automatically. When activated, an end user can be sure the environment is in a known state and reserved for their use, allowing the user to focus on what they need to get done rather than setting up their environment. When done, the environment and associated resources will be returned to the shared pool of resources that make up the lab as a service cloud.

State of the art orchestration software for enabling lab-as-a-service should deliver a broad range of capabilities that enable sustainability of the LaaS initiative including:

Centralized, live infrastructure and resource inventory that is built on an open, XML based data model

Inventory-aware environment topology design

Web-based, catalog-driven environment reservation

Automated setup and teardown provisioning of connectivity and resource states

Non-programmer friendly, object based automation work�ow creation

Open interface for extending integrations

Fully interactive sandboxing and live environment customization

CloudShell is the self-service automation platform built on these capabilities for transforming heterogeneous, multi-generational infrastructures and networks into self-service clouds. CloudShell allows IT infrastructure, lab, and network teams deliver fully automated, custom, self-service infrastructure to internal and external users - transforming complex, even legacy infrastructure, into a solution speci�c Cloud Sandbox that enables consolidation, increased device utilization, multi-tenancy, and overall CAPEX and OPEX savings.

3

CloudShellVM

VM

SELFSERVICE

1

2


Deploying CloudShellBefore you build your Lab-as-a-Service solution, you’ll need to deploy CloudShell. CloudShell is enterprise class, distributed software, consisting of multiple components that can be deployed in various con�gurations. Here is an overview of the CloudShell components.

Components

Quali ServerThe Quali Server is the main server component that manages all the core CloudShell capabilities. Typically only one Quali Server component is required, unless a High-Availability con�guration is used (see below). The Quali Server runs on Windows and can be deployed as a precon�gured VM for VMWare or KVM.

Execution ServersOne or more Execution Servers are used to run automation and provision physical and virtual infrastructure. CloudShell allows scalable, distributed execution of automation on both Windows and Linux platforms. Execution Servers can scale out as needed.

Quali Portal ServerThe Quali Portal Server is the web server for the self-service portal. The Portal Server runs on IIS.

Quali Database ServerThis is the main database component for CloudShell, and runs on Microsoft SQL (or use an existing SQL instance which is installed automatically during the install process).

Business Intelligence ComponentsCloudShell also provides BI/Dashboarding software called InSight which requires a web server and data server to store and manage the analytics data.

Admin and Authoring ClientsThese are the back end clients used for administration of CloudShell and for authoring custom CloudShell orchestration flow and automation drivers.

NOTE - CloudShell can be installed in a high availability con�guration using active-standby clustering based on either VMWare vSphere or Microsoft solutions.

Database Server(s)

Quali Server

License Server

InSight Server

Self Service Portal

Web Browser / Mobile / Tablet

CloudShellAuthoring

CloudShellAdmin

Studio(Test Automation)

ExecutionServers

Distributed ScalableCross-Platform

CloudShell

Portal

On-Premises

VM

Protected / Cloud

VM

YourInfrastructure

Clie

nts

Serv

ers

4

3


Managing Network/ Security ZonesCloudShell is an agentless architecture, which means that CloudShell’s Execution Servers will provision your lab infrastructure via standard interfaces like SSH, SNMP, CLI, and REST APIs. This means you need to deploy an Execution Server in each zone of your lab or labs, and open the appropriate CloudShell ports so that those Execution Servers can communicate with the Quali Server.

Sizing Your DeploymentYou’ll also want to plan the size of your CloudShell deployment. Typical deployments of CloudShell range from pilot, small, medium, and enterprise.

Pilot Deployment In a pilot deployment, where CloudShell is being used in a limited fashion (e.g. evaluation, training, or pilots)., In this scenario, it is common to install all CloudShell components on a single machine.

Small Production Deployment

A Small Production Deployment will typically target a couple of teams with a maximum of �ve to ten users accessing and provisioning resources simultaneously. In this deployment model all Quali components are installed on a single machine (or VM) except for the InSight Analytics component and client components. InSight should be installed on a separate machine.

Medium Production Deployment A Medium Production Deployment will typically target more than �ve teams, and will include typically have more than ten users accessing and provisioning resources simultaneously. In this deployment model one machine or VM will include the Quali Server, Web Server, and Database. Another machine or VM will have the InSight Analytics component. And lastly, the Execution Server will be on a separate machine. Additional Execution Server machines can be added as needed to scale out with demand.

Enterprise DeploymentThe Large Production Deployment is typically used to handle organization wide scale out capabilities and maximum demand. In this con�guration all the components will be installed on separate machines. Multiple Execution Servers can be used and added as needed to scale to meet capacity needs. The Large Production Deployment can also support High Availability options (see below). In addition, a SSD based drive is recommended for the Quali Server and Database storage volumes.The CloudShell Deployment and Sizing Guide provides detailed guidelines to help you size and scope your deployment, and give you step by step instructions on how to deploy each component. Follow the Installation Guide to install CloudShell in your lab environment.

Import Your InventoryAs part of transforming your lab into a self-service cloud, CloudShell will track and manage of all your lab inventory, which includes everything from physical equipment like network, storage, and servers, to virtual components like VMs, Virtual Network Functions (VNFs), and virtual appliances, as well as logical components like security groups, address pools, VLANs, policies, and quotas.

CloudShell can import your lab infrastructure through auto discovery. With the click of a button CloudShell can detect and import all your network gear, servers, and virtualization components.

5

4

5

6


If custom device and structure information needs to be discovered (like speci�c chassis, blade, and port data), CloudShell’s Authoring Tool provides a template to allow you to easily extend the autoload process, which will then allow CloudShell to discover custom and extended device information.

CloudShell can also import inventory data directly from your BOM, DCIM, Asset Management system, or even from a Spreadsheet.

Customize Your Data ModelWhen CloudShell imports your inventory it will assign your resources unique names and assign them to the CloudShell data model structure. The CloudShell data model is organized by default to re�ect general lab infrastructure like switches, routers, servers, storage, etc. with default attributes and structure.

The CloudShell data model can be customized according to your needs. You might de�ne custom attributes for tracking, reporting, and automated provisioning of infrastructure.

This can be done for individual types of resources or families of resources.

For example – you might want to de�ne a “Firmware Version” attribute for managing�rmware upgrades on equipment, or a “Location” attribute for tracking the physical location of equipment in a CloudShell InSight dashboard.

The CloudShell data model takes a modular approach using the concept of composition to create complex, compound representations of your infrastructure. For example – a switch might be composed of a Switch parent resource with multiple ports as sub-resources. This allows you to easily customize and extend the way your infrastructure is modeled.

One of the important aspects of creating a cloud out of your lab infrastructure is managing access to resources. CloudShell’s modular approach to modelling allows you to customize how resources are shared and locked at a granular level so that multiple users can simultaneously access the common pool of resources down to the port level without risk of users overwriting each other’s con�gurations.

6

VMCloudShell

Auto Load

Family Attribute A

Model Attribute A

Model Attribute A

Attribute B

Model Attribute A

Attribute C

Switch Attribute A

CiscoSwitch

Attribute A

HPSwitch

Attribute A

Attribute B

Juniper Switch

Attribute A

Attribute C

Juniper A CE

Eth1 10G

Eth2 40G

Switch Role

CiscoSwitch

Role

Juniper Switch

Role

Port Bandwidth

EthernetPort Bandwidth

FiberPort Freq

Fib1 40G

10KHz

7


Configure Physical ConnectionsAutomating your physical – or “Layer 1” – connections is important to automating your lab. CloudShell provides a dedicated physical connectivity framework that allows you to de�ne you physical connection fabric. You can also import this connectivity information from a spreadsheet directly into CloudShell.

Once your physical connections are de�ned, CloudShell will then be able to automatically connect devices in your lab. Typically customers use Layer 1 switches for making connections, and CloudShell supports all major L1 switch vendors . However, CloudShell’s physical connectivity framework is extensible, allowing other technologies or devices to be integrated, like using OpenFlow Switches to simulate Layer 1 point-to-point connections.

CloudShell also supports provisioning L2 Switches, SDN Controllers, and other networking components for creating higher level network connectivity like VLANs, routes, etc. This is typically done using

Services (see below) rather than the physical connectivity framework.If custom device and structure information needs to be discovered (like speci�c chassis, blade, and port data), CloudShell’s Authoring Tool provides a template to allow you to easily extend the autoload process, which will then allow CloudShell to discover custom and extended device information.

CloudShell can also import inventory data directly from your BOM, DCIM, Asset Management system, or even from a Spreadsheet.

Create Your Automation LibraryIn order to create a lab as a service cloud, CloudShell needs to provision your lab equipment.

To do this, CloudShell provides an extensive set of libraries that enable integrating with common technologies and vendors including:

Networking: Cisco IOS, JunOS, Palo Alto Networks, HP, and others

Storage: EMC VNX, Pure Storage, Hitatchi, and others

Compute: HP, Cisco UCS, Dell, and others

Virtual/Cloud: vSphere, KVM, OpenStack, AWS; includes ESXi bare metal support

Management: Cisco APIC, Cisco UCS Director, and others

Test: Ixia IxLoad, IxNetwork, IxVM, Breaking Point; Spirent Avalanche; TerraVM, and others

In most cases, the existing integrations that CloudShell provides will be enough for you start building your cloud environments out of the box. In some cases, you’ll want to create custom integrations to equipment and services to provide extended provisioning capabilities. For example – you might have legacy devices or custom in house tools that need to be con�gured as part of activating certain environment.

7

8

9


The CloudShell Authoring tool makes it extremely easy to create custom integrations to any kind of device, tool, or service so that they can be used within your self-service cloud. The Authoring tool is visual based, and provides wizard like tools for creating integrations via CLI, SNMP, SSH, XML or REST APIs, as well as any language including Python, JavaScript, .NET, and TCL. CloudShell even supports other orchestration and con�guration tools like Docker and Puppet.

CloudShell’s Authoring tool enforces a modular, object based approach to creating integrations and automation. With CloudShell Authoring, not only can you create integrations with infrastructure, but entire automation �ows for performing tasks like enforcing policies with a business process platform, interacting with an external e-commerce or chargeback engine, or running test/certi�cation suites.

The automation and provisioning libraries that you create in CloudShell Authoring can be made available to other users as a shared library of automation objects.

Note – CloudShell also supports creating integration libraries and orchestration �ows directly in Python. CloudShell provides a Python API to make it easy for Python developers to use CloudShell without leaving their native development environment. You can �nd out more from our CloudShell API Guide.

Create Your Self-Service Catalog

Create EnvironmentNow you have all the components in place to start building your self-service catalog. Your goal will be to create a self-service catalog with environments that serve all your end users’ needs. You’ll want to start with the simplest scenarios and progress to more complex scenarios, based on the use cases you’ve identi�ed.

Each environment can be customized with an icon, description, and user instructions (including video and web content). Each environment can also be assigned to one or more categories, which can also be assigned visibility on a per-domain basis. This allows you to customize which categories and environments are visible to di�erent users based on their domain membership.

Each environment can also be further customized to present the user with a set of con�guration options when the user chooses to activate an environment. Environment inputs provide a powerful way of con�guring both the selection of resources that will compose the environment as well as the automation that’s used to provision the environment.

8

VMCloudShell

10


Add Resources and ServicesOnce you’ve created an environment you’ll need to model it, which means adding to the environment all the components that represent the infrastructure you want the environment to provision. Clicking on an environment will open the modelling screen where you can drag and drop resources, abstract resources, and services onto the canvas. CloudShell allows searching across millions of resources in less than a second. You can easily search for any resource by name, type, keyword, IP address or any other attribute.

Abstract ResourcesAbstract Resources are resource templates that specify rules that CloudShell will use to resolve the resources to actual concrete resources in your Lab Inventory when an environment is reserved. For example – suppose we want to include a switch in our environment that supports OpenFlow 1.3. We might add a custom attribute to the Switch family called “OpenFlowVersion”. We would then create an abstract resource that will select any switch that has OpenFlowVersion set to “1.3”.

In addition, attributes of abstract resources can be associated with an Environment Input. This allows the user to drive the selection of the resources in a controlled fashion.

ServicesServices are di�erent than Resources and Abstract Resources because they don’t represent resources in your inventory. Rather, they represent automation, and can be used to provide continuous automation in an environment or used to dynamically create or provision new resources. Services should not be confused with the automation associated with Resources.

For example, the Virtualization Services allow you add a new VM to your environment that will be created and replaced with a VM instance when the environment is activated.

Another example is the VLAN service, which allows you to connect multiple resources to a common VLAN and, upon activation, will automatically con�gure whatever resources are connected to it to be on the same VLAN.

Services also allow the user to specify the inputs to the service when added to an Environment, even an Active Environment. For example – this vSphere VM service allows the user to specify the con�guration of the VM that will be created in the user’s vSphere virtualization environment.

9


Connecting ResourcesOnce you’ve added resources, abstract resources, and services, you can connect them using the Connection Tool. The Connection Tool allows creating three types of connections: Physical, Route, and Automated Connection. Physical connections represent the physical connections between devices; Routes represent connections that CloudShell will resolve using the physical connections and the physical connection framework. Automated Connections can be used by the automation or services to perform device or technology speci�c provisioning .

For example, the VLAN Service uses automated connections to determine which hosts should be placed on a common VLAN.

Create Orchestration FlowsEach Environment is associated with an Environment Orchestration Flow. Environment Orchestration Flows are the high level automation that drives the provisioning of each of your environments.

The default Orchestration Flow that you can use with all environments simply calls the “Setup” automation command on every Resource and Service in your environment. This will cause each Resource and Service in your environment to run their own individual Setup automation �ows simultaneously. Each resource and service will in turn make the speci�c automation calls necessary to setup the resource, which could be di�erent depending on the resource.

However, in many cases, you’ll likely want to create custom Orchestration Flows. This is because even if an environment uses the built in Services and Resource Models, like the VM Service, or even just rely on CloudShell’s ability to automatically provision the physical layer connection fabric, the order of tasks may need to be de�ned by the user. For example, we might want to ensure that CloudShell spins up a particular VM before it connects the VLANs.

10

VM

VM

Resource A Resource B Resource C

VM

SSH

“Setu

p” “Setup”

“Setup”

SNM

P

“get

Stat

us”

<re

spon

se>

<re

spon

se>

REST

“configure”

<re

spon

se>


Orchestration Flows are created in the CloudShell Authoring client. The CloudShell Authoring client is visual based, and �ows can easily be created by dragging and dropping �ow logic tools and Library objects onto the authoring canvas. Once created, Environment Orchestration Flows can be associated with one or more environments. In addition to providing the default “Setup” and “Teardown” �ows that are required for each environment, additional �ows can be published and made available to users from within the environment.

Monitoring, Reporting, and BIOnce your environments and resources are in place, CloudShell allows you to con�gure live status feedback and monitoring of your infrastructure, with default support for integrating with Nagios. Other monitoring solutions are supported as well.

Lastly, providing reporting and Business Intelligence through clear, sharable, and customizable dashboards provides insight into the key success metrics for you and your end users. CloudShell’s InSight BI tool provides out of the box support for visualizing utilization of lab resources, users, groups, and more. It can be customized for providing end-user speci�c analytics because CloudShell tracks all your lab infrastructure and automation data.

Your Lab, Your CloudOnce you’ve created your initial set of environments, orchestration �ows, and any necessary integration libraries for custom resources you’re ready to provide your end users access to your Lab as a Service Cloud. It is recommended that you start with a small set of key use cases and on-board an initial group of beta users. Once you have an initial set of environments published in your catalog and end-users actively using them you can begin to expand your Lab as a Service o�ering.

In addition to end user access via the CloudShell self-service portal, CloudShell provides a full API so that your cloud can be integrated with other third party tools and systems.

11

11

12


CloudShell allows IT and engineering organizations to successfully transform their lab environments into consolidated self-service clouds. CloudShell’s object based, open architecture provides the state-of-the-art platform that industry leaders rely on to move beyond �xed, manual based labs to fully automated self-service clouds. The net result is signi�cant CAPEX and OPEX savings, increased business velocity and agility, and higher levels of market competitiveness.

About QualiSystems

QualiSystems is the leading provider of environments as a service solutions. Quali automation makes infrastructure agile to enable business to get to market faster, maximize costly resources, and reduce CAPEX and OPEX waste. Quali solutions are deployed by hundreds of market-leading service providers, mobile operators, global enterprises, governments and military agencies and technology equipment manufacturers. CloudShell is deployed for a wide variety of use cases ranging from development, test, security & compliance, support, training, sales, marketing and manufacturing. To learn more about QualiSystems and CloudShell, please visit www.qualisystems.com

CloudShell’s Bene�tsCAPEX & OPEX savings

Business velocity & agility

Market competitiveness

12

LAA

S-TG

-1

cloudshell lab as a service 3 - quali | automation for … · 2017-07-12 · components 4 4....

Documents