Onderwerp: Mogelijkheden - schaalbaarheid en virtualisatie met VMware

Goedemiddag,

het doel is een web applicatie aan te bieden.
we zitten momenteel op 2.000.000 hits per maand. en de behoeft groeit nog iedere dag

een hit betekend. 1 pagina laden met dynamic content en 15 database querys.
een hit duurt ongeveer 5 minuten. (de pagina staat gemiddeld 5 minuten open bedoel ik hiermee)

hopelijk geeft dit meer info over de behoefte van de virtuele servers
groeten,
Menno

Oorspronkelijk geplaatst door Pantsy

Dat is wat Lefthand doet op storage level, is dan al opgepakt/opgelost.

Deze is ook uitgevoerd over minimaal 2 kasten? En niet 1 kast met 2 controllers of iets dergelijks?

Een setup met 2 controllers in 1 kast heb ik dus al een keer kapot horen gaan bij anderen (hebben we zelf nooit gebruikt). Een echt goede HA oplossing voor storage kun je op termijn verspreiden over meer dan 1 rack (of beter nog) meer dan 1 gebouw.

Oorspronkelijk geplaatst door menno192

ik ben nog aan het onderzoeken en vrij nieuw in het virtualiseren met Linux en Vmware.
zelf heb ik meer ervaring met Microsoft en Hyperv

Gezien je aangeeft dat je meer ervaring hebt met Windows is het dan geen beter idee om de Linux virtualisatie (ten minste het beheer) (deels) uit te besteden?

Oorspronkelijk geplaatst door menno192

het doel is een web applicatie aan te bieden.
we zitten momenteel op 2.000.000 hits per maand. en de behoeft groeit nog iedere dag

een hit betekend. 1 pagina laden met dynamic content en 15 database querys.
een hit duurt ongeveer 5 minuten. (de pagina staat gemiddeld 5 minuten open bedoel ik hiermee)

Wat voor soort querys gaat het om? Met name SELECT querys of juist UPDATE/INSERT querys? In het eerste geval is het misschien verstandig om de SELECT querys naar andere servers te sturen, dat zouden MySQL slaves kunnen zijn en zo is het mogelijk de belasting op de MySQL master te beperken.

Oorspronkelijk geplaatst door Mark17

Deze is ook uitgevoerd over minimaal 2 kasten? En niet 1 kast met 2 controllers of iets dergelijks?

Een setup met 2 controllers in 1 kast heb ik dus al een keer kapot horen gaan bij anderen (hebben we zelf nooit gebruikt). Een echt goede HA oplossing voor storage kun je op termijn verspreiden over meer dan 1 rack (of beter nog) meer dan 1 gebouw.

Google it zou ik zeggen ons lefthand cluster bestaat inmiddels uit 10+ nodes welke zijn uitgesmeerd over meerdere kasten en datacenters.

Oorspronkelijk geplaatst door Pantsy

Google it zou ik zeggen ons lefthand cluster bestaat inmiddels uit 10+ nodes welke zijn uitgesmeerd over meerdere kasten en datacenters.

Ik zie net inderdaad dat er een variant is bestaande uit meerdere nodes. Er lijkt echter ook een variant te zijn met alles in 1 kast. Verder is het een keuze om voor HP, Dell, Coraid, etc. te gaan op het gebied van storage.

Oorspronkelijk geplaatst door menno192

Goedemiddag,

het doel is een web applicatie aan te bieden.
we zitten momenteel op 2.000.000 hits per maand. en de behoeft groeit nog iedere dag

een hit betekend. 1 pagina laden met dynamic content en 15 database querys.
een hit duurt ongeveer 5 minuten. (de pagina staat gemiddeld 5 minuten open bedoel ik hiermee)

hopelijk geeft dit meer info over de behoefte van de virtuele servers
groeten,
Menno

Ik zou in dit geval wellicht niet eens meer voor virtualisatie gaan. In onze ogen heeft virtualisatie veel voordelen wanneer je gebruik maakt van een enkele VPS die je gemakkelijk wilt schalen. Wij maken met dit soort websites (bij elkaar goed voor 7m pageviews per dag) echt gebruik van fysieke servers. We kunnen met behulp van puppet in enkele minuten met fysieke servers bijschalen.

Met grotere aantallen en meerdere servers heb je naar mijn ogen niet echt veel meer aan de voordelen die VPSen kunnen bieden.

alle soorten querys maar voornamelijk select en update

