La mondo vidis la unuan prototipon de objektostokado en 1996. Post 10 jaroj, Amazon Web Services lanĉos Amazon S3, kaj la mondo komencos sisteme freneziĝi kun plata adresspaco. Danke al ĝia metadatumado kaj ĝia kapablo grimpi sen malleviĝo sub ŝarĝo, objektostokado rapide fariĝis la normo por plej multaj nubaj stokadoservoj kaj pretere. Alia grava trajto estas ĝia bona adaptebleco por stoki arkivojn kaj similajn malofte uzatajn dosierojn. Ĉiuj implikitaj en datumstokado ĝojis kaj portis la novan teknologion sur siaj manoj.
Sed la onidiroj de homoj estis plenaj de onidiroj, ke objektostokado temas nur pri grandaj nuboj, kaj se vi ne bezonas solvojn de la damnitaj kapitalistoj, tiam estos tre malfacile fari vian propran. Oni jam skribis multon pri deplojado de via propra nubo, sed ne estas sufiĉe da informoj pri kreado de la tiel nomataj S3-kongruaj solvoj.
Sekve, hodiaŭ ni eltrovos kiajn eblojn ekzistas "Esti kiel plenkreskuloj, kaj ne CEPH kaj pli granda dosiero", ni deplojos unu el ili, kaj ni kontrolos, ke ĉio funkcias uzante Veeam Backup & Replication. Ĝi asertas subtenon por labori kun S3-kongruaj stokaĵoj, kaj ni kontrolos ĉi tiun deklaron.
Kio pri aliaj?
Mi proponas komenci per malgranda superrigardo de la merkato kaj ebloj por objekto stokado. La ĝenerale agnoskita gvidanto kaj normo estas Amazon S3. La du plej proksimaj persekutantoj estas Microsoft Azure Blob Storage kaj IBM Cloud Object Storage.
Ĉu tio estas ĉio? Ĉu ne ekzistas aliaj konkurantoj? Kompreneble, ekzistas konkurantoj, sed iu iras sian propran vojon, kiel Google Cloud aŭ Oracle Cloud Object Storage, kun nekompleta subteno por la S3 API. Iu uzas malnovajn versiojn de la API, kiel Baidu Cloud. Kaj iuj, kiel Hitachi Cloud, postulas la aplikon de speciala logiko, kiu certe kaŭzos siajn proprajn malfacilaĵojn. Ĉiukaze, ĉiuj estas komparitaj kun Amazon, kiu povas esti konsiderata la industria normo.
Sed en surlokaj solvoj, la elekto estas multe pli granda, do ni skizu la kriteriojn, kiuj estas gravaj por ni. Principe, nur du sufiĉas: subteno por la S3 API kaj la uzo de v4 subskribo. Mane sur koro, ni, kiel estonta kliento, nur interesiĝas pri interfacoj por interago, kaj ni ne tiom interesiĝas pri la interna kuirejo de la stokado mem.
Nu, multaj solvoj taŭgas ĉi tiujn simplajn kondiĉojn. Ekzemple, klasikaj kompaniaj pezeguloj:
- DellEMC ECS
- NetApp S3 Stokado-Krado
- Nutanix Siteloj
- Pura Stokado FlashBlade kaj StorReduce
- Huawei FusionStorage
Estas niĉo de sole programaraj solvoj, kiuj funkcias ekster la skatolo:
- Red Hat Ceph
- SUSE Enterprise Stokado
- Cloudian
Kaj eĉ tiuj, kiuj ŝatas zorge prilabori dosieron post kunigo, ne ofendiĝis:
- CEPH en ĝia plej pura formo
- Minio (Linuksa versio, ĉar estas multaj demandoj pri la Vindoza versio)
La listo estas malproksima de kompleta, ĝi povas esti diskutita en la komentoj. Nur ne forgesu kontroli la sisteman rendimenton krom API-kongruo antaŭ efektivigo. La lasta afero, kiun vi volas, estas la perdo de terabajtoj da datumoj pro blokitaj petoj. Do bonvolu ŝarĝi testojn. Ĝenerale, ĉiuj plenkreskaj programoj, kiuj funkcias kun grandaj kvantoj da datumoj, havas almenaŭ kongruajn raportojn. En kazo de vidu estas pri reciproka testado, kiu permesas al ni kuraĝe deklari la plenan kongruon de niaj produktoj kun specifa ekipaĵo. Ĉi tio jam estas dudirekta laboro, ne ĉiam rapida, sed ni konstante plivastiĝas provitaj solvoj.
Kunmeti nian budon
Mi volas iomete paroli pri elekto de testtemo.
Unue, mi volis trovi eblon, kiu funkcius tuj el la skatolo. Nu, aŭ almenaŭ kun la maksimuma probableco, ke ĝi funkcios sen neceso fari nenecesajn gestojn. Danci per tamburino kaj elekti la konzolon nokte estas tre ekscita, sed foje oni volas, ke ĝi funkciu tuj. Kaj la ĝenerala fidindeco de tiaj solvoj estas kutime pli alta. Kaj jes, la spirito de aventurismo malaperis en ni, ni ĉesis grimpi tra la fenestroj al niaj amataj virinoj ktp (c).
Due, por esti honesta, la bezono labori kun objekta stokado ŝprucas en sufiĉe grandaj kompanioj, do ĉi tiu estas la kazo, kiam rigardi al entreprennivelaj solvoj ne nur ne hontas, sed eĉ kuraĝigas. Ĉiukaze, mi ankoraŭ ne konas ekzemplojn de iu maldungita pro aĉetado de tiaj solvoj.
Surbaze de la antaŭa, mia elekto falis Dell EMC ECS Komunuma Eldono. Ĉi tio estas tre interesa projekto, kaj mi opinias necesa rakonti pri ĝi al vi.
La unua afero, kiu venas al la menso, kiam vi vidas la aldonon komunumo Eldono - ke ĉi tio estas nur spurpapero de plentaŭga ECS kun iuj limigoj, kiuj estas forigitaj per aĉeto de permesilo. Do ne!
Memoru:
!!!Komunuma Eldono estas aparta projekto kreita por testado kaj sen teknika subteno de Dell!!
Kaj ĝi ne povas esti transformita en plentaŭgan ECS, eĉ se vi vere volas.
Ni eltrovu ĝin
Multaj homoj opinias, ke Dell EMC ECS estas preskaŭ la plej bona solvo se vi bezonas objekton. Ĉiuj projektoj sub la marko ECS, inkluzive de komercaj kaj kompaniaj, estas . Ia gesto de bonvolo de Dell. Kaj krom la programaro, kiu funkcias per ilia marka aparataro, ekzistas malfermfonta versio, kiu povas esti deplojita eĉ en la nubo, eĉ sur virtuala maŝino, eĉ en ujo, eĉ sur iu ajn el via aparataro. Rigardante antaŭen, ekzistas eĉ OVA versio, kiun ni uzos.
La DELL ECS Community Edition mem estas mini-versio de la plentaŭga programaro, kiu funkcias per Dell EMC ECS-markitaj serviloj.
Mi identigis kvar ĉefajn diferencojn:
- Neniu subteno por ĉifrado. Estas domaĝe, sed ne kritika.
- Ne estas ŝtofa tavolo. Ĉi tiu afero respondecas pri konstruado de aretoj, administrado de rimedoj, ĝisdatigo, monitorado kaj stokado de Docker-bildoj. Ĉi tie ĝi jam estas tre seniluziiga, sed Dell ankaŭ estas komprenebla.
- La plej malbona konsekvenco de la antaŭa punkto: la grandeco de la nodo ne povas esti vastigita post kiam la instalado estas finita.
- Neniu teknika subteno. Ĉi tio estas produkto por testado, kiu ne estas malpermesita uzi en malgrandaj instalaĵoj, sed mi persone ne kuraĝus alŝuti tie petabajtojn da gravaj datumoj. Sed teknike, neniu povas malhelpi vin fari ĉi tion.
Kio estas en la granda versio?
Galopante tra Eŭropo, ni trarigardu la ferajn solvojn por havi pli kompletan bildon de la ekosistemo.
Mi ne iel konfirmos aŭ refutos la deklaron, ke DELL ECS estas la plej bona surloka objektostokado, sed se vi havas ion por diri pri ĉi tiu temo, mi volonte legos ĝin en la komentoj. Ĉiukaze, laŭ la versio Dell EMC memfide eniras la plej bonajn kvin OBS-merkatajn gvidantojn. Kvankam nubo-bazitaj solvoj ne estas konsiderataj, tio estas aparta konversacio.
De teknika vidpunkto, ECS estas objekta stokado, kiu disponigas aliron al datumoj uzante protokolojn de nuba stokado. Elportas AWS S3 kaj OpenStack Swift. Por dosier-ebligitaj siteloj, ECS subtenas NFSv3 por dosiero-post-dosiera eksporto.
La procezo de skribado de informoj estas sufiĉe nekutima, precipe post la klasikaj blokaj stokadsistemoj.
- Kiam novaj datumoj alvenas, nova objekto estas kreita, kiu havas nomon, la datumojn mem kaj metadatenojn.
- Objektoj estas dividitaj en 128 MB pecojn, kaj ĉiu peco estas skribita al tri nodoj samtempe.
- La indeksa dosiero estas ĝisdatigita, kie estas registritaj identigiloj kaj konservaj lokoj.
- La protokolo-dosiero (registro-protokolo) estas ĝisdatigita kaj ankaŭ skribita al tri nodoj.
- Mesaĝo estas sendita al la kliento pri sukcesa rekordo.
Ĉiuj tri kopioj de la datumoj estas skribitaj paralele. La skribo estas konsiderata sukcesa nur se ĉiuj tri ekzempleroj estis skribitaj sukcese.
Legado estas pli facila:
- La kliento petas datumojn.
- La indekso serĉas lokon por konservi datumojn.
- Datenoj estas legitaj de unu nodo kaj senditaj al la kliento.
Estas sufiĉe multaj serviloj mem, do ni rigardu la plej malgrandan Dell EMC ECS EX300. Ĝi komenciĝas je 60Tb, kun la kapablo kreski ĝis 1,5Pb. Kaj lia pli aĝa frato Dell EMC ECS EX3000 jam ebligas vin stoki ĝis 8,6Pb per rako.
Deploji
Teknike, Dell ECS CE povas esti deplojita tiel granda kiel dezirate. Ĉiukaze, mi ne trovis eksplicitajn limigojn. Tamen, ĉio skalo estas oportune farita per klonado de la plej unua nodo por kiu ni bezonas:
- 8 vCPUoj
- 64GB-RAM
- 16GB por operaciumo
- 1TB rekte por stokado
- Plej nova eldono de CentOS minimuma
Ĉi tio estas opcio por la kazo, kiam vi volas instali ĉion mem de la komenco. Por ni ĉi tiu opcio ne gravas, ĉar. Mi uzos OVA-bildon por deploji.
Sed ĉiukaze la postuloj estas tre malbonaj eĉ por unu nodo, kaj se vi strikte sekvas la leteron de la leĝo, tiam vi bezonas kvar tiajn nodojn.
Tamen, ECS CE-programistoj vivas en la reala mondo, kaj la instalado sukcesas eĉ kun ununura nodo, kaj la minimumaj postuloj estas:
- 4 vCPUoj
- 16 GB RAM
- 16 GB por operaciumo
- 104 GB memstokado
Estas ĉi tiuj rimedoj, kiuj estas necesaj por deploji la OVA-bildon. Jam multe pli humana kaj realisma.
La instala nodo mem povas esti prenita de la oficiala . Ekzistas ankaŭ detala dokumentaro pri deplojado de ĉio-en-unu, sed vi ankaŭ povas legi sur la oficiala . Sekve, ni ne detale pritraktos la disfaldiĝon de OVA, ne ekzistas lertaĵoj. La ĉefa afero - ne forgesu antaŭ ol komenci ĝin, aŭ pligrandigu la diskon al la bezonata volumo, aŭ aligu la necesajn.
Ni lanĉas la maŝinon, malfermas la konzolon kaj uzas la plej bonajn defaŭltajn kreditojn:
- ensalutu: admin
- Pasvorto: ŝanĝu min
Poste ni rulas sudo nmtui kaj agordas la retan interfacon - IP / masko, DNS kaj pordego. Konsiderante, ke ne ekzistas retaj iloj en CentOS minimumaj, ni kontrolas la agordojn per ip-adreso.
Kaj ĉar nur la kuraĝuloj konkeras la marojn, ni faras yum ĝisdatigon, post kio ni rekomencas. Ĝi fakte estas sufiĉe sekura. ĉiu deplojo estas farita per ludlibroj, kaj ĉiuj gravaj docker-pakaĵoj estas ŝlositaj al la nuna versio.
Nun estas tempo redakti la instalan skripton. Neniuj belaj fenestroj aŭ pseŭdointerfaco por vi - ĉio estas per via plej ŝatata tekstredaktilo. Nur teknike, estas du manieroj: vi povas ruli ĉiun komandon permane aŭ ruli la videploy-konfiguranton tuj. Ĝi simple malfermos la agordon en vim, kaj post eliro ĝi komencos kontroli ĝin. Sed ne estas interese intence simpligi vian vivon, do ni plenumu du pliajn komandojn. Kvankam ĝi ne havas sencon, mi avertis vin =)
Do, ni faras vim ECS-CommunityEdition/deploy.xml kaj faras la optimumajn minimumajn ŝanĝojn por ke ECS ŝaltu kaj funkciu. La listo de parametroj povas esti mallongigita, sed mi faris tion jene:
- licensed_accepted: true Vi ne devas ŝanĝi ĝin, tiam dum deplojiĝo oni eksplicite petos vin akcepti ĝin kaj montri belan frazon. Ĝi povus eĉ esti paska ovo.
- Malkomentu la liniojn aŭtonomoj: kaj kutimo: Enigu almenaŭ unu deziratan nomon por la nodo - gastiga nomo estos anstataŭigita per ĝi dum la instalado.
- install_node: 192.168.1.1 Specifu la realan IP de la nodo. En nia kazo, ni precizigas la samon kiel en nmtui
- dns_domain: enigu vian domajnon.
- dns_servers: enigu vian dns.
- ntp_servers: Iu ajn povas esti specifita. Mi prenis la unuan el la naĝejo 0.pool.ntp.org (ĝi fariĝis 91.216.168.42)
- aŭtonomado: kutimo Se lasita nekomentita, la luno estos nomita Luna.
- ecs_block_devices:
/ dev / sdb
Pro iu nekonata kialo, povas esti neekzistanta bloka stokado-aparato /dev/vda - stokejoj:
membroj:
192.168.1.1 Ĉi tie denove ni indikas la realan IP de la nodo - ecs_block_devices:
/dev/sdb Ni ripetas la operacion tranĉi neekzistantajn aparatojn.
Ĝenerale, la tuta dosiero estas priskribita tre detale en sed kiu legos ĝin en tia turbula tempo. Tie estas ankaŭ skribite, ke la minimumo sufiĉa estas specifi la IP kaj maskon, sed en mia laboratorio tia aro ne komenciĝis bone, kaj mi devis pligrandigi ĝin al la supre indikita.
Post eliro de la redaktilo, vi devas ruli update_deploy /home/admin/ECS-CommunityEdition/deploy.yml, kaj se ĉio estas farita ĝuste, ĉi tio estos raportita eksplicite.
Tiam vi ankoraŭ devas komenci videploy, atendi ĝisdatigi la medion, kaj vi povas komenci la instaladon mem per la komando ova-step1, kaj post ĝia sukcesa kompletigo, la komando ova-step2. Grave: ne ĉesigu skriptojn mane! Iuj paŝoj povas daŭri longan tempon, daŭri pli ol la unua provo, kaj aspekti kvazaŭ ĉio estas rompita. Ĉiukaze, vi devas atendi la kompletigon de la skripto en natura maniero. Fine, vi devus vidi ion tian.
Nun, finfine, ni povas malfermi la WebUI-kontrolpanelon uzante la IP kiun ni konas. Se ĝi ne estis ŝanĝita en la agorda etapo, tiam la defaŭlta konto estos root/ChangeMe. Vi povas eĉ tuj uzi nian S3-kongruan stokadon. Ĝi estas disponebla en havenoj 9020 por HTTP, kaj 9021 por HTTPS. Denove, se nenio estis ŝanĝita, tiam access_key: object_admin1 kaj secret_key: ChangeMeChangeMeChangeMeChangeMeChangeMe.
Sed ni ne antaŭeniru kaj komencu en ordo.
Ĉe la unua ensaluto, vi perforte petos ŝanĝi la pasvorton al taŭga, kiu estas absolute ĝusta. La ĉefa panelo estas ege klara, do ni faru ion pli interesan ol klarigi la evidentajn metrikojn. Ekzemple, ni kreu uzanton, kiun ni uzos por aliri la deponejon. En la mondo de servaj provizantoj, ĉi tiuj estas nomitaj luantoj. Ĉi tio estas farita en Administri > Uzantoj > Nova Objekta Uzanto
Kiam oni kreas uzanton, ni petas specifi nomspacon. Teknike nenio malhelpas al ni komenci ilin tiom da kiom da uzantoj estos. Kaj inverse. Ĉi tio permesas rimedojn esti administritaj sendepende por ĉiu luanto.
Sekve, ni elektas la funkciojn, kiujn ni bezonas kaj generas uzantŝlosilojn. S3/Atmos sufiĉos por mi. Kaj ne forgesu konservi la ŝlosilon 😉
La uzanto estas kreita, nun estas tempo por li elekti la sitelon. Iru al Administri > Sitelo kaj plenigu la postulatajn kampojn. Ĉio estas simpla ĉi tie.
Nun ni havas ĉion preta por sufiĉe batala uzo de nia S3-stokado.
Starigante Veeam
Do, kiel ni memoras, unu el la ĉefaj aplikoj de objektostokado estas la longdaŭra konservado de informoj, kiujn oni malofte aliras. Ideala ekzemplo estas la bezono stoki sekurkopiojn ĉe fora retejo. En Veeam Backup & Replication, ĉi tiu funkcio nomiĝas Capacity Tier.
Ni komencu la aranĝon aldonante nian Dell ECS CE al la interfaco de Veeam. Sur la langeto Rezerva Infrastrukturo, lanĉu la sorĉiston por aldoni novan deponejon kaj elektu la objekton de Objekto Stokado.
Ni elektas por kio ĉio estis komencita - S3 Kongrua.
En la fenestro, kiu aperas, skribu la deziratan nomon kaj iru al la paŝo de Konto. Ĉi tie vi devas specifi la Servopunkton en la formularo , la regiono povas esti lasita tia, kaj la kreita uzanto povas esti aldonita. Pordega servilo estas postulata se via stokado troviĝas en fora retejo, sed ĉi tio jam estas temo pri infrastruktura optimumigo kaj aparta artikolo, do vi povas sekure preterlasi ĝin ĉi tie.
Se ĉio estas precizigita kaj agordita ĝuste, aperos averto pri la atestilo kaj poste fenestro kun sitelo, kie vi povas krei dosierujon por niaj dosieroj.
Ni pasas la sorĉiston ĝis la fino kaj ĝuas la rezulton.
La sekva paŝo estas aŭ krei novan Malgrandan Rezerva Deponejo, aŭ aldoni nian S3 al la ekzistanta - ĝi estos uzata kiel Kapacita Nivelo por arkiva stokado. La funkcio uzi S3-kongruajn deponejojn rekte, kiel regula deponejo, ne estas en la nuna eldono. Estas tro da sufiĉe neevidentaj problemoj por ke ĉi tio estu solvita, sed ĉio povas esti.
Ni eniras la deponejajn agordojn kaj ŝaltas la Kapacitan Nivelon. Ĉio estas travidebla tie, sed estas interesa nuanco: se vi volas, ke ĉiuj datumoj estu senditaj al objektostokado kiel eble plej baldaŭ, simple agordu ĝin al 0 tagoj.
Trapasinte la sorĉiston, se vi ne volas atendi, vi povas premi ctrl+RMB sur la deponejo, perforte ruli la Tiering-laboron kaj rigardi la grafikaĵojn rampi.
Tio estas ĉio por nun. Mi pensas, ke mi traktis la taskon montri, ke bloka stokado ne estas tiel timiga kiel oni kutime pensas. Jes, solvoj kaj ebloj por ekzekuto de vagono kaj malgranda troleo, sed estas neeble kovri ĉion en unu artikolo. Do ni dividu nian sperton en la komentoj.
fonto: www.habr.com