nakapachi blog

という企画のデモを担当させていただきました。デモ担当兼１ブロガーとして参加させていただきました。

この企画、facebookとTwitterのみで集客してしまったという企画。今までではありえないですね。

普通はセミナーできちんと台本作ってレビューしてみたいな感じでやるものですが、それもなし（笑）

私自身メインフレームにかかわって２０年になります。

実はメインフレームLinux(z/Linux)が誕生してすぐにUSの大学がz/Linuxのディストリビューションを早速入手し、当時の会社のメインフレームに入れて研究をしてました。

当時のz/Linuxってとにかく遅い。というのが第一印象。会社で見せたら酷評でしたね。

私自身も代理店としてどう売るのかはっきり言ってよくわかりませんでした、なのでいろんな研究を片手間でやってました。

私自身、ある時はIBM代理店でメインフレームを売って歩いたり、ユーザー企業（金融機関）で逆の立場だったりしたこともあります。

実際に金融機関に在籍していた時はサーバーで行くのかメインフレームで行くのかというコストシミュレーションを行った結果、結局メインフレームにしたということもありました。

なので、使う立場の方の先入観というのは非常によくわかります。

今回の企画はメインフレームは古いという日本では一般的な常識を覆してしまおうという企画の一環です。

実際にいらっしゃった方にもそういう感覚を持っていらっしゃる方もいました。

この前段としてブロガーミーティングがあり、今回のメインフレームを見に行こうという企画になりました。

まぁ、いろいろ議論はされていると思ったので、レガシィーな部分と新しい部分をいっぺんに見せてしまえということで実際にデモンストレーションを行いました。

レガシィーとやり玉にあがるCOBOLのソースを3270で見せつつ、かたやz/Linuxを実際にブートして、Xwindowまで見せてしまおうという。

ホントは最近安定版が出た、QEMUという異プラットフォームでソフト的にエミュレーションしてしまうものを使って、Windowsとかknopixという奥の手も用意はしてました。

これはここ最近のテーマでした。

ユーザー企業では、メインフレーム系と分散系という風に組織が分断されている場合が多いです。

その垣根をあっけなく超えてしまうのがIBMのメインフレームでしょうか。

私は以前にこんな遅いLinuxでサーバー集約なんてできるわけがないと思ってました。

なんか売り方はないのかといろいろ検証をしてました。

当時のメインフレームとIAサーバーに同じjavaアプリを搭載して多重でJDBCでDBにinsertしまくるというテストを行いました。

その結果、パフォーマンスはIAに軍配が上がりますが、多重度を上げてゆくとIAはinsert件数に非常にばらつきがあり、ある時点で落ちてしまいました。

一方、z/Linuxはパフォーマンスはそれなりだったが多重度を上げていっても安定したinsert件数がでたという結果になりました。

これをもう少し分析してみるとコンテキストスイッチが非常に早く、IAの1/10でした。

確かにハイパフォーマンス物にはz/Linuxは向いてません。ただ、データベースなどの安定的にたくさんさばくというのには非常に向いています。

サーバー集約もこの恩恵を受けて、統合が可能であるという結論になりました。

今は単体性能も上がったので集約もできてパフォーマンスも期待できるとこまで来ました。

そもそもこのz/LinuxってドイツのIBMの若いエンジニアが夏休みになんとなく移植したらできちゃったという代物らしいです。

MVS屋さんとしてはこういう風になるとは予想もしてなかったですが。

今回の企画が日本の方に浸透してゆけばよいなーと感じました。

以前mixiのコミュに掲載してたのですが、ここにも。

結構W/Wは面白いねー。

http://youtu.be/0i7kBnhN3Lg

これは４０年前のメインフレーム屋さんが現代にタイムスリップしたらという内容。

http://youtu.be/iaENdDQ0RH4

こちらはzがベビーシッターっていう・・・・。

なかなか日本では発想できないですね。

z196+RHEL6.1の稼働検証を行いました。
微妙にインストーラーが変わってますが、RHEL6.0とほぼ同じでした。

よくDVDないんですか？って聞かれますが、あるわけがない。

