IBM Cloud Docs
NPSaaS に関する FAQ

NPSaaS に関する FAQ

これは、IBM® Netezza® Performance Server for IBM Cloud Pak® for Data as a Service に関するよくある質問 (FAQ) のコレクションです。

ユーザーをオンプレミスの LDAP から NPSaaS に移行し、外部認証機能を有効にするにはどうすればよいですか?

ユーザーを OnPrem LDAP から NPSaaS に移行し、外部認証機能を有効にするには、以下の手順に従います:

  1. NPSaaS で使用する外部認証を有効にして設定する。 詳細については、 認証方法の管理を 参照してください。

  2. 以下のコマンドを使用して、オンプレミス・システムのグローバル・バックアップを取る:

    nzbackup -globals -dir /nzscratch/OnPremGlobals
    
  3. バックアップしたグローバル・ディレクトリをターゲット・システムにコピーします。

  4. ターゲット・システムでグローバルをリストアする前に、以下のクエリを実行して、ソース・システムの現在のユーザ数お よび最新のユーザ作成日を確認します:

    1. 現在のユーザー数を取得します:

      SELECT COUNT(*) FROM _v_user;
      
    2. 最新のユーザー作成日を取得します:

      SELECT createdate FROM _v_user ORDER BY createdate DESC LIMIT 1;
      
  5. 以下のコマンドを使用して、バックアップしたグローバルをターゲット・システムにリストアします:

    nzrestore -globals -dir /nz/OnPremGlobals -npshost <sourcehost> -u <targetSystemUser> -pw '<targetSystemuserPassword>'
    
  6. グローバルのリストア後、以下のクエリを実行して、ターゲット・システムに追加されたユーザ数を確認します:

    SELECT COUNT(*) FROM _v_user;
    
  7. 以下のクエリを実行して、新しく追加されたユーザーの USEAUTH フィールドを更新する:

    UPDATE table_name
    SET use_auth= new_value
    WHERE usename IN (
       SELECT username
       FROM table_name
       WHERE CREATEDATE > <O/P captured in step 4b>
    );
    
    

認証を設定する際には、使用する認証方法を指定する必要があります。 使用可能なオプションは次のとおりです。

認証方法:

  IBM IAM: 3
  Azure AD: 4
  LDAP: 5
  AWS IAM: 6
  SAML: 7
  OIDC: 8

認証方法を選択するには、 new_value を、選択した認証方法に対応する番号に置き換えるだけです。

更新されたユーザー数は、移行されたユーザー数と一致する必要があります。

NPSaaS に登録するにはどうすればよいですか?

無料IBM Cloudアカウントを作成する の。 アカウントがあれば、IBM Cloud®カタログからNPSaaSインスタンスを直接プロビジョニングできます。 詳しくは、 NPSaaS の紹介を参照してください。

NPSaaS インスタンスの資格情報を生成または表示するにはどうすればよいですか?

資格情報を生成するには、以下の手順を実行します。

  1. IBM Cloud アカウントにログインします。

  2. リソースリスト > サービスとソフトウェア > データベース.

  3. NPSaaS インスタンスをクリックしてください。 サービスインスタンスの詳細ページが表示されました。

  4. 「サービス資格情報」 タブに移動します。

  5. **「新規資格情報」**をクリックします。

  6. 資格情報に付ける名前を入力します。

  7. インスタンスを管理するために割り当てられた IAM 役割を選択します。

  8. 追加 をクリックします。 資格情報が正常に生成された場合は、ここで表示できます。 資格情報エントリーを展開します。 以下の資格情報が生成されました。

    • username: admin-インスタンスにアクセスするために作成されたローカル・データベース管理者ユーザーを指定します。
    • password: xxxx-インスタンスに admin としてログインするときに使用する必要があるパスワードを指定します。

    初めてインスタンスにログインした後に、管理者パスワードを変更します。

資格情報を表示するには、以下の手順を実行します。

  1. IBM Cloud アカウントにログインします。

  2. リソースリスト > サービスとソフトウェア > データベース.

  3. NPSaaS インスタンスをクリックしてください。 サービスインスタンスの詳細ページが表示されました。

  4. 「サービス資格情報」 タブに移動します。

  5. 前に生成した資格情報に関連付けられている資格情報エントリーを展開します。

    • username: admin-インスタンスにアクセスするために作成されたローカル・データベース管理者ユーザーを指定します。
    • password: xxxx-インスタンスに admin としてログインするときに使用する必要があるパスワードを指定します。

    初めてインスタンスにログインした後に、管理者パスワードを変更します。

資格情報を生成しました。どのように NPSaaS インスタンスにアクセスできますか?

NPSaaS インスタンスには、専用の Web コンソールや REST API など、いくつかの方法でアクセスできます。

詳しくは、 Netezza Performance Server を参照してください。

クレジット使用量を追跡するために、 NPSaaS インスタンスの消費量の通知をセットアップできますか?

