By Yan Aksenfeld, Member of Technical Staff, VMware

This 4-part blog post series discusses the addition of MongoDB to Mirage.

Part 1 introduced the benefits of adding MongoDB to Mirage to enhance the performance of Mirage when working with a large number of small files.

This blog post discusses new MongoDB components in Mirage, designing Mirage for high availability, and MongoDB considerations of Mirage installations and upgrades.

New MongoDB Components in Mirage

Mirage has several MongoDB components:

• MongoDB database, preferably replicated
• VMware Mirage MongoDB service
• VMware Mirage MongoDB Arbiter service

Primary and secondary MongoDB databases are recommended for high availability. Future blog posts in this series will discuss database replication.

When you install the Mirage Management server, the VMware Mirage MongoDB service is also installed, as shown in the Windows Control Panel applet:

The MongoDB service handles the read and write operations of all the small files used by Mirage. The VMware Mirage Management service manages the MongoDB service and maintains the overall configuration of the MongoDB environment as follows:

• If no MongoDB database exists in the location configured for it during Mirage installation, the Mirage Management service creates one.
• If a secondary MongoDB database has been created for high availability, the Mirage Management service creates an object called a replica set. The replica set maintains replication in a high-availability environment.
• If the MongoDB service is stopped, the Mirage Management service starts it.
• If the MongoDB service is marked as disabled, the Mirage Management service keeps it disabled. (If you manually start the MongoDB service, the Mirage Management service stops it again.)

The VMware Mirage MongoDB Arbiter service is also automatically installed on each Mirage Server, although it will be active only on one of them. The Arbiter service determines the MongoDB failover server in the event that one of the nodes fails. A Mirage administrator should not configure or work with the Arbiter service directly. For more details, see Replica Set Arbiter.

Part 1 of this series showed a figure illustrating an implementation of Mirage with the introduction of MongoDB. Here is a more detailed version.

Figure 1: Detailed MongoDB Architecture with VMware Mirage

You might have noticed in this diagram that unlike in earlier diagrams of Mirage, there are two Mirage Management Servers. This is now the recommended architecture to prevent a single point of failure. As we discussed before, MongoDB stores all small files used by Mirage. It is important to protect the MongoDB database from corruption, and this is done with two Mirage Management Servers. Each Mirage Management Server manages a separate MongoDB database replica, and the primary node is replicated to the secondary node. If the primary node fails, the system continues working with the secondary node. These separate MongoDB database replicas should be stored in different locations. Each location should provide low-latency access (<5 ms) and must be constantly available to the service that uses it. See Designing a Mirage System for High Availability with MongoDB for recommendations.

You can monitor the status of MongoDB in the Management Servers tab of the Mirage Web Manager. If the status of a Mirage Management Server is Up, then the MongoDB service is enabled and running. See the Mirage Web Manager Guide for more details.

Figure 2: Mirage Management Server Status

Note: VMware recommends installing and using the Mirage Web Manager, because the Mirage Console (formerly the Mirage Management Console) will be deprecated soon. All new features since Mirage 5.3 are available only in the Mirage Web Manager (this includes monitoring, moving, and configuring MongoDB), so using it is imperative for successful management of Mirage.

Designing a Mirage System for High Availability with MongoDB

As Figure 1 shows, VMware introduced several new MongoDB components in Mirage 5.4. For high availability, there are two important requirements for deploying Mirage 5.4 and later, or for upgrading to such a version:

1. A second Mirage Management server, which should be identical in hardware to the first server. Both servers must be available at all times and connected to replicas of the same MongoDB database. The MongoDB service must also be active on each Mirage Management server. If only one Mirage Management server is available, you will notice a pop-up window in the Mirage Web Manager, and a banner will also be displayed at the top of the Mirage Web Manager:
   
2. For each of the two Mirage Management servers, a separate storage location is required for locating MongoDB replica database files. It is extremely important to have highly available disks with low latency for each Mirage Management server. The best practice is to place MongoDB on a dedicated local disk with no other files except for the data automatically created by Mirage for MongoDB. If such a disk is not available, a highly available SAN disk can suffice, especially when the Mirage Management server is a virtual machine—but make sure the datastore is located on stable storage.

In Mirage 5.4, the MongoDB database was automatically placed in the same location as the Mirage storage. This practice is no longer recommended, and in Mirage 5.5 and later, VMware allows choosing a location for MongoDB during the installation process. Therefore, VMware recommends installing Mirage 5.5 or later when upgrading from an earlier version.

For additional details on where to place MongoDB and how to correctly size the disks, see the Knowledge Base article Mirage Mongo DB location and sizing best practices (2132759).

Installing or Upgrading Mirage

When you install Mirage 5.5 or later, or you upgrade to it from Mirage 5.3 or earlier, you can choose the location to place MongoDB. For each instance of Mirage Management server, choose separate, dedicated local disks on which to place the MongoDB database files. Do not point both Mirage Management servers to the same shared location.

Figure 3: MongoDB Database Location

After both Mirage Management servers are installed, make sure both show as Up in the Mirage Web Manager. To confirm, click Servers, and click Management Servers.

Figure 4: Mirage Management Server Status

Upgrading Mirage with an Existing MongoDB Database

When upgrading from a Mirage version that already has a MongoDB database (for example, from Mirage 5.4), you do not get the dialog box to choose a location for MongoDB, and MongoDB remains in its original location. In Mirage 5.4 installations, MongoDB was located with Mirage storage, and this location will be retained after upgrading to 5.5 or later.

If you wish to move the MongoDB database, you need to move it after the installation is complete. Mirage 5.6 introduced a feature to the Mirage Web Manager to do this, but it is not available in earlier versions or in the Mirage Console. For more information on how to move MongoDB, see Changing the location of MongoDB when in use by Mirage (2131044).

It is important to monitor both MongoDB nodes and to make sure they are both online at all times for full replication and protection.

Summary of Part 2

In Part 2 of this blog post series on Mirage and MongoDB, you learned about

• Two new services that are installed and what they do.
• Designing Mirage for high availability.
• Installing and upgrading Mirage when MongoDB is involved.

Part 1 introduced the benefits of adding MongoDB to Mirage.
Part 3 takes a closer look at the underlying technology behind MongoDB and Mirage.
Part 4 provides information on troubleshooting MongoDB issues.