Bilder av deres servere

[Ascubal]

Sier meg enig med µp1is, dette her er meget spennende å lese. Mye inspirasjon og hente her

[Savagedlight]

' timestamp='1320616500' post='18547660']

Hehe, ja, har holdt paa med Linux og *nix i noe over ett og ett halvt tiaar selv

 

Core, L3 og opp er stort sett bare 100mbit, men kjorer gigabit mellom VM'er.. bruker i hovedsak Marvell, Intel og Broadcom. Er ikke noe reelt behov aa oppgradere kjernen til noe mer enn 100mbit for jeg har upstream til aa stotte det..

 

Kjorer for det meste *BSD paa embedded og dedikerte tjenere og systemer, Linux kjernen er bedre til det aller meste utover (paranoid) sikkerhet og single eller special-purpose, IMO Blant annet kjorer jeg assortert BSD paa nesten alle brannvegger, IDS'er og andre sikkerhets-ssytemer i nettverket. Juniper Netscreen kjorer ogsaa sin egen form av NetBSD, samt selvfolgelig FreeBSD pfSense paa diverse annet dedikert utstyr. Utover det er gaar det for det meste i Linux paa alt annet, men har jo selvfolgelig litt Solaris og annet esoterisk unix ogsaa Selv om Slackware uten tvil er hvor jeg foler meg mest hjemme; Death to the Pinks!

 

Har ikke noen egentlige tall for throughput i nettverket, min fokus er hovesakelig paa MPI ytelse og latency, fremfor ren raa baandbredde. er derfor i gang med aa implementere en ny 10Gbit/20gbit SDR/DDR InfiniBand arkitektur for server fabric (dvs. PCIe behovet i nevermind)..

 

bilde

Marvell Ethernet vs Mellanox IB..

 

Mvh

[infected]

