前のトピック: 既知の問題

次のトピック: 既知の問題と制限

準備 › リリース ノート › 既知の問題 › 重要な注意事項

重要な注意事項

  1. ADL は、グリッドのインストール/アップグレード、および、カタログとアプリケーションのインポートには使用されなくなりました。 ALD に代わる機能は、Backbone Fabric Controller （BFC）です。 BFC は簡単に使用できる Web ベースの GUI アプリケーションで、1 つのバックボーン内のすべての CA AppLogic グリッドの作成および管理に使用されます。 BFC をダウンロード/インストールする方法、および CA AppLogic グリッドを管理するための BFC の使用方法については、BFC のドキュメントを参照してください。 お使いのグリッドにカタログおよびアプリケーションをインポートするには（CA AppLogic に同梱されている system_ms）、カタログ/アプリケーションをお使いのグリッドの impex ボリュームにコピーし、CA AppLogic コマンド cat import および app import を使用します。
  2. CA AppLogic 3.x は、Xen に加えて VMWare ESX ハイパーバイザもサポートするようになりました。 CA AppLogic 3.x は両方のハイパーバイザの特徴と機能をすべて維持していますが、VMWare ESX と CA AppLogic を一緒に使用する場合に、VMWare ESX に固有の重要な使用方法があります。
  3. CA AppLogic 3.x では、RBAC （Role-Based Access Control、役割ベースのアクセス制御）が導入されています。 RBAC は、オブジェクト（アプリケーション テンプレート、アプリケーション インスタンス、カタログ、またはグリッド）に対して権限（制御権）を付与する機能を提供します。 デフォルトでは、グリッドで新しいユーザが作成された場合、そのユーザのグリッド オブジェクトへのアクセスは制限されています。 たとえばデフォルトでは、そのユーザにはグリッドにログインする権限がありません。 ユーザがグリッドにアクセスできるようにするには、適切なアクセス権を設定する (ユーザとグループの管理, RBAC の概要)必要があります。
  4. Web API を使用して CA AppLogic 3.ｘ グリッドにアクセスする場合、グリッドに対するフル アクセス権限（管理者タイプのアクセス）を持つユーザで Web API アプリケーションを設定する必要があります。
  5. CA AppLogic 3.ｘ では、アプライアンスのオペレーティング システム サポート範囲が以前の CA AppLogic リリースほど広くありません。 3.ｘ では Solaris 10 がまったくサポートされていません。また、OpenSolaris は Xen のみでサポートされています。 Oracle によって OpenSolaris および Solaris 10 が廃止され、Solaris Express および Solaris 11 に置換される予定であることに注意してください。

    注： Solaris ベースのアプライアンスは、Solaris ファイラを除き、CA AppLogic 3.5 以降すべて削除されました。 これらのアプライアンスが必要な場合は、CA Supportにお問い合わせください。

  6. CA AppLogic は、OS に依存せず、さまざまなオペレーティング システムと共に使用できるように設計されています。 その設計の一部として、すべてのボリューム操作（作成/フォーマット、コピー、リサイズ、ファイル システムの確認/修復、および管理）はファイラと呼ばれる CA AppLogic アプリケーションで実行されます。これらの操作は、以前のバージョンの CA AppLogic のように CA AppLogic グリッド コントローラによって実行されなくなりました。 そのため、これらの新しいファイラ アプリケーションは、他の通常の CA AppLogic アプリケーションのようにグリッドのリソースを使用します。 したがって、CA AppLogic のボリューム操作を実行するには、グリッドに十分な使用可能リソースがある必要があります。 ファイラ アプリケーションを raw ボリュームまたはブロック レベルのボリューム コピーには使用しないことに注意します。
  7. グリッド コントローラは、コアの 10% を使用します（ESX および Xen ベースのサーバの両方）。
  8. すべてのボリューム操作はファイラ アプリケーションを使用して実行されるようになったため、以前の CA AppLogic リリースと比較すると、すべてのボリューム操作が遅くなります。これは、ファイラ アプリケーションをボリューム操作の一部として開始/停止する必要があるためです。 一般的に、Linux ベースのボリューム操作には約 20 秒のオーバーヘッドがあり、Solaris ベースのボリューム操作には約 130 秒のオーバーヘッドがあります。
  9. ネットワークの帯域幅のリソース使用状況は、すべてのアプライアンスで取得されます。 アプライアンスは、そのすべての端子用に設定された帯域幅を超えて使用することはできません（割り当てられた帯域幅は、すべての端子が考慮されています）。 アプライアンスおよびアプリケーション用に設定された帯域幅が、帯域幅の使用ニーズに沿って適切であることを確認します（そうしないと、アプリケーションで一部のネットワーク パフォーマンスが非常に遅くなる場合があります）。 CA AppLogic サーバあたりの最大帯域幅は 2 Gb です。
  10. ゲートウェイ、ロード バランサ、およびポート スイッチなどのネットワーク トラフィックをパススルーするアプライアンスでは、実際の帯域幅が半分になります。 たとえば、割り当てられた帯域幅が 100 M であるロード バランサは、実際には 50 M に制限されます（ネットワーク トラフィックがアプライアンスの内側と外側に向かって通過するためです）。
  11. 新しくインストールされた、またはアップグレードされた CA AppLogic グリッドの CA AppLogic GUI にアクセスする前に、ブラウザのキャッシュをクリアする必要があります。 ブラウザのキャッシュをクリアしないと、CA AppLogic GUI が正しく動作しない場合があります。
  12. グリッド シェルには Web ブラウザまたは ssh クライアントを使用してアクセスできます。 セキュリティを強化するために、グリッドのインストールを実行しているとき以外は、パスワードベースの ssh ログインはサポートされていません。

    重要： CA AppLogic GUI と一緒に提供されている Web シェルを使用することを強くお勧めします。

  13. ssh を使用してグリッドにアクセスする場合、CA AppLogic のユーザ名にかかわらず、ログイン ユーザ名には常に root を使用します。 ssh ログインを行うために、ユーザとユーザの役割は公開 ssh キーによって一意に識別されます。
  14. Web ベースのグラフィカル ユーザ インターフェース（ダッシュボード、エディタ、ドキュメント）を使用するには、Web ブラウザの Javascript とポップアップを有効にする必要があります。
  15. ユーザは、外部に表示可能なアプリケーションの IP アドレスの割り当て、指定、および使用を担当します。CA AppLogic はすべての内部ネットワークの割り当てを担当します。
  16. Backbone Fabric Controller が事前に注意深く設定されたファイアウォールを使用してすべてのグリッド サーバおよびコントローラをセットアップし、不要なネットワーク サービスを無効にする間に、ユーザと管理者はシステムのセキュリティ設定を確認することをお勧めします。
  17. ボリュームとアプライアンス間通信に使用されるプライベート ネットワークのサーバ間のネットワーク パフォーマンスは、およそ 900 Mbps です。 別のサーバに存在するアプライアンス間で測定された TCP ネットワーク パフォーマンスは、720 ～ 900 Mbps です。 Windows を実行している場合、TCP ネットワークのパフォーマンスは約 940 Mbps です。また、UDP の場合は約 500 ～ 700 Mbps です。
  18. アプライアンスのハードウェア リソースに対するリソース制限は、さまざまなリソース タイプ（CPU、メモリ、帯域幅）ごとに別々に実施されます。 CPU は「最小値」、メモリは「厳密な値」（VM オーバーヘッドを含む）、帯域幅は「厳密な値」です。 アプリケーションの開始時に新しい --cap_cpu オプションを使用して、CPU リソースに対して「その値に等しい」を実施することができます。
  19. 指定された最小限の CPU を使用してアプリケーションを開始する場合、アプリケーションが指定された CPU の量を正確に取得しているかどうかは保証されません。 たとえば、アプリケーションを cpu=2 で開始する場合、アプリケーションのすべてのコンポーネントに対して割り当てられた CPU をすべて合計するとわかるように、アプリケーションが 1.97 という CPU 量を受信する可能性があります。 これは、個別のコンポーネントに CPU を割り当てるときに発生する場合がある丸め誤差によるものです。
  20. アプリケーションの開始が失敗した場合、失敗に関連するすべてのメッセージがシェルに表示されるとは限りません。 追加情報については、list log n=20 コマンドを使用してグリッド ログを調査します。
  21. パフォーマンスのリニア スケーラビリティを重視するグリッドでは、CPU タイプ/速度、メモリ サイズ、およびディスク容量ができるだけ同じであるサーバを使用して構築する必要があります。 ハードウェア リソースの量が異なるサーバで構築されたグリッドでも CA AppLogic は正常に動作しますが、このようなグリッドでは、リニアよりもパフォーマンスが遅くなる場合があります。
  22. グリッド コントローラの VM に障害が発生したためにグリッド コントローラが再起動している間に、ユーザには何も表示されません。 グリッド コントローラの VM に障害が発生し、CA AppLogic がグリッド コントローラの VM を再起動する場合、コントローラが再起動している間にユーザには何も表示されません。 通常は、グリッド コントローラが自力で再起動するのに 1 ～ 2 分かかります。 グリッド コントローラが 5 分以上使用できない場合は、CA Supportにお問い合わせください。
  23. NTFS03 ボリュームを作成すると、常に NTFS08 ボリュームになります。 NTFS08 ボリュームは Windows Server 2003 と一緒に使用することができます。
  24. ESX ベースのグリッド/サーバでは、グリッドとサーバ用の net_discover コマンドはサポートされていません。
  25. CA AppLogic グリッドで SAN を使用している場合は、設定された NFS 共有を使用しているグリッドごとに、少なくとも 500 GB の空き容量が存在することを確認してください。 たとえば、NFS 共有が 5 つの異なるグリッドに使用される場合、その共有には 2.5 TB の空きディスク容量が存在する必要があります。
  26. CA AppLogic グリッドで SAN を使用している場合は、SAN または NFS 共有が少しの期間でもオフラインになると、使用されていたボリュームの一部が破損する可能性があります。 この破損によってグリッド コントローラが動作できなくなったり、アプリケーションの開始に失敗したり（または、その他のグリッドやアプリケーションが不安定になったり）する場合は、すぐにCA Supportにお問い合わせください。
  27. 最新の OS ディストリビューション（Fedora Core、Ubuntu、Debian および CentOS など）に基づいて CA AppLogic アプライアンスを使用するには、アプライアンス境界に新しいフィールド エンジニアリング コードとして 128 を設定します。 この新しいフィールド エンジニアリング コードは、新しいディストリビューションによって使用されるアプライアンス ボリュームに、新しいデバイス名スタイルを使用するよう CA AppLogic に指示します。 128 のフィールド エンジニアリング コードが指定されない場合、これらの新しいディストリビューションに基づいたアプライアンスは起動に失敗します。
  28. お使いのプライマリまたはレプリカの BFC データベースのいずれかが失われるか破損した場合、BFC の 3.1 バージョン以降常に実行されている自動バックアップから回復できる可能性があります。 これらのバックアップは、実際にはプライマリ データベースのサブディレクトリに存在するため、レプリカの設定の代わりになるものではありません。 （設定した場合はこれらのバックアップがレプリカのサブディレクトリにも書き込まれます。）最新のバックアップからリストアするには以下の手順に従います。