Dag Allemaal. Dit artikel is geschreven voor degenen die nog steeds twijfelen tussen het kiezen van virtualisatieplatforms en na het lezen van het artikel uit de serie “We hebben proxmox geïnstalleerd en over het algemeen is alles in orde, 6 jaar uptime zonder een enkele pauze.” Maar na het installeren van een of andere out-of-the-box oplossing rijst de vraag: hoe kan ik dit hier corrigeren, zodat de monitoring begrijpelijker wordt, en hier, om back-ups te controleren…. En dan komt de tijd dat je beseft dat je iets functionelers wilt, of dat alles binnen je systeem duidelijk wordt, en niet deze zwarte doos, of dat je iets meer wilt gebruiken dan een hypervisor en een heleboel virtuele machines. Dit artikel bevat enkele gedachten en oefeningen gebaseerd op het Opennebula-platform - ik heb ervoor gekozen omdat. het vergt geen middelen en de architectuur is niet zo complex.
En dus werken, zoals we zien, veel cloudproviders op kvm en maken ze externe verbindingen om machines te besturen. Het is duidelijk dat grote hosters hun eigen raamwerken voor cloudinfrastructuur schrijven, dezelfde YANDEX bijvoorbeeld. Iemand gebruikt openstack en maakt op basis hiervan een verbinding - SELECTEL, MAIL.RU. Maar als je je eigen hardware hebt en een kleine staf specialisten, dan kies je meestal voor iets kant-en-klaar - VMWARE, HYPER-V, er zijn gratis en betaalde licenties, maar daar hebben we het nu niet over. Laten we het over enthousiastelingen hebben - dit zijn degenen die niet bang zijn om iets nieuws aan te bieden en te proberen, ondanks het feit dat het bedrijf duidelijk duidelijk heeft gemaakt: "Wie gaat dit na jou bedienen", "Gaan we dit later in productie nemen?" ? Eng." Maar je kunt deze oplossingen eerst op een testbank toepassen, en als iedereen het leuk vindt, kun je de vraag stellen naar verdere ontwikkeling en gebruik in serieuzere omgevingen.
Hier vindt u ook een link naar het rapport van een actieve deelnemer aan de ontwikkeling van dit platform.
Misschien is er in dit artikel iets overbodig en al begrijpelijk voor een ervaren specialist, en in sommige gevallen zal ik niet alles beschrijven omdat soortgelijke commando's en beschrijvingen op internet beschikbaar zijn. Dit is slechts mijn ervaring met dit platform. Ik hoop dat actieve deelnemers in de reacties zullen toevoegen wat er beter kan en welke fouten ik heb gemaakt. Alle acties vonden plaats in een thuisstand bestaande uit 3 pc's met verschillende kenmerken. Ook heb ik specifiek niet aangegeven hoe deze software werkt en hoe je deze moet installeren. Nee, alleen administratieve ervaring en de problemen die ik tegenkwam. Misschien zal dit nuttig zijn voor iemand bij zijn keuze.
Dus laten we beginnen. Als systeembeheerder zijn de volgende punten belangrijk voor mij, zonder deze punten is het onwaarschijnlijk dat ik deze oplossing zal gebruiken.
1. Herhaalbaarheid van de installatie
Er zijn veel instructies voor het installeren van opennebula, er zouden geen problemen moeten zijn. Van versie naar versie verschijnen er nieuwe functies die niet altijd werken als je van versie naar versie gaat.
2. Toezicht houden
We zullen het knooppunt zelf, kvm en opennebula monitoren. Gelukkig is het al klaar. Er zijn veel opties voor het monitoren van Linux-hosts, dezelfde Zabbix- of knooppuntexporteur - wie het maar leuk vindt, wat beter - op dit moment definieer ik het als het monitoren van systeemstatistieken (temperatuur waar het kan worden gemeten, consistentie van de schijfarray), via zabbix , en wat betreft aanvragen via de Prometheus-exporteur. Voor kvm-monitoring kunt u bijvoorbeeld het project nemen en instellen dat het via systemd draait, het werkt best goed en toont kvm-statistieken, er is ook een kant-en-klaar dashboard .
Hier is bijvoorbeeld mijn bestand:
/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.targetEn dus hebben we 1 exporteur, we hebben een tweede nodig om de opennebula zelf te monitoren, ik heb deze gebruikt
Kan worden toegevoegd aan normaal om het systeem als volgt te controleren.
In het node_exporter bestand veranderen we de start als volgt:
ExecStart=/usr/sbin/node_exporter --web.listen-address=":9102" --collector.textfile.directory=/var/lib/opennebula_exporter/textfile_collectorMaak een map mkdir -p /var/lib/opennebula_exporter
bash-script hierboven gepresenteerd, eerst controleren we het werk via de console, als het laat zien wat we nodig hebben (als het een fout geeft, installeer dan xmlstarlet), kopieer het naar /usr/local/bin/opennebula_exporter.sh
Voeg voor elke minuut een cron-taak toe:
*/1 * * * * (/usr/local/bin/opennebula_exporter.sh > /var/lib/opennebula_exporter/textfile_collector/opennebula.prom)Er begonnen statistieken te verschijnen, je kunt ze als een prometheus gebruiken en grafieken maken en waarschuwingen maken. In Grafana kun je bijvoorbeeld zo’n eenvoudig dashboard tekenen.
(het is duidelijk dat ik hier cpu, ram te veel inzet)
Voor degenen die van Zabbix houden en deze gebruiken, is er
Wat de monitoring betreft, gaat het erom dat die er is. Uiteraard kun je daarnaast de ingebouwde virtual machine monitoring tools gebruiken en data uploaden naar de facturatie, hier heeft iedereen zijn eigen visie, ik ben hier nog niet verder mee aan de slag gegaan.
Ik ben nog niet echt begonnen met loggen. De eenvoudigste optie is om td-agent toe te voegen om de map /var/lib/one te parseren met reguliere expressies. Het bestand sunstone.log komt bijvoorbeeld overeen met de nginx-regexp en andere bestanden die de geschiedenis van toegang tot het platform tonen - wat is het voordeel hiervan? Welnu, we kunnen bijvoorbeeld expliciet het aantal “Error, error” volgen en snel volgen waar en op welk niveau er een storing is.
3. Back-ups
Er zijn ook betaalde voltooide projecten - bijvoorbeeld sep :OpenNebula_Backup. Hier moeten we begrijpen dat het eenvoudigweg maken van een back-up van een machine-image in dit geval helemaal niet hetzelfde is, omdat onze virtuele machines met volledige integratie moeten werken (hetzelfde contextbestand dat de netwerkinstellingen, vm-naam en aangepaste instellingen voor uw applicaties beschrijft) . Daarom beslissen we hier wat en hoe we een back-up maken. In sommige gevallen is het beter om kopieën te maken van wat zich in de VM zelf bevindt. En misschien hoeft u slechts één schijf van een bepaalde machine te back-uppen.
We hebben bijvoorbeeld vastgesteld dat alle machines na het lezen beginnen met persistente afbeeldingen
Dit betekent dat we eerst de afbeelding van onze VM kunnen uploaden:
onevm disk-saveas 74 3 prom.qcow2
Image ID: 77
Смотрим, под каким именем он сохранился
oneimage show 77
/var/lib/one//datastores/100/f9503161fe180658125a9b32433bf6e8
И далее копируем куда нам необходимо. Конечно, так себе способ. Просто хотел показать, что используя инструменты opennebula можно строить подобные решения.Heb ik ook gevonden op internet en er is meer , maar er is alleen opslag voor qcow2.
Maar zoals we allemaal weten, komt er vroeg of laat een moment waarop je incrementele back-ups wilt, het is hier moeilijker en misschien zal het management geld toewijzen voor een betaalde oplossing, of de andere kant op gaan en begrijpen dat we hier alleen maar op middelen bezuinigen. en het maken van back-ups op applicatieniveau en het toevoegen van een aantal nieuwe knooppunten en virtuele machines - ja, hier zeg ik dat ik de cloud puur gebruik om applicatieclusters te starten, en de database op een ander platform te lanceren of een kant-en-klaar platform te nemen indien mogelijk bij de leverancier.
4. Gebruiksgemak
In deze paragraaf beschrijf ik de problemen die ik tegenkwam. Volgens afbeeldingen is er bijvoorbeeld, zoals we weten, persistent: wanneer deze afbeelding op een vm wordt gemonteerd, worden alle gegevens naar deze afbeelding geschreven. En als dit niet-persistent is, wordt de afbeelding naar de opslag gekopieerd en worden de gegevens geschreven naar wat van de bronafbeelding is gekopieerd - dit is hoe sjabloonsjablonen werken. Ik heb herhaaldelijk problemen voor mezelf veroorzaakt door te vergeten persistent op te geven en de afbeelding van 200 GB is gekopieerd. Het probleem is dat deze procedure zeker niet kan worden geannuleerd, je moet naar het knooppunt gaan en het huidige "cp" -proces beëindigen.
Een van de belangrijke nadelen is dat je acties niet eenvoudigweg via de gui kunt annuleren. Of beter gezegd, je annuleert ze en ziet dat er niets gebeurt en je start ze opnieuw, annuleert ze en in feite zullen er al 2 cp-processen zijn die de afbeelding kopiëren.
En dan begrijp je waarom opennebula elke nieuwe instantie nummert met een nieuwe id. In dezelfde proxmox heb je bijvoorbeeld een vm gemaakt met id 101, deze verwijderd, en vervolgens maak je hem opnieuw aan met id 101. In opennebula zal dit niet gebeuren, elk nieuw exemplaar wordt gemaakt met een nieuwe ID en dit heeft zijn eigen logica, bijvoorbeeld het wissen van oude gegevens of mislukte installaties.
Hetzelfde geldt voor opslag; dit platform is vooral gericht op gecentraliseerde opslag. Er zijn add-ons voor het gebruik van lokaal, maar daar hebben we het in dit geval niet over. Ik denk dat iemand in de toekomst een artikel zal schrijven over hoe ze erin geslaagd zijn lokale opslag op knooppunten te gebruiken en deze met succes in productie te gebruiken.
5. Maximale eenvoud
Hoe verder je gaat, hoe minder mensen je zullen begrijpen.
Onder de omstandigheden van mijn stand - 3 knooppunten met nfs-opslag - werkt alles prima. Maar als we experimenten uitvoeren met een stroomstoring, bijvoorbeeld bij het uitvoeren van een momentopname en het uitschakelen van de stroom van het knooppunt, slaan we instellingen in de database op dat er een momentopname is, maar die is er in feite niet (nou ja, we begrijpen allemaal dat we schreef de database aanvankelijk over deze actie in sql , maar de bewerking zelf was niet succesvol). Het voordeel is dat bij het maken van een snapshot een apart bestand wordt gevormd en er een “ouder” is, dus in geval van problemen en zelfs als het niet via gui werkt, kunnen we het qcow2-bestand ophalen en afzonderlijk herstellen
Op netwerken is helaas niet alles zo eenvoudig. Nou ja, het is in ieder geval eenvoudiger dan in openstack, ik heb alleen vlan (802.1Q) gebruikt - het werkt best goed, maar als je wijzigingen aanbrengt in de instellingen van het sjabloonnetwerk, worden deze instellingen niet toegepast op reeds draaiende machines, d.w.z. Als u een netwerkkaart moet verwijderen en toevoegen, worden de nieuwe instellingen toegepast.
Als je het nog steeds wilt vergelijken met openstack, dan kun je dit zeggen: in opennebula is er geen duidelijke definitie van welke technologieën te gebruiken voor het opslaan van gegevens, het beheren van het netwerk, bronnen - elke beheerder beslist zelf wat voor hem handiger is.
6. Extra plug-ins en installaties
Zoals wij het begrijpen, kan het cloudplatform immers niet alleen kvm, maar ook vmware esxi beheren. Helaas had ik geen zwembad bij Vcenter, als iemand het heeft geprobeerd, schrijf dan alsjeblieft.
Ondersteuning voor andere cloudproviders wordt vermeld
AWS, AZUUR.
Ik heb ook geprobeerd Vmware Cloud van Selectel aan te sluiten, maar niets werkte - over het algemeen werd het geblokkeerd omdat er veel factoren zijn en het geen zin heeft om naar de technische ondersteuning van de hostingprovider te schrijven.
Ook heeft de nieuwe versie nu knaller - dit is de lancering van microvm, een soort kvm-harnas over docker, dat nog meer veelzijdigheid, veiligheid en verhoogde productiviteit biedt omdat het niet nodig is middelen te verspillen aan emulatieapparatuur. Het enige voordeel dat ik zie ten opzichte van Docker is dat het geen extra aantal processen in beslag neemt en dat er geen bezette sockets zijn bij het gebruik van deze emulatie, d.w.z. Het is heel goed mogelijk om het als load balancer te gebruiken (maar het is waarschijnlijk de moeite waard om hier een apart artikel over te schrijven totdat ik alle tests volledig heb uitgevoerd).
7. Positieve ervaring met gebruik en foutopsporing
Ik wilde mijn observaties over het werk delen, ik heb er hierboven een deel van beschreven, ik zou graag meer willen schrijven. Ik ben inderdaad waarschijnlijk niet de enige die in eerste instantie denkt dat dit niet het juiste systeem is en dat alles hier in het algemeen een kruk is - hoe werken ze hiermee eigenlijk? Maar dan komt het besef dat alles heel logisch is. Natuurlijk kun je niet iedereen tevreden stellen en sommige aspecten behoeven verbetering.
Bijvoorbeeld een eenvoudige handeling waarbij een schijfkopie van de ene datastore naar de andere wordt gekopieerd. In mijn geval zijn er 2 knooppunten met nfs, ik stuur de afbeelding - het kopiëren gebeurt via de frontend opennebula, hoewel we allemaal gewend zijn aan het feit dat gegevens rechtstreeks tussen hosts moeten worden gekopieerd - in dezelfde VMware, hyper-v zijn we gewend aan dit, maar hier aan het andere. Er is een andere aanpak en een andere ideologie, en in versie 5.12 hebben ze de knop ‘migreren naar datastore’ verwijderd – alleen de machine zelf wordt overgedragen, maar niet de opslag omdat betekent gecentraliseerde opslag.
Vervolgens volgt een populaire fout met verschillende redenen: “Fout bij het implementeren van de virtuele machine: kon geen domein maken van /var/lib/one//datastores/103/10/deployment.5” Hieronder ziet u het belangrijkste waar u op moet letten.
- Beeldrechten voor de oneadmin-gebruiker;
- Machtigingen voor de oneadmin-gebruiker om libvirtd uit te voeren;
- Is de datastore correct aangekoppeld? Ga het pad op het knooppunt zelf controleren, misschien is er iets afgevallen;
- Verkeerd geconfigureerd netwerk, of beter gezegd, aan de frontend staat in de netwerkinstellingen dat de hoofdinterface voor vlan br0 is, maar op het knooppunt wordt het geschreven als bridge0 - het moet hetzelfde zijn.
system datastore slaat metagegevens op voor uw VM. Als u de VM met een persistente image uitvoert, moet de VM toegang hebben tot de aanvankelijk gemaakte configuratie op de opslag waar u de VM hebt gemaakt - dit is erg belangrijk. Daarom moet u bij het overbrengen van een virtuele machine naar een andere datastore alles dubbel controleren.
8. Documentatie, gemeenschap. Verdere ontwikkeling
En de rest, goede documentatie, gemeenschap en het belangrijkste is dat het project in de toekomst blijft leven.
Over het algemeen is alles redelijk goed gedocumenteerd en zelfs als je een officiële bron gebruikt, zal het geen probleem zijn om te installeren en antwoorden op vragen te vinden.
Gemeenschap, actief. Publiceert vele kant-en-klare oplossingen die u in uw installaties kunt gebruiken.
Op dit moment zijn er enkele beleidsregels binnen het bedrijf veranderd sinds 5.12 Het zal interessant zijn om te zien hoe het project zich ontwikkelt. In het begin heb ik specifiek gewezen op enkele leveranciers die hun oplossingen gebruiken en op wat de industrie te bieden heeft. Er is natuurlijk geen duidelijk antwoord op wat te gebruiken. Maar voor kleinere organisaties is het onderhouden van hun kleine private cloud misschien niet zo duur als het lijkt. Het belangrijkste is om precies te weten wat je nodig hebt.
Hierdoor moet je, ongeacht wat je kiest als cloudsysteem, niet stoppen bij één product. Als je tijd hebt, is het de moeite waard om naar andere, meer open oplossingen te kijken.
Er is een goed gesprek Ze helpen actief en sturen je niet om op Google naar een oplossing voor het probleem te zoeken. Doe met ons mee.
Bron: www.habr.com