SoEを促進する技術に
注目が集まる
メインフレームは基幹系業務が中心でSystems of Record（SoR）のイメージが強いが、IBM Zが提供するコネクティビティ機能やLinux on IBM Z（以下、zLinux）上で稼働するオープンソース・ソフトウェア（以下、OSS）が、メインフレームのSystems of Engagement（SoE）を促進する技術として大きな注目を集めている（図表1）。SoEはユーザーと企業とのつながりを大事にするシステムで、かつ迅速な提供が求められるので、システム基盤に自社外のクラウドを利用することが多い。zLinuxは自社内のLPAR Native環境またはz/VM環境で動作するため社外のクラウド環境への載せかえは困難だが、システムの迅速な提供が要請されていることは他のプラットフォームと同様である。本稿ではSoEシステムへの取り組みの第1歩としてインフラ構築や構成の自動化を紹介する。
zLinuxはSoR系のシステムとして開発されるのが大半で、安定稼働を軸とした歴史がある。時間をかけて入念に設計・構築・テストが実施され、高い品質が求められるのである。それゆえ開発期間は1年ほどになるのが一般的で、大規模なシステムになると2年以上かかるものもある。開発手法もマイグレーションによる現行業務ロジックの踏襲が多いため、バージョンの差異による非互換の影響調査に注力することが多い。
その一方SoEシステムは、インフラ構築に時間をかけるよりもシステムの迅速な開発・更改が必須である。現状では、zLinuxをSoE用途で使うときも、メインフレームがSoRの性質を備えるために開発期間の猶予が与えられてきたが、今後はSoEとしての利用が大きく見込まれるため、従来の開発手法では期間・人手とも足りなくなると考えられている。SoEのワークロードを確保するためにSoRシステムの開発期間を短縮する傾向も、既に出てきている。
経済産業省の「平成27年度調査研究レポート」は、日本のIT人材は2020年末までに30万人以上不足すると指摘している。この背景からも、開発手法に自動化を取り入れ、インフラ構築にかかる労力を軽減することが不可欠なのである。
zLinuxで実現できる
システム構成の自動化
インフラ構築にかかる労力を削減するには、OpenStack、Chef、Ansible、ServerSpecなどのOSSの存在が欠かせない。これらのソフトウェアは、インフラ構築に必要なOSの導入からパラメータ構成、インフラのテストまでを自動化することが可能である。
従来、zLinuxの自動化にはシェルスクリプトを使うことが多く、システム構築をより効率よく行うために、ユーザーごとにシェルスクリプトを開発してきた。しかしユーザーごとのシェルスクリプトでは汎用性がないため、労力の大きな軽減は望めなかった。その点、今挙げたOSSを使えば構築手法に汎用性をもたせられ、プロジェクトや開発サーバー数に関係なく自動化のロジックを横展開できる（図表2）。
本稿では、自動化分野でもzLinuxで取り組みやすいシステム・パラメータリングとパラメータ構成の自動化に焦点を当て、OSSのなかでもAnsibleを取り上げる。
zLinuxの操作性はIAサーバー上のLinuxと変わらない。IAサーバーとの相違点はハードウェアのコネクティビティやI/Oデバイス周りで、ディスク装置やネットワーク機器の設定が大きく異なる。またs390xアーキテクチャであるため、商用サポートのあるLinuxディストリビューションは、RedHat、SuSE、Ubuntuに限られる。ディストリビューションとアーキテクチャが限られているので利用可能なOSSにも制約はあるが、増えつつあるのも現状である。
zLinuxを自動構成する目的で使用できるOSSとしては、ChefとAnsibleが存在する（図表3）。Chefは構成先サーバーにChefの導入が必要なので、本稿では構成先サーバーにモジュールの導入が不要なAnsibleを前提に話を進める。
一般的にzLinuxシステムのインフラ構築は、次のステップで行われる。
①OS新規導入
②OS基本設定
③OS個別設定、ミドルウェア導入設定
④インフラテスト
インフラ構築の自動化は①～④のすべてで検討できる。そしてAnsibleで対応可能なのは②と③である。
自動構成ツール
Ansibleを採用するメリット
Ansibleによる自動化で重要なのはコードである。従来は、コマンドベースの手順書を作成し、それを手作業で実行したり作業をシェルスクリプト化して設計書からLinuxへの設定を行っていたが（図表4）、このやり方は構築する環境ごとに手順書が必要になるため作業が重複し、担当者の負荷も大きかった。
Ansibleで用いるコードは、Linuxの設定手順をプログラムに置き換えたもので、Pythonコードによってプログラム化される。そしてこのコードは環境に依存しないので他のプロジェクトでも再利用可能である。システム構築作業者はシステムパラメータを設計書からPythonコードに対応したyaml形式へ変換することで、複数のサーバーの構成自動化を実現できる（図表5）。
これまでの構成方法では、設計書の修正、手順書の反映、オペレーションなどをすべて手作業で行うためミスが起きやすく、リスク軽減のために念入りなレビューを必要としていた。Ansibleにより設計書と手順書のフォーマットを決めることができ、手作業によるオペレーションミスが抑えることができる。これもAnsibleのメリットの1つである。
また、起動しているLinuxの自動構成はAnsibleで実現できるが、ゼロからシステム構成を検討する際はOSの導入も自動化する必要がある。一般的にクラウドではOpenStackなどを使いOSをテンプレート化してユーザーに提供するが、オンプレミスでクラウド環境を整備しているユーザーは少なく、zLinuxでもクラウド環境が構築されていないことがほとんどなので、初期導入したシステムをコピーして使用するクローニングが多く利用されている。
z/VM環境における
zLinux自動構成の検討
ここからは、z/VMによってクローニングされたzLinuxサーバーをAnsibleとの組み合わせで自動構成する仕組みについて解説しよう。
zLinuxはIA Linuxと異なり、リソース（ディスク、ネットワーク、ホストバスアダプタなど）をアドレスで管理している。z/VMはアドレスを仮想化できるため、異なる物理装置でもLinuxには同一のものとして提供可能である。そのためDASD（ディスク）を使用するシステムでは、そのままディスクコピーを行って同じシステムを可動させることできる。
ただし、コピーしたシステムは、システムごとに固有であるべきホスト名やIPアドレスなども同一になってしまうので、ユーザーによる変更作業が必要になる。また、FCP（SAN Disk）を使用している場合、WWPN、LUN番号などはディスク上に保存されている情報となるため、z/VM環境でも仮想化できず単純なディスクコピーではシステムを正常起動することはできない。
z/VM環境におけるLinuxのクローニングは、Linuxがz/VMで可動するようになった初期から行われているが、システム固有の情報は手動もしくはユーザー作成のスクリプトで行うのが一般的であった。システムのクローニングとAnsibleなどの自動設定ツールを組み合わせることで、システム作成にかかる作業負荷の大幅な削減が期待できる。
システムのクローニング
z/VMでシステムをクローニングしてサーバーを構成する場合、以下のような手順となる。
①ディスクのコピー（FlashCopy、z/VM DDRなど）の実施
②z/VMゲストの作成（Dirmaintが有効であれば自動化可能）
③他のLinuxでコピーしたディスクを認識
・DASDの場合はDASDをアタッチ
・FCPの場合はFCPをアタッチしWWPN/LUNを認識させる
④/mntなどに/（rootファイルシステム）をマウントし/boot/ziplなどディレクトを再現する
・dev,proc,sysといったディレクトリの再現も必要
⑤必要な変更を行う
・ IPアドレス、ネットマスク、ホスト名などネットワーク関連
・ DASDアドレス、WWPN/LUNなどのディスク関連
・その他（必要に応じてLVM関連など）
⑥ブートローダーを変更（grub2-mkconfigなどの実行）
⑦chrootを行いinitrdを再作成（grub2-zipl-setupの実行）
上記の作業を行うには、作業実施者のスキルと時間が必要になる。数台であれば対応可能だろうが、台数が多くなると時間もかかり作業ミスなどのリスクも高まる。プロジェクトによっては作業をスクリプト化することもあるが、多少なりとも作業者がかかわるので完全な自動化が求められる部分となっている。
前述したように、Ansibleは起動しているサーバーに対しては設定を行えるものの、システムの導入は行えない。そこでサーバー共通で設定できるものは、コピー元システムに組み込んでおくことで、あとの作業を削減でき、自動構成ツールで実施する必要がある検証作業を省くことができる。
Linuxブートの流れ
システムのクローニングと自動構成ツールの組み込みについて説明する前に、Linuxのブートの流れを確認しておこう。
図表6で示している黄色部分は、各システムで固有になる、もしくは固有にすべき箇所となる。z/VM環境下ではDASDアドレスを仮想化できるので、「DASDの認識」において実アドレスに応じた変更を行う必要はないが、LPARへの対応も考えるならば変更を前提としておくべきである。LVMはVolume Group（VG）名などの認識を指すが、システム固有の名前にする必要はなく共通でも構わない。同時に、同じVG名、UUIDをもつVolumeは扱えないので業務要件によっては変更する必要がある。ネットワークはシステムごとに固有の設定をもつので、必ず変更するものとなる。
Linuxクローニングの自動化
Linuxのブートプロセスに変更を加えることによりクローニングを自動化できる。自動化にあたり、以下のような点に留意したい。
●すべてに対応しようとせずツールの適材適所で対応する
・ブートしてから変更するのが難しいパラメータを変更する
・起動してからでも変更できるもの・問題のないものはAnsibleなど自動構成ツールで対応する。
●変更ルールを決める
・コピー元システムを決めておく
・コピー元環境から変更しなくてはならないものを決めておく
・共通で変更する必要なものに限定する
●共通で設定・導入しておくものはコピー元にしておく
Linuxのブートにおいて初期システムで用いられるファイルシステムは、initrdに含まれている。このinitrdにカスタマイズを行うためのスクリプトを組み込み、実行時にサーバーに合わせた引数を指定することでinitrdにカスタマイズを行わせることができる。
IA Linuxでは多くの場合、ブートローダーとしてGrub2が使用されており、これを使用することでさまざまな引数を渡せるが、zLinuxの場合、Grub2を使用することはインターフェースの違いから現実的でない（z/VMでもLPARでも起動時にフルスクリーンモードでの作業はできない）。このためzLinuxではパラメータファイルを使用しての起動となる。パラメータファイルは設定書などからスクリプトで自動で作成することもできる。ここではIPアドレス、DASDアドレス、LVM（VG名） を変更することとする。
initrdのカスタマイズ
initrdをカスタマイズして以下の項目を起動中に変更できるようにする。自動構成ツールはAnsibleを使用することを想定している。
●DASDアドレスの変更
●IPアドレス・ホスト名の変更
●VG名の変更、ディスクラベルの変更
●/etc/fstabの修正
●VG、PVのUUID変更
●Ansible実行の準備
●initrdの再作成
この変更のためのパラメータファイルは、図表7を使用する。
自動構成ツール
Ansibleの活用
通常、自動構成ツールは、構成したいシステムに対しツールの実行により構成を行うので「プッシュ型のツール」と言える。これに対し、クローニングのタイミングで自動構成するには、構成したいシステムから要求を出す必要があるので「プル型のツール」を使用する必要がある。自動構成ツールであるAnsibleには「ansible-pull」と呼ぶプル型の構成を可能にするツールが同梱されているので、これを利用する。
ansible-pullは次のような特徴をもつ。
●ansible-pullは、Ansibleに同梱されており実行するサーバーに対しPlaybookを適用する
●必要なPlaybookはGitを経由して取得される
●ansible-pullをcronで定期実行することで構成変更の反映を自動化することも可能（本来の使い方）
Ansibleとansible-pullの関係を図表8に示す。ansible-pullを実行するには以下の注意が必要である。
●実行にはAnsibleが実行できる環境を整えておかなくてはならない。
Ansibleはsshを用いて対象サーバーに設定を行っていくツールなので対象サーバーに導入する必要はないが、ansible-pullを実行するにはAnsibleの導入が必要である
●適用されることを想定したPlaybookを書く必要がある。
通常のAnsibleはリモートサーバーに適用するのでコピーするファイルなどはローカルにあることを想定しているが、ansible-pullの場合、GitでPlaybookをもってくるだけなので、考慮しておかないとローカルにあると想定していたファイルがない場合が発生する。たとえばunarchiveモジュールはローカルのファイルをコピーし展開するモジュールなので、ansible-pullで使用すると不具合が発生する。
●Gitが必須なのでGitも忘れずに入れておく。
GitからPlaybookを呼び出す際にホスト名をキーワードとしたPlaybookにするなどの工夫をすることで、要件に合ったシステムを柔軟に構成できるような環境が構築できる。クローニング環境に自動構成ツールを組み合わせることで構築にかかる時間を大幅に短縮でき誰でも構築可能な環境にできる。
＊
SoEシステムが拡大しているなかでメインフレームにおいてもzLinuxを用いたSoEシステムの構築需要が増える見込みである。インフラ開発の需要が高まっていることから開発スピードも速まっているが、IT人材不足が深刻になるなかでインフラ構築の自動化の流れはますます進むと考えられる。本稿ではzLinuxにおけるクローニングおよび構成の自動化を紹介したが、今後はインフラテストの自動化などもメインフレームにおいても採用が進み、いっそう自動化が進むであろう。
････････
著者｜芝崎丈男氏
日本アイ・ビー・エムシステムズ・エンジニアリング株式会社
ISE Mainframe Center
1993年、日本IBMに入社。IBM Notes、WebSphereなどのプログラム開発を行った後、1999年よりLinux on IBM zの活動を始める。2011年にISEへ出向。現在はz/VM、Linux on IBM zを中心に活動している。
････････
著者｜下野主税氏
日本アイ・ビー・エムシステムズ・エンジニアリング株式会社
ISE Mainframe Center
2008年 日本アイ・ビー・エムシステムズエンジニアリング株式会社に入社。入社当時からメインフレーム(Linux on IBM Z, z/VM, z/VSE)の製品技術支援に従事。現在はAutomationに関わるOSSをメインフレームユーザーのデリバリーで扱う活動も行っている。
［IS magazine No.21（2018年10月）掲載］
