Tag: ec2

When Just IOPS Aren’t Enough – Optimal EBS Bandwidth Calculation

adminComputers

The current EBS features in Amazon EC2 environment offers really good performance and the marketing material and documentation boosts how different EBS types give IOPS, but a lesser talked thing is the bandwidth which EBS can offer. Traditional SATA attached magnetic hard disks can usually provide speeds from 40-150 MiB/s but really low amount of IOPS – something between 50-150 depending on rotation speed. With the Provisioned and GP2 EBS volume types it’s easy to focus on just getting enough IOPS but it’s important not to forget how much bandwidth the instance can get from the disks.

The EBS bandwidth in EC2 is limited by a few different factors:

  • The maximum bandwidth of the EBS block device
  • EC2 instance type
  • Is EBS-Optimised bit turned on for the instance

In most instance types the EBS traffic and the instance network traffic flows on the same physical NIC attached. In these cases the EBS-Optimised bit simply adds a QOS marker to the EBS packets. According to AWS documentation some instance types have a dedicated network interface for the EBS traffic and thus they don’t need to offer separated EBS-Optimised mode. This can be seen as the instances are natively always EBS-Optimised in the AWS documentation. It seems that the c4, d2 and m4 instance types seems to have this dedicated EBS NIC in the physical host.

The EBS type itself has bandwidth limitations. According to the documentation GP2 has maximum throughput of 160 MiB/s, Provisioned volume 320 MiB/s and magnetic 40-90 MiB/s. The GP2 and Provisioned bandwidth is determined on the volume size, so a small volume will not achieve the maximum bandwidth.

So to get maximum bandwidth in a single EC2 instance with EBS you should choose an instance type which is always EBS optimised, calculate maximum bandwidth of your EBS instance types and usually combine several EBS volumes together with stripped LVM to obtain best performance. For example a c4.4xlarge has max EBS bandwidth of 250 MiB/s and would require two GP2 EBS volumes (2 * 160 MiB/s) to max it out. According to my tests a single striped LVM logical volume which is backed up with two EBS volumes can achieve a constant read or write speed of 250 MiB/s while also transferring at 1.8 Gbps speed over the ethernet network to another machine.

Q&A on MongoDB backups on Amazon EC2

adminComputers

I just recently got this question from one of my readers and I just posted my response here for future reference:

I was impressed about your post about MongoDB because I have similar setup at my company and I was thinking maybe you could give me an advice.

We have production servers with mongodb 2.6 and replica set. /data /journal /log all separate EBS volumes. I wrote a script that taking snapshot of production secondary /data volume every night. The /data volume 600GB and it takes 8 hours to snapshot using aws snapshot tool. In the morning I restore that snapshot to QA environment mongodb and it takes 1 minute to create volume from snapshot and attach volume to qa instance. Now my boss saying that taking snapshot on running production mongodb drive might bring inconsistency and invalidity of data. I found on internet that db.fsynclock would solve the problem. But what is going to happen if apply fsynclock on secondary (replica set) for 8 hours no one knows.
We store all data (data+journal+logs) into the same EBS volume. That’s also what MongoDB documentation suggests: “To get a correct snapshot of a running mongod process, you must have journaling enabled and the journal must reside on the same logical volume as the other MongoDB data files.” (that doc is from 3.0 but it applies also to 2.x)
I suggest that you switch to having data+journal in the same EBS volume and after that you should be just fine with doing snapshots. The current GP2 SSD disks allows big volumes and great amount of IOPS so that you might be able to get away with having just one EBS volume instead of combining several volumes together with LVM. If you end up using LVM make sure that you use the LVM snapshot sequence which I described in my blog http://www.juhonkoti.net/2015/01/26/tips-and-caveats-for-running-mongodb-in-production
I also suggest that you do snapshots more often than just once per night. The EBS snapshot system stores only new modifications, so the more often you do snapshots, the faster each snapshot will be created. We do it once per hour.
Also after the EBS snapshot API call has been completed and the EBS snapshot process is started you can resume all your operations in the disk which was just snapshotted. In other words: The data is frozen at some atomic moment during the EBS snapshot API call. After that moment the snapshot will contain exactly that data what it was during that atomic moment. The snapshot progress just tells you when you can restore a new EBS volume from that snapshot and that your volume IO performance is degraded a bit because the snapshot is being copied to S3 behind the scenes.
If you want to use fsynclock (which btw should not be required if you use mongodb journal) then implement a following sequence and you are fine:
  1. fsynclock
  2. XFS freeze (xfs_freeze -t /mount/point)
  3. EBS snapshot
  4. XFS unfreeze
  5. fsyncUnlock (xfs_freeze -u /mount/point)
The entire process should not take more than a dozen or so seconds.