Hyppää sisältöön

Welcome to our weekly research support coffee hour on Zoom! Click here for more information.

Warning!

Puhti scratch disk is becoming very full (80+ % ) resulting in performance degradation. Everybody is advised to only keep actively processed data on scratch, all other data should be deleted, transferred to host institute or stored in Lumi-O. No new quota will be granted. Click here for a tool for examining your disk usage.

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 tallennuksen käyttämiseksi. Lisäksi ne hallitsevat joukkoa OST-kohteita; kullakin OSS-palvelimella voi olla useampi kuin yksi OST I/O-rinnakkaisuuden parantamiseksi.
  • Object Storage Targets (OST): Yleensä OST koostuu RAID-kokoonpanoon liitetyistä tallennuslaitteista. 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): Tallennus sisältää tietoa tiedostoista ja hakemistoista, kuten tiedostokoista, käyttöoikeuksista ja käyttöpäivistä. Jokaisen tiedoston osalta MDT sisältää tietoa datan sijoittelusta OST-kohteisiin, kuten OST-numerot ja objektitunnisteet.

"Kaaviokuva laskentasolmuista, jotka käyttävät OST- ja MDT-kohteita OSS- ja DST-palvelimien kautta verkon yli. Lyhenteet ja niiden suhteet selitetään myös tekstissä."

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 toimintoja, 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 eri prosessien suorittaessa paljon operaatioita samoille pienille tiedostoille metadataoperaatiot voivat hidastaa toimintaa. Viattoman näköiset Linux- komennotkin voivat lisätä metadatakuormaa: esimerkiksi ls -l tulostaa tiedoston metadataa, ja komennon antaminen hakemistossa, jossa on paljon tiedostoja, aiheuttaa paljon pyyntöjä MDS:lle.

Tiedoston 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-jaoksi. Loogisesti tiedosto on lineaarinen tavujono. Stripe-jaossa tiedosto pilkotaan tavulohkoihin, jotka sijaitsevat eri OST-kohteilla, jolloin luku-/kirjoitusoperaatiot voidaan suorittaa samanaikaisesti.

Stripe-jako voi kasvattaa tiedostojen käyttöön saatavilla olevaa kaistanleveyttä, mutta samalla syntyy myös lisäkuormaa verkko-operaatioiden lisääntymisestä ja mahdollisesta palvelinkilpailusta. Siksi stripe-jaosta on yleensä hyötyä vain suurille tiedostoille.

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

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

"Kaavio, jossa tiedosto on jaettu lohkoihin ja kukin lohko on tallennettu eri OST-kohteelle."

Lustren stripe-jako ja kohdistus

Jos yllä olevassa esimerkissä tiedoston koko olisi 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 ja käyttö ei 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 nyt aiheuttaa verkkokilpailuongelmia.

Striping-asetusten hallinta

CSC:n Lustressa oletus-stripe-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-kokoonpano voidaan asettaa lfs setstripe -komennolla. Useimmissa tapauksissa riittää, että asetetaan stripe count -c- valinnalla, mutta myös muita valintoja voidaan käyttää, katso esimerkiksi man lfs-setstripe tai Lustre- wiki.

mkdir experiments
lfs setstripe -c 4 experiments
touch experiments/new_file
Komennon lfs getstripe experiments/new_file suorittaminen tuottaa 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

!!!! Huomaa Jos tiedosto on jo luotu tietyllä stripe-jaolla, sitä ei voi muuttaa. Myöskään tiedoston siirtäminen ei muuta sen stripe-asetuksia. Jotta stripe-jakoa voidaan muuttaa, 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 kokoonpanolla ja kopioi (älä siirrä) tiedosto hakemistoon.

Erot Puhdin ja Mahdin välillä

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

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

Yksi keskeinen ero on, että Mahdissa scratch-, home- ja project- alueilla on erilliset MDT-kohteet, joten metadata-suorituskyky ei häiriinny eri tiedostojärjestelmien välillä. Lisäksi Mahdin scratch voi tarjota parempaa suorituskykyä kuin muut tallennusalueet, jos sovelluksesi ja datan koko ovat riittävän suuria, koska siellä on enemmän OST- ja MDT-kohteita. Puhdissa kaikki OST- ja MDT-kohteet ovat yhteisiä tallennusalueiden kesken, joten suorituskyvyn pitäisi olla samankaltainen niiden välillä.

Mahdin huippu-I/O-suorituskyky 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ä.

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ä ls-komentoa, jos et tarvitse lisätietoja.

  • Vältä tallentamasta suurta määrää tiedostoja yhteen hakemistoon, vaan jaa ne mieluummin useampaan hakemistoon.

  • 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 lukutilassa.

  • 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 optimoinnin oppaassamme.

Suomenkielinen tekoälykäännös

Sisällössä voi esiintyä virheellistä tietoa tekoälykäännöksestä johtuen.

Klikkaa tästä antaaksesi palautetta