特集・ブログ
こんにちは。てくさぽBLOGメンバーの高村です。 IBM の定例イベント「Think 2023」で発表された IBM watsonx はご存じでしょうか？ AI開発の最前線を走り続けている IBM Watson は、2023年7月に企業向けAI及びデータ・プラットフォーム IBM watsonx（以下 watsonx）のサービス提供を開始しました。なお、watsonx の概要は製品紹介ページで紹介していますので、是非ご覧ください。 今回は watsonx製品の一つ、生成AI開発プラットフォームを担う「IBM watsonx.ai」（以下 watsonx.ai）を使用し、その感想を二部構成でご紹介したいと思います。 Part1（本記事）では、watsonx.ai のご紹介とサービスのプロビジョニング、UI画面にてプロンプトを使ってみた感想を、Part2では、watsonx.ai を利用した Retrieval-Augmented Generation（RAG）検証をご紹介します。 乞うご期待ください。 目次 ビジネスにおける生成AIの活用 watsonx.aiとは？ プロンプト・ラボを使ってみる さいごに お問い合わせ ビジネスにおける生成AIの活用 2022年の ChatGPT公開を機に生成AI は脅威的なスピードで生活に普及されています。企業も生成AI をビジネスに取り入れる動きが加速しており、例えば、OpenAI社は企業向けに ChatGPT Enterprise、Microsoft社は Azure上で Azure OpenAI Service を提供しています。 このように企業向け生成AIサービスも次々発表されている状況で、企業はビジネスの目的に合ったサービスを選ぶことが重要になってきています。 それでは、生成AI を採用する際にどのような考慮点があるでしょうか。以下にいくつかご紹介します。 生成AI採用時の考慮点 回答精度の問題：生成AI は状況や文脈を完全に理解しておらず、適切な回答を生成することが困難となる場合があります。そのため、モデルのチューニングや精度の高い回答を出せるように指示を設計する仕組みが必要です。 他社との差別化：今後多くの企業が生成AI を活用したビジネスを展開していくと、他社との差別化がますます重要となります。ベンダー独自の大規模言語モデルを利用することは勿論ですが、AI開発の先駆者であるサード・パーティーが提供するモデルを利用できることなど、複数のモデルから選択できる点もポイントになります。 セキュリティ対策：ビジネスで生成AI を活用する上では機密情報の取り扱いを注意しなければいけません。個人情報を含んだ情報が他のユーザの回答に利用されることが無いよう、セキュリティ対策が求められます。 このように、企業が求める精度の高い AIモデルを実現でき、他社との差別化及び生産性向上を図ることが可能なサービスが watsonx.ai です。 watsonx.aiとは？ サービス提供形態 はじめにサービス提供形態をご紹介します。 2023年10月時点、watsonx.ai は IBM Cloud からの SaaS提供のみとなっています。また、watsonx.ai を利用するには従来から提供されている Watson Studio（機械学習モデルを開発するための統合環境）と Watson Machine Learning（機械学習環境）の2つのサービスが必要です。 IBM Cloud のカタログ上では「watsonx.ai」という名前のサービスは無く、Watson Studio をプロビジョニングし Watson Machine Learning を紐づけることで、watsonx.ai が利用できるようになります。 料金は Lite/Essentials/Standard のプランが提供されています。（2023年10月時点）Lite は容量制限のある無料プランです。機能を試したい場合はこのプランをご選択ください。Essennsials、Standard は以下の①②③を合計した料金プラン（月額請求）です。 ①プランの基本料金 ※Essentials の基本料金は$0/月です（2023年10月時点）②基盤モデルの利用料③Watson StudioとWatson Machine Learningの利用料 watsonx.aiの特徴 以下の図の通り、watsonx.ai は基盤モデルの選択から調整、テスト、デプロイまでを一貫して行うことができる AI開発スタジオです。 基盤モデル（Foundation Model） watsonx.ai は基盤モデル（Foundation Model）を利用した AI開発スタジオです。 従来の機械学習による AI開発は用途ごとにモデルを作成していましたが、基盤モデルによる AI開発は大量のデータで事前学習を行い、一つの基盤モデルを作成し、用途別に少量のデータでカスタマイズしモデルを作成します。これにより用途向けのモデルは少量のデータで学習が可能となり、今までのような学習時間やリソースを大幅に削減できます。 IBM独自の基盤モデル、サード・パーティーの基盤モデルを提供 watsonx.ai は IBM独自の基盤モデル、サード・パーティーのモデルを提供しており、用途によって選択することは勿論、最先端な技術をサービスに取り入れることが可能です。 2023年10月現在、IBM独自の基盤モデルは2つ、Hugging Face などのサード・パーティーの基盤モデルは7つ提供されています。詳細は「watsonx.ai で使用可能なサポート対象のファウンデーション・モデル」（IBMサイト）をご確認ください。 プロンプト・ラボ watsonx.ai では抽出や生成、分類などのタスクをプロンプトラボで調整します。 プロンプトラボには最大トークン数などのパラメータを調整する機能やサンプルプロンプトも提供されており、迅速なデプロイが可能です。こちらは後ほど試してみようと思います。 今後基盤モデルのチューニング・スタジオも提供予定です。アップデートが楽しみですね。 プロンプト・ラボを使ってみる watsonx.ai をプロビジョニングし、UI画面からプロンプト・ラボを使用してみましょう。（※前提としてIBM Cloudアカウントが作成されていることとします） IBM Cloud のカタログ画面から「Watson Studio」を検索し、クリックします。 料金プランはライトプラン、ロケーションは「ダラス（us-south）」を選択します。※基盤モデルの推論とプロンプト・ラボはダラスとフランクフルトのリージョンでのみ使用可能 以下の画面が表示されるので「Launch in」をプルダウンしてプラットフォームを「IBM watsonx」にします。 以下の画面が表示されるので閉じます。 以下の画面が表示されるので閉じます。 以下の画面で「新規プロジェクト +」をクリックします。 プロジェクト作成画面で「空のプロジェクトを作成」をクリックします。 新規プロジェクト作成画面で任意の名前を入力し「作成」をクリックします。 プロジェクトが作成されました。 左側メニューから「すべてのプロジェクトの表示」をクリックし、作成したプロジェクトを選択します。 「サービスおよび統合」を選択し「サービスの関連付け +」をクリックします。 「Watson Machine Learning」にチェックを入れサービスを関連付けます。 Watson Machine Learning が関連付けられました。 ホーム画面に戻り「ファウンデーション・モデルを試し、プロンプトを作成する」をクリックします。 サンプル・プロンプトから「Questions about an article」を選択し、命令箇所に命令と対象のArticleを入力します。（今回はサンプル・プロンプトを使用してみます） 「llama-2-70b-chat」は一つ以上の例を指定するとより効果的に機能するため、例の箇所に QuestionとAnswer の例を入力します。（このプロンプトは基盤モデル「llama-2-70b-chat」を指定しています） Question へ「トマトの栽培になぜマルチを使用すべきなのか」と入力し「生成」をクリックします。 Answer の箇所に回答が生成されました。（原文と照らし合わせると、適切な箇所を参考にして生成していることがわかります） なお、「モデルパラメータ」をクリックすると最大トークン数などのパラメータ調整もすることが可能です。 UI画面もわかり易く、サンプルをベースに目的のプロンプトを作成できそうです。他にもコールメモの要約やコード生成などのサンプル・プロンプトがありますが、ここでのご紹介は割愛させていただきます。 基盤モデルは IBM独自の基盤モデルやオープンソースの基盤モデルが選択できますが、どれを選べばよいのか迷うところです。基盤モデルを選択においては「watsonx.ai でのファウンデーション・モデルの選択」（IBMサイト）に考慮点が掲載されていますので、こちらを参考に選択いただければと思います。 さいごに いかがでしたでしょうか。watsonx.ai のご紹介とサービスのプロビジョニング、UI画面にてプロンプトを使ってみた感想をご紹介しました。 watsonx.ai には複数の基盤モデルが用意され、今後基盤モデルのチューニングスタジオもリリース予定されています。目的にあったモデルの選定、検証は考慮が必要ですが、カスタマイズの幅が広く、ビジネスの目的にあったAIモデルを実現できますね。 次回の Part2 では、watsonx.ai を利用した Retrieval-Augmented Generation（RAG）の検証結果をご紹介します。watsonx.ai をビジネスにどのように繋げられるかのヒントになると思いますので、ぜひご覧いただければ幸いです。 お問い合わせ この記事に関するご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社E-Mail：nicp_support@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:#eb6100; 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 #eb6100; transition: all 0.5s ease; } .btn_A a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }
こんにちは。てくさぽBLOGメンバーの高村です。 今回は IBM Cloud Schematics（以下 Schematics）を利用して IBM Power Virtual Server のプロビジョニングを検証してみました。 IBM Cloud Schematics とは、Infrastructure as a Code（以下 IaC）を提供する IBM Cloud のマネージドサービスです。IaC や Schematics などについてご存じでない方もいらっしゃると思いますので、順番にご紹介します。 目次 IaCとは？ Schematicsとは？ 検証の概要 Githubの設定 Schematicsワークスペースの設定・プランの実行 さいごに お問い合わせ IaCとは？ IaC はインフラストラクチャの設定や管理をコードで行うアプローチです。具体的には、サーバーやネットワークなどのインフラストラクチャをコードで定義し、必要な時に実行し展開・変更することができます。 IaC を利用するメリットとしては以下が挙げられます。 構築・管理の効率化： インフラストラクチャをコードとして管理することで構築・管理を自動化することができます。またコードを再利用することもできるため、複数の環境に対して同じ構成やリソース追加を効率的に構築することができます。 共有の容易化： IaC は通常、ソースコード管理システム（Githubなど）を使用してコードを管理します。これにより、チームメンバーとの共有・変更の管理が容易になります。 人為的ミスの削減： 人為的なミスのリスクが減り、変更の管理やインフラストラクチャの状態の監視も容易になります。 以下はコードが実行される流れを表した図です。作業者がコードを作成し、そのコードを Gitリポジトリなどにアップロードすると構成管理ツールによってコードが実行され、自動的に環境が構築される流れになります。 IaC を実現するためには構成管理ツールを利用します。代表的なツールとしては「Terraform」「Ansible」「chef」などがあります。以下に簡単にご紹介します。 Terraform： インフラストラクチャのコードを記述することで、インフラストラクチャの作成、構成、および変更を自動化します。Terraform は主に IaaS に焦点を当てており、インフラストラクチャの構成及び状態の管理に使用されます。 Ansible： 構成管理、アプリケーションのデプロイ、タスクのオーケストレーションなど、幅広い自動化タスクに使用されるツールです。主に構成管理とアプリケーションのデプロイに使用されます。 Chef： Chefサーバーとクライアントを使用して設定を管理します。主にシステム設定やソフトウェアの導入などの自動化に使用されます。 ツール毎に得意とする分野があり、使用目的や環境に応じて使い分けられています。これからご紹介する Schematics は上記の Terraform や Ansible の機能を統合し、IBM Cloud環境での IaC を実現するマネージドサービスです。 Schematicsとは？ Schematics は IBM Cloud のサービスの一つとして提供されるマネージドサービスです。 Schematics自体は無償サービスで、プロビジョニングしたリソースに対し費用が発生します。2023年8月時点で、Schematics自体のリソースは北アメリカやヨーロッパなど一部の地域に作成されます。ただし IBM Cloud のリソースを作成する場合は、Schematics のロケーションに関係なくどこでも作成することができます。 Schematics は大きく分けて3つの機能を利用することができます。 Schematicsワークスペース： Terraform の機能を利用し、IBM Cloud環境へのリソースのプロビジョニングと構成の管理の自動化を行います。 Schematicsアクション： Ansible as a Service機能を利用し、構成の管理及びアプリケーションを IBM Cloud環境にデプロイします。 Schematics Blueprints（2023年8月現在ベータ版）： 定義したインフラコードをモジュールとして取り扱い、組み合わせることで大規模環境をデプロイします。 Schematicsワークスペースと Schematicsアクションの使い分けとしては、リソースのプロビジョニングは Schematicsワークスペースを利用し、ソフトウェアのデプロイや設定管理には Schematicsアクションを利用することが推奨されています。 今回の検証では、Schematicsワークスペースを利用した Power Virtual Server のプロビジョニングをご紹介いたします。 検証の概要 Schematicsワークスペースの利用シーンとしては、複数の区画をプロビジョニングしたり、構成変更や別環境へ同一構成をプロビジョニングすることなどが考えられます。 今回の検証では Power Virtual Server を東京リージョンにプロビジョニングし、メモリ容量を変更を行います。また、大阪リージョンにも同じ区画をプロビジョニングしていきます。 なお、事前に Power Virtual Server のワークスペースを東京と大阪に作成しておきます。ワークスペースの作成方法につきましては「【やってみた】IBM Power Virtual ServerのAIX環境とIBM Cloud Object Storageを接続してみた -Part1-」の「2) IBM Power Virtual Serverの作成」をご参照ください。 以下は検証の構成図です。コードは Github のプライベートリポジトリに配置します。外部のソースコード管理ツールを使用したくない場合は IBM Cloud Toolchain の Gitlab を利用することも可能です。 Githubの設定 プライベートリポジトリの作成 Github の使用は初めてなので、アカウントやリポジトリ作成方法は Web で検索しました。以下の画面は Github のトップ画面です。デザインがカッコいいですね。 アカウントを作成し、ダッシュボード画面に入ります。コードは外部公開しない想定のため、プライベートリポジトリを使用します。任意のリポジトリ名を入力、[Private] を選択し [Create a new repository] をクリックします。 プライベートリポジトリが作成できました。作成したリポジトリにコードを配置していきます。 コードの作成 Power Virtual Server をプロビジョニングするためのコードですが、こちらの Github に「サンプルコード」が公開されています。5つのコードファイルがありますが全て使用します。以下各コードファイルの説明です。 README.md：Readmeファイル main.tf ：インフラ定義を記述するファイル provider.tf ：対象のクラウドなどの情報を記述するファイル（リージョンなども記述） variable.tf ：変数を記述するファイル versions.tf ：使用するモジュールとバージョンの組み合わせを記述 プライベートリポジトリの画面に戻り、[Add file] から [Create new file] をクリックします。 ファイル名を入力し、サンプルコードをコピー＆ペーストします。最後に [Commit change] をクリックします。 5つのコードファイルを作成しました。 コードの編集 検証では以下構成の Power Virtual Server をプロビジョニングしていきます。 リージョン：東京 インスタンス名：test_AIX OS：AIX V7.3 CPUタイプ：Uncapped Shared CPU：0.25 メモリ：2GB ストレージタイプ：Tier3 外部ディスク名：dg 外部ディスクサイズ：1GB NW名：pvs_test_nw サンプルコードのままでは上記の構成を作成することはできないため、変数ファイル「variable.tf」を編集する必要があります。main.tf、provider.tf は variable.tf の値をみて動きますので特に編集は不要です。versions.tf は変更無し、README.md は適宜編集します。 以下は variable.tf の内容です。各パラメータの説明は割愛いたしますが、ピンク字①～③の値の確認方法は下にご紹介します。 // Service / Account variable "ibm_cloud_api_key" { description = "API Key" type = string default = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" }＜① variable "region" { description = "Reigon of Service" type = string default = "tok" } variable "zone" { description = "Zone of Service" type = string default = "tok04" } variable "cloud_instance_id" { description = "Cloud Instance ID of Service" type = string default = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" }＜②// Image variable "image_name" { description = "Name of the image to be used" type = string default = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" }＜③// Instance variable "instance_name" { description = "Name of the instance" type = string default = "test_AIX" } variable "memory" { description = "Instance memory" type = number default = 2 } variable "processors" { description = "Instance processors" type = number default = 0.25 } variable "proc_type" { description = "Instance ProcType" type = string default = "shared" } variable "storage_type" { description = "The storage type to be used" type = string default = "tier3" } variable "sys_type" { description = "Instance System Type" type = string default = "s922" }// SSH Key variable "ssh_key_name" { description = "Name of the ssh key to be used" type = string default = "ssh_20230719" } variable "ssh_key_rsa" { description = "Public ssh key" type = string default = "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" }＜公開鍵を入力// Network variable "network_name" { description = "Name of the network" type = string default = "pvs_test_nw" } variable "network_type" { description = "Type of a network" type = string default = "pub-vlan" } variable "network_count" { description = "Number of networks to provision" type = number default = 1 }// Volume variable "volume_name" { description = "Name of the volume" type = string default = "dg" } variable "volume_size" { description = "Size of a volume" type = number default = 1 } variable "volume_shareable" { description = "Is a volume shareable" type = bool default = false } variable "volume_type" { description = "Type of a volume" type = string default = "tier3" } ピンク字①～③の値の確認方法は以下です。 ①APIキー APIキーの作成方法は「APIキーの作成方法」（IBMサイト）をご参照ください。作成したAPIキーを控えます。 ②クラウドインスタンスID IBM Cloudリソースリストから Power Virtual Server のワークスペースを選択すると GUID が表示されるので控えます。 ③イメージID IBM Cloud Shell からコマンドを実行してブートイメージのイメージIDを取得します。Cloud Shell は管理コンソール画面の右上のアイコンから入ります。 Cloud Shell で以下コマンドを実行します。 $ ibmcloud pi servicelist ＜ワークスペースのcrnが表示されます $ ibmcloud pi service-target crn:XXXXXXXX ＜表示された対象ワークスペースのcrnを入力します $ ibmcloud pi images ＜イメージIDが表示されるのでIDを控えます 以下は出力結果画面です。マスキングが多く申し訳ございませんが、ご参考ください。 これでコードの編集が完了しました。サンプルコードが提供されているので、variable.tf の変数を編集すれば目的のコードを作ることができますね。 トークンの取得 Schematics から Github のプライベートリポジトリにアクセスする際にパーソナルアクセストークンが必要となるため、Github からパーソナルアクセストークンを取得します。メニューから [Settings] をクリックします。 左側メニューの [<>Developer settings] をクリックします。 [Tokens(classic)] をクリックします。 [Generate new token(classic)] をクリックします。 [Note] に適宜入力し、[Expiration] を30日に設定し、"Select scopes" では [repo] にチェックを入れます。画面を下にスクロールし、[Generate token] をクリックします。 パーソナルアクセストークンが作成できました。後程Schematicsワークスペースの作成で必要になるためメモ帳などに控えておきます。 リポジトリーのURL取得 プライベートリポジトリのURLを取得します。リポジトリ画面に戻り [<>Code] をクリックし、[HTTPS] を選択して URL を控えておきます。 これで Github の設定は完了しました。 Schematicsワークスペースの設定・プランの実行 Schematicsワークスペースの作成 Schematicsワークスペースから Power Virtual Server をプロビジョニングにしてみましょう。 IBM Cloud のカタログから "Schematics" を選択します。 Schematics のホーム画面に入りました。[ワークスペースの作成+] をクリックします。 ワークスペース作成画面です。[GithubのURL] にはプライベートリポジトリの URL、[パーソナル・アクセス・トークン] には Github で作成したトークンを入力します。[完全リポジトリーの使用] のチェックボックスはデフォルトままにします。[Terraformバージョン] は最新バージョンを指定して [次へ] をクリックします。 [ワークスペース名] に任意の名前を入力し、[ローケーション] を北アメリカ/ロンドン/フランクフルトの中から選択し、[次へ] をクリックします。 設定値が表示されるので確認し、[作成] をクリックします。 約1分程でワークスペースが作成できました。variable.tf の変数が読み込まれ、ワークスペースの変数に表示されています。 [README] を選択すると、README.md が読み込まれていることがわかります。 Power Virtual Serverのプロビジョニング 右上の [プランの生成] をクリックし、コードのチェックを行います。 プランの生成が成功すると、[ジョブ] 画面に以下のように表示されます。 ちなみに失敗時は以下の画面が表示されます。失敗した場合はエラーメッセージから原因を確認します。ここでは記載しませんが、何回かプランの生成に失敗しコードを修正しました。 コードを修正した場合は、[最新をプル] をクリックすると最新の状態にすることができます。 話がそれましたが、プランを適用してプロビジョニングを実行します。[プランの適用] をクリックします。 進行状況は [ジョブ] から確認できます。 適用が進んでいますね。 約15分程でプランの適用が完了しました。 Power Virtual Server のワークスペースを確認すると、指定通りのインスタンスが作成されていました。 構成変更 Schematicsワークスペースにてメモリ容量を2GBから4GBへ変更します。Github のコード編集ではなく、ワークスペースから変数を上書きすることができます。ワークスペースの変数画面から [memory] の編集アイコンをクリックします。 値を [4] にして [保存] をクリックします。なお、デフォルト値に戻したいときは [デフォルトの使用] にチェックを入れて保存します。 メモリの変数がデフォルトは2、オーバーライド値が4になりました。 プランの生成、適用を行い正常に行われたことを確認します。 Power Virtual Server を確認するとサイズ変更が実行されていました。 数分後、メモリが2GBから4GBに変更されたことを確認できました。 大阪リージョンへプロビジョニング 東京リージョンに作成した区画と同じ構成を大阪リージョンに作成します。リソース変更手順と同様にワークスペースの変数を編集します。[region] を選択して [編集] をクリックします。 大阪リージョンの [osa] を入力して [保存] をクリックします。 同様に、zone, cloud_instane_id, image_name の変数を大阪リージョンの値に上書きします。 変数の上書きをした後、プランの生成を行ったところ生成が失敗してしまいました。ログをみると、イメージを Get できない内容のエラーが出力されています。 しかし、変数のオーバーライド値には大阪リージョンの値を入力しています。Github のコードを編集して Schematicsワークスペースを更新してみましたが、同様のエラーで失敗しました。プラン適用時に環境変数が残ってしまっているのかも？と考え、新たに大阪リージョンの用の Schematicsワークスペースを作成し、変数は大阪リージョンの値を登録しました。 プランの生成・適用を行ったところ、無事成功しました。変数の値は間違っていないようです。 大阪のワークスペースを確認すると、指定した構成で作成されていました。Schematicsワークスペースはリージョン毎に分けた方が良いのかもしれません。 以上で検証は完了です。 コード作成の経験がない私でも、Schematicsワークスペースから Power Virtual Server をプロビジョニングすることができました。サンプルコードはカスタマイズや修正を行えば実行できたので、作業の難易度はそこまで高くありませんでした。 さいごに いかがでしたでしょうか。 Schematicsワークスペースを利用して Power Virtual Server のプロビジョニング、構成変更、別環境へ同一構成のプロビジョニングを行いました。コード作成はスキルが必要と思われる方も多いかと思いますが、サンプルコードが提供されているため初心者でも取り掛かりやすいと思います。 検証では1区画のみの作成でしたが、複数区画作成する場合は GUI で作業するよりもコードを定義し Schematicsワークスペースから実行した方が工数・ミスを削減できるのではと感じます。また、ワークスペース上で変数のデフォルト値が保持されているため、デフォルト値に戻したい場合はクリック一つで設定を戻すことができ、デフォルト値がわからなくなるといったミスを防ぐことができます。 別環境へのプロビジョニングでは変数を上書きしてもプランを適用できなかったため、別リージョン専用のワークスペースを作成しました。明らかな原因を突き止めることができなかったのですが、環境ごとに Schematicsワークスペースを分けた方が運用面では管理がしやすいですね。 また今回は検証しませんでしたが、ベータ版の Schematics Blueprints は定義したコードをモジュールとして取り扱い・組み合わせることで大規模環境をデプロイすることができる機能です。例えば本番環境と同一構成を別リージョンに作成したい場合、通常は一つ一つリソースをプロビジョニングし別環境にも同じ作業を行います。コードを定義し Schematics Blueprints を使用すればコードを組み合わせて環境をデプロイできるため、作業工数の削減が期待できます。 システムの構築は設計から始まり、構築、試験の実施、運用手順書の作成など多くの過程があり、長い時間と労力が必要です。昨今 Schematics をはじめとする IaC の実現ツールが徐々に広まりつつありますが、これからは従来の構築作業がコードとツールを利用した作業や運用に移行していくかもしれません。 最新情報 2023年8月23日に Terraform バージョン0.x が2023年9月末で営業活動終了、2024年9月末にサポート終了されることが発表されました。既存でバージョン0.xをご利用されている場合は2024年9月末までにバージョン1.x以上にアップグレードする必要があります。 Schematics に限らず、IBM Cloudサービスの営業活動終了/サポート終了などは定期的に発表されますので、留意してご利用いただくことが重要です。 お問い合わせ この記事に関するご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社E-Mail：nicp_support@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:#eb6100; 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 #eb6100; transition: all 0.5s ease; } .btn_A a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }
こんにちは。てくさぽBLOGメンバーの高村です。 今回は IBM Cloudアカウントとユーザのアクセス管理についてご紹介します。IBM Cloud を利用する上で欠かせない情報になりますので、ぜひ最後までお読みいただければと思います。 目次 IBM Cloudのアカウントとは？ ユーザのアクセス管理 注意したいポイント さいごに お問い合わせ IBM Cloudのアカウントとは？ IBM Cloudアカウントとは IBM Cloud を利用するために必要な資格情報で、IBM Cloud を利用するには、まず IBM Cloudアカウントの作成が必要です。 IBM Cloud の利用形態は以下の4種類があり、支払い方法が異なります。ご要件によって選択いただきますが、エヌアイシー・パートナーズで販売可能な利用形態はサブスクリプションとなっております。サブスクリプションは PAYG（Pay as You Go）などの後払いとは異なり、事前に使用権を購入し、毎月使った分だけ消費される支払い方法です。 アカウント登録方法や消費の仕組みは本ブログではご紹介しませんが、ご質問は弊社担当営業または本ページの下部記載の お問い合わせ からご連絡ください。 利用形態 説明 ライトアカウント クレジットカード不要で期限なしで使えるアカウント※新規申し込みは終了 PAYG クレジットカードで使った分だけ後払いするアカウント サブスクリプション デパート商品券のように使用権を事前購入するアカウント 契約書 契約書ベースで契約し、請求書による支払いが可能なアカウント ユーザのアクセス管理 IBM Cloudアカウントを作成したら利用スタートです。 多くの案件はプロジェクトメンバーなど複数人でアカウント内のリソースにアクセスしたり操作を行うと思いますが、その際に利用するのが「ユーザ」です。IBM Cloud では IBM Cloud Identity and Access Management（IAM）という仕組みを利用し、ユーザ及びリソースに対するアクセス管理を行います。 ユーザの種類 アカウントで作成できるユーザは4種類あります。1つのアカウントに1名のアカウント所有者が割り当てられ、アカウント所有者がユーザとアクセス管理を行います。 アカウント所有者：アカウント内のユーザ、リソースの管理責任を負う担当者です。 ユーザ：IBMid により認証される個人の利用者です。アカウント所有者に招待され、リソースに対して作業を実施できます。 サービスID：サービスまたはアプリケーションに付与することができる ID です。サービスID を作成することで、IBM Cloud の外部にあるアプリケーションが IBM Cloudサービスにアクセスできるようになります。 アクセスグループ：複数のユーザやサービスID をまとめてグループしたものです。グループ内のメンバー変更があった場合でも個々のユーザの設定を変更することなく管理が可能です。 リソースへのアクセス管理 管理権限を持つユーザは、ユーザ/サービスID/アクセスグループにアクセス・ポリシー*を設定してリソースへのアクセス許可を実施します。 *アクセス・ポリシー ユーザ/サービスID/アクセスグループがどのリソースに対してどのようなアクションを実施できるかというルール。以下の2種類のアクセス・ポリシーを設定可能です。 プラットフォーム・アクセス：IBM Cloudプラットフォーム上でのアクション実行権限。"管理者" "エディター" "オペレーター" "ビューワー" の4つのロールから指定します。 サービス・アクセス：リソースがもつ独自のツールへのアクセス（API/CLIの実行など）の実行権限。"管理者" "ライター" "リーダー" の3つのロールから指定します。 注意したいポイント 以上、アカウント、ユーザのアクセス管理についてご紹介しました。設定値が複数あり複雑なため、以下に注意すべきポイントをご紹介します。 アカウント間の接続、プロビジョニングの制限 既存でアカウントAをお持ちで、新規でアカウントBをご契約する場合、アカウントAとB内のリソースで通信することは可能ですが異なるアカウントにリソースをプロビジョニングすることはできません。 例）PAYGアカウント内にサブスクリプションアカウントの仮想サーバはプロビジョニング不可 アカウント所有者のメールアドレス 会社のシステムで IBM Cloud をご利⽤される場合、アカウント所有者のメールアドレスは管理用の共有メールアドレスをご登録いただくことをお勧めします。 個⼈のメールアドレスを登録した場合、退職・⼈事異動などでアカウント所有者がログインできなくなってしまう可能性があります。 アクセス・ポリシーの設定し忘れ 「【やってみた】IBM Power Virtual ServerのAIX環境とIBM Cloud Object Storageを接続してみた -Part1-」でご紹介した通り、プラットフォーム・アクセスとサービス・アクセスの両方が設定されていないと、仮想サーバのコンソールがオープンができないなど、全ての機能を利用することができません。 作業を行う前に、アクセス・ポリシーが正しく設定されているかご確認いただくことをお勧めします。 さいごに IBM Cloud を利用する上で、アカウントとユーザのアクセス管理は重要です。 オンプレミスではアカウントという概念は無いため、ご要件にあったアカウントの選定、アカウント毎の制限事項に注意してご利用ください。また、ユーザのアクセス管理は複雑になっていますので、オンプレミスの構築と同様にユーザ管理、アクセス・ポリシーの設計を行ってからご利用されることをお勧めします。 お問い合わせ この記事に関するご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社E-Mail：nicp_support@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:#eb6100; 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 #eb6100; transition: all 0.5s ease; } .btn_A a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }
こんにちは。てくさぽBLOGメンバーの佐野です。 海外で開催されたイベント「IBM Think 2023」に参加してきました。久しぶりの海外出張なので、移動も含めてレポートしていきます。 IBM Thinkとは 「IBM Think」はIBMが年次で開催するテクノロジーとビジネスソリューションにフォーカスしたグローバルなフラッグシップイベントです。コロナ禍のためオンサイトでの開催は2020年、2021年の2年間中止していましたが2022年から小規模に再開をし、今年は2022年に比べて少し規模を大きくした開催となりました。 2023年度のイベントが「IBM Think 2023」となり、今年は5月9日から11日までの3日間、アメリカ合衆国のフロリダ州オーランドで開催されました。 IBM Think では基調講演内で IBM の CEO から最新の動向や IBM の進む道、新たな製品発表などが行われます。また、AutomationやSecurityといったカテゴリ毎の基調講演もあり、それぞれのより詳細な内容を聞くこともできます。 基調講演だけではなく個別のセッションや多数のゼネラルセッションもあるので、今後の動向や今現在何ができるかを把握しておきたい分野・ソリューションについてより深く知ることができるイベントです。 出発 Think会場のあるオーランドへは日本からの直行便はありません。そのため、アメリカ国内で飛行機を乗り換える必要があります。今回は羽田からワシントンDC経由でオーランドへ向かいます。 出発日は大雨で羽田空港に向かう電車が遅れていましたが、GW明け直後だったためか空港内は閑散としておりスムーズに出国手続きをすることができました。 羽田：5月8日（月）10:55 → ワシントン：5月8日（月）10:35所要時間 12時間40分（時差13時間） 飛行機の中ではあまり寝られなかったので時差ボケが心配ですが、無事に定刻でワシントンへ到着。 入国審査の税関では疲れのせいか英語があまり聞き取れず何度も聞き返してしまったために係員がかなり不機嫌でした…（笑）が、印刷しておいた飛行機の予約やホテル情報を渡してなんとか無事通過できました。 ワシントンでの乗り換え時間は約2時間取っていましたが、入国がスムーズだったため余裕を持って乗り継ぎの時間に間に合いました。 空港に着いてふと気づいたのですが、アメリカではマスクをしている人はほとんどおらず、付近でマスクをしているのは日本人っぽい人たちだけ。日本とはマスクに対しての意識が全く違うなぁと感じました。 ここまでくれば目的地まであと少しです。オーランド行きの飛行機に搭乗します。 ワシントン：5月8日（月）12:44 → オーランド：5月8日（月）15:04所要時間 2時間20分 その後トラブル無く定刻でオーランド空港に到着！リゾート地なので空港の雰囲気がほかの空港とも全然違います。 滞在するホテルまでUberを使って20分ほどで到着し、ひとまず一安心です。 少し部屋で休憩をし、イベント会場で参加登録を行ってからイベント前日夕方から開催されているウェルカムレセプションへ。 日本時間では真夜中を過ぎそろそろ朝になる時間ですが、外が明るいので物凄く眠たいということはなく、他に日本から来ている方々とご挨拶させて頂き歓談を楽しみました。 その日の夜はぐっすり眠れる・・・わけもなく、まとまって眠れたのは3時間程度でした。。。 IBM Think 2023イベント さぁ、ここからがイベント本番です！ Think 2023 の初日は IBM CEO である Arvindさんの基調講演からスタート。この講演の目玉は「watsonx」の発表でした。 既にメディア各社で基調講演の概要がまとめられているので詳細は割愛しますが、watsonx について一言でいうと、企業向けに ChatGPT のような機械学習モデルをカスタマイズして利用するためのプラットフォームです。 私自身 ChatGPT（3.5）を時々使っていますが、社内の情報は当然答えてくれないので聞けませんし、入力情報を学習に使われてしまうという情報漏洩のリスクがあり機密情報を入れてはいけないという会社のガイドラインもあるため、当たり障りのないことしか聞けません。 しかし、モデルを自社用にカスタマイズし動かす場所を自分で決められるようになればこのような懸念がなくなるので、仕事で使える場面がかなり増えそうだという期待を感じます。 watsonx は「watsonx.ai」「watsonx.data」「watsonx.governance」の3つの製品に分かれています。 watsonx.ai：AIモデルのトレーニングやチューニングを行います。 watsonx.data：AIモデルの学習に使うためのデータを整備します。 watsonx.governance：運用しているAIモデルをモニタリングし、モデルのライフサイクル管理や信頼性を管理しコンプライアンスを遵守しリスクを緩和します。 このように、watsonx を利用することで自社でAIモデルを開発し運用を効率的に実施できるようになります。 watsonx以外にもこれから出荷開始となる製品がセッション内で紹介されていたり展示会場内のブースがあったりしたので、出荷前にどんな製品なのかを知ることができました。 最近の IBM はまず SaaS でリリースした後にソフトウェア版を提供するという順番となることが多いです。一般的にも製品の初期バージョンは改良すべき点が多いため、メーカー側で製品を改善しやすいSaaSから提供開始となるのはユーザーにとってもいいことですね。 イベント開催に伴い展示会場もオープンになっています。 従来の展示会場と比べると控えめな大きさでしたが、基調講演で発表があったwatsonxの展示スペースは初日、たくさんのお客様で大盛況でした！ レゴで作ったサーバーがあったりスケルトンのIBM z16があったりと、普段は見られないものが設置されているのもイベントならではです。 イベント期間中の朝食・昼食はセルフ形式なので、自分の体調やお腹の具合に応じて食べるものや量を調節できます。朝食にはこんなものが置いてあります↓ イベント最終日前日（5/10）の夜は、ユニバーサルスタジオのパークを1つ貸し切ってのパーティーです！ ところどころにIBMのロゴがプロジェクションされ、貸し切りであることを実感できスケールの大きさに感動しました。 帰国 Think2023は5月11日の午前中で終わりなのですが、当日の帰りの飛行機が取れなかったため、帰国は翌日の5月12日になりました。 帰りはオーランドからシカゴ経由で羽田へ向かいます。 オーランド：5月12日（金）7:30 → シカゴ：5月12日（金）9:33所要時間 3時間3分（日本とは14時間の時差）※オーランドは東部時間ですが、シカゴは中部時間のため1時間の時差があります 飛行機の乗り継ぎ時間の確保のため早朝の便になってしまい、ホテルの出発時間は朝の5時…前日の夜にUberで予約ができるのは非常に便利で助かります！ 朝早かったこともあるのか、空港内の人は少なめです。搭乗手続きもすんなり終えることができました。 これからの移動も長いので、オーランド空港で朝ごはんです。 シカゴ：5月12日（金）13:10 → 羽田：5月13日（土）15:55所要時間 12時間45分 シカゴ空港内で迷ったこと以外は特にトラブルも無く、ようやく帰国便への搭乗です。 帰国便は偏西風に乗れないので行きに比べて1時間ほど時間がかかりますが、ワシントンよりシカゴの方が日本に近いため所要時間はあまり変わりません。しかし、単純に移動時間が長いので長距離移動は疲れます… 無事に羽田空港へ到着し、帰宅のための電車に乗ることができました。 帰宅した後2時間ほど仮眠をとったのですが、起きたら真っすぐ歩けない状態！それほど疲れていたとは自分でも思っていなかったのでびっくりしました。 まとめ 今回のイベントの目玉は新しく発表があった「watsonx」です。出荷開始は7月とのことなので情報はこれから徐々に入ってくると思いますが、最近の流行りであるGenerative AIを企業向けに使いやすくするためのIBMらしいソリューションだなぁと感じました。また基調講演内でもメッセージがありましたが、これからどんどんAIを活用したソリューションが出てくるので、個人的には楽しみです。 watsonx以外にも、サステナビリティーソリューションである Envizi や XDR を含めたセキュリティソリューションスイートである QRadar Suite のような、今後の展開が楽しみな製品がありました。これら最新の IBMソリューションがどういう場合に使えるものなのかをしっかり理解して状況に応じて適切なものをご提案できるよう、引き続き情報収集していきます！ 以上、「IBM Think 2023」参加レポートでした。最後までお読み頂きありがとうございました。 お問い合わせ この記事に関するご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社技術支援本部E-Mail：nicp_support@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:#eb6100; 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 #eb6100; transition: all 0.5s ease; } .btn_A a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }
皆様こんにちは。エヌアイシー・パートナーズ てくさぽBLOGメンバーの佐藤です。 IBM Power10サーバー、大変好評をいただいております。今回は Power10 の重要な改良ポイントの一つであるメモリの技術について、DDRメモリの限界と問題点を交えながら深堀していきます。 目次 DDRメモリの限界 DDRメモリの課題 OMIのメリット -DDRメモリの課題を解決するには？- 最後に 関連ブログ・コラム・インタビュー お問い合わせ DDRメモリの限界 DDRメモリは業界標準のメモリです。スマートフォンから PC、サーバーまで広く採用されています。世代を重ねるごとに高速化されており、最新は DDR5メモリとなります。 Power9 でも DDR4メモリインターフェイスを採用していましたが、Power10 からは OpenMemoryInterface（以下 OMI）インターフェイスに変更されました。 DDR の問題点はメモリチップ自体というより、そのやり取りである "パラレル信号" にあります。 パラレル信号においてより高速なメモリアクセスをするためには、信号数を増やすかクロックを上げるほかありません。これ以上の信号数を増やすことは容易ではない為、世代ごとにクロックの高速化を行ってきました。しかしながら、クロックの高速化に伴って問題が発生しています。特にこの問題はサーバー製品において顕著で、限界に達しつつあります。 パラレル信号の等長性 パラレル信号は等長である必要があります。すべての信号が同時並列にメモリと CPU の間を行ったり来たりします。 メモリと CPU の端子の距離は端子やソケットの物理位置によって異なるため、マザーボード上のメモリ配線は蛇行し複雑なパターンを描いています。さらに世代を追うごとに配線長の制限も厳しく、CPUとメモリの間配線はできるだけ最短でかつ同じ長さである必要があります。 これによってマザーボードのレイアウト設計は非常に制限が多く、世代を追うごとに複雑さが増している状態です。 メモリチャンネル クロックを上げるほど配線はシビアになるため、クロックは簡単には上げられません。しかしながら1ソケットあたりの CPUコア数は増加の一途をたどっているため、メモリ帯域は必要です。 そのため、これまでは同時アクセス可能なメモリチャンネル数を増やし、2チャンネル、4チャンネル、6チャンネル、8チャンネルとチャンネル数を増やしてきました。 DDRメモリの課題 1. スペース＆価格 メモリチャンネル数を増やすとマザーボード上の配線が増えます。 サーバー製品ですと障害時の交換を考慮するとラップトップパソコンのようにマザーボード上に直接メモリチップをマウントすることは難しく、結果として大量のメモリソケットがマザーボード上のスペースを占拠し、配線のための多層基板がマザーボード価格を押し上げています。 CPU とメモリソケットのレイアウトにも制限があり、一般的な19インチラックでは16チャンネルメモリ、2ソケット、32メモリソケット/ノードが限界になります。 2. 高速化が難しい PCIe と DDR の新しい世代はほぼ同時期のリリースで、最新は PCIeGen5 と DDR5 です。過去も含めて比較すると、基本的に同一世代の PCIe が DDRメモリの転送速度を上回っているということが分ります。この点が、DDRメモリが抱える課題のひとつと言えるでしょう。 ※出典：「転送速度」（ウィキペディア） OMIのメリット -DDRメモリの課題を解決するには？- ここから OMI の話に移ります。 優れた生産性がありながらも制限の厳しいパラレル転送方式の DDRメモリですが、シリアル化すれば、高速転送が可能となり非常に使い勝手がよくなります。具体的には、SoC を通した DDRメモリチップのシリアル変換です。 以下にそのメリットを紹介します。 1. 省スペース化 Power10 に採用されている OMIメモリは物理的に非常に小型です。これは、シリアル化によってピン数を減らすことができたためです。 DDR4 ではメモリ1枚あたり72本、DDR5 では80本もの配線が必要ですが、OMI ではディファレンシャル信号で 8Bitのため、たった16本の配線で済みます。 図1：Power10のOMIメモリ（一般的なDDRメモリと比較すると端子部分は非常に小さくメモリチップレイアウトの自由度が高い） 結果的に、Power10 E1080モデルでは標準的な19インチラックサイズにもかかわらず4ソケット構成で、かつそれぞれ16チャンネルメモリを実現しています。 図2：Power10 E1080モデルの内部構成（中央CPUソケット右がメモリソケット、32ソケットに見えるが、左右にソケットがある） 2. 高速化 メモリソケットの物理サイズが小型化し少ない配線で済むとなるとどうなるでしょうか？ メモリチャンネル数の増加による高速化が可能になります。 他社の CPU では最新世代であっても8チャンネルメモリが限度で、DDR4 3200 の8チャンネルでは最大転送が約200GB/s、発表されたばかりの DDR5 4800 の8チャンネルですら最大転送は約300GB/sです。 Power10 は16チャンネルメモリのため、現時点で最大転送は約400GB/s、双方向では約 800GB/s にもなります。 図3：Power10 E1080モデツのブロック図（3272Gbps theoretiacal max bandwidth per socket, 16チャンネルメモリ×4ソケットというのは驚異的） 3. 高可用性 シリアル化した際のメリットとして、レーン転送があります。転送経路にエラーが発生した場合、縮退して動かすことができます。 OMIメモリは通常25Gbps×8レーンで動作しますが、縮退して×4レーンでの動作もサポートされています。 4. 暗号化 SoC を経由してデータを書き込むため、データの暗号化が可能です。 クラウドが増えてきた今、仮想化されたメモリ空間のとなりは攻撃者となりえます。サイドチャネル攻撃は直接的な該当区画への攻撃ではなく、攻撃者自身のメモリ空間に対し、特定パターンでの書き込みにより隣接したメモリ空間を予測する攻撃です。そのため、通常のセキュリティ対策では防ぐことができません。 パスワードは HDD や SSD上では暗号化されますが通常メモリ上では平文で展開されるため、メモリ暗号化はこのような攻撃に非常に有効な対策です。 5. 将来性 OMI のメリットはそれだけではありません。 現在は DDR4メモリのみですが、メモリーコントローラーチップが対応すれば DDR5 や GDDR といったより広帯域のメモリに対応することが可能です。現在の OMI の帯域は1レーンあたり25Gbpsのみですが、Power10自体は32Gbpsも対応しており、CPUとして最大で512GB/s、双方向では1024GB/sに対応しています。 将来の拡張にも対応可能なインターフェイスと言えます。 最後に 報道発表の通り、OMIメモリを推進していた OpenCAPI は Compute Express Link（CXL）に譲渡されました。今後 CXLメモリとして OMI と同様のメモリが登場する可能性はありますが、2023年現在、CXL に対応した CPU は登場していません。 OMIメモリは従来の DDRメモリの制限を開放し、省スペース化、高速化、高可用性、暗号化を実現しているメモリです。現在、この優れた性能を提供できるのは Power10 のみです。 ※出典：「CXL Consortium and OpenCAPI Consortium Sign Letter of Intent to Transfer OpenCAPI Specifications to CXL」（computeexpresslink.org） 関連ブログ・コラム・インタビュー IBM Power10 について、以下のブログやコラム、インタビュー記事でもご紹介しています。※画像をクリックするとコラムや記事へ遷移します。 お問い合わせ この記事に関するご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社E-Mail：nicp_support@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:#eb6100; 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 #eb6100; transition: all 0.5s ease; } .btn_A a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }
※この記事は2023年5月23日時点の情報をもとに作成しています ＊ ＊ ＊ ＊ ＊ ＊ こんにちは。てくさぽBLOGメンバーの原田です。 IBMソフトウェア（Passport Advantage：以下 PA）ライセンス管理ツールである IBM License Metric Tool（以下 ILMT）を導入するにあたり、ILMT の具体的な構成と導入前の注意事項についてご説明いたします。 ILMT の必要性や基本的な利用ルールついては「【早わかり】仮想化環境でIBMソフトウェアを利用するには」で解説していますので、ぜひご覧ください。 目次 はじめに ILMT9.2管理サーバーの導入タイプ ILMT9.2でサポートされるオペレーティング・システム ILMTサーバー構成に関するよくある質問 さいごに お問い合わせ はじめに ILMT でのライセンス管理にあたっては、ILMT管理サーバーを用意し、ライセンス管理を必要とするサーバーに対して ILMTエージェントを導入する必要があります。 パスポートアドバンテージ契約が必要 ILMT は無償のツールですが、製品のダウンロードや技術サポート受けるにはパスポート・アドバンテージのご契約が必要です。このため、ゼロ円のライセンスの発注が必要な点にご注意ください。 ご契約が締結されていない場合は、製品のダウンロードや技術サポートを受けることができません。また、翌年以降もソフトウェア・サブスクリプション&サポート（以下 SS&S）をゼロ円で注文する必要があります。（※SS&S契約がないとバージョンアップができないため） ILMT管理サーバーは専用サーバー（区画）への導入が前提 ILMT は専用のサーバー機または仮想サーバーにインストールすることが前提とされています。 他のアプリケーションと共存させた場合、リソースやポートの競合が発生する可能性が考えられます。運用開始後に想定外の問題が発生することを避けるためにも、ILMTサーバー用に専用のサーバー機、または仮想サーバーをご用意ください。 ILMTは常に最新のバージョンをご利用ください サブキャパシティ・ライセンスのご契約条件上、ILMT は常に最新のバージョンをご利用いただくことが前提です。 最新バージョンをご利用でない場合は規約違反となり、監査上お客様に不利益が生じる可能性がありますのでご注意ください。 また、最新バージョンには様々な修正が含まれているため、問題の発生を事前に抑制するためにもバージョンアップをご実施ください。 現時点での ILMT最新バージョンは9.2となっています。9.2リリース後も「License Metric Tool -新機能-」（IBMサイト）に記載の通り随時修正がリリースされるため、常に最新化する必要があります。 ILMT9.2管理サーバーの導入タイプ ILMT の現時点最新バージョンは9.2です。ILMT 9.2 における管理サーバーの導入タイプとしては、以下の3種類が用意されています。 License Metric Tool Lite Ansibleを使用したLicense Metric Tool BigFixを使用したLicense Metric Tool 上記のうち1と2については、エージェント側で収集した情報を手動でサーバーに渡す仕組みを検討する必要があるため弊社では「3」のタイプでの導入を推奨しており、今回は「3」のパターンで ILMT管理サーバーを構成する場合についてご説明します。 各導入タイプの詳細については「License Metric Tool -インストール-」（IBMサイト）の資料をご参照ください。 BigFixを使用したLicense Metric Toolの構成概要図 以下図の通り、サブキャパシティー・ライセンス対象のシステム上に導入する BigFixクライアントにて収集したデータを ILMT/BigFixサーバーにアップロードし、ILMTサーバーにて監査レポートを作成します。 BigFixサーバーから最新のソフトウェアカタログを入手するため、インターネット接続が必要です（直接インターネットに接続できない構成の場合はAir-Gapped構成も可能） BigFix は HCL社の製品ですが、ILMT で利用する BigFix については IBMサポートの対象となります ILMT9.2でサポートされるオペレーティング システム 次に、「License Metric Tool -サポートされているオペレーティング システム-」（IBMサイト）を元に、ILMT を導入するサーバーのオペレーティング・システムの前提を確認する必要があります。ILMT管理サーバーとエージェントを導入するサーバーでは、サポートされるオペレーティング・システムが異なりますのでご注意ください。 弊社では、LESサーバーを利用した ILMT管理サーバーのサンプル構成（現在は以下に記載の2パターン）をご提供しています。 Windows構成 RHEL構成 特徴 1台のマシンにILMTサーバー、BigFixサーバー、BigFixコンソールを同居させる構成 1台のマシンにILMTサーバー、BigFixサーバーを同居させる構成 BigFixコンソール 別途用意は不要 別途PC等で用意が必要（Windowsのみサポート） ILMT管理サーバーのOS Microsoft Windows Server 2022 Standard Red Hat Enterprise Linux（RHEL）8.1 データベース MS SQL Server Standard Edition（コアライセンスモデル） Db2（ILMTサーバーライセンスとともに無償提供） ILMTサーバー構成に関するよくある質問 Windows構成の場合、データベースとして MS SQL Server Expressは利用できますか？ IBM License Metric Tool と BigFix を同一コンピューターに導入するオールインワン構成の場合、SQL Server Express はご利用いただけません。また、BigFix は本番環境での SQL Server Express のご利用はサポートされておりません。従いまして、Windows にて IBM License Metric Tool を構築する場合は、有償版の SQL Server が必要となります。 RHEL構成の場合、データベースとして別途Db2ライセンスの購入が必要でしょうか？ いいえ。Db2ライセンスはILMTライセンスとともに無償で提供されるため、別途購入は不要です。 RHEL構成の場合、BigFixコンソールは別途必要でしょうか？ はい。BigFixコンソールは Windows のみがサポートされるため、別途PC等で BigFixコンソールをご用意いただく必要があります。「オプション A: Linux へのオールインワン・インストール（BigFixシナリオ）」もご参照ください。 さいごに 昨今のシステムでは仮想化やコンテナ化は当たり前になり、仮想化環境やコンテナ環境におけるソフトウェア製品のライセンス管理は必要不可欠となっています。コンテナ環境で IBM PAライセンスをご利用される場合には「IBM Container Licenses」（IBMサイト）をご確認ください。 IBMソフトウェア製品のライセンス管理ツールとして ILMT はおなじみの製品となりましたが、ILMT を取り巻く環境や制度は時代の流れと共に変化しています。ぜひ正しい理解のもとでご利用いただきますようお願いいたします。 また、IBM PAライセンスを管理するツールとして「Flexera One with IBM Observability」という SaaS製品もございます。弊社での導入検証結果を「【やってみた】IT資産管理ソリューション「Flexera One with IBM Observability」を使ってみる -Part1-」でご紹介していすので、ぜひご覧ください。 お問い合わせ この記事に関するご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社E-Mail：nicp_support@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:#eb6100; 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 #eb6100; transition: all 0.5s ease; } .btn_A a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }
こんにちは。てくさぽBLOGメンバーの高村です。 本ブログは IBM PowerSystems Virtual Server（PowerVS）から IBM Cloud Object Storage（IBM COS）へバックアップ取得を想定し、AIX環境から Proxyサーバ経由で IBM COS へファイル転送を行う手順をご紹介するブログです。 前回の Part1 では、PowerVS、VSI for VPC、Direct Link Connect、IBM COS のプロビジョニング手順をご紹介しました。Part2（本ブログ）では、各サービスの設定とファイル転送を行います。 Part1 でもご説明しましたが、以下の図は検証の接続イメージ図です。今回はセクション1,2,3,4の IBM COS の設定、Proxyサーバソフトウェアの設定、AIXの設定、最後にAIX環境からProxyサーバ経由でIBM COSへファイル転送を行う手順をご紹介します！ セクション 1）IBM COSの設定 2）VSIのセキュリティー・グループ設定 3）Proxyサーバの設定 4）AIXの設定 5）IBM COSへファイル転送 6）IBM COSの使用量確認 さいごに お問い合わせ 1）IBM COSの設定 ・作成したバケットにアクセス・ポリシーを設定します。作成したバケットをクリックします。 ・バケット・アクセス・ポリシーの設定画面でユーザをプルダウンして選択し「アクセス・ポリシーの作成」をクリックします。 ・アクセス・ポリシーが作成されました。 ・左側メニューから「サービス資格情報」を選択し「新規資格情報+」をクリックします。 ・「HMAC 資格情報を含める」を「オン」にして「追加」をクリックします。 ・サービス資格情報が作成されました。※AIXの設定で赤枠内のaccess_key_idとsecret_access_keyが必要なのでテキストなどにメモしておきましょう IBM COSの設定が完了しました。 2）VSIのセキュリティー・グループ設定 IBM COSへの通信はhttps (port443) を使用します。VSIのセキュリティー・グループ設定でインバウンド・ルールにport443の許可を設定をします。 ・ナビゲーションメニューから「VPCインフラストラクチャー」「セキュリティー・グループ」を選択、「ルール」タブを選択し、インバウンド・ルールの「作成+」をクリックします。 以下の設定で作成します。 プロトコル：TCP ポート最小値：443 ポート最大値：443 ソースタイプ：CIDRブロック IPの範囲：192.168.1.0/24 (PowerVSのセグメント) ・インバウンド・ルールにport443許可の設定ができました。 3）Proxyサーバの設定 Part1でもご紹介しましたが、PowerVS から IBM COS への接続には IBM Cloud (x86環境) 上の Proxyサーバを経由する必要があります。今回は Proxyサーバソフトウェアとしてリバースプロキシ機能がある nginx を使用します。 ・作成した VSI に ssh でログインし、su で rootユーザにスイッチします。nginx設定のため "/etc/nginx/nginx.conf" を探しましたが見当たりません。RHEL に nginx はデフォルトで導入済みと思い込んでいましたがインストールが必要でした。yumコマンドを使用してインストールします。 # yum -y install nginx ・nginxのプロセス起動を確認します。 ・"/etc/nginx/nginx.conf" が作成されていました。次はnginx.confを編集します。 ・その前にファイルのバックアップを行います。 ・viコマンドでnginx.confファイル内のhttp { } の中に下記を追加します。proxy_passはIBM Cloud資料「Endpoints and storage locations」記載の IBM COS の Direct Endpoint を指定します。 vi /etc/nginx/nginx.conf server { client_max_body_size 100M; listen 443 ssl http2; listen [::]:443 ssl http2; server_name 10.244.64.14; <VSIのIPアドレス root /usr/share/nginx/html; ssl_certificate "/etc/ssl/certs/NGINX-selfsigned.crt"; ssl_certificate_key "/etc/ssl/NGINX-selfsigned.key"; ssl_session_cache shared:SSL:1m; ssl_session_timeout 10m; ssl_ciphers HIGH:!aNULL:!MD5; ssl_prefer_server_ciphers on; location / { proxy_set_header Host $server_name; proxy_pass https://s3.direct.jp-tok.cloud-object-storage.appdomain.cloud ; } <IBM COSのDirect Endpoint # Load configuration files for the default server block. include /etc/nginx/default.d/*.conf; error_page 404 /404.html; location = /40x.html { } error_page 500 502 503 504 /50x.html; location = /50x.html { } } ・nginxにhttps通信のため自己証明書を作成します。以下コマンドを実行します。今回パラメーターは特に入力せずブランクで設定しました。 # openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout /etc/ssl/NGINX -selfsigned.key -out /etc/ssl/certs/NGINX-selfsigned.crt ・systemctlコマンドでnginxのサービスを再起動し、ステータスを確認します。 # systemctl restart nginx # systemctl status nginx これでProxyサーバソフトウェアの設定は完了です。コマンドのインストールが必要など、多々躓きました。次は AIX側の設定です。 4）AIXの設定 AIX から IBM COS を操作するために s3cmd というツールをインストールします。以下 rpmファイルを「Apache 2 Test Pageのrpmファイルダウンロードページ」からダウロードし、SCP などのツールで任意のディレクトリに配置します。 file-5.32-1.aix5.1.ppc.rpm file-libs-5.32-1.aix5.1.ppc.rpm python-magic-5.32-1.aix5.1.ppc.rpm s3cmd-1.6.1-1.aix5.1.noarch.rpm ・rpmコマンドでインストールします。s3cmd-1.6.1-1.aix5.1.noarch.rpmファイルをインストールしようとしたところ error でインストールできませんでした。どうやら前提ファイルが足りないようです。 # rpm -i file-libs-5.32-1.aix5.1.ppc.rpm # rpm -i file-5.32-1.aix5.1.ppc.rpm # rpm -i python-magic-5.32-1.aix5.1.ppc.rpm # rpm -i s3cmd-1.6.1-1.aix5.1.noarch.rpm error: Failed dependencies: python-dateutil >= 2.6.0-1 is needed by s3cmd-1.6.1-1.noarch # ・以下のrpmファイルを「AIX Toolbox for Open Source Software」からダウンロードし、SCPでAIXに転送し、rpmコマンドでインストールします。「python-dateutil-2.6.0-1.aix6.1.noarch.rpm」 # rpm -i python-dateutil-2.6.0-1.aix6.1.noarch.rpm ・インストールを失敗した rpmファイルも無事インストールできました。 # rpm -i s3cmd-1.6.1-1.aix5.1.noarch.rpm ・以下のコマンドで環境変数を設定します。 # export PATH=/opt/freeware/bin:$PATH ・以下のコマンドで IBM COS に接続しようとしましたが、エラーが返ってきてしまいました。エラーの内容からs3cfgのパラメーターが設定されていないようです。 # s3cmd -ls ERROR: /.s3cfg: None ERROR: Configuration file not available. ERROR: Consider using --configure parameter to create one. ・Web で検索して調べたところ s3cmd の初期設定が必要でした。以下のコマンドを実行して設定します。※access_key と secret_key は「１) IBM COSの設定」でメモした access_key_id と secret_access_key を入力します。 # s3cmd --configure Enter new values or accept defaults in brackets with Enter. Refer to user manual for detailed description of all options. access key and Secret key are your identifiers for Amazon S3. Leave them empty for using the env variables. access Key:メモした情報 Secret Key :メモした情報 Default Region [US]: ＜ブランクのままエンターキーで継続 Encryption password is used to protect your files from reading by unauthorized persons while in transfer to S3 Encryption password: ＜ブランクのままエンターキーで継続 Path to GPG program [None]: ＜ブランクのままエンターキーで継続 When using secure HTTPS protocol all communication with Amazon S3 servers is protected from 3rd party eavesdropping. This method is slower than plain HTTP, and can only be proxied with Python 2.7 or newer Use HTTPS protocol [Yes]: ＜ブランクのままエンターキーで継続 On some networks all internet access must go through a HTTP proxy. Try setting it here if you can't connect to S3 directly HTTP Proxy server name: ＜ブランクのままエンターキーで継続 New settings: access Key: c03ad59f84274b069f69cc60b0b4fb9b Secret Key: 3b8c9337eff3d611fd7081f6d13223841f19bb72725f7821 Default Region: US Encryption password: Path to GPG program: None Use HTTPS protocol: True HTTP Proxy server name: HTTP Proxy server port: 0 Test access with supplied credentials? [Y/n] n ＜nを入力 Save settings? [y/N] y ＜yを入力 Configuration saved to '/.s3cfg' ・ホームディレクトリの下に .s3cfgファイルが作成されました。viコマンドで host_baseとhost_bucket の項目を編集します。access_key と secret_key は前述の初期設定で反映済みです。 # cat .sc3cfg access_key = xxxxxxxxxxxxxxxxx check_ssl_certificate = False check_ssl_hostname = False encrypt = False gpg_command = None host_base = 10.244.64.14 <VSIのIPアドレス secret_key = xxxxxxxxxxxxxxxxx use_https = True host_bucket = %(bucket).10.24.64.14 <VSIのIPアドレス # ・再度 AIX から IBM COS に接続してみたところ接続成功し、IBM COS に作成したバケットが表示されました。 # s3cmd ls 2022-12-12 05:32 s3://icos-test-20221212 ようやく AIX から Proxyサーバ経由で IBM COS に接続することができました。細かいところで躓いてしまったので少し時間がかかりました。次は AIX から Proxyサーバ経由で IBM COS にファイル転送をしてみたいと思います。 5）IBM COSへファイル転送 AIX から Proxyサーバ経由で IBM COS にファイル転送をします。今回は1.8GBのファイルを用意し IBM COS への転送時間を Timeコマンドで計測します。また、Proxyサーバでは dstatコマンドで受信データ量、送信データ量、CPU の使用状況を確認します。 ・VSIにログインし、dstatコマンドをインストールします。 # yum -y install dstat ・ファイル転送時にProxyサーバでの受信データ量、送信データ量、CPU使用割合を確認するためdstatコマンドをオプション無しで実行しておきます。 # dstat ・次に AIX にログインし、SCP などで任意のディレクトリに IBM COS に転送するファイルを配置します。 # cd test_data # ls -l 合計 3756712 -rw-r--r-- 1 root system 1923432893 Dec 16 12:06 DB2S_11.5.4_AIXML.tar.gz ・以下コマンドを実行し、IBM COS にファイル転送を行います。15MB毎に分割されてアップロードされていることがわかります。Timeコマンドの結果から転送時間は2分37秒でした。思っていたよりも速い印象です。 # time s3cmd put /test_data/DB2S_11.5.4_AIXML.tar.gz s3://icos-test-20221212/DB2S_11.5.4_AIXML.tar.gzupload: '/test_data/DB2S_11.5.4_AIXML.tar.gz' -> 's3://icos-test-20221212/DB2S_11.5.4_AIXML.tar.gz' [part 1 of 69, 15MB] [1 of 1] 65536 of 15728640 0% in 0s 858.63 kB/s 15532032 of 15728640 98% in 1s 12.11 MB/s 15728640 of 15728640 100% in 1s 7.78 MB/s done upload: '/test_data/DB2S_11.5.4_AIXML.tar.gz' -> 's3://icos-test-20221212/DB2S_11.5.4_AIXML.tar.gz' [part 2 of 69, 15MB] [1 of 1] 65536 of 15728640 0% in 0s 862.77 kB/s 15728640 of 15728640 100% in 0s 16.22 MB/s done upload: '/test_data/DB2S_11.5.4_AIXML.tar.gz' -> 's3://icos-test-20221212/DB2S_11.5.4_AIXML.tar.gz' [part 3 of 69, 15MB] [1 of 1] 65536 of 15728640 0% in 0s 865.13 kB/s 15728640 of 15728640 100% in 0s 25.65 MB/s done -中略- real 2m37.57s user 0m4.63s sys 0m0.70s # ・Proxyサーバの画面に戻ってdstatコマンドの状況を確認します。検証では送受信 (send/recv) とも平均30MB/sでした。CPU (user/sys/idle) を見ると使用割合は少ないことがわかります。 # dstat You did not select any stats, using -cdngy by default. ----total-usage---- -dsk/total- -net/total- ---paging-- ---system-- usr sys idl wai stl| read writ| recv send| in out | int csw 0 0 100 0 0| 0 0 | 60B 633B| 0 0 | 50 72 0 1 100 0 0| 0 0 | 60B 298B| 0 0 | 48 71 0 0 99 0 0| 0 0 | 60B 314B| 0 0 | 44 68 0 0 100 0 0| 0 0 | 60B 298B| 0 0 | 43 67 1 0 100 0 0| 0 4096B|6575B 4017B| 0 0 | 91 93 2 1 96 0 2| 0 0 | 15M 56k| 0 0 |2374 1091 2 1 98 0 0| 0 0 | 235k 12M| 0 0 |1278 135 2 1 96 0 1| 0 0 | 12M 3564k| 0 0 |2136 994 1 1 97 0 0| 0 0 |3094k 13M| 0 0 |1869 382 5 3 91 0 2| 0 0 | 31M 18M| 0 0 |6414 2595 7 3 87 0 3| 0 0 | 26M 29M| 0 0 |6771 2006 1 0 99 0 0| 0 6144B|4022k 13k| 0 0 | 596 294 3 2 93 0 1| 0 0 | 16M 16M| 0 0 |4203 1323 6 3 87 0 3| 0 0 | 21M 29M| 0 0 |5826 1447 1 1 99 0 1| 0 0 |8528k 28k| 0 0 |1300 716 6 2 92 0 2| 0 0 | 17M 19M| 0 0 |4601 1358 5 3 91 0 3| 0 0 | 21M 26M| 0 0 |5732 1621 7 3 87 0 3| 0 0 | 25M 30M| 0 0 |6634 1800 2 1 97 0 1| 0 0 | 13M 39k| 0 0 |1806 877 5 2 90 0 2| 0 0 | 18M 19M| 0 0 |4897 1470 5 3 92 0 1| 0 0 | 31M 29M| 0 0 |7496 2665 6 3 88 0 3| 0 0 | 28M 28M| 0 0 |6420 2091 0 0 99 0 0| 0 0 | 60B 314B| 0 0 | 48 72 6 2 91 0 3| 0 0 | 19M 15M| 0 0 |4769 1541-以下省略- ・IBM Cloud のコンソールから IBM COS の画面に入ります。作成済みバケットにAIXからアップロードしたファイルを確認できました。 これでファイル転送は完了です。私の予想は5分以上かかると思っていましたが、予想よりも速かった印象です。 6）IBM COSの使用量確認 IBM COS は Liteプランの範囲で作業したため課金は発生しませんが、IBM Cloud の管理画面から使用量を確認できるので見てみましょう。 ・IBM Cloud画面上の「管理」⇒「請求および使用量」をクリックします。 ・「使用量」を選択し「Cloud Object Storage」をクリックします。以下の画面の様に各メトリックの使用量を確認できます。ClassA (PUT) は数量233となっており、予想以上に使用していたことがわかりました。※前述した通りLiteプランのためコストは$0となっています。 さいごに Part1 からご覧頂きありがとうございます。遠回りしながらなんとかファイル転送をすることができました。 実際に作業してみて公開されている手順以外に必要な作業を確認できました。Part1では、VSIのコンソールを開くためにユーザー権限が必要であることとRHELの初期パスワードはレスキューモードで再設定を行わなければいけないこと、Part2では、Proxyサーバソフトウェア設定で nginx やコマンドのインストールが必要なことがわかりました。構築のご予定がある方はご参考になれば幸いです。 今回 PowerVS から IBM COS へ 1.8GB のファイルを転送しました。私の予想では5分以上かかると思っていましたが意外にも予想の半分程度の時間で完了しました。Proxyサーバの send/recv値は平均 30MB/s なので、遅すぎる結果ではないと思います。また、転送時 Proxyサーバの CPU使用割合は少なかったので、沢山のリソースを構成する必要はなさそうです。 今回は PowerVS から Proxyサーバ経由で IBM COS に接続しましたが、Qiita のブログ「オンプレミスやPowerVSからDirect Link 2.0越しにVPE経由でICOSのDirect Endpointにアクセスする」にある通り、VPE経由でもアクセスすることが可能となりましたので今後検証してみたいと思います。 お問い合わせ この記事に関するご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社E-Mail：nicp_support@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:#eb6100; 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 #eb6100; transition: all 0.5s ease; } .btn_A a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }
※この記事は2023年3月24日時点の情報をもとに作成しています。 ＊ ＊ ＊ ＊ ＊ ＊ こんにちは。てくさぽBLOGメンバーの原田です。 すでにご存知の方も多いかと思いますが、仮想化環境で IBMソフトウェア（Passport Advantage：以下 PA）ライセンスを利用する場合の注意点について【早わかり】シリーズとしてご説明いたします。 目次 フルキャパシティ・ライセンスとサブキャパシティ・ライセンス サブキャパシティ・ライセンス利用のための要件 IBM License Metric Tool（ILMT）とは さいごに お問い合わせ フルキャパシティ・ライセンスとサブキャパシティ・ライセンス まずはじめに、IBM PAライセンスを利用するお客様は、すべてのサイトおよびすべての環境におけるすべての「プログラム」についてライセンス記録を管理する必要があることをご理解ください。 IBM PAライセンスには「IBMソフトウェア（Passport Advantage）ライセンスのまとめ【2022年12月版】」でも記載している通り製品によって様々な課金体系があり、その中でもコア数を元にした課金体系の製品が多くあります。 IBM PAライセンスにおける基本的な考え方として、活動化されたすべてのプロセッサー・コアに対してライセンスの取得が必要となります。ただし、以下に記載した課金体系の製品を仮想化環境にインストールした場合には、次のうち低い方のライセンスを取得することができます。 対象製品が任意の時点で使用できるサーバー内の物理コアの最大数の PVU/VPC/RVU 対象製品が任意の時点で利用できる仮想マシン（VM）の仮想コアの最大数の PVU/VPC/RVU 前者をフルキャパシティ・ライセンス、後者をサブキャパシティ・ライセンスと呼んでいます。 以下の表でもう少し詳しく整理してみましょう。 フルキャパシティ・ライセンス サブキャパシティ・ライセンス 特徴 物理サーバー上のコア数分に基づいたライセンス取得方法 仮想化環境の仮想サーバー上に割り当てたコア数に基づいたライセンス取得方法 （サーバーの物理コア総量は超えない） ライセンス管理ツールの使用 推奨（手動レポート可） 必須 レポーティングに関するお客様の責任 少なくとも年に1回はレポートが必要 四半期ごとに少なくとも1回はレポートが必要 このように、サブキャパシティ・ライセンスの場合には仮想サーバーに割り当てたコア数のみライセンスを取得すればよいため、フルキャパシティ・ライセンスの場合と比較してライセンス費用を削減することができます。 しかしながら、サブキャパシティ・ライセンスを利用するためにはいくつかの条件があります。 サブキャパシティ・ライセンス利用のための要件 「Sub-capacity（Virtualization capacity）licensing」（IBMサイト）で掲載されているサブキャパシティ・ライセンスの利用要件について、もう少し分かりやすく整理してみました。 十分なライセンスの取得 「Virtualization Capacity License Counting Rules」（IBMサイト）に従った、IBMプログラムが利用可能なパーティションまたは仮想サーバーの仮想コア総量に基づいた十分なライセンスを取得する 適格なサブキャパシティー製品の使用 ※2023年3月時点 対象課金体系のサブキャパシティー製品の利用 Processor Value Unit（PVU） Resource Value Unit Managed Activated Processor Core（RVU MAPC） Virtual Processor Core（VPC） 適格な仮想化テクノロジーを使用する（2022年12月15日） 当リストは適宜更新され、更新があった場合にはその条件が新たに適用されます 特に古いOSやハイパーバイザーはリストから削除されていくため、最新バージョンに上げる必要があります 利用する仮想化テクノロジーによってサブキャパシティ・ライセンスのカウント方法は変わります※詳細は「Sub-capacity（Virtualization capacity）licensing」（IBMサイト）の "License Counting Scenarios:" 以下をご参照ください 適格なプロセッサー・テクノロジーを使用する（2023年2月9日） 管理ツールの利用 ※2023年3月時点 以下のいずれかの IBM認定のツールを使ってライセンス管理が必要 IBM License Metric Tool（ILMT） HCL BigFix Inventory Flexera One with IBM Observability IT Asset ManagementおよびFlexera One IT Asset Management Flexera One with IBM Observability はまだあまり知られていない製品ですが、弊社での導入検証結果を「【やってみた】IT資産管理ソリューション「Flexera One with IBM Observability」を使ってみる -Part1-」でご紹介していますので、ぜひご覧ください。 IBM License Metric Tool（ILMT）とは 「IBM License Metric Tool（以下 ILMT）」とは、「パスポート・アドバンテージのご契約条件」（IBMサイト） で使用を規定されたライセンス管理ツールです。複数あるライセンス管理ツールの中でも最も多くのお客様にご利用いただいており、以下のデータを収集してレポートを作成することができます。 IBMソフトウェアのフルキャパシティ/サブキャパシティ ライセンス数 サーバー環境の情報 ILMT は IBMソフトウェアのライセンス管理を支援し、監査に備えたコンプライアンス遵守を実現します。お客様はツールのインストールに必要なハードウェアを用意し、ツールの導入、運用を行っていただく責任があります。 ILMT利用にあたって ILMT の利用にあたっては以下の通り様々な規定があります。※ここに列記した規定はあくまで一部であり、予告なく変更される場合があります。 他のIBMソフトウェア製品同様に発注が必要 ILMTはライセンス+ソフトウェア・サブスクリプション&サポート（以下 SS&S）をゼロ円で注文して取得 翌年以降もSS&Sをゼロ円で注文する必要がある（SS&S契約がないとバージョンアップができないため） ILMTのライセンスは無償だが、ハードウェア、導入費用、管理・運用費用等はお客様負担 ILMTは専用サーバーを準備する必要がある 常に最新のILMTバージョンを使用する必要がある サブキャパシティー・ライセンス導入後、90日以内にILMTによるライセンス管理を開始する必要がある ILMTレポート文書は少なくとも四半期ごとに1回は実行し、各レポートは少なくとも 2 年間は保持する必要がある ILMTレポートは要求があった場合はIBMに提供する必要がある 2023年2月の IBM Passport Advantage Agreement v11 のリリースにより、IBM はサブキャパシティー報告要件の例外サポートをしなくなった（導入例外規定はなくなった） ILMTでライセンスカウントする範囲は下記に示す同一リージョン内にあるサーバに適用される リージョン1: 北アメリカと南アメリカ リージョン2: ヨーロッパとアフリカ リージョン3: アジア と オーストラリア さいごに 仮想化環境で IBM PAライセンスをご利用いただく際に、フルキャパシティ・ライセンスとサブキャパシティ・ライセンスの2通りの考え方がある点についてご理解いただけたと思います。 サブキャパシティ・ライセンスの利用は一見ライセンス費用の効果が高いように見えて管理ツールの導入と運用のためのコストが追加負担となりますので、ライセンス/SS&S費用の低減と比較してお客様にとって本当に望ましい選択かどうかを検討する必要があります。 なお、近年ではクラウド環境やコンテナ環境での IBM PAライセンスの利用も増えてきており、サブキャパシティ・ライセンスでの利用を余儀なくされるケースもあるため、サブキャパシテイ・ライセンス利用における条件や注意事項をよくご理解いただいた上で IBM PA製品導入のご検討をお願いいたします。 また今回は詳しく触れていませんが、コンテナ環境で IBM PAライセンスをご利用される場合には「IBM Container Licenses」（IBMサイト）をご確認ください。 お問い合わせ この記事に関するご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社E-Mail：nicp_support@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:#eb6100; 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 #eb6100; transition: all 0.5s ease; } .btn_A a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }
こんにちは。てくさぽBLOGメンバー佐野です。 前回のPart1 では、Flexera One の概要と検証環境についての説明をしました。今回のPart2では実際に導入検証した内容を共有します。 前回のおさらいとして、検証環境の構成を再掲します。 今回の検証手順の紹介において、Flexera OneはSaaSですので、SaaSの契約およびプロビジョニングまで完了していることが前提となります。また、初回ログインのための最初のユーザー登録は済んでいる状態と想定しております。ログインが求められる場合にはこのユーザーで実施下さい。 目次 導入手順の検証 ビーコンサーバーの構築 エージェントの導入 レポートの出力 おわりに お問い合わせ 導入手順の検証 Flexera One を検証するにあたって、以下の手順で構築を進めました。 ビーコンサーバーの構築 エージェントの導入 レポートの出力 今回はエージェント導入先として Windowsサーバーへの導入検証結果・手順を共有します。※エージェント導入対象サーバーの構築手順については省略します １．ビーコンサーバーの構築 まず初めにビーコンサーバーを構築します。 システム要件に書いてある通り、OS は Windows Server 2012 から 2022、Windows 8,10,11 がサポート対象です。ソフトウェアの要件として Power Shell 3.0以上と IIS7.0 with ASP.NET 4.5.2以上（ただし.NET v 4.6.2以上推奨）が必要です。 本検証環境では Windows Server 2022 を利用しています。※英語版で構築したため画面ショットが全て英語となっていることご了承ください。 ビーコンサーバーを構築するためには以下のステップが必要となります。それぞれについて操作を進めていきます。 1-1．事前設定（信頼済みサイトの設定、IIS導入、.NET導入、TLS設定）1-2．ビーコンサーバープログラムのダウンロードおよびインストール1-3．ビーコンサーバー設定 1-1．事前設定（信頼済みサイトの設定、IIS導入、.NET導入、TLS設定） IBM Cloud上にデプロイされている Windows Server 2022 ではシステム要件に必要な IIS、.NET などは導入済みでしたので省略します。TLS も要件にある 1.1/1.2 が設定されていました。個別に設定が必要なものは「信頼済みサイトの設定」のみでした。IEのインターネットオプションから「Trusted Site」で指定されたドメインを信頼済みサイトとして登録します。 検証時点ではSaaSの管理サーバーとして選択できるロケーションがヨーロッパと北米であったため、距離が近い北米で契約・デプロイしました。そのため、「https://app.flexera.com」を設定しています。※2023年3月時点ではアジアも選択できるようになっています これで事前の設定は終了です。次にビーコンサーバーのプログラムを導入していきます。 1-2．ビーコンサーバープログラムのダウンロードおよびインストール Flexera One の管理画面にログインし、プログラムをダウンロードします。 左側のペインにある「Data Collection」から「IT ASSETS INVENTORY TASKS」内の「Beacons」を選択します。 画面右上に表示されている「Deploy A Beacon」ボタンを押します。 「Download a beacon」内にある「Download A Beacon」ボタンを押します。もしバージョンを変更したい場合には「Version to Deploy」欄に表示されているバージョンから変更ください。 ビーコンサーバー上以外でダウンロードを実行した場合にはダウンロードした実行ファイルをビーコンサーバーへコピーします。 実行ファイルを右クリックし「管理者として実行」を選択し実行します。 「Next」を押し、操作を進めます。特に何かを変更する必要はありません。「Configure Scheduled Tasks」では「Run as a named user」が選択されているのでそのまま、管理者権限を持つユーザー名とパスワードを入力します。 "Install Wizard Completed"が表示されればインストール終了です。 1-3．ビーコンサーバー設定 次にビーコンサーバーからインベントリ情報をFlexera One環境へアップロードするための設定をします。 インストールした「FlexNet Beacon」を右クリックし「管理者として実行」を選択し実行します。 Parent Connectionを有効化するため「Enable parenet connection」にチェックを入れます。 「Configure inventory beacon connection」内の「Configure and import configuration file」をチェックし「Download Configuration」ボタンを押します。 ブラウザが自動的に起動し、Flexera Oneの画面が表示されますのでログインします。 「Configure Beacon」ページが表示されるので、Name欄にビーコンサーバーの名前を入れます。今回はビーコンサーバーのホスト名である「IBMcloudBeaco」と入れます。他の項目は変更しません。 「Download Configuration」ボタンを押します。拡張子が「flxconfig」となっているファイルをダウンロードし保存します。 （FlexNet Beaconが起動していない場合）ビーコンサーバーの「FlexNet Beacon」を右クリックし「管理者として実行」を選択し実行します。 ウィンドウの真ん中にある「Download and import configuration file」を選択し「Import configuration」ボタンを押します。 先ほどダウンロードした設定ファイルをインポートし「Connection details」欄にServer URLやDownload URL、Upload URLなどが表示されることを確認します。 その後、Testing parent connectio...欄の結果が "Succeeded" になることを確認します。 Flexera One画面の左側のペインにある「Data Collection」から「IT ASSETS INVENTORY TASKS」内の「Beacons」に登録したビーコンサーバーが表示され、「Connectivity status」が "Connected" になっていることを確認します。 ここまででビーコンサーバーの設定は終了です。次に管理対象サーバーにエージェントを導入します。 ２．エージェントの導入 管理対象サーバーにエージェントを導入します。今回は Windowsサーバーへエージェントを導入する手順を紹介します。 AIX や Linux は設定ファイルの書き方や実行方法が異なりますので詳細はエージェント導入のドキュメントをご参照下さい。また、導入先のシステム要件は必ず事前に確認するようにして下さい。 エージェントの導入は以下ステップで実施します。 2-1．エージェントをダウンロードする2-2．エージェント導入前の設定ファイルを作成する2-3．エージェントを導入する 2-1．エージェントをダウンロードする Flexera Oneエージェントを管理画面からダウンロードします。 左側のメニュー「Data Collection」から「IT ASSETS INVENTORY TASKS」内の「Inventory Settings」を選択します。 Inventory agent for download欄にある"Inventory agent:"からバージョンと導入先プラットフォームに適切な組み合わせを選びます。今回はWindowsなので"Version 19.1.0 FlexNet Inventory Agent"を選択し「Download」ボタンを押します。 また、この後設定に使う設定ファイルも"Download bootstrapping template file"リンクからダウンロードします。 ダウンロードしたエージェントのプログラム（ZIP）を解凍し設定ファイルを「FlexNet Inventory Agent.msi」と同じディレクトリ内に配置します。 2-2．エージェント導入前の設定ファイルを作成する こちらを参考にしてエージェント導入前に設定ファイルを作成します。 ダウンロードした設定ファイルから3点変更します。 URLを変更DEPLOYSERVERURL = http://10.244.0.4/ManageSoftDL※"10.244.0.4"はビーコンサーバーのIPアドレスを指定します。 以下2行の冒頭にあるコメント（;）を外すTMPMAINDIR = c:\Program Files\ManageSoftUSAGEAGENT_DISABLE = False 2-3．エージェントを導入する 「FlexNet Inventory Agent.msi」を実行します。基本、デフォルトの選択のままで進めればOKです。エラーが発生せずに"Install Wizard Completed"と表示が出ればインストール完了です。 エージェント導入後にしばらく待つと、Flexera One管理画面の左側のペインにある「Inventory」から「INVENTORY」内「All Inventory」ページにエージェントを導入したホスト名が表示されます。ホスト名が表示されたらエージェントから収集したデータがビーコンサーバー経由でFlexara One環境にアップロードされたため、正常にセットアップできたことが確認できました。※図はWindowsだけでなくPower Virtual Serverもエージェントを導入した後となります ３．レポートの出力 ソフトウェアの導入状況と数量のレポートを出力します。エージェント導入サーバーに管理対象となるソフトウェアを導入し、Flexera One の管理画面でライセンスの登録およびレポート出力を実行します。 今回はIBMソフトウェアをサブキャパシティとして利用していることのレポートを出力します。対象ソフトウェアは WebSphere Application Server 9.0 Base（以下 WAS）となります。 レポート出力は以下のステップで実施します。 3-0. エージェント導入サーバーへWASの導入3-1. ライセンスの登録 3-2. ライセンス数量入力3-3. レポート出力 3-0. エージェント導入サーバーへWASの導入 エージェント導入サーバーへ WAS を導入します。 この手順はエージェント導入前に実施しても問題ありません。※本ブログはFlexera Oneの導入ブログであるため、WAS の導入手順は省略します 3-1. ライセンスの登録 レポートを出力するためには、ご自身が所有しているライセンスを登録し、そのライセンスを Flexera One が検出したソフトウェアと紐づける必要があります。そのため、まずは利用しているソフトウェアのライセンスを登録します。 Flexera One管理画面の左側のペインにある「License」から「LICENSE MANAGEMETNT」内「All Licenses」を選択します。 画面中央付近にある「Create A License」ボタンを押します。 「Application:」欄に"WebSphere Application Server"を入力し「Search」ボタンを押します。 検索結果に表示されたProductから導入している製品（WebSphere Application Server 9.0 Base）を選択します。 「Add Application」ボタンを押します。 「License Type」で「IBM PVU」を選択します。 「Create」ボタンを押します。 これで WebSphere Application Server のライセンスが登録できました。 この後に保有しているライセンス数量を入力します。 3-2. ライセンス数量入力 保有している WAS のライセンス数量を入力します。 右側にある「Compliance」を選択し、中央ペインの下段に「Entitlements and consumption」項目にライセンス数量を入力します。 「Extra entitlements」項目の「＋」の右側に保有しているライセンス数量を入力します。今回は400PVU分と入力し、ページ右上にある「Save」ボタンを押します。 これでライセンス数量の入力まで終わりました。 3-3. レポート出力 最後にレポートを出力します。 今回は IBMソフトウェアをサブキャパシティとして利用していることのレポートとなるので、IBM の Auditレポートになります。※WAS は PVU課金の製品であるため、PVU課金のレポート画面から内容を確認した上で Auditレポートを出力します Flexera One管理画面の左側のペインにある「Reporting」から「LICENSE REPORTS」内「IBM PVU License Consumption」を選択します。 「Run Report」ボタンを押します。少し待つと、画面下段の表に「License Name」が「IBM WebSphere Application Server 9.0」となっている項目が出てきます。※画像では他のソフトウェアも表示されています表内で「License Consumption」列に現在WASが稼働しているサーバーのスペックにあわせたPVU数が表示されていることを確認します。※反映までに時間がかかることがあるので、もし出てこない場合には翌日再確認してみてください 正しく内容が反映されている場合には「Run Report」ボタンの右側にある「Download the IBM audit report」リンクをクリックします。 これにより、ZIPファイルに圧縮されたIBM Audit Reportをダウンロードできます。IBMへはこちらのZIPファイルをご提出ください。 ZIPファイルの中身を見ると、環境内にあるPVU・VPC課金、Cloud Pakライセンスのインベントリ情報、使用数量などのデータが入っているCSVファイルが存在することが分かります。（各CSVファイルの中身を確認し、保有数量と消費している数量に乖離が無いかを念のためご確認頂くのがよいでしょう） おわりに Flexera One を使った IBMソフトウェアのライセンスの監査レポートの出力までの手順を追って説明いたしました。今回は Windowsサーバーを対象にした手順をご紹介しましたが、AIX や Linux の場合に異なるのはエージェントの導入方法のみで管理画面の操作方法は同じです。 管理対象のプラットフォームが違っていても一つの画面でソフトウェアの導入状況が分かり、監査レポートとして提出できるのは非常に良い点だと感じました。また、Flexera One を利用する際に RDBMS をはじめとした他の製品が不要なので、問題の切り分け対応が楽です。 今回は検証していませんが、SaaS や IaaS のコスト管理・最適化機能もありますので、ソフトウェアを管理するだけでなくSaaS含めたコストの最適化ができ、応用範囲が広い製品です。ご興味ある方は是非使ってみて下さい。 お問い合わせ この記事に関するご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社技術支援本部E-Mail：nicp_support@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:#eb6100; 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 #eb6100; transition: all 0.5s ease; } .btn_A a:hover{ background:#f56500; color:#999999; margin-left:0px; margin-top:0px; box-shadow:0px 0px 0px 4px #f56500; } .bigger { font-size: larger; }
