5

I am trying to work on a standard configuration for a set of EC2 instances running ubuntu 12.04. These servers are going to be primarily web servers for a Ruby on Rails application. When you configure a new large instance, you are given a primary of 8GB and then ephemeral storage of 400 GB that is mounted to /mnt.

It seems logical to me to move some directories that have a potential for growth off to the /mnt directory, I was specifically thinking of /var/www and /var/log.

My question is two-fold:

  1. Is this a good idea or are there pitfalls that I cannot see?

  2. If this is a good idea, how should I go about configuring this. I do have the ability to configure new instances and down our old instances. My concern is over long term configuration, I am not necessarily concerned about downtime.

I am a developer with some experience in devops, but mounting drives is something I have not faced before, so explicit directions would be greatly appreciated.

user9517
  • 115,471
  • 20
  • 215
  • 297

3 Answers3

1

I don't know what you keep in /var/www, but the contents on my servers definitely can't be described as "ephemeral", which I understand to mean "could go away any time, and I don't much mind". If that's not what amazon means by "ephemeral", I apologise.

As for /var/log, if you don't care about the log data at all, don't collect it in the first place.

If you do care about it, but can't afford to hold it in primary storage very long, then this isn't a mounting issue so much as a log management problem. I'd be inclined to use logrotate, if it's available to you, and configure it to move old logs out to /mnt every week or so. That way, the old logs are there (until the ephemeral storage goes away), but the current log is safe on primary storage.

A logrotate recipe like

/var/log/foo {
    olddir /mnt
    compress
    weekly
    rotate 1000
    postrotate
    /etc/rc.d/init.d/fooservice restart
    endscript
}

might be of use, at least as a template.

MadHatter
  • 79,770
  • 20
  • 184
  • 232
  • Thanks, the term "ephemeral" seems to be what people call the extra drive on a ec2 instance, it was not a reference to the data. The data in /var/www can be pulled at any time. I don't care about the logs after a certain amount of time, but I do care about them initially. I already have log rotation configured. Thanks I had not considered moving the rotated logs on a cron... that hold promise and reduces complexity, which I like. – Geoff Lanotte Dec 13 '12 at 14:46
0

What you are planning is similar to what I do for all of my instances but I also include /var/lib/mysql and most of the /etc/{apache2,mysql,php} directories as well. I do that so I never lose my configurations when an instance terminates for whatever reason.

  1. It is an excellent idea in that you will never lose your data. As I mentioned, if the instance goes down you will retain that information and simply need to mount it to a new instance.

  2. The easiest way to do it is to simply move those directories to the EBS volume and then create symlinks to them at their original location.

daemonofchaos
  • 1,211
  • 1
  • 8
  • 10
0

If the data (on the filesystem) that the application accumulates is valuable then ignore the 400GB complimentary storage and mount an EBS volume. Otherwise...

The answers depend (a) on your application, and (b) "spot", or "reserved" instance, but

1) Yes it's a good idea because, obviously, you're less likely to run out of disc space. Whether that is likely depends what your rails app does, but just for separation and clearly defining what's "yours" and "mine" I tend to put all "my" stuff on /mnt. There is no need to mount it manually. That's done just cd mnt and off you go. There's a little fiddling with permissions which you won't have any problem overcoming.

But of course this space is "ephemeral" so it dies when the server does, which leads us to my second qualification...

2) "spot" or "reserved" instance?

If you have a spot instance, then you have to accept that there is a chance, remote as that might be, your maximum price will be outbid and the server will be unexpectedly terminated. That will pose a problem if the data on the server has value.

But! if you're paying the premium for a "reserved" instance, which (I've not read all the fine print disclaimer ;-/) means the threat of your server being unexpectedly terminated, and the application's accumulation of data, is very substantially reduced. You might be able to schedule a periodic backup (to S3?) and sleep very easy without the added expense of an EBS.

If long term, as stated, minimal downtime (and risk) is the goal. So you'd rather pay a little bit more than muck around saving pennies, then ignore /mnt and get very familiar with how to create and mount an EBS volume. Put all your stuff there. That way you can reboot the server without loosing sleep. That stuff will not disappear and it will not "take a while" to get things back to where they were before whatever disaster occurred to require cycling server instances.

John Mee
  • 2,548
  • 1
  • 24
  • 27