r24 - 24 Nov 2009 - 13:57:53 - EricTYou are here: Wiki >  AppLogic24 Web > ReleaseNotes-2-4-10
ALERT! AppLogic 2.4 Documentation The latest production release is AppLogic 2.8.9

AppLogic Release Notes

Version 2.4.10 - July 21, 2009

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

Note: This release is the official AppLogic 2.4.10 production release and supersedes AppLogic 2.4.8; it is suitable for all customer deployments.

Note: AppLogic 2.4.10 is the same as AppLogic 2.4.8 with all of 2.4.8 hotfixes applied plus a few additional bug fixes.

Overview

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

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

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

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.4.10 for AppLogic 2.4.8 users

Please see the key bug fixes for the full list of changes between AppLogic 2.4.8 and 2.4.10.

What is new in AppLogic 2.4.10 for AppLogic 2.4.7 users

For 2.4.7 users, 2.4.10 contains the key bug fixes and also includes the following bug fixes that were introduced in AppLogic 2.4.8:

  • SCR 2280: Product: grid controller may become unresponsive (also affects other appliances)
  • SCR 2738: Product: a failed "comp start" could cause subsequent app start failures
  • SCR 2736: Product: application list may fail in cases where a component is stopped during the list operation
  • SCR 2727: EDT: balloon connections do not work under Firefox 3.0.5
  • SCR 2745: CLI: server reboot/shutdown commands do not fail if there are running appliances or shared volumes on the server
  • SCR 2760: ALD: enh: add server BIOS check on grid new/upgrade

What is new in AppLogic 2.4.10 for AppLogic 2.4.5 beta users

For 2.4.5 beta users, 2.4.10 contains all of the bug fixes mentioned above plus the following:

  • The release contains 90+ bug fixes that resolve various defects from previous AppLogic releases (also includes all AppLogic hotfixes up through the 2.4.8 release)
  • Resource oversubscription for network bandwidth can now be enabled, allowing appliances to use more network bandwidth than their configured amount (but not more than the 2Gbit server limit). Resource oversubscription for network bandwidth is disabled by default.
  • Several new system catalog appliances:
    • L3LB: TCP/UDP load balancer (very similar to HALB)
    • TOMCAT/TOMCAT64: tomcat application server (Sun Java machine and Apache Tomcat); 32-bit and 64-bit
    • PGSQL64: 64-bit PostgreSQL database
  • 2 new AppLogic utilities that make it easier to manage your Windows/Linux appliances (accessible using the util command)
    • wincfg: makes it easy to change the computer name, administrator password and security ID (SID) of your Windows appliances
    • hvm2pv: used in conjunction with the iso2class utility to convert a Linux HVM-based appliance to PV-based (paravirtualized)
  • The release now supports 50 appliances per server (AppLogic 2.4.5 and prior supported 40 appliances per server)
  • AppLogic now prohibits users from repeatedly logging into the GUI with various name/pasword combinations in order to significantly reduce the effectiveness of brute-force password guessing attacks

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

What is new in AppLogic 2.4.10 for AppLogic 2.1.1 users

AppLogic 2.4.10 contains all of the new features below plus the hotfixes from all previous AppLogic releases.

Overview of the AppLogic 2.4.10 release

For those who have not used the AppLogic 2.3.x/2.4.x betas, the AppLogic 2.4.10 production release also brings the following functions initially provided in the AppLogic 2.3/2.4.5 betas:

  • support for 64-bit appliances; you can now mix and match 32-bit and 64-bit appliances in applications
  • support for Microsoft Windows Server 2003 32-bit (Standard/Enterprise/DataCenter/Web) as well as for Microsoft's NTFS file system
  • support for OpenSolaris 64-bit and Solaris 10 32-bit, as well as for Sun's Zetabyte file system (ZFS) and Unix file system (UFS)
  • support for dynamic appliances, including the backup appliance, migration appliance and SLA controller appliance
  • new appliances include a 64-bit MySQL server, a replicated MySQL server, 32-bit and 64-bit PostgreSQL servers, a redundant HTTP input gateway with SSL Support, a session-aware HTTP load balancer based on HAProxy, a TCP/UDP load balancer, 32-bit and 64-bit tomcat application servers, a load generator appliance, as well as several new virtual dedicated server appliances
  • introduction of the appliance kit (APK) for easier creation of new appliances
    • please see the following topic for how to upgrade your old-style appliances to use APK: VolfixDHCPConversion
  • a new iso2class utility that can be used to easily create new appliance distributions from CD/DVD ISO images (Linux, Solaris and Windows)
  • resource oversubscription for network bandwidth can now be disabled (an appliance cannot use more network bandwidth than its configured bandwidth); this is disabled by default and is enabled/disabled using hotfix hf2668
  • visual improvements in the editor include text annotations, OS icons, quick documentation links and design error flagging
  • improved web user interface; including visual volume browser, application provisioning/migration wizards, appliance boot console access for troubleshooting boot problems, graphical console access for accessing appliance graphical desktops, free-form text notes for applications and appliances, progress indicator and a cancel button for long operations, menu system restructuring within the dashboard and editor
  • core system enhancements including improved hardware support, support for global volumes, symbolic links to volumes, impexless import from a remote URL, catalog/class migration, user-level access to application and appliance descriptors (ADL), support for locked appliances and applications, support for bi-directional terminals, support for ext3 file system with snapshots
  • automatic check for high availability capacity
  • AppLogic now prohibits users from repeatedly logging into the GUI with various name/pasword combinations in order to significantly reduce the effectiveness of brute-force password guessing attacks

Details of the AppLogic 2.4.10 features

