View source

'''Before starting this section please make sure that you have already configured the appropriate cloud provider/s, currently we support Amazon EC2(all regions), RackSpace, IBM, and Eucalyptus cloud.  Follow these links for instructions on configuring supported clouds [[Amazon AWS Setup|Amazon]], [[RackSpace Setup|RackSpace]], [[IBM Cloud Setup|IBM Cloud]], and [[Private Eucalyptus Cloud Setup| Eucalyptus]]'''

*[[#Deploying n-tier System from the System Template|Deploying n-tier System from the System Template]]
*[[#Monitoring and Alerts|Monitoring and Alerts]]
*[[#Configuring System Level Events(Auto Pilot Functionality)|Configuring System Level Events(Auto Pilot Functionality)]]

===Deploying n-tier System from the System Template===
After you have setup your account, created the SSH key-pair (Certificate), and setup tthe firewall groups, you are ready to deploy the n-tier system.  Go to the n-tier page.  Select the system from the list of templates you want to deploy, in this example we will select the 3 tier LAMP stack (Linux, Apache, MySQL, PHP).  Give a name to the system and click on Deploy System.  The system will be deployed, and by clicking on the System Name under Your System you will get the graphical view of the system.  Before launching the system you need to configure the system.  Configure the system, please watch '''[http://www.youtube.com/watch?v=pBHLriQIra8 this brief video]''' to learn how to configure the system using the UI Wizard introduced in version 1.8 of IMOD. [http://demos.kaavo.com/UI-Wizard/Kaavo-IMOD-UI-Wizard.html Click here for the high resolution video of the UI Wizard]

[[File:Deploying-System-From-Template.jpg]] 
'''Figure 1: Deploying System from sample template'''

[[File:Graphical-View-Deployed-System.jpg]] 
'''Figure 2: Graphical view of the deployed system prior to launching'''

Clicking on the Definition tab for the system will give you the view of the System Definition with the workflows and scripts for configuring the entire system in one place.
[[File:System-Definition-File-Deployed-System.jpg]]
'''Figure 3: System Definition for the deployed system'''

You can make any changes to the system definition, e.g. put custom firewall rules for each server, have different key-pairs or launch parameters.  If you are deploying the system in the EU region please make sure to replace the US ami ids in the system definition file with equivalent EU amis and update the corresponding awsServer parameters. To find the list of Kaavo images in EU and US region go to the ami tab on the Dashboard page.  Kaavo installed images have agents for monitoring and encryption functionality.  You can deploy systems with non Kaavo images using IMOD n-tier dashboard.  However, you wouldn’t be able to use monitoring and encryption functionality without the monitoring and encryption agents.  Contact Kaavo support for information on how to install Kaavo monitoring and encryption agents on your custom server images.  You can install additional software on Kaavo provided images and re-bundle them and use them.  For more information about how to edit the system definition file or create your own custom system definition please refer the Guide For Creating Custom System Definitions in IMOD .  To launch the system go to the Runtime tab for the system and click on Start System, this will launch the system. IMOD will start deploying the system by launching servers and configuring tiers based on order and dependencies defined in the system definition file.  It takes about 12-15 minutes to have everything fully live for the 3-tier system we are using in this example.   All the servers and tiers will have the green light once everything is fully online.

[[File:Running-System.jpg]] 
'''Figure 4: Fully functional running system'''

After the servers are up click on the drop down arrow on one of the load balancers and copy the URL.  

[[File:List-of-functions-on-servers.jpg]]
'''Figure 5: Drop down list for functions for the servers'''

----

[[File:Instance-Information.jpg]] 
'''Figure 6: Information about the server instance'''

Paste the IP address of the load balancer in a browser and add /php-colab in the end of the URL, you will see the PHPCollab app is deployed and running.  So with a single click within few minutes the entire infrastructure with 4 servers MySQL cluster, 2 app servers, and 2 load balancer running PHPCollab application is up and is live.  You can start and stop system with a single click.  Basically creating a custom system definition file gives you a single click repeatable process for deploying and running your custom systems.

[[File:php-collab-app-screenshot.jpg]] 
'''Figure 7: Screenshot of fully functional PHPCollab application'''

To see the configuration of the load balancer put the pubic IP address of the load balancer in the browser and add /balancer-manager to the following to the URL.  You will see the IP addresses of the two app servers are configured to each load balancer.

[[File:Loadbalancer-screenshot.jpg]]
'''Figure 8: Screenshot of load balancer configuration'''

Note: System templates are provided for convenience and as examples you can create any custom system and clone or edit any deployed system.

===Monitoring and Alerts===
On the monitoring page you will see a list of all running systems and you can drill down tiers and selecting the individual server you want to monitor or set alert on. 

[[File:Monitoring-page-screenshot.jpg]]
'''Figure 9:  Monitoring page screenshot'''

'''Note:''' Monitoring functionality is available for only Kaavo provided AMIs as each Kaavo provided AMI has a custom monitoring agent installed on it for sending monitoring data to IMOD.  If you want to install monitoring agent on your own custom AMI please contact support@kaavo.com for how to instructions.

===Configuring System Level Events(Auto Pilot Functionality)===
Kaavo’s unique application centric approach allows you to define custom workflows at the system level and associate them with the custom event such that anytime a system level event is triggered corresponding workflow is executed.  Proper configuration of events and appropriate response (workflow) for the event allows the user to run the application with IMOD engine acting as auto-pilot.  This is very useful functionality to improve service levels and have IMOD take automatic actions to ensure security and higher service levels for your application.  In our example the 3-tier LAMP system definition file have three preconfigured workflows for auto-recovery (app-tier-server-died), auto scale-up (app-tier-over-utilized), and auto scale-down (app-tier-under-utilized).  You can have as many events/workflows defined for your system as you need.

To configure the triggers for the events, go to the monitoring page after the system deployed is up and running, click on Configure System Event button, it will bring up the configuration window for the event. In our example as the workflows are defined only for the app tier unselect the servers for the app tier.  In the Event Name drop down list, select one the event workflows defined in the system definition file, for this example lets pick app-tier-server-died.  

[[File:Configure-System-Level-Triggers-For-Events.jpg]]
'''Figure 10: Configuring system level triggers for events'''

There are two types of events, Aggregate and Non-Aggregate. Aggregate events are triggered when the aggregate function threshold is met for the servers; for computing the aggregate threshold we use average function.  The non-aggregate events are triggered when threshold is met on any of the servers in the group.  

If you configure the app-tier-server-died event as shown in the diagram (Non-Aggregate with Ping as Threshold), whenever server ping failed for the server, the system will automatically launch and configure a new server in the system and remove the dead server (not responding to the ping).  To test this functionality you can simulate the killing of the server by looking at the instance id of one of the server in the app-tier and killing it from the outside IMOD using either using the command line tool or the Firefox plug-in for EC2.  Within 1 minute of the killing of the instance IMOD will launch a new instance and start configuring it automatically using the predefined workflow.  Within few minutes the system will be fully recovered and the load balancer configuration will be updated with the IP address of the new server.  During the recovery IMOD will change the state of the system from running to recovery.

[[File:System-Recovery.jpg]] 
'''Figure 11: System in recovering state (auto-recovery)'''

Events can also be triggered manually by clicking on the event button and selecting and firing the appropriate event.

[[File:Manual-Triggering-Events.jpg]]
'''Figure 12: Manual triggering of events'''

For more information refer to the Guide For Creating Custom System Definitions in IMOD

'''Note:''' You can define any custom workflows in the system definition file and configure them to any custom events.  In addition to configuring your own system level triggers, we also allow integration for events from external monitoring systems; please contact us at support@kaavo.com to find out details on how to integrate the events generated from external systems to IMOD.

===Scheduling Events===
As of version 1.7, IMOD added the ability to execute application centric complex workflows for n-tier systems at scheduled time, see the screen-shot below.  This functionality allows to users to schedule complex or simple maintenance tasks to be performed automatically on n-tier systems at the scheduled time.  Users can also schedule deployment of complex n-tier systems at the scheduled time or stop a running system at the scheduled time.  Any event/workflow can be scheduled, for example if you know your application's behavior you can add additional resources at a specified time using scheduler, e.g. add more resources during peak hours and remove them after peak hours.  Although IMOD allows you to add resources automatically using the monitoring system to trigger events in response to load, monitoring approach is reactive and suited for applications where load characteristic are unpredictable.  For predicable load you can proactively bring servers online even before monitoring system will detect increase in usage.

[[File:Scheduling-Workflows.jpg]] 
'''Figure 13: Screen-shot of the System Workflow Scheduler'''