4
Siga-nos na web. Procure o Comunicado Uptime na página da Série VNX em: https://support.emc.com/ products/12781 Março de 2014 Até o momento desta publicação, a versão oficial da EMC™ mais recente para o código na família R33 é a 05.33.000.5.038. A EMC recomenda que todos os clientes com sistemas de armazenamento que executem o código na família R33 façam upgrade para a versão 05.33.000.5.038 ou uma posterior o mais rápido possível para se beneficiar de algumas correções significativas detalhadas a seguir. A versão 05.33.000.5.038 (também chamada de 33.038) do Block Operating Environment foi lançada em 13/01/2014 como um service pack de correção crítica, com o objetivo de corrigir, entre outros aspectos, os seguintes problemas críticos: 1. ETA 175619: Os sistemas VNX podem sofrer uma reinicialização 80 dias após o tempo de execução, a menos que um upgrade de código ou uma reinicialização escalonada seja implementada como descrito neste alerta de supervisão . Os sistemas de armazenamento VNX que executam o código na família R33 em uma versão anterior à 05.33.000.5.038 podem sofrer reinicializações não agendadas de ambas as respectivas controladoras de armazenamento em apenas 80 dias de tempo de funcionamento. O número exato de dias varia de um modelo para o outro. As reiniciações da controladora de armazenamento podem se tornar frequentes o suficiente para causar perda do cache da SP. Consulte o ETA vinculado para obter detalhes específicos e medidas que podem ser tomadas para reduzir o risco antes de fazer upgrade de seu código. 2. Um problema que poderia fazer com que as LUNs em pools de desduplicação em block ficassem off-line sob certas circunstâncias. Esse problema não afeta os pools menores da remoção da duplicação em bloco, no entanto, para prevenir, todos os clientes que executam o código na família R33 e usam a remoção duplicação em bloco estão sendo encorajados a fazer upgrade para a versão 05.33.000.5.038. Se as LUNs de remoção da duplicação em bloco ficarem off-line devido a inconsistências, o array deverá receber upgrade antes de as LUNs serem colocadas on-line novamente. 3. Um problema no qual o autoteste da BBU (Battery Backup Unit, unidade de bateria reserva) poderia ser executado diariamente, em vez de semanalmente. Esse problema foi corrigido parcialmente na versão 05.33.000.5.035, no entanto, na versão 05.33.000.5.038, ele está totalmente corrigido. Além de ser executado diariamente, o autoteste da BBU poderia ser executado repetidamente. Durante a execução dele, várias FRUs (Field Replaceable Units, unidades substituíveis em campo) poderiam ficar off-line. As FRUs afetadas com maior frequência incluem: módulos de gerenciamento, certos Slics e a própria controladora de armazenamento. Esse problema resultaria em muitas substituições desnecessárias do hardware. Um hardware substituto não resolverá o problema. O problema foi resolvido no código 05.33.000.5.038. Além das correções mencionadas anteriormente, também há algumas verificações de bugs e outras correções críticas nessa versão. Para obter uma lista completa das correções, consulte as notas da versão 05.33.000.5.038 do Block Operating Environment. GOSTARÍAMOS DE SABER SUA OPINIÃO SOBRE O COMUNICADO UPTIME. ENVIE-NOS SUGESTÕES PARA AS EMISSÕES FUTURAS EM: [email protected] https://mydocs.emc.com/VNX http://emc.com/vnxesupport Upgrade dos arrays R33 para a versão 33.038. 1 Novo recurso de notificação automática do USM. 2 Famílias R32.201 e posteriores fortalecem código do Snapshot: uma atualização. 2 Dicas de CLI do VNX Snapshots na família R32. 2 Revisões de código de destino e principais correções. 3 Impossibilidade de gerenciar controladoras de armazenamento na família R31 após 497 dias. 4 Expansão de thick-LUNs com compactação habilitada causa quantidade incorreta de espaço reservado no pool. 4 Para VNX/VNXe

