ソフトウェアを最新に保つ方法を、苦い経験から学ぶ
学校に通わなくなって久しい今でも、私にとって学ぶことは楽しいものです。新しいことを学ぶたびに、充足感に満たされます。特にテクノロジーの分野では、新しい概念に触れることで、物事の仕組みをもっと深く理解することができます。今まで何度となく、誰かの肩越しに、あるいは共有画面を通して、新しいツールやテクノロジー、あるいはデスクトップや環境をセットアップする別のやり方を学んできました。
私は誰かのやり方を見たり話を聞いたりして学ぶのが好きですが、IBM Redbooksなどの文書や記事を読んだり、ウェビナーの録画を観たりするのも十分に価値があります。Power Systemsのエコシステム、仮想HMCの長所と短所、特定のマシンに収まる物理アダプターの数、ファイルやバックアップマシンの転送方法、CLあるいはRPGプログラミングのテクニック、IBM iのオープンソース環境のアップデート、あるいはもっと全般的なベストプラクティスについてなど、どれも知りたいことばかりです。
新しいトピックについてほんのわずかな深さであろうともっと知ることは、少人数しかいな職場のIT担当者にとっては特に重要です。小さい会社ほど、数少ない人材が複数の役割を担っており、一人で多くのことをするように求められることが一般的です。
私は、たとえ今すぐに必要ではない情報であったとしても、結局一度もその情報を使うことすらなかったとしても、学ぶという経験に価値があると思っています。どのようなことが可能なのかを知ることが好きなのです。私にとっては、新しい概念に触れるために使う時間は有意義なものであり、よく知らないことほど、そのことについての本を読んで学びたくなります。そうして吸収した様々な情報がいつ役に立つのかはわかりませんが、ほんの少しトピックに触れておくだけでも、後で検索したり、質問したりするのがずっと楽になります。
Scott Berkun氏が最近、Twitterで同様のことを述べていました。「自分の仕事で十分な経験がある場合、成長できるいい方法は、他の何かを勉強することです。自分があまりよく知らない何かについての本を読んだり、それに関する会議に出席したりしてみてください。そこでは誰もが知りたいと思うような大きな質問を投げかけることも、新しいモデルや考え方を学ぶこともできるでしょう。そして、新たな目線で自分の仕事にも取り組めます」
このような流れで言えば、読者のみなさんの多くは、PowerVM Virtual I/O Server（別名VIOS）の内部の仕組みには馴染みがないかもしれません。それでも、これについてことを学んでおく価値はあります。対応を仮想化環境でする必要があるからです。
VIOSを使用することで、Power Systemsサーバーを仮想化することができます。AIXやLinux on Power環境で多く見かけますが、最近ではIBM iのワークロードにも対応するようになってきています。VIOSユーザーであれば、2020年10月時点でVIOS 2.xに対するIBMのサポートが終了していることはご存知でしょう。そして、VIOS 3.1.xにできるだけ早く移行することが重要である理由も理解しているはずです。
VIOS 2.xのサポートが終了したからといって、サポートをまったく受けられなくなるというわけではありません。サポートが終了した他の多くの製品と同様、今後もIBMは延長サポートを提供することでしょう。しかし、サポートを受けるのに追加料金が必要となることばかりが問題ではありません。もっと重要な問題があります。
また、これは最新かつ最高バージョンへの移行をお勧めしようという、ありきたりなお願いでもありません。移行すべき理由は、VIOS 3.xはVIOS 2.xとは根本的に異なるからなのです。VIOS 3.xは、新しいPower Systemsハードウェア（Power8以降）と使用することでより効率的に機能する設計になっています。VIOS 2.xがAIX 6.1を実行するのに対し、VIOS3.xは見えないところでAIX 7.2を実行します。AIX オペレーティングシステムのバージョン番号をよく知らない方もいらっしゃるでしょうが、AIX 6.1は2007年にリリースされ、AIX 6.1 TL9のサポートは2017年4月に終了しています。つまり、このVIOSのバージョンは、見えない部分で時代遅れになってしまっているのです。前述のとおり、新しいVIOSのコードはPowerハードウェアの改良を最大限に利用することができます（ディスパッチできるスレッドが増えるといったことを思い浮かべて下さい）。さらに、IBMはVIOSのレガシーコードを削除し（IBM Systems Directorといえばピンと来るかもしれません）、その結果VIOS 3.xの全体的なパフォーマンスが向上しました。
おさらいしておくと、VIOサーバーに割り当てられたストレージは、NPIVまたは仮想SCSIのいずれかを使用して、VIOクライアントに接続することができます。どちらにもメリットとデメリットがありますが、最近ではNPIVが使われていることが多いようです。
仮想SCSIモデルでは、共有ストレージリソースはストレージを仮想化します。ヘテロジニアス（異機種混合）ストレージは、VIOSによってブロック・ストレージの同種プールとしてエクスポートされ、一般的なSCSI LUN（論理装置番号）を与えられ、クライアントLPARに割り当てられます。 一般的なSCSI LUNの形でクライアントのLPARに割り当てられます。VIOSはSCSIエミュレーションを実行し、SCSIターゲットとして動作します。
NPIVでは、VIOSは根本的に異なる役割を持ちます。VIOSが行うのはアダプターの共有のみで、デバイスレベルの抽象化やエミュレーションはありません。NPIVを提供するVIOSはパススルーであり、ストレージを仮想化するのではなく、クライアントLPARからSANへFCP接続を拡張します。
次のような役割分担の説明の大部分は、一人の人間がすべてをこなす小規模なショップではなく、さまざまなチームがさまざま役割を果たすような大規模なショップにあてはまるものです。NPIVが使用されている場合SAN担当者はクライアントのLPARに直接LUNをゾーニングしますが、仮想SCSIが使われる場合にはVIOサーバー自体にLUNをゾーニングします。割り当てられたLUNをクライアントのIBM i LPARにマッピングするというさらなる手順はPower Systemsの管理者が行います。SAN担当者は一般的に、どのLPARが実際にLUNを使用しているのか、より高い透明性を求めるものです。ブラックボックス（VIOサーバー）にマッピングされた瞬間LUNが消えてしまうのを見ているよりも、NPIVを好む傾向があるようです。小規模ショップでは、ゾーニングとマッピングを同じ人が行っているので、これはそれほど問題にはならないかもしれません。
コード変更がなされたことで、VIOS 3.xへのアップグレードのプロセスは、これまで慣れ親しんだものとは違うものになるということを認識しておくことが重要です。単にフィックスパックやサービスパックをあてているだけではなく、見えないところでOSをAIX 6.1からAIX 7.2にアップグレードしているのです。アップグレードは比較的わかりやすいかと思いますが、それでもある程度の計画と準備が必要なので、慎重に進めてください。
良いニュースは、ほとんどの環境でVIOSサーバーはデュアルVIO構成でセットアップされるため、ストレージとネットワークへの複数のパスが提供され、実行中のクライアントのLPARに影響を与えることなくメンテナンスが可能だということです。つまり、VIOサーバー2をアップグレードしてテストし、すべてをその2番目のサーバーにフェイルオーバーしてから、VIOサーバー1のメンテナンス作業を行うことができるのです。もちろん、VIOフェイルオーバープロセスは、定期的にテストする必要があります。他の高可用性ソリューションやシステムのバックアップと同様に、テストを行わなければ、必要なときに正しく動作するかはわかりません。
IBMではアップグレードを実行するのに役立つツールや方法を提供していますが、基本的には構成をバックアップし、新しいVIOSをインストールしてから、新しいVIOSコピーに構成情報を復元するというものです。私の友人に、ここ最近でかなりの数のアップグレードを実行している人がいます。IBMはデータをバックアップするためのツールを提供していますが、彼は自分で構成データを集めるほうが好きだといいます。
彼は次のような珍しい経験について教えてくれました。ある時扱ったその特定の環境において、彼はIBM iクライアントはすべてNPIVを介してストレージに接続されていると聞いていました。必要なデータを収集し、VIOSコードの新規インストールを行った後、そのまま次に進んでネットワークとNPIVの設定を復元しました。その後、彼はクライアントをすべて新しく構築したVIOサーバーにフェイルオーバーし、もう一方のサーバーの作業を開始しました。ほとんどのIBM iクライアントは問題ありませんでしたが、いくつかのクライアントがディスクへのアクセスを失ったことを示すLEDコードを出し始めました。調べたところ、その環境には仮想SCSIディスク接続がまだいくつか残っていたことが判明しました。先ほど書いたように、彼はディスクがどのように接続されているのかを自分で確認せずに、聞いたことを鵜呑みにしてしまっていたのです。
システムが実行中に、ディスクへのすべてのパスを切り離したら何が起こるでしょうか。システムがクラッシュしそうに思われるでしょう。しかし、どこが問題だったかが判明した後（これには約1時間かかりました）、両方のVIOサーバーでは仮想SCSIマッピングが元に戻され、LPARは問題が発生する直前まで戻って改めて動作しました。クラッシュすることも再起動することもなく、何事もなかったかのように稼働を続けたのです。顧客はログインして、システムの見た目も動作も期待通りであることを確認することができました。
このエピソードはIBM iのレジリエンスを示すものかもしれませんし、友人が単に運が良かったのかもしれません。メンテナンスは一日の中でも静かな時間帯に行われたので、その瞬間にシステムに負荷がかかることはありませんでした。いずれにしても、私は感心しました。
しかし、この話から間違った教訓を得てはいけません。本番環境で稼働しているシステムからディスクのパスを勝手に切り離すことは、いかなる場合も決して良いことではありません。しかし、私はラボ環境でこの動作を試しに再現してみたいと思っています。この結果について他の人と話したとき、懐疑的な意見もありました。あの環境がクラッシュしなかったのには、何か別の理由があるはずだと。一つ考えられるのは、ロードソースディスクがNPIV経由で接続されていたのではないかということです。
私はその真相を突き止めるつもりです。これは新たな学習の機会だと思っています。正式に学校に通う時期はもう終わったかもしれませんが、学びはまだ続きます。
