私は2006年頃に初めてz/Linuxの構築業務に携わりました。アサインされた当初はSystem zのハードウェア担当としての参画だったのですが、学生時代にオープン系システムの構築・管理を行ったことがあり、その技術を評価されてOSの担当者へとシフトしていきました。これまでの記事でもお伝えしたのですが、z/Linuxは構築が完了し、ログインして作業する分にはオープン系のシステムとほとんど同じです。z/Linuxのメリットとして、「オープン系で稼動していたアプリケーションをポーティングしやすい」という点があります。アプリケーションだけではなく、技術者確保という意味でもオープン系技術者の活用が容易である点が大きなメリットだと感じています。

z/OSのように一般の人が触ること自体が難しいシステムは技術者の教育も容易ではありません。しかし、Linuxであれば、技術者の育成はSystem zが存在しなくても可能です。オープン系システムが流行し、誰でも自宅で簡単にLinuxの構築ができるようになった昨今では、教育しなくともLinuxに触ったことがある人は少なくないと思います（私もそのひとりです）。System zが長年培ってきたハードウェアの堅牢性のうえで、万人が触れるOSが動くということは、構築・運用のコスト面で大きなメリットが享受できると思います。

昨年、当時のシステムを拡張し、z/Linuxを追加して新業務システムを構築するという業務に携わる機会がありました。当時の担当者にお聞きしたところ、大きな障害がないだけでなく、ほかのオープン系システムと比較すると、とても安定して稼動しているとのことでした。エンドユーザーから見てもz/Linuxを一度使ってみれば「またz/Linuxを使いたい」となるのかなと思いました。

末筆ながら、最後まで読んでいただきありがとうございました。今回の記事を通して、少しでも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などそれぞれの環境がそれぞれで運用していくという方法です。

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シリーズに限らずほかのディスク装置についても類似した機能が提供されていれば同様と思われます。

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から見た場合データセット）の作成位置を意識しますので、リストアを考えた場合、データセット単位でのバックアップは考慮が必要です。

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

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

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

【勘どころ4】ハードウェア構成

System zでは可能な限りの冗長性が考慮されており、その上で動くOSがOSとして24時間365日連続稼動が可能な環境が提供されています。OSがz/OSであれz/Linuxであれ受けられる恩恵や設計思想に違いはありません。「z/OS環境との違い」といった意味ではFCP形式のディスク、LTOデバイスといった定義が増える程度です。

z/Linuxとしては、「ボンディングを組むからNICはふたつ。予備も考えて4つにしよう」といった具合にどのデバイスがどのLinuxから使えれば良いかをLinuxという観点から設計すれば良いと思います。

【勘どころ5】不要デバイスの制御

System zは「システムが連続稼動可能な環境であること」を大切にしています。ハードウェアとしても動的なデバイス追加・削除をサポートしており、z/Linuxからもその恩恵を享受することができます（一部ディスクのon/offの話は既にさせていただきました）。しかし、それゆえにデフォルトの状態では「使用できる準備が完了しているデバイスが多すぎる」という状況に陥る場合があります。もちろんハードウェア側から「使用できないようにする」という定義も可能ですが、拡張性の面からもある程度は使用できるようにしておくのが一般的です。

しかしながらz/Linuxは起動の段階で使用することのできるすべてのデバイスを感知してしまうため、起動に時間がかかったり、CPUを過剰に使用してしまうといった好ましくない状況が起こり得ます。この事象に対する具体的な対応として、使用できるデバイスの状態を一段階下げる（動的に追加できなくするわけではありません。起動時に実施するフェーズを後回しにするだけです）といった設定を施す必要があります（/etc/zipl.confによるディスク制御など）。

【勘どころ6】デバイス認識順序

z/Linuxのデバイスは/sys配下にデバイスアドレスとして認識され、認識した順に/dev/dasdnといったデバイス名がつけられます（主にディスク・テープドライブ）。そのため、システムを起動する前に割り振られるデバイス名を予測するのが困難になります。構築時以外にも要件変更によってディスク追加・削除をする必要が発生した場合、デバイスの認識順序が変わってしまい、それまであるデバイス名で認識されていたデバイスが別のデバイス名として認識されてしまうことがあります。

このような状況を避けるため、設定ファイル上は /sys 配下に認識されたデバイスアドレス付きのブロックファイル（もしくはalias）を指定するようにすることで上記のような事象を回避することができます。

