Pirmo objektu uzglabāšanas prototipu pasaule ieraudzīja 1996. gadā. Pēc 10 gadiem Amazon Web Services laidīs klajā Amazon S3, un pasaule sāks sistemātiski trakot ar plakanu adrešu telpu. Pateicoties darbam ar metadatiem un to spējai mērogot, nesamazinot slodzes laikā, objektu glabāšana ātri kļuva par standartu lielākajai daļai mākoņdatošanas datu krātuves pakalpojumu, un ne tikai. Vēl viena svarīga iezīme ir tā, ka tā ir labi piemērota arhīvu un līdzīgu reti lietojamu failu glabāšanai. Visi, kas bija iesaistīti datu glabāšanā, priecājās un nēsāja jauno tehnoloģiju rokās.
Bet cilvēku baumas bija pilnas ar baumām, ka objektu glabāšana ir tikai par lieliem mākoņiem, un, ja jums nav vajadzīgi risinājumi no nolādētajiem kapitālistiem, tad to būs ļoti grūti izveidot. Jau daudz ir rakstīts par sava mākoņa izvietošanu, taču nav pieejama pietiekami daudz informācijas par tā saukto ar S3 saderīgu risinājumu izveidi.
Tāpēc šodien mēs izdomāsim, kādas ir iespējas “Lai tas būtu kā pieaugušajiem, nevis CEPH un lielāks fails”, mēs izvietosim vienu no tām un pārbaudīsim, vai viss darbojas, izmantojot Veeam Backup & Replication. Tas apgalvo, ka atbalsta darbu ar S3 saderīgām krātuvēm, un mēs pārbaudīsim šo apgalvojumu.
Kā ar citiem?
Iesaku sākt ar nelielu tirgus un objektu uzglabāšanas iespēju apskatu. Vispāratzītais līderis un standarts ir Amazon S3. Divi tuvākie meklētāji ir Microsoft Azure Blob Storage un IBM Cloud Object Storage.
Vai tas ir viss? Vai tiešām nav citu konkurentu? Protams, ir konkurenti, taču daži iet savu ceļu, piemēram, Google Cloud vai Oracle Cloud Object Storage, ar nepilnīgu S3 API atbalstu. Daži izmanto vecākas API versijas, piemēram, Baidu Cloud. Un dažiem, piemēram, Hitachi Cloud, ir nepieciešama īpaša loģika, kas noteikti radīs savas grūtības. Jebkurā gadījumā visi tiek salīdzināti ar Amazon, ko var uzskatīt par nozares standartu.
Taču lokālajos risinājumos izvēle ir daudz lielāka, tāpēc ieskicēsim mums svarīgos kritērijus. Principā pietiek tikai ar diviem: atbalsts S3 API un v4 parakstīšanas izmantošana. Roku pie sirds, mūs kā topošo klientu interesē tikai saskarnes mijiedarbībai, un mūs neinteresē pašas noliktavas iekšējā virtuve.
Daudzi risinājumi atbilst šiem vienkāršajiem nosacījumiem. Piemēram, klasiskie korporatīvie smagsvari:
- DellEMC ECS
- NetApp S3 StorageGrid
- Nutanix spaiņi
- Pure Storage FlashBlade un StorReduce
- Huawei FusionStorage
Ir niša tīri programmatūras risinājumu, kas darbojas jau no kastes:
- Red Hat Ceph
- SUSE uzņēmuma krātuve
- Mākoņains
Un pat tie, kam patīk rūpīgi kārtot pēc montāžas, neapvainojās:
- CEPH tīrākajā formā
- Minio (Linux versija, jo ir daudz jautājumu par Windows versiju)
Saraksts nebūt nav pilnīgs, to var apspriest komentāros. Vienkārši neaizmirstiet pirms ieviešanas pārbaudīt sistēmas veiktspēju papildus API saderībai. Pēdējā lieta, ko vēlaties, ir zaudēt terabaitus datu iestrēgušu vaicājumu dēļ. Tāpēc nekautrējieties ar slodzes testiem. Kopumā visai pieaugušo programmatūrai, kas darbojas ar lielu datu apjomu, ir vismaz saderības atskaites. Gadījumā, ja Veeam tur ir par savstarpēju testēšanu, kas ļauj mums droši deklarēt mūsu produktu pilnīgu saderību ar konkrētu aprīkojumu. Tas jau ir divvirzienu darbs, ne vienmēr ātrs, bet mēs pastāvīgi paplašinām pārbaudīti risinājumi.
Mūsu stenda montāža
Es gribētu nedaudz parunāt par testa priekšmeta izvēli.
Pirmkārt, es vēlējos atrast iespēju, kas darbotos uzreiz. Nu, vai vismaz ar maksimālu varbūtību, ka tas darbosies bez nepieciešamības veikt nevajadzīgas kustības. Dejot ar tamburīnu un naktī čakarēt ar pulti ir ļoti aizraujoši, taču dažreiz gribas, lai tas nostrādā uzreiz. Un šādu risinājumu kopējā uzticamība parasti ir augstāka. Un jā, avantūrisma gars mūsos ir zudis, mēs pārstājām kāpt pa logiem mūsu mīļajām sievietēm utt.(c).
Otrkārt, godīgi sakot, nepieciešamība strādāt ar objektu glabātuvi rodas diezgan lielos uzņēmumos, tāpēc tieši tas ir gadījums, kad skatīties uz uzņēmuma līmeņa risinājumiem ir ne tikai apkaunojoši, bet pat iedrošināmi. Jebkurā gadījumā es vēl nezinu nevienu piemēru, ka kāds būtu atlaists par šādu risinājumu iegādi.
Pamatojoties uz visu iepriekš minēto, mana izvēle krita uz Dell EMC ECS kopienas izdevums. Šis ir ļoti interesants projekts, un es uzskatu par nepieciešamu jums par to pastāstīt.
Pirmā lieta, kas nāk prātā, kad redzat papildinājumu Kopienas izdevums - ka šī ir tikai pilna ECS kopija ar dažiem ierobežojumiem, kas tiek noņemti, iegādājoties licenci. Tātad nē!
Atcerieties:
!!!Community Edition ir atsevišķs projekts, kas izveidots testēšanai un bez Dell tehniskā atbalsta!!
Un to nevar pārvērst par pilnvērtīgu ECS, pat ja ļoti vēlaties.
Izdomāsim
Daudzi cilvēki uzskata, ka Dell EMC ECS ir gandrīz labākais risinājums, ja jums ir nepieciešama objektu glabāšana. Visi projekti ar ECS zīmolu, tostarp komerciālie un korporatīvie, ir balstīti uz . Sava veida labas gribas žests no Dell. Papildus programmatūrai, kas darbojas viņu firmas aparatūrā, ir arī atvērtā pirmkoda versija, ko var izvietot mākonī, virtuālajā mašīnā, konteinerā vai jebkurā no jūsu aparatūrā. Raugoties nākotnē, ir pat OVA versija, kuru mēs izmantosim.
Pati DELL ECS Community Edition ir pilnas programmatūras mini versija, kas darbojas firmas Dell EMC ECS serveros.
Es identificēju četras galvenās atšķirības:
- Nav šifrēšanas atbalsta. Tas ir kauns, bet ne kritisks.
- Trūkst auduma slāņa. Šī lieta ir atbildīga par kopu veidošanu, resursu pārvaldību, atjauninājumiem, Docker attēlu uzraudzību un glabāšanu. Šeit tas jau ir ļoti aizskaroši, taču arī Dell var saprast.
- Pretīgākās iepriekšējā punkta sekas: mezgla izmēru nevar paplašināt pēc instalēšanas pabeigšanas.
- Nav tehniskā atbalsta. Šis ir testēšanai paredzēts produkts, kuru nav aizliegts lietot mazās instalācijās, bet es personīgi neuzdrošinātos tur augšupielādēt petabaitus svarīgu datu. Bet tehniski neviens nevar jums liegt to darīt.
Kas ir lielajā versijā?
Dosimies pa Eiropu un iesim cauri dzelžainiem risinājumiem, lai iegūtu pilnīgāku izpratni par ekosistēmu.
Es kaut kā neapstiprināšu un neapstiprināšu apgalvojumu, ka DELL ECS ir labākā lokālā objektu krātuve, taču, ja jums ir kas sakāms par šo tēmu, es labprāt to izlasīšu komentāros. Vismaz pēc versijas Dell EMC pārliecinoši ir starp pieciem labākajiem OBS tirgus līderiem. Lai gan tur netiek ņemti vērā mākoņa risinājumi, šī ir atsevišķa saruna.
No tehniskā viedokļa ECS ir objektu krātuve, kas nodrošina piekļuvi datiem, izmantojot mākoņa krātuves protokolus. Atbalsta AWS S3 un OpenStack Swift. Failiem iespējotiem segmentiem ECS atbalsta NFSv3, lai eksportētu katru failu atsevišķi.
Informācijas ierakstīšanas process ir diezgan neparasts, īpaši pēc klasiskajām bloku uzglabāšanas sistēmām.
- Kad tiek saņemti jauni dati, tiek izveidots jauns objekts ar nosaukumu, pašiem datiem un metadatiem.
- Objekti tiek sadalīti 128 MB gabalos, un katrs gabals tiek ierakstīts trīs mezglos vienlaikus.
- Tiek atjaunināts indeksa fails, kurā tiek reģistrēti identifikatori un uzglabāšanas vietas.
- Žurnāla fails (žurnāla ieraksts) tiek atjaunināts un arī ierakstīts trīs mezglos.
- Klientam tiek nosūtīts ziņojums par veiksmīgu ierakstīšanu
Visas trīs datu kopijas ir rakstītas paralēli. Rakstīšana tiek uzskatīta par veiksmīgu tikai tad, ja visas trīs kopijas ir uzrakstītas veiksmīgi.
Lasīt ir vieglāk:
- Klients pieprasa datus.
- Indekss meklē, kur dati tiek glabāti.
- Dati tiek nolasīti no viena mezgla un nosūtīti klientam.
Pašu serveru ir diezgan daudz, tāpēc apskatīsim mazāko Dell EMC ECS EX300. Tas sākas no 60 TB, ar iespēju palielināties līdz 1,5 PB. Un tā vecākais brālis Dell EMC ECS EX3000 ļauj uzglabāt pat 8,6 PB vienā statīvā.
Izvietot
Tehniski Dell ECS CE var izvietot tik lielu, cik vēlaties. Jebkurā gadījumā es neatradu nekādus skaidrus ierobežojumus. Tomēr ir ērti veikt visu mērogošanu, klonējot pašu pirmo mezglu, kuram mums ir nepieciešams:
- 8 vCPU
- RAM 64GB
- 16 GB operētājsistēmai
- 1 TB tiešā krātuve
- CentOS minimālā jaunākā versija
Šī ir iespēja, kad vēlaties visu instalēt pats no paša sākuma. Šis variants mums nav aktuāls, jo... Izvietošanai izmantošu OVA attēlu.
Bet jebkurā gadījumā prasības ir ļoti ļaunas pat vienam mezglam, un, ja stingri ievēro likuma burtu, tad vajag četrus šādus mezglus.
Tomēr ECS CE izstrādātāji dzīvo reālajā pasaulē, un instalēšana ir veiksmīga pat ar vienu mezglu, un minimālās prasības ir:
- 4 vCPU
- 16 GB RAM
- 16 GB operētājsistēmai
- Pati 104 GB krātuve
Šie ir resursi, kas nepieciešami OVA attēla izvietošanai. Jau daudz humānāks un reālistiskāks.
Pašu instalācijas mezglu var iegūt no amatpersonas . Ir arī detalizēta dokumentācija par "viss vienā" izvietošanu, taču jūs varat lasīt arī oficiālajā . Tāpēc mēs sīkāk nekavēsimies pie OVA izvēršanas, tur nav nekādu triku. Galvenais ir tas, ka pirms tā palaišanas neaizmirstiet vai nu paplašināt disku līdz vajadzīgajam apjomam, vai pievienot nepieciešamos.
Mēs startējam mašīnu, atveram konsoli un izmantojam labākos noklusējuma akreditācijas datus:
- pieteikšanās: admin
- parole: ChangeMe
Pēc tam palaižam sudo nmtui un konfigurējam tīkla interfeisu - IP/mask, DNS un vārti. Paturot prātā, ka CentOS minimal nav tīkla rīku, mēs pārbaudām iestatījumus, izmantojot ip addr.
Un tā kā tikai drosmīgie iekaro jūras, mēs veicam yum atjauninājumu, pēc kura mēs atsāknējam. Tas patiesībā ir diezgan droši, jo... visa izvietošana tiek veikta, izmantojot rokasgrāmatas, un visas svarīgās docker pakotnes ir bloķētas pašreizējā versijā.
Tagad ir pienācis laiks rediģēt instalācijas skriptu. Jums nav nekādu izsmalcinātu logu vai pseido lietotāja interfeisa — viss tiek darīts, izmantojot jūsu iecienītāko teksta redaktoru. Tehniski ir divi veidi: katru komandu var palaist manuāli vai nekavējoties palaist videoploy konfiguratoru. Tas vienkārši atvērs vim konfigurāciju, un pēc iziešanas tas sāks to pārbaudīt. Bet nav interesanti apzināti vienkāršot savu dzīvi, tāpēc izpildīsim vēl divas komandas. Lai gan tam nav jēgas, es jūs brīdināju =)
Tātad, izveidosim vim ECS-CommunityEdition/deploy.xml un veiksim optimālās minimālās izmaiņas, lai ECS darbotos. Parametru sarakstu var saīsināt, bet es to izdarīju šādi:
- licenced_accepted: true Jums tas nav jāmaina, tad, izvietojot, jums tiks skaidri lūgts to pieņemt un tiks parādīta jauka frāze. Varbūt šī pat ir Lieldienu ola.
- Atņemiet komentārus no rindiņām autonames: un custom: Ievadiet vismaz vienu vēlamo mezgla nosaukumu — resursdatora nosaukums tiks aizstāts ar to instalēšanas procesa laikā.
- install_node: 192.168.1.1 Norādiet mezgla reālo IP. Mūsu gadījumā mēs norādām to pašu, ko nmtui
- dns_domain: ievadiet savu domēnu.
- dns_servers: ievadiet savu DNS.
- ntp_servers: varat norādīt jebkuru. Es paņēmu pirmo, ko atradu no baseina 0.pool.ntp.org (tā kļuva par 91.216.168.42)
- autonaming: custom Ja nekomentēsit, mēness tiks saukts par Lunu.
- ecs_block_devices:
/ dev / sdb
Nezināma iemesla dēļ var būt neeksistējoša bloka atmiņas ierīce /dev/vda - storage_pools:
biedri:
192.168.1.1 Šeit atkal mēs norādām mezgla reālo IP - ecs_block_devices:
/dev/sdb Mēs atkārtojam neesošu ierīču izgriešanas darbību.
Kopumā viss fails ir ļoti detalizēti aprakstīts , bet kurš gan to lasīs tik nemierīgā laikā. Tur arī teikts, ka minimāli pietiek norādīt IP un masku, bet manā laboratorijā šāds komplekts iesākās diezgan slikti, un nācās to paplašināt līdz iepriekš norādītajam.
Pēc iziešanas no redaktora jums ir jāpalaiž update_deploy /home/admin/ECS-CommunityEdition/deploy.yml, un, ja viss ir izdarīts pareizi, par to tiks skaidri ziņots.
Tad vēl jāpalaiž videoploy, jāgaida, kamēr vide atjaunināsies, un var sākt pašu instalāciju ar komandu ova-step1 un pēc veiksmīgas pabeigšanas komandu ova-step2. Svarīgi: nepārtrauciet skriptus ar roku! Dažas darbības var aizņemt daudz laika, tās var nebūt pabeigtas pirmajā mēģinājumā un var šķist, ka viss ir bojāts. Jebkurā gadījumā jums jāgaida, līdz skripts tiks dabiski pabeigts. Beigās jums vajadzētu redzēt līdzīgu ziņojumu.
Tagad mēs beidzot varam atvērt WebUI vadības paneli, izmantojot mums zināmo IP. Ja konfigurācija tajā posmā netika mainīta, noklusējuma konts būs root/ChangeMe. Jūs pat varat uzreiz izmantot mūsu ar S3 saderīgo krātuvi. Tas ir pieejams portos 9020 HTTP un 9021 portiem HTTPS. Atkal, ja nekas netika mainīts, tad access_key: object_admin1 un secret_key: ChangeMeChangeMeChangeMeChangeMeChangeMe.
Taču neapsteigsim sevi un sāksim kārtībā.
Piesakoties pirmo reizi, būsiet spiests nomainīt savu paroli uz atbilstošu, kas ir pilnīgi pareizi. Galvenais informācijas panelis ir ārkārtīgi skaidrs, tāpēc darīsim kaut ko interesantāku, nekā izskaidrosim acīmredzamos rādītājus. Piemēram, izveidosim lietotāju, kuru izmantosim, lai piekļūtu krātuvei. Pakalpojumu sniedzēju pasaulē tos sauc par īrniekiem. Tas tiek darīts sadaļā Pārvaldīt > Lietotāji > Jauns objekta lietotājs
Veidojot lietotāju, mums tiek lūgts norādīt nosaukumvietu. Tehniski nekas neliedz mums tos izveidot tik daudz, cik lietotāju. Un otrādi. Tas ļauj pārvaldīt resursus neatkarīgi katram nomniekam.
Attiecīgi mēs izvēlamies vajadzīgās funkcijas un ģenerējam lietotāja atslēgas. Man pietiks ar S3/Atmos. Un neaizmirstiet saglabāt atslēgu 😉
Lietotājs ir izveidots, tagad ir laiks piešķirt viņam spaini. Dodieties uz Pārvaldīt > Segums un aizpildiet obligātos laukus. Šeit viss ir vienkārši.
Tagad viss ir gatavs mūsu S3 krātuves kaujas lietošanai.
Veeam iestatīšana
Tātad, kā mēs atceramies, viens no galvenajiem objektu glabāšanas veidiem ir tādas informācijas ilgtermiņa glabāšana, kurai tiek reti piekļūts. Ideāls piemērs ir nepieciešamība saglabāt dublējumus attālā vietā. Programmā Veeam Backup & Replication šo līdzekli sauc par jaudas līmeni.
Sāksim iestatīšanu, pievienojot mūsu Dell ECS CE Veeam saskarnei. Cilnē Dublēšanas infrastruktūra palaidiet vedni Pievienot jaunu repozitoriju un atlasiet Objektu krātuve.
Izvēlēsimies, ar ko tas viss sākās – S3 Compatible.
Parādītajā logā ierakstiet vajadzīgo nosaukumu un pārejiet uz konta darbību. Šeit veidlapā jānorāda apkalpošanas punkts , reģionu var atstāt tādu, kāds tas ir, un pievienot izveidoto lietotāju. Vārtu serveris ir nepieciešams, ja jūsu krātuve atrodas attālā vietnē, taču šī jau ir infrastruktūras optimizācijas tēma un atsevišķs raksts, tāpēc šeit varat to droši izlaist.
Ja viss ir norādīts un konfigurēts pareizi, parādīsies brīdinājums par sertifikātu un pēc tam logs ar spaini, kurā varat izveidot mapi mūsu failiem.
Mēs ejam cauri vednim līdz galam un izbaudām rezultātu.
Nākamais solis ir vai nu izveidot jaunu Scale-out dublējuma krātuvi, vai pievienot mūsu S3 esošajam — tas tiks izmantots kā ietilpības līmenis arhīva glabāšanai. Pašreizējā laidienā nav funkcijas, kas tieši izmantotu ar S3 saderīgu krātuvi, piemēram, parastu repozitoriju. Lai tas notiktu, ir jāatrisina pārāk daudz diezgan acīmredzamu problēmu, taču viss ir iespējams.
Dodieties uz repozitorija iestatījumiem un iespējojiet ietilpības līmeni. Tur viss ir caurspīdīgs, taču ir interesanta nianse: ja vēlaties, lai visi dati pēc iespējas ātrāk tiktu nosūtīti uz objektu krātuvi, vienkārši iestatiet to uz 0 dienām.
Ja pēc vedņa apmeklēšanas nevēlaties gaidīt, varat repozitorijā nospiest ctrl+RMB, piespiedu kārtā palaist līmeņu darbu un skatīties, kā diagrammas pārmeklē.
Tas pagaidām ir viss. Es domāju, ka man izdevās parādīt, ka bloku uzglabāšana nav tik biedējoša, kā cilvēki domā. Jā, ir risinājumi un iespējas gan vagonam, gan mazam ratam, taču visu nevar aptvert vienā rakstā. Tāpēc dalīsimies pieredzē komentāros.
Avots: www.habr.com
