Opslagconsultant Van Kester blijft na het lezen van de test met Linux op een mainframe met een aantal vragen zitten (Pinguïn is haantje de voorste, Computable 7 februari). Wat hem vooral opvalt is dat zelfs subtiele veranderingen in de configuratie tot zulke ingrijpende veranderingen in de doorvoersnelheid (throughput) leiden. Vincent Re, de auteur van het onderzoek en werkzaam als divisional VP mainframe common services bij Computer Associates in de VS tracht in een reactie die vragen te beantwoorden. Uit zijn woorden valt op te maken dat het zeker niet bij dit ene vergelijkend warenonderzoek zal blijven.
| Linux op mainframe: interessant, maar verklaar u nader De vergelijking van Linux-op-mainframe met Linux op Sun en Intel levert een interessant stuk op. Maar een aantal zaken zijn me toch niet duidelijk. Wat me vooral opviel waren de verschillen die optreden wanneer Escon wordt toegepast vergeleken met het aanwenden van Ficon. Nogal tegen de verwachting in blijkt gedurende de tests dat zelfs subtiele veranderingen in de configuratie tot ingrijpende wijzigingen van de doorvoersnelheid (throughput) kunnen leiden. Het lijkt me nogal duidelijk dat Escon vergeleken met Ficon een grote impact heeft op het performanceniveau. Ficon biedt een bandbreedte van 100 Mb/s (effectief ca. 80 Mb/s), terwijl Escon het moet doen met slechts 17 Mb/s (effectief ca 13 Mb/s). Dus als ik dan lees dat de doorvoersnelheid zich juist in dit gebied afspeelt dan zal het gebruik van Ficon deze bottleneck wegnemen. Neem als voorbeeld de Logical Volume Manager (lvm). Hoewel het gebruik hiervan slechts een geringe invloed op het prestatieniveau heeft, veroorzaakt het al of niet toepassen van 'sofware striping' belangrijke verschillen. Met striping neemt de doorvoersnelheid met meer dan 80 procent af van 18 Mbps naar 3,5 Mbps. Ik weet niet of Freud meeschrijft, maar met een sofware striping kan natuurlijk nooit wat worden . . . Zeker als blijkt dat dit een dergelijke vermindering van de doorvoersnelheid oplevert. Ik pas zelf striping toe om een verbetering te bereiken, niet om het geheel te zien verslechteren. Ik ben benieuwd hoe de opzet van deze stripeset is. Het Dell systeem presteert niet slecht, maar interessant zou zijn geweest om een Intelsysteem met scsi-schijven te testen met striping om te zien of dit een bottleneck zou zijn. Ik denk dat vooral de processen block-in en -out met hun grote datablokken hiervan sterk hadden kunnen profiteren. De rode lijn van de totale eigendomskosten (want daar gaat het verhaal over) is zeker zo interessant. Ik denk dat de conclusie terecht is dat het Intel-systeem bij een vergroting van de schaal zich niet lineair gedraagt, maar exponentieel. Jos van Kester consultant opslagsystemen |
Ik wil graag op de opmerkingen van Jos van Kester reageren. Ik had er geen flauw idee van dat het onderzoek ergens buiten CA zou worden gepubliceerd, maar ik ben erg blij met dat goede nieuws!
Van Kester stelt allereerst de ingrijpende wijzigingen aan de orde in de doorvoersnelheid die het gevolg zijn van subtiele veranderingen in de configuratie. Wij geloven dat het effect dat hij terecht signaleert een resultante is van de betrekkelijke onvolwassenheid van het platform en van dingen als de device drivers die in gebruik zijn. Zelfs subtiele korte weggetjes in het ontwerp van dit soort kritische componenten kunnen een belangrijke uitwerking hebben op de performantie en uiteindelijk op de kosten.
Daarom ook denken we niet dat ons onderzoek het definitieve 'Laatste Woord' zal zijn. We verwachten daarentegen voortdurende veranderingen (hopelijk zelfs verbeteringen) nu Computer Associates, IBM en anderen leren hoe Linux aan te passen aan de de hardware-architectuur van het mainframe. Bemoedigend is het daarbij dat de trend wijst op voortdurende verbeteringen, omdat Linux meer en meer van de mogelijkheden van het mainframe begint te benutten. In de loop der tijd verwachten we dat de totale eigendomskosten (total cost of ownership) voor een mainframe-oplossing substantieel omlaag kunnen.
Zwakte van Escom
De vergelijking die Van Kester trekt tussen (de bandbreedte van) Ficon en Escon brengt een interessant punt naar voren. Ik denk dat als er een grote werkbelasting is richting I/O die je op Linux wilt consolideren, dat je dan geen Escon schijven zou moeten gebruiken. Mainframe gebruikers die z/OS draaien hebben soms geen weet van dit soort zaken omdat z/OS schijftechnologie gebruikt (PAV bijvoorbeeld: parallel access volumes) die de zwakte van Escom verbergen.
Van Kesters opmerkingen over de logical volume manager (Lvm) en striping zijn wederom een indicatie voor de onvolwassenheid van de software. Volumebeheer op andere platforms handelen striping af zonder enig verlies aan prestatie, sterker nog: in de meeste gevallen levert striping een netto prestatiewinst op. Het voornaamste dat we wilden aantonen is dat kleine dingen van invloed zijn op prestaties op een manier die tegen ons intuïtieve gevoel ingaat. We verwachtten dat striping de parallelle verwerking en efficiency zou verbeteren, maar het omgekeerde bleek waar. Gelukkig voor ons zijn deze effecten op een mainframe dat z/VM draait betrekkelijk eenvoudig te meten en hopelijk op te lossen.
Striping
Hoe de striping-test was opgezet? We hebben software striping eenvoudig toegestaan middels de Lvm die meegeleverd wordt met SuSE's Sles 7 voor de zSeries. We hebben verschillende configuraties van Lvm-opties uitgeprobeerd, net als verschillende aantallen fysieke schijven en dergelijke, met in zijn algemeenheid overeenkomstige uitkomsten. Het probleem schuilt kennelijk in het feit dat in veel gevallen de Lvm-laag ervoor zorgt dat de disk driver een veelvoud van I/O verzoeken per call uitvoert, en dat dit substantiële doorvoerproblemen bij schijftoegang veroorzaakt.
Wat additionele tests met Intel en Scsi-schijven betreft: het zou zeker mooi zijn geweest wat meer I/O configuraties te testen, en ook wat san- en nas-configuraties. Dat geldt ook voor databanken van verschillende grootte, variërend van een paar gigabyte tot tientallen terabyte. Ik vermoed dat als we totale eigendomskosten (tco) van al deze verschillende configuraties plotten in een kromme, we een verschillende kromme zullen vinden voor elk van de I/O-subsystemen afzonderlijk. Afhankelijk van de omvang van een database en prestatievereisten zouden dan precies afgebakende pieken in de tco-kromme verschijnen, die zouden wijzen in de richting een bepaalde combinatie van platform en I/O-mogelijkheid. Blijf luisteren, want dat is iets dat we in een toekomstig white paper willen uitspitten.
Schaalverandering
Volgend punt dat Van Kester aanvoert betreft de schaalbaarheid van op Intel gebaseerde configuraties. Hij heeft gelijk: schaalbaarheid is een belangrijk aspect van de totale eigendomskosten. Om een voorbeeld te geven: toen we onze benchmark-applicatie op zSeries loslieten konden we binnen één enkele zSeries z900 bij benadering een schaalverandering aanbrengen tot de orde van grootte van 100:1. Daarbij bleven de totale eigendomskosten relatief statisch. In feite zou het een zaagtand-achtige curve worden, die een weerspiegeling zou zijn van de korreligheid van een opwaardering van zSeries: in de groei zijn er tijdsperioden waarin er meer capaciteit beschikbaar is – en kosten – dan absoluut noodzakelijk en de totale eigendomskosten zouden afnemen. Verder 'schalen' dan deze 100:1 limiet zou additionele computers vereisen, en dan zou de complexiteit en dientengevolge de kosten oplopen. Dus wat we voor het mainframe krijgen is een step function waarbij de totale eigendomskosten beginnen te stijgen vanaf het 100:1 niveau. De oplossingen van Sun en Intel zullen waarschijnlijk een andere tco-curve hebben, die op een lager niveau begint (een heel kleine Sun of een Intel systeem is in totaal een stuk minder duur dan een klein mainframe) en voortdurtend doorstijgt naarmate de vereisten in aantal toenemen. Weten waar je je op die curve bevindt, en waar je naar toe beweegt is een belangrijk onderdeel van een analyse van totale eigendomskosten.
Sprekend over schaalbaarheids vraagstukken wordt het belangrijker sommige van de variabele kosten mee te nemen die we nu buiten beschouwing hebben gelaten. Stroom, vloeroppervlak, backup om na een ramp door te kunnen draaien en dergelijke zijn dramatisch anders al naar gelang het platform en de schaal. De mainframe-oplossing bijvoorbeeld is betrekkelijk constant in termen van stroomvoorziening en vereisten van airconditioning, althans tot het 100x niveau bereikt wordt en een tweede processor nodig is. In tegenstelling daarmee nemen de vereisten op dit gebied van de Sun- en Intel-oplossingen lineair toe. Voor een werkbelasting die genoeg heeft aan een klein aantal servers is dat waarschijnlijk niet zo'n probleem. Maar als het om tientallen of zelfs honderden servers gaat, wordt het bijzonder belangrijk.
Met dank aan Marcel den Hartog,
CA Nederland
Vertaling: René Rippen
Vincent Re, divisional VP Mainframe common services Computer Associates Inc.
