Re: StaticMembers within Multiple Clusters
On Fri, Jan 18, 2019 at 11:05 AM Christopher Schultz wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Tim, > > On 1/18/19 06:38, Tim K wrote: > > Thanks for this. The video helps explain it a bit better than the > > documentation. So I set it up with a backup manager instead of the > > delta manager, changing the channelSendOptions to 6 for the > > cluster. > > If you think you can help clarify the documentation, patches are of > course always welcome. > > > From a maintenance standpoint, what is the best way to stop/start > > the nodes without losing sessions; one at a time, letting it fully > > come up before moving on to the next one (like a ripple restart)? > > I presume you don't want too many nodes to be down at a single > > time. > > I definitely wouldn't bring two down simultaneously if your can avoid > it. The cluster needs time to re-stabalize after the loss of a member, > meaning that new backup nodes must be selected for each session and > then the sessions must be transmitted to those backups nodes. If you > have small amounts of data in the sessions, this will probably be > fairly fast. If you have lots of data or a very busy network, it will > take longer. > > I would recommend setting-up a scenario (even in production) where you > intentionally disable a node in the cluster and watch to see how long > the cluster takes to re-stabalize. I think you'll learn a lot from > that exercise and it will help you plan for scheduled maintenance and > downtime. > > - -chris Is there a way to tell which server was assigned as the primary and backup roles? When I stop a member, is it this line which would tell me how long it took to sync up the sessions? Relocation of map entries was complete in [X] ms. Another question, I'm using the StaticMembershipService; do I need to define a LocalMember for each of my nodes or is that optional/assumed? Also, I recall reading something about the uniqueId might not really be used? Do I need to set that for each member? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: StaticMembers within Multiple Clusters
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Tim, On 1/18/19 06:38, Tim K wrote: > Thanks for this. The video helps explain it a bit better than the > documentation. So I set it up with a backup manager instead of the > delta manager, changing the channelSendOptions to 6 for the > cluster. If you think you can help clarify the documentation, patches are of course always welcome. > From a maintenance standpoint, what is the best way to stop/start > the nodes without losing sessions; one at a time, letting it fully > come up before moving on to the next one (like a ripple restart)? > I presume you don't want too many nodes to be down at a single > time. I definitely wouldn't bring two down simultaneously if your can avoid it. The cluster needs time to re-stabalize after the loss of a member, meaning that new backup nodes must be selected for each session and then the sessions must be transmitted to those backups nodes. If you have small amounts of data in the sessions, this will probably be fairly fast. If you have lots of data or a very busy network, it will take longer. I would recommend setting-up a scenario (even in production) where you intentionally disable a node in the cluster and watch to see how long the cluster takes to re-stabalize. I think you'll learn a lot from that exercise and it will help you plan for scheduled maintenance and downtime. - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlxB+WEACgkQHPApP6U8 pFgaTBAAgB/GvhBVqD4TBfqvGu6EjnuC74p/yrK8QnflWXLsLT8U8O9Omqd/o6/Q uPstnAh9WW8ubQ9NA7GuIXLB2xo9zhfVcruncFSyHN4u65+PPy7zM6Jwc8ZXZ102 zO0esMIIHDa9b+ZqPxg2ire19jJnrPX0UqhBMiuNTUDl+8uNem7DcMBq8m0xsDPw jbglN4+Wu3kSYRzyhETK4PGHVgHJN0AZqzIh968t6VqqcrSkHd8EXUu+qoh62KJI MiEZJYKznzlm08Fb5N+a+cG60rV1zUI1QgYWnK/88gMNHib4Zg+x0HDdgIXSk1+D lDsAJMNQQ/W1gs0b/O0bX15bZCZxlxYDzNVVg4XjII5YhHdk8XriRk0Kgx2XZBP2 dcDvg8nppTLtpmBw5rs/SAHRR6RjV89z9RX9GWYUtrRR5IolGdfF3jeBA6VObImI X8xQ8qohy3U49WMPSae3Dg+8hQFWcDNw7+K9Q8j8ZhVW2JGk5ze0Q+zNnE0j5wuF szspBj+BA9E7VszPBJ5RYBMRbm9/UktzxVH53LwwKr46n7UxHQ/nQ84/4KaWlTKl EVD7/sa2dsFKfVxC0pf7d6WFs1SYkWouCeFrHNc3QDLdUHkuBsFBHMVhbQWe+YbJ pXROlmYBd3UVyE/BUkmuBlyYzi5riRkg8n6vewR4MGqHbeWooEo= =kiHi -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: StaticMembers within Multiple Clusters
On Fri, Jan 18, 2019, 4:55 AM Mark Thomas On 18/01/2019 01:40, Tim K wrote: > > On Thu, Jan 17, 2019, 3:36 PM Mark Thomas > > >> On 17/01/2019 15:28, Tim K wrote: > >> > >>> With the DeltaManager, instead of it notifying all nodes when sessions > >> get > >>> established, is there a way for it to only share that single node's > >>> sessions during a shutdown event of that particular node? For example, > >>> node 1 of 8 has 5 sessions on it. When node 1 is shut down, only then > >> will > >>> it replicate those 5 sessions to the other 7 nodes... This would > reduce > >>> the all-to-all traffic that would be occurring constantly but would put > >>> more weight on a shutdown event... Also, another wrinkle, the shutdown > >> port > >>> is disabled in server.xml for security reasons. > >> > >> None of the managers can be configured to replicate only on shutdown. > >> > >> The BackupManager is closer to the behaviour you describe. Note it is a > >> common misconception that in the BackupManager a single node acts as a > >> backup for all the other nodes. This is incorrect. Backups are > >> distributed on a round-robin basis between all other nodes. > >> > >> The shutdown port being disabled should be a non-issue. As long as you > >> kill -15 rather than kill -9 then you'll get a clean shutdown. > >> > >> Mark > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > >> For additional commands, e-mail: users-h...@tomcat.apache.org > > > > > > So to switch to Backup manager, just swap out the DeltaManager for it on > > each serve or just one? > > All of them. > > > You're right, it does seem the backup manager was > > a single node, even after looking again at the documentation. Is the > > backup manager "battle tested" enough since the documentation was > written? > > Yes. > > > Is there less network traffic with backup manager? > > Yes. > > > My nodes all have the > > same single app installed, I'm not sure what the advantage would be in > > using the backup manager. > > Less network traffic. > > See: > https://www.youtube.com/watch?v=6LoAdy9-jBI > > particularly from around 29:30 > > Mark > > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org Thanks for this. The video helps explain it a bit better than the documentation. So I set it up with a backup manager instead of the delta manager, changing the channelSendOptions to 6 for the cluster. >From a maintenance standpoint, what is the best way to stop/start the nodes without losing sessions; one at a time, letting it fully come up before moving on to the next one (like a ripple restart)? I presume you don't want too many nodes to be down at a single time.
Re: StaticMembers within Multiple Clusters
On 18/01/2019 01:40, Tim K wrote: > On Thu, Jan 17, 2019, 3:36 PM Mark Thomas >> On 17/01/2019 15:28, Tim K wrote: >> >>> With the DeltaManager, instead of it notifying all nodes when sessions >> get >>> established, is there a way for it to only share that single node's >>> sessions during a shutdown event of that particular node? For example, >>> node 1 of 8 has 5 sessions on it. When node 1 is shut down, only then >> will >>> it replicate those 5 sessions to the other 7 nodes... This would reduce >>> the all-to-all traffic that would be occurring constantly but would put >>> more weight on a shutdown event... Also, another wrinkle, the shutdown >> port >>> is disabled in server.xml for security reasons. >> >> None of the managers can be configured to replicate only on shutdown. >> >> The BackupManager is closer to the behaviour you describe. Note it is a >> common misconception that in the BackupManager a single node acts as a >> backup for all the other nodes. This is incorrect. Backups are >> distributed on a round-robin basis between all other nodes. >> >> The shutdown port being disabled should be a non-issue. As long as you >> kill -15 rather than kill -9 then you'll get a clean shutdown. >> >> Mark >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org >> For additional commands, e-mail: users-h...@tomcat.apache.org > > > So to switch to Backup manager, just swap out the DeltaManager for it on > each serve or just one? All of them. > You're right, it does seem the backup manager was > a single node, even after looking again at the documentation. Is the > backup manager "battle tested" enough since the documentation was written? Yes. > Is there less network traffic with backup manager? Yes. > My nodes all have the > same single app installed, I'm not sure what the advantage would be in > using the backup manager. Less network traffic. See: https://www.youtube.com/watch?v=6LoAdy9-jBI particularly from around 29:30 Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
