PDA

Bekijk Volledige Versie : Leuke SAN



Yourwebhoster
13/12/09, 13:33
Kwam na het topic van Geert-Jan over zijn controller deze SAN tegen: http://www.hpsindustrial.nl/9U_server

Natuurlijk is zo'n SAN om te kwijlen wat opslag betreft, maar nou zie ik op de foto's slechts één LAN poort. Dit staat natuurlijk nooit in verhouding met de hoeveelheid opslag en volgens mij wordt deze server dan ook niet intensief gebruikt (wat ik persoonlijk zonde vind maar dat terzijde).

Nu vroeg ik mij af of iemand zo'n ding heeft draaien (of iets vergelijkbaars met veel disks) en wie allemaal slechts één LAN poort gebruiken of meerdere (op Gbit uiteraard, 10/100Mbit is no-done)? Ik heb het nu nog niet nodig maar wellicht zit het in de toekomst er in dat zulke opslag systemen nodig zijn voor een backupsysteem en/of virtualisatie platformen. Volgens mij kan deze bak redelijk voldoen als backupsysteem mits extra network poorten aangebracht worden (moet wel even kijken hoe het gaat passen natuurlijk) maar ben ik beter af met kleinere opslagsystemen voor virtualisatie platformen, of niet?

En wat de virtualisatie opslag betreft, ik hoor van sommigen dat normale disks op 7200 RPM eigenlijk niet voldoen en dat een SAS op 10k op 15k beter is. Ik heb natuurlijk ook met een budget te maken, dus ik denk dat 10k rpm voldoende is. Graag hoor ik de meningen/ervaringen hier over.

Verder lijkt mij het beste om via iscsi de storage servers te verbinden, of is een andere techniek beter? (gebruikte OS zal CentOS zijn voor zowel de nodes als storage servers).

gjtje
13/12/09, 14:18
Dit is geen san, dit is een behuizing waar veel disks in kunnen. Een san wordt het pas met de juiste configuratie en software.

't Is leuk inzetbaar als maglib voor de backups, ik zou er nooit een productie san op draaien. Dan wil je toch echt wel redundante controllers en data paden hebben. Afgezien van de performance als dat ding goed vol zit met dynamische data.

Yourwebhoster
13/12/09, 14:59
Dit is geen san, dit is een behuizing waar veel disks in kunnen. Een san wordt het pas met de juiste configuratie en software.

't Is leuk inzetbaar als maglib voor de backups, ik zou er nooit een productie san op draaien. Dan wil je toch echt wel redundante controllers en data paden hebben. Afgezien van de performance als dat ding goed vol zit met dynamische data.
Er wordt windows gebruikt, hoe staat er niet bij. Lijkt mij toch echt wel een SAN, je hebt wel verschillende soorten.

Ik zou dit zelf idd alleen als backup platform inzetten, althans als een deel van het backup systeem. Voor de doeleinden van het backupsysteem is eventuele uitval niet schadelijk aangezien het backupsysteem zichzelf daarop zal aanpassen. Ook bij een VPS platform zou dit het probleem niet zijn, maar volgens mij is het gewoon beter om meerdere storage servers te hebben met minder opslag per server ivm performance.

vne
13/12/09, 15:03
Je kan zoiets gerust zelf ineen knutselen. Supermicro heeft zo 4U kasten:
http://www.supermicro.com/products/chassis/4U/846/SC846E1-R900.cfm
daarin steek je dan een 24poort SAS controller (of 2x 16port) en 1 of 2 netwerkkaarten

Yourwebhoster
13/12/09, 15:08
Ik weet niet wat handiger is, twee controllers of één? Denk dat ivm redundantie dat twee beter zal zijn, maar het budget moet daar ook naar wezen dan. Maar wat raden jullie aan?

Verder, welke netwerk kaarten zijn aan te raden? 1Gbps is noodzakelijk maar eigenlijk wel vrij standaard tegenwoordig, maar wellicht dat iemand een aanrader heeft.

En verder: Ik weet niet wat eigenlijk beter is, ZFS met DRBD of hardware RAID met DRBD? Ik zou persoonlijk gaan voor hardware RAID en dat dit wat makkelijker is omdat dit ook gewoon op CentOS kan.

