This document provides an overview of using MongoDB in Windows Azure. It discusses the differences between using Platform as a Service (PaaS) vs Infrastructure as a Service (IaaS) and recommends using IaaS to have more control. It also covers MongoDB deployment options like replica sets and sharding in Azure. Several drawbacks of Azure disks, instances rebooting, and connection timeouts are discussed along with workarounds.

1. MongoDB in Windows Azure
Evgeniy Maliy, QA engineer

2. Cloud Service
Brief introduction to Windows Azure
Cloud Service
Azure VM Azure VMAzure VM
private port
public port
private
port
public
port 1
private
port
public
port 2
private
port
public
port 3
Common DNS name
and public IP
publicport
private
port
Standalone endpoints
Load balanced
endpoints
Round-robin load balancer
Azure Vnet
Affinity group

3. Are in the same Azure Location (Datacenter)
Brief introduction to Windows Azure
Azure VM
Cloud service Azure storage
vhd
http

4. Which to use PaaS or IaaS ?
It’s up to you

5. Endpoints overview
Standalone endpoint
- Is created for one particular virtual machine.
- One particular public port can be opened once within given cloud
service. The same public port can’t be opened for another VM in
cloud service.
- One particular private port can be opened (via endpoint) once per
virtual machine. You can open the same private port for another VM
within the same cloud service.
- One Virtual Machine can have several endpoints.
- Request comes to the public port of the endpoint of cloud
service, endpoint gets it and sends to corresponding Instance (Virtual
Machine) using private port.
Cloud Service 1
private
port
27017
public
port
27017
VM nVM 1
private
port
27017
public
port
27017
private
port
27017
public
port
27018
private
port
27017
public
port
27017
private
port
27017
public
port
27017
private
port
80
public
port
80

6. Endpoints overview
Load balanced endpoint
- Is only one way to open the same public and private ports for all
virtual machines in cloud service.
- It is load balanced.
- Round-Robin load balancing principle is applied
Cloud Service 1
VM nVM 1
private port 27017
public port 27017

7. Which deployment to use for mongoDB: Replica set
Cloud Service
Secondary 1 Secondary 2Primary
private
port
27017
public
port
27017
private
port
27017
public
port
27018
private
port
27017
public
port
27019
Common DNS
name and public IP
Client
WRONG
until
Such configuration
will work
cloud service goes
down.
If it is down you will
lose whole replica set !

8. Which deployment to use for mongoDB: Replica set
Cloud Service 1
private
port
27017
public
port
27017
Primary
Client
private
port
27017
public
port
27017
Secondary1
Cloud Service 2
private
port
27017
public
port
27017
Secondary2
Cloud Service 3
DNS name 1 DNS name 2 DNS name 3

9. How about sharding ?
Client
Replica set 1
Primary
instance
Secondary
instance 1
Secondary
instance 2
Replica set 2
Primary
instance
Secondary
instance 1
Secondary
instance 2
Config
instance 3
Config
instance 2
Config
instance 1
Router (mongos)
instance

10. Which instance configuration is suggested for running
mongoDB
VM
Instance
-Has 127 GB OS disk (drive C)
-Has temporary disk (drive D)
Vhd1 (Drive E)
Vhd3 (Drive G)
Cloud service
Are running in the same Affinity Group
Vhd2 (Drive F)
- Store journal files on separate disk
located in the cloud storage (disk G):
Shut down mongod process and run
following script in cmd:
mkdir G:journal
cd /d E:datadb
rmdir journal
mklink /d journal G:journal
- Do not store data on the OS disk
- Do not use temporary drive at all
- Store data on separate disk located in
the cloud storage (disk E):
Set dbpath E:datadb setting in config
file or as option when start mongod
- Store mongoDB logs on separate disk
located in the cloud storage (disk F) :
Set logpath F:mongodblogmongo.log
setting in config file in config file or as an
option when start mongod

11. Instances of which sizes to use for running mongoDB
Size
CPU
cores
Memory
Bandwidth
Disk sizes –
virtual machine
Max. data disks
(1 TB each)
Max. IOPS
(500 per disk)
ExtraSmall Shared 768 MB 5 Mbps OS = 127 GB
Temporary = 20
GB
1 1x500
Small 1 1.75 GB 100 Mbps OS = 127 GB
Temp = 70 GB
2 2x500
Medium 2 3.5 GB 200 Mbps OS = 127 GB
Temp = 135 GB
4 4x500
Large 4 7 GB 400 Mbps OS = 127 GB
Temporary = 285
GB
8 8x500
ExtraLarge 8 14 GB 800 Mbps OS = 127 GB
Temporary = 605
GB
16 16x500
Not
recommended
for mongoDB

12. Drawbacks and workarounds : Disks performance
vhd
blob file
500 IOPS !!!
Storage account
10 GBs
bandwidth
Azure VM
Bandwidth depends on size of VM
mounted over network
- Deploy as big Azure instance as you can to get better
bandwidth
- Place one virtual disk per storage account
- Place your storage accounts and virtual machine in the same affinity group
- Enable caching for virtual disks.
In our case:
enable Read/Write caching for disks which store data and logs
but do not enable caching for disk with journal files
Caching
- None
- Read
- Read/Write
- Fairy tale of space preallocation problem

13. Drawbacks and workarounds : Disks capacity
There is a capacity limit for each
virtual disk: it can be max. 1 TB
Workaround or solution?
Sharding only !

14. Drawbacks and workarounds : Instances rebooting
Microsoft takes care of us:
- once in 2-3 weeks patches our instances with latest security updates
- Installs OS updates for us
- And reboots our instances as a result !
- Without any wornings or notifications!
Solution?
- If you are running IaaS, just disable automatic Windows Updates.
- If you are running PaaS, you can do nothing about this!
Maybe configuring an availability set for virtual machines can solve this.
Anyway you need to handle this in code or mongoDB settings

15. Drawbacks and workarounds : Not persistent public IP
Public IP 1
Global DNS name:
[nameOfCloudService].cloudapp.net
Microsoft doesn’t guarantee
that your public IP will never
change
While cloud service is
deployed, it has unique DNS
name
If all VMs within cloud service
are down, Public IP is lost, but
DNS name is still assigned to
that cloud service
When you start the VM, it will
get new public IP, but DNS
name is the same
Public IP 2
Solution :
Never use IP addresses in any settings, config files and connection strings.
Use DNS names instead

16. Drawbacks and workarounds : connection timeout for .Net driver
MongoDB
Client
Uses .Net driver
socket timeout exception
Windows Azure terminates an
inactive connection after
roughly 4 minutes of idling
MongoDB suggests:
Set the max idle connection time on the driver:
MongoDefaults.MaxConnectionIdleTime = TimeSpan.FromMinutes(1);
My experience:
Add following options to connection string:
maxIdleTimeMS=60000;connectTimeoutMS=60000;socketTimeoutMS=60000
Sample of connection string:
connectionString="mongodb://localhost/mydb ?maxIdleTimeMS=60000;connectTimeoutMS=60000;socketTimeoutMS=60000"

17. Useful tools:
- Windows Azure SDK
- Worker roles in Windows Azure mongoDB solution
- Windows Azure Powershell cmdlets
- RDP connection to Instances
-Cerebrata Tools for windows azure
- MongoDB management service (MMS)