Dell Unity: As SPs podem entrar no modo de serviço devido ao inchaço de logs (a partição /nbsnas fica 100% cheia)
Summary: Um array pode entrar no modo de serviço (dados indisponíveis) devido ao inchaço de registros (corrigível pela Dell)
Symptoms
Para arrays de controladora dupla, uma SP do sistema de armazenamento entra em modo de serviço e o sistema inteiro não pode ser operado por meio de interfaces de gerenciamento, inclusive CLI, UI, API REST e SMI-S. Isso também pode se manifestar quando as controladoras são reinicializadas alternadamente até que ambas as controladoras acabem no modo de serviço.
Um array do Unity com ambas as SPs no modo de serviço não atenderá à E/S, portanto, essa seria uma situação de dados indisponíveis (DU).
Para VSA, a controladora única pode reinicializar no modo de serviço ou simplesmente permanecer no modo normal, perdendo o gerenciamento em ambos os casos.
Não é possível operar todo o sistema por meio de interfaces de gerenciamento, inclusive CLI, UI, API REST e SMI-S.
SSH ou IPMI devem funcionar. O IPMI funciona sempre, o SSH pode funcionar somente depois que o array for estabilizado.
Esse problema é encontrado no OE versão 4.0.0.x e corrigido no OE versão 4.0.1.x.
Cause
O arquivo de log /nbsnas/http/logs/mod_jk.log, que registra todas as solicitações da interface do usuário e do REST, reside em um file system montado em /nbsnas da controladora primária. Sem um mecanismo de rodízio de logs, o inchaço desse arquivo continua a consumir o espaço disponível do file system. Outros consumidores internos começam a falhar depois que não há espaço no sistema de arquivos. Uma das controladoras entra no modo de serviço quando detecta falhas repetidas desses componentes.
Foi observado no laboratório que, quando isso acontece e os serviços tentam fazer failover para a controladora secundária, ela também apresenta os mesmos sintomas. As SPs são reinicializadas algumas vezes alternadamente e, por fim, ambas entram no modo de serviço.
Os clientes verão esse problema se: sempre usar a interface do usuário ou a API REST para configurar o sistema de armazenamento ou abrir a interface do usuário no navegador e deixá-la lá sem fechar. Com apenas acesso à interface do usuário, normalmente os clientes levam alguns meses para ver esse problema. Se os clientes usam a API REST para consultar dados do sistema de armazenamento com frequência, esse problema ocorre mais rapidamente.
Foi encontrado um segundo problema, no qual o upgrade para o Unity OE 4.0.1.8320161 pode exacerbar o problema, pois pode duplicar o arquivo de log em questão durante o NDU, acelerando o processo.
Você pode confirmar isso verificando o consumo de espaço em /nbsbas. Se o consumo de espaço for mínimo ou baixo, você NÃO enfrentou esse problema durante o NDU e, portanto, nada mais será necessário.
Os códigos 4.0.1.x já contêm a correção do problema principal, portanto, o rodízio de logs em si está funcionando corretamente.
Se a partição estiver mostrando uma porcentagem usada muito alta, os arquivos de registros responsáveis podem ter que ser excluídos (requer suporte da Dell).
Um exemplo de como verificar o uso do espaço e quais logs excluir pode ser encontrado na seção de notas.
A Dell decidiu remover o Unity OE 4.0.1.8320161 para Unity e UnityVSA do support.emc.com. Em setembro de 2016, foi publicada uma versão revisada do Unity OE (4.0.1.8404134).
Resolution
Para resolver esse problema, é necessário que o suporte técnico obtenha acesso root ao array.
Entre em contato com o suporte técnico do Unity e mencione este artigo da KB: 489057
Additional Information
Exemplo de como verificar o uso do espaço:
spX:~> df -h /nbsnas Filesystem Size Used Avail Use% Mounted on /dev/c4nasdba1 1013M 55M 908M 6% /nbsnas
O log ou logs que causam isso podem ser encontrados em /nbsnas/http/logs:
spx:~> cd /nbsnas/http/logs spx:/nbsnas/http/logs> ll -h total 975M -rw-r--r-- 1 root root 12K Sep 8 13:32 access_log -rw-r--r-- 1 root root 165K Sep 8 08:45 access_log.1.gz -rw-r--r-- 1 root root 239K Sep 8 06:59 access_log.2.gz -rw-r--r-- 1 root root 1.6M Sep 8 13:32 error_log -rw-r--r-- 1 root root 167K Sep 3 04:56 error_log.1.gz -rw-r--r-- 1 root root 495M Sep 8 13:32 mod_jk.log <<<<<<<<<< -rw-r--r-- 1 root root 475M Sep 8 08:45 mod_jk.log.1 <<<<<<<<<<
svc_dc -lcd (list core dumps) também pode mostrar alguns dumps com o sufixo "_mgmtd".
Eles foram criados quando as SPs entraram em pane, pois alguns serviços não conseguem iniciar (porque /nbsnas está cheio).
spx:/> svc_dc -lcd ======================== [DC copier]: Available on backend: CP_dump_spb_CKM00161701xxx_2016-09-08_13_29_47_17275_ECOM core-dump_dump_spb_CKM00161701xxx_2016-09-08_08_46_23_778_mgmtd core-dump_dump_spb_CKM00161701xxx_2016-09-08_09_18_19_11994_mgmtd core-dump_dump_spb_CKM00161701xxx_2016-09-08_09_18_53_21524_mgmtd core-dump_dump_spb_CKM00161701xxx_2016-09-08_09_41_05_11446_mgmtd core-dump_dump_spb_CKM00161701xxx_2016-09-08_09_41_45_24620_mgmtd core-dump_dump_spb_CKM00161701xxx_2016-09-08_13_28_30_3067_mgmtd core-dump_dump_spb_CKM00161701xxx_2016-09-08_13_29_08_15086_mgmtd