AppLogic Release Notes

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

Note: This release is the official AppLogic 2.9 general availability production release and supersedes AppLogic 2.8.9 and all previous 2.9.* releases; it is suitable for all customer deployments.

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, Windows and Solaris, and all popular open-source middleware, such as Apache, MySQL, JBoss and Ruby on Rails.

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.9.9 for users of the AppLogic 2.9.3 limited availability release

AppLogic 2.9.9 is functionally identical to the 2.9.3 release. In addition, it includes several bug fixes and additional Windows 2008 Server support for both IIS (Microsoft Internet Information Server) and SQL (Microsoft SQL Server).

If using Windows 2003 or 2008 server and you already have your Windows-based filers before upgrading to this new release, you must upgrade your Windows-based filers to the latest version included in this release. See the Windows upgrade documentation for more information.

AppLogic 2.9 now contains strict network configuration enforcement and as such will not work on systems that do not conform to the documented certified network configuration. AppLogic 2.9 should not be used on systems that have bypassed the documented certified configuration. The documented certified configuration is described here (only accessible to grid maintainers). AppLogic 2.9 does also support a "legacy" mode which allows 2.9 to be used with network configurations that were used for AppLogic 2.8 and earlier releases; see the ALD reference for more details (only accessible to grid maintainers).

What is new in AppLogic 2.9.9 for users of AppLogic 2.9 beta

AppLogic 2.9.9 includes bug fixes and several other important advances for AppLogic users:

• Windows 2008 Server is now supported for AppLogic appliances. This includes support for a Windows 2008 server-based filer, Windows server generic appliance, VDS (virtual dedicated server), IIS and SQL. AppLogic supports both 32-bit and 64-bit (R2), and also provides support for all editions (Web, Standard, Enterprise and DataCenter).
• The AppLogic application programming interface provides a web service interface to one or multiple AppLogic grids through a Representational State Transfer (REST) based service (considered "beta" at this time). The AppLogic web Services API enables developers of RESTful client software to directly interface with AppLogic based Virtual Data Centers (VDC) (i.e., an AppLogic grid). The API allows for programmatic control of large pools of virtualized infrastructure to be available within each VDC. In order to use the Web Service API, the WS_API application should be running on a grid. The WS_API application provides HTTP, HTTPS and VPN based access to the API.
• A new AppLogic utility called image2class is now available which allows users to import virtual machine images as AppLogic appliance classes. This makes it easy for users to migrate workloads from existing virtualization deployments into AppLogic. The virtual machine image that is being imported may be located on either the grid's impex volume or on a remote site accessible over HTTP/HTTPS. image2class currently supports only Linux-based virtual machines that comply with the Open Virtualization Format (OVF).
• AppLogic now supports global read-only volumes that can be used by maintainers to organize and provide common appliance or application files. Regular users have read-only access to these global volumes where as maintainers have full control.
  • AppLogic 2.9 ships with 3 global read-only volumes that contain all of the files neccessary to build new AppLogic appliances. There is one global read-only volume for each type of OS supported by AppLogic (apk_windows, apk_linux and apk_solaris). These volumes contain the files needed for building new appliances, such as the AppLogic APK, PV drivers, Linux kernels, etc. Simply attach one of the apk volumes to your appliance and the appliance has local access to all of the files.
• AppLogic now allows users to control the keyboard mapping for any HVM-based virtual appliance.
• Incorporates all of the AppLogic 2.8 hotfixes and some additional bug fixes for issues found during the 2.9 beta. See the key bug fixes for a list of the key issues that were resolved in this release.
• AppLogic 2.9 is compatible with existing applications built for AppLogic 2.8, 2.7, 2.4 and 2.1.

AppLogic 2.9 now contains strict network configuration enforcement and as such will not work on systems that do not conform to the documented certified network configuration. AppLogic 2.9 should not be used on systems that have bypassed the documented certified configuration. The documented certified configuration is described here (only accessible to grid maintainers). AppLogic 2.9 does also support a "legacy" mode which allows 2.9 to be used with network configurations that were used for AppLogic 2.8 and earlier releases; see the ALD reference for more details (only accessible to grid maintainers).

What is new in AppLogic 2.9.9 (in general and for users of AppLogic 2.7/2.8)

The main focus of the AppLogic 2.9 release is to provide complete autonomic operation with the new addition of Network High-availability. Network HA provides reliable operation in the event of network-related failures (both the external and backbone networks are taken into account). When a network failure occurs, all servers in the grid remain operational and all applications/appliances continue to operate uninterrupted (as long as neither of the networks are fully unavailable). In order to take advantage of this new feature, the physical servers within the grid must be set up with redundant networking: a pair of switches are used for each of the external and backbone networks, which enables the grid to withstand various physical NIC and switch failures.

In addition, 2.9.9 includes several other important advances for AppLogic users:

• Windows 2008 Server is now supported for AppLogic appliances. This includes support for a Windows 2008 server-based filer, Windows server generic appliance, VDS (virtual dedicated server), IIS and SQL. AppLogic supports both 32-bit and 64-bit (R2), and also provides support for all editions (Web, Standard, Enterprise and DataCenter).
• The AppLogic application programming interface provides a web service interface to one or multiple AppLogic grids through a Representational State Transfer (REST) based service (considered "beta" at this time). The AppLogic web Services API enables developers of RESTful client software to directly interface with AppLogic based Virtual Data Centers (VDC) (i.e., an AppLogic grid). The API allows for programmatic control of large pools of virtualized infrastructure to be available within each VDC. In order to use the Web Service API, the WS_API application should be running on a grid. The WS_API application provides HTTP, HTTPS and VPN based access to the API.
• External IPs can now be enforced by AppLogic for appliances that use external interfaces. A new property type called ip_owned can be used on the appliance's boundary to specify IP addresses that are enforced by AppLogic. AppLogic enforces that the value of an ip_owned property type is within the application IP range(s) configured for the grid. In addition, AppLogic enforces that the incoming/outgoing network traffic is limited to the specified IP address assigned to the appliance's external interface (as specified through the ip_owned property).
• A new AppLogic utility called image2class is now available which allows users to import virtual machine images as AppLogic appliance classes. This makes it easy for users to migrate workloads from existing virtualization deployments into AppLogic. The virtual machine image that is being imported may be located on either the grid's impex volume or on a remote site accessible over HTTP/HTTPS. image2class currently supports only Linux-based virtual machines that comply with the Open Virtualization Format (OVF).
• AppLogic now supports global read-only volumes that can be used by maintainers to organize and provide common appliance or application files. Regular users have read-only access to these global volumes where as maintainers have full control.
  • AppLogic 2.9 ships with 3 global read-only volumes that contain all of the files neccessary to build new AppLogic appliances. There is one global read-only volume for each type of OS supported by AppLogic (apk_windows, apk_linux and apk_solaris). These volumes contain the files needed for building new appliances, such as the AppLogic APK, PV drivers, Linux kernels, etc. Simply attach one of the apk volumes to your appliance and the appliance has local access to all of the files.
