Eucalyptus のトラブルシューティング (1.5.2)
Eucalyptus が意図したとおりに動作しない場合、Eucalyptus クラウド管理者は、原因の調査を始める前に、既知のバグのページを参照し、問題がすでに特定されていないかどうか確認してください。
以下に示す手順の説明では、Eucalyptus チームが配布している euca2ools コマンドライン・ツールを使うことを前提としています。これらのツールをまだインストールしていない場合は、インストールしてください。
1. 再起動
Eucalyptus のコンポーネントは、起動スクリプトに '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 以外のリソース (ネットワーク、ハイパーバイザーなど) の扱いを根本的に変えるような eucalyptus.conf の修正を行った場合、現在実行中のすべての VM を終了しなければ修正内容を反映できないことがあります。また、 Eucalyptus を SYSTEM モード以外のネットワークモード (VNET_MODE) で実行している場合、VM のネットワーク接続が保証されるのは、その VM を起動したクラスタコントローラが実行されている間だけです。VM を起動したクラスタコントローラを引き受けているマシンがダウンしたり再起動したりした場合、VM のネットワーク接続は失われます。
上に述べた理由で実行中の VM を終了させる必要がある場合、管理者はクライアントツールを使ってすべてのインスタンスを終了させることができます。また管理者は、すべての Eucalyptus コンポーネントを手動で停止し、ノード上で 'xm shutdown' または 'xm destroy' を使って実行中のすべての Xen インスタンスを破棄し、さらにすべての Eucalyptus コンポーネントを起動することで、クリーンな状態に戻すことができます。
2. 診断
インストール/リソースの表示
インストールした 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' と 'cloud-debug.log' に記録されます。クライアントツール (EC2 API ツール) の出力に通常とは異なるメッセージが含まれている場合や、指示した操作が実行されている形跡がまったくない場合には (ノード上で Xen が一度も動作しない、フロントエンドのネットワーク構成が機能しないなど)、これららのログファイルを調べてください。
クラスタコントローラ (CC) もフロントエンド上にあり、ログは 'cc.log' と 'httpd-cc_error_log' に記録されます。一般的にはもちろんのこと、とりわけネットワークに関連する問題の発生が疑われる場合には、これらのログファイルを調べてください。'cc.log' にはクラスタコントローラ自身から出力されたログが記録され、'httpd-cc_error_log' には、クラスタコントローラが (クラスタコントローラの実行時に) 実行したすべての外部コマンドの標準エラー出力と標準出力が記録されます。
ノードコントローラ (NC) は、VM インスタンスを実行するよう管理者が構成したすべてのマシンで実行されます。ノードコントローラのログは 'nc.log' と 'httpd-nc_error_log' に記録されます。一般的にはもちろんのこと、とりわけ実際に実行中の VM に関連する問題の発生が疑われる場合は (たとえば、インスタンスが実行を開始し、'pending' 状態に入り、すぐに 'terminated' になってしまうなど、インスタンス自体は実行を試みているように見えるのに、実行状態を維持できないなど)、これらのログファイルを調べてください。
ノードコントローラに関するトラブルシューティング
- 'nc.log' に "Failed to connect to hypervisor" と出力されている場合は、xen/kvm と libvirt が正常に動作していません。
- ノードコントローラにコンタクトできない場合は、ノードとの間で鍵の同期化を行っていること、ノードコントローラを実行させているユーザー (eucalyptus.conf の EUCA_USER で設定) が鍵を所有していることを確認してください。
Walrus に関するトラブルシューティング
- "ec2-upload-bundle" は、すでに存在するバケットに対してアップロードを行った場合、"409" エラーを返します。これは、Eucalyptus で EC2 ツールを使った場合の互換性に関する既知の問題です。エラーを回避するには、"--clear" オプションを使って ec2-delete-bundle を実行してバンドルとバケットを削除してから、同名のバケットに対してアップロードを行うか、さもなければ別のバケット名を使ってアップロードを行います。
注: Euca2ools を使っている場合、このような作業は不要です。
- "ec2-upload-bundle" を使うときは、バケット名の最後に "/" が付いていないことを確認してください。
ブロックストレージに関するトラブルシューティング
- フロントエンドとノードコントローラを同じマシンで実行している場合にボリュームをアタッチできない。これは、ATA over Ethernet (AoE) に関する既知の問題です。AoE は、サーバーが実行されているマシンと同じマシンに対してエクスポートを行いません。この問題を回避するには、フロントエンドとノードコントローラをそれぞれ別のホストで実行します。
- ボリューム作成時に、"available" と表示される代わりに、"deleted" 状態になってしまう。$EUCALYPTUS/var/log/eucalyptus/cloud-error.log にエラーメッセージが出力されていないか調べてください。よくあるのは、ATA-over-Ethernet が、作成されたボリュームをエクスポートできないという問題です (この場合は cloud-error.log に "Could not export..." というメッセージが記録されています)。フロントエンドの eucalyptus.conf の "VNET_INTERFACE" の設定が正しいかどうか確認します。
- ボリューム/スナップショット作成の失敗。loopback デバイスの数が十分にあるかどうか確認してください。パッケージからインストールしている場合には、警告が表示されます。ほとんどのディストリビューションでは、loopback ドライバはモジュールとしてインストールされています。利用できる loopback デバイスの数を増やすには、次のようにします。
rmmod loop ; modprobe loop max_loop=256
- VM にブロックデバイスが自動的に現れない場合は、"udev" パッケージをインストールしているかどうか確認してください。
- Gentoo を実行していて、"which: no vblade in ((null))." というメッセージが表示される場合は、pam なしで "su" をコンパイルしてみてください。
「管理者ガイド」に戻る