wdv
13/12/09, 15:23
Als je een low-budget SAN wil bouwen zou ik gewoon een flinke JBOD bak (zonder RAID controller) pakken met 2 CPU's en een flinke sloot geheugen. Vervolgens OpenSolaris erop met ZFS en gaan met die banaan! Als je redundantie wil gebruik je replicatie functionaliteiten van ZFS.

Yourwebhoster
13/12/09, 16:35
Oke, ik wist niet dat ZFS zelf over replicatie beschikte. Zal eens hier naar zoeken, het is trouwens wel belangrijk dat de ZFS zowel een master als slave is zoals bij drbd.

Piwi-Web
13/12/09, 18:04
Als je een low-budget SAN wil bouwen zou ik gewoon een flinke JBOD bak (zonder RAID controller) pakken met 2 CPU's en een flinke sloot geheugen. Vervolgens OpenSolaris erop met ZFS en gaan met die banaan! Als je redundantie wil gebruik je replicatie functionaliteiten van ZFS.

Denk dat JBOD de snelheid van het bakkie niet ten goede komt omdat alle schijven achter elkaar geplakt worden. Ook als je een schijf uitvalt ben je alles kwijt. Etc.
Je kan dus beter een beetje investeren in een RAID kaart en dan in RAID-10 o.i.d. draaien :)

Yourwebhoster
13/12/09, 18:20
Denk dat JBOD de snelheid van het bakkie niet ten goede komt omdat alle schijven achter elkaar geplakt worden. Ook als je een schijf uitvalt ben je alles kwijt. Etc.
Je kan dus beter een beetje investeren in een RAID kaart en dan in RAID-10 o.i.d. draaien :)
Ooit van ZFS gehoord?:)

Randy
13/12/09, 18:24
Denk dat JBOD de snelheid van het bakkie niet ten goede komt omdat alle schijven achter elkaar geplakt worden. Ook als je een schijf uitvalt ben je alles kwijt. Etc.
Je kan dus beter een beetje investeren in een RAID kaart en dan in RAID-10 o.i.d. draaien :)

Misschien moet je je eerst eens verdiepen in het ZFS filesystem voor je dergelijke uitspraken doet? Installeer OpenSolaris (Of Nexenta als je Debian kent), plak er 4 disken aan (kan gewoon virtueel) en ga eens spelen. RTFM voor de werking van ZFS. Als je het snapt, trek er dan eens een random disk uit en je zult zien dat alles gewoon blijft werken.

Piwi-Web
13/12/09, 20:29
Misschien moet je je eerst eens verdiepen in het ZFS filesystem voor je dergelijke uitspraken doet? Installeer OpenSolaris (Of Nexenta als je Debian kent), plak er 4 disken aan (kan gewoon virtueel) en ga eens spelen. RTFM voor de werking van ZFS. Als je het snapt, trek er dan eens een random disk uit en je zult zien dat alles gewoon blijft werken.

Ok excuses ... heb mij inderdaad niet in ZFS verdiept maar weet wel wat JBOD normaal doet :)

Yourwebhoster
13/12/09, 20:32
Ok excuses ... heb mij inderdaad niet in ZFS verdiept maar weet wel wat JBOD normaal doet :)
Hier ergens @WHT is een topic daarover en google is your friend:)

t.bloo
13/12/09, 23:19
Of Nexenta als je Debian kent

Waarbij je echter niet het idee moet hebben dat je het "op" Debian Linux kunt installeren. Het is namelijk een Debian distributie met een andere kernel dan de meesten hier zullen gebruiken.

Yourwebhoster
13/12/09, 23:23
Ik ben niet van plan debian te gebruiken, als ZFS gebruikt gaat worden wordt het op opensolaris.

stiller
14/12/09, 11:27
Als je voor zelfbouw kiest, bijvoorbeeld d.m.v. ZFS, zorg er dan wel voor dat je je data tussen twee machines repliceert. Zoals al gezegd hebben dit soort oplossingen geen volledige interne redundantie (controllers/datapaden), dus bij een hardware falen ligt alles eruit.

