[Magnus_A]

Kan finnas en poäng att flytta din databas i förväg innan ompekningen, så slipper du jobba med två olika databaser på två olika ställen. Eller att sätt upp en replikerande server om du inte tål någon nertid alls och är extremt känslig för dataförluster

[abergman]

Vi har våra prylar i CityCloud, och jag är bara nöjd. Det funkar smidigt, supporten är bra och priserna helt helt ok. Eftersom jag själv är tekniker så tycker jag det är jävligt skönt att kunna starta/stoppa/skala maskinerna som jag själv vill och inte vara i händerna på att en supportavdelning ska göra det åt mig.

[mekwall]

Ursprungligen postat av abergman

Vi har våra prylar i CityCloud, och jag är bara nöjd. Det funkar smidigt, supporten är bra och priserna helt helt ok. Eftersom jag själv är tekniker så tycker jag det är jävligt skönt att kunna starta/stoppa/skala maskinerna som jag själv vill och inte vara i händerna på att en supportavdelning ska göra det åt mig.

Okej, tack för infon. Försöker sätta upp en testserver hos dem med, men har inte fått något "aktiveringsmail". Kan det ha fastnat i spamfiltret mån tro?

Det jag blir lite konfunderad över när det gäller City Cloud är användningen av bandbredd. Som jag förstår det så är det där det skiljer sig mest mellan dem och GleSYS, att man helt enkelt bara betalar för det man använder. Hos GleSYS behöver man köpa en viss mängd. Misstänker att GleSYS blir billigare per GB om man räknar rakt av men om man ändå inte utnyttjar hela mängden så blir ju kostnaden en helt annan.

Och hur är det med diskprestandan hos City Cloud? Vet inte riktigt vad de har för hårdvarukonfiguration, men har hört rykten om att de har problem på den biten. GleSYS kör väl genomgående med 15k SAS-diskar om jag inte har helt fel.

Majoriteten av vår bandbredd används för att leverera content. T.ex. nedladdningsbara filer eller större bilder. Det känns som att det bästa där hade varit att använda ett CDN, där inte lagringen kostar så mycket. Finns det någon vettig svensk leverantör av Storage/CDN-tjänster?

[mekwall]

Ursprungligen postat av Magnus_A

Kan finnas en poäng att flytta din databas i förväg innan ompekningen, så slipper du jobba med två olika databaser på två olika ställen. Eller att sätt upp en replikerande server om du inte tål någon nertid alls och är extremt känslig för dataförluster

Nja, tror inte det är nödvändigt. Vid flytten kommer nya databasen att synkas så det inte saknas data. Räknar med att detta tar max 10 minuter, men innebär enbart att det kan saknas data under den tiden, men inte att hela sajten behöver vara nere.

Har satt upp en testserver hos GleSYS och redan lyckats replikera hela sajten (på bara några timmar), och då med nginx/php-fpm istället för apache/php-cgi som vi använder idag. Det enda som saknas är nedladdningsbart material. Känns som att en flytt kommer att gå otroligt smärtfritt!

[Magnus_A]

Ursprungligen postat av mekwall

Nja, tror inte det är nödvändigt. Vid flytten kommer nya databasen att synkas så det inte saknas data. Räknar med att detta tar max 10 minuter, men innebär enbart att det kan saknas data under den tiden, men inte att hela sajten behöver vara nere.

Har satt upp en testserver hos GleSYS och redan lyckats replikera hela sajten (på bara några timmar), och då med nginx/php-fpm istället för apache/php-cgi som vi använder idag. Det enda som saknas är nedladdningsbart material. Känns som att en flytt kommer att gå otroligt smärtfritt!

Även om flytten av data tar 10 minuter tar ompekningen längre tid om det är sant som det står här att vissa isp:er sätter längre tid på TTL än vad du sätter.

[Dennis Holm]

Ursprungligen postat av Magnus_A

Även om flytten av data tar 10 minuter tar ompekningen längre tid om det är sant som det står här att vissa isp:er sätter längre tid på TTL än vad du sätter.

2 enklare versioner av vad man kan göra..

gammal site=iframe till dedikerat ip på nya siten (eller subdomän med (funkar inte om siten har länkar direkt till domän.com/filnamn.php eller scripts som är beroende av domännamnet i urlen)
Extremt lowtech lösning .


Den andra är att gamla siten kopplar till NYA serverns mysql databas.
Då är all databas trafik i sync även om man har siten på 2 ip'n för de besökare som inte fått den nya ompekningen.

Finns fler lösningar men ja. lätt att göra dessa två för deflesta.

[Norman]

Kan ju säga så här. Lagringslösningar för cloud är bra mycket mer avancerat.
Å ena sidan så är driftsäkerheten god, men när det väl strular så kan det va mycket som går ned och det kan va svårt att åtgärda.

Dedicerad server eller co-lo är mindre komplicerad, har god driftsäkerhet och är mindre svårt att fixa om något skulle pajja

[mekwall]

Ursprungligen postat av Norman

Kan ju säga så här. Lagringslösningar för cloud är bra mycket mer avancerat.
Å ena sidan så är driftsäkerheten god, men när det väl strular så kan det va mycket som går ned och det kan va svårt att åtgärda.

Dedicerad server eller co-lo är mindre komplicerad, har god driftsäkerhet och är mindre svårt att fixa om något skulle pajja

Menar du att bara för att det är fler variabler involverade så är det större risk att något strular? Må vara logiskt, men man måste vara en riktig pessimist om man ska följa det till punkt och pricka.

Rätt människor med rätt kompetens på rätt plats, så spelar antalet variabler ingen roll. Detsamma kan man säga om det motsatta, och det är mycket därför jag frågar efter era erfarenheter av de svenska bolagen som tillhandahåller dessa tjänster

[KristianE]

mekwall:
Jag tror snarare Norman syftar på att när ett stort SAN pajar i en stor cloud-
lösning så är man riktigt rökt. Du ska inte förvänta dig att din leverantör har
köpt två identiska SAN med symmetrisk replikering av data. Har de detta är
det jättebra men jag tror inte du ska räkna med det.

I alla fall inte när du betalar några korvören per timme..

[mekwall]

Ursprungligen postat av Magnus_A

Även om flytten av data tar 10 minuter tar ompekningen längre tid om det är sant som det står här att vissa isp:er sätter längre tid på TTL än vad du sätter.

Därför jag har tänkt forwarda/maskera gamla maskinerna (kanske helt enkelt som en proxy) så att de pekar till den nya så att även de som pekas till det gamla IP:t kommer att skickas till rätt plats. På så vis behöver det inte finnas två databaser.