Dell EMC Unity: Sådan foregår LUN-indtrængen i Unity-systemet. (Kan rettes af brugeren)

LUN-overtrædelsesoperationen kan ske på grund af flere årsager, men fra Unity Side opstår der en LUN-overtrædelsesudløser på enten fejlhændelser for en af SP'erne eller en vært ved hjælp af dens ikke-optimerede designede sti. De ejede LUN'er overtrædes til den anden SP.

Faktisk udnytter Unity Asymmetric Logic Unit Access (ALUA) til værtsadgang. Dette gør det muligt for flere stier at være aktive for I/O, men nogle stier optimeres, mens andre ikke er optimeret. De stier, der er angivet som optimerede, er dem, der er forbundet til den SP, der ejer den pågældende ressource. Hvis I/O sendes ned ad den ikke-optimerede sti, udnytter peer-SP den interne CMI-bus (Common Messaging Interface) til at omdirigere I/O en til den SP, der ejer ressourcen. Denne handling er fuldstændig transparent for værten og fjerner behovet for at trænge ind på ressourcen for at fuldføre I/O'en. Alt dette forudsætter, at bedste praksis for tilslutning af en vært er blevet fulgt – to HBA er pr. vært, to switchede og to SP-porte pr. SP. Dette er konfigureret til fire stier - se andet billede nedenfor.
 
Eksempel: Her er forskellige scenarier for LUN'er, der overtrædes til den anden SP "oprindeligt ikke-ejet"
 
Scenarie1
: I nedenstående opsætning, hvis SPA er nede, overføres dens ejede LUN'er fra SPA til SPB, indtil SPA er UP, derefter omdirigeres ejerskabet af LUN'erne tilbage til den oprindelige ejer - Trængt tilbage til SPA  Scenarie2:
Hvis der modtages et stort antal I/O'er ned ad den ikke-optimerede sti, overgår Unity-systemet LUN'en til peer-SP for at optimere datastien.
Det senere nævnte scenarie vil ske, når værten ved en fejl sender sine data på en forkert sti, så derfor vil Unity automatisk overtræde LUN'erne for at optimere datastien. 
 
Så dette er bare en Unity-forsvarsmekanisme for at undgå høj udnyttelse af en SP, der ikke ejer en bestemt LUN.

Scenarie3:
I nedenstående opsætning, I tilfælde af SP-fejl, overgår LUN'en til den overlevende SP og fortsætter med at servicere I/O, da den er tilsluttet de samme switche. I tilfælde af switchfejl giver den resterende switch adgang til begge SP'er, hvilket eliminerer behovet for at bruge den ikke-optimerede sti. I tilfælde af værtsfejl starter klyngen en failover til den anden vært og bringer applikationen online. Enhver stifejl på grund af et dårligt kabel eller port forårsager ingen problemer, da den anden optimerede sti kan bruges.
 
Denne konfiguration kan også overleve flere fejl, så længe de ikke er inden for den samme komponent. For eksempel kan fejl i vært B, Switch A og SPA tolereres, da de tilbageværende komponenter kan bruges til at få adgang til LUN'en. I dette tilfælde kan vært A oprette forbindelse via Switch B og få adgang til den LUN, der er overtrådt SPB.