今回は、vncで外からつないでKDEを使ってみました。
SLESだとこの辺は自動的に入りますが、RHELは自分で・・。
yumでインストールします。

yum install Packge名で個々のパッケージは入れられますが、yum grouplistで表示された、groupをgroup毎に入れられるのは知らなかった・・。

この辺は、z/Linuxといえど、Redhat系。ググるとすぐ出てきます。
SLESがあまりにオートマティックなのでRHELのほうが触っててLinuxだなーと思います。

これをやりながら、z/OS上のIMS V11の稼働検証を・・・。

z/Linuxでviをいじりながら、シェルを書きながら、IMSの生成をやって、FF/FPのトランザクションとBMPバッチのテストを並行でやるという・・。ある意味ハイブリッドを自でいってます。

個人的にはz/LinuxのWASからIMSのDEDBをいじくるというテストをしてみたい。
もちろん、DL/IのPGMを書き、Javaもコーディングし、な感じで。

ハイブリットってのはかなりニッチかもしれませんね。

これがよくわからなかった。

一応最新のメインフレームとIAマシンで円周率の計算、約１億桁という処理をやらせてみた。
結果はかけないが、IAの圧勝で終わってしまった。最近はIBMメインフレームでもクロック数というキーワードを出してきたので結構期待したのだが・・・。
確かにかなりのCPUインテンシブな処理である。IAのほうが非常に有利だと思う。

まぁLinuxという他のアーキテクチャと比較できる土俵があるので比較してみたくなる今日この頃。

実は８年位前にもjavaのJDBCを経由して、z/OS上にあるDB2に対してSQLでInsertしまくるというベンチマークをやったことがある。
この時もIAのサーバーとメインフレーム上のLinuxをそれぞれクライアントにして、比較した。
それそれCPUは１個で実験した。この時も１スレッドであればパフォーマンスでIAの圧勝となってしまう。
ただこの多重度を上げていくと、この時のvmstatを見ると相当なコンテキストスイッチが発生しているが、IAはスレッド毎のInsert件数が安定しない。z/Linuxはスレッドが増えても安定して処理をこなしている。

この理由は、IBM System zの特性が出ている。
コンテキストスイッチが非常に早いということ。コンテキストスイッチのオーバーヘッドがほぼないので安定しているといえると思う。

１スレッドの性能が遅いからと言ってサーバー統合できるわけないだろうと思ったのだが、こういう特性であればサーバーを統合して筐体でフルに性能を使っても安定しているということになる。
これを実現しているのは２つ。z特有のアクセスレジスターの存在とIO専用プロセッサーの存在。

今はIAサーバーでもかなり速いスピードが出てしまうので、単純にパフォーマンスを比較しても無意味かと。
統合しても安定した特性が出せるというのが、z/Linuxの特徴だと思います。

確かに基幹系で安定してスケールアップな統合をするならz/Linux、スケールアウトで行くならIAというところでしょうか？

どちらに優越はないと思います。

というのが最近の結論。

ただ、H/Wが壊れにくいとか安定してますとかだけだと知らない人からすると良くわからない。
アンチメインフレームな人からすると何がいいのかさっぱり理解できないと思う。

メインフレームって世代ごとで考え方が違うようで、５０代は俺たちが作ったぜ、４０代だとあの昔のものねと、２０代になると見たこともないし、知らないしーと思うようです。

コンピューターも適材適所というとこですね。

一応USなどでは一般的になってるそうです。
日本ではまずありえないですが、メインフレームが直接インターネットにつながっている場合もあるそうです。
日本では、専門の方がPTFをセレクションし、適用を行います。
その際にPTF適用情報として登録を行い、サポートセンターからPTFを媒体でデリバリーしてもらえます。

日本でもInternetからのPTF入手は可能です。
（ただし顧客先のサービスレベルによって異なる。私がなぜ入手できたかはさておき・・・）

まず手順ですが、
これもz/OS DVD導入と同じく、zFSにPTFを一度展開してから実際のPTFがReceiveされます。
同じくpax圧縮がかかっています。

まずはSMP/Eでbitmapと呼ばれる、プロダクト導入情報、PTF適用情報をリストします。
それを元に、Shop zSeriesでこのリストを添付し、特定のPTF、RSUを選択します。

