.
The UnifiedSessionsManager is from beginning on designed with the emphasis of the management of embedded services within virtual and physical machines, including the login sessions for both. This results in a slightly different concept than of the products which are actually designed around the machine in their main focus. The concept of the UnifiedSessionsManager avoids - whenever possible - the application of machine oriented attributes, but presents a common generic task oriented interface with abstract parameters.
| UnifiedSessionsManager as a Service-Composer |
|---|
The overall resulting functionality is positioned as a personal Service-Manager, and offers particularly specific features for the creation and application of combined services. The presented interface for this is kept unique by the definition of a superset of partly optional attributes. Thus the seamless view onto a pool of services and groups of services - v-components - providing various features is provided. The current version provides particularly the desktop based assembly and automation of arbitrary services, following versions will emphasize the VM based assembly. Either by reference, or by containment of nested VMs - stacked-VMs.
The UnifiedSessionsManager itself is designed in it's current implementation as a thin mediation layer, adapting
the interfaces of the various components to a common abstract interface.
This comprises the tools required for the runtime environment including the management of resource data.
The access control to the resources including the encryption of network connections rely solely on the
provided facilities of the underlying operating systems.
The first step to define a target structure for the requirements of
a 'personal Cloud-Management' application is the definition of an
overall concept for the major day-by-day usage embedded into a
heterogeneous IT landscape.
Related to the CloudServices the evolution of the basically
quite similar progress of the
internet/intranet
could be used as a
pattern.
This was developed by using the term 'internet' for the 'geek-period',
the term 'intranet' for the migration into the high-priced enterprise
customers. Finally ther term 'internet' is used again, now for the conversion
into the public volume market.
Each of the overlapping periods had it's specific product policies and
design requirements.
The analogy which to be transfered for the design requirements of the UnifiedSessionsManager is the
evolution of the iconising terminology Cloud-Computing, Private-Clouds,
and Public-Clouds with Cloud-Computing as a synonym.
The implied content is quite similar as for the internet, the public access to variuos distributed resources.
The association with intranet as a closed-group access pattern is basically almost the same as associated with Private-Cloud.
Therefore the expectation is the evolution to a quite similar destination with
some adapted design requirements.
The major difference for the targeted Public-Cloud specification in comparison to the Internet is the
extended personal on-demand application of the provided services without the requirement
of a provisioning human administrator.
This results in in the majority to a dialogue oriented public purchase of on-demand processing and application services.
Thus the design implication for the UnifiedSessionsManager was the introduction of
a personal service management application - A Personal CloudComposer.
The UnifiedSessionsManager is focusing on the personal management and application
of embedded services within the machines.
The contained services are represented by specialized applications, either as a single application, or a
set of grouped applications consisting of one or more VMs.
The various logical session types are represented by a layered plugin structure, where these are categorised
to task specific sets of entities.
These are either representing hardware associated sessions features such as physical machines/PMs and virtual machines/VMs,
or defining logical sessions objects, dynamically created and tighly coupled to the demanded services.
The latter extends the definition of a service even to the actual sessions as the frontend, interconnection entity,
and the lifetime of the optinally executed application.
The on-demand sessions are handeled by the HOSTs plugins comprising logins and the execution of applications.
| SW-Layers and Plugins |
|---|
This is visibly expressed by a common syntax which is the superposition of all attributes, for example
in case of the vendor and product independent common address for the required component by it's
<machine-address>
.
Thus the UnifiedSessionsManager implements a generic Personal Service-Management Application - a ServiceComposer.
The first versions emphasizes the composition of assembled desktops by various local and remote services, which are actually
ordinary logins to machines with specific software sets. Therefore the script interface with GROUPS and MACROs
is provided first. Thus any user could easily design his personal service compositions including the frontend-desktop.
Optionally by dialogue, or for batch-repetition by the creation of a few simple bash scripts
based on remote-logins and remote-execution.
The evolutionary steps to the application level service composition by assembled VMs leak for now some OS and probably HW support
for nested multi-level stacked VMs. This becomes by the application of emulators quickly a performance challange.
| Stacked VMs - VSTACK |
|---|
Thus the VM based service assembly is for now still a draft proof-of-concept from 07/2008.
The actual implementation was based on a VSTACK of nested QEMU based emulators within Xen and VMware Hypervisors.
The following test demonstrated the instanciation of multiple entities within each layer.
| Stacked VMs - Multiple-Instance VSTACK |
|---|
The scope of applicability comprises the common application by ordinary users as well, as by administrators
with advanced permissions.
The access control is almost solely delegated to the system facilities - here OpenSSH, Kerberos, LDAP, and sudo
in combination with file access permissions either by UNIX only, or by Posix-Attributes.
This could be extended by SELinux and/or AFS when required and running on Linux.
The current application of VMSTACKs is mainly applied for the advanced management of VMs as a flat
appliance structure based on their contained guest OS attributes.
The first feature set and target direction is availabele by 01.03.003a01 from 02/2008,
the first basically stable applicable VSTACK feature set for the VM-based
service composition by 01.07.001 beginning at 08/2008
at sourceforge.net/berlios.org.
These comprise the definition and reference implementation for the automatic boot and shutdown of VSTACKs with multiple
instances on each layer forming a tree structure,
which particularly requires the controlled bottom-up startup and top-down shutdown of the mashed runtime dependencies.
The current available products are commonly focussing on the 'technical convenience'
of the machine-handling, but less on the contained 'services'.
This is partly senseful of course, but it is offereing the convenience of the
technical 'administration functionality' only.
Either for the systemsadministrator in a more comprising but granular feature scope,
or for the user with a more restricted and abstract feature set.
Whereas the UnifiedSessionsManager emphasizes the contained applications
and is shifting the focus to the provided services, which are represented
by sets of applications.
One draft example for the difference might be a locator application
for Circusses in your area for making a gift to your children.
If you want to load a 'Circus-Exploration' service, first a
'GIS-Service', but second a 'Circus-Service', and probably an interconnecting
'Navigator-Service' are required. The machine-focused products support
in analogy for the management of three appliances as individual entities only,
which you have to assemble by yourself.
What the UnifiedSessionsManager is designed for is the management of
ONE Combined Service which is assembled by the three composite
services - the v-components.
The stacked VMs - VSTACKS - even offer a generic assembly feature,
where the contained services could be either referenced
only, or physically located within the superior VM by containment.
This actually flexible interface is based on TCP/IP, like CORBA.
The distinction to the current SOA pattern is the completely contained runtime-environment
within each v-component, offering almost independent assembly modules.
Last but not least, when the OSs support for nested VMs is present,
these vertically defined logical structure
is going to be physically executed in a flat matrix structure of
multiple cores. It is expected that in future hundreds, even
thousands of cores are going to be available. Making this approach an
additional component model for software development and flexible
applications management even for the execution on one physical machine only.
The personal service composition - The ServiceComposer - is implemented as draft for now on
application level, but is already present perfectly on the desktop
level with extensive configuration features.
The current release allows for example by the
GROUPS class
for the grouping of arbitrary sessions to a new instance,
which could be used for the replacement of a single
host by the extended <machine-address>
.
In combination with the workspace handling of the
-W
option combined with the extended geometry option
-g
the preparation of multiple 'service-workspaces' could be efficiently automated.
| Multiple Service-Workspaces |
|---|
The following example is just a gimmick, but the
implementation of 'moving and resizing appliances' on your desktop with animated
VMs and HOSTs consoles shows the available configuration and customization capabilities. The
-g
option is
a superset of the --geometry option of X11.
The following examples demonstrate the seamless interface, where the type of the session is going to
be deleted for unambitiously defined entities based on a pre-created inventory database.
For
QEMU/KVM:
for i in 10 20 30;do
ctys -t QEMU -a create=l:myApp,reconnect -g ${i}x100+${i}+100;
done
For
VirtualBox(TM):
for i in 10 20 30;do
ctys -t VBOX -a create=l:myApp,reconnect -g ${i}x100+${i}+100;
done
For
VMWare-Server-1/2+Player-1/2/3+WS-6/7(TM) - next VMWare-ESX+ESXi(TM):
for i in 10 20 30;do
ctys -t VMW -a create=l:myApp,reconnect -g ${i}x100+${i}+100;
done
for i in 10 20 30;do
ctys -t XEN -a create=l:myApp,reconnect -g ${i}x100+${i}+100;
done
For
RDP-Console:
for i in 10 20 30;do
ctys -t RDP -a create=l:myApp,reconnect -g ${i}x100+${i}+100;
done
For
VNC-Console:
for i in 10 20 30;do
ctys -t VNC -a create=l:myApp,reconnect -g ${i}x100+${i}+100;
done
And similarly for
X11-Console:
for i in 10 20 30;do
ctys -t X11 -a create=l:myApp -g ${i}x100+${i}+100 -A on;
done
That's all to be customized.
The presented desktops and workspaces on the home page are
just started within seconds by an ordinary Gnome menu entry - even
though partly containing dozens of VMs on several hosts and additionaly
several guest logins by VNC, RDP, X11, etc..
Now to the datacenter and applications management aspect for
administrators.
The current implemented version has some gaps related to typical
production application, particularly for broader client management.
The features for the management of servers in the back-end by the administrator may fit quite good,
in general the needs for an administrators swiss-army-knife may be matched perfectly.
The missing features are going to follow soon, which includes some re-coding, performance enhancements,
and the introduction of optional server deamons including
optional LDAP integration
.
Also the final integration of the commercial enterprise degree products VMware-ESX(TM) and
Citrix-XenServer(TM) embedded into an additional professional level graphical user interface.
The sytems administrators tasks of the future are expected to be joined
with the application administrators responsibilities.
There might be particularly no extended general outsourcing paradigma
into Public-Clouds, but a case-by-case approach for additional on-demand options.
The so called Private-Clouds may evolve quite similar to nowadays
inhouse services, which could be easily extended by on-demand-resources
from a Public-Cloud.
The responsibility for the administrator is expected to be the management
of the back-end services, including the management of the virtual client-services.
These have quite similar algorithms for execution environment constraints.
The typical constraint migt be a specific hardware or a specific
set of software to be installed in the requested machine founding a service
for a specific task.
The constraint apply to the physically accessed machine of a user, e.g. requiring a locally attached label-printer.
A typical constraint for the assignment of service aspects is a personal
printer. For employees with a lot of 1-2 page printouts a department
printer may not be suitable, also the previous example of a label-printer attached to the physical workstation
may require a specific software including drivers.
For other tasks the label-printer may not be required.
In a future load-balancing scenario you can say
now, that the user requires a printer-aware-VM e.g. with an installed
label-application when he is working in the store.
Afterwords in the office not.
But when writing the bill for his travel expenses the
application composition may be different than for the construction
task of the engineering project he is working on.
This could have an impact on the available floating-license pool of
contained applications.
So when assigning the VM to a specific PM from a pool of available,
the contained application has to be recognize by the balancer.
Particularly when a market for appliances as lean applications evolves in a broader range.
Where lean appliances for example may be delivered as complete machines, including
either a open-source OS, or an appliance-only licensed commercial OS.
This aspect is already designed into the UnifiedSessionsManager by present specific
attributes and application specific custom fields.
But once again, the UnifiedSessionsManager for now only draftly implements this feature on application level.
But the desktop based integration of distributed services is already present and fully operational.
Another aspect for example is the security related to the access permissions.
The administrator is supported for this by system features for the assignment of user
access permissions, and in addition by various features of the UnifiedSessionsManager like
the provisioning of individual database sets, which comprise the
'known as accessible' VMs.
So due to the basic approach of the reuse of available system services, the user
access could be provisioned by standard mechanisms provided by the OS.
The first step of implementation is mainly targeted for the personal application by systemadministrators,
SW developers, and SW testers.
The personal application for various tasks by users requiring some basic skills is also foreseen.
The automation is targeted for the ease of application, but not yet for the complete automation including
the various special cases combined with an extended graphical user interface.
This is planned for the second step, which is currently going to follow.
The implementation for now is based on scripting by bash and Python.
The emphasis was set on a modular expandable and replaceable software architecture, thus providing the
basic structure for the furture migration.
Even though, the current available implementation fits the requirements for individual usage and is fully production ready,
the application within environments for a huge number of users may cause some performances degradation.
Also some feature enhancement is required.
The main enhancements planned to be implemented and added first to the service concept towards a major enterprise environment are:
Therefore some funding and probably support is required.
Datasheets:
UnifiedSessionsManager - Virtualisation and Cloud-Computing as a personal Workspace
Manuals:
ctys(1)
,
ctys-distribute(1)
,
ctys-createConfVM(1)
,
Command-Reference(*)
,
HowTo(*)
,
User-Manual(*)
Use-Cases:
(*) Contained in the DOC-Package only by CCL-3.0.
Archives:
Written and maintained by Arno-Can Uestuensoez:
| Maintenance: | <<acue_sf1 (a) sourceforge net>> |
| Homepage: | <https://arnocan.wordpress.com> |
| Sourceforge.net: | <http://sourceforge.net/projects/ctys> |
| Project moved from Berlios.de to OSDN.net: | <https://osdn.net/projects/ctys> |
| Commercial: | <https://arnocan.wordpress.com> |
Copyright (C) 2008, 2009, 2010 Ingenieurbuero Arno-Can Uestuensoez
This is software and documentation from BASE package,
The whole document - all sections - is/are defined as invariant.
For additional information refer to enclosed Releasenotes and License files.