Yourwebhoster
14/12/09, 11:40
Als je voor zelfbouw kiest, bijvoorbeeld d.m.v. ZFS, zorg er dan wel voor dat je je data tussen twee machines repliceert. Zoals al gezegd hebben dit soort oplossingen geen volledige interne redundantie (controllers/datapaden), dus bij een hardware falen ligt alles eruit.
Zoals ik al schreef, het is de bedoeling om de data op twee machines te hebben, daar zorgt normaal gesproken drbd voor. Ik heb verder nog niet uit kunnen vinden hoe ik live data tussen twee machines kan laten repliceren, zodat de nodes direct kunnen overswitchen naar een andere SAN zonder data verlies.

Mikey
14/12/09, 11:46
Zoals ik al schreef, het is de bedoeling om de data op twee machines te hebben, daar zorgt normaal gesproken drbd voor. Ik heb verder nog niet uit kunnen vinden hoe ik live data tussen twee machines kan laten repliceren, zodat de nodes direct kunnen overswitchen naar een andere SAN zonder data verlies.

simpel toch, nfs, heartbeat drbd have fun :)

En wil je kunnen opschalen, pak een dure contoller en begin met klein aantal schijven. Prik er later schijven bij, vergroot je raidset en extend je lvm volume

Yourwebhoster
14/12/09, 11:58
simpel toch, nfs, heartbeat drbd have fun :)
Zat zelf aan iscsi te denken en ZFS die zichzelf repliceert. Ik weet niet of drbd ofp ZFS werkt, geen ervaring mee. heartbeat is default of course:)

Wido
14/12/09, 12:24
ZFS repliceert zichzelf niet (althans niet dat ik kan vinden). Je kan dit voor elkaar krijgen met zfs send en zfs receive, maar dat is niet realtime (al kan je er wel supergave backups mee maken!).

Wil je dan toch een failover maken moet je kijken naar SunCluster, zie ook mijn post op de OSOL mailinglist: http://opensolaris.org/jive/thread.jspa?threadID=110921&tstart=15

Pas als ZFS naar Linux komt kun je leuke dingen doen met DRBD, maar tot die tijd blijft het een beetje houtje touwtje werk.

Verder is het afwachten wat btrfs ons gaat brengen, wat het is onderhand wel duidelijk dat EXT, XFS en consorten hun langste tijd gehad hebben.

wdv
14/12/09, 12:49
ZFS repliceert zichzelf niet (althans niet dat ik kan vinden). Je kan dit voor elkaar krijgen met zfs send en zfs receive, maar dat is niet realtime (al kan je er wel supergave backups mee maken!).
Je kunt volgens mij gewoon continu een zfs send laten lopen, dus dan blijft hij gewoon continu doorsturen. Anders zal je het inderdaad met een cronjob moeten doen, maar dan is het nog steeds niet slechter dan een EqualLogic wat betreft replicatie :)

Wido
14/12/09, 12:56
Je kunt volgens mij gewoon continu een zfs send laten lopen, dus dan blijft hij gewoon continu doorsturen. Anders zal je het inderdaad met een cronjob moeten doen, maar dan is het nog steeds niet slechter dan een EqualLogic wat betreft replicatie :)Nope, dat gaat niet, net ff op Google gezocht.

Al kan je wel elke seconde een snapshot maken en weer een ZFS sync draaien, of je doet het elke minuut. Dan ben je bij een echte HW crash maximaal je interval tijd data kwijt.

Mikey
14/12/09, 12:59
Nope, dat gaat niet, net ff op Google gezocht.

Al kan je wel elke seconde een snapshot maken en weer een ZFS sync draaien, of je doet het elke minuut. Dan ben je bij een echte HW crash maximaal je interval tijd data kwijt.

En wat mag dan het voordeel zijn ten opzichte van drbd die dit realtime voor je kan afhandelen ?

Wido
14/12/09, 13:01
En wat mag dan het voordeel zijn ten opzichte van drbd die dit realtime voor je kan afhandelen ?DRBD is alleen maar low-level block replicatie. ZFS is een filesystem, RAID controller en volume manager in één.