• Various catalog software upgrades; LUX, LINUX and VDSes were re-based on CentOS 5.4
• MYSQLR has been re-added to the system catalog (originally removed in AppLogic 2.8.9)
• AppLogic now allows users to control the keyboard mapping for any HVM-based virtual appliance.
• The storage health monitoring feature introduced in AppLogic 2.7 has been re-enabled in AppLogic 2.9. AppLogic now logs detected hard disk storage issues to the grid dashboard.
• Support for the 3tera AppStore (the new appstore utility), an e-commerce site offering AppLogic appliances and application templates for use on-demand in AppLogic virtual private data centers. AppStore is currently in private beta trials.
• Server state is now persistent across grid reboots. For example, if a server is disabled using srv disable and then the grid is rebooted, the server remains disabled (in previous AppLogic releases, all servers are enabled by default upon grid boot).
• Incorporates all of the AppLogic 2.8 hotfixes and some additional bug fixes. See the key bug fixes for a list of the key issues that were resolved in this release.
• AppLogic 2.9 is compatible with existing applications built for AppLogic 2.8, 2.7, 2.4 and 2.1.

AppLogic 2.9 now contains strict network configuration enforcement and as such will not work on systems that do not conform to the documented certified network configuration. AppLogic 2.9 should not be used on systems that have bypassed the documented certified configuration. The documented certified configuration is described here (only accessible to grid maintainers). AppLogic 2.9 does also support a "legacy" mode which allows 2.9 to be used with network configurations that were used for AppLogic 2.8 and earlier releases; see the ALD reference for more details (only accessible to grid maintainers).

What is new in AppLogic 2.9 for AppLogic 2.4 users

The main focus of AppLogic 2.9 is to provide for autonomic operation of AppLogic. This reduces the operational cost of AppLogic and improves the availability of applications and services running on a grid. The most important new feature is the ability to recover from network and grid controller failures without human intervention and without affecting the applications running on the grid. AppLogic now contains the following key new features and capabilities:

• Auto-diagnostic and self-healing enhancements
  • Automatic volume repair: AppLogic automatically schedules and performs volume repair, including retries, in order to maintain the availability of running applications. The operator can still postpone repairs when necessary for performance reasons.
  • Network High-availability: AppLogic automatically recovers from external and backbone network failures in order to maintain the availability of running applications.
  • Grid Controller Restart: The AppLogic controller can now be restarted while leaving all applications running. Further, the controller is now monitored like all applications and will be restarted automatically in the event of failure. This significantly improves the uptime of applications running under AppLogic and reduces the operator workload associated with managing maintenance windows.
  • Improved server isolation: AppLogic can now fully eliminate failed servers from the grid to prevent them from interfering with the grid's operation. This also allows operators to power-cycle, power-down and power-up servers in the grid (via IPMI).
• The AppLogic application programming interface provides a web service interface to one or multiple AppLogic grids through a Representational State Transfer (REST) based service (considered "beta" at this time). The AppLogic web Services API enables developers of RESTful client software to directly interface with AppLogic based Virtual Data Centers (VDC) (i.e., an AppLogic grid). The API allows for programmatic control of large pools of virtualized infrastructure to be available within each VDC. In order to use the Web Service API, the WS_API application should be running on a grid. The WS_API application provides HTTP, HTTPS and VPN based access to the API.
• External IPs can now be enforced by AppLogic for appliances that use external interfaces. A new property type called ip_owned can be used on the appliance's boundary to specify IP addresses that are enforced by AppLogic. AppLogic enforces that the value of an ip_owned property type is within the application IP range(s) configured for the grid. In addition, AppLogic enforces that the incoming/outgoing network traffic is limited to the specified IP address assigned to the appliance's external interface (as specified through the ip_owned property).
• A new AppLogic utility called image2class is now available which allows users to import virtual machine images as AppLogic appliance classes. This makes it easy for users to migrate workloads from existing virtualization deployments into AppLogic. The virtual machine image that is being imported may be located on either the grid's impex volume or on a remote site accessible over HTTP/HTTPS. image2class currently supports only Linux-based virtual machines that comply with the Open Virtualization Format (OVF).
• AppLogic now supports global read-only volumes that can be used by maintainers to organize and provide common appliance or application files. Regular users have read-only access to these global volumes where as maintainers have full control.
  • AppLogic 2.9 ships with 3 global read-only volumes that contain all of the files neccessary to build new AppLogic appliances. There is one global read-only volume for each type of OS supported by AppLogic (apk_windows, apk_linux and apk_solaris). These volumes contain the files needed for building new appliances, such as the AppLogic APK, PV drivers, Linux kernels, etc. Simply attach one of the apk volumes to your appliance and the appliance has local access to all of the files.
• Storage Health Monitoring allows AppLogic to monitor the hard disk storage devices within the grid and log detected storage issues to the grid dashboard (potential hard disk failures, etc).
• Support for 32-bit and 64-bit Microsoft Windows 2003/2008 Server
• Various catalog software upgrades; all appliances/applications re-based on CentOS 5.x, in addition LUX, LINUX and all VDSes are re-based on CentOS 5.4
• Several new catalog appliances:
  • NASR: replicated NAS for implementing disaster recovery (DR)
  • VPN: Virtual Private networking appliance, includes IPv6 and ipsec support (ipsec is only for IPv4)
  • URLSW: URL port switch for distributing HTTP requests to different appliances based on a regular expression
  • SQUID: SQUID proxy (web cache). SQUID keeps local copies of frequently requested data and returns cached content when applicable; thus decreasing response time and load on the backend servers
  • MYSQLR/MYSQLR64: 32/64-bit replicated MySQL databases
  • OSOL/OSOL64: 32-bit/64-bit OpenSolaris appliances based on OpenSolaris 2008.11
• Support for several new Microsoft Windows appliances (based upon Windows 2003 server)
  • IIS03x: Microsoft Internet Information servers
  • IIS03yx4/IIS03yx8: Scalable Microsoft Internet Information servers
  • SQL08x: Microsoft SQL server database appliances
• New Microsoft Windows template applications. These are just like the existing Linux Lamp applications except they are based on the IIS/SQL/ASP.NET Microsoft application stack:
  • WISA: simple 2-tier non-scalable Windows application
  • WISAx4: simple 2-tier scalable Windows application
