プロジェクト概要

金融系企業のお客様において新規システムとしてファイルサーバーを構築しました。業務性質上は高い信頼性と拡張性、高速でのファイル共用などが求められるものの、コストミニマムでの運用が必要という要件を満たすために、z/Linuxによる環境構築を採択しました。

アークシステムの担当業務

当プロジェクトにおいてアークシステムは主に以下の範囲を担当しました。

• システム詳細設計
• z/Linux環境構築方法および運用方法の検討
• インフラ構築から結合テストまで

特徴

1. HiperSocketsを活用したファイル共用の高速化

System z上のz/Linux同士でファイルシステムを共有した上でクライアント（Windows端末）へ資源を提供するという要件を満たすために、System zの機能であるHiperSocketsと呼ばれるネットワークインターフェース上にNFSを構築することで、ファイルシステム共有を実装しました。

HiperSocketsとは仮想的なネットワークインターフェースであり、同一筐体内の仮想区画同士がメモリー転送速度とほぼ同等の速度で通信を行えるという仕組みです。これを用いることによって高速なI/Oが可能なNFSを構築しました。

HiperSocketsを活用したファイル共用の高速化

2. 設計書（設定情報）と実際の設定値の設定や検証の効率化

z/Linuxのパラメータ設定および確認コマンドからの出力形式を意識した上で、設計書（設定情報部分）のフォーマットおよび記述方法を検討・作成し、設定ミスや、設定値の確認ミスを極力排除する仕組みを構築しました。

プロジェクト概要

金融機関の基幹システムにおいて、650店舗を越える営業店に散在する2100台のサーバーをz/Linuxによって統合するという、アジア圏内では最大級の統合規模となったプロジェクトでした。サーバーのコンソリデーションによって運用コスト、維持管理コストを削減するとともに、System zの高い信頼性を活かした高可用システムを実現するということが、本プロジェクトの目的でした。お客様は元より、メーカーのIBM社や運用ベンダーの方も含めるとピーク時6000人のエンジニアが関わった大規模プロジェクトとなりました。

アークシステムは、z/Linuxインフラの設計・構築に留まらず、システムアベイラビリティの確保、および大規模サーバー群のリソース管理（Linuxパッケージ管理）を実現する運用上の仕組み作りに携わりました。どちらも、大規模なサーバー統合においては必ず必要になるノウハウと考えております。

アークシステムの担当業務

当プロジェクトにおいてアークシステムは主に以下の範囲を担当しました。

•  ハードウェア構成設計、定義
•  z/Linux環境構築
•  インフラ系基本テスト、結合テスト
•  Satellite Serverによるパッケージ管理

特徴

1. LVMミラーによる可用性の確保

アプリケーション要件として挙げられた「ディスク筐体障害時やロングビジー状態時等の際、アプリケーションのタイムアウト値以内にI/Oを再開し業務を継続する」というサービスレベルを満たすために、IBMが開発したLVMミラーという技術を採用して可用性の高いシステムを構築しました。基本的な操作は通常のLVMと同じなのですが、ログ領域の冗長化や片系障害時におけるI/Oの継続等、様々な機能を追加したものです。そのテクノロジーに関する技術検証と運用方法の確立に携わりました。

LVM ミラーによる可用性の確保

2. 世界初、z/LinuxシステムでのSatellite Serverによる大規模パッケージ管理

今回のサーバー統合によるz/Linuxのサーバー数は300OSという規模になりました。この膨大な数のLinuxのパッケージ管理をいかに行うかという点が運用上の大きな課題であり、構築後にバグフィックス等のパッケージ適用を実施する便宜においてもLinuxのパッケージを同レベルに維持する必要があります。本案件ではSatellite Serverを使用することでz/Linuxのパッケージ管理を行いました。

