Helo, ddarllenwyr Habr. Gyda'r erthygl hon rydym yn agor cyfres a fydd yn siarad am y system hyperconverged AERODISK vAIR yr ydym wedi'i ddatblygu. I ddechrau, roeddem am ddweud popeth am bopeth yn yr erthygl gyntaf, ond mae'r system yn eithaf cymhleth, felly byddwn yn bwyta'r eliffant mewn rhannau.
Gadewch i ni ddechrau'r stori gyda hanes creu'r system, ymchwilio i system ffeiliau ARDFS, sy'n sail i vAIR, a hefyd siarad ychydig am leoliad yr ateb hwn ar farchnad Rwsia.
Mewn erthyglau yn y dyfodol byddwn yn siarad yn fwy manwl am wahanol gydrannau pensaernïol (clwstwr, hypervisor, cydbwysedd llwyth, system fonitro, ac ati), y broses ffurfweddu, codi materion trwyddedu, dangos profion damwain ar wahân ac, wrth gwrs, ysgrifennu am brofi llwyth a sizing. Byddwn hefyd yn neilltuo erthygl ar wahân i'r fersiwn gymunedol o vAIR.
Ai stori am systemau storio yw Aerodisk? Neu pam wnaethon ni ddechrau gwneud hypergydgyfeirio yn y lle cyntaf?
I ddechrau, daeth y syniad i greu ein gor-gydgyfeirio ein hunain i ni rywle tua 2010. Ar y pryd, nid oedd Aerodisk nac atebion tebyg (systemau hypergydgyfeiriol bocsys masnachol) ar y farchnad. Ein tasg oedd y canlynol: o set o weinyddion gyda disgiau lleol, wedi'u huno gan ryng-gysylltiad trwy'r protocol Ethernet, roedd angen creu storfa estynedig a lansio peiriannau rhithwir a rhwydwaith meddalwedd yno. Roedd yn rhaid gweithredu hyn i gyd heb systemau storio (oherwydd yn syml, nid oedd arian ar gyfer systemau storio a'i galedwedd, ac nid oeddem wedi dyfeisio ein systemau storio ein hunain eto).
Fe wnaethom roi cynnig ar lawer o atebion ffynhonnell agored ac yn olaf datrys y broblem hon, ond roedd yr ateb yn gymhleth iawn ac yn anodd ei ailadrodd. Ar ben hynny, roedd yr ateb hwn yn y categori “A yw'n gweithio? Peidiwch â chyffwrdd! Felly, ar ôl datrys y broblem honno, ni wnaethom ddatblygu ymhellach y syniad o drawsnewid canlyniad ein gwaith yn gynnyrch cyflawn.
Ar ôl y digwyddiad hwnnw, symudasom i ffwrdd o'r syniad hwn, ond roeddem yn dal i deimlo bod y broblem hon yn gwbl solvable, ac roedd manteision datrysiad o'r fath yn fwy nag amlwg. Yn dilyn hynny, dim ond y teimlad hwn a gadarnhaodd y cynhyrchion HCI a ryddhawyd o gwmnïau tramor.
Felly, yng nghanol 2016, fe wnaethom ddychwelyd at y dasg hon fel rhan o greu cynnyrch cyflawn. Bryd hynny nid oedd gennym unrhyw berthynas â buddsoddwyr eto, felly roedd yn rhaid i ni brynu stondin datblygu ar gyfer ein harian ein hunain nad oedd yn fawr iawn. Ar ôl casglu gweinyddion ail law a switshis ymlaen Avito, daethom i lawr i fusnes.
Y brif dasg gychwynnol oedd creu ein system ffeiliau ein hunain, er ei bod yn syml, a allai ddosbarthu data yn awtomatig ac yn gyfartal ar ffurf blociau rhithwir ar yr nfed nifer o nodau clwstwr, sy'n cael eu cysylltu gan ryng-gysylltiad trwy Ethernet. Ar yr un pryd, dylai'r FS raddio'n dda ac yn hawdd a bod yn annibynnol ar systemau cyfagos, h.y. cael eu dieithrio oddi wrth vAIR ar ffurf “cyfleuster storio yn unig”.
Cysyniad vAIR cyntaf
Rhoesom yn fwriadol y gorau i ddefnyddio datrysiadau ffynhonnell agored parod ar gyfer trefnu storfa estynedig (ceph, gluster, luster ac ati) o blaid ein datblygiad ein hunain, gan ein bod eisoes wedi cael llawer o brofiad prosiect gyda nhw. Wrth gwrs, mae'r atebion hyn eu hunain yn wych, a chyn gweithio ar Aerodisk, fe wnaethom weithredu mwy nag un prosiect integreiddio gyda nhw. Ond mae'n un peth i weithredu tasg benodol ar gyfer un cwsmer, hyfforddi staff ac, efallai, prynu cefnogaeth gwerthwr mawr, a pheth eithaf arall i greu cynnyrch hawdd ei ailadrodd a fydd yn cael ei ddefnyddio ar gyfer tasgau amrywiol, yr ydym ni, fel gwerthwr, efallai hyd yn oed yn gwybod am ein hunain ni fyddwn. At yr ail ddiben, nid oedd cynhyrchion ffynhonnell agored presennol yn addas i ni, felly penderfynasom greu system ffeiliau ddosbarthedig ein hunain.
Ddwy flynedd yn ddiweddarach, cyflawnodd nifer o ddatblygwyr (a gyfunodd waith ar vAIR â gwaith ar y system storio Beiriant clasurol) ganlyniad penodol.
Erbyn 2018, roeddem wedi ysgrifennu system ffeiliau syml a'i hategu â'r caledwedd angenrheidiol. Cyfunodd y system ddisgiau ffisegol (lleol) o wahanol weinyddion yn un pwll fflat trwy ryng-gysylltiad mewnol a'u “torri” yn flociau rhithwir, yna crëwyd dyfeisiau bloc gyda graddau amrywiol o oddefgarwch nam o'r blociau rhithwir, y crëwyd rhai rhithwir arnynt. a'i weithredu gan ddefnyddio'r ceir hypervisor KVM.
Wnaethon ni ddim trafferthu gormod ag enw'r system ffeiliau a'i alw'n gryno yn ARDFS (dyfalwch beth mae'n ei olygu))
Roedd y prototeip hwn yn edrych yn dda (nid yn weledol, wrth gwrs, nid oedd unrhyw ddyluniad gweledol eto) ac yn dangos canlyniadau da o ran perfformiad a graddio. Ar ôl y canlyniad gwirioneddol cyntaf, fe wnaethom roi'r prosiect hwn ar waith, gan drefnu amgylchedd datblygu llawn a thîm ar wahân a oedd yn delio â vAIR yn unig.
Dim ond erbyn hynny, roedd pensaernïaeth gyffredinol yr ateb wedi aeddfedu, nad yw wedi cael newidiadau mawr eto.
Plymio i mewn i system ffeiliau ARDFS
ARDFS yw sylfaen vAIR, sy'n darparu storfa ddata wasgaredig, goddefgar ar draws y clwstwr cyfan. Un o (ond nid yr unig) nodweddion nodedig ARDFS yw nad yw'n defnyddio unrhyw weinyddion pwrpasol ychwanegol ar gyfer metadata a rheolaeth. Dyluniwyd hyn yn wreiddiol i symleiddio cyfluniad y datrysiad ac am ei ddibynadwyedd.
Strwythur storio
O fewn holl nodau'r clwstwr, mae ARDFS yn trefnu cronfa resymegol o'r holl ofod disg sydd ar gael. Mae’n bwysig deall nad yw cronfa yn ofod data neu wedi’i fformatio eto, ond yn syml marcio, h.y. Mae unrhyw nodau gyda vAIR wedi'u gosod, o'u hychwanegu at y clwstwr, yn cael eu hychwanegu'n awtomatig at y gronfa ARDFS a rennir ac mae adnoddau disg yn cael eu rhannu'n awtomatig ar draws y clwstwr cyfan (ac ar gael ar gyfer storio data yn y dyfodol). Mae'r dull hwn yn caniatáu ichi ychwanegu a thynnu nodau ar y hedfan heb unrhyw effaith ddifrifol ar y system sydd eisoes yn rhedeg. Y rhai. mae'r system yn hawdd iawn i'w graddio “mewn brics”, gan ychwanegu neu dynnu nodau yn y clwstwr os oes angen.
Mae disgiau rhithwir (gwrthrychau storio ar gyfer peiriannau rhithwir) yn cael eu hychwanegu ar ben y pwll ARDFS, sy'n cael eu hadeiladu o flociau rhithwir o 4 megabeit mewn maint. Mae disgiau rhithwir yn storio data yn uniongyrchol. Mae'r cynllun goddefgarwch bai hefyd wedi'i osod ar lefel y disg rhithwir.
Fel y gallech fod wedi dyfalu eisoes, ar gyfer goddef diffygion yr is-system ddisg, nid ydym yn defnyddio'r cysyniad o RAID (Arae Diangen o Ddisgiau annibynnol), ond yn defnyddio RAIN (Arae Diangen o Nodau annibynnol). Y rhai. Mae goddefgarwch nam yn cael ei fesur, ei awtomeiddio a'i reoli yn seiliedig ar y nodau, nid y disgiau. Mae disgiau, wrth gwrs, hefyd yn wrthrych storio, maen nhw, fel popeth arall, yn cael eu monitro, gallwch chi berfformio'r holl weithrediadau safonol gyda nhw, gan gynnwys cydosod RAID caledwedd lleol, ond mae'r clwstwr yn gweithredu'n benodol ar nodau.
Mewn sefyllfa lle rydych chi wir eisiau RAID (er enghraifft, senario sy'n cefnogi methiannau lluosog ar glystyrau bach), nid oes dim yn eich atal rhag defnyddio rheolwyr RAID lleol, ac adeiladu storfa estynedig a phensaernïaeth RAIN ar ei ben. Mae'r senario hwn yn eithaf byw ac yn cael ei gefnogi gennym ni, felly byddwn yn siarad amdano mewn erthygl am senarios nodweddiadol ar gyfer defnyddio vAIR.
Cynlluniau Goddef Nam Storio
Gall fod dau gynllun goddef diffygion ar gyfer disgiau rhithwir yn vAIR:
1) Ffactor atgynhyrchu neu ddyblygiad yn unig - mae'r dull hwn o oddefgarwch bai mor syml â ffon a rhaff. Perfformir atgynhyrchu cydamserol rhwng nodau â ffactor o 2 (2 gopi fesul clwstwr) neu 3 (3 chopi, yn y drefn honno). Mae RF-2 yn caniatáu disg rhithwir i wrthsefyll methiant un nod yn y clwstwr, ond mae'n “bwyta” hanner y cyfaint defnyddiol, a bydd RF-3 yn gwrthsefyll methiant 2 nod yn y clwstwr, ond mae'n cadw 2/3 o'r cyfrol ddefnyddiol ar gyfer ei anghenion. Mae'r cynllun hwn yn debyg iawn i RAID-1, hynny yw, mae disg rhithwir wedi'i ffurfweddu yn RF-2 yn gwrthsefyll methiant unrhyw un nod yn y clwstwr. Yn yr achos hwn, bydd popeth yn iawn gyda'r data ac ni fydd hyd yn oed yr I / O yn dod i ben. Pan fydd y nod syrthiedig yn dychwelyd i'r gwasanaeth, bydd adferiad / cydamseru data awtomatig yn dechrau.
Isod mae enghreifftiau o ddosbarthiad data RF-2 a RF-3 yn y modd arferol ac mewn sefyllfa fethiant.
Mae gennym beiriant rhithwir gyda chynhwysedd o 8MB o ddata unigryw (defnyddiol), sy'n rhedeg ar 4 nod vAIR. Mae'n amlwg ei bod yn annhebygol mewn gwirionedd y bydd cyfaint mor fach, ond ar gyfer cynllun sy'n adlewyrchu rhesymeg gweithrediad ARDFS, yr enghraifft hon yw'r un mwyaf dealladwy. Mae AB yn flociau rhithwir 4MB sy'n cynnwys data peiriannau rhithwir unigryw. Mae RF-2 yn creu dau gopi o'r blociau hyn A1 + A2 a B1 + B2, yn y drefn honno. Mae'r blociau hyn wedi'u “gosod allan” ar draws nodau, gan osgoi croestoriad yr un data ar yr un nod, hynny yw, ni fydd copi A1 wedi'i leoli ar yr un nod â chopi A2. Yr un peth â B1 a B2.
Os bydd un o'r nodau'n methu (er enghraifft, nod Rhif 3, sy'n cynnwys copi o B1), caiff y copi hwn ei actifadu'n awtomatig ar y nod lle nad oes copi o'i gopi (hynny yw, copi o B2).
Felly, gall y disg rhithwir (a'r VM, yn unol â hynny) oroesi methiant un nod yn y cynllun RF-2 yn hawdd.
Mae'r cynllun atgynhyrchu, er ei fod yn syml ac yn ddibynadwy, yn dioddef o'r un broblem â RAID1 - dim digon o le y gellir ei ddefnyddio.
2) Mae codio dileu neu godio dileu (a elwir hefyd yn “godio segur”, “codio dileu” neu “god dileu swydd”) yn bodoli i ddatrys y broblem uchod. Mae EC yn gynllun diswyddo sy'n darparu argaeledd data uchel gyda gofod disg is uwchben o'i gymharu â dyblygu. Mae egwyddor weithredol y mecanwaith hwn yn debyg i RAID 5, 6, 6P.
Wrth amgodio, mae'r broses EC yn rhannu bloc rhithwir (4MB yn ddiofyn) yn sawl "darn data" llai yn dibynnu ar gynllun y CE (er enghraifft, mae cynllun 2+1 yn rhannu pob bloc 4MB yn 2 dalp 2MB). Nesaf, mae'r broses hon yn cynhyrchu “talpiau cydraddoldeb” ar gyfer y “talpiau data” nad ydynt yn fwy nag un o'r rhannau a rannwyd yn flaenorol. Wrth ddadgodio, mae EC yn cynhyrchu'r talpiau coll trwy ddarllen y data “goroesi” ar draws y clwstwr cyfan.
Er enghraifft, bydd disg rhithwir gyda chynllun 2 + 1 EC, a weithredir ar 4 nod clwstwr, yn hawdd wrthsefyll methiant un nod yn y clwstwr yn yr un modd ag RF-2. Yn yr achos hwn, bydd y costau gorbenion yn is, yn benodol, y cyfernod cynhwysedd defnyddiol ar gyfer RF-2 yw 2, ac ar gyfer EC 2+1 bydd yn 1,5.
I'w ddisgrifio'n symlach, y hanfod yw bod y bloc rhithwir wedi'i rannu'n 2-8 (pam o 2 i 8, gweler isod) “darnau”, ac ar gyfer y darnau hyn cyfrifir “darnau” o gydraddoldeb cyfaint tebyg.
O ganlyniad, mae data a chydraddoldeb wedi'u dosbarthu'n gyfartal ar draws holl nodau'r clwstwr. Ar yr un pryd, yn yr un modd ag atgynhyrchu, mae ARDFS yn dosbarthu data yn awtomatig ymhlith nodau mewn modd sy'n atal data union yr un fath (copïau o ddata a'u cydraddoldeb) rhag cael eu storio ar yr un nod, er mwyn dileu'r siawns o golli data dyledus. i'r ffaith y bydd y data a'u cydraddoldeb yn dod i ben yn sydyn ar un nod storio sy'n methu.
Isod mae enghraifft, gyda'r un peiriant rhithwir 8 MB a 4 nod, ond gyda chynllun EC 2+1.
Rhennir blociau A a B yn ddau ddarn o 2 MB yr un (dau oherwydd 2+1), hynny yw, A1+A2 a B1+B2. Yn wahanol i replica, nid yw A1 yn gopi o A2, mae'n bloc rhithwir A, wedi'i rannu'n ddwy ran, yr un peth â bloc B. Yn gyfan gwbl, rydym yn cael dwy set o 4MB, ac mae pob un ohonynt yn cynnwys dau ddarn dwy-MB. Nesaf, ar gyfer pob un o'r setiau hyn, cyfrifir cydraddoldeb gyda chyfaint o ddim mwy nag un darn (h.y. 2 MB), rydym yn cael + 2 ddarn ychwanegol o gydraddoldeb (AP a BP). Yn gyfan gwbl mae gennym ddata 4 × 2 + 2 × 2 cydraddoldeb.
Nesaf, mae'r darnau wedi'u “gosod allan” ymhlith y nodau fel nad yw'r data'n croestorri â'u cydraddoldeb. Y rhai. Ni fydd A1 ac A2 ar yr un nod ag AP.
Mewn achos o fethiant o un nod (er enghraifft, hefyd y trydydd), bydd y bloc syrthio B1 yn cael ei adfer yn awtomatig o'r cydraddoldeb BP, sy'n cael ei storio ar nod Rhif 2, a bydd yn cael ei actifadu ar y nod lle mae dim B-cydraddoldeb, h.y. darn o BP. Yn yr enghraifft hon, dyma nod Rhif 1
Rwy’n siŵr bod gan y darllenydd gwestiwn:
“Mae popeth a ddisgrifiwyd gennych wedi cael ei weithredu ers amser maith gan gystadleuwyr ac mewn datrysiadau ffynhonnell agored, beth yw'r gwahaniaeth rhwng eich gweithrediad o EC yn ARDFS?”
Ac yna bydd nodweddion diddorol ARDFS.
Dileu codau gyda ffocws ar hyblygrwydd
I ddechrau, darparwyd cynllun EC X+Y gweddol hyblyg, lle mae X yn hafal i rif o 2 i 8, ac Y yn hafal i rif o 1 i 8, ond bob amser yn llai na neu'n hafal i X. Darperir y cynllun hwn am hyblygrwydd. Mae cynyddu nifer y darnau data (X) y mae'r bloc rhithwir wedi'i rannu iddynt yn caniatáu lleihau costau gorbenion, hynny yw, cynyddu gofod defnyddiadwy.
Mae cynyddu nifer y talpiau cydraddoldeb (Y) yn cynyddu dibynadwyedd y ddisg rithwir. Po fwyaf yw'r gwerth Y, y mwyaf o nodau yn y clwstwr sy'n gallu methu. Wrth gwrs, mae cynyddu'r cyfaint cydraddoldeb yn lleihau faint o gapasiti y gellir ei ddefnyddio, ond mae hwn yn bris i'w dalu am ddibynadwyedd.
Mae dibyniaeth perfformiad ar gylchedau CE bron yn uniongyrchol: po fwyaf o “ddarnau”, yr isaf yw'r perfformiad; yma, wrth gwrs, mae angen golwg gytbwys.
Mae'r dull hwn yn galluogi gweinyddwyr i ffurfweddu storfa estynedig gyda'r hyblygrwydd mwyaf. O fewn y pwll ARDFS, gallwch ddefnyddio unrhyw gynlluniau goddef diffygion a'u cyfuniadau, sydd, yn ein barn ni, hefyd yn ddefnyddiol iawn.
Isod mae tabl sy'n cymharu sawl cynllun RF a EC (nid pob un yn bosibl).
Mae'r tabl yn dangos bod hyd yn oed y cyfuniad mwyaf “terry” EC 8+7, sy'n caniatáu colli hyd at 7 nod mewn clwstwr ar yr un pryd, yn “bwyta” llai o ofod defnyddiadwy (1,875 yn erbyn 2) na dyblygu safonol, ac yn amddiffyn 7 gwaith yn well. , sy'n gwneud y mecanwaith amddiffyn hwn, er ei fod yn fwy cymhleth, yn llawer mwy deniadol mewn sefyllfaoedd lle mae angen sicrhau'r dibynadwyedd mwyaf posibl mewn amodau lle cyfyngedig ar y ddisg. Ar yr un pryd, mae angen i chi ddeall y bydd pob "plws" i X neu Y yn orbenion perfformiad ychwanegol, felly yn y triongl rhwng dibynadwyedd, arbedion a pherfformiad mae angen i chi ddewis yn ofalus iawn. Am y rheswm hwn, byddwn yn neilltuo erthygl ar wahân i ddileu maint codio.
Dibynadwyedd ac ymreolaeth y system ffeiliau
Mae ARDFS yn rhedeg yn lleol ar bob nod o'r clwstwr ac yn eu cydamseru gan ddefnyddio ei ddulliau ei hun trwy ryngwynebau Ethernet pwrpasol. Y pwynt pwysig yw bod ARDFS yn cydamseru'n annibynnol nid yn unig y data, ond hefyd y metadata sy'n gysylltiedig â storio. Wrth weithio ar ARDFS, ar yr un pryd astudiwyd nifer o atebion presennol a gwnaethom ddarganfod bod llawer yn cydamseru meta'r system ffeiliau gan ddefnyddio DBMS dosbarthedig allanol, yr ydym hefyd yn ei ddefnyddio ar gyfer cydamseru, ond dim ond ffurfweddiadau, nid metadata FS (am hyn ac is-systemau cysylltiedig eraill yn yr erthygl nesaf).
Mae cysoni metadata FS gan ddefnyddio DBMS allanol, wrth gwrs, yn ddatrysiad gweithredol, ond yna byddai cysondeb y data sy'n cael ei storio ar ARDFS yn dibynnu ar y DBMS allanol a'i ymddygiad (ac, a dweud y gwir, mae'n fenyw fympwyol), sydd mewn mae ein barn yn ddrwg. Pam? Os bydd metadata FS yn cael ei niweidio, gellir dweud “hwyl fawr,” ar ddata FS ei hun, felly fe benderfynon ni ddilyn llwybr mwy cymhleth ond dibynadwy.
Gwnaethom yr is-system cydamseru metadata ar gyfer ARDFS ein hunain, ac mae'n byw'n gwbl annibynnol ar is-systemau cyfagos. Y rhai. ni all unrhyw is-system arall lygru data ARDFS. Yn ein barn ni, dyma'r ffordd fwyaf dibynadwy a chywir, ond amser a ddengys a yw hyn mewn gwirionedd. Yn ogystal, mae mantais ychwanegol gyda'r dull hwn. Gellir defnyddio ARDFS yn annibynnol ar vAIR, yn union fel storfa estynedig, y byddwn yn sicr yn ei ddefnyddio mewn cynhyrchion yn y dyfodol.
O ganlyniad, trwy ddatblygu ARDFS, cawsom system ffeiliau hyblyg a dibynadwy sy'n rhoi dewis lle gallwch arbed ar gapasiti neu roi'r gorau i bopeth ar berfformiad, neu wneud storfa hynod ddibynadwy am gost resymol, ond gan leihau gofynion perfformiad.
Ynghyd â pholisi trwyddedu syml a model darparu hyblyg (wrth edrych ymlaen, mae vAIR wedi'i drwyddedu trwy nod a'i gyflwyno naill ai fel meddalwedd neu fel pecyn meddalwedd), mae hyn yn ei gwneud hi'n bosibl teilwra'r datrysiad yn gywir iawn i amrywiaeth eang o ofynion cwsmeriaid a yna yn hawdd cynnal y cydbwysedd hwn.
Pwy sydd angen y wyrth hon?
Ar y naill law, gallwn ddweud bod yna chwaraewyr ar y farchnad eisoes sydd ag atebion difrifol ym maes gor-gydgyfeirio, a dyma lle'r ydym mewn gwirionedd yn mynd. Mae'n ymddangos bod y datganiad hwn yn wir, OND ...
Ar y llaw arall, pan fyddwn yn mynd allan i'r meysydd ac yn cyfathrebu â chwsmeriaid, rydym ni a'n partneriaid yn gweld nad yw hyn yn wir o gwbl. Mae yna lawer o dasgau ar gyfer hypergydgyfeirio, mewn rhai mannau nid oedd pobl yn gwybod bod datrysiadau o'r fath yn bodoli, mewn eraill roedd yn ymddangos yn ddrud, mewn eraill roedd profion aflwyddiannus o atebion amgen, ac mewn eraill maent yn gwahardd prynu o gwbl oherwydd sancsiynau. Yn gyffredinol, trodd y cae allan yn un aredig, felly aethom i godi pridd gwyryf))).
Pryd mae'r system storio yn well na GCS?
Wrth i ni weithio gyda'r farchnad, gofynnir i ni yn aml pryd mae'n well defnyddio cynllun clasurol gyda systemau storio, a phryd i ddefnyddio hyperconvergent? Mae llawer o gwmnïau sy’n cynhyrchu GCS (yn enwedig y rhai nad oes ganddynt systemau storio yn eu portffolio) yn dweud: “Mae systemau storio yn dod yn ddarfodedig, yn hypergydgyfeiriol yn unig!” Mae hwn yn ddatganiad beiddgar, ond nid yw'n adlewyrchu realiti yn llwyr.
Mewn gwirionedd, mae'r farchnad storio yn wir yn symud tuag at or-gydgyfeirio ac atebion tebyg, ond mae “ond” bob amser.
Yn gyntaf, ni ellir yn hawdd ailadeiladu canolfannau data a seilweithiau TG a adeiladwyd yn ôl y cynllun clasurol gyda systemau storio, felly mae moderneiddio a chwblhau seilweithiau o'r fath yn dal i fod yn etifeddiaeth am 5-7 mlynedd.
Yn ail, mae'r seilwaith sy'n cael ei adeiladu ar hyn o bryd yn bennaf (sy'n golygu Ffederasiwn Rwsia) yn cael ei adeiladu yn unol â'r cynllun clasurol gan ddefnyddio systemau storio, ac nid oherwydd nad yw pobl yn gwybod am hypergydgyfeirio, ond oherwydd bod y farchnad hypergydgyfeirio yn newydd, atebion a nid yw safonau wedi'u sefydlu eto , nid yw pobl TG wedi'u hyfforddi eto, nid oes ganddynt lawer o brofiad, ond mae angen iddynt adeiladu canolfannau data yma ac yn awr. A bydd y duedd hon yn para am 3-5 mlynedd arall (ac yna etifeddiaeth arall, gweler pwynt 1).
Yn drydydd, mae cyfyngiad technegol pur mewn oedi bach ychwanegol o 2 milieiliad fesul ysgrifennu (ac eithrio'r storfa leol, wrth gwrs), sef cost storio dosbarthedig.
Wel, gadewch i ni beidio ag anghofio am y defnydd o weinyddion corfforol mawr sy'n caru graddio fertigol yr is-system ddisg.
Mae yna lawer o dasgau angenrheidiol a phoblogaidd lle mae systemau storio yn ymddwyn yn well na GCS. Yma, wrth gwrs, ni fydd y gweithgynhyrchwyr hynny nad oes ganddynt systemau storio yn eu portffolio cynnyrch yn cytuno â ni, ond rydym yn barod i ddadlau'n rhesymol. Wrth gwrs, byddwn ni, fel datblygwyr y ddau gynnyrch, yn bendant yn cymharu systemau storio a GCS yn un o'n cyhoeddiadau yn y dyfodol, lle byddwn yn dangos yn glir pa un sydd orau o dan ba amodau.
A ble bydd atebion hypergydgyfeiriol yn gweithio'n well na systemau storio?
Yn seiliedig ar y pwyntiau uchod, gellir dod i dri chasgliad amlwg:
- Lle mae 2 milieiliad ychwanegol o hwyrni ar gyfer cofnodi, sy'n digwydd yn gyson mewn unrhyw gynnyrch (nawr nid ydym yn sôn am synthetigau, gellir dangos nanoseconds ar synthetigion), yn anfeirniadol, mae hypergydgyfeiriol yn addas.
- Lle gellir troi'r llwyth o weinyddion corfforol mawr yn nifer o rai rhithwir bach a'u dosbarthu ymhlith nodau, bydd hypergydgyfeiriant hefyd yn gweithio'n dda yno.
- Lle mae graddio llorweddol yn flaenoriaeth uwch na graddio fertigol, bydd GCS yn gwneud yn iawn yno hefyd.
Beth yw'r atebion hyn?
- Pob gwasanaeth seilwaith safonol (gwasanaeth cyfeiriadur, post, EDMS, gweinyddwyr ffeiliau, systemau ERP a BI bach neu ganolig, ac ati). Rydym yn galw hyn yn “gyfrifiadura cyffredinol”.
- Seilwaith darparwyr cwmwl, lle mae angen ehangu a “torri” yn gyflym yn llorweddol yn llorweddol nifer fawr o beiriannau rhithwir ar gyfer cleientiaid.
- Seilwaith bwrdd gwaith rhithwir (VDI), lle mae llawer o beiriannau rhithwir defnyddwyr bach yn rhedeg ac yn “arnofio” yn dawel o fewn clwstwr unffurf.
- Rhwydweithiau cangen, lle mae angen seilwaith safonol, goddefgar, ond rhad o 15-20 o beiriannau rhithwir ar bob cangen.
- Unrhyw gyfrifiadura dosranedig (gwasanaethau data mawr, er enghraifft). Lle mae'r llwyth yn mynd nid “mewn dyfnder”, ond “yn ehangder”.
- Amgylcheddau prawf lle mae oedi bach ychwanegol yn dderbyniol, ond mae cyfyngiadau cyllidebol, oherwydd bod y rhain yn brofion.
Ar hyn o bryd, ar gyfer y tasgau hyn yr ydym wedi gwneud AERODISK vAIR ac arnynt hwy yr ydym yn canolbwyntio (yn llwyddiannus hyd yn hyn). Efallai y bydd hyn yn newid yn fuan, oherwydd... nid yw'r byd yn sefyll yn ei unfan.
Felly…
Mae hyn yn cwblhau rhan gyntaf cyfres fawr o erthyglau; yn yr erthygl nesaf byddwn yn siarad am bensaernïaeth y datrysiad a'r cydrannau a ddefnyddir.
Rydym yn croesawu cwestiynau, awgrymiadau ac anghydfodau adeiladol.
Ffynhonnell: hab.com