Je kan DRBD en ZFS eigenlijk totaal niet vergelijken.

Mikey
14/12/09, 13:12
DRBD is alleen maar low-level block replicatie. ZFS is een filesystem, RAID controller en volume manager in één.

Je kan DRBD en ZFS eigenlijk totaal niet vergelijken.

Dat snap ik, maar ik vraag om de voordelen. Het feature list plaatje kan nog zo spannend zijn, de praktijk kan zwaar tegenvallen. En als ik in een eerdere posting al zie dat het niet realtime kan, wat zijn dan de voordelen ?

Wido
14/12/09, 13:45
Dat snap ik, maar ik vraag om de voordelen. Het feature list plaatje kan nog zo spannend zijn, de praktijk kan zwaar tegenvallen. En als ik in een eerdere posting al zie dat het niet realtime kan, wat zijn dan de voordelen ?Het is niet met elkaar te vergelijken, met ZFS kan je je filesystems dumpen, net zoals je met xfsdump kan.

Het is dat ZFS niet onder Linux draait en DRBD niet onder Solaris, anders had je ZFS boven op DRBD kunnen draaien, dan had je voor elkaar kunnen krijgen wat je wil.

Maar er is onder Solaris/ZFS zo even geen makkelijke mogelijkheid voor realtime data replicatie, tenzij je de storage direct bij Sun koopt, maar dat doe ik liever niet :)

Mikey
14/12/09, 13:50
Maar er is onder Solaris/ZFS zo even geen makkelijke mogelijkheid voor realtime data replicatie, tenzij je de storage direct bij Sun koopt, maar dat doe ik liever niet :)

Merci merci, duidelijk :)

maxnet
14/12/09, 14:07
Maar er is onder Solaris/ZFS zo even geen makkelijke mogelijkheid voor realtime data replicatie, tenzij je de storage direct bij Sun koopt, maar dat doe ik liever niet :)

Heb het (nog) niet uitgeprobeert, maar wellicht komt dit project in de buurt van wat je wilt: http://hub.opensolaris.org/bin/view/Project+avs/WebHome

Zit blijkbaar ook bij de standaard editie van Opensolaris: "For OpenSolaris 2008.11, the IPS packages for AVS are: SUNWscm, SUNWspsv, SUNWrdc, SUNWii"

Yourwebhoster
14/12/09, 15:50
Bedankt voor de info. Het linkje wat maxnet geeft lijkt wel op wat ik wil, ik moet het nog even verder doorlezen. Zoals ik het nu zie is ZFS erg mooi maar waarschijnlijk kost het mij veel werk om het goed te configureren, en ik denk dat drbd daarom een beter geschikte oplossing is voor mij ook omdat het gewoon op CentOS kan waar ik in tegenstelling tot solaris wel bekend mee ben. En omdat behalve budget de tijd ook gelimiteerd is die ik hier aan kan besteden is de bekende CentOS met drbd en heartbeat een beter geschikte oplossing voor mij, wellicht dat ik later nog eens de mogelijkheden van ZFS bekijk.

Verder de volgende vraag: Welk systeem is het beste wat performance betreft? ISCSI? NFS? Het is voor een linux virtualisatie platform, ik heb ooit eens gelezen dat iscsi beter dan nfs kan zijn maar zonder onderbouwing. Ik ga zelf hier nog naar googelen maar misschien dat een aantal WHTers hun ervaringen hierover kunnen delen?

Tim.Bracquez
14/12/09, 15:55
iSCSI en NFS is een wereld van verschil.

Is een paper (wel gedateerd!) : http://www.usenix.org/events/fast04/tech/full_papers/radkov/radkov_html/index.html

Mikey
14/12/09, 15:59
iSCSI en NFS is een wereld van verschil.

Is een paper (wel gedateerd!) : http://www.usenix.org/events/fast04/tech/full_papers/radkov/radkov_html/index.html

iscsi, fibre channel, nfs iets minder gedateerd ;)

http://www.vmware.com/files/pdf/vsphere_perf_exchange-storage-protocols.pdf

