Kemp Load Master 1500 Review
Posted by Sam
A while back I reviewed the Barracuda 340 load balancer. The review wasn't pretty, because frankly the experience was horrible. I was so disgusted that I shipped that box back pretty quickly and went with the other contender. The other contender was Kemp's Load Master 1500. Several people have written me to find out what my experience with the Kemp load balancer has been so I thought it was about time that I put my thoughts down on paper ... so to speak.
I've been using the Kemp in production for over three months. Because of the amount of sites that run behind the Load Master it's pretty difficult to tell exactly how much traffic passes through it. A quick look revealed that it easily handled over 2.1 million hits a day around Christmas last year. And it did this without breaking a sweat so I'm confident that it can handle much more than that. I have yet to experience any of the sort of strange issues that I experienced with the Barracuda and overall I have much higher degree of confidence in the Kemp solution.
The interface definitely doesn't do this machine justice. It could stand to be completely revamped and for some strange reason you can't always put a name on your virtual servers. Well you can name it, but the name doesn't stick. This is more of an annoyance than a real problem and just goes to show that their web interface could use some love. They have a very solid product, but I'd definitely love to see some more flexibility. Like being to add multiple users or allowing the admin user to be named something besides 'bal', which took me forever to get used to. How about something more normal like admin or root or something.
The only real complaint I have about the Load Master is Kemp using a license key. It's a physical box that I'm buying and having to enter in a license key for a physical piece of hardware never sits well with me. And to top it off their documentation isn't at all clear that the box requires a permanent license key or it will shutdown. I failed to install the permanent license key because I thought it was for the SSL acceleration and one day I wake up to phone calls saying all the sites are down. If you are going to enforce a license key (which I think is stupid on a physical product but whatever) then you need to have it fail better. I actually had the license key but the Load Master reverted back to it's pre-configured state and was completely unavailable remotely. This forced me to drive to the data center, through piles of snow, to figure out why the load balancer died. A much more sensible way of handling this would be to not allow you to make any changes next time you log into the admin tool. Or you could just make the documentation clear and explain exactly how important that permanent key is.
The Kemp Load Master 1500 is a very solid performer and other than the extremely irritating way they handle licensing I've been quite happy with it to date. At just under $2,500 is cheaper than the Barracuda with a more responsive interface and much more reliable track record. The Kemp wins hands down and is a great deal for the price. I was really looking forward to the IPS system in the Barracuda, but first and foremost the load balancing functions need to work.
Tags: loadbalancer
New Staging Environment in LiteSpeed
Posted by Sam
In version 3.3.4 of LiteSpeed they have finally added a staging environment for Ruby on Rails. This is a big deal for me because every site I create gets a staging environment. In a previous post I blogged about setting up custom environments for Rails in LiteSpeed, but with the new staging environment the code changes in that blog are no longer required. I'm very happy about this and it's nice to see my only real complaint with LiteSpeed fixed. Although now that they've added the staging option maybe they can expose a web service to add new web sites. It would be great for scripting the setup of new sites!
Tags: litespeed rubyonrails
Limiting Bandwidth for Solaris Zones
Posted by Sam
I love Solaris. I mean I really love it. Using zones and ZFS is like a breath of fresh air. If I had one complaint it's that Solaris is sometimes over-documented. I know that seems strange at first, but case in point is trying to setup IPQoS to simply limit the bandwidth on a particular zone. This week I decided that I need to take some time and figure out how to limit a zone to only using 1mb of bandwidth. So I started by looking around on the web and there was nothing. It was a ghost town. Some people were talking about, but nobody had a simple example of how to implement it. In the Linux world there would be a million how-tos. More than half of which are out of date and of questionable quality, but they are out there none the less.
Since I couldn't get any love from the internet at large I decided to look at the documentation that Sun provides. Sun's documentation is great, but often times it's overkill. Or they expect that you've been to some training class and already have a pretty decent understanding of what you are doing. The documentation for IPQoS was no different. It came in at 72 pages when printed and was not at all helpful. Ugh! Finally, I put together a solution and I thought I would share it here. Hopefully it will help others as well.
In Solaris 10 update 4 there are three example files for QoS in the /etc/inet directory so I created a new file there. Here are the contents of the file.
fmt_version 1.0
The important parts of the file are committed_rate, committed_burst and peak_burst. Basically this tells IPQoS that it should start dropping packets whenever the bandwidth exceeds 1 megabit (1,048,576 bits). In the example above I have a class named web1 and a filter that's also named web1 that points to the class web1. These can be named anything you like, but make sure that filter > class has the same name as class > name.
action {
module ipgpc
name ipgpc.classify
params {
global_stats TRUE
}
class {
name web1
next_action cap
enable_stats FALSE
}
filter {
name web1
daddr 10.1.1.5
class web1
}
}
action {
module tokenmt
name cap
params {
committed_rate 1048576
committed_burst 1048576
peak_burst 1048576
red_action_name drop
green_action_name continue
yellow_action_name continue
global_stats TRUE
}
}
After you create the file above you can active it by using ipqosconf like so:
bash-3.00# ipqosconf -a ipqos.conf
Be sure to substitute the name of the file above for ipqos.conf. Assuming you don't have any errors you should be good to go!
Easy and Fast Solaris Zone Creation
Posted by Sam
Want to automate the creation of Solaris zones or just want to create zones faster? Using Zone Manager you can save yourself several steps and even some time. As I'll show below you can easily create a brand new zone in less than two minutes with one command. Grab Zone Manager and stick it in your path. I put mine in /usr/sbin. Here's an example:
bash-3.00# time zonemgr -a add \
> -n web1 \
> -z /opt/zones \
> -P secret \
> -I "10.100.1.1|bge0|255.255.255.0|web1" \
> -C /etc/resolv.conf \
> -C /etc/nsswitch.conf
Checking to see if the zone IP address (10.100.1.1) is already in use...IP is available.
Preparing to install zone < web1 >.
Creating list of files to copy from the global zone.
Copying <297> files to the zone.
Initializing zone product registry.
Determining zone package initialization order.
Preparing to initialize <205> packages on the zone.
Initialized <205> packages on zone.
Zone < web1 > is initialized.
The file contains a log of the zone installation.
Creating the sysidcfg file for automated zone configuration.
Copying (/etc/resolv.conf) from the global zone to (/etc/resolv.conf) in the non-global zone.
Copying (/etc/nsswitch.conf) from the global zone to (/etc/nsswitch.conf) in the non-global zone.
Copy completed.
Booting zone for the first time.
Waiting for first boot tasks to complete.
Updating netmask information.
Copying (/etc/nsswitch.conf) from the global zone to (/etc/nsswitch.conf) in the non-global zone.
Copy completed.
Updating /etc/inet/hosts of the global zone with the webshell IP information.
Zone web1 is ready.
real 1m52.449s
user 0m12.063s
sys 0m16.275s
What we did
Here's what we did, line by line.
- Add the zone
- Name the zone web1
- Create the zone in /opt/zones/web1
- Set the password to secret
- Set the IP address, ethernet adaptor, subnet mask and hostname
- Copy the resolv.conf file from the global zone
- Copy the nsswitch.conf file from the global zone
That's it! With one command and in less than two minutes you have a brand new, fully functional zone. For more information on Zone Manager check out the docs. You can also subscribe to the Zone Manager blog. To see how much time and how many steps that saves check out this blog. Happy Zoning!
Easy Ruby on Rails Deployments
Posted by Sam
A couple of days ago a large web hosting company named DreamHost posted a blog about how Ruby on Rails could be improved. Some of what they are wrestling with I also wrestled with when we first started deploying Rails applications. But honestly I figured out how to overcome these problems several years ago so I'm wondering what their problem is. Just to put my money where my mouth is I thought I would touch on their points one by one.
Ruby on Rails needs to be a helluva lot faster. With a proper accelerator it’s nicely usable but without one it’s painful. Ruby itself is a big part of the problem so this one may come down to just simplifying the management of the accelerator technologies, unfortunately. Mongrel seems like a big step in the right direction, even though it’s not Rails-specific. I hope the Rails core developers will be cooperating a lot more closely with Mongrel developers in the future.
Ok, where to begin on this. First of all let me say for the record that I don't understand why everybody insists on saying Rails is soooo slow. Judging by all the Rails is slow posts all over the net you would think it takes days to load a page, yet these folks handled it just fine. Any technology can fold under traffic and just about any technology if used correctly can scale. Is Ruby the fastest language? No, definitely not. Neither is PHP. If you really need speed you need to go with Java or C and you need to code it correctly. A fast language alone is no guarantee of performance. And because PHP has to startup every time a request comes in it can easily be much slower than Rails.
As for Mongrel being a big step in the right direction I couldn't disagree more strongly. Mongrel is a nightmare for hosting more than one or two sites. Having to setup clusters that don't grow and shrink based on the load is ridiculous. Especially for a shared hosting environment. I can't believe people have latched on to this so much and if Zed is so brilliant why can't he think of a MUCH better way to handle this. LiteSpeed handles this a million times better. Basically just tell LiteSpeed the maximum number of Rails instances and it handles bringing them up and down to handle the load. Oh yeah and LiteSpeed is much faster than Apache so all the way around it's a better setup.
Ruby on Rails needs to more or less work in ANY environment. You can’t just expect your users to set up their servers any which way. There are millions of established systems that cannot simply integrate any bleeding edge technology you think is better this week. If you continue to keep this attitude you are surely shooting yourselves in both feet.
I'm guessing by any environment what they are really upset about is that it doesn't work in their environment. Guess what? To support a new technology you often have to make changes. When Java came on the scene you had to add additional application servers, which is far more of a pain than what Rails asks of you. And it does work in pretty much environment. Your real complaint is that it doesn't work in your broken environment. This is really your problem. There are plenty of places where Rails will work just fine as David points out in his blog.
You need to maintain backwards compatibility better. Admittedly this is the area where PHP has historically done very poorly, but that’s no reason to not one-up them. Also, Rails is admittedly very young as a development platform and you guys have gotten a LOT of attention very early on. Still, with big hype comes big responsibility. You need to keep the momentum going now.
This is just dumb. Rails is an incredibly new framework and they have great backwards compatibility. In fact they have full backwards compatibility. If your site doesn't work with the latest version of Rails just stick with the one you are using. You can have hundreds of different versions of Rails installed at the same time and the app can use whatever version is wishes. This is full backwards compatibility.
Officially support shared hosting environments. The feeling I get from the Rails community is that Rails is being pushed as some sort of high-end application system and that makes it ok to ignore the vast majority of user web environments. You simply cannot ignore the shared hosting users. In my opinion, the one thing the PHP people did that got them to where they are today is to embrace shared hosting and work hard to make their software work well within it. That means it has to be very lightweight (it may be too late for that in Rails already!), and it has to ‘plug in’ to a wide variety of operating environments with minimal fuss and hassle. Compatibility work like that is not glamorous, exciting, or fun, but it’s gotta be done.
The reason you get the feeling that Rails is some sort of high-end application system is because to some extent you are right. You absolutely can't ignore shared hosting? Really? Seems to have worked OK for Java. Why doesn't DreamHost support Java? Let me guess, because it's too heavy weight? Rails is a full fledged web development framework. Just like Java, it's always in memory so that it can take advantage of being a long running process. This is less than ideal for hosting companies that are trying to sell $5 hosting packages, but for building real web applications this is almost a necessity. I'd say not only CAN they ignore shared hosting companies but they quite successfully are ignore you. Rails doesn't lend itself as well to shared hosting as well as PHP does. It's up to the shared hosting companies to figure that out. That's what YOUR business is. Oh and several hosting companies can and have figured it out so your public rant is really kind of embarrassing for DreamHost.
Tags: rubyonrails litespeed