Saluton, Habr-legantoj. Kun ĉi tiu artikolo ni malfermas serion, kiu parolos pri la hiperkonverĝa sistemo AERODISK vAIR, kiun ni evoluigis. Komence, ni volis rakonti ĉion pri ĉio en la unua artikolo, sed la sistemo estas sufiĉe kompleksa, do ni manĝos la elefanton en partoj.
Ni komencu la historion kun la historio de la kreado de la sistemo, enprofundu en la dosiersistemon ARDFS, kiu estas la bazo de vAIR, kaj ankaŭ parolu iomete pri la poziciigado de ĉi tiu solvo sur la rusa merkato.
En estontaj artikoloj ni parolos pli detale pri malsamaj arkitekturaj komponentoj (areto, hiperviziero, ŝarĝbalancilo, monitoradsistemo ktp.), la agorda procezo, levos licencajn problemojn, aparte montros kraŝtestojn kaj, kompreneble, skribos pri ŝarĝtestado kaj grandeco. Ni ankaŭ dediĉos apartan artikolon al la komunuma versio de vAIR.
Ĉu Aerodisk estas rakonto pri stokadsistemoj? Aŭ kial ni komencis fari hiperkonverĝon en la unua loko?
Komence, la ideo krei nian propran hiperkonverĝon venis al ni ie ĉirkaŭ 2010. En tiu tempo, ekzistis nek Aerodisk nek similaj solvoj (komercaj boksitaj hiperkonverĝaj sistemoj) sur la merkato. Nia tasko estis la jena: el aro da serviloj kun lokaj diskoj, kunigitaj per interkonekto per la Ethernet-protokolo, necesis krei plilongigitan konservadon kaj lanĉi tie virtualajn maŝinojn kaj programaran reton. Ĉio ĉi devis esti efektivigita sen stoksistemoj (ĉar simple mankis mono por stoksistemoj kaj ĝia aparataro, kaj ni ankoraŭ ne inventis niajn proprajn stoksistemojn).
Ni provis multajn malfermkodajn solvojn kaj finfine solvis ĉi tiun problemon, sed la solvo estis tre kompleksa kaj malfacile ripetebla. Krome, ĉi tiu solvo estis en la kategorio "Ĉu ĝi funkcias? Ne tuŝu! Sekve, solvinte tiun problemon, ni ne plu disvolvis la ideon transformi la rezulton de nia laboro en plenan produkton.
Post tiu okazaĵo, ni malproksimiĝis de ĉi tiu ideo, sed ni ankoraŭ havis la senton, ke ĉi tiu problemo estas tute solvebla, kaj la avantaĝoj de tia solvo estis pli ol evidentaj. Poste, la liberigitaj HCI-produktoj de eksterlandaj kompanioj nur konfirmis ĉi tiun senton.
Sekve, meze de 2016, ni revenis al ĉi tiu tasko kiel parto de kreado de plena produkto. Tiutempe ni ankoraŭ ne havis rilatojn kun investantoj, do ni devis aĉeti evoluistan standon por nia propra ne tre granda mono. Kolektinte uzitajn servilojn kaj ŝaltilojn sur Avito, ni eklaboris.
La ĉefa komenca tasko estis krei nian propran, kvankam simplan, sed nian propran dosiersistemon, kiu povis aŭtomate kaj egale distribui datumojn en formo de virtualaj blokoj sur la n-a nombro da grapolnodoj, kiuj estas konektitaj per interkonekto per Ethernet. Samtempe, la FS devus skali bone kaj facile kaj esti sendependa de apudaj sistemoj, t.e. esti fremdigita de vAIR en la formo de "nur stokejo".
Unua koncepto vAIR
Ni intence forlasis la uzon de pretaj malfermkodaj solvoj por organizi streĉitan stokadon (ceph, gluster, luster kaj similaj) favore al nia propra evoluo, ĉar ni jam havis multan projektan sperton kun ili. Kompreneble, ĉi tiuj solvoj mem estas bonegaj, kaj antaŭ ol labori pri Aerodisk, ni efektivigis pli ol unu integrigan projekton kun ili. Sed unu afero estas efektivigi specifan taskon por unu kliento, trejni personaron kaj, eble, aĉeti la subtenon de granda vendisto, kaj tute alia afero krei facile reprodukteblan produkton, kiu estos uzata por diversaj taskoj, kiujn ni, kiel vendisto, eble eĉ scias pri ni mem, ni ne faros. Por la dua celo, ekzistantaj malfermkodaj produktoj ne taŭgis por ni, do ni decidis mem krei distribuitan dosiersistemon.
Du jarojn poste, pluraj programistoj (kiuj kombinis laboron pri vAIR kun laboro sur la klasika Engine stokadsistemo) atingis certan rezulton.
Ĝis 2018, ni skribis simplan dosiersistemon kaj kompletigis ĝin per la necesa aparataro. La sistemo kombinis fizikajn (lokajn) diskojn de malsamaj serviloj en unu platan naĝejon per interna interkonekto kaj "tranĉis" ilin en virtualajn blokojn, tiam blokaparatoj kun ŝanĝiĝantaj gradoj da faŭltoleremo estis kreitaj de la virtualaj blokoj, sur kiuj virtualaj estis kreitaj. kaj efektivigita uzante la KVM-hiperviziulaŭtojn.
Ni ne tro ĝenis la nomon de la dosiersistemo kaj koncize nomis ĝin ARDFS (divenu, kion ĝi signifas))
Ĉi tiu prototipo aspektis bone (ne videble, kompreneble, ankoraŭ ne estis vida dezajno) kaj montris bonajn rezultojn laŭ rendimento kaj skalo. Post la unua reala rezulto, ni lanĉis ĉi tiun projekton, organizante plentaŭgan evoluan medion kaj apartan teamon, kiu okupiĝis nur pri vAIR.
Ĝuste en tiu tempo, la ĝenerala arkitekturo de la solvo maturiĝis, kiu ankoraŭ ne spertis gravajn ŝanĝojn.
Plonĝado en la dosiersistemon ARDFS
ARDFS estas la fundamento de vAIR, kiu disponigas distribuitan, mistoleran datumstokadon tra la tuta areto. Unu el (sed ne la solaj) karakterizaj trajtoj de ARDFS estas ke ĝi ne uzas iujn ajn kromajn diligentajn servilojn por metadatenoj kaj administrado. Ĉi tio estis origine konceptita por simpligi la agordon de la solvo kaj por ĝia fidindeco.
Stoka strukturo
Ene de ĉiuj nodoj de la areto, ARDFS organizas logikan naĝejon de ĉiu disponebla diskspaco. Gravas kompreni, ke naĝejo ankoraŭ ne estas datumoj aŭ formatita spaco, sed simple markado, t.e. Ĉiuj nodoj kun vAIR instalita, kiam aldonite al la areto, estas aŭtomate aldonitaj al la komuna ARDFS-naĝejo kaj diskresursoj aŭtomate iĝas dividitaj tra la tuta areto (kaj haveblaj por estonta datumstokado). Ĉi tiu aliro permesas vin aldoni kaj forigi nodojn sur la flugo sen grava efiko al la jam funkcianta sistemo. Tiuj. la sistemo estas tre facila por grimpi "en brikoj", aldonante aŭ forigante nodojn en la areto se necese.
Virtualaj diskoj (stokaj objektoj por virtualaj maŝinoj) estas aldonitaj aldone al la ARDFS-naĝejo, kiuj estas konstruitaj el virtualaj blokoj de 4 megabajtoj en grandeco. Virtualaj diskoj rekte stokas datumojn. La faŭltoleremo-skemo ankaŭ estas metita ĉe la virtuala disknivelo.
Kiel vi eble jam divenis, por erartoleremo de la disksubsistemo, ni ne uzas la koncepton RAID (Redundant array of independent Disks), sed uzas RAIN (Redundant array of independent Nodes). Tiuj. Faŭltoleremo estas mezurita, aŭtomatigita kaj administrita surbaze de la nodoj, ne la diskoj. Diskoj, kompreneble, ankaŭ estas stokadobjekto, ili, kiel ĉio alia, estas monitoritaj, vi povas plenumi ĉiujn normajn operaciojn kun ili, inkluzive de muntado de loka aparataro RAID, sed la areto funkcias specife sur nodoj.
En situacio kie vi vere volas RAID (ekzemple, scenaro kiu subtenas plurajn misfunkciadojn sur malgrandaj aretoj), nenio malhelpas vin uzi lokajn RAID-regilojn kaj konstrui streĉitan stokadon kaj PLUVA-arkitekturon supre. Ĉi tiu scenaro estas sufiĉe viva kaj estas subtenata de ni, do ni parolos pri ĝi en artikolo pri tipaj scenaroj por uzi vAIR.
Stokaj Faŭltoleremo-Skemoj
Povas ekzisti du faŭltoleremo-kabaloj por virtualaj diskoj en vAIR:
1) Reprodukta faktoro aŭ simple reproduktado - ĉi tiu metodo de toleremo de kulpoj estas tiel simpla kiel bastono kaj ŝnuro. Sinkrona reproduktado estas farita inter nodoj kun faktoro de 2 (2 kopioj per areto) aŭ 3 (3 kopioj, respektive). RF-2 permesas al virtuala disko elteni la fiaskon de unu nodo en la areto, sed "manĝas" duonon de la utila volumeno, kaj RF-3 eltenos la fiaskon de 2 nodoj en la areto, sed rezervas 2/3 de la. utila volumeno por siaj bezonoj. Ĉi tiu skemo estas tre simila al RAID-1, tio estas, virtuala disko agordita en RF-2 estas imuna al la fiasko de iu ajn nodo en la areto. En ĉi tiu kazo, ĉio estos bone kun la datumoj kaj eĉ la I/O ne ĉesos. Kiam la falinta nodo revenas al servo, komenciĝos aŭtomata reakiro/sinkronigo de datumoj.
Malsupre estas ekzemploj de la distribuado de RF-2 kaj RF-3-datenoj en normala reĝimo kaj en fiaskosituacio.
Ni havas virtualan maŝinon kun kapacito de 8MB da unikaj (utilaj) datumoj, kiu funkcias per 4 vAIR-nodoj. Estas klare, ke fakte estas malprobable, ke estos tiom malgranda volumo, sed por skemo, kiu reflektas la logikon de ARDFS-operacio, ĉi tiu ekzemplo estas la plej komprenebla. AB estas 4MB virtualaj blokoj enhavantaj unikajn virtualajn maŝinajn datumojn. RF-2 kreas du kopiojn de tiuj blokoj A1+A2 kaj B1+B2, respektive. Ĉi tiuj blokoj estas "metitaj" trans nodoj, evitante la intersekciĝon de la samaj datumoj sur la sama nodo, tio estas, kopio A1 ne situos sur la sama nodo kiel kopio A2. Same kun B1 kaj B2.
Se unu el la nodoj malsukcesas (ekzemple, nodo n-ro 3, kiu enhavas kopion de B1), ĉi tiu kopio estas aŭtomate aktivigita sur la nodo kie ekzistas neniu kopio de ĝia kopio (tio estas kopio de B2).
Tiel, la virtuala disko (kaj la VM, sekve) povas facile postvivi la fiaskon de unu nodo en la RF-2-skemo.
La reproduktadskemo, kvankam simpla kaj fidinda, suferas de la sama problemo kiel RAID1 - ne sufiĉe uzebla spaco.
2) Forviŝkodigo aŭ forviŝkodigo (ankaŭ konata kiel "redunda kodigo", "forviŝkodigo" aŭ "redunda kodo") ekzistas por solvi la supran problemon. EC estas redundskemo kiu disponigas altan datenhaveblecon kun pli malalta diskspaco supre kompare kun reproduktado. La funkcia principo de ĉi tiu mekanismo estas simila al RAID 5, 6, 6P.
Dum kodado, la EC-procezo dividas virtualan blokon (4MB defaŭlte) en plurajn pli malgrandajn "datumpecojn" depende de la EC-skemo (ekzemple, 2+1-skemo dividas ĉiun 4MB-blokon en 2 2MB-pecojn). Poste, ĉi tiu procezo generas "egalecaj pecoj" por la "datumaj partoj" kiuj ne estas pli grandaj ol unu el la antaŭe dividitaj partoj. Dum malkodado, EC generas la mankantajn pecojn legante la "pluvivajn" datumojn tra la tuta areto.
Ekzemple, virtuala disko kun 2 + 1 EC-skemo, efektivigita sur 4 clusternodoj, facile eltenos la fiaskon de unu nodo en la areto en la sama maniero kiel RF-2. En ĉi tiu kazo, la superkostoj estos pli malaltaj, precipe, la utila kapacita koeficiento por RF-2 estas 2, kaj por EC 2+1 ĝi estos 1,5.
Por priskribi ĝin pli simple, la esenco estas, ke la virtuala bloko estas dividita en 2-8 (kial de 2 ĝis 8, vidu sube) "pecoj", kaj por ĉi tiuj pecoj "pecoj" de egaleco de simila volumeno estas kalkulitaj.
Kiel rezulto, datumoj kaj egaleco estas egale distribuitaj tra ĉiuj nodoj de la areto. Samtempe, kiel kun reproduktado, ARDFS aŭtomate distribuas datumojn tra nodoj tiel, ke identaj datumoj (kopioj de datumoj kaj ilia egaleco) ne estu stokitaj sur la sama nodo, por forigi la ŝancon perdi datumojn pro tio. al la fakto, ke la datumoj kaj ilia egaleco subite finiĝos sur unu stokada nodo, kiu malsukcesas.
Malsupre estas ekzemplo, kun la sama 8 MB virtuala maŝino kaj 4 nodoj, sed kun EC 2+1-skemo.
Blokoj A kaj B estas dividitaj en du pecojn de 2 MB ĉiu (du ĉar 2+1), tio estas, A1+A2 kaj B1+B2. Male al kopio, A1 ne estas kopio de A2, ĝi estas virtuala bloko A, dividita en du partojn, la sama kun bloko B. Entute, ni ricevas du arojn de 4MB, ĉiu el kiuj enhavas du du-MB-pecojn. Poste, por ĉiu el ĉi tiuj aroj, egaleco estas kalkulita kun volumeno de ne pli ol unu peco (t.e. 2 MB), ni akiras pliajn + 2 pecojn de egaleco (AP kaj BP). Entute ni havas 4×2 datumojn + 2×2 egalecon.
Poste, la pecoj estas "metitaj" inter la nodoj tiel ke la datumoj ne intersekcas kun ilia egaleco. Tiuj. A1 kaj A2 ne estos sur la sama nodo kiel AP.
En la okazo de malsukceso de unu nodo (ekzemple, ankaŭ la tria), la falinta bloko B1 estos aŭtomate restarigita de la BP-egaleco, kiu estas konservita sur la nodo n-ro 2, kaj aktiviĝos sur la nodo kie ekzistas. neniu B-egaleco, t.e. peco de BP. En ĉi tiu ekzemplo, ĉi tio estas nodo n-ro 1
Mi certas, ke la leganto havas demandon:
"Ĉio, kion vi priskribis, estas delonge efektivigita kaj de konkurantoj kaj en liberkodaj solvoj, kio estas la diferenco inter via efektivigo de EC en ARDFS?"
Kaj tiam estos interesaj trajtoj de ARDFS.
Forigu kodigon kun fokuso sur fleksebleco
Komence, ni disponigis sufiĉe flekseblan EC X+Y-skemon, kie X estas egala al nombro de 2 ĝis 8, kaj Y estas egala al nombro de 1 ĝis 8, sed ĉiam malpli ol aŭ egala al X. Ĉi tiu skemo estas provizita. por fleksebleco. Pliigi la nombron da datenpecoj (X) en kiuj la virtuala bloko estas dividita permesas redukti superkostojn, tio estas, pliigi uzeblan spacon.
Pliigi la nombron da egalecaj pecoj (Y) pliigas la fidindecon de la virtuala disko. Ju pli granda la Y-valoro, des pli da nodoj en la areto povas malsukcesi. Kompreneble, pliigi la egalan volumon reduktas la kvanton de uzebla kapablo, sed ĉi tio estas prezo por pagi por fidindeco.
La dependeco de agado de EC-cirkvitoj estas preskaŭ rekta: ju pli da "pecoj", des pli malalta estas la agado; ĉi tie, kompreneble, necesas ekvilibra vido.
Ĉi tiu aliro permesas al administrantoj agordi streĉitan stokadon kun maksimuma fleksebleco. Ene de la ARDFS-poolo, vi povas uzi iujn ajn mistoleremajn skemojn kaj iliajn kombinaĵojn, kiuj, laŭ nia opinio, ankaŭ estas tre utila.
Malsupre estas tabelo komparanta plurajn (ne ĉiujn eblajn) RF- kaj EC-skemojn.
La tabelo montras, ke eĉ la plej "tery" kombinaĵo EC 8+7, kiu permesas la perdon de ĝis 7 nodoj en areto samtempe, "manĝas" malpli uzeblan spacon (1,875 kontraŭ 2) ol norma reproduktado, kaj protektas 7 fojojn pli bone. , kiu faras ĉi tiun protektan mekanismon, kvankam pli kompleksa, multe pli alloga en situacioj, kie necesas certigi maksimuman fidindecon en kondiĉoj de limigita diskospaco. Samtempe, vi devas kompreni, ke ĉiu "pluso" al X aŭ Y estos plia agado supre, do en la triangulo inter fidindeco, ŝparado kaj rendimento vi devas elekti tre zorge. Tial ni dediĉos apartan artikolon al forviŝado de kodigo.
Fidindeco kaj aŭtonomeco de la dosiersistemo
ARDFS funkcias loke sur ĉiuj nodoj de la areto kaj sinkronigas ilin uzante siajn proprajn rimedojn per diligentaj Eterretaj interfacoj. La grava punkto estas, ke ARDFS sendepende sinkronigas ne nur la datumojn, sed ankaŭ la metadatumojn rilatajn al stokado. Laborante pri ARDFS, ni samtempe studis kelkajn ekzistantajn solvojn kaj ni malkovris, ke multaj sinkronigas la dosiersistemon meta per ekstera distribuita DBMS, kiun ni uzas ankaŭ por sinkronigado, sed nur agordojn, ne FS-metadatenojn (pri ĉi tiu kaj aliaj rilataj subsistemoj. en la sekva artikolo).
Sinkronigi FS-metadatenojn uzante eksteran DBMS estas, kompreneble, funkcianta solvo, sed tiam la konsistenco de la datumoj stokitaj sur ARDFS dependus de la ekstera DBMS kaj ĝia konduto (kaj, sincere parolante, ĝi estas kaprica sinjorino), kiu en nia opinio estas malbona. Kial? Se la FS-metadatumoj difektiĝas, la FS-datumoj mem ankaŭ povas esti diritaj "adiaŭ", do ni decidis preni pli kompleksan sed fidindan vojon.
Ni mem faris la metadatuman sinkronigan subsistemon por ARDFS, kaj ĝi vivas tute sendepende de apudaj subsistemoj. Tiuj. neniu alia subsistemo povas korupti ARDFS-datenojn. Laŭ nia opinio, ĉi tio estas la plej fidinda kaj ĝusta maniero, sed la tempo diros ĉu tio efektive estas tiel. Krome, estas plia avantaĝo kun ĉi tiu aliro. ARDFS povas esti uzata sendepende de vAIR, same kiel streĉita stokado, kiun ni certe uzos en estontaj produktoj.
Kiel rezulto, disvolvante ARDFS, ni ricevis flekseblan kaj fidindan dosiersistemon, kiu donas elekton, kie vi povas ŝpari kapablo aŭ rezigni ĉion pri rendimento, aŭ fari ultra fidindan stokadon je racia kosto, sed reduktante agadon-postulojn.
Kune kun simpla licencadpolitiko kaj fleksebla livermodelo (rigardante antaŭen, vAIR estas licencita per nodo, kaj liverita aŭ kiel programaro aŭ kiel programarpakaĵo), tio ebligas al vi tre precize adapti la solvon al plej diversaj klientpostuloj kaj tiam facile konservu ĉi tiun ekvilibron.
Kiu bezonas ĉi tiun miraklon?
Unuflanke, ni povas diri, ke jam estas ludantoj sur la merkato, kiuj havas seriozajn solvojn en la kampo de hiperkonverĝo, kaj ĉi tie ni efektive iras. Ŝajnas, ke ĉi tiu deklaro estas vera, SED...
Aliflanke, kiam ni eliras en la kampojn kaj komunikas kun klientoj, ni kaj niaj partneroj vidas, ke ĉi tio tute ne estas la kazo. Estas multaj taskoj por hiperkonverĝo, en iuj lokoj homoj simple ne sciis, ke tiaj solvoj ekzistas, en aliaj ĝi ŝajnis multekosta, en aliaj estis malsukcesaj provoj de alternativaj solvoj, kaj en aliaj ili tute malpermesas aĉeti pro sankcioj. Ĝenerale, la kampo montriĝis neplugita, do ni iris levi virgan grundon))).
Kiam konserva sistemo estas pli bona ol GKS?
Dum ni laboras kun la merkato, ni ofte demandas, kiam estas pli bone uzi klasikan skemon kun stokaj sistemoj, kaj kiam uzi hiperkonverĝan? Multaj kompanioj produktantaj GCS (precipe tiuj, kiuj ne havas stokadsistemojn en sia biletujo) diras: "stoksistemoj malnoviĝas, nur hiperkonverĝaj!" Ĉi tio estas aŭdaca deklaro, sed ĝi ne tute reflektas la realon.
Verdire, la stokadmerkato ja moviĝas al hiperkonverĝo kaj similaj solvoj, sed ĉiam estas "sed".
Unue, datumcentroj kaj IT-infrastrukturoj konstruitaj laŭ la klasika skemo kun stokaj sistemoj ne povas esti facile rekonstruitaj, do la modernigo kaj kompletigo de tiaj infrastrukturoj ankoraŭ estas heredaĵo dum 5-7 jaroj.
Due, la infrastrukturo kiu estas nuntempe konstruita plejparte (signifas la Rusa Federacio) estas konstruita laŭ la klasika skemo uzante stoksistemojn, kaj ne ĉar homoj ne scias pri hiperkonverĝo, sed ĉar la hiperkonverĝo merkato estas nova, solvoj kaj normoj ankoraŭ ne estis establitaj, IT-uloj ankoraŭ ne estas trejnitaj, ili havas malmulte da sperto, sed ili bezonas konstrui datumcentrojn ĉi tie kaj nun. Kaj ĉi tiu tendenco daŭros ankoraŭ 3-5 jarojn (kaj poste alia heredaĵo, vidu punkton 1).
Trie, ekzistas pure teknika limigo en aldonaj malgrandaj prokrastoj de 2 milisekundoj per skribo (ekskludante la lokan kaŝmemoron, kompreneble), kiuj estas la kosto de distribuita stokado.
Nu, ni ne forgesu pri la uzo de grandaj fizikaj serviloj, kiuj amas vertikalan skalon de la disksubsistemo.
Estas multaj necesaj kaj popularaj taskoj kie stokadsistemoj kondutas pli bone ol GCS. Ĉi tie, kompreneble, tiuj fabrikantoj, kiuj ne havas stokadsistemojn en sia produkta biletujo, ne konsentos kun ni, sed ni pretas argumenti racie. Kompreneble, ni, kiel programistoj de ambaŭ produktoj, certe komparos stokadsistemojn kaj GCS en unu el niaj estontaj eldonaĵoj, kie ni klare pruvos, kio estas pli bona sub kiuj kondiĉoj.
Kaj kie hiperkonverĝaj solvoj funkcios pli bone ol stokaj sistemoj?
Surbaze de la supraj punktoj, tri evidentaj konkludoj povas esti tiritaj:
- Kie pliaj 2 milisekundoj da latenteco por registrado, kiu konstante okazas en iu ajn produkto (nun ni ne parolas pri sintezoj, nanosekundoj povas esti montritaj sur sintezoj), estas nekritikaj, hiperkonverĝa taŭgas.
- Kie la ŝarĝo de grandaj fizikaj serviloj povas esti igita multaj malgrandaj virtualaj kaj distribuita inter nodoj, hiperkonverĝo ankaŭ bone funkcios tie.
- Kie horizontala skalado estas pli alta prioritato ol vertikala skalado, GCS ankaŭ faros bone tie.
Kio estas ĉi tiuj solvoj?
- Ĉiuj normaj infrastrukturaj servoj (dosierujo, poŝto, EDMS, dosierserviloj, malgrandaj aŭ mezaj ERP kaj BI-sistemoj, ktp.). Ni nomas ĉi tion "ĝenerala komputado".
- La infrastrukturo de nubaj provizantoj, kie necesas rapide kaj normigita horizontale vastigi kaj facile "tranĉi" grandan nombron da virtualaj maŝinoj por klientoj.
- Virtuala labortabla infrastrukturo (VDI), kie multaj malgrandaj uzantaj virtualaj maŝinoj funkcias kaj kviete "flosas" ene de unuforma areto.
- Branĉaj retoj, kie ĉiu branĉo bezonas norman, mistolerantan, sed malmultekostan infrastrukturon de 15-20 virtualaj maŝinoj.
- Ajna distribuita komputado (ekzemple servoj de grandaj datumoj). Kie la ŝarĝo iras ne "profunde", sed "larĝe".
- Testmedioj kie pliaj malgrandaj prokrastoj estas akcepteblaj, sed ekzistas buĝetaj limigoj, ĉar ĉi tiuj estas testoj.
Nuntempe, estas por ĉi tiuj taskoj ke ni faris AERODISK vAIR kaj estas sur ili ke ni koncentriĝas (sukcese ĝis nun). Eble ĉi tio baldaŭ ŝanĝiĝos, ĉar... la mondo ne staras senmove.
Do…
Ĉi tio kompletigas la unuan parton de granda serio de artikoloj; en la sekva artikolo ni parolos pri la arkitekturo de la solvo kaj la uzataj komponantoj.
Ni bonvenigas demandojn, sugestojn kaj konstruajn disputojn.
fonto: www.habr.com