The scripts are available at github. Only tested on Ubuntu 12.04 LTS.
As default (for my dev env) each container will get its own separate mounted /opt (under host's /opt/lxc/\) and /mnt/dbext4 (/mnt/dbext4/lxc/\) and /mnt/dbxfs (/mnt/dbxfs/lxc/\). Containers will be named as 'name-seqno'. Paths/defaults can be changed by editing etc/config. There are no shared disks between the containers. Install:
$ fdisk /dev/sdc
Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel with disk identifier 0xec3e2922.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.
Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)
The device presents a logical sector size that is smaller than
the physical sector size. Aligning to a physical sector (or optimal
I/O) size boundary is recommended, or performance may be impacted.
sysbench is a popular system peformance benchmark tool and has a database OLTP benchmark module which is popular among MySQL users. We are going to use it to create the default OLTP schema that is used and run a light test.
The purpose is not to really bench our newly deployed Galera cluster but to get some test data that we can pull out from our web servers that we setup previously.
In the next following posts we’ll deploy a multi-master synchronous MySQL Galera Cluster with Amazon’s VPC service. We’re going to create a public facing subnet for app/web servers and a private subnet for our database cluster.
The deployment will look similar to the below diagram.
Amazon’s VPC provides a secure environment where you can chose to isolate parts of your servers by having complete control of how to deploy your virtual networking infrastructure much like your own datacenter.
The steps that we’ll go through are as following:
Create a VPC with Public and Private subnets
Define Security Groups (add rules later)
Launch one instance for ClusterControl
Launch three EBS optimized instances for the Galera/database nodes
Format and mount an EBS volume (or RAID set) for each Galera nodes
Create a Galera Configuration with Severalnines Galera Configurator
Deploy and bootstrap Galera Cluster
Add an internal load balancer
Add a MySQL user for the internal load balancer
Add web server instances
Add an external load balancer
Test the VPC database cluster setup
At the end we have the following instances available on the public subnet (Note your IP addresses would be different):
1 Elastic External Load Balancer, Elastic IP 188.8.131.52
2 Web servers: IP 10.0.0.28, Elastic IP 184.108.40.206 and IP 10.0.0.38, Elastic IP 220.127.116.11
1 ClusterControl server: IP 10.0.0.53, Elastic IP 18.104.22.168
and on the private subnet:
1 Elastic Internal Load Balancer, IP 10.0.1.17
Galera Node 1, IP 10.0.1.13
Galera Node 2, IP 10.0.1.16
Galera Node 3, IP 10.0.1.26
In this example going forward we only deploy one private subnet however if you require a more fault tolerant setup you can for example create two private subnets for the database cluster one in each Availability Zone (AZ) which can protect you from single location failures within a single Amazon region.
There are a number issues that needs to be handled properly with a Galera cluster across two regions and/or AZs (which practically is two data centers). This will be addressed in a future post.