特集・ブログ
こんにちは。 てくさぽBLOGメンバーの佐藤です。 2022年7月20日に IBM より Power10 Scale Out Model の発表がありました。 既にリリースされている E1080モデルと比較して、リーズナブルな価格帯を実現してます。 今回は IBM Power の設計に注目し、どのような点が優れているのか？他社との違いは何か？にポイントを絞ってご紹介します。 Powerの3要素 Powerの設計は主に以下の3つの要素から形成されます。 パフォーマンス 資産継承 システム連続稼働(可用性 、セキュリティ) 1.パフォーマンス Power9からPower10 の主だった進化ポイントは以下の通りです。 Power9 Power10 最大搭載コア数 12 15 L2キャッシュ 512kB/Core 2MB/Core L3キャッシュ 120MB/チップ 120MB/チップ PCle Gen4 Gen5 消費電力 - Power9の半分 また、次の点も進化しています。 新命令セットISAを追加（AIやセキュリティ対応） 実行ユニット 128Bit (整数/浮動小数対応) ×8/Core OMIメモリ 1024GB/s対応 以上の観点からもパフォーマンスUPされていることがわかりますが、ここではさらに代表的なx86CPUとの比較について、独自の視点でまとめてみました。 会社名 IBM INTEL AMD CPU名称 Power10 Xeon SP 3rd EPYC 7003 プロセスルール Samsung 7nm Intel 10nm TSMC 7nm+GF 14nm ダイサイズ 602㎟ 非公開 8×81㎟＋416㎟ トランジスタ数 180億 非公開 8 ×33.2億⁺84億 (パッケージ328億) コア数 15 40 64 1コアあたりのトランジスタ数 12億 非公開 5.125億 1コアあたりのスレッド数 8 2 2 L2キャッシュ/Core 2MB 1MB 512KB L3キャッシュ(共有) 120MB 60MB 32MB×8⁼256MB L3キャッシュ/Core 8MB 1.5MB 4MB CPUクロック 3.55GHz～4.0GHz 2.3GHz~3.4GHz 2.45GHz~3.5GHz メモリクロック DDR4 3200MHz DDR4 3200MHz DDR4 3200MHz メモリチャンネル 16ch(OMI） 8ch(ダイレクト接続) 8ch(ダイレクト接続) メモリ帯域 1024GB/s 200GB/s 200GB/s 比較いただければわかると思いますが、Power10は非常に豪華な構成です。 1Coreあたりの資源投入量が多く、メモリ帯域も非常に高いです。 「クロック数が高い」「1Coreあたりのキャッシュが多い」「スレッド数が多い」となり、性能向上に対して妥協なく取り組んでいます。 Intel® 64 and IA-32 Architectures Optimization Reference Manual を参考により詳しく見ていきます。 Intel Power アーキテクチャ Skylake Power10 整数同時実行数 4 8 浮動小数同時実行数 3 8 512Bit行列演算同時実行数 2 4 Power10は、1Coreあたりの同時実行数が整数、浮動小数、行列演算すべてにおいて上回っています。 SMT8は、単純な水増しではなく、同時に8つの演算を並列して実行できるだけの構造になっていることがお判りいただけるかと思います。 同時にOMI (後ほど詳細を説明します) によってより多くのメモリ帯域を確保しています。 2.資産継承 Powerは互換性について重視しています。 通常、CPUのアーキテクチャ変更はOS側で吸収するというのが一般的ですが、OSとCPU両方開発しているIBMは違います（IBMのStrong Pointの1つです！） PowerはCPU自体に互換モードを備えており、100％の互換性を担保します。 つまり、Power10ではPower9モード、Power8モードが利用可能ですので、従来の環境から一旦そのままで移行したいケースや、CPUの相性が心配といった場合でも互換モードを使うことによって安心して移行することが可能です。 ただし、互換性を最重視した結果、互換モードではPower10から新たに対応している命令セット、例えばMMA（Matirix Multiply Assist）命令は対応できない為、性能が十分に発揮できないケースがございます。 移行後はOSを最新化していただくのがおすすめです。 3.システム連続稼働(可用性、セキュリティ） IBM Powerは非常に障害に強い、ダウンタイムが少ないプラットフォームというのは周知の事実かと思います。 では、どのようにしてこのような堅牢な環境になっているのでしょうか？ 従来よりPowerはプロセッサー周りについては非常に堅牢なRAS機能を搭載しています。 これらの機能は引き続きPower10でも継承されています。 First Failure Data Capture Processor Instruction Retry L2/L3 Cache ECC protections with cache line-delete Power and cooling monitor function integrated into processors’ on chip controllers CRC checked processor fabric bus retry with spare data lane 追加されたPower10のRAS機能とセキュリティ機能について解説します。 Power10では、主にプロセッサー外部のRASおよびセキュリティ機能が強化されています。 OMI (Open Memory Interface) : 本来パラレル転送であるDDR4メモリをシリアル転送化するメモリインターフェースです。 シリアル転送化により、より高速にするだけでなく、従来では不可能だったCPU-メモリ間のアクセスの障害についても帯域を半減させて縮退動作させることが可能になりました。 ※Powr10プロセッサーはPower9プロセッサーと比べ4倍以上の帯域幅を確保により、高速処理を実現 Chipkill : Chipkill は従来のECCメモリより高い可用性があり、RAIDパリティのような機能です。 DIMMの中に多数搭載されたメモリチップのうち一つが障害を起こしてもリカバリします。 スペアチップ : RAIDのスペアドライブと同じでDIMM内にスペア用のメモリチップを用意することにより障害を起こしたチップを切り離し、容量を少なくすることなく代替メモリチップに切り替えます。 透過的メモリ暗号化: メインメモリ上に展開されたパスワード等のデータは暗号化が難しいため常にセキュリティリスクにさらされています。 近年ではサイドチャネル攻撃により、別の仮想区画のデータを覗き見る手段が指摘されており、これらの攻撃に対しては、根本的な対抗策はメインメモリの暗号化となります。 Power10は専用の暗号化エンジンをDIMM上に配置することにより、パフォーマンス劣化なくメモリ暗号化を実現しています。 Power10が先駆けた性能改良、セキュリティを実装しているか、を解説いたしました。 おわりに Power10は高速、高可用性、高いセキュリティとすべての要求に応えるプロセッサーとなります。 特にセキュリティについては、現状で攻撃が存在しないとしても悪意ある攻撃が登場するとゼロディ攻撃にさらされるため、対策が遅れがちになります。 さらに修正不可能なバグがあった場合は、明日サーバーを入れ替えるということも現実的にできないので、問題が発覚する前によりセキュアな機能を先んじて実装するというのが非常に大切です。 将来も安心して利用できるインフラ環境としてPower10を覚えていただければと思います。 今後Power10での提案活動が加速ていくことを期待してます。 お問い合わせ この記事に関するご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社 E-Mail：voice_partners@niandc.co.jp 関連情報 出荷から半年、IBM Power10が市場に与えたインパクトとは？ (インタビュー) 【10分で早わかり】インタビュー記事「Power10の真の価値とは」 (インタビュー) 早わかり！ここが進化したIBM Power10！ (コラム)
こんにちは。エヌアイシー・パートナーズ 村上です。 2022年度は新しい試みとして、 ・理解しているつもりだけど説明はできない ・時間があれば調べたいと思っていた ・当たり前な知識かもしれなくて質問しにくい という内容を取り上げた「早わかりシリーズ」を掲載していきます。 今回は、IBM Power のメインOS、AIX と IBM i のライセンス情報をご紹介します。 AIX とIBM i は、片方のライセンス情報しか知らないという方も意外と多いので、ぜひこの機会に比較しながら読んでみてくださいね。 セクション 1) 永続ライセンスのおさらい 2) マンスリーとサブスクリプションをご存じですか？ 3) ライフサイクルとバージョンのポイント 1) 永続ライセンスのおさらい AIX とIBM i のスタンダードなライセンス「永続ライセンス」。 有効期限のない永続ライセンスは、SWMA (SoftWare MAintenance) と合わせて所有します。 永続ライセンス OSを利用できる権利。1年目に購入。 SWMA 「サブスクリプション（最新バージョンへのアップグレード）」と「テクニカルサポート（対象製品に対するQAサポート）」の権利。 1年～5年で選択し、継続するためには都度オーダーが必要。 更改などで新ハードウェアへ移行する場合、 AIX 永続ライセンスはIBM Power本体に紐づくので、新ハードウェアになるタイミングで永続ライセンスが買い直しになります IBM i 既存機のライセンスを新ハードウェア移管することが可能です（移行先の機械レベルが高くなる場合は追加料金が発生） IBM i には、移行中ライセンスとして安価なITL(IBM Temporary License)が提供されたり、DR機専用のライセンスがあったりもします。 2) マンスリーとサブスクリプションをご存じですか？ さて、このセクションが今回のブログの本題です。 2022年6月現在、AIX とIBM i には「永続」「マンスリー」「サブスクリプション」と3種類のライセンスがあります。 以下は利用ケースのイメージです。 利用ケース 永続ライセンス ・長期間利用 マンスリーラインセンス ・移行時の短期利用 ・スパイク(最低限の環境をさっと作って概ねの方向性を確認する） サブスクリプションライセンス ・初期投資を抑えたい場合に利用 ・HWに依存せず臨機応変に利用(中長期間でAIXの場合) サブスクリプションライセンスは、AIX は2021年、IBM i は2022年に提供が開始されました。 （表が見えにくいのでクリックして拡大してご覧ください） サブスクリプションライセンスは、今後拡張が予定されています。 利用ケースにあったライセンスを選択できるようになってきたので、臨機応変な検討ができるようになりますね。 3) ライフサイクルとバージョンのポイント 2022年6月時点で、IBMは「AIX も IBM i も将来の投資を継続する」という発表をしています。 IBM Power ユーザとしては一安心です。 どちらのOSも、サポートライフサイクルは10年間となります。 下記にバージョンのポイントを纏めてみました。 ＜AIX ＞ 購入できるバージョン v7.2 , v7.3 標準サポートがあるバージョン v7.1, v7.2, v7.3 どうやってもサポートが終わっているバージョン v5.3 実はまだ有償延長サポートがあるバージョン v6.1 TLが出るタイミング（※） 1回/年、成熟してくると1回/2年 サポートライフサイクル(10年) 標準(最短6年)+延長保守(3~5年) ＜IBM i ＞ 購入できるバージョン v7.3 , v7.4, v7.5 標準サポートがあるバージョン v7.3, v7.4, v7.5 どうやってもサポートが終わっているバージョン v6.1 実はまだ有償延長サポートがあるバージョン v7.1, v7.2 TRが出るタイミング（※） 2回/年（最新バージョンと1世代前のバージョンに対して） サポートライフサイクル(10年) 標準(7年)＋延長保守(3年) <※TLとTRの補足> TL：テクノロジー・レベル。AIXにおける問題の修正、新しいハードウェアのサポート、ソフトウェアの機能拡張が含まれたプログラム。 TR：テクノロジー・リフレッシュ。IBM i におけるオファリング、サービス、およびハードウェアの機能拡張を提供するプログラム。 かなり前のバージョンも、延長保守のサポートがあるため更改時も安心です。 ただ、延長保守サポートは、部品不足による急な保守終了や、新規の問い合わせに対応いただけない、という面があるので要注意です。 また、延長保守サポートには細かい前提が設けられており前提にも随時変更が入りますので、ご利用を検討される際はお問い合わせください。 さいごに つい先日(2022年6月)、IBM i の複数のソフトウェアラインセンスが無償化される発表(IBM PartnerWorld)がありました。 IBM i では更改の検討が始まると、実際に利用している有償ソフトウェアの見直しが入ったりして、見積もりに時間がかかることがありますよね。 有償ライセンスが減ったことで、見積もりが少しでも簡単になり助かります。 クラウドシフトが進む中で、ライセンス体系、課金、監査方法が複雑化しています。 弊社には毎日のようにパートナー様からライセンス関連の相談やお問い合わせが来ています。 OSのみではなく、あらゆるソフトウェアのライセンス情報収集に日々奮闘(?)しているSEが多数おりますので、お困りの際はお気軽にご連絡ください！ ※ 本ブログの情報は時間経過とともに変更が入る可能性があります。 お問い合わせ この記事に関するご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社 E-Mail：voice_partners@niandc.co.jp
こんにちは。 事業企画部メンバーの栗本です。 例えば「Db2 V11.5 はいつまでサポートがありますか？」など、継続してお問い合わせの多い IBMソフトウェア製品の「サポート・ポリシー」について説明いたします。 (さらに…)
こんにちは。 てくさぽBLOGメンバーの宮里です。 前回に引き続きAzure Stack HCIの検証で得られた知見をお伝えします。検証の目的は、Azure Stack HCIの構築・管理・クラウドとの連携をどのような手順でおこなうのか、使いやすいのか、を実機を使って体感してみることです。 今回は3回シリーズの2回目で、Azure Stack HCIを管理するサーバーを構築した手順をご紹介します。 Azure Stack HCIを導入してみた Vol.1 -Azure Stack HCI構築編- Azure Stack HCIを導入してみた Vol.2 -管理機能編- ＊本編 Azure Stack HCIを導入してみた Vol.3 -Azureと連携編- なお、現在のAzure Stack HCIは専用のAzure Stack HCI OSを利用してクラウドから管理するAzure Stack HCIと、従来からのWindows Server DataCenterエディションを利用するAzure Stack HCIの２つがありますが、本ブログのAzure Stack HCIはWindows Server DataCenterエディションの方となります。 Index はじめに 1. Windows Admin Center (WAC) の構築 2. Lenovo XClarity Administratorの構築 3. WACとLXCAの連携 さいごに お問い合わせ はじめに 第一回に続いて、今回は管理機能の検証としてWindows Admin Center（以下、WAC）サーバーとLenovo XClarity Administrator（以下、LXCA）サーバーを構築した内容になります。 今回の検証環境の概要図はこちらになります。WACサーバーとLXCAサーバーは仮想マシンで立てることにしたのでMXサーバー以外にもう1台物理サーバーを用意し、そこにHyper-V環境を構築しました。このHyper-V環境上にWACサーバーとLXCAサーバーを構築します。 LXCAはハードウェアを一元管理するサーバーです。そのためAzure Stack HCIを利用するにあたって必須ではなくオプションですが、WAC向けにLenovo XClarity Integrator for Microsoft Windows Admin CenterというLXCAと連携させる拡張機能が提供されているので、WACでハードウェアまで管理できるとどのように便利になるかを確認するために検証してみました。 1. Windows Admin Center（WAC）の構築 WACはマイクロソフト社が提供する無償で利用できるリモート管理ツールです。Azure Stack HCIはWindows Server 2019の標準機能を組み合わせて利用するので、そのままでは複数の管理ツールを使い分ける必要があります。WACを利用することでWebベースで一元管理が可能なので今回はその構築と実際の利用を検証してみました。 ブログ記事の順番は前後しますが、今回の検証ではまずWACサーバーを構築してからAzure Stack HCIサーバーを構築しました。Azure Stack HCIサーバー構築については当ブログ第一回を参照ください。 1-1. WACインストール WACのホームページからインストールファイルをダウンロードします。ダウンロードには以下のフォームで必要情報を入力し［Continue］をクリックするとダウンロードが始まります。 WACの展開方式はいくつかありますが、管理するWACと管理対象のMXノードが分かれていてWACには複数クライアントから接続できるゲートウェイサーバー方式が実際の案件でも選択される場合が多いとの想定から、ゲートウェイサーバーで検証することにしました。 最初の画面で[使用許諾契約書に同意します] にチェックを入れ、次に進みます。診断データのマイクロソフトへの送信はデフォルトのままで進みます。 デフォルトのまま次に進みます。 SSL証明書も今回は検証なので自己署名証明書のままで進みます。 インストールが完了したら、表示されているURLに接続して管理者アカウントでログインします。 WACに接続して自身のサーバーが確認できれば完了です。特に設定項目を変更することなくほぼデフォルトでインストールできてとても簡単でした。 1-2. クラスタの追加と確認 MXサーバーの2台をWACに追加し、続いて第一回で作成したnicp-clusterという名前のWindowsサーバークラスタを追加します。追加が完了すると以下のように確認できますのでこれをクリックして接続します。 WACからできるクラスタ管理を確認しました。以下のように状態を確認したり、 ボリュームを作成できることや、 仮想マシンの作成などもできました。 使ってみた感想としては、WACのインストール作業や操作性はシンプルでわかりやすく、スムーズに済みました。 GUIなども見易いのですぐ慣れると思います。 2. Lenovo XClarity Administratorの構築 続いてLenovo社のXClarity Administrator（以下、LXCA）を構築します。LXCAは無償で利用できるハードウェア管理ツールです。＊LXCAはサポートは無いので本番利用でサポートが必要な場合はXClarity Proを購入する必要があります。 2-1. LXCAインストール まずLXCAのファイルをダウンロードします。仮想アプライアンス形式で提供されているので、今回はHyper-V用をダウンロードしました。 次にHyper-VマネージャーでLXCA用仮想マシンを作成します。仮想マシンの新規作成ウィザードが始まります。 分かりやすい仮想マシン名を付けて次に進みます。 仮想マシンの世代を「第一世代」、次の画面でメモリ割り当てを8GBにします。このあたりはLXCAのマニュアルを参考にしました。 今回の検証環境は固定IPの利用が必要な環境だったのでネットワークは一旦「接続しない」とし、後で固定IPを設定してからネットワークに接続することにしました。 次の画面で「既存の仮想ハードディスクを使用する」を選択し、ダウンロードしたLXCAのファイルを指定します。 これで仮想マシンの作成は完了です。以下の設定値で作成しました。 仮想マシン後に1箇所設定を変更します。作成した仮想マシンの設定画面で、仮想プロセッサの数をデフォルトの1個から2個に変更します。これも上記LXCAマニュアルに書かれている内容です。 ここまで終わったら仮想マシンを起動します。 起動が完了すると、仮想マシン画面上に以下のようにネットワーク設定を選択する画面が表示されるので”1. To set a static IP address for Lenovo XClarity virtual appliance eth0 port"を選択して固定IP設定に入ります。 続けるかどうかのメッセージが出るので”ｙ”と入力します。 次に設定するIPの種類を聞かれるので”ipv4"と入力します。 続いてIPv4の各項目を入力していきます。IP address、netmask、gateway、DNS1、DNS2と順番に入力していきます。 継続するかの確認が出たら”ｙ”を入力します。 しばらくすると固定IPが設定された画面が表示されます。 この後、Hyper-Vマネージャーにて仮想スイッチに接続することでネットワークに接続できます。 以上でLXCAがネットワークに接続しました。 2-2. LXCA初期セットアップ ブラウザでLXCA仮想マシンのIPアドレスに接続するとライセンス使用許諾から始まり各項目を順番に設定していくようになっています。では、早速設定していきましょう。 まずはライセンス使用許諾からです。内容を確認し［同意する］をクリックします。 次にユーザー・アカウントの作成です。スーパーバイザー・アカウントを２つ作成するようあるのでrootとroot2という２つのユーザーを作成しました。 次はネットワーク設定です。固定IPの設定は済んでいるのでここは確認だけでした。 次はサービスおよびサポート設定の構成です。左ペインにある［定期的なデータ・アップロード］から［サービス・リカバリー・パスワード］までの各項目を設定します。 以下は2つ目の［コール・ホームの構成］画面です。本番では管理対象サーバーがコール・ホーム対象のイベントを記録した際に自動的に通報される機能の設定を行いますが、今回は検証なのでここはスキップしました。 3つ目の［Lenovoアップロード・ファシリティー］の設定画面です。Lenovoサポートからサービス・データのアップロードを指示された場合のアップロード設定を行います。こちらも今回の検証では利用しないのでスキップしました。 4つ目の［保証］画面です。内容を確認してそのまま［適用］をクリックします。 5つ目の［Lenovo Bulletin Service］設定画面です。Lenovo がセキュリティや新バージョンリリースなどの情報をXCLAに送信するのを許可する設定です。デフォルトで許可する設定になっていますのでそのまま［適用］をクリックします。 6つ目の［サービス・リカバリー・パスワード］設定画面です。リカバリーの際に利用するパスワードを設定します。 すべての項目の設定が完了したら［システム管理の開始］をクリックします。 最初にデモデータを含めるかを選択します。どちらでもよいです。 ［新しいデバイスの検出と管理］画面で、MXノードのXClarity Controller（管理プロセッサのこと。以下、XCC）のIPアドレスを手動登録します。 XCCのIPアドレスを入力して次の画面でユーザーID・パスワードを入力して登録します。 以下のようにMXノード2台のXCCを登録しました。 以上でLXCAのインストールと設定は完了です。 3. WACとLXCAの連携 WAC対応のLenovo XClarity Integrator（以下、LXCI）を利用することで、WAC画面からLXCAの管理情報にアクセスすることができるようになります。これでWACからハードウェア管理もできるようになります。 まず、WACにて［Lenovo XClarity Integrator］という拡張機能をインストールします。 左ペインの［拡張］を選択し、右ペインで［Lenovo XClarity Integrator］を選択してインストールします。 インストールが完了すると、［設定］から［Lenovo XClarity Integrator］が選択できるようになるのでこれを選択します。 LXCAを登録します。LXCAのIPアドレスと初期セットアップで登録したスーパーバイザーアカウントで接続します。 接続が完了するとLXCAが［接続済み］というステータスで確認できますのでこれをクリックします。 次にMXノードをLXCAに追加します。画面ではnicp01というMXノードに接続しています。拡張機能がインストールされたので、ノードの左ペインに［Lenovo XClarity Integrator］が選択できるようになったのでこれを選択して右ペインで”接続されたXClarity Administrator管理サーバーにノードを追加する”を選択してLXCAのIPアドレスを指定します。 するとWAC上のLenovo XClarity Integrator画面にMXノードが追加されます。以下はMXノード2台の登録が済んだ状態です。ThinkAgile MXと正しく認識されていることが確認できます。 WACに統合されたLXCAを利用してみました。以下のようにWACからLXCAのハードウェア情報を確認することができます。 このように、WACとLXCAの連携もとても簡単にできました。WAC上でハードウェア管理もできるようになるのでWACもLXCAも利用するのであればぜひ連携機能も利用してみては、と思います。 最後に WACとLXCAを連携することでHW、SWの両方を一度に管理することが出来、あれこれ見に行くことが無くなるので非常に見易く、便利だと感じました。 それぞれWACとLXCAの操作も切り分けが出来ていて、操作としてもGUIがシンプルであるため困ることは無いでしょう。 是非ともWACにLXCAを連携して使ってみてください。 管理機能編は以上になります。 如何でしたでしょうか、次はクラウド連携編になりますので是非ご覧ください。 お問い合わせ この記事に関するご質問は下記までご連絡ください エヌアイシー・パートナーズ株式会社 技術支援本部 E-Mail：nicp_support@NIandC.co.jp
こんにちは。 てくさぽBLOGメンバーの宮里です。 今回はAzure Stack HCIの検証をしてみたので3回シリーズで検証で得られた知見をお伝えします。 (さらに…)
※この記事は2022年12月26日時点の情報をもとに作成しています ＊ ＊ ＊ ＊ ＊ ＊ こんにちは。てくさぽBLOGメンバーの佐野です。 継続してお問い合わせの多い、IBMソフトウェア（Passport Advantage：以下 PA）のライセンス体系について説明します。全網羅的ではなく代表的なもののみ説明するので、載っていない製品や課金体系については個別にお問い合わせください。 目次 IBMソフトウェア（PA）のライセンスとソフトウェア・サブスクリプション＆サポート 課金体系 まとめ お問い合わせ IBMソフトウェア（PA）のライセンスとソフトウェア・サブスクリプション＆サポート IBMソフトウェアを利用するために必要な権利は「ライセンス」「製品サポート」の2つに大別されます。 ライセンス：ソフトウェアを使用する権利 製品サポート：製品に対する各種問い合わせ、トラブル対応、バージョン・アップの権利 製品サポートは「IBMソフトウェア・サブスクリプションおよびサポート」（以下 SS&S）ともいいます。ライセンスと SS&S には、それぞれ以下の種類があります。 ライセンス 永久ライセンス：Perpetual License（買い切り型ライセンス） 期間限定ライセンス：Term License（期間使用型ライセンス） SS&S 継続SS&S：製品サポートを継続する場合に必要 新規SS&S：SS&Sの契約を停止した（空白期間が生じた）製品サポートを再開する場合に必要 永久ライセンスを購入すると対象ソフトウェアを永久的に使用できます。また、1年間の SS&S が付加されているので、1年目は製品サポートを受けられます。なお、SS&S の購入は1年単位です。 2年目以降は、継続SS&S を購入することで製品サポートを継続して受けられます。（図1-A）継続SS&S を購入しない場合、製品サポートに空白期間が生じたのちに再開する際には新規SS&S を購入する必要があります。（図1-B） 図1：2年目以降のSS&S購入による違い 期間限定ライセンスは以下が提供されます。 指定された期間に対してのソフトウェア使用権（ライセンス） 指定された期間中の製品サポート（SS&S） 期間限定ライセンスにはライセンスとSS&Sが必ず含まれるため、契約期間中に製品サポートも受けられる点が永久ライセンスと異なります。また、期間限定ライセンスは以下の種類があります。 サブスクリプションライセンス（Subscription License） 月額ライセンス（Monthly License） 期間限定ライセンス（Fixed Term License） それぞれの特徴は以下に記載の通りです。 各ライセンスの特徴 サブスクリプションライセンス（Subscription License） 契約期間：12か月から60か月 最短期間：12か月 途中解約：不可 製品サポート（SS&S）：あり 月額ライセンス（Monthly License） 契約期間：1か月から60か月 最短期間：1か月 途中解約：30日前に書面で通知 製品サポート（SS&S）：あり 期間限定ライセンス（Fixed Term License） 契約期間：12か月の固定期間 最短期間：12か月の固定期間 途中解約：30日前に書面で通知 製品サポート（SS&S）：あり スモールスタートするプロジェクトや PoCプロジェクトにおいて期間限定ライセンスを採用することで、"初期投資を抑えることができる" や "必要なくなったら停止ができる" といったメリットがあります。特に、DXの実装段階においてはプロジェクトを素早く立ち上げ、効果がなければやめるという進め方が多くなります。このようなケースでは期間限定ライセンスのご利用が適しています。 一方、長期利用をする場合に期間限定ライセンスを採用することは永久ライセンスと比べてコスト増となることが多くなります。 プロジェクトの特徴や特性に合わせて期間限定ライセンス／永久ライセンスを選択し、最適なものを選びましょう。 課金体系 IBMソフトウェアの課金体系は「Passport Advantage / Passport Common License Types & Definitions」（IBMサイト/英語）にも記載がありますが、なんだか堅苦しい記述になっているのでざっくり解説をします。 課金体系は大きく「ユーザー課金」「サーバー課金」「その他」の3種類に分類できます。製品によってはユーザー課金とサーバー課金を組み合わせて買う必要があります。 具体的にもう少し詳しくみていきましょう。 ユーザー課金 Authorized User（許可ユーザー） 許可ユーザーは名前の通り、ソフトウェアを利用するユーザー数に応じた課金単位です。「どのPCからアクセスするか」ではなく、利用者個人に紐付きます。例えば、あるユーザーが PC だけでなく iPhone からアクセスをしても1ライセンスです。 図2：「許可ユーザー」におけるライセンスの数え方 Authorized User Single Install（許可ユーザー・シングルインストール） この課金単位は少し特殊です。考え方は許可ユーザーとほぼ同じですが、ユーザーと利用するサーバーを紐付ける必要があります。 具体例を挙げて説明します。 例えば、サーバーAとサーバーBの2台を稼働させ、サーバーAには管理者、ユーザー1、ユーザー2の3人がアクセスします。サーバーBにはユーザー1とユーザー2がアクセスをします。Authorized User の考え方ではユーザー数とイコールになるので3ライセンスとなりますが、Authorized User Single Install では "サーバーA：3ライセンス / サーバーB：2ライセンス ＝合計5ライセンス" の購入が必要となります。 この課金単位を利用している代表的な製品は Db2 v11.1以前のバージョンです。最新の Db2 では後述の Virtual Processor Core課金が使われこのカウント方法は使われないため、ご注意ください。 図3：「許可ユーザー・シングルインストール」におけるライセンスの数え方 Concurrent User（同時接続ユーザー） 同時接続ユーザーの場合は、サーバーなどに一時点で同時に接続しているユーザー数分のライセンスとなります。たとえ10ユーザーいたとしても、同時に利用しているのが2ユーザーなのであれば2ライセンスとなります。 代表的な製品としては、SPSS がこの課金単位での購入が可能です。 図4：「同時接続ユーザー」におけるライセンスの数え方 User Value Unit（ユーザー・バリュー・ユニット） ユーザー・バリュー・ユニット（UVU）でのユーザー数のカウントは Authorized User と同じ考えですが、製品によって以下のポイントが異なる場合があります。 ユーザーの種類（例：社内ユーザー、社外ユーザー） 総ユーザー数に応じた階段式の係数（例：1,000ユーザーまでは係数1、1,001から5,000ユーザーまでは係数0.8、それ以降は係数0.6、など） 製品によってカウント方法や上記の係数などが異なるので、UVU課金単位の製品を購入する場合には IBMサイトのライセンスインフォメーション（英語）から対象製品を検索するか、個別に取引先にご確認ください。 代表的な製品としては、IBM Security Verify Access（旧 ISAM、TAM）があります。 図5：「ユーザー・バリュー・ユニット」におけるライセンスの数え方 サーバー課金 Install（インストール） インストール課金単位はソフトウェアをインストールしたマシン数に対する課金です。1台に導入するのであれば数量は1で、利用するユーザー数は関係ありません。 代表的な製品としては、IBM Security Guardium Key Lifecycle Manager がこの課金単位です。 図6：「インストール課金」の場合 Processor Value Unit（プロセッサー・バリュー・ユニット：PVU） 課金単位に関する問い合わせで一番数が多いのが、この PVU課金です。 PVU課金では、利用する CPU に応じた係数が決まっています。係数表は「Processor Value Units (PVUs)」（IBMサイト/英語）に掲載されています。この表の係数を元に、コア数を掛け算した数量のライセンス購入が必要となります。 例えば、Intel Xeon E5-2609v4 であれば最大2ソケットマシンにしか搭載できないので、先の PVU表からコアあたりの PVU値は 70PVU となります。この CPU は 8コアCPU であるため、1CPUサーバーの場合には "70PVU / コア×8コア / CPU×1CPU ＝560PVU" となります。 Intel CPU の場合、4ソケットマシンには100PVU、4ソケットを超えると 120PVU と、係数が変わるので、数量を確定するためには何ソケットサーバーなのかを調べておく必要があります。 図7：PVUはCPUに応じた係数に総コア数を乗じて算出する。 気を付けないといけないのは、サーバー更改や仮想化統合をする場合です。 割り当てコア数は変わっていなくても、物理サーバーのソケット数が変わることで PVU値が上がってしまうケースがあるので注意が必要です。また、新しい CPU は搭載しているコア数の最小数がどんどん増えているので、「現行機は2コアで稼働しているけれど更改後は4コアで稼働（＝不足分の追加ライセンスが必要）」なんてこともよくあります。 多くの IBMソフトウェア製品がこの課金単位を利用しています。 Managed Virtual Server（管理対象仮想サーバー） 管理対象仮想サーバー課金単位はインストール課金と同じ考え方です。数量はソフトウェアを導入する仮想サーバー数をカウントします。 下図の場合には2台の仮想サーバーにソフトウェアを導入するので、2ライセンスとなります。なお、仮想環境ではなく物理サーバーが対象の場合には1ライセンスとしてカウントします。 この課金単位を使っている代表的な製品は、Instana や Turbonomic ARM があります。 図8：「管理対象仮想サーバー課金単位」はソフトウェアを導入する仮想サーバーを数える。 Virtual Processor Core（仮想プロセッサーコア） 仮想プロセッサーコア（VPC）課金単位は仮想サーバーに割り当てられたコア数（仮想環境の場合）、もしくは物理サーバーに搭載しているコア数（物理サーバーの場合）をカウントします。 PVU課金と違って CPUソケット数や種類による係数はなく、単純にコア数をカウントするだけなので環境を選びません。 この課金単位を使うのは、IBM Db2 Standard Edition や IBM Cloud Pakシリーズです。PVU課金のようにプラットフォームの影響を受けないので、計算がシンプルなのが特徴です。 図9：「VPC課金単位」は単純にコア数を数える。 その他 Client Device（クライアント・デバイス） クライアント・デバイス課金単位は、対象をサーバーではなく一般的なユーザーが利用するような端末に限定する課金体系です。 例えば、パソコンやスマートフォンなどが対象です。サーバーを対象とする場合には別の課金単位を用意している場合がほとんどです。 図10：「クライアント・デバイス課金単位」はパソコンやスマートフォンなどが対象 Resource Value Unit（リソース・バリュー・ユニット：RVU） RVU課金単位は、製品によって「何を課金対象とするのか」が変わる厄介な課金単位です。 例えば、Netcool OMNIbus では監視対象機器の物理台数が RVU数となります。似たような製品で、Tivoli Monitoring では監視対象のコア数が RVU数とカウントされます。 製品によってカウント方法が異なるので、RVU課金の場合は何をカウント対象とするのかを個別の製品ごとに確認が必要です。カウント対象を把握するにはIBMサイトのライセンスインフォメーション（英語）で対象製品を検索するか、個別に取引先にご確認ください。 図11：「RVU課金単位」はカウント対象が製品ごとに異なる。 まとめ IBMソフトウェアのライセンス体系と課金体系に関して簡単な解説をしました。 従来は一度構築したシステムを長期間使用することが多く、永久ライセンス（所有）にメリットがありましたが、昨今の IT環境の変化の速さやデータ量の増加、システムのライフサイクルの短期化などの背景から、期間限定ライセンスを採用することでメリットを享受できます。 期間限定ライセンスも選択肢に入れていただくことで、ご利用になる環境に最適なライセンスを選択できるようになります。ご不明な点がございましたら、以下の窓口までお問い合わせください。 お問い合わせ この記事に関するお問い合わせは、以下のメールアドレスまでご連絡ください。 エヌアイシー・パートナーズ株式会社E-Mail：voice_partners@niandc.co.jp .highlighter { background: linear-gradient(transparent 50%, #ffff52 90% 90%, transparent 90%); } .anchor{ display: block; margin-top:-20px; padding-top:40px; } .btn_A{ height:30px; } .btn_A a{ display:block; width:100%; height:100%; text-decoration: none; background:#dceefe; text-align:center; border:2px solid #51aafd; color:#FFFFFF; font-size:16px; font-weight:normal; border-radius:16px; -webkit-border-radius:16px; -moz-border-radius:16px; transition: all 0.5s ease; } .btn_A a:hover{ background:#FFFFFF; color:#51aafd; margin-left:0px; margin-top:0px; border:2px solid #51aafd; box-shadow:0px 0px 0px 0px #FFFFFF inset; } .btn_B{ height:30px; } .btn_B a{ display:block; width:100%; height:100%; text-decoration: none; background:#085399; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; font-weight:normal; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #085399 ; transition: all 0.5s ease; } .btn_B a:hover{ background:#085399; color:#999999; margin-left:0px; margin-top:0px; border:1px solid #FFFFFF; box-shadow:0px 0px 0px 4px #085399 ; } .btn_CTA{ height:30px; margin-bottom:40px; width:450px; } .btn_CTA a{ display:block; width:100%; height:100%; text-decoration: none; background:#6200f5; text-align:center; border:1px solid #FFFFFF; color:#FFFFFF; font-size:16px; border-radius:50px; -webkit-border-radius:50px; -moz-border-radius:50px; box-shadow:0px 0px 0px 4px #6200f5; transition: all 0.5s ease; } .btn_CTA a:hover{ background:#bf94ff; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #bf94ff; } figure{ text-align:center; } figcaption{ font-size:80%; }
こんにちは。 てくさぽBLOGメンバーの村上です。 本ブログは、IBM Power Virtual Server をトライしてみた内容や感想をご紹介するブログです。 シリーズ化していますので、まずインデックスのご紹介をします。 インデックス ・IBM Power Virtual ServerでAIX環境を作ってみた ・IBM Power Virtual ServerのAIX環境にSWを導入してみた ・IBM Power Virtual ServerのAIX環境を日本ロケールにしてみた ・IBM Power Virtual ServerのAIX環境をバックアップしてみた（Part.1） ・IBM Power Virtual ServerのAIX環境をバックアップしてみた（Part.2） ・IBM Power Virtual ServerのAIX環境とIBM Cloud x86環境を接続してみた ←今回 今回は、Power Virtual ServerのAIX環境を IBM Cloud の x86環境と接続する方法をご紹介します。 セクション 以下の1)～6)のセクションに分けてご紹介します。 1） 接続イメージの説明 2） Direct Link Connect の説明 3） Direct Link Connect の作成 4） Caseを利用した接続依頼 5） VSI for VC の作成 6） AIX環境とx86環境の接続確認 最後に お問い合わせ 検証はAIXのインスタンスで行いましたが、IBM i のインスタンスでも同等の手順で操作を行うことができます。 利用したクライアント端末（私のPC）は、Windows10 pro バージョン2004（検証当時）です。 1) 接続イメージ の説明 Power Virtual Server のAIX環境と IBM Cloud の x86環境 はロケーションが異なる別のサービスで、ネットワークは直接つながっていません（2021年11月時点）。 そこで、お互いの環境を接続する方法が IBM Cloud から提供されています。 Direct Link Connect を利用する方法です。 今回は、上記の図の青色の線「Direct Link Connect」 を作成し、オレンジ色のubuntuサーバ（仮想サーバ・インスタンス(VSI)）とAIXサーバを接続することが目的です。IBM Cloud環境の「仮想プライベート・クラウド(VPC)」と「仮想サーバ・インスタンス(VSI)」は未作成だったので、新規に作成し手順もブログ内に残しました。 2) Direct Link Connect の説明 Direct Link Connect と Power Virtual Server は全く別のサービスですので、Direct Link Connect は新規に作成する必要があります。 Direct Link Connect は IBM Cloud のポータルから作成（契約）します。 1)でも記載した通り、Power Virtual Server は IBM Cloud の x86環境と異なるコロケーションサイトを利用しており、ネットワークも直接つながっていません。そのため、Direct Link Connect を 契約し設定することで x86環境と接続することが可能となります。 Direct Link Connect には、従来からある「Classic」と新しく提供が開始された「2.0」があり、どちらも無料で利用できるので、今回は新機能が充実している「2.0」を利用します Direct Link Connect 利用条件（IBM Cloud 柔らか層本20211124版 p.85より） ・1データセンターあたり、10Gbps ポート x 2回線(HA) まで無料 ・Global routing を利用しても追加費用は不要 ・Direct Link Connect の申請時、「Network Provider」は「IBM Power Virtual Server」を選択すること（「3) Direct Link Connect の作成」 でも触れます） 3) Direct Link Connect の作成 では早速、Direct Link Connect を作成します。 ・IBM Cloud にログインし、左上にある「ナビゲーション・メニュー」→「相互接続性(Interconnectivity)」を選択します。 相互接続性(Interconnectivity) の画面に移動しました。 ・「Direct Link」を選択します。 ・「Direct Linkの注文」を選択します。 ・「Direct Link Connect」を選択します Direct Link Connect の構成パラメーターを選択する画面に移動しました。 ・「リソース」情報は以下を入力・選択します。 ＞ Direct Link 名：tok-powervs（任意の文字列） ＞ リソース・グループ：Default ここから、Direct Link Connect の構成パラメータを設定していきます。 ・「ゲートウェイ」では以下の順番で選択します。 ＞ ジオグラフィー：APAC ＞ 市場：Tokyo ＞ タイプ：すべて ＞ サイト：Tokyo 4 ＞ 経路指定：ローカル（グローバルを選択すると別リージョンへ接続可能） プロバイダー：IBM POWER VS 速度は、50Mbps~10Gbps まで8種類から選択可能です。どの速度でも金額は変わりません。IBM推奨は1Gbps以上です。 ・速度とポート(1つ)を選択します。 ＞ 速度：1Gbps（10Gbpsにしようかと思いましたが、何となく遠慮してみました） ＞ ポート：SL-TOK04-POWERIAASLITE-1-1-(ASR1) ※ 選択するポートは「速度範囲」が当てはまるものを選びます。今回は、どのポートでも当てはまりますので一番上のポートを選びました。 ・「請求処理」で「従量制」を選択します。 ・「BGP」は以下の通り選択および入力します ＞ BGPピアリング・サブネット：「IPの手動選択」を選択 ＞ 範囲：「169.254.0.0/16」を選択（169.254.0.0/16 から） ＞ 自分のIPv4 CIDR：「169.254.0.2/30」を選択 ＞ IBM IPv4 CIDR：「169.254.0.1/30」を選択 ＞ BGP ASN：「64999」を入力 ※ BGPピアリングは「169.254.0.0/16 」から範囲を指定します。今回は特に決めごともないので自由に設定しました。 ※ BGP ASNは Direct Link Connect の構成ガイドにある通り、「64999」を指定します。 ・「接続」は初期状態のまま変更しません。 ここまで入力が出来たら構成パラメータの設定は完了です。 ・画面の右側に表示されるサマリーを確認し「作成」ボタンをクリックします。 Direct Link Connect の作成が受け付けられたメッセージが出力されます。 暫く待つと Direct Linkの「状況」が「構成中」→「プロビジョン済み」に代わります。作成したDirect Link名「tok-powervs」 をクリックし詳細画面を表示します。 下記の詳細情報は「4) Caseを利用した接続依頼」で利用しますので、このまま表示させておくかコピペしておきます。 Direct Link Connect の作成が完了しました！ 4) Caseを利用した接続依頼 次に、Power Virtual Server のAIX環境とDirect Link Connect の情報を紐付けるための作業を行います。この作業は、IBM Cloud のWEBポータル画面やIBM Cloud CLI 、API からは実施できません。Case を利用して、IBMのSEさん(？) へ接続のリクエストを出します。 Caseとは、IBMのサポートコミュニティの「問い合わせ」のことです ・IBM Cloud のWEBポータル画面の右上にある「サポート」をクリックします。 ・「Caseの作成」をクリックします。 ・「リソース」を選択します。 ・「Caseの作成」画面で以下を選択し「次へ」をクリックします。 ＞ トピック：「Power Virtual Server」をプルダウンから選択 ＞ 名前：「Power Virtual Server-g5」にチェックを入れる 下記の画面に移動したら、依頼内容を記載することができます。 Caseに依頼する情報は、「3) Direct Link Connect の作成」の最後に表示した詳細情報を利用し、以下のように記載しました。Case は英語で記載する必要があります。 実は、日本語でCaseを依頼してしまったことがあったのですが（英語で記入することをすっかり忘れていました）、担当SEさんが丁寧に英語に翻訳してくださって「質問はこういう意味であっていますか？」と返信が来ました。優しいです。 Caseの記載方法はQiitaのブログを参考にさせてもらっています。 サブジェクト：PowerVS : Direct Link 2.0 Request 説明： <Inquiry regarding Direct Link Connect for PowerVS> I ordered Direct Link Connect from IBM Cloud portal and its provisioning has finished. The detail information is as follows. Please proceed at Power VS side to establish Direct Link Connect. Thanks. --- Data creaged : Tue,Mar 2,2021,13:49:39 JST Resource group : Default Provider : IBM POWER VS Routing : Local Speed : 1 Gbps Billing : Metered User CIDR : 169.254.0.2/30 IBM CIDR : 169.254.0.1/30 BGP ASN : 64999 IBM ASN : 13884 Port : SL-TOK04-POWERIAASLITE-1-1-(ASR1) Location : Tokyo 4 Service key : （「サービス・キー」にある値を記載します） BGP status : Idle VLAN : 3921Connected VLAN : CIDR public-192_168_187_32-29-VLAN_2032 : 192.168.187.32/29 ・記載が完了したら「Caseの作成」ページの一番下にある「次へ」をクリックします。 ・記載した内容を確認し「Caseの送信」をクリックします。 下記のメッセージが出力されたらCaseによる申請が完了しています。 数日後・・サポート・センターよりPower Virtual Server 側の接続が完了されたお知らせが来ました。 依頼内容を間違えてしまったのと少しのんびりやっていたので、接続完了まで5日くらいかかりました。Advanced Supportに入っていないので、対応はクイックではない印象ですが、Caseの担当SEさんより私の方がのんびり返信しているので問題ないです。 修正がなければ、2日程度時間を用意していれば確実に接続してもらえそうです。 IBM CloudのWEBポータル画面ではBCPのステータスが「確立済み」になっていました。 Direct Link Connect とPower Virtual Server の接続が完了しました！ 5) VSI for VPC の作成 Direct Link Connect がPower Virtual Server と接続できたので、IBM Cloud の x86環境とちゃちゃっと接続したいところではありますが、実はまだ仮想プライベート・クラウド(VPC)もIBM Cloud のx86環境(仮想サーバインスタンス(VSI)) もありません。。 そのため、この検証のためにx86環境を作っていきます。画面ショットを取得していない部分は文字のみで説明しています。 ・「ナビゲーションメニュー」から「VPCインフラストラクチャー」を選択します。 ＞ 左のメニューから「VPC」を選択し、「作成」をクリックします。 ・「新規仮想プライベート・クラウド」の画面で以下のように入力・選択します。 ＞ 名前：tok-vpc（任意の名前でOK） ＞ リソース・グループ：Default（変更なし） ＞ タグ：（記載なしのまま） ＞ Region：「東京」にチェック ＞ デフォルト・セキュリティー・グループ：「SSHを許可」「Pingを許可」にチェック ＞ クラシック・アクセス：「クラシック・リソースへのアクセスを有効にします」は無効 ＞ デフォルトのアドレス接頭部：「各ゾーンのデフォルト接頭部の作成」にチェック ・「サブネット」の項目では「サブネットの追加」をクリックします。 ・画面の左に「VPC用の新規サブネット」が表示されるので以下の情報を入力し「保存」をクリックします。 ＞ 名前：tok-vpc-subnet（任意の名前） ＞ ゾーン：「東京1」（東京1~3まで選択できます） ＞ リソース・グループ：Default（初期値のまま） ＞ タグ：（記載なしのまま） ＞ IP選択範囲 ＞＞ アドレス接頭部：10.244.128.0/18 ＞＞ アドレスの数：256 ＞＞ IP範囲：10.244.1.0/24 ＞ ルーティング・テーブル：（記載なしのまま） ＞ サブネット・アクセス制御リスト：（記載なしのまま） ＞ パブリック・ゲートウェイ：「接続済み」にチェック 保存が完了したらVPCの作成承認画面になりますので「仮想プライベート・クラウドの作成」をクリックしVPCを作成します。 仮想プライベート・クラウド(VPC)の作成が完了しました！ 続いて、VPCの中に仮想サーバ・インスタンス（VSI）を作成します。 ・「カタログ」に「virtual server」と入力するとリストに「Virtual Server for VPC」が出てくるので選択します。 「VPC用の新規仮想サーバ」の作成画面になります。 ・「詳細」では以下の通り入力・選択します。 ＞ 名前：tok-test-vsi（任意の名前でOK） ＞ リソース・グループ：Default ＞ タグ：（記載なしのまま） ＞ ロケーション：東京1（東京1~3が選択できます） ＞ 仮想サーバのタイプ：パブリック ＞ プロセッサー・アーキテクチャー：x86 ・「オペレーティング・システム」と「プロファイル」は以下を選択しました。 （SSH鍵はAIXインスタンス作成時に作ったものを利用します） ・「配置グループ」「ブート・ボリューム」「データ・ボリューム」は初期値のままとします。 ・「ネットワーキング」では以下を選択します。 ＞ 仮想プライベート・クラウド：tok-vpc (先ほど作成したVPC) ・「ネットワーク・インターフェース」は初期値のままとします。 ここまで入力と選択ができたら左画面に出力されているサマリーを確認し「仮想サーバ・インスタンスの作成」をクリックしてVSIを作成します。 下記のような表示となります。 「状況」が「稼働中」になったら作成完了です（2分くらいで稼働中になりました）。 仮想サーバ・インスタンス(VSI)の作成が完了しました！ 次に、VSIをインターネット経由でアクセスできるようにするために、浮動IPアドレスを作成して割り当てます。浮動IPは、フローティングIPとも呼ばれています。 ・IBM Cloud ポータル画面の左上にある「ナビゲーション・メニュー」→「VPCインフラストラクチャー」→「浮動IP」を選択します。 ・「VPC用の浮動IP」の画面で「作成」をクリックします。 左画面に「浮動IPの予約」画面が出力されます。 ・「浮動IPの予約」画面では以下を選択・入力します。 ＞ 浮動IP名：tok-test-vsi-ip（任意の名前でOK） ＞ リソース・グループ：Default ＞ タグ：(記載なし) ＞ロケーション：「東京3」を選択 ＞ バインドするインスタンス：「tok-test-vsi」を選択(作成したVSI) ＞ ネットワーク・インターフェース：「en0」を選択 すべての設定ができたら「IPの予約」をクリック 浮動IPが割り振られました。 私のPCから作成した浮動IPに疎通できるか確認します。 疎通ができました。 浮動IPの設定が完了しました！ 6）AIX環境とx86環境の接続確認 いよいよ、Direct Link Connect と VPC を接続します。 ・「ナビゲーションメニュー」→「相互接続性(Interconnectivity)」→「Direct Link」で「Direct Link」の画面を表示します。 ・左の3つの点をクリックし「接続の追加」を選択します。 ・「接続の追加」で以下を選択・入力し「追加」をクリックします。 ＞ 接続の作成：アカウントに新規接続を追加します。 ＞ ネットワーク接続：VPC ＞ 地域：東京 ＞ 使用可能な接続：tok-vpc ＞ 接続の名前：tok-powervs（任意の名前） 以下のメッセージが出力されます。 2分程度経つと、状況が「作動可能」になります。 これで、VPC と Direct Link Connect がつながりました。 AIX環境とx86環境間でPing疎通ができるかの確認を行います。 ・AIXインスタンスにログインし、VSI環境にpingを投げます。 AIX環境とx86環境が疎通できました！ AIXサーバからVSIのubuntuサーバにssh でログインできることも確認できました。 今回で Power Virtual Server のブログは終了です。 検証を通して沢山の新しい知識を培うことができ、とても充実した機会でした！ 最後に 2021年は多くのお客様が、Power Systems のオンプレミス更改の考え方を見直すと同時に、 クラウド化を本格的に検討されました。 特に、中小企業のお客様は、クラウド化を選択することで得るメリットがお客様ご自身の負担やストレスを減らす手助けになられたように感じます。 2021年10月から、Power Virtual Server は安価な新ネットワークサービスが開始になったり、IBM i のライセンス移行オファリングが始まったりと、ユーザの目線に立った新機能が続々登場しています。 より身近なクラウドになってきました。 さて、2022年はアフターコロナが訪れるでしょうか。 海外旅行に行きたいです。 お問い合わせ この記事に関するご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社 技術支援本部 E-Mail：nicp_support@NIandC.co.jp
こんにちは。 てくさぽBLOGメンバーの村上です。 本ブログは、IBM Power Virtual Server をトライしてみた内容や感想をご紹介するブログです。 シリーズ化していますので、まずインデックスのご紹介をします。 インデックス ・IBM Power Virtual ServerでAIX環境を作ってみた ・IBM Power Virtual ServerのAIX環境にSWを導入してみた ・IBM Power Virtual ServerのAIX環境を日本ロケールにしてみた ・IBM Power Virtual ServerのAIX環境をバックアップしてみた（Part.1） ・IBM Power Virtual ServerのAIX環境をバックアップしてみた（Part.2） ←今回 ・IBM Power Virtual ServerのAIX環境とIBM Cloud x86環境を接続してみた 今回は、AIX環境のバックアップ手順のご紹介です。 検証環境で2種類のバックアップ方法を試しましたので、Part.1 とPart.2(本ブログ)に分けてご紹介しています。 本ブログでは 「AIX環境をバックアップしてみた Part.2」として、FlashCopy によるバックアップ手順をご紹介します。 セクション 以下の1)～4)のセクションに分けてご紹介します。 1） FlashCopy の説明 2） IBM Cloud CLI 導入 3） FlashCopy によるバックアップの事前準備 4） FlashCopy の実施 検証はAIXのインスタンスで行いましたが、IBM i のインスタンスでも同等の手順で操作を行うことができます。 利用したクライアント端末（私のPC）は、Windows10 pro バージョン2004です。 1) FlashCopy の説明 Power Virtual Server で実装する FlashCopy は以下の仕様となっています(IBM Cloud 柔らか層本 20210915版より）。 説明 ・IBM Cloud で提供されており、外部ストレージ装置のコピーを実施する ・バックアップ/リストアの時間が大幅に削減できる ・NWデータ転送量を削減できる 主な用途 ・データベース領域のバックアップ(容量が大きいものにおススメ) ・VM全体のバックアップ 対象 rootvg を含む任意のボリューム 保管場所 外部ストレージ装置 取得時の LPAR停止有無 不要 ※ ファイルの整合性担保のためにバックアップ前にはアプリの静止、LPAR停止が推奨される 制約事項 など ・リストア時はアプリ静止、LPAR停止が推奨 ・GUIは未実装であり、API呼び出しでのみ実行可能(2021年9月 時点) ・FlashCopy 先のストレージは無償で利用可能 ・インスタンス削除と同時にFlashCopy データも消失する FlashCopyとは、「Snapshot 」「Clone 」「Point in time Copy」とも呼ばれ、ある一時点のボリュームのコピーを作成する機能です。コピー元とコピー先は異なるLUN(ストレージのボリューム単位)を使用することができ、バックアップ手法として利用されています。 FlashCopy 先のディスクは課金されず無料で利用することができますが、バックアップデータの実体をWEBインターフェースの画面で確認することはできません。また、インスタンスを削除するタイミングで FlashCopy のデータも消失するため、バックアップデータはICOSなどへのデータのエクスポートが推奨されています。 2) IBM Cloud CLI 導入 FlashCopy を実施する前に、実施環境(ローカルPC)の準備を行います。 Power Virtual Server の FlashCopy は「IBM Cloud API 」を利用します。残念ながらWEBインターフェース画面では FlashCopy 機能が提供されていません（2021年9月時点）。 FlashCopy の実行は「IBM Cloud API 」で行いますが、Power Virtual Server へのログインやFlashCopy に必要なパラメータ取得などで 「IBM Cloud CLI 」も利用します。 IBM Cloud API とは 仮想サーバを簡単にデプロイおよび構成するために利用されるAPI（アプリケーション・プログラム・インターフェイス） ：利用する場合、モジュールとしてのインストールは不要 IBM Cloud CLI とは IBM Cloud のリソースを管理するためのCLI（コマンド・ライン・インターフェイス） ：利用する場合、モジュールとしてのインストールが必要 「IBM Cloud CLI 」を利用するためには、ローカルPCに「IBM Cloud CLI」のモジュールをインストールする必要があります。 では、IBM Cloud CLI のインストール作業を行っていきます。 ・WEBブラウザーを利用して、GitHub の IBM Cloud リポジトリーにアクセスします。 ・IBM Cloud CLI を導入するPCのOSを選択します（私のPCは下記のピンク色で囲んだOS）。 IBM Cloud CLI のインストーラーがローカルPC内にダウンロードされました。 ※ 上記は2021年1月時点のバージョンで、2021年9月時点の最新版は v2.0.3 です。 ・ローカルPC内にダウンロードしたインストーラーをダブルクリックして起動します。 「IBM Cloud CLI の インストール・ウィザード」が表示されます。 ・「Next」をクリックします 「License Agreement 」の画面が表示されます ・「I accept the terms in the license agreement」にチェックを入れます ・「Next」をクリックします 「Ready to Install the Program」の画面が表示されます。 ・「Install」をクリックします 「The installation completed successfully」のメッセージでインストールが正常に終了した画面が表示されます。 ・「Finish」をクリックします IBM Cloud CLI のインストールが完了です！ IBM Cloud CLI が正常にインストールされていることを確認します。 これ以降の作業では、CUI を利用して検証を行います。CUI は Windows標準搭載の「Windows PowerShell」を利用します。（※画面ショットの 固有の値はマスキングします） ・Windows PowerShell を起動し IBM Cloud CLI のバージョン確認コマンドを入力します。 > ibmcloud -v 上記の通り、IBM Cloud CLI 1.3.0 でした。私のPC内の IBM Cloud CLI は、2021年1月頃に導入したので、かなりバージョンが古くなっているようです。 ・IBM Cloud CLIのバージョンアップを行います。 > ibmcloud update →「今すぐ更新しますか？[Y/n]」で「Y」を入力 自動でIBM Cloud CLI のインストーラーが立ち上がります。 ・インストールウィザードの画面で「Next」→「Finish」と進めます ・インストールウィザードが終了したらIBM Cloud CLI のバージョンを確認します。 > ibmcloud -v IBM Cloud CLI 2.0.3 にUpdateできていることが確認できました。 次に、Power Virtual Server 専用のプラグイン（power-iaas/pi ）を導入します。IBM Cloud CLI で Power Virtual Server を操作するためには、専用のプラグインが必要になるためです。 ・ibmcloud コマンドでプラグインの一覧を表示します > ibmcloud plugin repo-plugins -r "IBM Cloud" ・「power-iaas/pi」が「未インストール」になっていることを確認し「power-iaas/pi」を導入します。 > ibmcloud plugin install power-iaas プラグインが導入出来ました。 ・導入したプラグインのバージョンを確認します > ibmcloud plugin list 「状況」欄に「更新が使用可能です」と出力されている場合、プラグインのバージョンが古くなっています。 ・プラグインをUpdateします > ibmcloud plugin update 最新バージョンにUpdateでき、「状況」が空欄になりました。 IBM Cloud CLI の準備は完了です！ 3) FlashCopy によるバックアップの事前準備 FlashCopy を実施する前にFlashCopyに必要なパラメーターを用意します（パラメータは IBM Cloud API Docs の「Create a PVM instance snapshot」に記載されています）。 単純に出力できないパラメーターは変数に代入していきます。 FlashCopy に必要なパラメーター(変数)は以下となります。 内容 パラメーター/ 変数 ①IBM Cloud へログイン - ②認証情報 A. $TOKEN : IBM Cloud IAM アクセストークン B. $CRN：Cloud Resource Name ③Pathのパラメータ C. $CLOUD_INSTANCE_ID ：Cloud Instance ID D. $PVM_INSTANCE_ID：PVM Instance ID ④Bodyのパラメータ ・name ・description E. $VOL_ID：Volume ID それでは、上記の①～④の順番で、パラメータ(変数）を取得していきます。 ① IBM Cloud へログイン ・IBM Cloud へログインします（対話式コマンドでログインを行います）。 > ibmcloud login →「Email」にIBM Cloud ログインIDを入力 →「Password」にIBM Cloud ログイン時のパスワードを入力 →「アカウント選択」で利用するアカウントが複数ある場合はアカウントNo.を選択 IBM Cloud にログインができました。 ② 認証情報 の取得 ②では、Power Virtual Server の認証情報を取得します。 Power Virtual Server で IBM Cloud API を利用するためには、すべてのリクエストに 「IBM Cloud IAM アクセストークン」 と 「CRN※」が必要で、これは認証情報と呼ばれます。 ※ CRN：Cloud Resource Name の略。Power Virtual Server のインスタンスID と テナントIDが含まれたもの。 A. IBM Cloud IAM アクセストークンの取得 ・IBM Cloud CLI を利用しアクセストークンを出力します。 > ibmcloud iam oauth-tokens ・必要なストリングをjsonを利用して抽出し、結果を「$TOKEN 」変数に入れます。 > $TOKEN = (ibmcloud iam oauth-tokens --output JSON | ConvertFrom-Json ).iam_token IBM Cloud IAM アクセストークンのパラメータ変数「$TOKEN」 が取得できました。 B. CRNの取得 ・IBM Cloud CLI を利用しCRNを出力します。 > ibmcloud pi service-list ・出力したCRN ID のストリングを抜き出し「$CRN」変数に代入します。 > $CRN = ( ibmcloud pi service-list --json | ConvertFrom-Json).crn 「$CRN」が取得できました。 ③ Pathのパラメータ取得 ③では、FlashCopy の実行文の Path 部分に設定するパラメータを取得します。 C. Cloud Instance ID の取得 Cloud Instance ID を取得するためには「テナント ID」が必要です。「テナント ID」は「IBM Cloud のアカウントID」のことで、以下の通り、IBMCloud のWEB画面でも確認できます(https://cloud.ibm.com/account/settings)。 上記で確認できるIDをIBM Cloud CLI とAPI で取得します。 ・IBM Cloud CLI を利用し「$TENANT_ID」変数に IBM Cloud アカウントID(テナントID)を代入します。 > $TENANT_ID = (ibmcloud account show --output JSON | ConvertFrom-Json ).account_id ・IBM Cloud API を利用し、テナント状況「$TENANT_STATE」変数を作成します。 $TENANT_STATE = ( ` >> curl.exe -X GET ` >> https://tok.power-iaas.cloud.ibm.com//pcloud/v1/tenants/$TENANT_ID ` >> -H "Authorization: $TOKEN" ` >> -H "CRN: $CRN" ` >> -H "Content-Type: application/json" ` >> | ConvertFrom-Json ) ・「$TENANT_STATE 」の「cloudInstances」キーに「cloudInstanceID」が含まれているため(上記のピンク色で囲んだ値)、この値を「$CLOUD_INSTANCE_ID」変数に代入します。 > $TENANT_STATE.cloudInstances > $CLOUD_INSTANCE_ID = ( $TENANT_STATE.cloudInstances).cloudInstanceID 「$CLOUD_INSTANCE_ID」 が取得できました。 D. PVM Instance ID の取得 PVM Instance ID は、Power Virtual Server のインスタンスID のことです。下記の通り、IBM Cloud のWEB画面からも確認できます。 ・IBM Cloud CLI を利用してインスタンス情報を取得し結果を「$INSTANCE」変数に代入します。 > $INSTANCE = ( ibmcloud pi instances --json | ConvertFrom-Json ) ・「$INSTANCE」変数の「Payload.pvmInstances」キーの配下「pvmInstanceID」キーの値を「$PVM_INSTANCE_ID」変数に代入します。 >$PVM_INSTANCE_ID = ( $INSTANCE.Payload.pvmInstances.pvmInstanceID) 「$PVM_INSTANCE_ID」 が取得できました。 ④ Body のパラメータ取得 ④では、FlashCopy 実行文の Body 部分に設定するパラメータを取得します。 「name」と「description」は任意の値で構いません。 ・ name : test ・ description : snapshot-test と設定することにしました。 E. Volume ID の取得 ややこしいのですが、Volume ID は Volume Name を指しています。実際に、Volume ID というパラメーターもあるので間違えないように注意が必要です。Volume ID は、以下の通りWEB画面でも確認できます。 ・IBM Cloud CLIを利用してインスタンス名をリストし、インスタンスに紐づくボリュームを調べます。 > ibmcloud pi instances > ibmcloud pi instance-list-volumes AIX72-test ・上記のピンク色で囲んだ値を「$VOL_ID」変数に代入します。 > $VOL_ID =(ibmcloud pi instance-list-volumes AIX72-test --json |ConvertFrom-Json ).Payload.volumes.name 「$VOL_ID」 が取得できました。 4) FlashCopy の実施 すべてのパラメータが取得できたので、いよいよ(やっと) FlashCopy を実行します。 ・念のため、3)で取得したパラメータ（変数）がきちんと出力されるか確認します。 FlashCopy の実行文は IBM Cloud API Doc に記載がある以下の文です。この実行文を例に、上記の取得したパラメーター（変数）を当てはめて FlashCopy を実行します。 curl -X POST https://us-east.power-iaas.cloud.ibm.com/pcloud/v1/cloud-instances/ ${CLOUD_INSTANCE_ID}/ pvm-instances/{pvm_instance_id}/snapshots -H 'Authorization: Bearer <>' -H 'CRN: crn:v1...' -H 'Content-Type: application/json' -d '{ "name": "VM1-SS", "description": "Snapshot for VM1", "volumeIDs":["VM1-7397dc00-0000035b-boot-0"] }' 上記の実行文の通り、色々と試してみましたが、Body の部分( -d 以降) が PowerShell ではうまく実行できません。 そのため、Qiitaのブログを参考にさせていただき、Body は変数に当てはめて FlashCopy を実行しました（他の部分もかなり参考にさせていただいているブログです！）。 ・FlashCopy 実行文のBody の部分のみ変数に当てはめます。 > $BODY = '{"name": "test", "description": "snapshot-test","volumeIDs": ["' + $VOL_ID + '"] }' ・IBM Cloud API を利用して、FlashCopy を実行します。 > ( $BODY | curl.exe -X POST ` >> https://tok.power-iaas.cloud.ibm.com/pcloud/v1/cloud-instances/ $CLOUD_INSTANCE_ID/pvm-instances/$PVM_INSTANCE_ID/snapshots ` >> -H "Authorization: $TOKEN" ` >> -H "CRN: $CRN" ` >> -H "Content-Type: application/json" ` >> -d `@- ) FlashCopy が完了しました！ ・FlashCopy が正常に完了していることを IBM Cloud API を利用して確認します。(参考「Get all snapshots for this PVM instance」) > curl.exe -X GET ` >> https://tok.power-iaas.cloud.ibm.com/pcloud/v1/cloud-instances/ $CLOUD_INSTANCE_ID/pvm-instances/$PVM_INSTANCE_ID/snapshots ` >> -H "Authorization: $TOKEN" ` >> -H "CRN: $CRN" ` >> -H "Content-Type: application/json" 上記のピンク色で囲んだ値が FlashCopy の結果を示しています。 「percentComplete」が「100」、「status」が「available」であれば、FlashCopy が成功しています。 FlashCopy が成功していることを確認できました！ この後、AIX環境に変更を加えて、取得したFlashCopy のデータのリストアを行い、変更前の状態に戻っているところまで確認しましたが、長くなりましたのでブログはここで終了します。 リストアは「Restore a PVM Instance snapshot」を参考にし、今回のバックアップ手順で取得したパラメータを利用すると簡単に実行できました。 次のブログでは、IBM Cloud IA環境との接続手順をご紹介します。↓ ☆準備中です☆【やってみた】IBM Power Virtual Server AIX環境と IBM Cloud IA環境を接続してみた 最後に 今回の検証は、IBM Cloud API Docs や Qiita に投稿されているブログ を参考にさせていただきました。 Part.1 のImage Capture を利用したバックアップ方法と比べると、今回は慣れないAPIを利用したこともあり調査にとても時間が掛かりました。また、バックアップ処理自体はあっという間でも事前準備にも時間を取られました。 そのため、スピードを求められる開発環境や検証環境には、Image Capture の利用がおすすめです。 実際の運用に組み込むとしたら、FlashCopyでしょうか。 OS、ストレージ、データベース、アプリケーション。バックアップ対象も方法も様々で、バックアップ方法のドキュメントを読んでもイメージが湧かないことがよくありますが、実際に検証をしてみることで、イメージが湧き、メリットやデメリットを捉えることができるので、お客さまにも伝えやすくなります。 今後も時間を見つけ、こつこつ検証をしていきたいと思います。 お問い合わせ この記事に関するご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社 技術支援本部 E-Mail：nicp_support@NIandC.co.jp
