How AppLogic starts applications

You can add a new application to an existing AppLogic grid by using the visual interface to create it, by copying another application or by importing it from an archive. In all cases, to make the application available to AppLogic it has to be placed on file storage accessible to the grid controller. This may be a disk attached directly to the server that acts as a controller, or any suitable network storage.

When you import the application from another grid, you will probably have to configure it by using the Application Configurator to specify externally visible IP addresses and network settings, as well as default hardware resource budgets. Depending on the application, you may also have to set some tuning parameters. Once this is done, the application is deployed and AppLogic is ready to start it.

How to start an application

To start your application, perform the following steps:

• Log in the command line shell (over ssh)
• At the AppLogic prompt, type app start appname, where appname is the name of the application to be started.
  See application start command reference for additonal parameters that may be specified.
• Wait until the application starts (all appliances start successfully and the shell returns to the prompt).

If for some reason an appliance fails to start, AppLogic cleans up the application.

If the application was started with --debug option and an appliance fails to start, AppLogic displays a warning message but leaves the application in a state where the user may ssh into the failed appliance and determine the reason for why the appliance did not start.

What happens on application start

Phase 1: Building

You start an application by issuing a start command to the controller. You can do this through the visual interface or using the command-line shell. In response to this command, the grid controller first runs the build system. The build system compiles all required ADL descriptors, verifies their correctness, resolves all connections within the application and prepares to instantiate it.

Next, the build system instantiates class volumes for virtual appliances within the application (whenever needed), and applies property values and other configuration parameters captured in the application descriptors to the appropriate volume instances.

Phase 2: Scheduling

In the second phase, the controller uses the resource constraints defined in the application, as well as options you may have specified with the start command to determine the actual amount of resources required to run the application. Then, the controller verifies that the grid has enough available resources for this application and proceeds to schedule virtual appliances onto specific servers. If it turns out that the system does not have enough resources to meet the needs of the application, the start is aborted.

The grid controller creates virtual machines and virtual network interfaces for all virtual appliance instances within the application, binds volume instances and application volumes to the respective virtual machines, binds virtual network adapters in the virtual machines to the appropriate virtual network interfaces, and creates virtual connections between virtual network interfaces. At this point, the application structure is properly bound to hardware and ready to run.

Phase 3: Booting appliances

Once all appliances are created, the controller starts the next phase, in which appliances are booted. The order of the boot process is determined by the start order attributes of the appliances within the application. When assembling the application, you will find it useful to configure the start order for most appliances. The start order attribute is an ordinal value that determines the relative order of starting the particular virtual appliance instance among all other instances in the application.

When you assign a particular start order value to an appliance, AppLogic will start that appliance:

• only after all appliances with lower start order values have completed their start process, and
• in parallel with any other appliance that has been assigned the same start order value, and
• before any appliance whose start order value is greater

Most appliances are configured with a small software agent that reports to AppLogic at the moment the appliance has completed its boot process and becomes available to the rest of the application. If a particular appliance or server does not include the start agent, AppLogic will determine its readiness externally, by waiting for a pre-determined amount of time, detecting CPU idle on the appliance, watching for network port activity, etc.

Once all appliances have booted successfully, the application is fully operational and AppLogic reports this fact back to you.

What happens in steady state?

In steady state, your application is executing on AppLogic. Each appliance operates within a virtual machine created on one of the servers within the system. This virtual machine has access to the respective virtual volume instances and application volumes defined for the particular appliance, as if they were local on that server. Each volume is located on one of the servers within the system. Most volumes are accessed exclusively by the virtual machines of the appliances that own them and are usually cached aggressively on the same server where the virtual machine of the appliance executes.

The virtual machines interact with each other by sending and receiving IP packets through their virtual network adapters. Those packets are tunneled through the appropriate virtual wires.

Inside the application, one or more appliances serve as input and output gateways that provide the interaction with the outside world. These gateways have virtual network adapters that are set up to communicate on a routed IP network, with real IP addresses, network masks and other settings. The gateways accept incoming traffic from users, and forward outgoing requests to network services and other applications, including applications that run on the same grid.

Transactional applications running on AppLogic are usually idle until they receive a service request from an external IP network. Such request enters the application through one of the gateways. The gateway that receives the request reacts to it by initiating one or more interactions through its output terminals.

These requests reach other virtual appliances in accordance with the structure of the application, causing them to provide services. In the course of providing these services, some appliances issue secondary requests through their output terminals, which end up being received by yet other appliances in accordance with the structure of the application.

At the end, each request is terminated in one of the following two ways:

• it is received by an ultimate “server” appliance that can complete the request without generating outgoing requests, or
• it is received by a “gateway” appliance which can forward the request to a network service or another application via the IP network

When all secondary requests complete, the application as a whole is ready to complete the initiating request that caused the activity. If no other requests are pending, the application enters idle state, waiting for a request to serve.

Sharing the grid between applications

AppLogic makes it easy and safe to run two or more applications on the same grid. This is because it enforces the minimum and maximum limits on hardware resources assigned to each application, and to each appliance within the application.

One of the main problems that makes people reluctant to share hardware resources is that today's systems cannot guarantee quality of service. Simply put, if you and I each run an application on the same shared grid, how can you make sure that your users are not going to experience poor performance when my application is under heavy load?

In AppLogic, each virtual appliance is assigned a certain minimum and maximum hardware budget. As you assemble you application, the system aggregates the budgets of the various appliances and produces automatically a summarized budget for the application as a whole.

When the application is executed, AppLogc treats the lower bound of the resource budget as a “guaranteed performance minimum” similar to a service level agreement (SLA). Your application will not start unless AppLogic can provision at least enough resources required to meet the guaranteed performance minimum and it will never reduce the application resources below that amount.

AppLogic treats upper bound of the resource budget as a “resource quota”, guaranteeing to other applications running on the same grid together with your application that it will never be allowed to access resources in excess to its quota. This makes sure that all remaining resources will always be available to the other applications.

-- BeckyH - 27 May 2006