How to setup availability sets on Windows Azure and deploy an MVP that will be….available….

A few weeks ago we wrote a post about “How to launch your MVP in a budget with BizSpark” at the Apirise blog. The post briefly explains how someone can build an early MVP with BizSpark and Azure without binding to the Microsoft technologies stack! This post is a sequel of the original post but a bit more technical this time.

What we’ll try to do in this post, is to demonstrate how we can deal with the “availability” of our application (or MVP in the current context) when we build it on a cloud platform like Azure. For this reason we’ll discuss concepts like the “Availability Sets” of the Azure cloud platform and what technologies we can use in order to utilize the availability that the cloud service offers to us. We’ll mess a bit with replication but having the availability in mind and not the scalability of our application, although the same principles more or less apply also when we want to scale our application.

So we’ll proceed by building an environment consisting of an Ubuntu server + Nginx (or apache) web server + MySQL + ElasticSearch on Microsoft Azure. I assume that this stack is quite common for many application and at the end we’ll also be able to identify what difference makes when a piece of software is written from the beginning with replication and in mind (yep I’m refering to the difference between ES and MySQL, in setup terms).

Let’s start…

Continue reading

Advertisements

How to setup ElasticSearch with Replication on a Windows Azure Availability set of VMs

Installing Elastic Search

If you wonder why we care about availability sets you better read here

Now to the final ingredient of our uber stack of technologies that will form the foundation of our awesome new product ;), ElasticSearch. Installing ElasticSearch is a quite straightforward process, you just download a binary file and run it, although as we’ll see below running ElasticSearch on a multi-node environment and especially on a cloud infrastructure like Azure, is a bit more complicated process.

Running ElasticSearch in a Multicast friendly environment in a multi-node setup is also a straightforward process that involves mainly the proper configuration of your individual nodes together with setting in the configuration a cluster name that will be used for auto-discovery, after that you run all your nodes and ElasticSearch does its magic and the nodes will join your cluster. But this can happen only in environments that multicast is supported, in Windows Azure Multicast is not supported and thus we cannot rely on it for auto-discovery.

Continue reading

How to Setup MySQL (MariaDB) with Master-Master Replication on a Windows Azure availability set of VMs

Installing MySQL (actually MariaDB)

If you wonder why we care about availability sets you better read here

By just having two instances of a database on two different VMs, doesn’t offer much even if the VMs are members of an availability zone. In order to make something out of the configuration of our machines we need the data that our application generates to be replicated between the two databases.

Replication is a quite rich and compilcated subject, the most common replication pattern is the simple master-slave replication in which one “master” node takes care of all the application writes while a number of “slave’ nodes are only reading the data, on top of that basic concept it is also possible to have failover configurations and other desirable characteristics on the DB cluster. The issue in this approach is what will happen if the “master” node fails, and although there might be solutions to that, e.g. having more than one “master” node, here we are having a situation with limited resources and thus we cannot really afford to have sets of master and slave nodes. In our case we would like to follow a master-master configuration where each node is able to accept writes and distribute them throughout the cluster. In this way we can redirect all traffic on one of the VMs we have on Azure, the writes will be replicated also on the second VM and in the case where something happens to the first node, automatically the second one will continue serving the application.

Continue reading