December 24 - AppLogic 2.4.7 is now available and is the latest production release!

---

History of features for AppLogic

This topic describes all of the new features that have been added to AppLogic between the 1.2.14 and 2.x releases.

From 2.1.0 to 2.2.2 BETA

The AppLogic 2.2.2 BETA release includes the following features which were not available in AppLogic 2.1.0.

User Features

• 64-bit Support: AppLogic now supports both 32-bit and 64-bit appliances. AppLogic provides the following 64-bit appliances in the /system catalog: LUX64, LINUX64, WEB64 and MYSQL64 (all based on 64-bit CentOS 5). AppLogic also provides the new GSC64, also based on 64-bit CentOS 5.
• New appliances in the /system catalog based on CentOS 5: The following new appliances are provided in the /system catalog (note that all appliances in /proto have been moved to /system):
  • LUX5: Generic Linux appliance based on CentOS 5
  • LUX64: Generic Linux appliance based on 64-bit CentOS 5
  • LINUX5: Generic Linux server based on CentOS 5
  • LINUX64: Generic Linux server based on 64-bit CentOS 5
  • MYSQL5: MySQL database based on CentOS 5 and MySQL 5.0.22
  • MYSQL64: MySQL database based on 64-bit CentOS 5 and MySQL 5.0.22
  • WEB4: Web server based on CentOS 5 and PHP 4.3.9
  • WEB5: Web server based on CentOS 5 and PHP 5.1.6
  • WEB64: Web server based on 64-bit CentOS 5 and PHP 5.1.6
• New Dynamic catalog: AppLogic now includes a new /dynamic catalog used for storing dynamic appliances. Dynamic appliances are a new type of appliance that are dropped into existing applications in order to add new functionality to the containing application. The /dynamic catalog includes the following appliance:
  • MIG: MIG enables the containing application to migrate or snapshot (non-live) itself to another grid (the migrate/snapshot operations are initiated through a GUI that is exposed by MIG).
• Updated GSC reference application: GSC is now based on CentOS 5
• New GSC64 reference application: GSC64 based on 64-bit CentOS 5
• Updated Linux Kernel: AppLogic now uses Linux Kernel 2.6.18, adding stability to the system and a wider variety of device support
  • Note that the 2.6.16.33 kernel may still be used in AppLogic appliances (the 2.6.16.33 and 2.6.18 appliance kernels are both supported on the same grid)

From 2.0.2 BETA/2.0.5 BETA to 2.1.0

The AppLogic 2.1.0 release includes the following features which were not available in AppLogic 2.0.2/2.0.5 BETA.

User Features

• Support for default resources: All appliances and applications now contain default resources (in place of the sandbox resources which have been removed from AppLogic). The default resources are used when an application/appliance is started w/o any specific resource requirements. The default resources are always between the minimum and maximum resources.
• Single-hop migration of applications: Application migration is now signifficantly faster as applications are migrated directly to remote grids (w/o having to use the impex volume for compression and transfer). A no-compress option has been added for migrations over GigE connections.
• 3 new prototype appliances based on CentOS 5: The following 3 new appliances are provided in the /proto catalog:
  • LUX5: Generic Linux appliance based on CentOS 5
  • LINUX5: Generic Linux server based on CentOS 5
  • WEB5: Web server based on CentOS 5
• WEB enhanced to execute a user-defined script on boot: The WEB catalog appliance can be configured with a user-defined script that will be automatically executed after WEB has booted. This allows the user to execute their own script at WEB appliance startup.
• CPU % is now supported for all commands: The user can now specifiy the CPU resource as % for any AppLogic command (in previous versions this only worked for some commands).
• Volume prefill: When a volume is created, a new --prefill option can be specified which causes the allocation of all blocks of the volume (using this new option will significantly increase the volume creation time). Prefilling a volume results in a non-sparse volume where all blocks in the volume are allocated ensuring higher read and write performance from the volume.
• Light control for application monitoring: Users can now control the lighting of their graphs, they can choose between a white or a black background. The colors in the graphs are automatically adjusted according to the selected lighting. The dark background can be used in NOC-type setup in order to reduce the intensity of the screens and increase graph's contrast.
• Global pace control in application monitoring: Users can now change the pace of all graphs from a single setting.
• Destroy all dashboard messages with a single command: Added support to destroy all messages on the dashboard using a single command: msg destroy --all

