Olen suuri Cephin, avoimen lähdekoodin, massiivisesti skaalautuvan ohjelmistomuotoisen tallennusratkaisun, fani. Sen kyky itsestään parantua ja selviytyä muutoin traumaattisista klusteritapahtumista (oi, menetit solmun? ei ongelmaa!) yhdistettynä siihen, että siinä ei ole yksittäisiä vikapisteitä, tekee siitä suosikkini.
Alhaalla on kolme yksinkertaista periaatetta, jotka voivat auttaa ohjaamaan suurten tai pienten klusterien suunnittelua.
Jos pääpainopisteenäsi ovat dollarit tallennustilamegatavua kohden, saatat luonnollisesti pyrkiä käyttämään palvelimia, jotka pystyvät ottamaan vastaan suurimman mahdollisen määrän levyjä, ja suurimpia levyjä.
Tässä kohtaa kannattaa olla varovainen. ”Kapeisiin ja syviin” klustereihin liittyy muutamia näkökohtia:
- Jokaiseen solmuun mahtuu suurempi prosenttiosuus klusterin datasta. Esimerkki: Kolmen solmun klusterissa kullakin solmulla on 33 % datasta. Kymmenen solmun klusterissa se on vain 10 % per solmu. Yksittäisen solmun menettäminen pienessä klusterissa johtaa huomattavasti suurempaan datan siirtymiseen, erityisesti kun klusteri alkaa täyttyä, ja mahdollisesti käyttökatkokseen, jos et ole konfiguroinut klusterin täysien ja lähes täysien solmujen suhdelukuja oikein.
- Pakottaa enemmän verkkoliikennettä harvempiin solmuihin. Ceph on verkkopohjainen tallennusjärjestelmä, joten vähemmillä solmuilla pakotat paljon asiakasliikennettä vähemmille verkkokortille. Tämä pahenee, kun levyjen määrä solmua kohden kasvaa, koska sinulla on enemmän OSD-levyjä kilpailemassa rajallisesta kaistanleveydestä. Vielä pahempaa on se, että toipumistapahtumien aikana toipumisliikenne kilpailee asiakkaan I/O:n kanssa verkon kautta, mikä vaikuttaa käyttäjäkokemukseen entisestään.
- Kun solmua kohti on paljon levyjä, levyohjain voi olla pullonkaula, jos sen kaistanleveys ei riitä kuljettamaan kaikkia levyjä täydellä nopeudella.
- Lisääntyvä toipumis- ja parantumisaika, kun menetät kokonaisen solmun, koska enemmän dataa on replikoitava ja palautettava.
Kokonaisklusterin suorituskyky skaalautuu erittäin hyvin solmujen määrän kasvaessa. Täältä löydät vertailun 3 solmun vs. 5 solmun klusterista BlueStorella.
Jos tähtäät suureen klusteriin, vastusta kiusausta pakata kaikki levyt mahdollisimman harvoihin solmuihin.
Yhteenvetona:
- Ceph skaalautuu erittäin hyvin solmujen lukumäärän kasvaessa.
- Jos klusterissa on liian vähän solmuja, sijoitat enemmän klusterin dataa kuhunkin solmuun, mikä kasvattaa talteenoton I/O:ta ja talteenottoaikoja.
- Voit aloittaa jo kolmella solmulla, mutta jos sinulla on varaa hajauttaa levyt useampaan solmuun, niin kannattaa tehdä niin.
Ole avokätinen verkkoyhteyksien kanssa
Palvelimeen ei kannata laittaa nopeita tietovälineitä ja sitten hankaloittaa niitä 1 GbE:n verkkoyhteydellä. Tavoittele vähintään 10 GbE:tä tuotantoa varten, ja vielä parempi on, että sinulla on useita 10 Gb:n liitäntöjä, jotka on yhdistetty LACP:llä (Link Aggregation Control Protocol) kaistanleveyden lisäämiseksi. Ceph on verkkopohjainen tallennusjärjestelmä, joten yksi asia, jota klusterista ei saisi puuttua, on verkon kaistanleveys.
Erottele aina julkisesti käytettävä verkko klusterin sisäisestä verkosta. Julkinen verkko välittää asiakasliikennettä, kun taas sisäinen verkko välittää heartbeat-, replikointi- ja palautusliikennettä käyttöjärjestelmien välillä. Jos voit säästää verkkokortteja, siirrä nämä kaksi verkkoa erillisten liitäntöjen kautta. Niiden erottaminen toisistaan parantaa asiakkaiden reagointikykyä toipumistapahtumien aikana ja auttaa toipumistapahtumia päättymään nopeammin, koska toipumisen I/O ei kilpaile asiakkaan I/O:n kanssa samassa verkkokortissa.
Muista myös, että sisäinen verkko kuljettaa replikaatioliikennettäsi, joten jokainen kirjoitus julkisessa verkossa aiheuttaa (n-1) kirjoitusoperaatiota sisäisessä verkossa, missä n on replikaatioiden määrä. Ceph kuittaa kirjoituksen asiakkaalle vasta, kun se on kirjoitettu kaikkien replikoiden journal/WAL:iin – joten et halua replikointikirjoitusten muodostavan pullonkaulaa verkossa. Jos käytät paljon replikoituja pooleja, harkitse klusteriverkon mitoitusta n-1 kertaa suuremmaksi kuin julkinen verkko.
Viimeiseksi, varmista redundanssin vuoksi, että kaapeloit solmusi redundantteihin top of rack -kytkimiin. Et halua menettää kokonaista solmua – tai solmujen joukkoa – koska yksi kytkin on vikaantunut!
Yhteenvetona:
- 10Gbit Ethernet tuotantoon vähintään.
- Erottele julkinen verkko ja klusteriverkko, mieluiten eri verkkokortteihin, mutta ainakin eri VLANeihin/alaverkkoihin.
- Muista (n-1) nyrkkisääntö replikoidulle datalle – harkitse sisäisen verkon mitoitusta n-1 kertaa suuremmaksi kuin julkinen.
- Älkää unohtako kaapeloida redundanssia varten ja luoda sidokset oikein käyttöjärjestelmätasolla.
- Ja lisänä: älkää unohtako jumbo-kehyksiä rajapinnoillanne!
Flash-media BlueStore-metatietoja varten.
Ceph kuittaa kirjoituksen asiakkaalle vasta, kun tiedot on kirjoitettu ensisijaisen OSD:n write-ahead-lokiin (WAL) ja kaikkien replikoiden WAL:iin. Mitä nopeammin WAL:iin kirjoitetaan, sitä nopeammin Ceph siis kuittaa kirjoituksen ja sitä paremmat kirjoituksen IOPS-arvot asiakkaalle saadaan.
WAL-tietueesi ja mieluiten BlueStore RocksDB:n metatietosi pitäisi olla nopeimmalla mahdollisella tietovälineellä – vähintään SSD-levyllä ja NVMe-levyllä, jos mahdollista. Jos olet rakentamassa täyttä HDD-klusteria, harkitse vahvasti pienen lisämaksun käyttämistä solmua kohden ja vähintään kahden nopean medialaitteen lisäämistä metadataa ja WAL:ia varten.
Välttääksesi pullonkauloja nopealla medialaitteellasi harkitse datalevyjesi kestävää kirjoitusnopeutta ja vertaa sitä nopean laitteesi kestävään kirjoitusnopeuteen. Jos kiintolevysi pystyy kirjoittamaan 100 Mt/s kestävällä nopeudella ja SSD-levysi 500 Mt/s kestävällä nopeudella, niin jos SSD-levyä kohti on enemmän kuin 4-5 OSD-levyä, SSD-levy muodostaa pullonkaulan kirjoitusten osalta. NVMe sopii täydellisesti tähän käyttötapaukseen, koska niiden jatkuvat kirjoitusnopeudet voivat nousta gigatavuihin sekunnissa.
Viimeiseksi, käytä aina useampaa kuin yhtä SSD/NVMe-laitetta solmua kohden metadataa/WAL:ia varten varmistaaksesi, ettet menetä kaikkia solmun OSD-levyjä, jos metadatalaite pettää.
Yhteenvetona:
- Ceph kuittaa kirjoituksen asiakkaalle, kun se on kirjoitettu ensisijaisen OSD:n WAL:iin ja kaikkien replikoiden WAL:iin. Se tekee näin säilyttääkseen datan eheyden.
- WAL:n ja RocksDB:n tulisi olla nopeimmalla mahdollisella medialla – mieluiten NVMe:llä – jotta saat vastauksen asiakkaalle mahdollisimman nopeasti.
- Älä liioittele nopeita laitteita WAL:lle/RocksDB:lle. Jos teet niin, siirrät pullonkaulan vain nopealle laitteellesi.
- Harrasta useampaa kuin yhtä nopeaa laitetta, jotta vältyt menettämästä kaikki OSD:t solmussa, jos WAL-laitteesi vikaantuu.
Yhteenveto
Ceph on verkkopohjainen ohjelmistomääritelty tallennusjärjestelmä, joka skaalautuu horisontaalisesti poikkeuksellisen hyvin. Edellä on vain muutama periaate, joiden avulla voit koota suorituskykyisen järjestelmän – älä mene liian kapealle tai syvälle, pidä klusteri ruokittuna kaistanleveydellä ja käytä nopeita medioita metatietoja ja WAL:ia varten.