連載
» 2013年10月17日 18時00分 UPDATE

OSS「JobScheduler」で実現するこれからの運用自動化(1):JobSchedulerの機能と設定〜基礎編 (1/2)

本連載では運用管理の一要素である「バッチジョブ管理」に着目し、より効率よいバッチジョブ管理を実現するためのツールであるオープンソースの「JobScheduler」について解説します。

[秋穂賢(TIS株式会社),@IT]

はじめに

 サーバ仮想化やクラウドの浸透により、システム環境はますます複雑化しています。このような中、近年ではDevOpsに代表されるとおり、迅速にサービス提供を実施するために効率よい開発や運用を実施することが求められています。

 本連載では運用管理の一要素である「バッチジョブ管理」に着目し、効率よいバッチジョブ管理を実現するためのツールであるオープンソースのソフトウェア「JobScheduler」について解説します。

※以降、本編の中で記載する「ジョブ」は「バッチ形式で実行するジョブ」を指します。

これまでのジョブ管理

 バッチジョブというと、モダンなアプリケーションとは縁遠いもの、と感じる人がいるかもしれません。しかし現在もなお、特にエンタープライズ環境においてはなくてはならない仕組みでもあります。

 バッチジョブは、黎明期からコンピュータと深いかかわりを持ってきました。最も古くから使われているコンピュータであるメインフレームは1950年代に登場しましたが、そのころから1台で大量のバッチジョブを制御していました。1977年にはメインフレームコンピュータのジョブ運用自動化ツールの草分けともいえる「A-AUTO」が販売されています。このようにジョブ運用自動化の重要性は、コンピュータが登場した当初から認識されていたのです。

 1990年代になると、UNIXなどの登場によってシステムの分散化が進み、複数台の分散環境で稼働するジョブを管理する必要が生じてきました。このようなニーズに対応すべく、国産の運用自動化ツールとして有名な「JP1シリーズ」もこのころに登場しています。

 そして2000年代後半になると、前述のようにサーバの仮想化・クラウド化が進みました。管理するサーバ台数も桁違いに増え、数十台〜数百台、時には数千台といった大規模環境になっています。

【関連記事】

Hadoopの現実解「バッチ処理」の常識をAsakusaで体得

http://www.atmarkit.co.jp/ait/articles/1205/28/news126.html

バッチ処理はJavaでバッチリ? その現状とこれから

http://www.atmarkit.co.jp/fjava/column/andoh/andoh37.html


クラウド/仮想化時代に必要なジョブ運用の自動化

 このように、仮想化やクラウドの登場によって、システム管理者には大量のサーバの管理が求められています。一方でITシステムに求められる要件はこれまで以上に多様化・複雑化し、処理するデータ量は膨大になっています。このような状況において、システムの運用を人手で行うことは現実的ではありません。

 こういった運用の課題に対応すべく、さまざまな運用自動化ツールが登場してきました。

 ジョブの運用自動化ツールも例外ではありません。ジョブの運用自動化は、OSに標準で搭載している機能(Windows環境であれば「タスクスケジューラ」、Linuxであれば「cron」など)でも実施することはできます。しかし、OS標準の機能を使用するといくつかの制約や課題が出てきます。例えば、

  • どのサーバにどのジョブが実装されているのか収拾がつかなくなり、管理が煩雑になる
  • 標準機能ではジョブ実行時間や実行ログなどの履歴管理ができず、独自実装が必要となる
  • 先行後続制御や排他制御などの複雑な処理構成が必要な場合、独自実装が必要となる
  • OSに依存したジョブ実装を行う必要がある

 これらの課題を解決するために、メインフレーム時代から多種多様なジョブの運用自動化ツールが生まれ、使われています。この連載ではその中から、高機能かつ効率よいジョブ運用自動化を実現するオープンソースの「JobScheduler」について解説します。

オープンソースの運用自動化ツール「JobScheduler」

JobSchedulerの概要

 JobSchedulerはドイツのSoftware und Organisations-Service GmbH(以降、SOS社)で開発されている、非常に豊富な機能を有したジョブ運用自動化ツールです。

 JobSchedulerは、GPL2と商用ライセンスのデュアルラインセンスで配布されており、2003年から提供が開始された商用版と、2005年より提供が開始されたオープンソース版があります。

 実行環境としてはLinux、Windowsが標準で対応しており、商用ライセンスを購入することでSolaris、AIX、HP-UXでも動作します。商用版とオープンソース版とで機能的な差異はありませんが、商用版のライセンスを購入するとSOS社からのサポートやコンサルティング、トレーニングなどのサービスを受けることができます。

 日本国外での使用実績も豊富で、ヨーロッパやアメリカを中心に金融・保険・製薬の企業や政府・大学などの公共機関で使われています。一部の企業ではミッションクリティカルなシステムのジョブ運用自動化ツールとしても使われています。

 一方、日本での知名度はまだあまり高いとはいえませんが、日本JobSchedulerユーザーグループが立ち上がり、日本での導入実績も着々と増えてきていることから、ジョブ運用自動化ツールとしての有用性がうかがえます。なお、連載の最終回では、日本の某製造業向けシステムにJobSchedulerを導入した際の事例を紹介する予定です。

