Load balancing over identieke VPS servers

[Yzord]

Ik heb een server waarop 10 identieke VPS nodes draaien. Ik vroeg mij af of ik een load balancer kan gebruiken op de hardware node welke de traffic verdeelt over deze 10 vps nodes wanneer er een hoge aanvraag is.

Stel dat het meeste traffic wordt gestuurd naar node01, maar dit de load van de node vergroot, dan wil ik een stuk software hebben die dan zegt: ok, de load is hoog op node01, dus we sturen wat door naar node02/node03 etc.

Is dit mogelijk?

Ik gebruik CentOS 6.6 met OpenVZ latest kernel (22 dec).

[Verwijderd]

Je zou is kunnen kijken naar haproxy.

[Yzord]

Ja daar zat ik net op...eens zien of ik daar wat mee kan

Ze schermen met poortnummers in Haproxy, maar ik wil dat de proxy naar alle poorten luistert en doorstuurt, kan dat ook met Haproxy? Want dat vind ik nergens.

[ Voor 59% gewijzigd door Yzord op 28-12-2014 17:54 ]

[CAPSLOCK2000]

Welk(e) protocol(len) wil je balancen?

[Yzord]

Wallets van coins....zeker 11 per server en worden er meer. Ze hebben ieder een andere poort elke keer. Dus wat ik eigenlijk zoek is dat er naar de load van de VPS wordt gekeken en uitgeweken wordt naar een VPS met minder load.

[ Voor 58% gewijzigd door Yzord op 28-12-2014 22:32 ]

[d1ng]

Yzord schreef op zondag 28 december 2014 @ 16:54:
Ik heb een server waarop 10 identieke VPS nodes draaien. Ik vroeg mij af of ik een load balancer kan gebruiken op de hardware node welke de traffic verdeelt over deze 10 vps nodes wanneer er een hoge aanvraag is.

Als alles op dezelfde server draait, waarom dan eigenlijk virtualiseren?

[Yzord]

Omdat ik tien aanspreekbare servers moet hebben. Om dan 10 dedicated servers in DC op te hangen is ook weer zoiets

[CAPSLOCK2000]

Yzord schreef op zondag 28 december 2014 @ 22:04:
Wallets van coins....zeker 11 per server en worden er meer. Ze hebben ieder een andere poort elke keer. Dus wat ik eigenlijk zoek is dat er naar de load van de VPS wordt gekeken en uitgeweken wordt naar een VPS met minder load.

Wallets & coins als in bitcoin? En die wallets zijn op meerdere servers tegelijk bereikbaar? Ik snap er niks van.
Wat voor protocol spreek je met die wallets? Is dat protocol geschikt voor loadbalancing? Is alle data op alle nodes aanwezig? Heb je echt geen controle over welke poorten er gebruikt worden?
Ik snap ook niet waarom je tien identieke VMs op dezelfde hardware wil draaien. Waarom heb je tien "aanspreekbare servers" nodig en wat kunnen 10 VMs wat een losse server niet kan?

[Yzord]

Simpelweg omdat daar voor is betaald. Als de opdrachtgever een server afneemt welke in 10 nodes omgebouwd moet worden met ieder een exacte kopie van node1, dan lever je dat gewoon. Ook omdat degene die dit heeft afgenomen weet wat hij doet. Hij wilt 10 aanspreekbare IP's hebben die allemaal hetzelfde doen en daar zal de bottleneck zitten. Ik kan nu wel heel wijs tegen hem gaan zeggen dat hij alles op 1 server moet draaien, maar daar betaald hij niet voor

Daarbij 110+ wallets draaien op 1 node? Al wetende dat een wallet welke zijn blockchain aan het binnenhalen is alle CPU resources kan opeten. Dan lijkt het me juist 100% verstandig als je je resources verdeelt en zodoende 1 wallet niet alle cores gaat gebruiken en 109+ wallets in de kou laten staan. Gezien het doel van de server lijkt me dat onaanvaardbaar voor de opdrachtgever.

