What makes a software-defined storage software-defined


Software-Defined Storage is something that every storage vendor on the planet talks today. If we however stop and think about it a bit we actually realise that software-defined is just yet another buzzword.  This is 101 on SDS and we are not going to go deep in all areas. I will write more in-depth article per characteristics later. So the question is: What makes a software-defined storage software-defined?

A bit of background research

To really understand what software-defined actually means we must first do a bit of background research. If we take any modern storage – and by modern I mean something released in past 10 years – we actually see a product having somekind of hardware component, x pieces of hard disk drives / ssd drives and yes, a software component. So by definition every storage platform released in past years is actually a software-defined storage since there is software which actually handles all the nice things of them.

Well, what the hell software-defined storage then is?


Software-defined actually doesn’t mean something where software is defining features but:

Software-defined storage (SDS) is an evolving concept for computer data storage software to manage policy-based provisioning and management of data storage independent of the underlying hardware. Software-defined storage definitions typically include a form of storage virtualization to separate the storage hardware from the software that manages the storage infrastructure. The software enabling a software-defined storage environment may also provide policy management for feature options such as deduplication, replication, thin provisioning, snapshots and backup. SDS definitions are sometimes compared with those of Software-based Storage.

Above is a quote from wikipedia defining what SDS actually means. So let’s go deeper and look what are characteristics you would except from SDS product. Note that there are products on marketed as SDS which doesn’t have all of these. It’s not necessary to have them all, but more you have better it is – or is it?

Automation with policy-driven storage provisioning with service-level agreements

Automation of storage systems is not that new feature, but it’s a feature that is really usable and it’s also required feature if you plan to build any kind of modern cloud architecture with storage systems. Traditional storage admin tasks like creating and mapping a LUN cannot done by humans in modern cloud environment but rather they must be done by automation. What this means in reality is that in VMware environment a VM-admin is able to create new storage based in service-level needed directly from his/her VMware tools. Most of the modern storage products has at least some kind of plugin for VMware vCenter – but not all has same features. VMware released their vVols with vSphere 6 and it will be dominant model with storage deployments in future I think. It helps VMware admins to create a storage with needed features (deduplication, compression, protection, replication, etc) per VM. This is not that new feature also, since OpenStack has been using this kind of model for quite long. And there are even storage vendors having their business on this (Tintri).

Policy based provisioning and automation are in my opinion most important features of software-defined storage and you should look these carefully if achieving cloud kind of environment is your short or long term plan.

Abstraction of logical storage services and capabilities from the underlying physical storage systems

Logical storage services and capabilities and their abstraction is really not a new thing. Most of the modern storage architectures have been using this kind of abstraction for several years. What this means is for example virtualisation of underlaying storage (One or more RAID-group in generic storage pool) to save unused capacity and giving flexibility. I don’t even remember any modern storage product not using any virtualisation of underlaying storage since this has been really basic feature for years and has nothing to do with modern software-defined thinking that much.

What makes this as a modern software-defined storage feature is features like VMware vVols. They enable you to have more granular control per VM what kind of storage they need and what are needed features. Not all VM’s for example need to be replicated in sync to second location and having a separate datastore for replicated VM’s is just not enough for most of the companies – and it’s really not enough in modern cloud like architectures. You must have per VM control and all the magic must happen without VM admin to know which storage datastore is replicated and which is not. This is a quite new feature in VMware but has been available for OpenStack users for a while mainly because OpenStack is built for modern cloud environment where as VMware was mainly built for datacenter virtualisation but has implemented cloud like features later on.

Commodity hardware with storage logic abstracted into a software layer.

Traditionally most of the storage vendors had their own hardware they used with some of them designing even own ASICs but at least some form of engineered hardware combined with commodity hard disk drives / ssd drives with custom firmware. Legacy vendors, like they are nowadays called did indeed invest lot’s of money to develop engineered hardware to meet their special needs and this typically meant longer release cycles and different go-to-market strategy since introducing a new feature might mean developing a new ASIC and new hardware to support it.

