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=4&rev2=5 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}} - ..Machine #2............. - : : - : [Tomcat #2] : - : ^ : - : | [Tomcat #6] : - : | ^ : - : | | [Tomcat #9] : - : | | ^ : - : | | | : - +---------->[Grid Agent #2] : - | : : - | ......................... - | - | - ..Machine #1............. | ..Machine #3............. - : : | : : - : [Primary Web Manager]---------->| : [Tomcat #3] : - : : | : ^ : - : [Tomcat #1] : | : | [Tomcat #7] : - : ^ : | : | ^ : - : | [Tomcat #5] : | : | | [Tomcat #10]: - : | ^ : | : | | ^ : - : | | : | : | | | : - : [Grid Agent #1]<----------------|---------->[Grid Agent #3] : - : : | : : - : [Primary CLI Manager]---------->| ......................... - : : | - ......................... | - | ..Machine #4............. - | : : - | : [Sec. Web Manager] : - | : : - | : [Tomcat #4] : - | : ^ : - | : | [Tomcat #8] : - | : | ^ : - | : | | : - +---------->[Grid Agent #4] : - : : - : [Sec. CLI Manager] : - : : - ......................... - }}} 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] 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. @@ -79, +36 @@ Considering all the above, the following phases could be considered for on the Tomcat Grid development. == 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. In particular, no Tomcat instances or Grid Agents automatic provisioning is considered, no configuration GUI (only pre-configured XML config files), no WAR deployments, no command-line interface, no complex grid operations, no secondary managers, and no collections. @@ -136, +92 @@ 1. 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 == - This phase revamps the Grid Agents so they become manageable. Included features are: @@ -156, +111 @@ 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. == Phase 3. Secondary Managers == - The functionality for configuration replication is added. Included features are: @@ -168, +122 @@ 1. If the primary manager is down, secondary managers can distribute new configuration changes. == Phase 4 - Extended Service & Machine Information == - This phase extends the status information of the whole grid beyond the basic data. Included features are: @@ -188, +141 @@ * File system space usage for the mount where the "webapps" dir is (can this be different per instance?). == Phase 5 - Command-Line Interface (CLI) == - This phase provides a CLI manager interface for environments that cannot use the web interface. Included features are: @@ -210, +162 @@ 1. Return codes must be strategically defined to allow automation. Well defined return codes can provide useful information to the caller program/process, so it can clearly identify the problem and act accordingly. == Phase 6 - Hooks == - Extending the core operation of the grid services with custom logic. Included features are: @@ -238, +189 @@ 1. When hooks are registered (maybe uploaded) on the Grid they are automatically distributed behind the scenes to all instances/machines before they are ready to use. == Phase 7 - Enhanced Grid Operation == - Beyond the basic trigger operations, there's usually need for more complex ones, that provide very common needs but are seldom formally implemented. Included features are: @@ -275, +225 @@ 1. The non-trigger commands show an update of the service state periodically (defaults to every 10s, and can be specified on the configuration file), and they keep working until the full operation completes. == Phase 8 - Simple Deployment == - This phase implements War applications deployment and undeployment to the grid as a whole, or to specific Tomcat instances. Included features are: @@ -289, +238 @@ 1. The status command is revamped so it now lists all war applications deployed on each instance. == Phase 9 - Application Version Management == - The application versioning is like a deployment functionality on steroids. The Application Version Management may interfere with the simple Deployment as described before, since it manages web applications in a different manner. It needs to be studied if both modes are compatible and can work at the same time, or if both are mutually exclusive. If the latter, the user will need to choose which mode to use when setting up the grid. @@ -353, +301 @@ * '''post-link''' == Phase 10 - Collections == - Collections are groups and sub-groups of services (instances and/or agents) that are managed together. Essentially, instead of issuing a command on a single service, you can now issue it onto a collection. The commands will now affect all services in the collection and will probably take longer to complete, since multiple operations are now needed to complete the whole command. Collections may group identical Tomcat instances or maybe Tomcat instances that do not serve the same purpose. For example, one subgroup of Tomcat instances may run the customer facing site (like an HTTP cluster), other group may run the back end site (maybe processing JMS queues), other group may be dedicated to serving or connecting to integration points. @@ -386, +333 @@ 1. [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 == - The Web interface adds functionality to specify Tomcat instances configuration from the centralized location. The CLI interface does not offer this functionality. [to be discussed] @@ -404, +350 @@ * Other instance configurations == Phase 12 - Instance Provisioning == - This functionality removes the necessity of a manual setup of all machines and Tomcat instances of the Grid. After installing the first Tomcat instance and deploying the Web Manager, provisioning operations to local or remote machines can be performed through the web interface. Because of its nature, the implementation of the provisioning operations is heavily OS dependent. @@ -449, +394 @@ 1. The provisioning operations require remote access to the new machine, and therefore some kind of connections needs to be setup. For example, an SSH connection could be used if the user provides the user name/password credentials or if if an ssh key exchange had been previously setup between the machines. == Phase 13 - Custom Commands == - [To be described] == Phase 14 - Version Repository == - [To be described] --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
