MongoDB Deployment Tips

4,197 views
4,010 views

Published on

This presentation covers two important topics for scalable mongodb deployments. First, we will discus how MongoDB stores data so you can figure out how much RAM you need in each of your servers. Second, we'll look at replica sets and how to design a highly available topology for your replica set.

Published in: Technology, Health & Medicine
1 Comment
7 Likes
Statistics
Notes
  • At MongoDirector (www.mongodirector.com) we automate the entire process of deploying and managing Mongo replica sets and shards using a simple two step wizard. You can pick the number of replicas and shards and the regions in which you want to place them. Provisioned IOPS and RAID can be used for optimal performance. We also use LVM snapshots for backup so that your backups take the same amount of time irrespective of the size of data.
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total views
4,197
On SlideShare
0
From Embeds
0
Number of Embeds
13
Actions
Shares
0
Downloads
83
Comments
1
Likes
7
Embeds 0
No embeds

No notes for slide

MongoDB Deployment Tips

  1. 1. MongoDB deployment tipsJared Rosoff - @forjared<br />
  2. 2. Agenda<br />Sizing Machines<br />Understanding working set <br />Sizing RAM <br />Sizing Disk <br />Configuring Replica Sets<br />Understanding failover <br />Avoiding single points of failure <br />Minimizing recovery time<br />
  3. 3. Overview<br />Secondary<br />Secondary<br />Secondary<br />Config<br />Config<br />Config<br />Router<br />Router<br />Shard 1<br />Shard 2<br />Shard 3<br />Primary<br />Primary<br />Primary<br />Secondary<br />Secondary<br />Secondary<br />
  4. 4. Servers and Hardware<br />Secondary<br />Secondary<br />Secondary<br />Config<br />Config<br />Config<br />Router<br />Router<br />Shard 1<br />Shard 2<br />Shard 3<br />Primary<br />Primary<br />Primary<br />Secondary<br />Secondary<br />Secondary<br />
  5. 5. Sizing ram and disk<br />
  6. 6. Collection 1<br />Index 1<br />
  7. 7. Collection 1<br />Virtual Address Space 1<br />Index 1<br />
  8. 8. Collection 1<br />Virtual Address Space 1<br />This is your virtual memory size (mapped) <br />Index 1<br />
  9. 9. Collection 1<br />Virtual Address Space 1<br />Physical RAM<br />Index 1<br />
  10. 10. Collection 1<br />Virtual Address Space 1<br />Physical RAM<br />Index 1<br />This is your resident memory size<br />
  11. 11. Disk<br />Collection 1<br />Virtual Address Space 1<br />Physical RAM<br />Index 1<br />
  12. 12. Disk<br />Collection 1<br />Virtual Address Space 1<br />Physical RAM<br />Index 1<br />Virtual Address Space 2<br />
  13. 13. Disk<br />Collection 1<br />Virtual Address Space 1<br />Physical RAM<br />Index 1<br />100 ns<br />=<br />10,000 ns<br />=<br />
  14. 14. Disk configurations<br />Single Disk<br />~200 seeks / second<br />
  15. 15. Disk configurations<br />Single Disk<br />RAID 0<br />~200 seeks / second<br />~200 seeks / second<br />~200 seeks / second<br />~200 seeks / second<br />
  16. 16. Disk configurations<br />Single Disk<br />RAID 0<br />~200 seeks / second<br />RAID 10<br />~200 seeks / second<br />~200 seeks / second<br />~200 seeks / second<br />~400 seeks / second<br />~400 seeks / second<br />~400 seeks / second<br />
  17. 17. SSDs ?? <br />Seek time of 0.1ms vs 5ms <br />(200 seeks / sec => 10000 seeks / sec)<br />But expensive<br />
  18. 18. Tips for sizing hardware<br />Know how important page faults are<br />If you want low latency, avoid page faults<br />Size memory appropriately <br />To avoid page faults, fit everything in RAM<br />Collection Data + Index Data<br />Provision disk appropriately<br />RAID10 is recommended<br />SSD’s are fast, if you can afford them <br />
  19. 19. Replica Sets<br />Secondary<br />Secondary<br />Secondary<br />Config<br />Config<br />Config<br />Router<br />Router<br />Shard 1<br />Shard 2<br />Shard 3<br />Primary<br />Primary<br />Primary<br />Secondary<br />Secondary<br />Secondary<br />
  20. 20. Understanding automatic failover<br />
  21. 21. Primary Election<br />As long as a partition can see a majority (>50%) of the cluster, then it will elect a primary. <br />Secondary<br />Primary<br />Secondary<br />
  22. 22. Simple Failure<br />66% of cluster visible. Primary is elected<br />Primary<br />Failed Node<br />Secondary<br />
  23. 23. Simple Failure<br />33% of cluster visible. <br />Read only mode. <br />Failed Node<br />Failed Node<br />Secondary<br />
  24. 24. Network Partition<br />Secondary<br />Primary<br />Secondary<br />
  25. 25. Network Partition<br />66% of cluster visible. Primary is elected<br />Secondary<br />Failed Node<br />Primary<br />Primary<br />Secondary<br />Secondary<br />
  26. 26. Secondary<br />Network Partition<br />Primary<br />Failed Node<br />Secondary<br />Secondary<br />Failed Node<br />33% of cluster visible. <br />Read only mode. <br />
  27. 27. Even Cluster Size<br />Secondary<br />Primary<br />Secondary<br />Secondary<br />
  28. 28. Even Cluster Size<br />50% of cluster visible. <br />Read only mode. <br />Secondary<br />Failed Node<br />Primary<br />Secondary<br />Failed Node<br />Secondary<br />Secondary<br />Secondary<br />
  29. 29. Even Cluster Size<br />Secondary<br />Failed Node<br />Primary<br />Secondary<br />Failed Node<br />Secondary<br />Secondary<br />Secondary<br />50% of cluster visible. <br />Read only mode. <br />
  30. 30. Avoiding single points of failure<br />
  31. 31. Avoid Single points of failure<br />
  32. 32. Avoid Single points of failure<br />Secondary<br />Primary<br />Secondary<br />Top of rack switch<br />Rack falls over<br />
  33. 33. Better<br />Secondary<br />Primary<br />Secondary<br />Loss of internet<br />Building burns down<br />
  34. 34. Better yet<br />San Francisco<br />Secondary<br />Primary<br />Dallas<br />Secondary<br />
  35. 35. Priorities<br />San Francisco<br />Priority 1<br />Priority 1<br />Secondary<br />Priority 0<br />Primary<br />Dallas<br />Secondary<br />Disaster recover data center. Will never become primary automatically. <br />
  36. 36. Even Better<br />San Francisco<br />New York<br />Secondary<br />Primary<br />Dallas<br />Secondary<br />
  37. 37. Fast recovery<br />
  38. 38. 2 Replicas + Arbiter??<br />Arbiter<br />Is this a good idea? <br />Primary<br />Secondary<br />
  39. 39. 2 Replicas + Arbiter??<br />1<br />Arbiter<br />Primary<br />Secondary<br />
  40. 40. 2 Replicas + Arbiter??<br />1<br />2<br />Arbiter<br />Arbiter<br />Primary<br />Primary<br />Secondary<br />Secondary<br />
  41. 41. 2 Replicas + Arbiter??<br />3<br />1<br />2<br />Full Sync<br />Arbiter<br />Arbiter<br />Arbiter<br />Primary<br />Primary<br />Primary<br />Secondary<br />Secondary<br />Secondary<br />Secondary<br />Uh oh. Full Sync is going to use a lot of resources on the primary. So I may have downtime or degraded performance<br />
  42. 42. With 3 replicas<br />1<br />Primary<br />Secondary<br />Secondary<br />
  43. 43. With 3 replicas<br />1<br />2<br />Primary<br />Primary<br />Secondary<br />Secondary<br />Secondary<br />Secondary<br />
  44. 44. With 3 replicas<br />3<br />1<br />2<br />Primary<br />Primary<br />Primary<br />Full Sync<br />Secondary<br />Secondary<br />Secondary<br />Secondary<br />Secondary<br />Secondary<br />Secondary<br />Sync can happen from secondary, which will not impact traffic on Primary. <br />
  45. 45. Tips for choosing replica set topology<br />Avoid single points of failure <br />Separate racks<br />Separate data centers<br />Avoid long recovery downtime<br />Use journaling <br />Use 3+ replicas<br />Keep your actives close <br />Use priority to control where failovers happen<br />
  46. 46. Summary<br />Sizing a machine <br />Know your working set size <br />Size RAM appropriately <br />Provision sufficient disks <br />Designing a replica set <br />Know how failover happens <br />Design for failure <br />Design for fast recover <br />

×