Storage en Netwerk uitdaging

Oke, eerst een korte introductie:

Bijna 1,5 jaar geleden ben ik begonnen met een groot laptop project bij een klant van mijn werkgever. De opdracht omvat het ontwerpen en bouwen van een volledige mobiele ICT werkplek voor een specifieke gebruikersgroep van 165 personen die geen echte affiniteit met computers hebben. De opstelling moest omvatten:

  • Een robuste laptop
  • Een GPRS / UMTS / HSDPA (afhankelijk van beschikbaarheid) verbinding
  • Een printer
  • Een dockingstation
  • GPS plaatsbepaling

De software die uiteindelijk op de laptop komt is niet heel erg belangrijk in dit verhaal, een aantal wel relevante kernpunten zijn:

  • Windows XP SP3
  • MsSQL 2000 SP4
  • RES PowerFuse
  • RES Wisdom
  • Data om mee te werken (3x XML Database van 3,x GB)
  • Text, JPG, PDF en TIFF bestanden met informatie (45 GB, 3.000.000 bestanden)

Het probleem / vraagstuk waar we nu mee bezig zijn ligt in het verlengde van een probleem dat we eerder tegen gekomen zijn en deels opgelost hebben. In het begin van het originele project hadden we de volgende opstelling om de laptops mee te installeren (inspoelen)

Hardware:

  • 2x HP DL360 G5 – 2 x 74GB in RAID1 als boot + 4 x 146 GB in RAID5  voor storage + 512 MB Cache op de (standaard) RAID controller
  • 1x 48 Poorts full Gigabit Cisco switch

dl360g5

Software:

  • Inspoelen basisimage + essentiele drivers: Microsoft BDD
  • Installeren software + overige drivers: RES Wisdom
  • Filetransfers: Robocopy

Client laptops die we gekozen hebben:

6930p

Het originele probleem:

Toen we op grotere schaal de laptops gingen installeren kwamen we er achter dat het in 1 Robocopy script kopieren van 45 GB aan data geen probleem was, tenzij het 3.000.000 kleine bestanden waren, op volstrekt willekeurige punten in de job kreeg de laptop een blue-screen, wat wel vast stond was dat geen enkele laptop de gehele installatie procedure goed doorliep. Als eerste hebben we uiteraard gecontroleerd of we de meest recente AHCI en Intel Matrix Storage drivers hadden, deze bleken beiden recent te zijn. Echter, ondanks de verschillende oplossingen die we bedachten vonden we niets dat werkte.

Echter, ergens ver weg gestopt in alle Google resultaten bleek dat met de combinatie Windows XP, ons type chipset en onze drivers problemen konden ontstaan die erg sterk op die van ons leken. Oudere driver versies waren geen optie in verband met problemen met BDD en AHCI. De oplossing kon gevonden worden in een specifiek KB artikel (linkje volgt nog) van Microsoft dat een custom versie van NTFS.sys aanbood als oplossing van ons probleem.

Dit in combinatie met het inpakken (zonder compressie ivm uitpak-tijd) van de files in 4 GB blokken zorgde er voor dat we voor toen snel genoeg (14-16 laptops gelijktijdig) laptops konden installeren.

Van:

dozen

Naar:

laptops

Tussendoor:

Ondertussen hebben we de laptops uitgeleverd, zijn er gezien het zeer complexe ontwerp wel nog redelijk wat problemen die we nu stuk voor stuk aan het oplossen zijn. Al met al worden de laptops met redelijke tevredenheid gebruikt. Gezien redelijke tevredenheid niet goed genoeg is zijn we er nog steeds druk mee bezig en voeren we regelmatig optimalisaties uit. Zeer binnenkort gaat er in 1 weekend overgestapt worden op een nieuwe SAP backend, waardoor ook alle clients opnieuw ingericht moeten worden (mijn laptops dan in ieder geval). De vorige keer hadden we 174 laptops en 3 weken de tijd.. Nu hebben we 225 laptops en 3 dagen voor het inrichten en 2 dagen voor het verpersoonlijken van de laptops

Uitdaging:

