AppLogic Release Notes

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

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

Overview

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

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

AppLogic does not require a SAN or other expensive hardware, and is open and vendor-neutral. It supports Linux 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.7.8 for AppLogic 2.7.4 beta users

For 2.7.4 beta users, 2.7.8 resolves many of the issues reported during the 2.7 beta program. See the key bug fixes for a list of the key issues that were resolved in this release. In addition, 2.7.8 contains several new features:

• support for 64-bit Microsoft Windows 2003 Server
• new appliances that are now available
  • NASR: replicated NAS for implementing disaster recovery via remote replication
  • MYSQLR64: 64-bit replicated MySQL database; useful for disaster recovery scenarios
  • IN2/OUT2/NET2: new optimized gateways; based on BusyBox and contains read-only boot volumes
  • IIS03yx4/IIS03yx8: Scalable Microsoft Internet Information servers
• VPN now supports both ipsec and IPv6 (ipsec is only supported for IPv4; IPv6 ipsec support is coming soon)
• WISAx4: simple 2-tier scalable Windows application
• enhanced GUI support for the Apple Safari and FireFox browsers on a Mac

Please see the next section for the full list of features/changes that are available in AppLogic 2.7.

What is new in AppLogic 2.7.8 for AppLogic 2.4.x users

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

• Auto-diagnostic and self-healing enhancements
  • Automatic volume repair: AppLogic automatically schedules and performs volume repair, including retries, in order to maintain the availability of running applications. The operator can still postpone repairs when necessary for performance reasons.
  • Grid Controller Restart: The AppLogic controller can now be restarted while leaving all applications running. Further, the controller is now monitored like all applications and will be restarted automatically in the event of failure. This significantly improves the uptime of applications running under AppLogic and reduces the operator workload associated with managing maintenance windows.
  • Improved server isolation: AppLogic can now fully eliminate failed servers from the grid to prevent them from interfering with the grid's operation. This also allows operators to power-cycle, power-down and power-up servers in the grid (via IPMI).
  • Storage health monitoring: AppLogic now monitors and detects hard drive issues and reports them to the user even before they result in redundancy degradation. The operator can use this data to make decisions about migrating volumes and replacing hardware before there's any potential for data loss. Storage health monitoring is supported only for storage devices that are S.M.A.R.T enabled. Please see the storage failure topic for more information.
• Support for 64-bit Microsoft Windows 2003 Server
• Several new catalog appliances:
  • NASR: replicated NAS for implementing disaster recovery (DR)
  • VPN: Virtual Private networking appliance, includes IPv6 and ipsec support (ipsec is only for IPv4)
  • IN2/OUT2/NET2: new gateways based on a read-only boot volume
  • URLSW: URL port switch for distributing HTTP requests to different appliances based on a regular expression
  • SQUID: SQUID proxy (web cache). SQUID keeps local copies of frequently requested data and returns cached content when applicable; thus decreasing response time and load on the backend servers
  • MYSQLR64: 64-bit replicated MySQL database
  • OSOL/OSOL64: 32-bit/64-bit OpenSolaris appliances based on OpenSolaris 2008.11
• Support for several new Microsoft Windows appliances
  • IIS03x: Microsoft Internet Information servers
  • IIS03yx4/IIS03yx8: Scalable Microsoft Internet Information servers
  • SQL08x: Microsoft SQL server database appliances
• New Microsoft Windows template applications. These are just like the existing Linux Lamp applications except they are based on the IIS/SQL/ASP.NET Microsoft application stack:
  • WISA: simple 2-tier non-scalable Windows application
  • WISAx4: simple 2-tier scalable Windows application
• New 32-bit OpenSolaris VDS application: VDS_OSOL
• Updated sample applications that contain the latest versions of SugarCRM and TWiki
• Various appliance updates: INSSLR now contains healthchecks just like HALB, support for webdav and security enhancements, HALB now supports IPv6 and ipsec, MYSQLx/WEBx allow the timezone to be configured, all appliances contain support for iSCSI (built into the distributed domU kernel), appliances that use the APK have access to the _APPLOGIC_USERID environment variable that contains the name of the current user who is logged into the appliance via SSH
• The AppLogic GUI contains several improvments: it is now accessible using Google Chrome on Windows and Apple Safari on MAC in addition to Internet Explorer and FireFox, singleton appliances are denoted by an S icon in the upper-right corner
• Server information displayed by srv info now includes additional server information such as BIOS vendor/version/date, motherboard manufacturer/model/version, server uptime, HA role used for grid controller HA, reason for server reboot/shutdown/power-cycle, and whether storage health monitoring and server management (power control) is supported/enabled
• Applications now have the following new states:
  • BUILDING: application is currently being built
  • RESTARTING: application is currently starting as part of an application restart
  • RESTART_STOPPING: application is currently stopping in preparation for an application restart
  • UNKNOWN: AppLogic has not yet determined the state of the application; only present during grid controller boot
