VPLEX: Componentstoringen in de fabric- of arraycontroller leiden tot niet-beschikbaarheid van prestatiedata

Overzicht van
het probleemEindgebruikers kunnen ernstige gevolgen ondervinden op sommige of alle hosts die zijn verbonden met VPLEX door problemen zoals trage afvoeren, fouten in de arraydoelcontroller, CRC-fouten, switch-ASIC-fouten, opnieuw opstarten van switches, enz. De VPLEX-back-end maakt gebruik van een round robin-beleid dat ervoor kan zorgen dat problemen op de ene fabric van invloed zijn op alle hostpaden op die fabric (of ook op paden op de andere fabric).
  
Voor switch- en arrayteams   
Als een eindgebruiker een wijdverspreide impact meldt als gevolg van een storing van één component, langzaam afvoeren, enz., neem dan contact op met de eindgebruiker om te zien of VPLEX zich in de omgeving bevindt. Als VPLEX zich in de omgeving bevindt en de omvang van het probleem bekend is, vraagt u de eindgebruiker om de getroffen pad(en) op de switch te blokkeren. Als VPLEX zich in de omgeving bevindt en de getroffen paden niet bekend zijn, neemt u contact op met de klantenservice van Dell EMC, legt u het probleem uit en vermeldt u dit artikel.
 
Voor het VPLEX team
Als er een SR is waarbij de eindgebruiker een voortdurende impact meldt en het vermoeden bestaat dat de oorzaak te wijten is aan slecht presterende back-endpaden, identificeert u de slecht presterende paden en blokkeert u deze in VPLEX. Als de getroffen paden niet duidelijk zijn, schakel dan een coach in voor hulp. Switch- en array-samenwerkingen kunnen worden uitgevoerd zodra de impact is beëindigd.
 
Achtergrond
VPLEX naar Array I/O Flow
VPLEX werkt net als een geclusterde hostomgeving. Elke director, die I/O van de host ontvangt, is verantwoordelijk voor het voltooien van die I/O. Elke director heeft meerdere paden over beide fabrics naar elke LUN. Elke VPLEX-director is verantwoordelijk voor het verdelen van de I/O over alle beschikbare actieve paden.
 
VPLEX foutdetectie en -beperking
De primaire methode die VPLEX gebruikt voor het detecteren en beperken van padfouten is het bewaken van de verhouding van time-outs op elk pad. Als 90 procent van de I/O in twee opeenvolgende perioden van 15 seconden verloopt, verbant VPLEX het betreffende pad en gebruikt het niet meer. VPLEX zal vervolgens periodiek het verbannen pad testen en het verbannen ongedaan maken als I/O opnieuw wordt gezien op dit pad.
 
Hoe problemen kunnen ontstaan
Vanwege de hoge drempel voor het verbannen van paden, frequent sonderen en de lage drempel voor het opheffen van het pad, kunnen ongezonde paden nog steeds worden gebruikt door VPLEX. Het resultaat is dat VPLEX een aanzienlijke hoeveelheid I/O kan verzenden via slecht presterende paden of paden met zachte fouten. Er treedt een time-out op of deze I/O neemt te veel tijd in beslag. Het resultaat is aanzienlijk langere responstijden op alle hostpaden. Dit kan ertoe leiden dat prestatiedata niet beschikbaar zijn voor enige of alle hosts die zijn verbonden met de VPLEX.


Aanbeveling
Upgrade naar VPLEX GeoSynchrony-doelcode 6.2 P3 of hoger voor verbeterde ontlasting/afhandeling van de bovenstaande omstandigheden. Raadpleeg de releaseopmerkingen voor meer informatie over back-end padbeheerfunctionaliteit.