z/Linux構築における6つの勘どころ

2012年2月6日systemZ, z/Linux

こんにちは、システム基盤サービス部の田上です。

今回は、z/Linuxを設計・構築する際の勘どころについて紹介いたします。

z/Linuxを導入する環境では複数のOSを構築することがあります。場合によっては50~100といった単位でOSの導入をすることがあります。「z/Linuxに触れてみよう(後半)」で紹介した手順ですべてのOSを導入するのは時間がかかるうえに、作業ミスの原因ともなります。

そのため、z/Linux環境の構築では通常の導入手順を実施する回数を最小限に抑え、クローニングによるOS構築の手法が良くとられます。このクローニングをする際に、Linuxごとに異なる設定ファイルを作成したり、デバイス周りの制御をしたりするため、IA Linuxとの大きな相違点である「デバイス関係」に触ることが多くなります。

z/Linuxのクローニングをする際に私が感じた点を中心に、z/Linux構築における6つの勘どころを紹介します。

前回の記事はこちら。

【勘どころ1】種別精査

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

必要なパッケージ

Linux技術者からすれば当たり前の話なのですが、不要なパッケージを入れることは管理上も、セキュリティ上も好ましくありません。構築するどのOSとどのOSが同じパッケージでよいかをまず精査しパターン分けしておきます。

ディスク構成

前述のCKD形式のディスクは2.7GB(3パターンのうち最も利用頻度が高い)程度のサイズのボリュームをLVMとして使用します。その分z/Linuxから見たファイルシステムのサイズには自由度がありますので、どのような容量のLinuxがいくつ必要かを精査しておきます。

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

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

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

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

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

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

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

z/Linuxバックアップ方式の考慮点

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

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

FlashCopyを使用したクローニング

コピーする対象はディスク全体になります。DS8000シリーズのディスク装置が提供するFlashCopy(以降FC)機能を使ってディスクをコピーし、VG名、LV名に変更を加えて中の設定ファイルを修正します。

メリット

FCを使うため構築時間が短縮されます(ディスクI/O待ちはほとんどありません)。
手順がファイルコピーによるクローニングに比べ比較的簡単です。

デメリット

ディスクごとコピーしてしまうのでコピー元と先でPV、VG、LVすべてのuuidが同じ物になってしまいます。PV、VGにつきましてはuuidを変更するコマンドが存在しますが、LVにつきましては存在しません(構成ファイルを書き換えてリストアすることで実現は可能です)。

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

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

メリット

uuidの重複が発生しません。

デメリット

手順が煩雑です。実I/Oによるコピーとなるため、FCを使用したクローニングに比べて作業時間がかかります。

【勘どころ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といったデバイス名がつけられます(主にディスク・テープドライブ)。そのため、システムを起動する前に割り振られるデバイス名を予測するのが困難になります。構築時以外にも要件変更によってディスク追加・削除をする必要が発生した場合、デバイスの認識順序が変わってしまい、それまであるデバイス名で認識されていたデバイスが別のデバイス名として認識されてしまうことがあります。

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

まとめ

今回はCKD形式のディスクでLVMを使用して構築する際に、バックアップを考慮したうえでのクローニングする場合の勘所を紹介させていただきました。これまでにいくつかのz/Linux構築案件に携わってきましたが、ほとんどの案件はクローニングでOSを構築しました。1つか2つのOSを構築するのであればクローニングをするメリットはあまりないですが、感覚的には5つぐらいを超える場合はクローニング手法を検討したほうが効率が良いように思います。最近ではFB形式のディスクを使うお客様も増えてきています。FB形式のディスクの場合の勘所についても今後ご紹介しようと思います。

次回の記事はこちら。

  • 株式会社アークシステムの来訪管理・会議室予約システム BRoomHubs
  • 低コスト・短納期で提供するまるごとおまかせZabbix