De uitdaging is duidelijk, 225 laptops installeren en voorzien van 60 GB aan data (de “probleem-data” en nog wat extra) in 72 uur.. Volgens mijn planning moet het lukken als we een beetje door kunnen werken en een nieuwe inspoel-omgeving bouwen. Dat deel is gebeurt.. en goed ook.. Dus die inspoelomgeving is niet zo zeer het probleem. De specs:

  • 1x HP DL360 G5 – 2 x 74GB in RAID1 als boot + 4 x 146 GB in RAID5  voor storage + 512 MB Cache op de (standaard) RAID controller (Voor het aanleveren van de BDD basisimage voor de laptops)
  • 4x HP DC7900 Desktop systemen met on-board INTEL 82567LM Gigabit netwerk chipset
  • 4x INTEL X25-m 160 GB SSD (voor in de bovengenoemde systemen als 2e / data disk)
  • 4x Windows 7 professional (Betere SSD ondersteuning)
  • 2x 48 poorts full gigabit Cisco switches in een stack

systemen

Even een korte uitleg over het bovenstaande, de keuze voor dit type HP client is gebasseerd op de aanwezige netwerkchip die er voor zorgt dat we geen zware CPU belasting krijgen door het netwerkverkeer. Gezien we ze alleen voor deze actie nodig hebben en ze alleen maar data aan hoeven te leveren zijn “echte” servers overbodig. De SSD’s hebben we gekozen voor de enorme hoeveelheid data die dit type schijf aan kan leveren. De INTEL X25-m die wij gebruiken doet ongeveer 240 MB per seconde tegenover +- 80-90 MB voor een “normale”  disk. We hebben voor Windows 7 gekozen vanwege de betere SSD ondersteuning dan in Windows XP en het feit dat het systeem moet werken zonder dat we daar teveel aan hoeven te tunen.

