Effective Deployment Architecture - Kevn Matulef

MongoDB Beijing 2012

Transcript

1. After Party 5:30-7:30pm Sunday Bar & Grill Room 101, Tower C, Fang Heng Guo Ji Building, Futong Dong Dajie ෞ௨תେ֗6߸ํ߃ࠃ࠽C࠲101ࣨ
2. Kevin  Matulef matulef@10gen.com http://www.mongodb.org Effective MongoDB Deployment Architecture
3. Agenda • Simple deployments • High-availability deployments • High-performance, high-availability deployments • Application suggestions
4. The Simplest Deployment
5. Single Node •Will have downtime eventually •If node crashes human intervention might be needed
6. High Availability with Replica Sets
7. Replica Sets Overview •Replica Sets is MongoDB’s data redundancy and availability mechanism •Designed to cope with hardware failures, server downtimes, and so on
8. Some RS Features •Asynchronous replication from writable node (Primary) to read-only nodes (Secondaries) •Automatic failover when the Primary goes offline •App-level definition of “write replication” (the w argument to getLastError) •Secondary nodes can replicate with a slaveDelay
9. When do you need replication? •All deployments should use replication •Really, we mean it!
10. Replica Set 1 Arbiter •Single datacenter •Same switch, power (1 rack) •Points of failure: •Power •Network •Datacenter •Two node failure •Automatic recovery of single node crash Primary Secondary
11. Replica Set 2 •Single datacenter •Multiple power/network zones •Points of failure: •Datacenter •Two node failure •Automatic recovery of single node crash •w=2 not practical
12. Replica Set 3 •Single datacenter •Multiple power/network zones •Points of failure: •Datacenter •Two node failure •Automatic recovery of single node crash •w=2 practical, can tolerate 1- node failure
14. Replica Set 4 •Multi datacenter •Disaster Recovery node for safety •Can’t do multi data center durable write safely since only 1 node in distant DC DR
15. Replica Set 5 delayed •Three data centers •Can survive full data center loss •Can do w= { dc : 2 } to guarantee write in 2 data centers
16. High Performance & High Availability with Sharding
17. Sharding Overview •Sharding is MongoDB’s horizontal scaling architecture •Designed to allow you to grow your database capacity linearly with your requirements
18. When do you need sharding? •If your write load can’t be handled by a single replica set’s primary for some reason •If your working set can’t fit into a single replica set’s physical memory capacity
19. Basics • Each shard should be a replica set • All rules for replica sets before apply to each shard
20. Config Servers • Need to have 3 - best on at least 2 different power/network zones • Only need 1 of the 3 to be available • Use host names (mongoconfig[123]) • Take backups • Not Replica Sets
21. mongos • One per appserver • Or, pool per power region with load balancer
22. A Sharded Cluster Shards Configs mongos mongos
23. Internals •When collections are sharded, the cluster tracks ranges of documents, called chunks. •As chunks grow in size, the cluster automatically splits them into smaller chunks. •If one shard has too many chunks gets, the cluster automatically migrates chunks. •This is all invisible to applications (unless they peek).
24. Splitting •Splitting happens automatically. •It’s possible to split a chunk manually, with the split command. •Splitting is essentially a logical operation: no data gets moved around.
25. Migrating •Migrations happen automatically, when the number of chunks on any shard is too great. •It’s possible to migrate a chunk manually, with the moveChunk command. •Migrations can be expensive, and so you can disable them, e.g., during peak load times on your database: // connect to mongos > use config > db.settings.update( { _id: "balancer" }, { $set : { stopped: true } } , true );
26. Application Magic
27. Things Happen • Handle spikes and failure gracefully • Queue non-synchronous writes • Isolate components and features • Login and Interacting with e-mail vs. updating contact list • Read only mode?
28. Homework
29. Develop Your Playbook • Monitor • load, disk, cpu (MMS) • Alerts • Procedures • Backups, adding replica set members, adding shards
30. Practice • (In staging - which should be the same as production!) • Randomly shutdown boxes and see how things react • Load test
31. Download MongoDB http://www.mongodb.org and  let  us  know  what  you  think! @mongodb http://mongodb.org