/ Forside / Teknologi / Hardware / Server / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
Server
#NavnPoint
dk 1398
EXTERMINA.. 1330
webnoob 1267
o.v.n. 820
stone47 800
Klaudi 720
severino 580
granner01 580
rotw 500
10  Uffe29 470
Compaq SA5302 RAID på Linux databaseserver
Fra : Ole Thomsen


Dato : 04-12-02 13:44

Jeg står overfor et skift fra Tru64 til Linux AS 2.1 på en
Oracle databaseserver, hardwaren bliver en Proliant server
og SA5302 RAID controller.

I den forbindelse har jeg bedt Compaq levere et forslag til
sizing, og på disksiden modtaget følgende:

10 diske fordelt med
2 diske i RAID1 til OS
2 diske i RAID1 til logs
6 diske i RAID0+1 til database

Hvori ligger fordelene i ovenstående?

Kunne man ikke med fordel lægge alle diskene i et 0+1
og i stedet partitionere i OS? Det vil for det første sprede
diskoperationerne på flere diske, for det andet give en
større frihed mht. den indbyrdes størrelse af partitionerne.

Det foreslås også at lægge OS og logs på den ene kanal
og db på den anden, hvilket forekommer mig lidt tåbeligt
både ift. performance men også sikkerhedsmæssigt. Hvis
man lægger et stripesæt på den ene kanal og spejler det
på den anden vil systemet jo køre videre selv om en kanal
falder ud.

Kommentarer?

Ole Thomsen



 
 
Flemming Riis (04-12-2002)
Kommentar
Fra : Flemming Riis


Dato : 04-12-02 15:18

"Ole Thomsen" <ot@networks.dk> wrote in message news:3dedf88d$1@mail.ehs.dk

> Jeg står overfor et skift fra Tru64 til Linux AS 2.1 på en
> Oracle databaseserver, hardwaren bliver en Proliant server
> og SA5302 RAID controller.
>
> I den forbindelse har jeg bedt Compaq levere et forslag til
> sizing, og på disksiden modtaget følgende:
>
> 10 diske fordelt med
> 2 diske i RAID1 til OS
> 2 diske i RAID1 til logs
> 6 diske i RAID0+1 til database
>
> Hvori ligger fordelene i ovenstående?

> Kunne man ikke med fordel lægge alle diskene i et 0+1
> og i stedet partitionere i OS?

Du kan risikere at OS operationer som er disk tunge bruger din database IO.

> Det foreslås også at lægge OS og logs på den ene kanal
> og db på den anden, hvilket forekommer mig lidt tåbeligt
> både ift. performance men også sikkerhedsmæssigt. Hvis
> man lægger et stripesæt på den ene kanal og spejler det
> på den anden vil systemet jo køre videre selv om en kanal
> falder ud.

Jeg tror ikke på en 5302 overlever at en kanal dør alligevel, så log/os på 1
kanal og resten på den anden kanal er ikke tosset

Men med så få diske totalt tror jeg det bliver svært at måle forskel på om
alle diskene sidder på den ene kanal i et stort raid 0+1 eller
om det er politisk korrekt opdelt.

Jeg syntes personligt det er spildt af diske at bruge 2 til os med mindre
man pager extremt meget tror jeg du vil se en bedre performance hvis du
lavet 4 til os/log men igen er det tvivlbart om det overhovedet er måleligt.

Få serveren ud 14 dage før det var planlagt og se om du kan mærke en forskel

De fleste (windows) servere jeg roder med vil folk ikke bruge seperate os
diske med mindre de enten har et san eller et meget stort behov for
performance
så bliver log os og data splitter over flere diske/controller/kanaler.

Man skal ikke helt undervudere performancen i en håndfuld moderne diske,
tror de helt hysteriske opdeling er ved at være fortid med mindre det er
extremt
performance krævende systemer.

Men seperate os diske er altid rart men henblik på image og server skift






Lars Kim Lund (04-12-2002)
Kommentar
Fra : Lars Kim Lund


Dato : 04-12-02 19:20

"Flemming Riis" <flemming@riis.nu> wrote:

>Man skal ikke helt undervudere performancen i en håndfuld moderne diske,
>tror de helt hysteriske opdeling er ved at være fortid med mindre det er
>extremt >performance krævende systemer.

Enig - 15k diskene sparker røv, selv på de "små" integrated
controllers. Jeg har set et R1 sæt på en integrated 5i controller give
grundigt baghjul til ældre controllere og langsommere diske i pænt
store stripesæt.

