MongoDB and Amazon Web Services: Deploying for High Availability

47
MongoDB and AWS Part 1: Deployment and Availability Senior Solutions Architect, MongoDB Inc. Sandeep Parikh #mongodb

description

MongoDB and Amazon Web Services are a great match for those deploying and scaling applications in the cloud. This session will highlight the best practices for those running MongoDB on EC2, starting with basic installation using the AMI, to configuration of replica sets, to scaling a sharded system across multiple availability zones in order to ensure fault tolerance. We’ll walk through the specific steps necessary to set up, monitor and backup MongoDB so that you walk away from the presentation ready to deploy in production.

Transcript of MongoDB and Amazon Web Services: Deploying for High Availability

Page 1: MongoDB and Amazon Web Services: Deploying for High Availability

MongoDB and AWSPart 1: Deployment and Availability

Senior Solutions Architect, MongoDB Inc.

Sandeep Parikh

#mongodb

Page 2: MongoDB and Amazon Web Services: Deploying for High Availability

Agenda

• MongoDB Basics

• Deployment Configurations

• AWS EC2 Instances

• Configuring Instances

• Next Steps

Page 3: MongoDB and Amazon Web Services: Deploying for High Availability

MongoDB Basics

Page 4: MongoDB and Amazon Web Services: Deploying for High Availability

MongoDB Basics

• Open source

• Document database

• High performance

• Horizontally scalable

• Full featured

• Built to match agile development and deployment

Page 5: MongoDB and Amazon Web Services: Deploying for High Availability

MongoDB Features

• Flexible document data model

• Rich ad-hoc queries and in-place updates

• Real-time aggregation

• Geospatial support

• Text search

• Built-in support for– Redundancy, failover, auto-partitioning

Page 6: MongoDB and Amazon Web Services: Deploying for High Availability

Accessing MongoDB

ShellCommand-line shell for interacting directly with database

DriversDrivers for most popular programming languages and frameworks

> db.collection.insert({product:“MongoDB”, type:“Document Database”})> > db.collection.findOne(){

“_id” : ObjectId(“5106c1c2fc629bfe52792e86”),

“product” : “MongoDB”“type” : “Document Database”

}

Java

Python

Perl

Ruby

Haskell

JavaScript

Page 7: MongoDB and Amazon Web Services: Deploying for High Availability

Deployment Configurations

Page 8: MongoDB and Amazon Web Services: Deploying for High Availability

Deploying MongoDB

• Single node– Development: prototyping, testing

• Replica Set– Production: high availability, disaster recovery

• Sharding– Production: auto-paritioning, linear read/write

scale

Page 9: MongoDB and Amazon Web Services: Deploying for High Availability

MongoDB: Single Node

MongoDB

App

Page 10: MongoDB and Amazon Web Services: Deploying for High Availability

MongoDB: Replica Sets

MongoDB

Primary

App

MongoDB

Secondary

MongoDB

Secondary

Page 11: MongoDB and Amazon Web Services: Deploying for High Availability

MongoDB: ShardingApp

MongoDBPrimary

MongoDBSecondar

y

Shard

MongoDBSecondar

y

MongoDBPrimary

MongoDBSecondar

y

Shard

MongoDBSecondar

y

MongoDBPrimary

MongoDBSecondar

y

Shard

MongoDBSecondar

y

mongosconfig

config

config

App

mongos

App

mongos

Page 12: MongoDB and Amazon Web Services: Deploying for High Availability

Amazon Web Services

Page 13: MongoDB and Amazon Web Services: Deploying for High Availability

Amazon Web Services

• Complete cloud infrastructure– Compute – Storage– Database– Analytics– Deployment

• Multitude of configuration options

• Pricing flexbility– On-demand, Spot, Reserved instances

Page 14: MongoDB and Amazon Web Services: Deploying for High Availability

EC2 Instance Types

• General Purpose

• Compute-optimized

• GPU

• Memory-optimized

• Storage-optimized

• Micro

Page 15: MongoDB and Amazon Web Services: Deploying for High Availability

EC2 Instance Types

• General Purpose

• Compute-optimized

