Unus ex iuvenibus scaenicis in foro ad calamitatem solutionis Recuperationis Hystax est, satus a 2016 Russicus. Cum locus calamitatis recuperationis valde popularis est et mercatus est maxime competitive, initium migrationis inter diversas nubes substructiones intendere statuit. Productum, quod permittit te ad nubem migrationem simplicem et velox disponere, valde utilis esset etiam pro clientibus Onlantae - usoribus. . Id est quomodo Hystax cognoui et facultates eius probare coepi. Dicam quid in hoc articulo factum sit.
Praecipuum notae Hystax est ampla eius functionis ad sustentandas varias virtualizationis suggestas, hospites systemata operantem et operas nubilum, quae sinit transferre opera tua alicunde, alicubi.
Hoc permittit ut non solum DR solutiones ad augendam culpae tolerantiae officia, sed etiam cito ac mollius migret opes inter diversas sites et hyperscalores, ut peculiorum sumptus augeantur et optimam solutionem ad certum ministerium dato momento eligat. Praeter suggesta in tabula inscripta, societas etiam active cooperatur cum provisoribus Russiae nubis: Yandex.Cloud, CROC Cloud Services, Mail.ru et multi alii. Notatu etiam dignum est quod anno 2020 societas R&D centrum in Skolkovo sita aperuit.
Electio unius solutionis per magnum numerum lusorum in foro indicat bonum Morbi cursus sapien et magna applicabilitas producti, quod in usu probare decrevimus.
Itaque, negotium testium nostrum migrationis ex VMware situs et machinis physicis ad situm provisoris consistet, etiam ab VMware tractatum. Ita multae solutiones sunt quae talem migrationem praestare possunt, sed Hystax consideramus instrumentum universale et migrationem in omnibus possibilibus combinationibus probatum munus univocum est simpliciter. Et nubes Oncloud.ru specie in VMware aedificata est, ita hoc suggestum ut scopum magis nobis consulit. Deinde principale principium operationis describemus, quod plerumque a pulpito est, et VMware ex quavis parte per suggestum ab alio venditore restitui potest.
Primus gradus est Hystacem Acura explicandi, quae est imperium tabulae systematis.
Explicat ex template. Horum autem causa in nostro casu minus recte erat et loco commendatorum 8CPU, 16Gb cum dimidia parte explicabatur. Ergo meminisse debes ea mutare, alioquin continens infrastructuram intra VM, super qua omnia construuntur, simpliciter non incipiet, et porta inaccessibilis erit. IN' Facultates requisitae singillatim describuntur, ac portus omnium partium systematis.
Difficultates quoque IP oratio per formulam positae erant, sic eam a console mutavimus. Postea, ad interface admin adire potes et configurationem initialem magum absolvere.
Endpoint - IP vel FQDN nostri vCenter.
Login et Password - hoc patet.
Scopum ESXi hostname est unum ex exercitibus in botro nostro ad quod replicatio peragetur.
Scopus notariorum unus est e notariis in botro nostro cui replicatio peragetur.
Hystax Acura Control Panel Public IP β inscriptione ubi praesto erit imperium panel.
Parum explicatio requiritur circa exercitum et datastoris. Ita est quod replicatio Hystax operatur in gradu militiae et datastoris. Deinde dicam quomodo exercitum et datorum mutare possis colonum, sed quaestio alia est. Hystax lacus resource laborantibus non favet, i.e. Replica semper ad radicem botri (tempore huius materiae scribendae, guys ex Hystax versionem renovatam dimiserunt, ubi celeriter plumam meam postulationem ad subsidia subsidiorum lacunis compleverunt). vCloud Director non valet, i.e. si, ut in casu meo, tenens iura non habet ad totum botrum, sed solum ad certae subsidii piscinam, et accessum dabimus ad Hystacem, tunc poterit libere replicare et hos vms immittere, sed faciet. eas in infrastructura VMware videre non poteris, ad quas aditus habet et proinde machinas virtuales ulterius administrat. Botrus administratorem necessarium est ut VM ad piscinam subsidii desideratam moveat vel in vCloud Directorem importet.
Cur tantopere de his pono? Quia, quatenus conceptum producti intelligo, emptorem migrationem ullam vel DR utens in tabula Acura, sine instrumento esse poterit. Sed hactenus, subsidium VMware paulo post est in gradu subsidii OpenStack, ubi similes machinae iam effectae sunt.
Sed ad instruere redeamus. Imprimis, post primam tabulae paroemiam, primum in nostro systemate tenentem creare opus est.
Omnes hic campi patent, tantum tibi dicam de agro nubilo. Iam habemus "default" nubem quam in initiali configuratione creavimus. Sed si velimus unumquemque colonum in proprio datastore ponere et in sua piscina subsidia, hoc efficere possumus, ut singulas nubes pro singulis clientibus nostris efficiant.
In forma ad novam nubem addendi, easdem parametris exprimimus ac in initiali configuratione (etiam eodem exercitu uti possumus), datastoras ad certum emptorem requisitum indicant, et nunc in parametris additis singulas facultates debitas definire possumus. stagnum {"resource_pool" : "your_POOL_NAME"}
Ut notatum est, in forma tenentis creationis nihil est de destinatione resource aut quotas ulla - nulla est hujus in systemate. Impossibile est colonum finire numero replicationum simultanearum, numero machinis replicationis, vel quibuscunque aliis parametris. Hunc igitur primum tenente creavimus. Nunc non est omnino logica, sed res facienda - installing Cloud agent. Consentaneum est, quia agens in pagina certae emptoris recepta est.
Simul, non ligatur tenenti creato, et omnes nostri clientes operabuntur per illum (vel per plures, si eas explicabimus). Una agentis 10 sessiones simultaneas sustinet. Una machina una sessione numeratur. Non refert quot orbis habet. Ad date, nulla est mechanismus ad agentia in ipsa Acura sub VMware scandendis. Unum momentum est ingratum - facultas non habemus "dispositionem" huius agentis ex tabula Acura spectare ad concludendum utrum plus explicandum sit an satis sit hodierna institutione. Quam ob rem stare placet;
Proximus accedendi gradus ad emptorem nostrum portae rationem creare est (et primum munus quod huic usori applicabitur).
Lorem nunc porta independenter uti potest. Omne quod opus est facere, procuratores portae ex parte extrahunt et in latere suo instituunt. Tria genera agentium sunt: ββLinux, Fenestra et VMware.
Duo prima in physicis vel in machinis virtualis in quolibet hypervisore praeter VMware instituuntur. Nihil additicium configurare opus est, agens receptatur et iam scit ubi pulset, et littera minuto vehiculo in tabula Acura patebit. Cum agente VMware res paulo magis implicata est. Problema est agens pro VMware etiam e portali iam parata et necessariae figurae continente deponi. Sed praeter cognitionem nostram Acura portae, agens VMware etiam scire debet de systemate virtualizatione in quo explicabitur.
Profecto ratio postulabit ut haec notitia nobis praebeatur cum primum agente VMware download. Quaestio est quod nostra aetate universalis amoris securitatis, non omnes indicare volent eorum tesseram admin in portali alieno, quod satis intellegibile est. Ab intus, post instruere, agens ullo modo configurari non potest (modo retis occasus mutare potes). Hic difficultates praevideo cum maxime cautis clientibus.
Itaque, procuratoribus installatis, redire ad tabulam Acura possumus et omnes currus videre.
Cum aliquot dies iam systema laboravi, in diversis civitatibus carros habeo. Habeo omnes in Default coetus, sed separatos circulos creare potest et ad eos cars transferre prout opus est. Hoc nihil obstat - tantum propositio logica notitiarum eorumque aggregatio ad laborem commodiorem. Primum ac maximum opus est post migrationem committitur processus. Hoc facere possumus sive manually sive cedulam instituendo, in mole pro omnibus simul machinis inclusis.
Admoneam te Hystacem productum pro migratione positum esse. Quare non mirum est quod machinas nostras replicatas ad currendum nobis consilium DR creare necesse est. Consilium de machinis quae in statu Synced iam sunt fieri potest. Tam pro una specie VM quam pro omnibus simul machinis generare potes.
Propositum parametrorum cum consilium generans DR differet secundum infrastructuram ad quam migrabis. Minimum ambitus parametri ad VMware environment. Re-IP pro machinis etiam non valet. Qua de re quaerimus in his punctis: in descriptione VM, "subnet" parameter: "VMNetwork", ubi ligamus VM ad certam retis in botro. Ordo - pertinet cum plures VMs migrantes, determinat ordinem quo emittuntur. Sapor - configurationem VM describit, hoc casu β 1CPU, 2GB RAM. In sectione subnetm definimus "subnet": "VMNetwork" cum VMware "VM Network" coniungi.
Cum DR consilium creando, nulla via ad "divulgationem" orbis per diversos datastores. In eodem datastore locabuntur quae huic clienti nube definita sunt, et si discos diversorum generum habes, hoc potest aliquas difficultates cum machina incipiens, et post VM ab Hystace incipiens et "separare", erit etiam. migrationem orbis separati ad datastores requisiti requirunt. Tunc omnia facienda sunt, nostrum DR consilium deducunt et carros nostros exspectant ut surgant. Processus conversionis P2V/V2V etiam operam dat. In maxima mea machina test, 100GB cum tribus orbis disci, maximum 10 minutarum cepit.
Post haec, cursus VM, officia in eo, constantiam datarum coerceas, et alia compescere debeas.
Deinde habemus duas vias:
- Delere β currentem delere DR consilium. Haec actio solum cursus VM claudit. Replicae istae nusquam eunt.
- Abducere - rescindere currus replicatur ab Acura, i.e. migrationis actu perficere processus.
Pros solutionis:
- otium institutionis et configurationis tam a cliente quam a provisore;
- ease migrationem erigendi, DR consilium creandi et replicas deducendi;
- subsidia et tincidunt satis cito respondent quaestionibus inventis et eis utentes suggestum vel agentis updates figunt.
ΠΠΈΠ½ΡΡΡ
- Sufficiat Vmware firmamentum.
- Absentia alicujus quotas tenentibus a suggestu.
Etiam Request Feature, quam submisimus venditori, compilavit;
- usus vigilantia et instruere ab Acura administratione consolatoriae pro Cloud agentium;
- promptuarium quoius pro tenentibus;
- facultatem circumscribere numerum replicationum simultanearum et velocitatem pro unoquoque tenente;
- VMware vCloud Director subsidium;
- support for resource lacus.
- facultas configurandi VMware procuratorem ab ipso agente, sine documentorum infrastructura clientis in tabula Acura intrantis;
- "visualization" processus startup VM cum consilio DR currit.
Sola res, quae me magnae reprehensionis effecit, documenta sunt. Non vere amo "peculas nigras" et malo cum documenta explicata quomodo intus opus sit. Et si pro AWS et OpenStack productum descriptum est plus minusve, pro VMware exigua documenta sunt.
Instructio est Guide quod tabulae Acurae solum describit instruere, et verbum de facto Cloud etiam opus non est. Plena copia productorum specificationum est, quae bona est. Documentum est quod "ab initio ad metam" utens AWS et OpenStack exemplum describit (quamvis mihi magis placet tabellarium blogum), et est minima scientia Base.
In genere, haec forma documentorum non plane est, quam soleo, dicere, a maioribus mercatoribus, ideoque non plane commodus sum. Eodem tempore numquam responsa de aliquibus nuances inveni quomodo systema "intra" in hoc documento operatur - multae interrogationes technicae subsidii declarandae erant, et hoc plane moratus est processus explicandi statis et agendi. probatio.
Summatim dicere possum generatim me productum et accessum ad negotium societatis probavisse. Ita defectus sunt, vere critica defectus functionis est (in nexu cum VMware). Patet, ante omnia, adhuc turba in nubibus publicis versari, praesertim AWS, idque satis erit aliquot. Tam simplex et opportunum productum habens hodie, cum multae turmae multi- nubem consiliorum eligunt, magni momenti est. Considerans multo minore pretio competitoribus comparati, hoc productum maxime venustum facit.
Quaerimus Suspendisse . Forsitan est tibi?
Source: www.habr.com