nakapachi blog

またやりました。第2弾。
今回は、エバンジェリストの講演がありました。

Ustream動画フルバージョンはこちら。
http://www.ustream.tv/recorded/20479346
デモのリハ。
http://www.ustream.tv/recorded/20477681

メインフレーム屋さん歴20年としてはあんまり驚く話はなかったけど、グロッシュの法則は知らんかった・・。
やっぱり、技術屋さんってこういうプレゼンテーションが不得意な人が多いが、この辺はさすがだなーと思いました。

今回のデモは2回目ということで前回よりちょこっと内容を増やしてみました。
実際にz/LinuxをBootをさせるのと、Worepressを動かしちゃったり、最後はOpenOfficeで。
たぶん、z/Linuxでこんなことやる人いないだろうと（笑）
そういう内容をあえてやってみました。

まぁ、完全個人的な世界ですね（笑）メインフレームをおもちゃにしてます（笑）
実はこういう環境を渡されるのは今に始まった話ではなく、昔お客さん環境でもおもちゃLPAR区画を持ってました。
名目上は重大障害テスト用だったのですが、実際に障害試験もやっていたのですが暇があればいろんなアセンブラやらプログラムを作ってました。
この時代はまだz/linuxがなかったので、MVSで遊んでいた訳ですが・・。
で、代理店に入って、今度は筐体丸ごとおもちゃメインフレームというのがあり、このころz/Linuxが出たてでUSのMarist大学のディストリビューションを導入して、
いろいろやってました。
x86のソースコードを片っ端からポーティングしてました。Samba+Namazuを使って社内の技術文章検索システムを作ってみたりとか。
z/OS(MVS)+CICS+IMSでなんちゃって勘定系システムつくっちゃったりとか。
x86Linuxとz/Linuxでベンチマーク比較しちゃったりとか。
とにかくメインフレームを好き勝手にできる機会が結構あったのでいろいろ経験してきました。

まぁいろいろやり過ぎたのでもう飽きた感が非常にあるのですが、また新しいネタを考えたら片手間でやろうと思います。

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

この企画、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の代替としてかなり存在感が増したというのが現状ではないでしょうか？