Salve, Habr lector. Hoc articulo seriem aperimus quae de systemate hyperconvergo AERODISK vAIR loquetur quem enucleavimus. In primo articulo omnia de omnibus voluimus dicere, sed ratio est implicata, sic elephas in partibus comedemus.
Fabulam committitur cum historia creationis systematis, intromittere in ARDFS systematis fasciculi, quod est fundamentum vAIR, et etiam pauca loqui de positione huius solutionis in mercatu Russico.
In futuris articulis fusius loquemur de diversis componentibus architecturae (botrus, hypervisor, librarius onus, ratio vigilantia, etc.), processus configurationis, quaestiones licentiae excitantes, singulatim monstrant ruinas et, sane scribe de onere probationis ac inspectione. Articulum separatum etiam in versione communitatis vair ponemus.
Estne Aerodiscus fabulam de systematibus repono? Aut cur in primo loco hyperconvergence incipimus facere?
Initio, idea nostra creare hyperconvergence alicubi circa MMX ad nos venit. Eo tempore in foro nec Aerodiscus nec similes solutiones (rationes hyperconversales commerciales) in foro factae sunt. Nostrum negotium talis erat: ex praeposito ministrantium cum orbis locali, per protocollum Ethernet coniunctum, necesse erat repositam extensam creare et virtualis machinis ac retiaculis programmatis creare. Haec omnia perficienda erant sine systematibus repono (quia nulla erat pecunia simpliciter pro rationum repositione et eius ferramentis, et nondum inveniebamus systemata nostra reposita).
Multae solutiones fontium apertae conati sumus ac tandem hanc quaestionem solvimus, sed solutio valde implicata et difficilis iteratio fuit. Praeterea haec solutio in praedicamento βAn operatur? Noli tangere! Itaque, illo problemate soluto, notionem ulterius enucleavimus mutandi exitum laboris nostri in plenam mobilitatem.
Post illam rem, ab hac idea discesserunt, sed adhuc sentiebamus hoc problema omnino esse solubile, et beneficia talis solutionis magis quam manifesta erant. Postmodum dimissi HCI producta societatum exterarum hoc modo sensum confirmaverunt.
Itaque, medio-2016, ad hoc negotium ut partem plenam curum productum creandi reddidimus. Tunc nondum aliquas relationes cum obsidibus habuimus, ergo pro nostra progressione emere debebamus non magnas pecunias. Coactis servitoribus et permutationibus in Avito adhibitis ad negotia descendimus.
Praecipuum initiale munus erat nostrum proprium, licet simplex, sed proprium fasciculi systematis creare, quod automatice et aequaliter notitias distribuere potuit in forma stipitiorum virtualium in numero nodis botri, quae per Ethernet connectuntur. Eodem tempore, FS bene ac facile scandere debet et ab adjacentibus systematibus independentes esse, i.e. VAIR abalienetur in forma "tantum facilitas repono."
Primo conceptu vair
Consulto usum solutionum solutionum fontium patentium promptarum derelinquimus ad reponendum ordinandum protensum (ceph, glomeratio, nitor et similia) in favorem nostrae evolutionis, cum iam multam experientiam apud eos habuimus. Utique hae solutiones ipsae optimae sunt, et antequam in Aerodisk laboramus, plus quam unam integrationem cum illis programma perficiemus. Sed aliud est ad efficiendum munus specificum unius emptoris, baculi instituendi et fortasse subsidia magni venditoris emam, et aliud ad rem faciliter replicandam, quae variis officiis utendum est, quae nos, ut. venditorem, etiam de nobis nolumus. Ad alterum propositum, fons aperta producta non opportuna nobis fuit, ut nosmetipsos systematis fasciculi distributos creare decrevimus.
Duobus annis post complures tincidunt (qui opus in VAIR coniunxerunt cum labore in systematis repositionis classicae Engine) effectum quendam consecuti sunt.
Per MMXVIII, simplex systematis fasciculi scripseram et cum necessariis odio supplevimus. Systema physicum (locorum) orbis a diversis ministris in unum plana piscinam per interna connexum et "sectum" eas in stipites virtuales conglobavit, deinde machinae clausulae variis gradibus culpae tolerantiae e stipibus virtualibus creati sunt, in quibus virtuales creati sunt. KVM hypervisor carros usus et supplicium.
Nomine tabellae systematis nimis molesti sumus et succincte eam ARDFS appellavimus (conicere quid stat))
Hoc prototypum bonum spectavit (non uisum, utique, nondum consilium visuale) ostenditque bonos eventus secundum perficiendi et scandendi. Post primum verum exitum, consilium hoc in motu constituimus, ordinantes ambitum evolutionis plenam flexam et turmam separatam, quae solum vAIR tractavit.
Eo tempore architectura generalis solutionis coaluerat, quae maiores mutationes nondum subiit.
Tribuo in ARDFS lima ratio
ARDFS fundamentum est vAIR, quod per totum botrum repositionis notae vitiosae distributae praebet. Una (sed non sola) notae propriae ARDFS est quod nullis additis ministris dedicatis pro metadata et administratione non utitur. Hoc initio conceptum est ad simpliciorem conformationem solutionis eiusque firmitatis.
Repono compages
Intra omnes nodi botri, ARDFS piscinam logicam ab omnibus in promptu orbis spatio ordinat. Refert ad intelligendum piscinam nondum spatio dato vel formato, sed notam simpliciter, i.e. Nodi quivis cum vAIR inauguratus, botro addito, automatice ad ARDFS piscinae et discri opes communicatae sponte factae per totum botrum communicatae fiunt (et praesto sunt futurae notitiae repositionis). Hic aditus permittit ut nodos addere et removere in musca sine gravi impulsu in systematis iam currentis. Illae. systema facillime scandere "in lateribus", addendo vel removendo nodos in botro, si necesse est.
Disci virtualis (repono objecta pro machinis virtualibus) additae sunt super piscinam ARDFS quae aedificata sunt e clausuris virtualis 4 megabytarum in magnitudine. Virtual disks directe reponunt data. Vitium tolerantiae schema etiam in gradu virtualis orbis ponitur.
Ut iam coniectare poteras, propter culpam tolerantiae subsystem orbis, notione RAID (Redundantis Disks independentium ordinata), sed usu imbribus (procuratio Nodis independentium Redundantis). Illae. Culpa tolerantia mensuratur, automated, et in nodi fundata, non orbis administratur. Orbis, sane, etiam objectum reponendi sunt, hi, sicut omnia, monitores sunt, omnes operationes vexillum cum illis praestare potes, etiam localis ferramentis INCURSUS congregans, sed botrus specialiter in nodis operatur.
In statu ubi re vera vis INCURSIO (exempli gratia, missionis quae plures defectiones in parvis racemis sustinet), nihil obstat quominus moderatores locales INCURSUS utantur, et repositiones extentae et architectura imbrium superposita aedificent. Haec missione satis vivunt et nobis suffragatur, sic in articulo de missionibus typicis utendo vAIR loquemur.
At Grand Tolerantia Consilia
Duo culpae tolerantiae technae possunt esse pro orbis virtualis in vair:
1) Replicatio factor vel replicatio simpliciter - modus hic culpae tolerantiae tam simplex est quam baculus et funis. Replicatio synchrona fit inter nodos cum factore 2(2 exemplarium per glomerorum) vel 3 (3 exemplaria respective). RF-2 rectum disci permittit ut defectum unius nodi in botro sustineat, sed dimidium voluminis utilissimi "comedit", et RF-3 defectum 2 nodi in botro sustinebit, sed 2/3 subsidia volumen utile suis necessitatibus. Hoc schema valde simile est cum RAID-1, hoc est, virtualis disci in RF-2 conformatus, defectui unius nodi in botro resistit. In hoc casu omnia denique data erunt nec non I/O cessabunt. Cum nodi lapsi ad servitium redeunt, datae recuperationis automatice synchronisation incipient.
Infra sunt exempla distributionis RF-2 et RF-3 datae in modo normali et in situ defectu.
Rectum machinam habemus cum capacitate notitiarum 8MB singularium (utilis) quae in 4 vAIR nodis currit. Patet in re veri simile esse tam parvum volumen futurum esse, sed ad propositum, quod logicam operationis ARDFS reflectit, hoc exemplum est comprehensibile. AB sunt 4MB caudices virtuales quibus notitia apparatus singularis virtualis. RF-2 duos horum clausorum exemplaria A1+A2 et B1+B2, respective. Hae caudices trans nodos "expositae" sunt, intersectionem notitiarum eiusdem nodi vitantes, hoc est, exemplum A1 in eodem nodi exemplari A2 non collocari. Idem cum B1 et B2.
Si una e nodi desit (exempli gratia nodi No. 3, quae exemplum B1 continet), hoc exemplum ipso facto in nodo reducitur ubi nullum exemplar eius exemplar est (id est exemplar B2).
Sic disci virtualis (et sic VM) facile superesse potest defectum unius nodi in schemate RF-2.
Replicatio schema, dum simplex et certa, laborat ab eodem problemate cum RAID1 - spatio non satis utilis.
2) coding rasura vel in litura coding (etiam ut "coding redundans", "coding rasura" vel "codex redundantia") est solvere quaestionem supra. EC nugatio est nugatio quae altam datam promptitudinem praebet cum spatio orbis inferioris supra caput ad replicationem comparatum. Principium operativum hujus mechanismi simile est INCURSIO 5, 6, 6P.
Cum modum translitterandi, EC processus virtualem scandalum (per 4MB defaltam) in plura minora "data chunks" dividit secundum schema EC (exempli gratia, propositum 2+1 quemlibet 4MB scandalum in 2 2MB chunks dividit). Deinde, hic processus "paritatem chunks" pro "data chunkis" generat, quae nulla maior est quam una ex partibus antea divisis. Cum decoding, EC chunks absentis gignit, notitias "superstes" per totum botrum legendo gignit.
Exempli gratia, orbis virtualis cum 2+1 EC schemate, in 4 nodis botri instructo, facile sustinebit defectum unius nodi in botro eodem modo ac RF-2. Hoc in casu, gratuita supra caput inferius erit, in specie, facultas utilis coefficientis pro RF-2 est 2, et pro EC 2+1 1,5 erit.
Ut simplicius dicam, essentia est quod virtualis stipes dividitur in 2-8 (cur ab 2 ad 8, vide infra) "fragmenta", et pro his fragmentis "fragmenta" paritatis similis voluminis computantur.
Quam ob rem data et pari aequaliter per omnes nodos botri distribuuntur. Simul, sicut cum replicatione, ARDFS data trans nodi data automatice distribuit ita ut ne eadem notitia (copia notitiarum et parium) eodem nodo recondatur, ad tollendam occasionem amissionis notitiae debitae. ad hoc quod notitia eorum et parium in una nodi reposita subito desinunt quae deficit.
Infra exemplum est, cum eadem machina 8 MB virtualis et 4 nodi, sed cum schemate EC 2+1.
Caudices A et B dividuntur in partes 2 MB utriusque (duo ob 2+1), id est, A1+A2, B1+B2. Dissimilis imago, A1 exemplar A2 non est, est virtualis stipes A, in duas partes divisus, idem cum scandalo B. In summa, binas 4MB accipimus, quarum quaelibet duo-MB frusta continet. Deinde, pro unaquaque harum copia, pari numero non plus quam una (i.e. 2 MB) computatur, additamenta pari (AP et BP) obtinemus. In summa habemus 2Γ4 data + 2Γ2 pari.
Deinde inter nodos frusta sunt "posita" ut cum pari notitia non secat. Illae. A1 & A2 non erunt eadem node qua AP.
In eventu unius nodi defectus (exempli gratia etiam tertia), stipes lapsus B1 ipso facto restituetur ex pari BP, quae in nodo No. 2 reponitur, et in nodi ubi est reducitur. no-B pari, i.e. nummum, BP. In hoc exemplo, haec nodi est 1 . No
Pro certo habeo lector quaestionem:
"Omnia, quae descripsisti, tamdiu a competitoribus quam in solutionibus apertis effecta sunt, quid interest inter tuam exsecutionem EC in ARDFS?"
Et tunc erit interesting lineamenta ARDFS.
Litura coding cum focus in flexibilitate
Primum schema satis flexibile EC X+Y praebuimus, ubi X numerus aequalis est ab 2 ad 8, et Y aequalis est numero ab 1 ad 8, sed semper minor quam vel aequalis X. Haec ratio cauetur. ad mollitiem. Numerum notitiarum fragmentorum (X) in quos virtualis stipes divisus est, permittit reducere supra caput sumptus, id est, spatium utibile augere.
Numerum chunks pari (Y) auget constantiam orbis virtualis. Quo maior Y valorem, eo plures nodi in botro deficere possunt. Scilicet, augendo volumine pari quantitatem facultatis utibilis minuit, sed hoc pretium pro firmitate solvendum est.
Dependentia actionis in eC ambitus propemodum directa est: plus "pieces", inferior effectus, hic utique necessaria est sententia librata.
Accessus permittit administratores ut repositiones extensae configurarent maxima cum flexibilitate. Intra ARDFS piscinam nulla culpa uti potes tolerantiae machinas eorumque compositiones, quae, ut nostra fert opinio, utilissima est.
Infra tabula plures (non omnes possibile) RF et EC technas comparans.
Mensa ostendit compositionem ec 8+7 vel maxime "terry", quae simul permittit detrimentum usque ad 7 nodos in botro, minus utibile spatium comedat (1,875 versus 2) quam replicatio vexillum, et tuetur 7 vicibus melius. quae mechanismum, quamvis magis implicatum, multo pulchrius in condicionibus, ubi necesse est ut maximam firmitatem habeant in condicionibus spatii orbis circumscripti. Eodem tempore, oportet intelligere quod omne "plus" ad X vel Y erit additus effectus supra caput, sic in triangulo inter fidem, peculi et effectus diligentissime eligere debes. Qua de causa separatum articulum in litura coding recognoscendo vacabimus.
Reliability et autonomia systematis tabellae
ARDFS in omnes nodos botri localiter decurrit et eos conformat suis mediis utentes per interfaces Aer dedicatas. Praecipuum illud est quod ARDFS independenter non solum notitias, sed etiam metadata ad repositas congruere potest. Dum in ARDFS laborantes, simul nonnullas solutiones exsistentium investigavimus et invenimus multas meta systematis fasciculi synchronizare utentes externa DBMS distributa, quibus etiam utimur synchronisationi, sed tantum conformationibus, non FS metadata (de hoc et aliis subsystematis affinibus. in sequenti articulo).
Synchronising FS metadata utens externa DBMS est, utique solutione laborantis, sed tunc constantia notitiarum in ARDFS conditarum dependet ab externo DBMS et eius moribus (et, libere loquendo, domina levis est), quae in opinio nostra mala est. Quare? Si metadata FS laeditur, ipsa notitia FS etiam dici potest "vale", ut viam magis implicatam sed certam capere decrevimus.
Metadatam synchronisationem subsystem pro ARDFS ipsi fecimus et sine subsystematibus adiacentibus omnino vivit. Illae. nulla alia subsystem notitia ARDFS corrumpere potest. Opinione nostra haec est verissima et rectissima via, sed tempus indicabit an ita se habeat. Accedit praeterea utilitas cum hac accessione. ARDFS independenter a vAIR adhiberi possunt, sicut repositionis extentae, quibus in futuris productis certe utemur.
Quam ob rem, ARDFS evolvendo, flexibilem et certarum tabularum systema recepimus, quae eligit ubi potes salvare facultatem vel omnia in agendis dare, vel ultra certas tabulas ad rationabiliter sumptus facere, sed exigentias faciendis reducere.
Una cum simplici licentiae consilio ac flexibili traditione exemplar (prospiciens, vAIR nodo licentiatus est, et vel ut programmator vel ut sarcina software liberatus est), hoc tibi permittit ut valde pressius sartor solutionem ad varietatem usorum emptorum ac tunc facile hanc aequilibrium conservabo.
Quis hoc miraculo eget?
Ex altera parte, dicere possumus iam esse lusores in foro, qui graves solutiones habent in campo hyperconvergentiae, et hoc est ubi actu tendimus. Videtur quod haec propositio vera sit, SED.
Contra, cum in agros egredimur et cum clientibus communicamus, nos et socii nostri hoc minime casui esse vident. Hyperconvergentiae opera multa sunt, in quibusdam locis tales solutiones non sciverunt esse, in aliis pretiosae videbantur, in aliis non succedere tentamenta solutionum alternarum, in aliis sanctionibus debitas emere prohibent. In universum ager inaratus evasit, sic nos ad virgineum solium attollere))).
Quando est melius quam GCS ratio repono?
Cum in foro laboramus, saepe quaesivimus quando melius est ut schema classicum cum systematibus repono, et quando hyperconvergent? Multae societates quae GCS gignunt (praesertim quae in librario suo systemata non habent) dicunt: "Repono systemata obsoleta sunt, tantum hyperconvergiae sunt!" Audax haec enuntiatio est, sed rem non omnino reflectit.
Revera, mercatus repono in hyperconvergentiam et solutiones similes quidem movetur, sed semper est "sed".
Uno modo, data centra et IT infrastructurae secundum ordinem classicum cum systematibus repositionibus constructae, facile reaedificari non possunt, ideo modernisatio et peractio talium infrastructurarum per 5-7 annos adhuc legatum est.
Secundo, infrastructura quae nunc plerumque aedificatur (id est Foederatio Russica) secundum systema classicum systematis repositionis utens, non quia homines de hyperconvergence nesciunt, sed quia hyperconvergenceum mercatum novum, solutiones ac signa nondum confirmata sunt, IT homines nondum exercitati sunt, parvam experientiam habent, sed centra hic et nunc aedificare indigent. Et haec inclinatio durabit ad aliud 3-5 annos (et deinde aliud legatum, vide punctum 1).
Tertio, est limitatio mere technica in accessionibus parvis morarum 2 millium secundorum per scribe (exclusis sane cache localis), quae sunt sumptus repositionis distributae.
Bene, ne obliviscamur de usu magnarum ministrantium physicarum quae amant verticalem scandentem orbis subsystem.
Multa sunt necessaria et popularia officia in quibus systemata repono melius quam GCS faciunt. Hic nimirum artifices illi, qui tabulas repositas in suo producto librario non habent, nobiscum non consentiunt, sed rationabiliter disputare parati sumus. Utique nos, ut tincidunt utriusque producti, certa rationum repositionis et GCS in una nostrae publicationis futurae comparabimus, ubi quid melius sub quibus conditionibus clare demonstrabimus.
Et ubi hyperconvergae solutiones melius operantur quam systemata repono?
Ex punctis superioribus tres conclusiones evidentes sumi possunt;
- Ubi additamentum 2 millium secundorum latency pro memoria, quod constanter occurrit in omni producto (nunc non loquimur de syntheticis, nanoseconds ex syntheticis ostendi potest), sunt incritica, hyperconvergens apta est.
- Ubi onus e magnis corporis ministris in plures parvas virtuales verti potest et inter nodos distribui, hyperconvergentia etiam ibi bene laborabit.
- Ubi scalis horizontalis altior est prioritate quam scalis verticalibus, GCS multam etiam ibi faciet.
Quid sunt hae solutiones?
- Omnia signa infrastructura officia (servitium directivum, epistularum, EDMS, fasciculi ministrantium, parvae vel mediae ERP et BI systemata, etc.). Hanc "computationem generalem" vocamus.
- Substructurae nubis provisores, ubi necesse est cito et normatum horizontaliter dilatare et facile "secare" magnum numerum machinorum virtualium clientium.
- Rectum desktop infrastructurae (VDI), ubi multae parvae user virtualis machinae currunt et quiete intra botrum uniforme "natat".
- Retia ramus, ubi quisque ramus vexillum eget, mendum tolerat, sed infrastructurae 15-20 virtualium machinis vilia sunt.
- Quaelibet computatio distributa (magna notitia muneris, exempli gratia). Ubi onus non Β« in profundum Β», sed Β« in latitudinem Β» it.
- Test ambitus ubi additae parvae morae placent, sed restrictiones fiscales sunt, quia hae sunt probationes.
In momento, ad haec opera nos AERODISK vAIR fecerimus et in illis sumus (feliciter hucusque). Fortasse hoc cito mutabitur, quia... mundus non stat.
Ita ...
Hanc primam partem absolvit magnae seriei articulorum, in sequenti articulo loquemur de solutione architecturae et partium adhibitarum.
Interrogationes, suggestiones et controversias utiles suscipimus.
Source: www.habr.com