• New 32-bit OpenSolaris VDS application: VDS_OSOL
• Updated sample applications that contain the latest versions of SugarCRM and TWiki
• Various appliance updates: INSSLR now contains healthchecks just like HALB, support for webdav and security enhancements, HALB now supports IPv6 and ipsec, MYSQLx/WEBx allow the timezone to be configured, all appliances contain support for iSCSI (built into the distributed domU kernel), appliances that use the APK have access to the _APPLOGIC_USERID environment variable that contains the name of the current user who is logged into the appliance via SSH
• The AppLogic GUI contains several improvments: it is now accessible using Google Chrome on Windows and Apple Safari on MAC in addition to Internet Explorer and FireFox, singleton appliances are denoted by an S icon in the upper-right corner
• AppLogic now allows users to control the keyboard mapping for any HVM-based virtual appliance.
• Server information displayed by srv info now includes additional server information such as BIOS vendor/version/date, motherboard manufacturer/model/version, server uptime, HA role used for grid controller HA, reason for server reboot/shutdown/power-cycle, and whether storage health monitoring and server management (power control) is supported/enabled
• Applications now have the following new states:
  • BUILDING: application is currently being built
  • RESTARTING: application is currently starting as part of an application restart
  • RESTART_STOPPING: application is currently stopping in preparation for an application restart
  • UNKNOWN: AppLogic has not yet determined the state of the application; only present during grid controller boot
• The release contains 120+ bug fixes that resolve various defects from previous AppLogic releases. It also includes all previous AppLogic hotfixes.
• Includes the new appstore utility that is used to query/download purchased products from 3Tera's AppStore.

Note that this release is backwards compatible with all 2.1/2.3/2.4/2.7/2.8 installations, appliances and applications.

Key Bug Fixes

The following key defects have been resolved in AppLogic 2.9.9:

• SCR 3818: Product: security vulnerability
• SCR 3806: Product: add support for Cisco switches that don't provide explicit switch ID in the CDP packets
• SCR 3698: EDT: Chrome on Windows 7: various UI dialogs/windows do not work
• SCR 3760: EDT: cut/copy of annotation does not operate as expected when pasted into interior of sub assembly
• SCR 3788: CPL: Chrome (MAC): entering vi after resizing the webshell window incorrectly renders the file contents
• SCR 3790: CPL: FF: copying text in the webshell results in a JS error
• SCR 3793: EDT: Branching of a class is not completed if popups are disabled
• SCR 3776: CAT: CCA: Windows: custom counter types are incorrectly reported
• SCR 3777: CAT: CCA: Windows: CCAD fails to start on some Win08 appliances when /etc/ccad.conf is present
• SCR 3800: CAT: WEB: apache counter script eating 100% of the CPU
• SCR 3803: CAT: Windows APK on localized installation does not report PV drivers correctly
• SCR 3769: ALD: mid-upgrade failures are not handled correctly
• SCR 3808: ALD: controller memory should be configurable up to 8 GB of memory

Hotfixes for AppLogic 2.9.9

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

Mandatory Hotfixes

• hf3240: Resolves a networking issue which may cause an AppLogic grid to crash
• hf6099: Adds support for the Intel 55xx chipsets (requries e3882)

Recommended Hotfixes

• None.

Optional Hotfixes

• hf3820: Resolves issue with the web API application where it won't accept special characters for some of the command arguments
• hf2668: Enables bandwidth oversubscription (appliances may use more bandwidth than their configured bandwidth)
• hf3388: Disables the storage failure detection feature (for testing purposes only)
• hf1248: Add support for controlling the volume repair speed of a grid from the distribution server
• e3624: Facilitates classes to be moved from one global catalog to another from the aldo server
• e3856: Adds support for displaying the effective configuration of an application
• e3882: Provides enhanced network and hard disk controller support (upgrade to CentOS 5.5 and Xen 3.4)

Installation/Upgrade/Migration notes and issues for AppLogic 2.9

This section describes various issues/how-tos related to AppLogic 2.9 installation and upgrades. Carefully read and follow the instructions for each issue to ensure a properly working AppLogic 2.9 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). When adding a new server to your grid, be sure to re-apply any hotfixes that affect the AppLogic servers (as specified in the hotfix documentation).

• Installing a new 2.9 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 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.

• 64-bit support in AppLogic 2.9: AppLogic 2.9 requires that all servers have 64-bit support. The AppLogic installer will fail a new installation/upgrade/add server if all servers do not have 64-bit support.

• Upgrading from AppLogic 2.1.x/2.2.2/2.3.8-2.4.x/2.7.x/2.8.x/2.9.x: AppLogic 2.9 supports upgrades from either 2.1.x/2.2.2/2.3.x/2.4.x/2.7.x/2.8.x 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). Upgrade your grid by simply executing the following command from your AppLogic 2.9 distro: ./aldo upgrade grid=mygrid. If your AppLogic 2.1.x/2.2.2 grid does not use the AppLogic partitioning schema, you must install a new AppLogic 2.9 grid on separate servers and migrate your applications, catalogs and users over to the new 2.9 grid.
  • If using Windows 2003 or 2008 server and you already have your Windows-based filers before upgrading to this new release, you must upgrade your Windows-based filers to the latest version included in this release. See the Windows upgrade documentation for more information.

• Upgrading from AppLogic 1.2.x/2.0.x: AppLogic 1.2.x/2.0.x grids cannot be upgraded to AppLogic 2.x. A new AppLogic 2.x grid must be installed on separate servers and the 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/2.0.x grid, reboot its servers before using them for an AppLogic 2.x installation.

• Migrating applications from an AppLogic 2.3.x/2.4.x/2.7.x/2.8.x grid to a AppLogic 2.9 grid: Migrate your appliances, catalogs and applications to your new 2.9 grid. 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.9 distro, execute the following:
    • ./upgrade_kernels.sh controller-IP --force
    • Be sure to specify the correct controller IP address
  • The upgrade script may take a few minutes to complete.
  • After the script has completed, your new grid is ready for use.
  • At this point, all appliances and applications should be migrated to the new grid and updated with the latest Linux kernel.
  • Note that in 2.9, the following obsolete appliances have been removed from the catalog: HLB, MYSQL64, PGSQL, WEB4. If your applications are using any of these obsolete appliances, they should be replaced with the appliances described in this section below. The applications can be updated after they are migrated to your new 2.9 grid.

Be sure to use the app migrate command from the web shell to migrate your applications between grids. The application migration wizard in the GUI will only work between 2.4/2.7/2.8/2.9 grids.

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 currently keeps volumes mirrored across two 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 run time component that virtualizes the hardware resources used by applications.
• Logical connection manager: a run time 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 run time 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, release notes, 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.

The AppLogic application programming interface is also available which provides a web service interface to one or multiple AppLogic grids through a Representational State Transfer (REST) based service (considered "beta" at this time). The AppLogic web Services API enables developers of RESTful client software to directly interface with AppLogic based Virtual Data Centers (VDC) (i.e., an AppLogic grid). The API allows for programmatic control of large pools of virtualized infrastructure to be available within each VDC. In order to use the Web Service API, the WS_API application should be running on a grid. The WS_API application provides HTTP, HTTPS and VPN based access to the API.

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 27 appliance classes, ready to use in applications.

