Your Mission Critical Applications Deserve Real Backup Validation!

accident disaster steam locomotive train wreck

Photo by Pixabay on

Every organisation knows how important data protection is. However still most of the organisations never test their backups. Why? Because it is complex issue. However if you do not test how do you know that you can really survive from disasters?

Modern Approach for Data Protection

First step for Data Protection is of course thinking it in modern ways. Even that most of the restores from backups are still individual files and/or folders your organisation has to prepare for bigger disasters. What if half of your 500 VM production environment is hit by ransomware attack? How do you really survive from these types of disasters? Restore times with so called legacy backups might take days, even weeks. Can your business survive without access to these VMs for weeks, propably not.

Data protection depends upon timely backups, fast global search, and rapid recovery. Cohesity DataProtect reduces your recovery point objectives to minutes. Unique SnapTree technology eliminates chain-based backups and delivers instantaneous application or file-level recovery, with a full catalog of always-ready snapshots even at full capacity. With this approach it can dramatically reduce recovery time.

However even modern data protection is not enough if you don’t know that you really have something to recover to. Most of the modern technologies handle file system level data integrity but still there is no way to really know that your backups are fully recoverable without testing them.

From Data Protection to Recovery Testing

Typically organisations approach recovery testing with either just recovering single (or multiple) virtual machines. This of course makes sure that you can recover individual VMs but it doesnt ensure that you can recover something that is truly working. Some backup vendors implement recovery testing, but still it is mostly just VMs or some basic uptime testing.

Other way to do this is manually restore application setups and do manual testing. This is very costly because it requires lot’s of manual work, and also introduces several risks. However it enables your organisation to really test application workflows with proper testing. Do you really get answer from your 3-layer web application, can you get answers to your DB queries etc. What if you could take this method of running complex testing but without any need for manual labour?

Automating Recovery Testing

Because modern hypervisor platforms are API driven it is pretty easy to automate things on VM level. When you add API driven data protection platform, like Cohesity, you can automate full recovery testing with very complex testing. This is a issue I hear from most of my Service Provider customers – but also from bigger enterprise customers. How to automate complex recovery testing? Lets see….

Cohesity Backup Validation Toolkit

To make things simpler, you can download Cohesity Backup Validation toolkit from here and with minimal scripting knowledge it is easy to automate validation process.

After downloading it is time to create some config-files. Lets start with environment.json -file. This file contains connection information for both Cohesity, and VMware vSphere environments. Create file with content:

        "cohesityCred": "./cohesity_cred.xml",
        "vmwareServer": "",
        "vmwareResourcePool": "Resources",
        "vmwareCred": "./vmware_cred.xml"

After this we need to create actual config.json -file containing information about each virtual machine we are about to test.

This file also defines tests per VM so it is very easy to define multiple tests but only use selected per VM. Script also enables you to attach VM to needed test network, and change IP address to different for testing purpose so you don’t need to test with overlapping production IPs, or create siloed networking for VMware.

