Brocadelta 16 gigainen FC-liityntä

Brocade julkisti reilu kuukausi sitten uudet tuotteensa ja niiden joukosta löytyy myös kaksi uutta FC-kytkintä jotka tarjoavat kauan odotetun 16 gigaisen FC-liitynnän. Tarjonta sisältää alkuvaiheessa ainakin Brocade 6510-kytkimen joka on 1U:n korkounen 24- ja 48-porttinen kytki joka kykenee kokonaisuudessa 768 gigabitin suorityskykyyn. Laitteen portit on konfiguroitavissa 2,4,8 tai 16 gigaisiksi FC-porteiksi joten yhteensopivuus alaspäin säilyy samanlaisena kuin se on nykyisissä 8 gigaisissa FC-kytkimissäkin.

Samaan aikaan julkistettiin myös uusi DCX 8510 konesalikytkinrunko josta tulee markkinoilla 4- ja 8-korttiset versiot. Laiteeseen on mahdollista kytkeä yhteensä 384 kappaletta 16 gigaisia FC-portteja tai 512 kappaletta 8 gigaisia FC-portteja kokonais-suorituskyvyn ollessa huimat 8.2 terabittiä.

Jäämme odottelemaan ensimmäisiä laitetoimituksia. Käytännössä useimmat yritykset ovat kuitenkin edelleen 4 gigaisessa FC-verkossa ja ovat joko tekemässä tai suunnittelemassa siirtymistä 8 gigaiseen FC-verkkoon. Brocaden laitetarjonta mahdollistaa kuitenkin jo miettimisen seuraavaa päivitystä pidemmälle. Tällä hetkellä Ciscon tarjonta tallennusverkkoihin on auttamattomasti jäänyt Brocaden taakse. Uskon kuitenkin että Cisco julkistaa omat uutuutensa vielä tämän vuoden aikana.

PostgreSQL:n ja avoimen lähdekoodin mahdollistama yksinkertainen HA

Useimmat SQL-sovellukset tukevat Point-in-Time Recoveryä joka tarkoittaa käytännössä yksinkertaisesti sitä että tietokanta tuottaa transaktio-logeja joiden avulla voidaan halutessaan palata hyvinkin tarkasti tiettyyn ajankohtaan. Myös avoimen lähdekoodin PostgreSQL tukee tätä ominaisuutta (Kirjoitushetkellä ainakaan MySQL ei tätä vielä tue) ja tämä mahdollistaa useita mielenkiintoisia käyttötapoja, mm. mahdollistamalla tarkan varmuuskopion tietokannasta jolla voidaan palata aina tiettyyn ajankohtaan helposti.

Virtualisointi on kuitenkin mahdollistanut uusien koneiden tuotttamisen helposti, nopeasti ja kustannustehokkaasti. Kun koneita voidaan tuottaa aika tehokkaasti on katastrofivarmentaminenkin helpottunut huomattavasti. Toisessa konesalissa voidaan ajaa erillistä tuotantoa ja varalta muutamaa konetta joihin katastrofitilanteissa voidaan käynnistää toisen konesalin palveluita, esim. juuri PostgreSQL:n tietokannat. PostgreSQL:n tarjoama point-in-time recovery mahdollistaa standby-koneen käytön erittäin helposti. Käytännössä tuotantokantaan asetetaan transaktiolgoit päälle jonka jälkeen tietokanta tallentaa wal-tiedostoja arkistohakemistoon josta ne voidaan siirtää helposti toiseen lokaatioon ja siellä ajaa katastrofivarmennus-käytössä olevaan standby-koneeseen, tämä on myös erittäin helppoa koska standby-tietokanta voidaan määrittää tilaan jossa se automaattisesti hakee tietystä hakemistosta transaktiologit ja ajaa niiden mukaiset muutokset tietokantaansa. Alla oleva kaaviokuva kertoo tarkemmin mistä on kyse:

Kuvattu ominaisuus on todella helppoa ottaa käyttöön jonka lisäksi se on myös erittäin tehokas ja nopea. Käytännössä toisen konesalin kopio on perässä 1-2 transaktiologin verran mikäli konesalien välissä on normaali yhteys joka ei ole täysin kuormitettu. Pahimmassakin tilanteessa siis menetetään vain pienen hetken tiedot, joka tarjoaa erittäin hyvän kustannustehokkuuden ratkaisulle. Ominaisuuden käyttöönotto aloitetaan muokkaamalla tuotantopuolelle tietokantaan logit käyttöön muokkaamalla postgresql.conf-tiedostoa:

archive_mode = on
archive_command = 'cp -v %p /var/lib/pgsql/data/pgsql/archives/%f'
archive_timeout = 300

Seuraava toimenpide on siirtää itse logit standby-koneelle. Tämä onnistuu helpoiten lisäämällä standby-koneen croniin rsync-työ, alla olevassa esimerkissä logeja haetaan viiden minuutin välein, mutta voit säätää sen omaan ympäristöösi parhaiten sopivaksi. Käytännössä siis tämä määrittelee maksimaalisen datan menetyksen katastrofitilanteessa, eli jos kantaan tulee paljon muutoksia tätä on syytä kiristää hiukan.

/5 * * * * rsync -avz --remove-sent-files prod-sql:/var/lib/pgsql/data/pgsql/archives/ /var/lib/pgsql/data/pgsql/archives/ > /dev/null

Esimerkki olettaa että olet tehnyt SSH-avaimet koneiden välille, jolloin siirto onnistuu automaattisesti. Viimeinen työvaihe käyttöönotossa on määritellä standby-tietokanta hakemaan archive-hakemistosta transaktiologeja ja ajamaan niiden mukaiset muutokset tietokantaan. Tässä hyödynnetään pg_standby-komentoa jonka käyttöönotto tapahtuu muokkaamalla standby-koneen recovery.conf-tiedostoa.

restore_command = '/usr/bin/pg_standby -l -d -s 2 -t /tmp/pgsql.trigger /var/lib/pgsql/data/pgsql/archives %f %p %r 2>>standby.log'

PostgreSQL:n dokumentaatiossa on erittäin hyvin kuvattu tämä warm standby-toiminto joten kannattaa tutustua näihin mikäli aihe kiinnostaa tarkemmin. Tässä taas hyvä esimerkki siitä miten avoimen lähdekoodin tietokanta kykenee tarjoamaan ominaisuuksia jotka useimmin löytyvät vain kalliista enterprise-tietokannoista. PostgreSQL:stä on saatavilla lisäksi tuettu PostgreSQL Plus-versio joka tarjoaa paljon muitakin lisäominaisuuksia ja mm. erittäin hyvän Oracle-yhteensopivuuden jonka avulla olemassa olevia Oracle-tietokantoja voidaan helposti migroida kustannuksiltaan paljon edullisempaan Postgres-tietokantaan.