1

tl;dr - What are the proper readahead values for the different EBS PIOPS volumes in a RAID 10 array ?
What about the RAID 10 physical and logical volumes themselves ?
What about the chunk size of the mdadm call and blocksize of the dd call?

The long story:

I'm using MongoDB Cloud (previously MMS) to manage my replica set.

I have written the following script that launches an instance (or more) and prepares them for the installation of the MMS automation agent, including setting up RAID 10, setting the readahead, disabling huge pages, formatting with xfs, setting up munin, etc.

You can see the script here - https://gist.github.com/dorongutman/01d8daf0154621e4645d

Most of the documentation and community information out there refers to the values of the readahead for a single EBS volume (usually magnetic). What I did not find are the suggested readahead values for multiple EBS PIOPS volumes, used in a RAID 10 setup. There’s also the chunk size of the RAID creation and block size when using dd.

I want to create a RAID 10 from 4 EBS PIOPS volumes, each with 50GB and 250 IOPS (which should bring me a single 100GB volume with 500 IOPS once RAID'ed, right ?), and use XFS on the RAID'ed volume for the mongo data folder. I have the following questions:

  • What should be the Readahead value of each of the different volumes that comprise the RAID 10 ? (/dev/xvdw to /dev/xvdz)
  • What should be the Readahead for the RAID 10 device itself ? (both physical and logical volumes - /dev/md0 and /dev/vg0/data
  • The instance that was created by mongodb cloud (in my initial tests of MMS) had the following values in /etc/security/limits.d/99-mongodb-mms-automation-agent.conf:
 mongod - fsize unlimited mongod - cpu unlimited mongod - as unlimited mongod - nofile 64000 mongod - rss unlimited mongod - nproc 64000


Are the above configuration good as well (RAID 10 over 4 EBS PIOPS volumes) ?

I would love to get your general feedback on the script as well - is there something I missed? Is there something that could be setup/configured better ?

I've played with MongoDB Cloud quite a lot and while it offers the option to create the relevant instances - all from inside the mongodb cloud dashboard - it is limited in regards to the production best practices you publish (RAID 10 array, private subnet, replica set configuration, etc.).

Improve this question
4
  • Why wouldn't you just make a single EBS volume with 100GB and 500 IOPS?
    – James Thompson
    Jan 23, 2016 at 22:38
  • Creating a mongodb node without some kind of RAID-like redundancy in the storage is very dangerous and considered bad for production - docs.mongodb.org/manual/administration/production-notes/#raid
    – Doron
    Feb 9, 2016 at 20:54
  • EBS has redundancy, and S3 snapshots are very very reliable : infoheap.com/aws-ebs-reliability
    – Tim
    Feb 9, 2016 at 21:10
  • Yes, but "Each Amazon EBS volume is automatically replicated within its Availability Zone to protect you from component failure, offering high availability and durability" (aws.amazon.com/ebs). That means that you don't need to do mirroring yourself. As far as I can tell, the only reason you should do striping is if you need more performance than EBS offers from a single volume, which I don't think that you need in this case.
    – James Thompson
    Feb 14, 2016 at 19:34

0

Reset to default

You must log in to answer this question.

Browse other questions tagged .