met microsoft ben ik bekend omdat ik hier dagelijks mee werk. maar mijn eigen omgeving met daarop de web applicatie wil ik gewoon niet op windows hebben.
ik heb een linux expert aan boord en ben zelf ook niet vreemd met linux. het punt is alleen dat we zo snel groeien en kosten willen drukken dat we moeten virtualiseren.

en de linux expert is nog niet bekend met virtualisatie in op linux niveu met vmware.
en ik zelf heb meer ervaring in Hyper-V

alles blijft dan ook in eigen beheer.
gewoon bedrijfs policy

Oorspronkelijk geplaatst door golden

Ik zou in dit geval wellicht niet eens meer voor virtualisatie gaan. In onze ogen heeft virtualisatie veel voordelen wanneer je gebruik maakt van een enkele VPS die je gemakkelijk wilt schalen. Wij maken met dit soort websites (bij elkaar goed voor 7m pageviews per dag) echt gebruik van fysieke servers. We kunnen met behulp van puppet in enkele minuten met fysieke servers bijschalen.

Met grotere aantallen en meerdere servers heb je naar mijn ogen niet echt veel meer aan de voordelen die VPSen kunnen bieden.

kijk ik vind het niet erg om alles in hardware te doen. wij houden van hardware. alleen de SQL weet ik op geen andere mannier te schalen dan virtueel.

de web server of web servers moeten van elkaar weten wat er gebeurt. anders heb ik op iedere hardware bak een verouderde site staan of een outdated souce code.
en de SQL server of servers moeten dat data van een centraal punt denken. anders veradnderd server WEB-004 de username in HENK en tegelijk wordt er in WEB-008 gemeld dat dit PIET moet zijn. snap je wat ik bedoel?

zelf denk ik aan meerdere DOMME web servers die de pagina`s laden en de page request afhandelen. --> vervolgens querys zenden naar een SQL active active cluster.
of is dat een gekke gedachten?

Oorspronkelijk geplaatst door menno192

het punt is alleen dat we zo snel groeien en kosten willen drukken dat we moeten virtualiseren.

Wie heeft je vertelt dat je kosten kunt drukken met virtualisatie in gevallen van snelle groei?
Je kunt pas kosten drukken op het moment dat je meerdere diensten op dezelfde hardware kunt draaien, echter dan moeten dat diensten zijn die zich daar ook voor lenen ( webservers met weinig bezoekers, databases met weinig queries, etc...).
Op het moment dat je moet gaan schalen omdat bv. 1 server de web-/dbrequests niet meer aankan, dan heeft virtualisatie maar een heel beperkte toegevoegde waarde.

Daarnaast... moet je virtualisatie niet half/half doen maar in 1 keer goed. Ik weet niet hoe dat bij andere hosters zit, maar onze vpsplatformen zijn pas rendabel als er 30+ vpssen op draaien. (Aangenomen dat een vps voorheen een fysieke server was van ~2k)

Oorspronkelijk geplaatst door Mark17

Wat voor soort querys gaat het om? Met name SELECT querys of juist UPDATE/INSERT querys? In het eerste geval is het misschien verstandig om de SELECT querys naar andere servers te sturen, dat zouden MySQL slaves kunnen zijn en zo is het mogelijk de belasting op de MySQL master te beperken.

Dat is nog lang geen vreemde gedachten.
ik wist niet dat je dat kon opsplitsen. ik heb wel films gezien waarin ze praten over front end en back-end sql servers.

Oorspronkelijk geplaatst door menno192

kijk ik vind het niet erg om alles in hardware te doen. wij houden van hardware. alleen de SQL weet ik op geen andere mannier te schalen dan virtueel.

Denk vooral niet dat je SQL schaling 'vanzelf' krijgt als je het virtueel maakt.
Nog minder dan andere services.
SQL schaling krijg je het beste van een database developer die het _echt_ snapt. Dwz: de structuur , de queries en de gekozen database engine optimaal aan elkaar aanpassen. En daarna pas van meer systeem resources.

Oorspronkelijk geplaatst door menno192

de web server of web servers moeten van elkaar weten wat er gebeurt. anders heb ik op iedere hardware bak een verouderde site staan of een outdated souce code.
en de SQL server of servers moeten dat data van een centraal punt denken. anders veradnderd server WEB-004 de username in HENK en tegelijk wordt er in WEB-008 gemeld dat dit PIET moet zijn. snap je wat ik bedoel?

Ja, dat is het gemakkelijke van een centrale component inbouwen die altijd een consistent en exact up to date beeld heeft van deze dingen.
En het grote gevaar als je veel dingen daarop laat leunen, en dan aan de grens van de capaciteit van die centrale component (hier een database) komt. Want dan is schalen moeilijk, als je het niet meer van 'volgende generatie cpu' kunt krijgen.
Je hebt het misschien wel _ergens_ nodig, maar op erg grote schaal moet heel zorgvuldig afwegen hoeveel resources van deze component je nodig hebt, en hoeveel garantie binnen welk tijdswindow antwoorden exact hetzelfde moeten zijn. Als opeenvolgende queries pas op minutenbasis het ge-update antwoord van een andere server hoeven te zien [bijvoorbeeld omdat websessies zolang duren en sticky zijn opdezelfde server ] heb je veel meer design (en schaal) ruimte dan wanneer je eist dat elke volgende query het ge-update antwoord krijgt.

Oorspronkelijk geplaatst door menno192

zelf denk ik aan meerdere DOMME web servers die de pagina`s laden en de page request afhandelen. --> vervolgens querys zenden naar een SQL active active cluster.
of is dat een gekke gedachten?

