Atjaunināt!. Komentāros kāds no lasītājiem ieteica pamēģināt (varbūt viņš pats pie tā strādā), tāpēc esmu pievienojis sadaļu par šo risinājumu. Es arī rakstīju , jo process ļoti atšķiras no pārējiem.
Ja godīgi, es padevos un padevos (vismaz pagaidām). es izmantošu . Kāpēc? Glabāšanas dēļ! Kurš to būtu domājis, ka es vairāk lāpīšos ar uzglabāšanu, nevis pašu Kubernetes. ES izmantoju jo tas ir lēts un veiktspēja ir laba, un no paša sākuma es izvietoju klasterus, izmantojot . Es neizmēģināju pārvaldītos Kubernetes pakalpojumus no Google/Amazon/Microsoft/DigitalOcean utt., u.c., jo gribēju visu apgūt pats. Es arī esmu taupīgs.
Tātad, jā, es pavadīju daudz laika, mēģinot izlemt, kuru krātuvi izvēlēties, izvērtējot iespējamo Kubernetes steku. Es dodu priekšroku atvērtā pirmkoda risinājumiem ne tikai cenas dēļ, bet arī ziņkārības dēļ esmu izskatījis dažas maksas iespējas, jo tām ir bezmaksas versijas ar ierobežojumiem. Esmu pierakstījis dažus skaitļus no nesenajiem testiem, kad salīdzināju dažādas iespējas, un tie varētu būt interesanti tiem, kas mācās par Kubernetes krātuvi. Lai gan es personīgi pagaidām esmu atvadījies no Kubernetes. Es arī gribu pieminēt , kas var tieši nodrošināt Hetzner Cloud apjomus, taču es to vēl neesmu izmēģinājis. Es izpētīju mākoņa programmatūras definētu krātuvi, jo man bija nepieciešama replikācija un iespēja ātri uzstādīt pastāvīgus sējumus jebkurā mezglā, it īpaši mezgla kļūmju un citu līdzīgu situāciju gadījumā. Daži risinājumi piedāvā momentuzņēmumus un dublējumus ārpus vietnes, kas ir ērti.
Es pārbaudīju 6–7 uzglabāšanas risinājumus:
Kā jau teicu Pārbaudījis lielāko daļu no saraksta opcijām, es sākotnēji izvēlējos OpenEBS. OpenEBS ir ļoti viegli instalējams un lietojams, taču, godīgi sakot, pēc testēšanas ar reāliem datiem zem slodzes, biju vīlies par tā veiktspēju. Tas ir atvērts avots, un izstrādātāji ir paši vienmēr ļoti palīdzēja, kad man bija vajadzīga palīdzība. Diemžēl tai ir ļoti vāja veiktspēja salīdzinājumā ar citām opcijām, tāpēc testi bija jāveic atkārtoti. OpenEBS pašlaik ir 3 krātuves dzinēji, bet es publicēju cStor etalona rezultātus. Man vēl nav Jiva un LocalPV numuru.
Īsumā, Jiva ir nedaudz ātrāks, un LocalPV parasti ir ātrs, ne sliktāks par diska etalonu tieši. Vietējā PV problēma ir tāda, ka sējumam var piekļūt tikai tajā mezglā, kurā tas tika sagatavots, un vispār nav replikācijas. Man bija dažas problēmas ar dublējuma atjaunošanu, izmantojot jaunā klasterī, jo mezglu nosaukumi bija atšķirīgi. Ja mēs runājam par dublēšanu, cStor ir , ar kuru jūs varat izveidot momentuzņēmumu dublējumus ārpus vietnes noteiktā brīdī, kas ir ērtāk nekā faila līmeņa dublējumkopijas ar Velero-Restic. ES rakstīju , lai atvieglotu dublējumu un atjaunošanas pārvaldību, izmantojot šo spraudni. Kopumā man ļoti patīk OpenEBS, bet tā veiktspēja...
Rook ir arī atvērtā koda un atšķiras no pārējām opcijām sarakstā ar to, ka tas ir krātuves orķestrētājs, kas veic sarežģītus krātuves pārvaldības uzdevumus ar dažādām aizmugursistēmām, piemēram, , un citi, kas ievērojami vienkāršo darbu. Man bija problēmas ar EfgeFS, kad es to izmēģināju pirms dažiem mēnešiem, tāpēc es testēju galvenokārt ar Ceph. Ceph piedāvā ne tikai bloku krātuvi, bet arī objektu krātuvi, kas ir saderīga ar S3/Swift un izplatīto failu sistēmu. Tas, kas man patīk Ceph, ir iespēja izplatīt apjoma datus vairākos diskos, lai sējums varētu izmantot vairāk diska vietas, nekā var ievietot vienā diskā. Tas ir ērti. Vēl viena lieliska iezīme ir tā, ka, pievienojot diskus klasterim, tas automātiski pārdala datus visos diskos.
Ceph ir momentuzņēmumi, bet, cik man zināms, tos nevar izmantot tieši Rook/Kubernetes. Tiesa, es tajā neiedziļinājos. Bet ārpus vietnes nav dublējumu, tāpēc jums būs kaut kas jāizmanto ar Velero/Restic, taču ir tikai faila līmeņa dublējumkopijas, nevis momentuzņēmumi brīdī. Man ļoti patika Rook tas, cik viegli ir strādāt ar Ceph — tas slēpj gandrīz visas sarežģītās lietas un piedāvā rīkus, lai tieši sarunātos ar Ceph problēmu novēršanai. Diemžēl Ceph apjomu stresa testa laikā man joprojām radās problēmas ar , kas izraisa Ceph nestabilitāti. Pagaidām nav skaidrs, vai tā ir kļūda pašā Ceph vai problēma tajā, kā Rook pārvalda Ceph. Es pārdomāju atmiņas iestatījumus, un tas kļuva labāks, taču problēma netika pilnībā atrisināta. Kā redzams zemāk esošajos etalonos, Ceph ir pienācīgs sniegums. Tam ir arī labs informācijas panelis.
Man ļoti patīk Longhorn. Manuprāt, tas ir daudzsološs risinājums. Tiesa, paši izstrādātāji (Rancher Labs) atzīst, ka tas vēl nav piemērots darba videi, un tas arī liecina. Tas ir atvērtā koda, un tam ir pienācīga veiktspēja (lai gan viņi to vēl nav optimizējuši), taču sējumiem ir nepieciešams ļoti ilgs laiks, lai izveidotu savienojumu ar podziņu, un sliktākajos gadījumos tas aizņem 15–16 minūtes, īpaši pēc lielas dublējuma atjaunošanas vai darba slodzes uzlabošana. Tam ir šo momentuzņēmumu momentuzņēmumi un dublējumkopijas ārpus vietnes, taču tie attiecas tikai uz sējumiem, tāpēc jums joprojām būs nepieciešams kaut kas līdzīgs Velero, lai dublētu citus resursus. Dublēšana un atjaunošana ir ļoti uzticama, taču nepieklājīgi lēna. Nopietni, vienkārši neticami lēni. Strādājot ar vidēju datu apjomu programmā Longhorn, centrālā procesora lietojums un sistēmas slodze bieži palielinās. Lai pārvaldītu Longhorn, ir ērts informācijas panelis. Es jau teicu, ka man patīk Longhorn, bet ar to ir jāpiestrādā.
StorageOS ir pirmais maksas produkts sarakstā. Tam ir izstrādātāja versija ar ierobežotu pārvaldīto krātuves lielumu 500 GB, taču es nedomāju, ka mezglu skaits ir ierobežots. Pārdošanas nodaļa man teica, ka izmaksas sākas no 125 USD mēnesī par 1 TB, ja pareizi atceros. Ir pamata informācijas panelis un ērts CLI, taču ar veiktspēju notiek kaut kas dīvains: dažos etalonos tas ir diezgan pieklājīgs, bet skaļuma noslodzes testā ātrums man nepatika. Kopumā es nezinu, ko teikt. Tāpēc es īsti daudz nesapratu. Šeit nav dublējumu ārpus vietnes, un sējumu dublēšanai būs jāizmanto arī Velero ar Restic. Dīvaini, jo prece ir apmaksāta. Un izstrādātāji nevēlējās sazināties Slack.
Es uzzināju par Robinu vietnē Reddit no viņu tehniskā direktora. Es nekad agrāk par viņu nebiju dzirdējis. Varbūt tāpēc, ka meklēju bezmaksas risinājumus, bet Robinam maksā. Viņiem ir diezgan dāsna bezmaksas versija ar 10 TB krātuvi un trim mezgliem. Kopumā produkts ir diezgan pienācīgs un tam ir jaukas īpašības. Ir lieliska CLI, taču pats foršākais ir tas, ka varat izveidot momentuzņēmumu un dublēt visu lietojumprogrammu (resursu atlasītājā to sauc par Helm izlaidumiem vai “flex apps”), ieskaitot apjomus un citus resursus, lai jūs varētu iztikt bez Velero. Un viss būtu brīnišķīgi, ja ne tikai viena sīka detaļa: ja atjaunotu (vai “importētu”, kā to sauc Robinā) lietojumprogrammu jaunā klasterī - piemēram, atkopšanas gadījumā pēc katastrofas - atjaunošana, protams, darbojas, bet turpināt dublēt lietojumprogrammu tas ir aizliegts. Šajā laidienā tas vienkārši nav iespējams, kā to apstiprinājuši izstrādātāji. Tas ir, maigi izsakoties, dīvaini, īpaši ņemot vērā citas priekšrocības (piemēram, neticami ātras dublēšanas un atjaunošanas). Izstrādātāji sola visu salabot līdz nākamajam laidienam. Veiktspēja kopumā ir laba, taču es pamanīju dīvainību: ja es palaižu etalonu tieši sējumā, kas pievienots resursdatoram, lasīšanas ātrums ir daudz ātrāks, nekā palaist to pašu skaļumu no poda. Visi pārējie rezultāti ir identiski, taču teorētiski atšķirībai nevajadzētu būt. Lai gan viņi pie tā strādā, es biju sarūgtināts par problēmu ar atjaunošanu un dublēšanu - es domāju, ka beidzot esmu atradis piemērotu risinājumu, un es pat biju gatavs par to maksāt, kad man vajadzēja vairāk vietas vai vairāk serveru.
Man te nav daudz ko teikt. Šis ir maksas produkts, vienlīdz foršs un dārgs. Izrāde ir vienkārši pārsteidzoša. Tas ir līdz šim labākais rādītājs. Slack man teica, ka cenas sākas no USD 205 mēnesī par mezglu, kā norādīts Google GKE Marketplace. Nezinu, vai būs lētāk, pērkot pa tiešo. Es tik un tā nevaru to atļauties, tāpēc biju ļoti, ļoti vīlies, ka izstrādātāja licence (līdz 1 TB un 3 mezgliem) ir praktiski bezjēdzīga ar Kubernetes, ja vien jūs neesat apmierināts ar statisko nodrošinājumu. Es cerēju, ka izmēģinājuma perioda beigās lielapjoma licence automātiski tiks pazemināta uz izstrādātāju, taču tas nenotika. Izstrādātāja licenci var izmantot tikai tieši ar Docker, un Kubernetes konfigurācija ir ļoti apgrūtinoša un ierobežota. Protams, es dodu priekšroku atvērtajam pirmkodam, bet, ja man būtu nauda, es noteikti izvēlētos Portworx. Līdz šim tā veiktspēja vienkārši nav salīdzināma ar citām iespējām.
Šo sadaļu pievienoju pēc ieraksta publicēšanas, kad kāds lasītājs ieteica izmēģināt Linstor. Es to izmēģināju, un man tas patika! Bet man ir jāpapēta vēl. Pagaidām varu teikt, ka veiktspēja ir diezgan laba (esmu pievienojis etalona rezultātus zemāk). Patiesībā es ieguvu tādu pašu veiktspēju kā ar tiešā diska etalonu, bez jebkādām papildu izmaksām. (Nejautājiet, kāpēc Portworx skaitļi ir labāki par tiešā diska etalonu. Man nav ne jausmas. Maģija, es domāju.) Tātad, Linstor līdz šim šķiet ļoti efektīvs. Tā iestatīšana nav īpaši sarežģīta, taču tā nav tik vienkārša kā citas iespējas. Vispirms man bija jāinstalē Linstor (kodola modulis un rīki/pakalpojumi) un jāiestata LVM plānai nodrošināšanai un momentuzņēmumu atbalstam ārpus Kubernetes, tieši resursdatorā, un pēc tam jāizveido resursi, kas nepieciešami, lai izmantotu krātuvi no Kubernetes. Man nepatika, ka tas nedarbojās... CentOS un nācās izmantot UbuntuProtams, tā nav liela problēma, bet nedaudz kaitina, jo dokumentācijā (kas, starp citu, ir lieliska) ir minētas vairākas pakotnes, kas nav pieejamas norādītajās Epel krātuvēs. Linstor ir momentuzņēmumi, bet nav ārpusvietas dublējumu, tāpēc sējumu dublējumkopijām man atkal nācās izmantot Velero ar Restic. Es dotu priekšroku momentuzņēmumiem, nevis failu līmeņa dublējumkopijām, bet tas ir pieļaujams, ja risinājums ir jaudīgs un uzticams. Linstor ir atvērtā koda risinājums, bet ir maksas atbalsts. Ja pareizi saprotu, to var izmantot bez ierobežojumiem, pat ja nav atbalsta līguma, bet man tas būtu jāpārbauda. Es nezinu, cik labi Linstor ir pārbaudīts Kubernetes, bet pats krātuves slānis atrodas ārpus Kubernetes, un izskatās, ka tas jau kādu laiku pastāv, tāpēc tas droši vien jau ir pārbaudīts reālos apstākļos. Vai šeit ir kāds risinājums, kas liktu man pārdomāt un atgriezties pie Kubernetes? Es nezinu. Man vēl nedaudz jāpapēta un jāapgūst replikācija. Redzēsim. Bet pirmais iespaids ir labs. Es noteikti dotu priekšroku saviem Kubernetes klasteriem Heroku vietā, lai iegūtu lielāku brīvību un apgūtu jaunas lietas. Tā kā Linstor nav tik vienkārši instalēt kā citus, drīz uzrakstīšu par to ierakstu.
Etaloni
Diemžēl es nesaglabāju daudz piezīmju par salīdzinājumu, jo nedomāju, ka par to rakstīšu. Man ir rezultāti tikai no pamata fio etaloniem un tikai viena mezgla klasteriem, tāpēc man vēl nav skaitļu replicētām konfigurācijām. Bet no šiem rezultātiem var iegūt aptuvenu priekšstatu par to, ko sagaidīt no katras opcijas, jo es tos salīdzināju tajos pašos mākoņserveros, 4 kodoli, 16 GB RAM, ar papildu 100 GB disku pārbaudītajiem sējumiem. Es trīs reizes izpildīju etalonus katram risinājumam un aprēķināju vidējo rezultātu, kā arī atiestatīju servera iestatījumus katram produktam. Tas viss ir pilnīgi nezinātniski, lai sniegtu jums vispārēju priekšstatu. Citos testos es nokopēju 38 GB fotoattēlu un videoklipu no sējuma, lai pārbaudītu lasīšanu un rakstīšanu, bet diemžēl es nesaglabāju skaitļus. Īsāk sakot: Portworkx bija daudz ātrāks.
Apjoma etalonam izmantoju šo manifestu:
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: 4Vispirms es izveidoju sējumu ar atbilstošu uzglabāšanas klasi un pēc tam veicu darbu ar fio aizkulisēm. Es paņēmu 1 GB, lai novērtētu veiktspēju un negaidītu pārāk ilgi. Lūk, rezultāti:
Es esmu iezīmējis katra rādītāja labāko vērtību zaļā krāsā un sliktāko sarkanā krāsā.
Secinājums
Kā redzat, vairumā gadījumu Portworx darbojās labāk nekā citi. Bet man tas ir dārgi. Es nezinu, cik maksā Robin, bet viņiem ir lieliska bezmaksas versija, tāpēc, ja vēlaties maksas produktu, varat to izmēģināt (cerams, ka viņi drīz atrisinās problēmu ar atjaunošanu un dublēšanu). No trim bezmaksas man vismazāk bija problēmas ar OpenEBS, taču tā veiktspēja ir nenormāla. Žēl, ka nesaglabāju vairāk rezultātu, bet ceru, ka skaitļi un mani komentāri jums palīdzēs.
Avots: www.habr.com
