Multiple eth devices in EC2: Feature request
Wed, 10/01/2008 - 17:58 — mvyver
Hi,
In order for UC 4.0 to work out the box it would be useful to have multiple ethernet interfaces on the head/boot node.
UC workarounds might be possible. Nonetheless, it would seem to make the adoption of Grid head node oriented software less painful if this feature was added to Amazon's EC2.
If you also think so, perhaps you might add your voice to the following thread, or other related threads you come across?
http://developer.amazonwebservices.com/connect/thread.jspa?messageID=102...
Ethernet
I have very little idea about ethernet. I am looking for more information if anyone continue this thread to provide more information, then I will really appreciate.
Thanks,
Multiple devices EC2
Mulitple interfaces in EC2 is nice to work. Perhaps when u consider a cluster part definitly network will not identify these. But bugs can be removed when u follow the proper channel.
cool.....
This is a really great post!
Best Regards
Jay Pleas,
Multiple eth devices and private networks
Hi Mark,
I agree that it would be nice to have mulitple interfaces in EC2 but I think that only gets you part way. What would be ideal for UniCluster is to have a concept of a private network within EC2 so that the head node could actually run a network. If you just had two interfaces you would still need a way to know which other nodes in EC2 were part of your cluster.
I've been doing some work to get UniCluster 4.0 running in EC2. The problem with the network interfaces isn't really that there's only one, its that the one that exists is a dynamic address. This is what will keep it from installing out of the box. I've got an installer (head) node running on EC2 now (I had to fix some bugs to get this to work) and I'm trying to figure out the best way to deal with the dynamic addresses and the shared network.
Multiple eth devices and private networks
Hi Tom,
Thanks for the response. Great to know my interest in running UC completely within EC2 this does not make me Robinson Crusoe. It seems the white paper's inside-outside UC 3.2 configuration was a sensible move.
Or are this issues for UC 4.0 alone?
I'm not a network guru, but it was suggested in an Amazon forum to use vtun to make connections - is this feasible? Sensible?
Then I wonder if it is possible to setup the head node as a router for all the node traffic?
I'm not even sure if this is possible, but it also means that there is now a network bottleneck at the head node.
There is an interesting discussion in the EC2 thread below. Several people essentially ask for the same feature (I suggest it would be worth raising the 'employ existing cluster software' use case in that thread?). Two possible work around approaches mentioned are openVPN and VDE - "building a switch topology on the fly" sounds a challenge.
Hopefully you have some network guru to comment on the best approach? which would be.... :)
http://developer.amazonwebservices.com/connect/thread.jspa?messageID=445...
A openVPN AMI might save some time?
ami-d72fcabe rbuilder-online/phonehome-1.6.2-x86_13742.img.manifest.xml
Finally. Am I likely to have much luck trying to get a UC 3.2 head node running within EC2? I'm still 'doing my homework' but this is what I wanted/needed to get working.
Mark
Good link
Yeah, that link describes a scheme that would work out well for UniCluster. Unfortunately it looks like there hasn't been any action on it by Amazon. Also unfortunately, I don't think turning the node into a psuedo router is the answer either as it would become the bottleneck and that would just get worse as the size of the cluster started to scale up.
Partially, it depends if there is any need for the compute nodes to talk to each other. Things like ganglia require this but SGE doesn't. I think what needs to be worked out is a way for the head node to identify each of the compute nodes and for the compute nodes to be able to recognize the head node. Once you have that you can decide if you need those links encrypted.
As far as getting a 3.2 head node inside EC2 I can't think of any reason why it wouldn't work off the top of my head other than the same things I mentioned above regarding the nodes being able to find each other. With an external head node its pretty simple because you always have a reference point that has a static IP address. Is your reason for wanting everything inside EC2 that you don't have a suitable machine/connection to run externally?
Agreed. AWS probably won't
Agreed. AWS probably won't make such network changes.
I don't like the openVPN or VDE workarounds. As you say, because of the bottleneck issue, but mainly because they'll be difficult to maintain - not much of a user/experience group in this context.
This issue of the EC2 head-node identifying the workers is tricky, I think most EC2 project (scalr) solve this by using a external server.
Yes, I don't have a suitable machine to serve as the head-node of a cluster - so I need the Head-node to be within EC2.
Now I've been digging around and it seems this problem has potentially been solved - it is not currently clear that the solutions code/package will be released.
Specifically addressing: "a way for the head node to identify each of the compute nodes and for the compute nodes to be able to recognize the head node"
I'll post about this is a separate thread.
Mark
Yes, please do post
Yes, please do post somewhere if there's a good solution.
The post
FYI, a possible solution?
http://groups.grid.org/content/deploying-ec2-clusters-using-uc
I think this could work
Yeah, it might work.
Thanks for the link provided!
---
I agree
Many ethernet interfaces are needed to get it to work better.