PDA

Bekijk Volledige Versie : Vraag over VPS/Dedi en aantal klanten



Tussendoor
20/09/12, 10:00
Wij overwegen om enkele hosting klanten te gaan bedienen (á 500-1000). De vraag is wat wij het beste kunnen doen.

A. Gaan voor 1 grote VPS machine met veel specs (12GB geheugen, 1000 GB HDD en een X aantal cores). Alles erop en er aan. De VPS zal worden voorzien van een linux distro, in combinatie met Direct Admin. Alle klanten worden geplaatst op deze deze VPS machine en er hoeft dus maar voor 1 machine aan service level (aantal uren ondersteuning per maand + monitoring) ingekocht te worden.

B. Gaan voor meerdere kleinere VPS machines met wat minder specs (2 GB geheugen, 250 GB HDD en 2 cores). Ook deze VPS machines worden voorzien van linux in combinatie met Direct Admin. De klanten worden nu verdeeld over 5 kleinere VPSes (100-200 per VPS). Per machine moet er een service level worden ingekocht.

C. Gaan voor een dedicated oplossing. Ook hier kan je kiezen tussen 1 grote of meerdere kleine machines. Voor mijn gevoel gaat het tegenwoordig allemaal richting VPS maar wellicht hebben jullie een goede motivatie om in deze situatie toch te kiezen voor dedi?

- Eigen servers geen optie. We willen hardware en managed uitbesteden maar de vraag is wat de beste optie is.
- De klanten betreft voornamelijk kleine websites, Wordpress en Magento.
- Wat is de handigste manier om backup te realiseren? Bij didicated of bij VPS?

vDong
20/09/12, 10:13
- De klanten betreft voornamelijk kleine websites, Wordpress en Magento.
Wordpress en Magento zijn perfecte voorbeelden van resource vreters, dus kleine websites zullen het nooit worden.

5 kleinere VPSes (100-200 per VPS)
Dat lijkt me veel te veel overloaded als je bovenstaande bekijkt

Gaan voor 1 grote VPS machine met veel specs (12GB geheugen, 1000 GB HDD en een X aantal cores). Alles erop en er aan. Wellicht een beter idee, alleen ken ik weinig partijen die dit voor een betaalbare prijs kunnen leveren.

Wat ik je wel kan adviseren is om gewoon bij klant 1 te beginnen met een kleinere vps en gewoon eens gaan benchmarken wat sites doen.

Ramon Fincken
20/09/12, 10:35
Ivm schalen en faillure points zou ik zelf voor 2 of 3 VPS-en gaan.
Backups altijd offsite doen, niet enkel op de server zelf (zonde van de opslag).

<knip>

vDong
20/09/12, 10:46
Backups altijd offsite doen, niet enkel op de server zelf (zonde van de opslag).
En daarmee bedoelen we ook niet in hetzelfde rack, niet in hetzelfde gebouw en niet bij dezelfde provider.

systemdeveloper
20/09/12, 12:51
Met 500 klanten moet je nooit gaan voor '1' want 1 storing betekent dan altijd 500 storingen en als je 500 telefoontjes krijgt als de setup van apache 10 minuten verkloot is dan word je niet erg blij.

Daarnaast moet je rekening houden met de backups/cronjobs van directadmin. Als je 500GB aan klantdata hebt (en dan met name veel kleine bstandjes) dan word je ook niet blij in de nacht. Zeker niet als je dan ooknog de backups moet draaien want de DirectAdmin backups kun je beter vergeten met 500gb data.

Dus je kunt beter beginnen met 1 vps bij een hoster die die problemen waar jij nu over nadenkt, al lang heeft getackeld en een goed platform heeft.
Wij bepalen bv. nooit op voorhand 'hoeveel' users er op 1 vps kunnen omdat er geen pijl op te trekken is: 1 user kan 100 domeinen hebben met god weet wat voor sites, de andere kan 24 uur per dag bezig zijn met allerlei imports voor zijn webshop, weer een andere maakt 10 keer per dag een da backup.
Zeker met vpssen wil je uiteindelijk een gezonde belasting op alle onderdelen (ram, cpu, diskio) en er is er maar 1 die dat kan bepalen as you go: je hoster/beheerder.

Backups realiseer je het beste op een vps omdat je daar simpelweg niet aan de hardware gebonden bent zoals je bij een dedi wel bent. Een recovery backup kun je dus redelijk overzetten naar een 'nieuw' vps.

SF-Jeroen
20/09/12, 14:25
Ik zou voor optie B gaan. Je kan eventueel ook overwegen CloudLinux o.i.d. te gebruiken om users te beperken in CPU cycles en RAM gebruik. Anders heb je het risico dat een gebruiker de server omver helpt. Vergeet ook niet MySQL connecties te cappen, en op te letten dat 1 user niet een spamrun veroorzaakt en je mailqueue bomvol zit (en niemand meer mail kan versturen).

avanmessen
21/09/12, 05:30
Persoonlijk ook optie B, iets met "niet alle eieren in dezelfde mand" ...