Archive | announcement RSS feed for this section

Introducing mLab Private Environments

Today we are excited to announce the private beta of mLab Private Environments. mLab Private Environments are virtual private networks you can provision to house your various database deployments hosted with mLab. These private networks isolate your database from public networks while allowing your application infrastructure secure access to your database deployments.

With Private Environments, you can continue to use the mLab platform for dynamic database provisioning and scaling while leveraging security features that are traditionally only found in private networks.

mLab Private Environments overview

When you provision a Private Environment with mLab (currently only available on AWS) we provision a dedicated AWS VPC for that environment. You can place any number of mLab MongoDB deployments inside of that Private Environment.

You can then peer the VPC underlying your Private Environment to the AWS VPC that houses your application infrastructure. This peering operation will create a single, extended, private network consisting of both your application infrastructure and your database deployments.

mlab-private-environments

From there, you can very conveniently and scalably design network ACLs and routing rules to only allow access to your database deployment from the parts of your application infrastructure that need it.

You can provision and maintain any number of Private Environments.

Benefits of using Private Environments

The move to the public cloud has been a huge win in terms of simplicity, but also a big step backwards from a networking perspective. In order to move to the public cloud, organizations had to abandon the more sophisticated networking techniques they used to employ when working in traditional data centers.

Recently, however, public cloud providers have been reintroducing some of the networking functionality that has been missing. For example, AWS VPC (Virtual Private Clouds) allow you to create virtual private networks with subnets, route tables, and network ACLs, just like you would have in a traditional datacenter, only virtualized.

Upon this infrastructure (AWS VPC) we have implemented a new deployment solution that allows you to:

  • Isolate your database from public networks while allowing secure access to your application infrastructure.
  • Create sophisticated network topologies to ensure least privilege access to your database deployments using CIDR ranges and Security Groups.
  • Easily auto-scale your application tier without having to modify database firewall rules.

How are Private Environments used?

With Private Environments, you can use all of the traditional network security best practices and techniques for designing your application. You can place your front-end load balancers in a public subnet, and place your application servers, microservices, and databases in private subnets protected from the internet, but accessible to each other.

Furthermore, if your application tier has an auto-scaling component that accesses the database, Private Environments are extremely convenient. Before Private Environments, it was impossible to add application servers to your app tier without adding new allow rules to your database firewall. This made autoscaling VMs that required access to your database deployment extremely difficult, requiring either a NAT layer or opening your database to more sources than necessary.

With Private Environments, you simply allow the proper CIDR block for the subnet holding your application VMs, or the AWS Security Group you wish to give access to (Security Groups coming soon). You can then add and remove app infrastructure without needing to touch the definition of your database deployment’s firewall.

Availability

Private Environments is currently in private beta and only available with our Dedicated plans. If you would like to join the waitlist, please email our team at support@mlab.com.

Comments are closed

How to choose a DBaaS? Check out our piece in DZone

DZone recently asked us to contribute an article on choosing a Database-as-a-Service provider. I was excited to write this because it gave us a chance to summarize some of our experience hosting hundreds of thousands of MongoDB deployments over the past five years.

The piece, titled How to Choose a DBaaS, is also part of DZone’s new Guide to Data Persistence. Beyond our piece, there are some other interesting articles in it, like Vadim Tkachenko’s article comparing B-Trees, LSM Trees, and Fractal Trees, which are various data structures used for implementing indexes, and a very interesting and appropriate read for those of us who use MongoDB.

Check it out — hopefully you will find the guide useful, especially if you are interested in databases and learning about tools and techniques that other developers are using.

MongoLab is now mLab

We have some exciting news to share! Below is the email we sent to our users earlier today:


mLab-logo-onlight

I’m very excited to share some important news with you.

Today we are changing our name from MongoLab to mLab in order to better align with our long-term vision.

When we started this business five years ago, our MongoLab database service was the first step of a larger mission. Our ultimate goal was to simplify server-side development.

We envisioned a cloud-based laboratory where developers could build and deploy the entire server side of their application with a completely software-defined interface. Our premise was that a cloud-based server-side application stack built around JSON, microservices, document databases (like MongoDB), and software-defined networking could radically simplify server-side development.

We decided to start at the bottom of the stack and work our way upwards. This meant building a Database-as-a-Service platform upon which we could layer the rest of the stack. Around the same time we discovered MongoDB and recognized it as the operational data store of the future.

And so we set out on Phase 1 and created MongoLab: the game-changing cloud database service developers worldwide have grown to love.