Det er også lidt derfor at jeg tænker lidt på hvor meget man egentlig
opnår ved parallelismen - og især når vi ikke snakker nogle af de
rigtig seje controllers.

>Men seperate os diske er altid rart men henblik på image og server skift

Hvis der er plads så betyder det jo ikke det store. Prisen for dem er
nok ikke det der vælter budgettet når vi taler systemer i denne
størrelsesorden

--
Lars Kim Lund
http://www.net-faq.dk/

Ole Thomsen (05-12-2002)
Kommentar
Fra : Ole Thomsen


Dato : 05-12-02 07:25

"Lars Kim Lund" <lkl@fabel.dk> wrote
>
> Det er også lidt derfor at jeg tænker lidt på hvor meget man egentlig
> opnår ved parallelismen - og især når vi ikke snakker nogle af de
> rigtig seje controllers.

Du mener altså at controlleren bliver en flaskehals og
fordelen ved flere spindler/kanaler falder bort ved brug
af 15K diske på en 53xx?

Du har muligvis ret, men jeg tvivler.

Ole Thomsen




Lars Kim Lund (05-12-2002)
Kommentar
Fra : Lars Kim Lund


Dato : 05-12-02 12:26

Hej "Ole Thomsen" <ot@networks.dk>

>> Det er også lidt derfor at jeg tænker lidt på hvor meget man egentlig
>> opnår ved parallelismen - og især når vi ikke snakker nogle af de
>> rigtig seje controllers.
>
>Du mener altså at controlleren bliver en flaskehals og
>fordelen ved flere spindler/kanaler falder bort ved brug
>af 15K diske på en 53xx?
>
>Du har muligvis ret, men jeg tvivler.

Næh - jeg tænker på hvor meget nettoeffekt man får ved 0+1 kontra 1.
Dvs. hvor meget bedre r/w performance får man ved striping.

--
Lars Kim Lund
http://www.net-faq.dk/

Ole Thomsen (05-12-2002)
Kommentar
Fra : Ole Thomsen


Dato : 05-12-02 07:20

"Flemming Riis" <flemming@riis.nu> wrote
>
> > Kunne man ikke med fordel lægge alle diskene i et 0+1
> > og i stedet partitionere i OS?
>
> Du kan risikere at OS operationer som er disk tunge bruger din database IO.

Gør de ikke det alligevel når begge arrays ligger på
samme controller?

> Jeg tror ikke på en 5302 overlever at en kanal dør alligevel, så log/os på 1

Det skal du ikke være så sikker på, jeg havde for år
tilbage en DEC (Mylex) hvor der opstod en kabel
eller terminatorfejl, og den kørte lystigt videre på en
kanal.

> Få serveren ud 14 dage før det var planlagt og se om du kan mærke en forskel

Det er ikke muligt.

> Man skal ikke helt undervudere performancen i en håndfuld moderne diske,
> tror de helt hysteriske opdeling er ved at være fortid med mindre det er
> extremt performance krævende systemer.

Og så kan man jo ligesågodt lave eet stort 0+1 der
spænder over begge kanaler

Ole Thomsen



Flemming Riis (05-12-2002)
Kommentar
Fra : Flemming Riis


Dato : 05-12-02 12:36

"Ole Thomsen" <ot@networks.dk> wrote in message
news:asmr6t$b46$1@news.net.uni-c.dk

> > Du kan risikere at OS operationer som er disk tunge bruger din database
IO.
>
> Gør de ikke det alligevel når begge arrays ligger på
> samme controller?

Controlleren har typisk rigeligt io , jeg tænkte på disk io

> > Jeg tror ikke på en 5302 overlever at en kanal dør alligevel, så log/os
på 1
>
> Det skal du ikke være så sikker på, jeg havde for år
> tilbage en DEC (Mylex) hvor der opstod en kabel
> eller terminatorfejl, og den kørte lystigt videre på en
> kanal.

Ok jeg mente en død kanal fejl agtig ting

> > Få serveren ud 14 dage før det var planlagt og se om du kan mærke en
forskel
>
> Det er ikke muligt.

Øv





Lars Kim Lund (04-12-2002)
Kommentar
Fra : Lars Kim Lund


Dato : 04-12-02 19:16

"Ole Thomsen" <ot@networks.dk> wrote:
>I den forbindelse har jeg bedt Compaq levere et forslag til
>sizing, og på disksiden modtaget følgende:
>
>10 diske fordelt med
>2 diske i RAID1 til OS
>2 diske i RAID1 til logs
>6 diske i RAID0+1 til database
>
>Hvori ligger fordelene i ovenstående?