Core System

  • 64-bit Appliance Support: AppLogic now supports both 32-bit and 64-bit appliances (can be mixed in the same application). AppLogic provides the following 64-bit appliances in the /system catalog: LUX64, LINUX64, WEB64, MYSQL64, PGSQL64 and TOMCAT64 (all based on 64-bit CentOS 5.0). Both 32-bit and 64-bit appliances can now use up to 32GB of memory.
  • Windows Appliance Support: AppLogic now supports the Microsoft Windows Server 2003 32-bit Standard/Enterprise/DataCenter/Web R2 Edition/Standard SP2 Edition Operating System for use in AppLogic appliances.
  • Solaris Appliance Support: AppLogic now supports the Solaris 10 32-bit and OpenSolaris 64-bit Operating Systems for use in AppLogic appliances. 3tera has created and tested Solaris 10/OpenSolaris based VDSes and server appliances. Only the OpenSolaris appliances are distributed with AppLogic (based on OpenSolaris 2008.05), Solaris 10 appliances are not distributed with AppLogic due to licensing issues. You can create your own Solaris-based appliances using the iso2class Appliance Distro Creation Utility.
  • Improved hardware support: The AppLogic kernel now supports all devices supported by CentOS 5.1, providing support for more recent hardware. AppLogic is now based on XEN 3.2.2 and the Linux 2.6.18 kernel. In addition, AppLogic can now use up to 32GB of server memory.
    • Note that the 2.6.16.33 kernel may still be used in AppLogic appliances (the 2.6.16.33 and 2.6.18 appliance kernels are both supported on the same grid)
  • High-Availability Checking: AppLogic now automatically checks whether enough resources are available to recover from server failure (displays HA status on the dashboard). Note that this doesn't mean HA will always succeed, it just means that there are enough resources for it.
  • Resource oversubscription of network bandwidth: AppLogic now allows maintainers to enable/disable the oversubscription of network bandwidth on a grid for the backbone/internal network (disabled by default). If enabled, appliances may use more bandwidth than their configured network bandwidth (as in AppLogic 2.1.1 and all previous releases). If disabled, AppLogic enforces the maximum network bandwidth for each appliance based on its configured network bandwidth (as in AppLogic 2.3+). Once the used bandwidth for the appliance closely approaches its configured bandwidth, AppLogic randomly drops network packets for that appliance. For as long as the used appliance bandwidth exceeds the configured bandwidth, AppLogic drops all network packets for that appliance. The enabling/disabling of this feature is controlled through an AppLogic hotfix (hf2668).
  • Appliance OS Information: AppLogic now reports the OS information for running appliances such as OS name, OS version, PV driver information, etc
  • Bi-directional Terminals: The any protocol can now be used on terminals to allow bi-directional connections.

Note: Please see the Appliance OS Support Limitations reference for a full list of the supported appliance OSes and known OS limitations for AppLogic 2.4.10.

Storage Volumes

  • Volume Browser: Users can now access the contents of their volumes by using either the volume browser or root-level shell access (this replaces volume mount and remote scp/sftp access)
    • The volume browser is an explorer-like GUI interface that allows users to:
      • browse the contents of their volume
      • upload/download files to/from their volume
      • create/edit files
      • view/modify owner and access rights for files and directories
      • supports accessing 2 volumes at the same time (useful for copying files between volumes, etc)
      • ...and much more!
  • File-system format/check/repair: Users now have the ability to reformat a volume with a specific file-system, check the health of the file-system and repair errors in the file-system on any of their application/appliance volumes.
  • Volume Import/Export: Ability to import/export volumes to/from a grid
  • Support for ntfs and iso file systems: Support for Microsoft's NTFS and iso (cd-rom)
    • iso is useful for creating new appliance distros in AppLogic using the new iso2class utility
  • support for Sun's UFS and ZFS file systems
  • ext3-snapshot File-system: New type of Linux file-system; LVM with 2 partitions, one for data (ext3) and one for snapshots (used in MYSQLR and also available for custom appliances and VDSes).
  • Increased maximum volumes per server: AppLogic now supports up to 1024 volumes per server (used to be 256)

User Interface

  • GUI Login Brute-Force Attack Prevention: AppLogic now prohibits users from repeatedly logging into the GUI with various name/pasword combinations in order to significantly reduce the effectiveness of brute-force password guessing attacks.
  • Enhanced Application List GUI: The AppLogic Application List page has been enhanced with several new features:
    • New Application Information: The application list page now displays the state and resources for each application.
    • Application Start/Stop/Restart: Users can now start/stop/restart their applications directly from the application list page with a single click of a button. The progress of the application start/stop is also shown in the GUI; as well as any errors that may have occurred. Users can also now delete/stop running applications and system applications
    • Application Provisioning Wizard: GUI-based application provisioning wizard which allows provisioning any template application
    • Application Migration Wizard: GUI-based application migration wizard which allows the migration of applications from remote grids or to remote grids
  • Editor improvements for self-documented application designs
    • Annotations: Users can now add colorful annotations (with optional text) to their applications and assemblies that reside on the editor canvas. The annotations are typically used to convey architecture decisions/notes and also to identify the various tiers that are present (web tier, database tier, etc).
    • Notes: Users can now add design notes to an application, class, singleton or appliance instance. The notes are free-form text with basic text formatting such as boldface, italics, ordered and bulleted lists, and also hyperlinks. The notes can be used to document appliance release notes, design notes or anything else that you might need to specify.
    • Documentation URLs: Users can now configure a documentation URL for each application/appliance that provides the user level documentation for that entity. The URL is also accessible from the editor, as well as the application list page for the application itself.
    • OS icons: Appliances can now display an OS icon on the canvas that represents which brand of operating system is used in the appliance.
  • Descriptor Access: Users may now view and edit application and appliance ADL descriptors through the editor. Caution must be taken when using this feature as modifications to a descriptor may prevent the application from building or starting.
  • Automatic check for design rules: The editor now tracks unconfigured mandatory properties/volumes and unconnected mandatory terminals for all appliances in an application. Such appliances that need configuration and/or are missing connections are visually flagged on the canvas. If the user drags the mouse cursor over the flagged appliance, the editor displays the list of properties/volumes/terminals that need attention. The editor also displays on the status bar the number of entities that need attention. This feature also includes highlighting unconfigured mandatory properties/volumes that are not configured on appliances/applications.
  • Operation Progress/Cancellation: GUI displays progress for lengthy operations and also gives the user the ability to cancel the operation
    • Progress/Cancellation is supported for the following operations: app start/copy, volume create/resize/manage, class branch
  • Menu Restructuring: The infrastructure editor's menus has been completely restructured
    • The main menu contains all of the operations for all entities (applications, assemblies and applications)
    • All right-click context menus contain only the most widely used operations (everything else is in the main menu)
  • Symbolic-links: Allows the creation/deletion of symbolic links in the volume manager
  • Grid IP Configuration: AppLogic now allows a maintainer to configure the IP ranges, netmask and gateways that can be used by applications running on the grid. This information is displayed on the dashboard. This is a precursor to IP address range enforcement that is coming in a subsequent release (2009).
  • Customer feedback: There is now a link for customer feedback on the support page.