IBM Cloud® Pay-As-You-GoまたはSubscriptionアカウントをお持ちの場合、Eメールによる支出通知を設定できます。 アカウントを設定した後、支出のしきい値を設定し、しきい値の80%、90%、100%に達したときに通知を受け取るように選択することができます。 詳しくは、 使用量通知の設定を参照してください。

NPSaaS では何が管理されていますか?

IBM が、NPSaaS インスタンスのソフトウェアのアップグレード、オペレーティング・システムの更新、およびハードウェアの保守をすべて処理します。 また、IBM は、分析ワークロード全体で最適なパフォーマンスを得るために NPSaaS パラメーターを事前構成し、データの暗号化と定期的なバックアップを行います。

このサービスには、データベースおよびインフラストラクチャーの 24 時間 365 日ヘルス・モニターが含まれています。

ハードウェアまたはソフトウェアの障害が発生した場合は、このサービスが自動的に再始動されます。 NPSaaS は完全管理の SaaS オファリングであるため、基礎となるサーバー・ハードウェアに対する SSH アクセスまたは root アクセスは取得しないので、追加のソフトウェアをインストールすることはできません。

NPSaaS に関する詳細情報はどこにありますか?

  • IBM Cloud 資料サイトに加えて、IBM Documentation には、基礎となる NPSaaS エンジン機能に関する幅広い情報があります。

  • サービスに対する更新は、リリース・ノートに掲載されます。

  • 料金情報は、IBM Cloud カタログ・ページにあります。

詳しくは、IBM 営業担当員にお問い合わせください。

生じている問題に関するヘルプはどこで得られますか?

フォーラムに質問を投稿したり、サポート・チケットを開いたりする方法については、以下を参照してください。

Query History ユーザーのパスワードを変更する方法を教えてください

Query History パスワードは2つの方法で変更できる:

  • クエリエディタの使用
  • リモートnzsqlクライアントの使用

adminまたは管理者権限を持つユーザーで以下のSQL構文を使用する:

  1. 既存の「Query History コンフィギュレーションの名前を決定する。 コンフィギュレーション名は最初に返されるフィールドである:
show history configuration
CONFIG_NAME | CONFIG_DBNAME | CONFIG_DBTYPE | CONFIG_TARGETTYPE | CONFI  G_LEVEL | CONFIG_HOSTNAME | CONFIG_USER | CONFIG_PASSWORD |  CONFIG_LOADINTERVAL | CONFIG_LOADMINTHRESHOLD | CONFIG_LOADMAXTHRESHOLD |  CONFIG_DISKFULLTHRESHOLD | CONFIG_STORAGELIMIT | CONFIG_LOADRETRY |
CONFIG_ENABLEHIST | CONFIG_ENABLESYSTEM | CONFIG_NEXT | CONFIG_CURRENT | CONFIG_VERSION | CONFIG_COLLECTFILTER | CONFIG_KEYSTORE_ID | CONFIG_KEY_ID | KEYSTORE_NAME | KEY_ALIAS | CONFIG_NAME_DELIMITED | CONFIG_DBNAME_DELI  MITED | CONFIG_USER_DELIMITED
-------------+---------------+---------------+-------------------+--------------+-----------------+-------------
  NZ_HIST   | HISTDB        |             1 |                 1 |              2 | localhost       |
TESTUSER    |
y5neWx3HuL2k$w5DqbqJOp+Y= |                     5 |
(1 rows)
  1. Query history(「HISTTYPE 引数で)無効にするコンフィギュレーションを作成する。 例えば、以下はhist_disabledというコンフィギュレーションを作成します:
CREATE HISTORY CONFIGURATION hist_disabled HISTTYPE NONE
CREATE HISTORY CONFIGURATION
  1. hist_disabled コンフィギュレーションを使用するようにシステムをアップデートする。
SET HISTORY CONFIGURATION hist_disabled
SET HISTORY CONFIGURATION
  1. 無効にした「Query History コンフィギュレーションがアクティブになったことを確認する:
SHOW HISTORY CONFIGURATION
| CONFIG_NAME  | CONFIG_DBNAME | CONFIG_DBTYPE | CONFIG_TARGETTYPE | CONFIG_LEVEL |
| -------- | ------- | ------- | ------- | ------- |
| HIST_DISABLED |     |   3  |    1 |   1  | localhost
.
.
.
---------------+---------------+---------------+-------------------+--------------+----------
 HIST_DISABLED |               |             3 |                 1 |            1 | localhost       |             |
.
.
.
 (1 row))
  1. 元の「Query history 設定(nz_hist)で、必要なパスワードを変更する。以下の例では、ユーザー 'qryhist にパスワード new_password が割り当てられています。
ALTER HISTORY CONFIGURATION nz_hist USER qryhist PASSWORD new_password'
ALTER HISTORY CONFIGURATION
  1. パスワードを変更した初期設定(nz_hist)を使用するようにシステムを設定する。