いかがでしたでしょうか？

本章ではバックアップの話が出てきましたが、次章ではさらに「運用」という観点を考慮に入れてお話いたします。
なお、次回の内容は日本GUIDE/SHARE委員会（別ウィンドウで開きます）（JGS）における研究プロジェクト [SP-02]部会「z/Linux環境の運用をどう設計するか？」に参画したときの議論を元に紹介いたします。

 【勘どころ1】種別精査

クローニングは文字通りベースとなるLinuxをコピーし、別のOSを作る手法です。どういったOSを元として展開していけばよいのか？といったことを以下の2つの観点から決めておくと構築がスムーズに進みます。もちろん、どちらもクローニング後に調整することは可能です。

【勘どころ2】バックアップ方式

z/Linuxのみが稼動しているシステムでのバックアップの運用設計においては、バックアップ取得用のOS（バックアップサーバー）をひとつ作成し、そのOSから他のOSのディスクが見える状態にして、バックアップをとるような設計がよく用いられます。

※z/VM配下での環境やz/OSと共存環境などにおいてはこの限りではありません。

ここで気にしなくてはいけないのがLVMのuuidです。クローニングの手法にもよるのですが、仮にすべてを同じOSからコピーした場合、バックアップサーバーとバックアップを取得されるOSでuuidが重複してしまうため、LVMの構成管理上に不整合が存在することとなってしまいます。

また、多重度を上げるために複数OSのディスクを一度に見えるような形にしてバックアップを取るような場合、バックアップを取得されるOS同士のuuidも重複することとなります。

しかしながら、z/Linuxでは必要な時に必要なディスクだけを見えるようにしたり（online）、見えないようにしたり（offline）することができますので、バックアップのしくみにディスクのon/offを制御するようなステップを組み込むことでuuidの重複をある程度緩和することもできます。

つまりクローニングを使用する際は予めバックアップ設計も考慮に入れる必要があると言えます。

【勘どころ3】クローニング手法

私が今まで携わってきたz/LinuxのOS構築はいずれもクローニングによるものだったのですが、そのコピー対象や方法によってそれぞれ手法が異なりました。前述の通りバックアップ設計との兼ね合いが重要になりますので、その点を考慮して手法を決める必要があります。今回は2つのクローニング手法についてメリットやデメリットも含めて紹介します。

(1) FCを使用したクローニング

コピーする対象はディスク全体になります。文字通りDS8000のFC機能を使ってディスクをコピーし、VG名、LV名に変更を加えて中の設定ファイルを修正します。

(2) ファイルコピーによるクローニング

コピー対象をファイルシステム内のファイルのみとします。必要なLVMについてはコマンドを使用して作成します。

クローニングによるOS導入作業での主な勘どころは以上の3点です。
次節ではその他の勘どころをいくつか紹介します。

z/Linuxを導入する環境では複数のOSを構築することがあります。場合によっては50～100といった単位でOSの導入をすることがあります。第3章で紹介した手法ですべてのOSを導入するのは時間がかかるうえに、作業ミスの原因ともなります。そのため、z/Linux環境の構築では通常の導入手順を実施する回数を最小限に抑え、クローニングによるOS構築の手法が良くとられます。このクローニングをする際に、Linuxごとに異なる設定ファイルを作成したり、デバイス周りの制御をしたりするため、IA Linuxとの大きな相違点として第1章2節で述べたように「デバイス関係」に触ることが多くなります。

クローニング自体はIA Linuxでも実施可能であり、実績もあると思います。私はIA Linuxのクローニングを実施したことがないので、IA Linuxでも同じようなことに気を使っているのかもしれませんが、本章「勘どころ」では主にz/Linuxのクローニングをする際に私が感じた勘どころについて紹介したいと思います。

前提知識（LVMとFlash Copy）

メインとなるz/Linux 構築における6つの勘どころについてお話をする前に、技術的な2つのキーワード（LVMとFlash Copy）について説明いたします。

LVM

z/Linuxで使用するファイルシステムはLVM上に構成することがほとんどです。これはz/Linuxでよく使われるCKD形式のディスクが1ボリューム0.9GB、2.7GB、8.1GB（サイズはおおよそ）といった固定かつ小容量ディスクサイズで構成されるためです。

