Page History

...

1. The Web Grid Manager presents a Web interface that shows information of the whole Grid and present simple buttons to operate the Tomcat instances.
   
2. The managing logic must be clearly separated from the Web interface logic, since later on, a Command-Line Grid Manager will be included, and will use the same managing logic.
   
3. The available commands for each instance are:
   • status: retrieves the status of a Tomcat instance through the corresponding Grid Agent
   • trigger-start: sends a start request to the Tomcat instance using the corresponding Grid Agent
   • trigger-stop: sends a stop request to the Tomcat instance using the corresponding Grid Agent
   • trigger-kill: sends a kill request to the Tomcat instance using the corresponding Grid Agent
     • markt: A small thing. I think I'd prefer start/stop/kill/
     • vlad: I added these commands on phase 7 and, as I see them, they behave are a little bit different from the trigger ones, specially when we refer to the CLI manager. The trigger-start, issues the signal to the Grid Agent and ends. The start keeps on working (and updating the user) until the Tomcat instance is actually up (or fails to start up). On the Web interface the trigger start could show up as a simple icon (omitting its name). On the CLI I see the start command as far more useful than the trigger-start.
       

4. Wiki Markup
   A simple configuration file lists all the machines and their instances so the Grid knows where each instance resides. \[This configuration file is probably in XML format\] \\

5. Grid Agents are installed on each machine and manage all instances in that machine pertaining to the Grid. Grid Agents receive commands from any manager and act accordingly. To manage the instances the Agents use:
   • Shell calls: start an instance, kill an instance.
   • JMX calls to retrieve instance live information.
   • JMX calls to change instance live values, and to request instance shutdown.
   • OS calls for any OS related need.
     
6. It's assumed that a port will be accessible from each Grid Manager to each machine where the Grid Agents are serving. The firewall, if present must allow active server-type sockets on that port.
   • markt: Another architectural question. Which end opens the connection, does it stay open and which protocol is used? For example, agents connect to Manager via WebSocket.
   • vlad: I always considered the Grid Agent would would open a server NIO socket, to avoid using ephemereal ports. The Grid Agent is always listening, and the Managers connect when needed. In terms of protocol, it could be a ad-hoc one, specially developed for this tool, or use a well-known standard. I have ad-hoc one that I can use, but I'm open to suggestions.
     
7. Multiple Grids (and Grid Agents) can be running on the same set (or subset) of machines. If that's the case, Tomcat instances, and Grid Agents run on different ports for each grid. When multiple grids use the same machines they don't interfere with each other and can be operated simultaneously.
   
8. The status command shows the following information for each instance:
   • Machine
   • Service (a unique grid-wide name for each instance)
   • State
     
9. The state of an instance can be:

   • Wiki Markup
     *Active*: the instance OS process exists, the instance is serving requests, and it looks healthy \[enough\]. \\

   • Wiki Markup
     *Zoetic* \[for lack of a better word\]: the instance OS process exists, but the instance is unresponsive and it doesn't respond to requests for state. It's probably not serving any HTTP requests, does not look healthy, it may be starting, it may be shutting down, it may be overwhelmed. Who knows. \\

   • Stopped: the instance OS process does not exist, and therefore the instance is not operating at all.
     
   • Not Available: This is a pseudo state that the manager applications (web and cli) show when a Grid Agent does not respond to requests for status in a timely manner.
     
   • If possible it would be great to discern different sub cases of the Zoetic state, so to help the user to determine what's going on and tackle the case accordingly:
     • Starting: The Tomcat instance process exists, and the instance is starting. It's not yet serving HTTP requests.
       
     • Stopping: The Tomcat instance process exists, and the instance is stopping. It's no longer serving HTTP requests.
       
     • Unresponsive: The Tomcat instance process exists, but the instance health isn't good, it's not responding to HTTP requests, or it's overwhelmed. It's not even responding to requests for status. This state is different from "Not Available" since in this case the Grid Agent IS active and responding, but the Tomcat instance itself is unresponsive.
       
     • On second thoughts, these extra states can actually be discerned today with the current version of Tomcat, since the Grid Agents know all the trigger commands each local instance has received and can deduce (or make up) the sub case. If the Grid Agent is restarted, some kind of persistence of its state might be needed to "remember" what was going on before the Grid Agent was shut down, so to make an educated guess.
       
10. Grid Agents communicate over unsecured TCP sockets, and assume communication security is enforced by the network architecture (segregated segments/VLans).
    
11. The "trigger"-type commands just deliver the corresponding signal to the instance's Grid Agent and returns right away, without waiting for the full operation to complete. It's kind of "fire and forget". The web user can keep on refreshing the the web interface to find out about the progress of the status of the Tomcat instances.
    

12. Wiki Markup
    Simple user name/password authentication is implemented to secure the Web interface. \[Maybe we'll need to provide more options\] \\

Phase 2 - Manageable Grid Agents

...

1. The status command now adds more information for each service (Tomcat instances and Grid Agents):
   • CPU usage (if possible)
   • CPU load (if possible)
   • Heap usage (if possible)
   • Threads (if possible)
   • Started on (if possible)
   • Any other information deemed useful for managing purposes.
     

2. Wiki Markup
   \[Optional\] Machine information (same page, or maybe an extra tab) shows per machine:

   • CPU usage
   • CPU load (1 min, 5, min, 15 min)
   • Memory usage
   • File system space usage for the mount where the "webapps" dir is (can this be different per instance?).
     

...

1. The following commands can now be issued on collections in addition to plain services:
   • status
   • trigger-start
   • trigger-stop
   • trigger-kill
   • start
   • stop
   • kill
   • restart
   • killstart
   • deploy
   • rollback
   • deploystop
   • undeploy
     
2. Hooks are modified to provide information of the collection they are affecting.
   
3. When a hook runs on a collection, it runs on the machine where the manager application (web or cli) runs, not remotely on the machine of any other instance. This is because in this case the execution is not tied to a specific instance, but to a collection.
   
4. Services defined in a collection can be managed in sequential or parallel modes. For example, a restart command on a sequential collection will restart the second service only, when the first one has fully completed. Once the second completes, it will restart the third one, and so on. A parallel collection would issue a restart on all services simultaneously.
   
5. Collections are defined in the configuration file and are of a recursive nature: a collection can include plain services, other collections, or both. For sequential mode, each "sub-collection" is treated as a single element so it's considered fully complete when all its included services and collections complete.
   

6. Wiki Markup
   \[To be analyzed and defined if it's useful or not\] Collections editing through the Web interface. This can be useful to graphically update collections when machines/instances are added/removed. \\

Phase 11 - Instance Configuration

...