Some of the startup vendors claims that using engineered hardware is expensive and it means that customers pay too much. This might be true but there is long list of advantages using engineered hardware instead of commodity hardware but by definition you, as a customer, shouldn’t look that much about this area. Commodity hardware can be as good as engineered hardware and engineered hardware can be as cheap as commodity hardware.

If the vendor you are looking for uses commodity hardware they must do many things on their software layer which can be done on hardware layer with microcode.  However which ever route they go storage logic is, and has been abstracted into a software layer years ago. All of modern storage vendors products uses software to do most of the logic but some of them uses ASICs to do some clever things, like HP uses ASIC to do de-duplication while most of the competitors use software to do this.

Scale-Out storage architecture

Scale-Out storage architecture is not that new since first commercial scale-out storage products came to market over 10 years ago. However it is still not that common to have commercial storage vendor to have a good scale-out product on their portfolio to solve most of the customer needs but typically just used for one purpose (Like scale-out NFS).

You can think scale-out in two forms.

Isolation Domain Scale-Out

Traditional method to deploy storage controllers is to use HA-pairs where you have two controllers sharing same backend disk storage system and in case of failover one can handle all traffic. This type of method is not a scale-out, but you can also do scale-out type of storage architecture relaying on HA-pairs and then connecting them together. What this allows is moving data between HA-pairs and doing all kind of maintenance and hardware refresh tasks without need to take your storage down. There are however many limitations this method has for your scalability. When you add new capacity to cluster you must select one isolation domain / HA-pair where you add this capacity rather than just adding capacity to one pool. This method has however much better failover handling because there are several isolation domains in case of faults.

This method however typically means vendor using engineered hardware etc. Think this as a method NetApp Clustered Data ONTAP uses.

Shared Nothing Scale-Out

Shared Nothing is a scale-out method where you have N storage controllers who do not share their backend storage at all. This method is more common with vendors and products built on commodity hardware since this can solve most of the problems of commodity hardware has and is in most of the cases much more understandable way to scale than typical isolation domain type of scaling (HA-pairs, etc.). All of the virtual SAN products on market relay on this type of scaling since it doesn’t need any specific hardware components to achieve scalability and high availability. This is also type of scaling all hyper-converge infrastructure (HCI) vendors use and claim that their method is same as used with Google, Facebook and Amazon type of big environments, even that it’s not 100% true.

However this is by far best method to use if you design your architecture from scratch and design it for commodity hardware. It’s also much better in handling rebuild scenarios because there’s not that big performance hit and also self healing is possible with this kind of approach.

Think this as a method Nutanix, Simplivity, SolidFire, Isilon, etc. uses.

So is one better than other?

No. Both have good things and bad things. This is a design choice you make and you can make a realiable and scalable system with both methods. When architected correctly either of them can give you performance, reliability and scalability needed.

Conclusion. Why would I care?

Understanding what Software-Defined Storage (SDS) means helps you understand more competitive landscape and helps you not falling on typical traps of FUD from competitors. Any modern storage, either NAS or SAN, is software-defined, but not all have same feature s or same kind of approach. Anyway all of them solve most of the problems modern infrastructure has nowadays and most of them can help your organisation to store more data than 10 years ago and get enough speed to meet requirements of most of your applications. When selecting storage vendor do it based on your organisational needs rather than marketing jargon.

