バージョン 1.0.7.0 リリース・ノート (2018 年 4 月)

バージョン 1.0.7.0 には、コールド・データの階層型ストレージの可用性や、IBM Spectrum Protect の LAN フリーのバックアップとリストアの方法などのさまざまな新機能と改善点が含まれます。

Integrated Analytics System バージョン 1.0.7.0 には、DSX Local バージョン 1.1.2.2 が含まれています。詳しくは、What's new in Data Science Experience Local の『What's new in Version 1.1.2 (October 2017)』を参照してください。

IIAS バージョン 1.0.7.0 の新機能

階層型ストレージ

マルチラック構成およびオプションの階層型大容量ディスク・ストレージのサポートを含む、M4002 ファミリーの Integrated Analytics System (IIAS) をサポートします。

アップグレード

アップグレード・コマンド apupgrade は、セッションから切断された場合でも、開始プロセスが失敗しても、引き続き実行されます。

バックアップおよびリストア
  • LAN ベース方式に加えて、新しい IBM Spectrum Protect (TSM) LAN フリー方式をバックアップおよびリストア操作に使用できるようになりました。TSM の LAN フリー・オプションを使用するには、bluadmin ユーザー・アカウントから manage_tsm ツールを使用して、API クライアント、パスワード構成、およびストレージ・エージェントを構成する必要があります。TSM クライアントを TSM サーバーと通信するように構成できるようになったため、クライアントを使用してデータベースのバックアップ・ファイルおよびログを管理できます。デフォルトでは、Db2 Warehouse コンテナーは、ポイント・イン・タイム・ロールフォワードをサポートしない削減されたロギング向けにセットアップされています。そのため、IIAS にあるバックアップとリストアの機能を使用すると、IIAS のデフォルト設定と一致するように TSM へのバックアップが構成されます。現行のデフォルト設定では、ファイル・システム、TSM、または NAS に関係なく、すべてのバックアップのアーカイブ・ログがローカル・ディスクに保存されます。IIAS の Db2 Warehouse コンテナーは、ポイント・イン・タイム・ロールフォワードをサポートするフル・ロギング、およびデータベース・ログを管理する TSM を使用して構成できます。
  • バックアップ操作またはリストア操作を実行する前に、システムで dsmsta.service が検査されます。サービスが既に構成されて実行されている場合、LAN フリーのバックアップまたはリストアの実行中に、そのサービスは引き続き実行されます (サービスがダウンしていた場合はバックアップが開始されます)。LAN フリーのバックアップまたはリストアを実行していない場合、バックアップまたはリストア操作が開始される前にサービスが停止されます。IBM Spectrum Protect にバックアップするか、そこからリストアする場合、システムはまず製品が既に構成されているかどうかを検査します。
  • db_restore コマンドで db_restore -history パラメーターを使用すると、リストア履歴が表示されるようになりました。最新の 10 件のリストアが表示され、残りは /scratch/bluadmin_BNR/restore_history.txt ファイルに書き込まれます。
  • db_backup -history コマンドでバックアップ履歴のみが表示されるようになり、バックアップ履歴とリストア履歴の両方が同じコマンドで表示されることがなくなりました。
  • host_backup コマンドを使用してプラットフォーム・レベルのバックアップを実行できます。これにより、物理災害または論理災害の後でシステムの操作がリカバリーされます。このオプションでは、すべてのシステム構成ファイルとログ・ファイルが /opt/ibm/appliance/storage/platform/host_backup_timestamp ディレクトリーにコピーされ、host_backup_timestamp.tar.gz ファイルが作成されます。
  • db_backup で、bluadmin ユーザーではなく、db2inst1 ユーザーとしてバックアップ・ディレクトリーが作成されるようになりました。
プラットフォーム管理

プラットフォーム・マネージャーで、CPU 頻度がモニターされ、最適でないときにリカバリー・アクションが実行されるようになりました。

信頼性と保守容易性

apdiag ユーティリティーで、デフォルトのログ収集が過去 7 日間に制限されるようになりました。より長い履歴が必要な特殊なケースでは、--atime オプションを使用して時間間隔を変更できます。