• TOMCAT/TOMCAT64: Tomcat application server (Sun Java machine and Apache Tomcat); 32-bit and 64-bit
• WEB5/WEB64: Apache-based web server with plug-in content/scripts volume
• WEBx4, WEBx8: Scalable web servers
• MYSQL5: MySQL-based database server
• MYSQLR/MYSQLR64: 32/64-bit MySQL-based database servers suitable for replication
• PGSQL64: PostgreSQL database server 64-bit appliance
• 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
• SQUID: SQUID proxy (web cache)
• HALB: Session-aware HTTP load balancer based on HA Proxy
• L3LB: TCP/UDP load balancer based on HA Proxy
• PS8: Scalable port switch for distributing TCP and UDP traffic to different appliances
• RPL: Event replicator that replicates incoming HTTP requests to different appliances
• URLSW: URL port switch for distributing HTTP requests to different appliances based on a regular expression
• INSSL: HTTP Input Gateway with SSL Support
• INSSLR: Redundant HTTP Input Gateway with SSL Support (useful for disaster recovery purposes)
• IN, OUT, NET: Firewalled network gateways based on iptables
• MON: Application Monitor used to monitor running applications (collects and displays counters using visual graphs)
• LUX5/LUX64, LINUX5/LINUX64: A tiny and a minimal Linux appliances that can be used as basis for new appliances

The system catalog also contains 2 beta appliance classes.

• VPN: Virtual Private networking appliance
• NASR: Replicated Network attached storage / file server appliance (HTTP and CIFS file access)

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

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

The following classes were removed from the system catalog and are now superseded by newer classes. 3tera recommends to update your AppLogic applications to use the latest appliances as specified below:

• HLB: Session-aware HTTP Load Balancer, superseded by HALB
• MYSQL64: MySQL Database Appliance, superseded by MYSQLR64
• PGSQL: PostgreSQL Database Appliance, superseded by PGSQL64
• WEB4: Simple Web Server Appliance, superseded by WEB5/WEB64

Here is some best practice information on how to update your applications (if they are using any of the obsolete classes mentioned above):

• It is best to replace these appliances in your applications before the applications are migrated to your new 2.9 grid (assuming you are using 2.4/2.7/2.8 and these appliances exist on your grid). In this case, the appliances can be replaced by opening the application in the application editor, hold the SHIFT key and drag/drop the new appliance class over the existing appliance class on the canvas. The editor will prompt to make sure you want to replace the class. Repeat this for all of the obsolete appliance classes in all of your applications. Doing it this way will preserve all property settings and connections within the applications. Afterwards, save your application and the updated application is ready to be used. Note that this will work for all of the obsolete appliances above except for HLB. For HLB, use the following recommendation.
• If you are migrating applications from an older grid such as AppLogic 2.1 or do not have access to the newer classes mentioned above, you will have to update your applications after they are migrated to your new 2.9 grid. When you open your application in the editor, the editor will display a message stating that the appliance class is missing, and the appliance will disappear from the canvas. In this case, you will need to drag the new appliance class instances onto the canvas and re-parameterize/re-connect the appliances. Afterwards, save your application and the updated application is ready to be used.
• If you do not replace the obsolete classes within your applications, the applications will fail to start. If you open such an application in the application editor, the editor will display a message stating that the appliance class is missing. In order to resolve these issues, follow the recommendations mentioned in this section above.

Note: INSSL, the HTTP Input Gateway with SSL Support, is now assembled out of INSSLR instead of being a stand-alone appliance.

3tera also supports Windows-based appliances (note that these appliances are not distributed with AppLogic. Please see the Windows Appliance Installation Reference for details on how to create these appliances on your AppLogic 2.9 grid):

• WIN03S/WIN0364S/WIN08S/WIN0864S: Windows 2003/2008 Server Standard Editions 32/64-bit
• WIN03E/WIN0364E/WIN08E/WIN0864E: Windows 2003/2008 Server Enterprise Editions 32/64-bit
• WIN03DC/WIN0364DC/WIN08DC/WIN0864DC: Windows 2003/2008 Server DataCenter Editions 32/64-bit
• WIN03W/WIN08W: Windows 2003/2008 Server Web Edition 32-bit
• IIS03x: Microsoft Internet Information servers (Standard/Enterprise/DataCenter/Web editions)
• IIS03yx4: Scalable Microsoft Internet Information servers (Standard/Enterprise/DataCenter/Web editions)
• IIS03yx8: Scalable Microsoft Internet Information servers (Standard/Enterprise/DataCenter/Web editions)
• SQL08x: Microsoft SQL server database appliances (Web/Standard/Enterprise/Developer/Workgroup/Express editions)

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 application 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

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

Sample Applications

This AppLogic release includes 19 ready-to-use application templates.

The AppLogic release includes the following Virtual Dedicated Server (VDS) application templates:

• Linux
  • VDS_CentOS54: 32-bit CentOS 5.4 VDS
  • VDS64_CentOS54: 64-bit CentOS 5.4 VDS
• SunOS
  • VDS_OSOL: 32-bit OpenSolaris VDS
  • VDS64_OSOL: 64-bit OpenSolaris VDS
  • VDS_SOL10: Solaris 10 VDS. This is not distributed with AppLogic. Please contact 3tera technical support for more information.
• Windows
  • VDS_Win03S/VDS_Win08S: 32-bit Windows 2003/2008 Server Standard Edition VDS
  • VDS_Win0364S/VDS_Win0864S: 64-bit Windows 2003/2008 Server Standard Edition VDS
  • VDS_Win03E/VDS_Win08E: 32-bit Windows 2003/2008 Server Enterprise Edition VDS
  • VDS_Win0364E/VDS_Win0864E: 64-bit Windows 2003/2008 Server Enterprise Edition VDS
  • VDS_Win03DC/VDS_Win08DC: 32-bit Windows 2003/2008 Server DataCenter Edition VDS
  • VDS_Win0364DC/VDS_Win0864DC: 64-bit Windows 2003/2008 Server DataCenter Edition VDS
  • VDS_Win03W/VDS_Win08W: 32-bit Windows 2003/2008 Server Web Edition VDS
  • Note that these applications are not installed on the AppLogic grid. Please see the Windows Appliance Installation Reference for details on how install and set up these applications.

The AppLogic release also includes the following preconfigured Linux-based infrastructure templates:

• Lamp: basic 2-tier non-scalable WEB application
• LampX4: scalable Lamp
• LampCluster: scalable Lamp cluster

The AppLogic release also includes the following preconfigured Windows-based infrastructure templates (based on Windows 2003 Server):

• WISA: simple 2-tier non-scalable WEB application (Windows/IIS/SQL/ASP.NET)
• WISAx4: simple 2-tier scalable WEB application (Windows/IIS/SQL/ASP.NET)
• Note that these applications are not installed on the AppLogic grid. Please see the Windows Appliance Installation Reference for details on how install and set up thse applications.

The AppLogic release also includes the following ready-made pre-installed application templates:

• TWiki: web-based collaboration platform
• SugarCRM: customer relationship management system
• WS_API: AppLogic web service API

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.

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

Aldo and its documentation are available only to grid maintainers.

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

Please contact your account manager for obtaining access to this release.

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

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

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.

After downloading the release, make sure you untar ALDO before attempting to install a grid (tar -xjf rel-ald-x.y.z.tar.bz2).

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

• maximum of 128 servers per grid supported (tested on up to 8 servers)
• 31 grids per back-end LAN
• 1024 applications per grid, up to 1024 applications running simultaneously
• If you need different dimensions, give us a call

Other Dimensional Limits

Please also see the OS limitations topic for more information.

• Per application
  • 512 network interfaces per application

• Per appliance, common dimensions
  • 64GB RAM
  • 16 CPU (1600%)
  • 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
  • 32-bit and 64-bit
  • 10 volumes
  • 10 network interfaces/terminals (including external and default interfaces)

• Per appliance: Windows 2003/2008 Server (Standard/Enterprise/DataCenter/Web R2 Editions, Standard SP2 Edition)
  • 32-bit and 64-bit (R2 for 2008 server)
  • 4 volumes
  • 8 network interfaces/terminals (including external and default interfaces)
  • maximum CPUs and memory (Microsoft Windows limitations are also documented here: http://technet.microsoft.com/en-us/library/cc758523.aspx)
    • Web: 4 CPUs, 2GB memory
    • Standard: 4 CPUs, 4GB memory
    • Enterprise: 8 CPUs, 64GB memory
    • DataCenter: 64 CPUs, 128GB memory

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

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

• Grid controller High-Availability
  • maximum of 1 primary server; where the grid controller VM is currently running
  • maximum of 7 secondary servers; where the grid controller may end up running in case of primary server failures
    • AppLogic has been certified to use up to 7 secondary servers

• Network High-Availability (physical network topology)
  • maximum of 2 switches for each network; external and backbone (4 switches in total)
    • each pair of switches must be of the same make/model and they must be identically configured
    • each switch must have LLDP enabled (link layer discovery protocol)
  • maximum of 4 NICs per physical server (2 NICs for the external network, 2 NICs for the backbone network)

• Automatic Volume Repair
  • maximum of 1 volume repair scheduled per server

• 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, Intel Nehalem (Core i7: Lynnfield 860), 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
  • Requires either Intel VT or AMD-V for hardware virtualization support (HVM)
    • HVM is mandatory for running Solaris 10 and Microsoft Windows on your grid
    • HVM is mandatory for using iso2class to install new appliances based on different OS distros

• 64-bit support (32-bit servers are not supported)
  • maintainers can only use 64-bit enabled servers in their AppLogic grids

• Minimum 2GB RAM (4 GB recommended, 64 GB tested)
• Maximum 64GB RAM per server

• 80 GB IDE/SATA/SAS/SCSI/SSD 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
    • nVidia Corporation CK804 IDE (rev a2)
    • nVidia Corporation CK804 Serial ATA Controller (rev a3)
    • Intel Corporation Ibex Peak 2 port SATA IDE Controller (rev 05)
    • Intel Corporation Ibex Peak 4 port SATA IDE Controller (rev 05)
    • Intel Corporation 82801JI (ICH10 Family) 2 port SATA IDE Controller
    • Intel Corporation 82801JI (ICH10 Family) 4 port SATA IDE Controller
    • Intel Corporation 631xESB/632xESB/3100 Chipset SATA IDE Controller (rev 09)
    • LSI Logic / Symbios Logic SAS1068 PCI-X Fusion-MPT SAS (rev 01)
    • LSI Logic / Symbios Logic SAS1068E PCI-Express Fusion-MPT SAS (rev 08)
  • Supported: most IDE, SATA and SCSI devices supported by CentOS 5.3 (excl. Adaptec AHA-15xx). Details.
  • AppLogic has not been certified with any hardware RAID solutions and as such it is recommended to disable hardware RAID on all servers (each grid contains its own shared, mirrored storage pool; IP-based SAN). There are customers who are using AppLogic with their own RAID solutions but these types of configurations have not been certified/tested by 3tera.

• Dual Gigabit and 10G Ethernet adapters (Intel or Broadcomm recommended)
  • Certified:
    • Intel Corporation 82541GI/PI Gigabit Ethernet Controller
    • Intel Corporation 82571EB Gigabit Ethernet Controller (rev 06)
    • Intel Corporation 82574L Gigabit Network Connection
    • Intel Corporation 82576 Gigabit Network Connection (rev 01)
    • Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper) (rev 01)
    • Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet
    • Broadcom Corporation NetXtreme BCM5715 Gigabit Ethernet (rev a3)
    • Broadcom Corporation NetXtreme BCM5721 Gigabit Ethernet PCI Express (rev 11)
    • Broadcom Corporation NetXtreme II BCM5709S Gigabit Ethernet (rev 20)
    • Broadcom Corporation NetXtreme II BCM5716 Gigabit Ethernet (rev 20)
    • Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (as external 10/100 NICs)
    • Neterion's X3100 Series 10GbE PCIe (certified but is not going to be distributed with AppLogic in a future release)
  • Supported: most Gigabit Ethernet network adapters supported by CentOS 5.3. Details.

• Any single non-blocking gigabit Ethernet layer 2 switch (for private network; all ports must be on the same switch, no cascading)
  • the spanning tree protocol (STP) must be disabled on the switch
  • if using a network HA configuration, each switch must have LLDP enabled (link layer discovery protocol)
  • Certified:
    • 10G switches
      • Force10 S2410P - 24 port 10GigE XFP switch
    • 1G switches for network HA and non-network HA configurations
      • Cisco WS-C3560E-24TD
      • Cisco WS-C3560E-48TD
      • Cisco WS-C3560E-24TD
      • Cisco WS-C3750G-24TS-1U
      • Cisco WS-C2960G-48TC-L
      • Cisco WS-C2960G-24TC-L
      • Cisco IOS Software; C3560 Software (C3560-IPSERVICESK9-M); Version 12.2(40)SE

• Power-control for servers (IPMI-based)
  • AppLogic is certified to work with the following IPMI configurations:
    1. IPMI cards directly connected to the backbone configured to use non-routable IPs (10.x.x.x), seperate backbone from the servers used in AppLogic grids; accessible only through VPN on the internal network
    2. IPMI cards configured to use routable IPs; accessible from the external network using name/password (non-VPN)
  • The following IPMI configurations may work but have not been certified by 3tera:
    • Same as option #1 above except accessible through VPN on the external network
    • Same as option #2 above except that the IPMI is accessible from the internal network using name/password (non-VPN)

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

Software Compatibility