Satellite Serverとは、IA Linuxで大規模サーバー群のパッケージ管理を行う際に使用されている運用技術です。管理対象のLinuxに適用されているパッケージ情報と、Red Hatが管理するRed Hat Network Satellite Serverが持つ最新パッケージ情報を連携させることにより、自社環境におけるLinuxのパッケージの整合性を維持管理するという仕組みになります。z/Linuxへ適用するのは全世界でも初の試みでしたが、前述のLVMミラー同様に、アークシステムがその技術検証と運用方法の確立に携わりました。

Red Hat Satellite Serverによるパッケージ管理

本稿では、z/Linuxのインフラ構築、運用ツールの作成をする中で私が感じた点を加えながら、System zおよびz/Linuxについて一般的な紹介をさせていただこうと思います。

z/Linuxとは

z/Linuxとは、IBMの製品であるSystem z（いわゆるメインフレーム）上で動作するLinuxを指します。LinuxのディストリビューションとしてはSUSE (R) Linux Enterprise Server、Red Hat Enterprise Linux等があります。この他にもSystem z上で動作するLinuxは存在しますが、現在商用目的として利用されるz/Linuxは前記の2種類がほとんどです。

何故System zなのか？

メインフレームは1964年に誕生し、長年に渡って企業システムの基幹業務を支えてきました。その長い歴史と技術革新の変遷の中で非常に高い「信頼性」、「可用性」、「拡張性」を培ってきました。また昨今の流行である仮想化技術もその祖はSystem zであり、40年の歴史を持っています。他にもI/O処理能力や同時並行処理能力に優れているのがSystem zの特徴です。企業システムのプラットホームとして圧倒的な信頼性と安定性を誇るSystem zの上でLinuxを稼動させることで、Linuxのオープン性を保持したままSystem zのこれらのメリットを享受できるのがz/Linuxを選択する最大の理由です。

IA Linuxとの違い

z/LinuxとIA Linuxを比べるとそのソース改修箇所は全体の数％と言われています。Linuxのコード構造自体には変更を加えず、「カーネル内のハードウェア依存コード」、「デバイスドライバ」、「アセンブラコード」のみに改修が入っており、IA Linux用に開発されたソースコードの90%以上は無修正のままz/Linux上で動くといわれています。

では、どこがどう違うのか？

アセンブラコードについては我々の目に触れるようなことはありません。IA Linuxとの最大の違いは「デバイス周り」と言ってしまえばそれまでなのですが、インフラ構築のSEとして実作業の中で気づいた違いについて、いくつか例を挙げてみます。

ディスク

z/Linuxが使用するディスク形式には大きくFBとCKDの2つの形式があります。

FBはIA Linuxが使用するディスクと使われ方も見え方も同じです。z/Linuxからは、SCSIディスクとして/dev/sdxといった名称で認識されます。

一方で、多くの場合に使用されているのはCKD形式です。CKD形式はz/Linux独自の形式で、System zのH/W機能であるChannel subsystemを使用してI/Oを行うことが出来ます。通常System zにおけるディスク接続は冗長性を考慮し、複数経路を用意します。FB形式では複数経路に対してソフトウェア的にI/Oの最適化を図りますが、CKD形式の場合Channel subsystemが専用H/WとしてI/Oの最適化を担います。単独のI/OのパフォーマンスとしてはFB形式のほうが速いですが、細かいI/Oが重なるようなケースでは最適化のオーバーヘッドが大きくなるため、CKD形式が向いているといわれています。CKD形式はz/Linux独自のドライバが使用され、/dev/dasdxといった名称で認識されます。

ネットワークデバイス

IA Linuxではひとつのポートに対してethxといったように単純にデバイスが割り当てられます。z/Linuxでは、System zがQDIOというプロトコルを用いてポートを使用し、論理的に複数デバイスとして分割します。z/Linuxは分割された論理デバイスのうち3つのデバイスをRead、Write、Dataとして用途を分けて認識し、これらをグルーピングすることによってひとつのネットワークデバイスqeth-xxxxとして認識します。構築時にはこれらを意識してデバイスの追加・削除といった定義変更をしなくてはなりません。