• GPU (compute resources not needed)

• Memory-optimized

• Storage-optimized

• Micro (bursty, no sustained CPU)

Page 16: MongoDB and Amazon Web Services: Deploying for High Availability

EC2 Instance Types

• General Purpose– M1, M3

• Compute-optimized– C1, CC2, C3

• Memory-optimized– M2, CR1

• Storage-optimized – HS1, HI1, I2

Page 17: MongoDB and Amazon Web Services: Deploying for High Availability

Instance Details

• Differences in – CPU, Memory, Storage, Networking

• Networking– EBS-optimized, Enhanced, Cluster

• Availability– Not all are available in all regions

Page 18: MongoDB and Amazon Web Services: Deploying for High Availability

Zones, Regions, Security

• Regions– Data center

• Availability Zones– Rack in a data center

• Security– Security Groups, VPC

us-east-1

1b

1c

1d

us-west-1

1a

1c

us-west-2

2a

2b

2c

Page 19: MongoDB and Amazon Web Services: Deploying for High Availability

mongod

Core database process

High performance

Memory, Storage, Network

config

Sharding metadata

Smaller

m1.small or m1.medium

mongos

Sharding query router

Deploy on app server

Components and Sizing

Page 20: MongoDB and Amazon Web Services: Deploying for High Availability

Replica Sets: Security Groups

MongoDB

Primary

App

MongoDB

Secondary

MongoDB

Secondary

“database”

“application”

Page 21: MongoDB and Amazon Web Services: Deploying for High Availability

Replica Sets: Availability Zones

MongoDB

Primary

App

MongoDB

Secondary

MongoDB

Secondary

Zone 1 Zone 2 Zone 3

Page 22: MongoDB and Amazon Web Services: Deploying for High Availability

Replica Sets: Regions

MongoDB

Primary

App

MongoDB

Secondary

MongoDB

Secondary

Region 1 Region 2

Page 23: MongoDB and Amazon Web Services: Deploying for High Availability

Replica Sets: Regions and Zones

MongoDB

Primary

App

MongoDB

Secondary

MongoDB

Secondary

Region 1 Region 2

Page 24: MongoDB and Amazon Web Services: Deploying for High Availability

Sharding: RegionsApp

MongoDBPrimary

MongoDBSecondar

y

Shard

MongoDBSecondar

y

MongoDBPrimary

MongoDBSecondar

y

Shard

MongoDBSecondar

y

MongoDBPrimary

MongoDBSecondar

y

Shard

MongoDBSecondar

y

mongosconfig

config

config

App

mongos

App

mongos

Region 1

Region 2

Page 25: MongoDB and Amazon Web Services: Deploying for High Availability

Sharding: RegionsApp

MongoDBPrimary

MongoDBSecondar

y

Shard

MongoDBSecondar

y

MongoDBPrimary

MongoDBSecondar

y

Shard

MongoDBSecondar

y

MongoDBPrimary

MongoDBSecondar

y

Shard

MongoDBSecondar

y

mongosconfig

config

config

App

mongos

App

mongos

Region 1 Region 2

Page 26: MongoDB and Amazon Web Services: Deploying for High Availability

High Availability

• Use Replica Sets– Deploy in odd numbers– Maintain majority

• Withstand the loss of– Any single zone?– Any single region?– Deploy in 3 places

• Scale– Replica Sets for HA– Sharding for scale– Combine for both

MongoDB

Primary

1

MongoDB

Secondary

2

MongoDB

Secondary

3

Page 27: MongoDB and Amazon Web Services: Deploying for High Availability

Deployment Considerations

• How much availability do you need?

• Can you withstand loss of zone, region?

• Where is your app and where are your users?

• What are the security requirements?– Note: security groups don’t span regions– SSL or VPC

Page 28: MongoDB and Amazon Web Services: Deploying for High Availability

Best Practices

Page 29: MongoDB and Amazon Web Services: Deploying for High Availability

Instance Configuration Best Practices

• Amazon Linux

• Install via yum for flexibility

• Use PIOPS EBS

• Update system settings

• Launch EBS optimized