Application Model

  • Appliance Kit (APK): A set of binaries that are used to convert virtual machine boot images into AppLogic appliance boot volumes. Allows for easier creation of appliances, provides finer control inside appliances and improved start time.
  • Appliance Volume Management: When editing the appliance class volumes, AppLogic now auto-assigns a volume device for each volume that is added to the class (i.e., /dev/hda1, /dev/hda2, etc). In addition, if an appliance is using the new APK, the user may specify a path where a volume should be mounted inside of their appliance. The APK in their appliance will then automatically mount the volume at the specified path during the appliance boot phase. Users no longer have to manage the volume devices and mounts within their appliances.
  • Appliance console and management interfaces: Appliances can now define consoles and management interfaces, all accessible from the application list or editor:
    • Appliance Graphical Console: Allows the user to access an appliance's graphical console; for example a Windows/Linux/Solaris desktop
    • Appliance Text Boot Console: Allows the user to access an appliance's text boot console that is typically used for diagnosing appliance boot issues (available for Linux and Solaris)
    • Web Management Interface: Users may configure a particular appliance with a web management interface (assuming the appliance exposes a web interface on its default terminal at the specified port). This allows a user to integrate and access the appliance's web interface through the AppLogic GUI via a new "Manage" option.
  • Application Login: Users can now log into an application, just like for a regular appliance (i.e., SSH, graphical/text console, web management interface). For each application, the user can designate a "management" appliance that provides ssh, console and management UI for the application as a whole.
  • Configure applications from other applications: Ability to configure an application based on the configuration of another application
  • Prevent Application debugging: An application may now use field engineering code 16 which will prevent users from running the application in debug mode (i.e., users cannot start the application with the --debug flag).
  • Appliance Reboot Enhancement: Appliances may enter maintenance mode during boot (using "vme id=maintenance msg=mymsg progress=myprogress") and reboot themselves w/o AppLogic treating that as an appliance failure. This is useful for situations where reboots are needed during application software upgrades.
  • Import/Export application ADL descriptors: Ability to import/export application ADL descriptors only (no volumes) using the new --novols option; allows easy backup of an application's structure

Improvements in migration, import and export capabilities

As more and more customers operate multiple AppLogic grids in different geographic locations, we have extended the support for exchanging data and apps between grids:

Simplified Creation of Appliances
  • Appliance Distro Creation Utility: New appliances can now be created from CD/DVD ISO images using the new iso2class utility.
  • Global Volumes: New type of volumes that are global to the entire grid and can be used by any application; useful for sharing ISO images for appliance creation and for sharing other data volumes between applications
  • Ability for Appliances to download files from the controller: Appliances may now download files from the grid controller through their default interface.This is useful for accessing the new AppLogic APK and other files.
    • Maintainers can now copy appliance-specific files to the grid controller (/var/lib/applogic/acs/pub/download/) so running appliances may download these files through their default interfaces via HTTP.
    • AppLogic uses this feature to distribute the Windows MSIs that are needed to build Windows appliances.
  • New utilities for appliance creation and management: 2 new AppLogic utilities that make it easier to manage your Windows/Linux appliances (accessible using the util command)
    • wincfg: makes it easy to change the computer name, administrator password and security ID (SID) of your Windows appliances
    • hvm2pv: used in conjunction with the iso2class utility to convert a Linux HVM-based appliance to PV-based (paravirtualized)
  • Appliance Reboot Enhancement: Appliances may use a new field engineering code (64) that tells AppLogic to completely ignore appliance reboots after the appliance has booted. Useful when creating new appliances.

Catalogs

  • Application and class Locking: Application and appliance locking is designed to protect the intellectual property (IP) contained within such entities. When an application or appliance is locked, AppLogic disallows regular users from executing certain commands over the locked entities, such as export, edit/modify, copy, branch or migrate. This feature allows partners and other 3rd parties to publish appliances that are protected.
  • New dynamic catalog: Used for storing AppLogic dynamic appliances, currently this catalog contains 3 classes:
    • SLA: enables dynamic scaling of an application by starting and stopping other appliances within the application in accordance with a user defined policy
    • BCK: enables automatic application backup to external storage
    • MIG: provides a single-button migration of applications between multiple data centers
  • New application stack appliances:
    • INSSLR: the second appliance in our disaster recovery suite; a redundant HTTP input gateway with SSL Support
      • 2 copies of the same application can be running on 2 different grids, if one of the apps fails, the other app automatically serves the client requests via INSSLR
    • MYSQLR: a MySQL cluster server with replication, supporting master-master, multi-master, master-slave and remote replication/DR
    • MYSQL64: a 64-bit MySQL database server appliance
    • PGSQL/PGSQL64: PostgreSQL database server appliances; 32-bit and 64-bit
    • TOMCAT/TOMCAT64: Tomcat application server (Sun Java machine and Apache Tomcat); 32-bit and 64-bit
    • LOAD: Load Generator that can be used to test various load scenarios in your AppLogic web applications
  • New load-balancers for HTTP/TCP/UDP traffic:
    • HALB: a new session-aware HTTP load balancer based on HAProxy; with many new load-balancer features
      • configurable monitoring of the health state of all backend servers: TCP connection check or HTTP response check by using HTTP get/head methods
      • control of various timeouts (client/server responses, inactive sessions, etc)
      • web service interface that allows programmatic control (enable/disable) of all of HALB output terminals
      • maintains detailed statistics which is accessible through MON counters and/or a GUI exposed by HALB itself
    • L3LB: TCP/UDP load balancer (very similar to HALB)
  • improved INSSL gateway appliance: easier integration in Ruby-on-rails applications (changed SSL html header)
  • Monitoring Web Service API: The MON appliance now exposes a REST-based web service interface that can be used to retrieve appliance counters for an application. This information can be used to implement custom monitoring or new functionality based on the value of appliance counters.
  • Routerless Network Support: All gateway appliances and VDSes support routerless networks.
  • many of the appliances now support configurable timezones and port ranges
  • all appliances now use the new AppLogic APK
  • all appliances and applications now have a convenient link for quick access to their documentation directly from the editor and dashboard

