As we increasingly build applications to reach global audiences, the scalability and availability of your database across geographic regions becomes a critical consideration in systems selection and design.
3. MongoDB Data Center Awareness
• Replicate data across data centers (up to 50 in a single
replica set)
• Configure cross-data center write guarantees
• Isolate subsets of data to specific data centers
• Configure local reads and global writes
• Create active/active datacenter deployments
5. MongoDB Replica Sets
Replica Set – 2 to 50 copies
Addresses availability & user
experience requirements:
High Availability / Disaster Recovery
Serve local reads
Self-healing & Data Center Aware
Configurable election policies
Workload Isolation: operational &
analytics
6. MongoDB Auto-Sharding
Application transparent scale-out on commodity hardware
Shards can be distributed across multiple data centers
Three policies: hash-based, range-based, location-aware
Elastic scalability & automatic balancing
9. Traditional Deployment:
Active/Standby Data Center
Business continuity: DR + Low RPO (with continuous backup & PIT Recovery)
But we can do better: architecture constrained by limits of RDBMS
13. Read Locally, Write Globally
Primary Secondary Secondary
WEST EAST
Local Reads (Eg. Read Preference = Nearest)
Query
Query
Shard 1
PrimarySecondary Secondary
Shard 2
Tag = East
Tag = West
PrimarySecondary Secondary
Shard 3
Tag = East
Update
Update
Collection: Users, Shard Key: {regionCode,uid}
Priority=10Priority=10
Priority=10 Priority=10
Tag Start End
West MinKey, MinKey 50, MaxKey
East 50, MinKey MaxKey, MaxKey
16. Single-click (or API call) provisioning,
scaling & upgrades, admin tasks
Monitoring, with charts, dashboards and
alerts on 100+ metrics
Continuous backup, with point-in-time
recovery, support for sharded clusters
MongoDB Ops Manager & MMS
The Best Way to Manage MongoDB In Your Data Center or in the Cloud
Up to 95% Reduction in Operational Overhead
17. How MongoDB Ops Manager helps you
Scale EasilyMeet SLAs
Best Practices,
Automated
Cut Management
Overhead
19. Scaling Across Geographies
99.999% availability for image content management.
Sharded across multiple data centers
Location-aware sharding to distribute software updates
protecting against global security threats
Multi-National
Banking Group
Derivatives application deployed across a 110-node cluster
spanning three continents, managed by Ops Manager
China’s Uber. Sharded cluster over 4 data centers across
Greater China, connecting drivers with passengers
eCommerce product catalog scaled across continents to
support global expansion and DR
20. We Can Help
MongoDB Enterprise Advanced
The best way to run MongoDB in your data center
MongoDB Management Service (MMS)
The easiest way to run MongoDB in the cloud
Production Support
In production and under control
Development Support
Let’s get you running
Consulting
We solve problems
Training
Get your teams up to speed.
21. For More Information
Resource Location
Case Studies mongodb.com/customers
Presentations mongodb.com/presentations
Free Online Training education.mongodb.com
Webinars and Events mongodb.com/events
Documentation docs.mongodb.org
MongoDB Downloads mongodb.com/download
Additional Info info@mongodb.com
MongoDB Multi-Data Center Deployments Whitepaper
23. MongoDB Use Cases
Single View Internet of Things Mobile Real-Time Analytics
Catalog Personalization Content Management
Hinweis der Redaktion
Building apps that reach global audiences – how we deploy our DBs across regions becomes critical part of selection critiera
We’ll cover
MongoDB’s data center awareness
Deployment topologies, including active/active data centers and disaster recovery
Sample deployments
Ask questions – Paul Done
3 principal reasons:
Availability: cloud or on-prem, need to know your service survives in event of a regional disaster – fire, flood, huuricane. Gartner estimate average cost of downtime $300k per hour
Customer experience: global audience, need consistent low latency experience wherever located. Famous Amazon example that each 100ms in added latency cost 1% of sales
Compliance – national govts exert strict control on where customer data is located. Snowden leaks excaberate concerns about where is placed and controlled
What does MongoDB enable you to do
Enables you to build globally distributed, data center aware apps to meet requirements for availability, scalability and corp compliance
Before getting into this – talk about some foundation tech – replication and sharding
Builtin MongoDB feature
Data is copied or replicated to up to 50 members, distributed across multiple data centers
Can use for HA / DR. Also for serving local reads(discuss later)
Self healing, so if primary fails, secondary auto elected without intervention. Election policies are configurable – so specify preferred secondaries to take over, based on their location. Wouldn’t for example want a secondary in a remote DC to become primary if there are surving secondaries in a primary DC
Lots of other nice features – separate operational from analytics workloads
Automatic sharding for scale out. , which is trans- parent to applications. Sharding distributes data across multiple physical partitions called shards – shards can be distributed across multiple DCs.
MongoDB supports three types of sharding:
Hash-based Sharding. Random distribution
Range-based Sharding. Co-locates ranges of data on a specific shard
• Location-aware Sharding. Assign ranges of documents to specific shards - control data placement to specific data centers. Might have all German customers assigned to servers in Germany – data is never replicated outside of Germany
MongoDB automatically balances the data in the cluster as the data grows or the size of the cluster increases or decreases.
Putting RS & shards together, we can scale MongoDB with continuous availability
These features are location-aware
Replicas in DC East configured as secondary-only.
MongoDB allows users to specify write guarantees, using an option called write concern. With the appropriate config, know your data exists in multiple sites, and can withstand a regional outage – enables you to write to multiple data centers in parallel
Configure globally or per operation,
1. Write ACK only once applied The primary replica set member). This is the default write concern;
2. Primary and 1 replica
3. A majority of replicas;
4. All replicas.
It is also possible to configure acknowledged based on specific policies for example - write to at least two replica set members in one data center and at least one replica in a second data center.
MongoDB has pwerful replication capabilities – replicate data to up to 50 members – they can be globally distributed. Speed of light is something we can’t overcome (yet), so the further a client is from the location where the data is stored, the higher the latency, example reading from Sydney to London – adding over 300 milliseconds to your query
With MongoDB, control which replicas respond to queries – using read preference.
By default, always read from primary to ensure strong consistency. But you can elect to read from secondaries as well. The nearest read option allows the client to read from the lowest-latency members of a replica set based on ping time, rather than always reading from the primary.
This is typically used to route queries to a local data center, reducing the effects of geographic latency. Tags can also be used to ensure that reads are always routed to a specific node or subset of nodes.
Location aware sharding tagging a range of shard key values to associate that range with a shard. Those shards receive all inserts within the tagged range of values.
Administrators can use this to control the location of data for ie placing data sets closest to its users, or regulatory controls determining where data can be physically stored.
Location-aware sharding enables great flexibility in regional scaling. For example, a new service could experience explosive growth in Asia, requiring the addition of new shards just in that region. Administrators do not also have to add new shards in other regions as well.
By combining local reads with location-aware sharding, we can create deployments for local reads and global writes.
In this deployment each MongoDB shard is localized to a specific data center, in this case AWS East and West. Each region has a primary replica member for its shard and also maintains secondary replica members for shards located in other regions. So you have cross-regional HA
To scale operations, applications can perform local read and write operations of their data, based on their location. The sharding policies are configurable, so if a customer moves to another region – global roaming, shard tags can be updated, and the MongoDB balancer automatically migrates their data to the correct shard
Configuring a deployment to survive outages and network partitions without data loss requires active/active confiuration and majority write concern
In this example, two data centers – one in the west and one in the east configured with equal numbers of replica set members. The primary members are in the West
Then a third data center (Central) contains arbiters or an additional hidden replica member. necessary to ensure that if one of the other data centers fail, a majority of replica set members can form a quorum
If DC west fails, Central and East data centers can agree on the state of the cluster, and failover to the East data center. All of the datacenter are active. They can all serve traffic. Writes can persist across regions to ensure no data loss
Provide a complete mgmt platform
MongoDB Ops Manager: install and run yourself – that is part of commercial MongoDB EA
Or you can connect your systems to MMS which is a service hosted by MongoDB in the cloud
Enables you to provision and upgrade clusters. With a few clicks. On AWS, it will allow you to spin up complete VMs, select the region for deployments
Provides real time monitoring and alerts. So can tell you if hosts are failing, monitor replication lag
Only b/up tool providing PiT backups and consistent sharded cluster snapshots
Control it via self-service portal, or integrate it with existing mgmt frameworks via Ops Manager API
These and other customers use a range of product and services from MongoDB
We have MongoDB Enterprise Advanced – package of advanced software, including ops maanger and security software, proactive support, s/w certifications
MongoDB Management Service (MMS) cloud managed MongoDB – handling automation and backups with the mgmt infrastructure run by us
Production & Development Support helps you get up and running quickly project.
MongoDB Consulting specifically Production Readiness and Ops Mastery that asses your deployment, make recommendations
MongoDB Training – dev & DBA. Free online classes or classroom, instructor led training