Filed under web

Fixing holes in EC2 reliability

We are in the era of clouds, and at the moment AWS is the Zeus among public clouds. With its scalable and flexible architecture, cheap rates, secure PCI compliant environment, wide array of loosely coupled services and boasting of 99.95% availability, they may deserve the crown. However they are not without holes and few days ago I got the chance to taste it firsthand. This post is about few measures that you should (and I mean this with capital SHOULD) take before moving your production servers to AWS.

To start with, I had been using Slicehost and Linode as VPS providers for couple of years while tinkering with AWS. After a trial run of few months I was satisfied that everything is working as it should be and moved to AWS for real. But the mistake I’ve done and AWS didn’t bother to mention anywhere easily findable is to couple Elastic Block Storage (ESB) with all instance stores. And this is something easy to overlook when you are coming from a regular VPS provider because ephemeral Instance store is the most counterpart similar device to a slice and you may expect the same behaviour throughout.

So back to the story, everything was running fine until AWS had scheduled a maintenance rebooting of the instance two weeks ago. Nothing much to worry right ? But it turns out that the instance didn’t reboot and there was very little possible to do from the AWS web console. Unlike in regular VPS slices, AWS doesn’t come with a back-door SSH console and it turns out even the staff can do pretty much little regarding an instance store. The only solution they could give me was to reboot the instance few times and if it doesn’t work out…well, they are sorry and it’s a lost cause.

I earlier mentioned the mistake I’ve made. But what I got right was to have several layers of backups including database replication slaves. So backups were running pretty much as expected and there wasn’t any lasting damage done.  And only when you are in trouble that you are glad of the time well spent on emergency procedures.

So rest of the story is very little. I removed the crashed instance, restarted a new one from the custom AMI we had and copied data over from DB slaves. But this scenario could have gone vastly wrong if there wasn’t a redundancy setup and for some unfortunate bootstrapping startup it could have reduced all their hard work to crisp.

I know servers should be up running and having them down is not heroic. But there are few points you should have in place before moving your production servers to AWS.

  1. Have a proper backup procedure in place. Better if replication slaves are in some other server vendor or in another AWS region and have a monitor setup to make sure replication process is working properly. Also it’s better to have several layers of backups running so you will have point-in-time recoverable database copy as well as one day old, week old, month old.etc data copies in worst to worst case scenarios.
  2. Use Elastic Block Storage (EBS) – They are the external USB drives of AWS. Couple one or more EBS with your instance store  and use them to store any data you think is valuable. If your instance die, you can just decouple the block and reattach to another fresh instance and run without a hitch.
  3. Have a custom bare-bone AMI with just the OS and may be couple of basic services. Also have an AMI with fully ready-to-launch setup. This way you can make another production ready instance in minimal time as well as have an option in a worst case scenario where the full ready made AMI doesn’t work. Finally, test all your AMIs to make sure that they are working properly.
  4. Have snapshots from your EBS devices in scheduled intervals.
  5. Use these not so easy to find AWS architectural guidelines in designing your platform.

So as I mentioned it’s not about heroics, but making sure your service not getting reduced to ashes because of some stupid server glitch. As someone wise had noted, better be ready than sorry!

Update:

There is another set of sound suggestions made in comment #4 by kordless for any cloud deployment. If you are into heavy scaling they may be particularly useful.

My best 7 free JS modal boxes

I have been working on a new iteration of HOT (follow @hotelotravel for more info) for last few weeks and thought of changing the existing JQuery UI Dialog box for something bit fancy and solid (on other hand I may have just wanted to get a break from usual PHP stuff and to play with JQuery a bit after some time). I did have some popular JS modal box names such as Lightbox, Facebox and Thickbox that I wanted to test and found some few new names on the way.Certainly there will be many more modal boxes out there that I’ve missed and not to mention my requirement will be different from yours, but here is the gist of each modal box in my opinion of those I’ve tested so it may help someone to pick the right one at the right moment.

JQuery UI Dialog

JQUery UI in Hotelotravel

JQUery UI in Hotelotravel

This is the dialog box that I’ve used in most cases and of course it’s great. Few years back when I started working with it I noticed few issues when closing the dialog and such but by now they have all been fixed. Also it’s continuously maintained by JQuery community so you can be sure it is solid. What I like mostly about it is its simplicity as well as customization power through various callbacks when you need more action (you can define what to do when a drag starts, drag stops, box shows up, box closes. etc) through various option settings.

This is all you have to do to get a simple dialog box if you have a div with the id of “myDialog”.

$("div#myDialog").dialog();

Another perk of this modal box is its file size, which is quite small (about 10KB and minimized version is about 6KB) and when doing a complex site with numerous CSS and JS scripts, size of each file becomes crucial to maintain a small load size to reduce the load time as well as save server bandwidth. Only seemingly downside of this box is that it doesn’t come with any fancy preloaded stuff (themes, effects, preload-images.etc) but for someone interested (and with a bit of JS and CSS knowledge) can customize them.

LightBox

Light box

Light box

This is focused mainly on presenting pictures and does a good job at it. If you are interested in creating something like a picture gallery without touching much JS, this could be the ideal JQuery plugin for you. Also it has a relatively low size with a size around 19KB and packed version is about 6KB. But since I was looking for something more with raw customization power, this wasn’t the choice for me.

FaceBox

Facebox

Facebox