• The release contains 90+ bug fixes that resolve various defects from previous AppLogic releases. It also includes all previous AppLogic hotfixes.

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.7.8 for AppLogic 2.1.1 users

AppLogic 2.7.8 contains all of the hotfixes from the previous AppLogic releases and all of the following features.

Overview of the AppLogic 2.7.8 release

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

• grid and application high-availability enhancements: the ability to recover automatically from grid controller failures and without causing application downtime; this includes recovery from grid controller software failures and grid controller server failures. It also includes automated volume repair and storage health monitoring in order to help prevent data loss.
• support for server power control using IPMI; this allows a user to power-cycle, power-down and power-up a server. AppLogic can also take advantage of this feature by power-cycling a server that loses connection to the grid controller to speed up application recovery.
• 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/64-bit (Standard/Enterprise/DataCenter/Web) as well as for Microsoft's NTFS file system; this also includes appliance support for Microsoft IIS and SQL server and 2 LAMP-like template applications based on the IIS/SQL/ASP.NET Microsoft application stack
• support for OpenSolaris 32-bit/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, a replicated NAS, 32-bit and 64-bit PostgreSQL servers, a redundant HTTP input gateway with SSL Support, optimized IN2/OUT2/NET2 gateways, 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, a web cache appliance based on SQUID, a virtual private network gateway with support for IPv6 and ipsec, a URL switch, 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 support for Google Chrome and Apple Safari (on a MAC), text annotations, OS icons, quick documentation links, design error flagging and singleton appliance identification
• 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, new application states, reporting additional server information (BIOS, motherboard, etc)
• 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.7 features

Core System

• Auto-diagnostic and self-healing enhancements: One of the most important features of AppLogic 2.7 is to improve the availability of applications and services that are running on a grid. This includes the following improvements:
  • Automatic volume repair: AppLogic automatically schedules and performs volume repair, including retries, in order to maintain the availability of running applications. The operator can still postpone repairs when necessary for performance reasons.
  • Grid Controller Restart: The AppLogic controller can now be restarted while leaving all applications running. Further, the controller is now monitored like all applications and will be restarted automatically in the event of failure. This significantly improves the uptime of applications running under AppLogic and reduces the operator workload associated with managing maintenance windows.
  • Improved server isolation: AppLogic can now fully eliminate failed servers from the grid to prevent them from interfering with the grid's operation. This also allows operators to power-cycle, power-down and power-up servers in the grid (via IPMI).
  • Storage health monitoring: AppLogic now monitors and detects hard drive issues and reports them to the user even before they result in redundancy degradation. The operator can use this data to make decisions about migrating volumes and replacing hardware before there's any potential for data loss. Storage health monitoring is supported only for storage devices that are S.M.A.R.T enabled. Please see the storage failure topic for more information.
  • High-Availability Checking: AppLogic now automatically checks whether enough resources are available to recover from server and appliance failures (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.
• 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: LUX64, LINUX64, WEB64, MYSQL64, MYSQLR64, 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 and 64-bit Standard/Enterprise/DataCenter/Web R2 Edition/Standard SP2 Edition Operating System for use in AppLogic appliances.
  • The includes support for the following Microsoft Windows-based appliances:
    • WIN03xy: 32-bit/64-bit Windows 2003 Server appliances
    • IIS03x: Microsoft Internet Information servers
    • IIS03yx4/IIS03yx8: Scalable Microsoft Internet Information servers
    • SQL08x: Microsoft SQL server database appliances
  • Windows appliances are not distributed with AppLogic due to licensing issues. However, AppLogic makes it easy to install new OS distributions by using the new iso2class Appliance Distro Creation Utility.
  • Please see the following topics for more information on how to obtain/build Windows appliances on your AppLogic grid:
    • Windows Appliance Installation Reference
    • Important Windows Appliance Notes
• Solaris Appliance Support: AppLogic now supports the Solaris 10 32-bit and OpenSolaris 32-bit/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.11), 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)
• 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.
• Server information displayed by srv info now includes additional server information such as BIOS vendor/version/date, motherboard manufacturer/model/version, server uptime, HA role used for grid controller HA, reason for server reboot/shutdown/power-cycle, and whether storage health monitoring and server management (power control) is supported/enabled

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

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