Ja, vi har jo alle våre behov og ønsker, får jeg si. Jeg har aldri rørt mer enn 1Gbps selv, og ser jo at jeg absolutt burde hatt mer enn 1G for inter-switch koblinger, siden alt tilkoblet utstyr er 1G og dermed kan strupe nettverket hvis man vil. Jeg bruker dog ikke IRQ-IO på servere og brannmurer, men heller polling; Den avgjørelsen tok jeg etter å ha hatt det litt moro med å teste noe som kalles "DrDoS" (Distributed Redirected Denial of Service").

 

Dvs. jeg hadde tre enheter koblet til samme switch; To servere og en klient. Klienten sendte en storm med oppkoblingsforsøk til ServerA, der pakkene sa de var fra ServerB. Du kan jo tenke deg hvor stressende det er for ServerA å motta en slik storm over lokalnettet; Men værre skulle det bli. For når ServerA mottok disse forespørslene, så sendte den ut pakker til ServerB for å si "Ja, jeg godtar oppkoblingen din". Eneste problemet var at ServerB ikke visste hva ServerA snakket om, og dermed ignorerte den, hvilket førte til at for hver pakke ServerA mottok, så sendte den 3-5 (husker ikke nøyaktig) pakker til ServerB. Dvs. serveren ble ganske så opptatt med å prosessere IO. Forståelig nok så gikk ting tregt eller nesten ikke i heletatt over nettverket, men det som var avgjørende var at ServerA var så oppslukt med å pushe nettverkspakker at det var tilnermet umulig å administrere den ved lokal konsoll også.

 

Så da bestemte jeg meg for å stanse pakkestormen og bytte over til polling på ServerA; Når det var gjort så fortsatte jeg pakkestormen. Det gikk fortsatt ganske så sirup over nettverk, men det gikk ihvertfall an å styre den via lokal konsoll uten noen merkbar treghet.

 

Sånn for ordens skyld: IRQ-basert pushing av nettverkspakker gjør at CPU slutter å gjør hva enn det er den gjør, når nettverkstrafikk må prosesseres; Uansett. (Så lenge som den ikke driver med annen IO som har høyere prioritet). Ved polling så instrueres CPU til å sjekke nettverks-I/O ved jevne intervaller, for eksempel 1000 eller 10 000 ganger i sekundet. Begge måter har sine fordeler og ulemper; For eksempel vil polling gjøre at CPU vil sjekke for I/O selv om det ikke er noe å prosessere, og at all trafikk vil bli ilagt ekstra forsinkelse omvendt proporsjonalt med hvor ofte CPU instrueres å sjekke for I/O. Ved videre-routing av nettverkstrafikk så vil det ved 10 000 polls i sekundet (den innstillingen jeg benytter) bli maksimalt (1000/10000)*2ms = 0.2ms ekstra forsinkelse som følge av polling.

 

Når det er sagt så ligger ping internt på nettverket rundt 0.2 til 0.5ms, alt ettersom hvilke maskiner jeg pinger fra/til (de har forskjellig polling/IRQ oppsett), mens f.eks. vg.no ligger rundt 8ms, og disse forumene på ca. 9ms.

 

Når det gjelder Wiggum og dens rolle som filserver, så må jeg si at den absolutt ville hatt nytte av mer enn 1G uplink, da den (ifølge Bonnie) fint klarer å skrive ca. 170MB/s (1360 Mbit/s) og lese ca. 280MB/s (2240Mbit/s) fra DataStore (der hvor brukerdata lagres). Det ville f.eks. vert fordelaktig mtp. flere PCer og servere som fra tid til annen kjører backup samtidig.

*Ser på de tallene* Jeg burde nok legge til en SSD "log" device eller to på DataStore da, for å redusere fragmentering som følge av skriving til disk. Sånn som det er nå så skrives ting til lagringsdiskene to ganger; En gang til et midlertidig område (log) og noe senere til en permanent plassering på diskene. SSD-basert log ville gjort at data skrives til SSD først, så permanent til lagringsdiskene noe senere.

Endret 7. november 2011 av Savagedlight

[[Infected]]

Ja, vi har jo alle våre behov og ønsker, får jeg si. Jeg har aldri rørt mer enn 1Gbps selv, og ser jo at jeg absolutt burde hatt mer enn 1G for inter-switch koblinger, siden alt tilkoblet utstyr er 1G og dermed kan strupe nettverket hvis man vil. Jeg bruker dog ikke IRQ-IO på servere og brannmurer, men heller polling; Den avgjørelsen tok jeg etter å ha hatt det litt moro med å teste noe som kalles "DrDoS" (Distributed Redirected Denial of Service").

 

Dvs. jeg hadde tre enheter koblet til samme switch; To servere og en klient. Klienten sendte en storm med oppkoblingsforsøk til ServerA, der pakkene sa de var fra ServerB. Du kan jo tenke deg hvor stressende det er for ServerA å motta en slik storm over lokalnettet; Men værre skulle det bli. For når ServerA mottok disse forespørslene, så sendte den ut pakker til ServerB for å si "Ja, jeg godtar oppkoblingen din". Eneste problemet var at ServerB ikke visste hva ServerA snakket om, og dermed ignorerte den, hvilket førte til at for hver pakke ServerA mottok, så sendte den 3-5 (husker ikke nøyaktig) pakker til ServerB. Dvs. serveren ble ganske så opptatt med å prosessere IO. Forståelig nok så gikk ting tregt eller nesten ikke i heletatt over nettverket, men det som var avgjørende var at ServerA var så oppslukt med å pushe nettverkspakker at det var tilnermet umulig å administrere den ved lokal konsoll også.

 

Så da bestemte jeg meg for å stanse pakkestormen og bytte over til polling på ServerA; Når det var gjort så fortsatte jeg pakkestormen. Det gikk fortsatt ganske så sirup over nettverk, men det gikk ihvertfall an å styre den via lokal konsoll uten noen merkbar treghet.

 

Sånn for ordens skyld: IRQ-basert pushing av nettverkspakker gjør at CPU slutter å gjør hva enn det er den gjør, når nettverkstrafikk må prosesseres; Uansett. (Så lenge som den ikke driver med annen IO som har høyere prioritet). Ved polling så instrueres CPU til å sjekke nettverks-I/O ved jevne intervaller, for eksempel 1000 eller 10 000 ganger i sekundet. Begge måter har sine fordeler og ulemper; For eksempel vil polling gjøre at CPU vil sjekke for I/O selv om det ikke er noe å prosessere, og at all trafikk vil bli ilagt ekstra forsinkelse omvendt proporsjonalt med hvor ofte CPU instrueres å sjekke for I/O. Ved videre-routing av nettverkstrafikk så vil det ved 10 000 polls i sekundet (den innstillingen jeg benytter) bli maksimalt (1000/10000)*2ms = 0.2ms ekstra forsinkelse som følge av polling.

 

Når det er sagt så ligger ping internt på nettverket rundt 0.2 til 0.5ms, alt ettersom hvilke maskiner jeg pinger fra/til (de har forskjellig polling/IRQ oppsett), mens f.eks. vg.no ligger rundt 8ms, og disse forumene på ca. 9ms.

 

Når det gjelder Wiggum og dens rolle som filserver, så må jeg si at den absolutt ville hatt nytte av mer enn 1G uplink, da den (ifølge Bonnie) fint klarer å skrive ca. 170MB/s (1360 Mbit/s) og lese ca. 280MB/s (2240Mbit/s) fra DataStore (der hvor brukerdata lagres). Det ville f.eks. vert fordelaktig mtp. flere PCer og servere som fra tid til annen kjører backup samtidig.

*Ser på de tallene* Jeg burde nok legge til en SSD "log" device eller to på DataStore da, for å redusere fragmentering som følge av skriving til disk. Sånn som det er nå så skrives ting til lagringsdiskene to ganger; En gang til et midlertidig område (log) og noe senere til en permanent plassering på diskene. SSD-basert log ville gjort at data skrives til SSD først, så permanent til lagringsdiskene noe senere.

 

Du har saa absolutt en milevis bedre internett forbindelse enn det jeg sitter paa ivertfall, morsomt du skulle nevne packet storm, jeg ble utsatt for noe lignende selv forrige dagen, internett er absolutt ett farlig sted disse dager. selv har jeg gitt opp med aa rote med alt det der selv, det var mye mer fokus paa akkurat det temaet forrige semester.. etter 3.5 aar med Cisco har jeg sett lyset med Juniper.. junier har ogsaa et utmerket innebygget DDoS filter, andre funksjoner som Signature Detection og Attack Signatures gjor mye god jobb. Se bare hvor aggresivt internett har blitt disse dager, saa mange scripts, selv om targeted attacks fortsatt er mye sjeldnere enn sweeps.

 

Poenget er vel at jeg ikke har tid til styre ting paa et slikt nivaa, og bruker derfor heller ett Onion type layered defense, Bruce Schneier, "security is a process not a product" type approach, og alt det der. Klart man kan faa "ultimat sikkerhet", og kort av aa fylle pc'en opp med betong er vel OpenBSD ikke saa alt for langt vekke heller.

 

Alt om sikkerhet handler stort sett om trade-offs, og hvilke av disse man er villige til aa ta. Alt omhandler aa minimalisere Attack-vectors, en enterprise firewall vil for eksempel aldri 'choke' fra noen som helst packet-storm rent bortsett fra selve interfacet som da blir choket. Kernel ligger jo da over nettverket samt under iptables eller packetfilter, respektivt. Uansett, en skikkelig konfigurert enhet vil jo aldri videresende pakker fra en kilde som markerer seg abnormalt i et ellers stabilt eller relativt forutsigbart miljo, og slike IDP og IDS algoritmer overlater jeg gjerne heller til snort og Emerging Threats, etc. saa skriver jeg heller mine egne customs paa toppen av det hele Layered security for the win. Er mange troll der ute paa internettet, og tallene ser ut til aa vaere i konstant okning, saa jeg forstaar godt valget av BSD som platfom.. selv om jeg kanskje ikke helt deler det.

 

Er ingenting som er sikkert der ute uansett, aa paastaa noe annet ville vaert totalt aa ignorere verden rundt seg. Saa sent som bare noen maaneder siden ble jo en rekke Root CA'er hacket, en rekke av disse kjorte jo baade BSD paa toppen av RSA og diverse andre FIPS samt DoD autoriserte two- og three-factor auth losninger.

 

Man kan aldri vaere trygg, der er alltid angrepsvektorer der ute, som Schneier paapeker, beste man kan gjore er vel aa 'save ones prayers' og vente til uvaeret letter fokusere paa de mest konstnadsokonomiske strategiene for aa holde skuta seilende; Confidentiality, Integrity, Availability, og etc.

 

 

 

Uansett var det ett virkelig rent og stilig,samt ikke minst vel-tweaket setup du har der Savagedlight

 

Mvh

[infected]

Endret 7. november 2011 av [Infected]

[Savagedlight]

Veldig interessante data dere kommer med Savagedlight og [infected], elsker å lese om slikt.

 

 

Sier meg enig med µp1is, dette her er meget spennende å lese. Mye inspirasjon og hente her

 

Hyggelig å høre

[Savagedlight]

Jeg er klar over at vi kanskje går litt off topic her, men syns det er en naturlig utvikling av tråden... Så får evt. moderator splitte tråden hvis det blir for rotete.

 

' timestamp='1320638194' post='18548470']

Du har saa absolutt en milevis bedre internett forbindelse enn det jeg sitter paa ivertfall, morsomt du skulle nevne packet storm, jeg ble utsatt for noe lignende selv forrige dagen, internett er absolutt ett farlig sted disse dager. selv har jeg gitt opp med aa rote med alt det der selv, det var mye mer fokus paa akkurat det temaet forrige semester.. etter 3.5 aar med Cisco har jeg sett lyset med Juniper.. junier har ogsaa et utmerket innebygget DDoS filter, andre funksjoner som Signature Detection og Attack Signatures gjor mye god jobb. Se bare hvor aggresivt internett har blitt disse dager, saa mange scripts, selv om targeted attacks fortsatt er mye sjeldnere enn sweeps.

 

Poenget er vel at jeg ikke har tid til styre ting paa et slikt nivaa, og bruker derfor heller ett Onion type layered defense, Bruce Schneier, "security is a process not a product" type approach, og alt det der. Klart man kan faa "ultimat sikkerhet", og kort av aa fylle pc'en opp med betong er vel OpenBSD ikke saa alt for langt vekke heller.

 

Alt om sikkerhet handler stort sett om trade-offs, og hvilke av disse man er villige til aa ta. Alt omhandler aa minimalisere Attack-vectors, en enterprise firewall vil for eksempel aldri 'choke' fra noen som helst packet-storm rent bortsett fra selve interfacet som da blir choket. Kernel ligger jo da over nettverket samt under iptables eller packetfilter, respektivt. Uansett, en skikkelig konfigurert enhet vil jo aldri videresende pakker fra en kilde som markerer seg abnormalt i et ellers stabilt eller relativt forutsigbart miljo, og slike IDP og IDS algoritmer overlater jeg gjerne heller til snort og Emerging Threats, etc. saa skriver jeg heller mine egne customs paa toppen av det hele Layered security for the win. Er mange troll der ute paa internettet, og tallene ser ut til aa vaere i konstant okning, saa jeg forstaar godt valget av BSD som platfom.. selv om jeg kanskje ikke helt deler det.

 

Er ingenting som er sikkert der ute uansett, aa paastaa noe annet ville vaert totalt aa ignorere verden rundt seg. Saa sent som bare noen maaneder siden ble jo en rekke Root CA'er hacket, en rekke av disse kjorte jo baade BSD paa toppen av RSA og diverse andre FIPS samt DoD autoriserte two- og three-factor auth losninger.

 

Man kan aldri vaere trygg, der er alltid angrepsvektorer der ute, som Schneier paapeker, beste man kan gjore er vel aa 'save ones prayers' og vente til uvaeret letter fokusere paa de mest konstnadsokonomiske strategiene for aa holde skuta seilende; Confidentiality, Integrity, Availability, og etc.

 

 

 

Uansett var det ett virkelig rent og stilig,samt ikke minst vel-tweaket setup du har der Savagedlight

 

Mvh

[infected]

 

Ja, jeg er enig i at det er lurt å ha flere lag med sikkerhet, hvor ett av disse lagene er en IDS. Men nå må jeg innrømme at jeg ble litt filosofisk her.. Hva er egentlig sikkerhet? Vi kan vel alle være enige om at det å holde crackerne unna serveren og nettverket er det de aller fleste vil legge i uttrykket it-sikkerhet.

 

Spoiler: Lang tekst om sikkerhet.

 

Så da har man en brannmur helt ytterst som grovfiltrerer innkommende (og utgående) trafikk, som samkjøres med en IDS (enten på samme boks eller mellom ytre brannmur og resten av nettverket); Gjerne noe som scanner all smtp/pop/imap og http trafikk for virus og ulumskheter i samme slengen (kan vel sies å være del av IDS).

 

Har man alt dette på plass, så har man kommet langt på et meta-nivå ihvertfall. Det vil kreve mye fikling for en inntrenger å komme seg forbi dette, spesielt om den ytre brannmuren er konfigurert til å maskere (TCP) stack signaturer. Da vil det ta noe lenger tid å finne en angrepsvektor; Som vil si at det gir deg litt ekstra tid til å finne ut at noe er på gang.

 

Her vil mange gå i fella at "Jammen brannmuren sikrer jo nettverket", og la ting ligge åpent bak brannmuren. DET synes jeg er en ganske skummel felle å gå i. For det som ligger bakom brannmuren bør egentlig konfigureres slik at det går ut ifra at alt annet på nettverket er kompromittert; dvs. kun eksponere de tjenester som er nødvendige, og ikke stole blindt på at kommunikasjon fra en kilde er legitim. For eksempel så kan det nevnes at en mailserver f.eks. bør ha (software) brannmur som blokkerer tilgang til fjern-administrering (SSH) fra andre kilder enn "administrasjons-nettet", men at man likevel må ha autentisering. Man bør selvsagt ha rate limiting på oppkoblinger/trafikk for å redusere sjangsen for DoS.

 

Som jeg såvidt nevnte tidligere i tråden, så kan det være lurt å isolere alle eksponerte tjenester i individuelle VMs slik at hvis en cracker finner en angrepsvektor på webserveren din, så får han ikke automatisk tilgang til resten av systemt, som f.eks. fil og mailserver. Hvis man tar forrige avsnitt i betraktning, så vil heller ikke en full kompromittering av webserveren gi utstrakt tilgang til resten av nettverket; Så vedkommende måtte i såfall begynne helt fra bunnen av igjen når han leter etter neste mål i nettverket. Ved bruk av VMs/jails så kan man også skjule hvor system/bruker-data faktisk ligger, og faktisk klare å gjøre at webserver-VMet ikke har noen som helst tilgang til filserveren unntatt på det ene avgrensede området; Hvilket betyr at crackeren ikke har denne angrepsvektoren heller.

 

Når man tar alt ovenfor i betraktning, så kan man jo begynne å lure på om det ikke er sikkert nok nå...? Neida. Absolutt ikke!

Her trengs det mer sikkerhet. F.eks. kan det være lønnsomt å benytte seg av noe som i FreeBSD kalles for "securelevel", som gjør at man kan sette serveren til å ikke tillate endringer av henholdsvis kernel, systemfiler, programmer og spesielt markert brukerdata (f.eks. kan man låse brukerdatabasen slik at en cracker ikke kan legge til en ny konto for å lett få tilgang på et senere tidspunkt, eller låse webside-script slik at de ikke kan erstattes med nytt innhold). Skal man endre låst innhold, må man restarte serveren i singleuser-modus og ha tilgang på lokal konsoll. Så dette har jo selvsagt sine fordeler og ulemper.

 

Så var det de individuelle tjenestene da... Det er jo kjempelett å gå i den fella å installere alt, fordi det er jo så kjekt! Selvsagt trenger jeg mysql og php og ruby-on-rails for apache-serveren min! FastCGI og mod_proxy kan jo være kjekt i noen tilfeller også!!

Men her er det heller lurt å dele opp litt, slik at man ikke får alle disse potensielle angrepsvektorene på samme installasjon. Sett opp en webserver som har akkurat det du trenger, ikke noe mer og ikke noe mindre. Hvis du trenger noe mer/annet, sett opp en til for det oppsettet, slik at websider som ikke trenger alt gimmicket ikke utsettes for angrepsvektorene til de modulene som ikke benyttes.

Så kan man sette opp en reverse proxy foran alle disse forskjellige webserverene, med noen sikkerhetsregler (lettvekter-IDS om du vil), som gjerne vil forvirre en potensiell angriper. "Hmm.. Serveren kjører nginx og phpbb, da kan jeg jo utnytte sikkerhetshullet i php-modulen til nginx!", mens i realiteten så vil alle de spesifikke triksene enten bli stopped av IDS eller ikke påvirke den serveren som i realiteten kjører programvaren.

 

Det er jo mye, mye, mye mer man kan ta med i beregningen her, alt fra sikkerhetshull i switcher til nettverkskortenes firmware og brukergenerert programvare. UANSETT hvor sikkert du setter opp serveren din, så kan brukergenerert programvare (f.eks. php websider) være fulle av sikkerhetshull som gir delvis eller full tilgang til systemet som den brukeren som kjører webserveren. Her kan det være lurt å sette opp CGI-kjøring av PHP-kode, gjerne som den brukeren som eier PHP-filene. Da har ihvertfall slike sikkerhetshull begrenset tilgang, og kan for det meste bare ødelegge for den stakkars brukeren som hadde sikkerhetshullet i websiden sin. (med mindre man får til å gjennomføre noen lokale exploits via webserveren da, som f.eks. kan gi elevert tilgang).

 

Men nå tror jeg at jeg har skrevet aaaaaalt for mye, men håper det ihvertfall kan hjelpe noen å tenke på hva sikkerhet egentlig er.

 

 

PS: Fra et organisatorisk perspektiv, så bør tilgjengelighet på tjenesten også vurderes i en evt. sikkerhetsanalyse, siden nedetid betyr tapte inntekter som påvirker økonomisk sikkerhet, eller i værste fall humanitær sikkerhet. (tenk tilgjengelighet på elektroniske pasientjournaler)

Endret 7. november 2011 av Savagedlight

[kpolberg]

@[infected] se der lekker det ut hvilke HCA kort du bruker også. Tør jeg nesten tippe på at du har en Voltaire(Mellanox) switch inni der? Kjører du subnet manageren på en av nodene eller har du denne på switchen?

 

Fully-managed betyr liksom ikke så mye i ib verden, annet enn at switchen vanligvis har ofed stacken innstallert.

[[Infected]]

@[infected] se der lekker det ut hvilke HCA kort du bruker også. Tør jeg nesten tippe på at du har en Voltaire(Mellanox) switch inni der? Kjører du subnet manageren på en av nodene eller har du denne på switchen?

 

Fully-managed betyr liksom ikke så mye i ib verden, annet enn at switchen vanligvis har ofed stacken innstallert.

 

Hehe, du har tilfeldigvis ett aldri saa lite poeng der switchen i bruk er en TopSpin 120S, ogsaa senere kjent under navnet Cisco SFS7000

 

Mvh

[infected]

[kpolberg]

Ahh, vi har ett par gamle SFS-7024 kjørende her, greie bokser det.

[Savagedlight]

Her er et bilde fra Sideshow Bob (ESXi server) ved fysisk vedlikehold i dag.

[robert166]

Serverrommet på jobben

 

link

Endret 29. november 2011 av robert166

[[Infected]]

Ahh, vi har ett par gamle SFS-7024 kjørende her, greie bokser det.

 

Kan vel kanskje nevnes at den er aller siste generasjon av SFS 7000(D), saa DDR (20gbit/960gbit/140ns) versjonen, og ikke standard SFS7000(P) versjonen som 'bare' tilbyr SDR, 10gbit/480gbit/200ns Saa akkurat saaaaa gammel er den jo strengt talt ikke da

 

Ikke det at jeg har faktisk raad til DDR HCA'er, uansett (om du har noe(n) til overs kan du jo gjerne sende meg en PM )

 

Mvh

[infected]

Endret 7. november 2011 av [Infected]

[kpolberg]

Hehe, her er alt over 1 år gammelt

[[Infected]]

Hehe, her er alt over 1 år gammelt

 

Kjekt med budsjett

[Khani]

Her er et bilde fra Sideshow Bob (ESXi server) ved fysisk vedlikehold i dag.

 

Hvorfor bruker du et eksternt skjermkort når du kunne ha kjøpt et hk med et integrert skjermkort?

 

Eller var bare dette noe du hadde liggende?

Endret 8. november 2011 av WilliamAR

[Savagedlight]

Her er et bilde fra Sideshow Bob (ESXi server) ved fysisk vedlikehold i dag.

 

Hvorfor bruker du et eksternt skjermkort når du kunne ha kjøpt et hk med et integrert skjermkort?

 

Eller var bare dette noe du hadde liggende?

Såvidt jeg husker, så fant jeg ikke noen hovedkort som passet kravspeccen som og hadde integrert grafikk (enten separat chip eller ved bruk av den på CPU). Mest fordi de aller fleste hk i den klassen er full av dilldall som man aldri trenger likevel, men som gjerne fører til en dominoeffekt når det går istykker.

[Theo343]

Hvorfor kjøper dere overpriset servere ? Den største forskjell er jo hovedkortet ???? Eller hvilken årsak er det at noen kjøper overpriset varer ?

Det mange misforstår er at hvilke som helst type maskiner liksågodt kan stå som en server.

 

En server har ofte viktige oppgaver hvor oppetid, driftstabilitet/driftsikkerhet samt administrasjonsvennlighet er viktige faktorer. I tillegg til at man har avtaler om bytte av komponenter innen 4 timer etc.

 

Dette blir som å skille lek fra alvor.

Endret 9. november 2011 av Theo343

[Theo343]

Husker lærern min i fjor hadde med seg noen gamle pentium 3 servere med muligheten til og sette i 6 prosessorer som var hot swap.

 

De skulle vist ha kostet 100,000kr når de var nye.

På den tiden var serverprisene mye høyere, i dag får man gode servere til langt under den prisen. 100.000,- var heller ikke spesielt dyrt på tiden hvor P3 var gjeldende.

[Theo343]

De jeg har i drift er ganske så grønne egentlig.

 

3stk for esxi cluster

....

Cluster? Mener du at du kjører vmotion, HA osv? Hvilke lisenser sitter du med?

[Khani]

Her er et bilde fra Sideshow Bob (ESXi server) ved fysisk vedlikehold i dag.

 

Hvorfor bruker du et eksternt skjermkort når du kunne ha kjøpt et hk med et integrert skjermkort?

 

Eller var bare dette noe du hadde liggende?

Såvidt jeg husker, så fant jeg ikke noen hovedkort som passet kravspeccen som og hadde integrert grafikk (enten separat chip eller ved bruk av den på CPU). Mest fordi de aller fleste hk i den klassen er full av dilldall som man aldri trenger likevel, men som gjerne fører til en dominoeffekt når det går istykker.

 

Jeg skjønner.

 

Men har du skjermkortet i 24/7 eller?

 

Jeg tenker at det kan lønne seg mer og gå for et kort som er mer low end og drar mindre strøm i lengden.

 

Det er vel et 3650 du bruker om jeg husker rett?

 

Jeg bruker selv et x600 pro i filservern som trekker snaue 20w idle og rundt 40w under load.

Endret 9. november 2011 av WilliamAR

[Savagedlight]

Jeg skjønner.

 

Men har du skjermkortet i 24/7 eller?

 

Jeg tenker at det kan lønne seg mer og gå for et kort som er mer low end og drar mindre strøm i lengden.

 

Det er vel et 3650 du bruker om jeg husker rett?

 

Jeg bruker selv et x600 pro i filservern som trekker snaue 20w idle og rundt 40w under load.

Det står i som standard ja.

 

Det er et GeForce 210 ett eller annet. Ifølge nvidia så trekker chippen 30W ved full belastning; Så jeg tviler på at det trekker så voldsomt mye strøm å vise en tekst-terminal i VGA oppløsning. (selv om den har litt farge her og der..)

Endret 9. november 2011 av Savagedlight