Denna delen av 99 uppdateras inte längre utan har arkiverats inför framtiden som ett museum.
Här kan du läsa mer om varför.
Mac-nyheter hittar du på Macradion.com och forumet hittar du via Applebubblan.

Välja riktigt snabb Apache server

Tråden skapades och har fått 24 svar. Det senaste inlägget skrevs .
1

Jag håller på att titta på en ersättare för dom fem Xserve G5 vi använder idag som webbservrar. Istället för flera lastbalanserade maskiner vill jag ha en fetingburk helt enkelt.

Med utgångspunkt i Unix/Linux och Apache i grunden (inte MySQL) hade det varit intressant att höra förslag på hårdvara. Utgå ifrån att det måste vara en rackmonterad "märkesdator" och att vi tänkt köra RAID-10 (4 diskar + hotspare) samt 16-32GB RAM. Maxpris runt 100.000kr exkl moms.

  • Medlem
  • Lund
  • 2007-11-30 12:29

Ta en titt på Suns maskinpark. De har en del bra just för enorma mängder sessioner.

  • Medlem
  • Sundsvall
  • 2007-11-30 19:11

Sun eller HP, etablerade och bra serverhårdvara.

Ursprungligen av Sidde:

Sun eller HP, etablerade och bra serverhårdvara.

Sun burkarna är sjukt dyra!

Sun Fire X4450 Server
B15-VZ4-FC-16G-KD6
Sun Fire X4450 x64 Rackmount Server, 4 Quad-Core Intel Xeon X7350 processor (2 x 4 MB L2, 2.93 GHz, 1066 MHz FSB, 130W), 16 GB memory (8 x 2 GB PC2-5300 667 MHz ECC fully buffered DDR2 DIMMs), 4 x 146 GB 10000 rpm 2.5 SAS disk drives, 8-port intl SRL RAID PCIe card, DVD+/-RW drive, 2 PSU, Embedded LOM, 4 x 10/100/1000 Ethernet ports, 5 USB 2.0 ports, 6 PCIe slots, Solaris 10 Operating System and JES preinstalled, RoHS-5 Compliant
SEK 176.600,00

Den är 50% dyrare än motsvarande Proliant med samma specs såvitt jag kan se. Iofs kör den Solaris 10 istället för SUSE 10.

  • Medlem
  • Sundsvall
  • 2007-11-30 19:34

Efter lite diskussion på irc med folk inom serverbranchen bland annat var det övervägande åsikterna att lastbalanserade med sticky sessions och flera maskiner en billigare och bättre lösning, samt att det erbjuder redudans.

En maskin som ska ta denna mängd trafik kommer kräva rätt mycket, en annan lösning är ju att stoppa in nyare servrar eftersom, kanske köpa 1 server från sun för 20-30k med solaris och köra apache i den och ha detta i racket, tillsammans med de andra. Och eftersom byta ut de andra om man vill det.

  • Medlem
  • Varberg
  • 2007-12-01 01:19

RAIS! Redundant Array of Independent Servers.

Jag tror mer på flera mindre burkar, än en fet.

  • Medlem
  • Sollentuna
  • 2007-12-01 14:28

Hur många ägg vill du ha i samma korg?

Det finns rätt stora administrativa problem med att hantera flera lastbalanserade servrar.

Problemen gör att utvecklingstakten för sajten bromsat upp eftersom det är så struligt att göra småändringar (en ändrad fil måste ändras på 5 ställen).

Även om risken för totalt driftstopp ökar (single point of failure) finns det redan så många andra felkällor att det inte är en faktor. MySQL servern, lastbalanseraren, switchen och servern som sköter statiska filer skulle alla göra att sajten stannar ändå.

  • Medlem
  • Sundsvall
  • 2007-12-01 20:25
Ursprungligen av Björnström:

Det finns rätt stora administrativa problem med att hantera flera lastbalanserade servrar.

