System Administration Archive

Scale out vs Scale up

There is no doubt that cloud hosting is taking its place and it offers some advantages for managing your deployments but, is it the right choice to take?

This dissertation comes from the recent new that StackOverflow uses a scale-up methodology to handle its services. And that’s a quite strange thing to see nowadays. Every single web service tends to use Scale-out and that’s the same for our company services, OpenHost, where we have been migrating from metal-servers to the cloud “panacea”.

Our main aim to move to cloud servers was to reduce our costs when our infrastructure is not having a lot of load, which always use to be at nights, and to quickly replace malfunctioning servers with new servers by provisioning them with puppet.

Just to clarify the terms, below I will describe both:

  • Scale-up: it is as simple as adding more computational power and RAM to your server, by buying a more expensive and robust server.
  • Scale-out: Refers to adding more servers with less processors and RAM.

There are common pros and cons for scale-up and scale-out which are:

  • Scale-up: they are less challenging to implement, and given that they can use all the power of the “metal” you will retrieve far better performance from the same machine in cloud. As a counterpart, using metal tends to be a risky business due to greater risk of hardware failure that causes bigger outages (yes we have learned this by heart).
  • Scale-out: as the opposite solution, using cloud based solutions tends to be easier to run fault-tolerance and easy to upgrade, but it will have a bigger footprint which raises some doubts about scale-up being harder to implement.

Scale out is usually cheaper overall and can literally scale theoretically infinitely (although we know that there are usually limits imposed by software or the environment’s infrastructure).

Our experience says that you will need more servers due to the fact that those VMs will have far less performance against metal-ones, but they have helped us to autoscale when our infrastructure had a huge demand. And we have mitigated a lot of outages caused by server failures.

A good resource to read is the Scalability Rules: 50 Principles for Scaling Web Sites which explains in a good way how to handle with this problem. But again, it’s quite weird nowadays that services like StackOverflow uses the scale-up technique, but they have probed that this have been worked better than scale-out for them.Take a look at how the StackOverflow was back in January 2014.

Solving caching issues with Vagrant on vboxsf

Since some months I’ve been working with Vagrant as a tool for provisioning my production-like environment to develop Opennemas. Vagrant is a really powerful tool for automating the creation of environment that mimic your production stack without having to deal with configuration files.

In fact this task, automatic provisioning machines, was one of the most important tasks in order to reduce our technical debt. But anyway, let’s move to the topic of this article.

We use Ubuntu OS as a guest VM provisioned by Vagrant+Virtualbox and we share our project code with the guest machine through vboxsf. Inside that machine, among the rest of the stack, it’s running Nginx (but this issue will be present regardless the web server you are running).

Get better performance and life from your SSD in Linux-based systems

OCZ Vertex 4

Recently I acquired an OCZ Vertex 4 SSD as my old hard drive was about to die as SMART were reporting. Definitely I would suggest you to go for a SSD as this upgrade will be the most significant and noticeable upgrade you can do for you computer.

Moving on. In this article I will write down some tips/rules for get the best performance out of your Linux-based system while giving some explanations about them.

Remove grub from MBR under Mac OS X


OK, you messed it up, you’ve installed Ubuntu on your Mac running a dual boot with OSX, and accidentally installed the bootloader to the MBR.  Well this will render your system useless as Mac’s use EFI and GPTs, rendering MBRs rather useless, outside of its MBR emulation mode that is.

The proper location for installing the GRUB locader in this EFI-based systems has to be on your first Ubuntu partition, not in the whole disk’s MBR segment.

If you try to install GRUB again in the proper location, that’ll will leave another icon of Tux just sitting there in your rEFIt menu.  Its a little annoying in my opinion so lets get rid of it.

Page 1 of 6