Met de bovengenoemde opstelling kunnen we zonder enig probleem een volle gigabit aan dataverkeer aanleveren (per “server”) en als het zou moeten denk ik dat we in totaal (de 4 systemen samen) 6-7 Gigabit kunnen halen met extra netwerkadapters (wat neer zou komen op 875 MB per seconde (meer dan 1 cd per seconde dus). Maar voor onze plannen is 500 Mb (4 Gigabit) voldoende.

De opstelling is bedoeld om 40 laptops gelijktijdig te kunnen installeren terwijl we de batch van daarvoor afconfigureren.. Dus, 80 laptops tegelijk aangesloten aan het netwerk, wat weer de nodige bekabeling met zich mee brengt die ik gister ter ontspanning tijdens het werk heb neergelegd..

Van:

kabels0

naar:

kabels1

naar:

kabels2

Het nieuwe “probleem”:

Oke, we hebben al het bovenstaande, alleen hebben we ook een “oud ” probleem terug… Eerder spoelden we al laptops in maar hadden we meer tijd, gezien de tijdsdruk de vorige keer niet al te groot was konden we er goed mee leven dat het binnenhalen van de 45 GB aan data 3 uur duurde.. Nu hebben we echter haast.. Wanneer we de data naar de laptop toe beginnen te sturen (in blokken van 4 GB, ingepakt, uncompressed) zien we dat de laptop begint met een kleine 250-300 Mbit (25 – 37,5 MB per seconde), wat een zeer acceptabele snelheid zou zijn. Echter, na een korte periode zakt de snelheid in naar +- 30 Mbit (3,75 MB per seconde) wat dus te langzaam is. Het zou aan de drivers of de custom ntfs.sys kunnen liggen, maar daar kunnen we helaas niets aan doen.

Wat we nu morgen gaan testen is het opbreken van de 4 GB bestanden in bestanden van 100 MB, en kijken wat hij dan doet. De “grote” achives komen dus op de 4 fileservers (iedere server heeft een eigen complete set en bedient 10 van de 40 clients). Andries en Steph merkten terrecht op dat het wel eens een beperking van NTFS zou kunnen zijn waardoor de transfer na x MB inzakt, dus daar had ik vanmiddag al het een en ander voor in gang gezet (het uitpakken en opnieuw inpakken van de bestanden duurt samen ongeveer 5 uur op een laptop).

Een ander alternatief waar Steph mee kwam is het gebruiken van een nieuwe versie van Robocopy die meerdere transfers gelijktijdig kan doen, maar dit wil ik als noodoplossing gebruiken omdat Robocopy voor veel dingen gebruikt worden die we dan ook weer individueel zullen moeten testen (waar we zo goed als geen tijd meer voor hebben om dat ook nog te doen).

Het uiteindelijke doel is dat iedere client 100 Mbit per seconde aan data aangeleverd krijgt.. Het uitpakken van de data gebeurt vervolgens geautomatiseerd (net als de rest van het installatie proces overigens) op de laptops zelf. Met 100 Mbit per client kan ik de 4 “file-servers” volledig belasten (qua netwerk) en zou ik dus dus de meest redelijkerwijs haalbare oplossing hebben bereikt..

Ik vind het in ieder geval erg leuk om hier mee te werken. het is geen fijn probleem, maar wel een leuk probleem om uit te zoeken en ik denk ook wel dat we uiteindelijk een goede oplossing gaan vinden, die ik hier dan ook zeker met jullie ga delen.

Uiteindelijk is dit een iets groter stuk geworden dan ik voorzien had, maar het geeft denk ik wel een klein beetje inzicht een een deel van de technische kant van mijn werkzaamheden..

5 comments

  1. Kijk eens aan, een zeer leuk project indeed! 😀

    Ik had hier en daar al ooit wat opgevangen inderdaad, maar nooit hoe het nu helemaal gelopen was.

    Wat ik in mijn twitter bedoelde was iets anders dan je begreep zo te zien. Eventjes wat uitleg wat ik in mijn werk met backup pakketen veel tegenkom.

    Storage en Windows

    Single Stream Some Large Files = Storage Speed limitation
    Single Stream Lots of Small Files = NTFS limitation

    Althans, het zit wat complexer dan dat, maar je zou het zo kunnen zien:

    Als het een storage limitation is moet je NIET met meerdere streams gaan werken omdat je mechanische harddisk dit niet kan. HDD’s zijn gemaakt om 1 ding te doen, sequentieel. Ga je meerdere dingen tegelijk van ze vragen, dan word het onherroepelijk trager. Raid array, cache, etc. boeit allemaal niets. (Word sowieso in de praktijk overschat). Maar dat is een heel ander verhaal.

    Ik moet je credits geven voor je oplossing aan de server kant. De perfecte en enige kosten effectieve oplossing die er maar is. Mechanische disken kunnen niet meerdere dingen tegelijk. Aangezien je meerdere clients probeert “dezelfde” data stroom te leveren kun je dat deels met caching opvangen, maar dat is een valkuil als ze teveel uit elkaar gaan lopen. Wil jij 10 reads van een raid array met 10 disken erin, zal elke disk uiteindelijk 10 reads moeten uitvoeren. RAID is namelijk in veel gevallen makkelijk, maar niet per definitie sneller. Met 10 disken die elk 100MB/sec kunnen (moderne 1TB+ disk kan dat gemakkelijk) in een RAID0 = 1000MB/sec. Maar, als elke disk 10 simultane reads moet doen, moeten ze heel veel seeken en stort je read performance in elkaar. Had je 10×1 losse disk gehad met dezelfde data erop, had je altijd 10x100MB/sec gehaald, zo lang het maar een single stream per disk is. Hetzelfde geld voor writes. Geen controller, cache of wat dan ook dat dit gaat veranderen. Maar dat eventjes ter zijde.

    Je oplossing hiervoor in een SSD. Perfect, die heeft hier namelijk een stuk minder last van! Deze moet ook de seeks verwerken, maar aangezien ze hierbij ongeveer 0.01MS duren in plaats van gemiddeld 10MS bij een moderne SATA disk of 4MS bij de snelste SAS 15K disk, heb je daarbij een enorme winst! In die zin is voor seeks de SSD velen malen (tientallen malen) sneller dan een disk array, met veel HDD’s en controllers bij elkaar. chapeau! Niet veel mensen die dit al goed doorhebben is mijn ervaring! 😀

    Maar eventjes terug naar je problematiek.

    Oh nee, eventjes dit tussendoor: http://forums.laptopvideo2go.com/topic/21147-intel-chipset-drivers-whql/

    Website forum waar altijd de nieuwste intel chipset links te vinden zijn, terwijl ze een stuk moeilijker bij intel zelf te vinden zijn. Nieuwere versies hebben ook effect op oudere chipsets en ik raad aan te installeren via “setup -OVERALL” zodat alles geforceerd vervangen word. Je draait nu wel op AHCI neem ik aan? Dat is over het algemeen efficiënter dan IDE.

    Windows 7 prima keuze, maar geen windows 2008 SP2 R2. Caching is wat beperkter aangezien het geen server versie is van het OS. Wellicht dat het zetten bij advanced system settings -> system options -> advanced -> performance -> background services er nog net wat extra performance uit kan persen!

    Anyway.

    Zoals ik lees gaat je transfer eerst snel en daarna langzamer. Mijn verwachting is dat het knippen van de 4GB stukken naar bijvoorbeeld 100MB stukken tijdens de file copy helemaal *niets* gaat veranderen. Mocht dat wel zo zijn zou ik blij verrast zijn. Sterker nog, ik verwacht dat het trager is.

    Persoonlijk dacht ik uit je twitter stuk te begrijpen dat juist het uitpakken van de data het grootste probleem was. Mijn oplossing daarvoor was geweest (en uitgangs punt van deze reply) dat je niet de files kopieert naar de laptop, maar een share mapped over het netwerk. Hier zet je meerdere archives neer (grootte boeit niet). Je maakt een script welke eerst een archive uitpakt met daarin grote/lompe bestanden. En als dat klaar is welke begint met de kleinere bestanden. Aangezien de grote bestanden gelimitereerd zullen zijn door de storage op je laptop hoef je daar niets aan te doen. De kleine bestanden daar in tegen zullen hangen op liminitaties binnen NTFS met single stream file read/writes. Als je die in parallel zou uitvoeren kun je daar een aardige winst boeken in de praktijk. Ook heb je zo niet het probleem dat de disk in de laptop eigenlijk tegelijk reads en writes moet uitvoeren, welke deze niet kan. Ik verwacht dat je dan in het totaal een stuk hogere doorvoer snelheid hebt voor de hele handeling op de laptop, niet zozeer de kopieer actie zelf.

    Ik snap dat dat wat lastiger te bouwen is waarschijnlijk en dat je helemaal geen tijd (of zelfs zin hebt) om dat om te gaan bouwen. Dus eens zien wat we aan je huidige probleem kunnen doen!

    Je probleem zit puur in de snelheid van het kopiëren van de files van de server naar de laptops.

    Enkele vragen :

    Fact – In het begin is het snel maar daarna word het langzamer en langzamer
    Question- Lopen de laptops exact gelijk met kopiëren of variëren ze in snelheid?
    Question- Verschilt het als je 1 laptop tegelijk doet of 10 per server?
    Question- Heb je op de disken in de server gekeken wat de Read queue van de disk is?

    Wat ik zelf wel eens gezien heb in de praktijk bij dit soort zaken is dat de eene laptop toch net wat eerder start of sneller loopt dan de andere. Als dit teveel uiteen gaat lopen kan de caching van windows/raid controller dit gaat niet meer opvangen en moet effectief op de disk gaan seeken. Als dat gebeurt gaan er meer out of sync lopen en uiteindelijk word het trager en trager totdat ze allemaal out of sync zijn en je disk zich achterlijk zoekt! Dit zou je in de praktijk moeten kunnen meten via performance monitor naar de physicaldisk en dan avg. read queue te kijken. In principe is het zo dat als deze boven 2 komt dat windows moet wachten op zijn storage subsystem en daardoor vertraging ondervind. Als dit aan de hand is, zul je dat gestaag zien oplopen.

    Wat kan daarin helpen? Je partite alignen (zorgt voor betere reads) kan helpen. Verder je cluster size op je disk als 64KB formateren inplaats van 4KB. Met grote transfers is dat altijd een voordeel. Enhanced disk caching aanzetten op je disk in windows (kan niet bij raid controller met cache) hierdoor zal windows meer geheugen alloceren voor caching. Dat kan in performance monitor. Als je de intel drivers gebruikt kan dat niet en zal dat in de matrix storage manager moeten.

    Naar mijn mening kan een moderne 5400 RPM sata disk in een laptop zo’n 35MB/sec tot 45-50MB/sec sequentieel aan. Daar moet dus het probleem niet kunnen liggen. Met 10MB/sec kun je in 1 uur ongeveer 40GB overhalen. Dat moet *makkelijker* haalbaar zijn, 3MB/sec voor grote files, dan is er serieus iets mis!

    Fact – In het begin is het snel maar daarna word het langzamer en langzamer
    Question- Ook hier de avg. disk queue monitoren (niet read queue uiteraard), kijken of dit oploopt
    Question- Neemt toevallig system heel veel cpu in? Helaas heeft windows XP nog geen resource monitor dus het is lastig te zien waarin de vertraging zou zitten.
    Question- Word de laptop traag en schokkerig? Of blijft dat gewoon doorlopen?
    Question- Beschikken de laptops over Turbo Memory? Dit kan invloed hebben je disk performance van de NV cache feature ervan

    Je zou op de laptops kunnen testen met attobench. Dat is een tool waarmee je bijvoorbeeld 2GB files kunt testen met verschillende blok groote. Beter nog HPreaddata en HPwritedata. Dan zou je een file kunnen genereren van 20GB platte data en zien hoe lang de disk daarover doet. Ook met iperf testen hoe de netwerk snelheid bijvoorbeeld zich een uur lang gedraagt, etc. Maar dat zijn allemaal testen die tijd kosten, welke je eigenlijk niet hebt. 🙁

    Verder is het lastig zo een diagnose te stellen. Je methodiek is solid. Ik ben wel bang voor het out of sync lopen van de clients tijdens het kopieren. Maar als het met 1 client ook gebeurt zit het probleem dieper. Windows, de hardware en de disken zouden dit makkelijk moeten kunnen met 65MB/sec (realistische CIFS grens van Windows XP), daargelaten dat de disk van de laptop dat misschien niet vol kan houden.

    Anyway, ik help je graag mee om te onderzoeken hoe dit op te lossen. Zoals jullie wel weten is dit 1 van de dingen die ik het leukste vind, denk aan mijn servers op lanparties, etc. 😀

  2. Leuk, uitgebreide reactie 🙂

    Je vragen:

    == Question- Lopen de laptops exact gelijk met kopiëren of variëren ze in snelheid?
    Nee, de laptops lopen sowieso altijd iets uit de pas, hier ontkomen we ook even niet aan zonder ons veel extra werk op de hals te halen helaas.

    == Question- Verschilt het als je 1 laptop tegelijk doet of 10 per server?
    Wanneer we 1 van de servers belasten door dezelfe taak die de clients normaal uit laten voeren door 3 servers laten draaien zien we dat de lijn 100% belast is (1 Gbit). Wanneer ik dan 1 laptop aan de server hang begint deze snel en zakt hij in naar een belasting van 3%, als ik dan nog een laptop daar bij hang stijgt de belasting naar 6% (na het snelle deel) enzovoorts, hierbij maakt het niet uit of ik ze gelijk of out of sync start.

    == Question- Heb je op de disken in de server gekeken wat de Read queue van de disk is?==
    Nee, maar wel een goede tip inderdaad, ik zal hier morgen even tijd in steken.

    == Question- Ook hier de avg. disk queue monitoren (niet read queue uiteraard), kijken of dit oploopt
    zelfde als hierboven

    == Question- Neemt toevallig system heel veel cpu in? Helaas heeft windows XP nog geen resource monitor dus het is lastig te zien waarin de vertraging zou zitten.
    Dit was mijn eerste gedachte, alleen dat bleek ook niet het geval te zijn, de belasting komt maar op een % of 3-4 te staan, dus dat is niet noemenswaardig

    == Question- Word de laptop traag en schokkerig? Of blijft dat gewoon doorlopen?
    De laptop is wel duidelijk ergens mee bezig maar niet schokkend druk, wat inderdaad wel weer de noodzaak aangeeft om eens naar de queue te kijken..

    == Question- Beschikken de laptops over Turbo Memory? Dit kan invloed hebben je disk performance van de NV cache feature ervan
    Nope, en als het er in zou zitten zouden we het uit gezet hebben.

    Zoals we net op MSN ook al bespraken zal ik morgen eens die 2 tools eens draaien (HPcreatedata HPreaddata). Ik begin eerst eens met precies hetzelfde dat ik tot heden al gedaan heb maar dan met de 100 Mb files.. Als ik dit zo lees ligt het inderdaad wel in de lijn der verwachting dat dit een minimaal verschil op gaat leveren.

    Ik zal in ieder geval de vorderingen hier posten.. Bedankt voor de hulp in ieder geval alvast 🙂

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.