synapse unsync

This is a brief look at the use of vReplicator from Vizioncore for replicating VMWare VMs to a disaster recovery site. The information is based on my experiences in setting up this environment for my employers.

Main site is a VMWare ESX 3.5 HA cluster (Intel CPUs) and SAN with multiple VMFS filesystems. Remote site (300K from main office) is a single VMWare server (AMD CPUs) with 2 VMFS filesystems on RAIDed internal storage. The 2 sites are connected by 10Mbps optical fibre. Both sites are managed through Virtual Center which is installed into a VM in our main site. To backup our main site VMs (including Virtual Center) we decided to use vReplicator from Vizioncore.

Installation was very easy, just run the installer and follow the prompts to set it up - we installed vReplicator into the same VM as our Virtual Center installation. vReplicator logged in to our VC and discovered our HA cluster, the VMs it contained and also our remote server and its VMs.

Using it was just as easy, you select the VM you want to replicate, click the “Create Job” link and complete the details. There are dropdowns for resources like VMFS filesystems on the target and you can select which of the VM’s disks replicate to which remote VMFS filesystem.

Which type of replication? We used what vReplicator refers to as “Differential” replication which is essentially a point-in-time comparison of original and replicated VMs and uses a VM snapshot to capture changed data. The other type of replication supported by vReplicator is called “Hybrid”. Hybrid replication uses a “change over time” model to identify what should be replicated. It is faster because there is no need to scan during the replication pass but uses more disk space for its (2) snapshots. It was largely because of constraints on the amount of disk space available for snapshots that we selected “Differential” replication.

Once you save a job you can leave it to autostart at the time/date you designated or you can run the job now by clicking the “Run” menu item for the job. The first replication takes quite some time as the entire VM has to be copied. Subsequent runs are much quicker. In our case a replicate job for a fairly static VM which took 3 hours for the first run takes around 30mins for 2nd and subsequent runs; another job for our main SQLServer2005 VM which took 11 hours for the first run takes about 2-3 hours for 2nd and subsequent runs.

At the moment we are replicating 4 VMs, all Windows 2003, including our Virtual Center VM and 2 SQLServer database installations (different vesions). Shortly we will be adding Centos 5.x Linux VMs with our mailserver and Samba installations.

So vReplicator in a nutshell, easy to install, easy to setup and configure and easy to run. Things to watch out for are that you have enough space for the snapshots that vReplicator uses and that you have enough bandwidth to move the amount of data you want to move in the time window you have available.

Separately to the VM replication outlined above we have an additional Linux VM in our remote site which has a redundant DNS server, a synchronised OpenLDAP replication configuration and a redundant RADIUS server. These servers provide secondary DNS, radius and authentication services for both our main site, our remote site and regional offices.

No comments »

Postgres triggers are created in 2 stages, firstly you create the trigger function then you link the function to the trigger event. In this sample code a function that fires during before an INSERT event updates a column in the table where the data is being inserted. The function uses an internal (SQL92 compliant) string manipulation function to create the additional data that is required to complete the insert. The column has been defined as char (8), the data being manipulated is a postgres date type and must be cast to a text type. Note also that text types are indexed starting at a base of 1 (not 0 as with ‘C’ character arrays).

CREATE OR REPLACE FUNCTION set_initial_pass() RETURNS trigger AS $set_initial_pass$
DECLARE
yyyy char(4);
mm   char(2);
dd   char(2);
BEGIN
yyyy := substring(cast(NEW.dob as text) from 1 for 4);
mm   := substring(cast(NEW.dob as text) from  6 for 2);
dd   := substring(cast(NEW.dob as text) from 9 for 2);
NEW.initial_code := dd||mm||yyyy;

RETURN NEW;
END;
$set_initial_pass$
LANGUAGE 'plpgsql' VOLATILE COST 100;
ALTER FUNCTION set_initial_pass() OWNER TO script;

Now create the trigger and attach the function above.


CREATE TRIGGER set_initial_pass
BEFORE INSERT
ON person
FOR EACH ROW
EXECUTE PROCEDURE set_initial_pass();


This example was created using pgadmin III.

No comments »