VPS vs OpenStack

[Blune]

Ik werk bij een klein internet bedrijf wat inmiddels zo'n 250 kleine websites en 50 middelgrote websites in de lucht heeft. Die websites zijn verdeeld over ongeveer 10 VPSen. En deze aantallen groeien nog steeds. Wellicht zie je het al aankomen, dat onderhouden is een ramp geworden.

Nu heb je tegenwoordig veel OpenStack oplossingen. Maar ik snap niet goed wat OpenStack is. Ik weet wel dat het software is om resources te beheren en te gebruiken via één API. Dat het daarmee heel makkelijk is om verschillende recourses bij te schakelen op het moment dat je het nodig hebt. Klinkt eigenlijk precies als wat we nodig hebben.

Echter heb ik moeite om mij om voor me te zien hoe dit in de praktijk gaat werken.

Hoe we momenteel werken is dat elke VPS zowel als webserver en als databaseserver fungeert. De webserver handelt met apache de PHP af, maar serveert ook alle statische content zoals afbeeldingen, javascript en css. Voor dat laatste zouden we graag overstappen naar nginx. Ook zitten we er aan de denken om voor de database aparte servers te nemen.

Hoe verandert dit wanneer we voor een OpenStack oplossing kiezen?
Krijg ik dan ook gewoon een ubuntu of centos server waar ik kan loggen met SSH om wat extra apache modules te installeren? Of zijn dat er dan meerdere? Moet ik het zo zien? Dat ik eigenlijk gewoon allemaal VPSjes krijg; Aan elkaar geknoopt; Die elk een specifieke taak hebben?

[CyBeR]

Hoe verandert dit wanneer we voor een OpenStack oplossing kiezen?

OpenStack volgt meer het Amazon EC2-model van cloud computing. Het is zeker mogelijk om 't als "VPS-service" te gebruiken op de manier zoals je nu doet, maar dat is niet de bedoeling zozeer. De bedoeling is dat je alles automatiseert zodat als je bijvoorbeeld meer resources nodig hebt, je gewoon een paar extra instances lanceert die vervolgens allemaal automatisch geinstalleerd worden, toegevoegd worden aan je load balancer en dezelfde sites serven.

Krijg ik dan ook gewoon een ubuntu of centos server waar ik kan loggen met SSH om wat extra apache modules te installeren?

Dat is aan jou. In de basis krijg je inderdaad gewoon een VM waarop je shit kunt doen. Maar handmatige acties zijn eigenlijk niet het idee erachter. Dan krijg je snowflake servers waar openstack eigenlijk meer gericht is op phoenix servers.

Moet ik het zo zien? Dat ik eigenlijk gewoon allemaal VPSjes krijg; Aan elkaar geknoopt; Die elk een specifieke taak hebben?

Ook dat is aan jou. Dat gaat over resourceverdeling. Voor sommige dingen is 't prima (en wellicht zelfs handiger) om 't hele zooitje op één vm te hebben als self-contained dingetje. Voor andere dingen heb je beter een scheiding tussen web, database en file storage. Als je web servers load balancet bijvoorbeeld is het handiger om daar op geen state te hebben bijvoorbeeld en alle data dus extern op te slaan.

[ik222]

Ik zou in deze situatie beginnen met het implementeren van een server management systeem zoals puppet. Zo kun je in elk geval zorgen dat nodes identiek zijn wat betreft configuratie en inderdaad makkelijk te herinstalleren zijn. Ook dingen als patches installeren en monitoring zijn op basis daarvan zo stap voor stap te automatiseren.

Natuurlijk is dat slechts een gedeelte van de oplossing. Want uiteindelijk zul je met die puppet omgeving waarschijnlijk een of meedere clusters willen bouwen waarop je de sites verdeeld over nodes en mogelijk redundant gaat hosten.

Maar mijn inziens begint het met centraal beheer over je servers inrichten. Openstack is slechts een van de manieren om resources te schalen.

[ Voor 4% gewijzigd door ik222 op 26-03-2016 19:20 ]

[Yarisken]

Gebruik zeker geen puppet :-). Kijk is naar ansible.
Kan je niet in "onderaanneming" bij een grote speler zoals Combell gaan ? Die hebben de resources om veel werk voor jullie uit handen te nemen.

[ik222]

Wat is er mis met puppet dan volgens jou? Een beetje onderbouwing is wel fijn bij zo'n stelling lijkt me...

Er zijn natuurlijk meerdere systemen maar puppet vind ik zelf erg goed werken (beheer er zelf zo'n 250 servers mee), er is een grote community en het is erg uitgebreid. Enige echte nadeel is dat het relatief veel resources vraagt al valt dat ook nog best mee eigenlijk.

[ Voor 3% gewijzigd door ik222 op 26-03-2016 21:06 ]

[CyBeR]

Puppet is gemaakt voornamelijk om langdurig te draaien en zorgen dat je server in een bepaalde configuratie blijft. Maar dat is nagenoeg onmogelijk om daadwerkelijk te doen omdat je nooit álles in puppet hebt staan. Uiteindelijk krijg je dus altijd subtiele verschillen.

Daarom ook het idee van phoenix servers wat ik hierboven al aanhaalde: je bouwt een server (vm) die je niet meer aanpast. Als je wel een aanpassing nodig hebt bouw je een nieuwe. Zo zorg je ervoor dat je altijd in staat bent om heel je omgeving opnieuw op tezetten in het geval van problemen en dat je niet afhankelijk wordt (zonder 't door te hebben) van je speciaal ingerichte snowflakes.

Op zich maakt het niet zo veel uit hoe je dat doet overigens -- shell scripts, ansible, puppet, salt, allemaal andere implementaties van hetzelfde idee: automatisering en infrastructure as code.

[Yarisken]

ik222 schreef op zaterdag 26 maart 2016 @ 21:03:
Wat is er mis met puppet dan volgens jou? Een beetje onderbouwing is wel fijn bij zo'n stelling lijkt me...

Er zijn natuurlijk meerdere systemen maar puppet vind ik zelf erg goed werken (beheer er zelf zo'n 250 servers mee), er is een grote community en het is erg uitgebreid. Enige echte nadeel is dat het relatief veel resources vraagt al valt dat ook nog best mee eigenlijk.

Puppet heeft een steile leercurve. Meer een meer admins zijn over aan het gaan op bv ansible. Zelf waren we ook aan het kijken naar een automatiseringstool en puppet kwam er toch uit als nodeloos complex en schiet meer en meer zijn doel voorbij.

[Blune]

Dank voor jullie antwoorden. Het is me nu duidelijk wat open stack inhoudt. En ik zal me eens gaan verdiepen in Ansible, en wellicht Puppet.

[Gomez12]

Yarisken schreef op zaterdag 26 maart 2016 @ 23:15:
[...]
Meer een meer admins zijn over aan het gaan op bv ansible.

Heb je hier ook een onderbouwing voor? Want dit is namelijk niet mijn ervaring...