Open Virtualization Management with oVirt Project

Posted on by

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

Posted on by

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.

VMware vCenter plugin for IBM’s XIV/SVC/Storwize v7000

Posted on by

IBM released version 2.5.1 of  it’s Storage Management Console for VMware vCenter while ago. Installation is quite simple and after this adding new vdisks for VMware infrastructure is quite easy. New version supports XIV, SVC and Storwize V7000 as per the versions on the following table:

Product Firmware version
IBM XIV® Storage System 10.1.0 to 10.2.4x
IBM Storwize® V7000 6.1 and 6.2
IBM System Storage® SAN Volume Controller (SVC) 5.1, 6.1 and 6.2

Direct download link for software is here.

Installation needs to be done to vCenter Windows-machine. Currently vSphere 5 is not supported, but hopefully it will be soon. Installation asks few questions about userid’s etc.

After installation you need to restart your vSphere Client and check that IBM’s plugin is enabled

After installation you need to connect plugin to your storage, in my example I will connect it to Storwize v7000. Click “Add”  to start storage system adding wizard.

Select brand of storage you are connecting. If you want to add multiple brands or multiple storages you need to add them one by one.

Next wizard asks connection settings for storage. Enter ip-address or hostname of storage, username and select private key which you have connected to selected user. If your key uses passphrase enter it also.

Note that keys need to be in openssh-format. If you created your keys with putty key generator you need to convert your key to correct one. First import key you have created and then export key in OpenSSH-format.

Last step is to select mdisk-groups you want to access from plugin. Note that v7000 gives mdisk group name by default in format mdiskgrpX. You should change names ones that explain better features of group, I usually use format of  disktype_speed_size_number (for example SAS_15k_600gb_1).

After this you are able to create and present new vdisks from vCenter rather than creating and mapping new vdisks from v7000/SVC/XIV GUI and then creating VMFS after this. Creating new disks is quite easy, just select correct mdisk group and clicl “New Volume”. After this you get window like below where you fill necessary details and after that you just select hosts/clusters where you want to map this volume.

Seven rules to help you on preparing for problems on storage area networks

Posted on by

I wrote this article due the fact that every SAN-adminisrator should know how to be better prepared for problems on their storage area networking. As central storage nowadays is rather a rule than an exception does storage area networking play really important role for everyday computing.

Note that these seven steps are more like my suggestions rather than generic rules that should be followed strictly. So try to find at least something that you can implement for your environment and please let me know if there’s more relevant things than these, or something to add.

Rule #1 – Implement NTP

From my opinion this is the most important thing. Anyone who has faced situation where you needed to find out what happened on environment where all clocks are pointing different time understands relevancy of NTP. When you have all your devices on same time finding root cause is usually much easier. Implement NTP server on your management network and sync all your devices from there. You can keep your management networks NTP on proper time by syncing it from internet but it’s more relevant that all devices are on same time rather than exactly on right second of world clock.

Rule #2 – Implement good naming schema

In past servers usually got their names from action heroes and stars and this might be nice but if you want to have easy rememberable names use them as CNAMES rather then proper names. In problem situation it would be nice to see from name exactly where your device/server is located so I suggest that you use something like Helsinki-DC1-BC01-BL01-spiderman rather than just spiderman. In this example you could easily see that your server is located at Helsinki on datacenter 1 and is on blade chassis one and there blade number one.

Use consistent naming on zoning. I usually name zones ZA_host1_host2. This shows immediately that it’s zone on fabric A and it’s between host1 and host2. On SAN I always prefer that aliases are also named with same kind of naming schema; AA_host1 which is alias on fabric A for host1.

For storage area networking domain ID is like phone number, domain ID’s should always be unique. This is not usually problem if you have separate SAN’s, but if you move something between SAN’s having unique ID is crucial so from the beginning use unique id’s. This information is also used for several other things like fibre channel address of device ports etc.

Rule #3 – Create generic SAN management station

This is usually done on all bigger environments but every now and then I see environments where there is no generic SAN management station implemented. Almost every company has implemented virtualization at least in some level so creating generic SAN management station should not be any kind of problem. You can go easily with virtualized Windows Server or maybe even with just virtualized Windows 7 with RDP connection enabled but I would go with server so there can be more than just one admin on station at time.

