新しい会話を開始

この投稿は5年以上前のものです

Solved!

ソリューションへ移動

Community Manager

 • 

3.1K メッセージ

4670

2013年10月9日 22:00

VNX Fileの2xx日問題や4xx日問題(コントロールステーションのリブート発生問題)

VNX Fileにおいて、200日過ぎや400日過ぎにリブートが発生する事象があると聞きました。

今利用しているVNXがこの問題に該当するかを確認する方法はあるでしょうか?

31 メッセージ

2015年12月16日 00:00

事象1 :Control Stationのuptimeが208.5日以上である場合、Control Stationが突然Rebootする。

原因   :Linux KernelのBugでクロックソースでTSCを使用している場合、クロックカウンタオーバーフローによりControl Stationが予期せずRebootする。

回避策 :クロックソースをtscからhpetに変更する回避策が提示されております。(手順につきましてはKBをご参照下さい)

解決策 :7.1.70.2以上でFixしております。

事象2 :Control Stationのuptimeが480日以上である場合、Control Stationが突然Rebootする。

原因   :Control Station監視用モジュール(nas_watchdog)の死活監視判定に問題があり、Control Stationのuptimeが480日以上の場合Control Stationが予期せずRebootする。

回避策 :480日前にControl Stationをリブート。

解決策 :VNX1は7.1.79.6以上、VNX2は8.1.8.119以上でFIXしています。

Community Manager

 • 

3.1K メッセージ

2013年10月9日 22:00

はい。確認する方法があります。

以下コマンド出力が"tsc"である場合には問題が発生する可能性があるので、emc317909 https://support.emc.com/kb/91167に従い対応を行うことをお勧めします。

# cat /sys/devices/system/clocksource/clocksource0/current_clocksource

【事象説明】

2xx日問題、4xx日問題の両方ともVNX FileのControl Stationが利用しているLinuxカーネルの不具合、クロックカウンタオーバーフローにより発生するという不具合に起因した事象です。

この不具合を発生させてしまう原因はクロックのカウント方法(ソース)の"tsc"にあることが判明しているために、この設定を確認することにより、本問題に該当するかどうかを判断することが出来ます。

また、このソースを"tsc"から"hpet"に変更することで発生を防ぐことが可能です。

※2013年10月時点でemc317909やemc300585で本事象が報告されています。

なお、この問題はVNX Fileの中でもControl Stationでしか発生しておらず、Data Moverにおける2xx日、4xx日問題は(2013年10月時点)報告されていません。

【問題修正済コードバージョン】

7.1.71.1以降ではクロックソースがデフォルトで"hpet"に変更されているために、本事象は発生しません。

従いまして、

$ nas_version

コマンドの出力結果が7.1.71.1以降である場合には本問題は発生しません。

【emc317909のアクションプラン実行例】

1) ソースを確認

# cat /sys/devices/system/clocksource/clocksource0/current_clocksource

tsc

2) ソースを変更

# echo hpet > /sys/devices/system/clocksource/clocksource0/current_clocksource

3) 変更を確認

# tail /var/log/messages | grep hpet

Oct 10 14:58:09 vnx5300-1 kernel: Time: hpet clocksource has been installed.

4) リブート後もソースがhpetになるようにgrub.confに設定追加

# cat /boot/grub/grub.conf

(出力一部省略)

        kernel /vmlinuz ro root=/dev/hda3 console=ttyS1,19200 TERM=ansi-generic

# vi /boot/grub/grub.conf

[viを利用してclocksource=hpetを追記] 

該当項目の「追記」のみで、grub.confの他の項目は一切変更しないようお願い致します(下記★を参照)

# cat /boot/grub/grub.conf

(出力一部省略)

        kernel /vmlinuz ro root=/dev/hda3 console=ttyS1,19200 TERM=ansi-generic clocksource=hpet

★追記前と追記後の/boot/grub/grub.confファイル例

[追記前]

$ cat /boot/grub/grub.conf

default=0

timeout=10

hiddenmenu

serial .unit=1 .speed=19200

terminal .timeout=10 serial console

title EMC Celerra Control Station Linux

        root (hd0,0)

        kernel /vmlinuz ro root=/dev/hda3 console=ttyS1,19200 TERM=ansi-generic

        initrd /initrd.img

[追記後]

$ cat /boot/grub/grub.conf

default=0

timeout=10

hiddenmenu

serial .unit=1 .speed=19200

terminal .timeout=10 serial console

title EMC Celerra Control Station Linux

        root (hd0,0)

        kernel /vmlinuz ro root=/dev/hda3 console=ttyS1,19200 TERM=ansi-generic clocksource=hpet

        initrd /initrd.img