tcp 0 0 127.0.0.1:9332 0.0.0.0:* LISTEN 3449/./litecoind
tcp 0 0 0.0.0.0:10101 0.0.0.0:* LISTEN 3916/./boolbd
tcp 0 0 0.0.0.0:9333 0.0.0.0:* LISTEN 3449/./litecoind
tcp 0 0 127.0.0.1:10102 0.0.0.0:* LISTEN 3916/./boolbd
tcp 0 0 127.0.0.1:51990 0.0.0.0:* LISTEN 3623/./opalcoind
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 2437/sshd
tcp 0 0 0.0.0.0:14631 0.0.0.0:* LISTEN 13837/./BitcoinDark
tcp 0 0 127.0.0.1:14632 0.0.0.0:* LISTEN 13837/./BitcoinDark
tcp 0 0 0.0.0.0:62123 0.0.0.0:* LISTEN 16781/./bitstard
tcp 0 0 127.0.0.1:58683 0.0.0.0:* LISTEN 4319/./vericoind
tcp 0 0 127.0.0.1:62124 0.0.0.0:* LISTEN 16781/./bitstard
tcp 0 0 127.0.0.1:8332 0.0.0.0:* LISTEN 14329/bitcoind
tcp 0 0 0.0.0.0:58684 0.0.0.0:* LISTEN 4319/./vericoind
tcp 0 0 0.0.0.0:50990 0.0.0.0:* LISTEN 15535/./opalcoind
tcp 0 0 127.0.0.1:7767 0.0.0.0:* LISTEN 1603/ruby
tcp 0 0 0.0.0.0:3000 0.0.0.0:* LISTEN 1599/ruby
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN 1361/master
tcp 0 0 :::11920 :::* LISTEN 7360/./vpncoind
tcp 0 0 :::7777 :::* LISTEN 13926/./SuperNET
tcp 0 0 ::1:11921 :::* LISTEN 7360/./vpncoind
tcp 0 0 :::7778 :::* LISTEN 13926/./SuperNET
tcp 0 0 :::7874 :::* LISTEN 13283/java
tcp 0 0 ::1:7787 :::* LISTEN 1590/ruby
tcp 0 0 ::ffff:127.0.0.1:7876 :::* LISTEN 13283/java
tcp 0 0 ::1:9332 :::* LISTEN 3449/./litecoind
tcp 0 0 :::9333 :::* LISTEN 3449/./litecoind
tcp 0 0 ::1:51990 :::* LISTEN 3623/./opalcoind
tcp 0 0 :::22 :::* LISTEN 2437/sshd
tcp 0 0 :::14631 :::* LISTEN 13837/./BitcoinDark
tcp 0 0 ::1:14632 :::* LISTEN 13837/./BitcoinDark
tcp 0 0 :::54121 :::* LISTEN 14194/java
tcp 0 0 :::62123 :::* LISTEN 16781/./bitstard
tcp 0 0 ::1:58683 :::* LISTEN 4319/./vericoind
tcp 0 0 ::1:62124 :::* LISTEN 16781/./bitstard
tcp 0 0 ::1:8332 :::* LISTEN 14329/bitcoind
tcp 0 0 :::58684 :::* LISTEN 4319/./vericoind
tcp 0 0 :::50990 :::* LISTEN 15535/./opalcoind
tcp 0 0 ::1:25 :::* LISTEN 1361/master
tcp 0 0 ::1:38781 :::* LISTEN 1599/ruby

Dat wordt dus wellicht elke van deze poort openen, alleen vrees ik dat het poorten zijn die generiek worden gekozen. Ik heb ze niet ergens vast staan in een config.

Ik zou natuurlijk in elke config dit kunnen toevoegen:

port=11920
rpcport=11921

Om de poorten vast te kunnen zetten.

[ Voor 73% gewijzigd door Yzord op 29-12-2014 20:55 ]