JobSchedulerの特徴

 JobSchedulerは、オープンソースソフトウェアでありながら、商用ソフトウェアと遜色のない豊富な機能を備えています。主な特徴は以下のとおりです。

  • 高度なジョブ制御機能と柔軟なジョブ定義
  • エージェントおよびエージェントレスでのリモートジョブ実行
  • デスクトップアプリケーションやWebUIでのジョブ管理
  • APIを使用した操作
  • 高可用な構成
  • ジョブに関する構成定義ファイルがすべてXML形式
  • さまざまな言語でジョブを記述可能

 これら特徴の詳細について解説していきましょう。

JobSchedulerのアーキテクチャ

 JobSchedulerは大きく2つのコンポーネントで構成されています。

・JobScheduler-Engine(以降、Engine)

 JobSchedulerのコア部分であり、各種制御の役割を担います。ジョブ関連の定義は全てEngineで一括管理します。

・JobScheduler-Agent(以降、Agent)

 Engineから与えられたジョブを実行する役割を担います。

 JobSchedulerでは、ジョブの実行状況や履歴の管理を実現するために、外部のRDBMSを使用しています。サポートしているRDBMSは以下のとおりです。

  • MySQL(5.x)
  • Oracle(8.1.7、9.2、10g、11g)
  • Microsoft SQL Server(2000、2005)
  • PostgreSQL(8.x、9.x)
  • Firebird(1.5)
  • DB2(8.x)
  • Sybase ASE(15.0)

 ユーザー側でJobSchedulerを操作するには、以下のアプリケーションを使用します。

・JobScheduler Object Editor(JOE)

 ジョブの内容やスケジュール・実行ホストなど、ジョブに関連する定義を実装する際に使用するデスクトップアプリケーション

・JobScheduler Operations Center(JOC)

 ジョブの実行や停止・状態の監視など、オペレーションを実施する際に使用するWebアプリケーション

・JobScheduler Infomation Dashboard(JID)

 JOEとJOCに加え、実行スケジュール確認や実行履歴確認などの機能が統合されたデスクトップアプリケーション

jobscheduler01_fig01.png 図1 JOC/JOE/JIDの画面例

 なお、執筆時点ではJOCおよびJIDは日本語化されていますが、JOEはまだ日本語化されていません。

JobSchedulerで可能な構成

 JobSchedulerは大きく4つの構成が可能です。

・スタンドアロン構成

 Engine単体で使用する構成。EngineとRDBMSをインストールすることで使用可能です。Engineをインストールしたサーバに加え、Agentがインストールされていないサーバに対してエージェントレスでジョブを実行することも可能です。

jobscheduler01_fig02.gif 図2 スタンドアロン構成

・クライアントサーバ構成

 1台のEngineで複数のAgentを管理する構成。ジョブを実行したいサーバにAgentを配置することで中央のEngineでジョブを一元管理することが可能です(エージェントレスとの違いは表「エージェント/エージェントレスの違い」を参照)。

jobscheduler01_fig03.gif 図3 クライアントサーバ構成
項目 エージェント エージェントレス
ジョブの実行ユーザー Agentをインストールしたユーザー パラメータで指定したユーザー
ジョブ内部でのJobScheduler API使用 可能 不可能
ジョブの内容 さまざまな言語を用いてジョブ内部にロジックを記述可能 1行で表現可能なコマンドのみ実行可能
ジョブの実行ログ リアルタイムでEngineへの実行ログを連携 ジョブ終了時に実行ログを連携
表 エージェント/エージェントレスでの違い

・バックアップクラスタ構成

 2台のEngineでアクティブ-スタンバイ型の構成を取ります。RDBMSにジョブの実行状況を随時保存しておくことで、ジョブの実行中にアクティブ系のEngineが止まった場合でもジョブのエラーが発生することなく、スタンバイ系でジョブ実行を引き継ぐことが可能です。

 前提として、アクティブとスタンバイで同一のデータベースとジョブ構成定義ファイルを設定する必要があります。また、RDBMSやNFSなどの可用性については、JobSchedulerとは別に確保する必要があります。

jobscheduler01_fig04.gif 図4 バックアップクラスタ構成

・負荷分散クラスタ構成

 複数台のEngineでアクティブ-アクティブ型の構成を取ります。特定のEngineに処理が偏らないよう、ジョブの実行量が少ないノードでジョブを実行するよう負荷分散します。

 クラスタに属しているEngineが1分間隔でデータベースの特定テーブルを更新し、1分以上更新のないノードは障害と見なしてクラスタから除外します。その結果、処理可能なノードが含まれているクラスタ内で処理を継続します。バックアップクラスタ構成と同様にクラスタに属するEngineで同一のデータベースとジョブ構成定義ファイルを設定する必要があり、RDBMSやNFSなどの可用性向上についても、JobSchedulerとは別に確保する必要があります。

jobscheduler01_fig05.gif 図5 負荷分散クラスタ構成
       1|2 次のページへ

Copyright© 2017 ITmedia, Inc. All Rights Reserved.

@IT Special

- PR -

TechTargetジャパン

この記事に関連するホワイトペーパー

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。