• The AppLogic GUI is now accessible using the Google Chrome and Apple Safari web browsers in addition to Internet Explorer and FireFox
• Singleton appliances are now denoted by an S icon in the upper-right corner
• 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
• Applications now have the following new states:
  • BUILDING: application is currently being built
  • RESTARTING: application is currently starting as part of an application restart
  • RESTART_STOPPING: application is currently stopping in preparation for an application restart

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:

• Impexless Import from a remote URL: Ability to import applications/catalogs/classes/volumes from a remote URL (HTTP only)
  • Note that impexless export is not supported
• Application migration to a grid: Applications can now be migrated to and from a remote grid (both directions are now supported)
• Full migration support: Catalogs and classes may now be migrated 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 disaster recovery (DR) appliances:
  • MYSQLR64: a MySQL cluster server with replication, supporting master-master, multi-master, master-slave and remote replication/DR
  • INSSLR: 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
  • NASR: NAS for remote replication
• New application stack appliances:
  • VPN: Virtual Private networking appliance. Provides secure and reliable tunnels for inter-grid communications as well as remote access to applications and appliances.
  • IN2/OUT2/NET2: new gateways based on a read-only boot volume
  • MYSQL64: a 64-bit MySQL database server appliance
  • PGSQL64: 64-bit PostgreSQL database server appliances
  • TOMCAT64: 64-bit Tomcat application server (Sun Java machine and Apache Tomcat)
  • LOAD: Load Generator that can be used to test various load scenarios in your AppLogic web applications
  • URLSW: URL port switch for distributing HTTP requests to different appliances based on a regular expression
  • SQUID: SQUID proxy (web cache). SQUID keeps local copies of frequently requested data and returns cached content when applicable; thus decreasing response time and load on the backend servers
• 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)
• OSOL/OSOL64: 32-bit/64-bit OpenSolaris appliances based on OpenSolaris 2008.11
• 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
  • VDS64_CentOS50: 64-bit CentOS 5.0 VDS, used to be GSC64
  • VDS_OSOL: 32-bit OpenSolaris VDS (2008.11)
  • VDS64_OSOL: 64-bit OpenSolaris VDS (2008.11)
  • VDS_SOL10: 32-bit Solaris 10 VDS. This is not distributed with AppLogic.
  • VDS_Win03x: 32-bit/64-bit Windows 2003 Server VDS (all editions). These are not distributed with AppLogic.
• New Microsoft Windows template applications. These are just like the existing Linux Lamp applications except they are based on the IIS/SQL/ASP.NET Microsoft application stack:
  • WISA: simple 2-tier non-scalable WEB application
  • WISAx4: simple 2-tier scalable WEB application
• Updated sample applications that contain the latest versions of SugarCRM and TWiki
• All applications now have a convenient link for quick access to their documentation directly from the editor and dashboard.

Key Bug Fixes

The following key defects have been resolved in AppLogic 2.7.8:

• SCR 3240: Product: grid may crash due to bad ARP cache behavior and flood forwarding
• SCR 3227: Product: application recovery may hang after a grid recovers from an outage
• SCR 3318: Product: an unresponsive grid controller may not be restarted
• SCR 3131: Product: app/comp stop may stop the wrong HVM-based appliance
• SCR 3130: Product: windows appliance can unexectedly shutdown during app start
• SCR 3340: Product: appliances on the grid controller server lose their VMA connection (workaround implemented)
• SCR 3149: Product: system uptime may be reported incorrectly after grid install
• SCR 3257: CTL: comp restart can cause AppLogic to display that that the comp restarted due to a server failure
• SCR 3258: CTL: appliance will no longer fail to start if max mounts on a server is reached
• SCR 3133: CLI: grid reboot refuses to reboot if the grid has a disconnected server
• SCR 3221: CLI: moving an assembly to a catalog results in an unbuildable appliance
• SCR 3245: CLI: multi-line applications descriptions cannot be used
• SCR 2984: CAT: readable '/etc/applogic/' files pose security risk in VDSes
• SCR 3146: CAT: INSSL/INSSLR: uses insecure SSL ciphers
• SCR 3283: CAT: HALB: post data is incorrectly removed from post requests
• SCR 3185: GUI: Web Console does not redirect properly when using alternate ports
• SCR 3263: GUI: User can delete singletons from a read-only application