Yourwebhoster
14/12/09, 16:05
Ik zal het een en ander gaan lezen en zelf ook wat testjes gaan doen. Moet trouwens wel benadrukken dat er een budget is, fibre is niet bepaald goedkoop te noemen en daarvoor moet het nodige aangepast worden. Verlopig gewoon via het normale netwerk dus:)

Tim.Bracquez
14/12/09, 17:25
iscsi, fibre channel, nfs iets minder gedateerd ;)

http://www.vmware.com/files/pdf/vsphere_perf_exchange-storage-protocols.pdf
Dank, was dit al tegen gekomen maar vond het niet meer :-)

RobJEpping
14/12/09, 22:55
Moet trouwens wel benadrukken dat er een budget is, fibre is niet bepaald goedkoop te noemen en daarvoor moet het nodige aangepast worden. Verlopig gewoon via het normale netwerk dus:)

Wanneer je ISCSI gaat doen wordt gezegd dat je dat eigenlijk op een appart netwerk moet doen. Wanneer je dat geloofd is er geen groot prijsverschil tussen een echt goede ethernet switch en een FC switch en goede NICs met ISCSI offload en FC HBAs. Maarja ' t is maar wat je geloofd.

Moet zeggen dat onze Equallogic (PS6500E) ook aardig zijn best doet. En het voordeel: box ingericht voor redundancy (dus 2*PSU, 2* controller, genoeg interne bandbreedte, etc.). Prijs is best OK (na onderhandelen ;) )

