[MiniAnton]

Jag skulle uppskatta tips och råd kring setup och val av VPS.

Vi kommer lansera en ny webbtjänst i januari som bl a kommer innebära att vi kommer att ha ett stort antal registrerade medlemmar med klientmedelskonton. Dvs vårt behov av säkerhet och tillgänglighet är hög.

Redan idag har vi en VPS hos en svensk host som det kör en SQL-server på och vi kommer att använda denna databas även för den kommande webbtjänsten. Men frågan är hur/var vi ska hosta vår webbserver (IIS - det är utvecklat i asp.net). Är det rekommenderat att hosta både databasserver och webbserver på samma VPS?

Jag kan själv inte så mycket kring detta, men har hört genom åren att man bör separera databasserver och webbserver, men har aldrig riktigt fått klart för mig vad orsakerna är till att den rekommendationen ges. Är det pga säkerhetsskäl? Frågan är om dessa rekommendationer fortfarande gäller - och om de även gäller när man har VPS hosting?

Vår kommande webbtjänst kommer att vara helt databasdriven så om databasen inte är tillgänglig så spelar det heller ingen roll om IIS´en är uppe eftersom webbtjänsten ändå inte kan fungera utan databasen.

[gregoff]

Tycker inte du ska tänka att du ska ha separata burkar för att det skulle vara säkrare. Du ska snarare tänka på att ha separata burkar på om du vill kunna skala bättre i framtiden.

Det hela beror även på storleken av databasen. Har du några enstaka tabeller med kanske upp till 1 miljon rader så finns det ingen anledning att krångla till det med att dela upp applikationen och databasen.

Svårt att ge ett konkret svar när man inte vet hur produkten ser ut (och framför allt kommer att se ut och hur det hela kanske kommer växa).

[Jim_Westergren]

Du kan uppnå en viss högre säkerhet genom att sätta upp så att endast din applikationsserver kan koppla till din databasserver och att din databasserver inte kan nås från det publika internet. Om din applikationsserver skulle bli hackad så har de inte root access till din DB.

Rent prestandamässigt så tror jag inte det ska spela någon större roll såvida du inte direkt räknar med att få mer besökare än aftonbladet. Bättre då att satsa på bra cachning, varnish osv.

Tänk även på att genom att dela upp det så har du nu 2 points of failure istället för 1 - det var i alla fall den avgörande faktorn för mig själv att ha kvar det på samma server. Och några hundra queries per sekund bör inte vara några problem om din applikation är bra byggd.

[MiniAnton]

Tack båda för er input!

[coredev]

Jag kapar tråden för en relevant följdfråga: Vad bör man ha för prestanda (ram, cpu, etc) på en VPS som skall köra både webb och databas (samt ev cachning, redis, etc)?

[gregoff]

Ursprungligen postat av coredev

Jag kapar tråden för en relevant följdfråga: Vad bör man ha för prestanda (ram, cpu, etc) på en VPS som skall köra både webb och databas (samt ev cachning, redis, etc)?

Om det är rätt eller fel vet jag inte men vad jag gjorde var helt enkelt att skapa en VPS sen uppgradera/nedgradera efter behov. Till slut landade jag på ett bra "mellanläge" som fungerade ok i alla väder.

Vissa leverantörer tillåter dessutom att du kan uppgradera maskinen ifrån maskinen själv. På så vis kan du t.ex. lägga på mer ram-minne vid minnesintensiva operationer osv eller lägga på fler cpu-kärnor vid tunga beräkningar osv.

[Clarence]

Ursprungligen postat av MiniAnton

Jag skulle uppskatta tips och råd kring setup och val av VPS.

Vi kommer lansera en ny webbtjänst i januari som bl a kommer innebära att vi kommer att ha ett stort antal registrerade medlemmar med klientmedelskonton. Dvs vårt behov av säkerhet och tillgänglighet är hög.

Hanterar du klientmedelskonton bör din säkerhet efterspegla detta. Rör det sig om tillräckligt stora summor att du vid säkerhetsintrång inte har råd att ersätta dina kunder bör du verkligen vidta större säkerhetsåtgärder och den viktigaste är din datahantering.

Det borde dels innebära att din databas inte är åtkomlig externt. Men även att kommunikationen med den part som nås via internet (webbserver) bara kan göras på ett sätt som är fullt spårbart, t ex genom att uppdatering sker via event sourcing vars representation enkelt kan återställas till ett tidigare state genom inverterade events. Detta ska också replikeras och backupas på ett tillförliligt sätt med korta intervaller. Helst ska alla events vara säkert backupade innan representationen uppdateras med dom.

Om du nöjer dig med något mindre skulle jag verkligen kolla på ansvaret du har i lagen för den verksamhet du tänkt bedriva så du inte får arga finansiellt starka användare på dig för din bristande säkerhet.

Prestandamässigt kan det vara både bra och dåligt att separera databas och webbserver. Det kan vara bra då många script som körs på en webbserver kräver mycket rörlighet i ram-minnet och konsumerar mycket minne ena sekunden som det sedan släppper omgående, medans databasen normalt presterar bättre genom att kunna ha en bra mängd minne tillgängligt för cachad data som den slipper tävla om. Sämre blir det för att du har en network latency mot en annan server, normalt sätt är det inget större problem, men vet du inte hur bra det interna nätet hos din VPS-leverantör är finns det anledning att undersöka det först. De flesta mindre (redan snabba) sajterna blir minimalt snabbare av att ha databasen på samma server just pga nätverks-latencyn.

[Clarence]

Ursprungligen postat av coredev

Jag kapar tråden för en relevant följdfråga: Vad bör man ha för prestanda (ram, cpu, etc) på en VPS som skall köra både webb och databas (samt ev cachning, redis, etc)?

För 1 eller 2000 requests i sekunden? För 50 eller 99,9% procents cache via memcache? För 5 raders enkel datahanterande i php eller ett fullständigt ramverk i python med tunga templates och avancerade beräkningar? För en enkel primary key lookup eller tunga aggregations-queries som genomsnitts-query? Hur långt är ett kort snöre?

[Adestro]

Om utomstående förlitar sig på att tjänsten i princip alltid är tillgänglig finns det väl inget att fundera på. In med lastbalanserare och flera instanser av både appservern och databasservern (kanske ett cache-lager och en filserver också?). Kostar inga jättepengar idag, inte ens med Dotnet.

Om det å andra sidan "bara" är dåligt men inte fullständig katastrof om tjänsten går ner så ser jag ingen anledning att börja mecka med det just nu. Det är trots allt inte så svårt att flytta ut databasen när tiden är kommen. Särskilt inte om tjänsten tål några minuters nertid mitt i natten.

Skulle rekomenderat Azure men de hade ju en riktigt skandallång nertid häromveckan...