【重要情報】WebSphere Application Server製品　2017年1月1日うるう秒関連情報

現時点で、下記の通りうるう秒に関する情報を報告いたします。
ご不明点につきましては、IBMサービスライン までお問い合わせください。

 

対象製品	要約
WebSphere Application Server	1. WebSphere Application Server(以下WAS)の稼働には問題は発生しないと想定しています。WAS は独自に時刻管理をしていないので設定の変更は不要です。 2. WAS 上で稼働しているお客様のアプリケーションは考慮が必要な場合があります。 3. WAS製品に含まれるLoad BalancerのDispatcherコンポーネントをご利用のお客様は考慮が必要な場合があります。 詳しくは下記をご参照ください。

 

---

【WASに関する考慮点】
●　うるう秒の実施に当たっての時刻の調整の必要性
WASは独自に時刻の管理をしていませんので、設定変更は不要です。


●　うるう秒の調整による製品への影響について
うるう秒への対応によって、多くのOSにおいて時刻が1秒戻されるという調整が行われます。
この影響はNTPによる時刻の修正と同じような影響です。
NTPによる時刻の修正は，「時刻の修正を数分～1時間程度かけてゆっくりと行う」「正しい時間への修正を瞬時に行う」の２通りがあります。

うるう秒の調整がどちらの方式で行われても、WASの稼働に問題は発生しないと想定しています。

他のコンポーネントに対する影響(※１)も考えられますので、前者の「ゆっくりと修正する」方式を利用いただくことをお勧めします。
(※1)Dispatcherについては、下記の「うるう秒によるDispatcherのHeartBeatへの影響」をご確認下さい。


【WAS上で稼動するアプリケーションに関する考慮点】
●　うるう秒の調整によるアプリケーションへの影響について
WASが稼動するJVMは、うるう秒をサポートしておりません（※2）。
そのため、たとえばSystem.currentTimeMillis()は、1970年1月1日午前0時UTC からの経過秒数をmsecで返すとなっていますが、2016年12月31日12時JSTに実行した場合には1483153200000 を返します。
(1970年から現在までは26回の正のうるう秒の挿入が行われており，実際の経過時間は1483153226000です）。

また、2016年12月31日12時JST と 2017年1月1日12時JSTの二つの時刻の差は、うるう秒挿入により86401秒になりますが、Javaのライブラリでこれを計算すると86400秒になります。

2017年1月1日午前8時59分60秒JSTという、実際には存在する時刻がJavaの時刻ライブラリーから戻されることもありません。

アプリケーションのロジックにおいて、これらの挙動が問題になる場合には、アプリケーションでの対処が必要となります。

（※2）Linuxでうるう秒を考慮したタイムゾーンを利用しているような場合には、システムの時刻が2017年1月1日午前8時59分60秒JSTとなりますが、この時にJavaのAPIを用いて時刻を取得しても、秒の値が"60"になるような事はありません。Javaとしてはうるう秒に対する修正はありませんが、前回のうるう秒でOS(Linux)の影響を受けて障害が発生した事例があるため、OSの最新パッチを適用することを推奨します。


【Dispatcherに関する考慮点】
●　うるう秒によるDispatcherのHeartBeatへの影響について
Dispatcherを使用する場合にはNTPを使用することはお勧めしておりません（※3）が、NTPを使用しているHA構成の環境において、うるう秒に伴うNTPの時刻補正とネットワークの遅延などの要因が重なった場合、正副機間でやり取りしているHeartbeatの通信がタイムアウト(デフォルト2秒)し、Takeoverが発生する可能性があります。
Dispatcherノード上でNTPを稼動させていないシステムでは、影響はありません。

発生条件（すべて AND 条件）を以下にまとめます。
1. HA構成である
2. Dispatcher の稼働するサーバーで NTP を稼働させている
3. うるう秒の挿入に伴うシステム時刻の変更が起きる
4. 瞬時に NTP で時刻調整される
5. ネットワークの遅延などの他の要因も重なって2秒以上時刻がずれる


対応方法としては、以下の2つの方法があります。

対応方法1：　
NTPによる時刻の修正は、「時刻の修正を数分～1時間程度かけてゆっくりと行う」「正しい時間への修正を瞬時に行う」の２通りのモードがあります。
前者の「ゆっくりと修正する」方式を利用いただくことで、この問題を回避することが可能です。

対応方法2：
以下のコマンドを用いて、Takeoverのトリガーとなるタイムアウト (hatimeout) を伸ばすことでも対応可能です。

#　dscontrol executor set hatimeout ［秒数］

上記 ［秒数］の欄に5（秒）など新規の秒数を設定します。
この値は動的に変更可能ですが、必ずHA構成を行っている双方のマシンで実行してください。起動時にロードされる構成ファイルに明示的に記載していないと再起動でデフォルト値に戻りますので、再度のコマンド実行が必要になります。
このタイムアウト・パラメータはDispatcherの障害検知に用いられるパラメータですので、問題当日以外は元の値に戻して頂くことを推奨します。
元の値に戻すには、上記コマンドで［秒数］に2（秒）を設定します。


【その他の考慮点】
●　うるう秒挿入後、CPU使用率が上昇する事象
Linuxカーネルの不具合が原因で、2012年6月30日のうるう秒挿入後、JavaをベースとしたWebSphere製品のCPU使用率が上昇する事象が報告されました。
それぞれに関して、RedHat、Novellよりナレッジベースが公開されておりますので、参考情報としてご案内いたします。
OSによってはうるう秒に伴い生じる不具合が報告/修正されている場合もございますので、OSの観点でも対応の要否をご確認いただく事をお勧めいたします。

- RedHat
Why is there high CPU usage after inserting the leap second?
https://access.redhat.com/knowledge/solutions/154793

- Novell
Leap second issues - June 30, 2012
http://www.novell.com/support/kb/doc.php?id=7010351

- Leap Second may cause Linux to freeze
http://www.ibm.com/support/docview.wss?uid=swg21602521
 

---

【お問合せ先】
技術的な内容に関して、サービス契約のもとIBMサービス・ラインにお問い合わせください。
IBMサービス・ライン

【関連情報】 
「うるう秒」挿入のお知らせ (2016年7月8日発表)
・総務省
・国立研究開発法人情報通信研究機構

【重要情報】WebSphere Application Server製品　2015年7月1日うるう秒関連情報
https://www.ibm.com/support/docview.wss?uid=swg21697840
 

---

【変更履歴】
2018/03/22 リンク切れ対応 - "Dispatcherに関する考慮点"から"Network Time Protocol support with WebSphere Edge Components"の文書リンクを削除しました。