sysfs（/sys配下）

Linuxでは/sys配下にデバイスドライバにアクセスするための構造を提供していますが、System zが提供する独自のデバイスをz/Linuxにおいて使用するために、z/Linux独自のドライバが追加され、sysfsから操作できるようになっています。例えば、同一筐体上の別区画で稼動するOSを含めたリソース使用状況を取得するためのものや、CKD形式のディスク、ネットワークデバイス等を動的に追加・削除するためのドライバ等です。後に述べるz/Linux独自コマンドは実はスクリプトが多く、このsysfsの中身を収集・操作しているものがほとんどです。

ブートローダー

IA LinuxがLiloやGrubといったブートローダーを使用するのに対して、z/Linuxは起動時にSystem z独自のデバイス制御を必要とするため、ziplと呼ばれるブートローダーを使用します。

設定ファイル

上記のような違いを吸収する必要があるため、やはり設定ファイルもオプションが増えたりしています。IA Linuxをご存知の方であれば想像がつくと思いますが、/etc/fstab（ファイルシステム定義）、/etc/sysconfig/network/ifcfg-*（ネットワークデバイス定義）、/etc/zipl.conf（ブートローダー定義）等のファイルがその影響を受ける設定ファイルです。

独自コマンド

やはりデバイス周りのコマンドになりますが、構築時に頻繁に利用したz/Linux独自のコマンドをいくつか紹介します。

上述のように、z/LinuxとIA Linuxの違いは

• 利用者から見ると変わらない
• しかしながら構築時にはH/Wを意識した違いがある

といった説明が一番わかりやすいと思います。構築時のH/Wを意識した違いは、「高い信頼性／可用性／拡張性」を享受するために必要なものであり、予め分かっていれば臆する事は無い、と言えると考えています。

次回からは、私が経験した事例の紹介、構築・運用の勘どころを順次紹介します。

近年注目を集めてきたz/Linuxについて、実際に構築現場に携わってきた中で感じた設計上の考慮点、メリット／デメリットを踏まえながら、以下の内容でそのノウハウを紹介したいと思います。Linuxサーバーの運用負荷が高くて困っている方や堅牢性に不満を持っている方にお勧めします。

• 第1章： z/Linuxとは
  System zおよびz/Linuxの一般的な紹介を、実際にz/Linuxの構築現場に携わって感じた点を踏まえながらお伝えします。
• 第2章： z/Linux構築事例
  アークシステムが携わった構築事例を数点紹介します。
• 第3章： z/Linuxに触れてみよう
  Windows上で動くSystem zエミュレータHercules上でのz/Linuxの導入手段を紹介します。
• 第4章： z/Linux構築の勘どころ
  アークシステムのインフラSEが考える構築の勘どころを紹介します。
• 第5章： z/OS、z/Linux共存環境における運用方法
  日本GUIDE/SHARE委員会（JGS）における研究プロジェクト [SP-02]部会「z/Linux環境の運用をどう設計するか？」について紹介します。
• 第6章： おわりに
   

テープ媒体を使用してデータ移行するにあたり、既存ソフトウェアのみでデータの整合性を確認できる手順を作成することで、データロストしないしくみを確立するとともに、コスト削減を図った。

データの整合性確認の手順

1. 移転元で、ディスク装置からテープ媒体へデータを吸いあげる時にVTOC情報を取得
2. 移転元のVTOC情報は、データと一緒のタイミングに同媒体で搬送
3. 移転先で、テープ媒体からディスク装置へデータを落とした後、VTOC情報を取得
4. 移転元と移転先でのVTOC情報を比較し、差異がないことを確認

システム状況予測から、事業企画側へ締め切り日の前倒しなどを依頼できるようになり、処理の分散化が可能になった。特処理を実施した際、時折発生していた作業ミスなども審査会を行うことで減少した。その上、事業企画部門との定例会を設けたことで、システム化計画や廃止計画が共有されるようになり、余剰機器 (CPUやメモリなど) の流用により無駄な投資を抑えることができてきている。今後は、流用や共用も見込んだ機種選定につながると期待できる。