[CAPSLOCK2000]

Ok, de "geld is geld" insteek. Ik zal niet meer in gaan op de vraag of dit een goede oplossing voor het probleem van je opdrachtgever is en direct over gaan op mijn conclusie:

Je hebt geen loadbalancer nodig.
Verdeel de wallets over je VPS'en en vertrouw op het toeval om de load te balanceren.

Een traditionele loadbalancer werkt met inkomende verbindingen. Voor iedere nieuwe verbinding wordt bepaald door welke node die verbinding kan worden aangenomen. Jij hebt echter niks te kiezen, iedere transactie hoort bij een bepaalde wallet en kan alleen door die ene wallet worden afgehandeld. Je kan dus alleen maar doorsturen, niet balanceren. Doorsturen is dan zinloos, je wint er niks mee. Sterker nog, waarschijnlijk wil iedereen direct met het IP-adres van de nodes praten en niet met dat van de server.

Eventueel kun je een scriptje maken om wallets naar een andere VPS te verplaatsen als er toevallig een stel zware wallets op dezelfde VPS terecht komen. Ik zou ook een scriptje schrijven om te monitoren hoeveel load iedere wallet genereert zodat je weet welke nodes je moet verplaatsen.

Nou vooruit, toch nog een stukje mening: Persoonlijk zie ik het nut van VMs niet voor zo'n server. IMHO maakt het de zaak alleen maar complexer en levert het niks op. Je hebt geen VMs nodig om processen te beperken tot bepaalde IP's of CPU's. De scheduler in de Linux-kernel heeft voldoende mogelijkheden om te voorkomen dat processen elkaar verdrinken.

[GeeMoney]

Is iets simpels als een round-robin DNS truukje niet mogelijk?

Niet echt load-verdeling op basis van resources maar doet wel ongeveer wat je vraagt?

[CAPSLOCK2000]

Volgens mij gaat dat niet werken. Een wallet is op precies 1 systeem actief. Daar valt niks aan te balancen, andere nodes hebben de data niet en draaien de service niet.

[Yzord]

Alle nodes hebben de wallets draaien...dus zoiets zou mogelijk moeten zijn

[Blokker_1999]

Er is 1 ding waar ik mijn hoofd niet direct rond krijg: hoe ga je balanceren wanneer alles op 1 hardwarematige host draait? Het lijkt me net dat je je performance naar beneden gaat halen door de virtualisatie die je er tussen steekt alsook de eventueel benodigde software om alles te balanceren. Als het doel is om een maximale performantie eruit te halen en je kan/wil niet schalen in de hardware, dan moet je die hardware toch zo efficient mogelijk inzetten lijkt mij.

En wil je voorkomen dat een process alle CPU kracht naar zich toetrekt, beperk dan het aantal rekenkernen dat zo een proces mag aanspreken en zorg ervoor dat die processen met een zeer lage prioriteit draaien.

[Yzord]

Persoonlijk, maar dat is dan ook echt mijn mening, denk ik dat wanneer ik een dedicated server 110+ wallets laat draaien op 1 OS dat dit meer performance problemen oplevert dan wanneer ik dit verdeel over 10 nodes. Maar dat is mijn logische gedachte hierover hoor.

Stel ik zou alles op 1 dedicated server zetten en er zou maar eens wat fout gaan (zou zomaar kunnen dat je van de 110+ wallets er tien hebt die willen syncen) dan houdt meteen de hele server er mee op. Nu kan er een node uitvallen vanwege te hoge load, maar blijven er in ieder geval 9 draaien.

Daarbij heb ik de performance tuning redelijk onder de knie inmiddels. Mijn nodes met 11 wallets per stuk hebben een load van 0.32 per 15 minuten wat ik vrij netjes vindt. Ik zou de load van 1 OS met 110+ wallets niet eens willen weten aangezien je daar vrij weinig aan kan "tunen". Gezien mijn ervaring van de laatste 2 weken denk ik dat de load daarvan een stuk hoger ligt dan 10 x 0.32. Nu kan ik met de virtualisatie software in ieder geval de resources netjes verdelen.