Op deze hoofdlijn hoeft het geen gekke gedachte te zijn. Zolang je maar niet denkt dat "active-active" betekent 'altijd twee keer zoveel database performance ongeacht hoe ik 'm query' .

Oorspronkelijk geplaatst door systemdeveloper

Wie heeft je vertelt dat je kosten kunt drukken met virtualisatie in gevallen van snelle groei?
Je kunt pas kosten drukken op het moment dat je meerdere diensten op dezelfde hardware kunt draaien, echter dan moeten dat diensten zijn die zich daar ook voor lenen ( webservers met weinig bezoekers, databases met weinig queries, etc...).
Op het moment dat je moet gaan schalen omdat bv. 1 server de web-/dbrequests niet meer aankan, dan heeft virtualisatie maar een heel beperkte toegevoegde waarde.

Daarnaast... moet je virtualisatie niet half/half doen maar in 1 keer goed. Ik weet niet hoe dat bij andere hosters zit, maar onze vpsplatformen zijn pas rendabel als er 30+ vpssen op draaien. (Aangenomen dat een vps voorheen een fysieke server was van ~2k)

Ik denk dat hij een klok&klepel verhaal gehoord heeft (of misschien zelf de klepel gemist) met veel hype van cloud en AWS.

'Cloud' en bijvoorbeeld AWS leveren typisch instances met een wat variabele performance, en een zekere onderlinge latency (en zeker latency naar 'de wereld' ).

*Als* je de echt moeilijke stap gehad hebt en je service min of meer lineair kan schalen door het bijschakelen van dergelijke instances, _dan_ kun zeker kosten drukken doordat die resources pas geld kosten als je ze bijschakelt.

Als je dat met eigen hardware moet doen, bouw je altijd in brokken bij en heb je een window waarin je al geld uitgegeven hebt terwijl de servers (/DC capaciteit) nog niet strikt nodig is, of nog niet gebouwd/geinstalleerd is.

Ik denk dat bovenstaand het verhaal is waar de combinatie kosten drukken, snelle groei en virtualisatie bij elkaar komen.
Op kleine schaal zou je nog kunnen zeggen dat als je geen hele fysieke server nodig hebt je dus die kosten drukt door een VPSje te nemen.

Oorspronkelijk geplaatst door systemdeveloper

Daarnaast... moet je virtualisatie niet half/half doen maar in 1 keer goed. Ik weet niet hoe dat bij andere hosters zit, maar onze vpsplatformen zijn pas rendabel als er 30+ vpssen op draaien. (Aangenomen dat een vps voorheen een fysieke server was van ~2k)

Per VPS node zijn niet echt heel veel vpsen nodig om het rendabel te maken bij ons, echter als je gaat kijken incl. failover en voordelen voor de klant dan zit je wel op minimaal iets van 25-50 vpsen per cluster om er ongeveer net zo veel aan te verdienen tov losse servers met een vergelijkbare rekenkracht. Dit alles uiteraard sterk afhankelijk van het type klanten en de belasting die ze veroorzaken.

Oorspronkelijk geplaatst door menno192

Dat is nog lang geen vreemde gedachten.
ik wist niet dat je dat kon opsplitsen. ik heb wel films gezien waarin ze praten over front end en back-end sql servers.

Ik heb het met name over opsplitsen in de applicatie, het kan ook met een tussen laag (MySQL proxy). Het is echter zo dat aan al het schalen een eind zit als de applicatie niet aangepast wordt en uiteindelijk is er met de juiste kennis een heel eind te schalen met standaardsoftware. Wat is overigens de reden om voor vmware te kiezen?