Kubisys-Product-Overview-1.2

June 2015, Dr. Shinichi Urano
KUBISYS PLATFORM
Product Overview
!
!
!

Product Overview Page 2
!
1. INTRODUCTION
Today, separate test environments are commonly used to test updates
to Production applications. In order to ensure the validity of these
tests, IT teams attempt to build these test environments as facsimiles
of the Production environment. In the industry, these test environments
are given names such as Staging Environments, QA Environments, UAT
Environments, etc.
While the need for these test environments is ubiquitous, they pose
numerous challenges for IT organizations:
•! Slow to Build: Creating test environments typically crosses
multiple technology silos and is time-consuming.
•! Invalid Config/Data: Traditionally, IT teams build test
environments with fewer resources than Production and design
them to coexist with Production (domain and network.) This
results in test environments with configurations that are
significantly different from Production. In addition, due to the
lack of resources, test environments are often set up with a
subset of the Production data, or mock data. These differences
lead to a significant decrease in the validity of the tests being
performed.
•! Slow to Refresh: Ideally, IT teams should resync test
environments to Production before each use of a test
environment. However, because they typically differ significantly
from Production, refreshing test environments from Production is
often a manual, complex and time-consuming process.
•! Insufficient Scope: Even in cases where several test
environments exist covering multiple application scopes, test
environments are often independent of each other. Consequently,
end-to-end integration tests for inter-dependent applications
(e.g., SharePoint and Exchange) are impossible to perform.
Due to these reasons, organizations today are unable to provision test
environments with sufficient agility, accuracy, scope, and quantity,
leading to:
•! Production Outages: Faulty updates are sometimes introduced
into Production, causing service outages to the business.
•! Slow Deployments: Delivering new updates to Production takes
months, as test-fix cycles are slowed down.

!
The Kubisys Platform addresses these challenges by fully automating
the process of creating and refreshing test environments. Kubisys
customers leverage the solution to support various IT projects and
activities, drastically reducing risks while improving IT staff productivity.
With Kubisys, customers have achieved:
•! 50%-100% reduction in Production outages due to faulty
software updates.
•! 25%-50% reduction in time to delivery.

!
2. KUBISYS PLATFORM
OVERVIEW
!
The Kubisys Platform is an appliance-based solution that provisions
and orchestrates test environments based on Production. It achieves
this by replicating Production Windows servers (physical or virtual) into
the appliance as virtual servers.
In the diagram above, each sphere denotes a test environment created
inside the Kubisys Platform, known as Kubisys Test Environments
(KTEs). The user simply selects one or more Production servers and the
Kubisys Platform replicates these servers, along with networking, in a
fully automated manner. This automated replication is known as the
Capture process.
The Kubisys Platform offers two versions of the Capture process: Thin
Capture and Thick Capture. Thin Capture is particularly resource
efficient and can complete in minutes. See Section 4 for details on
these processes.
Within each KTE, the virtual servers are configured with the same IP
and MAC addresses as in Production and networked together within an
isolated network segment. The virtual servers also contain disks that
are built upon point-in-time snapshots of Production disks. The result is
a fully functional application test environment that accurately mirrors
Production.

!
ARCHITECTURE
The Kubisys Platform is delivered in a rack mount appliance designed
to be deployed alongside Production. The appliance plugs into the
Production LAN so that it can connect to and capture the Production
environment.
Architecturally, the Kubisys Platform is a virtualization platform that
hosts multiple Virtual Machines (VMs). There is one special VM, called
the Kubisys VM, which runs the Kubisys Software. The Kubisys
Software serves out the web-browser-based User Interface (UI). The
software has the ability to provision and remove virtual servers and
virtual switches within the appliance.

!
3. WORKING WITH A KUBISYS TEST ENVIRONMENT
A key characteristic of the Kubisys Platform is that each replicated
server has the same IP and MAC address as in Production, which is
enabled by the network isolation of each Kubisys Test Environment
(KTE). At the same time, users must be able to interact with the servers
in each KTE. Additionally, there are often scenarios where the servers
within a KTE must access services that are outside the KTE. This
section covers the networking details and features of the Kubisys
Platform that simplify these interactions.
NETWORKING ARCHITECTURE
The Kubisys Platform contains multiple network interface cards, all of
which connect to the Kubisys VM. The Kubisys VM is connected to an
internal virtual switch (Kubisys Switch), which in turn connects to
specialized VMs in each of the KTEs. These specialized VMs are virtual
firewalls, and together with the Kubisys VM control the networking
within the Kubisys Platform.

!
ACCESSING SERVERS IN A KTE
CONSOLE ACCESS
The simplest way to access the servers in a KTE is via the web-
browser-based UI. The UI user can launch a console to each server in
another web page. Note that these consoles are only accessible after
logging into the UI, and so are generally meant for administrators of the
Kubisys Platform. Below is an example of a console to a Windows
server displayed within a web browser page.
RDP ACCESS
The Kubisys Platform automatically configures an RDP port-forward
from the Kubisys VM, through the KTE virtual firewalls, to each of the
captured servers. These ports are enumerated in a simple interface that
can be shared with end users of the KTEs (e.g., QA engineers).

!
When a user clicks on the link
next to the server name, it
downloads an .rdp file that
contains the port information.
When the user opens this file
with an RDP client, it will
connect to the captured server
through the forwarded port.
OTHER MECHANISMS TO ACCESS SERVERS IN A KTE
If a large number of end users require access to the environment
through a workstation, a terminal server can be part of the KTE. Each
end user will then simply RDP into the terminal server via the port
forwarding mechanism described above.
If a special workstation (e.g., with a fat client) is needed to access the
service(s) captured in a KTE, the workstation itself can be captured.
The user will then use the port forward mechanism to RDP into the
captured version of the workstation.