これで自動的にPRE REQとなるPTFも自動的にチョイスされてインターネットでデリバリーされます。

あとはReceive/Applyを行えば、適用が可能になります。

私も緊急的にUnicodeにバグがあるのでいち早くほしいと言われつかいました。
意外に便利。
これからお取り寄せはこっちかな（笑）

まぁLinuxだとサポートに入ってると当たり前のようにInternetからパッチを入手できますがとうとうz/OSまで・・・。

便利になりましたね。

汎用機を昔からやっている人からは？？？でしょう。
汎用機といえばDASD！ですから（笑）

サーバーの世界では内蔵Diskがあって、外部Diskとして、FCP Diskを使うのがスタンダードです。

今どきのメインフレームで使うストレージはあくまで論理的に作り出したDASDで、この手のストレージはFCPDisk、DASDを混在して使うことも可能です。

今のSystem z　（IBM メインフレーム)にはFCP Diskが接続できて使えてしまいます。
こうなるとそこらのサーバーと全く変わらんという（笑）

厳密には昔からあったのですが、z/Linuxが出てきてからはかなりフューチャーされた感があります。

普通にFCP DiskからBoot(IPL)も可能です。これはサーバーでいうとこのSAN Bootですかね。

DASDだと今は主にFICONで接続されていて複数本のFICONで使用しても１本使えなくても動的にリカバリーをしてくれていて完全仮想化されているのであんまりマルチパスというのを意識しません。

ただ、FCP Diskを複数本のFCPでつなぐとほかのサーバーと同様、OS上でのMultipathでの制御となります。
使うドライバーもいたって一般的なSCSIドライバーを使うので、割とどんなFCP Diskともつながります。

体感的にはDASDよりFCP Diskのほうが早いですね。
DASDだと3390の型式に制約がかかるため、大規模な領域を作るのがかなりめんどくさいですが信頼性は高いです。
一方FCP DiskだとでかいLUNを作ってしまうとそれで終了なんですよね。

たまにz/Linux+OracleでDiskの構成ってどんなのがお勧めですか？と聞かれますが、
個人的には、それほどパフォーマンスは要求されないが信頼性が重要なところはDASDで作ってOracleのDBなんかはFCPDiskでとご提案しております。

Linux自体の信頼性も上がってきたので、大規模なLinuxサーバーとして使う価値は技術的にもありだと思います。

企業さんによっては、メインフレーム部門、サーバー部門と分かれているとこが多いですがここまで来ると垣根がないです。

この辺がまだ浸透してないのはもっと宣伝しないとだめですね（笑）

最近z/OS触っている方ならご存知でしょう。

z/OS(MVS)の中にUNIXが存在していることを。
しかもTelnetでつなげるという・・・。

割と前からあり、OpenMVSとも言われていました。最近は、Unix System Serviceとも呼ばれます。
z/LinuxでJavaが動くのは当たり前ですが、z/OSでもJavaが動きます。
ご丁寧にSDKまで用意されている。もちろんタダ。

これらはすべて、USS上で稼働します。

いわゆる、Unixでいうところのプロセスにあたる部分が、z/OS(MVS)の１アドレス空間して稼働します。
WASもこの仕掛けで動きます。

最近は導入とかもDVD、PTFもインターネットで入手できますが、これらはすべて、USS上のファイルシステムにおいて処理を行います。
ご丁寧にXMLをパースして適用するという・・・。
Javaがないと何もできなくなってしまいました。

この辺の領域になってくると国産メインフレームは太刀打ちできないですね・・・。

W/Wではこの辺あたりがかなり使われているようですが、日本ではやはり旧来のイメージが非常に強いですね。
COBOL/アセンブラ/3270の画面。この辺のイメージでしょうか？
Linuxが動いて、Javaが動いて、動かないのはWindowsくらいでしょうか？
z/LinuxだともちろんOracleも動きます。ご丁寧にRACまで組めます。

途中で放置してますが、Bochsというx86エミュレーターもコンパイルして移植するとかろうじて動きます。
FreeDOSは動きました。WindowsXPあたりになると、ちょっと厳しかったかな・・。

