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

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

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

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

2z/Linux構築における勘どころ(前編)

z/Linuxのクローニングをする際に私が感じた点を中心に、z/Linux構築における6つの勘どころのうち本節ではクローニングによるOS導入作業での主な勘どころを紹介します。

 【勘どころ1】種別精査

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

必要なパッケージ Linux技術者からすれば当たり前の話なのですが、不要なパッケージを入れることは管理上も、セキュリティ上も好ましくありません。構築するどのOSとどのOSが同じパッケージでよいかをまず精査しパターン分けしておきます。
ディスク構成   前述のCKD形式のディスクは2.7GB(3パターンのうち最も利用頻度が高い)程度のサイズのボリュームをLVMとして使用します。その分z/Linuxから見たファイルシステムのサイズには自由度がありますので、どのような容量のLinuxがいくつ必要かを精査しておきます。

【勘どころ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名に変更を加えて中の設定ファイルを修正します。

メリット FCを使うため構築時間が短縮されます(ディスクI/O待ちはほとんどありません)。
手順が(2)に比べ比較的簡単です。
デメリット ディスクごとコピーしてしまうのでコピー元と先でPV、VG、LVすべてのuuidが同じ物になってしまいます。PV、VGにつきましてはuuidを変更するコマンドが存在しますが、LVにつきましては存在しません(構成ファイルを書き換えてリストアすることで実現は可能です)。

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

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

メリット uuidの重複が発生しません。
デメリット 手順が煩雑です。
実I/Oによるコピーとなるため、FCに比べて作業時間がかかります。

 


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

このページの先頭へ