Sample Applications

New VDS reference applications: The old GSC applications have been renamed to VDS_xxx and some new VDSes have been added:

  • VDS_CentOS51: CentOS 5.1 VDS
  • VDS_CentOS50: CentOS 5.0 VDS, used to be GSC
  • VDS64_CentOS50: 64-bit CentOS 5.0 VDS, used to be GSC64
  • VDS64_OSOL: 64-bit OpenSolaris VDS
  • VDS_SOL10: 32-bit Solaris 10 VDS. This is not distributed with AppLogic.
  • VDS_Win03S: Windows 2003 Server Standard Edition VDS. This is not distributed with AppLogic.
  • VDS_Win03E: Windows 2003 Server Enterprise Edition VDS. This is not distributed with AppLogic.
  • VDS_Win03DC: Windows 2003 Server DataCenter Edition VDS. This is not distributed with AppLogic.
  • VDS_Win03W: Windows 2003 Server Web Edition VDS. This is not distributed with AppLogic.
  • all applications now have a convenient link for quick access to their documentation directly from the editor and dashboard

Key Bug Fixes

AppLogic 2.4.10 is the same as AppLogic 2.4.8 with all of the following AppLogic 2.4.8 hotfixes integrated into the release:

  • hf3036: Product: logged in user can elevate his rights to a maintainer
  • hf2878: CLI: any operation that results in the creation of a volume while vol clean --orphan is running may lead to data loss
  • hf3049/hf2860: Product: resolves an issue with a grid rebooting during app start and PV-based appliances becoming unresponsive
  • hf2814: Product: grid restarted during heavy block I/O on the grid controller (i.e., app copy)
  • hf2910: Product: servers may reboot or application start may fail caused by low memory conditions on the servers
  • hf3031: Product: multicast/broadcast traffic through an appliance's external interface is dropped
    • 2889: Product: prevents appliances from receiving network traffic that is not destined for the appliances
    • 2900: Product: failed to setup default interface which caused Windows appliance start failure when using no PV drivers
  • hf2794: CTL: scheduler: comp start/restart may fail because the scheduler incorrectly fails to schedule the appliance
  • hf2839: Product: app start may fail due to a mount failure
  • hf2831: Resolves several issues with hvm2pv
    • 2830/2831: does not work with some Debian-based appliances
    • 2843: does not work with 64-bit appliances
  • hf2841: Resolves several bugs affecting the Applogic distributed kernel
    • 2841: Product: Windows 2003 server standard appliance hangs on login screen and fails to boot
    • 2705: Product: iso2class does not work with most OSes
  • hf2849: Product: iso2class: install is very slow for some OSes
  • e2802: Product: automatically obtain a core dump of the grid controller VM when there is a problem with the controller
  • e2804: Product: grid controller running on a server with an Intel 82575EB NIC is not accessible through SSH
  • e3032: Product: improved e1000/e1000e device support

In addition, the following bug fixes are included in AppLogic 2.4.10 that are not available in previous releases:

  • SCR 3048: Product: grid may fail due to grid controller process termination
  • SCR 3130: Product: windows appliance may unexectedly shutdown during comp/app start
  • SCR 2492: Product: 64-bit Windows 2003 server does not work due to the 3tera APK using cygwin for shell access
  • SCR 2966: Product: hvm2pv: does not work with CentOS 5.3
  • SCR 2898: APK: install fails if the etc/fstab file contains "# /" (observed when installing Ubuntu 9.04)
  • SCR 2911: EDT: allows the AppLogic GUI to be used with grids installed in data centers that use NAT (network address translation)
  • SCR 2103: ALD: if controller server is down and controller is switched to a new server, the old controller server never rejoins the grid
  • SCR 2785: ALD: reimage fails when there are only legacy IDE disks or PCI-IDE disks
  • SCR 2788: ALD: incomprehensible error message if ALD_DISABLE_GRM=1 and account_key= is provided at the same time
  • SCR 2825: ALD: failed to reboot the original controller server on a controller switch
  • SCR 2929: ALD: hardware check fails for devices that require subsystem ID match

Please note that the following hotfixes are not included in AppLogic 2.4.10 but are available for download as for other releases:

  • hf2668: Enables bandwidth oversubscription (appliances may use more bandwidth than their configured bandwidth)
  • e3160: Enable Windows development support for AppLogic 2.4.x grids (including localized Windows VDS support)

Hotfixes for AppLogic 2.4.10

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

Mandatory Hotfixes

  • hf3238: Disables vol repair --all --nowait in order to prevent possible grid failures
  • hf3240: Resolves a networking issue which may trigger grid failures

Recommended Hotfixes

  • hf2824: Resolves an issue with srv list --map where it reports that the grid controller is running on the wrong server

Optional Hotfixes

  • hf2668: Enables bandwidth oversubscription (appliances may use more bandwidth than their configured bandwidth)
  • e3160: Enables Windows development support (including localized Windows VDS support; supersedes e2833)
  • e3141: Servers that lose connection to the grid controller may reconnect w/o rebooting to overcome grid stability issues
  • hf1248: Add support for controlling the volume repair speed of a grid from the distribution server

ALERT! e2833 has been recalled and replaced with e3160.

