PowerScale: Isilon: Análise em cluster do Isilon: Pools de rede — suporte a upgrade paralelo

Network Pools - Parallel Upgrade Support          FAIL

CRITICAL: A parallel upgrade runs the risk of making one or more external networks temporarily unavailable. Affected pools: groupnet0.subnet0.pool1, groupnet0.subnet1.pool1, groupnet0.subnet1.pool2

• Isso ocorre por padrão, pois o cluster tem redes externas separadas, onde há um possível risco de que todos os nós dos pools de rede afetados reinicializem simultaneamente.
• Nesse caso, os clients não podem acessar o cluster por meio do nome da zona do SmartConnect (SCZN) associado a esse pool de redes. 

Definições importantes:
 

• Pool de discos:  Conjunto de discos distribuídos entre um subconjunto de nós do cluster. 
• Níveis/políticas de proteção: Todos os arquivos no file system /ifs recebem um nível de proteção. O OneFS fraciona ou espelha o conteúdo dos arquivos em nós e unidades de um só pool de discos. Um arquivo com um nível de proteção de 2d+1n garante que o arquivo ainda estará disponível se quaisquer duas unidades ou um nó no pool de discos de compartimento ficar inativo.
• Bairros:  Conjuntos de nós que contêm totalmente um ou mais pools de discos. Um subconjunto de nós atribuído a um pool de discos pode se sobrepor a um subconjunto de nós atribuídos a outra vizinhança. Não há sobreposição de pools de discos entre vizinhanças. 
• API DB do pool de discos e reservas A API de banco de dados do pool de discos tem um recurso de reserva que permite que um aplicativo client, como o Upgrade Framework, remova um conjunto de nós (ou seja, reinicializar) ou unidades do cluster sem violar a proteção em nenhum pool de discos.
• Redes externas desagregadas: Um cluster terá redes externas desagregadas se houver um conjunto de nós com interfaces externas que não se sobreponham em todos os pools de discos

• Um upgrade paralelo instala o novo sistema operacional em todos os nós e, em seguida, reinicializa um subconjunto de nós simultaneamente, até um nó em cada pool de discos.
• Cada nó tenta fazer uma reserva para sua vez de reinicializar até que todos os nós tenham recebido upgrade.  Os subconjuntos e as reservas de nós são baseados no pool de discos e na disponibilidade do nó.
• Durante um upgrade paralelo, os subconjuntos de nós que não estão sendo reinicializados permanecem on-line e podem continuar atendendo aos clients.

• O cluster tem redes externas separadas (exemplo KB : groupnet0.subnet0.pool1, groupnet0.subnet1.pool1, groupnet0.subnet1.pool2)
• Durante o upgrade paralelo, há um possível risco de DU nesses pools de rede, pois todos os nós nos pools de rede afetados podem reinicializar ao mesmo tempo (ou seja, todos eles podem fazer uma reserva de pools de discos para reinicializar simultaneamente). 
• Se isso ocorrer, o acesso ao SCZN do pool de rede afetado não será possível. 

• Como cada cluster tem uma configuração de rede diferente, a solução não é a mesma para todos os clusters.
• Para evitar uma possível DU no pool de rede desagregado durante o upgrade paralelo, será necessária uma alteração de configuração de rede no cluster e no ambiente externo, o que geralmente requer várias aprovações por parte do cliente.
• Este artigo da KB não incluirá uma resolução direta para a falha de verificação de IOCA devido aos pontos acima.
• No entanto, a diretriz geral é que existam pelo menos duas interfaces de membro externo dos nós nos pools de rede afetados no mesmo domínio/vizinhança para evitar um risco de rede/DU separado para esse pool de rede SmartConnect (ou seja, adicionar nós do mesmo domínio de vizinhança/falha ao pool de rede afetado). 
• O artigo da base de conhecimento fornece comandos sobre como determinar os domínios de vizinhança/falha do cluster e os nós membros nos pools de rede afetados.

• Use o comando abaixo para determinar os nós membros nos pools de rede afetados (Nota: Substitua o "<network-pool 1 ID> | <ID> do pool de rede 2 | <network-pool 3 ID>" com os IDs do pool de rede afetado dos detalhes de verificação do IOCA e separados entre eles usando o caractere '|'). 