• Appliances
  • Please also see the OS limitations topic for more information.
  • Note: all OSes listed in this section were verified using iso2class (and hvm2pv when needed)
  • 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.3.2 support
    • 32-bit Tested: CentOS 5.x, RHEL 5.3, SUSE Enterprise 11, Ubuntu 8.0.4, Debian 5.0
    • 64-bit Tested: CentOS 5.0, CentOS 5.1, CentOS 5.3, CentOS 5.4, RHEL 5.3, Debian 5.0
    • Supported: all Linux distros based on recent 2.6 kernel (see Linux distros verified by AppLogic developers and users)
    • SUSE Enterprise APK is BETA; please report issues to 3tera technical support
  • OpenSolaris based
    • 32-bit and 64-bit are both supported
    • Verified with OpenSolaris 2008.11
  • Solaris 10 based
    • 32-bit only
    • Verified with Solaris 10 update 4
  • Windows 2003/2008 Server based
    • 32-bit and 64-bit
    • Verified with Windows 2003/2008 Server Standard/Enterprise/DataCenter/Web R2 Editions, Standard SP2 Edition
    • Windows 2003 Server 32/64-bit and Windows 2008 Server 32/64-bit are supported with the Halsign Turbogate PV drivers provided with the release

• Appliance volumes
  • File systems supported: ext2, ext3, ext3-snapshot, reiserfs, fat16, fat32, Solaris ufs, Solaris zfs, NTFS
  • Swap volumes are supported and optional for appliances
  • Integration services for other file systems are available

• AppLogic GUI
  • Browser support: Microsoft Internet Explorer (on Windows), Mozilla FireFox (on Windows/Linux/MAC), Google Chrome (on Windows/Linux/MAC), Apple Safari (on MAC)
  • Note: The graphical console does not work on Chrome/FireFox for MAC and on Chrome for Linux (this will be fixed in a future release)

• 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. 3tera also has a hotfix available that enables network bandwidth oversubscription that allows appliances to use more bandwidth than what is assigned. Please contact 3tera support on how to obtain/install this hotfix on your grid. The bandwidth oversubscription mode is displayed on your grid's dashboard.
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. 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.
7. 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.
8. 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.
9. Web browser's Javascript and pop-ups must be enabled to use the web-based graphical user interface (dashboard, editor, documentation)
10. Users are responsible for allocating, assigning and use of externally visible IP addresses for applications; AppLogic takes care of all internal network assignments
11. 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.
12. 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. When running Windows, the TCP network performance is about 940 Mbps and UDP is about 500-700 Mbps. A future release of AppLogic may contain optimizations that will improve the network performance of Linux, Solaris and Windows.
13. 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" (unless bandwidth oversubscription is enabled on your grid). CPU resources may be enforced to "exactly that much", using the new --cap_cpu option when starting the application.
14. 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.
15. 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.
16. 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.
17. There is no user visibility during a grid controller restart due to a grid controller VM failure. If the grid controller VM fails and AppLogic restarts the grid controller VM, there is no user visibility while the controller is restarting. Typically it takes 1-2 minutes for the grid controller to restart on its own. If the grid controller is unavailable for more than 5 minutes, please contact 3tera technical support.
18. There is an issue with the GUI that was reported when using older versions of FireFox; specifically version 3.0.14 on Microsoft Vista. When using the application editor, closing the editor window resulted in closing all of the AppLogic GUI browser windows, thus forcing the user to re-open their browser and login to the AppLogic GUI. Upgrading FireFox to the latest version resolved this issue (3.5.3 at the time of this writing). If you experience this issue or any other strange type of GUI behavior, please make sure your browser is updated to the latest version before reporting the issue to 3Tera.

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 3 or later, Microsoft Internet Explorer 6 or later, Google Chrome 3.0.195.24 or later, or Apple Safari 4.0.3 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.

3. 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.

4. 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).

5. 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.

6. The volume management GUI available via the filers 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.

7. zfs may be used on the boot volume of an OpenSolaris appliance

AppLogic does support booting OpenSolaris appliances from a zfs-based boot volume. Please note however that this has not been verified by 3tera and may not work. Solaris 10 does not support zfs.

8. 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.

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

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

10. 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.

11. Validation flags don't appear if the application is opened in read-only mode

To see the validation flags for an application, open the application in edit mode. The validation flags are used to flag appliances that do not have all of their mandatory properties/terminals/volumes properly configured.

12. Text-based graphical console must be used with Solaris 10 after installation

iso2class may be used to install a Solaris 10 appliance using the graphical console for the installation process. However, after the installation is complete and the appliance is re-started, the graphical console may still be used however it must be used in text mode (no access to the Solaris 10 desktop - strictly text-based access). This is due to a problem in the Solaris 10 GUI (not an AppLogic bug).

13. All of the appliances that are distributed with AppLogic are missing their GUI/desktop packages/support

Therefore, the graphical console cannot be used with these appliances. This is done on purpose to make the appliances as compact as possible. Using the new iso2class utility, users may create their own appliances with full desktop support.

14. Running more than 1 Windows application with appliances having the same instance name results in a duplicate computer name error from Windows

This error is due to the fact that AppLogic sets the computer name of an appliance to its instance name. Therefore, if you have more than 1 appliance running on a grid that all have the same instance names, the duplicate name error will be displayed in Windows on the graphical console. This error is just a warning and does not affect the grid or its operation. However, if you need to use Windows as a domain controller, you will need to set the computer names to unique names for each appliance. You may use the wincfg utility to set the computer name in your appliance.

15. The graphical console requires the latest version of Java in your IE/FF browser

3tera has tested with Java version 6 update 7 on IE/FF/Chrome/Safari. If the latest version of Java is not used, the graphical console may not work correctly (it will hang while trying to load). Before reporting graphical console errors to 3tera, be sure to check that you are using the latest Java version (if you need to upgrade java in your browser, be sure to re-open your browser afterwards in order for the graphical console to work correctly).

16. Application migration wizard in the GUI only works with 2.4.5-2.9 grids

The application migration wizard in the GUI will only work between 2.4.5-2.9 grids. If you need to migrate applications between other versions of AppLogic, use the app migrate command from the web shell.

17. Failover groups may not be satisfied upon controller recovery

When a secondary server takes over as the new primary server, if there are not enough resources available on the server to start the grid controller, AppLogic restarts appliances which are running on the new primary server on other servers within the grid so the grid controller can be started on the new primary server. Note that this may break appliance failover groups. If AppLogic stops one of these appliances it may not be able to restart the appliance on another server since there may not be enough resources to satisfy the failover group.

18. HVM-based appliances use more memory than their configured amount

All HVM-based appliances (Solaris 10, Windows, etc) use more memory on the server than what they are configured to use. Typically, depending upon the amount of memory assigned to an HVM-based appliance, the appliance uses additional memory on the server in which it is running (this additional memory is required by the virtualization hypervisor running on the servers and is known as shadow memory). Therefore it is possible that even though a server might have enough available memory as compared to what is assigned for the appliance, the appliance will not be able to run on that server due to the additional shadow memory needed for HVM-based appliances that is not available on the server. The AppLogic scheduler does take this extra shadow memory into account when scheduling appliances during application start.

