Brocade komt met 8Gbps-blades voor oem's

Brocade heeft de eerste blades met 8Gbps Fibre Channel-technologie richting oem's verstuurd. De blades moeten hun weg vinden naar Brocade's vlaggenschip op san-gebied: de 48000 Director.

De overstap naar 8Gbps-technologie betekent een verdubbeling van de bandbreedte ten opzichte van de huidige high-end san-producten. Volgens Brocade is deze verbetering vooral waardevol voor datacenters met grote virtuele serveromgevingen, aangezien ze nu aanzienlijk meer virtuele machines kunnen uitrollen. Er zijn echter ook nadelen verbonden aan de overstap van 4Gbit/sec naar 8Gbit/sec, zoals hogere kosten voor bekabeling. Of de overstap net zo succesvol zal verlopen als die van 2Gbit/sec naar 4Gbit/sec is afhankelijk van de vraag of er bij san-gebruikers voldoende behoefte is aan een hogere snelheid.

Naast de overstap naar 8Gbps-technologie heeft Brocade de interoperabiliteit van de 48000 Director met McData-san-technologie verbeterd. Klanten die het Fabric Operating System van de 48000 updaten kunnen hun systeem daardoor direct te verbinden met de Brocade M6140 en de Brocade Mi10K-directors, evenals met traditionele McData-switches. De 8Gbit/s-blades van Brocade moeten begin volgend jaar beschikbaar komen, volgens The Register. Over de komende director die het nieuwe vlaggenschip van Brocade moet worden en die de codenaam 'Neptune' heeft meegekregen, laat het bedrijf nog niets los.

Reacties (12)

[Bierkameel]

Leuk spul dus om VMware ESX op te draaien.
Schijf I/O is nog steeds de bottleneck om SQL, Exchange en TS servers te virtualiseren, geheugen is wel een fractie langzamer maar dit is meestal het probleem niet.

Met 2 van deze SANs is een failover naar een andere server echt leuk.

[smartsys]

Gozer, dit zijn alleen switchen. Deze dingen zijn totaal niet bepalend wat de uiteindelijke schijf i/o is. Deze switchen worden gebruikt om Storage componenten, bijv. diskarrays of andere switchen met elkaar te verbinden.
Wat veel mensen doen is FC vergelijken met Ethernet omdat de snelheden een beetje overeenkomen. Dit is zéér verkeerd. Zie FC als de locale SCSI of SAS bus binnen je server. Deze verbinding is niet OS afhankelijk. Het OS vraagt iets aan de Storage Controller en deze handeld de rest af met de schijven.
Binnen een SAN is het ongeveer hetzelfde.
Een HBA binnen een server fungeert als SCSI kaart. Deze krijgt vanuit de SAN controllers een of meerdere LUN(s) gepresenteerd en het verkeer tussen de HBA en de SAN controllers is FC.
Binnen Windows hebben we te maken met NTFS. Oftewel traag, vooral als er heel veel kleine bestanden (<4KB) op een schijf staan. Met dit soort bestanden wordt zoveel I/O gegenereerd dat je tientallen tot zelfs honderden schijven nodig hebt om een 2GB FC verbinding vol te trekken.
Ga je echter buiten het OS om, dus bijv. bij image back-up, dan wordt er alleen naar blocks gekeken en niet naar files en dan zijn snelheden van 300 tot 800MB/s vanaf één HOST plotseling helemaal niet raar meer. Heb je echter tientallen hosts die tegelijkertijd efficiente verkeer voeren, dus geen NTFS'en met miljoenen kleine bestanden, maar bijv. uncompressed HD video, dan loopt vooral het verkeer van en naar de diskarrays vol en is 4GB of zelfs 8GB FC nodig om de boel werkend te houden. Naar de host zelf is 2GB FC dan vaak meer dan voldoende.

Kortom: Ook een VMware host met gemiddeld 20VM's zal via een active/active 2GB FC verbinding geen bandbreedte gebrek hebben. 10 van deze hosts kunnen echter wel de verbinding naar de diskarrays voltrekken, dus moet hier óf de bandbreedte omhoog óf meer parallele verbindingen naast elkaar. FC switch poorten en HBA's zijn best prijzig, dus is meer bandbreedte vaak goedkoper om toch de gewenste performance te kunnen bieden en daar zijn deze grote switchen voor. Deze kom je overigens niet in een school of een gemiddeld kantoor tegen. Ook een grote overheid zal niet snel dit soort switchen inzetten, maar bijv. bij Shell of Microsoft of IBM zullen dit soort apparaten wel gebruikt gaan worden.

[Anoniem: 153393]

volgens mij heb je geen ruk aan die switches of zo'n netwerk als je (SQL) vmware op intelbased servers draait. de systeem pci bus is dan je gootste bottle neck.

[Olaf van der Spek]

de systeem pci bus is dan je gootste bottle neck.

Heb jij misschien de introductie van PCI Express gemist?
Anders heb je ook nog PCI-X.

[Olaf van der Spek]

Schijf I/O is nog steeds de bottleneck om SQL, Exchange en TS servers te virtualiseren,

Als je dit soort IO nodig hebt ga je dat soort servers toch niet virtualiseren?

[Anoniem: 1322]

Als men VMware gebruikt wil men al snel alles virtualiseren.
Dit om de functies als HA,DRS,disaster recovery en clonning funtionaliteit te gebruiken die vmware infrastructure bied.

[Anoniem: 227339]

VMware betekent automatisch dat je snelheid verliest op IO, dus als je bijv. een database hebt die zoveel IO genereert dat je 8GBit FC vol trekt, dan ga je dat zeker niet op VMware draaien en als je dan HA nodig hebt bouw je een cluster... De voordelen van VMware met HA, DRS e.d. wegen dan niet op tegen het verlies aan IO...
En zo'n server clonen is met een highend storage systeem ook geen probleem, de luns kan je bij dit soort apparaten gewoon in het storage systeem clonen zonder tussenkomst van de server....

[n4m3l355]

Hoe moet ik dit eigenlijk lezen? De onderlinge blades kunnen dus veel sneller met elkaar communiceren en zijn dus beter geschikt om bv clusters ermee te bouwen?

[froggie]

Servers kunnen op 8Gb/s met de switch worden verbonden waardoor de bandbreedte richting de storage devices wordt vergroot. Hierdoor zullen data intensieve applicaties in theorie een betere performance halen. Latency van je netwerk neemt echter niet af, dus het is de vraag in hoevere die extra bandbreedte daadwerkelijk nodig is en klanten daadwerkelijk behoefte hebben aan deze blades.

[Olaf van der Spek]

Latency van je netwerk neemt echter niet af,

Is netwerk latency uberhaupt een issue dan, als het over storage gaat?

[spierie]

Op zich niet, latency wordt pas een issue op grotere afstanden. Binnen het datacenter dus niet. Snelheid van licht in glas is ±200.000km/sec, dus op 200km krijg je een latency van 1msec (roundtrip dus 2msec). Dit betekent dus dat 200mtr ongeveer 1usec latency geeft.
De 48000 kan intern een pakketje van poort naar poort switchen in ongeveer 2usec. Deze gegevens bij elkaar geeft dus latencys van onder de 10usec binnen het datacenter, dit heeft dus geen of zeer weinig effect op de snelheid van de storage, welke nog steeds in milliseconden gerekend wordt, zelfs in de high-end storage systemen van EMC/IBM/HDS etc.

[Keiichi]

Voor HPC's hebben we infiniband