Dell Unity: Como ocorre a invasão de LUN no array do Unity.

A operação de troca de LUN ocorre por vários motivos. No lado do Unity, ocorre uma troca de LUN em um evento de falha do processador de serviço (SP) para uma das SPs ou um host usando seu caminho projetado não otimizado. Quando isso ocorre, as LUNs de propriedade são trocadas para a outra SP.

O Unity aproveita o Asymmetric Logic Unit Access (ALUA) para acesso ao host. Isso permite que vários caminhos estejam ativos para E/S, mas alguns caminhos são otimizados, enquanto outros não são otimizados. Os caminhos designados como otimizados são conectados à SP proprietária desse recurso específico. Se a E/S for enviada pelo caminho não otimizado, o par da controladora aproveita o barramento CMI (Common Messaging Interface) interno para redirecionar a E/S para a controladora proprietária do recurso. Essa operação é transparente para o host e elimina a necessidade de troca do recurso para concluir a E/S. Isso pressupõe que as práticas recomendadas para conectar um host tenham sido seguidas: dois HBAs por host, duas portas comutadas e duas portas SP por SP. Isso é configurado para quatro caminhos - veja a segunda imagem abaixo.
 
Exemplo: Aqui estão diferentes cenários para LUNs sendo trocadas para a outra SP "inicialmente sem proprietário"
 
Cenário 1:
Na imagem abaixo, se a SPA ficar inativa, as LUNs de propriedade dela serão trocadas da SPA para a SPB. Quando a SPA retorna ao serviço, a propriedade das LUNs é redirecionada de volta para o proprietário inicial - trocada de volta para a SPA. 

  

Cenário 2:
se muitas E/Ss forem recebidas no caminho não otimizado, o Unity trocará a LUN pelo par da controladora de armazenamento para otimizar o caminho de dados.
O cenário mencionado posteriormente acontece quando, por engano, o host envia seus dados para um caminho errado, portanto, consequentemente, o Unity invadirá automaticamente as LUNs para otimizar o caminho de dados. 
 
É assim que o Unity evita a alta utilização de uma SP que não possui uma determinada LUN.

Cenário 3:
na imagem abaixo, se uma SP falhar, a LUN sofrerá failover para a SP sobrevivente e continuará atendendo à E/S, já que está conectada aos mesmos switches. Se houver falha no switch, o switch restante fornecerá acesso a ambas as controladoras, eliminando a necessidade de usar o caminho não otimizado. Se houver uma falha no host, o cluster iniciará um failover para o outro host e colocará o aplicativo on-line. Qualquer falha de caminho devido a um cabo ou porta defeituoso não causa problemas, pois o segundo caminho otimizado pode ser usado.
 
Essa configuração também pode sobreviver a várias falhas, desde que elas não estejam dentro do mesmo componente. Por exemplo, a falha do Host B, do Switch A e da SPA pode ser tolerada, uma vez que os componentes sobreviventes podem ser usados para acessar a LUN. Nesse caso, o Host A pode se conectar por meio do Switch B e acessar a LUN que foi trocada para a SPB.