Gå til innhold

Anbefalte innlegg

Det blir nok Vmware VI3 på oss om litt.

 

Tenkte å sette opp en egen storage server. Linux burk med EVMS og bruke vanlig samba shares. 8 disker i RAID10 i første omgang.

 

Men hvordan blir ytelsen her når det er snakk om NIC med 1gbps? Vil det hjelpe sette inn flere nettverkskort og kable direkte til ESX serverne? tenkte å ha 2-3 esx servere.

Lenke til kommentar
Videoannonse
Annonse
Det blir nok Vmware VI3 på oss om litt.

 

Tenkte å sette opp en egen storage server. Linux burk med EVMS og bruke vanlig samba shares. 8 disker i RAID10 i første omgang.

 

Men hvordan blir ytelsen her når det er snakk om NIC med 1gbps? Vil det hjelpe sette inn flere nettverkskort og kable direkte til ESX serverne? tenkte å ha 2-3 esx servere.

8633169[/snapback]

tror du skal satse på NFS da i hvert fall! så vidt jeg vet så vil ikke samba shares fungere...

Lenke til kommentar
Det blir nok Vmware VI3 på oss om litt.

 

Tenkte å sette opp en egen storage server. Linux burk med EVMS og bruke vanlig samba shares. 8 disker i RAID10 i første omgang.

 

Men hvordan blir ytelsen her når det er snakk om NIC med 1gbps? Vil det hjelpe sette inn flere nettverkskort og kable direkte til ESX serverne? tenkte å ha 2-3 esx servere.

8633169[/snapback]

tror du skal satse på NFS da i hvert fall! så vidt jeg vet så vil ikke samba shares fungere...

8635697[/snapback]

 

Det har du nok helt rett i ja. :blush:

Lenke til kommentar
Det blir nok Vmware VI3 på oss om litt.

 

Tenkte å sette opp en egen storage server. Linux burk med EVMS og bruke vanlig samba shares. 8 disker i RAID10 i første omgang.

 

Men hvordan blir ytelsen her når det er snakk om NIC med 1gbps? Vil det hjelpe sette inn flere nettverkskort og kable direkte til ESX serverne? tenkte å ha 2-3 esx servere.

8633169[/snapback]

tror du skal satse på NFS da i hvert fall! så vidt jeg vet så vil ikke samba shares fungere...

8635697[/snapback]

 

Det har du nok helt rett i ja. :blush:

8635847[/snapback]

1 Gb/s kommer ikke til å være noen spesiell begrensing.

 

Det som er viktig er god RAID kontroller, mest mulig cache på kontroller og på lagringsserver (husk UPS!!) og mest mulig spindles (flest mulig harddisker) for best mulig IO ytelse.

 

Husk et skikkelig hovedkort på lagringsserver med dedikerte PCI-busser for nettverkskort og raid-kontroller.

 

Det ER jo mulig å kjøre en eller annen form for link aggregation mellom switch og lagringsserver slik at du får 2 eller 4 Gb/s (for eks), men du vil ikke få mer enn 1 Gb/s mot en enkelt ESX server uansett pga begrensinger i vmkernel (støtter "trunks", men kun som failover)

10Gb/s nettverkskort kommer nok uansett ikke på tale pga pris (særlig på switch-siden)

Lenke til kommentar

Merk deg det lohelle har sagt her om RAID-kontroller og cache. En RAID-kontroller med batteri vil også hjelpe for ytelsen i og med at du kan slå på write back caching i kontrolleren.

 

En annen ting du også kan vurdere istedet for NFS er iSCSI. Tester har likevel vist at iSCSI er marginalt kjappere enn NFS. Vi gjorde en test av dette (og FC) mot samme disk array her: http://download3.vmware.com/vmworld/2006/l...ANCE-MANUAL.pdf

Lenke til kommentar
Merk deg det lohelle har sagt her om RAID-kontroller og cache. En RAID-kontroller med batteri vil også hjelpe for ytelsen i og med at du kan slå på write back caching i kontrolleren.

 