ディスク装置の技術としては、他のサイズのCKD形式のボリュームも作れるのですが、メインフレーム（z/OS）において使用されてきた歴史的な側面もあり、また管理が煩雑にならないように、使われるのは多くてもこの3パターン程度です。

この項でお伝えしたいのは「LVMとは？」といったことではありません。普段は気にしないであろうLVMの特性についてです。LVMはその構成要素となるPV、VG、LVの構成を管理するために各々にuuid(universally unique identifier)というものを割り当てます。LVMは同じシステム上に同じuuidが存在することは想定していません。 z/Linuxでは構築手法、バックアップ方式によってはこれが重複してしまうことがあります。今回の勘どころではその大半がこれを避けるための知見を提示しています。

Flash Copy（以降FC）

System zのディスク装置としてよく使われるDS8000シリーズが持っている機能です。RAIDディスク上に仮想的に作成したディスクのコピーをする際、条件に一致すれば、ディスク装置内のメモリーテーブルのコピーと更新フラグの管理をすることで表面上のコピー時間は数秒で終わらせ、実際のデータコピーはバックグラウンドで実施するという機能です。構築作業の中でよく使用します。

余談になりますが、z/OSの場合、ディスク装置とSystem zをつなぐチャネル経由でFCの命令が発行できます。そのため、ユーザーは通常のコピーを実施するだけで、FCを使用可能か否かが自動で判断されます。z/Linuxではチャネル経由での命令発行ができないため、FCが使用可能か否かはユーザーが判断し、コマンド発行はTCP/IP経由でディスク装置の管理端末にログインして実施することになります。

ここまでの手順で、System z上でSLES10が稼動している状態となりました。
TeraTerm、Puttyなどのクライアントソフトを利用してSSHでゲストOSに割り振ったIPアドレスにアクセスしてみてください。

実際にログインしていただければ分かりますが、存在するコマンド、ディレクトリ構成など、デバイス構成を除けば、表面上はIA Linuxと変わりません。
第1章2節の中で紹介した「独自コマンド」もIA Linux同様マニュアルが用意されておりますので、”man lsdasd”と実行すればマニュアルを確認することができます。ぜひ実行してみてください。
 

駆け足でz/Linuxの導入方法を紹介させていただきましたがいかがでしたでしょうか？IA Linuxの導入経験のある方なら、ほとんど差がないことが確認できたのではと思います。

導入方法も使用感もIA Linuxと大きな違いがあるわけではないわけですが、ではz/Linuxの設計・構築を行う上ではどんなところを気にするべきなのか？
第4章では、私がこれまでz/Linuxの設計・構築に携わるなかで感じた勘どころを紹介させていただこうと思います。

6-3.YaSTによる導入－再起動後

HerculesからゲストOSを起動します。

YaSTの待機画面になったら再度ウェブブラウザから以下にアクセスし、YaSTへログインします。
http://aaa.bbb.ccc.100:5801/
上記の「aaa.bbb.ccc.100」は、手順4（Hercules用ハードウェア定義ファイルの作成）にてゲストOSに割り振ったIPアドレスになります。

●Hostname and Domain Name
Hostname、Domain Nameを入力し「Next」を選択します。（任意の名前で構いません）

●システム管理者「root」パスワード
パスワードを入力し「Next」を選択します。

●ネットワーク設定
“ハードウェア検出の確認”画面で「続行」を選択し、表示された画面でファイアウォールを「使う」を選択し、使わないの状態にし「Next」を選択します。

●ネットワークへの接続のテスト
「テストをスキップする」を選択し、「Next」を選択します。

●インストールの設定
「Next」を選択します。

●ユーザー認証方式
「ローカル（/etc/passwd）」が選択されている状態で、「Next」を選択します。

●新規のローカルユーザー
作成するユーザー情報を入力し、「Next」を選択します。

●リリースノート
「Next」を選択します。

●ハードウェア設定
「環境設定をスキップ」を選択し、「Next」を選択します。

●インストールが完了しました
「完了」を選択し導入を終了します。
しばらく待つと以下の画面が表示され、ゲストOSが起動します。

6-2.YaSTによる導入

Herculesの画面が以下のようになっていればYaSTの準備が完了しています。

Java Plug-inを導入してあるウェブブラウザで以下のURLを開きます。
http://aaa.bbb.ccc.100:5801/
上記の「aaa.bbb.ccc.100」は、手順4（Hercules用ハードウェア定義ファイルの作成）にてゲストOSに割り振ったIPアドレスになります。