Page 30: MongoDB and Amazon Web Services: Deploying for High Availability

Instance Configuration Best Practices

• Launch as EBS-optimized

• Use separate PIOPS volumes for data, log, journal

• Use EXT4

• Set read ahead

• Update ulimits

• Update TCP KeepAlive

Page 31: MongoDB and Amazon Web Services: Deploying for High Availability

Sensible Instance Defaults

• Best practices are meant to be a sensible starting point

• Amazon Linux optimized for EC2

• EBS provides persistent storage

• EBS-optimized allocates additional NIC for storage

• Provisioned IOPS provides consistent EBS performance

Page 32: MongoDB and Amazon Web Services: Deploying for High Availability

Sensible Instance Defaults

• Individual volumes to reduce IO contention

• Default read ahead is too high

• Default ulimits are too low

• Default keepalive too low

Page 33: MongoDB and Amazon Web Services: Deploying for High Availability

AWS Marketplace

Page 34: MongoDB and Amazon Web Services: Deploying for High Availability

AWS Marketplace

• The AWS Marketplace is an online store that helps users find, buy, and deploy software.

• Launch pre-configured software and let AWS handle billing and payments

Page 35: MongoDB and Amazon Web Services: Deploying for High Availability

MongoDB on AWS Marketplace

Page 36: MongoDB and Amazon Web Services: Deploying for High Availability

MongoDB on AWS Marketplace

Page 37: MongoDB and Amazon Web Services: Deploying for High Availability

MongoDB Configurations

• Follows MongoDB best practices– Amazon Linux, MongoDB installed via yum– EBS PIOPS volumes per mount (data, log, journal)– Configured: ulimits, read ahead, keep alive

ConfigData Log Journal

Size IOPS Size IOPS Size IOPS

1000 IOPS

200 GB 1000 10 GB 100 25 GB 250

2000 IOPS

200 GB 2000 15 GB 150 25 GB 250

4000 IOPS

400 GB 4000 20 GB 200 25 GB 250

Page 38: MongoDB and Amazon Web Services: Deploying for High Availability

MongoDB Management Service

Page 39: MongoDB and Amazon Web Services: Deploying for High Availability

MongoDB Management Service• MongoDB Management Service (MMS) is a suite of services for

managing MongoDB deployments.

• Engineered by the team who develops MongoDB, MMS makes it easier to operate MongoDB at any scale.

• MMS provides monitoring, backup and recovery, helping users optimize clusters and mitigate operational risk.

• MMS users can visualize database performance and set custom alerts that notify when particular metrics are out of normal range.

• MMS is also the only continuous backup solution for MongoDB, providing point-in-time recovery for replica sets and cluster-wide snapshots of sharded systems.

Page 40: MongoDB and Amazon Web Services: Deploying for High Availability

MMS Monitoring

Page 41: MongoDB and Amazon Web Services: Deploying for High Availability

MMS Monitoring

• MongoDB-specific metrics

• Performance visualization

• Metrics dashboards

• Custom alerts and notifications

Page 42: MongoDB and Amazon Web Services: Deploying for High Availability

MMS Monitoring

Page 43: MongoDB and Amazon Web Services: Deploying for High Availability

MMS Monitoring

• Agent-based deployment monitoring

• Opcounters, memory usage, index usage, lock %, connections, background flush, queues, page faults, and more

• Notifications and alerts on any metric and condition

• Agent pre-installed on AWS Marketplace instances

Page 44: MongoDB and Amazon Web Services: Deploying for High Availability

Coming Up Next

• Part 2 in late March– Storage Configurations– Storage Tradeoffs– Disaster Recovery

• Part 3 in late April– Integrating with AWS Services– CloudFormation– Elastic MapReduce

Page 45: MongoDB and Amazon Web Services: Deploying for High Availability

Questions?

Page 47: MongoDB and Amazon Web Services: Deploying for High Availability

MongoDB WorldNew York City, June 23-25

#MongoDBWorld

See what’s next in MongoDB including • MongoDB 2.6• Sharding• Replication• Aggregation

http://world.mongodb.comSave 25% with discount code 25SandeepParikh