Maintainer Features

• Improved hardware support: the AppLogic kernel now uses CentOS 4.4 as its base OS, providing support for more recent hardware.
• Server re-imaging and partitioning: maintainers no longer have to worry about having a specific OS installed on their servers when installing an AppLogic grid. The AppLogic installer can now re-image a server with the proper base OS and partition schema as expected by AppLogic. Servers are re-imaged by using the ald-reimage script in the AppLogic distro.
• New rollback command: allows the maintainer to rollback an upgrade to the previous AppLogic version with minimal downtime (takes just a few minutes)
• Improved upgrade to minimize downtime: upgrade is now split into 2 distinct stages. The first stage readies your grid for the upgrade by importing all of the new software onto your grid (during this stage your grid is fully operational). The second stage performs the actual upgrade and is designed to minimize the downtime of your grid (typically just a few minutes).
• 128 servers per grid: an AppLogic grid can now contain up to 128 servers. 3tera has tested up to 64 servers.
• Logging of all executed AppLogic commands: All AppLogic commands that are executed through the command shell are now logged to the /var/log/3tshell log file on the AppLogic controller. This file contains the user which executed the command, the command itself and the date and time that the command was executed. Only grid maintainers have access to this log.

From 1.2.14? to 2.0.2 BETA/2.0.5 BETA

The AppLogic 2.0.2 BETA release includes the following key features which were not available in AppLogic 1.2.14.

User Features

• Application Monitoring: Provides visibility in the operatio1n and performance of AppLogic applications. Every appliance within an application can be monitored using the new MON appliance. Simply insert the new MON appliance into your application, connect the appliances to MON and start your application. Appliances are monitored by using the new monitoring GUI accessed by clicking on the monitor button in the main GUI. Appliances are monitored by using visual graphs that display the values of various counters within the appliances. The following counters are examples of what can be monitored for each appliance; please see CatMonitoringMon for the full list of supported counters and AdvCustomCounters for how to define your own custom counters:
  • Key statistics: CPU, memory, scheduler; total/used CPU, total/used/free memory, number of running processes
  • Network statistics: Packets sent and recieved, total bytes sent and recieved
  • Virtual volume statistics: total bytes read/written, completed read/write requests
  • Appliance specific statistics:
    • WEB: number of active requests, number of hits per second
    • MYSQL: number of queries, number of connections
• GUI Enhancements: AppLogic contains several new GUI enhancements:
  • Web Shell: The AppLogic GUI now contains a web shell used for accessing the grid controller's AppLogic shell and for accessing individual appliances (through SSH sessions)
    • Grid controller access: the main dashboard page contains a new "Shell login" button used for logging into the grid controller (also accessible through the application editor)
    • Appliance access: right click on an appliance and click on the new "Login" menu item; this will log the user into the appliance (bash shell)
  • Branding: The grid maintainer can now customize various aspects of the AppLogic GUI (see GuiBrandingConfig for customizing your grid GUI):
    • specification of the logo displayed when a user logs into the AppLogic GUI
    • replacement of various links available from the grid dashboard: terms of use and AppLogic help
    • support page customizations: support icons and links
  • Balloon connections: The AppLogic application editor now supports balloon connections. Balloon connections make an application diagram less cluttered by allowing the user to connect terminals without drawing connection lines on the diagram. See the new Lamp application for an example of how balloon connections look on a diagram.
