Lage iSCSI performace in VM

[Red-Front]

Vanmorgen waren onze servers erg traag.. bleek dat de backup van vannacht van de VM's nog liep. Backups stop gezet, maar het was daarna nog niet echt snel.

Setup is als volgt:
TrueNAS in HA
4 Hyper-V nodes
Ubiquiti ES-16-XG 10 Gbit switch op koper

Nu is mij opgevallen dat wanneer ik de firewall tijdelijk uit zet op de Hyper-V nodes, iops verdubbelen. Maar op zich is dat niet echt het probleem.

Tests zijn uitgevoerd met DiskSpd:
DiskSpd.exe -c15G -d120 -r -w40 -t8 -o32 -b8K -h -L C:\ClusterStorage\Volume1\ICT\Test\data.dat

Settings	Read iops	Write iops
Node fw aan	37.500	30.000
Node fw uit	87.500	62.500
Test vanuit vm iX systems	1.400	900
Test vanaf ander cluster netwerk (HP)
Node HP	56.000	37.300
Test vanuit vm HP netwerk	26.000	17.500

Wat opvalt is het dat het verschil tussen testen vanuit de hyper-v nodes zo'n verschil opleveren, terwijl het bij een ander netwerk dat ik beheer het verschil wel enigszins reëel is.

De iops op de vm bij ons zijn dus in verhouding dramatisch.

Edit: Sinds 12:00 krijg ik meldingen door dat alles weer snel werkt. Zojuist dezelfde test gedaan weer op de trage VM en de iops zijn (bijna) gelijk aan de resultaten van host -> iscsi target.

Het is net alsof er de hele ochtend naweeën zijn geweest, na het stoppen van de backups die vanmorgen nog draaiden. Alleen heeft vreemde blijft, waarom zijn de iops op de host richting de iSCSI target zoveel hoger dan vanaf een VM?

Edit2: Zojuist gebeld met producent en die geeft aan dat het de caching is die moet/moest opbouwen na een reboot van afgelopen nacht / weekend.. we houden het in de gaten..

[ Voor 17% gewijzigd door Red-Front op 14-05-2019 20:42 ]

[Dromer]

Ik merk het ook, wij gebruiken Altaro als backup, als deze loopt en gecanceld word hebben we daar ook idd zomaar een ochtend last van.
Kan het echt volledig reproduceren, en het verdwijnt ook altijd als vanzelf weer.

[MAX3400]

Wat gebeurt er op controller-niveau van de storagr? Of cache-niveau? Of block-niveau.

Oud voorbeeld: een snapshot van een snapshot van een LUN waar een VM op gerestored was laten de-dupen... Je kon wel een weekendje koffie gaan drinken, zeg maar.

[hans_lenze]

Zijn de naweeën niet gewoon het opruimen van de CSV snapshots?

[Red-Front]

Wat Dromer en hans_lenze aangaven was inderdaad de oorzaak.

Verder blijkt dat het aardig wat tijd in beslag neemt voordat de cache goed werkt bij TrueNAS, volgens de leverancier. Alles ging sneller werken naarmate de tijd vorderde.