I’m proud to say that mLab has become THE place to run MongoDB in the cloud and now manages over 250,000 deployments on AWS, Azure, and Google. If you are using MongoDB in the cloud, there really is no better experience.

MongoLab was a great name for us when our only product was MongoDB-as-a-Service. But now we feel it is time to change our name to one that can accommodate the larger vision that we have around cloud infrastructure and cloud data services.

Over the coming quarters we will focus on our broader premise that server-side development is largely about securely moving and transforming JSON objects between the client and the database, and that it should be much easier than it is today.

To be clear, we are still fully committed to MongoDB and our cloud MongoDB service, as this is the backbone of our future vision. MongoDB Inc., the stewards of MongoDB, will continue to concentrate on enterprise customers who host the database themselves. Our job at mLab will be to focus on the rest of the world and to continue to provide the best fully managed MongoDB-as-a-Service for developers who want to build great apps without worrying about database operations.

Thank you for helping make us such a success. We truly appreciate that you have chosen our service and look forward to helping you build great software.

Will Shulman
CEO of mLab

Please help us spread the word!

Team@mLab

{ "comments": 17 }

Shared Cluster plans in AWS Oregon (us-west-2)

We are now offering Shared Cluster plans in the AWS Oregon region. You can visit the MongoLab create page if you would like to provision the plan.

Shared Cluster plans are configured with two data-bearing nodes and an arbiter. These plans are hosted on shared multi-tenanted resources but are also suitable for “production use“. If you have questions about our different plans, we have helpful documentation on each plan type. For additional help, you can also email us at support@mongolab.com.

 

Introducing Telemetry – monitoring for MongoLab deployments

Today we are announcing the alpha release of Telemetry, our real-time and historical monitoring tool for MongoLab deployments. Telemetry is a customizable dashboard GUI that displays important MongoDB metrics and helps you effectively monitor and tune database performance.

Telemetry Dashboard

Telemetry dashboard overview

Metrics in Telemetry

The alpha version of Telemetry displays real-time and historical MongoDB serverStatus data.

Specifically, there are historical graphs for:

  • Opcounters (queries, inserts, updates, deletes, getmores, cmds)
  • Memory
  • Effective Lock
  • Page Faults
  • Index Access (accesses, hits, misses)
  • Connections
  • Network (in, out, requests)
  • Queues (readers, writers)
  • Journal (stats, commits in write lock)
  • Cursors
  • Background Flush
  • Record Stats
  • Replication Stats (oplog window, lag)

Feature highlights

Telemetry has many features to help you quickly assess the health of your deployment.

Customizable dashboard

By default, Telemetry displays all of your historical MongoDB serverStatus data in a grid layout. You can also choose to view graphs in a row layout, which allows each graph to span the width of your screen. If there are specific graphs that you want to view, you can further customize the dashboard by adding, removing, or dragging individual graphs to specific locations.

Preset and dynamic zooms

Preset and dynamic zoom

Leverage preset and dynamic zooms

 

Our Zoom feature allows you to specify the timeframe for database metrics that you’d like to view. For example, if there’s an incident that occurred within the past hour, you can use the “1 HR” zoom option to filter out irrelevant information.

For further granularity, you can also highlight over a section of interest on any chart.

Highlight over the section of interest

 

This action provides a custom zoom that allows you to closely examine metric values.

Time lock

Frozen point-in-time

Lock a point-in-time for all metrics

 

Once you have your desired zoom set, you can lock your cursor by double-clicking on any point on a graph. This locked point in time will propagate to all the charts, making it easy to compare metrics at the same point in time.

Real-time stats

Sometimes you want to view real-time performance metrics. You can access your real-time dashboard in Telemetry by clicking on “View real-time stats” in the upper right-hand corner.

Accessing Telemetry

Once you log in to the MongoLab management portal, you can access Telemetry two different ways:

  • From your account’s Home page, locate the deployment whose stats you want to view and click on the graph icon at the end of the row. You can choose to view metrics for any member in your deployment.
  • From the deployment’s Home page, click on the “Monitoring” tab, locate the server whose stats you want to view and click on the “open historical” link at the end of the row.

Happy monitoring!

We hope Telemetry helps you become even more productive with MongoDB. If you’re new to MongoLab, you can get started with Telemetry by provisioning any for-pay plan. Please keep in mind that Telemetry is in alpha, which means it may be subject to occasional downtime and clearing of historical data.

We greatly value your feedback during the alpha period so please feel free to email support@mongolab.com with bug reports or general comments.

 

{ "comments": 4 }

Fully managed Dedicated MongoDB plans on Heroku

We’re excited to announce that a new line of production-ready Dedicated replica set plans are now available through the MongoLab add-on on Heroku!

