AppLogic Release Notes

These are the release notes for AppLogic 2.3.8. Other versions.

Note: This release is the official AppLogic 2.3 Beta release. The 2.3.8 release is available to preferred partners and select direct licensees who participate in the beta program. THIS IS A BETA RELEASE; the current production release is AppLogic 2.1.1

Overview

AppLogic is the first grid operating system that runs and scales existing web applications. It converts a set of commodity servers into a scalable grid that's easy to manage. With AppLogic, you can:

• Deploy existing web applications on a grid without changing any code
• Scale each application from a fraction of a server up to the whole grid
• Manage whole racks of servers easier than a single server today
• Handle hardware failures automatically without losing data
• Add or remove servers and storage without disrupting applications
• Manage all applications, servers and storage with just a browser

AppLogic does not require a SAN or other expensive hardware, and is open and vendor-neutral. It supports Linux and all popular open-source middleware including Apache, MySQL, JBoss and Ruby on Rails, so there is no learning curve.

What's so special about AppLogic?

AppLogic does for web applications what Apache does for web content. By separating the application from the datacenter infrastructure required to run it, AppLogic makes it possible to:

• Deploy the same web application on different grids
• Run multiple different web applications on the same server
• Scale a web application to multiple servers, up to the whole grid
• Manage applications and hardware easily

Just like the web servers made it possible to run web sites without owning a datacenter and servers, AppLogic makes it possible to run and scale web applications without the enormous expense of owning and operating scalable IT infrastructure. With AppLogic, you can host any web application on commodity servers rented on a month-to-month basis from your favorite hosting provider.

What is new in AppLogic 2.3 beta

AppLogic 2.3 beta contains all of the new features below plus all of the AppLogic 2.1.1 and 2.2.2 hotfixes.

New Appliance OS Support

• Solaris Appliance Support: AppLogic now supports the Solaris 10 and OpenSolaris Operating Systems for use in AppLogic appliances; in addition to the various Linux distributions that AppLogic currently supports. Solaris is the first new operating system that 3tera has added since AppLogic was initially released. AppLogic is now operating system agnostic. 3tera will be adding support for other operating systems such as Microsoft Windows and FreeBSD in upcoming releases. 3tera has created and tested Solaris 10/OpenSolaris based VPSes and server appliances. Only the OpenSolaris appliances are distributed with AppLogic (based on OpenSolaris 2008.05), Solaris 10 appliances are not distributed with AppLogic due to licensing issues. For more information on how to use Solaris 10 on your AppLogic grid, please contact Technical Support.
• 64-bit Appliance Support: AppLogic now supports both 32-bit and 64-bit appliances. AppLogic provides the following 64-bit appliances in the /system catalog: LUX64, LINUX64, WEB64 and MYSQL64 (all based on 64-bit CentOS 5.0). Both 32-bit and 64-bit appliances can now use up to 32GB of memory.

AppLogic GUI Enhancements

• Enhanced Infrastructure Editor: The AppLogic Infrastruture Editor has been enhanced with several new features:
  • Volume Browser: Users can now access the contents of their volumes by using the AppLogic GUI. This is an explorer-like GUI interface that allows users to:
    • browse the contents of their volume
    • upload/download files to/from their volume
    • create/edit files
    • view/modify owner and access rights for files and directories
    • ...and much more!
  • Annotations: Users can now add colorful annotations to their applications and assemblies that reside on the editor canvas. The annotations are typically used to convey architecture decisions/notes and also to identify the various tiers that are present (web tier, database tier, etc).
  • Notes: Users can now add their own notes to an application, class, singleton or appliance instance. The notes are free-form text with basic text formatting such as boldface, italics, ordered and bulleted lists, and also hyperlinks. The notes can be used to document appliance release notes, design notes or anything else that you might need to specify.
  • Documentation URLs: Users can now configure a documentation URL for each application/appliance that provides the user level documentation for that entity. The URL is also accessible from the editor, as well as the application list page for the application itself.
  • Default Appliance Console: Users can now select a single appliance/assembly within an application to be the "default console" for the application. This allows a user to login to the application itself, which actually logs into the selected appliance (via SSH). You can login to the application from either the editor, application list page or by using the new app login command.
  • Web Management Interface: Users may configure a particular appliance with a web management interface (assuming the appliance exposes a web interface on its default terminal at the specified port). This allows a user to integrate and access the appliance's web interface through the AppLogic GUI via a new "Manage" option (which is accessed from either the editor or application list page).
  • Descriptor Access: Users may now view and edit application and appliance ADL descriptors through the editor. Caution must be taken when using this feature as modifications to a descriptor may prevent the application from building or starting.
  • Appliance Flagging: The editor now tracks unconfigured mandatory properties/volumes and unconnected mandatory terminals for all appliances in an application. Such appliances that need configuration and/or are missing connections are visually flagged. If the user drags the mouse cursor over the flagged appliance, the editor displays the list of properties/volumes/terminals that need attention. The editor also displays on the status bar the number of entities that need attention.
• Enhanced Application List GUI: The AppLogic Application List page has been enhanced with several new features:
  • New Application Information: The application list page now displays the state and resources for each application.
  • Application Start/Stop: Users can now start and stop their applications directly from the application list page with a single click of a button. The progress of the application start/stop is also shown in the GUI; as well as any errors that may have occured.
  • Documentation URLs: Users can now configure a documentation URL for each application that provides the user level documentation for the application. The documentation can also be accessed from the application list page.
  • Application Login: Users can now login to an application, just like for a regular appliance (i.e., SSH into an appliance). For each application, the user can select a single appliance/assembly that is used for the login. Usually this appliance is the main controller or management component for the application.

Sample Application and Catalog Enhancements

• New appliances in the /system catalog providing brand new functionality to AppLogic applications:
  • MYSQLR: MySQL-based database server suitable for replication
  • LOAD: Load Generator that can be used to test various load scenarios in your AppLogic applications
• New dynamic catalog: Used for storing AppLogic dynamic appliances, currently this catalog contains 3 classes:
  • SLA: enables dynamic scaling of an application by starting and stopping other appliances within the application in accordance with a user defined policy
  • BCK: enables automatic appliacation backup to external services
  • MIG: enables the containing application to migrate or snapshot (non-live) itself to another grid
• New VPS reference applications: The old GSC applications have been renamed to VPS_xxx:
  • VPS_CentOS51: virtual private server (CentOS 5.1)
  • VPS_CentOS50: virtual private server (CentOS 5.0), used to be GSC
  • VPS64_CentOS50: virtual private server (64-bit CentOS 5.0), used to be GSC64
• Appliance Kit (APK): A set of binaries that are used to convert virtual machine boot images into AppLogic appliance boot volumes. The APK also allows the user to use the new dhcp appliance configuration mode; which provides much faster application startup and other benefits such as automatic volume mounting within the appliance (see below).