Note that VMs don’t need to be protected with same protection job making this more scalable since propably you have different job for web frontends and actual backend databases.

    "virtualMachines": [
            "name": "Win2012",
            "guestOS": "Windows",
            "backupJobName": "VM_Job",
            "guestCred": "./guestvm_cred.xml",
            "VmNamePrefix": "0210-",
            "testIp": "",
            "testNetwork": "VM Network",
            "testSubnet": "24",
            "testGateway": "",
            "tasks": ["Ping","getWindowsServicesStatus"]
            "name": "mysql",
            "guestOS": "Linux",
            "linuxNetDev": "eth0",
            "backupJobName": "VM_Job",
            "guestCred": "./guestvm_cred_linux.xml",
            "VmNamePrefix": "0310-",
            "testIp": "",
            "testNetwork": "VM Network",
            "testSubnet": "24",
            "testGateway": "",
            "tasks": ["Ping","MySQLStatus"]

And then final step is to create actual credential files. To prevent having usernames and password in configuration files in plaintext format we can use  simple powershell script to create these. You can have one shared credential file for all VMs, or you can have one per VM. Note that these users must have administrator level access to VMs to change IP network to test network.

To create credential files you can use included createCredentials.ps1 script which will create only one guestvm_cred.xml file but if you want to create more you can just simply run simple powershell command:

Get-Credential | Export-Clixml -Path guestvm_more.xml

Since this file is encrypted it can be only accessed with same user who created file, so make sure that you create credential files with same user you are using for running testing scripts.

So How Does it Work?

Here is an example run to clone two virtual machines (one Linux and one Windows) and run different set of tests on each VM.

First script gets configuration files and connects to Cohesity cluster and VMware vSphere vCenter environments. Then it will start clone process for VMs



and after clone process is done it will move to actual validation phase where we will first check that clone task is in success state and actual VMware VM’s are powered on with VMware Tools running in VMs cloned.


When VMs are up and VMware Tools are running we will run test per VM to ensure that we can push scripts trough VMware Tools. Next task is to move VMware VM to correct VM Network and then change IP configuration for each VM.


After moving VMs to correct network we will run tests for each VM


and after running tests we will clean clones automatically from Cohesity and VMware environment



This automation toolkit is not officially provided by Cohesity. Any bugs can be reported to me directly. There are some limitations with this toolkit:

You can use it only for VMware environments running vCenter

You can run tests only against Linux and Windows virtual machines and Windows machines need to have PowerShell installed.

Hope that this simple toolkit helps you to automate your organisations backup validations!

Setting up open virtualization system (oVirt)

In this post I’ll demonstrate how easy it is to setup open virtualization system with hypervisor and management. oVirt is based on Red Hat’s Red Hat Enterprise Virtualization manager (RHEV-M) and Red Hat Enterprise Virtualization hypervisor (RHEV-H).

So lets start with installing some prerequisite packages:

[root@ovirt-manager ~]# yum install -y wget postgresql-server postgresql-contrib pgadmin3 java-1.6.0-openjdk-devel

Next we’ll add new repository for ovirt:

[root@ovirt-manager ~]# wget -P /etc/yum.repos.d/

Final step is to install actual ovirt-manager packages:

[root@ovirt-manager ~]# yum install -y ovirt-engine ovirt-engine-setup

Now we have all needed packages installed and we can configure manager.

[root@ovirt-manager ~]# engine-setup
Welcome to oVirt Engine setup utility
HTTP Port  [8080] :
HTTPS Port  [8443] :
Host fully qualified domain name, note that this name should be fully resolvable  [ovirt-manager.demo.local] :
ovirt-manager.demo.local did not resolve into an IP address
User input failed validation, do you still wish to use it? (yes|no): yes
Password for Administrator (admin@internal) :
Warning: Weak Password.
Confirm password :
Database password (required for secure authentication with the locally created database) :
Warning: Weak Password.
Confirm password :
Organization Name for the Certificate: Demolab
The default storage type you will be using  ['NFS'| 'FC'| 'ISCSI']  [NFS] :
Should the installer configure NFS share on this server to be used as an ISO Domain? ['yes'| 'no']  [yes] : yes
Mount point path: /install
Display name for the ISO Domain: install
Firewall ports need to be opened.
You can let the installer configure iptables automatically overriding the current configuration. The old configuration will be backed up.
Alternately you can configure the firewall later using an example iptables file found under /usr/share/ovirt-engine/conf/iptables.example
Configure iptables ? ['yes'| 'no']: yes

oVirt Engine will be installed using the following configuration:
http-port:                     8080
https-port:                    8443
host-fqdn:                     ovirt-manager.demo.local
auth-pass:                     ********
db-pass:                       ********
org-name:                      Demolab
default-dc-type:               NFS
nfs-mp:                        /install
iso-domain-name:               install
override-iptables:             yes
Proceed with the configuration listed above? (yes|no): yes

After this setup might take while, but in few minutes you should get output like below:

Configuring oVirt-engine...                              [ DONE ]
Creating CA...                                           [ DONE ]
Setting Database Security...                             [ DONE ]
Creating Database...                                     [ DONE ]
Updating the Default Data Center Storage Type...         [ DONE ]
Editing JBoss Configuration...                           [ DONE ]
Editing oVirt Engine Configuration...                    [ DONE ]
Configuring the Default ISO Domain...                    [ DONE ]
Configuring Firewall (iptables)...                       [ DONE ]
Starting JBoss Service...                                [ DONE ]

 **** Installation completed successfully ******

     (Please allow oVirt Engine a few moments to start up.....)

Additional information:
 * There is less than 4 GB available free memory on the Host.
It is  recommended to have at least 4 GB available memory to run the RHEV Manager.
 * Keystore already exists, skipped certificates creation phase
 * A default ISO share has been created on this host.
   If IP based access restrictions are required, please edit /install entry in /etc/exports
 * The firewall has been updated, the old iptables configuration file was saved to /usr/share/ovirt-engine/conf/iptables.backup.074609-01032012_1691
 * The installation log file is available at: /var/log/engine/engine-setup_2012_01_03_07_44_46.log
 * Please use the user "admin" and password specified in order to login into oVirt Engine
 * To configure additional users, first configure authentication domains using the 'engine-manage-domains' utility
 * To access oVirt Engine please go to the following URL: http://ovirt-manager.demo.local:8080

If you get database creation error, please check the database installation log. If there’s lines saying “Peer authentication failed for user “postgres”” please change authentication method in pg_hba.conf to trust and restart your postgresql-service and run installer again.

Next step is install ovirt-node (Hypervisor). It’s really simple and straightforward. Just get latest iso from and boot your hypervisor machine with it, install to local disk and do basic configurations: This shouldn’t take long, there is only few things to do. Select disk where you are installing, type root password and go.


Next thing to do is install more hypervisors and connect them to ovirt-engine. I’ll write another post about this with basic configuration examples. Try oVirt today, it’s really competitive alternative for VMware / Citrix and it’s totally open source 🙂

Implementing IPA-server with windows/linux-environment

Red Hat included IPA-server (FreeIPA) with RHEL6.1 release. FreeIPA is an integrated security information management solution, like Microsoft Active Directory, combining 389 (LDAP server), MIT Kerberos, NTP, DNS. It consists of a web interface and command-line administration tools, so management can be done either with web browser or from command-line. It’s quite easy to implement FreeIPA on Windows/Linux-environment and i’ll show here how you can install, configure and use IPA without any deeper knowledge about Linux.

First step: Install

In my example I have already installed RHEL6.2, but you can use also CentOS or Fedora. I installed RHEL with minimal installation, upgraded all packages and then installed all packages for FreeIPA:

[root@x1 ~]# yum install ipa-* bind bind-chroot bind-dyndb-ldap

This will install all FreeIPA-packages and bind (nameserver) with chroot-option. It will take while, for example in my demo lab it installed 262 packages totally. So run install and relax with cup of coffee while waiting.

After installation completes, we need to check that ipa-servers hostname is set correctly:

[root@x1 ~]# cat /etc/hosts       localhost localhost.localdomain localhost4 localhost4.localdomain4
::1             localhost localhost.localdomain localhost6 localhost6.localdomain6 x1
[root@x1 ~]# hostname

Check that there is line with your servers FQDN, shortname and correct IP-address. If name/ip is not correct, you need to fix them before next step.

Second step: Configure FreeIPA

Now it is time to install and configure FreeIPA. This is really simple:

[root@x1 ~]# ipa-server-install --setup-dns

Installer will ask server host name, domain name and kerberos realm name. Accept default settings if you do not want to change them, you might want to change kerberos realm to short name (Like, DEMO in my example) if you want. You need to write also password for LDAP Directory Manager account and FreeIPA admin-user account, for best practise use different password for accounts.

By default installer will also setup DNS forwarder and reverse zones for you. It will ask IP of your forwared and will automatically create reverse zone for that network.  After this installer will configure all necessary services (This might take while also).

Last phase here is to check that necessary firewall ports are opened, below is example from my iptables-configuration:

[root@x1 ~]# cat /etc/sysconfig/iptables
# Firewall configuration written by system-config-firewall
# Manual customization of this file is not recommended.
-A INPUT -p icmp -j ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 22 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 80 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 443 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 389 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 636 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 88 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 464 -j ACCEPT
-A INPUT -m state --state NEW -m tcp -p tcp --dport 53 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 88 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 464 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 53 -j ACCEPT
-A INPUT -m state --state NEW -m udp -p udp --dport 123 -j ACCEPT
-A INPUT -j REJECT --reject-with icmp-host-prohibited
-A FORWARD -j REJECT --reject-with icmp-host-prohibited

You could also combine ports to one line, but I like to have one line per port. After configuration you can test that everything is working just like it should:

[root@x1 etc]# kinit admin
Password for admin@DEMO.KONEHUONE.FI:
[root@x1 etc]# ipa user-find admin
1 user matched
  User login: admin
  Last name: Administrator
  Home directory: /home/admin
  Login shell: /bin/bash
  UID: 805800000
  GID: 805800000
  Account disabled: False
  Keytab: True
  Password: True
Number of entries returned 1

If you can find admin user your FreeIPA-server is now configured and running fine.

Third step: Configure your Windows/Linux machines to authenticate with IPA

Adding Windows-clients to IPA includes bit more tasks than Linux-clients so we’ll start with Windows one.

Before we add any clients to IPA we need to create user account for user. In my example I will use cli-way, but you could do it from web-ui also:

[root@x1 log]# ipa user-add
First name: Ipa
Last name: Test
User login [itest]: ipatest
Added user "ipatest"
  User login: ipatest
  First name: Ipa
  Last name: Test
  Full name: Ipa Test
  Display name: Ipa Test
  Initials: IT
  Home directory: /home/ipatest
  GECOS field: Ipa Test
  Login shell: /bin/sh
  Kerberos principal: ipatest@DEMO.KONEHUONE.FI
  UID: 805800004
  GID: 805800004
  Keytab: False
  Password: False

Next we need to reset ipatest-users password:

[root@x1 log]# ipa passwd ipatest
New Password:
Enter New Password again to verify:
Changed password for "ipatest@DEMO.KONEHUONE.FI"

Next we need to create also account for client machine. In this example we will add first dns-record for the machine called winxp and then add host-entry to IPA and give host initial password used when connecting host to IPA:

[root@x1 log]# ipa dnsrecord-add
Zone name:
Record name: winxp
[A record]:
[AAAA record]:
  Record name: winxp
  A record:
[root@x1 log]# ipa host-add
Host name:
Added host ""
  Host name:
  Principal name: host/
  Keytab: False
  Password: False
  Managed by:
[root@x1 log]# ipa-getkeytab -s -p host/
-e arcfour-hmac -k -P
New Principal Password:
Verify Principal Password:
Keytab successfully retrieved and stored in:

After this we configure host to use IPA-server. Currently there’s one problem with Windows authentication. You need to have local user where kerberos users are mapped. However local user can be locked, so you cannot log on with them directly but via kerbers-authentication. In my example I’ll use XP machine, and because of that we need to download additional tools and install whole package to get ksetup-tool.

In my example I didn’t create any local users, I just mapped everything to guest-user:

ksetup /mapuser * guest

Final task is reboot the machine and after it you should be able to logon using kerberos acount, in my example ipatest@DEMO.KONEHUONE.FI

Final words

You can do much more with IPA. I will write another post how you can extend usage of your IPA. I think that FreeIPA is really good implementation for any company wanting to avoid usage of Microsoft Active Directory.

Open Virtualization Management with oVirt Project

Finally there’s really good open source alternatives for virtualization management. Yesterday oVirt-project made announcement:

The oVirt project today announced that Canonical, Cisco, IBM, Intel, 
NetApp, Red Hat and SUSE have joined together to help create a new
open source community for the development of open virtualization
platforms, including virtual management tools to manage the
Kernel-based Virtual Machine (KVM) hypervisor. With the oVirt
project, the industry gains an open source, openly governed
virtualization stack.

What this means actually is that Red Hat finally open sourced their RHEV-M and RHEV-H. While we need to wait while for official release (Jan, 2012) you can start testing it today.

Red Hat acquired gluster

Red Hat has announced that it will acquire Gluster. Gluster is the company behind cluster/cloud filesystem GlusterFS. Red Hat explains that the company considers the technologies used in Gluster to be a good fit with its cloud computing strategy. Red Hat will continue to support Gluster customers and will integrate Gluster products into its portfolio over the coming months. It hopes to continue to involve the GlusterFS community in developing the filesystem.

GlusterFS is released under the GPLv3 and is described by the developers as a stackable modular cluster file system, which runs in user space and hooks into the kernel via Fuse (Filesystem in Userspace). Communication between storage nodes and clients is via Infiniband or TCP/IP. GlusterFS scales to the petabyte level and, rather than storing data onto storage media directly, uses proven file systems such as Ext3, Ext4 and XFS.

Varmuuskopiointi käyttäen tiedostojärjestelmän ominaisuuksia

Varmuuskopiointi mielletään usein hankalana asiana, vaikka todellisuudessa hankalaksi se tulee vain koska siitä tehdään hankalaa. Oraclen Solaris-käyttöjärjestelmän käyttämässä ZFS-tiedostojärjestelmässä on useita erinomaisia ominaisuuksia ja yksi niistä on snapshotit, joita voidaan käyttää varmuuskopiointiin. Linuxin käyttämällä LVM:llä, eli loogisilla volyymeillä voidaan hoitaa myös varmuuskopiointi helposti.

Tuotantoympäristöissä usein ongelmaksi muodostuu tilanne jossa useat prosessit käyttävät tiedostoja ja samaan aikaan niistä yritetään ottaa varmuuskopiota. Tämä johtaa siihen että tiedostosta otettu varmuuskopio joko on puutteellinen tai siitä ei voida palauttaa toimivaa versiota, tätä varten on kuitenkin keinot jolla tiedostoista pystytään ottamaan varmuuskopio joka on ehyt.

Ehyt varmuuskopio käyttäen luku-tilaa

Tiedostojärjestelmästä voidaan ottaa ehyt ja toimiva varmuuskopio, kunhan se ensin muutetaan luku-tilaan, joka estää kirjoitukset, ja näin kaikki muutokset jotka saattaisivat sotkea varmusukopion ottamista.

jpj@x1:~$ sudo umount /home
jpj@x1:~$ sudo mount -o ro /home
jpj@x1:~$ sudo tar -cvf /dev/st0 /home
jpj@x1:~$ sudo umount /home
jpj@x1:~$ sudo mount -o rw /home


Tämä aiheuttaa kuitenkin ongelmia. Koska tiedostojärjestelmään ei voida kirjoittaa, aiheuttaa se usein katkon palveluille jotka käyttävät tietoa tiedostojärjestelmästä. Jos esimerkiksi haluat ottaa varmuuskopion tietokantapalvelimesta, on tietokantapalvelut suljettavat varmuuskopion ajaksi (Tämä ei tietysti koske työkaluja joilla voidaan ottaa suoraan tietokannasta lennossa varmuuskopio. Tässä tarkoitetaan yleisesti varmuuskopion ottamista, ei pelkästään tietokantoja).

Linuxin loogiset volyymit apuna varmuuskopioinnissa

Linuxin LVM tarjoaa erinomaiset työkalut varmuuskopiointiin, mutta näiden edellytyksenä on luonnollisesti se että tiedostojärjestelmä on tehty käyttäen LVM:ää, tosin nykyisin valtaosa Linux-distribuutioista ottaa asennuksessa lvm:n käyttöön. Käytämme tässä ratkaisussa hyväksemme LVM:n volyymiä jonka tyyppi on snapshot. Tämän erikoislaatuisen volyymin sisältö on täysin sama kuin volyymin sisältö sen ottoajankohtana, ts. kun snapshot-volyymi luodaan sen sisällöstä tulee täysin identtinen. Tämän tarjoama hyöty on siinä, että kun snapshot on otettu voidaan siitä ottaa varmuuskopio ilman pelkoa tiedostojen sisällön muuttumisesta varmuuskopioinnin aikana. Jos tätä tekniikkaa käytetään esimerkiksi tietokanta-volyymin varmuuskopioinnissa tietokannan ei tarvitse olla suljettuna itse varmuuskopioinnin aikana.

Ensin luodaan snapshot-volyymi ja sille määritellään riittävän iso koko:

jpj@x1:~$ sudo lvcreate -L1G -s -n dbbackup /dev/datavg/datalv
  Logical volume "dbbackup" created


Tämän jälkeen itse snapshot-volyymi otetaan käyttöön ja ajetaan itse varmuuskopiointi:

jpj@x1:~$ sudo mkdir /mnt/dbbackup
jpj@x1:~$ sudo mount /dev/datavg/dbbackup /mnt/dbbackup
jpj@x1:~$ sudo tar -cf /dev/st0 /mnt/dbbackup


Lopuksi kun itse varmuuskopiointi on saatu tehtyä poistetaan snapshot käytöstä:

jpj@x1:~$ sudo umount /mnt/dbbackup
jpj@x1:~$ sudo lvremove /dev/datavg/databases
Do you really want to remove active logical volume dbbackup? [y/n]: y
  Logical volume "dbbackup" successfully removed


LVM:n snapshottien käyttäminen MySQL-tietokannan varmuuskopiointiin

Aluksi itse tietokanta laitetaan snapshotin oton ajaksi luku-tilaan:

jpj@x1:~$ sudo mysql -u root -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or g.
Your MySQL connection id is 610
Server version: 5.1.41-3ubuntu12.8 (Ubuntu)

Type 'help;' or 'h' for help. Type 'c' to clear the current input statement.

mysql> flush tables with read lock;
mysql> flush logs;
mysql> quit


Kun tietokanta on asetettu luku-tilaan otetaan itse snapshot ja vapautetaan tietokanta lukutilasta, tärkeää on luoda riittävän iso snapshot-volyymi (koko rippuu itse tietokantavolyymin koosta, esimerkissä käytän 5G:n volyymia). Koska Linux ottaa LVM:stä snapshotin varsin nopeasti on itse katko varsin lyhyt.

jpj@x1:~$ sudo lvcreate -L5G -s -n backup /dev/dbvg/dblv
  Logical volume "backup" created
jpj@x1:~$ sudo mysql -u root -p
Enter password:
Welcome to the MySQL monitor.  Commands end with ; or g.
Your MySQL connection id is 610
Server version: 5.1.41-3ubuntu12.8 (Ubuntu)

Type 'help;' or 'h' for help. Type 'c' to clear the current input statement.

mysql> unlock tables;
mysql> quit


Lopuksi otetaan varmuuskopio ja poistetaan snapshot käytöstä.

jpj@x1:~$ sudo mount -o ro /dev/dbvg/backup /mnt/mysqlbackup
jpj@x1:~$ sudo tar czvf mysql.$(date +"%m-%d%-%Y).tar.gz /mnt/mysqlbackup/*
jpj@x1:~$ sudo umount /mnt/tmp
jpj@x1:~$ sudo lvremove -f /dev/dbvg/backup

Avoimen lähdekoodin vaihtoehto – Exchange


Tulen esittelemään blogissani tämän vuoden varrella useita erilaisia vaihtoehtoja korvaamaan yrityskäytössä tarpeellisia ratkaisuja avoimen lähdekoodin tuotteilla. Aloitan artikkelijaksot ehdottamalla muutamaa avoimen lähdekoodin ratkaisua korvaamaan yrityskäytössä erittäin yleinen Microsoftin ratkaisu, Microsoft Exchange. Yritykset tarvitsevat yleisimmin käyttöönsä sähköpostin sekä mahdollisuuden kalenterien jakamiseen helposti.

Markkinoilla on useita erilaisia ratkaisuja, esitän tässä nyt kaksi.


Zimbra on ollut markkinoilla varsin pitkään ja on saanut kehitettyä varsin toimivan konseptin, ainakin sitä voi pitää toimivana koska ohjelmistoyhtiö VMware osti sen viime vuonna. Zimbra tarjoaa yksinkertaisuudessaan suoraa korviketta Exchangelle. Tuotteessa on kaikki yrityskäytössä välttämättömät ratkaisut, tuote on kuitenkin ilmainen vain osittain. Ilmaisesta versiosta on poistettu mm. tuki MIcrosoft Outlook-ohjelmistolle, jota myös monet yritykset käyttävät. Tuki löytyy lisenssoidusta versiosta (eli tuote on siis kaksoislisenssoitu) joka sekin on hinnoiteltu varsin kilpailukykyisesti Exchangeen nähden.

Tuote on erittäin helppo ottaa käyttöön. Zimbra tarjoaa täysin valmista VMware-imagea joka pohjautuu Ubuntuun ja sen päälle asennettuun Zimbran ohjelmistokerrokseen. Valmiista imagesta tuotteen asennus ja käyttöönotto on nopeaa ja helppoa. Tuotteen saa erittäin helposti kiinni mm. Microsoftin ActiveDirectoryyn sekä siinä on valmiina työkalut helpottamaan migraatiota Exchange-ympäristöistä. Kaupallisessa tuotteessa on myös mobiilirajapinta jolla postit ja kalenteri voidaan tuoda matkapuhelimiin. Ohjelmiston www-pohjainen sähköposti ja kalenteri on erittäin hyvän näköinen, huomattavasti parempi kuin Microsoft Exchangessa.

Tuotteesta voit lukea lisää osoitteesta


Täysin avoimen lähdekoodin ratkaisu SOGo on markkinoilal uudempi tulokas. Tuote on toteutettu noudattaen valmiita ja hyväksi todettuja avoimia rajapintoja ja sen liittäminen erilaisiin ohjelmistoihin onkin nopeaa ja yksinkertaista, esimerkiksi ohjelman kalenteria voidaan lukea suoraan Thunderbirdillä, Outlookilla sekä Applen iCal-ohjelmalla.

Vaikka tuote on täysin avoimen lähdekoodin ilmainen ratkaisu on siinä suoraan tuki myös Outlookille, joka helpottaa yrityksiä siirtymisessä. Tuote pohjautuu muutamaan avoimen lähdekoodin projektiin ja näistä OpenXchange tuo rajapinnat Outlookkiin. Tuote on nopea asentaa ja tarjolal on valmis virtuaalikone-image josta käyttöönotto voidaan tehdä todella nopeasti. Tuotteelle löytyy suoraan asennuspaketit useimmille Linux-distribuutioille mm. Red Hat sekä Ubuntu.

Avoimien rajapintojen lisäksi tuotteen ehdottomasti paras puoli on sen WWW-käyttöliittymä. Tuotetta voi käyttää täysin moitteetta www-selaimella ja esim. kalenteri-ominaisuudet eivät jää jälkeen Outlookin vastaavista yhtään, www-rajapinnan kautta on mahdollisuus mm. buukata uusia tapaamisia ja tarkistaa kutsuttavien tilanne kalenterista. WWW-käyttöliittymä on paljon parempi kuin Exchangen tarjoama OWA sekä huomattavasti kevyempi ja nopeampi kuin Zimbran ratkaisu.

Tuotteeseen kannattaa ehdottomasti tutustua ja miettiä seuraavissa migraatioissa siirtymistä. Tarkempaa tietoa ja live-demo nähtävissä osoitteessa

Miten saavuttaa korkea(mpi) käytettävyys ilman valtavia kuluja – osa II


Ensimmäisessä osassa artikkelia rakensimme ympäristön jossa kahdella erillisellä Linux-palvelimella on yksi yhteinen, DRBD:llä peilattu levy sekä sen päällä GFS2:lla toteutettu klusteroitu tiedostojärjestelmä. Kun perusteet on tehty voidaan ympäristöön ottaa käyttöön erilaisia palveluita. Periaatteessa melkein kaikki normaalit palvelut voidaan toteuttaa DRBD:n päällä, mutta esim. tietokannat vaativat hieman asetusten muuttamista ja niitä ei tässä artikkelissa nyt käsitellä.

Tässä artikkelissa esitän tavan toteuttaa DNS-palvelimen avulla kuormantasausta sekä keinon jolla DNS-palvelun avulla voidaan toteuttaa käytettävyyden kannalta yksi olennainen asia, nimellä voidaan tarjota palvelua kahden eri operaattorin kautta ja kun toinen operaattori ei toimi tarjotaan palvelua automaattisesti jäljellä olevan kautta. Ratkaisu ei kuitenkaan ole täysin katastrofivarma, koska jos ympäristössämme on esimerkkinä palvelin a joka on kytketty internet-yhteys a:n sekä palvelin b kytkettynä internet-yhteys b:n voi käytännössä tapahtua tilanne jossa sekä internet-yhteys a että palvelin b ovat poissa käytöstä laitevikojen vuoksi, tällöin palvelut eivät toimi. Antamani esimerkki kuitenkin tarjoaa tavan toteuttaa parempaa käytettävyyttä, koska on kuitenkin epätodennäköisempää että internet-yhteys toisesta konesalista ja palvelin toisesta on rikki.

Tässä artikkelissa tulen näyttämään miten voit parantaa käytettävyyttä www-palveluille DNS-kuormantasauksella.

DNS-palvelun avulla toteutettava kuormantasaus

Homma aloitetaan asentamalla kumpaankin palveliemen bind9-nimipalvelut. Esimerkissä käytettävät IP-osoitteet tulee korvata oikeilla, on master-palvelimen julkinen IP-osoite sekä on slave-palvelimen julkinen IP-osoite:

jpj@x1:~$ sudo apt-get install bind9

Seuraavaksi luomme itse nimipalvelumääritykset lisäämällä /etc/bind/named.conf-tiedostoon (master-koneella):

zone "" {
        type master;
        file "/etc/bind/";
        notify yes;
        allow-update {;};
        allow-transfer {;};
Sekä slave-koneelle /etc/bind/named.conf-tiedostoon:
zone "" {
        type slave;
        file "";
        masters {; };

Tämän jälkeen itse master-palvelimelle luomme zone-määrittelyt lisäämällä master-koneelle tiedostoon /etc/bind/

$TTL 86400
@                       IN SOA (
                                2011012001  ; serial
                                28800      ; refresh (8 hours)
                                7200       ; retry (2 hours)
                                604800     ; expire (1 week)
                                86400      ; minimum (1 day)

                        MX      10
                        MX      20


www                     CNAME
x                       NS      x1
x                       NS      x2

Määrittelyissä ei ole mitään erikoisempaa, paitsi että on osoitettu CNAME-määritykseksi ja on määritelty nimipalvelimiksi kummatkin noodimme (x1 ja x2).

Itse pitää myös määritellä nimipalveluihin, joten lisäämme kummankin palvelimen /etc/bind/named.conf-tiedostoon seuraavan määrittelyn:

zone "" {
        type master;
        file "/etc/bind/";

Sama määrittely tehdään kummallekin noodille, koska haluamme että kumpikin noodi palauttaa vain oman IP-osoitteensa. Näin kun loppukäyttäjä yrittää ottaa yhteyttä ohjautuu kysely jota loppukäyttäjän kone kysyy nimipalveluista, nimipalvelimia on kaksi ja osoitetta kysytään jommasta kummasta, mikäli ensimmäinen nimipalvelu ei palauta IP:tä, kysytään sitä toiselta. Tällä voidaan varmistaa että loppukäyttäjä saa IP-osoitteen palvelulle, vaikka jompi kumpi yhteys olisikin alhaalla, tai jompi kumpi palvelimista. Nimipalvelimet kuitenkin säilövät IP-osoitetietoja välimuistissaan ja päivittävät niitä vain aika ajoin itse palvelimelta, tässä tapauksessa homman juju perustuukin siihen että määrittelemme tuon säilöntäajan niin lyhyeksi että käytännössä IP-osoite selvitetään joka kerta kun käyttäjä ottaa yhteyden palveluun.

Master koneella /etc/bind/ lisätään:

$TTL 86400
@                       IN SOA (
                                2011012001  ; serial
                                28800      ; refresh (8 hours)
                                7200       ; retry (2 hours)
                                604800     ; expire (1 week)
                                86400      ; minimum (1 day)


        IN 60           A
*       IN 60           A

ja vastaavasti slave-koneella samaan tiedostoon lisätään:

$TTL 86400
@                       IN SOA (
                                2011012001  ; serial
                                28800      ; refresh (8 hours)
                                7200       ; retry (2 hours)
                                604800     ; expire (1 week)
                                86400      ; minimum (1 day)


        IN 60           A
*       IN 60           A

Nyt nimipalvelimien osalta palvelu on määritelty. Käynnistä nimipalvelimet uusiksi kummallakin noodilla ja tarkista toiminta kysymymällä host-käskyllä ip:tä Kummankin noodin tulisi palauttaa palvelulle oma ip-osoitteensa.

WWW-palveluiden määrittelyt

Kummallekin noodille asennetaan www-palvelut, esimerkissä käytän lighttpd:tä koska olen todennut sen varsin toimivaksi ja yksinkertaiseksi. Vastaavat määrittelyt voidaan kuitenkin tehdä myös apachella ja monella muullakin palvelulla.

Asennetaan noodeille lighttpd:

jpj@x2:/etc/bind$ sudo apt-get install lighttpd

Jonka jälkeen jommalla kummalla noodilla siirretään /var/www-hakemiston sisältö sekä /etc/lighttpd-hakemiston sisältö yhteiselle levylle ja muutetaan lokaali hakemisto osoittamaan yhteiseen:

jpj@x2:/etc/bind$ sudo mkdir /j0/var
jpj@x2:/etc/bind$ sudo mkdir /j0/etc
jpj@x2:/etc/bind$ sudo mv /etc/lighttpd /j0/etc
jpj@x2:/etc/bind$ sudo mv /var/www /j0/var
jpj@x2:/etc/bind$ sudo ln -s /j0/var/www /var/www
jpj@x2:/etc/bind$ sudo ln -s /j0/etc/lighttpd /etc/lighttpd

Toisella noodilla poistetaan hakemistot ja tehdään samat määritykset:

jpj@x2:/etc/bind$ sudo rm -rf /etc/lighttpd
jpj@x2:/etc/bind$ sudo rm -rf /var/www
jpj@x2:/etc/bind$ sudo ln -s /j0/var/www /var/www
jpj@x2:/etc/bind$ sudo ln -s /j0/etc/lighttpd /etc/lighttpd

Ja lopuksi itse lighttpd-palvelu käynnistetään kummallakin noodilla uudelleen. Lighttpd-palvelu käynnistyy automaattisesti koneiden käynnistyksessä, mutta DRBD-palvelun tarjoama levy ei välttämättä ole vielä pystyssä joten palvelu käynnistetään uudelleen lisäämällä /etc/rc.local-tiedoston loppuun:

service lighttpd restart

Koska yhteinen www-hakemisto ja konfiguraatiot on jaetulla levyllä, riittää että määrittelyt tehdään vain toisella noodilla ja www-sivut tallennetaan toisen koneen kautta, tai editoidaan toisen koneen kautta.


Näiden esimerkkien avulla voidaan siis helposti ja nopeasti parantaa erilaisten palveluiden käytettävyyttä, mm. sähköpostipalvelut on helppo toteuttaa tällä sijoittamalla tarpeelliset hakemistot yhteiselle levylle. Useimmilla sähköpostipalveluilla riittää että käyttäjien kotihakemistot on jaetulla levyllä, näin palvelu toimii käytännössä ilman mitään lisämäärittelyitä.