このセクションには、以下のトピックが含まれています。
注： Solaris ベースのアプライアンスは、CA AppLogic® 3.7 以降すべて削除されました。
重要： CA AppLogic® GUI と一緒に提供されている Web シェルを使用することを強くお勧めします。
このセクションでは、現時点での既知の問題と制限事項について説明します。
これは、アプライアンスが自分に接続されたアプライアンス（および自分自身のサーバとグリッド コントローラ）のみと通信できることを意味します。 ただし、アプリケーション設計の整合性と CA AppLogic® の今後のバージョンとの互換性を保証するために、新しいアプライアンスのプロトコルを正しく指定する必要があります。
grid info コマンドによってレポートされた使用可能なディスク空き容量の合計はそのままの推量であり、ボリュームのミラーリングが考慮されていません。 本当に使用可能なディスク空き容量は、使用可能な空き容量をミラー数（デフォルトでは 2 つのミラー）で割った値です。 たとえば使用可能なディスク空き容量が 1000 GB あり、グリッドには 2 つのミラーリングが設定されている場合、使用可能なディスク空き容量は 500 GB になります。 また、ボリュームを正常にミラーリングするには、少なくとも X （ミラーの数）台のサーバに十分なディスク空き容量が必要です（いずれかのミラーを作成できない場合、CA AppLogic® はボリュームの作成に失敗し、ボリュームをミラーリングできなかったことを示す警告を表示します）。
アプリケーションを開始し、いずれかのグリッド サーバに障害が発生した場合に、障害が発生したサーバで 1 つ以上のアプリケーションのアプライアンスが実行されるようにスケジュールされていると、そのアプリケーションの開始が失敗します。 この状況が発生した場合は、単にアプリケーションを再起動します。
さらに大きなファイルをボリュームにアップロードするには、vol manage シェル コマンドを使用します。ボリューム マネージャの内部からのリモート アクセスを有効にするには、必ずこのコマンドに外部 IP 設定を指定してください。 詳細については、vol manage コマンドのリファレンスを参照してください。
新しい dhcp 環境設定モードでは、アプライアンス設定用のプロパティ マークアップをサポートしていません。 volfix から dhcp 環境設定モードにアプライアンスを移植する場合に、アプライアンス設定用のプロパティ マークアップに依存するアプライアンスを処理する方法については APK のドキュメントで説明しています。 詳細については、アプライアンス キット（APK）を参照してください。
アプリケーションの検証フラグを表示するには、編集モードでアプリケーションを開きます。 検証フラグは、一部の必須のプロパティ/端子/ボリュームが適切に設定されていないアプライアンスにフラグを付けるために使用されます。
そのため、グラフィカル コンソールをこれらのアプライアンスと一緒に使用できません。 これは、アプライアンスをできるだけコンパクトにするために、意図的に行われています。 新しい iso2class ユーティリティを使用すると、ユーザはデスクトップを完全にサポートする独自のアプライアンスを作成できます。
このエラーは、CA AppLogic® がアプライアンスのコンピュータ名をインスタンス名に設定するために発生します。 そのため、グリッドにすべてが同じインスタンス名を持つ複数のアプライアンスがある場合、Windows のグラフィカル コンソールに名前の重複エラーが表示されます。 このエラーは単に警告であるため、グリッドまたはその操作には影響しません。 ただし、Windows をドメイン コントローラとして使用する必要がある場合は、各アプライアンスでコンピュータ名に一意の名前を設定する必要があります。 アプライアンスのコンピュータ名を設定するには、wincfg ユーティリティを使用できます。
最新バージョンの Java が使用されていないと、グラフィカル コンソールが正常に動作しない場合があります（ロードされる際にハングアップします）。 グラフィカル コンソール エラーが発生した場合は、CA にレポートする前に、必ず最新バージョンの Java が使用されていることを確認してください（ブラウザで Java をアップグレードする必要がある場合は、グラフィカル コンソールが正常に動作できるように、アップグレード後に必ずブラウザをいったん閉じて再度開いてください）。
セカンダリ サーバが新しいプライマリ サーバの役割を引き受けたときに、グリッド コントローラを開始するための十分な利用可能リソースがサーバ上にない場合、CA AppLogic® は新しいプライマリ サーバ上で実行されているアプライアンスをグリッド内の他のサーバ上で再起動し、新しいプライマリ サーバ上でグリッド コントローラを開始できるようにします。 これによってアプライアンスのフェールオーバ グループが分割される場合があることに注意します。 CA AppLogic® がこれらのアプライアンスのいずれかを停止すると、フェールオーバ グループに対応するための十分なリソースがなくなり、別のサーバ上でアプライアンスを再起動できなくなることがあります。
すべての HVM ベースのアプライアンス（Windows など）は、使用できるように設定された容量よりも多くのメモリをサーバで使用します。 通常、HVM ベースのアプライアンスに割り当てられたメモリの量によって、アプライアンスは実行しているサーバの増設メモリを使用します（この増設メモリはサーバで実行している仮想化ハイパーバイザが必要としており、シャドウ メモリと呼ばれます）。 そのため、HVM ベースのアプライアンスがサーバでは使用できない追加のシャドウ メモリを必要とするために、アプライアンス用に割り当てられた量と比べてサーバには使用可能なメモリが十分にあるとしても、アプライアンスをそのサーバで実行できない可能性があります。 CA AppLogic® のスケジューラは、アプリケーションの開始中にアプライアンスをスケジュールするときに、この追加のシャドウ メモリを考慮します。
代わりに他のブラウザを使用できます。
共有インターフェースは、他のすべてのオペレーティング システムで動作します。
このリリースの既知の問題は以下のとおりです。
グリッドおよびグリッド コントローラ自体に高い負荷がかかっている場合、さまざまなグリッド コントローラ コマンド（たとえば、app provision/vol resize）が失敗し、GUI のネットワーク エラーが発生します。 この問題が発生する場合、グリッド コントローラ CPU を 1 に増加させて、メモリを少なくとも 2 GB に増加させて、問題を回避する必要があります。
この問題は後続のリリースで修正されます。
この問題を回避するには、アプライアンスの固定を解除し、アプリケーションを再起動します。 この問題は後続のリリースで修正されます。
現在、ファイラは同時に 2 つの ext3-snapshot ボリュームを管理することをサポートしていません。 この問題は将来のリリースで修正されます。
ライトキャッシュが有効でない HP Smart アレイ RAID コントローラを使用すると、パフォーマンスが 50% 低下します。 この問題は、HP DL 580 G7 サーバで Smart アレイ P410i 256mb を使用して確認されています。 これらのカードでは、ライトキャッシュを有効にするためにバッテリまたはキャパシタが搭載されている必要があります。
ServerEngines Corp を使用する場合、 Emulex OneConnect 10Gb NIC （be3） （rev 01）を CA AppLogic® と共に使用する際に、SR-IOV BIOS オプションが有効であると、これらの NIC で不適切なバウンスが発生します。 これらバウンスが発生したパケットがブリッジの転送キャッシュを変更し、そのためにブリッジはパケットを正しい宛先に転送せずにドロップします。 これにより、CA AppLogic® が不安定になり、アプリケーションの起動エラーが断続的に発生します。 したがって、グリッド内のすべてのサーバ上のすべての Emulex 10G NIC で、SR-IOV BIOS の設定が DISABLED になっている必要があります。
非常にまれですが、いずれかのサーバでスタック ボリュームがマウントされているために、アプリケーションの開始が失敗します。 CA AppLogic® はスタック ボリュームのマウントを検出し、それをグリッドのダッシュボードのユーザにレポートします。 お客様のグリッドでこの問題が発生した場合は、CA サポートにご連絡ください。 任意で、サーバを無効にするか、スタックをマウントしているサーバを再起動すると、この問題が解決されます。
この状況が発生した場合、プライマリ サーバを再起動すると、グリッドが稼働状態に戻ります。 この問題は CA AppLogic® 3.5 または 3.7 では考察されていないことに注意してください。
今後、グリッド コントローラに高い負荷がかかっている場合に、GUI が自動でユーザをログアウトさせることはありません。 代わりに、ユーザはネットワーク エラーが発生したというメッセージを受け取ります。 ただし、この場合 GUI はまだ完全に機能しています。 4 つのアプリケーションを同時に開始し、かつ大規模な複数 GB のボリュームをコピーするなど、コントローラに重い負荷がかかっている場合にのみ、ネットワーク エラー メッセージを受け取ります。 大規模なグリッドでは、コントローラに最大ですべての CPU コアと 1 GB の RAM を割り当ててみます。
grid reboot コマンドを使用してグリッドを再起動する場合、再起動の後、グリッドが元の状態に戻るときに、1 つ以上のシステム ボリュームが劣化する場合があります。 CA AppLogic® は、自動的に最優先でこれらのボリュームを修復します。
ボリュームをマイグレートする場合、少なくとも 1 つのストリームが有効なサーバ上にあることを確認します。ストリームがない場合は、マイグレート コマンドが失敗します。 ボリュームを 2 回マイグレートすることにより、元のサーバ セットのボリュームを完全にマイグレートできます。
一部の物理サーバは再起動に長い時間がかかる場合があります。そのために CA AppLogic® の自動グリッド復旧が失敗する場合があります。 最終的には、グリッドが障害から復旧した後に、すべてのアプリケーションが必ずしも自動的に再起動されない場合があります。 これは、すべてのサーバが再起動し、グリッド コントローラに再接続するために、グリッド コントローラが最大で 10 分間待機するためです（この時間は、すべてのサーバが再起動するには十分でない場合があります）。 回避策は、すべてのサーバがグリッド コントローラに再接続した後に、手動でアプリケーションを再起動することです。「list srv」を実行してすべてのサーバがグリッド コントローラに接続したことを確認します（すべてのサーバが稼働状態になるはずです）。 CA AppLogic® 2.1 ではサーバ ブートのタイムアウトが 10 分ですが、主にハードウェアまたは BIOS の誤動作のためにサーバがブートに失敗する場合に、このような状態が発生する場合があります。
オペレータがグリッドを再起動すると、グリッドのフラッピング状態はリセットされることになっています。また、オペレータがグリッドを意図的に再起動したことを示すメッセージ（「グリッドは、...でオペレータによって再起動されました」など）がダッシュボードに表示されます。 グリッドを再起動してもグリッド ファイルがリセットされず、ダッシュボード メッセージも表示されない場合があります。 このような状態を引き起こす可能性がある唯一の問題は、次のグリッドの失敗に関するもので、アプリケーションが自動で再起動されない場合があります（このバグが発生したときに、グリッドが何回失敗したかによります）。 この問題を回避するには、意図的にグリッドを再起動した後にダッシュボード メッセージが表示されなかった場合、CA サポートに連絡して、グリッドのグリッド フラッピング状態をリセットしてもらいます。
リソースがわずかに少なくなっている理由は、サービス領域の割り当てに関連します。 メモリについては、Xen の仮想マシンのメモリ マップ テーブルに関連するためと考えられます。 ディスクについては、通常のファイル システム サービス領域によるものです（これは標準的な Linux サーバと同じです）。
この場合、他のユーザが編集するためにアプリケーションを開いていないのに、CA AppLogic® エディタが、他のユーザが編集のためにアプリケーションを開いていると誤って認識しています。 このような状態が発生した場合は、アプリケーションを開いていることに関してエディタがメッセージを表示しても、単にアプリケーションのロックを無視します。
CA AppLogic® インフラストラクチャ エディタでアプリケーションを開くと、大きな遅延が発生します。
クライアントがグラフィカル コンソールを開いており、そのインターネット接続が失われた場合（クライアントのネットワーク カード エラー、クライアント コンピュータのクラッシュ、インターネットにアクセスできない、など）、グラフィカル コンソールを再度開くには 15 分かかります。
CA AppLogic® のグラフィカル コンソールを使用している場合、Ubuntu でマウスを簡単に使用できません。 これは Xen の VNC サポートの制限によるものです（マウスのアクセラレーションがサポートされていません）。 一部のユーザから Ubuntu でマウスの設定を調節すると問題が解決されるとレポートされています。 また、キーボードからテキストを入力するときに、まれにキー入力が複数回繰り返されることがあります（このような場合は、単に表示された余分な文字を削除します）。
これには、アプライアンスにログインする場合のパスワードも含まれます。 テキスト ブート コンソールは、デバッグ目的のみに使用する必要があります。 代わりに、SSH コンソールは他のすべての目的に使用できます。
テキスト ブート コンソールをすでに開いた後に、ユーザがアプライアンス用のテキスト ブート コンソールを再度開いた場合、ログイン プロンプトまたはコマンド プロンプトのいずれかを表示するには、Enter キーを押す必要があります。 これは、ブート コンソールがユーザ入力（ログイン情報または実行するコマンドのいずれか）を待機しているためです。
グリッドにセカンダリ サーバで実行しているフェールオーバ グループに含まれるアプライアンスがあり、そのセカンダリ サーバーでグリッド コントローラを再起動する必要がある場合、CA AppLogic® がそのアプライアンスを停止したためにフェールオーバ グループが分割される場合があります。
グリッドを最新のリリースにアップグレードすると、ハードウェアの問題のためにグリッドに障害が発生したことを示すダッシュボード メッセージが表示されます。 このメッセージを無視しても問題はありません。また、このメッセージをダッシュボードから削除できます。
CA AppLogic® でネットワーク HA 設定を使用し、外部ネットワークに障害が発生した場合、外部インターフェースを使用するアプリケーション/アプライアンスが最大 5 分間アクセスできなくなる場合があります。 これは、MAC アドレスをキャッシュする外部ルータが原因だと考えられます。 ルータが ARP のキャッシュをフラッシュするまで待機するか、またはアプリケーションから arp を実行して ARP 応答を送信することにより、正常な状態に戻ります。 これは、外部ネットワークにのみ影響します（バックボーン ネットワークには影響しません）。
復旧 GUI は Xen ベースのサーバでのみ動作します。
共有インターフェースはアプライアンス カウンタをサポートしていません。
ユーザがグリッドの電源を入れ直した場合、システム稼働時間はリセットされません。 グリッドが再起動された場合は、システム稼働時間がリセットされます。
grid power_cycle コマンドを使用してグリッドの電源を入れ直した場合、プライマリ サーバが再起動しない場合があります。 これは、新しいグリッドのインストール後にコマンドが実行され、power cycle コマンドを実行する前にグリッドが再起動されたことがない場合に発生します。 新しいグリッドのインストール後にグリッドをいったん再起動しておくことで、この問題を回避できます。
SAN を使用していたグリッドが破棄された場合、CA AppLogic® は SAN 上のそのグリッドのフォルダの内容を削除しますが、空のフォルダが残されます。 この問題は将来のリリースで解決されます。
非常にまれに、3.0 または 3.1 から 3.7 へのアップグレードが失敗することがあります。 アップグレードのこの特定の失敗では、BFC を使用してアクセスされるグリッドのステータス ログに以下のメッセージが存在します（グリッドのステータスをクリックしてログを開きます）。
installing the controller image ioctl: LOOP_SET_FD: Device or resource busy installing new controller FAILED, aborting
ログにこれらのメッセージが存在する場合は、アップグレードを再実行すれば成功するはずです。
注： この問題は、実際には CA AppLogic® 3.0 および 3.1 の両方のバグであり、CA AppLogic® 3.7 では解決されています。
ESX ベースのグリッドの場合、3.5 から 3.1 への rollback コマンドが機能しません。 ただし、回避策として downgrade コマンドを使用できます（ダウングレードはロールバックより少し時間がかかることに注意してください）。 この問題は将来のリリースで解決されます。
ext3-snapshot ベースのボリュームは、ESX ベースのグリッド上では動作しません。 ただし、これらのボリュームは Xen ベースのグリッドでは動作します。 ESX ベースのグリッドを使用していて、ext3-snapshot ボリュームを使用する必要がある場合は、グリッドに Xen ベースのノードを追加し、そのノードを使用して ext3-snapshot ボリュームを作成または管理することができます（ボリューム コマンドの実行中に、Xen ベースのノードで CA AppLogic® ファイラが動作するように、すべての ESX サーバを無効にします）。 この問題は将来のリリースで解決されます。
ローカル SAN のボリューム ストリームをマイグレートしようとすると、外部 SAN を使用するように設定されているグリッドで失敗する場合があります。 CA AppLogic® は、ボリューム ストリームをローカル SAN ではなく、外部 SAN にマイグレートしようと試行します。 この問題が発生した場合は、「vol migrate」コマンドで「store=local」オプションを使用してください。 この問題は将来のリリースで解決されます。
CA AppLogic® を 3.0.30 から 3.5.x にアップグレードすると、グリッド コントローラが断続的にハングアップします。また、3tshell コマンドを実行すると、メモリ不足のエラー メッセージが返されます。
この問題を回避するには、グリッド コントローラを再起動します。 この問題は将来のリリースで解決されます。
注： これは 3.7 リリースにも影響する可能性があります。
非常に大きいサイズの NTFS ベースのボリューム（多くの場合 GB サイズ）をサイズ変更している間、サイズ変更操作は進捗状況のレポートを停止することがあり、スタックしているように見えることがあります。 しかし、サイズ変更操作は実際には進行中であり、正常に完了します。 このレポートの問題は将来のリリースで修正されます。
CA AppLogic® 3.1 以降、MegaRAID SAS ドライバのパフォーマンスが低下し、物理サーバと比較して ～75% 低速に動作します。 CA は、この問題の解決に現在取り組んでおり、問題を特定して修正が行われ次第、直ちにホットフィックスをリリースします。 この問題が解決されるまでは、別のタイプのディスク コントローラをご使用になることを強くお勧めします。
現在、Windows 2008 DataCenter エディションのアプライアンスは、8 つを超える CPU を使用するように設定した場合、開始に失敗します（Xen ベースのグリッドのみ）。 この問題は将来のリリースで修正されます。
CA AppLogic® 3.7 で配布される最新の Windows APK にアップグレードしようとすると、Cygwin のアップグレードで問題が生じます。 この問題が修正されるまで、アップグレードではなく新しい Windows アプライアンスを作成することをお勧めします。 この問題は将来のリリースで修正されます。
ssh で 3t コマンドを実行する場合、パラメータはスペースまたはバッククォート（'）のいずれかで区切られます。これはコマンドが呼び出された方法によって変わります。 3t コマンドのプロパティ値にスペースが存在する場合、スペースの後の文字は別の引数として不正に処理されます。 この問題は将来のリリースで修正されます。
http_port プロパティが無視されます。ポートは常に 8080 になります。 この問題は将来のリリースで修正されます。
Xen ベースのグリッドで、90 を超える HVM ベースのアプライアンスを開始しようとすると、マウント エラーまたはアプライアンスの開始エラーで失敗することがあります。 これは既知の問題で、将来のリリースで解決されます。
Safari の以前のバージョンを使用するか、次のリンクからこの問題に対応する回避策を参照してください。
このリリースでの Windows アプライアンスに関する主要な既知の問題を以下に示します。 また、追加の手順および注意事項については、「Windows アプライアンス インストール」を参照してください。
32 ビット Windows 8 は、現在 Halsign Turbogate ドライバによってサポートされていません。ただし、Windows 8 の 64 ビット バージョンはサポートされています。 この問題は後続のリリースで修正されます。
Windows APK は、現在重複した IP アドレスのアサインを正しく検出しません。 そのため、重複した IP アドレスが誤って割り当てられたかどうかはユーザが判断します。 この問題は後続のリリースで修正されます。
ソース ボリュームに破損しているディレクトリ エントリ/ファイルが含まれている場合、Windows ファイラのボリューム リサイズ操作に失敗する場合があります。 この問題の主な原因は、Microsoft ソフトウェアのインストールの一部に、意図的に無効なディレクトリ エントリが含まれていることに起因します（弊社ではこの理由を把握していません。この状況は、あるバージョンの Microsoft SQL Server をアプライアンスにインストールした場合に発生します）。 また、通常の損傷によりソース ボリュームが破損する場合もあります。 この問題は、ボリュームのサイズを変更する前に、ボリュームでファイル システムの修復を実行することにより回避できます（vol fsrepair）。
CA では、NTFS ボリュームのリサイズ操作が 100 回のうち 2 回失敗することを把握しています。 この 2 回の失敗は、グリッドで Windows ファイラが正常に開始しなかったために発生しました。 この問題が発生する場合、リサイズ操作を 2 回繰り返すと成功します。 ただし、この問題はこのリリースで解決されているはずです。この問題が発生する場合は、CA テクニカル サポートにご連絡ください。
Windows ファイラは、Windows の NTFS ボリュームを処理する際に diskpart と呼ばれる Microsoft のユーティリティを使用します。 diskpart がボリューム情報を取得しない、またはボリュームのマウントに失敗する場合があります。 これは非常にまれな失敗で、NTFS ボリュームをフェールオーバーするための vol create または vol resize のいずれかが原因である可能性があります。
Windows アプライアンスを含むアプリケーションがあり、1 つ以上の Windows アプライアンスをアプリケーションに追加するか、Windows アプライアンスに対して端子を追加/削除する場合、最初のアプリケーションが開始する間に一部の Windows アプライアンスが内部ネットワークの重複した IP を検出する場合があります（これは、アプリケーションが変更された後に、最初のアプリケーションを開始するときのみに発生する場合があります）。 これは、アプリケーションの操作の失敗を引き起こすものではなく、ユーザの介入が必要であるものでもありません。重複した IP アドレスは単に一時的なものです。 悪くすると、Windows アプライアンスを含むネットワーク通信の一部が最大で 30 ～ 60 秒遅れる場合があります。
99% でハングアップした Windows アプリケーションを停止しようとすると、この操作が 15 分後にタイムアウトします。 このアプリケーションには、Windows Server 2003 DataCenter Edition のアプライアンス（WIN03DC）の 2 つのインスタンスが含まれていました。 1 つの Windows アプライアンスは停止し、もう 1 つのアプライアンスは「comp stop」の実行中にハングアップしました。 この状況は 1 回のみ発生しましたが、再現できませんでした。
Windows アプライアンスの以下のようなディスク I/O カウンタで、持続した I/O が生成されていてもゼロがレポートされる場合があります： 書き込み/読み込みの合計バイト数、書き込み/読み取りボリューム数、書き込み/読み取りにかかった時間。 これは Windows PerfMon API のバグによるものです。ゼロという値は Windows PerfMon API がレポートした内容です。
ファイラの MSI 以外は、ローカライズされた日本語の Windows は CA AppLogic® で動作します。
MagicISO 仮想 DVD-ROM デバイスがインストールされている場合、Windows アプライアンスの開始が失敗します。 Windows ベースのアプライアンスの場合、現在 CA AppLogic® では仮想 DVD-ROM デバイスをサポートしていません。
Windows がアプライアンス内部の新しい NIC を検出するのに数分かかる場合があります。 これは、ユーザが Windows アプライアンス シングルトンの端子を追加/削除した場合に発生します。 これらの新しい NIC を検出するために余分な時間がかかると、アプライアンスのブートでタイムアウトが発生する場合があります。 これを回避するには、Windows アプライアンスのブート タイムアウトを増やします。
グリッドに Windows アプライアンスがあり、別のハードウェアを持つ別のグリッドにアプライアンスをマイグレートすると、Windows アプライアンスの再アクティブ化（Microsoft の Windows の再アクティブ化）が必要になる場合があります。 再アクティブ化は、特定の数のハードウェアが変更された場合にトリガされます（どのハードウェア変更が再アクティブ化のトリガになるかは、CA では正確に把握していません）。 再アクティブ化には、Windows アプライアンスの内部からインターネットにアクセスしなければならない場合があることに注意します。 この特定の問題は、Windows アプライアンスのブート ボリュームのサイズを変更し、アプライアンスを別のグリッドにマイグレートした後に発生しました。
この問題は Windows 2008 Server 32/64 ビットのみに影響します（Windows Server 2003 では問題なく動作します）。 ファイラまたは ssh を使用して Windows 2008 ボリュームがアプライアンスにアクセスする場合、権限の問題でユーザがファイルにアクセスしたりファイルを変更できない場合があります。 コマンド シェルを使用してファイルにアクセスしたりファイルを変更したりするには、グラフィカル コンソールから Windows デスクトップにログインしてコマンド シェルを開きます。 コマンド シェルを使用してファイルにアクセスしたりファイルを変更できます。
Windows Server 2003 はインストール中に初めてブートする際にタイムアウトします。 この問題を回避するには、必ず Windows ビルドの指示に従ってください。
Turbogate PV ドライバのインストールでは、Xen ベースのグリッド サーバ上で実行される場合、アプライアンスを最初に開始した時点で、アプライアンスに設定されているすべての端子に対して Turbogate PV ドライバのインストール用のハードウェア セットアップ ウィザードを、ユーザが手動でクリックしていく必要があります。 そうしないと、アプライアンスが開始されません。
新しい 32/64 ビットの Windows 2003 サーバ アプライアンスを作成した場合、アプライアンスは、アプライアンスが最初に作成されたハイパーバイザと同じものを使用するグリッド サーバ上でのみ動作します。 それ以外の場合、アプライアンスは起動中にクラッシュします。 たとえば、アプライアンスが最初に ESX ベースのグリッド サーバで作成された場合、このアプライアンスは ESX ベースのグリッド サーバでのみ使用できます（このアプライアンスを XEN ベースのグリッド サーバで使用しようとすると、アプライアンスは起動中にクラッシュします）。
これは Microsoft Windows Server 2003 の既知の問題です。 Microsoft は、Windows 2003 アプライアンスに関するこの問題の解決策を用意しています。
以下のリストに示す問題は、CA AppLogic® リリースで発生しましたが、（再現できるとしても）再現するのが非常に困難であり、一度か二度しか発生していません。 これらのいずれかの問題がお客様のグリッドで発生した場合は、どの問題が発生したのか、およびエラーが発生したときに CA AppLogic® のどのコマンドを実行したのかを説明するバグ レポートを CA にお送りください。
サーバの dom0 で Linux カーネルがクラッシュしたために、グリッド内のサーバが自力で再起動しました。 前の CA AppLogic® リリースのように、これによってグリッド全体に障害が発生したわけではありませんが、アプリケーションのダウンタイムを引き起こす可能性があります。 このような場合、CA AppLogic® は障害の発生したサーバで実行したアプライアンスをグリッド内の他のサーバで再起動します。 この問題がお客様のグリッドで発生した場合は、CA サポートにご連絡ください。
CA AppLogic® 2.4 では、サーバがグリッド コントローラへの接続を失い再起動するケースがいくつかありました。 これによって、あるサーバで実行していたすべてのアプライアンスが、グリッド内の他のサーバで再スケジュールされます。またアプリケーションのダウンタイムを引き起こす可能性もあります。 サーバがグリッド コントローラへの接続を失った理由は不明です。 CA AppLogic® では、サーバのグリッド コントローラへの接続が失われた場合、サーバはグリッド コントローラへの再接続を試みます。成功した場合はサーバはそのまま操作可能になり、アプリケーションのダウンタイムは発生しません。 1 分間のうちにサーバがグリッド コントローラに再接続できない場合、サーバは再起動され、アプリケーションのダウンタイムが発生します。 サーバがグリッド コントローラへの接続を失った場合、メッセージがダッシュボードのログに記録されます。 この問題が発生した場合は、すぐに CA サポートにご連絡ください。
CA AppLogic® では、4 つの NTFS ボリュームのリサイズを同時に実行すると、4 つのボリュームすべてのサイズ変更操作が失敗します。 この問題は 1 回のみ発生しています。
NASR が 1 GB のボリュームで 800 MB のファイルをレプリケートしている間に、NASR アプライアンスが応答しなくなりました。 CA ではこの問題を再現できません。 お客様のグリッドでこの問題が発生した場合は、CA のサポートにご連絡ください。
ユーザがグリッドで実行しているさまざまな Windows アプライアンスに対して 6 つ以上のグラフィカル コンソールを開きました（同時に）。 7 番目のグラフィカル コンソールを開いたときに、サーバの 1 つが再起動し、グリッドに再追加されました。 障害の発生したサーバで実行していたアプライアンスは、グリッド内の他のサーバで再起動されました。 この問題は 1 回のみ発生しています。
このリリースでは、Backbone Fabric Controller （BFC）に関する以下の既知の問題が確認されています。
su - bfcadmin
重要： この接続状態を切断した後は、システムはレプリカなしで実行されています。そのため、UI に戻り、同じ場所または別の場所で再度レプリカへの接続を確立します。
グリッド上で「3t grid shutdown」コマンドを使用しないでください。
この問題が発生する場合は、BFC で「service nfs restart」を実行して解決してください。
このメッセージが表示される場合は、Esc キーを押してインストールを続行します。
このバージョンの製品で自動インストールを行う場合、ユーザのパスワードに "=" を含めることはできません。
このバグでは、ブロックすべきサーバがグリッドに含まれてしまう場合があります。 ポートを適切に設定すれば、この問題は発生しません。
256 文字を超える文字を使用する場合は、パラメータを複数のグリッドに分割します。
グラフィックス レンダリング オプションが Internet Explorer 9 で正しく設定されていない場合、BFC のグラフは正しく表示されません。 影響を受けたグラフが BFC ダッシュボード、グリッド、およびサーバ ページに表示されます。
この問題を修正するには、Internet Explorer 9 で［ツール］メニューの［インターネット オプション］をクリックします。 ［詳細設定］タブをクリックし、［アクセラレータによるグラフィック］セクションを見つけます。 ［GPU レンダリングでなく、ソフトウェア レンダリングを使用する］チェック ボックスをオンにします。 変更を保存し、IE を再起動します。
これらの多くの MAC を AutoDiscovery （ブラックリスト）モードに設定する必要がある場合、3.5 で手動設定（ホワイトリスト）モードを使用することをお勧めします。
サーバが BFC に追加されるときに利用可能な外部 IP アドレスがあることを確認してください。
このバグのため、1 つの手順でコントローラとアプリケーションの IP を相互に直接スワップできません。 これを実行する必要がある場合、最初に他の値を設定してから、目的の値に再度設定するができます。
API によりタグ付けされたネットワークをタグ付けされていないグリッドに追加しようとする場合、コールは「400 正しくない要求」を返さずに成功します。
設定されたダウンロード サーバがない場合（ローカル ダウンロード ディレクトリ）、「ダウンロード済み」としてバージョンを表示し、削除操作を許可しますが、削除は正しくは操作されません。 将来のリリースでは、このアクションが実行されない理由を示すエラーを生成します。
これは実際にはエラーではなく、単なる混乱させるメッセージです。
同じ範囲を複数回追加するには API を使用できますが、重複した範囲を削除するには UI を使用します。 （ただし、重複した範囲を配置されたままにしても問題は調査されません）。
3.7.0 がローカライズされていないため、アプリケーションの新しい部分は英語の文字列のみで表示されます。 以前にアプリケーションでローカライズされた部分（3.5 に存在したもの）は、以前と同様に英語以外の文字列が表示されます。
Dell ハードウェアの中には、DRAC Virtual Media BIOS オプションを有効にできるものがあります。 この機能により、ネットワーク上の仮想メディア デバイスから起動できるようになります。 ただし、CA AppLogic® カーネルは仮想メディア デバイスを SCSI デバイスとして識別し、ブート デバイス名を混同する可能性があります（「sda」だったものが「sdb」になる）。
この問題を回避するには、Dell ハードウェアの DRAC BIOS 内の DRAC Virtual Media オプションを無効にします。
BFC 内の MAC アドレスのリストに対してアドレスを追加または削除する場合は、最大で 500 までに制限してください。 検出モードでは、MAC リストを使用して、サーバを含めるか（［手動設定］に設定された場合）、またはサーバを除外（［自動検出］モードに設定された場合）します。
BFC の［検出］タブの［管理］ページで MAC のリストを操作できます。 サーバのリストを編集するか、またはサーバのリストを含むファイルをインポートできます。 また、BFC API を使用して、MAC アドレス リストを設定することもできます。
AppLogic Xen グリッド サーバは 3 TB のディスクをサポートしていますが、AppLogic ESX グリッド サーバは最大で 2 TB のディスクをサポートします。 ESX ハイパーバイザを実行するために 3 TB のディスクを持つサーバを選択しないでください。グリッド作成が失敗します。
CA AppLogic® 3.7 ベータ プログラムに参加していた場合は、アップグレードの失敗によりフォールバック手順を実行する必要がある場合、CA AppLogic® のベータ版が BFC ダウンロード ディレクトリに存在することを確認する必要があります。
|
Copyright © 2013 CA.
All rights reserved.
|
|