Dear Wiki user, You have subscribed to a wiki page or wiki category on "Tomcat Wiki" for change notification.
The "TomcatGridDiscussion" page has been changed by theimpaler: https://wiki.apache.org/tomcat/TomcatGridDiscussion?action=diff&rev1=5&rev2=6 Please feel free to update, fix, change, and reorganize this document in any manner you feel is useful. == Introduction == - The Tomcat Grid manages one or more Tomcat instances from a centralized location. This manager application shows the status of each Tomcat instance, and provides a simple interface to trigger operations on them, individually or as a group. + The Tomcat Grid manages one or more local or remote Tomcat instances from a centralized location. This manager application shows the status of each Tomcat instance, and provides a simple interface to trigger operations on them, individually or as a group. == Architectural Overview == The centralized location of the Tomcat Grid (the primary location) stores the grid configuration, probably as an XML file. For reliability purposes, secondary locations can be setup so the grid configuration is replicated after every change. - The primary location runs a Tomcat Grid Manager, a web application that runs on a separate Tomcat instance. This manager application shows the state of the all Tomcat instances on the grid, and allows users to trigger operations on these Tomcat instances. + The primary location runs a Tomcat Web Grid Manager, a web application that runs on a separate Tomcat instance. This manager application shows the state of the all Tomcat instances on the grid, and allows users to trigger operations on these Tomcat instances. In addition to the Web Grid Manager, a Command-line (CLI) Grid Manager application mimics the functionality of the web manager, with an equivalent (text-only) interface that shows the status of the Tomcat instances, and provides commands to trigger remote operations on them. - The secondary locations run on dedicated Tomcat instances. They run a copy of the Grid Manager but they are shut down all the time unless they are explicitly started by an operator (when the primary one goes bad). No two managers should be active at the same time. If activated, the secondary locations can start producing changes to the local grid configuration, and these changes are replicated to all other managers (if/when possible). + The secondary locations run on dedicated Tomcat instances. They run a copy of the Web Grid Manager but they are shut down all the time unless they are explicitly started by an operator (when the primary one goes bad). No two managers should be active at the same time. If activated, the secondary locations can start producing changes to the local grid configuration, and these changes are replicated to all other managers (if/when possible). The example shown in the figure below assumes Machines #1 and #4 run a lighter web and/or back end applications, so they have enough resources bandwidth to run the extra Tomcat instance for the manager. In case the primary manager on Machine #1 goes down (or the whole Machine #1 goes down), there is a secondary manager (on Machine #4) that can be activated to take over the managing duties. {{attachment:TomcatGridExample.png}} - The Grid Agents are Java processes installed and running on each machine that listen (on a configured port) for commands from a manager application (Web or CLI) and act upon them by interacting with the local Tomcat instances. No encryption is envisioned on the network channels, since all these machines are considered to be installed on a secured network segment (at least in prod). [Maybe we should reconsider this] + The Grid Agents are Java processes installed and running on each machine that listen (on a configured port) for commands from a Grid Manager application (Web or CLI) and act upon them by interacting with the local Tomcat instances. No encryption is envisioned on the network channels, since all these machines are considered to be installed on a secured network segment (at least in prod). [Maybe we should reconsider this] - All the Tomcat instances (including the Web Grid Managers), as well as the Grid Agents, are installed manually. The primary grid manager and all the agents are started manually too. + All Tomcat instances (including the Web Grid Managers), as well as the Grid Agents, are installed manually. The primary grid manager and all the agents are started manually too. - Once the Web Grid Manager is started up, machines and instances can be registered in it, so they can become manageable. No centralized (comprehensive) provisioning is envisioned until later version of Tomcat Grid (see below). + Once the Web Grid Manager is started up, machines and instances can be registered in it, so they can become manageable. No centralized (comprehensive) provisioning is envisioned until later versions of Tomcat Grid (see below). - The Grid Agents are also processes that can be managed. In particular, status can be obtained (and showed) from them, and basic operations (start/stop/kill) can be triggered on them. These operation are, however, heavily dependent on the OS capabilities (configuration, installed tools, etc.) and the infrastructure architecture (fire-walled machines, network VLans, etc). + The Grid Agents are processes that can also be managed. In particular, status can be obtained (and showed) from them, and basic operations (start/stop/kill) can be triggered on them. These operations are, however, heavily dependent on OS and OS capabilities (configuration, installed tools, etc.) and the infrastructure architecture (fire-walled machines, network VLans, etc). - Collectively Tomcat instances and Grid Agents are "services", since both can be managed. + Collectively, Tomcat instances and Grid Agents are "services" since both can be managed. - Later versions of the grid include "collection" management. This allows to group subsets of services (Tomcat instances and Grid Agents), so they can be operated as whole. A collection can include plain services, or other collections (recursively). + Later versions of the Grid include "collection" management. This allows to group subsets of services (Tomcat instances and Grid Agents), so they can be operated as whole. Each collection can include plain services, or other collections (recursively). - Considering all the above, the following phases could be considered for on the Tomcat Grid development. + Considering all the above, the following phases could be considered as a base line for the road map of the Tomcat Grid. == Phase 1 - Core Grid Operation == The first phase includes the most basic features, in order to provide a functioning and useful first version of the Grid. @@ -42, +42 @@ Included features are: - 1. The Grid Manager presents a Web interface that shows information of the whole Grid and present simple buttons to operate the Tomcat instances. + 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. 1. 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. 1. The available commands for each instance are: - * '''status''': retrieves the status of a Tomcat instance + * '''status''': retrieves the status of a Tomcat instance throught the corresponding Grid Agent - - * '''trigger-start''': sends a start request to the Tomcat instance + * '''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 + * '''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 + * '''trigger-kill''': sends a kill request to the Tomcat instance using the corresponding Grid Agent 1. 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] 1. 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 calls, + * Shell calls: start an instance, kill an instance. * JMX calls to retrieve instance live information. - * JMX calls to change instance configuration and state. + * JMX calls to change instance live values, and to request instance shutdown. * OS calls for any OS related need. - 1. It's assumed that a port will be accessible on each where the Grid Agent serves the managers application. The firewall, if present must allow active server-type sockets on that port. + 1. 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. - 1. Multiple Grids 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. When multiple grids use the same servers they don't interfere with each other and can be operated simultaneously. + 1. 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. 1. The status command shows the following information for each instance: * Machine @@ -84, +81 @@ * '''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 state 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. - 1. Grid Agents communicate over unsecured TCP sockets, and assume the network segmentation provides a secure segment. + 1. Grid Agents communicate over unsecured TCP sockets, and assume communication security is enforced by the network architecture (segregated segments/VLans). - 1. 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 status of the Tomcat instances. + 1. 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. 1. Simple user name/password authentication is implemented to secure the Web interface. [Maybe we'll need to provide more options] @@ -96, +93 @@ Included features are: - 1. As well as the instances, the agents can become unresponsive, or even crash. To address cases like these commands are implemented to manage the agents as well. The grid agents become now manageable services. + 1. As well as the instances, the agents can become unresponsive, or even crash. To address cases like these commands are implemented to manage the Grid Agents as well. The Grid Agents become now manageable services. - 1. All grid agents are now also registered in the configuration file under (also) unique service names. All manageable services have unique names so commands (a trigger-start, for example) can distinguish which type of service it needs to act on, and will chose a different logic (program, or script) to execute. + 1. All grid agents are now also registered in the configuration file under a unique service names. Grid agents names share the same namespace than Tomcat instance names: i.e. the Tomcat instances & Grid Agent names are grid-wide unique. This way commands (such as a trigger-start for example) can distinguish which type of service it needs to act on, and will chose a different logic (program, or script) to execute. - 1. All four previously defined commands are now available for the Grid Agents: + 1. All previously defined commands are now available for the Grid Agents: * status * trigger-start * trigger-stop * trigger-kill - 1. The status command now adds an extra column "Type" after the service column that indicates the type of service: Tomcat instance, or Grid Agent. + 1. The status command now adds an extra column "Type" that indicates the type of service: Tomcat instance, or Grid Agent. - 1. The mechanism to manage the grid agents is necessarily OS dependent. For example, in Linux it can be implemented using Bash commands though SSH. Most suitable mechanisms must be studied for each OS. + 1. The mechanism to manage the grid agents is necessarily OS dependent. For example, in Linux it can be implemented using Bash commands though SSH. Suitable mechanisms must be studied for each OS. == Phase 3. Secondary Managers == The functionality for configuration replication is added. @@ -119, +116 @@ 1. Every time a configuration change is produced or detected on the configuration of the primary manager, the changes are distributed to all secondary managers. - 1. If the primary manager is down, secondary managers can distribute new configuration changes. + 1. If the primary manager is down, secondary managers can be started, and can start producing changes (based on the local configuration copy). They can also start distributing the new configuration changes. == Phase 4 - Extended Service & Machine Information == This phase extends the status information of the whole grid beyond the basic data. --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
