/MongoDB-Deployment-Planner

Primary LanguageHTML

#MongoDB Deployment Planner

An online tool that helps engineering teams organize and plan their MongoDB projects

##Overview

Engineering teams plan for production by writing proper specs and requirements. These specs serve as a "DevOps contract" where both teams agree on what load the database will serve and how it will be configured.

Deployments MongoDB can and should be described with standard documentation including all requirements and specifications such that:

  • Dev and Ops have a clear understanding of expected load
  • Clusters can be provisioned and configured appropriately
  • Operation Constraints can be defined, (e.g. constrained queries)
  • Failure protection can be defined, (circuit breakers, bulkheads, and timeouts)

###The MongoDB Deployment Planner Is an online form which users can create their own DevOps contract by creating a list of all operations the database is to serve. DevOps teams can qualify and quantify these operations in a helpful and easy to use online template which will generate 4 documents:

  • Database Access Requirements (DAR)
  • Database Access Specifications (DAS)
  • Cluster Configuration Specifications
  • Monitoring and Alerting Specification

Click here to view a sketch implementation of the DAS template.

ScavengerHunt is an example applicaiton which implments the DAR/DAS best practices described in this project. You can examine that project's DevOps contract here.

###Database Access Requirements Document (DAR) A complete list of all operations, (queries, commands, aggregations) sent by the application client to the database with sufficient detail such that the Operations Team can declare required indexes, allocate necessary hardware and provision a cluster to meet current and expected loads.

Each line item describes an individual operation, which can be identified by name and type, [query|insert|update|command]. A operation descriptor is composed of a set of operation specific fields relevant to the operation type

####Operation Descriptor

  • Operation Name: "Update User “Shopping Cart”

  • Operation Type [read|insert|update|delete|aggregate]

  • Query Predicates

  • Projected fields

  • Expected Result Set Size

  • Service Level Agreement, (SLA)

  • Frequency of Operation

  • Required Durability (Write ops only)

  • Required Availability

  • Consistency Tolerance (Read ops only)

  • Relevant Schema Descriptor

  • Growth expectations

##Template Descriptions

###Database Access Specification Document (DAS)

Details all parameters the application client is required include when issuing requests to the database on a per-operation basis. This document shall include an entry for each individual operation defined in the Access Declaration Document. This document is generated by The Operations Team as a response to the Database Operations Requirement Specifications.

####Operation Descriptor

  • Operation Name
  • Namespace: <database.collection>
  • Authentication / Authorization Credenitals
  • Consistency: Read Preference (Reads only)
  • Durability; i.e. Write concern (writes only) [ [0-N] | 'majority' ] journal: false fsync: false tags { tagname:min, ... } GetLastErrorMode: "name"
  • Operation time outs

###Cluster Configuration Document

A comprehensive description of the MongoDB cluster, including node composition, locations, configuration parameters, hardware specifications, tags and index declarations for each node in the cluster.

####Cluster Configuration

#####Configuration at the Sharded Cluster Level

  • Shard namespaces
  • Shard Keys
  • Shard tags
  • Balancer windows
  • Primary Shards

#####Configuration at the Replica Set Level

  • Topology & Geographic locations
  • Tags
  • Priorities
  • Hidden Nodes
  • Delayed Secondaries
  • Index declarations
    • per replica set
    • per node
  • Authentication and Authorization
  • Backups & Recovery Protocols
  • Maintenance Routines

###Monitoring and Alerting Specification

This document describes the specific monitoring metrics with alerting thresholds required for the production cluster. An alert should be triggered when a scalar value has been exceeded for a sustained duration of time.

####Alert Descriptor

Example: Page Faulting exceeds a rate of 10,000 faults/second for an observed duration of 5 minutes

{	
	metric: "Faults",
	threshold: { 
		number: 10000,
		interval: 300
	}
}

##TODOs

Look for all possible constraints in the UI fields

Suggested features

Preview window on the on the right Hash url access Modal window FOR SAVE requires user contact information Default values in fields

###Phased input mode (user work flow)

  • step one query plans what do I want to do
  • step two more nitty-gritty how fast / how much (engagement invite)
  • step SLA on a path to real documentation (engagement invite)