Posts Tagged: Amazon AWS

Amazon AWS / Recovery — No Comments
30
Jan 12

Recovering a non responsive AWS instance

I could not ssh in to one of my AWS instances last evening and it wasn’t serving any pages either. AWS management console said it was up, though. Rebooting did not help. The second reboot did not help either. Shutdown and start did not help. I was running out of tricks here!

For some reason, the instance had been running on 100% CPU utilization for days:

(I better do some monitoring in future!)

Even though the CPU usage had dropped after the restarting, the instance would not accept any connections. The only thing I could think of was to either ping the AWS forum, or to get the running volume on some new instance as the instance was an EBS based one. I decided to go with the new volume if the database would not mind too much. Steps I needed to do were:

  1. Snapshot the running volume
  2. Create a new volume out of the snapshot on the same availability zone
  3. Start a new instance with the Launch more like this
  4. Shutdown the new instance
  5. Detach the volume on the new instance
  6. Attach the volume which was created from the snapshot to new instance (need to have the correct  attachment information, like /dev/sda1)
  7. Start the new instance
  8. Disassociate the Elastic IP from the old instance
  9. Associate the correct Elastic IP on the new instance
  10. Test and wish for the best

This actually worked and did not even take too much time. Actually, really cool when thinking about this and imagining I would have had a physical server instead…

Amazon AWS — No Comments
19
Nov 11

My new best AWS feature, CloudFormation

I just realized AWS has a feature called the CloudFormation which allows users to script their technology stack in a convenient and easily understood JSON formatted text files which can then be used to deploy the stack over and over again, always the same way. Fantastic! This eases a the burden of managing a bunch of customized AMIs or other ways of having some custom features introduced to the AMIs. I wonder how I did not notice this feature before. It even has a tab in the AWS Management Console. There are also some sample templates which for example install Drupal or a basic Ruby Hello World example.

As a test, I ran the Drupal installation script and I have to say this was by far the easiest Drupal installation I have ever done. From start to finish in 5 minutes where most of it was just waiting for the deploy to finish. Absolutely great! Minor thing might be to remember that the security keys are not available in all the Regions, at least not in US East (Virginia) my keys were not available which caused the stack deployment to fail without any good reason except key was not found… I was of course first thinking of a typo in the key name. The other thing is that the user must know the instance type name, such as t1.micro while a drop down menu would be great.

There is also a possibility to modify an existing stack which is actually a relatively new feature. This makes it even more usable. It would be interesting to see if I could do a stack for a simple Aegir installation as lately that’s the platform I have been installing the most and doing the manual installation has become kind of boring. CloudFormation would help lot with that!

Amazon AWS — No Comments
16
May 11

Amazon Web Services used in Sony PSN attack

Today’s breaking news have been Bloomberg’s story about the Sony PSN attack been conducted by using Amazon Web Services. I read the story and feel confused, like how on earth can the source of the servers be any kind of relevancy if they’ve been using a public cloud provider? Come on, Amazon can’t and really should not, follow what their customers do with their servers. This whole thing Bloomberg is writing about is like saying the bank was robbed by a Smith&Wesson and it was Smith&Wesson’s fault.

Of course, there will be a subpoena for getting all the information of the account used in managing the account and I guess they had to use some stolen credit card as well which is interesting. Also, the statement in the Bloomberg’s article about anyone anonymously going and getting an account in AWS is kind of not totally true. Maybe it can be managed somehow if using a stolen credit card, but it’s not an anonymous service as such. And how are you going to prevent that “flaw” in the system of the possibility using stolen cards and false identities? Scan your id and send that as well or visit them at AWS personally? Huh?

In the end of the article, there is a thought-provoking paragraph of “Rethinking the Cloud” because a cloud can be used also for malicious purposes. Yep. I’ll do think about this for a while…

Thinking…

Thinking…