At paging og OS-operationer ikke forstyrrer logoperationer. På en stor
boks med rigeligt ram tror jeg det er begrænset hvad den pager eller
bruger af OS'et når den først triller.

>Kunne man ikke med fordel lægge alle diskene i et 0+1
>og i stedet partitionere i OS?

Som jeg forstået det er det godt at have forskellige arrays fordi de
enkelte operationer ikke forstyrrer hianden. Tænk på praksis ved
backup hvor det f.eks. ikke er sundt at trække fra flere logiske diske
på samme tid der måske er partioneret fra det samme array kontra at
trække det fra separate arrays.

>Det vil for det første sprede
>diskoperationerne på flere diske, for det andet give en
>større frihed mht. den indbyrdes størrelse af partitionerne.

Hvis diskene er i samme boks ville jeg nok køre OS og logs på samme
diske, evt. i 0+1 - jeg tror ikke du mærker nogen forskel med nutidens
controllere og diske.

Er der egentlig nogen der har nogle performance-tal for R1 vs. 0+1?
Hvor stor er effekten ved parallelismen?

>Det foreslås også at lægge OS og logs på den ene kanal
>og db på den anden, hvilket forekommer mig lidt tåbeligt
>både ift. performance men også sikkerhedsmæssigt. Hvis
>man lægger et stripesæt på den ene kanal og spejler det
>på den anden vil systemet jo køre videre selv om en kanal
>falder ud.

Jeg har aldrig set en controller smide en enkelt kanal. Hvis man
tænker i de baner bør man istedet bruge flere controllers IMO - det
vil også (teoretisk) give bedre performance.

--
Lars Kim Lund
http://www.net-faq.dk/

Lars Kim Lund (04-12-2002)
Kommentar
Fra : Lars Kim Lund


Dato : 04-12-02 19:27

Lars Kim Lund <lkl@fabel.dk> wrote:

>Jeg har aldrig set en controller smide en enkelt kanal. Hvis man
>tænker i de baner bør man istedet bruge flere controllers IMO - det
>vil også (teoretisk) give bedre performance.

... hvis det aht. sikkerhed så skal man jo have spejlede controllere.
Med interne controllers har jeg ikke ret gode erfaringer med det
(SA3100ES). F.eks. oplevede jeg at serveren havde svært ved at
detektere en controllerfejl således at den halvdøde controller var den
aktive (men ikke virkede) og den passive tog ikke over fordi den
troede den aktive var funktionsdygtig.

Jeg har ikke prøvet med de nyere ES controllers. Belært af den
erfaring (og pga. andre forhold) gik vi over til spejlede eksterne
controllers på de kritiske systemer.

--
Lars Kim Lund
http://www.net-faq.dk/

Ulrik Lunddahl (04-12-2002)
Kommentar
Fra : Ulrik Lunddahl


Dato : 04-12-02 23:43

"Ole Thomsen" <ot@networks.dk> wrote:

> Kommentarer?

En Oracle konsulent kan være til meget gang ved sizing, Oracle databasen som
du har i drift nu kan give dig svar på præsis hvor du vil have gavn af mere
IO og hvor det er totalt spild.

Jeg blev selv ganske overrasket over hvordan vores Oracle egentligt opfører
sig i praksis.

Der kan også opnås ganske betydelige gevinster ved disaster revovery hvis
man planlægger sin diskstruktur fornuftigt.

Hvor havde du egentligt tænkt dig at smide dine archive logs og anvender du
duplex dest for disse.


--
Med Venlig Hilsen

Ulrik Lunddahl - nospam037@lunddahl.dk
My heroes: Heddy Lamar, George Antheil and now also Anders Hejlsberg



Ole Thomsen (05-12-2002)
Kommentar
Fra : Ole Thomsen


Dato : 05-12-02 07:05

"Ulrik Lunddahl" <nospam037@lunddahl.dk> wrote
>
> En Oracle konsulent kan være til meget gang ved sizing, Oracle databasen som
> du har i drift nu kan give dig svar på præsis hvor du vil have gavn af mere
> IO og hvor det er totalt spild.

Det var faktisk en god ide.

Nu er det sådan at det er et "standardsystem" som kører på
flere hundrede installationer i Danmark, så jeg havde egentlig
en forventning om at konsulenterne der installerer har en "best
practises", men ved nærmere eftertanke er jeg ikke sikker.

> Der kan også opnås ganske betydelige gevinster ved disaster revovery hvis
> man planlægger sin diskstruktur fornuftigt.

Det tror jeg på.

> Hvor havde du egentligt tænkt dig at smide dine archive logs og anvender du
> duplex dest for disse.