112 メッセージ

2013年10月17日 17:00

表題の範囲を少し超えますが、Celerra(NX,NS)シリーズやCLARiiON(CX)シリーズなどでは同様の日数問題はあるのでしょうか。

また存在するのであれば同様な修正対応はありますでしょうか。

112 メッセージ

2013年10月17日 18:00

Uehara Y.さん

早速のご回答有難うございました。

Community Manager

 • 

4.9K メッセージ

2013年10月17日 18:00

Celerraシリーズでは同様の問題が報告されています。RH Linux kernel bug# 68466に合致してしまう可能性があるためです。修正方法はVNXと同様にclocksourceの変更です(emc317909がそのままCelerraにも利用可能です)。

CLARiiON、CLARiX(CX)シリーズでは同様の日数問題は存在しません。2xx、4xx日問題はVNXシリーズに利用されているベースのOSに起因した問題であり、CXシリーズで利用しているベースOSはVNXのものとは異なるためです。

Community Manager

 • 

3.1K メッセージ

2014年2月6日 18:00

本対応にコントロールステーションの再起動は不要です。

(設定変更後即時反映されます)

また、4)でgrub.confの設定変更を行っているために、コントロールステーションが何かの理由でリブートされた場合でも設定は残ります(クロックのカウンタ方法が"hpet"で立ち上がってきます)。

特に無理をして確認をする必要はないと思いますが、もしもコントロールステーションの再起動後も問題なく変更が反映されているのかを確認したい場合には、コントロールステーションのリブートを行った後に、以下コマンドの実行で設定の確認が可能です。

# cat /sys/devices/system/clocksource/clocksource0/current_clocksource


【FYI】

コントロールステーションのリブート方法はコントロールステーションのリブート方法に記載があります。

Community Manager

 • 

3.1K メッセージ

2014年3月25日 01:00

Control Stationのリブートが本問題によるものかを確認するために、last rebootコマンドが利用できます。

last rebootコマンドに関する情報はVNX/CelerraのControl Stationリブート履歴確認をご参照ください。

112 メッセージ

2014年11月30日 19:00

Article Number:000091167 Version:3

Celerra and VNX: Control Station reboots unexpectedly, or failover to secondary after over 400 days uptime.

の内容を確認したところ

The Control Station Linux kernel will be upgraded in VNX Operating
Environment (OE) for File 8.0, using "hpet" clocksource as the default.

という記載を拝見しました。

内容的には以前のバージョン制限についての記載がなく、VNX1に関してはすべての7.xのバージョンで対応を

行わなければならない意味に変わっています。

こちらは何時ごろそのようなことが分かったのでしょうか。

また7.x台のOperating Environment (OE) for File では対策修繕がされず今後も新たにりリースされるものでも

hpetの対応をしなくてはならないのでしょうか。

Moderator

 • 

6.5K メッセージ

2014年12月25日 02:00

4man10さん

お知らせをありがとうございます!時間がかかりましたが確認が取れたのでお知らせです・・・

エンジニアと確認を取りました。VNX2では発生なし、その他に関しては 7.1.70.2へのアップグレードで解決するということがわかりました。

KBも以下の分を追加修正してもらいました。

The Control Station Linux kernel will be upgraded in VNX Operating Environment (OE) for File 8.0, using "hpet" clocksource as the default. The fix is also included in 7.1.70-2 and above.

なお、類似事象でFIXされているコードが微妙に違う事象もまれにあるそうです。この場合修正のコードがまだ開発中とのことなので判断に関しては

サポートとの相談が必要なようです。この場合の修正コードは7.1.77.0~(まだ未発表)だそうです・・・・

43 メッセージ

2015年2月22日 18:00

KB91167の情報が更新されました。

https://support.emc.com/kb/91167

類似事例のFixが、7.1.79.x以降のバージョンに含まれています。

1 Rookie

 • 

791 メッセージ

2016年1月7日 23:00

こちらの問題ですが、CelerraでのFixバージョンはないのでしょうか。

何か理由などあるのでしょうか。

Community Manager

 • 

4.9K メッセージ

2016年1月27日 20:00

リリースノート確認してみたのですが、おっしゃる通りCelerraではFixバージョンないですね。。

不思議に思いサポートチームに聞いてみたところ、プロダクト的にEOSLに近くなってきているので今のところ入れていないし、今後入るかどうかも未定(現状で計画が上がっていないということは可能性としては・・・)ということでした。

イベントは見つかりませんでした!

Top