Storage en Netwerk uitdaging (2)

Vorige week besloot ik na een aantal berichten heen en weer op Twitter dat het beter was even een bericht op mijn website te zetten over het probleem waar ik op het werk mee te maken had.. Dat bericht werd wat groter dan verwacht maar stond na 2 uurtjes schrijven online. Gelukkig namen zowel Steph als Andries de tijd om met me mee te denken om tot een goede oplossing te komen.

Ik heb een 11-tal scenario’s uitgewerkt en getest (klik op onderstaand plaatje) om te kunnen bepalen waar het probleem nou zat. Mede door de tips van Andries in zijn meer dan uitgebreide reactie is het uitendelijk gelukt om te vinden waar de vertraging vandaan kwam.

metingen

Tevens heb ik een stuk performance log opgeslagen om te kunnen kijken of de bottleneck dan niet toch op de server zou zitten. Bij het bestuderen van deze logging bleek dat de disk queue length van de SSD die de data aan moest leveren onder de 0.1 bleef, dat in combinatie met een verwaarloosbare CPU belasting en een beperkte hoeveelheid netwerkverkeer bevestigden nogmaals dat de server het probleem niet kon zijn. Om dit te bevestigen heb ik als test terwijl de server 6 clients van data aan het voorzien was (met 300 Mbit) een kopieractie van 40 GB naar de 3 andere servers gestart.. Meteen zat de Gbit verbinding van de server op  92% belasting, wat in dit geval inclusief de overhead onderveer het max is (941 Mbit bij een packetsize van 64k). Vanaf dit punt was het zeker dat de server de beperking niet was.

Steph had al eerder aangegeven dat CIFS mogelijk het probleem was, nadat we de server uitgesloten hadden kwamen Andries en ik eigenlijk tot de conclusie dat het wel in die hoek MOEST zitten.. Om dit te testen heb ik de 6 laptops opnieuw ingericht en weer de standaard filetransfer gestart (490 blokken van 100 MB, 1 robocopy sessie). De netwerkbelasting op de laptosp schommeld op dat moment rond de 50-60 Mbit. Wanneer ik dan handmatig nog een extra Robocopy sessie start van een 4,5 GB bestand schiet de netwerkactiviteit naar +- 300 Mbit op de desbetreffende client.. Hieruit valt op te maken dat het verhogen van het aantal gelijktijdige Robocopy acties de snelheid drastisch doet verhogen..

Op dit punt was het probleem duidelijk en eigenlijk ook meteen de beste oplossing. De nieuwste versie van Robocopy bied ondersteuning voor simultane downloads, deze versie (XP0027) werkt helaas alleen op Windows 7 en Windows Vista.. Als noodoplossing heb ik een kort AutoIT scriptje geschreven dat 2 robocopy sessies start. Wanneer dit script gebruikt wordt starten er 2 gelijktijdige kopieracties.. De totale snelheid van 6 clients komt dan op de 807 Mbit te liggen, wat ruim voldoende is voor wat wij van plan zijn (100 Mbit per client is de max die we met dit netwerk met 10 clients gelijktijdig kunnen behalen).

cacti

Het enige dat nu nog rest is het schrijven van een net script en de implementatie in het grote installatie project, maar dit laat ik volgende week aan anderen over (die zijn daar stukken beter in).

Dan rest mij verder niets dan Steph en Andries te bedanken voor hun hulp bij het oplossen van dit probleem en het nemen van een vrije dag aan het einde van deze week..

8 comments

  1. Nope, dat verbaasde mij ook, maar ik gok dat het iets met prioriteiten te maken heeft, de eerste kopieractie draaide daar op de achtergrond en de 2e op de voorgrond.. In de nieuwe situatie lopen ze beiden gelijk op de voorgrond.

  2. Viel mij ook op inderdaad. Weet niet zo goed hoe dat te verklaren is, maar als het werkt, dan werkt het! 😀

    Als je nog eens zoiets moet bouwen toch eens FTP proberen (als je ook wat meer tijd hebt) die heeft dit soort nadelen volgens mij niet. 🙂 CIFS Blergh.

  3. Dit soort dingen maken de IT leuk, vond het leuk dat je deze zo sociaal opgelost hebt, open en bloot heeft hem leuk en interessant te maken! 🙂

  4. Ja, maar bij FTP heb je zeer waarschijnlijk geen meerdere threads nodig, aangezien deze niet gebonden is aan allerlei CIFS limitaties. Althans in mijn ervaring haal je over het algemeen 35 a 40MB/sec (XP) tot 65MB/sec (Vista/7) waarbij je met FTP gewoon 100MB/sec met gemak trekt. 🙂

  5. Ik heb deze week geen tijd meer om naar het FTP gebeuren te kijken helaas 🙁 (vandaag in Zwolle, morgen Zwolle, donderdag thuis en vrijdag vrij + examen)

Leave a Reply

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

Deze website gebruikt Akismet om spam te verminderen. Bekijk hoe je reactie-gegevens worden verwerkt.