The Blueprint

Services for the User

• The focus is on the operation and the configuration of the required runtime elements for distributed environments.


• The initial version supports...
  • ... a generic address schema and aliasses for simplified common addressing.
  • ... a set of utilities for a virtualized nameservice.
  • ... a plugin architecture for expansion and custom plugins.
  • ... commandline interfaces for the automation of provisioning and startup of service sets.
  • ... automation tools for the collection of inventory data and provisioning of local and remote configurations.

Scope of Application

• The UnifiedSessionsManager provides a set of generic actions for the creation, usage and termination of user sessions to operating systems, thus ctys - commutate to your sessions.


• These are CREATE, CANCEL, LIST, ENUMERATE, SHOW, and INFO.
  • These provide interactive sessions and batch processing.
  • No distinctintion between Desktop, Client, and Server Virtualization is required.
  • Physical machines and OS access are handled equally to virtual machines.


• The inherent security concept based on OpenSSH provides reliable applicability for sessions to local and remote sites.

Generic View to Services...

• The deeper analysis of the common tasks used within virtual environments leads to sessions management facilities by a common generic approach.
  
  
• The definition of basic building blocks for distributed virtual environments offers advanced concepts and interfaces for future developments based on virtual components - v-components
  
  
• Current concepts comprise flat virtual appliances - v-apps - based on the following operational paradigms:
  • Desktop Virtualization
  • Client Virtualization
  • Server Virtualization

...Desktop Virtualization

• Desktop Virtualization is an inherently interactive user session requiring a local user interface.
  
  
• Local user acces is supported by CLI and graphical user interfaces on base of X11 (Gnome, KDE, Fvwm, Xfce, X11, ...).
  • Single and multiple screen configurations.
  • Special parameters are supported for connection handling and re-establishment:
    CONNECT, RECONNECT, REUSE, and RESUME.
  
  
• The interconnection of clients is supported by OpenSSH only, this...
  • ...provides inherently a versatile dynamic and reliable security facility.
  • ...includes DISPLAYFORWARDING and split of X-Client and X-Server by encrypted tunnels.
  • ...no rule without exception: RDP sessions are provided native for the last hop to the MS-Windows(TM)-Boxes.

...Client and Server Virtualization

• Client virtualization is basically the same as desktop virtualisation, with the extend, that it has not neccessarily to be an interactive session. Thus this could be a so called headless session to a remote service, serving by itself as a server.
  
  
• Similar to this is the Server Virtualization, where the logical task for the entity is to offer a backend service only.
  
  
• Technically there is basically almost no difference, though any of the entities require at least an interactive administrations access. This could be an graphical user interface with a remote desktop in case of powerful servers, or a RS232 console port for a tiny embedded device or network equipment.

=> A Common View

• The UnifiedSessionsManager does not distinguish between types of virtualization. The remaining distinction is a logical 3-layered approach of serving categories:
  • HOSTs: Native access to the contained Operating Systems
  • VMs: Virtual Machines
  • PMs: Physical Machines
  
  
• The logical categorization provides the definition of dependencies for automated operations and nested containment hierarchies.
  • The resulting dependency is used in a bottom-up order for automated boot of pre-required hosting systems of lower layers, whereas a top-down approach is utilized for shutdown procedures.
  • The generic design and implementation allows for containment stacks, where each hypervisor or emulator executed within a hypervisor itself has a view to a virtually physical machine, hosting a contained substack itself. This expands the 3-layer-categories actually to arbitrary numbers of stack layers. Where each is founding it's own subtree.
• This founds the basic conceptual building block of v-components .

Clouds, SOA and SaaS - today

