EucalyptusTroubleshooting_v1.5.2 の変更点

追加された行はこの色です。
削除された行はこの色です。
EucalyptusTroubleshooting_v1.5.2 へ行く。
EucalyptusTroubleshooting_v1.5.2 の差分を削除
[[EucalyptusAdministratorGuide_v1.5.2]]

#contents
----
* Eucalyptus トラブルシューティング (1.5.2) [#lef00230]

Eucalyptus クラウドの管理者は、予想外の動作が怒ったときには、まず[[既知のバグ>EucalyptusKnownBugs_v1.5.2]]のページを確認するようにしてください。

以下の説明では、Eucalyptus チームが配布している [[euca2ools>Euca2oolsGuide]] というコマンドライン・ツールを用います。インストールがまだであれば、これから作業をしてください。

** 1. 再起動 [#j0916008]

Eucalyptus のコンポーネントは、init スクリプトを使って、いつでも 'restart'（再起動）することができます。
 /etc/init.d/eucalyptus-cloud restart
 /etc/init.d/eucalyptus-cc restart
 /etc/init.d/eucalyptus-nc restart
クラスタ・コントローラやノード・コントローラ上で、設定ファイル $EUCALYPTUS/etc/eucalyptus/eucalyptus.conf の変更を行った後は、設定を反映させるために、一時的にサービスを'stop'(停止)した後 'start'(起動)する必要があります。
 /etc/init.d/eucalyptus-cc stop
 /etc/init.d/eucalyptus-cc start
 /etc/init.d/eucalyptus-nc stop
 /etc/init.d/eucalyptus-nc start
'警告'：Eucalyptus の設定を eucalyptus.conf で大幅に変更する場合（ネットワーク、ハイパーバイザー等）は、設定を適用する前に、現在動作している仮想マシンすべてを停止させておく必要があります。更に、SYSTEM モード以外のネットワーク・モードで動作させている場合、現在の仮想マシンが動作しているネットワークの接続は、クラスタ・コントローラ（CC）が稼働している間だけですので、注意してください。
クラスタ・コントローラ（CC）として稼働しているマシンが故障するか、あるいは再起動してしまいますと、仮想マシンはネットワークの接続ができなくなります。

管理者は設定変更を反映させるため、稼働中の仮想マシン・インスタンスを停止する必要がある場合、クライアント・ツールを使って、すべてのインスタンスを終了することもできます。あるいは、管理者はすべての Eucalyptus コンポーネントを手動で停止させることもできます。Xen のノード上で稼働している、全インスタンスを停止するには、'xm shutdown' か 'xm desotoy' を実行します。設定を反映したクリーンな状態に復帰するには、手動で Eucalyptus コンポーネントを起動してください。

** 2. 診断 [#o731faac]

*** リソースの組み込みと発見 [#b4fe51ff]

なぜか Eucalyptus が正常に動作しない場合、確実な第一歩は（ドキュメントを読みながら、忠実にインストール・設定・ネットワークを行った後）、クラウドが確実に動作していることを確認することです。その際、すべてのコンポーネントがきちんと通信できるかどうかや、インスタンスを実行可能なリソースがあるかどうか、確認してください。Eucalyptus をセットアップして設定した後は、管理者による証明書の組み込みが正常に行われているかどうかは、クラウドで'status'コマンドを実行して確認できます。
 euca-describe-availability-zones verbose
そうすると、次のような結果が表示されるでしょう。
 AVAILABILITYZONE        cluster <hostname of your front-end>
 AVAILABILITYZONE        |- vm types     free / max   cpu   ram  disk
 AVAILABILITYZONE        |- m1.small     0128 / 0128   1    128    10
 AVAILABILITYZONE        |- c1.medium    0128 / 0128   1    256    10
 AVAILABILITYZONE        |- m1.large     0064 / 0064   2    512    10
 AVAILABILITYZONE        |- m1.xlarge    0064 / 0064   2   1024    20
 AVAILABILITYZONE        |- c1.xlarge    0032 / 0032   4   2048    20
 AVAILABILITYZONE        |- <node-hostname-a>        certs[cc=true,nc=true] @ Sun Jan 04 15:13:30 PST 2009
 AVAILABILITYZONE        |- <node-hostname-b>        certs[cc=true,nc=true] @ Sun Jan 04 15:13:30 PST 2009
 AVAILABILITYZONE        |- <node-hostname-c>        certs[cc=true,nc=true] @ Sun Jan 04 15:13:30 PST 2009
 AVAILABILITYZONE        |- <node-hostname-d>        certs[cc=true,nc=true] @ Sun Jan 04 15:13:30 PST 2009
 AVAILABILITYZONE        |- <node-hostname-e>        certs[cc=true,nc=true] @ Sun Jan 04 15:13:30 PST 2009
 AVAILABILITYZONE        |- <node-hostname-f>        certs[cc=true,nc=true] @ Sun Jan 04 15:13:30 PST 2009
 ...
次に管理者は、Eucalyptus のログファイルを参照しなくてはいけません。Eucalyptus コンポーネントを動作させている各々のマシン上で、ログは次の場所にあります。
 $EUCALYPTUS/var/log/eucalyptus/
フロント・エンド上のクラウド・コントローラ（CLC）のログは、主に 'cloud-output.log' と 'cluod-debug.log' に記録されます。クライアントツール（ec2 API ツール）が例外メッセージを表示するような場合や、何もしていないのに問題が発生していると思う場合（Xen がノード上で一切動作しない場合や、フロントエンドのネットワーク設定が通らないなど）も同様です。

クラスタ・コントローラ（CC）は、フロント・エンド上に存在しており、ログは 'cc.log' と 'httpd-cc_error_log' に記録されます。ほとんどの場合は、これらのログファイルを参照して問題解決を図ることができますが、ネットワークの問題が、とりわけ原因になることがあります。'cc.log' にはクラスタ・コントローラ自身のログを記録します。また、'httpd-cc_error_log' には、クラスタ・コントローラ実行時のランタイムが外部コマンドとして実行する際の、STDERR や STDOUT が記録されます。

ノード・コントローラ（NC）は、仮想マシン・インスタンスを実行するように設定されている、すべてのマシンで動作します。ネットワーク・コントローラ（NC）のログは、'nc.log' と 'httpd-nc_error_log' に記録されます。ほとんどの場合は、これらのログファイルを参照して問題解決を図ることができますが、仮想マシン・インスタンス事態の問題が、とりわけ原因になることがあります（例えば、インスタンスが稼働しようとしているように見えるのにかかわらず、実際には'pending'(保留)となっている状態です。このような場合は、直接インスタンスを停止させ、稼働できないようにします）。

*** ノード・コントローラのトラブルシューティング [#b9f31edb]

- nc.log に "Failed to connect to hypervisor"（ハイパーバイザーへの接続に失敗しました）と表示される場合は、Xen 又は kvm と libvirt が正常に機能していないことを示します。
- ノード・コントローラが応答しない場合、それぞれのノード・コントローラ上の設定で、同期鍵の所有者権限が設定通り（eucalyptus.conf の EUCA_USER で明示）かどうか確認してください。

*** Walrus のトラブルシューティング> [#q6885738]

- "ec2-upload-bundle"が「409」エラーを表示したときは、既にバケットがアップロード済みの状態を指します。これは既知のバグで、 Eucapyptus で EC2 ツールを使う際に発生します。回避するには、ec2-delete-bundle コマンドに "--clear" オプションをつけることです。そうすると、バケットをアップロードする前に、バンドル済みの同名のバケットを削除するようにできます。あるいは、違うバケット名を使ってください。
 メモ：[[euca2ools>Euca2oolsGuide]] を使っている場合、この作業は必要ありません。
- "ec2-upload-bunle" を使うとき、バケット名の最後に "/" を絶対つけないでください。

*** Block Storage のトラブルシューティング [#p124db80]

- フロント・エンドとネットワーク・コントローラが同一のマシン上で実行していますと、ボリュームを割り当てることができません。これは既知の ATA over Ethernet(AoE)に関するバグです。AoE は、サーバとして動作している同じマシンにはエクスポートすることができません。回避するには、フロント・エンドとノード・コントローラを別々のホストで実行してください。

- ボリューム作成時に "available"(利用可能) になっていても、結局は"deleted"(削除)してしまわなければいけない状況もあります。$EUCALYPTUS/var/log/eucalyptus/cloud-error.log のエラーメッセージを確認してください。ATA-over-Ehternet の既知の問題として、作成済みボリュームがエクスポートできないかもしれないという問題があります（"cloud not export..."というメッセージが、cloud-error.log に出力されます）。このような場合は、フロントエンドの eucalyptus.conf の "VNET_INTERFACE" が適切に設定されているか確認してください。

- ボリュームやスナップショットの作成に失敗する場合は、十分なループバック・デバイスを持っているかどうか確認してください。もし、パッケージからインストールしている場合であれば、警告として受け取ってください。多くのディストリビューションでは、ループバック・デバイスはモジュールとして組み込まれています。次の設定を行う事で、利用可能なループバック・デバイスの数を増やします。
 rmmod loop ; modprobe loop max_loop=256

- ブロックデバイスが仮想マシン上で自動的に追加されない場合は、"udev" パッケージがインストールされているかを確認します。
- Gentoo で動作させようとしている場合は、"which: no vblade in ((null) )　)." と表示されるでしょう。この場合は、"su" コマンドで pam を使用しないようにコンパイルしてください。


----

戻る：[[管理者ガイド (Administrator's Guide)>EucalyptusAdministratorGuide_v1.5.2]]

----
原文：http://open.eucalyptus.com/wiki/EucalyptusTroubleshooting_v1.5.2