Hotfixes for AppLogic 2.7.8

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

Mandatory Hotfixes

• hf3389: Resolves several issues related to appliance compatibility, appliance/controller recovery and the AppLogic command line

Recommended Hotfixes

• None.

Optional Hotfixes

• hf2668: Enables bandwidth oversubscription (appliances may use more bandwidth than their configured bandwidth)
• hf3355: Resolves compatibility issues when using older appliance/assemblies that were created using AppLogic 2.1.1
• hf3388: Disables the storage failure detection feature (for testing purposes only)
• hf1248: Add support for controlling the volume repair speed of a grid from the distribution server

Note that you no longer need to install a seperate Windows hotfix to enable Windows support on your grid. AppLogic 2.7 includes Windows support.

Installation/Upgrade/Migration notes and issues for AppLogic 2.7

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

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

• Upgrading from AppLogic 2.1.x/2.2.2/2.3.8-2.4.x/2.7.4: AppLogic 2.7 supports upgrades from either 2.1.x/2.2.2/2.3.x/2.4.x/2.7.4 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.7 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.7 grid on separate servers and migrate your applications, catalogs and users over to the new 2.7 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.7 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.7 grid, follow the steps below:
  • First, make sure you create the users on your new 2.7 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.7 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.7 grid using the Linux rsync command: rsync -r -v --progress /vol/_impex/mydir 2.7_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.7 grid. Migrate the applications using the app migrate command executed from the 2.7 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.
  • In order to use your older AppLogic 1.2.14/2.0.2/2.0.5/2.1.x/2.2.2 appliances on a 2.7 grid, please execute the following:
    • From within your AppLogic 2.7 distro, execute the following:
      • ./upgrade_apps.sh controller-IP
      • Be sure to specify the correct controller IP address
    • From within your AppLogic 2.7 distro, execute the following to make sure your appliances are using the latest Linux kernels:
      • ./upgrade_kernels.sh controller-IP --force
      • Be sure to specify the correct controller IP address
  • These scripts 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.x/2.7.4 grid to a AppLogic 2.7 grid: Migrate your appliances, catalogs and applications to your new 2.7 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.7 distro, execute the following:
    • ./upgrade_kernels.sh controller-IP --force
    • Be sure to specify the correct controller IP address
  • The upgrade script may take a few minutes to complete.
  • After the script has completed, your new grid is ready for use.
  • At this point, all appliances and applications should be migrated to the new grid and updated with the latest Linux kernel.

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.x and 2.7 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.

System Catalog

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

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

The system catalog also contains 5 beta appliance classes.

• VPN: Virtual Private networking appliance
• NASR: Replicated Network attached storage / file server appliance (HTTP and CIFS file access)
• IN2, OUT2, NET2: Optimized firewalled network gateways based on iptables (read-only boot volume and based on BusyBox)

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

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

The system catalog contains the following 6 deprecated appliance classes that are now superseded by newer classes. They will remain in the system catalog for this release but may be removed in a future release. 3tera recommends to update your AppLogic applications to use the latest appliances as specified below:

• HLB: Session-aware HTTP Load Balancer, superseded by HALB
• INSSL: HTTP Input Gateway with SSL Support, superseded by INSSLR
• MYSQLR, MYSQL64: MySQL Database Appliances, superseded by MYSQLR64
• PGSQL: PostgreSQL Database Appliance, superseded by PGSQL64
• WEB4: Simple Web Server Appliance, superseded by WEB5/WEB64

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

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

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

AppLogic also includes the following global catalogs:

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

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

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

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

Sample Applications

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

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

• Linux
  • VDS_CentOS51: CentOS 5.1 VDS
  • VDS64_CentOS50: 64-bit CentOS 5.0 VDS
• SunOS
  • VDS_OSOL: 32-bit OpenSolaris VDS
  • VDS64_OSOL: 64-bit OpenSolaris VDS
  • VDS_SOL10: Solaris 10 VDS. This is not distributed with AppLogic. Please contact 3tera technical support for more information.