This station should have at least these:

  • SSH and telnet tool witch allows you to output of session to text file, on Windows environments I usually go with putty
  • FTP-server (and maybe tftp also). I usually go with Filezilla Server which is really easy to configure and use
  • NTP server for your SAN environment
  • Management tools for your SAN (Fabric Manager for Cisco and DCFM for Brocade) – This is really important on larger environments for toubleshooting
  • Enough disk space to store all firmware-images and log files from switches (Rule #5)
  • ….access for internet in cases where you need to download something new or just use google when sitting on fire 😉

Rule #4 – Implement monitoring on your SAN environment

This can be done at least by using same software you use for your server environment but I would go with Fabric Manager on Cisco SAN’s and DCFM on Brocade SAN’s because these include also other features and are really useful when your environment gets bigger. Configure your management software to send email/sms when something happens – don’t just trust your eyes!

You should also implement automatic log collection for your environment. For example this helps a lot when you try to find physical link problems or slow drain devices. Configure your management station to pull out all logs from switches daily/weekly and then clear all counters so next log starts with empty counters. This can be implemented with few lines of perl and ssh library and there are plenty of exciting scripts already on google if you don’t know how to do it with perl.

Rule #5 – Design your SAN layout properly

This is really easy to achieve and doesn’t even need much time to keep in update. Create layout sketch of your SAN – even in smaller environments – and share it with all admins. You don’t need to have all servers on this sketch, include just your SAN switches and storage systems, if you want you can include your servers also but this usually makes your sketch quite big and unreadable. In two SAN environments (Having two separate SAN’s should be defacto!) plug your servers and storage always on same ports, so if you connect your storage system on ports 1-4 on switch one in fabric A, connect them to ports 1-4 also in corresponding switch on fabric B.

Rule #6 – Update your firmwares

Don’t just hang on working firmwares. There is no software which is absolutely free of bugs and this is why you should always update your firmwares regularly. I am not saying that you should go with new release as soon as it gets to downloads but try to be in as new version you can. There are lot’s of storage systems which makes requirement for firmware levels so always follow your manufactures advices. If your manufacturer doesn’t support newer then something released year ago it might be time to change your vendor!

If you have properly designed SAN with two separate networks you can do firmware upgrades without any breaks on production and most of the enterprise class SAN switches (Usually called SAN Directors) have two redundant controllers so you can update them on fly without any interruption on your production!

Rule #7 – Do backups!!!

Take this seriously. Taking backups is not hard. You can implement this on your daily statistics collection scripts or do this periodically by your hands – which ever way you choose take your backups regularly. I have seen lot’s of cases where there was no backups from switch and on crash admins needed to create everything from scratch. Implement this also to your storage systems if possible, at least IBM’s high end storage systems has features which allows you to take backups of configs. Config files are usually really small and there shouldn’t be place where there is no disk/tape space for backups of such a important things like SAN switches and storage systems. From SAN switches you might also want to keep backup of your license files as getting new license files from Cisco/Brocade can take while.

IBM added new disk choices for Storwize V7000

Posted on by

Recently IBM added two new disk choices for the Storwize V7000 in the 2.5″ form factor:

  • 300 GB 15k SAS
  • 1 TB 7.2k Nearline (NL) SAS

This adds total choices of 2.5″ disks for Storwize V7000 to seven.

  • 300 GB SSD
  • 146 GB 15k SAS
  • 300 GB 15k SAS
  • 300 GB 10k SAS
  • 450 GB 10k SAS
  • 600 GB 10k SAS
  • 1 TB 7.2k Nearline SAS

and of course there is still 3.5″ 2TB Nearline SAS disk available.

All new disks should be available in this week.

Original release notes can be found here.

Why IBM’s XIV matters?

Posted on by

IBM’s XIV has raised lot’s of discussion on market, mostly because IBM claims that it’s enterprise class storage system running on SATA disks which are considered to be more midrange stuff.

There are plenty of cases where customers have evaluated IBM’s XIV storage system and realized that it’s amazing product. Here are couple of examples why XIV really matters:

  • A service provider that had used EMC disk systems for over 10 years evaluated the IBM XIV versus upgrading to EMC V-Max. The three year total cost of ownership (TCO) of EMC’s V-Max was $7 Million US dollars higher, so EMC counter-proposed CLARiiON CX4 instead. Customer selected XIV.
  • A large US bank holding company managed to get 5.3 GB/sec from a pair of XIV boxes for their analytics environment. That’s amazing performance from SATA disks!

I have seen IBM’s XIV in couple of customer environments and it’s really proven to be enterprise storage. IBM recently upgraded XIV to third generation. Same time they announced that XIV will have in future option for SSD caching which is claimed to change performance to next level at a fraction of typical SSD storage costs. Will this happen really, I will bet that this feature comes quite soon. At the same time they also made internal cache larger, added faster disk controllers and changed internal connection to InfiniBand.

IBM has proven that you can create really good performing storage by looking this from other point of view and using generic intel x64 hardware and generic SATA-disks. In fact XIV was not invented by IBM but company which was founded by Moshe Yanai (who actually leaded EMC’s Symmetrix development).

Read more about XIV from IBM’s XIV page.

Could iSCSI provide enough performance?

Posted on by

Allmost every day I face up situation where people are thinking could iSCSI provide enough performance? Usually it’s quite relevant to know what kind of environment is and what kind of architecture design is used but in most of the cases iSCSI can provide enough IOPS. I’ll try to give you information why.

From storage systems actual storage is shared with several methods but most used once’s are Fibre Channel and NFS, where first is block based. There is also quite many other ways to share storage, like iSCSI and FCoE, which has been hot topic for quite long now and big bang of FCoE has been waited for couple of years now. From performance point biggest improvement for last two once’s has been 10 Gbit/s ethernet technology which provides good pipe for data movement.

Intel showed on 2010’s Microsoft Management Summit iSCSI performance where they managed to get from software iSCSI and 10 Gbit/s ehternet-technology over 1 million IOPS (IO operations per second) which is quite nice. In same summit they had nice demo on their booth where they showed environment with Intel’s Xeon 5600-chipset and Microsoft software iSCSI-initiator which was able to do more than 1.2 million IO operation per second with CPU usage of almost 100%. It’s quite relevant to understand that when you have CPU utilization near 100% you cannot actually do anything else than just this IO, but this shows that you can get really massive performance by using iSCSI and 10 Gbit/s ethernet.

At past iSCSI’s bottleneck was 1 Gbit/s ethernet connection. Of course there was ways to get better performance by designing architecture correct but in most of iSCSI storage there was only 4 pcs of 1 Gbit/s connections. When 10 Gbit/s connection got more introduced to storage systems it enabled more and more cases where iSCSI was comparable solution for Fibre Channel. There used to be also dedicated iSCSI-cards in market but they are mostly gone because CPU technology got so good that CPU overhead of iSCSI was not anymore so relevant. Nowadays most of 10 Gbit/s ethernet cards can do iSCSI encapsulation on their internal chip so it won’t affect to CPU so much neither.

10 Gbit/s ethernet-technology has helped a lot and you don’t need separate SAN-networks anymore if you go with iSCSI or FCoE. You can use already exciting 10 Gbit/s connections which are now common and mostly standard on Blade-systems. Still in big environments you should have separation between your data networks and storage networks, but this can be done with proper network architecture and VLAN’s. But I would still like to do separation (at least in core level) for storage and data networking to avoid cases where problems in data networking might affect your storage systems.

FCoE is coming for sure, but there are still some limitations on it and mostly lack of native FCoE storage is reason for this. However if you are doing investment for network renewal I would keep FCoE in mind and do all new networks in way that FCoE can be implemented with less work when the time comes. While waiting, iSCSI might be good alternative for FC.

….but I still prefer old school fibre channel. Why? Brocade just released 16 Gbit/s FC-switches and again FC is faster 😉

Read more about Intel’s iSCSI performance test from here..

Brocadelta 16 gigainen FC-liityntä

Posted on by

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

Posted on by

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.

Miten otan käyttöön FCoE:n Ciscon Nexus-laitteissa

Posted on by

Fibre Channel over Ethernet (FCoE) on teknologia joka helpottaa erittäin paljon konesaliympäristöjen kaapelointia yhdistämällä samalla kuituyhteydellä sekä perinteisen IP-tietoliikenteen että SAN-yhteydet. Teknologian etu tulee erittäin nopeasta 10 Gbit/s -linkistä sekä sen oikeaoppisesta hyödyntämisestä. Perinteisesti blade-ympäristöissä on ollut erikseen 1 Gbit/s-nopeudella toimivat tietoliikenneyhteydet ja lisäksi 4/8 Gbit/s-nopeudella toimivat FC-moduulit. Suurimmista valmistajista HP on jo pitkään tuonut blade-kehikkonsa nopealla 10 Gbit/s-yhteydellä ja nyt myös esim. IBM:n kehikoihin on saatavilla moduulit tähän tarkoitukseen. FCoE:n käyttöönottaminen on erittäin helppoa, mikäli käytössä oleva CNA-kortti on tuettu käytetyllä käyttöjärjestelmällä. Kytkinpuolella FCoE:n käyttöönotto on lyhykäisyydessään seuraavanlainen prosessi:

1. Otetaan FCoE-ominaisuus käyttöön.
2. Yhdistetään VSAN jota käytetään FCoE-liikenteeseen sopivaan VLANiin.
3. Luodaan virtuaalinen Fibre Channel-rajapinta joka kuljettaa FCoE-sanomat.

Ciscon Nexus mahdollistaa ominaisuuksien käyttöönottamisen erittäin helposti joten ensimmäinen kohta on suorastaan lasten leikkiä, ajetaan vain yksi komento:

switch(config)# feature fcoe

Seuraava tehtävä on määritellä yhteys käytettävän VSANin ja VLANin välille. Käytännössä käytettävä VSAN määräytyy helposti. Yleisesti Nexus 5000-sarjan kytkimistä menee yhteydet Ciscon MDS-kytkimiin joissa itse levyjärjestelmät ovat kiinni. Käytännössä VSANin tulee siis olla täysin sama jota käytetään MDS:n puolella koska muuten liikenne ei koskaan kulje perille asti. Tämä kohta on kuitenkin pakollinen tehtävä, muuten FCoE-rajapinta ei nouse ylös. Tässä esimerkissä käytetään VSANia 210 ja VLANia 210.

switch(config)# vlan 210
switch(config-vlan)# fcoe vsan 210
switch(config-vlan)# exit

Kun itse VSAN on mäpätty sopivaan VLANiin jatketaan luomalla virtuaalinen fibre channel-rajapinta (vfc). Jokaisessa Nexuksen portissa, jolla on tarkoitus liikennöidä FCoE-liikennettä, tulee olla VFC määriteltynä. Yleisesti jokaista porttia kohden tehdään oma VFC jonka numero vastaa käytettyä porttia. Esimerkissa käytetään porttia yksi

switch(config)# interface vfc 1
switch(config-if)# bind interface ethernet 1/1
switch(config-if)# no shutdown
switch(config-if)# exit

Vaikka tässä vaiheessa voisi olettaa niin yhteys ei vielä toimi koska luotu VFC tulee myös liittää käytettyyn VSANiin, tämä selviää myös katsomalla interfacea “show interface vfc”-komennolla:

vfc1 is down (VSAN not mapped to an FCoE enabled VLAN)

Kun FCoE VSAN on määritelty sopivaan VLANiin tarvitsee enää ainoastaan liittää luotu VFC sopivaan VSANiin:

switch(config)# vsan database
switch(config-vsan-db)# vsan  interface vfc
switch(config-vsan-db)# exit

Tässä vaiheessa VFC:n pitäisi olla ylhäällä ja koneen yhteystiedot pitäisi löytyä “show flogi database”-komennolla. Nyt itse FCoE-osuus on hoidettu ja ainoa jäljellä oleva tehtävä on luoda sopivat aliakset WWN:llä ja liittää ne oikeisiin zone-määrityksiin jotta kone näkee levyjärjestelmän. Nämä tehdään kuitenkin aivan samalla tavalla, riippumatta siitä käytetäänkö perinteistä FC:tä vai FCoE:tä.