日本でももう少しメインフレームのイメージが変わるといいなと思います。

ここにきてまたトレンドなのかなーと思います。

ちょうどSystem zでLinuxは誕生して１０年になりますが、つい５年位前までははっきり言って遅くて使い物にならずに「これはいったいなんのメリットがあるんだろう」とずっと思ってました。

z10がでたあたりからこの辺が劇的に改善し、他社のハイエンドサーバーと同じくらいのパフォーマンスを出すようになりました。Linux自体もかなり進化しており、従来のUNIXをも肩をならべたのではないでしょうか。

System z（IBMメインフレーム)でLinuxを使うメリットがずっとわからずにいましたが、ここにきて理解ができました。
理由はSW保守費用の大幅な削減が可能であるということ。
おそらく100台以上のUNIXを使ってるあたりから、メリットが出てくると思います。

あとは仮想化でしょうか。なんたって元祖仮想化ですから・・・。
この辺はまだ優位性が崩れてないのも事実です。
仮想化でたくさんの仮想マシンを１台で動かしてもよほどのことがない限りスローダウンすることがありません。
（明らかにCPUやメモリーを相当使うサーバーを統合するとさすがに落ちます・・・）
これもメインフレームの特性。コンテキストスイッチが非常に早いのでこの辺もあまりボトルネックにはなりません。
コレのおかげでI/Oをたくさん使う処理でもスローダウンが少ない。
今までもこういう特性があったのですが、いかんせんCPUスピードが遅かったのですが、z10のアーキテクチャ変更からこの辺もクリア。
1台で仮想化マシンをたくさん立てて、筐体全体でかなりのCPUを使用してもスローダウンがあまり出ません。
仮想マシン間のCPUのスライシングも早いのが特徴です。
よってたくさんのUNIXサーバーを統合することが可能になります。
ということは実質的にCPU数が減るので、Oracleなどの保守料が結果的に減るというのが最大の利用価値ではないかと思います。

今はItaniumがかなり微妙なところです。大規模DBとしてのハイエンドサーバーとしての受け皿にもなります。
確かに今でもSystem zは旧来のレガシィーな使い方をする人もたくさんいます。
ただ、今まで全くメインフレームに縁がなかった人が使う機会も増えてきました。

ハイエンドUNIXの代替としてかなり存在感が増したというのが現状ではないでしょうか？

以前からやっております、Bochsのz/Linuxへのポーティング。
今回はレスキュー用のz/Linuxを作ったついでにやってみました。

http://ameblo.jp/nakapachi2/entry-10798176141.html

このエントリーの時は不発に終わりましたが、今回ある程度めどが立ちました。

今回はz196+SLES11SP1+Bochs2.4.6という組み合わせ。
Bochsって何？という方はこちらを。ちなみにBochsはBoxをもじったものだそうです。

http://bochs.sourceforge.net/

いわゆる、IA-32/64を完全にSWでエミュレーションしてしまうもの。
理論上は、どんなアーキテクチャーのLinuxでもエミュレーションができるはずだったのが１年近く苦戦をしている訳です。

SLES11SDKからx関連のdevel rpmも合わせて導入する必要があります。
コレを含めて、makeします。一応Fedora for s390xにはrpmがあるみたい・・。今回もOSが違うのでmakeから。

