Lustre-tiedostojärjestelmä

CSC:n supertietokoneet käyttävät Lustrea rinnakkaisena hajautettuna tiedostojärjestelmänä. Tämä artikkeli tarjoaa lyhyen teknisen kuvauksen Lustresta.

Lustren arkkitehtuuri

Lustre erottaa tiedostodatan ja metadatan omiin palveluihinsa. Data on tiedoston varsinainen sisältö, kun taas metadata sisältää tietoja kuten tiedoston koon, käyttöoikeudet, käyttöpäivän jne.

Lustre-tiedostojärjestelmä koostuu joukosta I/O-palvelimia, joita kutsutaan nimellä Object Storage Servers (OSS), sekä levyistä, joita kutsutaan nimellä Object Storage Targets (OST), joille varsinainen data tallennetaan. Tiedoston metadataa hallitsevat Metadata Servers (MDS), ja se tallennetaan Metadata Targets (MDT) -kohteisiin. Käytännössä palvelimet käsittelevät pyynnöt tiedoston sisällön ja metadatan käyttämiseksi; sovellukset eivät käytä levyjä suoraan. Lustre-järjestelmissä käytetään tyypillisesti useita OSS-/MDS-palvelimia yhdessä useiden OST-/MDT-kohteiden kanssa rinnakkaisen I/O:n mahdollistamiseksi.

• Object Storage Servers (OSS): Ne käsittelevät asiakkaiden pyynnöt tallennustilan käyttämiseksi. Lisäksi ne hallinnoivat joukkoa OST-kohteita; kullakin OSS-palvelimella voi olla useampi kuin yksi OST I/O-rinnakkaisuuden parantamiseksi.
• Object Storage Targets (OST): Yleensä OST koostuu RAID-konfiguraation alla olevasta tallennuslaitteiden lohkosta. Data tallennetaan yhteen tai useampaan objektiin, ja kukin objekti tallennetaan erilliselle OST-kohteelle.
• Metadata Server (MDS): Palvelin, joka seuraa kaiken datan sijainteja, jotta se voi päättää, mitä OSS- ja OST-kohteita käytetään. Esimerkiksi kun tiedosto on avattu, MDS ei enää osallistu toimintaan.
• Metadata Target (MDT): Tallennuskohde sisältää tietoja tiedostoista ja hakemistoista, kuten tiedostokoista, käyttöoikeuksista ja käyttöpäivistä. Kunkin tiedoston osalta MDT sisältää tietoa datan sijoittelusta OST-kohteisiin, kuten OST-numerot ja objektitunnisteet.

Lustre-tiedostojärjestelmän näkymä

Lustre on suunniteltu tehokkaaseen rinnakkaiseen I/O:hon suurille tiedostoille. Pienten tiedostojen ja intensiivisten metadataoperaatioiden kanssa MDS/MDT voi kuitenkin muodostua pullonkaulaksi. Esimerkiksi kun käyttäjä avaa/sulkee tiedoston monta kertaa silmukassa, MDT:n kuormitus kasvaa. Kun useat käyttäjät tekevät samankaltaisia operaatioita, metadataoperaatiot voivat hidastaa koko järjestelmää ja vaikuttaa moniin käyttäjiin. Koska kirjautumis- ja laskentasolmut jakavat saman tiedostojärjestelmän, tämä voi näkyä jopa tiedostojen hitaana muokkauksena kirjautumissolmulla. Myös rinnakkaissovelluksessa metadataoperaatiot voivat hidastaa toimintaa, jos eri prosessit tekevät paljon operaatioita samoille pienille tiedostoille. Myös viattoman näköiset Linux- komennot voivat lisätä metadatakuormaa: esimerkiksi ls -l tulostaa tiedoston metadataa, ja komennon antaminen hakemistossa, jossa on paljon tiedostoja, aiheuttaa paljon pyyntöjä MDS:lle.

Tiedostojen stripe-jako ja kohdistus

Jotta Lustren rinnakkaisesta I/O:sta saadaan hyötyä, datan tulee olla jaettuna useille OST-kohteille. Tätä jakamista useille OST-kohteille kutsutaan tiedoston stripe-jakamiseksi. Loogisesti tiedosto on lineaarinen tavujono. Stripe-jaossa tiedosto pilkotaan tavulohkoihin, jotka sijaitsevat eri OST-kohteilla, jolloin luku- ja kirjoitusoperaatiot voidaan suorittaa samanaikaisesti.