Deze gast (http://blog.backblaze.com/2009/09/01/petabytes-on-a-budget-how-to-build-cheap-cloud-storage/) heeft ook goed nagedacht over zijn design, iig genoeg bandbreedte van disk naar MB.

Yourwebhoster
14/12/09, 23:01
Wanneer je ISCSI gaat doen wordt gezegd dat je dat eigenlijk op een appart netwerk moet doen. Wanneer je dat geloofd is er geen groot prijsverschil tussen een echt goede ethernet switch en een FC switch en goede NICs met ISCSI offload en FC HBAs. Maarja ' t is maar wat je geloofd.

Het is de bedoeling als deze opstelling gaat draaien dat het op een apart Gbit netwerk komt, opstelling zal ietwat anders zijn dan normaal gesproken omdat maar een aantal nodes toegang hoeven te hebben. En wat het probleem wordt met fibre dat de nodes die er op moeten ook over fibre moeten gaan beschikken, en dat gaat aardig in het prijskaartje zitten dan (correct me if I'm wrong).

Randy
15/12/09, 00:37
Ik mag het nu wel zeggen, ik zag het ook al op twitter verschijnen: De NPO heeft net 192TB extra storage in gebruik genomen op basis van NexentaStor (http://www.nexenta.com/corp/) (ZFS) voor het uitzendinggemist platform.

Yourwebhoster
15/12/09, 00:38
Ik geloof dat ik verlopig even genoeg heb om onderzoek naar te doen. Bedankt jongens:)

RobJEpping
15/12/09, 08:53
Het is de bedoeling als deze opstelling gaat draaien dat het op een apart Gbit netwerk komt, opstelling zal ietwat anders zijn dan normaal gesproken omdat maar een aantal nodes toegang hoeven te hebben. En wat het probleem wordt met fibre dat de nodes die er op moeten ook over fibre moeten gaan beschikken, en dat gaat aardig in het prijskaartje zitten dan (correct me if I'm wrong).

Recent prijzen gehad voor een Brocade 300 (=FC 4GB) met 8 poorten gelicenseerd en een HP Procurve 2900-24G. Het prijsverschil is ongeveer €400. Die Procurve is aan de kleine kant.

Heb zo geen prijzen van NICs en HBAs.

Dat je nodes HBAs moeten krijgen is logisch, maar vergeet niet dat je de ethernet poorten ook betaald (hebt).

BDW: FC werkt niet op basis van IP en dat kan een voordeel(tje) zijn in de beveiliging.

Yourwebhoster
15/12/09, 09:09
Recent prijzen gehad voor een Brocade 300 (=FC 4GB) met 8 poorten gelicenseerd en een HP Procurve 2900-24G. Het prijsverschil is ongeveer €400. Die Procurve is aan de kleine kant.

Heb zo geen prijzen van NICs en HBAs.

Dat je nodes HBAs moeten krijgen is logisch, maar vergeet niet dat je de ethernet poorten ook betaald (hebt).

BDW: FC werkt niet op basis van IP en dat kan een voordeel(tje) zijn in de beveiliging.
De ethernet poorten van zo'n node is goedkoper dan fiber, hangt natuurlijk ook van het type af maar in principe zou een dual port voldoen. Daarnaast zou ik nog wat meer ervaring moeten krijgen met FC, dus als ik dit ga toepassen wordt het pas in een later stadium:)
Ik houd het in elk geval in gedachte, bedankt.

Tim.Bracquez
15/12/09, 13:30
De ethernet poorten van zo'n node is goedkoper dan fiber, hangt natuurlijk ook van het type af maar in principe zou een dual port voldoen. Daarnaast zou ik nog wat meer ervaring moeten krijgen met FC, dus als ik dit ga toepassen wordt het pas in een later stadium:)
Ik houd het in elk geval in gedachte, bedankt.
Mag ik je er even op wijzen dat je niet de interne poorten moet gaan gebruiken, maar goede insteekkaarten. Dan ben je ook al een hoop geld kwijt. Goede Gbit kabels zijn ook niet aan de goedkope kant. Je spreekt over een klein prijs verschil tussen beide. Maar er zijn nog andere dingen waar je moet op letten. Ondersteund de hypervisor dit bijvoorbeeld (normaal wel / en anders zijn er wel drivers).
Denk als je niet van het ene naar het andere rack moet dat het best meevalt.

Yourwebhoster
15/12/09, 13:39
Mag ik je er even op wijzen dat je niet de interne poorten moet gaan gebruiken, maar goede insteekkaarten. Dan ben je ook al een hoop geld kwijt. Goede Gbit kabels zijn ook niet aan de goedkope kant. Je spreekt over een klein prijs verschil tussen beide. Maar er zijn nog andere dingen waar je moet op letten. Ondersteund de hypervisor dit bijvoorbeeld (normaal wel / en anders zijn er wel drivers).
Denk als je niet van het ene naar het andere rack moet dat het best meevalt.
Ik heb het over dual port, deze vind je over het algemeen niet op een moederbord terug;) Maar het schort me nog aan de kennis over FC, dat telt ook. Bovendien zal ik eerst testen of het voldoet voor het doel, zo niet dan gaat er naar andere opties gekeken worden. Ik verwacht wel dat uiteindelijk van het normale Gbit netwerk afgestapt wordt, maar dit zal waarschijnlijk pas gebeuren als het "kleine" storage netwerk uitgroeit tot iets groters, dan is een budget waarschijnlijk ook beschikbaar. Maar dat is allemaal toekomst praat, ik moet eerst dit maar eens goed laten werken:)

m_w_mol
17/03/10, 15:07
Je kan zoiets gerust zelf ineen knutselen. Supermicro heeft zo 4U kasten:
http://www.supermicro.com/products/c...846E1-R900.cfm
daarin steek je dan een 24poort SAS controller (of 2x 16port) en 1 of 2 netwerkkaarten

Waarschijnlijk mosterd na de maaltijd, maar, als je de 9U Chenbro-behuizing gezien hebt in de post van de TS, doet deze wel heeeel erg "gewoontjes" aan :)

Heb zelf overigens ervaring met de 3U Supermicro SC933 en dat is ook een mooi dingetje; daar passen echter "slechts" 15 schijven in.
http://www.supermicro.com/products/chassis/3U/?chs=933

Jesperw
17/03/10, 16:26
Deze supermicro is leuk: 36 Disks in een 4U. http://www.supermicro.com/products/chassis/4U/847/SC847A-R1400.cfm

Voor en achterkant dus. Heel apart.

