Architectural overview

Abstract

Table of Contents: IBM Lotus Foundations Start Developers Guide: FS12

IBM® Lotus Foundations™ is divided into two equal parts, the core and the Nitix® virtual server (NVS).

IBM Lotus Foundations Core

The core of IBM Lotus Foundations is composed of a Linux® kernel, a set of packages from a Linux distribution, a large chunk of proprietary applications and some architectural glue. The IBM Lotus Foundations core aims to deliver an all-in-one package to the Appliance and server market by including a set of applications that encompass a small-businesses basic need. The applications included within the core deliver the following features:

IPSec (IP Security for inter-office connectivity)
File sharing to:

Windows® using SMB
Mac using AFP
Linux using NFS
All the above using rsync and FTP

Domain control and membership (to NT4 and Active Directory)
Time synchronization (using NTP)
Network reporting (using SNMP)
Mail delivery, routing, and storage (using SMTP, POP3/IMAP over TLS/SSL)
Disk manager (single disk, RAID1, RAID5, idb)
Intelligent Disk Backup (idb)
Name resolution (DNS, WINS)

The core delivers on all the mainstream protocols and functions which require simple services to deliver them. The core also delivers the architectural and functional glue that is required to bind these services into one working autonomic piece. The architectural glue for the core is provided using:

UniConf (Unified Configuration Backend)
WebConfig – Globalized/Localized Configuration UI
Autonomic engine (responsible for steering the system and its services through error conditions and freeing up resources)

Controls core mechanisms and aids in reporting
Controls NVS containers and aids in problem determination
Controls configuration mechanisms for individual services

SoftUpdate – Delivers licensing functionality

The core is designed so a service might act alone or with the architecture to determine failure points, to allow for UI integration, to allow for custom configuration options or even choose to act as a publishing service for system configuration. This design helps to ensure there is glue between each of the elements and its required components. By using autonomics as the center of the core, each service is protected and configured by a system that knows how to determine and correct the service's state. The cores services and binaries are protected by a read-only file system, minimizing the chance that accidental damage can be done to the underlying files and binaries.

The IBM Lotus Foundations core is an environment that is not intended for modification using the command line. Only a small subset of outward facing utilities exists and access to the file system is limited. Currently only telnet is supported for accessing the core file system.

IBM Lotus Foundations NVS

Each NVS (or Nitix Virtual Server) is composed of a stripped-down version of a Linux distribution, plus a series of scripts to start the basic services. The NVS can be seen as an extension of the core. If you were to look at the services for a given IBM Lotus Foundations host, you would not be able to tell if the services were delivered using the core or within an NVS environment.

The NVS operates using a different philosophy than the core. The NVS is an open domain, where modification is easily possible, and most of the luxuries of a SLES environment are there to enjoy. The NVS is where integrators can implement their solutions and be offered services from the core. The NVS to core relationship is depicted in the following diagram.

Figure 1. IBM Lotus Foundations Core & NVS

diagram of the core & NVS

Within this diagram, there are two NVSs interacting with the core. Each of these NVS environments have their own application context, own environment and dependencies, and yet have the ability to communicate and control various core services and even be monitored and backed up by the core.

Within IBM Lotus Foundations, the configuration bus (UniConf) is used as the primary method of communication between the NVS and the core, and it is over this bus that services are configured and queried. The virtual environment itself does not offer any internal monitoring scripts or programs; however, it does permit the integrators to create monitoring scripts which can be monitored by the core.

Setting the boundary between the core and the NVS

This section shows a logical difference between the primary functions of the core and NVS environments and how they each integrate features.

IBM Lotus Foundations Core

The core system is built using some basic principles. These principles include:

Core services should define the notion of stability. It is stable under all conditions with unlimited outside influences.
Core services should define how a service can optimally work. Working under tough conditions and still choosing the right service parameters.
Core services even potentially serve as a catalyst to the services delivered by the NVS. The core can essentially serve as a portion of a service-oriented subarchitecture (SOA) or as the entire encapsulated object in an SOA.

In summary, the core services serve as an example for NVS services; services that are delivered by integrators and IBM Lotus Foundations teams alike.

The uniqueness of the core is that core services are granted the right and ability to have direct access to all core APIs. The core APIs include APIs for direct access into licensing systems, user interfaces, disk management facilities, and all other core services.

At the advanced level, the core differs from an NVS in all aspects, from the base file system to the user interfaces provided. However, if the two components are compared on a functional level, they would seem practically identical in potential. So what is the core system composed of?

A basic file system: Just like any Linux file system, there is a structure and the IBM Lotus Foundations core file system infrastructure is vastly different from the NVSs. Whereas the NVS file system is organized like a standard Linux distribution, the core's file system is organized as follows:

/usr (READ ONLY)
/tmp (WRITEABLE – Temporary storage space only)
/disk (WRITEABLE)
/bootdisk
/dev (READ ONLY)
/proc (READ ONLY)
/sys (READ ONLY)
/etc (WRITEABLE)

User interface: The primary interface for controlling core services is named 'WebConfig'. This web configuration utility is responsible for tying into all the core services and providing a rationalized view of configuration options and current configuration parameters. This user interface has not been extended to allow for NVS applications to easily control elements of WebConfig. The typical integration path for NVS-based UI's is their own UI utility that is provided in addition to WebConfig.
Monitoring infrastructure: The core's services are protected by monitoring infrastructure so that if a problem arises, the service can be protected from damage or a period of unavailability. These mechanisms provide the aspect of autonomics as they provide the ability to heal the system from damage and also to prevent malicious use of services. These mechanisms also work to protect the NVS as a whole and present disaster recovery solutions to an NVS environment.
Core services: The primary services provided by the core deliver core functionality and SOA ability to the customer base were present/service. Therefore, the primary services should be seen as the essential set of services to enable NVS applications to successfully deliver to market. Each package and application is carefully selected for core integration or NVS integration before deliverance to market based on the above criteria. An additional criteria for inclusion in the core image is also space, as the typical DOM size for an appliance is only 256 MB.

IBM Lotus Foundations NVS

The NVS does not have all the advantages that come along with being integrated into the core. The NVS does not have direct access to the core APIs, nor access to its file system, nor knowledge of whom and what it knows. Instead, the NVS has more than all this, the freedom of flexibility. The NVS sits on a writable file system, has libraries unknown to the core, and can provide services to anything.

The NVS is like a fresh installation of a Linux distribution, without the X11 libraries and applications, without the default file services, and without a tap into a content repository. Think of the NVS having the cushion of knowing that any mistake it made could be fixed within minutes and access to any core service (delivered by essentially another Linux server) was as simple as an API call away.

The only restriction imposed on the NVS is the dependencies that lie within the files needed to make it work and that eventually an API call has to be created in order to grant it the ability to do something. It is this limited set of restrictions which make it unlike the core, but still a valid extension of an IBM Lotus Foundations server.

If you take a look at the file system, the NVS can be defined as everything within the container chroot. Each container chroot is located at /home/nvs_username/Files/filesystem/ if viewed from the core namespace. The files within this file system directory represent a complete SUSE micro-environment plus any modifications made by the integrator.

Each virtual server/add-on is delivered using an NVS package. This package, once installed in the core, is seen as an extension to the core piece. Each add-on is required to be installed into a unique user/team directory; that user/team is then reserved for the sole purpose of providing a virtual server environment.

As a final note, the autonomic file monitoring aspect of the core does not pertain to NVS containers; therefore, it is safe to write to all directories within an NVS.