General Enhancements

• High-Availability Checking: AppLogic now automatically monitors the grid's high availablity state and warns the user if downtime is possible due to a server or appliance falure.
• Bandwidth Enforcement: AppLogic now enforces the network bandwidth usage for all appliances running on the grid. An appliance will not be allowed to use more network bandwidth than what the appliance is assigned.
• Monitoring Web Service API: The MON appliance now exposes a REST-based web service interface that can be used to retrieve appliance counters for an application. This information can be used to implement custom monitoring or new functionality based on the value of appliance counters.
• Appliance Volume Mangement: When editing the appliance class volumes, AppLogic now auto-assigns a volume device for each volume that is added to the class (i.e., /dev/hda1, /dev/hda2, etc). In addition, if an appliance is using the new APK, the user may specify a path where a volume should be mounted inside of their appliance. The APK in their appliance will then automatically mount the volume at the specified path during the appliance boot phase. Users no longer have to manage the volume devices and mounts within their appliances.
• Routerless Network Support: All gateway appliances and VPSes support routerless networks.
• Bi-directional Terminals: The any protocol can now be used on terminals to allow bi-directional connections.
• File-system format/check/repair: Users now have the ability to reformat a volume with a specific file-system, check the health of the file-system and repair errors in the file-system on any of their application/appliance volumes.
• ext3-snapshot File-system: New type of Linux file-system; LVM with 2 partitions, one for data (ext3) and one for snapshots.
• Prevent Application debugging: An application may now use field engineering code 16 which will prevent users from running the application in debug mode (i.e., users cannot start the application with the --debug flag).
• Updated Linux Kernel: AppLogic now uses Linux Kernel 2.6.18, adding stability to the system and a wider variety of device support
  • Note that the 2.6.16.33 kernel may still be used in AppLogic appliances (the 2.6.16.33 and 2.6.18 appliance kernels are both supported on the same grid)

Maintainer Features

• Improved hardware support: The AppLogic kernel now supports all devices supported by CentOS 5.1, providing support for more recent hardware. AppLogic is now based on XEN 3.2.1 and the Linux 2.6.18 kernel. In addition, AppLogic can now use up to 32GB of server memory.
• Application and class Locking: Application and appliance locking is designed to protect the intellectual property (IP) contained within such entities. When an application or appliance is locked, ApplLogic disallows regular users from executing certain commands over the locked entities, such as export, edit/modify, etc. This new feature is used by partners and customers to develop distributable AppLogic appliances.
• Grid IP Configuration: AppLogic now allows a maintainer to configure the IP ranges, netmask and gateways that can be used by applications running on the grid. aldo provides several new commands for IP configuration such as addip, remip, setip and listip. After the IP information is configured, it is displayed on the AppLogic GUI dashboard. See the ALD documentation for more information.

Important Bug Fixes in AppLogic 2.3.8

The following defects have been resolved in AppLogic 2.3.8:

• SCR 2192: vulnerability allowing grid users to obtain grid internal data
• SCR 2198: Product: Heavy network load between appliances on the same server can cause the server to reboot
• SCR 2203: VRM: unable to start an application because of a stuck mount on a server (workaround implemented)
• SCR 2197: ABS: assembly to assembly connection with output fanout may be mis-connected (also SCR 2217)
• SCR 2163: INSSL gateway fails with too many open pages
• SCR 2240: HLB/INSSL: under load the pound process seems to trigger the OOM killer which causes appliance failures
• SCR 1975: impex volume is missing (workaround implemented)
• SCR 2215: ABS: default resource settings of components are not preserved when assembly does not specify an override value
• SCR 2200: VRM: unable to mount large volumes (750GB+)
• SCR 2104: all appliances: /var/log/wtmp is not rotated properly which may cause appliance start failures
• SCR 2105: some appliances have little free disk space which could lead to appliance start failures
• SCR 2118: Free memory on some appliances is insufficient (min/dflt should be a minimum 64MB)
• SCR 2146: WEB: two instances in the same app with the same log file name can result in a corrupted log file
• SCR 2148: CTL: cannot specify resources on comp start/restart (default resources are always used)
• SCR 2161: HOOP: raw volumes don't get mirrored properly (workaround implemented)

Hotfixes for AppLogic 2.3.8

This section describes all of the available hotfixes for the AppLogic 2.3.8 release. Make sure that your AppLogic 2.3.8 grid is updated with the mandatory hotfixes to ensure a properly working AppLogic grid.

Mandatory Hotfixes

Optional Hotfixes

Installation/Upgrade/Migration notes and issues for AppLogic 2.3

This section describes various issues/how-tos related to AppLogic 2.3 installation and upgrades. Carefully read and follow the instructions for each issue to ensure a properly working AppLogic 2.3 grid.

• AppLogic Hotfixes: Be sure to install any hotfixes that come with an AppLogic release. The hotfixes are stored in the AppLogic distro that is downloaded from the 3tera download server. The hotfixes are usually named applogic-x.y.z-hfXXXX.tar.bz2; where x.y.z is the AppLogic version and hfXXXX is the SCR number in 3tera's bug database which corresponds to the hotfix (hfXXXX may also be eXXXX for a product enhancement). Some hotfixes are optional - be sure to read the hotfix documentation for hotfix installation instructions and important notes (see the previous section about hotfixes).

• Installing a new 2.3 grid: Starting from AppLogic 2.1.0, AppLogic requires all servers to use a special partitioning schema that makes grid upgrades safer and faster. The AppLogic installer (ALD) contains a new ald-reimage script that automatically both installs the OS and creates the necessary partitions on the specified servers. This makes it easier for the maintainers to install new AppLogic grids; and also ensures that all servers contain the same software and configuration. Please be sure to read the latest ALD documentation before installing your new grid.

• New 64-bit support in AppLogic 2.3: AppLogic 2.3 requires that all servers have 64-bit support, maintainers cannot mix 32-bit and 64-bit servers within the same grid. The AppLogic installer will fail a new installation/upgrade/add server if all servers do not have 64-bit support.

