Re: [Question] Akka, EC2 and autoscaling

[Eric Pederson]

Hi Pere:

1. You will want to have at least one application instance running at a well-known location (hostname and port#).  For example use Elastic IP to allocate static IP addresses for the well-known instances.   Use these as the cluster seed nodes.

2. Take a look at the Cluster Singleton Pattern.  

On Tuesday, April 2, 2013 5:59:55 PM UTC-4, Pere Villega wrote:

Hi,

I have a question about Akka, EC2 and auto-scaling (and a bit of design). I promise I tried to do my homework but after spending a couple of days reading as much as I could, I still can't wrap my head around some "issues". Any help would be extremely appreciated.

Scenario:

I want to deploy a Play 2.1 app (which includes Akka) in Amazon EC2, across several nodes. As a web app, the application may receive connections to different nodes that should somehow communicate with other nodes in the network to transmit messages. To draw a parallelism, think about it like a massive distributed chat.

I'm thinking on a pub-sub approach for this, but I have a couple of questions for which I've found either no answer or a confusing one.

Questions:

1. I've seen that Akka cluster is still experimental. In the case the application gets new instances deployed, how can I notify existing nodes about the new ones using Remote? More specifically, how would that work with an automated process like auto-scale in Amazon AWS? Is that even possible without the cluster? (I suspect no, but would like to confirm just in case there is some workaround)
2. Let's say I want the state of a channel to be managed by a certain node. This node will be in one instance and should send/receive (via the pub-sub channel) messages to other ec2 instances. If the instance the node is at dies (kernel panic or similar) that manager would cease to exist, and no node would replace it. What would be a recommended way to avoid that, or in other words, which system would you recommend to track the death of that manager? I thought a router that passes management messages to actors in different nodes would be an option, but I wonder about state synchronization between the different instances and if there is some common pattern for that scenario that I missed.

Thanks a million :)

Pere Villega

[Eric Pederson]

Hi Pere - no problem.  Note, Cluster doesn't require multicast - you join to a specific cluster member using seed nodes or manual joining.  If I remember correctly there have been some issues reported with failure detection on EC2 and that you may need to tune failure detection to get it to work smoothly.

On Sunday, April 7, 2013 10:22:38 AM UTC-4, Pere Villega wrote:

Hi Eric,

thanks for answering! I'll try that. I assume that Cluster works fine in EC2, as I read some comments about multicast usage that made me doubt it.

Cheers,
Pere Villega

[Roland Kuhn]

7 apr 2013 kl. 20:20 skrev Eric Pederson:

Hi Pere - no problem.  Note, Cluster doesn't require multicast - you join to a specific cluster member using seed nodes or manual joining.  If I remember correctly there have been some issues reported with failure detection on EC2 and that you may need to tune failure detection to get it to work smoothly.

Yes, the default settings are definitely too tight for EC2; we plan on experimenting with alternate settings after the next milestone is out, the goal is to be able to give some guidelines from where to start tuning for different deployment scenarios. If anybody has experience with some cloud providers and is willing and able to share, that would be great!

Regards,

Roland

On Sunday, April 7, 2013 10:22:38 AM UTC-4, Pere Villega wrote:

Hi Eric,

thanks for answering! I'll try that. I assume that Cluster works fine in EC2, as I read some comments about multicast usage that made me doubt it.

Cheers,
Pere Villega



On Thursday, April 4, 2013 8:43:53 PM UTC+1, Eric Pederson wrote:

Hi Pere:

1. You will want to have at least one application instance running at a well-known location (hostname and port#).  For example use Elastic IP to allocate static IP addresses for the well-known instances.   Use these as the cluster seed nodes.

2. Take a look at the Cluster Singleton Pattern.  

On Tuesday, April 2, 2013 5:59:55 PM UTC-4, Pere Villega wrote:

Hi,

I have a question about Akka, EC2 and auto-scaling (and a bit of design). I promise I tried to do my homework but after spending a couple of days reading as much as I could, I still can't wrap my head around some "issues". Any help would be extremely appreciated.

Scenario:

I want to deploy a Play 2.1 app (which includes Akka) in Amazon EC2, across several nodes. As a web app, the application may receive connections to different nodes that should somehow communicate with other nodes in the network to transmit messages. To draw a parallelism, think about it like a massive distributed chat.

I'm thinking on a pub-sub approach for this, but I have a couple of questions for which I've found either no answer or a confusing one.

Questions:

1. I've seen that Akka cluster is still experimental. In the case the application gets new instances deployed, how can I notify existing nodes about the new ones using Remote? More specifically, how would that work with an automated process like auto-scale in Amazon AWS? Is that even possible without the cluster? (I suspect no, but would like to confirm just in case there is some workaround)
2. Let's say I want the state of a channel to be managed by a certain node. This node will be in one instance and should send/receive (via the pub-sub channel) messages to other ec2 instances. If the instance the node is at dies (kernel panic or similar) that manager would cease to exist, and no node would replace it. What would be a recommended way to avoid that, or in other words, which system would you recommend to track the death of that manager? I thought a router that passes management messages to actors in different nodes would be an option, but I wonder about state synchronization between the different instances and if there is some common pattern for that scenario that I missed.

Thanks a million :)

Pere Villega

--
>>>>>>>>>> Read the docs: http://akka.io/docs/
>>>>>>>>>> Check the FAQ: http://akka.io/faq/
>>>>>>>>>> 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 akka-user+...@googlegroups.com.
To post to this group, send email to akka...@googlegroups.com.
Visit this group at http://groups.google.com/group/akka-user?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Dr. Roland Kuhn
Akka Tech Lead
Typesafe – Empowering professional developers to build amazing apps.
twitter: @rolandkuhn

[√iktor Ҡlang]

Music to our ears! :)

On Mon, Apr 8, 2013 at 10:00 PM, Pere Villega <arac...@gmail.com> wrote:

Thanks a million for the answers, I've been trying and it works great in EC2 :)

--

Viktor Klang
Director of Engineering

Typesafe

Twitter: @viktorklang

[G J]

Would you care to outline the steps to run Akka on EC2? It would help a great deal.

Thanks.

On Monday, April 8, 2013 4:00:09 PM UTC-4, Pere Villega wrote:

Thanks a million for the answers, I've been trying and it works great in EC2 :)

On Sunday, April 7, 2013 7:30:19 PM UTC+1, rkuhn wrote: