Päivittää!. Kommenteissa yksi lukijoista ehdotti kokeilla (ehkä hän työskentelee sen parissa itse), joten olen lisännyt osion tästä ratkaisusta. kirjoitin myös koska prosessi on hyvin erilainen kuin muut.
Rehellisesti sanottuna luovutin ja luovutin (ainakin toistaiseksi). Aion käyttää . Miksi? Säilytyksen takia! Kukapa olisi uskonut, että sotkin enemmän tallennustilan kanssa kuin itse Kuberneteksen kanssa. käytän , koska se on halpa ja suorituskyky on hyvä, ja alusta alkaen otin käyttöön klustereita . En ole kokeillut Kubernetesin hallinnoimia Google/Amazon/Microsoft/DigitalOcean jne jne.-palveluita, koska halusin oppia kaiken itse. Olen myös säästäväinen.
Joten - kyllä, vietin paljon aikaa päättääkseni, minkä tallennustilan valitsen, kun harkitsin mahdollista pinoa Kubernetesissa. Pidän enemmän avoimen lähdekoodin ratkaisuista, enkä pelkästään hinnan takia, vaan katsoin pari maksullista vaihtoehtoa uteliaisuudesta, koska niissä on ilmaisia versioita rajoituksin. Kirjoitin muistiin muutamia lukuja viimeaikaisista vertailuarvoista vertaillessani eri vaihtoehtoja, ja ne saattavat kiinnostaa niitä, jotka opiskelevat tallennustilaa Kubernetesissa. Vaikka henkilökohtaisesti olen sanonut hyvästit Kubernetesille toistaiseksi. Haluan myös mainita , jossa voit tarjota suoraan Hetzner Cloud -taltioita, mutta en ole vielä kokeillut sitä. Tutkin pilviohjelmiston määrittämää tallennustilaa, koska tarvitsin replikointia ja kykyä liittää nopeasti pysyviä taltioita mihin tahansa solmuun, erityisesti solmuvikojen ja muiden vastaavien tilanteiden varalta. Jotkut ratkaisut tarjoavat ajankohtaisia tilannekuvia ja ulkopuolisia varmuuskopioita, mikä on kätevää.
Testasin 6-7 tallennusratkaisua:
Kuten jo sanoin , testattuaani useimpia luettelon vaihtoehdoista päädyin aluksi OpenEBS:ään. OpenEBS on erittäin helppo asentaa ja käyttää, mutta ollakseni rehellinen, testauksen jälkeen todellisella datalla kuormitettuna sen suorituskyky pettyi. Tämä on avoimen lähdekoodin, ja kehittäjät ovat omia aina erittäin hyödyllinen, kun tarvitsin apua. Valitettavasti sillä on erittäin huono suorituskyky muihin vaihtoehtoihin verrattuna, joten jouduin suorittamaan testit uudelleen. Tällä hetkellä OpenEBS:ssä on 3 tallennusmoottoria, mutta julkaisen cStorin vertailutuloksia. Minulla ei ole vielä Jivan ja LocalPV:n numeroita.
Lyhyesti sanottuna Jiva on hieman nopeampi, ja LocalPV on yleensä nopea, ei huonompi kuin aseman vertailuarvo suoraan. LocalPV:n ongelma on, että taltiota voi käyttää vain siinä solmussa, jossa se on varattu, eikä replikointia ole ollenkaan. Minulla oli ongelmia varmuuskopion palauttamisen kanssa uudessa klusterissa, koska solmujen nimet olivat erilaiset. Varmuuskopioista puheen ollen, cStorilla on , jolla voit tehdä off-site-snapshot-varmuuskopioita, mikä on kätevämpää kuin tiedostotason varmuuskopiot Velero-Resticillä. Kirjoitin helpottaaksesi varmuuskopioiden ja palautusten hallintaa tällä laajennuksella. Kaiken kaikkiaan pidän todella OpenEBS:stä, mutta sen suorituskyky...
Rook on myös avoimen lähdekoodin lähde, ja se eroaa muista luettelon vaihtoehdoista siinä, että se on tallennusorganisaattori, joka suorittaa monimutkaisia tallennustilan hallintatehtäviä erilaisilla taustaohjelmilla, esim. , ja muut, mikä yksinkertaistaa huomattavasti työtä. Minulla oli ongelmia EfgeFS:n kanssa, kun kokeilin sitä muutama kuukausi sitten, joten testasin pääasiassa Cephilla. Ceph ei tarjoa vain lohkotallennusta, vaan myös S3/Swiftin ja hajautetun tiedostojärjestelmän kanssa yhteensopivaa objektitallennusta. Pidän Cephissä kyvystä jakaa asematietoja useille levyille, jotta taltio voi käyttää enemmän levytilaa kuin mahtuu yhdelle levylle. Se on mukava. Toinen hieno ominaisuus on, että kun lisäät levyjä klusteriin, se jakaa tiedot automaattisesti uudelleen kaikille levyille.
Cephillä on tilannekuvia, mutta tietääkseni niitä ei voi käyttää suoraan Rook/Kubernetesissa. Kieltämättä en perehtynyt siihen. Mutta paikan päällä ei ole varmuuskopioita, joten sinun on käytettävä jotain Velero / Resticin kanssa, mutta on vain tiedostotason varmuuskopioita, ei ajankohtaisia tilannekuvia. Pidän kuitenkin todella Rookista sen helppoudesta työskennellä Cephin kanssa - se piilottaa melkein kaikki monimutkaiset asiat ja tarjoaa työkaluja, joilla voit keskustella suoraan Cephin kanssa vianetsintää varten. Valitettavasti minulla oli aina Ceph-määrien stressitestissä , mikä saa Cephin muuttumaan epävakaaksi. Ei ole vielä selvää, onko tämä vika itse Cephissä vai ongelma siinä, miten Rook hallitsee Ceph. Pyöritin muistiasetuksia, ja se parani, mutta ongelma ei ratkennut kokonaan. Cephillä on hyvä suorituskyky, kuten alla olevista vertailuarvoista näkyy. Siinä on myös hyvä kojelauta.
Pidän todella Longhornista. Tämä on mielestäni lupaava ratkaisu. Totta, kehittäjät itse (Rancher Labs) myöntävät, että se ei vielä sovellu tuotantoympäristöön, ja tämä näkyy. Se on avoimen lähdekoodin ja sen suorituskyky on kunnollinen (vaikka he eivät ole vielä optimoineet sitä), mutta levyjen kiinnittäminen podiin kestää hyvin kauan, ja pahimmillaan se kestää 15-16 minuuttia, varsinkin kun on palautettu suuri varmuuskopio tai työmäärän päivittäminen. Siinä on tilannekuvia ja varmuuskopioita näistä tilannekuvista, mutta ne koskevat vain levyjä, joten tarvitset silti jotain, kuten Velero, muiden resurssien varmuuskopiointiin. Varmuuskopioinnit ja palautukset ovat erittäin luotettavia, mutta kohtuuttoman hitaita. Vakavasti, aivan kohtuuttoman hidasta. Prosessorin käyttö ja järjestelmän kuormitus kasvavat usein työskennellessäsi keskimääräisen datamäärän kanssa Longhornissa. Longhornin hallintaan on kätevä kojelauta. Sanoin jo, että pidän Longhornista, mutta sitä on työstettävä kunnolla.
StorageOS on listan ensimmäinen maksullinen tuote. Siinä on kehittäjäversio, jonka hallittu tallennustila on rajoitettu 500 Gt, mutta en usko, että solmujen lukumäärää rajoiteta. Myyntiosasto kertoi minulle, että 125 TB hinta alkaa 1 dollarista kuukaudessa, jos muistan oikein. Siellä on peruskojelauta ja kätevä CLI, mutta jotain outoa suorituskyvyssä tapahtuu: joissain benchmarkissa se on melko hyvä, mutta volyymien stressitestissä en pitänyt nopeudesta ollenkaan. Yleisesti ottaen en tiedä mitä sanoa. En siis oikein ymmärtänyt. Täällä ei ole varmuuskopioita sivustolta, ja sinun on myös käytettävä Veleroa Resticin kanssa varmuuskopiointiin. Se on outoa, koska tuote on maksettu. Ja kehittäjät eivät olleet innokkaita kommunikoimaan Slackin kanssa.
Opin Robinista Redditissä heidän teknologiajohtajaltaan. En ollut koskaan ennen kuullut hänestä. Ehkä siksi, että etsin ilmaisia ratkaisuja, ja Robinille maksetaan. Heillä on melko antelias ilmainen versio, jossa on 10 Tt tallennustilaa ja kolme solmua. Yleisesti ottaen tuote on varsin kunnollinen ja mukavilla ominaisuuksilla. Siellä on hieno CLI, mutta hienointa on, että voit ottaa tilannekuvan ja varmuuskopioida koko sovelluksen (kutsutaan Helm-julkaisuiksi tai "flex-sovelluksiksi" resurssivalitsimessa), mukaan lukien volyymit ja muut resurssit, joten voit tehdä ilman Veleroa. Ja kaikki olisi ihanaa, ellei yksittäinen pieni yksityiskohta: jos palautat (tai "tuot", kuten sitä kutsutaan Robinissa) sovelluksen uuteen klusteriin - esimerkiksi katastrofipalautuksen tapauksessa - palauttaminen, tietenkin, toimii, mutta jatka sovelluksen varmuuskopiointia, se on kielletty. Tässä julkaisussa tämä ei yksinkertaisesti ole mahdollista, ja kehittäjät ovat vahvistaneet. Tämä on vähintäänkin outoa, varsinkin kun ottaa huomioon muita etuja (esimerkiksi uskomattoman nopeat varmuuskopiot ja palautukset). Kehittäjät lupaavat korjata kaiken seuraavaan julkaisuun mennessä. Suorituskyky on yleisesti ottaen hyvä, mutta huomasin oudon asian: jos suoritat benchmarkin suoraan isäntiin liitetyllä taltiolla, lukunopeus on paljon suurempi kuin samalla tilavuudella, mutta podin sisältä. Kaikki muut tulokset ovat identtisiä, mutta teoriassa ei pitäisi olla eroa. Vaikka he työskentelevät asian parissa, turhauduin palautus- ja varmuuskopiointiongelmaan - minusta tuntui, että olin vihdoin löytänyt sopivan ratkaisun, ja olin jopa valmis maksamaan siitä, kun tarvitsin lisää tilaa tai enemmän palvelimia.
Minulla ei ole paljon sanottavaa tässä. Tämä on maksullinen tuote, yhtä siisti ja kallis. Suoritus on vain hämmästyttävä. Toistaiseksi tämä on paras indikaattori. Slack kertoi minulle, että hinnat alkavat 205 dollarista kuukaudessa per solmu, kuten Googlen GKE Marketplacessa on listattu. En tiedä tuleeko halvemmaksi, jos ostat suoraan. Joka tapauksessa minulla ei ole siihen varaa, joten olin erittäin, hyvin pettynyt, että kehittäjälisenssi (jopa 1 Tt ja 3 solmua) on käytännössä hyödytön Kubernetesin kanssa, ellet tyydy staattiseen provisiointiin. Toivoin, että volyymilisenssi muuttuisi automaattisesti kehittäjäksi kokeilujakson lopussa, mutta niin ei käynyt. Kehittäjälisenssiä voidaan käyttää vain suoraan Dockerin kanssa, ja Kubernetesin asennus on erittäin hankalaa ja rajoitettua. Tietysti pidän avoimesta lähdekoodista, mutta jos minulla olisi rahaa, valitsisin ehdottomasti Portworxin. Toistaiseksi sen suorituskykyä ei yksinkertaisesti voi verrata muihin vaihtoehtoihin.
Lisäsin tämän osion postauksen julkaisun jälkeen, kun eräs lukija ehdotti kokeilemaan Linstoria. Kokeilin sitä ja pidin siitä! Mutta sinun on silti kaivettava. Nyt voin sanoa, että suorituskyky ei ole huono (benchmark-tulokset lisätty alle). Itse asiassa sain saman suorituskyvyn kuin levylle suoraan, ilman ylimääräisiä kustannuksia. (Älä kysy, miksi Portworxin luvut ovat parempia kuin aseman vertailuarvo suoraan. Minulla ei ole aavistustakaan. Taikuutta kai.) Joten Linstor näyttää toistaiseksi erittäin tehokkaalta. Sen asentaminen ei ole niin vaikeaa, mutta ei yhtä helppoa kuin muut vaihtoehdot. Minun täytyi ensin asentaa Linstor (ydinmoduuli ja työkalut/palvelut) ja määrittää LVM suppeaa provisiointia ja tilannevedostukea varten Kubernetesin ulkopuolella, suoraan isännässä, ja sitten luoda Kubernetesin tallennustilan käyttöön tarvittavat resurssit. En pitänyt siitä, että se ei toiminut CentOS:ssä ja piti käyttää Ubuntua. Ei tietenkään kauheaa, mutta hieman ärsyttävää, koska dokumentaatiossa (joka muuten on erinomainen) mainitaan useita paketteja, joita ei löydy määritetyistä Epel-arkistoista. Linstorilla on tilannekuvia, mutta ei ulkopuolisia varmuuskopioita, joten tässäkin jouduin käyttämään Veleroa Resticin kanssa taltioiden varmuuskopiointiin. Haluaisin tilannekuvia tiedostotason varmuuskopioiden sijaan, mutta tämä voidaan sietää, jos ratkaisu on sekä tehokas että luotettava. Linstor on avoimen lähdekoodin, mutta sillä on maksettu tuki. Jos ymmärrän oikein, sitä voidaan käyttää ilman rajoituksia, vaikka sinulla ei olisi tukisopimusta, mutta tämä on selvennettävä. En tiedä miten Linstor on testattu Kubernetesille, mutta itse tallennuskerros on Kubernetesin ulkopuolella ja ilmeisesti ratkaisu ei ilmestynyt eilen, joten se on todennäköisesti jo testattu todellisissa olosuhteissa. Onko tässä ratkaisua, joka saa minut muuttamaan mieltäni ja palaamaan Kubernetesiin? En tiedä. Meidän on vielä kaivettava syvemmälle, tutkittava replikaatiota. Katsotaan. Mutta ensivaikutelma on hyvä. Käytän ehdottomasti mieluummin omia Kubernetes-klustereitani Herokun sijaan, jotta minulla olisi enemmän vapautta ja oppia uusia asioita. Koska Linstor ei ole yhtä helppo asentaa kuin muut, kirjoitan siitä pian postauksen.
Vertailuarvot
Valitettavasti säilytin vähän kirjaa vertailusta, koska en uskonut kirjoittavani siitä. Minulla on vain fio-perustason vertailutuloksia ja vain yhden solmun klustereita, joten minulla ei ole vielä numeroita replikoiduille kokoonpanoille. Mutta näistä tuloksista voit saada karkean käsityksen siitä, mitä odottaa kustakin vaihtoehdosta, koska vertasin niitä samoissa pilvipalvelimissa, 4 ydintä, 16 Gt RAM-muistia ja 100 Gt:n lisälevyä testatuille levyille. Suoritin vertailut kolme kertaa kullekin ratkaisulle ja laskin keskimääräisen tuloksen sekä nollasin kunkin tuotteen palvelinasetukset. Kaikki tämä on täysin epätieteellistä, jotta ymmärrät yleisesti. Muissa testeissä kopioin taltiolta 38 Gt valokuvia ja videoita sekä lukemisen ja kirjoittamisen testaamiseksi, mutta valitettavasti en tallentanut numeroita. Lyhyesti: Portworkx oli paljon nopeampi.
Volyymivertailussa käytin tätä luetteloa:
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
name: dbench
spec:
storageClassName: ...
accessModes:
- ReadWriteOnce
resources:
requests:
storage: 5Gi
---
apiVersion: batch/v1
kind: Job
metadata:
name: dbench
spec:
template:
spec:
containers:
- name: dbench
image: sotoaster/dbench:latest
imagePullPolicy: IfNotPresent
env:
- name: DBENCH_MOUNTPOINT
value: /data
- name: FIO_SIZE
value: 1G
volumeMounts:
- name: dbench-pv
mountPath: /data
restartPolicy: Never
volumes:
- name: dbench-pv
persistentVolumeClaim:
claimName: dbench
backoffLimit: 4Tein ensin talteen sopivalla tallennusluokalla ja suoritin sitten työn fion kanssa kulissien takana. Käytin 1 Gt arvioidakseni suorituskykyä ja odottamatta liian kauan. Tässä tulokset:
Olen korostanut kunkin mittarin parhaan arvon vihreällä ja huonoimman punaisella.
Johtopäätös
Kuten näette, useimmissa tapauksissa Portworx suoriutui muita paremmin. Mutta minulle se on kallista. En tiedä kuinka paljon Robin maksaa, mutta siellä on loistava ilmainen versio, joten jos tarvitset maksullisen tuotteen, voit kokeilla sitä (toivottavasti he korjaavat ongelman palautuksilla ja varmuuskopioilla pian). Kolmesta ilmaisversiosta minulla on ollut vähiten ongelmia OpenEBS:n kanssa, mutta sen suorituskyky on surkea. Olen pahoillani, etten tallentanut enempää tuloksia, mutta toivon, että numerot ja kommenttini auttavat sinua.
Lähde: will.com