2. サービスレベルにあったシステム構成への変更による効果

レスポンス悪化やバッチ遅延などは、ほとんどなくなった。今後は、余裕を持ったサーバー増強、ピーク時対応の実施が期待できる。

3. 回復管理におけるユーザー広報の徹底による効果

レスポンス悪化につながる障害が発生した際にも、迅速にユーザーへ連絡できるようになり、コールセンターの負荷は軽減。エンドユーザー側でも回復待ち時間は業務形態を切り替えるなどし、生産性を向上させる動きが出てきた。

前提事項および対応前後の環境

前提

• それぞれの汎用機にはOSA装置が既に存在する。
• SDLC専用端末はすべて直接LAN接続可能な3270端末装置にリプレースする。
• すべての周辺装置のOWNERはMVSAとし、MVSAおよびMVSBの両方のアプリケーション (TSO / CICSなど) をCDRM接続で使用する。

対応前後の環境

アークシステムの支援内容および納品物件

このモデルケースにおいて、アークシステムが果たす役割と業務分担は次のとおりとなります。お客様のご担当者様との協働作業にて、計画作成から実装、テスト、移行まで、首尾一貫して業務推進いたします。

あくまで想定モデルですので、現状環境の複雑さや規模、またお客様との役割分担によって当社の作業範囲と必要工数は変動いたします。お打ち合わせのうえ、概算のお見積もりとご提案を提示させていただきますので、お気軽にご相談ください。

支援内容

凡例 : 　◎実施　　○支援

※ 上記の役割分担はあくまで想定ですので、お客様のご要望に応じて調整は可能です。

納品物件 (ドキュメント)

設計書 / 計画書	基本設計書
	基本テスト計画書
	システムテスト計画書
	移行計画書
	環境設定書
	パラメーター設定書
報告書	ネットワーク構成図
	基本テスト結果報告書
	システムテスト結果報告書
	移行結果報告書
作業管理	作業報告書

• ※お客様ご担当作業範囲分のドキュメントはお客様にて作成いただくことになります。
• ※ご要望があれば以下のドキュメントも提供可能です。
  別途、ドキュメント作成およびデータ収集、テストなどの費用を申し受けます。
  • ・変更手順書･･･ネットワークの変更 (追加、削除、変更など) にともなって発生する作業の概要および作業手順
  • ・操作手順･･･ネットワーク操作全般 (状況確認、障害時の対応など) に関する操作手順
  • ・その他･･･お客様のご要望に応じたドキュメント

作業期間、支援価格

上の「支援内容」の表でアークシステム担当が◎の作業項目を実施する場合の、期間と価格は次のとおりです。

作業期間

1ヶ月程度から

支援価格

100万円程度から

補足

• 汎用機側のハードウェア環境 (OSAなど) を追加構築する必要がある場合、ハードウェア追加にかかわるすべての環境構築業務をトータルに支援することが可能です。
• 実際はこのモデルケースのようにシンプルなネットワーク環境ではないことが予想され ますが、アークシステムでは汎用機全般の豊富な経験をベースに、お客様の環境および要件を考慮した、最適なソリューションを個別に提供いたします。また、 IP化が難しい特殊なプロトコルについても豊富な経験に基づき、最適な解決策を提示いたします。
• CCLへの移行を希望される場合、作業期間が長期にわたり、かつ多額の費用が発生することが予想されますので、予めご了承ください。

Struts-Tilesはその利用を宣言する必要があるとお話ししました。その方法を紹介します。定義方法は前述のようにプラグインをモジュール設定ファイルに追加するのみです。この時に「リスト：struts-config.xml抜粋」のように、ページ定義ファイルへのパスをpropertyとして指定します。

リスト：struts-config.xml抜粋