Compile optionはmarch=z10 としました。(SLES11SP1に含まれるgccがまだz196に対応していないため）

makeはあっけなく終了・・・。
特にエラーやワーニング類は一切なし。

早速Freedosのブートをしてみる。VGA周りでうまくいかない感じだった。
Bochs側のVGA設定周りを変えてみると、なんと、BochsのBIOS画面が出てきました。
おー。ここまでが長かった・・。
FloppyのFreedosのイメージをBootしてみる。いけますね。きちんとプロンプトも出ます。
一応IAエミュレートはうまく行っているようだ。

次はFreedosのCDimageからFreedosのDISKへのインストールと稼働確認。
まずは空のDiskImageを作成。次にFreedos ISOイメージファイルをマウント。
続いてBoot。コレも問題なし。インストールも問題なし。最後はDiskからBoot。コレも問題なし。

最終的にこの超個人的なプロジェクト（笑）何がやりたいかというとWindows XPをz196で動かしたい訳です。

というわけでWindowsXPのメディアをお借りしてInstallに挑戦。
あくまでトライアルでアクティベーションはやりません。

WIN XPのISOからBootしてみる。できます。インストールは途中までは進むようです。
ファイルをコピーするところでブルーバックです。しかも原因がバラバラ・・・。
WinXPからするとかなり異質な環境ではありますので・・・。

というわけでここまでは来ました・・・。

BochsのBIOS画面が出るようになったのは今までとは違う部分です。
おそらくx周りかな・・・と思ってまして今回はデバックをするつもりでしたがすんなり行ってしまいました・・・。

Freedosを使ってみた感じではさくさく動きます。z196だからでしょうか。
WINXPのインストールも途中まではさくさくいきます。エミュレーターの割には優秀ではないでしょうか。

またヒマがあったらやってみます・・。

GW前日からGW初日の朝までこの環境の準備をやってました。はっきり言って拷問。
まず、3390-3型のフォーマット。容量にして約1T程度で、いまどきアキバでも3TのHDDが売ってるくらいですから、一般の人には大したことないや んといわれるのがオチ。ECKD（３３９０）ディスクって要は３型の場合は2.2Gのディスクの器が決まっているので１Tといわれるとこれらの 3390DASD全部をフォーマットしなくてはならないのです。つまりFCPディスクのように１つでかいLUNを作ってそこをフォーマットというわけには いかないのです。
その辺があんまり理解されてないっすね。
これ、LPARUnderだったら少しはまし。でもVM Underとなるとちょっとめんどくさいです。

さてー、この400vol強のDASDをどうやってフォーマットするか？
まずはVM Underで１つ目のLinuxを作ります。そこにRACの共有DASDをとりあえずATTACHしておきます。
これはコマンドとかGUI(Yast）でできるレベルではないのでシェル作りました。
手順としてはDASDFMT→FDASDになりますが、DASDFMTのほうは複数Volumeをいっぺんに指定ができるのでその中で並行フォーマットの数などを指定できます。
DASDFMT自体は時間がかかるのですが、並行でやればある程度時間は短縮できます。
シェルはこんな風に作りました。
for i in ‘ls /dev/disk/by-pass/ccw-0.0.xxxx | grep part’
do dasdfmt $i
done
という風に作ります。これでdasdfmtはできる。
問題はfdasd。これは１つずつしかできない。うーん困った・・・。シェルを考えるも思いつかない。
とりあえず、lsdasdをawkで先頭デバイスをひらって、fdasdのコマンドを作った（笑）
これもきちんとしたシェルにできるのかもしれないが時間がなかった（笑）

今回はOracleのASMで管理を行うのでLVMでパーテーションを切るまででおしまい。

さてこれをRACの相手側と共有しなくてはならない。LPARの場合は簡単なんだけどVM Underでは一筋縄ではいかない。
まず、あるGuest Userに単純にATTACHしてしまうと、ほかのGuestユーザは使えない。
なので、MINIDISKとして定義をする。通常MIDIDISKって名前の通り、100Cylとか区切って使うものだが、今回は3390-3のフルVolumeのMIDIDISKとしてUser directに定義を行う。

MDISK xxxx 3390 0 END 0Xxxxx MNW と定義を行う。400vol分。
ちなみにCylder指定で、0 ENDとするとVTOCも変更できるが1 ENDとするとVTOCが変更できません。

これでRAC 1側の設定はおしまい。

続いてRAC 2側の設定。すでにDASDおよびLVMの設定は終わっているので、VMの定義から。
今度はRAC 1側で定義したMINIDISKにLINKを行います。

LINK xxxx xxxx RAC1 GuestUser MW
をRAC 2側からRAC1GuestユーザーのMINIDISKに書き込み可能状態でLINKします。

これでRAC２側からもDASDが見える状態になりますが、このままではLinuxが認識しないので、
vgscan でRAC 1側で作ったｖｇが見えるか確認します。
見えたら、vgchange -ay VG名にすると晴れてRAC　２側からも書き込み可能なDASDが完成します。

これで私は徹夜しました。