!
It is also possible to configure the port forwarding so that a protocol
other than RDP (e.g., HTTP) is port forwarded. This allows users to
directly test services in the KTE, although by connecting to a non-
standard port.
INTEGRATING EXTERNAL SERVICES AND A KTE
Another common requirement for a test environment is integration with
external services. For example, a user may need access to a printer or
NAS device in order to test an application’s workflow. The Kubisys
Platform allows the user to expose specific network endpoints to a
KTE. When a network endpoint is accessible from a KTE in this manner,
we call the result Endpoint Captures.
When a network endpoint is captured into a KTE, the Kubisys Platform
creates a NAT rule within the KTE virtual firewall and also in the
Kubisys VM. The captured servers gain access to the external network
endpoint through this “double-NAT” mechanism.
The user must take special care when considering these endpoint
captures since the user is effectively establishing a direct connection
from a KTE to a Production device. Thus, it is possible for a test
workflow to affect Production. Typically, this is precisely what the user

!
is looking for (e.g., printing to a printer), but the user must be aware of
such cases and understand the risks involved.
INTERNET ACCESS
In a very similar way to the endpoint capture, the user may grant a KTE
access to the Internet by a single click. Note that the same caveat
exists for this feature as for the endpoint captures. Also, the Kubisys
Platform itself must be configured so that it can access the Internet.
For example, the user can use this feature to download patches into
the servers to be tested within a KTE.
4. KUBISYS TEST ENVIRONMENT CREATION
PRODUCTION DISCOVERY
Before the Kubisys Platform can construct any KTE, it needs to collect
information about the Production environment. This information
gathering process is called the Discovery process.
The Kubisys Platform leverages the LDAP (Active Directory) and WMI
(Windows Management Instrumentation) interfaces in order to
enumerate and catalogue the various servers that the solution is
intended to capture. The collected information includes hardware
information such as memory, CPUs, network interfaces, disks/volumes
and their configurations. The information is stored in the on-board
database within the Kubisys VM.
THIN CAPTURE
Thin Capture refers to the process of thinly replicating volumes from
Production servers. The Volume Shadow Copy Service (VSS) is invoked
to create volume snapshots, and these are mapped via the network to
the Kubisys appliance. These read-only volumes are then logically
converted to writable virtual disks by layering a local write-cache and
then connected to the target virtual servers. Note that no actual
copying of data is performed. Thus, the process is very fast, requiring

!
just minutes to complete, and lightweight. Thin Capture is also non-
disruptive to Production environments as very little data is pulled from
Production servers during this process.
For interested readers, a more detailed and visual overview of the
Discovery/Thin Capture workflow is available online:
http://portal.sliderocket.com/Kubisys/How-does-it-work-
SAVE SERVER
Thin Capture relies on the stability of the Production environment (i.e.,
VSS snapshots and networking.) In particular, if a Production server is
rebooted, the Thin-Captured server will lose its base snapshot image
and degrade. In order to combat this scenario, the Kubisys Platform

!
allows the user to save the snapshot image into the appliance. This is
known as the Save Server process.
The Save Server process follows the Thin Capture process and fully
copies data from Production snapshots into storage within the
appliance. While this takes time (for large disks) and has a minor effect
on the Production environment (similar to performing a backup), the
result is the creation of virtual disks that are local to the Kubisys
Platform.
THICK CAPTURE
Thick Capture refers to the process of performing a Thin Capture of the
servers that a user has saved via the Save Server process. Since each
Thick Capture is running from local storage, it is no longer reliant on
the Production environment. Users typically perform Thick Captures to
support long-running tests or development cycles.

!
Note that a user may apply Thick Capture multiple times from a single set of saved snapshot
images.
MIXED MODES
The user may combine Thin and Thick Capture processes, as well as
endpoint captures (see previous section) in a single KTE. The user may
also add new servers to a KTE or refresh a single server, or even a
single disk.

!
In this way, the Kubisys Platform offers a powerful and flexible
framework to dynamically adjust test environments depending on
required scopes.
5. SUMMARY
The Kubisys Platform was purposefully built to address the needs of IT
departments to provision Production-like environments to support
various use cases:
The Kubisys Platform delivers on the promise of operational efficiency
by providing an automation framework that creates environments
directly from Production. Once the automation is configured, an
environment may be refreshed, or additional environments created, by a
single click.
Since the Kubisys Platform ties these environments to Production, it
eliminates the traditional need to maintain separate, function-specific
environments. This maintenance task is very costly in both time and
resources, and it is difficult to keep these environments synchronized
with Production.
As the Kubisys Test Environments precisely reflect Production and are
readily available, the accuracy and frequency of application software
quality checks improve. Kubisys customers experience a reduction in
deployment errors by 50% to 100%.
When the solution is applied to support internal Software Development
Lifecycles (SDLC) (e.g., code merge projects), developers and testers
can leverage the Production-like environments to focus their efforts on
their code and not on creating and maintaining test environments. With

!
the gains in the speed to deploy test environments, Kubisys customers
reduce project timelines by 25% to 50%.
Kubisys enables IT to be more agile while mitigating risk in an efficient
integrated solution. To find out more, request a demo at
http://www.kubisys.com.

Kubisys-Product-Overview-1.2

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (8)

Similar a Kubisys-Product-Overview-1.2

Similar a Kubisys-Product-Overview-1.2 (20)

Kubisys-Product-Overview-1.2