• System catalog update: The system catalog now includes the following new/updated appliances:
  • INSSL: HTTP gateway with SSL support providing a firewalled entry point for network traffic into an AppLogic application
  • WEBx4/WEBx8: Scalable web server appliances for heavy traffic loads
  • MON: Monitor appliance used to collect counters from appliances within an application and displays them using visual graphs integrated into the AppLogic GUI
  • WEB: Added a new net output terminal used for subnet access, added real IP logging plus other minor changes
  • NAS: Added a new nfs input terminal used to access storage using the NFS/3.0 protocol
• New reference applications: AppLogic contains the following new reference applications which makes it easier to port your existing application onto AppLogic:
  • Lamp: Reference of a basic 2-tier non-scalable WEB application, includes the following appliances:
    • WEB for serving web content
    • NET for subnet access from within WEB
    • NAS for web content storage
    • MYSQL for database storage
    • INSSL to provide firewalled access to the web application
    • MON for monitoring the application
  • LampX4: A scalable Lamp application, uses 4 WEB servers with a load balancer (HLB) for heavy traffic load
• Various other new features:
  • Multi-user safe operation: The AppLogic grid is now safe to use by multiple users concurrently. This includes application build/start/stop, volume creation, volume repair, etc.
  • Unmanaged appliance support: An appliance can now be unmanaged; meaning that the appliance may not have/use any AppLogic-specific software such as the virtual machine agent or event generator (VMA/VME). In this case, the unmanaged appliance is started right away (AppLogic does not depend upon VMA/VME for boot and shutdown notifications). Managed appliances are required to use VMA/VME and will not start properly if it is missing or not used. Unmanaged appliances are denoted by using a field engineering code of 4.
  • New volume file system types: AppLogic now supports the following new file system types for AppLogic volumes. When creating a new volume, the user can specify any of these new file system types (for example: "create vol myapp:myvol size=100MB fs=reiserfs"):
    • reiserfs
    • fat32
  • Appliance shutdown timeout: Just like the current appliance boot timeout, now the shutdown timeout can be controlled on a per-appliance or system-wide basis:
    • For each appliance, the shutdown timeout can be configured through the GUI the same way as with the boot timeout (appliance attribute settings)
    • The default system-wide shutdown timeout can be controlled through the /etc/applogic/applogic.conf file on the grid controller (maintainer access is required). The com_shutdown_tout parameter controls the shutdown timeout (specified milliseconds, default is 15 minutes). All appliances use the configured boot/shutdown timeout unless the appliance-specific timeout setting is overridden.
  • Forced appliance shutdown: AppLogic supports a new --force flag for comp stop that is used to force an appliance to stop right away - the appliance is destroyed immediately bypassing the normal appliance shutdown (like a Linux halt -f). This is used in cases where an appliance is hung, stuck or does not respond and may refuse to shutdown. Keep in mind that forcing an appliance to stop may corrupt its file system; this command should be handled with care.
    • Example: stop my-app:comp1 --force
  • Application CPU capping: The amount of CPU that an application uses can be capped by using the new --cap_cpu option when the application is started using app start. This means that each appliance of the application cannot use more than its assigned CPU; for example if an appliance is assigned 30% CPU, then it cannot use more than 30% CPU even if the CPU has available cycles. In contrast, not capping the CPU allows the appliances use as much CPU as available on the server.
    • Example: start my-app --cap_cpu
  • Updated Linux Kernel: AppLogic now uses Linux Kernel 2.6.16.33, adding stability to the system and a wider variety of device support

Maintainer Features

• Support for modern hardware: AppLogic now supports modern SMP-style servers with the following features:
  • Dual CPUs, dual core for each CPU
  • Large physical memory support (>2GB, 8GB has been tested)
  • SMP Linux Appliances: Appliances can have more than 1 CPU and >2GB memory enabling them to take advantage of higher-end hardware
  • Multiple harddisks (spanned using LVM)
• 64 servers per grid: an AppLogic grid can now contain up to 64 servers.

-- EricT - 07 Sep 2007