Snelheid SAN

[wreckdicilous]

Hallo,

Wij maken gebruik van de volgende hardware:

Qsan (type ff niet bij de hand) met 16x WD Caviar RE4 2 TB in een Raid 6 (WD2003FYYS)
deze is voorzien van 4x 1Gb poorten die niet getrunct zijn!

SRW 2024 van linksys (Gb switch)
Qlogic HBA aangesloten (qla4052c, niet getrunct)
HP350ML (1x 3GHz, 1GB)

Dus: QSAN > Linksys2024(dedicated) > Qlogic HBA
genoeg info?

Wat voor een snelheid mag ik hier van verwachten? Snelheid ligt nu tussen de 15-30MB/s

In de toekomst gaan we de poorten wel truncen maar ik had nu al een hogere snelheid verwacht...

Alvast bedankt!

[TrailBlazer]

De vraag is of trunken zin heeft omdat het om maar een server gaat. Als je namelijk maar een (iSCSI) tcp sessie tussen je server en SAN doos hebt staan zal deze nooit meer dan 1 van de 2 links gebruiken.

Dat ding ondersteunt niet eens trunking dus dat is makkelijk.

[jvanhambelgium]

Mijn inziens is dit een belachelijk lage snelheid voor deze setup. (ik doe thuis met iSCSI meer als het dubbel)
Je gebruik sowieso een dedicated iSCSI HBA adapter in je server.

Zelfs met 1GB link met 1 "test" server moet je zeker ergens naar de 80MBytes/sec gaan!


Zit alles netwerktechnisch in orde ? Overal effectief gigabit speed LAN-technisch dan ?

[wreckdicilous]

Er zijn in totaal 4 machines aangesloten, één met een HBA met dubbele poort en 3 met enkele poorten.

2 van deze systemen zijn voorzien van ESX, daar bovenop een DC en een Exchange server.

1 systeem is momenteel niet aangesloten.

Eerst stonden de "hardeschijven" van de DC en de EX server op t SAN, later zijn deze naar de lokale hardeschijven van de fysieke machines gezet omdat we performance issues hadden...
(exchange is niet beschikbaar meldingen bij outlook gebruikers, trage OWA, enz...)

De Gbit lampjes van de Linksys srw2024 branden netjes.

Ik heb een tijd geleden in het weekend, wat getest zodat er geen andere zaken het SAN belasten. Toen kwam ik op de 15-30MB/s uit...

Dus ik ga van t weekend maar verder testen, wellicht dat de switch en de HBA of SAN elkaar niet liggen? Aangezien t een relatief goedkoop switchje is...

Handig de kabel(+cross) van de HBA direct op het SAN te pluggen en de rest te ontkoppellen en daarna op snelheid te testen?

[jvanhambelgium]

wreckdicilous schreef op maandag 11 januari 2010 @ 11:46:
Handig de kabel(+cross) van de HBA direct op het SAN te pluggen en de rest te ontkoppellen en daarna op snelheid te testen?

Als je die mogelijkheid hebt zeker doen met een cross-cable!
Dan moet het gewoon *vliegen* qua snelheid, zonder twijfel.

Als het dan nog zo povertjes is moet je ook eens op de SAN beginnen kijken (definitie van de arrays etc)

[MMaI]

15-30 MB/sec is alleen een interessant cijfer als we weten welk type data je er overheen gooit. Als je namelijk 15-30 MB/sec haalt met files van 1kb is er weinig aan de hand, maar als je grote files schrijft is de performance erg laag.

De beste manier om te kijken waar en of er problemen zijn is alle onderdelen afzonderlijk te testen.
Sluit dus de qsan op een directe connectie aan met de HBA en draai een test
Sluit de switch aan met een andere client en je 350ML test de snelheid client to client (monitor packetloss, ping tijden etc)
Omdat je geen typenummer geeft van de Qsan weet ik niet welke aansluitingen daar nog meer op zitten, maar als je hier bijvoorbeeld eSAS/eSATA op hebt zitten kun je ook nog daarop testen

Controleer daarna ook even je logfiles etc voor de zekerheid om te kijken of er niet ergens een driver probleem op je 350ML roet in het eten gooit. Ik neem aan de de 350ML windows draait, dus kijk bij performance kort naar je netwerk belasting.

Wat natuurlijk ook een mogelijkheid is, is dat je client data niet sneller aanlevert (bijvoorbeeld door grote berekeningen of simpelweg het ontbreken van zulke grote hoeveelheden data), dus is altijd de vraag of er ook daadwerkelijk vertraging optreed, of dat de gevonden waardes alleen benchmark resultaten zijn.

[wreckdicilous]

Het SAN type = De Storagedata Xi3160 maar ik weet dat deze door QSAN gefabriceert is.

