MMS - Monitoring, backup and management at a single click
•Download as PPTX, PDF•
1 like•5,954 views
MMS is MongoDB's monitoring, backup, and management system that provides: - Server and cluster monitoring with metrics, alerts and activity feeds - Backup of replica sets and sharded clusters with initial sync and incremental backups stored as snapshots - Restore of backups to point-in-time within the last 24 hours - Automation capabilities for tasks like capacity resizing, provisioning machines, and rolling upgrades It has cloud and on-premise deployment options with pricing based on usage for the cloud version. MMS aims to simplify managing large MongoDB deployments through monitoring, backups and automation.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to MMS - Monitoring, backup and management at a single click
Similar to MMS - Monitoring, backup and management at a single click (20)
More from Matias Cascallares
Recently uploaded
Recently uploaded (20)
MMS - Monitoring, backup and management at a single click
- 1. Solutions Architect, MongoDB Inc. Matias Cascallares #MongoDBDays @mcascallares MMS – Monitoring, Backup and Management at a single click
- 2. What is MMS?
- 3. MMS MongoDB Monitoring SystemMongoDB Management System
- 4. What can I do?
- 5. Two Deployment Models Using MongoDB Servers: cloud version Using my servers: on-premise
- 6. Monitoring
- 8. Cluster View
- 10. Alerts
- 11. Logs and Profile data
- 12. Hardware stats (CPU, disk)
- 13. DB Stats
- 14. User Management
- 16. Cloud Version 1. Go to http://mms.mongodb.com 2. Create an account 3. Install one agent in your datacenter 4. Add hosts from the web interface 5. Enjoy!
- 17. Some Cloud Numbers – May 2014 • 75K updates/sec • More than 30K active groups • More than 40K active hosts
- 18. Backups
- 19. MMS Backup • Backup a replica set or sharded cluster • Initial sync + incremental • Generated snapshots every 6 hs • Restore via HTTPS or SCP • Restore replica sets to point-in-time (last 24hs) • Restore sharded clusters to any 15 minute (last 24hs)
- 20. Picking a snapshot to restore
- 21. MMS Backup Setup
- 22. Some Cloud Numbers – May 2014 • 100 GB/hr of new data
- 23. Cloud Version - Billing • 12-months pre-paid: • $50 / GB / year • 6-hour interval snapshot stored for two days • Weekly snapshots stored for 1 month • Monthly snapshots stored for 1 year • Payment method: invoiced
- 24. Cloud Version - Billing • Pay as you go • Oplog processing: $1 / GB / month • Snapshot storage: 0.08 / GB / month • Customer defines snapshot frequency and retention policy • Payment method: online
- 25. Automation
- 26. Why? • Managing big MongoDB deployments can be a complex process • Some tasks require “manual” intervention: – Provision machines – Rolling upgrades – Rolling compactions – Etc.
- 28. What can I do? • Create your deployment • Capacity resize: add/remove shards and replica sets • Resize oplog • Specify users and roles • Provisioning new machines (only in AWS)
- 30. Automation: provisioning and creating a replica set
- 42. Automation: rolling upgrade my replica set
- 52. Solutions Architect, MongoDB Inc. Matias Cascallares #MongoDBDays @mcascallares Thank You
Editor's Notes
- Starting from the scratch, I don’t have any host configured in my MMS account, everything is empty so far
- I am going to ‘Provisioned Machines’ section, and I am going to provision some EC2 instances for this test
- We can specify my instance specs, sizing, location, where to store my database, etc
- I can see that my 3 machines are being provisioned in ‘Pending’ state, this can take a long time
- … and I can see that my 3 provisioned machines are up and running, remember that this process can take a long time depending on your provider
- Now checking ‘Current Config’ section and check that I don’t have any running configuration yet. We can create a standalone, replica set and cluster configuration, let’s create a new replica set configuration,
- Here we can specify my replica set configuration, describe them field by field
- In the next screen I am going to review my changes and if they are correct publish them
- Now my instances are being deployed, automation agent is going to download the specified versions of the database and setup up everything for me Check the ‘waiting’ status besides each machine, this status is going to change to reflect what actually is going on
- After completing the deployment I can see in ‘Topology View’ my replica set called myRS with 3 nodes up and running
- In ‘Topology View’ I can see how processes are distributed across machines, this can be really helpful on more complex topologies where I run more than one process per machine
- In my ‘Current Config’ screen I am going to click on my replica set name to change my configuration
- I can review my current configuration and update it clicking on ‘Edit’ button
- I can update values like port, replica set name and version
- Let’s upgrade the version to the latest stable 2.4.9 and click on ‘Apply’
- Let’s review my changes and accept them
- Check how the version is going to be upgraded from 2.4.6 to 2.4.9
- The new 2.4.9 version is being downloaded in each node and they are going to be upgraded with a rolling mechanism (explain rolling upgrade) without downtime
- … and we are done, all my nodes are up and running with the new version
- Checking on the monitoring screen I can see the healthy status of my deployment and running version 2.4.9