Para VNX/VNXe · A versão 1.3.2.1.0051 do USM, lançada no primeiro trimestre de 2014, tem um novo recurso que o notificará proativamente quando houver um novo software disponível

  • Upload
    others

  • View
    2

  • Download
    0

Embed Size (px)

Citation preview

Siga-nos na web.

Procure o Comunicado Uptime na página da Série VNX em:

https://support.emc.com/ products/12781

Março de 2014

Até o momento desta publicação, a versão oficial da EMC™ mais recente para o código na família R33 é a 05.33.000.5.038. A EMC recomenda que todos os clientes com sistemas de armazenamento que executem o código na família R33 façam upgrade para a versão 05.33.000.5.038 ou uma posterior o mais rápido possível para se beneficiar de algumas correções significativas detalhadas a seguir.

A versão 05.33.000.5.038 (também chamada de 33.038) do Block Operating Environment foi lançada em 13/01/2014 como um service pack de correção crítica, com o objetivo de corrigir, entre outros aspectos, os seguintes problemas críticos:

1. ETA 175619: Os sistemas VNX podem sofrer uma reinicialização 80 dias após o tempo de execução, a menos que um upgrade de código ou uma reinicialização escalonada seja implementada como descrito neste alerta de supervisão. Os sistemas de armazenamento VNX que executam o código na família R33 em uma versão anterior à 05.33.000.5.038 podem sofrer reinicializações não agendadas de ambas as respectivas controladoras de armazenamento em apenas 80 dias de tempo de funcionamento. O número exato de dias varia de um modelo para o outro. As reiniciações da controladora de armazenamento podem se tornar frequentes o suficiente para causar perda do cache da SP. Consulte o ETA vinculado para obter detalhes específicos e medidas que podem ser tomadas para reduzir o risco antes de fazer upgrade de seu código.

2. Um problema que poderia fazer com que as LUNs em pools de desduplicação em block ficassem off-line sob certas circunstâncias. Esse problema não afeta os pools menores da remoção da duplicação em bloco, no entanto, para prevenir, todos os clientes que executam o código na família R33 e usam a remoção duplicação em bloco estão sendo encorajados a fazer upgrade para a versão 05.33.000.5.038. Se as LUNs de remoção da duplicação em bloco ficarem off-line devido a inconsistências, o array deverá receber upgrade antes de as LUNs serem colocadas on-line novamente.

3. Um problema no qual o autoteste da BBU (Battery Backup Unit, unidade de bateria reserva) poderia ser executado diariamente, em vez de semanalmente. Esse problema foi corrigido parcialmente na versão 05.33.000.5.035, no entanto, na versão 05.33.000.5.038, ele está totalmente corrigido. Além de ser executado diariamente, o autoteste da BBU poderia ser executado repetidamente. Durante a execução dele, várias FRUs (Field Replaceable Units, unidades substituíveis em campo) poderiam ficar off-line. As FRUs afetadas com maior frequência incluem: módulos de gerenciamento, certos Slics e a própria controladora de armazenamento. Esse problema resultaria em muitas substituições desnecessárias do hardware. Um hardware substituto não resolverá o problema. O problema foi resolvido no código 05.33.000.5.038.

Além das correções mencionadas anteriormente, também há algumas verificações de bugs e outras correções críticas nessa versão. Para obter uma lista completa das correções, consulte as notas da versão 05.33.000.5.038 do Block Operating Environment.

GOSTARÍAMOS DE SABER SUA OPINIÃO SOBRE

O COMUNICADO UPTIME. ENVIE-NOS SUGESTÕES PARA AS EMISSÕES FUTURAS EM:

[email protected]

https://mydocs.emc.com/VNX

http://emc.com/vnxesupport

Upgrade dos arrays R33

para a versão 33.038. 1

Novo recurso de notificação automática

do USM.

2

Famílias R32.201 e posteriores fortalecem código do Snapshot:

uma atualização.

2

Dicas de CLI do VNX

