"Klaus Thuesen" <klth@mail.dk> wrote in message
news:3e4066c0$0$13190$edfadb0f@dread11.news.tele.dk...
> Hej,
>
> Beklager mit første indlæg ikke var så detaljeret som det måske burde have
> været
>
> Informationerne her skal bruges til en 'større skriftlig opgave' jeg er
> igang med at skrive, så det kommer ikke ud i praksisk :) Virksomheden er
en
> dansk tøj producent med årlig omsætning på 100 mio, og som sælger både B2B
> og B2C.
>
> Det er selvfølgelig ikke en eller anden dum dekstop server man skal have
ud
> at have fat i .. - jeg tænker lidt på Dual Xeon 2 ghz, 1 gb ram, 2stk
36gb
> diske kørt op imod RAID 1 systemet ? Hvad kan det koste? 50k?
>
> Samt et backup system med DLT bånd (80gb) som nok ligger omkring de
8-10kg.
>
> Svartider er selvfølgelig vigtig ... skal brugeren kunne navigere frit
rundt
> på siden, må der ikke forekommer svartider på over 1 sekund.
Uden hensyntagen til hvad load der vil komme, så :
Du bør separere database og web front-end på hver sin maskine og derudover
også lave segmentering af firewalls. Databaseserven bør ikke være i samme
segment som front-end servere.
Dernæst bør du tænke i DISA veje, d.v.s. en scale-out løsning hvor designet
tillader at du forholdsvist let kan addere flere identiske front-end servere
hvis det på et senere tidspunkt viser sig at der kommer mere load end den
eksisterende front-end kan klare og/eller udvides til at klare. (hint:
scale-up løber altid, før eller siden, ind i en mur hvor det enten ikke kan
lade sig gøre at få hurtigere isenkram, eller at det koster så meget at det
ikke kan forsvares økonomisk).
M.h.t. scale-out på database serveren så er det mere langhåret, men langt
fra umuligt. Afhængig af platform så kan du f.eks. med Oracle 9i RAC let
løse dette problem. Jeg ved ikke om Microsoft har noget tilsvarende til SQL
Server.....jeg roder ikke med Microsoft/Windows produkter.
Hvis du på forhånd planlægger at udnytte DISA så implementér løsningen med
en god (og redundant) hardware load balancer som entry-point. Det gør det
hele meget lettere.
Du kan med fordel starte ud med 2 front-ends og lade den ene køre som fast
produktions-front-end mens du kan bruge den anden til at prøve ting af på
før du sætter det i produktion og sekundært lade den være failover hvis den
primære front-end fejler eller bliver overbelastet. Dette er ofte benyttet
og det betaler sig da du uden at påvirke driften derved kan opgradere
operativsystem, skifte hardware, prøve nye features o.s.v. Det gøres blot
ved at sige til load-balanceren at den skal se bort fra den maskine du
"leger" med og istedet bruge den/de andre. Når du så er færdig med din
opgradering/omkonfigurering og ved at den virker så kan du fortælle
load-balanceren at nu skal den kun bruge denne nye maskine og undlade at
bruge de andre. Dernæst kan du i ro og mag opgradere dem.
Flerlags-modellen er også fordelagtigt set ud fra load type. En webserver
har typisk et helt andet load mønster end en database server og stiller
derfor andre krav til hardwaren. Så vidt jeg husker har Anandtech for ikke
så forfærdelig lang tid siden skrevet en længere artikel netop om dette i
forbindelse med et hardware skift. Artiklen beskæftiger sig kun med x86
hardware, men det er samme historie på større maskiner.
Front-end boxe kan ofte med fordel være 1-2 unit rack maskiner uden de store
features m.h.t. diskplads o.s.v.
På database-siden er det naturligvis også godt at have 2 for at opnå NSPOF,
men database-servere, og specielt database-licenser, er ofte de tunge poster
på fakturaen, så det er muligt at dette af økonomiske årsager ikke kan lade
sig gøre.
Som lappe-løsning kan du så kopiere produktions-basen eller dele af den til
en test database og så teste imod den fra den sekundære front-end.
NSPOF gælder naturligvis også netværket du forbinder tingene med. Redundant
switch og redundant netværkforbindelse til alle enheder.
Det hele bør naturligvis sættes på UPS.
Hvis det er tilpas kritisk kan det betale sig at lave det som en stretched
løsning, altså 2 seperate computerrum med en halvdel i hver. Du skal dog op
i noget dyrt isenkram (& software), meget dyrere end det du lægger op til,
før du kan implementere dette korrekt med real-time spejl & failover af alt.
I en sådan løsning bør det også overvejes at benytte 2 forskellige ISPs som
backbone, så du med lidt DNS gymnastik kan gelejde kunderne over på den del
af dit setup der kører på den anden ISP.
Påtænkes det at køre flere ting parallelt så forsøg at køre det som
solution-sets fremfor at kaste en masse gejl oveni hinanden på en enkelt
server. Før eller siden giver det problemer a la "løsning 1 kræver at vi
opgraderer Apache, men løsning 2 virker pt. kun med den Apache version vi
har nu". Hvis det istedet proppes på seperate maskiner så frigøres du for
den slags bindinger.
Backup. Du nævner DLT 80GB. Hvem skifter bånd når backuppen fylder 81 GB ?
Du bør beregne datamængden, og hvis der vælges en 1-drive løsning så sørg
for at der er rigeligt med margin til både full & differential backup, eller
hav en procedure klar (og med kalkulerede costs) hvis nogen skal skifte bånd
manuelt.
Ellers køb en jukebox/robot løsning.
/Jesper