Jeg smider ikke noget nogen steder, jeg er ikke dba, ja faktisk
har jeg ikke en fløjtende forstand på Oracle

Mig bekendt anvender vi ikke duplex destination, men jeg
har heller ikke haft hands-on kontakt med systemet siden
det kørte på Oracle v7.x hvor det ikke var en mulighed, så
jeg er ikke sikker.

Ole Thomsen




Ulrik Lunddahl (05-12-2002)
Kommentar
Fra : Ulrik Lunddahl


Dato : 05-12-02 21:49

"Ole Thomsen" <ot@networks.dk> wrote:

> Det var faktisk en god ide.

Jeg har aldrig være udsat for ikke at få fuld valuta for de penge jeg har
kaster eter min Oracle konsulent.

> Nu er det sådan at det er et "standardsystem" som kører på
> flere hundrede installationer i Danmark, så jeg havde egentlig
> en forventning om at konsulenterne der installerer har en "best
> practises", men ved nærmere eftertanke er jeg ikke sikker.

Det har de, men de har nok flere end en, og det kommer an på hvordan
databasen benyttes, hvilke krav der stilles til disaster recovery og
oppetid.

> > Hvor havde du egentligt tænkt dig at smide dine archive logs og anvender
du
> > duplex dest for disse.
>
> Jeg smider ikke noget nogen steder, jeg er ikke dba, ja faktisk
> har jeg ikke en fløjtende forstand på Oracle

Kort sagt registreres alt hvad der sker i databasen i x log filer når den
sidste nås starter man igen på den første, hver gang en log fil er fyldt og
der springes til den næste arkiveres log filen, dette skal foregå hurtigst
muligt, og der giver derfor ingen mening at arkivere filen på log diskene,
og data diskene kan den heller ikke være, da de arkiverede log filer jo
netop skal bruges hvis datadiskene går ned (de spoles på sidste backup).

Man kan selv bestemme hvor tit man vil have et "log switch", enten tager man
det bare når log filerne er fyldt eller også tvinger man en log switch efter
en given tid er gået, man kan herefter altid restore sin database til sidste
committede transsaktion før sidste "log switch"

Under alle omstæntligheder sker der ikke ret meget i databasen så længe
archiveren laver et log switch, og derfor skal det gå hurtigt.

I vores setup bruger vi 2 seperate diske uden raid til archive logs,
databasen arkiverer så på begge diske og er glad bare en af operationerne
lykkedes.

Diskene kan fint side på en ganske almindelig SCSI controller og hvis du er
til det, kan du også archive på tape og disk samtidigt.

Vi archiver på 2 diske og flytter via et cron job tillige filerne til en
anden server, hvilket giver os mulighed for kun at tabe omkring 10 minutters
drift hvis en bombe skulle springe i serverrummet.

> Mig bekendt anvender vi ikke duplex destination, men jeg
> har heller ikke haft hands-on kontakt med systemet siden
> det kørte på Oracle v7.x hvor det ikke var en mulighed, så
> jeg er ikke sikker.

Du vil elske en god Oracle konsulent...


--
Med Venlig Hilsen

Ulrik Lunddahl - nospam037@lunddahl.dk
My heroes: Heddy Lamar, George Antheil and now also Anders Hejlsberg



Ole Thomsen (10-12-2002)
Kommentar
Fra : Ole Thomsen


Dato : 10-12-02 09:57

"Ulrik Lunddahl" <nospam037@lunddahl.dk> wrote
>
> > Nu er det sådan at det er et "standardsystem" som kører på
> > flere hundrede installationer i Danmark, så jeg havde egentlig
> > en forventning om at konsulenterne der installerer har en "best
> > practises", men ved nærmere eftertanke er jeg ikke sikker.
>
> Det har de, men de har nok flere end en, og det kommer an på hvordan
> databasen benyttes

Mit gæt er at den anvendes på fuldstændig samme
måde alle steder, forskellen vil kun ligge i antallet
af samtidige brugere.

> hvilke krav der stilles til disaster recovery og
> oppetid.

Igen, kravene er de samme (ministerielle) medmindre
det enkelte site vælger at forhøje dem. Det har jeg
ikke hørt om.

> Vi archiver på 2 diske og flytter via et cron job tillige filerne til en
> anden server, hvilket giver os mulighed for kun at tabe omkring 10 minutters
> drift hvis en bombe skulle springe i serverrummet.

Tak for input.

Ole Thomsen



Søg
Reklame
Statistik
Spørgsmål : 177558
Tips : 31968
Nyheder : 719565
Indlæg : 6408914
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste