FAQ

10/31/2008 FA Q Linux on zSeries 一般 1 Q.一般的に31bit版と64bit版の選択はどういった基準でなされるのでしょうか？31bit版を採用した場合のメリットとデメリット、64bit版を採用した場合のメリットとデメリ ットについて教えてください。 A.今までのLinux on zSeriesをつかったシステムを構築する案件において主に選択の基準となるのはミドルウェアのサポート状況でした。IBMのミドルウェアのなかには31bit 版しかサポートしていないものがあります。また反対に他社のミドルウェアですが64bit版の使用が前提となっているものがあります。また他のプラット フォーム（x/Linuxなど）で稼動している既存の32bitアプリケーション(C/C++など)を移行してLinux on zSeriesで稼動させるのであれば、31bit版と比較して64bit版の場合ポーティングの手間がかかることが一般的に言えます。Linux on zSeriesにおいては31bit版のメモリの上限は2Gバイトですが64bit版においては2Gバイトという上限はありません。そのため大量のメモリを必要とするソ フトウェアおよびメモリを多く確保したほうがパフォーマンスが良くなるソフトウェアは（メモリを確保して）64bit版で稼動させるのが良いということ になります。逆に64bit版ではポインタなどが64bitで扱われるので31bit版よりも多くのメモリが要求されます。パフォーマンスのことを考えた場合にはコ ンテキスト・スイッチングのオーバーヘッドのことを考えると31bit版のほうが良い場合があるのですが、64bitの命令セットを使用したアプリケーション Q.メモリーの動的追加は可能ですか？ A.できません。 Linux on zSeriesを稼動したまま再起動することなく、増設したメモリをLinux on zSeriesに認識させる、つまり、Linux on zSeriesへのメモリの動的追加ができるかどうかとのご質問だと思いますが、カーネルがメモリの動的追加に対応しておりませんので、不可能です。 Q.Linux on zSeriesはEUCしか選択できないのでしょうか？AIXのように、IBM943を標準の文字コードには設定できないのでしょうか？ A.AIXのようにIBM943を標準の文字コードとして設定することはできませんが、ShiftJIS(ja_JP.sjis)であれば設定が可能です。ただし、ディストリビューションによってはShift-JIS(ja_JP.sjis)をサポートしていないものもあります。 2 3 4 5 Q.Linux on zSeries上で利用できるアンチウィルスソフトウェアはありますか？ A.トレンドマイクロ社の「ScanMail for Lotus Notes」「ServerProtect for zSeries Linux」があります。 また、オープンソースソフトウェアとして、OpenAntiVirus ScannerDaemon(http://www.openantivirus.org/index.php)があり、これはLinux on zSeries上でコンパイルすることで使用は可能です。ただし、オープンソースであるため自己責任での使用となってしまいます。 また、TLES8にはsambavscanがありますが、これ自身がウィルススキャンを行うのではなく別サーバーで稼動するウィルススキャンサーバーと連動するソフトウェアで、Sambaサーバーへの アクセスのみに限られてしまいます。Samba以外の経路で入ってくるデータをスキャンすることはできません。 海外では、F-PROTなどのアンチウィルス製品があります。 http://www-1.ibm.com/servers/eserver/zseries/solutions/s390da/linuxproduct.html Q.シングルユーザーモードで起動することは可能ですか？ A.initコマンドでランレベル１に変更することができます 　# init 1 または、/etc/inittabでrunlevelが指定できますので、そこを変更してrebootすることでシングルユーザーモードで起動することができます。 　(変更前) 　# The default runlevel is defined here 　id:3:initdefault: 　id:1:initdefault: PCのLinuxのように、Linux boot時にパラメーターを与えてシングルユーザーモードで起動することはできません。 Q.無料のLinux on zSeriesを入手したいのですが…。 A.今日現在、無料でダウンロードできるS/390ディストリビューションは複数あります。以下に有名なところをご紹介いたします。 - Marist College：http://linux390.marist.edu/ - ThinkBlue　　　：ftp://linux.s390.org/pub/ - Debian　　　　　：http://www.debian.org/ports/s390/ 6 1a9c0e3b-44a0-4942-afbf-67b9d5bff7a7.xls 10/31/2008 z/VM 7 Q.SPOOLサイズの見積もり方法はありますか？ A.z/VM上をLinuxの稼働のために使用する場合には、システム使用域として見積もるもののなかで、ページング域の他にはそれほど大きな領域は必要にならないと 考えられます。しかし、RSCSを使用する場合やたくさんのLinuxをReaderからIPLする場合や頻繁にダンプ・トレースを取得する場合などでは、スプール域(SPOL域) は事前に割当てられたデフォルトサイズでは小さいために、適切に見積もっておく必要がございます。 SPOL域は、スプールファイル、ダンプファイル、Named Saved Segment(NSS)、ページ域不足時の一時域、として使用されます。これらの総和として見積もることができます。 　1) スプールファイル RSCSを使用している場合は、メールやNJEのジョブやプリンター出力などのファイルがスプールしますので、使用するユーザー数と使用頻度などから、余裕をもって 見積もる必要があります。 Linuxの場合には、PunchしてReaderからIPLするためにSPOL域を使う場合があります。特に、z/VM上でLinuxを導入するときに多く用いられます。そのため、Kernel + parmline + initrd　のサイズと、Linuxの数を掛け合わせた容量のSPOL域が必要になります。 2) ダンプファイル ダンプする場合、ヘッダー部分があるため、実記憶域ページ数に5ページ分を加えたページ数のSPOL域が必要です。 　3) NSS Q NSSコマンドにより確認できますが、NSS 1ページにつき1ページ分のSPOL域が必要です。それに加えて情報用ページが必要ですので、3ページ+(4096ページごとに1ページ加算)が追加で必要となります。 　上記の1) + 2) + 3) + α(余裕) = SPOL域　として見積もることができます。 Q.z/VM 4.2からSAF(System Administration Facility)が提供されていますが、SAFのマニュアルを読むと、変更を加えたVMシステムではSAFを使用しないようにとの記述が見られます。 実運用の観点からすると、セキュリティー確保のためにRACFを追加プロダクトとして導入することが必須かと思いますが、RACFを導入したシステムでSAFを使用する のは問題ないでしょうか？ A.SAFのマニュアルに書かれていますとおり、SAFを使う場合にはz/VM導入直後の状態である必要がございます。 RACFの場合には、USER DIRECTORY等もRACFの管理下となるため、SAFと競合してしまい、整合性がとれなくなる可能性があります。z/VM4.2およびz/VM4.3のSAFではRACFがサポート されておりませんので、もしSAFをお使いになられる場合には、RACFを使わないことをお勧めいたします。 Q.　コンソール制御装置（２０７４）は、OS/３９０の２０７４とシェアで使用できるのですか？ ＬＩＮＵＸ用に一台２０７４を用意する必要はありますか？ A.2074はOS/390の区画とLinux区画(z/VMが稼働?)とでシェアは可能です。Linuxでは2074を直接サポートするわけではございませんが、z/VM上でLinuxが稼働す る場合にはz/VMのコンソールとして2074をOS/390区画とシェアして使用することができます。 Q.Linux shutdown時にCPに対してlogoffを発行する方法はありますか？ A.Linuxブート時に、カーネルパラーメーターとして vmpoff=LOGOFF (LOGOFFは大文字) を渡すことで、shutdown時に自動的にLOGOFFコマンドを実行させることが可能です。 ブート時に渡すカーネルパラメーターの指定は、/etc/zipl.confで行います。 parameters="root=/dev/dasda1 dasd=fd87 vmpoff=LOGOFF" 上記のように/etc/zipl.confを修正後、ziplコマンドで変更を反映させておく必要があります。 次回Linuxブート時よりvmpoffパラメーターが渡され、"init 0"、"shutdown -h now"、"halt p"、"poweroff"によりshutdownした後、自動的にLOGOFFされるようになります。 Q.Linuxに対応した3270エミュレーターはありますか？ A.TLES8には、x3270が同梱されております。 x3270はXwindow環境で3270端末として使えるオープンソースの3270エミュレータで、標準的な手順でTLES8をzSeriesに導入しますと、x3270も導入され、すぐに使える状態 になっています。zSeries上に限らず、IA32(Intel)用TLES8にも同梱されております。ただし、3270画面での日本語の入力・表示がサポートされておりませんのでご注 意ください。 もし、3270で漢字も使用されるということでしたら、WebShpere Host on-Demand V7.0以降(IBM Host Access Client Package for Multiplatform に同梱)をTLES8 8 9 10 11 1a9c0e3b-44a0-4942-afbf-67b9d5bff7a7.xls 10/31/2008 運用監視 12 Q.DFDSSでDUMP/RESTOREする場合、FULL DUMP/FULL RESTOREを計画していますが、物理処理以外に、論理処理も有効でしょうか？ A.Full Dump/Restore以外に、Linuxのパーティション単位でのDump/Restoreが可能です。 ただし、LinuxボリュームのフォーマットがCDL形式の場合に限ります。 VTOC形式をサポートするLinuxボリューム（デフォルト）のフォーマットはCDL(Compatible Disk Layout)と呼ばれ，z/OSからオンラインをかけた場合，以下のようなデータセットに見えます。 ネーミング・ルール LINUX.Vvolid.PART000n.NATIVE (Linuxファイルシステム: ext2, ext3, ReiserFS, JFSなど, n=1,2,3) LINUX.Vvolid.PART000n.SWAP (スワップ用ファイル・システム, n=1,2,3) したがって、データセット単位でのDump/Restoreが可能です。 Q.ｚ/OSからDFDSSでDUMPする場合、ALLDATA、ALLEXCPを指定する方が良いですか？また、その他のサブパラメータも扱いはz/OSと同様でよいですか？Linu xであるがゆえに使用できないパラメータなどあれば教えてください。 A.ALLEXCPの指定が必須です。 ALLEXCPを指定しなかった場合、z/OSから見てデータセット/パーティションが未使用の領域とみなされDUMPされません。その他のパラメーターに関しては、特に使 用できないものはございません。 Q.volume障害時、DASD再配置などの場合はDUMP元のボリュームではなく、別のアドレスのボリュームにCOPYVOLIDでRESTOREする必要があります。 IOCPでzLinux区画に割り振られているアドレス範囲であれば、RESTORE先をDUMP元とは異なるアドレスのボリュームにして大丈夫ですか？ またこの様な場合にzLinux側で変更しなくてはならない定義はありますか？ A.異なるアドレスのボリュームにRestoreすることは可能ですが、それを正常にブートさせるためにはLinux on zSeries側で変更が必要になります。 Linux on zSeriesは、Linuxブート時にロードするDASDモジュールのパラメータを/etc/zipl.confの中でdasd=xxxx(xxxxはアドレス)の形で指定します。また、ここで 指定した値を反映させるために、ziplというコマンドを実行する必要があります。 このため、異なるアドレスにRestoreした場合にやらなければならない作業として、 １．/etc/zipl.confの中のdasd=xxxxをRestore先のアドレスに変更する ２．ziplコマンドを実行し、変更内容を反映させる この２つの作業がRestore後に必要になります。 しかし、ResotreしたLinuxはRestore直後はブートしないため、上記2つの作業をすることができません。 この作業をするためには、すでに稼動している別のLinuxにResotreしたボリュームをマウントし、そこで行うことになります。 例) アドレス1000番のLinuxボリュームのバックアップを、2000番のボリュームにRestoreした場合 すでに稼動している別のLinux on zSeries上で以下の作業を実施します。(このLinux区画に2000番のアドレスが割り振られている必要があります) ①2000番のDASDを動的に追加します。 # echo "add device range=2000" > /proc/dasd/devices /proc/dasd/devicesの中を参照し、2000番のDASDが/dev/dasd?に割り当てられたのか確認します。 ②DASDをマウントします。(マウントポイントはどこでもかまいません） # mount /dev/dasd?1 /mnt ③ 2000番のDASDの中の/etc/zipl.confを変更します。(1000 → 2000) # vi /mnt/etc/zipl.conf ④ ルートディレクトリをマウントした先へ変更します # chroot /mnt ⑤ ziplを実行し、変更を反映します。 # zipl ⑥ ルートディレクトリを元に戻します。 # exit ⑦ アンマウントし、DASDを開放します。 # umount /mnt # echo "set device range=2000 off" > /proc/dasd/devices ここまでの作業を終えることで、2000番のDASDをIPLすることができるようになります。 13 14 15 16 Q.DUMP/RESTOREに関して考慮点はありますか？ A.DUMP取得は、Linux on zSeriesをshutdownしてから行うようお願いします。 Q.Linuxのリソース使用状況の調査方法について教えてください。 A.Linux on zSeries側でのリソースの使用状況の調査とその評価についてお答えします。 1) 調査項目 主に調査する項目としては以下のような項目があげられます。 CPU使用率 メモリ（ストレージ）使用率（ページングの発生頻度、スワップ使用状況など） ディスク（DASD）使用率 ネットワーク･デバイス使用状況（秒あたりの送受信量など） 2) 調査ツール Linux on zSeries上で使用できる代表的なツール（コマンド）としては以下のようなものがあります。 top リアルタイムで各プロセスのCPU使用率、メモリ使用率およびシステム全体のメモリ使用状況、スワップ使用状況を表示 free メモリの使用状況の表示 df ディスク（DASDなど）の使用状況を表示 vmstat メモリ、スワップ、ディスクI/O、CPUの使用状況を表示 iostat ディスクI/Oの状況を表示(*) mpstat CPU使用状況を表示(*) sar CPU、メモリ、スワップ、ページング、ディスクI/O、ネットワークの各使用状況などを収集･表示(*) procinfo procファイル･システムよりCPU、メモリ、スワップの使用状況などの情報を収集して表示 (*)がついているコマンドはsysstatというパッケージに含まれているコマンドです。 また、procファイル･システムを見ることにより、システムの状況が分かります。 /proc/meminfo メモリ使用状況を表示 17 Q.vmstatのIO(bi,bo)フィールドは、IO WAITを含んだ1秒あたりのI/O転送量ではないのでしょうか？ iostatのavgrqszフィールドは、IO WAITを含む平均レスポンス時間になりますでしょうか？ A.vmstatのbi,boフィールドは、ブロックデバイスに対する単位時間あたりのI/O転送量(blocks/sec)を意味します。 この値は、プロセス単位で計算されるものではないため、I/O WAIT等は考慮されません。 iostatのavgrq-szフィールドはデバイスごとのI/Oリクエストの平均サイズを意味します。 したがって平均レスポンス時間にはなりません。 Q.Linux上でI/O waitを取得する方法について教えてください。 18 1a9c0e3b-44a0-4942-afbf-67b9d5bff7a7.xls 10/31/2008 A.vmstatで可能です。 vmstatコマンドの出力結果は以下のようになります。 procs memory swap io system cpu r b w swpd free buff cache si so bi bo in cs us sy id 1 0 0 0 6388 45964 53056 0 0 22 3 0 13 1 2 97 この中で、procsの下のbが割り込み不可能なスリープ状態にあるプロセス数を意味し、これがI/O待ちの状態にあるプロセスを表しています。この数が増えていくようで すと、I/Oになんらかのボトルネックがあるということが推測できます。 また、topやpsでも同様の情報を取得することが可能です。 topの場合、出力結果の中のプロセスの状態を表すSTATが'D'となっていますとそのプロセスは割り込み不可能なスリープ状態になっていることを意味します。 > top PID USER PRI NI SIZE RSS SHARE STAT %CPU %MEM TIME COMMAND 23178 root 20 0 5136 5136 1336 R 82.9 4.0 0:04 mrtg 23175 kubo 9 0 1196 1196 996 R 1.3 0.9 0:00 top 10 root 9 0 0 0 0 SW 0.1 0.0 0:54 kjournald 1 root 9 0 548 548 484 S 0.0 0.4 0:02 init 2 root 9 0 0 0 0 SW 0.0 0.0 0:00 kmcheck 3 root 9 0 0 0 0 SW 0.0 0.0 0:00 keventd 4 root 19 19 0 0 0 SWN 0.0 0.0 0:00 ksoftirqd_CPU0 5 root 9 0 0 0 0 SW 0.0 0.0 1:49 kswapd 6 root 9 0 0 0 0 SW 0.0 0.0 0:00 kreclaimd 7 root 9 0 0 0 0 SW 0.0 0.0 0:00 bdflush 8 root 9 0 0 0 0 SW 0.0 0.0 0:05 kupdated 9 root -1 -20 0 0 0 SW< 0.0 0.0 0:00 mdrecoveryd 374 root 9 0 632 632 536 S 0.0 0.5 0:04 syslogd 379 root 9 0 876 876 484 S 0.0 0.6 0:00 klogd 393 rpc 9 0 564 564 472 S 0.0 0.4 0:00 portmap 415 rpcuser 9 0 680 680 584 S 0.0 0.5 0:00 rpc.statd 513 root 9 0 896 896 760 S 0.0 0.7 0:11 sshd psの場合も同様に、STATが'D'となっていますとそのプロセスが割り込み不可能なスリープ状態になっていることを意味します。 >ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.4 1408 548 ? S Sep12 0:02 init root 2 0.0 0.0 0 0 ? SW Sep12 0:00 [kmcheck] root 3 0.0 0.0 0 0 ? SW Sep12 0:00 [keventd] root 4 0.0 0.0 0 0 ? SWN Sep12 0:00 [ksoftirqd_CPU0] root 5 0.0 0.0 0 0 ? SW Sep12 1:50 [kswapd] root 6 0.0 0.0 0 0 ? SW Sep12 0:00 [kreclaimd] root 7 0.0 0.0 0 0 ? SW Sep12 0:00 [bdflush] root 8 0.0 0.0 0 0 ? SW Sep12 0:05 [kupdated] root 9 0.0 0.0 0 0 ? SW< Sep12 0:00 [mdrecoveryd] root 10 0.0 0.0 0 0 ? SW Sep12 0:54 [kjournald] 19 Q.フォルダ／ファイルへのアクセス状況を確認できるようなコマンド、方法はありますか？ A.ファイル/ディレクトリへのアクセス状況を確認するためのコマンドはありませんが、/proc/から情報を拾うことは可能です。 /proc/(プロセスID)/fd/以下にそのプロセスがアクセスしているファイルの情報を取ることが可能です。 また、/proc/(プロセスID)/environの中のPWDや/proc/(プロセスID)/cwd からそのプロセスが現在いるディレクトリを知ることができます。 これらの情報から特定のファイル/ディレクトリに対するアクセス状況を確認できる仕組みを作ることは可能だと思われます。 1a9c0e3b-44a0-4942-afbf-67b9d5bff7a7.xls 10/31/2008 ストレージ 20 Q.Linux間でのDASD共用はどのようにして行うのでしょうか？ A.DASD共用には以下の方法があります。 - EMIFによりIOCDS内でSHAREDに定義することで複数LPAR間で物理的共有が可能 - VM上ではCP LINKによりRR/MR/MWなどで共有可能。Fullpack, minidisk単位 - VM minidiskの場合には、minidiskキャッシュが有効 - VDISK(RAM Disk)もminidisk同様に複数Linuxイメージ間で共有が可能 いずれのケースもLinuxのファイル･システムのレベルではRead-Onlyでの共用のみ可能となります。 Q.DASD共用時の排他制御はどうなりますか？ A.基本的にLPAR間でDASDを共有した場合、排他制御は行われません。 したがって、2つのLinux区画から同時にディスクをマウントした場合、そのディスク上のデータは破壊されてしまう危険性があります。 しかし、DASD driverにreserve/releaseの機能が実装されており、それを使えば排他制御をすることは可能です。 reserve/releaseを行うためには、以下のDASD IOCTLを用いることになります。 DASD ’reserve’, ’release’ and ’unconditional reserve’ functionality is implemented using the DASD IOCTL interface: - BIODASDRSRV - to reserve a device - BIODASDRLSE - to release a device - BIODASDSLCK - to reserve a device even if it was already reserved by someone else (steal lock) "Device Drivers and Installation Commands"(http://www10.software.ibm.com/developerworks/opensource/linux390/index.shtml)より抜粋 ただし、Linuxコマンド等を用いて容易にreserve/releaseができるわけではありませんし、OSが自動的にしてくれるわけでもありません。 アプリケーション側でDASD IOCTLを使用し、reserve/releaseを行う仕組みを作る必要があります。 現在、このreserve/releaseの機能を使用しているのがTivoli SAになります。(quorum領域へのアクセス、等) Q.カーネル2.4からサポートされたVTOCサポートについて教えてください。 A.VTOCサポートによりz/OSからLinuxボリュームをONLINEにすることが可能になりましたが、このときz/OS側からはボリュームの各パーティションがデータセットに 見えるだけで、その内部まで見ることはできません。あくまでデータセット(パーティション)単位でのdump/restoreができるだけです。FTPのようなLinuxのディレクトリ・フ ァイルに対する操作をすることはできません。 ですので、VTOCサポートはz/OS側からのバックアップのために利用されます。 21 22 23 24 Q.ESSのカスタム・ボリュームをサポートしますか？ A.サポートします。 Q.Linux on zSeriesのFCP接続のサポート状況を教えてください。 A.zSeriesにおけるFCP接続のサポート状況については下記URLで確認することができます。 http://www-1.ibm.com/servers/eserver/zseries/connectivity/ 2004/01/30時点でのサポート状況は以下の通りです。 25 26 Q. 3380-Kをdasdfmtした場合には、4KBのブロックが幾つ作成できて、どれだけの容量を使用することができるのでしょうか？ A.3380-Kを4KBブロックでフォーマットした場合には、398250個の4KBブロックができ、約1.6GBの容量をLinuxにて使用できます。 3380型は4KBブロックが1 track当り10個、3390型では1track当り12個ですので、それにcylinder当りのtrack数とcylinder数を掛ければ算出できます。3380K以外のモデルや4K以外のブロックサイズ等の詳細な情報については、IBM DASD Product Information Bucket(RTA00013792)をご覧ください。 ただ、実際には1ブロックが4KBということは、例えば1バイトのファイルを作成しても4KBを使用してしまうということからも容易に想像できますとおり、3380Kで1.6GB分のデータが必ずはいるということではございませんのでご注意ください。 Q.使用していたdiskを切り離す際にはbootのパラメーターはどの様にすればよろしいでしょうか? A.bootのパラメーター(dasd=xxxx)としては、使用するDASDのみ指定していただいてかまいません(dasd=100103,110,111)が、それ以外の変更点として、/etc/fstabを修正する必要があります。 Linux boot時にどのディスクをどのディレクトリにマウントするかは、/etc/fstabの内容から決定されます。例えば、/etc/fstabの中が /dev/dasda1 / ext3 defaults 1 1 # 100 /dev/dasdb1 /mnt/datab ext3 defaults 1 2 # 101 /dev/dasdc1 /mnt/datac ext3 defaults 1 2 # 102 /dev/dasdd1 /mnt/datad ext3 defaults 1 2 # 103 /dev/dasde1 /mnt/datae ext3 defaults 1 2 # 104 /dev/dasdf1 /mnt/dataf ext3 defaults 1 2 # 105 /dev/dasdg1 /mnt/datag ext3 defaults 1 2 # 110 /dev/dasdh1 /mnt/datah ext3 defaults 1 2 # 111 となっている状態で、zipl.confの"dasd=100-105,110,111"を"dasd=100-103,110,111"に変更した場合、Linux boot時に、110が/dev/dasdeに、111が/dev/dasdfに割り当てられてしまい、/dev/dasdg,/dev/dasdhが無くなってしまいます。このため、/etc/fstabの内容から/dev/da sdg1を/mnt/datagにマウントしようするところでエラーとなってしまいます。 また、110のDASDは元々/mnt/datagにマウントされていたものが、/mnt/dataeにマウントされてしまうため、110のDASDにあるデータへのアクセスパスが変わってし まう(/mnt/datag/aaa.txt→/mnt/datae/aaa.txt)という問題も発生します。 zipl.confのパラメーター"dasd=xxxx"を変更することで、それぞれのDASDにどのデバイスファイル(/dev/dasdx)が割り当てられ、それがどこのディレクトリにマウントさ れるのか、を考慮した上で、/etc/fstabの方も修正する必要があります。 上記例から104,105を取り外したとき、マウントポイントも変わらないように正常bootさせるためには以下のように/etc/fstabを修正することになります。 /dev/dasda1 / ext3 defaults 1 1 # 100 /dev/dasdb1 /mnt/datab ext3 defaults 1 2 # 101 /dev/dasdc1 /mnt/datac ext3 defaults 1 2 # 102 /dev/dasdd1 /mnt/datad ext3 defaults 1 2 # 103 /dev/dasde1 /mnt/datag ext3 defaults 1 2 # 110 /dev/dasdf1 /mnt/datah ext3 defaults 1 2 # 111 Q.Linuxブート時にTAPEを認識させるにはどうすればよいですか？ A.Linux boot時にtape moduleをロードする方法はいくつかあります。 1.カーネルにtape module(tape390.o)を組み込む 2.tape moduleをloadするinitrdを作成し、それを用いてbootする 3./etc/init.d/boot.localに"insmod tape390 tape=xxxx"を記述し、boot時にinsmodコマンドを実行させる 上記、１と２の方法を用いる場合、カーネルパラメーターの"tape=xxxx"が必要になります。 3つの方法のどれを用いてもかまいませんが、3番の方法が一番簡単で、元に戻すことも容易であるため、3番をお勧めいたします。 Q.tarを使用して3490TapeにWriteした場合にTapeをまたがってWriteすることは可能ですか？ 27 28 1a9c0e3b-44a0-4942-afbf-67b9d5bff7a7.xls 10/31/2008 A.A1) 可能です。 tarコマンドにはマルチボリューム用のオプションが用意されています。 -M, --multivolume マルチ・ボリュームのアーカイブの作成/一覧表示/抽出を行なう これを用いることで複数のテープにまたがってWriteをすることが可能になります。 手順はつぎのようになります。 1.テープを挿入します。 2.必要があれば以下の操作をします >mt -f /dev/ntibm0 rewind >mt -f /dev/ntibm0 erase >mt -f /dev/ntibm0 rewind 3.別のTelnetセッションを開き/var/log/messagesを監視します。 >tail -f /var/log/messages 4.最初のTelnetセッションでtarコマンドを実行します。 >tar -cvMf /dev/ntibm0 / --exclude /proc 5.もっとテープが必要な場合は、以下のメッセージを返します。 ボリューム #2 (`/dev/ntibm0') を準備します. リターンキーを押してください: このメッセージが表示されたら、3つ目のTelnetセッションを開き、以下のコマンドを実行します。 >mt -f /dev/ntibm0 off コマンドを実行すると、2つ目のセッション(/var/log/messages)に以下のメッセージが表示されます。 Sep 18 11:45:12 linux2 kernel: T34xx:The drive is not ready. Maybe no medium in? 6.次のテープを挿入します。(auto loaderの場合、自動で次のテープが入ります) 7.2つ目のセッションで以下のメッセージが表示されるのを確認します。 Sep 18 11:47:28 linux2 kernel: T34xx:A medium was inserted into the tape. 確認したら一つ目のセッションでEnterキーを押し、tarの処理を続けます。 (必要があれば、Enterキーを押す前に上記２の操作を行います。) バックアップが終了するまで5～7を続けます。 Q.ESSのPAVは使えますか？ A.Linux on zSeriesのDASDデバイス・ドライバーはPAVボリュームをサポートしないため、LPAR環境で稼動するLinuxではPAVは使用することはできません。 しかし、z/VMはPAVをサポートします。 z/VM上で稼動するLinuxでPAVを使用する場合は、LVMのマルチパス機能を使ってPAVボリューム対応が可能です。 LVMマルチパス機能をサポートするのはTLES8のみになります。 また、これは技術的にPAV使用が可能であるだけで、正式にサポートはされませんのでご注意ください。 29 1a9c0e3b-44a0-4942-afbf-67b9d5bff7a7.xls 10/31/2008 ネットワーク 30 Q.Linux on zSeriesでCLAW対応のCPA、CIPは対応ネットワークデバイスとしてディストリビューションに含まれている（あるいは対応している）のでしょうか？ A.Linux on zSeriesでCLAW対応は以下の状況です。 （１）UTS Global社 UTS Global社のCLAW driverが最も有名です。 http://www.utsglobal.com/ （２）IBM developerWorks 2002年9月に対応済み(experimental)。 http://www10.software.ibm.com/developerworks/opensource/linux390/exp-2_4_19-may2002.shtml#claw-2.4.19_20020913 ディストリビューションから見て整理すると、以下のようになります。 Turbolinux6.5アップデートキット（営業活動終了済み）では別料金でCLAWサポートCDがありました(CLAWによるインストールも可能)。 SLES7やSLES8(=TLES8)およびRedhat7.2では、インストール時にCLAWの選択は不可ですが、前出（１），（２）のドライバーを入手してCLAWを利用することは可 能。 SLES8(=TLES8)にはCLAW driverはカーネルソースとして含まれていますが、これを利用するためにはカーネルのリコンパイルが必要になります。 RHEL3ではインストール時にCLAWの選択は不可ですが、導入後はカーネルリコンパイルなしでUTS GlobalのCLAW Driver(c7000.o)を利用できます。 31 Q.VMのGuestとして稼動しているLinuxからGuest LANに接続する際に、aliasとして「hsin」という名前を使用しているのですが、これを別の名前(具体的には「ethn」で代用することは可能でしょうか？ A.ipコマンドでインターフェース名の変更が可能です。具体的には以下のようにします。 linux:~ # ifconfig hsi0 hsi0 Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet addr:172.18.3.111 Mask:255.255.255.0 ...(省略)... linux:~ # ifconfig hsi0 down linux:~ # ip link set hsi0 name eth1 linux:~ # ifconfig eth1 eth1 Link encap:Ethernet HWaddr 00:00:00:00:00:00 inet addr:172.18.3.111 Mask:255.255.255.0 ...(省略)... Linuxを再起動するともとに戻りますので、常に変更した状態にしたい場合は/etc/init.d/boot.localでipコマンドを自動的に発行させるなどの設定が必要です。 Q.マニュアル「OSA-Express ユーザーズ・ガイドおよび解説書 資料番号 SA88-8516-01」 を参照しましたところ、QDIOモードの場合は、OAT(OSAアドレステーブル)が自動的に生成されると書かれていました。 Linux区画（LP8）についても、Linux on zSeriesでIPアドレスの設定を済ませれば、OATを自動生成してくれると考えてよろしいでしょうか？ A.はい。この場合、Linux on zSeriesでIPアドレスの設定を行うとOATが自動生成されます。 Q.TCPバッファとして指定できる最大サイズを送受信それぞれについて教えてください。 A.TCPバッファサイズの上限を定めるsysctl変数 net.ipv4.tcp_rmemやnet.ipv4.tcp_wmem自身は符号なし32bit変数で構成されますので2^321まで指定可能です。もちろんカーネルが使用可能なメモリサイズや、net.ipv4.tcp_memが定めるTCPネットワーキング用メモリサイズの上限以下でなければなりませ ん。 Q.SNMPを使ってOSAを監視する場合、OSAカード単体でSNMP AGENTになることはできますか？ ＶＭ上のヴァーチャルマシンとしてのSNMPD、もしくは、Linux on zSeries上のsnmpdを使うことにより、SNMP AGENTになることが可能となりますか？ A.OSAカード自身にはそのような機能はありません。 Linux on zSeries上で、snmpdとosasnmpdを動かすことで可能になります。osasnmpdはsnmpdのsubagentとして稼動し、OSAカードの状態を定期的にsnmpdに通 知します。 Q.VCTCデバイスを追加設定する方法を教えてください。 A.Under VMで、複数のVM USERとして動作するLinux on zSeriesの間をネットワークで接続する方法は、いくつかあります。OSA経由、ESCONCTC接続、VirtualCTC接続(VCTC)、IUCV接続などです。この中で、VCTCとIUCVは物理的配線やIOCP等の別途の定義が不要でありソフト的な接続です。 VCTCをVM上で定義するには、そのVirtual Machine上でCPコマンド発行により定義が可能です。あるいは、CP DIRECTORYの定義(USER DIRECT)でSPECIALステートメントにより定義できます。 以下にLINUX1とLINUX2というVirtual machine間で接続するための定義例を示します。この例では、9000/9001というvirtual addressでそれぞれCTCAを定義し、カップルをつくります。 1-a) CPコマンドで定義する場合には、 LINUX1上で、 LINUX1> CP DEF CTCA 9000 LINUX1> CP DEF CTCA 9001 LINUX2上で、 LINUX2> CP DEF CTCA 9000 LINUX2> CP DEF CTCA 9001 LINUX2> CP COUPLE 9000 LINUX1 9000 LINUX2> CP COUPLE 9001 LINUX1 9001 1-b) USER DIRECTORYで定義する場合には、 MAINT> USER LINUX1 ... MAINT> SPECIAL 9000 CTCA LINUX2 MAINT> SPECIAL 9001 CTCA LINUX2 MAINT> MAINT> USER LINUX2 ... MAINT> SPECIAL 9000 CTCA LINUX1 MAINT> SPECIAL 9001 CTCA LINUX1 CPで以上のような定義がなされている上で、Linux on zSeriesをIPLしますと、3088装置としてこれらのアドレスがセンスされます。Marist CollegeのコードではCTCドライバーはkernel内に含まれておりましたが、TurboLinux for S/390やSuSE Linuxでは、CTCドライバーがkernelモジュールから追い出されてデバイスドライバーとして存在しているため(これはkernelをビルドするときに選択され ます）、CTCドライバーを以下のようにロードする必要があります。 LINUX1> insmod ctc ctc=0,0x9000,0x9001,ctc0 LINUX2> insmod ctc ctc=1,0x9000,0x9001,ctc0 これによりctcモジュールがロードされ初期化されて、CTCが認識されます。次に、IPアドレスの設定等を行い、TCP/IPネットワークを使えるようにしま す。 LINUX1> ifconfig ctc0 192.168.0.1 pointopoint 192.168.0.2 mtu 1500 LINUX2> ifconfig ctc0 192.168.0.2 pointopoint 192.168.0.1 mtu 1500 以上により、LINUX1とLINUX2の間で、VCTCによりTCP/IPが接続されます。 なお、ctcドライバーをIPL時にロードさせるためには、/etc/modules.confにalias定義を、/etc/chandev.confにパラメータを追加します。また、/etc/syscofi Q.1バーチャルマシン上における、最大のIUCV接続数は幾つでしょうか？ A.1バーチャルマシン当たりの最大IUCV接続数は、USER DIRECTORY中のそのVM UserのOPTION MAXCONNにより設定されます。指定がない場合のデフォルト値は64であり、最大数は65535です。 USER DIRECTORYのUSERセクション内にOPTION指定しますので、IUCV接続上限としてのMAXCONNは、USER単位ということになります。 IUCVはz/VMワイドでの上限というものは特にございませんが、VM USER間でのメッセージングビークルですので、それぞれのUSER(バーチャルマシン)内でCTRL Blockやバッファが確保されますので、Virtual Storage Sizeなどのリソースによる制限を受ける可能性はあります。 32 33 34 35 36 1a9c0e3b-44a0-4942-afbf-67b9d5bff7a7.xls 10/31/2008 ｚSeries 37 Q.１つのIFLを複数の区画のLinux on zSeriesから使用する場合，標準CPの場合と同様に各区画への重み付けの設定は必要でしょうか？（NOT　DEDICATEDに設定します） また　専有・非専有を変更したり、重み付けの値の変更作業はLinuxが稼動中に可能でしょうか？ A.デフォルトではすべてのLPARに対して同じWeight値が設定されています。 標準CPと同様、必要に応じてWeight値を変更することになります。 動的に変更可能なのはTask List "CPC Operational Customization"の中の"LPAR Control"で設定可能なものに限られます。ですので、各LPARに対するWeight値は動的に変更可能ですが、専有・非専有を動的に変更することはできません。 この場合、Activateの処理が必要になります。 Q.Linux用のLPARを複数作成しますが、CPU H/W Capping、及びCPU Weightの設定は可能と考えておりますが正しいですか？また可能な場合、これら機能はS/390プロセッサーとIFLでは影響することはない。つまり2IFLでのCapping、 Weight制御と考えて正しいですか？ A.IFLを割り当てたLinux用LPARで、CappingおよびWeight設定は可能です。 この機能は、S/390プロセッサー(CP)とIFL(ICP)ではLPARで共有できないため、CPはCPのみで、ICPはICPのみでLPARを構成しますので、CappingやWeight制御 については影響することはありません。IFL(ICP)をnot dedicatedで共有定義できるLPARは、IFL(ICP)を定義するLPARのみとなります。 Q.メモリーのDSR機能は、Linux区画でも使用可能ですか？ また2064プロセッサーにおいてz/OSを稼動させる場合とIFLでLinuxを稼動させる場合で、機能的に違いがあれば教えてください。 A.DSRサポートについては、Linux区画ではサポートされておりません。 z900 PR/SM Planning Guide (SB10-7033)のChapter 3のDSRの記述で、Linux用LPARでDSRがサポートされていないことが明記されております。 なお、もしz900でDSRがサポートしたとしても、Linux kernelがメモリーの動的な増減をサポートする必要があります。Linux kernelとしては、稼働時のメモリー増減はkernel2.6にて対応予定であり、現時点ではre-IPLが必要となります。 Q.VMの場合は、USER DIRECTORYに記述することは知ってますが、LPARに直接の場合はIOCP等で定義したESSのディスクやOSA-EのUnit AddressをLinux側から認識（紐付け）させるのはどのようにして行っているのでしょうか。 A.LPAR上でLinux on zSeriesを稼動させるのであればIOCPなどで定義したデバイスのアドレスをLinux on zSeries（そのデバイス・ドライバー）が直接認識できます。z/VMの場合は定義などによりIOCPで定義したアドレスを別のアドレス、つまり仮想的なア ドレスにしてユーザ（仮想マシン）に割当てることもできるのですが、LPARでLinux on zSeriesを直接稼動させる場合はIOCPで定義したアドレスをそのまま使用するということになります。デバイスのアドレスを変更するのであればIOCPな どによりその定義を変更する必要があります。（つまり、Linux on zSeriesの導入時にインストーラーなどにより物理的にデバイスのアドレスを変更することは不可能です。） Q.CP共用時の考慮点について教えてください。 A.物理CPUの数より論理CPUの数が多い場合は時分割による物理CPUの取り合いが発生しますので、その分オーバーヘッドがかかってしまいます。 このオーバーヘッドは物理CPUの総数と論理CPUの総数の差に依存します。論理CPUの総数が物理CPU数の3倍以下になるようなデザインをすることを推奨いたし ます。 Q.ＯＳ/３９０の区画間であれば、ＥＭＩＦでＥＳＣＯＮチャネルはシェアできますが、ＯＳ/３９０とＬｉｎｕｘ区画間では可能ですか？ A.ESCONチャネルの共用はEMIFの機能ですので、Linuxとしてはシェアすることについては可能です。しかし、DASDの共用で操作ミスによりLinuxからOS/390のDA SDをフォーマットしてしまう等の可能性もありますので、シェアする場合には注意が必要になります。 Q.ＯＳＡファーストイーサネットアダプターはＯＳ/３９０とＬｉｎｕｘ区画間ではシェアできますか？ A.OSA-Express FastEthernetについても、EMIFによりLPAR間でシェアすることが可能です。 Q.パラレルチャネル接続の3172はサポートされますか？ A.ディストリビューションでサポートされないため、Linux on zSeriesに関しては使用できません。 38 39 40 41 42 43 44 1a9c0e3b-44a0-4942-afbf-67b9d5bff7a7.xls