19. The maximum network throughput between appliances running on different servers is 3.8Gbps when using a 10G backbone

When using a 10G backbone, the maximum throughput that can be achieved between appliances running on different servers is 3.8Gbps (possibly due to some sort of limitation within the hypervisor used by AppLogic). This limitation may be removed in a future AppLogic release.

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, Chrome or Safari 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. AppLogic automatically repairs these volumes as highest priority.

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 application 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 reset on your grid.

8. 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).

9. 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.

10. Defect SCR 2313 - IE6/7 are about 2x slower than FireFox/Chrome/Safari 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.

11. Defect SCR 2489 - Opening the graphical console in FF 3 rarely hangs

This problem has only been observed with FF 3 browsers (very rare). If the graphical console hangs when it is opened, close the browser, open up the AppLogic GUI and re-open the graphical console.

12. Defect SCR 2497 - It takes 15 minutes to re-open graphical console after client computer crashed while graphical console was open

If the client has the graphical console open and they lose connection to the internet (client network card failure, client computer crash, internet access is unavailable, etc), it will take 15 minutes to re-open the graphical console.

13. Defect SCR 2548/ SCR 2549 - Issues when using the AppLogic graphical console with Ubuntu

The mouse is hard to use in Ubuntu when using the AppLogic graphical console. This is due to a limitation of the XEN VNC support (mouse acceleration is not supported). Some users report that adjusting the mouse settings in Ubuntu resolves the issue. Also, rarely keystrokes will be repeated several times when typing in text from the keyboard (in such cases just delete the extra characters that are displayed).

14. Defect SCR 2534 - Cancelling a GUI operation occasionally does not cancel the operation

This problem was observed while trying to cancel a volume creation operation in the AppLogic GUI. If this problem occurs, simply cancel the operation a second time.

15. Defect SCR 2498 - All text entered by the user in the text boot console is echoed to the console

This includes passwords when logging into an appliance. The text boot console should only be used for debugging purposes. The SSH console can be used instead for all other purposes.

16. Defect SCR 2501 - User must press enter to see output in the text boot console after it is opened for the second time

If a user re-opens the text boot console for an appliance after it has already been opened, they must press the enter key to see either the login prompt or the command prompt. This is because the boot console is waiting for user input (either for login information or a command to be executed).

17. Defect SCR 2719 - Occasionally a user cannot monitor an appliance's external interface using MON

This only occurs on app copy and app provision when immediately afterwards the application is started (caused by component boot volumes being instantiated). Restarting the component after the application has been started resolves the issue.

18. Defect SCR 3107 - Appliances in failover groups are not accounted for when restarting the grid controller on a secondary server

If a grid has an appliance that is part of a failover group running on a secondary server where the grid controller needs to be restarted, AppLogic may stop that appliance which could break the failover group. This will be fixed in a future AppLogic release.

19. Defect SCR 2134 - Grid upgrade causes an incorrect warning about the cause of the grid reboot

After upgrading a grid to the latest release, a dashboard message is posted stating that the grid failed due to a hardware issue. This message can be safely ignored and removed from the dashboard. This issue will be fixed in a future release.

20. Defect SCR 3416 - Grid controller does not automatically recover if the primary server becomes unresponsive

There has been a single reported case of a primary server becoming unresponsive where AppLogic does not detect that the server is disfunctional. As a result, the grid controller is unresponsive and is never failed over to another secondary server within the grid. The only way to recover from this issue is to reboot the primary server. This issue will be fixed in a future release.

21. Defect SCR 3499 - The AppLogic APK does not work with latest Ubuntu 9.10 or 10.x releases

The appliance kit (APK) does not currently work with Ubuntu 9.10 or 10.x due to several incompatibilities with the newer OS. This issue will be fixed in a future release.

22. Defect SCR 3709 - Appliances become temporarily inaccessible (5 min) if external NIC fails in network HA configuration

If using a network HA configuration with AppLogic and there is an external network failure, applications/appliances that use external interfaces may become inaccessible for up to 5 minutes. This appears to be caused by the external router caching MAC addresses. Waiting for the router to flush its ARP cache or sending an ARP response with arping from the application restores operation. This only affects the external network (the backbone network is not affected).

23. Defect SCR 3693 - FireFox/Chrome on MAC - graphical console cannot be used

This issue will be fixed in a future release. The Safari browser may be used instead to access a graphical console.

Known Problems and Issues specific to Windows-based appliances

The following are the key known problems with Windows appliances in this release. Also, please review these important Windows appliance notes (dealing with appliance boundary changes, SIDs, computer names, Administrator passwords, etc).

1. Defect SCR 2751 - Windows filer volume resize can fail on a volume with a corrupt file-system

The Windows filer can fail a volume resize operation if the source volume contains a corrupt directory entry/file. The main source of this problem comes from the fact that some of the Microsoft software installations purposely contain invalid directory entries (we are not sure why this is; this has been observed when a user installed a version of Microsoft SQL server in their appliance). Additionally, the source volume can be corrupt due to normal ware and tear. This issue can be worked around by running a file system repair on the volume (vol fsrepair) before resizing the volume.

2. Defect SCR 3078 - Resizing an NTFS volume failed due to a Windows filer start failure

It has been observed by 3tera that the NTFS volume resize operation fails about 2 times out of 100. These 2 failures occured because the Windows filer failed to start correctly on the grid. If this issue is observed, repeating the resize operation a second time should succeed. This issue however should be resolved in this release; if this issue is observed please notify 3Tera technical support.

3. Defect SCR 2750 - Windows filer failed to create an ntfs volume (rare diskpart error)

The Windows filer uses a Microsoft utility called diskpart to deal with the Windows NTFS volumes. Occasionally diskpart fails to obtain volume information or may fail to mount the volume. This is a very rare failure and may cause either vol create or vol resize to fail over NTFS volumes.

4. Defect SCR 2490 - A branched Windows appliance with modified terminals failed to boot

If the user branches a Windows appliance and adds/removes terminals, the appliance may fail to boot. If the appliance is restarted a second time, it should boot without any issues. This problem has only been observed a single time.

5. Defect SCR 2514 - The APK applogic_init script failed which caused the Windows appliance to fail to boot

This has only been observed one time and looks like it is related to Windows dealing with failed DHCP requests (the applogic_init script may be timing out waiting for the DHCP to complete). The DHCP timeout has been increased in the applogic_init script from APK; this may workaorund the issue.

6. Defect SCR 2748 - Windows appliances occasionally detect duplicate IPs on their internal network