• Windows
  • VDS_Win03S: 32-bit Windows 2003 Server Standard Edition VDS
  • VDS_Win0364S: 64-bit Windows 2003 Server Standard Edition VDS
  • VDS_Win03E: 32-bit Windows 2003 Server Enterprise Edition VDS
  • VDS_Win0364E: 64-bit Windows 2003 Server Enterprise Edition VDS
  • VDS_Win03DC: 32-bit Windows 2003 Server DataCenter Edition VDS
  • VDS_Win0364DC: 64-bit Windows 2003 Server DataCenter Edition VDS
  • VDS_Win03W: 32-bit Windows 2003 Server Web Edition VDS
  • Note that these applications are not installed on the AppLogic grid. Please see the Windows Appliance Installation Reference for details on how install and setup thse applications.

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

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

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

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

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

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

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

AppLogic Grid Distribution System

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

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

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

Installation

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

Pre-requisites

Aldo and its documentation are available only to grid maintainers.

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

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

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

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

Downloading the release

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

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

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

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 (certified on 11 servers)
• 31 grids per back-end LAN
• 1024 applications per grid, up to 1024 applications running simultaneously
• If you need different dimensions, give us a call

Other Dimensional Limits

Please also see the OS limitations topic for more information.

• Per application
  • 512 network interfaces per application

• Per appliance, common dimensions
  • 64GB RAM
  • 16 CPU (1600%)
  • 2000 Mbps bandwidth
  • 1 external network interface
  • 1 default network interface

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

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

• Per appliance: OpenSolaris
  • 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 PV drivers for enhanced I/O performance
    • Please see the Windows Appliance PV driver topic for more information.

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

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

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

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

• If you need different dimensions, give us a call

Hardware Compatibility

• Single CPU, Multi-CPU (SMP), single, dual and quad core
  • Certified: Pentium P4, Intel Xeon/Woodcrest/Clovertown, AMD Opteron, AMD Athlon64
  • Supported: Intel Pentium P4 or better; AMD Athlon or better
  • Note: Intel hyperthreading is automatically disabled by AppLogic and is not used
  • Requires either Intel VT or AMD-V for hardware virtualization support (HVM)
    • HVM is mandatory for running Solaris 10 and Microsoft Windows on your grid
    • HVM is mandatory for using iso2class to install new appliances based on different OS distros

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

• Minimum 2GB RAM (4 GB recommended, 64 GB tested)
• Maximum 64GB RAM per server
• 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)
  • It is strongly recommended not to use servers with 1GB of RAM or less with AppLogic. If AppLogic is used with such servers, the grid may become unstable.

• 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.
  • Storage health monitoring: works only with hard disks that support S.M.A.R.T.
  • 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

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

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

Software Compatibility

• Appliances
  • Please also see the OS limitations topic for more information.
  • Note: all OSes listed in this section were verified using iso2class (and hvm2pv when needed)
  • Linux based
    • 32-bit/64-bit Linux OS (a mix of 32-bit/64-bit appliances may be running on the same grid)
    • Kernel 2.6.16-33 with Xen 3.0.4 support and Kernel 2.6.18 with Xen 3.2.2 support
    • 32-bit Tested: Fedora Core 3, CentOS 5.x, RHEL 5.3, SUSE Enterprise 11, Ubuntu 8.0.4, Debian 5.0
    • 64-bit Tested: CentOS 5.0, CentOS 5.1, RHEL 5.3, Debian 5.0
    • Supported: all Linux distros based on recent 2.6 kernel (see Linux distros verified by AppLogic developers and users)
    • SUSE Enterprise APK is BETA; please report issues to 3tera technical support
  • OpenSolaris based
    • 32-bit and 64-bit are both supported
    • Verified with OpenSolaris 2008.11
  • Solaris 10 based
    • 32-bit only
    • Verified with Solaris 10 update 4
  • Windows 2003 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

• AppLogic GUI
  • Browser support: Microsoft Internet Explorer, Mozilla FireFox, Google Chrome, Apple Safari