Stripe-jako voi kasvattaa tiedostojen käytettävissä olevaa kaistanleveyttä, mutta samalla syntyy myös lisäkuormaa lisääntyneiden verkko-operaatioiden ja mahdollisen palvelinkilpailun vuoksi. Siksi stripe-jako on yleensä hyödyllistä vain suurille tiedostoille.

Koska supertietokoneissa on paljon enemmän solmuja kuin OSS-/OST-kohteita, I/O- suorituskyky voi vaihdella paljon koko supertietokoneen I/O-kuormasta riippuen.

Rinnakkaisohjelmassa suorituskyky paranee, kun kukin rinnakkainen prosessi käyttää rinnakkaisen I/O:n aikana tiedoston eri stripeä. Lisäksi verkon ruuhkautumisen välttämiseksi kunkin prosessin tulisi käyttää mahdollisimman harvoja OST-/OSS-kohteita. Tämä voidaan saavuttaa stripe-kohdistuksella. Paras suorituskyky saavutetaan, kun data jakautuu tasaisesti OST-kohteille ja rinnakkaisprosessit käyttävät tiedostoa siirtymistä, jotka vastaavat stripe-rajoja.

Lustren tiedostojen stripe-jako ja kohdistus

Jos yllä olevassa esimerkissä tiedosto olisi kooltaan 5 Mt, OST 0:lla olisi ylimääräinen 1 Mt dataa. Jos data jaettaisiin tasaisesti neljän prosessin kesken, kullakin prosessilla olisi 1,5 Mt eikä käyttö olisi stripe-kohdistettua: ensimmäisen prosessin täytyisi käyttää OST 0:aa ja 1:tä, seuraavan prosessin OST 1:tä ja 2:ta, jne. prosessit eivät olisi kohdistettuja. Tämä voisi aiheuttaa verkon ruuhkautumiseen liittyviä ongelmia.

Stripe-jaon hallinta

CSC:n Lustressa oletusstripe-koko on 1 Mt ja stripe count on 1, eli oletuksena tiedostoja ei stripe-jaeta. Stripe-asetuksia voidaan kuitenkin muuttaa käyttäjän toimesta, mikä voi parhaimmillaan parantaa I/O-suorituskykyä merkittävästi.

Tiedoston tai hakemiston stripe-asetukset voidaan tarkistaa lfs getstripe -komennolla

lfs getstripe my_file

joka tulostaa:

my_file
lmm_stripe_count:  2
lmm_stripe_size:   1048576
lmm_pattern:       raid0
lmm_layout_gen:    0
lmm_stripe_offset: 11
    obdidx         objid        objid         group
        11      29921659    0x1c8917b             0
        20      29922615    0x1c89537             0

Tuloste osoittaa, että tiedosto on jaettu kahdelle OST-kohteelle (stripe count 2), ja tuloste näyttää myös, että kyseiset OST-kohteet ovat 11 ja 20.

Hakemiston kohdalla tuloste näyttää asetukset, joita käytetään kaikille hakemistoon luotaville tiedostoille.

Stripe-konfiguraatio voidaan asettaa lfs setstripe -komennolla. Useimmissa tapauksissa riittää, että asetetaan stripe count -c- valinnalla, mutta myös muita valintoja voidaan käyttää, ks. esim. man lfs-setstripe tai Lustre- wiki.

mkdir experiments
lfs setstripe -c 4 experiments
touch experiments/new_file

Komennon lfs getstripe experiments/new_file suorittaminen tulostaa nyt:

experiments/new_file
lmm_stripe_count:  4
lmm_stripe_size:   1048576
lmm_pattern:       raid0
lmm_layout_gen:    0
lmm_stripe_offset: 6
    obdidx         objid        objid         group
         6      29925064    0x1c89ec8             0
         1      29925258    0x1c89f8a             0
        19      29926834    0x1c8a5b2             0
        15      29921764    0x1c891e4             0

Stripen asettaminen tiedostolle on pysyvää

Jos tiedosto on jo luotu tietyllä stripe-asetuksella, sitä ei voi muuttaa. Myöskään jos siirrät tiedoston, sen stripe-asetukset eivät muutu. Stripe-jaon muuttamiseksi tiedosto täytyy kopioida:

• luo setstripe-komennolla uusi tyhjä tiedosto halutuilla stripe-asetuksilla ja kopioi sitten vanha tiedosto uuteen tiedostoon, tai
• määritä hakemisto halutulla konfiguraatiolla ja kopioi (älä siirrä) tiedosto hakemistoon.

Lustre-pakkaus