…and it should not matter for the most parts. Say, the whole AWS would be used only for attacks and the service level would degrade and my IPs would be black listed, then I probably would switch to some other provider, but, right now, I am not worried the least bit. I have my application and the service level I need in a good and healthy balance.

Amazon AWS — No Comments
25
Jan 11

Working with Amazon Route 53

I wanted to get a fi-domain as I am building a site for our housing company. It’s very much a pro bono work, but interesting nevertheless. To be honest, this is the first time I have to register a fi-domain and man, it’s not as easy as getting a com or similar domain with DynDNS etc. You need to be a Finnish citizen to be allowed to get one for starters and made sure you are not violating any possible trademarks or even more, some real people with your domain name.

I would perhaps been ok if a DynDNS type of service would exists (well, now as I write this it probably does) in Finland, but the ones I came across were mostly just taking orders and not like dynamically updating their resources… but can’t of course be totally sure. Anyway, I decided to give Amazon Route 53 a go as it is new and I do appreciate the possibility to update the records on command line. Or well, I perhaps did not investigate really too much before signing up.

First I had to though register the fi-domain with Ficora and that took around a day to get the credentials on paper. Yes. On paper. The next step was to register the name and give them two (at this point fictious) name servers. Then I was on my way to Route 53. The first look at the Getting Started Guide is not very encouraging. Need to create some files which contain the access keys and the actual requests. Need to run a perl script to actually create the records. Good thing I bought my first Mac just a few months ago as with Windows this would have sucked.

So the first thing was to create the .aws-secret file which contains your AWS Secret Access Keys it looks something like this:

%awsSecretAccessKeys = (
“my-keys” => {
id => “JISEGIOJDFGSLSDKFG”,
key => “KSLDFSDFGSDFGSasdfsdASFDSDF”,
},
);

And it really needs to be named .aws-secret and have only read permissions as the dnscurl.pl checks this.

Then create the zone you have registered:

<CreateHostedZoneRequest xmlns=”https://route53.amazonaws.com/doc/2010-10-01/”>
<Name>YOURDOMAIN.fi.</Name>
<CallerReference>SOMETHINGRANDOMHERE</CallerReference>
<HostedZoneConfig>
<Comment>Creating first zone</Comment>
</HostedZoneConfig>
</CreateHostedZoneRequest>

Then download dnscurl.pl from the AWS developer tools and run it with these parameters:

dnscurl.pl –keyname my-keys — -X POST -H “Content-Type: text/xml; charset=UTF-8″ –upload-file MyCreateRequest.xml https://route53.amazonaws.com/2010-10-01/hostedzone

You should get something like this in return:

<CreateHostedZoneResponse xmlns=”https://route53.amazonaws.com/doc/2010-10-01/”><HostedZone><Id>/hostedzone/34LJSKFSJGSDFKJ</Id><Name>YOURDOMAIN.fi.</Name><CallerReference>JIjasdmfasfw4af3233</CallerReference><Config><Comment>Creating first zone</Comment></Config></HostedZone><ChangeInfo><Id>/change/23ILKSFJDLSK</Id><Status>PENDING</Status><SubmittedAt>2011-01-24T20:48:47.715Z</SubmittedAt></ChangeInfo><DelegationSet><NameServers><NameServer>ns-1778.awsdns-30.co.uk</NameServer><NameServer>ns-372.awsdns-44.com</NameServer><NameServer>ns-1621.awsdns-38.org</NameServer><NameServer>ns-534.awsdns-04.net</NameServer></NameServers></DelegationSet></CreateHostedZoneResponse>

Here are the real name servers which I had to give to Ficora and it happily said them being ok, so fi-domain is well supported by AWS! Yey!

Then you can start adding records to your zone. First need to create the MyRecordsRequest.xml for the records which could look like this:

<?xml version=”1.0″ encoding=”UTF-8″?>
<ChangeResourceRecordSetsRequest xmlns=”https://route53.amazonaws.com/doc/2010-10-01/”>
<ChangeBatch>
<Comment>
Create A-record
</Comment>
<Changes>
<Change>
<Action>CREATE</Action>
<ResourceRecordSet>
<Name>www.yourdomain.fi.</Name>
<Type>A</Type>
<TTL>14400</TTL>
<ResourceRecords>
<ResourceRecord>
<Value>192.0.0.111</Value>
</ResourceRecord>
</ResourceRecords>
</ResourceRecordSet>
</Change>
</Changes>
</ChangeBatch>
</ChangeResourceRecordSetsRequest>

dnscurl.pl –keyname my-keys — -H “Content-Type: text/xml; charset=UTF-8″ -X POST –upload-file ./MyRecordsRequest.xml https://route53.amazonaws.com/2010-10-01/hostedzone/34LJSKFSJGSDFKJ/rrset

And you should get a response like this:
0.0%
<?xml version=”1.0″?>
<ChangeResourceRecordSetsResponse xmlns=”https://route53.amazonaws.com/doc/2010-10-01/”><ChangeInfo><Id>/change/C3FMNWCVL1YW40</Id><Status>PENDING</Status><SubmittedAt>2011-01-25T19:16:24.181Z</SubmittedAt></ChangeInfo></ChangeResourceRecordSetsResponse>

I got a few problems with “root is not authorized to perform: route53:ChangeResourceRecordSets on resource” because I did not have ./ in front of the MyRecordsRequest.xml, so remember to have it there.

Amazon AWS / Cloud Computing — 1 Comment
7
Oct 10

Testing t1.micro with loadimpact.com

Well hello there! It’s been a while, but I finally found some time to work with the sites and the latest of Amazon Web Services. Lately, AWS has introduced the tiny micro instances with a tempting price tag for small businesses with not too much of a need for high performance. For me, those do sound fantastic for testing purposes as I have been wanting to try running the two sites, this and vkaiser.com on a bit more robust architecture than the current one with just an EBS based AMI and the videos in S3.

I run the typical LAMP stack on one AMI, thus the idea was first to boot up one micro instance and have a look. Well, I chose to go with some old image I had created way long time ago. It also had a LAMP stack installed, but of course it was kind of outdated and the vkaiser.com did not look too good (well, does it now either…), so I figured I could rsync the html folder of the Drupal installation and I did eventually get the rsync with public key working. Then I realized that the db wasn’t really up to date either and the drupal modules would not of course work, so how about connecting to the database on the current “production” which would kind of resemble the hopefully future setup too as running a separate db server (and slave) would just be the way to go at least with Drupal.

Settings in Drupal for remote database connections are really simple. First edit the MySQL configuration (/etc/my.cnf) to have

Bind-address=database_ip

And if you have skip networking defined, comment that out.

Then add remote access permissions to the database for a db user

GRANT ALL ON *.* TO ‘dbuser’@'remote_ip’ IDENTIFIED BY ‘password’;

And modify the settings.php on the remote application server to point to the database server:

$db_url = ‘mysql://dbuser:password@database_ip/database_name’;

Then you can test the connection to the database. At least I got that working, though I was first editing the wrong settings.php file which of course did not prove to be very useful in getting the db connection working.

The real deal was though to see how the t1.micro performs under stress. I browsed a while for some tools with how to do the test, but then I found loadimpact.com which simulates really well concurrent users from 0-50 for free! With some euros, you can get up to 5000 users and customized tests and what not. I like the service, though it went down just as I got my t1.micro tested. The average response time was around 1.5 seconds for the vkaiser.com frontpage and it did not show any real implications of getting slower, thus I should put more load on the micro if I coughed up some cash. I next went on and tested my good old small instance and got about the same results

This wasn’t too scientific, though the results are encouraging. I mean, 50 concurrent users is about 49 more than this site usually has and the micro worked well, so I am planning to make a switch soon… More about that later!

← Older Entries