前項で設定したパスワードを入力しログインします。
ここから先はほぼ通常のLinux導入と同じです。

●Language
「日本語」を選択し「Next」をクリックします。

●License Agreement
「Yes, I Agree to the License Agreement」を選択し「Next」をクリックします。

●Disk Activation
DiskはSystem zのストレージであるdasdを使用するため、IAとは若干異なります。
「Configure DASD Disks」を選択します。

●DASD Disk Management
Channel：「0.0.1000」を選択した状態で「Select or Deselect」をクリックすると、Sel.：「Yes」に変わります。

この状態で「Perform Action」から「Activate」を選択するとDevice、Typeなどの情報が表示され、使える状態になるので「Next」を選択します。

“Disk Activation”の画面に戻るので「Next」を選択します。

●Installation Mode
「New Installation」を選択し「Next」を選択します。

●Clock and Time Zone
「Asia」「Tokyo」を選択し「Next」を選択します。

●Installation Settings
「Partitioning」を選択し、パーティション作成をします。Device：「/dev/dasda」を選択し、「dasdfmt」を選択します。確認用のポップアップが出力するので「Yes」を選択します。

パーティション作成が完了したらDevice：「/dev/dasda1」を選択した状態で「Create」を選択し、Expert Partitioner画面を開きます。

●Expert Partitioner
「Format」を選択、「File System」で「Ext3」を選択します。「Mount Point」に「 / 」を入力し、「OK」を選択すると、”Expert Partitioner”の画面で詳細情報が表示されます。「Finish」を選択し終了しようとするとSwap領域がない旨のメッセージが表示されます。Linuxに詳しい方は”Edit Partio /dev/dasda1”の画面で１GB程割り振っていただいても問題ありません。ここでは割愛しますので、「No」を選択してください。
 

“Installing Settings”画面に戻るので「Accept」を選択します。

●Confirm Installation
確認画面です。「Install」を選択し、処理が終了すると一旦システムが停止します。

6.SLES10の導入

z/Linux（SLES10）の導入は大きく3つのフェーズがあります。

1. 導入媒体／接続方式の指定（Herculesをインタフェースとします）
2. YaSTによる導入（いくつかの選択肢はありますが、VNCをインタフェースとします）
3. YaSTによる導入－再起動後

6-1.導入媒体/接続方式の指定

導入媒体／接続方式の指定のステップでは、図のように対話式の質問に答えていきます。
Herculesから内部で起動しているゲストOSに対して入力するときは「 . 」を先頭に打ちます。
導入媒体をFTPとし、接続方法をCTCとした場合の応答を以下に記述します。

ここまでの設定がうまくいくと以下の画面のようになり、次の処理へ進みます。

3.仮想デバイスの作成

ゲストOSがディスクとして使用するためのファイルを作成します。
コマンドプロンプトを起動し、作成先のディレクトリへ移動。以下のコマンドを実行します。
作成先のディレクトリには9GB程度の空き容量が必要になります。
この例では G:\hercules という場所に仮想ディスクを作成しています。
導入される環境に合わせて変更してください。

4.Hercules用ハードウェア定義ファイルの作成

上記と同一のディレクトリに sles10.conf という名前のファイルを作成してください。
ファイルには以下の内容を記載してください。太字部をホストOSの環境に合わせて変更してください。

5.Herculesの起動～導入開始

Herculesのインストールによって作成される「Hercules Command Prompt」を実行するとコマンドプロンプトが実行されます。
先ほど仮想デバイスを作成したディレクトリに移動し、以下のコマンドを実行するとHerculesが起動します。

上がHercules起動時の画面です。
この状態で以下のコマンドを実行するとインストールが開始します。
i:\ はDVDを読み込んでいるドライブ名に変更してください。

1.ホストOS環境構築

1-1.Herculesの導入

インストーラを実行しインストールしてください。インストール後「マイコンピュータ」を右クリックし「プロパティ」から「詳細設定」のタブを開きます。
「環境変数」から「システム環境変数」へと進み「Path」をダブルクリック。「変数値」にHercules導入先（通常はC:\Program Files\hercules\hercules-3.06\）を追加してください。
※既存の値に追加する値は ; で区切って設定してください。

