当社エンジニアによる書き下ろし技術レポート Close-Up IT

技術レポート 新着RSS(Atom)

この記事に関連するサービス
システム・インフラ基盤の設計・構築
この記事に関連するお問い合わせ
お問い合わせ

第5章 :z/OS、z/Linux共存環境における運用方法

1z/OSとz/Linuxの共存環境におけるバックアップ運用

最終回となる第5章ではz/Linuxの「運用」に触れてみたいと思います。

z/Linuxが採用されるケースは、System zを新規に購入しz/Linuxのみを動かす場合と、z/OSやz/VMが動いている既存のSystem zにz/Linuxを共存させる場合とがあります。前者の場合、既存の分散系での運用を踏まえてSystem z特有の点を考慮しながらz/Linuxの運用設計を行うこととなります。分散系の運用部隊が担当できるということです。後者の場合、ホスト系と分散系の運用が混在することとなります。ホスト系と分散系、どちらの運用部隊がどこまでの範囲を担当するのがよいかといったことがよく課題となります。ひとつの運用課題に対する解決方法もz/OS、z/VM、z/Linuxなどが混在することによって複数の選択肢が生まれます。

以下に、複数の選択肢が生まれる例として、「z/OSとz/Linuxの共存環境におけるバックアップ運用」について、実現方法・メリット・デメリットを紹介します。

1. 各環境で個別に運用

z/OS、z/VM、z/Linuxなどそれぞれの環境がそれぞれで運用していくという方法です。

メリット
  • バックアップを行う際の重要な項目として「静止点の確保」があります。この場合、それぞれのシステムで運用体系を持つわけですから、それぞれが比較的自由なタイミングでバックアップを取得することが可能となります。
  • z/OSとz/Linuxとの間のディスク参照制約に縛られることがありません(後述)。
デメリット
  • 設計・仕組みづくりでのコストが二重にかかります。
  • z/OSとz/Linuxが使用できるテープ装置は異なるため、外部保管を必要とする場合、それぞれにテープ装置が必要となります。

2. どちらかの運用への統合

DBMSのアンロードのようなミドルウェアの機能によって行うバックアップについては、各環境で設計する必要があります。しかし、同じディスク装置を使用しているわけですから、ディスクコピーやデータセットコピー、テープへの外部保管のような処理はどちらかの運用体系に統合することができます。

2-1. z/Linux環境における運用への統合

制約

z/Linuxからz/OSのディスクを参照しようとしても、「Non Formatディスク」つまり、未使用の領域として認識してしまい、アクセスすることはできません。従って、テープへの吸い上げのように、OSとしてディスクを使用する場合、z/Linux環境の「バックアップ運用」にz/OSの「バックアップ運用」を相乗りさせることはできません。

実現方法

z/LinuxがDS8000シリーズのFlash Copy(FC)機能を使用する場合、TCP/IPを経由してディスク装置の管理端末にログインして実行します(第4章1節「前提知識(LVMとFlash Copy)」参照)。そのため、z/Linuxからz/OSのディスクを参照できなくても、ディスク装置にアドレスを伝えることでz/OSが使用する領域のスナップショットを取得することができます。DS8000シリーズに限らずほかのディスク装置についても類似した機能が提供されていれば同様と思われます。

メリット
  • 利用用途は極めて限定的になりますが、ディスクtoディスクバックアップに関しては、分散系運用担当者のみで運用が可能です。
デメリット
  • バックアップを実施する時間帯を分散側の都合に合わせる必要があります。
  • 前述のようにz/Linux側からはz/OSのディスク内容を確認することはできません。
  • z/OS側でディスクtoディスクのコピーを実現する場合と比べると、スクリプト構築のコストがかかります。

2-2. z/OS環境における運用への統合

制約

z/Linuxが使用するディスク形式にはFBとCKDの2つの形式があります(第1章2節「z/Linuxとは(IA Linuxとの違い)」参照)。FB形式の場合、z/OSから認識することはできないので、z/OSからバックアップを取得することもできません。以下はCKD方式の場合の例となります。

実現方法

z/OSからCKD形式のz/Linuxが使用するディスクを参照した場合、z/Linuxが作成したパーティションがデータセットとして参照でき、データセット単位・ボリューム単位などでのバックアップが可能です。ただし、z/Linuxはパーティション(z/OSから見た場合データセット)の作成位置を意識しますので、リストアを考えた場合、データセット単位でのバックアップは考慮が必要です。

メリット
  • 一部制限はありますが、ディスクtoディスクのコピー、テープへの外部保管、世代管理など、z/OS側の運用体系にほぼそのまま統合することができます。z/Linux側のバックアップ運用がほぼ必要なくなります。
デメリット
  • バックアップを実施する時間帯をホスト側の都合に合わせる必要があります。ディスク資源と、スクリプト構築のコストはかかりますが、z/Linux側で一時領域へのバックアップを実施し、一時領域をホストのバックアップ対象に入れることで、このデメリットを解消することも可能です。 

 



このように、それぞれにメリット・デメリットはありますが、「バックアップ」という運用項目ひとつについて考えてみても、いくつかの選択肢が生まれます。実際には「各環境で個別に運用する」のがほとんどだと思います。しかし、共存環境では、こういった複数の選択肢があることを把握したうえで、最適なものを検討するのが理想的だと思います。

また、ソフトウェア、ハードウェア共にそのような環境が整備されていくものと期待しています。

今回紹介した「バックアップ」のほかにも、ITILの提唱する運用設計において考慮すべき項目「障害監視、性能・リソース監視、復旧手順、ログ管理、起動・停止保守、自動化運用」に着目し、課題解決のためのひとつの選定基準を、日本GUIDE/SHARE委員会(別ウィンドウで開きます)(JGS)における研究プロジェクト [SP-02]部会「z/Linux環境の運用をどう設計するか?」にてまとめました。会員登録が必要ですが、興味のある方は参照いただければと思います。

このページの先頭へ