Snapshots na família R32. 2

Revisões de código de destino e principais

correções.

3

Impossibilidade de gerenciar controladoras de armazenamento na

família R31 após 497 dias.

4

Expansão de thick-LUNs com compactação habilitada causa quantidade incorreta de espaço reservado

no pool.

4

Para VNX/VNXe

Há um problema conhecido que afeta todas as versões do código no VNX Operating Environment na família R32 até a versão 05.32.000.5.209, incluindo-a. O problema é um defeito na CLI (Command Line Interface, interface

de linha de comando) do Unisphere que faz com que os SMPs (Snap Mount Points, pontos de montagem de snapshot) sejam sempre criados com um proprietário padrão da controladora A se um proprietário padrão não é especificado explicitamente na linha de comando. Isso pode causar trocas e redirecionamentos de tráfego desnecessários no back-end do sistema de armazenamentos™ quando a LUN de base tem um proprietário padrão da controladora B.

Como essas trocas desnecessárias tendem a criar outros problemas de configuração e/ou ambiente, a EMC pretende minimizá-las aumentando a conscientização sobre esse defeito. Para evitar esse problema, os usuários podem usar a GUI do Unisphere para criar SMPs ou especificar explicitamente o proprietário padrão como o mesmo da LUN de base ao emitir o comando CLI para criar um SMP.

A versão 1.3.2.1.0051 do USM, lançada no primeiro trimestre de 2014, tem um novo recurso que o notificará proativamente quando houver um novo software disponível para um array ao qual o USM está conectado. O USM precisa estar conectado a um sistema para receber essas notificações proativas. Na parte inferior da tela, depois de iniciar o USM e conectá-lo a um sistema de armazenamento, você receberá uma notificação proativa se o novo software estiver disponível. O pop-up de notificação permanece aberto por apenas 15 segundos. A seguir, um exemplo dessa notificação.

Os usuários também podem passar o cursor sobre o ponto de exclamação vermelho a qualquer momento para consultar qual software está disponível para o sistema de armazenamento conectado, como mostrado na imagem abaixo:

Se você clicar duas vezes no ícone Auto Notify SW rollover icon, será aberto o Assistente de download do USM, onde os usuários podem fazer download das novas atualizações de software, ferramentas e/ou notas da versão, posteriormente, eles poderão selecionar View no USM para ler as notas da versão.

No Comunicado Uptime do VNX divulgado no primeiro trimestre de 2013, publicamos as seguintes informações:

Nos sistemas de armazenamento VNX que executam o código do Block Operating Environment na família R32 anterior à versão 32.201, há uma rara condição de corrida que pode fazer com que uma ou mais controladoras de armazenamento sejam reinicializadas continuamente quando o último snapshot restante do VNX é excluído. Devido a esse problema, alguns clientes decidiram adiar a implementação do VNX Snapshots ou impedir a exclusão do último snapshot restante. A versão 05.32.000.5.201 do Block Operating Environment conserta esse defeito e remove as restrições mencionadas anteriormente que são associadas ao VNX Snapshots.

Desde a publicação original desse problema no primeiro trimestre de 2013, foram detectados outros sintomas desse bug. Esse problema também pode se manifestar como panes da controladora única ou entrada das LUNs no modo off-line. Como regra geral, se você ainda estiver executando o código anterior à versão 05.32.000.5.201, faça upgrade para a revisão de destino mais recente para se beneficiar das inúmeras correções de bug e da taxa bem maior de tempo de funcionamento/confiabilidade.

A EMC estabeleceu metas de revisão para cada produto a fim de garantir ambientes estáveis e confiáveis. Como prática recomendada, sugerimos trabalhar em níveis de código de destino ou acima para se beneficiar das mais recentes melhorias e correções disponíveis. Procure por “Taxa de adoção” em http://support.emc.com para obter as taxas atuais de adoção do código de destino do VNX/VNXe.

Consulte as Notas da versão do produto para obter uma lista completa dos aprimoramentos da nova versão do código.