Another popular choice for a modal boxes and it deserves the name. It has a very small file size and a simple code. It also comes with a default theme and can be a convenient choice for hasty tasks or people :P But the downside I noticed is that it gives very small customizing power to the user through JQuery code (which is the case with Light box also btw).

It’s simple to a fault and you just have to name the class name of the link you are going to pop the box as “facebox”. It could have had few more options such as to define the basepath of the project as I couldn’t find a way to define it for pre-loading images without hacking the code nor a way to give width and height manually or pass callbacks. Also this project seems to have been abandoned for a while now and if you are considering adapting this box for your whole site check it thoroughly.

ThickBox

ThickBox 3.1

ThickBox 3.1

ThickBox is really a cool JS box. It’s simplicity and extremely small file size makes it very adorable. This modal box gives some customizing power but still focuses mainly on simplicity and link naming as “thickbox” which is its magic word. However as mentioned earlier this has a better customizing power through JS than FaceBox or LightBox so it’s more flexible. With some hacking you can also give your own callbacks and options as you like.

LightWindow

LightWindow

LightWindow

This is an all purpose, very fancy looking modal box done using script.aculo.us and prototype libraries. It can host all kind of media types and even flash clips which is really impressive. But the obvious downside is its huge file size of about 60KB which is a huge amount when considering this will be just a small part of Hotelotravel.com and for general use it’s not tolerable IMHO. It is not compressed or packed by default so you can manually minimize it using something like YUI compresser to bring it to somewhere around 30KB but even then it’s too large for me. But this is ideal for a site that has tons of ajax stuff and in need of a very customizable modal box with lot of options and callbacks that can be used throughout the site.

SimpleModal

SimpleModal

SimpleModal

This is the smallest JQuery modal box I’ve seen and if you need to customize your modal box to the extreme I’d suggest this. Downside is that you will have to write a lot to get something done through this modal box but extreme small size complements that.

NyroModal

NyroModal

NyroModal

This is also a very good looking JQuery based modal box with a reasonable file size(about 14KB for packed version) and gives considerable customizing power to the user. Also it comes with a packed theme and all that so you can use it easily without much coding which is a plus. In fact, I had some trouble deciding whether to use this one or JQuery UI for my task but finally settled on using JQuery UI because my familiarity with it and community backing. So I guess in my case JQuery UI is the rightful winner :)
[digg=http://digg.com/programming/Best_7_free_JS_model_boxes]

Tagged , ,

Drupal with Dreamweaver

I had to migrate and setup the whole workspace at my old desktop machine last week after the breakdown of my HP notebook. So while setting it up I thought this little piece of trick could help someone who is fond of Dreamweaver and looking for an IDE to code Drupal.

As a side note, one could accuse me of promoting unethical software and in fact I don’t refute it (even though it is not my intention). I also know there are many great open source editors for coding PHP like Eclipse-PDT and even Gedit which could be transformed to a very helpful IDE. But on other hand I’m kind of addicted to DW after long years of working with it and if someone who already has DW looking for a way to use it for coding Drupal this could be helpful.

The most frustrating thing when coding Drupal modules or themes with DW is that it doesn’t recognize it as a PHP script and doesn’t give any validation or auto completion features like it usually does for php scripts. To fix this there’s little configuration to be done.

First find the installed directory of DW (if it’s Windows it most probably in ~/Program Files or if it’s Linux+wine it should be in your virtual windows environment) and go to Configuration->DocumentTypes. There should be a xml file called MMDocumentTypes that holds configurations regarding which language should be used for a given file format.

Find the line that says,
‘<documenttype id=”PHP_MySQL” servermodel=”PHP MySQL”….’
and depending on weather you are using windows or mac, append ‘,module,install,theme,inc’ to existing winfileextension or macfileextension values.

So for windows it should look like this.

<documenttype id=”PHP_MySQL” servermodel=”PHP MySQL” internaltype=”Dynamic” winfileextension=”php,php3,php4,php5,module,install,theme,inc” />

Now restart DW and open your module or theme file. Ta da!..it should now work as a normal php script.

Hope this will be helpful to someone looking for a way to convert Dreamweaver to a more Drupal friendly place.

Tagged , ,

PHP + Large files

I was working on the project Hotelotravel for last few months and as usual in many cases it involved working with large database files because when you consider all hotels, locations and images all over the world it means a lot. But if we want to do large file uploads or database updates with PHP there are few configurations to be done to default settings and I’m putting this as a note to myself (I’m always keep forgetting this) as well as to any one who may find this useful like when importing a large backup file through phpMyAdmin.

In your php.ini check for these settings and change them as you need.

  • post_max_size (The maximum size of post data you can send in one submission)
  • upload_max_filesize (Maximum size of file that can be uploaded)
  • memory_limit (Maximum memory limit that can be allocated for a script execution)
  • max_execution_time (Maximum time limit for a script execution)

As a side note, if you trying to import large files (backups.etc) through phpMyAdmin and it refuses, you may need to edit config.inc.php file and change these settings to 0 which means no limit.

  • $cfg[‘ExecTimeLimit’]
  • $cfg[‘MemoryLimit’]

As a final note, these settings are there for a purpose. So my advice is change them in whatever manner  you want in a development environment but be very careful when setting them in a production environment because an endless execution of a script can cause your servers to waste bandwidth and even crash.  So I guess this is my disclaimer ;)

Tagged ,