リクエスト処理手順へのTilesの組み込み

最後に、Struts1.3のHTTPリクエスト処理チェーンにStruts-Tilesが組み込まれるように、Tiles自身が用意しているチェーン定義を設定する必要があります。この定義は Webデプロイメントディスクリプタ (web.xml) のStrutsサーブレットへのパラメーターとして定義ファイルを指定します。具体的には、web.xml の action サーブレットの定義を下記のように指定することになります。

リスト：web.xmlのactionサーブレット定義

以上で、Struts-Tilesを用いたページが生成可能となります。準備に若干の手間がかかりますが、それ以上の効果が得られるはずです。

Struts-Tilesには、ご紹介した機能以外にもプログラム中から動的にレイアウトを変更する機能や定義する機能などが用意されています。この機能を用いることでポータルサイトを構築することも可能です。非常に強力なレイアウト機能を提供してくれるStruts-Tilesに興味のある方は、ぜひ利用してみてください。

ここで1つ注意しなくてはならないことがあります。それは、このページ名はStruts-TilesプラグインすなわちStrutsのコントローラーを経由しないと有効にならないということです。ブラウザから直接この論理名のページを指定しても、表示することはできません。そのため、すべてのリクエストがコントローラーを経由するように、アプリケーション全体のページ遷移を設計する必要があります。最初のページ (通常、index.jspなど) にもStruts-Tilesを用いる場合は、コントローラーにリダイレクト処理などを行うようにする必要があります。

リスト：モジュール設定ファイル (struts-config.xml) 抜粋

このStruts-Tilesのページ定義を行うしくみには、1つ強力な機能が備わっています。それが、レイアウトの継承です。「リスト：tileDefinitions.xml」のuser.shoplistの定義を参照してください。この定義にはtitleとbodyしか指定されていません。<definition>タグのpath属性を指定する代わりにextends属性が指定されています。extends属性はその名の通り、継承を示しています。要するにextendsで指定したページレイアウトを継承し、指定した部位のコンテンツのみを再定義しているのです。再定義されなかった部位は継承元の定義が引き継がれます。この機能により、ベースとなるページレイアウトを1つ定義し、実際に表示させるページはベースのレイアウトを継承し、titleやボディー部のみを再定義してゆけば、簡単にページを定義することができます。また、フッタやヘッダを変更する場合にも、ベースのレイアウト定義のみを変更すれば、継承しているページはすべて変更されるため、メンテナンス性が格段に向上します。Struts-Tilesの素晴らしい機能の1つです。

リスト：tileDefinitions.xml

リスト：shoplist.jsp

以上で、必要なJSPはすべて揃ったことになります。

リスト：header.jsp

リスト：menu.jsp

リスト：footer.jsp

• レイアウト用JSPの作成
• コンテンツ用JSPの作成 (ヘッダ用、フッタ用、ボディー用など)
• ページ定義ファイルの作成

を行い、ページ定義ファイルをStruts-Tilesプラグインに指定します。

レイアウト用JSPの作成

用意する必要があるレイアウト用JSPは、ページのレイアウトパターン分だけです。すべてのページを同一のレイアウトパターンで表示する場合には、1つということです。例えば、先の「スクリーンショット：サンプルデザイン」のようなWebページを作成する場合、そのレイアウト用JSPは、「リスト：layout.jsp」のようになります。レイアウト用JSPは通常のコンテンツ用JSPとは異なり、テーブル関連のHTMLタグを用いてレイアウトを定義します。その際、各テーブルのセルにStruts-Tilesが提供する<tiles:insert>カスタムタグを用いて名前を付けます。ページ定義ファイルでは、この名前をキーにさまざまなコンテンツを結びつけるのです。「リスト：layout.jsp」では「スクリーンショット：サンプルデザイン」の通り header、menu、 body、 footer と各セルに名前をつけています。セルに名前をつける以外にもう1つ、ページのタイトルを動的に変化させるための処理を記述しています。通常、Webページはページごとにさまざまなタイトルをつけ、ページを識別しやすくする必要があるでしょう。このような場合、<tiles:getAsString>カスタムタグを利用します。これはページ定義ファイルに記述した文字列を、動的に挿入するためのカスタムタグです。例えば、同じレイアウト用JSPを利用した2つのページがあり、1つはページA、もう1つはページBというタイトルを表示したい場合に、ページA、ページBという文字列をページ定義ファイルに定義しておけば、各レイアウトにあったタイトルを表示することが可能となるのです (実際の文字列の定義方法は後述します)。