If the user has an application that contains a Windows appliance and one or more Windows appliances are added to the app or terminals are added/removed from the Windows appliances, during the first app start some of the Windows appliances may detect duplicate IPs on their internal network (this can only happen during the first app start after the application is modified). This should not cause any operational failure of the application or require user intervention; the duplicate IP addresses are purely temporary. Worse case, some of the network communication involving any of the Windows appliances may be delayed for up to 30-60 seconds. This will be fixed in a future AppLogic release.

7. Defect SCR 3021 - Windows application stuck at 99% during application stop

An attempt to stop a Windows application hung at 99%; the operation timed out after 15 minutes. The application contained 2 instances of a Windows 2003 Server DataCenter Edition appliance (WIN03DC). One of the Windows appliances stopped and the other one hung during "comp stop". This was only observed one time and could not be reproduced.

8. Defect SCR 2504 - Occasionally disk read/write counter values are reported as zero (Windows perfmon API bug)

Occasionally zeros are reported for the following disk I/O counters for Windows appliances (even though sustained I/O is being generated): total bytes written/read, # of volume writes/reads, time spent in writes/reads. This is due to a bug in the Windows perfmon API - the zero values is what is being reported by the Windows perfmon API.

9. Defect SCR 2821 - the Windows filer MSI do not work under localized Japanese Windows

Other than the filer MSI, localized Japanese Windows should work under AppLogic. This will be fixed in a future release.

10. Defect SCR 2862 - Windows appliance fails to start if a virtual DVD-ROM device is installed

A windows appliance fails to start if the MagicISO virtual DVD-ROM device is installed. Virtual DVD-ROM devices are not currently supported in AppLogic for windows-based appliances.

11. Defect SCR 2499 - It can take several minutes to discover new NICs in Windows appliances which can cause boot timeouts

Occasionally it takes several minutes for Windows to detect new NICs inside of an appliance. This occurs when the user adds/removes terminals for a Windows appliance singleton. The extra time it takes to detect these new NICs may cause appliance boot timeouts. To workaround this, increase the boot timeout of your Windows appliance.

12. Defect SCR 2505 - Migration of a windows appliance to another grid may trigger re-activation of the Windows appliance

If a user has a Windows appliance on their grid and they migrate the appliance to another grid that has different hardware, the Windows appliance may require re-activation (Microsoft's Windows re-activation). The re-activation is triggered when a specific amount of hardware has changed (it is unknown to 3tera exactly what hardware changes trigger the re-activation). Note that re-activation may require access to the internet from within the Windows appliance. This particular problem was observed after resizing the Windows appliance boot volume and migrating the appliance to a different grid.

13. Defect SCR 2503 - Occasionally the first attempt to download Windows msi files did not save the entire file

This is a known issue with Internet Explorer. Downloading the msi file a second time works.

14. Defect SCR 3814 - Windows 2008 filer root access permissions are limited via ssh

This issue only affects Windows 2008 Server 32/64-bit (Windows 2003 server works OK). When accessing a Windows 2008 volume either through the filer or via ssh to an appliance, the user may not be able to access/modify files due to permission issues. In order to access/modify files via the command shell, log in through the graphical console to the Windows desktop and open up a command shell. The command shell can be used to access/modify files.

Unreproducible Problems and Issues

The following list of problems have been observed in AppLogic 2.3/2.4/2.7/2.8/2.9 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. AppLogic 2.8/2.9 is based upon the latest stable version of the XEN 3.3.2 hypervisor, which may eliminate some of the issues reported below.

1. Defect SCR 2842 - Server rebooted due to a crash in the Linux kernel

A server in the grid rebooted on its own due to a crash in the Linux kernel in dom0 of the server. Under AppLogic 2.7/2.8, this would not cause the entire grid to fail like in previous AppLogic releases; but could cause application downtime. In such a case AppLogic restarts the appliances that were running on the failed server on other servers in the grid. If this issue is observed on your grid, please contact 3tera technical support.

2. Defect SCR 2834/ SCR 2887 - Server loses connection to the grid controller

In AppLogic 2.4, there have been several cases where a server loses connection to the grid controller and reboots. This causes all of the appliances that were running on the server to be rescheduled on other servers in the grid and can also cause application downtime. It is unknown why the servers are losing their connections to the grid controller. In AppLogic 2.7/2.8/2.9, if the server's connection to the grid controller is dissolved, the server tries to reconnect to the grid controller and if successful, the server remains operational and there is no application downtime. If the server cannot reconnect to the grid controller for 1 minute, the server is rebooted and application downtime occurs. When a server loses its connection to the grid controller, a message is logged to the dashboard. If this problem is observed, please contact 3tera technical support immediately.

3. Defect SCR 2903 - Volume resize of 4 NTFS volumes exeucted at the same time failed

On AppLogic 2.7/2.8, resizing 4 NTFS volumes at the same time caused all 4 volume resize operations to fail. This issue has been observed only once.

4. Defect SCR 2945 - Grid controller fails and restarts due to low memory condition caused by executing many operations at the same time

User executed 7 app copies, 1 app start and 4 iso2class installs at the same time which caused the grid controller to fail due to the Linux OOM killer (low memory). This will be fixed in a future release. It is recommended not to execute > 3 app copy operations in parallel.

5. Defect SCR 2931 - Failed to start repair on 2 volumes after a large number of degraded volumes were repaired

After removing a server from a grid, a large number of volumes became degraded. AppLogic automatically repaired all of the degraded volumes except for two of the volumes. The volumes failed to be repaired due to a "volume not found" error. Restarting the grid controller fixed the issue. This issue has been observed only once.

6. Defect SCR 2944 - Application import of LampX4 failed

This error occurred during a grid upgrade to AppLogic 2.7. If this failure is observed, the application can be imported manually using the ALDO ai command. This issue has been observed a few times.

7. 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.

8. 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.

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.

12. Defect SCR 3289 - NASR replication failure was observed when almost out of disk space

While NASR was replicating an 800MB file on a 1GB volume, the NASR appliance became unresponsive. 3tera is unable to reproduce this issue. If this issue is encountered on your grid, please notify 3tera support.

13. Defect SCR 3300 - Grid controller became unresponsive while many parallel volume operations were being executed

While around 10 volume operations were executed in parallel on the grid controller (create, resize, copy), the grid controller became unresponsive. AppLogic will automatically detect this issue and recover the grid controller. 3tera is trying to reproduce this issue and it will be fixed in a future release.

14. Defect SCR 2203 - Stuck volume mount causes failures to start applications (rare, can't reproduce)

Very rarely an application will fail to start due to a stuck volume mount on one of the servers. AppLogic detects stuck volume mounts and reports them to the user on the grid's dashboard. If this problem occurs on your grid, please notify 3tera support.

15. Defect SCR 3711 - Opening many graphical consoles crashed a server in the grid

User opened 6+ graphical consoles to different windows appliances running on the grid (opened at the same time). Upon opening the 7th graphical console, one of the servers rebooted and rejoined the grid. The appliances that were running on the failed server were restarted on other servers within the grid. This issue has only been observed once.

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-mail: 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.