Hi All,
We have a Cassandra cluster setup with 2 EC2 m1.large machines, one is
running in us-east zone whereas 2nd one is running in us-west zone. As part
of Seed section, I provided each other's node's EC2 public DNS entry in each
of storage-conf.xml. but when I ran nodetool command, I am not fin
What are you using for ListenAddress and ThriftAddress in the
storage-conf.xml file? By default, they are set to 'localhost', which means
Node A is probably telling Node B to contact itself on the private IP
address.
Marty
On Mon, Jun 28, 2010 at 7:18 PM, Lenin Gali wrote:
> Hi All,
>
> We hav
ode's public IP as part of Seed for west.
Niru
--- On Mon, 6/28/10, Marty Greenia wrote:
From: Marty Greenia
Subject: Re: Cassandra on AWS across Regions
To: user@cassandra.apache.org
Date: Monday, June 28, 2010, 10:27 PM
What are you using for ListenAddress and ThriftAddress in the storag
Marty Greenia wrote:
>
> From: Marty Greenia
> Subject: Re: Cassandra on AWS across Regions
> To: user@cassandra.apache.org
> Date: Monday, June 28, 2010, 10:27 PM
>
> What are you using for ListenAddress and ThriftAddress in the
> storage-conf.xml file? By default, they are
On Jun 29, 2010, at 12:44 PM, Anthony Molinaro wrote:
> Maybe you need to modify the security groups to allow the ports to be
> accessible from one to the other?
A likely better solution would be to look into the VPNCubed product which was
built specifically for this purpose. We're in the middl
Thanks Joe, I was hoping to hear from you. Can you pass me the SA contact at
AWS we would love to look in to it.
Lenin
--Original Message--
From: Joe Stump
To: user@cassandra.apache.org
ReplyTo: user@cassandra.apache.org
Subject: Re: Cassandra on AWS across Regions
Sent: Jun 29, 2010 11
On Jun 29, 2010, at 2:56 PM, Lenin Gali wrote:
> Thanks Joe, I was hoping to hear from you. Can you pass me the SA contact at
> AWS we would love to look in to it.
Just contact your account representative. They'll get you hooked up. They have
multiple SAs that help out account representatives.
A few months ago, there was a thread on this list about using Cassandra
across multiple EC2 regions. I was interested in doing in doing
the same thing, and managed to make it work.
To implement this, there are basically two things that need to change.
First, in storage-conf.xml, I used the "ext
Could you explain this point further? Was there an exception?
On 09/01/2010 09:26 AM, Peter Fales wrote:
that doesn't quite work with the stock Cassandra, as it will
try to bind and listen on those addresses and give up because they
don't appear to be valid network addresses.
--
*Andres Marc
The issue is this:
The IP address by which an EC2 instance is known _externally_ is not
actually on the instance itself (the address being translated), and
the _internal_ address is not accessible across regions. Since you
can't bind a specific address that is not on one of your local
interfaces,
I probably should have made it clear that I wasn't proposing this as
an official patch (as you point out, it's not general enough for
production use). I'm just looking for feedback on the concept (thanks!)
and thought it might possibly be useful to other folks trying to
do the same thing.
On W
On Wed, Sep 1, 2010 at 4:42 PM, Peter Fales
wrote:
> I probably should have made it clear that I wasn't proposing this as
> an official patch (as you point out, it's not general enough for
> production use). I'm just looking for feedback on the concept (thanks!)
> and thought it might possibly b
Is it not possible to put the external host name in cassandra.yaml and
add a host entry in /etc/hosts for that name to resolve to the local
interface?
On 09/01/2010 01:24 PM, Benjamin Black wrote:
The issue is this:
The IP address by which an EC2 instance is known _externally_ is not
actuall
It's not gossiping hostnames, it's gossiping IP addresses. The
purpose of Peter's patch is to have the system gossip its external
address (so other nodes can connect), but bind its internal address.
As Edward notes, it helps with NAT in general, not just EC2. Not
perfect, but a great start.
b
+1
On Wed, Sep 1, 2010 at 1:24 PM, Benjamin Black wrote:
> The issue is this:
>
> The IP address by which an EC2 instance is known _externally_ is not
> actually on the instance itself (the address being translated), and
> the _internal_ address is not accessible across regions. Since you
> can'
I thought you might say that. Is there some reason to gossip IP
addresses vs hostnames? I thought that layer of indirection could be
useful in more than just this use case.
I still think it is a good idea to have a separate bind vs gossip config
param.
On 09/01/2010 03:10 PM, Benjamin Bla
On Wed, Sep 1, 2010 at 3:18 PM, Andres March wrote:
> I thought you might say that. Is there some reason to gossip IP addresses
> vs hostnames? I thought that layer of indirection could be useful in more
> than just this use case.
>
The trade-off for that flexibility is that nodes are now depen
On Sep 1, 2010, at 1:42 PM, Peter Fales wrote:
> I probably should have made it clear that I wasn't proposing this as
> an official patch (as you point out, it's not general enough for
> production use). I'm just looking for feedback on the concept (thanks!)
> and thought it might possibly be
I didn't have anything specific in mind. I understand all the issues
around DNS and not advocating only supporting hostnames (just thought it
would be a nice option). I also wouldn't expect name resolution to be
done all the time, only when the node is first being started or during
initial di
On Wed, Sep 1, 2010 at 4:16 PM, Andres March wrote:
> I didn't have anything specific in mind. I understand all the issues around
> DNS and not advocating only supporting hostnames (just thought it would be a
> nice option). I also wouldn't expect name resolution to be done all the
> time, only w
Ben, can you elaborate on some infrastructure topology issues that would
break this approach?
On Wed, Sep 1, 2010 at 6:25 PM, Benjamin Black wrote:
> On Wed, Sep 1, 2010 at 4:16 PM, Andres March wrote:
> > I didn't have anything specific in mind. I understand all the issues
> around
> > DNS and
On Thu, Sep 2, 2010 at 5:52 AM, Phil Stanhope wrote:
> Ben, can you elaborate on some infrastructure topology issues that would
> break this approach?
>
As noted, the naive approach results in nodes behind the same NAT
having to communicate with each other through that NAT rather than
directly.
22 matches
Mail list logo