Corrige uma pane do Data Mover devido a uma rara janela de tempo que envolve o uso dos recursos de remoção da duplicação e checkpoint.

Corrige uma possível reinicialização do Data Mover que poderia ocorrer se os usuários tivessem vários checkpoints com o mesmo registro de data e hora e o campo de mês preenchido com o valor 12 (dezembro).

Corrige um problema que poderia ocorrer após um upgrade que não causa interrupções, no qual um ou mais drives poderiam ficar off-line, geralmente em apenas um barramento.

Corrige um problema raro de pane da controladora de armazenamento, que poderia ocorrer ao ser feito upgrade do código da família R31 para a família R32.

Corrige um problema que impedia de ser desmontado um file system replicado para Celerra/VNX anterior à versão 7.1 com remoção da duplicação habilitada. Pode travar as operações de replicação.

Corrige um problema que poderia travar um movimentador de dados ao ler um arquivo de 4 GB ou mais.

Corrige um problema de desempenho do VAAI.

Introduz o recurso “Desligamento com um botão” do Unisphere.

Corrige um problema no qual o autoteste da BBU (Battery Backup Unit, unidade de bateria reserva) poderia ser executado repetidamente, o que poderia

fazer com que várias FRUs (Field Replaceable Units, unidades substituíveis em campo) ficassem off-line ou fossem reinicializadas.

Corrige um problema no qual as controladoras de armazenamento poderiam ser reinicializadas após apenas 80 dias.

Corrige um problema sério de remoção da duplicação que poderia levar à inconsistência de dados em certas circunstâncias.

Corrige várias panes, muitas das quais são relacionadas a remoção da duplicação.

Corrige um problema que impedia a recuperação de discos virtuais com mais de 2 TB.

Corrige um problema de desempenho que poderia ocorrer durante o período de inatividade da interface.

Corrige um problema que poderia impedir os usuários de ampliar os compartilhamentos CIFS.

Corrige vários problemas que poderiam impedir os usuários de gerenciar o sistema de armazenamento.

2.4.1.21519 16/12/13 Destino

2.4.2.21519 16/12/13 Versão mais recente

7.0.54.6 (para o componente File Operating Environment) 15/07/13 Destino

7.0.54.6 (para o componente File Operating Environment) 15/07/13 Versão mais recente

05.31.000.5.727 (para o componente Block Operating Environment) 15/07/13 Destino

05.31.000.5.727 (para o componente Block Operating Environment) 15/07/13 Versão mais recente

7.1.74.5 (para o componente File Operating Environment) 13/12/13 Destino

7.1.74.5 (para o componente File Operating Environment) 13/12/13 Versão mais recente

05.32.000.5.209 (para o componente Block Operating Environment) 13/12/13 Destino

05.32.000.5.209 (para o componente Block Operating Environment) 13/12/13 Versão mais recente

8.1.1.33 (para componente File OE) 31/10/13 Destino

8.1.2.51 (para o componente File Operating Environment) 28/02/14 Versão mais recente

05.33.000.5.038 (para o componente Block Operating Environment) 13/01/14 Destino

05.33.000.5.051 (para o componente Block Operating Environment) 28/02/14 Versão mais recente

A EMC assegura que as informações apresentadas neste documento estão corretas na data da publicação. As informações estão sujeitas a alterações sem prévio aviso.

AS INFORMAÇÕES CONTIDAS NESTA PUBLICAÇÃO SÃO FORNECIDAS “NO ESTADO EM QUE SE ENCONTRAM”. A EMC CORPORATION NÃO GARANTE NENHUM TIPO DE INFORMAÇÃO

CONTIDA NESTA PUBLICAÇÃO, ASSIM COMO SE ISENTA DAS GARANTIAS PARA A COMERCIALIZAÇÃO DE UM PRODUTO PARA UM PROPÓSITO ESPECÍFICO.