SET HISTORY CONFIGURATION nz_hist
SET HISTORY CONFIGURATION
  1. データベースを停止して再起動し、システムが元の「Query history 構成をロードするようにする(nzstop/nzstart コマンド)。

  2. 設定に加えた変更は、データベースを再起動した後にのみ有効になります。 nzstop/nzstart コマンドで再起動することで、無効化された'Query History コンフィギュレーションをロード(アクティブ化)する。

  3. 正しい「Query History コンフィギュレーションが「SHOW HISTORY CONFIGURATION コマンドで再びアクティブになっていることを確認する。

各'Query History コマンドの完全な説明については、IBM NetezzaDatabaseユーザーズガイドを参照してください。

ALL_HISTというコンフィグ名を使わずに名前をチェックするには?

以下のクエリを実行して、あなたの名前をチェックしてください:

 nzsql -c "SHOW HISTORY CONFIGURATION"

現在のコンフィギュレーションを変更し、パスワードを更新する手順。

  1. 現在のコンフィギュレーションを「hist_disabled」に設定する。

     nzsql -c "set history configuration HIST_DISABLED"
    
  2. データベースを再始動します。

  3. 以下のようにパスワードを変更する。

       nzsql -c "ALTER HISTORY CONFIGURATION <QUERYHIST> PASSWORD '<new password>';"
    
  4. 現在の設定を現在の履歴データベースファイルに設定します。 もし'all_hist があなたの設定なら、次のように変更してください:

       nzsql -c "set history configuration all_hist"
    
  5. データベースを再始動します。

履歴ユーザー・パスワードのリセット時にデータベースを停止して開始するには、チケットを開きます。

プロライフはどこまでスケールアップできるのか?

NC-START から、作業負荷のコンターをNC0にスケールアップすることができる。

AWS上で400GBのストレージ密度を持つNC-START構成から、ストレージをどれだけスケールアップできますか?

AWSの「NC-START ワークロードのコンター内では、ストレージは1200GBまでスケールアップできる。 さらにNC0コンターまで拡張することを選択した場合、ストレージ密度は2400GBから最大24000GBに及ぶ。 同様に、Azure上にデプロイされたNPSインスタンスの場合、基本ストレージは256GBです。 これは「NC-START 作業負荷コンター内で1024GBまで拡張可能である。 NC0コンターへのスケーリングにより、ストレージ密度は1536GBから12288GBの範囲となる。

ストレージのスケーリングの上限は?

NC-STARTワークロードのコンター内では、ストレージは1200GBまで拡張できる。 しかし、ワークロードのコンターもNC0にスケールすれば、ストレージ容量は2400GBから24000GBまで増やすことができる。

NC-STARTコンフィギュレーションからのスケールアップ手順は?

NC-STARTコンフィギュレーションからスケールアップするには、以下のドキュメントリンクに記載されているガイダンスに従ってください: NC-STARTワークロード輪郭(現在400GB)内でストレージを増やすには、以下を参照してください: NC-STARTストレージ・スケーリング・ガイド。 NC-STARTからNC0への作業負荷コンターのスケーリングについては、以下を参照のこと: NC-STARTNC0から。

現在のデータベース構成やデータに影響を与えることなく、規模を拡大することは可能ですか?

はい、現在のデータベース構成と既存のテーブルデータを保持したまま、スケールアップすることができます。

プロファイルをNC0にスケールアップした後、'NC-START に戻すことは可能ですか?

いいえ、一度NC-STARTからNC0にスケールアップすると、NC-STARTに戻すことはできません。

400GBから増やした後、ストレージを縮小することは可能ですか?

いいえ、ストレージは一度スケールアップすると、スケールダウンすることはできません。

SAML 認証を有効にするには、どのようなオプションがありますか?

LDAP内蔵: 他の方法はまだ開発中であるため、現在推奨されているオプションである。

Azure ADだ: なお、MFA(多要素認証)が有効になっている場合は、 Azure ADを使用することはできない。

マイクロソフトが提供するOIDC: 代替認証方法として利用可能。

SAML 認証を有効にするには、更新クエリを実行する必要がありますか?

はい、ユーザー認証設定を変更するには、以下の更新クエリを実行する必要があります:

UPDATE _t_user
SET use_auth = new_value
WHERE usename IN (
    SELECT username
    FROM _t_user
    WHERE CREATEDATE > <O/P captured in step 4b>
);

ユーザーデータの移行はグローバルリストアで十分ですか、それとも追加の手順が必要ですか?

グローバルリストアだけでは十分ではないかもしれない。 上記の更新クエリを実行することで、リストア後のユーザー認証データの適切な移行が保証されます。

NZSaaS、LDAPの設定はオンプレミスとは異なりますか?

設計的には: コンフィギュレーションのアプローチは基本的に同じだ。

コマンド: いくつかのコマンドは、 NZSaaS とオンプレミス環境で若干異なります。