Chris, On 5/12/2020 1:25 PM, Christopher Schultz wrote: > Mark, > > On 5/12/20 16:14, Mark Eggers wrote: >> Chris, > >> On 5/12/2020 12:55 PM, Christopher Schultz wrote: >>> Jonathan, >>> >>> On 5/12/20 11:20, Jonathan Yom-Tov wrote: >>>> The problem is that my application is running on AWS which >>>> apparently doesn't support multicasting so I can't use >>>> Tomcat's DeltaManager. >>> >>> The membership-manager is separate from the replication-manager, >>> so this has nothing to do with e.g. DeltaManager. >>> >>> You don't have to use multicast. You can use static membership if >>> you know your node IP addresses. >>> >>> Rémy recently added a cloud membership service that uses >>> Kubernetes as its default membership service. It looks like he >>> hasn't written any documentation for it, but it exists in Tomcat >>> 9 and 10.[1] >>> > >> This sounds interesting. I wonder how this will play using >> multiple availability zones for high availability. It still won't >> handle region outages, but there are other approaches for that. > > I have no idea. There doesn't seem to me to be any reason why > Kubernetes could not be used across regions. Maybe you wouldn't be > able to use AWS-kube and might have to do it yourself. I have zero > experience with Kubernetes, and zero experience with complex AWS > deployments. > >> I'll read the link you sent, and maybe play with that locally with >> a Kubernetes setup. If I have questions about the set up, would >> here or the dev list be the place to ask? > > I think here would be better, since the answers will be visible to a > wider group of people. >
That sounds reasonable. I know a lot of the devs read this group, so hopefully (once I get started) there will be some answers. > I'd love to see a writeup about this, including "how to set up > Kubernetes from scratch to manage your Tomcat cluster" because I know > literally nothing practical about it. That and tying it into a cloud environment should be interesting. I'll need to think about this before writing stuff on a mailing list, let alone a document. I'm just starting my journey through Docker / Kubernetes. I've put together some simple images locally, and even have a private repository set up running on Nexus 3. My experience with Kubernetes clusters is limited to running "canned" environments. It looks like an interesting road. . . . just my two cents. /mde/ > > -chris > >>>> I thought of using one of the Store implementations for >>>> PersistentManager but that has the issues which I mentioned >>>> earlier. My aim is to get to the point where I can add or take >>>> away servers from the cluster without impacting user >>>> experience. >>> >>> See above. Sounds like the cloud membership service is what you >>> are looking for because it (a) handles dynamic membership and (b) >>> doesn't use multicast. >>> >>>> Ideally all state would be stored in a central location (e.g. >>>> Redis). But, since this is difficult because of the way the >>>> application is built I thought of using one server and only >>>> persisting the sessions when the server goes down. But I still >>>> have to solve the issues I mentioned. >>> I would avoid single points of failure if possible. A "central >>> location" tends to be a single point of failure. Tomcat clustered >>> with e.g. BackupManager and dynamic membership will (a) achieve >>> your goals and (b) not require additional products. >>> >>> Hope that helps, -chris >>> >>> [1] >>> https://github.com/apache/tomcat/blob/master/java/org/apache/catalina > /tr >>> >>> > ibes/membership/cloud/CloudMembershipService.java#L34 >>> >>>> On Tue, May 12, 2020 at 6:06 PM Christopher Schultz < >>>> ch...@christopherschultz.net> wrote: >>> >>>> Jonathan, >>> >>>> On 5/12/20 05:51, Jonathan Yom-Tov wrote: >>>>>>> I have an application which changes the state of user >>>>>>> sessions in lots of places in the code. Is it possible to >>>>>>> do a seamless switch of Tomcat servers, preserving all >>>>>>> sessions? >>>>>>> >>>>>>> I know I can use PersistentManager to persist sessions >>>>>>> and load them. I can think of two strategies: >>>>>>> >>>>>>> 1. Persist sessions periodically. This is more robust as >>>>>>> I might not have control of when the server shuts down. >>>>>>> 2. Persist sessions on server shutdown. >>>>>>> >>>>>>> >>>>>>> The problem with the first approach is that I might lose >>>>>>> the latest changes when the new server comes up. The >>>>>>> problem with the second is that I'll have to lock access >>>>>>> to the session until the old server is done saving it, >>>>>>> which may make response times very slow. >>>>>>> >>>>>>> Is there a good solution to this that I might have >>>>>>> overlooked? >>> >>>> If you want to solve these problems: >>> >>>> 1. Seamless (uninterrupted) restarts 2. Always up-to-date >>>> (well, as much as possible) 3. No downtime >>> >>>> Then you really need a cluster where the sessions are being >>>> replicated around the cluster. >>> >>>> This will solve some other problems as well: >>> >>>> 4. Expected downtime (e.g. OS/Tomcat/application upgrade) 5. >>>> Unexpected downtime (network outage, hardware fault) 6. >>>> Scaling-out (either manually or automatically) >>> >>>> You can do it with as little as two Tomcat instances. If you >>>> only care about being able to restart your application (and not >>>> the whole server, for example), then you can even run them >>>> side-by-side on the same server. You won't get protection >>>> against OS upgrades and unexpected downtime in that case, but >>>> you can get familiar with the setup without a whole lot of >>>> infrastructure. >>> >>>> -chris >>>>> >>>>> ------------------------------------------------------------------- > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org >
signature.asc
Description: OpenPGP digital signature