• The current definition of Service Oriented Architectures involve basically the replacement of the former idea of a DCE/CORBA based network as a "seamless Computer" by the introduction of Web based service access points.
• The main approach hereby is the Web-Driven introduction of standard application servers as well defined operational container instances for applications. Expanded by required basic operational services, here mainly database access.
• This results in container instances that are physical processes, technologically implemented based on specific software infrastructure technologies and are running basically in specific operating systems only.
• Even though great enhancements for the service interfaces are achieved, this still results in...
  • ...a bunch of extended interfaces.
  • ...dependency on runtime environment and even applied technology.
  • ...lack of managability.
  • ...limits in configurability.
  • ...lack of location independency in networks.

v-components and stacked-VMs for SOA and SaaS

• The defined concept of v-components is destined to be used as a generic conceptual interface for expansion of the classical design-paradigm of software components within specific container instances.
• The container instance in the future of SOA is the network itself, hosting virtual services - v-services - as selfcontaining virtual hosts or as virtual subnets.
• The v-service itself could contain nested v-services in a virtual stack - v-stack - which are encapsulated by the gateway v-host, offering the service.
• This change has multiple impacts on the resulting software design and the generic capabilities available for the operations environment.
  • ...has actually network interfaces only.
  • ...does not suffer runtime environment or technology dependency.
  • ...could be completely managed generically by standard tools.
  • ...eliminates limits of configuration and scalability.
  • ...is network location independent.
  • ...provides advanced security options but challanges too!

The big Picture

Supported Systems

• The current version supports:
  • KVM, QEMU, VirtualBox, VMware(Workstation/Server/Player), and Xen
  • Linux(CentOS, debian, Fedora, Mandriva, OpenSUSE, ScientificLinux, SuSE, Ubuntu), OpenBSD, FreeBSD, OpenSolaris, Solaris
  • Gnome, KDE, X11, Xfce, FVWM
  • TightVN, RealVNC, RDP/rdesktop, Xterm, Gnome-Terminal, CLI, and Emacs
  
  
• The next versions are going to add support for:
  • OpenVZ, VMware(iESX), and XenServer
  • NetBSD
  • QNX, and uCLinux - initially for X86 and ARM architectures, RTEMS

How does this fit to Clouds and SaaS?

• ...Perfectly!
  
  
• The UnifiedSessionsManager offers publicly since 02/2008 the complete environment for the operations of distributed environments and roaming software services.
• The applied approach is generic and scalable from a single host with one-core only to server farms with an arbitrary number of servers. Therefore distributed remote commands are by default executed asynchronously and in parallel.
• A considerable set of major opensource and free hypervisors in combination with the majority of open source operating systems is supported.
• The provided license is GPL3 from the beginning on.
• The concepts and the inventions are documented in the
  • first version( 01.03.003a01 - 2008.02.11 - ) as a 250pg. online manual ("ctys -H print"),
  • from than on as a seperate PDF documents.( 01.10.009 - 2010.03.10 - ).

What has been defined for now?

• The actual definition provided by the UnifiedSessionsManager is a future architecture extension of SOA and SaaS towards
  • Virtualized Service Architectures
  and
  • Virtual Components as Runtime-Encapsulated Modules and Services

• It is already proven by means of standard components and is going to be widely used with upcoming further rise of the number of cores on each CPU. This is expected to pass the range of 16-cores within next 2 Years, 32-cores within the next following years in combination with OS and hardware support for nested hypervisors.
• The stacked VMs - v-stacks - become than a logical vertical administration concept, executed in a flat array of independent cores.
• Even 16-cores will offer the platform for extensive usage of v-stacks, without performance losses, thus will migrate to daily business. But when the range of e.g. 100 is passed, this will quickly become the broad main stream - with the loopback requirement for more cores.

Current Development - Future versions.

• The following updates will be based on the current implementation framework for bash:
  • The mentioned updates for additional hypervisors and operating systems will be introduced.
  • Install packages for Fedora, debian and OpenBSD will be provided.
  • A generic service reallocation layer for dynamic relocation of VMs will be introduced.
  • Bugfixes as required.
• For future versions it is foreseen to:
  • Reimplement the framework with Perl including C/C++ based extensions.
  • ...a lot more.

Copyright