Our fully managed Dedicated plans run on dedicated virtual machines (VMs) and offer guaranteed resources (RAM/IO/CPU), SSD-backed disks, and seamless zero-downtime scaling.

By using the MongoLab add-on on Heroku, teams can easily navigate between administering their Heroku application and their MongoDB deployment(s) via our integrated management portals and receive consolidated billing from Heroku for all their applications’ services.

Fully managed MongoDB-as-a-Service

MongoLab’s Dedicated plans come with:

Highly Available MongoDB Cloud Hosting

Provision a production-ready replica set with a few clicks.

  • Dedicated virtual machines
  • SSD-backed block storage (EBS) volumes
  • Multi-zone replication and automatic failover using MongoDB Replica Sets

MongoDB Management Tools

Manage current database operations, stream real-time logs, and perform other essential DBA functions through our MongoDB management GUI.

  • Free daily customizable backups with easy restore
  • Real-time and historical monitoring of key performance metrics
  • Automated query analysis and index recommendations
  • Tools to find and kill running database operations
  • Custom firewall configuration 

MongoDB Support

In addition to MongoLab’s standard timely email support, our Dedicated plan users get premium support.

  • 24×7 emergency support hotline
  • Expert advice on performance tuning and data modeling
  • Pre-production “health checks” to make sure you are ready to go live

Available in Heroku’s US and EU regions

All MongoLab plans available through Heroku’s add-on program are available in both Heroku’s US and EU regions.

It is highly recommended that teams deploy their MongoLab database into the same AWS region as their Heroku application. This keeps network traffic internal to the region which minimizes latency and maximizes security.

Resources for getting started

If you’re new to MongoLab and Heroku, we have free Sandbox plans with 500MB of storage to help you get started. These plans should be used for development and testing only.

We also have published some resources to help you quickly get up and running:

Production-ready MongoDB made easy

If you’re unsure about which plan you need or are just getting started with MongoDB, you can reach out to the MongoLab team at support@mongolab.com anytime. We look forwarding to hearing from you!

Fully managed MongoDB replica sets for $15

We’re very excited to announce $15 Shared Cluster plans across all major cloud providers (AWS, AzureGoogle, et al.) on MongoLab! MongoDB replica set clusters offer many benefits to developers, the biggest being high-availability. Any application in production needs a highly-available database to minimize downtime. At $15/GB per month, weekend hackers and teams on a tight budget can now afford to rest easy knowing that their application is backed by a highly-available MongoLab database. Continue Reading →

{ "comments": 1 }

Custom firewalls for your MongoDB deployment(s)

Update 6/16/2016: Updated references to old UI

MongoLab runs all of its hosted MongoDB deployments with authorization enabled, which means that username / password authentication is required before your database can be accessed.

For lower-level network security we also allow you to configure custom firewall settings. This feature is available to all MongoLab users on Dedicated plans.

Configuring custom firewalls

If you have yet to configure a custom firewall, you’ll notice a new Networking tab from your deployment view. By default, your firewall configuration will include 0.0.0.0/0, which allows all traffic to your database.

networking-tab

 

To lock down your deployment, we allow three options for configuring new firewall rules. You may:

  • Whitelist IP addresses
  • Whitelist Amazon EC2 Security Groups
  • Copy existing rules from one deployment to another

Whitelisting IP addresses

MongoLab can configure your firewall to limit access to only the IP address(es) (or address ranges) you specify. We use CIDR rules to define the allowable address(es) and secure access to your MongoLab-hosted Dedicated plan databases.

Whitelisting Amazon EC2 security groups (AWS only)

If your Dedicated plan database is hosted on AWS and your application is running from the same AWS region and on EC2-Classic, we recommend allowing access to Security Group(s) instead of IP addresses. This way you won’t need to change your database deployment’s firewall rules as you spin up/down your app servers.

To control access to your MongoLab-hosted database using your EC2 security group, you’ll need to provide your AWS account ID (a 12-digit number) and the name or ID of your Security Group(s).

Copy existing rules

If you have already configured custom allow rules for one MongoDB deployment in your MongoLab account, you can copy these rules to any other Dedicated plan deployment in your account. Simply select which deployment you want to copy from, and we’ll take care of the rest!

Security is our priority

MongoLab takes the security of MongoLab accounts and deployments seriously. We are continuously working to improve the features and tools that increase the safety of your data. To find up-to-date information on what security features are available to MongoLab users, visit our documentation portal. As always, if you have any questions or feedback you can reach us at support@mongolab.com.

{ "comments": 3 }