When it comes time to horizontally scale up your application with multiple server instances on AWS you generally have three choices: DNS round-robin (simply assigning multiple A names to a domain), using Amazon Elastic Load Balancer, or using one or more HAProxy‘s on EC2. The Robin-robin approach, while easiest, is not good since DNS will always forward round-robin to an IP even to a dead or overloaded EC2 instance, hence, a real HTTP load balancer is needed.
Amazon ELB is pretty awesome as it’s inherently fault tolerant and highly available. You never have to worry about scaling it up like regular EC2 instances. It just works, and it’s relatively cheap. But it also has a few drawbacks including lacking complex routing algorithms, no logging outside of Cloudwatch, and can’t gracefully handle great spikes in traffic like a Slashdot or a consumer flash sale without “prewarming” the load balancer (an act that requires a premium support agreement and contact with Amazon ahead of time).
HAProxy, the premiere open-source load-balancer contains a swiss army knife of functionality, including tons of routing algorithms, that addresses many of the limitation of Amazon ELB at the cost of a lot more manual setup, complexity, and cost (since it’s hosted directly on EC2 instance(s). This article is a great discussion on the merits of both and worth a read if you’re like to know which to go with.
But wait there’s more! What if you could have the best of both worlds? The following article discusses pairing both ELC and HAproxy together.
Lastly, if you don’t want to get into the complexity that is HAProxy, you can always try load balancing through Nginx. There’s less fine-grained controls but it’s totally useable as an efficient load balancer.
Posted on September 13th, 2012 in unix | No Comments »
I just discovered htop a more colorful version of top. It loads faster and visually shows you how each CPU core is doing. Love it.
To install on the Mac
To install on Amazon EC2
sudo rpm -Uvh htop-0.9-1.el5.rf.x86_64.rpm
sudo rpm -Uvh htop-0.9-1.el5.rf.i386.rpm
How to install htop in RHEL Centos or Fedora
Comparison between htop and top
If you have a lot of files (images, pdfs, etc) you need to view on a remote server but don’t desire to `rsync` the whole thing over to your local file system, here’s a way to mount that folder to your local Mac for on-demand browsing:
sudo port install sshfs
sshfs user@server:path remote
Note that could take awhile to load folders with hundreds of files. Otherwise Work great. Thanks to this link and this link.
I’ve yet to write my “Wonders of Tmux” entry but always have small tidbits to give in the meantime.
Sometimes sharing your whole desktop via Skype, Teamviewer, or some other screen-sharing system is overkill, at the very least harder to read and control remotely. Sharing a terminal session between two (or more) users is great for pair programming (especially if both users are vi or emacs users) or for one user to educate, walk-through, or troubleshoot something with another remote user – also great for showing how Tmux works! One can even split the screen in half and be SSH’d into multiple machines together!
There’s three ways that users can share a terminal session together. The first way requires a little more work from the person sharing their tmux session, the second and third require either sudo rights or being able to su to the other user’s account.
Similar to SSH, when you create a tmux session, it creates a temporary socket in the /tmp directory with the tmux user owning the file. This makes it unaccessible by other users.
Allow another user access to your tmux session:
# specify the name of your tmux socket with -S when creating it
tmux -S /tmp/pair
# chmod to allow other users to access it
chmod 777 /tmp/pair
# now the other user can connect with
tmux -S /tmp/pair attach
Sudo your way into another users tmux session
# Have the user create a tmux session
# ls -al /tmp to see which tmux session is owned by the user you want to share sessions with then
# in the following example tmux-502 is the tmux socket folder of the example user
sudo tmux -S tmux-502/delfault attach
su your way into the session
su username # need user's password or sudo
The newest version of Tmux (1.4, released Dec 2010) has a bunch of fixes and subtle workflow enhancements. Unfortunately Yum still only has 1.3.
You can compile it from source here. I did and got the following errors:
After checking around, I discovered I was missing these two packages:
yum install libevent-devel
yum install ncurses-devel ncurses
Recompile and you should be golden.
Addendum: on a fresh Ubuntu install it’s:
apt-get install libevent-dev
apt-get install libncurses5-dev libncursesw5-dev