iSCSI of Fibre Channel voor 150+ TB storage omgeving?

[]Byte[]

Voor een redelijke grote storage-omgeving (150+ TB) heb ik een paar vraagstukken waar ik nog niet echt uit ben. Gaan we gebruik maken van iSCSI of Fibre Channel? CIFS, NFS of GFS?
iSCSI zit tegenwoordig op iedere redelijke server onboard (TOE), en kan over bestaande infrastructuur. Snelheden van 1Gbit of 10Gbit.
Fibre Channel: separate infrastructuur, redundantie, betrouwbaar, snel (4-8 Gbit), beperkte afstand die je kan overbruggen en is wel prijzig.
En dan hebben we nog de keuze van filesysteem: CIFS, NFS of GFS.
De servers bestaan uit zowel Windows als Linux systemen en moeten beide platformen op dezelfde filesystemen tegelijk kunnen werken. Het zal ook een redelijk I/O intensieve omgeving zijn! (waarvan ca. 95-98% read's van extreem veel en kleine (overgrote deel: < 1 MB) bestanden)
NTFS is eigenlijk geen optie ivm locking problematieken.
Ik heb ooit begrepen dat de problematiek bij gebruik van CIFS is dat de doorvoersnelheid een beperking gaat worden. NFS zou dit probleem daarentegen niet hebben, maar zou wel weer meer last hebben van latency problematieken. En dan hebben we nog GFS als optie. GFS heeft wel weer als groot voordeel dat het extreem schaalbaar is. (wat ook de bedoeling van de gehele omgeving is)
De LUN's zullen 10+ TB worden.

Zijn er misschien mensen die ervaringen hebben met soortgelijke omgevingen hebben hebben hints en tips hiervoor?

@ WhizzCat

Wil je ook gaan mirroren/failover/[...]

Dat zijn nog zaken die nog niet zijn vastgesteld maar de optie wordt wel open gehouden.
Verder zoals het er nu naar uitziet zal het een centrale opstelling worden voor de storage en de servers, maar een deel zal wel decentraal zijn om de data te "pushen" naar de centrale opslag.

De achterliggende hardware-keuze is eigenlijk niet zo'n hot issue. Of het nu HP, EMC, NetApp, Compellent of wie dan ook is.

[ Voor 14% gewijzigd door ]Byte[ op 11-08-2010 10:13 ]

[PolarBear]

]Byte\[ schreef op woensdag 11 augustus 2010 @ 09:35:
Fibre Channel: separate infrastructuur, redundantie, betrouwbaar, snel (4-8 Gbit), beperkte afstand die je kan overbruggen en is wel prijzig.

Inderdaad, FC is beperkt in afstand, 150 tot 50000 meter is vrij beperkt. FC gaat tegenwoordig tot 20 Gbit. Overigens is 150 terrabyte niet echt een redelijk grote storage omgeving te noemen.

[DukeBox]

Het hangt natuurlijk ook af of de 150TB centraal of de-centraal staat. Wij hebben een kleine 120TB de-centraal staan middels iSCSI (grootste locatie is 60TB). Over het algemeen halen we meer bandbreedte voor een 10e van de kosten met iSCSI. Latency verlies is meer afhankelijk van het SAN en iSCSI oplossing (native of middels een FC-2-iSCSI bridge o.i.d.)

[ Voor 38% gewijzigd door DukeBox op 11-08-2010 09:44 ]

[WhizzCat]

Pft, dit had w.m.b. naar PNS gemogen

Dit is wel een vrij grote omgeving, zoals je zelf al zegt. Ik denk dat het sowieso verstandig is om met een aantal leveranciers om tafel te gaan zitten (niet tegelijk , EMC, HP, Dell, etc. ) en hun dit eens voor te leggen. De keuze voor cabinetten en type schijven is ook een erg belangrijke. Fata, Sata, etc. Dat bepaalt een groot deel van je read/write capaciteit. Ook de samenstelling van je Vraid sets en het uitsmeren over enclosures is iets wat snelheid kan bepalen.

Qua filesystems durf ik eigenlijk niet zoveel te zeggen. Dat is niet echt mijn ding.

Voor veel aparte reads zou ik toch neigen naar een separate infrastructuur, iSCSI of SAN/Fiber maakt niet uit, die moeten beide apart aangelegd worden wil je optimaal kunnen presteren.

Ik denk dat je gaat uitkomen op een XP12000 serie van HP of iets in die richting. Dat zijn grote, profi storage gevallen. Kost wat, maar dan heb je ook wat

Mogen we trouwens ongeveer de achtergrond weten van het soort omgeving? E.g. in wat voor soort omgeving zou je veel kleine bestandjes vooral moeten lezen?

-edit-

Decentraal/centraal is ook zoiets idd. Wil je ook gaan mirroren/failover/cluster-achtige zaken, moet je ook nog es rekening houden met latency

[ Voor 6% gewijzigd door WhizzCat op 11-08-2010 09:46 ]

[TrailBlazer]

Of je nou storage over IP of FC doet je latency blijft van invloed dus ook de max afstand. Ik weet niet of alles niet is of enkel de stroage omgeving. Als alles nie is zou je ook kunnen kijken naar FCOE. Veel minder FC switches nodig en minder bekabeling naar je servers toe.

[MrFX]

Even voor de duidelijkheid ]Byte[ zijn de windows en linux servers fysiek of virtueel?

[]Byte[]

MrFX schreef op woensdag 11 augustus 2010 @ 11:03:
Even voor de duidelijkheid ]Byte[ zijn de windows en linux servers fysiek of virtueel?

Fysiek! Juist ook omdat anders de bottleneck naar het systeem gaat en dat willen we juist zoveel mogelijk voorkomen.

[DukeBox]

TrailBlazer schreef op woensdag 11 augustus 2010 @ 09:55:
..Als alles nie is zou je ook kunnen kijken naar FCOE. Veel minder FC switches nodig en minder bekabeling naar je servers toe.

Het is opzich een mooie midden weg voor volledige HBA's en toch goedkoper draagvlak maar de beperkte toevoegingen van FC vind ik niet afwegen tegen de kosten van de HBA's en de toch minder flexibele schaalbaarheid van FC.
Ikzelf ben erg van van iSCSI met equallogic, echter omdat het een native oplossing is heb je aléén iSCSI., geen NFS, SMB enz.. Daarnaast is er ook nog geen synchrone replicatie (zonder 3e partijen), alleen a-synchroon. Daar tegenover staat wel weer dat verder alles volledige licentieloos is.

[MrFX]

]Byte\[ schreef op woensdag 11 augustus 2010 @ 11:19:
[...]

Fysiek! Juist ook omdat anders de bottleneck naar het systeem gaat en dat willen we juist zoveel mogelijk voorkomen.

Aan je reactie te merken loopt de huidige storage omgeving aardig op zijn tandvlees. Met de juiste hardware en infrastructuur zou virtualisatie toch heel wat voordelen opleveren t.o.v. de huidige situatie.

[]Byte[]

Dat heeft meer te maken met de omgeving als mogelijk voordeel behalen uit virtualisatie.
Zoals ik al eerder had opgemerkt is dit een I/O intensieve omgeving. Hierbij zal ook de CPU-load redelijk belast gaan worden.
Ik heb er nog geen kostenmodel op los gelaten, maar om te gaan virtualiseren zal ik waarschijnlijk niet veel verder komen dan 2 en misschien, onder optimale omstandigheden, 3 servers die dan gevirtualiseerd kunnen worden. Maar dan loopt het ook gelijk op z'n tandvlees.
Op dit moment is de honger naar opslagcapaciteit voor de komende jaren de grootste issue. (groei naar ca. 500TB voor 2014)

Hierbij wordt ook gekeken naar mogelijkheden tot deduplicatie. (DataDomain)

[MADG0BLIN]

Ik zou persoonlijk toch echt om tafel gaan zitten met wat grote partijen die al eerder genoemd zijn. Er zullen hier vast mensen rondlopen die dit vaker hebben gezien, maar zoals vaker bij dit soort omgevingen zullen jullie je eigen eisen zeker hebben en kan je die misschien goed laten invullen door partijen als HP, EMC, Netapp en zo verder.

Succes in ieder geval.

[TrailBlazer]

Grappig dat je bij storage je altijd naar de leverancier toe gaat in plaats van naar een onafhankelijke partij. Bij netwerken ga je maar zelden direct naar de leverancier toe en met server hardware volgens mij ook niet zo snel

[]Byte[]

Het gaat mij ook meer om de te gebruiken infrastructuur en koppeling van de storage, en niet zozeer de achterliggende hardware (storage).

[Bl@ckbird]

TrailBlazer schreef op woensdag 11 augustus 2010 @ 09:55:
Of je nou storage over IP of FC doet je latency blijft van invloed dus ook de max afstand. Ik weet niet of alles niet is of enkel de storage omgeving. Als alles niet is zou je ook kunnen kijken naar FCOE. Veel minder FC switches nodig en minder bekabeling naar je servers toe.

Het idee van FCoE is dat je Fibre Channel over 10Gbps Ethernet doet.
De standaard Catalyst ethernet switches en de MDS Fibre Channel switches heeft Cisco samen gevoegd.
Dit is de Nexus 5000 en die doet FC, 10Gbps Ethernet en FCoE.

Voor je servers heb je dan Converged Network Adapters nodig, van bijvoorbeeld Emulex of Qlogic.
Voor langere afstanden moet je de juiste buffer credits bereken i.v.m. de latency voor FC of FCoE.

]Byte\[ schreef op woensdag 11 augustus 2010 @ 09:35:
Ik heb ooit begrepen dat de problematiek bij gebruik van CIFS is dat de doorvoersnelheid een beperking gaat worden.
NFS zou dit probleem daarentegen niet hebben, maar zou wel weer meer last hebben van latency problematieken. En dan hebben we nog GFS als optie. GFS heeft wel weer als groot voordeel dat het extreem schaalbaar is. (wat ook de bedoeling van de gehele omgeving is)

En..

]Byte\[ schreef op woensdag 11 augustus 2010 @ 09:35:
Verder zoals het er nu naar uitziet zal het een centrale opstelling worden voor de storage en de servers, maar een deel zal wel decentraal zijn om de data te "pushen" naar de centrale opslag.

CIFS is een erg chatty protocol. Om een bestand via het netwerk te downloaden worden er erg veel kleine pakketten verstuurd. Op het LAN is vaak dit geen probleem (tenzij je een hoge I/O load hebt), maar op het WAN heb je latency en dat kan aardig je doorvoer snelheid beperken.

Dit kan je optimaliseren met WAN optimalisatie zoals Cisco WAAS of Riverbed Steelheads.
Wat whitepapers staan hier en hier. Een demo is hier en hier te vinden. (Hoewel die laatste de mobiele variant is...)

Latency kan je met WAN optimalisatie niet oplossen, maar de effecten van latency op je datastroom wel.
(Zoals het flink reduceren van je backup window.) Specifiek voor iSCSI zou ik Riverbed binnenkort even in de gaten houden. Hoewel ze nu al aardige performance halen.

Standaard Catalyst switches hebben een buffer van 180kb per poort.
Cisco heeft ook 4900 serie Data Center switches. Deze hebben een buffer van 16MB voor de hele switch.
(Niet alle poorten staan altijd te bufferen.)

Daarnaast is de latency van deze switches lager.
Dit is handig als je iSCSI verkeer wil doen. (Helemaal als je weet dat dit een hoge I/O load zal zijn met veel, kleine pakketten.) Deze switches kan je ook standaard voorzien van redundant voedingen.