1-2.WinPcapの導入

インストーラを実行しインストールしてください。

1-3.FishLib DLL／CTCI-W32の導入

解凍後binディレクトリ内のファイルをすべてHercules導入先へコピーしてください。

1-4.Java Plug-inの導入

SLES10インストール過程でVNCに接続する際に使用します。VNC Clientというソフトウェアを使用してもかまいません。

1-5.Microsoft Visual C++ 2005 SP1 再頒布可能パッケージ （x86）の導入

インストーラを実行しインストールしてください。

1-6.Windowsファイアウォールの設定

WindowsファイアウォールをOFFにしてください。導入作業が終了した後に、元に戻して問題ありません。

2.導入メディアの準備

Hercules上で稼動するゲストOSが導入メディアから直接読み込むのは『最小限のシステムとして起動するためのファイル』のみです。その他のデータは、コードサーバーと呼ばれるサーバーからネットワーク経由でダウンロードします。
今回はコードサーバーもホストOS上に構築することとします。

2-1.DVDイメージの読み込み

ダウンロードしたSLES10のディスクイメージをDVDメディアに焼いてDVDドライブで読み込むか、仮想デバイスとしてマウントしてください。ここではDVDドライブを I:\ とします（仮想デバイスについての詳細は省略させていただきます）。

2-2.FileZilla Serverの導入

インストーラをダブルクリックし、すべてデフォルト設定のまま導入してください。インストールが完了すると右のような画面が表示されます。Always connect to this serverにチェックを入れて「OK」を選択してください。
【注意】PC内のファイルをネットワーク経由で抜き出せる状態になりますので、SUSE導入が完了した後は、アンインストールすることをお勧めします。

2-3.FTPサーバーの設定１（ユーザー追加）

以下のようなFileZilla Serverの操作画面が表示されるので、「Edit」→「Users」を選択してください。

表示された【Users】の画面で右端の「Add」を選択し、【Add user account】画面で、上段の枠に適当なユーザー名を入力し、「OK」をクリックしてください。
ユーザー追加が完了したら、「Password」にチェックを入れ、パスワードを入力してください。
最終的に、右のような画面になっていれば問題ありません。

2-4.FTPサーバーの設定２（共有フォルダの追加）

上述の【Users】画面。左側の「Page:」内、「Shared folders」を選択し、右側に表示された「Shared folders」内の「Add」を選択してください。【フォルダの参照】画面が表示されますので、導入DVDを読み込んだドライブ（ここでは I:\）を選択し「OK」を選択すると右のような画面になります。
「OK」を選択し、設定を終了します。FileZilla Serverのメイン画面上にエラーメッセージが出力されていないか確認してください。

2-5.接続テスト

コマンドプロンプトを起動し、以下（太字の部分）を入力してください。

上記のようにDVD内のファイル名がリストアップされれば問題ありません。

本章はみなさんが自社で活用するイメージが持てるように、z/Linuxの稼動環境を一から構築することでその特徴をキャッチアップしていただくことを目的としています。

System zのハードウェア環境を準備せずにPC上でz/Linuxを稼動させることができるように、特別な検証環境を準備してセットアップする手順を解説します。

z/Linux構築環境

ホストOSとなるWindows上でHerculesというSystem zエミュレータを動かし、その上にゲストOSとしてz/Linux（以下、SLESと呼称）を導入します。

 
z/Linux構築環境

必要ソフトウェア

今回使用する環境の詳細を以下に記載します。ユーザーインタフェースや選択肢、設定方法などに違いはあるかもしれませんが、特に記載が無ければ別のバージョンを使用していただいてもかまいません。バージョンが異なる場合は適宜読み替えて参照ください。また、HerculesにつきましてはWindows上でなくても動作します。詳細につきましてはHerculesホームページhttp://www.hercules-390.org/（別ウィンドウで開きます）にて確認してください。

OS

エミュレータ

ライブラリ系

FTPサーバー

プロジェクト概要

金融系企業のお客様において新規システムとしてファイルサーバーを構築しました。業務性質上は高い信頼性と拡張性、高速でのファイル共用などが求められるものの、コストミニマムでの運用が必要という要件を満たすために、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を意識した違いは、「高い信頼性／可用性／拡張性」を享受するために必要なものであり、予め分かっていれば臆する事は無い、と言えると考えています。

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