• 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. 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.
8. 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.
9. 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.
10. Web browser's Javascript and pop-ups must be enabled to use the web-based graphical user interface (dashboard, editor, documentation)
11. Users are responsible for allocating, assigning and use of externally visible IP addresses for applications; AppLogic takes care of all internal network assignments
12. 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.
13. Network performance between servers on the private network used for volume and inter-appliance communication is measured to approximately 900 Mbps. The TCP network performance measured between appliances residing on different servers is measured as 720-900 Mbps. When running Windows, the TCP network performance is about 940 Mbps and UDP is about 350 Mbps. A future release of AppLogic may contain optimizations that will improve the network performance of Linux, Solaris and Windows.
14. 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.
15. 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.
16. 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.
17. 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.
18. There is no user visibility during a grid controller restart due to a grid controller VM failure. If the grid controller VM fails and AppLogic restarts the grid controller VM, there is no user visibility while the controller is restarting. Typically it takes 1-2 minutes for the grid controller to restart on its own. If the grid controller is unavailable for more than 5 minutes, please contact 3tera technical support.
19. There is an issue with the GUI that was reported when using older versions of FireFox; specifically version 3.0.14 on Microsoft Vista. When using the application editor, closing the editor window resulted in closing all of the AppLogic GUI browser windows, thus forcing the user to re-open their browser and login to the AppLogic GUI. Upgrading FireFox to the latest version resolved this issue (3.5.3 at the time of this writing). If you experience this issue or any other strange type of GUI behavior, please make sure your browser is updated to the latest version before reporting the issue to 3Tera.

Known Problems and Limitations

Limitations

1. Grid size is limited to 128 servers per grid

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

2. AppLogic's web based user interface requires Firefox 3 or later, Microsoft Internet Explorer 6 or later, Google Chrome 3.0.195.24 or later, or Apple Safari 4.0.3 or later to operate

Javascript, pop-ups and cookies should be enabled for the grid controller's host for proper operation of the user interface. Please use the latest available bugfix versions of these browsers, as they correct a number of browser defects needed for AJAX applications.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

17. Application migration wizard in the GUI only works with 2.4.5-2.7 grids

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

18. Failover groups may not be satisfied upon controller recovery

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

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 assigned to an HVM-based appliance, the appliance uses additional memory on the server in which it is running (this additional memory is required by the virtualization hypervisor running on the servers and is known as shadow memory). Therefore it is possible that even though a server might have enough available memory as compared to what is assigned for the appliance, the appliance will not be able to run on that server due to the additional shadow memory needed for HVM-based appliances that is not available on the server. The AppLogic scheduler does take this extra shadow memory into account when scheduling appliances during application start.

Known Problems and Issues

The following are the key known problems in this release:

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

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

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

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

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

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

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

If a grid is rebooted using the grid reboot command, when the grid comes back up after the reboot, one or more of the system volumes may become degraded. AppLogic automatically repairs these volumes as highest priority.

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

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

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

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

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

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

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

When a server fails, shell commands may 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 5 minutes. After 5 minutes, the grid should return to normal operation.Please note that in AppLogic 2.4+, 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/Chrome/Safari when using the AppLogic GUI

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

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

20. Defect SCR 3087 - An application started from the GUI goes into standby state if the page is refreshed

If a user starts an application using the AppLogic GUI and during the start process refreshes the application list page, the application will not start and will be in a standby state. This is a known issue; to workaround this problem restart the application (and do not refresh the application list page while the application is starting).

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

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

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

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

Known Problems and Issues specific to Windows-based appliances

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

1. Defect SCR 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 (we are not sure why this is; this has been observed when a user installed a version of Microsoft SQL server in their appliance). Additionally, the source volume can be corrupt due to normal ware and tear. This issue can be worked around by running a file system repair on the volume (vol fsrepair) before resizing the volume.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

15. Defect SCR 3323 - For the IIS/SQL appliances the pace of custom counters are not taken into account

This is an issue with the MON appliance in AppLogic and will be fixed in a future release. When using graphs with IIS/SQL, you must configure the pace of the graphs to the same pace that is used by these appliances. IISx uses a pace of 2 seconds, SQLx uses a pace of 10 seconds. If the paces are not set correctly in your IIS/SQL graphs, a red outline will appear around the entire graph.

Unreproducible Problems and Issues

The following list of problems have been observed in AppLogic 2.3/2.4/2.7 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 2842 - Server rebooted due to a crash in the Linux kernel

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

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

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

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

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

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

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

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

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

6. Defect SCR 2944 - Application import of LampX4 failed

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

7. Defect SCR 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).

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

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

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

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

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

13. 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 has been worked around in AppLogic 2.7.

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

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

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

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

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

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

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

Contact Information

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

Self-help Resources

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

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

3Tera Partner Resources

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

On-line

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

Live Support

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

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

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

Interactive Sessions

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

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

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

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