|
|
|
このセクションでは、現時点での既知の問題と制限事項について説明します。
これは、アプライアンスが自分に接続されたアプライアンス（および自分自身のサーバとグリッド コントローラ）のみと通信できることを意味します。 ただし、アプリケーション設計の整合性と CA AppLogic の今後のバージョンとの互換性を保証するために、新しいアプライアンスのプロトコルを正しく指定する必要があります。
grid info コマンドによってレポートされた使用可能なディスク空き容量の合計はそのままの推量であり、ボリュームのミラーリングが考慮されていません。 本当に使用可能なディスク空き容量は、使用可能な空き容量をミラー数（デフォルトでは 2 つのミラー）で割った値です。 たとえば使用可能なディスク空き容量が 1000 GB あり、グリッドには 2 つのミラーリングが設定されている場合、使用可能なディスク空き容量は 500 GB になります。 また、ボリュームを正常にミラーリングするには、少なくとも X （ミラーの数）台のサーバに十分なディスク空き容量が必要です（いずれかのミラーを作成できない場合、CA AppLogic はボリュームの作成に失敗し、ボリュームをミラーリングできなかったことを示す警告を表示します）。
アプリケーションを開始し、いずれかのグリッド サーバに障害が発生した場合に、障害が発生したサーバで 1 つ以上のアプリケーションのアプライアンスが実行されるようにスケジュールされていると、そのアプリケーションの開始が失敗します。 この状況が発生した場合は、単にアプリケーションを再起動します。
さらに大きなファイルをボリュームにアップロードするには、vol manage シェル コマンドを使用します。ボリューム マネージャの内部からのリモート アクセスを有効にするには、必ずこのコマンドに外部 IP 設定を指定してください。 詳細については、vol manage コマンドのリファレンスを参照してください。
CA AppLogic では zfs ベースのブート ボリュームからの OpenSolaris アプライアンスのブートをサポートしています。 ただし、これは CA によって確認されておらず、動作しない場合があることに注意してください。 Solaris 10 では zfs をサポートしていません。
現在は、単一デバイスの zfs プールに制限されています。 CA AppLogic で zfs のすべての機能を十分に利用するには、独自のアプライアンスの内部に独自の zfs プールを作成することができます。 zfs プールをミラーリングに使用する場合、プールで使用される CA AppLogic ボリュームは、CA AppLogic のミラーリングを無効にして作成する必要があります（ボリューム作成時に mirrored=0 オプションを使用）。 また、CA AppLogic の Solaris ファイラを使用して作成された zfs プールは、Solaris 10 では動作しません。 CA AppLogic のすべての OS の制限については、「OS のサポート制限」を参照してください。
さらに大きなストレージを必要とする場合は、別のファイル システムを使用してください。
新しい dhcp 環境設定モードでは、アプライアンス設定用のプロパティ マークアップをサポートしていません。 volfix から dhcp 環境設定モードにアプライアンスを移植する場合に、アプライアンス設定用のプロパティ マークアップに依存するアプライアンスを処理する方法については APK のドキュメントで説明しています。 詳細については、アプライアンス キット（APK）を参照してください。
アプリケーションの検証フラグを表示するには、編集モードでアプリケーションを開きます。 検証フラグは、一部の必須のプロパティ/端子/ボリュームが適切に設定されていないアプライアンスにフラグを付けるために使用されます。
インストール プロセスでグラフィカル コンソールを使用して Solaris 10 アプライアンスをインストールするには、iso2class を使用できます。 ただし、インストールが完了しアプライアンスが再起動された後にも、グラフィカル コンソールをそのまま使用できますが、テキスト モードで使用する必要があります（Solaris 10 のデスクトップにはアクセスできません。厳密なテキストベースのアクセスです）。 これは、Solaris 10 の GUI に問題があるためです（CA AppLogic のバグではありません）。
そのため、グラフィカル コンソールをこれらのアプライアンスと一緒に使用できません。 これは、アプライアンスをできるだけコンパクトにするために、意図的に行われています。 新しい iso2class ユーティリティを使用すると、ユーザはデスクトップを完全にサポートする独自のアプライアンスを作成できます。
このエラーは、CA AppLogic がアプライアンスのコンピュータ名をインスタンス名に設定するために発生します。 そのため、グリッドにすべてが同じインスタンス名を持つ複数のアプライアンスがある場合、Windows のグラフィカル コンソールに名前の重複エラーが表示されます。 このエラーは単に警告であるため、グリッドまたはその操作には影響しません。 ただし、Windows をドメイン コントローラとして使用する必要がある場合は、各アプライアンスでコンピュータ名に一意の名前を設定する必要があります。 アプライアンスのコンピュータ名を設定するには、wincfg ユーティリティを使用できます。
IE/FF/Chrome/Safari では、Java Version 6 Update 7 のテストを実行しました。 最新バージョンの Java が使用されていないと、グラフィカル コンソールが正常に動作しない場合があります（ロードされる際にハングアップします）。 グラフィカル コンソール エラーが発生した場合は、CA にレポートする前に、必ず最新バージョンの Java が使用されていることを確認してください（ブラウザで Java をアップグレードする必要がある場合は、グラフィカル コンソールが正常に動作できるように、アップグレード後に必ずブラウザをいったん閉じて再度開いてください）。
セカンダリ サーバが新しいプライマリ サーバの役割を引き受けたときに、グリッド コントローラを開始するための十分な利用可能リソースがサーバ上にない場合、CA AppLogic は新しいプライマリ サーバ上で実行されているアプライアンスをグリッド内の他のサーバ上で再起動し、新しいプライマリ サーバ上でグリッド コントローラを開始できるようにします。 これによってアプライアンスのフェールオーバ グループが分割される場合があることに注意します。 CA AppLogic がこれらのアプライアンスのいずれかを停止すると、フェールオーバ グループに対応するための十分なリソースがなくなり、別のサーバ上でアプライアンスを再起動できなくなることがあります。
すべての HVM ベースのアプライアンス（Solaris 10、Windows など）は、使用できるように設定された量よりも多くのメモリをサーバで使用します。 通常、HVM ベースのアプライアンスに割り当てられたメモリの量によって、アプライアンスは実行しているサーバの増設メモリを使用します（この増設メモリはサーバで実行している仮想化ハイパーバイザが必要としており、シャドウ メモリと呼ばれます）。 そのため、HVM ベースのアプライアンスがサーバでは使用できない追加のシャドウ メモリを必要とするために、アプライアンス用に割り当てられた量と比べてサーバには使用可能なメモリが十分にあるとしても、アプライアンスをそのサーバで実行できない可能性があります。 CA AppLogic のスケジューラは、アプリケーションの開始中にアプライアンスをスケジュールするときに、この追加のシャドウ メモリを考慮します。
10G のバックボーンを使用している場合、さまざまなサーバで実行しているアプライアンス間で達成可能な最大スループットは約 2 Gbps です（CA AppLogic が使用するハイパーバイザのなんらかの制限によるものと考えられます）。
代わりに他のブラウザを使用できます。
共有インターフェースは、他のすべてのオペレーティング システムで動作します。
このリリースの既知の問題は以下のとおりです。
ライトキャッシュが有効でない HP Smart アレイ RAID コントローラを使用すると、パフォーマンスが 50% 低下します。 この問題は、HP DL 580 G7 サーバで Smart アレイ P410i 256mb を使用して確認されています。 これらのカードでは、ライトキャッシュを有効にするためにバッテリまたはキャパシタが搭載されている必要があります。
Emulex OneConnect 10Gb NIC （be3） （rev 01）を CA AppLogic と共に使用する際に、SR-IOV BIOS オプションが有効であると、これらの NIC で不適切なバウンスが発生します。 これらバウンスが発生したパケットがブリッジの転送キャッシュを変更し、そのためにブリッジはパケットを正しい宛先に転送せずにドロップします。 これにより、CA AppLogic が不安定になり、アプリケーションの起動エラーが断続的に発生します。 したがって、グリッド内のすべてのサーバ上のすべての Emulex 10G NIC で、SR-IOV BIOS の設定が DISABLED になっている必要があります。
10G バックボーンを使用した際、異なるサーバ上で実行されるアプライアンス間でのスループットは最大で約 2.5 Gbps です（使用している 10G ハードウェアのタイプによって結果は異なる場合があります）。 CA では現在、10G ネットワーク パフォーマンスを向上させるために、今後の CA AppLogic リリースで利用できるような複数のネットワーク最適化方法（ジャンボ フレームを有効化など）について調査中です。
非常にまれですが、いずれかのサーバでスタック ボリュームがマウントされているために、アプリケーションの開始が失敗します。 CA AppLogic はスタック ボリュームのマウントを検出し、それをグリッドのダッシュボードのユーザにレポートします。 お客様のグリッドでこの問題が発生した場合は、CA Supportにご連絡ください。 任意で、サーバを無効にするか、スタックをマウントしているサーバを再起動すると、この問題が解決されます。
この状況が発生した場合、プライマリ サーバを再起動すると、グリッドが稼働状態に戻ります。
VDS： セキュリティの脆弱性： 初期ユーザ/パスワードのセットアップ
Microsoft Internet Explorer 6 または 7 を使用して CA AppLogic の GUI にアクセスすると、編集のためにアプリケーションを開いた場合または Web シェルを開いた場合に GUI にメモリ リークが発生します（これらの各操作で 5 ～ 20 MB のシステム メモリがリークします）。 リークされたメモリを回復させるには、数時間おきにブラウザを閉じて再度開くことをお勧めします。 Internet Explorer の代わりに Firefox、Chrome、または Safari を使用することもできます。
今後、グリッド コントローラに高い負荷がかかっている場合に、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 Supportに連絡して、グリッドのグリッド フラッピング状態をリセットしてもらいます。
リソースがわずかに少なくなっている理由は、サービス領域の割り当てに関連します。 メモリについては、Xen の仮想マシンのメモリ マップ テーブルに関連するものと考えられます。 ディスクについては、通常のファイル システム サービス領域によるものです（これは標準的な Linux サーバと同じです）。
この場合、他のユーザが編集するためにアプリケーションを開いていないのに、CA AppLogic エディタが、他のユーザが編集のためにアプリケーションを開いていると誤って認識しています。 このような状態が発生した場合は、アプリケーションを開いていることに関してエディタがメッセージを表示しても、単にアプリケーションのロックを無視します。
CA AppLogic アプリケーション エディタでアプリケーションを開くと、大きな遅延が発生します。
クライアントがグラフィカル コンソールを開いており、そのインターネット接続が失われた場合（クライアントのネットワーク カード エラー、クライアント コンピュータのクラッシュ、インターネットにアクセスできない、など）、グラフィカル コンソールを再度開くには 15 分かかります。
CA AppLogic のグラフィカル コンソールを使用している場合、Ubuntu でマウスを簡単に使用できません。 これは Xen の VNC サポートの制限によるものです（マウスのアクセラレーションがサポートされていません）。 一部のユーザから Ubuntu でマウスの設定を調節すると問題が解決されるとレポートされています。 また、キーボードからテキストを入力するときに、まれにキー入力が複数回繰り返されることがあります（このような場合は、単に表示された余分な文字を削除します）。
これには、アプライアンスにログインする場合のパスワードも含まれます。 テキスト ブート コンソールは、デバッグ目的のみに使用する必要があります。 代わりに、SSH コンソールは他のすべての目的に使用できます。
テキスト ブート コンソールをすでに開いた後に、ユーザがアプライアンス用のテキスト ブート コンソールを再度開いた場合、ログイン プロンプトまたはコマンド プロンプトのいずれかを表示するには、Enter キーを押す必要があります。 これは、ブート コンソールがユーザ入力（ログイン情報または実行するコマンドのいずれか）を待機しているためです。
グリッドにセカンダリ サーバで実行しているフェールオーバ グループに含まれるアプライアンスがあり、そのセカンダリ サーバーでグリッド コントローラを再起動する必要がある場合、CA AppLogic がそのアプライアンスを停止したためにフェールオーバ グループが分割される場合があります。
グリッドを最新のリリースにアップグレードすると、ハードウェアの問題のためにグリッドに障害が発生したことを示すダッシュボード メッセージが表示されます。 このメッセージを無視しても問題はありません。また、このメッセージをダッシュボードから削除できます。
APK（Appliance Kit）は Ubuntu 9.10 または 10.x で動作しません。これは、新しい OS といくつかの点で互換性がないためです。 ただし、CA AppLogic フォーラムには、CA AppLogic で最近のいくつかの OS ディストリビューションを使用する方法を説明したさまざまな投稿があります。
CA AppLogic でネットワーク HA 設定を使用し、外部ネットワークに障害が発生した場合、外部インターフェースを使用するアプリケーション/アプライアンスが最大 5 分間アクセスできなくなる場合があります。 これは、MAC アドレスをキャッシュする外部ルータが原因だと考えられます。 ルータが ARP のキャッシュをフラッシュするまで待機するか、またはアプリケーションから arp を実行して ARP 応答を送信することにより、正常な状態に戻ります。 これは、外部ネットワークにのみ影響します（バックボーン ネットワークには影響しません）。
Solaris 10 は、CA AppLogic 3.ｘ の Xen および ESX Server の両方で動作しません。
OpenSolaris は XEN ベースのサーバ上でのみ動作します。
復旧 GUI は XEN ベースのサーバ上でのみ動作します。
共有インターフェースはアプライアンス カウンタをサポートしていません。
ユーザがグリッドの電源を入れ直した場合、システム稼働時間はリセットされません。 グリッドが再起動された場合は、システム稼働時間がリセットされます。
grid power_cycle コマンドを使用してグリッドの電源を入れ直した場合、プライマリ サーバが再起動しない場合があります。 これは、新しいグリッドのインストール後にコマンドが実行され、power cycle コマンドを実行する前にグリッドが再起動されたことがない場合に発生します。 新しいグリッドのインストール後にグリッドをいったん再起動しておくことで、この問題を回避できます。
グリッドの実行中に NFS 共有のサイズが変更された場合、そのグリッドが再起動されるまで、CA AppLogic はこれを検出しません。 この問題は将来のリリースで解決されます。
SAN を使用していたグリッドが破棄された場合、CA AppLogic は SAN 上のそのグリッドのフォルダの内容を削除しますが、空のフォルダが残されます。 この問題は将来のリリースで解決されます。
CA AppLogic では、H200 RAID カードを使用している Dell ベースのサーバを使用できません。 この問題は将来のリリースで解決されます。
この問題を回避するには、グリッド作成に使用する前に、Dell サーバ上でハードウェア RAID を有効化します。
iso2class では、RedHat 5.3 ベースのアプライアンスをインストールできません。 この問題は将来のリリースで解決されます。
非常にまれに、3.0 または 3.1 から 3.5 へのアップグレードが失敗することがあります。 アップグレードのこの特定の失敗では、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.5 では解決されています。
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 コマンドを実行すると、メモリ不足のエラー メッセージが返されます。
この問題を回避するには、グリッド コントローラを再起動します。 この問題は将来のリリースで解決されます。
Broadcom 社製の特定の NIC、特に NetXterme II BCM5709/5716 では、ドライバでのリンク速度が 100Mb/s または 10Mb/s と報告されています。 そのため、CA AppLogic のインストールが失敗します。
この問題を回避するには、再インストールを試行します。 この問題は将来のリリースで解決されます。
グリッド コントローラにインストールされた OpenSSH バージョンでは、多重化同時 SSH セッション数が 10 に制限されます。 その結果、10 を超える非同期リクエストを実行すると、API によってドロップされます。
この問題を回避するには、API に発行する同期非同期リクエストが 10 よりも少なくなるようにします。 この問題は将来のリリースで修正されます。
アセンブリまたはコンポーネントのインターフェース名を変更すると、アプリケーション エディタはロードを完了することができなくなります。 この問題は将来のリリースで修正されます。
これらの NIC を使用しているサーバ上でグリッドを作成すると、「srv info srvX –extended」の出力として、NIC の状態が「アクティブ-ダウン」として表示されます。 これはハードウェアに固有の問題です。 この問題を回避するには、それぞれのスイッチにログインし、srvX の NIC のポートを閉じ、再度有効にします。 状態が「稼働」として表示されます。 この問題は将来のリリースで解決されます。
BFC は、NIC として Broadcom NetXtreme II 57711 （bnx2x） 10Gbe を使用した Dell PE R710 サーバを検出できず、インストールが失敗します。 これはハードウェアに固有の問題で、将来のリリースで解決されます。
このリリースでの Windows アプライアンスに関する主要な既知の問題を以下に示します。 また、追加の手順および注意事項については、「Windows アプライアンス インストール」を参照してください。
CA AppLogic 3.5 に付属する新しい Windows APK を使用している場合、Windows 2003 Server Datacenter Edition （64 ビット）が Xen ベースのグリッド上で使用されると、開始に断続的に失敗することがあります。 この問題が発生した場合は、アプライアンスを再起動すると問題が回避されることがあります。 この問題は将来のリリースで解決されます。
ソース ボリュームに破損しているディレクトリ エントリ/ファイルが含まれている場合、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 リリース 2.4 ～ 3.x で発生しましたが、仮にあったとしても再現するのが非常に困難であり、1 度か 2 度しか発生していません。 これらのいずれかの問題がお客様のグリッドで発生した場合は、どの問題が発生したのか、およびエラーが発生したときに CA AppLogic のどのコマンドを実行したのかを説明するバグ レポートを CA にお送りください。
サーバの dom0 で Linux カーネルがクラッシュしたために、グリッド内のサーバが自力で再起動しました。 前の CA AppLogic リリースのように、これによってグリッド全体に障害が発生したわけではありませんが、アプリケーションのダウンタイムを引き起こす可能性があります。 このような場合、CA AppLogic は障害の発生したサーバで実行したアプライアンスをグリッド内の他のサーバで再起動します。 この問題がお客様のグリッドで発生した場合は、CA Supportにご連絡ください。
CA AppLogic 2.4 では、サーバがグリッド コントローラへの接続を失い再起動するケースがいくつかありました。 これによって、あるサーバで実行していたすべてのアプライアンスが、グリッド内の他のサーバで再スケジュールされます。またアプリケーションのダウンタイムを引き起こす可能性もあります。 サーバがグリッド コントローラへの接続を失った理由は不明です。 CA AppLogic 2.7 ～ 3.ｘ では、サーバのグリッド コントローラへの接続が失われた場合、サーバはグリッド コントローラへの再接続を試みます。成功した場合はサーバはそのまま操作可能になり、アプリケーションのダウンタイムは発生しません。 1 分間のうちにサーバがグリッド コントローラに再接続できない場合、サーバは再起動され、アプリケーションのダウンタイムが発生します。 サーバがグリッド コントローラへの接続を失った場合、メッセージがダッシュボードのログに記録されます。 この問題が発生した場合は、すぐに CA Supportにご連絡ください。
CA AppLogic 2.7/2.8 で、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 キーを押してインストールを続行します。
CA AppLogic 3.5 では、Broadcom Corporation の NetXtreme II NIC が遅すぎると誤って報告されます。 このエラーが発生する場合は、サーバの再検出を実行してみてください。
シャットダウンの前に BFC が容量不足になった場合、シャットダウンを正常に行うために必要な容量を開放し、BFC を再起動する必要があります。
このバージョンの製品で自動インストールを行う場合、ユーザのパスワードに "=" を含めることはできません。
AppLogic 3.1 の BFC で VLAN 0 を使用していた場合、その VLAN ID を引き続き使用できますが、3.5 の UI でその VLAN ID を指定することはできません。
このバグでは、ブロックすべきサーバがグリッドに含まれてしまう場合があります。 ポートを適切に設定すれば、この問題は発生しません。
256 文字を超える文字を使用する場合は、パラメータを複数のグリッドに分割します。
ベア メタル インストールを使用して、NFS マウント ファイル システム上にレプリカを定義しようとしている場合、ディレクトリが bfcadmin によって所有されていないと問題が発生します。 簡単な方法は、UI を介してインストールした後でレプリカを追加することです。 別の方法としては、以下の手順に従います。
groupadd -g 64869 bfc useradd –u 64870 -g 64869 bfcadmin
chown bfcadmin /mnt/replica chgrp bfc /mnt/replica
（/mnt/replica は、レプリカ ディレクトリへのパス）
サーバによっては、システムが報告する CPU 数が、ハイパー スレッディングを有効にした場合と無効にした場合とで同じ場合があります。 これは Dell R610 シリーズの機種で確認されています。
これは、aldo set に渡される設定ファイルへのパラメータの書き込み方法に関連した問題です。 UI を使用して、エントリ間をカンマで区切ったデータを入力すると、同じ問題が発生します。 BFC API でこの問題を回避するには、エントリ間を改行で区切った単一の文字列を渡します。
例：
\"additional_config\":[\"ext_dns1=155.35.34.108\next_dns2=141.202.1.108\"]
以下の代わりに指定します。
\"additional_config\":[\"ext_dns1=155.35.34.108\",\"ext_dns2=141.202.1.108\"]
この問題は、外部スイッチでスパニング ツリー プロトコル（STP）が有効で、外部サーバ インターフェースに接続されているスイッチ ポートのタグなし VLAN と、BFC サーバの外部インターフェースに接続されているスイッチ ポートのタグなし VLAN が異なる場合に発生します。 外部サーバ インターフェースの stp_port 設定は、［不明］に設定され、サーバが隔離されます。 回避策としては、外部スイッチで STP を完全に無効化するか、または、外部サーバ インターフェースに接続されているスイッチ ポートのタグなし VLAN が BFC サーバの外部インターフェースに接続されているスイッチ ポートのタグなし VLAN と同じ VLAN になるように設定します。 次に、サーバを隔離解除して検出プロセスを再開します。
この問題は、削除したサブネット内のアプリケーション IP アドレスを含むグリッドがあっても、3.1 では、正しくエラーとして処理されないために発生します。 アップグレード プロセスは、失われているサブネットをアップグレード時に検索しますが、削除されているために失敗します。 回避策としては、アップグレードが失敗し、以前の 3.1 BFC インストールに戻す手順を使用します。 次に、各グリッドにアクセスし、現在設定可能なサブネットに属していないすべてのアプリケーション IP アドレス範囲をグリッドから削除します。 同じサブネットを新規 CIDR プレフィックス長パラメータと共に後から再度追加するような場合、その範囲が現在のサブネット範囲に収まっていても、基盤となるサブネット コンポーネントは不正となり、アップグレード中にエラーを発生させます。 BFC のサブネットと、グリッド コントローラ UI のアプリケーション IP アドレス範囲のパラメータとが必ず一致するようにする必要があります。
isotool -o パラメータで、マシン（CentOS 5.5 ボックス）に取り付けられた USB デバイスが正しく表示されません。 これは CentOS 5.5 での既知の問題です。 この問題を解決するには、root ユーザとして以下のシェル コマンドを発行する必要があります。
service haldaemon restart
| Copyright © 2012 CA. All rights reserved. |
|