セキュリティー
  • ap_external_ldap.pl ユーティリティーの listuseraccess オプションを使用して、外部 LDAP サーバーからシステムにアクセスできるプラットフォーム・ユーザーをリストできるようになりました。このコマンドを実行するには、システムで外部 LDAP が有効になっている必要があります。
  • ap_external_ldap.pl disable スクリプトに、非対話式モード用の -y オプションが用意されています。

解決済みの問題

  • GPFS に接続されている外部ストレージがマウントされていないときに、システムの始動に失敗することがなくなりました。
  • デフォルトの pam 認証設定を変更すると、外部 LDAP ユーザー認証が失敗します。これらの問題が解決されました。
  • apsetup コマンドを使用してネットワークを再構成した後で、データベースがかなりの時間無効になることがなくなりました。
  • サービスの電源サイクル後に docker サービスを再始動しようとして失敗したことによってノードが無効になることがなくなりました。
  • アラート 412 (ノード時刻が同期されていない) が、ノード時刻の同期後に自動的にクローズされるようになりました。
  • 外部 IP がアプライアンスへの 10 Gbps 接続に割り当てられたときに、サーバーの電源サイクル後にゲートウェイ設定が失われることがなくなりました。
  • ファイバー・チャネル・スイッチで PCI デバイス間のカーネルの競合/デッドロックが発生することがなくなりました。
  • 一部のデプロイメント状況で、複数のネットワーク・サービス間で競合状態が発生した場合に、接続が失われることがなくなりました。
  • リストア操作後に db_startsrc -all を手動で実行する必要がなくなりました。リストアの試行が失敗すると、db_restore が自動的に実行されるようになり、HA と DSM の接続が有効になります。
  • アップグレードを実行する前に、/etc/ntp.conf ファイルを手動でバックアップする必要がなくなり、DSX を開始および停止する必要がなくなりました。アップグレード・プロセスで、これらの手順が自動的に処理されます。
  • 以前のリリースでは、外部 LDAP 認証を使用してプラットフォームが既に有効になっている場合に、(ap_external_ldap を使用して) 外部 LDAP 認証を有効にしようとすると、エラーが発生していました。現在では、以前の LDAP 認証を無効にするように指示するメッセージが表示されます。
  • 外部 LDAP 認証を有効にするときに、外部 LDAP 証明書をヘッド・ノードからピア・ノードに手動でコピーする必要がなくなりました。外部 LDAP 認証を無効にするときに、ヘッド・ノードからピア・ノードにコピーされた外部 LDAP 証明書を手動で削除する必要もなくなりました。
  • etcd でキースペースを管理できるようにする自動圧縮機能が提供されました。この機能を有効にすると、etcd がデータベースを自動的に検出して整理し、キースペース制限内に保ちます。
  • ap_external_ldap ユーティリティーを使用してプラットフォームで外部 LDAP 認証が有効になるときに、外部 LDAP 証明書がピア・ノードの /etc/openldap/cacerts/ にコピーされませんでした。これは、オプション CA_CERTIFICATE を使用して提供され、LDAP 証明書をヘッド・ノードからピア・ノードに手動でコピーする必要があります。この問題に対応し、手動で証明書をコピーする必要がなくなりました。
  • ap_external_ldap ユーティリティーを使用してプラットフォームで外部 LDAP 認証が無効になるときに、外部 LDAP 証明書がすべてのノードの /etc/openldap/cacerts/ から削除されませんでした。そのため、手動でノードから LDAP 証明書を削除する必要があります。この問題に対応し、手動で証明書を削除する必要がなくなりました。

既知の問題

  • 現在、NFS マウントは IIAS ノードで正しく保持されません。ノードで NFS マウントを構成しようとして、強制的にそのノードを再始動してから、データベース・クラスターに対して再度有効にする場合、再有効化のプロセスにより、NFS がアンマウントされます。回避策はありません。
  • ノードのコンポーネント・ハードウェアに障害が発生した場合、障害が発生したコンポーネントを特定するロケーション LED が点灯しません。
  • 現在、Web コンソールを使用したリストア操作は、macOS でのみサポートされています。
    回避策
    「Restore to last backup instance」オプションも「Browse all backup instances」オプションも使用できない場合、回避策は、コマンド・ラインを使用して db_restore コマンドと db_backup -history コマンドを実行することです。
  • 現在、Web コンソールを使用した日次または週次のスケジュール済みバックアップ操作も、macOS でのみサポートされています。