Roihun Lustre-tiedostojärjestelmässä käyttäjät voivat myös muuttaa asetuksia tiedostopakkauksen käyttöönottoa varten. Pakkaus voi merkittävästi vähentää hyvin pakkautuvien tiedostojen käyttämää fyysistä tallennustilaa, ja joissakin tapauksissa se voi myös parantaa I/O-suorituskykyä vähentämällä tallennusjärjestelmän ja laskentasolmujen välillä siirrettävän datan määrää.

Lustre-pakkausta ei vielä tueta Roihussa, ja siitä tiedotetaan myöhemmin.

Erot Roihun, Puhdin ja Mahdin välillä

Roihussa, Puhdissa ja Mahdissa on samankaltaiset tallennusalueet koti, projekti ja scratch, mutta niiden Lustre- konfiguraatio ei ole sama.

Name	Roihu		Puhti		Mahti.
Disk area	# OSTs	# MDTs	# OSTs	# MDTs	# OSTs	# MDTs
home	4	4	24	4	8	1
projappl	4	4	24	4	8	1
scratch	24	4	24	4	24	2

Yksi järjestelmien tärkeimmistä eroista on tallennusalueiden erottelu. Mahdissa scratch, home ja projappl käyttävät erillisiä MDT-kohteita, joten eri tiedostojärjestelmien metadatasuorituskyky ei häiritse toisiaan. Lisäksi Mahdin scratch voi tarjota parempaa suorituskykyä kuin muut tallennusalueet, jos sovelluksesi ja datan määrä ovat riittävän suuria, koska siinä on enemmän OST- ja MDT-kohteita. Vastaavasti Roihussa scratch on erillään home- ja projappl-alueista. Puhdissa sen sijaan kaikki OST- ja MDT-kohteet ovat yhteisiä tallennusalueiden kesken, joten suorituskyvyn pitäisi olla niiden välillä samankaltainen.

Mahdin I/O:n huippusuorituskyky on kirjoituksessa noin 100 Gt/s ja luvussa 115 Gt/s. Tämä suorituskyky saavutettiin kuitenkin dedikoidussa järjestelmässä 64 laskentasolmulla, mikä tarkoittaa noin 1,5 Gt/s laskentasolmua kohden. Jos käytössä on enemmän solmuja tai monet työt tekevät merkittävästi I/O:ta, et saavuta 1,5 Gt/s nopeutta. Lisäksi sovelluksen I/O-malli ei välttämättä ole tehokas. Puhdin vastaava suorituskyky on puolet Mahdin suorituskyvystä.

Roihun scratch-alueen huippusuorituskyky on parantunut aiempiin järjestelmiin verrattuna: kirjoituksen huippu-I/O on 219 Gt/s ja luvun 180 Gt/s.

Parhaat käytännöt

• Jos mahdollista, vältä ls -l-komennon käyttöä, koska omistajuus- ja käyttöoikeusmetadata tallennetaan MDT-kohteille, kun taas tiedostokoon metadata on saatavilla OST-kohteilta. Käytä sen sijaan ls-komentoa, jos et tarvitse lisätietoja.

• Vältä tallentamasta suurta määrää tiedostoja yhteen hakemistoon; on parempi jakaa ne useampiin hakemistoihin.

• Jos mahdollista, vältä suuren määrän pieniä tiedostoja käyttämistä Lustressa.

• Varmista, että pienten tiedostojen stripe count on 1.

• Jos sovellus avaa tiedoston lukemista varten, avaa tiedosto vain luku -tilassa.

• Kasvata stripe countia rinnakkaiskäyttöä varten, erityisesti suurilla tiedostoilla:

  • Stripe-tekijän tulisi olla käytettyjen rinnakkaista I/O:ta suorittavien prosessien lukumäärän tekijä
  • Nyrkkisääntönä stripe-jakona kannattaa käyttää tiedostokoon neliöjuurta gigatavuina. Jos tiedosto on 90 Gt, neliöjuuri on 9,5, joten käytä vähintään 9 OST-kohdetta.
  • Jos käytät esimerkiksi 16 MPI-prosessia rinnakkaiseen I/O:hon, käytettyjen OST-kohteiden määrän tulisi olla enintään 16.

Lisätietoja on Lustren suorituskyvyn optimointiohjeessa.

Onko tämä sivu hyödyllinen?

Kyllä

Kiitos palautteestasi!

Ei

Kiitos! Arvostamme palautettasi.

Kerro meille miten voisimme parantaa tätä sivua ottamalla meihin yhteyttä.