Installation/Upgrade/Migration notes and issues for AppLogic 2.4.10

This section describes various issues/how-tos related to AppLogic 2.4.10 installation and upgrades. Carefully read and follow the instructions for each issue to ensure a properly working AppLogic 2.4.10 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.4.10 grid: Starting from AppLogic 2.1.0, AppLogic requires all servers to use a special partitioning schema that makes grid upgrades safer and faster. The AppLogic installer (ALD) contains a new ald-reimage script that automatically both installs the OS and creates the necessary partitions on the specified servers. This makes it easier for the maintainers to install new AppLogic grids; and also ensures that all servers contain the same software and configuration. Please be sure to read the latest ALD documentation before installing your new grid.

  • 64-bit support in AppLogic 2.4.10: AppLogic 2.4.10 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.4.7/2.4.8: AppLogic 2.4.10 supports upgrades from either 2.4.7 or 2.4.8. Upgrade your grid by simply executing the following command from your AppLogic 2.4.10 distro: ./aldo upgrade grid=mygrid applications= catalogs=. Note that the upgrade of the catalogs and applications are skipped because they have not been modified in 2.4.8 or 2.4.10. Skipping the catalogs and applications also makes the upgrade much faster.

  • Upgrading from AppLogic 2.1.x/2.2.2/2.3.x: AppLogic 2.4.10 supports upgrades from either 2.1.x/2.2.2/2.3.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.4.10 distro: ./aldo upgrade grid=mygrid dom0_vm_mb=512. If your AppLogic 2.1.x/2.2.2 grid does not use the AppLogic partitioning schema, you must install a new AppLogic 2.4.10 grid on separate servers and migrate your applications, catalogs and users over to the new 2.4.10 grid.

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

  • Migrating applications from an AppLogic 2.3.x/2.4.5-2.4.8 grid to a AppLogic 2.4.10 grid: Migrate your appliances, catalogs and applications to your new 2.4.10 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.4.10 distro, execute the following:
      • ./upgrade_apps.sh controller-IP vmlinuz-2.6.18-xenU [--force]
      • Be sure to specify the correct controller IP address
    • By default, the script will prompt you to confirm all changes to the appliances on your grid. To surpress the prompting, use the --force option.
    • After the script has completed, your new grid is ready for use.
    • The upgrade script may take a few minutes to complete.
    • At this point, all appliances and applications should be migrated to the new grid.

ALERT! 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.5-2.4.8 and 2.4.10 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 keeps volumes mirrored across two or more servers, ensuring high availability and improved read performance. The hierarchical volume space is structured along applications and catalogs, so volumes become integral part of those entities.
  • Distributed virtual machine manager: a 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.

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.

Windows-based appliances and applications

In order to use Windows-based appliances and applications, you must have the 3tera Windows enhancement hotfix e2833 installed on your grid. Access to e2833 requires a license addendum. For more information on how to obtain e2833, AppLogic licensees should contact 3Tera support or sales; VPDC customers should contact their service provider.

Windows appliances/applications are not distributed as part of AppLogic. However, depending upon your AppLogic license, you may be able to obtain the Windows-based appliances/applications from 3Tera:

  • If you are a direct licencee who installs AppLogic on-premesis in your own datacenter or on your own hardware, please contact Microsoft for a Windows Volume License (you must obtain your own Microsoft license in order to use Windows appliances on AppLogic). In addition, contact your 3tera account manager for information on how to obtain optional Windows PV drivers that are used to enhance the network/disk I/O performance within Windows appliances.
  • If you own a VPDC (Virtual Private Datacenter) obtained directly from 3tera, contact your 3tera account manager for information on how to obtain ready-made Windows appliances and applications that you may use on your VPDC.
  • If you own a VPDC (Virtual Private Datacenter) obtained directly from a 3tera partner, contact your sales representative with that vendor for information on how to obtain ready-made Windows appliances and applications that you may use on your VPDC.

System Catalog

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

  • WEB4/WEB5/WEB64: Apache-based web server with plug-in content/scripts volume
  • WEBx4, WEBx8: Scalable web servers
  • MYSQL5/MYSQL64: MySQL-based database server
  • MYSQLR: MySQL-based database server suitable for replication
  • PGSQL: PostgreSQL-based database server
  • HLB: Session-aware HTTP load balancer
  • HALB: Session-aware HTTP 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
  • NAS: Network attached storage / file server appliance (HTTP and CIFS file access)
  • LOAD: Load Generator that can be used to test various load scenarios in your AppLogic applications
  • INSSL, IN, OUT, NET: Firewalled network gateways based on iptables
  • INSSLR: Redundant HTTP Input Gateway with SSL Support
  • LUX5/LUX64, LINUX5/LINUX64: A tiny and a minimal Linux appliances that can be used as basis for new appliances
  • MON: Application Monitor used to monitor running applications (collects and displays counters using visual graphs)

The system catalog also contains 4 new beta appliance classes.

  • L3LB: TCP/UDP load balancer based on HA Proxy
  • PGSQL64: PostgreSQL database server 64-bit appliance
  • TOMCAT/TOMCAT64: Tomcat application server (Sun Java machine and Apache Tomcat); 32-bit and 64-bit

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

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

In addition, 3tera 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.4.10 grid):

  • WIN03S: Windows 2003 Server Standard Edition
  • WIN03E: Windows 2003 Server Enterprise Edition
  • WIN03DC: Windows 2003 Server DataCenter Edition
  • WIN03W: Windows 2003 Server Web Edition

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.

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

ALERT! Note: The proto catalog is no longer distributed with AppLogic.

Sample Applications

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

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

The AppLogic release also includes the following preconfigured infrastructure templates:

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

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

  • TWiki: web-based collaboration platform
  • SugarCRM: customer relationship management system

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

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

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

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

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

Downloading the release

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

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

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

IDEA! 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

  • 128 servers per grid
  • 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