# isi network pools list -v | egrep -i 'ID: |ifaces' | egrep -A1 '<network-pool 1 ID> | <network-pool 2 ID> | <network-pool 3 ID>'

• Execute o comando abaixo para determinar as vizinhanças do cluster (Nota: Substitua o <Localização> do script do IOCA e <Nova versão> do OneFS com seus valores corretos) 

# perl <IOCA script location> -o <New OneFS version>,parallel  -e -r "checkNetworkParallelUpgrade"  

• Faça referência cruzada aos resultados dos comandos acima para determinar quais alterações precisam ser feitas nos pools de rede do cluster.
• Uma correção rápida seria adicionar todos os nós do cluster aos pools de rede afetados, mas, novamente, isso geralmente não é fácil, pois o ambiente de rede externa pode não permitir essa alteração.
• Depois que as alterações necessárias forem aplicadas, execute novamente a verificação IOCA.
• Se não for possível determinar as alterações necessárias, abra um caso com o Suporte para obter assistência adicional.
• Exemplo abaixo para determinar as alterações necessárias em um cenário de teste:

1) Determine member nodes in affected network pools:
# isi network pools list -v | grep -i 'ID: |ifaces' | egrep -A1 'groupnet0.subnet0.pool1| groupnet0.subnet1.pool1| groupnet0.subnet1.pool2'
                     ID: groupnet0.subnet0.pool1
                 Ifaces: 1:10gige-agg-1, 2:10gige-agg-1, 4:10gige-agg-1, 3:10gige-agg-1
                     ID: groupnet0.subnet1.pool1
                 Ifaces: 37:10gige-agg-1, 38:10gige-agg-1, 39:10gige-agg-1, 40:10gige-agg-1
                     ID: groupnet0.subnet1.pool2
                 Ifaces: 37:10gige-agg-1, 38:10gige-agg-1, 39:10gige-agg-1, 40:10gige-agg-1

2) Run the IOCA check to determine cluster neighborhoods:
# perl IOCA -o 9.2.1.5,parallel -e -r "checkNetworkParallelUpgrade"
Isilon On-Cluster Analysis                        0.1395
Cluster Name                                      TestCluster
Cluster GUID                                      0050569b6db2ad086861001a2f1dd1d02473
Node Count                                        52
Current OneFS Version                             8.2.2.0
Destination OneFS Version                         9.2.1.5
Destination OneFS Version                         WARN
  WARN: There is a newer patch release available for OneFS 9.2.1: 9.2.1.9
Network Pools - Parallel Upgrade Support          FAIL
  CRITICAL: A parallel upgrade runs the risk of making one or more external networks temporarily unavailable. Affected pools: groupnet0.subnet0.pool1, groupnet0.subnet1.pool1, groupnet0.subnet1.pool2
  
  ==============================
  Node Neighborhoods
  ==============================
  1: [ 1, 7, 10, 16, 19, 24, 27, 31, 35, 40, 43, 45, 47 ]
  2: [ 2, 6, 9, 15, 18, 23, 26, 29, 33, 38, 41, 46, 48 ]
  3: [ 3, 5, 12, 14, 17, 22, 25, 30, 34, 37, 42, 50, 51 ]
  4: [ 4, 8, 11, 13, 20, 21, 28, 32, 36, 39, 44, 49, 52 ]

3) The possible resolution in this case would be to :

a) A quick fix would be to add all clusters nodes to the impacted network pools groupnet0.subnet0.pool1 & groupnet0.subnet1.pool1, groupnet0.subnet1.pool2
b) Add more nodes to affected network pools ( suggested nodes are based on neighborhood command output ) :

- Possible resolution to groupnet0.subnet0.pool1 : at least add node 7  to the network pool as node 7 exists in the same neighborhood as nodes 1
- Possible resolution to groupnet0.subnet1.pool1 : at least add node 34 to the network pool as node 34 exists in the same neighborhood as nodes 37
- Possible resolution to groupnet0.subnet1.pool2 : at least add node 33 to the network pool as node 33 exists in the same neighborhood as nodes 38

4) After applying the network changes, re-run the IOCA check to confirm that there are no issues:
# perl IOCA -o 9.2.1.5,parallel -e -r "checkNetworkParallelUpgrade"