特集・ブログ
NI+C Pコーポレートサイトに掲載している最新コラム・ブログ・ホワイトペーパーの一覧です。 (さらに…)
こんにちは。エヌアイシー・パートナーズ 村上です。 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を導入してみた：Azure Stack HCI構築編 第二回：【やってみた】Azure Stack HCIを導入してみた：管理機能編 ＊本編 第三回：【やってみた】Azure Stack HCIを導入してみた：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回シリーズで検証で得られた知見をお伝えします。 (さらに…)
こんにちは。 てくさぽBLOGメンバーの佐野です。 継続してお問い合わせの多い、IBMソフトウェア (Passport Advantage：以下 PA) のライセンス体系について説明いたします。 全網羅的ではなく代表的なもののみの説明としますので、載っていない製品や課金体系については個別にお問い合わせください。 １．IBMソフトウェア (PA) のライセンスと ソフトウェア・サブスクリプション＆サポート IBMソフトウェアを利用するために必要な権利は、以下に大別されます。 ライセンス：ソフトウェアを使用する権利 製品サポート：製品に対する各種問い合わせ、トラブル対応、バージョン・アップの権利 ※製品サポートを「IBMソフトウェア・サブスクリプションおよびサポート (以下 SS&S)」と呼びます。 ライセンスと SS&S には、それぞれ以下の種類があります。 【ライセンス】 永久ライセンス：Perpetual License (買い切り型ライセンス) 期間限定ライセンス：Term License (期間使用型ライセンス) 【SS&S】 継続SS&S：製品サポートを継続する場合に必要 新規SS&S：SS&Sの契約を停止した（空白期間が生じた）製品サポートを再開する場合に必要 永久ライセンスを購入すると対象ソフトウェアを永久的に使用できます。また、1年間の SS&S が付加されているので、1年目は製品サポートを受けることができます。 2年目以降は、継続SS&Sを購入することで製品サポートを継続して受けられます。(下図Aのケース) 継続SS&S を購入しないで製品サポートに空白期間が生じたのちに再開する場合は、新規SS&S を購入する必要があります。(下図Bのケース) なお、SS&S の購入は1年単位となります。 期間限定ライセンスは以下が提供されます。 指定された期間に対してのソフトウェア使用権 (ライセンス) 指定された期間中の製品サポート (SS&S) ライセンスとSS&Sが必ず含まれるため契約期間中に製品サポートも受けられる点が、永久ライセンスと異なります。 また、期間限定ライセンスは以下の種類があります。 サブスクリプションライセンス (Subscription License) 月額ライセンス (Monthly License) 期間限定ライセンス (Fixed Term License) それぞれの特徴は下表になります。 サブスクリプション ライセンス (Subscription License) 月額ライセンス (Monthly License) 期間限定ライセンス (Fixed Term License) 契約期間 12か月から60か月 1か月から60か月 12か月の固定期間 最短期間 12か月 1か月 12か月の固定期間 途中解約 不可 30日前に書面で通知 30日前に書面で通知 製品サポート (SS&S) あり あり あり スモールスタートするプロジェクトやPoCプロジェクトにおいて期間限定ライセンスを採用することで以下のメリットがあります。 初期投資を抑えることができる 必要なくなったら停止ができる 特に、DXの実装段階においてはプロジェクトを素早く立ち上げ、効果がなければやめるという進め方が多くなります。 このようなケースでは期間限定ライセンスのご利用が適しています。 一方、長期利用をする場合に期間限定ライセンスを採用することは永久ライセンスと比べてコスト増となることが多くなります。 プロジェクトの特徴、特性に合わせて、期間限定ライセンス/永久ライセンスを選択し最適なものを選びましょう。 ２．課金体系 次は課金体系です。 IBMソフトウェアの課金体系については こちら にも記載がありますが、なんだか堅苦しい記述になっているのでざっくり解説をしていきます。 課金体系としては、大きく以下3つの種類に分類できます。 ユーザー課金 サーバー課金 その他 製品によってはユーザー課金とサーバー課金を組み合わせて買う必要があります。 具体的にもう少し詳しく見ていきましょう。 ユーザー課金 Authorized User (許可ユーザー) 許可ユーザーは名前の通り、ソフトウェアを利用するユーザー数に応じた課金単位です。 どのPCからアクセスするのか、ではなく、利用者個人に紐付きますので、あるユーザーが PC だけでなく iPhone からアクセスをしても1ライセンスとなります。 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 ですが、Db2 は後述のプロセッサー・バリュー・ユニット課金などでも購入が可能です。 Concurrent User (同時接続ユーザー) 同時接続ユーザーの場合にはサーバーなどに一時点で同時に接続しているユーザー数分のライセンスとなります。 例え10ユーザーいたとしても、同時に利用しているのが2ユーザーなのであれば2ライセンスとなります。 代表的な製品としては、SPSSがこの課金単位での購入が可能です。 User Value Unit (ユーザー・バリュー・ユニット) ユーザー・バリュー・ユニット (UVU) でのユーザー数のカウントは Authorized User と同じ考えですが、製品によって以下のポイントが異なる場合があります。 ユーザーの種類 (例：社内ユーザー、社外ユーザー) 総ユーザー数に応じた階段式の係数 (例：1,000ユーザーまでは係数1、1,001から5,000ユーザーまでは係数0.8、それ以降は係数0.6、など) 製品によってカウント方法や上記の係数などが異なりますので、この課金単位の製品を購入する場合には ライセンスインフォメーション から対象製品を検索するか、個別に取引先にご確認下さい。 代表的な製品としては、IBM Security Verify Access（旧製品名 ISAM、TAM) があります。 サーバー課金 Install (インストール) インストール課金単位はソフトウェアをインストールしたマシン数に対する課金です。 1台に導入するのであれば数量は1です。利用するユーザー数は関係がありません。 代表的な製品としては、Netcool OMNIbus の管理サーバーがこの課金単位です。 Processor Value Unit (プロセッサー・バリュー・ユニット：PVU) 課金単位に関する問い合わせで一番数が多いのが、この PVU課金に関する問い合わせです。 PVU課金では、利用する CPU に応じた係数が決まっています。(係数表は こちら に掲載されています。) この表の係数を元に、コア数を掛け算した数量のライセンス購入が必要となります。 例えば、Intel Xeon E5-2609v4 であれば、最大2ソケットマシンにしか搭載できないので、先の PVU表からコアあたりの PVU値は 70PVU となります。 この CPU は 8コアCPU であるため、1CPUサーバーの場合には、70PVU / コア×8コア / CPU×1CPU ＝560PVU となります。 Intel CPU の場合、4ソケットマシンには100PVU、4ソケットを超えると 120PVU と、係数が変わるので、数量を確定するためには何ソケットサーバーなのかを調べておく必要があります。 気を付けないといけないのは、サーバー更改や仮想化統合をする場合です。 割り当てコア数は変わっていなくても、物理サーバーのソケット数が変わることで PVU値が上がってしまうケースがありますので注意が必要です。 また、新しい CPU は搭載しているコア数の最小数がどんどん増えていますので、現行機は2コアで稼働しているけれど更改後は4コアで稼働 (＝不足分の追加ライセンスが必要)、なんてこともよくあります。 多くの IBMソフトウェア製品がこの課金単位を利用しています。 Managed Virtual Server (管理対象仮想サーバー) この課金単位はインストール課金と同じ考え方になります。 数量はソフトウェアを導入する仮想サーバー数をカウントします。 下図の場合には2台の仮想サーバーにソフトウェアを導入するので、2ライセンスとなります。 なお、仮想環境ではなく物理サーバーが対象の場合には1ライセンスとしてカウントします。 この課金単位を使っている代表的な製品は、Netcool Operations Insight があります。 Virtual Processor Core (仮想プロセッサーコア) 仮想プロセッサーコア (VPC) 課金単位は、仮想サーバーに割り当てられたコア数 (仮想環境の場合、もしくは物理サーバーに搭載しているコア数 (物理サーバーの場合)をカウントします。 PVU課金と違って CPUソケット数や種類による係数はなく、単純にコア数をカウントするだけなので環境を選びません。 この課金単位を使うのは、Db2 Standard Edition や Cloud Pakシリーズ になります。 PVU課金のようにプラットフォームの影響を受けないので、計算がシンプルなことが特徴です。 その他 Client Device (クライアント・デバイス) クライアント・デバイス課金単位は、サーバーではなく一般的なユーザーが利用するような端末 (パソコンやスマートフォンなど) に限定した対象とする課金体系です。 サーバーを対象とする場合には別の課金単位を用意している場合がほとんどです。 Resource Value Unit (リソース・バリュー・ユニット：RVU) RVU課金単位は、製品によって何を課金対象とするのかが変わる厄介な課金単位です。 例えば、Netcool OMNIbus では監視対象の台数が RVU数となります。 似たような製品で、Tivoli Monitoring ではコア数が RVU数とカウントされます。 製品によってカウント方法が異なりますので、RVU課金の場合には何をカウント対象とするのかを個別の製品毎に ライセンスインフォメーション から対象製品を検索するか、個別に取引先にご確認下さい。 ３．まとめ IBMソフトウェアのライセンス体系と課金体系に関して簡単な解説をいたしました。 従来は一度構築したシステムを長期間使用することが多く、永久ライセンス (所有) にメリットがありましたが、昨今の IT環境の変化の速さや、データ量の増加、システムのライフサイクルの短期化などの背景から、期間限定ライセンスを採用することでメリットを享受することができます。 期間限定ライセンスも選択肢に入れて頂くことで、ご利用になる環境に最適なライセンスを選択できるようになります。 ご不明な点がございましたら弊社までお問い合わせください。 ※この記事は2021年12月21日時点の情報を元に作成しています。 この記事に関するご質問 エヌアイシー・パートナーズ株式会社 E-Mail：voice_partners@niandc.co.jp
こんにちは。 てくさぽBLOGメンバーの 村上です。 本ブログは、 IBM Power Systems 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 Sysems Virtual Server」をプルダウンから選択 ＞ 名前：「Power Systems 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 Systems 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