ALERT! 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
    • 64-bit only
    • 10 volumes
    • 10 network interfaces/terminals (including external and default interfaces)

  • Per appliance: Windows 2003 Server (Standard/Enterprise/DataCenter/Web R2 Editions, Standard SP2 Edition)
    • 32-bit and 64-bit
    • 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
    • Verified to work with the Halsign Turbogate and Novell PV drivers for enhanced I/O performance

  • Per server
    • 1024 virtual volumes (counting each mirror as a separate virtual volume)
    • 255 shares (counting each mirror as a separate share)
    • 128 mounts (counting each mirror mounted as a separate mount; i.e., 64 if mirroring by two)
    • 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)

  • If you need different dimensions, give us a call

Hardware Compatibility

  • Single CPU, Multi-CPU (SMP), single, dual and quad core
    • Certified: Pentium P4, Intel Xeon/Woodcrest/Clovertown, AMD Opteron, AMD Athlon64
    • Supported: Intel Pentium P4 or better; AMD Athlon or better
    • Note: Intel hyperthreading is automatically disabled by AppLogic and is not used
    • Requires either Intel VT or AMD-V for hardware virtualization support (HVM)
      • HVM is mandatory for running Solaris 10 an 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
  • ALERT! If using servers that have 1GB of RAM, you must specify that the dom0 memory is 384MB during the grid installation/upgrade (dom0_vm_mb=384)

  • 80 GB IDE/SATA HDD (250 GB or larger SATA drive recommended, multiple drives/server supported)
  • HDD controllers
    • Certified:
      • Intel Corp. 82801EB/ER (ICH5/ICH5R)
      • Silicon Integrated Systems [SiS] 5513
      • Advanced Micro Devices [AMD] AMD-8111 IDE
    • Supported: all IDE, SATA and SCSI devices supported by CentOS 5.1 (excl. Adaptec AHA-15xx). Details.
    • 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 Ethernet adapter (Intel or Broadcomm recommended)
    • Certified:
      • Intel Corp. 82541GI/PI Gigabit Ethernet Controller
      • Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet
      • Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (as external 10/100 NICs)
    • Supported: all Gigabit Ethernet network adapters supported by CentOS 5.1. Details.

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

  • 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.
    • Linux based
      • 32-bit/64-bit Linux OS (a mix of 32-bit/64-bit appliances may be running on the same grid)
      • Kernel 2.6.16-33 with Xen 3.0.4 support and Kernel 2.6.18 with Xen 3.2.2 support
      • 32-bit Tested: Fedora Core 3, CentOS 5.0, CentOS 5.1
      • 64-bit Tested: CentOS 5.0, CentOS 5.1
      • Supported: all Linux distros based on recent 2.6 kernel (see Linux distros verified by AppLogic developers and users)
    • OpenSolaris based
      • 64-bit only
      • Verified with OpenSolaris 2008.05 and build 82
    • Solaris 10 based
      • 32-bit only
      • Verified with Solaris 10 update 4
    • Windows 2003 Server based
      • 32-bit and 64-bit
      • Verified with Windows 2003 Server Standard/Enterprise/DataCenter/Web R2 Editions, Standard SP2 Edition

  • 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

  • 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. In AppLogic 2.3+, INSSL no longer uses "X-SSL-Request: 1" headers and instead uses "X-Forwarded-Proto: https" headers. Any use of these headers in configuration files (i.e., .htaccess) will need to be modified to compensate for this change. If you need to use the INSSL that uses "X-SSL-Request: 1" headers, you may request the AppLogic 2.1 version of INSSL by contacting Technical Support.
  7. In AppLogic 2.3+, the WEB/MYSQL/LUX/LINUX appliances have been removed and replaced with WEB5/MYSQL5/LUX5/LINUX5. In each of these updated appliances, the OS has been upgraded to CentOS 5.0 and the related software packages have also been upgraded. As such, after migrating older Applogic applications to 2.3+ grids, the applications will need to be updated to use these new appliances. This can be done by updating the application descriptor using the new AppLogic infrastructure editor (by replacing the class names).
  8. Before accessing the AppLogic GUI on a newly installed or upgraded AppLogic grid, the user should clear out the browser's cache. If the browser's cache is not cleared out, the AppLogic GUI may not behave properly.
  9. The grid shell can be accessed either through a web browser or using an ssh client. For increased security, password-based ssh logins are not supported except during grid installation. It is recommended to use the new web shell provided with the AppLogic GUI.
  10. When accessing the grid over ssh, the login user name is always root, regardless of the AppLogic user name. For the purpose of ssh logins, users and their roles are uniquely identified by their public ssh keys.
  11. Web browser's Javascript and pop-ups must be enabled to use the web-based graphical user interface (dashboard, editor, documentation)
  12. Users are responsible for allocating, assigning and use of externally visible IP addresses for applications; AppLogic takes care of all internal network assignments
  13. While the AppLogic distribution system sets up all grid servers and controllers with carefully pre-configured firewalls and disables unnecessary network services, users and maintainers are encouraged to verify the security settings of their systems.
  14. Network performance between servers on the private network used for volume and inter-appliance communication is measured to approximately 900 Mbps. The TCP network performance measured between appliances residing on different servers is measured as 720-900 Mbps. When running Windows, the TCP network performance is about 600 Mbps UDP is about 450 Mbps.
  15. Resource limits on appliance hardware resources are enforced differently for different types of resources (CPU, memory, bandwidth). CPU is "no less than" , memory is "exactly that much" (includes VM overhead), bandwidth is "exactly that much" (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.
  16. When starting an application with a specified amount of minimum CPU, it is not guaranteed that the application will get exactly the amount of specified CPU. For example, if an application is started with cpu=2, it is possible that the application will receive 1.97 CPU as observed by adding up all of the assigned CPU to all components of the application. This is due to rounding errors that may occur while trying to assign CPU to each individual component.
  17. When application start fails, not all messages related to the failure may be shown in the shell. Inspect the grid log for additional information, using the list log n=20 command.
  18. Grids in which linear scalability of performance is important should be built using servers that are as uniform as possible in CPU type/speed, memory size and disk capacity. AppLogic will work correctly in grids assembled from servers with different amounts of hardware resources; however, on such grids you may experience sub-linear performance.

Known Problems and Limitations

Limitations

1. Grid size is limited to 128 servers per grid
This is a limitation of the current AppLogic release. This release has been certified up to 8 servers; configurations up to 128 servers are supported.
2. AppLogic's web based user interface requires Firefox 2 or later or Microsoft Internet Explorer 6 or later to operate
Javascript, pop-ups and cookies should be enabled for the grid controller's host for proper operation of the user interface. Please use the latest available bugfix versions of these browsers, as they correct a number of browser defects needed for AJAX applications. Firefox 1.0 and 1.5 browsers are also supported, with some minor known problems (printing and image caching).
3. The private network Ethernet switch is a single point of failure in the grid
If the Ethernet switch dies or loses power, the grid will stop operating and will need to be restarted after the switch is restored to operation or replaced.
4. Protocols are not enforced on appliance terminals, only endpoints are enforced
This means that an appliance can only talk to appliances connected to it (plus its own server and the grid controller). Nevertheless, protocols on new appliances should be properly specified in order to ensure application design integrity and compatibility with future versions of AppLogic.
5. The total available disk space does not take volume mirroring into account
The total available disk space reported by the grid info command is a raw estimate and does not take volume mirroring into account. The true available disk space is the reported available amount divided by the number of mirrors (2 mirrors by default). For example, if there is 1000GB of available disk space and the grid was configured for mirroring of 2, the available disk space is 500GB. Also, in order to successfully mirror volumes, there must be enough disk space on at least X servers where X is the number of mirrors (AppLogic will not fail to create a volume if any one of its mirrors cannot be created, it will display a warning that the volume could not be mirrored).
6. A server failure during application start may cause the application start to fail
If an application is started and one of the grid's servers fails, the application start will fail if one or more of the application's appliances were scheduled to run on the failed server. If this situation occurs, simply restart the application.
7. During a grid upgrade, all of the current catalogs on the grid are renamed to aldsave_xxx before the new/updated catalogs are imported
Therefore, after the grid is upgraded, all custom appliances that were present in the proto catalog are now contained in aldsave_proto. These appliances should be moved back to the the current proto catalog (after the grid has been upgraded). If the custom appliance is not used by any other application or appliance assembly, it can be moved by right clicking on the appliance and choosing the move option. Otherwise, the appliance must be dragged into a new application, branched and then moved back into proto. After moving the appliances back into the proto catalog, all applications and appliance assemblies must be updated to use the appliances from proto (currently, your applications reference appliances from aldsave_proto). There is one exception for appliance assemblies. After branching the assembly, make sure all appliances in the assembly reference appliances from proto. An easy way to replace the aldsave_proto appliances with appliances from proto is by using the visual application editor. While holding the shift key, click on the proto appliance and drag it over the aldsave_proto appliance in your application. Drop the appliance and click the OK button and your appliance will be replaced (without having to re-parameterize or reconnect the appliance).
8. The new AppLogic 2.3+ volume management GUI has an upload limititation of 10MB per file
In order to upload larger files to your volume, please use the vol manage shell command; don't forget to specify the external IP settings for this command to enable remote access from within the volume manager. For more information, please see the reference for the vol manage command.
9. 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.
10. 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.
11. The maximum volume size for the ufssol file system is 1TB-1MB
3tera will remove this limitation in a future AppLogic release.
12. 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.
13. 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.
14. 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).
15. 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.
16. 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.
17. 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. 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).
18. Application migration wizard in the GUI only works with 2.4.5-2.4.10 grids
The application migration wizard in the GUI will only work between 2.4.5-2.4.10 grids. If you need to migrate applications between other versions of AppLogic, use the app migrate command from the web shell.
19. 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 and cpu assigned to an HVM-based appliance, the appliance uses 50-300 MB of additional memory on the server in which it is running (this additional memory is required by the virtualization hypervisor running on the servers; this additional memory needed by the hypervisor is called service memory in AppLogic). Therefore even though a server might have enough available memory compared to what is assigned to an appliance, the appliance may not be able to run on that server due to the additional service memory needed for HVM-based appliances that may not be available on the server. The service memory is now reported independently of the allocated/free/used memory that is reported by AppLogic (service memory is reported for components, applications, servers and the grid as a whole).