• Upgrading from AppLogic 2.0.2/2.0.5/2.2.2 beta/2.1: AppLogic 2.3 supports upgrades from either 2.0.2/2.0.5/2.2.2 beta or 2.1 grids as long as those grids use the AppLogic partitioning schema. A grid is using the AppLogic partitioning schema if its servers have one or two /mnt/aplbootX partitions (login to one of the servers and execute "df" to view the server's partitions). Before upgrading your grid, be sure to install hotfix 1687 (applogic-2.0.x-hf1687.tar.bz2). This hotfix updates the domU kernels in all appliances to fix a bug that was causing the appliances to intermittently fail to boot. After applying the hotfix, upgrade your grid by simply executing the following command from your AppLogic 2.3 distro: ./aldo upgrade grid=mygrid. If your AppLogic 2.0.2/2.0.5/2.1/2.2.2 grid does not use the AppLogic partitioning schema, you must install a new AppLogic 2.3 grid on separate servers and migrate your applications, catalogs and users over to the new 2.3 grid.

• Upgrade note for AppLogic 2.3: After a grid upgrade, the default catalog displayed by the application editor is not the system catalog. To workaround this issue, simply reboot your grid after the grid upgrade to AppLogic 2.3 has completed. After the grid is rebooted, the default catalog displayed by the application editor will always be the system catalog. This bug does not affect new installs of AppLogic 2.3.

• Upgrading from AppLogic 1.2.x: AppLogic 1.2.x grids cannot be upgraded to AppLogic 2.x. A new AppLogic 2.x grid must be installed on separate servers and the 1.2.x applications, catalogs and users must be migrated over to the new AppLogic 2.x grid. See the next note on how to migrate your applications to your new AppLogic 2.x grid. Also, after uninstalling an AppLogic 1.2.x grid, reboot its servers before using them for an AppLogic 2.x installation.

• Migrating applications from an AppLogic 1.2.14/2.0.2/2.0.5/2.1/2.2.2 grid to a AppLogic 2.3 grid: In order to migrate applications from a AppLogic 1.2.14/2.0.2/2.0.5/2.1/2.2.2 grid to a AppLogic 2.3 grid, follow the steps below:
  • First, make sure you create the users on your new 2.3 grid (maintainers and regular users). AppLogic currently does not support the migration of users.
  • Install hotfix e1720 on the 1.2.14/2.0.2/2.0.5 grid (applogic-x.y.z-e1720.tar.bz2). This hotfix enables faster application migration as applications are migrated directly to remote grids (w/o having to use the impex volume for compression and transfer) To install this hotfix, simply run the following command from your AppLogic 1.2.14/2.0.2/2.0.5 distribution server: ./aldo-fix grid=mygrid applogic-x.y.z-e1720.tar.bz2 (the applogic-2.0.2-e1720.tar.bz2 hotfix can be safely applied to both 2.0.2 and 2.0.5 grids). This hotfix is not needed for AppLogic 2.1/2.2.2. This hotfix does not require a grid reboot. This hotfix can be downloaded from the 3tera download server using the following command based on from which version of AppLogic you are migrating:
    • 1.2.14: rsync -v --progress applogic@download.3tera.net:/home/applogic/1.2.14c/* /root/applogic-1.2.14c/
    • 2.0.2/2.0.5/2.0.5a: rsync -v --progress beta@download.3tera.net:/home/beta/2.0.x/* /root/applogic-2.0.x/
    • (/root/applogic-x.y.z/ in this case contains the AppLogic x.y.z distribution as downloaded from 3tera, be sure to use the correct AppLogic version)
  • Install hotfix Hf1936 on your AppLogic 2.1.0 grid (if not already installed). This hotfix resolves an issue with application migration not working for regular users and maintainers. This hotfix does not require a grid reboot. The download and installation of this hotfix is simular to the hotifx in the previous step.
  • After both hotfixes above are installed, ensure that all custom appliances contained on your 1.2.14/2.0.2/2.0.5/2.1/2.2.2 grid are migrated over to your new AppLogic 2.3 grid. If you don't have any custom appliances, this step can be skipped. Note that there is no migrate command for appliances. Use the following steps to move these custom appliances over to your new grid:
    • Export all custom appliances using the class export command: class export myclass mydir. Each custom appliance is exported to the system impex volume into the specified folder (/vol/_impex/mydir). Repeat the class export command for each custom appliance on the grid. Note that in case you have custom appliances in your own custom catalog, you can export the entire catalog using a single AppLogic command: class export mycatalog mydir.
    • Copy the custom appliances over to your new 2.3 grid using the Linux rsync command: rsync -r -v --progress /vol/_impex/mydir 2.3_controller_ip:/vol/_impex/. Repeat the rsync command for each exported custom appliance or copy the entire /vol/_impex folder.
    • Import all custom appliances using the class import command: class import myclass mydir. Note that in case you have custom appliances in your own custom catalog, you can import the entire catalog using a single AppLogic command: class import mycatalog mydir.
  • It is now time to migrate the applications from your 1.2.14/2.0.2/2.0.5/2.1/2.2.2 grid to your new 2.3 grid. Migrate the applications using the app migrate command executed from the 2.3 grid. The general syntax of the command is app migrate source-grid app-to-migrate. See the AppLogic online documentation or web shell help for more information.
  • AppLogic 2.3 uses a newer Linux kernel version 2.6.18 - When migrating/importing applications from any previous AppLogic versions to AppLogic 2.3, all branched appliances must be updated to use this new kernel (with related modules) as well as newer versions of VMA/VME (AppLogic's virtual machine agent and event generator). The AppLogic 2.3 release provides a script that automates the process of updating all branched appliances on a grid with the latest Linux kernel, modules and AppLogic binaries. Please follow the steps below in order to update your grid after migrating/importing all of your applications/catalogs/appliances:
    • From within your AppLogic 2.3 distro, execute the following:
      • ./upgrade_apps.sh controller-IP vmlinuz-2.6.18-xenU [--force]
      • Be sure to specify the correct controller IP address
    • By default, the script will prompt you to confirm all changes to the appliances on your grid. To surpress the prompting, use the --force option.
    • After the script has completed, your new grid is ready for use.
    • The upgrade script may take a few minutes to complete.
  • At this point, all appliances and applications should be migrated to the new grid.

What's Included

This release of the AppLogic grid operating system includes the following key components.

Distributed Kernel

The AppLogic distributed kernel provides a set of system services required to support the distributed infrastructure and application model of AppLogic. The four most important system services include:

• Global volume store: a scalable, distributed volume store using the built-in hard disks of the grid servers. The volume store keeps volumes mirrored across two or more servers, ensuring high availability and improved read performance. The hierarchical volume space is structured along applications and catalogs, so volumes become integral part of those entities.
• Distributed virtual machine manager: a runtime component that virtualizes the hardware resources used by applications.
• Logical connection manager: a runtime component that provides the virtual network bindings between components of an application without the need to configure any IP addresses and network settings for distributed applications
• Application scheduler: a runtime component that selects and assigns hardware resources to applications, based on available grid resources, application constraints and user-provided configuration

Grid Dashboard

The grid dashboard provides:

• At-a-glance summary of the grid state, including grid name, version, state summary, resource use, messages, settings, etc.
• List of currently installed applications, with the ability to create new apps, copy existing apps, start/stop apps, etc.
• Support page with important links to user documentation, support forums, Grid University, etc.

Application Configurator

The application configurator is a control panel for configuring application parameters: setting their hardware resources, network resources, tuning and other parameters. It is a single property sheet that includes all configurable parameters.

The application configurator can also be accessed through the command line shell or scripts using the app configure command.

Infrastructure Editor

The infrastructure editor is a visual tool that makes it easy to create, assemble and troubleshoot disposable infrastructure for AppLogic applications.

The user interface of the editor is highly interactive and is modeled after popular drawing programs: you assemble infrastructure by dragging components onto the canvass, wiring them together and configuring each component using a property sheet.

For running applications, the editor can be used to open the monitoring dashboard for the application, as well as to start the grid shell for the application or login to individual appliances.

Command Line Shell

The command line shell gives you control of all aspects of an AppLogic grid. The shell runs on the AppLogic controller and can be accessed either through a browser, using the new web-based shell, or over SSH using any suitable SSH client package.

The shell commands are designed with the following objectives in mind:

• make the shell easy to use by human users
• provide simple means for scripting automation

All commands have a "batch" form of their output that makes it easy to parse programmatically, while the command's default output is structured for convenient interactive operation.

Application Infrastructure Build System

The infrastructure build system compiles the application infrastructure, producing a single entity for the application. It verifies resource and configuration constraints for each appliance and for the application as a whole, builds instance images and enforces the integrity of the application infrastructure. The infrastructure linker binds the application instance to the grid hardware resources just in time for application start, producing a ready-to-run application from the portable application format.

The infrastructure build system is automatically invoked when starting applications and is transparent for the grid operator.

Application Monitoring System

The application monitoring system provides a visual interface for monitoring performance and resource usage statistics of running AppLogic applications. The user interface of the Monitor is highly interactive and is accessible with a web browser. See RefMon for details.

System Catalog

The system catalog contains 22 appliance classes, ready to use in applications.

• WEB4/WEB5/WEB64: Apache-based web server with plug-in content/scripts volume
• WEBx4, WEBx8: Scalable web servers
• MYSQL5/MYSQL64: MySQL-based database server
• MYSQLR: MySQL-based database server suitable for replication
• HLB: Session-aware http load balancer
• PS8: Scalable port switch for distributing TCP and UDP traffic to different appliances
• RPL: Event replicator that replicates incoming http requests to different appliances
• NAS: Network attached storage / file server appliance (http and cifs file access)
• LOAD: Load Generator that can be used to test various load scenarios in your AppLogic applications
• INSSL, IN, OUT, NET: Firewalled network gateways based on iptables
• LUX5/LUX64, LINUX5/LINUX64: A tiny and a minimal Linux appliances that can be used as basis for new appliances
• MON: Application Monitor used to monitor running applications (collects and displays counters using visual graphs)

In addition, 3tera has created base appliances for Solaris:

• OSOL64/SOL10: Solaris appliances that can be used as basis for new appliances. Only OSOL64 is distributed with AppLogic. Please contact 3tera technical support for more information on how to create your own SOL10 appliance.

The system catalog is a global catalog, containing appliance classes that can be used by all applications on the grid. You can see the full documentation for each appliance in the catalog reference. The system catalog is read-only for AppLogic users and can be changed only by the grid maintainer.

AppLogic also includes the following global catalogs:

• dynamic: used for storing AppLogic dynamic appliances, currently this catalog contains 3 classes:
  • MIG: enables the containing application to migrate or snapshot (non-live) itself to another grid
  • BCK: enables automatic appliacation backup to external services
  • SLA: enables dynamic scaling of an application by starting and stopping other appliances within the application in accordance with a user defined policy
• user: used for your own production-level appliances, freely modifiable by AppLogic users, by default this catalog is empty
• proto: used for prototyping new appliances, freely modifiable by AppLogic users, each AppLogic release may provide new appliances in this catalog

See catalog reference for a list of all appliances and their data sheets.

Note: The INWEB, MYSQL, WEB, LUX and LINUX appliances are no longer distributed with AppLogic (superceded by newer appliances mentioned above).

Sample Applications

The AppLogic release also includes the following 8 sample applications:

• TWiki: web-based collaboration platform
• SugarCRM: customer relationship management system
• VPS_CentOS50: virtual private server (CentOS 5.0)
• VPS64_CentOS50: virtual private server (64-bit CentOS 5.0)
• VPS_CentOS51: virtual private server (CentOS 5.1)
• Lamp: basic 2-tier non-scalable WEB application
• LampX4: scalable Lamp
• LampCluster: scalable Lamp cluster

In addition, 3tera has created virtual private servers for Solaris.

• VPS64_OSOL: virtual private server (OpenSolaris)
• VPS_SOL10: virtual private server (Solaris 10). This is not distributed with AppLogic. Please contact 3tera technical support for more information.

The applications are ready to run, requiring only network settings to be configured. You can find details on each application in the Sample Applications reference.

Note: The cPanel reference application is no longer distributed with AppLogic.

AppLogic Grid Distribution System

The AppLogic Grid Distribution System (aldo) installs and configures the AppLogic grid operating system, the appliance catalogs and sample applications.

Aldo easily installs multiple grids from a single distribution server. It can also add and remove servers from existing grids, change grid configuration and upgrade AppLogic. In addition, aldo can "clean" servers, removing AppLogic and any user data stored on AppLogic volumes.

For more information on aldo, see Aldo Reference and Aldo Tutorial. Aldo and its documentation are available only to grid maintainers.

Installation

The following procedures are available only to grid maintainers. Hosted grid customers receive their grids pre-installed and pre-configured.

Pre-requisites

To install AppLogic, you need a set of servers (1-128) connected with a gigabit Ethernet network and a designated distribution server. See HardwareConfig, AldTutorial and RefAldSetup for more information.

Please read at least AldTutorial before choosing and setting up your servers and resources. Not reading or not following this document will likely result in a trial-and-error process which can be long and expensive. We want to make sure your installation is successful from the first time - please contact Technical Support if any of the requirements is unclear.

In addition, you will need an ssh keypair to be used to authenticate the grid maintainer. The public key must also be provided to 3tera, so that you can gain access to the 3tera download server. Please e-mail your public key to 3tera Technical Support

For more information on ssh keys, please see the man page on ssh-keygen or the Appendix in RefAldSetup.

Downloading the release

As user root from your chosen distribution server, run the following command:

rsync -v --progress beta@download.3tera.net:/home/beta/2.3.8/* /root/applogic-2.3.8/

Make sure you are running ssh agent with the key that you provided to 3tera for downloads. If you don't have a key or would like to use a different key, please contact Technical Support.

Installing a grid

See AldTutorial for a quick step-by-step guide to installing a grid in its default configuration. See RefAldSetup for details on the various options available when setting up a grid (e.g., installing your logo, setting up defaults for installing multiple grids, etc.).

Product Characteristics

Dimensions

Key System Dimensions

• 128 servers per grid (certified up to 8 servers)
• 31 grids per back-end LAN
• 1024 applications per grid, up to 1024 applications running simultaneously (certified only up to 256)
• If you need different dimensions, give us a call

Other Dimensional Limits

• Per application
  • 512 network interfaces per application

• Per appliance, common dimensions
  • 32GB RAM
  • 8 CPU (800%)
  • 2000 Mbps bandwidth
  • 1 external network interface
  • 1 default network interface

• Per appliance: Linux
  • 32-bit and 64-bit
  • 12 volumes
  • 15 network interfaces/terminals (including external and default interfaces)

• Per appliance: Solaris 10
  • 32-bit only
  • 4 volumes
  • 8 network interfaces/terminals (including external and default interfaces)

• Per appliance: OpenSolaris
  • 64-bit only
  • 10 volumes
  • 11 network interfaces/terminals (including external and default interfaces)

• Per server
  • 255 virtual volumes (counting each mirror as a separate virtual volume)
  • 255 shares (counting each mirror as a separate share)
  • 128 mounts (counting each mirror mounted as a separate mount; i.e., 64 if mirroring by two)
  • 40 appliances (AppLogic internal limit)

• Per virtual volume
  • volumes used in Linux: up to 2TB (1.2TB verified)
  • volumes used in Solaris: up to 1TB-1MB (1,048,575 MB)

• If you need different dimensions, give us a call

Hardware Compatibility

• Single CPU, Multi-CPU (SMP), single, dual and quad core
  • Certified: Pentium P4, Intel Xeon/Woodcrest/Clovertown, AMD Opteron, AMD Athlon64
  • Supported: Intel Pentium P4 or better; AMD Athlon or better
  • Note: Intel hyperthreading is automatically disabled by AppLogic and is not used

• 32-bit/64-bit support
  • maintainers cannot mix 32-bit/64-bit servers on the same grid (all servers of a grid must have the same bitness)

• Minimum 1GB RAM (2 or 4 GB recommended, 32 GB tested)
• Maximum 32GB RAM per server

• 80 GB IDE/SATA HDD (250 GB or larger SATA drive recommended, multiple drives/server supported)
• HDD controllers
  • Certified:
    • Intel Corp. 82801EB/ER (ICH5/ICH5R)
    • Silicon Integrated Systems [SiS] 5513
    • Advanced Micro Devices [AMD] AMD-8111 IDE
  • Supported: all IDE, SATA and SCSI devices supported by CentOS 5.1 (excl. Adaptec AHA-15xx). Details.

• Dual Gigabit Ethernet adapter (Intel or Broadcomm recommended)
  • Certified:
    • Intel Corp. 82541GI/PI Gigabit Ethernet Controller
    • Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet
    • Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (as external 10/100 NICs)
  • Supported: all Gigabit Ethernet network adapters supported by CentOS 5.1. Details.

• Any single non-blocking gigabit Ethernet layer 2 switch (for private network; all ports must be on the same switch, no cascading)

• If you have different network or storage devices, give us a call

Software Compatibility

• Server
  • CentOS 5.1, 32-bit

• Appliances
  • Linux based
    • 32-bit/64-bit Linux OS (a mix of 32-bit/64-bit appliances may be running on the same grid)
    • Kernel 2.6.16-33 with Xen 3.0.4 support and Kernel 2.6.18 with Xen 3.2.1 support
    • 32-bit Tested: Fedora Core 3, CentOS 5.0, CentOS 5.1
    • 64-bit Tested: CentOS 5.0, CentOS 5.1
    • Supported: all Linux distros based on recent 2.6 kernel (see Linux distros verified by AppLogic developers and users)
  • OpenSolaris based
    • 64-bit only
    • Verified with OpenSolaris 2008.05 and build 82
  • Solaris 10 based
    • 32-bit only
    • Verified with Solaris 10 update 4

• Appliance volumes
  • File systems supported: ext2, ext3, ext3-snapshot, reiserfs, fat32, Solaris ufs, Solaris zfs (zfs may not be used for appliance boot volumes)
  • Swap volumes are supported and optional for appliances
  • Integration services for other file systems are available

• If you are interested in other Linux distros, file systems and software infrastructure, give us a call.

Important Notes

1. Beginning with AppLogic 2.3, AppLogic is OS agnostic and designed to be used with different operating systems. As part of its design, all volume operations (create/format, copy, resize, file-system check/repair and manage) are executed within AppLogic applications called filers; they are no longer executed by the AppLogic grid controller as with previous versions of AppLogic. As such, these new filer applications use resources on the grid just like any other regular AppLogic application. Therefore, there must be enough available resources on your grid in order to execute any of the AppLogic volume operations. Note that the filer applications are not used for raw volumes or block-level volume copies.
2. Since all volume operations are now executed using filer applications, all volume operations are slower as compared to previous AppLogic releases since the filer applications have to be started/stopped as part of the volume operation. Typically, there is about 20 seconds of overhead for Linux-based volume operations and about 130 seconds for Solaris-based volume operations. 3tera is working on minimizing this overhead for future AppLogic releases.
3. Beginning with AppLogic 2.3, the mechanism for accessing appliance volumes has changed (there are no longer commands to mount appliance volumes as in previous AppLogic releases). AppLogic 2.3 provides a new way to access your appliance volumes using a visual Windows-like explorer. Users can now access the contents of their volumes by using the Volume Browser. This is a GUI interface that allows users to access the directores/files on their volume, upload/download, view/edit text files and much more. Users can also access a shell for manipulating their appliance volumes using the new vol manage command. In this new shell, users have access to familar tools such as rsync and wget in order to upload/download files. Note that when using the new manage operation, for Linux-based file systems it takes about 25 seconds to complete, for Solaris-based file systems it takes about 105 seconds.
4. Beginning with AppLogic 2.3, network bandwidth resource usage is enforced on all appliances. An appliance will not be able to use more than its configured bandwidth for all of its terminals (the assigned bandwidth takes all terminals into account). Please make sure that the configured bandwidth for your appliances and applications is appropriate according to your bandwidth usage needs (or else you may experience some very slow network performance in your application). The maximum bandwidth per AppLogic server is 2 Gbits.
5. Appliances that pass-through network traffic such as gateways, load balancers and port switches, the bandwidth is actually cut in half. For example, a load balancer that is assigned 100M of bandwidth is actually limited to 50M (due to the fact that the network traffic passes in and out of the appliance).
6. In AppLogic 2.3, INSSL no longer uses "X-SSL-Request: 1" headers and instead uses "X-Forwarded-Proto: https" headers. Any use of these headers in configuration files (i.e., .htaccess) will need to be modified to compensate for this change. If you need to use the INSSL that uses "X-SSL-Request: 1" headers, you may request the AppLogic 2.1 version of INSSL by contacting Technical Support.
7. In AppLogic 2.3, the WEB/MYSQL/LUX/LINUX appliances have been removed and replaced with WEB5/MYSQL5/LUX5/LINUX5. In each of these updated appliances, the OS has been upgraded to CentOS 5.0 and the related software packages have also been upgraded. As such, after migrating older Applogic applications to 2.3 grids, the applications will need to be updated to use these new appliances. This can be done by updating the application descriptor using the new AppLogic infrastructure editor (by replacing the class names).
8. Before accessing the AppLogic GUI on a newly installed or upgraded AppLogic grid, the user should clear out the browser's cache. If the browser's cache is not cleared out, the AppLogic GUI may not behave properly.
9. The grid shell can be accessed either through a web browser or using an ssh client. For increased security, password-based ssh logins are not supported except during grid installation. It is recommended to use the new web shell provided with the AppLogic GUI.
10. When accessing the grid over ssh, the login user name is always root, regardless of the AppLogic user name. For the purpose of ssh logins, users and their roles are uniquely identified by their public ssh keys.
11. Web browser's Javascript and pop-ups must be enabled to use the web-based graphical user interface (dashboard, editor, documentation)
12. Users are responsible for allocating, assigning and use of externally visible IP addresses for applications; AppLogic takes care of all internal network assignments
13. While the AppLogic distribution system sets up all grid servers and controllers with carefully pre-configured firewalls and disables unnecessary network services, users and maintainers are encouraged to verify the security settings of their systems.
14. Network performance between servers on the private network used for volume and inter-appliance communication is measured to approximately 900 Mbps. The TCP network performance measured between appliances residing on different servers is measured as 720-900 Mbps.
15. Resource limits on appliance hardware resources are enforced differently for different types of resources (CPU, memory, bandwidth). CPU is "no less than" , memory is "exactly that much" (includes VM overhead), bandwidth is "exactly that much". CPU resources may be enforced to "exactly that much", using the new --cap_cpu option when starting the application.
16. When starting an application with a specified amount of minimum CPU, it is not guaranteed that the application will get exactly the amount of specified CPU. For example, if an application is started with cpu=2, it is possible that the application will receive 1.97 CPU as observed by adding up all of the assigned CPU to all components of the application. This is due to rounding errors that may occur while trying to assign CPU to each individual component.
17. When application start fails, not all messages related to the failure may be shown in the shell. Inspect the grid log for additional information, using the list log n=20 command.
18. Grids in which linear scalability of performance is important should be built using servers that are as uniform as possible in CPU type/speed, memory size and disk capacity. AppLogic will work correctly in grids assembled from servers with different amounts of hardware resources; however, on such grids you may experience sub-linear performance.

Known Problems and Limitations

Limitations

1. Grid size is limited to 128 servers per grid

This is a limitation of the current AppLogic release. This release has been certified up to 8 servers; configurations up to 128 servers are supported.

2. AppLogic's web based user interface requires Firefox 2, or Firefox 3 beta or Microsoft Internet Explorer 6.x browser or later to operate

Javascript, pop-ups and cookies should be enabled for the grid controller's host for proper operation of the user interface. Please use the latest available bugfix versions of these browsers, as they correct a number of browser defects needed for AJAX applications. Firefox 1.0 and 1.5 browsers are also supported, with some minor known problems (printing and image caching).

3. The private network Ethernet switch is a single point of failure in the grid

If the Ethernet switch dies or loses power, the grid will stop operating and will need to be restarted after the switch is restored to operation or replaced.

4. Protocols are not enforced on appliance terminals, only endpoints are enforced

This means that an appliance can only talk to appliances connected to it (plus its own server and the grid controller). Nevertheless, protocols on new appliances should be properly specified in order to ensure application design integrity and compatibility with future versions of AppLogic.

5. The total available disk space does not take volume mirroring into account

The total available disk space reported by the grid info command is a raw estimate and does not take volume mirroring into account. The true available disk space is the reported available amount divided by the number of mirrors (2 mirrors by default). For example, if there is 1000GB of available disk space and the grid was configured for mirroring of 2, the available disk space is 500GB. Also, in order to successfully mirror volumes, there must be enough disk space on at least X servers where X is the number of mirrors (AppLogic will not fail to create a volume if any one of its mirrors cannot be created, it will display a warning that the volume could not be mirrored).

6. A server failure during application start may cause the application start to fail

If an application is started and one of the grid's servers fails, the application start will fail if one or more of the application's appliances were scheduled to run on the failed server. If this situation occurs, simply restart the application.

7. The AppLogic command line interface does not support decimals for memory (Defect SCR 1921), for example 1.5G must be expressed as 1536M

This will be fixed in a future version of AppLogic (app start, app config, etc).

8. During a grid upgrade, all of the current catalogs on the grid are renamed to aldsave_xxx before the new/updated catalogs are imported

Therefore, after the grid is upgraded, all custom appliances that were present in the proto catalog are now contained in aldsave_proto. These appliances should be moved back to the the current proto catalog (after the grid has been upgraded). If the custom appliance is not used by any other application or appliance assembly, it can be moved by right clicking on the appliance and choosing the move option. Otherwise, the appliance must be dragged into a new application, branched and then moved back into proto. After moving the appliances back into the proto catalog, all applications and appliance assemblies must be updated to use the appliances from proto (currently, your applications reference appliances from aldsave_proto). There is one exception for appliance assemblies. After branching the assembly, make sure all appliances in the assembly reference appliances from proto. An easy way to replace the aldsave_proto appliances with appliances from proto is by using the visual application editor. While holding the shift key, click on the proto appliance and drag it over the aldsave_proto appliance in your application. Drop the appliance and click the OK button and your appliance will be replaced (without having to re-parameterize or reconnect the appliance).

9. The new AppLogic 2.3 volume management GUI has an upload limititation of 10MB per file

In order to upload larger files to your volume, please use the vol manage shell command; don't forget to specify the external IP settings for this command to enable remote access from within the volume manager. For more information, please see the reference for the vol manage command.

10. OpenSolaris zfs cannot be used on the boot volume of an appliance

OpenSolaris appliances may not use zfs on their boot volumes, their boot volumes must use ufssol (Solaris ufs). This will be fixed in a future release of AppLogic.

11. The AppLogic Solaris filer that is used for Solaris volume operations supports a limited variation of zfs

Currently this is limited to single device zfs pools. In order to take full advantage of all of the zfs capabilities in AppLogic, users may assemble their own zfs pools inside of their own appliances. If a zfs pool is going to be used for mirroring, the AppLogic volumes that are used in the pool should be created with the AppLogic mirroring disabled (using the mirrored=0 option when creating the volumes). Also, a zfs pool created using the AppLogic Solaris filer will not work in Solaris 10. Please see RefOsLimitations for all of AppLogic OS limitations.

12. The new auto-mounting feature for appliances has a limitation of 2 volumes for Solaris 10

The AppLogic APK can only auto-mount the first 2 volumes that are defined for a Solaris 10 appliance. For Solaris 10 appliances that have more than 2 volumes, the user will have to manually mount the volumes themselves. Additional volumes also will not appear under the device names that are assigned by the AppLogic GUI; these volumes will appear under different controller device names (i.e., the 3rd volume will be /dev/dsk/c1d0s0, 4th will be /dev/dsk/c1d1s0, etc).

13. The maximum volume size for the ufssol file system is 1TB-1MB

3tera will remove this limitation in a future AppLogic release.

14. Web management GUIs for appliances is limited to GUIs that use only relative URLs

If an appliance has a web mangement GUI that needs to be accessed using the new AppLogic GUI manage operation, the GUI must be based on relative URLs. This is a limitation of the new AppLogic manage operation and will be fixed in a future release to support absolute URLs. Please see ApplianceWebInterface for more information on how to setup your appliance to expose a web management GUI through AppLogic.

15. The property markup for appliance configuration is only supported for the volfix configuration mode

The new dhcp configuration mode does not support the property markup for appliance configuration. When porting appliances from volfix to dhcp configuration modes, the APK documentation describes how to deal with appliances that depend upon the property markup for appliance configuration. Please see the Appliance Kit (APK) for more information.

Known Problems and Issues

The following are the key known problems in this release:

1. Defect SCR 2243 - The AppLogic GUI leaks memory when used with Microsoft Internet Explorer 6 or 7

If the AppLogic GUI is accessed using Microsoft Internet Explorer 6 or 7, the GUI leaks memory as applications are opened for editing or when the web shell is opened (5-20MB of system memory are leaked for each of these operations). It is recommended to close and re-open the browser every few hours to recover the leaked memory. FireFox may also be used instead of Internet Explorer.

2. Defect SCR 2304 - MON becomes unresponsive due to memory leaks when using the web services API

3tera has worked around this issue by updating MON to monitor its memory usage and if the available memory gets too low, the MON services are restarted automatically. This workaround enables MON to continue to function w/o having to restart the MON appliance. This may cause the web service API to malfunction for a period of 1-2 seconds (the wget request will fail). Any appliance that uses the web service API should be prepared to handle such failures by retrying the operation (it is recommended to sleep for a second before retrying the operation). 3tera will fix the memory leaks in MON in a future release (the memory leaks are in 3rd party open source packages that are used in MON).

3. Defect SCR 1471 - GUI times out and logs out the user while there is load on the grid controller

The GUI no longer automatically logs the user out when there is heavy load on the grid controller. Instead, the user will recieve a message stating that there was a network error. In this case however, the GUI is still fully funcitonal. The network error message will only be received when there is heavy load on the controller, such as starting 4 applications at the same time AND copying a large multi-GB volume. In large grids, try assigning up to a full CPU core and 1GB RAM to the controller.

4. Defect SCR 857 - Grid reboot may degrade one or more system volumes

If a grid is rebooted using the grid reboot command, when the grid comes back up after the reboot, one or more of the system volumes may become degraded. If your grid needs to be rebooted, after the grid has been rebooted and comes back online, login as a regular grid user. Check and repair the system volumes by executing the following commands below. This will ensure that the system volumes are always in a clean state. This bug will be fixed in a future AppLogic release.

• check vol # will show if there any volumes that need repair, look specifically for the _SYSTEM volumes
• repair vol _SYSTEM:boot
• repair vol _SYSTEM:meta
• repair vol _SYSTEM:impex

5. Defect SCR 1199 - Unable to migrate a volume whose streams are all on disabled servers

When migrating a volume, make sure that at least one of its streams is on an enabled server or else the migration command will fail. The volume can be completely migrated off of its original set of servers by migrating the volume twice.

6. Defect SCR 1233 - Grid automatic recovery (HA) may fail due to servers taking too long to reboot

Some physical servers may take a long time to reboot - this may cause AppLogic's automated grid recovery to fail. The end result of this is that applications may not be all restarted automatically after the grid recovers from a failure. This is due to the grid controller waiting for a maximum of 10 minutes for all servers to reboot and reconnect to the grid controller (which may not be enough time for all servers to reboot). Workaround is to manually restart applications after all servers have reconnected to the grid controller - execute "list srv" to ensure that all servers are connected to the grid controller - they all should be in the UP state. In AppLogic 2.1, with server boot timeout of 10 minutes, this may occur primarily if a server fails to boot due to hardware or BIOS malfunction.

7. Defect SCR 1234 - Grid flapping file is not always reset when the operator intentionally reboots the grid

When the operator reboots the grid, the grid flapping state is supposed to be reset and a message should be displayed on the dashboard stating that the operator rebooted the grid intentionally ("Grid has been restarted by operator on ..."). Occasionally when rebooting the grid, the grid file is not reset nor is the dashboard message displayed. The only problem that this may cause is upon the next grid failure, the applications may not be automatically restarted (depending on how many times the grid has failed when this bug occurs). To workaround this problem, if after an intentional grid reboot there is no dashboard message displayed, contact technical support to have the grid flapping state.

8. Defect SCR 1219 - 3 to 15 minute system lockout on server failure

In most cases when a server fails, shell commands will hang for 3 minutes but the AppLogic controller will remain operational. After 3 minutes, the grid will return to normal operation. In rare cases where the failed server contains one of the mirrors of the AppLogic controller system volumes (boot, meta or impex) and the server fails to reboot, the user will be locked out of the controller for up to 15 minutes. After 15 minutes, the grid should return to normal operation. This bug will be fixed in a future release.

9. Defect SCR 1360 - Appliance shows slightly less memory and less disk size than allocated

The reason for the slightly reduced resources is related to allocation for service areas. For memory, it is likely due to XEN related to the memory map table for a virtual machine. For disk, it is due to normal file system service areas (this is the same as on regular Linux servers).

10. Defect SCR 1896 - After closing the shell during volume resize, could not resize volume w/o maintainer access (general problem with any command)

If the web shell is closed during the execution of an AppLogic command, this may result in one or more volumes being left mounted on the grid controller. To recover from this situation, make sure all volumes that were involved with the particular operation are unmounted (note that this may include catalog volumes). You can use vol list --all to retrieve a list of all mounted volumes in the system.

11. Defect SCR 2293 - Occasionally opening an application in the editor results in a message that the application is locked for editing

In this case, the application is not opened for editing by any other user but the AppLogic editor errornously thinks somebody else has the application open for editing. If this occurs, simply override the application lock when prompted by the editor upon opening the application.

12. Defect SCR 1961 - After a grid upgrade, the default catalog displayed by the application editor is not the system catalog

To workaround this issue, simply reboot your grid after the grid upgrade to AppLogic 2.3 has completed. After the grid is rebooted, the default catalog displayed by the application editor will always be the system catalog. This bug does not affect new installs of AppLogic 2.3.

13. Defect SCR 2348 - JSError occurs in the editor if user deletes an application property that is redirected to a mandatory appliance property

If you need to delete an application property that is redirected to a mandatory appliance property, use the new edit descriptor feature in the editor and manually remove the application property from the application's descriptor.

14. Defect SCR 1646 - Sometimes the monitoring GUI gets stuck while creating a new view

If this problem occurs, the user must refresh the page in order to continue using the monitoring GUI. In other cases the GUI may not get stuck but the new view will not be created. The user will have to re-create the view a second time. This bug is rare and has only been seen a few times.

15. Defect SCR 2341 - Cannot stop system applications using the AppLogic GUI's application list page

Users cannot stop system applications from the application list page in the AppLogic GUI (such as filer applications). In order to stop system applications, please use the web shell.

16. Defect SCR 2342 - Application list page occasionally displays apps that do not exist

This problem only occurs if the user is creating/destroying applications with the same name. Refeshing the browser fixes this issue.

17. Defect SCR 2330 - Can't save application changes if viewing the interior of an assembly instance

While viewing the interior of an assembly, if the user makes changes to the application using the application configuration GUI, user cannot save the application changes. In order to save the changes, the user must navigate up to the main application assembly.

18. Defect SCR 2313 - IE6/7 are about 2x slower than FireFox when using the AppLogic GUI

The main slowdown occurs when opening an application in the AppLogic application editor. 3tera may optimize the AppLogic GUI in the future to eliminate this problem.

Unreproducible Problems and Issues

The following list of problems have been observed in AppLogic 2.3 but are extremely difficult to reproducible (if at all) and have only been observed once or twice. If any of these issues appear on your grid, please send a bug report to 3tera describing which problem occurred and which AppLogic commands were executed that led to the failure.

1. Defect SCR 2280 - Grid controller became unresponsive and then rebooted during app import/app start

There is an issue related to importing an application onto a grid and starting/stopping another application in parallel. There has been 2 occurances where the grid controller became unresponsive during the app import/app start and the grid eventually rebooted itself.

2. Defect SCR 2281 - Volume operation failed during parallel volume operations due to XEN failure on AppLogic server

While executing parallel volume operations, one of the volume operations failed. The failure was caused by the inability of AppLogic to start the filer application for the volume operation due to an apparent bug in XEN 3.2.1 (XEN failed to initialize the block back device for the filer appliance).

3. Defect SCR 2326 - An AppLogic server failure during app provisioning made the grid un-usable

There has been one observed case where during an app provision, an AppLogic server failure (intentional reboot of the server in this case) caused the app provision to fail and the grid became unusable. All application start and volume operations fail. The only recovery is to reboot the entire grid using grid reboot.

4. Defect SCR 2350 - An AppLogic server failure during app provisioning caused the app provision operation to fail

During a provision of a Sugar CRM application (during the volume copy phase), user intentionally rebooted srv2 on the grid which held the grid controller's system volumes and the app provision failed. The app provision should not have failed, it should have passed even through srv2 was lost.

5. Defect SCR 2347 - A volume resize operation failed 1 time out of 4500 operations

While 3tera was testing the volume operations in AppLogic 2.3, vol resize failed 1 time out of 4500 operations. The AppLogic filer appliance timed out during appliance boot.

6. Defect SCR 1968 - Application gets stuck in the "stopping" state

Very rarely when an application is stopped, it may get stuck in the "stopping" state (observed only once). In order to recover from this, the entire grid must be rebooted.

7. Defect SCR 2284 - The AppLogic volume browser sometimes does not work under IE6

Occasionally some of the edit controls do not work in the volume browser in IE6.

8. Defect SCR 1975 - Occasionally AppLogic operations involving the impex volume fail (i.e., class import/export)

Occasionally when an AppLogic grid is rebooted, the impex volume is not setup correctly on the grid controller. This causes failures when using AppLogic operations that involve the impex volume such as mounting volumes, class/catalog/application import/export, etc. This issue should be resolved in AppLogic 2.3. In order to work around this issue in case it occurs, execute the following commands as a grid maintainer (if the following workaround does not work on your grid, please contact 3tera support).

• /etc/init.d/nfs restart
• /etc/init.d/3trsh-init stop
• /etc/init.d/3trsh-init start
• mount /dev/hda3 /vol/_impex
• chown applogic:applogic /vol/_impex

9. Defect SCR 2285 - Stopping a component in a running application failed with cannot free resource error

User attempted to stop a single running component in a running application. The comp stop command failed stating that it could not free the resources for the component and left the component in a standby state. Stopping the application freed the component's resources.

10. Defect SCR 2286 - app stop --all failed after a failed application provision due to a lost server

A user intentionally killed an AppLogic server while provisioning an application. Afterwards, the user attempted to stop all running applications on the grid using app stop --all. One of the applications failed to stop and the application was left in a standby state. Stopping the same appliation a second time fixed the issue.

11. Defect SCR 2283 - Dashboard did not automatically refresh and display updated IP ranges

User modified the IP ranges for the grid using ALD and the dashboard did not display the updated ranges. If this occurs, refreshing the dashboard page forces the dashboard to display the correct IP ranges.

Contact Information

For questions about this release and its operation, please contact Technical Support:

Self-help Resources

• http://doc.3tera.net -- AppLogic product documentation
• http://support.3tera.net -- AppLogic discussion and support forum
• http://www.3tera.com/grid_university.html -- Grid University: free interactive and recorded training sessions

These links are also accessible through the Support Tab of your grid dashboard.

3Tera Partner Resources

3Tera partners and direct licensees can also obtain contract-based support and additional information resources.

On-line

• http://wiki.3tera.net -- 3Tera partners wiki
• https://helpdesk.3tera.com -- 3Tera partners support portal
• http://bugs.3tera.net -- AppLogic change tracking system

Live Support

• e-mai: support@3tera.com
• phone: (888) 492-4738
• fax: (949) 305-0160, ATTN: Technical Support

Support hours are Monday through Friday, 9:00am to 6:00pm Pacific Time (GMT-0800). We may be able to respond outside these hours. Please mark urgent messages as such.

When calling the emergency phone support, please e-mail to support first -- this will ensure that all support engineers will have access to your information. Keep in mind that the phone support rings several engineers in sequence; don't hang up while it is ringing.

Interactive Sessions

We can set up interactive help sessions using WebEx. To reach our WebEx site, go to http://3tera.webex.com/. You should also receive from us a meeting number to set up a successful session.

We have verified access with the following browsers/OS combinations:

• Windows XP: MS Internet Explorer, Mozilla Firefox
• Linux: Mozilla Firefox with Java plug-in

WebEx sessions require Java or ActiveX to work. For more information on system requirements and to test whether your browser can access WebEx, go to http://developers.webex.com/api/jointest/index.php.