Als ik test kopieer ik bestanden van ~100MB tot 2GB soms ook groter, deze kopieer ik dan naar de lokale schijf van de ML350, (3x 73GB 10K in een raid5)

Ik ga in het weekend wat tests draaien daarna post ik wat resultaten...

[DJ]

Ik zou sowieso kijken naar de mogelijkheden van Jumbo frames. De LinkSYS switch ondersteund Jumbo frames. Je moet het in ieder geval end-to-end ondersteunen. Dus de SAN op Jumbo frames, de switch op Jumbo frames en de ESX machines (en andere servers) op Jumbo frames zetten.

Verder uiteraard zorgen voor een apart VLAN met een klein subnet (dus geen 10.0.0.0/8 subnet bijvoorbeeld, maar een klein /24 of kleiner subnet).

Succes!

[Verwijderd]

Ik sluit me volledig aan wat DJ zegt m.b.t. Jumbo frames aan of uit.
Dit kan zo een factor 8 schelen wat betreft burst rate.

Verder de vraag of een Linksys nu wel een goede keuze is.
Zet er een krachtige Cisco switch neer en je performance gaat zeker vooruit!

Nadat je herdefinitie van de ipconfig op je SAN poorten hebt uitgevoerd moet je aan de client kant wel wat aanpassen.

Verder is ook de data die je uiteindelijk verstuurd over je netwerk van invloed op de performance.
Er is een optimale balans tussen pakket grote die je aanbiedt en wat encapsulated wordt. Dit speelt zich m.n. op HBA of initiator niveau af maar vertaald zich wel in uiteindelijke performance.

[jvanhambelgium]

Begin maar lekker met de basics zonder direct te gaan prullen met oa Jumbo Frames.
Met die vette HBA's zal de toegevoegde waarde niet erg groot zijn denk ik.

Steek een cross-cable tussen client <-> SAN en doe maar wat file-copietjes.
Je mag wel ergens tussen 60-85MBytes per seconde halen hoor als je ietwat client gebruikt.

DIe eerder geposte 15-30MBytes zijn te gek voor woorden met zo'n vet SAN!

[Westereen]

wreckdicilous schreef op maandag 11 januari 2010 @ 12:19:
Als ik test kopieer ik bestanden van ~100MB tot 2GB soms ook groter, deze kopieer ik dan naar de lokale schijf van de ML350, (3x 73GB 10K in een raid5)

Ik ga in het weekend wat tests draaien daarna post ik wat resultaten...

Die HP ML350 is dat een G5? Of een ander model met een Smart Array E/P200 controller? De schrijfsnelheid van deze controller in combinatie met RAID5 is namelijk rond de waardes die jij aangeeft, dus dat zou de test slecht beinvloeden (kortom je zal moeten kiezen voor een andere test). Hoe performen je lokale schijven in die HP ML350? Wil je eens een output van atto disk benchmark posten?

[ Voor 3% gewijzigd door Westereen op 13-01-2010 22:26 ]

[axis]

Hier nog een heeeel lang topic met vergelijkingsmateriaal: http://communities.vmware.com/thread/197844, hoewel het misschien over een andere orde van grootte speelgoed gaat.

[Verwijderd]

Als ik moet gokken zal die bottleneck in die linksys zitten.

Laatst teste gedaan in een esx 3.5 ubuntu machine gekoppeld aan een NFS share op een san.
Ding haalde 80 MS/sec over een enkele 1GB link. Windows moet toch wel 50 MB/sec aan kunnen over SMB 1.0

[ Voor 12% gewijzigd door Verwijderd op 23-01-2010 10:51 ]

[Verwijderd]

Even zonder specifieke kennis van dit SAN (geen idee of ik dit met een EMC kan vergelijken ofzo).

Je draait ESX en dus VM's op dat SAN. Of doe je dat nu helemaal niet meer?
Dan ga je dat SAN meteen flink belasten qua IO/s.

Een snelle SAS-disk doet waarschijnlijk een 500 IO/s. Zet 16 van die disks in 1 array en je hebt een array die ongeveer 16x 500 IO/s kan leveren - in ideale omstandigheden - dus max. 8.000 IO/s. Nou weet ik niet wat die WD's (SATA?) doen, maar dat zal wel een stuk minder zijn dan 500 IO/s.

Wij draaien een (wat ouder) EMC SAN op dit moment met fibre-disks en merken ook dat de load vooral bepaald wordt door je IO/s en NIET door je MB/s.

Caching is in deze dus ook zeer belangrijk. Want daarmee verhoog je de max. IO/s van je SAN enorm. Elke IO die uit cache geleverd kan worden, hoeft niet van de disks te komen.

[ Voor 11% gewijzigd door Verwijderd op 23-01-2010 11:04 ]