Known Problems and Issues

The following are the key known problems in this release:

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

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

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

4. Defect SCR 857 - Grid reboot may degrade one or more system volumes
If a grid is rebooted using the grid reboot command, when the grid comes back up after the reboot, one or more of the system volumes may become degraded. If your grid needs to be rebooted, after the grid has been rebooted and comes back online, login as a regular grid user. Check and repair the system volumes by executing the following commands below. This will ensure that the system volumes are always in a clean state. This bug will be fixed in a future AppLogic release.
  • check vol # will show if there any volumes that need repair, look specifically for the _SYSTEM volumes
  • repair vol _SYSTEM:boot
  • repair vol _SYSTEM:meta
  • repair vol _SYSTEM:impex

5. Defect SCR 1199 - Unable to migrate a volume whose streams are all on disabled servers
When migrating a volume, make sure that at least one of its streams is on an enabled server or else the migration command will fail. The volume can be completely migrated off of its original set of servers by migrating the volume twice.

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

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

8. Defect SCR 1219 - 3 to 15 minute system lockout on server failure
In most cases when a server fails, shell commands will hang for 3 minutes but the AppLogic controller will remain operational. After 3 minutes, the grid will return to normal operation. In rare cases where the failed server contains one of the mirrors of the AppLogic controller system volumes (boot, meta or impex) and the server fails to reboot, the user will be locked out of the controller for up to 15 minutes. After 15 minutes, the grid should return to normal operation. This bug will be fixed in a future release. Please note that in AppLogic 2.4.7, this bug was fixed but not fully verified. If you encounter a long lockout on server failure (> 5 minutes), please contact 3tera technical support.