frankske
19/03/10, 23:09
oh my. Hoe gaat die airflow lopen dan? Over airflow gesproken, wij hadden iets leuk voor met een Sun X4540 deze week: 48 disks in 4U, er staat overal op dat als je disks swapt, je dat "snel" moet doen. Alleen mag je het niet té snel doen, want dan werkt het niet. Hele verhaal op http://frank.be/articles/2010/03/17/allegro-ma-non-troppo/

Sander-
20/03/10, 20:14
Recent prijzen gehad voor een Brocade 300 (=FC 4GB) met 8 poorten gelicenseerd en een HP Procurve 2900-24G. Het prijsverschil is ongeveer €400. Die Procurve is aan de kleine kant.

Heb zo geen prijzen van NICs en HBAs.

Dat je nodes HBAs moeten krijgen is logisch, maar vergeet niet dat je de ethernet poorten ook betaald (hebt).

BDW: FC werkt niet op basis van IP en dat kan een voordeel(tje) zijn in de beveiliging.

Mag ik je erop wijzen dat dit het vergelijken van appels met peren is? Aangezien je een 24 poorts switch vergelijkt met een 8 poort. Verder heb je als je 2 van die switches wil gebruiken in een failover setup ook een ISL Trunk licentie nodig. Voor de trunk ben je minimaal 1 poort kwijt, maar vaak wordt gekozen voor een trunk group, aangezien je dan risico van uitval kabel + bandbreedte vergroot. En je hebt voor iedere machine een dualport HBA nodig, reken op 2000 a 3000 dollar per HBA.

Kies je voor singleport en single 300 is het allemaal wat goedkoper, maar dan doe je in mijn ogen wel concessies tov een ip-based setup op het gebied van availability. Tot slot is het dan ook wel handig als je weet hoe die dingen een beetje werken, want dat is toch wel ff iets anders dan het inrichten en beheren van een ethernet-switch.

gjtje
21/03/10, 02:13
Nou, met €1000 per dualport HBA ben je wel klaar hoor, zelfs met 24/7/4 gold support. ;)

Maar goed, als je elke server op 2x4Gb over iSCSI wilt ontsluiten ben je ook aardig wat centjes kwijt, als je toch appels met peren vergelijkt, vraag is of die bandbreedte nodig is.

BoudewijnS
21/03/10, 08:55
Denk goed na over een SAN, elk onderdeel is belangrijk, waarvoor wil je het gebruiken. Je heb zo een desinvestering gedaan als je ergens op bezuinigd en er na een tijdje achterkomt dat het niet helemaal werkt zoals je verwacht.

beenske
22/12/10, 16:32
Deze kast is ook erg fijn => http://www.supermicro.com/products/chassis/4U/417/SC417E16-R1400LP.cfm
72 disks in 4U :|

QBell
22/12/10, 20:48
Deze kast is ook erg fijn => http://www.supermicro.com/products/chassis/4U/417/SC417E16-R1400LP.cfm
72 disks in 4U :|

Hebben wij er 2 van draaien. Zijn echt mooie bakken.


oh my. Hoe gaat die airflow lopen dan? Over airflow gesproken, wij hadden iets leuk voor met een Sun X4540 deze week: 48 disks in 4U, er staat overal op dat als je disks swapt, je dat "snel" moet doen. Alleen mag je het niet té snel doen, want dan werkt het niet. Hele verhaal op http://frank.be/articles/2010/03/17/allegro-ma-non-troppo/

Je modo zit op 2U (dus waar de disken aan de achterkant op houden.
Voor de onderkant heb je 4 grote fans in het midden die voor de lucht in trekken en door de achterste disken uit blaast.
Wij hebben hiermee gemeten en bij je modo komt er warmere lucht uit als langs die dubbele disken.

Mark17
22/12/10, 20:53
Deze kast is ook erg fijn => http://www.supermicro.com/products/chassis/4U/417/SC417E16-R1400LP.cfm
72 disks in 4U :|

Is die kast al leverbaar? Toen ik een tijdje terug naar een vergelijkbare kast keek was de betreffende kast nog niet leverbaar. Op dit moment kun je je trouwens ook nog afvragen of je de voorkeur geeft aan 2,5" of 3,5" schijven (prijs/prestatie verhouding).

Met extenders kun je ook leuke opzetjes opbouwen.