リスト：layout.jsp

図：Struts-Tilesを用いた場合のイメージ

図からもわかるように、Struts-Tilesは各ページのレイアウト定義が記述されているファイル (本稿ではページ定義ファイルと呼びます) を参照して、その定義に従ってページの生成を行います。ページ定義ファイルには、生成するWebページに関して、どのJSPとどのJSPをどのレイアウトを用いて合成するかが定義されています。HTMLのフレームや、JSPのinclude機能を用いてページの合成を行う場合には、合成対象のJSP名がレイアウトと一体となり、ページごとにJSPを用意する必要があるためJSP数が増大します。また、JSP名がレイアウトファイル内に記述されるため、実JSP名がモジュール設定ファイル以外のファイルにも定義されることとなり、メンテナンス性が低下する危険性があります。Struts-Tilesでは、レイアウト (本稿ではレイアウト用JSPと呼びます) とコンテンツ (本稿ではコンテンツ用JSPと呼びます) を明確に分離して、両者を繋ぐ情報をページ定義ファイルで定義し、レイアウトに関する情報を集中管理することで、メンテナンス性の向上が図れます。また、レイアウト用JSPには実際に表示するコンテンツ用JSP名は定義しないため、レイアウトパターン数のみレイアウトファイルを用意すればよく、JSP数の大幅な削減が可能となるのです。

Webページを設計する場合、下図のように、ページをヘッダ、メニュー、ボディー、フッタに分けたデザインをすることが多いはずです。

図：サンプルデザイン

単純に考えると部位ごとのページを用意し、フレームによって1つのWebページとして表示する実装方法を思い浮かべるでしょう。しかし、フレームを用いて複数のJSPを合成する方法では、各部位のレイアウトをフレームとして管理するJSPが必要となり、場合によってはそのレイアウト用のページがWebページと同じ数だけできてしまいます。ボディー部に表示したいページとあわせると膨大な数のJSPを作成することになりかねません。またそのメンテナンスも容易ではありません。JSP のinclude機能を使うことによっても同様の機能を実現可能ですが、やはり前述のような問題が発生します。

そこで Struts では、Webページのレイアウト管理を行うフレームワーク Struts-Tiles を提供しています。

Struts-Tilesの機能を以下に示します。

• ページ合成
  複数のJSPページが生成するコンテンツをサーバーサイドで合成して、1つのHTMLページとして生成します。
• ページレイアウト管理
  複数JSPページの合成デザイン (レイアウト) をXMLファイルに定義します。レイアウトを継承して別のページを定義することもできます。モジュール設定ファイルでは、XMLファイルでページにつけた論理名をページに指定することになるため、実JSP名をモジュール設定ファイルから排除することが可能となります。
• 動的なコンテンツ指定が可能
  静的にXMLファイルに定義したレイアウト情報以外にも、プログラム中からレイアウトやその中身であるコンテンツのJSPを動的に指定することも可能です。使い方によってはポータルサイトの構築が可能となります。

機能としては、レイアウト管理を行うだけのツールのため、非常にシンプルですが、その利用による効果は想像以上です。Struts-Tiles自身は、Struts1.3のディストリビューションにstruts-tiles-1.3.X.jar として含まれており、このjarファイルを WebアプリケーションのWEB-INF/lib ディレクトリに配置することで利用可能となります。