[ISaFeeliN]

Als de machines in hetzelfde subnet zitten met z'n allen, zou je daarvoor prima LVS kunnen gebruiken met keepalived in DR modus. Die kun je op wlc (weighted least connections) laten load balancen (en door DR is dat dan ook nog transparant), eventueel met een persistence erbij zodat clients op een specifieke real_server blijven hangen. Met custom healthchecks kun je load monitoren van je real_servers en aan de hand daarvan real_servers even ontlasten, of je laat dat uberhaupt aan je healthchecks over - als de load op een real_server te hoog wordt zou die healthcheck ook kunnen zorgen dat een real_server er even uitgehaald wordt tot de load weer gezakt is.

https://github.com/acasse.../keepalived.conf.SYNOPSIS

[CAPSLOCK2000]

Yzord schreef op woensdag 31 december 2014 @ 19:53:
Persoonlijk, maar dat is dan ook echt mijn mening, denk ik dat wanneer ik een dedicated server 110+ wallets laat draaien op 1 OS dat dit meer performance problemen oplevert dan wanneer ik dit verdeel over 10 nodes. Maar dat is mijn logische gedachte hierover hoor.

Stel ik zou alles op 1 dedicated server zetten en er zou maar eens wat fout gaan (zou zomaar kunnen dat je van de 110+ wallets er tien hebt die willen syncen) dan houdt meteen de hele server er mee op. Nu kan er een node uitvallen vanwege te hoge load, maar blijven er in ieder geval 9 draaien.

Daarbij heb ik de performance tuning redelijk onder de knie inmiddels. Mijn nodes met 11 wallets per stuk hebben een load van 0.32 per 15 minuten wat ik vrij netjes vindt. Ik zou de load van 1 OS met 110+ wallets niet eens willen weten aangezien je daar vrij weinig aan kan "tunen". Gezien mijn ervaring van de laatste 2 weken denk ik dat de load daarvan een stuk hoger ligt dan 10 x 0.32. Nu kan ik met de virtualisatie software in ieder geval de resources netjes verdelen.

Resources verdelen is een van de primaire taken van een OS. Binnen een OS heb je meer mogelijkheden om je load te balanceren dan in een virtualisatieomgeving. En het is makkelijker om alleen je OS te tunen dan zowel virtualisatie als je OS te gebruiken. Je load hangt af van hoeveel processen de CPU willen en hoeveel CPU je hebt. Daar een virtualisatielaag tussen stoppen veranderd niks. Gebruik vooral de tools die je kent en doe wat je goed dunkt maar ik denk dat het de moeite waard kan zijn om wat meer te leren over resource-management onder Linux.

[GeeMoney]

CAPSLOCK2000 schreef op woensdag 31 december 2014 @ 16:11:
Volgens mij gaat dat niet werken. Een wallet is op precies 1 systeem actief. Daar valt niks aan te balancen, andere nodes hebben de data niet en draaien de service niet.

Vereiste van mijn truuk is inderdaad dat ze allemaal exact dezelfde data kunnen behandelen.
Ik maakte uit zijn verhaal op dat dat zo is.

Lijkt me een tamelijk eenvoudig en goedkope truuk om in ieder iets aan balancing te doen.
Alle andere opties geven wel beter resultaat maar vergen ook veel meer inzet.

Overigens kan ik maar 1 reden bedenken waarom je dit onder 10 virtuals zou willen doen en niet in 1 bak. (al is 10 wel wat veel inderdaad)
De mogelijkheid tot testen/gefaseerd updates/wijzigingen door te kunnen voeren, zonder een al te groot risico op downtime bij fouten.

Als je nu 1 virtual update/wijzigd en die knalt onderuit is er niets aan de hand.

[ Voor 22% gewijzigd door GeeMoney op 01-01-2015 21:21 ]