Hinemos5.0.1移行記（その１：理想と現実の葛藤）

ユーザベース インフラチームの小林です。

前回の記事から引き続き、今回からHinemos5.0.1への移行のお話です。

が、その前に1箇所訂正があります

前回のブログで書いたジョブスケジュール日跨ぎの件ですが、

0:00～48:00に設定する事で、日跨ぎができました！
先日Hinemosセミナーに出た際に、NTTデータさんに教えてもらいました。ありがとうございます。
（けれど、日付の指定が年・月・日をいちいち選ばないといけないので、やっぱり不便です。 日付選択を、カレンダーから選択できる機能もつけてしてほしい・・・と思ってます。）

移行の流れ

さて、話を本題に。
弊社のHinemos環境をバージョンアップするにあたり、おおざっぱに以下の流れで行いました。

1. Hinemos5Managerを新規構築 、動作検証
2. Hinemos3のデータをHinemos5に移行
3. Hinemos3からHinemos5への順次切り替え

（正確にはHinemos3.1.2とHinemos5.0.1ですが、省略します。）

では、動作検証の話

新規構築は、マニュアル通りに行えば特に問題はありません。 動作検証においては、Hinemos3ではあまり高度な機能を使っていなかったこともあり、
ジョブスケジューラとして、以下のような基本的な部分だけの検証で十分でした。(新機能は移行後に順次追加。)

• 指定した通りにコマンド実行ができるか
• きちんと先行条件が効くか
• スケジューラが機能するか

上の部分について全然問題はなかったのですが、Hinemos3と違うところがあったので、思いついた部分を列挙します。

先行条件が自動で変わって便利！
Himemos3の時、ジョブIDを変更したいと思っても、後続のジョブの先行条件も変更しなければならず、すごく億劫でした。
ところが、今回のバージョンアップで試してみたところ、下記のようにジョブIDを変更すると、それに紐付く後続ジョブの先行条件が自動で変わってくれます！

デフォルトのチェックが余計？
新規ジョブ作成時、デフォルトで【条件を満たさなければ終了する】にチェックが入っているのですが、これにチェックが入っていると、前のジョブが異常終了した際などに終了してしまうので、弊社の環境では不便でした。

また、ジョブをコピーして追加したい時に、うまくコピーができる場合と、できない場合（実行コマンド等が空になる）があるので、その謎を解きたいと思ってます。

データ移行は、アトミテックさんに依頼

次に、2点目の「Hinemos3のデータをHinemos5に移行」では、弊社の環境でノード数は約70、ジョブの登録数は約3000とありました。 これを人力で、ミスなく再設定する自信がない・・・
という事で、Hinemosのデータ変換は、Hinemosソリューションパートナーのアトミテックさんに依頼をさせていただきました。 今回はデータの変換だけではなく、Hinemos5移行後のサポートも含めて契約をさせていただき、 後々それが大きな助けとなりました。

ちなみに、アトミテックさんは、ブログでHinemosの情報発信をしており、いろいろな機能の検証をされてます。

Hinemos3->5へのデータ変換は、アトミテックさんにお願いしたことで、 弊社側での残作業は3つ目の「Hinemos3からHinemos5への順次切り替え」になります。

目指す移行方法

「順次切り替え」と書かせていただきましたが、 以下の要因から、一括切り替えではなく、順次確認をしながらの切り替えが可能でした。

• Hinemos3とHinemos5のエージェントは同居可能(Windows環境は除く)
• ジョブの組み方を単純にしているため、機能検証をする項目が少ない

後者について、もう少し詳しく説明します。
一般的なジョブの組み方としては、以下のようにジョブネット間を先行条件で繋ぐことが多いと思います。（Hinemosに限らず）
ところが、弊社環境では、ジョブネット間の連携において、先行条件で繋いでいませんでした。 どういうことかというと、各ジョブネットの最後にファイルを作成させて、 次のジョブは、そのファイルがあると動くようにしており、ファイルの作成・監視もshellで動かしています。 こんな感じです。

このおかげで、こんなことが可能になります。

こうする事で、一度に全部を切り替えるのではなく、ジョブネット一つずつの動作確認をしながら切り替えができるので、 スケジュールに余裕を持たせた移行が可能な状況でした。

と思ったら単純にはAgentが同居できなかったよ！

Agentで使うJavaをマニュアルから抜粋すると、

 Hinemosエージェントを利用する場合
 以下のいずれかのopenjdkをインストールしてください。
   java-1.7.0-openjdk
   java-1.6.0-openjdk

という事になっているのですが、弊社ではOracleJDK1.8を使ってました。
Agentにいれるために、既存のサービスに影響が出そうなことをしたくない。

そしてもう一つ。 インストールディレクトリ /opt/hinemos って、バージョンが違ってもインストール先が一緒だということ。
（rpmコマンドでのインストールなので、オプションを付ければ変更もできるかもしれませんが、デフォルトはこのまま）

つまり、異なるバージョンが同居できるといっても、インストール先をデフォルトから変更をしないといけないのです。

状況の整理

状況を整理すると、

• Agent用にサポート対象バージョンのOpenJDKを入れるか、OracleJDK1.8を使い続けるか。
• Hinemos3とHinemos5のAgentが同居できるといっても、どちらかのインストールディレクトリを変えないといけない。

という問題にぶつかりました。

前者ですが、当初は簡単に考えていて、 OpenJDKのバイナリファイルをダウンロードして、Agentのインストールディレクトリに展開をすればいいのでは、と思っていましたが、 http://openjdk.java.net/をみると、yumからしかインストールができないようです。 yumでインストールした場合、万が一環境変数に変更があったりすると、既存のジョブに影響が出てしまう。 うーん、困った。

そこで、後者。
新規でインストールをするHinemos5のAgentのインストールディレクトリを変える
or
既存サービスで利用をしているHinemos3のAgentのインストールディレクトリを変える

という２択ですが、これから使う方を大事にしたいと思い、Hinemos3の方を変えることにしました。

ここで登場をするのが、やはりアトミテックさんなのでした。 意外と長くなったので次回へ続く。

新機能のジョブのリトライ間隔の検証

ちょっと話題を変えまして、小ネタを一つ。

ジョブのリトライ機能が追加されましたが、

• リトライ間隔ってどれくらいなんだろう？
• それは変更ができるか？

というのが気になり、検証をしてみました。 管理者マニュアルには、他のリトライに関する説明はあったのですが、上の点については書いてないんだもの。。。。

では、検証開始。

1．エラーになるジョブを作る
2．あたりまえだけどすぐ終わる。 3．リトライ回数を2で設定してみたら、落ちるまで20秒かかった。 4．ソースを見てみた。
というか、retryって言葉でgrepをかけてみて探してみた。そして、下の情報にたどり着く。
どうやら、「job.retry.interval」という値で管理ができる。デフォルトは10*1000で、実際は10秒なので、msで設定しているっぽい。 5．プロパティ画面で、job.retry.intervalを60000で設定してみた。 6．ちゃんと2分伸びた！

というわけで、

• リトライ間隔のデフォルトは10秒
• job.retry.intervalで変更可能

というお話でした。