Volumet ovat vikasietoisilla levyjärjestelmillä sijaitsevaa massamuistia jotka voidaan liittää yhteen palvelimeen kerrallaan. Volume näkyy kovalevynä palvelimelle, ja sitä voi vapaasti käsitellä haluamallaan tavalla (partitiointi, tiedostojärjestelmät, LVM jne). Volumeja voi myös kasvattaa. Useasta volumesta voi käyttöjärjestelmässä tehdä Stripe-menetelmällä yhden isomman loogisen levyjaon, ja volumen voi sen omistavasta palvelimesta jakaa eteenpäin muille palvelimille käyttöjärjestelmästä (NFS/CIFS/iSCSI ym).
Levytilan luomiseen tarvitaan kolme tietoa:
- Käytettävä saatavuusalue
- Volumen koko
- Volumen nopeusluokka
Luomisen jälkeen volumen voi liittää yhteen palvelimeen kerrallaan.
Volumen voi irrottaa kyseisestä palvelimesta ja sen jälkeen liittää toiseen palvelimeen. Tämä on hyödyllistä esimerkiksi tilanteissa, missä käyttöjärjestelmän vaihdossa tai päivityksessä tehdään rinnalle korvaava instanssi, yliheitossa vanha instanssi sammutetaan ja siihen kiinnitetty volume kiinnitetään uuteen instanssiin. Näin sama data on heti uudella palvelimella käytettävissä.
Käyttötarpeesta riippuen volumen ominaisuuksiin kannattaa kiinnittää huomiota. Esim halvin ja hitain arkistointipinta ei ole paras mahdollinen valinta esimerkiksi tietokantakäyttöön, ja vaihtoehtoisesti kallista SSD-pintaa on turhaa varata varmuuskopioiden säilömiseen.
Palveluita suunnitellessa kannattaa kiinnittää alusta asti huomiota tilantarpeeseen ja datan sijoitteluun. Jälkikäteen tietyn sovelluksen siirtäminen volumelle tai eri hakemistoon palvelimella tarkoittaa pahimmillaan huoltokatkoa tai muutoksia sovelluksen koodiin.
Volumeista voi ottaa snapshoteja ja uusia volumeja voi luoda käyttäen lähteenä volume-snapshotia. Näin saman datan voi kopioida useaan volumeen tai snapshotin kopioimalla jopa nopeusluokasta toiseen.
Volumet toimivat vain omalla saatavuusalueellaan, et voi kiinnittää Helsinki-1 -zonella asuvaa volumea Helsinki-2 –zonella sijaitsevaan palvelimeen.
SUORITUSKYKYRAJAT
Palvelimille on määritelyt IO-rajat. Rajojen tarkoitus on varmistaa että kaikki asiakkaat saavat tehoja saman verran, eikä ikävää “noisy neighbour” efektiä ilmene. Näin asiakkaat voivat olla luottavaisia että suorituskyky on hyvin samanlainen jos käytössä on useita samanalaisia palvelimia. Rajojen määrittelyssä on huomioitu, että yleensä järeämpi palvelin tarvitsee myös enemmän levy IO:ta.
ResurssitKOKOONPANO
IOPS (R)IOPS (W)IO MB/sCPU painoNimi
40030050512nbl-f1-micro1 CPU, 1Gt, 32 järjestelmälevyä
40030050512nbl-n1-tiny1 CPU, 1Gt, 8Gt järjestelmälevyä
800500801024nbl-n1-small1 CPU, 2Gt, 32Gt järjestelmälevyä
10006001001024nbl-m1-small1 CPU, 4Gt, 50Gt järjestelmälevyä
15006001001024nbl-n1-medium2 CPU, 4Gt, 50Gt järjestelmälevyä
30007001251536nbl-m1-medium2 CPU, 8Gt, 50Gt järjestelmälevyä
40007001501536nbl-n1-large4 CPU, 8Gt, 100Gt järjestelmälevyä
40007001501536nbl-m1-large4 CPU, 16Gt, 100Gt järjestelmälevyä
40007001501536nbl-n1-xlarge8 CPU, 16Gt, 100Gt järjestelmälevyä
40008001501536nbl-m1-xlarge8 CPU, 32Gt, 150Gt järjestelmälevyä
40008001502048nbl-n1-2xlarge16 CPU, 32Gt, 150Gt järjestelmälevyä
40008001502048nbl-m1-2xlarge16 CPU, 64Gt, 200Gt järjestelmälevyä
40008001501536nbl-hm1-large2 CPU, 16Gt, 100Gt järjestelmälevyä
40008001502048nbl-hm1-xlarge4 CPU, 32Gt, 150Gt järjestelmälevyä
40008001502048nbl-hm1-2xlarge8 CPU, 64Gt, 200Gt järjestelmälevyä
400010001502048nbl-hm1-4xlarge16 CPU, 128Gt, 300Gt järjestelmälevyä
ONGELMATILANTEITA
Esimerkkiongelma 1:
Sovelluspalvelimelle on luotu volume, nopeusluokka ARK (hitain) ja koko 500GB. Levyillä säilytetään dataa jota luetaan melko aktiivisesti. Levyn lukusuorituskyky ei ole riittävä sovelluksen tarpeisiin nähden, joka aiheuttaa ongelmia sovelluksessa. Lisäksi levytila alkaa olemaan vähissä.
Korjaus:
- Tehdään uusi SAS-nopeusluokan volume, koko 800GB
- Kiinnitetään SAS-volume palvelimeen
- Pysäytetään sovellus hetkeksi levyä käyttävältä palvelimelta
- Kopioidaan ARK-levyn sisältö SAS-levylle
- Kun kopiointi valmis, pysäytetään / unmountataan / irroitetaan ARK-levy käyttöjärjestelmästä ja sen jälkeen hallintapaneelissa irroitetaan ARK-levy palvelimesta
- Kiinnitetään käyttöjärjestelmässä SAS-levy sijaintiin missä ARK-levy oli
- Käynnistetään sovellus
- Jos kaikki toimii oikein, poistetaan ARK-volume.
Esimerkkiongelma 2:
Sovelluspalvelimella olevalta suurelta SAS-volumelta pitäisi saada kaikki tiedostot raportointipalvelimelle jatkokäsittelyä varten, mutta jatkuva kirjoitus estää kopioinnin, data muuttuu nopeammin kuin mitä kopiointiohjelma ehtii lukemaan ja kopio ei ole validi. Käsittely epäonnistuu.
Korjaus:
- Otetaan levystä snapshot, nimetään se ”data-snap”
- Luodaan uusi volume samalle LTK-levytasolle (LTK-SAS). Käytetään volumen lähteenä snapshotia ”data-snap”. Annetaan volumen nimeksi mielikuvituksellisesti ”data-volume”.
- Kun uusi volume on valmistunut, poistetaan snapshot ”data-snap”.
- Kiinnitetään tämä uusi volume raportointipalvelimeen ja käsitellään data.
- Käsittelyn valmistuessa irroitetaan ja poistetaan data-volume.
Tämän esimerkin toimenpiteen voi myös skriptata ja ajastaa cinder-clientia käyttäen, näin raportointikäsittelyn voi automatisoida.
HUOM!
Emme suosittele irrottamaan volumea Pilven hallintapaneelissa mikäli se on edelleen palvelimen käyttöjärjestelmässä aktiivisena. Käyttöjärjestelmälle levyn irtoaminen on käytännössä sama kuin fyysinen kovalevy rikkoutuisi kesken luvun. Se saattaa aiheuttaa huomattavia ongelmia palvelimelle sekä kyseiselle volumelle.
KAPASITEETIN KÄYTTÖASTEEN / LEVYTYYPPIN TARKISTAMINEN
Parhaiten käytetyn levytilakapasiteetin saat katsottua komentorivi työkalulla. Asenna cinder työkalu ensin tietokoneellesi ja sen jälkeen aja komento
cinder quota-usage <tenant_id>
Vastauksena tulee sekä käyttöaste että rajoitukset, jotka ovat käytössä tilissäsi.
VIRTIO AJURIT
Windows updatesta löytyy tällä hetkellä valinnaisena päivityksenä SUSE:n QEMU/KVM jakeluille tehty virtio-ajuripäivitys. Päivitys löytyy ainakin Windows Server 2012 R2:lle. Microsoft jakelee tätä kaikille virtio-laitteille, vaikka tunnetusti virtio ajureissa, kuten monissa muissakin hypervisor kohtaisissa ajuri/tools paketeissa, on versioriippuvuuksia hypervisorin ja ajuriversion välillä. Kyseinen ajuripäivitys rikkoo Windowsin levyohjaimen ajurin ja tekee kyseisen instanssin käynnistämisestä mahdotonta!
Tätä ajuripäivitystä, kuten yleensä muitakaan tuntemattomia ajuripäivityksiä, ei missään nimessä tule asentaa palvelimiin. Varsinkin virtio-ajurien kohdalla on syytä ajaa vain testattua ja tuettua versiota ajureista ellei jonkin ongelmatilanne pakota toisin toimimaan.
Workaround ongelman kiertämiseen tilapäisesti, jotta palvelimen datoihin pääsee käsiksi:
1. Sammuta palvelin
2. Ota palvelimen snapshot
3. Odota, että snapshot valmistuu Image-palveluun
4. Aseta Images-palvelun (Glance) CLI-työkalulla juuri snapshotatulle imagelle IDE-emuloinnin pakotus levyohjaimelle:
$ glance image-update –property hw_disk_bus=ide <snapshot imagen id>
5. Käynnistä uusi palvelin tällä imagella (luonnissa kestää hetki, kun uusi image ei ole hypervisorien cachessa vielä ja Windows image on kooltaan suhteellisen iso)
6. Uusi palvelin preparoi nyt automatic prepairit läpi, mutta valikosta voi valita “Exit and boot to OS”
7. Palvelin on nyt käynnissä IDE emuloidulla (hitaalla) levyllä ja mahdollista elvytystä kuten ajurien poistoa/rollbackkiä jne. voi yrittää
Lisäyksenä kohtien 6. ja 7. jälkeen. Jotain lisäpäivityksiä voi asentua vielä ensimmäisen”preparing automatic repair bootin” jälkeen. Palvelin käynnistyy vielä kerran. Hard reboot tämän jälkeen, palauttaa järjestelmän emuloituun IDE-moodiin. IDE-moodi on tosiaan melko hidas eli kärsivällisyyttä.
Muistattehan että järjestelmän varmuuskopiointi sekä ajantasainen palautussuunnitelma on erittäin tärkeä erilaisia vikatilanteita varten.