Salvete omnes. Hic articulus scriptus est iis qui adhuc haerent inter eligendas machinas virtualizationis postquam legunt articulos ut "Proxmox instituimus et omnia optima sunt, sex anni operationis sine ulla mora." Sed postquam solutionem inclusam instituisti, miraris quomodo res hic illic modificare ut monitorium intuitivum reddas et copias reservatas modereris... Tum tempus advenit et intellegis te aliquid functionalius velle, aut omnia intra systema tuum magis intelligibilia reddere velle, non arcam nigram, aut aliquid plus quam hypervisorem et acervum machinarum virtualum uti velle. Hic articulus aliquas reflexiones et exempla practica praebebit, fundata in machina Opennebula—eam elegi quia non multas opes consumit et eius architectura non tam complexa est.
Itaque, ut videmus, multi nubium provisores cum KVM laborant et externa systemata ad machinarum administrationem creant. Patet magnos provisores hospitii propria systemata ad infrastructuram nubium scribere, ut YANDEX, exempli gratia. Quidam OpenStack utuntur et systemata in eo fundata creant—SELECTEL, MAIL.RU. Sed si proprium apparatum et parvum peritorum gregem habes, tum plerumque aliquid iam paratum eligis—VMWARE, HYPER-V. Sunt licentiae gratuitae et solutae, sed non de hoc nunc agitur. De studiosis loquamur—iis qui non timent proponere et aliquid novi experiri, quamvis societatis clara nuntia ut "Quis hoc post discessum tuum curabit?" vel "Vere hoc in productione evolvemus? Formidum." Sed initio has solutiones in experimento uti potes, et si omnibus placent, ulteriorem evolutionem et usum in ambitus gravioribus considerare potes.
Etiam hic est nexus ad relationem ab participante activo in evolutione huius suggestus.
Hic articulus fortasse nonnullas informationes superfluas continet, quae iam peritis artificibus manifestae sunt. Interdum, non omnia tractabo, cum similia mandata et descriptiones in interreti praesto sint. Haec mea sola experientia cum hac suggestu est. Spero utentes activos in commentariis interventurum esse de iis quae emendari potuerunt et de quibuslibet erroribus quos commisi. Haec omnia in apparatu domestico facta sunt, tribus computatris personalibus cum diversis specificationibus constante. Etiam consulto vitavi explicare quomodo programmata operatur vel quomodo ea instituantur. Potius, experientiam meam administrationis et difficultates quas inveni communicabo. Fortasse hoc alicui utile erit electionem suam facienti.
Itaque, incipiamus. Mihi, ut administratori systematis, haec momenta magni momenti sunt; sine his, vix hanc solutionem usurum essem.
1. Repetibilitas institutionis
Multae instructiones ad OpenNebula instituendum praesto sunt, ergo nullas difficultates experiri debes. Novae functiones ab una versione ad alteram adduntur, et non semper operabuntur dum ab una versione ad alteram transis.
2. Cras
Nodum ipsum, KVM, et OpenNebulam observabimus. Feliciter, solutionem iam paratam habemus. Multae optiones ad monitorandos hospites Linux sunt, ut Zabbix vel Node Exporter — tibi ipsi licet. Nunc, Zabbix ad monitorandas mensuras systematis (temperatura ubi mensurabilis, constantia ordinum discorum), et Prometheus ad monitorandas applicationes utor. Exempli gratia, proiectum ad monitorandum KVM uti possemus. et constitui ut per systemd currat, satis bene operatur et mensuras kvm ostendit, etiam tabula instrumentorum iam parata est. .
Exempli gratia, hic est fasciculus meus:
/etc/systemd/system/libvirtd_exporter.service
[Unit]
Description=Node Exporter
[Service]
User=node_exporter
ExecStart=/usr/sbin/prometheus-libvirt-exporter --web.listen-address=":9101"
[Install]
WantedBy=multi-user.targetUnum igitur exportatorem habemus, alterum ad ipsam OpenNebulam monitorandam requirimus, hunc ego usus sum.
Ad ordinarium addi potest ad systema sequentia monitorandum.
In fasciculo `node_exporter`, initium sic muta:
ExecStart=/usr/sbin/node_exporter --web.listen-address=":9102" --collector.textfile.directory=/var/lib/opennebula_exporter/textfile_collectorDirectorium crea: `mkdir -p /var/lib/opennebula_exporter`
Primum, scriptum bash supra exhibitum per consolam inspice; si quod tibi opus est ostendit (si errorem dat, xmlstarlet instala), illud ad /usr/local/bin/opennebula_exporter.sh exscribe.
Adde munus crono singulis minutis:
*/1 * * * * (/usr/local/bin/opennebula_exporter.sh > /var/lib/opennebula_exporter/textfile_collector/opennebula.prom)Metricae apparere incipiunt, et Prometheum ad eas capiendas et graphicas et admonitiones creandas uti potes. Exempli gratia, tabulam simplicem huiusmodi in Grafana creare potes.
(Videre potes me hic CPU et RAM nimis impendere)
Eis qui Zabbix amant et utuntur, est...
Hoc est totum quod ad monitorandum pertinet; res principalis est eam adesse. Scilicet, instrumenta monitoria machinarum virtualium inclusa uti et notitias ad rationes imponere potes, sed quisque suam opinionem de hac re habet, et ego nondum rem penitus investigavi.
Nondum vere ad inscriptiones perveni. Optio simplicissima est addere `td-agent` ad directorium `/var/lib/one` per expressiones regulares interpretandum. Exempli gratia, fasciculus `sunstone.log` cum `regexp` nginx aliisque fasciculis qui historiam accessus ad suggestum ostendunt congruit—quid enim prodest? Exempli gratia, numerum nuntiorum "Error, error" clare indagare possumus et celerius ubi et quo in gradu problema sit accurate determinare.
3. Copiae reservatae
Sunt etiam opera emenda, stipendiaria, ut septem :OpenNebula_Backup. Hic intellegendum est imaginem machinae simpliciter servare non esse solutionem in hoc casu, cum machinae nostrae virtuales cum plena integratione operari debeant (incluso fasciculo contextuali qui configurationes retiales, nomen machinae virtualis, et configurationes proprias applicationum tuarum describit). Ergo, hic determinamus quid et quomodo servandum sit. Interdum, melius est copias facere eorum quae in ipsa machina virtuali sunt. Et fortasse unum tantum discum ex data machina servare debes.
Exempli gratia, decrevimus omnes machinas cum imaginibus persistentibus initiari, ergo, post lectionem
Primum igitur imaginem e nostra machina virtuali exonerare possumus:
onevm disk-saveas 74 3 prom.qcow2
Image ID: 77
Смотрим, под каким именем он сохранился
oneimage show 77
/var/lib/one//datastores/100/f9503161fe180658125a9b32433bf6e8
И далее копируем куда нам необходимо. Конечно, так себе способ. Просто хотел показать, что используя инструменты opennebula можно строить подобные решения.Hoc etiam in interreti inveni. et plus est , sed spatium repositionis tantum pro qcow2 est.
Sed ut omnes scimus, citius aut serius tempus advenit cum incrementales copias reservatas desiderabis. Hoc magis implicatum est, et fortasse administratio pecunias solutioni emptae destinabit. Aut, cum intellectu nos hic tantum opes minuere, et copias reservatas in gradu applicationis fieri debere et novos nodos et machinas virtuales addere—bene, hic dico nubem solum ad greges applicationum currendos uti, et basem datorum in alia suggestu currere vel, si fieri potest, uno iam parato a venditore uti.
4. Otium usus
In hac sectione, problemata quae expertus sum describam. Exempli gratia, cum imaginibus, ut scimus, optio persistendi est — cum imago in machinam virtualem (VM) inseritur, omnia data in eam imaginem scribuntur. Sed si non persistens est, imago in memoriam copiatur et data in id quod ex imagine originali copiatum est scribuntur — ita formulae operantur. Mihi ipsi problemata plus semel creavi oblitus "persistentem" specificare, et imago 200GB copiata est. Problema est, haec ratio non potest dissolvi; ad nodum ire et processum "cp" praesentem interficere debes.
Magnum vitium est quod actiones non potes simpliciter per GUI abrogare. Immo, eas abrogabis et videbis nihil fieri. Deinde, iterum exsequeris, eas abrogabis, et re vera, duo processus cp erunt imaginem exscribentes.
Deinde intellego cur OpenNebula cuique novae instantiae novum ID assignat. Exempli gratia, in Proxmox, machinam virtualem cum ID 101 creas, eam deles, deinde cum ID 101 recreas. Hoc in OpenNebula non fiet; quaeque nova instantia cum novo ID creabitur, et logica quaedam est — exempli gratia, vetera data vel institutiones frustra delendae.
Idem valet de repositione: haec suggestus imprimis in repositione centralizata intendit. Sunt additiones ad repositionem localem utendum, sed hoc non est casus hic. Credo aliquem in futuro articulum scripturum esse de quomodo repositionem localem in nodis uti et eam in productione feliciter adhibere potuerit.
5. Simplicitas maxima
Scilicet, quo longius progredieris, eo pauciores erunt qui te intelligent.
In mea configuratione — tribus nodis cum repositorio NFS — omnia recte funguntur. Sed si experimenta cum energia extinguimus, exempli gratia, cum imaginem photographicam exsequimur et nodum energiam exstinguimus, configurationes in basi datorum servabimus quae imaginem photographicam exstare indicant, sed re vera nulla est (bene, omnes scimus me primum de hac actione in basi datorum SQL scripsisse, sed ipsa operatio non prospere processit). Commodum est quod, cum imago photographica creatur, fasciculus separatus creatur et "parens" adest, ita si difficultates oriantur, vel etiam si GUI non operatur, fasciculum qcow2 recuperare et separatim restituere possumus.
Infeliciter, res non tam simplices sunt cum retibus. Saltem simplicius est quam in OpenStack. Solum VLAN (802.1Q) usus sum—bene operatur, sed si mutationes configurationum ex exemplo retis facias, illae configurationes ad machinas existentes non valebunt. Necesse erit tibi chartam retis removere et addere ut novae configurationes valeant.
Si cum OpenStack comparare vis, hoc dicere potes: OpenNebula non clare definit quas technologias ad conservationem datorum, administrationem retium, et administrationem opum adhibendas sit — quisque administrator sibi decernit quid sit commodissimum.
6. Instrumenta et installationes additionales
Ut intellegimus, suggestus nubilus non solum KVM sed etiam VMware ESXI administrare potest. Infeliciter, piscinam cum VCenter non habui, sed si quis id temptavit, mihi quaeso dicat.
Subsidium pro aliis praebitoribus nubium declaratur.
AWS, CAERULEUM.
Conatus sum etiam VMware Cloud a Selectel instituere, sed frustra. Desisti quia tot factores intererant, et contactum cum auxilio technico provisoris hospitii inutile erat.
Praeterea, nova versio nunc Firecracker includit—programma microVM, quasi involucrum KVM super Docker—qui etiam maiorem versatilitatem, securitatem, et efficacitatem praebet, cum necessitatem perdendi opes in aemulatione apparatuum tollit. Sola commoditas quam prae Docker video est quod non occupat processus additionales nec sockets consumit cum hac aemulatione utitur. Hoc significat facile adhiberi posse ut librator oneris (quamquam fortasse separatum articulum de hoc scribere debeo donec plene probavero).
7. Usus positivus et errores depurationis
Observationes meas de opere communicare volui; quas nonnullas supra descripsi, sed plura scribere velim. Immo, fortasse non solus sum qui initio hoc systema falsum esse et omnia esse fraus putat—quomodo quisquam cum hoc laborare potest? Sed deinde intellego omnia satis logica esse. Scilicet, non omnibus placere potes, et quaedam partes emendatione indigent.
Exempli gratia, simplex operatio imaginem disci ex uno repositorio datorum in alterum transcribendi. In meo casu, duos nodos habeo qui NFS currunt, et cum imaginem mitto, transcriptio per frontem OpenNebula fit. Dum omnes adsueti sumus ad data directe inter hospites transcribenda — sicut in VMware et Hyper-V — hoc est prorsus quod adsueti sumus, hoc differt. Alia est ratio et alia philosophia, et in versione 5.12, pyga "migrare ad repositorium datorum" sublata est. Sola ipsa machina migratur, non repositorium datorum, cum repositorium subiacens centralizatum sit.
Deinde error vulgaris variis causis praeditus est: "Error deploying virtual machine: Could not create domain from /var/lib/one//datastores/103/10/deployment.5." Infra index rerum praecipuarum inspiciendarum est.
- Iura imaginis pro usore oneadmin;
- Permissiones usori oneadmin ad libvirtd exsequendum;
- Rectene repositorium datorum collocatum est? Semitam in ipso nodo inspice; fortasse aliquid fractum est.
- Rete perperam configuratum est, vel potius, optiones retiales in fronte dicunt br0 ut interfaciem primariam pro VLAN constitutum esse, cum in nodo dicit bridge0 — hoc idem esse debet.
Repositorium systematis metadata pro machina tua virtuali (VM) servat. Si VM ex imagine persistenti incipis, VM ad configurationem initialem in repositorio ubi VM creavisti accessum habere debet—hoc est maximi momenti. Ergo, cum VM ad aliud repositorium datorum migras, omnia bis inspicere debes.
8. Documentatio, communitas, et progressus futurus
Et cetera, bona documentatio, communitas et, quod potissimum est, ut proiectum in futuro vivat.
Hic, plerumque, omnia satis bene documentata sunt, et etiam ex fonte officiali non erit problema instituere et responsa ad quaestiones invenire.
Communitas activa est et multas solutiones iam paratas publicat quas in tuis propriis installationibus uti potes.
A die quinto Decembris, quaedam regulae societatis mutatae sunt. Interest videre quomodo proiectum evolvat. Initio, nominatim mentionem feci de quibusdam venditoribus qui suis ipsius solutionibus utuntur et quid industria offerat. Scilicet, non est certa responsio de eo quod uti debeas. Sed parvis societatibus, propriam nubem privatam conservare fortasse non tam carum est quam videtur. Res principalis est scire exacte quid tibi opus sit.
Denique, quodcumque systema nubis elegeris, ne uno tantum producto contentus sis. Si tempus habes, alias solutiones, magis apertas, considera.
Bona est disputatio Active auxilium ferunt nec te ad Google mittunt ut solutionem invenias. Nobiscum iunge.
Source: www.habr.com