9. Defect SCR 1360 - Appliance shows slightly less memory and less disk size than allocated
The reason for the slightly reduced resources is related to allocation for service areas. For memory, it is likely due to XEN related to the memory map table for a virtual machine. For disk, it is due to normal file system service areas (this is the same as on regular Linux servers).

10. Defect SCR 1896 - After closing the shell during volume resize, could not resize volume w/o maintainer access (general problem with any command)
If the web shell is closed during the execution of an AppLogic command, this may result in one or more volumes being left mounted on the grid controller. To recover from this situation, make sure all volumes that were involved with the particular operation are unmounted (note that this may include catalog volumes). You can use vol list --all to retrieve a list of all mounted volumes in the system.

11. Defect SCR 2293 - Occasionally opening an application in the editor results in a message that the application is locked for editing
In this case, the application is not opened for editing by any other user but the AppLogic editor errornously thinks somebody else has the application open for editing. If this occurs, simply override the application lock when prompted by the editor upon opening the application.

12. Defect SCR 2313 - IE6/7 are about 2x slower than FireFox when using the AppLogic GUI
The main slowdown occurs when opening an application in the AppLogic application editor. 3tera may optimize the AppLogic GUI in the future to eliminate this problem.

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

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

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

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

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

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

19. Defect SCR 2547 - If the user cancels a volume add operation and then changes their mind after the volume is created, the volume is not listed in the GUI
If the user closes the volume manager GUI and re-opens it, the volume will appear in the volume list.

20. Defect SCR 2653 - Web shell operation slows down significantly if left open for 10+ minutes
To work around this issue, close and re-open the web shell.

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

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

1. Defect SCR 2856 - Windows appliance locked up after several days of usage; no ssh access to appliance
Windows appliances may lock up, preventing access via ssh. A restart of the appliance resolves the issue. This has been observed several times. This particular appliance where the problem was observed is running Adobe Acrobat Connect Pro Server 7 SP2, but no other outstanding software packages. In the event viewer, the following message is present: "The device, \Device\Scsi\gkvbd1, did not respond within the timeout period".

2. 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 (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 can be worked around by running a file system repair on the volume ("vol fsrepair") before resizing the volume.

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 2813/ SCR 2821 - wincfg and the Windows filer MSI do not work under localized Japanese Windows
Other than the wincfg utility and the filer MSI, localized Japanese Windows should work under AppLogic. This will be fixed in a future release.

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

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

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

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

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

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

11. Defect SCR 2514 - The APK applogic_init script failed one time during appliance boot 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.

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

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

Unreproducible Problems and Issues

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

1. Defect SCR 2454 - Grid crashed during app start (grid did not recover, hang in dom0 on mostly srv1)
This bug has been observed on about 6 different AppLogic 2.3.9 grids (this bug may or may not exist in AppLogic 2.4.10). Usually during app start or app copy, the grid controller becomes unresponsive and the entire grid becomes dead and unusable. Rarely the grid will recover on its own but it usually requires a hard reset of srv1 to restore operation (or which ever server happened to crash). It looks like this particular issue may be hardware-related with Intel-specific hardware (3tera has caught a low-level machine check exception error reported by the Intel CPU when the server crashes). This issue was found to be caused by the use of an out-of-date BIOS on the AppLogic servers. Please be sure that all of your servers' BIOS are up-to-date. If all servers' BIOS are up-to-date and this problem persists, please contact 3tera techinical support.

2. Defect SCR 2842 - Server rebooted due to a crash in Linux kernel in dom0
A server in the grid rebooted on its own due to a crash in the Linux kernel in dom0 of the server. 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 immediately.

3. 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 also causes application downtime. It is unknown why the servers are losing their connections to the grid controller. There are several bug fixes in this release that may resolve this issue. If this problem is observed, please contact 3tera technical support immediately.

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 2281 - Volume operation failed during parallel volume operations due to XEN failure on AppLogic server
While executing parallel volume operations, one of the volume operations failed. The failure was caused by the inability of AppLogic to start the filer application for the volume operation due to an apparent bug in XEN 3.2.1/3.2.2 (XEN failed to initialize the block back device for the filer appliance).

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

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 2347 - A volume resize operation failed 1 time out of 4500 operations
While 3tera was testing the volume operations in AppLogic 2.4.7, vol resize failed 1 time out of 4500 operations. The AppLogic filer appliance timed out during appliance boot.

9. Defect SCR 2626 - Start of application/appliance rarely fails due to internal error on AppLogic server
Very rarely when starting an application one or more of its appliances fails to start. In the message log on the grid controller there will be a message stating that one of the appliances failed to start. The appliance start failure is caused by a failure on the server where the appliance is trying to start. The server failure is due to an internal error in XEN that occurs when AppLogic tries to create the appliance. In order to recover from this error, the server where the appliance was scheduled to run must be rebooted. This bug has been observed 2 times (once in AppLogic 2.3.9 and once in AppLogic 2.4.7).

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

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

12. Defect SCR 1975 - Occasionally AppLogic operations involving the impex volume fail (i.e., class import/export)
Occasionally when an AppLogic grid is rebooted, the impex volume is not setup correctly on the grid controller. This causes failures when using AppLogic operations that involve the impex volume such as mounting volumes, class/catalog/application import/export, etc. This issue should be resolved in AppLogic 2.4.10. In order to work around this issue in case it occurs, execute the following commands as a grid maintainer (if the following workaround does not work on your grid, please contact 3tera support).
  • /etc/init.d/nfs restart
  • /etc/init.d/3trsh-init stop
  • /etc/init.d/3trsh-init start
  • mount /dev/hda3 /vol/_impex
  • chown applogic:applogic /vol/_impex

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

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

15. Defect SCR 2283 - Dashboard did not automatically refresh and display updated IP ranges
User modified the IP ranges for the grid using ALD and the dashboard did not display the updated ranges. If this occurs, refreshing the dashboard page forces the dashboard to display the correct IP ranges.

Contact Information

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

Self-help Resources

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

Live Support

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

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

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

-- EricT - 31 May 2009
 
Copyright © 2005-2010 3tera, Inc. All Rights Reserved.
%