Problemen gör att utvecklingstakten för sajten bromsat upp eftersom det är så struligt att göra småändringar (en ändrad fil måste ändras på 5 ställen).

Med en gemensam filserver skulle detta inte behövas.

Ursprungligen av Sidde:

Med en gemensam filserver skulle detta inte behövas.

Men om du har en gemensam filserver där allt lagras så är du tillbaka till single-point-of-failure. Om filservern stannar så stannar allt

Vilken SUN maskin rekommenderar ni?

Jag är inne på en HP DL580G5 med 4st Quadcore Intel Xeon (Penryn)...

  • Medlem
  • Stockholm
  • 2007-12-01 20:42
Ursprungligen av Björnström:

Vilken SUN maskin rekommenderar ni?

Jag är inne på en HP DL580G5 med 4st Quadcore Intel Xeon (Penryn)...

Suns niagara baserade maskiner skall ju vara ena riktiga monster, T1 / T2

Men problemet med att filer måste ändras 5 gånger är lätt att lösa, antingen med en separat filserver (även om det är overkill för forum kod endast). lättare är ju att ha en testmaskin, denna kör commit mot cvs/svn som produktionsmaskinerna sedan kör auto-checkout mot varje natt, ger en förutbestämd och kontrollerbar produktions utrullning.

Problemet med en maskin är ju det att även om du köper ett riktigt monster så har den bara X mängd I/O bandbredd etc, du får mer sidor per sekund med flera lite billigare maskiner än ett monster..

I slutändan handlar det ju endå mer om vad som ni är vana med.. clusterlösningar är dock rätt lätta att hantera om man bara tänker till innan man sätter upp allt, skulle tro att det vore lättare att flytta sidan till en centraliserad utveckling och distrubierad användingsmodel än att handla nytt om det nu är utvecklingen av sidan som det hänger på

  • Medlem
  • Stockholm
  • 2007-12-01 21:21

Klurade lite på hur jag skulle lösa det, blev en rätt standard lösning

http://www.dnz.se/img/99.se.png

sql.99.se & dispatcher.99.se: är precis som det låter, SQL server respektive lastbalanserare.

dev.99.se: All utveckling av sidan görs på denna, som nodeX (1,2,3,4 etc) synkar mot på beställning, eller om man vill göra det ännu smidigare, så kan noderna i klustret nätboota mot dev.99.se, så även eventuella uppdateringar till OS och programvara bara behöver uppdateras på ett ställe (sql & lastbalanserare lär vara specialeriserade).

Vid nätboot, så är det trivialt egentligen att addera mer noder för att växa med ökande belastning, stoppa den i racket och PXE boota den nya noden

Ursprungligen av ntity:

Klurade lite på hur jag skulle lösa det, blev en rätt standard lösning

dev.99.se: All utveckling av sidan görs på denna, som nodeX (1,2,3,4 etc) synkar mot på beställning, eller om man vill göra det ännu smidigare, så kan noderna i klustret nätboota mot dev.99.se, så även eventuella uppdateringar till OS och programvara bara behöver uppdateras på ett ställe (sql & lastbalanserare lär vara specialeriserade).

Vid nätboot, så är det trivialt egentligen att addera mer noder för att växa med ökande belastning, stoppa den i racket och PXE boota den nya noden

Hur rekommenderar du att man synkar ut ändringar mot noderna från Dev?

Ovanstående lösning är ju precis som vi har det idag...fem frontend noder, lastbalanserare och MySQL server. Utöver detta även en dedicerad server för avatars, css, bilder och annat som kräver en unik burk.

Hanteringen av ovanstående är just vad jag ställer mig tveksam till - hade varit så grymt skönt att ha en snabb webserver och en snabb MySQL.

  • Medlem
  • Stockholm
  • 2007-12-02 15:04
Ursprungligen av Björnström:

Hur rekommenderar du att man synkar ut ändringar mot noderna från Dev?