O uso, a cópia e a distribuição de qualquer software da EMC descrito nesta publicação exigem uma licença de software. EMC2, EMC, E-Lab, Powerlink, VNX, VNXe, Unisphere, RecoverPoint

e o logotipo da EMC são marcas registradas ou comerciais da EMC Corporation nos Estados Unidos e em outros países. Todas as outras marcas comerciais aqui mencionadas pertencem a seus

respectivos proprietários. Copyright © 2014 EMC Corporation. Todos os direitos reservados. Março de 2014

Estas recomendações se aplicam a todas as versões do VNX Operating Environment na família R32, até a versão 05.32.000.5.209 i nclusive.

O VNX emprega um mecanismo de reserva de espaço para thick-LUNs a fim de garantir a disponibilidade do espaço em um pool de armazenamento. Quando a compactação está habilitada em uma thick-LUN, a reserva de espaço não é mais necessária, já que as LUNs compactadas são tratadas de maneira semelhante às thin-LUNs. No entanto, há um defeito no software que reserva espaço em um pool se a expansão de LUN é realizada em uma thick-LUN com compactação habilitada.

Esse espaço desnecessário reservado pode levar a vários problemas no pool de armazenamento, como falha ao criar LUNs, alocar espaço em thin-LUNs e descompactar ou expandir thick-LUNs. Para evitar esses e outros problemas, os clientes não devem expandir thick-LUNs quando a compactação está habilitada. Os clientes que precisam expandir uma thick-LUN com compactação habilitada devem realizar um destes procedimentos:

1. Desabilitar a compactação na thick-LUN e aguardar a descompactação ser concluída. Expandir a LUN até o tamanho desejado e reabilitar a compactação na LUN.

2. Criar uma thick-LUN compactada do tamanho desejado e usar a migração de LUN para migrar a LUN compactada original para a nova LUN.

Observe que, talvez, seja preciso expandir o pool, caso ele não tenha espaço suficiente para descompactar a LUN existente ou criar outra LUN.

Para determinar se a compactação está habilitada em uma LUN, procure a caixa de seleção “Turn On Compression” na guia Compression em Propriedades da LUN no Unisphere ou “Está Compactada: Sim” na saída do comando “naviseccli lun –list”.

O artigo da base de conhecimentos 90301 avisa sobre um problema que pode ocorrer na versão 31 dos sistemas de armazenamento VNX que executam um código anterior à versão 05.31.000.5.720. O principal sintoma dos problemas é a impossibilidade de gerenciar as controladoras de armazenamento pela GUI do Unisphere depois que uma controladora de armazenamento é executada por 497 ou mais dias seguidos. Na verdade, isso ocorre devido a um bug em nosso sistema operacional subjacente, o qual foi corrigido nas versões mais recentes do código do VNX Operating Environment for Block.

O artigo da base de conhecimentos vinculado anteriormente informa os sintomas que podem confirmar maneiras de identificar conclusivamente que essa é a condição da qual você se aproxima. A medida preventiva para essa condição é fazer upgrade do seu código para a versão 05.31.000.5.720 ou uma posterior. No momento, a EMC determinou que a melhor revisão de código de “destino” na família R31 é a 05.31.000.5.727. Consulte a página 3 deste Comunicado Uptime para obter mais detalhes sobre as revisões de código de destino e as principais correções de bugs em várias versões do código.

Caso você identifique esse problema, uma solução temporária é retornar a controladora de armazenamento para o estado gerenciado normal dela a fim de realizar uma inicialização controlada. A EMC recomenda que todas as reinicializações controladas desse tipo sejam realizadas sob a orientação do suporte técnico. Como prática recomendada, desabilite o cache de gravação em um sistema de armazenamento antes de reinicializar qualquer controladora de armazenamento. Essa ação protege contra cache sujo/perda de dados caso o par da controladora de armazenamento sofra qualquer reinicialização inesperada que impediria o cache de ser preservado. Embora essa ocorrência seja incomum, é melhor desabilitar o cache de gravação manualmente para proteger totalmente seus dados.