Thanks for your response. Some comments below... On Thursday, 27 November 2014 18:49:20 UTC, Ryan Tanner wrote: > > I think it really depends on how you've designed your cluster. If you > make use of cluster roles, you could just redeploy specific parts of your > cluster (e.g., we have an "analytics" role in our cluster and I could just > redeploy those nodes *if* their inter-node classes haven't changed). Doing > this does require some advanced planning on your part: you have to be > careful to define which messages are sent between nodes and which should be > purely within a node. Once again, that comes down to your specific use > case. >
I guess the approach of using roles still leaves the issue of version consistency unanswered? Even using roles, there's still a question mark over whether it's possible to ensure all nodes of a given role are updated at something close to resembling the same time. > > In our cluster, each role is a different service and we have a very small > set of messages sent between services and their supervisor so we could > redeploy a single node, though in practice we don't bother since our > cluster isn't user facing—they won't know if it's down for five minutes > during a redeploy. > > tldr: if you're very careful about the messages sent between nodes doing a > hot redeploy of a subset of your cluster should be doable. > > Another option of course would be to load-balance across > 1 cluster and > redeploy entire clusters at a time. > I'd definitely be keen to understand if anyone has tried this. Maybe using containerization (e.g. Docker) might pave the way for something like this - e.g. spinning up the new version on the same VM, but in a separate docker container to the currently active version. And then having some kind of mechanism for switching to the new cluster via loadbalancing. There's a potential benefit in this respect that rapid rollback would be pretty trivial. Of course, as you mention, there's obviously going to be context specific challenges that could make such a solution impractical. This theme does make me think somewhat about Bounded Context (BC) theory from Domain Driven Design (DDD). Whilst there might be a motivation from a strictly technology perspective to run a single cluster with multiple roles, I'd certainly be wary of allowing one cluster to overlap multiple BCs. My hunch would be that introducing such a coupling between BCs could end up comprising the benefits of having created a logical separation between them. My point here being, by all means use roles, but you may run into issues if you're running services (with a given role), that belong to separate BCs, within the same cluster. Complete deployment isolation would seem like a very desirable quality for separate BCs. Having said that, it's still perfectly reasonable for a single BC to encompass multiple services that you'd still ideally like to deploy independently from each other. Thoughts? > On Thursday, November 27, 2014 10:20:39 AM UTC-7, Andrew Easter wrote: >> >> I'm interested to understand what patterns people would use when >> upgrading a clustered Akka application. >> >> My main area of ignorance is over the situation where, during a new >> deployment, a cluster might be running different versions of the same >> application on different nodes. I can foresee potential situations where >> users would experience unexpected behaviour, for example, where nodes in >> the cluster may be handling web requests. >> >> Are there any patterns around doing this. For example, running a backup >> cluster alongside the active cluster? i.e. deploy new version to the backup >> cluster and have some mechanism (e.g. using load balancer) to switch >> traffic between the active and the backup. >> >> I'm conscious that I've presented a simple use case and the active/backup >> approach might be somewhat harder to achieve in complicated architectures. >> >> Is there something obvious I'm missing, or is this a common area that >> requires creative, context specific solutions? >> >> -- >>>>>>>>>> Read the docs: http://akka.io/docs/ >>>>>>>>>> Check the FAQ: >>>>>>>>>> http://doc.akka.io/docs/akka/current/additional/faq.html >>>>>>>>>> Search the archives: https://groups.google.com/group/akka-user --- You received this message because you are subscribed to the Google Groups "Akka User List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/akka-user. For more options, visit https://groups.google.com/d/optout.