Note. I work for “legacy” storage vendor and this has nothing to do with my job. I say same principles to every customer I talk to. This is my personal view and has nothing to do with my employer.

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 http://www.ovirt.org/releases/nightly/fedora/16/ovirt-engine.repo -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 http://www.ovirt.org/releases/nightly/binary/ 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 🙂

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.

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 "failsafe.fi" {
        type master;
        file "/etc/bind/failsafe.fi.zone";
        notify yes;
        allow-update {;};
        allow-transfer {;};
Sekä slave-koneelle /etc/bind/named.conf-tiedostoon:
zone "failsafe.fi" {
        type slave;
        file "failsafe.fi.zone";
        masters {; };

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

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

                        NS      x1.failsafe.fi.
                        NS      x2.failsafe.fi.
                        MX      10 x1.failsafe.fi
                        MX      20 x2.failsafe.fi

ORIGIN failsafe.fi.

www                     CNAME   www.x.failsafe.fi.
x                       NS      x1
x                       NS      x2

Määrittelyissä ei ole mitään erikoisempaa, paitsi että http://www.failsafe.fi on osoitettu CNAME-määritykseksi http://www.x.failsafe.fi:lle ja x.failsafe.fi:lle on määritelty nimipalvelimiksi kummatkin noodimme (x1 ja x2).

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

zone "x.failsafe.fi" {
        type master;
        file "/etc/bind/x.failsafe.fi.zone";

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ä http://www.failsafe.fi-osoitteeseen ohjautuu kysely http://www.x.failsafe.fi-nimelle 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/x.failsafe.fi.zone-tiedostoon lisätään:

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

                        NS      x1.failsafe.fi.
                        NS      x2.failsafe.fi.

        IN 60           A
*       IN 60           A

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

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

                        NS      x1.failsafe.fi.
                        NS      x2.failsafe.fi.

        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ä http://www.failsafe.fi:lle. 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ä.

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


Tämän päivän tietotekniset ympäristöt ovat yhä kriittisempiä ympäristöjä ja niiden käytettävyyden tulee olla korkeaa. Korkean käytettävyyden saavuttaminen ei kuitenkaan ole mitenkään yksiselitteistä eikä helppoa. Usein tämä tarkoittaa investointeja kahdennettuihin yhteyksiin dynaamisella reitityksellä, kahdennettuihin palvelimiin sekä kahdennettuun levyjärjestelmään.

Avoin lähdekoodi on kuitenkin tuonut mahdollisuuksia toteuttaa korkeaa (tai ainakin korkeampaa) käytettävyyttä ilman valtavia investointeja. Esitän tässä nyt yhden esimerkin siitä miten innovatiivisuus ja oikeiden työkalujen käyttö voi tuoda valtavia säästöjä.


Tässä esimerkissä toteutetaan kahden Linux-palvelimen klusteri ilman kalliita dynaamisia reitityksiä ja keskitettyjä levyjärjestelmiä. Tämä ei ole perusteista lähtevä opas siihen miten ratkaisu pitäisi toteuttaa, eikä tämän tarkoituksena ole esittää ratkaisua joka on liiketoimintakriittinen vaan herättää ajatuksia siitä miten avoimen lähdekoodin ratkaisuilla voidaan oikeasti löytää etuja.

Alkuvaiheessa minulla oli kaksi Ubuntu Server 10.04 -palvelinta, asennettuna ja toimintakunnossa. Kumpikin palvelin on virtualisoitu ja kummankin palvelimen internetyhteys tulee eri operaattorilta. Koska koneet sijaitsevat samassa konesalissa, on niiden välillä myös privaattiverkko, tosin tämä ei ole välttämätön ratkaisun kannalta, mutta nopeuttaa levyjen synkronointia.

Vaihe yksi – Ratkaisu datan kahdennukseen

Jotta ratkaisu voisi toimia oikein, ja tarjota palveluita kummankin koneen kautta, on itse palvelulla näytettävän datan oltava kahdennettu. Perinteisesti tähän käytetään keskitettyjä levyjärjestelmiä ja niiden peilauksia mutta tässä tapauksessa turvaudumme avoimen lähdekoodin tuotteeseen DRBD. Tuote ei ole uusi ja sitä on käytetty jo varsin pitkään erilaisissa ympäristöissä. Lyhyesti kerrottuna DRBD peilaa sille annetun blokkidatan kahden koneen välillä, tässä tapauksessa tulemme peilaamaan yhden levyosion kahden koneen välillä. Tuotetta voisi verrata verkkotasoiseksi RAID1:ksi koska toimintaperiaate on aika pitkälle sama. Perinteisesti tuotetta käytetään aktiivinen/passiivinen-asetelmalla, mutta esimerkissäni rakennetaan ratkaisu jossa tarjottava palvelu on käytettävissä kumman tahansa yhteyden kautta.

DRBD:na sennus on Ubuntun 10.04:n varsin nopea ja triviaali toimenpide. Ennen tuotteen asennusta kummallekin koneelle on lisätty yksi levy joka ei ole vielä missään käytössä, esimerkin tapauksesas virtuaalikoneilel lisättiin 8 gigan kokoinen virtuaalilevy ja sille tehtiin koko levyn kokoinen osio Linux-tyypillä (Levy on kummallakin koneella /dev/sdb1 konfiguroinnin helppouden vuoksi, levy voi olla eri niminen todellisuudessa). Itse tuote asennetaan:

jpj@x1:~$ sudo apt-get install drbd8-utils

Paketti hakee lisäksi muita riippuvuuksia ja hetken kuluttua itse tuote on asennettu. Tämän lisäksi lisäämme /etc/hosts-tiedostoon:   x1   x2

ja /etc/drbd.d/disk0.res-tiedostoon:

resource disk0 {
        protocol C;
        net {
                cram-hmac-alg sha1;
                shared-secret "yhteinensalasana";
        startup {
                become-primary-on both;
        on x1 {
                device /dev/drbd0;
                disk /dev/sdb1;
                meta-disk internal;
        on x2 {
                device /dev/drbd0;
                disk /dev/sdb1;
                meta-disk internal;
Tällä konfiguroinnilla tehdään perusteet levypeilaukseen, määrittelyyn annetaan kummankin koneen IP-osoite, sekä kummankin koneen peilattava levy.
Seuraavaksi käynnistellään tarvittavat palvelut ja tehdään DRBD:lle käytettävä levy disk0 (Ajetaan kummallakin koneella).
jpj@x1:~$ sudo drbdadm create-md disk0
jpj@x1:~$ sudo service drbd stop
jpj@x1:~$ sudo service drbd start
Kumpikin noodi määritellään meidän haluamassamme esimerkissä primääriksi, ts. kumpikin noodi voi kirjoittaa levylle (kunhan levyllä käytetään siis klusteriin soveltuvaa tiedostojärjestelmää kuten esimerkissämme käytettävää GFS). Tämä tehdään taas kummallakin noodilla.
jpj@x1:~$ sudo drbdsetup /dev/drbd0 primary -o
Nyt voimmekin seurata levyjen synkronointia, joka vie aikaa jonkin verran (Riippuen peilattavasta levystä).
jpj@x1:~$ cat /proc/drbd
version: 8.3.7 (api:88/proto:86-91)
GIT-hash: ea9e28dbff98e331a62bcbcc63a6135808fe2917 build by root@x1, 2011-01-08 17:46:15
 0: cs:SyncSource ro:Primary/Primary ds:UpToDate/Inconsistent C r----
    ns:1064252 nr:140 dw:6092 dr:1080376 al:0 bm:78 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:3131908
        [===>................] sync'ed: 22.5% (3131908/4031556)K
        finish: 2:10:29 speed: 336 (320) K/sec
Levyn valmistumista voi seurata, suosituksena on odottaa että synkronointi valmistuu, mutta tässä esimerkissä jatkamme suoraa eteenpäin.
Vaihe kaksi – Klusteriin soveltuva tiedostojärjestelmä
DRBD toimisi mainiosti ilman lisäominaisuuksia siten että toinen noodi on passiivinen, eli kun haluat tiedostojärjestelmän käyttöön toisella koneella (Esimerkiksi kun pääasiallinen kone on hajonnut), ajat kakkosnoodilla vain komennon jolla siitä tehdään aktiivinen ja mounttaat levyn käyttöön. Haluamme kuitenkin toteuttaa ratkaisun joka on aktiivinen kummankin noodin osalta ja tämä aiheuttaa pientä lisähaastetta. Yleisimmät tiedostojärjestelmät (XFS, EXT3, EXT4, JFS) on suunniteltu käytettäväksi vain yhdellä noodilla kerrallaan ja tähän haasteeseene on kehitetty tiedostojärjestelmiä jotka ovat tarkoitettu nimenomaan klusterien käyttöön, kuten esimerkiksi käyttämämme GFS2 ja VMware-ympäristöissä käytetty VMFS.
GFS2 on Red Hatin tekemä, avoimen lähdekoodin tiedostojärjestelmä ja sen käyttö on varsin helppoa myös Ubuntu Server 10.04:ssä. Aluksi asennetaan kumpaankin koneeseen tarvittavat paketit:
jpj@x1:~$ sudo apt-get install gfs-tools cman clvm
Jotta GFS2-tiedostojärjestelmä toimii (Eli että se voidaan mountata käyttöön) tarvitsee meidän määritellä sitä varten klusteri, klusterin asetusten tulee olla yhteneväiset, joten helpointa tehdä taas toisella koneella ja kopioida konfiguraariot suoraan toiselle. Luodaan /etc/cluster/cluster.conf-tiedosto ja muokataan se seuraavan näköiseksi
<?xml version="1.0"?>
<cluster name="cluster1" config_version="3">
<totem consensus="6000" token="3000"/>
<cman two_node="1" expected_votes="1"/>
<clusternode name="x1" votes="1" nodeid="1">
<method name="single">
<device name="manual" ipaddr=""/>
<clusternode name="x2" votes="1" nodeid="2">
<method name="single">
<device name="manual" ipaddr=""/>
<fence_daemon clean_start="1" post_fail_delay="0" post_join_delay="3"/>
<fencedevice name="manual" agent="fence_manual"/>
Seuraavaksi käynnistämme tarvittavat palvelut uudelleen kummallakin koneella
jpj@x1:~$ sudo service cman stop
jpj@x1:~$ sudo service cman start
jpj@x1:~$ sudo service clvm stop
jpj@x1:~$ sudo service clvm start
Ja lopuksi luodaan itse tiedostojärjestelmä levyille
jpj@x1:~$ sudo gfs2_mkfs -p lock_dlm -t cluster1:gfs -j 2 /dev/drbd0
jpj@x1:~$ sudo gfs2_fsck /dev/drbd0
Lopuksi dataosiot voidaan mountata kumpaankin koneeseen
jpj@x1:~$ sudo mkdir /j0
jpj@x1:~$ sudo mount -t gfs2 /dev/drbd0 /j0
Haluamme luonnollisesti että nämä mountataan myös käynnistyksen yhteydessä, ja tähän luonnollisesti paras olisi fstab, mutta klusterin levyt voidaan mountata vasta kun itse klusteri on pystyssä, ja tämä voi joskus hidastaa turhaan käynnistymistä joten helpoin tapa on tehdä tämä on lisätä /etc/rc.local -tiedostoon (Ennen exit 0-riviä):
sleep 5
mount -t gfs2 /dev/drbd0 /j0
Nyt olemme luoneet tarvittavat asiat ja sinulla pitäisi olla käytettävissä klusteroitu ja peilattu levy kahden koneen välillä. Seuraavassa osassa jatkan artikkelia kertomalla miten voit tarjota tiettyjä palveluita helposti kahden eri operaattorin kautta ilman dynaamisia reitityksiä, käyttäen normaaleja työkaluja sekä viimeistelemme ympäristön siten että sähköposti ja www-palvelut ovat käytettävissä kummankin koneen kautta.