En annen ting du også kan vurdere istedet for NFS er iSCSI. Tester har likevel vist at iSCSI er marginalt kjappere enn NFS. Vi gjorde en test av dette (og FC) mot samme disk array her: http://download3.vmware.com/vmworld/2006/l...ANCE-MANUAL.pdf

8660124[/snapback]

jeg har også hatt til problemer med vmotion mot NFS (noe med swapfil-navn osv). Det er en workaround til dette (eller patch?), men likevel....

 

Open-E DSS fungerer utmerket mot VI3 (iscsi).

 

wsp: du har ikke tilfeldigvis den testfilen (eller oppsettfilen) som er brukt til IOmeter i denne pdf'en? tenkte å teste min iscsi løsning..

Lenke til kommentar
For å være helt ærlig så har jeg god erfaring med software-raid. Er det virkelig nødvendig å bruke en liten milliard på raid-controllere?

8669688[/snapback]

Du har tenkt å sette opp en løsning med VI3 (med 3 hoster, var det ikke det du nevnte over msn?). Gjør ikke sammen feilen som meg og gå for en for dårlig lagringsløsning. Dette er jo småpenger i forhold til "alt det andre" (raid kontroller). Jeg skjønner ikke helt prioriteringen...

Lenke til kommentar
For å være helt ærlig så har jeg god erfaring med software-raid. Er det virkelig nødvendig å bruke en liten milliard på raid-controllere?

8669688[/snapback]

Du har tenkt å sette opp en løsning med VI3 (med 3 hoster, var det ikke det du nevnte over msn?). Gjør ikke sammen feilen som meg og gå for en for dårlig lagringsløsning. Dette er jo småpenger i forhold til "alt det andre" (raid kontroller). Jeg skjønner ikke helt prioriteringen...

8670516[/snapback]

 

Er helt enig. Men er egentlig litt interessert i hva hardware raid gjør forskjellige fra f.eks mdadm? mdadm bruker jo CPU kraft fra systemet. men når systemet bare skal stå og dele filer så er det vel ikke store cpu-kraften som trengs?

Lenke til kommentar
wsp: du har ikke tilfeldigvis den testfilen (eller oppsettfilen) som er brukt til IOmeter i denne pdf'en? tenkte å teste min iscsi løsning..

8661083[/snapback]

 

Njet.. de sa de skulle gjøre denne VMen tilgjengelig etter vmworld, men det ser det ikke ut som de har gjort.

 

Det som forøvrig kan være like aktuelt er å ta en titt på denne tråden:

Open inofficial storage performance thread

 

Her finner du også iometer-filer som kan brukes.

 

Lars

Endret av wsp
Lenke til kommentar
For å være helt ærlig så har jeg god erfaring med software-raid. Er det virkelig nødvendig å bruke en liten milliard på raid-controllere?

8669688[/snapback]

Avhenger helt og holdent av bruken RAIDet lages til. Vi f.eks kjører raid via mdadm på våre www/db-bokser og det er ikke SW-RAIDet som er flaskehalsen. Men snakker man f.eks bankservere som har voldsomme krav kan man vel strengt tatt glemme SW-RAID. :)

Lenke til kommentar

Når det gjelder virtuelle servere så er fordelene med en kjapp diskkontroller mye større og mere merkbare enn med fysiske servere. Dette fordi det både er et virtualiseringsoverhead på dette samt at det i en virtualiseringssammenheng gjerne er mange servere som samtidig aksesserer samme diskressursen, og da gjerne med en blandet workload der det blir mange usekvensielle diskaksesser (alle VMene aksesserer disken samtidig, gjennom samme kontroller). I en fysisk verden merker man ikke dette like kjapt da hver server har sine disker og sine kontrollere, men i en virtuell verden blir dette mye kjappere en flaskehals.

 

Å ha diskfilene på en treg diskkontroller vil fort begrense hvor mange virtuelle maskiner du kan kjøre på systemet (avhengig av workload osv). Man trenger ikke ha så voldsomme diskkrav før man møter denne begrensningen.

Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...