Ovanstående lösning är ju precis som vi har det idag...fem frontend noder, lastbalanserare och MySQL server. Utöver detta även en dedicerad server för avatars, css, bilder och annat som kräver en unik burk.

Hanteringen av ovanstående är just vad jag ställer mig tveksam till - hade varit så grymt skönt att ha en snabb webserver och en snabb MySQL.

CVS/SVN, har själv använt det vid flertalet tillfällen för confer och framförallt av zone filer till bind, ändra på ett ställe och resten av noderna synkar upp, så att om du ändrar eller arbetar på forumkoden så hanteras denna på en central plats.

Att sedan synka upp noderna är enkelt, antingen använder man cron om man vill att de skall synka upp exempelvis varje natt eller så, eller så ssh med public key auth (min favorit) där man enkelt skapar ett script på dev som går ut till noderna och startar en synkning.

Ursprungligen av Björnström:

En filserver där allt samlas skulle naturligtvis lösa detta - men då ser jag inte poängen med balanseringen eftersom man ändå bygger på single-point-of-failure på filservern.

Lastbalansering har inget med tillgänglighet att göra, om det är det som du är ute efter så är det redundans som du måste planera för..

Att gå över till en maskin för webb delen och en för SQL ger dig varken lastbalansering eller HA (redundans) oavset vad som det står i reklamen om maskinen som du kollar på

Ursprungligen av ntity:

Lastbalansering har inget med tillgänglighet att göra, om det är det som du är ute efter så är det redundans som du måste planera för..

Att gå över till en maskin för webb delen och en för SQL ger dig varken lastbalansering eller HA (redundans) oavset vad som det står i reklamen om maskinen som du kollar på

Lastbalanseringen för oss ger visst redundans - fallerar en node så står fyra kvar och svarar. Men vi har fortfarande flera "single point of failure" i kedjan.

Självklart ger inte en Frontend och en Backend maskin varken redundans eller lastbalansering, kan inte tänka mig att någon skulle påstå det. Min poäng är dock att vi kan leva med det - vinsten i att samla allt i en maskin är större än risken för nertid och "kostnaden" i form av komplex miljö.

SUN känns inte som något för oss.

  • Medlem
  • Stockholm
  • 2007-12-02 13:43

Satsa på en vettig synk mot dina frontends. (vi kan titta på det vid tillfälle om du vill)

Sen är xserve intel med leopard sjukligt snabbt om du jämför med xserve g5 med tiger.

Ursprungligen av glemme:

Satsa på en vettig synk mot dina frontends. (vi kan titta på det vid tillfälle om du vill)

Ett problem med lastbalanseringen är också att noderna genererar unikt material - exempelvis när någon laddar upp attachments, avatars osv. Även CSS:erna genereras dynamiskt och om man kör lastbalanserat kan alltså materialet hamna var som helst.

En filserver där allt samlas skulle naturligtvis lösa detta - men då ser jag inte poängen med balanseringen eftersom man ändå bygger på single-point-of-failure på filservern.

  • Medlem
  • International user
  • 2007-12-02 19:11

Hellre Solaris än SUSE även jag gillar bägge. Förresten vill jag minnas att du kan tanka hem Solaris 10 fritt från SUNs sida till intel.

  • Medlem
  • Stockholm
  • 2007-12-03 11:04
Ursprungligen av Lm:

Hellre Solaris än SUSE även jag gillar bägge. Förresten vill jag minnas att du kan tanka hem Solaris 10 fritt från SUNs sida till intel.

yepp, kallas opensolaris.

  • Medlem
  • International user
  • 2007-12-03 12:17
Ursprungligen av ntity:

yepp, kallas opensolaris.

Jo, jag vet men inte den jag tænker på

http://www.sun.com/software/solaris/get.jsp

  • Medlem
  • Stockholm
  • 2007-12-03 13:27
Ursprungligen av Lm:

Jo, jag vet men inte den jag tænker på

http://www.sun.com/software/solaris/get.jsp

jepp media för att installera och "licens" så att säga får du gratis, det har det iofs varit länge, men om du skall ha solaris riktigt gratis med "comunity support" som de kallar det etc är det opensolaris som gäller..

har det även för att man inte får de senaste uppdateringarna eller så till solaris om man inte har support avtal som kostar pengar (eller kör opensolaris) men det kanske de har slutat med nu, inte kollat.

Ursprungligen av Brörnström:

Lastbalanseringen för oss ger visst redundans - fallerar en node så står fyra kvar och svarar. Men vi har fortfarande flera "single point of failure" i kedjan.

Självklart ger inte en Frontend och en Backend maskin varken redundans eller lastbalansering, kan inte tänka mig att någon skulle påstå det. Min poäng är dock att vi kan leva med det - vinsten i att samla allt i en maskin är större än risken för nertid och "kostnaden" i form av komplex miljö.

SUN känns inte som något för oss.

Min poäng var som det att om man inte satsar på riktig redundans så är inte tillgänglighet att tala om egentligen, det är som inte så att man kan skapa en lösning som är till hälften tillgänglig, antingen ar sakerna redundanta eller inte

Dock det som jag mest har emot singel servern lösningen är att då (inte om) sidan växer ur servern krävs det en ny 100k+ investering, iställer för en investering i en klart billigare extra nod i clustret..

  • Medlem
  • International user
  • 2007-12-03 14:23
Ursprungligen av ntity:

jepp media för att installera och "licens" så att säga får du gratis, det har det iofs varit länge, men om du skall ha solaris riktigt gratis med "comunity support" som de kallar det etc är det opensolaris som gäller..

har det även för att man inte får de senaste uppdateringarna eller så till solaris om man inte har support avtal som kostar pengar (eller kör opensolaris) men det kanske de har slutat med nu, inte kollat.

Kør du en kritisk driftmiljø så brukar ju dem pengarna vara en piss i sjøn gentemot stillestånd, fast nu børjar vi glida OT.

  • Medlem
  • Stockholm
  • 2007-12-03 15:23
Ursprungligen av Lm:

Kør du en kritisk driftmiljø så brukar ju dem pengarna vara en piss i sjøn gentemot stillestånd, fast nu børjar vi glida OT.

kan tänka mig att det förkommit avrundningsfel större än den kostnaden där jag jobbar nu

  • Medlem
  • Stockholm
  • 2007-12-07 22:36

Måste hålla med övriga att en lastbalanserad och redundant miljö är klart bättre än en feting maskin.

I ett tidigare liv satsade vi på feta maskiner som funkade jättebra tills lasten ökade och vi behövde bygga ut. Att komplettera med ytterligare hårdvara var ju extremt dyrt. Ett problem är ju att man köper något som är bra för det mesta men inte specialiserad. Olika applikationer kräver ju olika typer av konfigurationer.

Den dyraste delen för websystem är normalt disksystemen och då speciellt för databaserna. Om du tycker att replikering ala ntitys rekommendentationer är dåligt kan du ju satsa på någon enklare form av san lösning. Ärligt talat så kör ni ju ingen jättestor lösning

Jag skulle satsa enligt nuvarande modell, som ntity har skissat upp. Eventuellt även slänga in en eller ett par generella standby maskiner. Dels för att ha emergency failover för databasen men även som extra vid behov.

Mitt område är ju inte hårdvara så utifrån mitt perspektiv skulle jag även gå över arkitekturen på hela lösningen. Nu vet jag inte vad som är flaskhalsen men du kan ju även överväga att sprida ut databasen på flera maskiner. Då får du ju redundans och failover lite gratis samt att du kan ha billigare maskiner som kan dela på lasten. Själva siten känns tung att ladda hem. Där kanske man kan se över arkitekturen och få sidorna att rendera snabbare och cacha mer av db och php bearbetningarna.

1
Bevaka tråden