See here: http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/index.html?concepts-regions-availability-zones.html
(My question remains. I'm interested in seed configuration practice/recipe when deploying on AWS. In the scenario, assume Cassandra sits behind some other part of the service -- say, web container -- that are then exposed publicly. Cassandra nodes themselves are not.)
A little off-topic, but is an availability zone in a separate physical
On Sat, Apr 3, 2010 at 5:08 PM, Benjamin Black <email@example.com> wrote:
> Right, you determine AZ by looking at the metadata. us-east-1a is a
> different AZ from us-east-1b. You can't infer anything beyond that,
> either with the AWS API or guesses about IP addressing. My EC2 snitch
> recipe builds a config file for the property snitch that treats AZs
> like racks (just breaking apart the AZ name, nothing magical), and the
> rest is the normal rack aware placement strategy. I am sure folks
> _could_ do interesting things on EC2 with extra code, but I don't see
> extra code as required for these basic features.
> On Sat, Apr 3, 2010 at 3:04 PM, Joe Stump <firstname.lastname@example.org> wrote:
>> On Apr 3, 2010, at 2:54 PM, Benjamin Black wrote:
>>> I'm pretty familiar with EC2, hence the question. I don't believe any
>>> patches are required to do these things. Regardless, as I noted in
>>> that ticket, you definitely do NOT need AWS credentials to determine
>>> your availability zone. It is available through the metadata web
>>> server for each instance as 'placement_availability_zone', avoiding
>>> the need to speak the EC2 API or store credentials in the configs.
>> Good point on the metadata web server. Though I'm unsure how Cassandra would know anything about those AZ's without using code that's aware of such things, such as the rack-aware strategy we made.
>> Am I missing something further? I asked a friend on the EC2 networking team if you could determine AZ by IP address and he said, "No."
Dan Di Spaltro