orz記録

おうちとかいしゃのシステム技術のことを中心に書いていこうと思っています。

2014/02/03 15:43 hobbitという監視ツールを使っています

こんにちは。会社から更新。社会人失格。ま、技術の話題ですから。

 

会社のサーバ、hobbitという監視ツールを使用しています。今はXymonという名前になっています。

設定が比較的簡単で、豊富な情報が取得できるのが良い所です。

 

が、最近そのhobbitでちょっと不可解なアラートが出て困っていました。

プロセスの生死確認のための監視を行っているのですが、その仕組みは

監視対象のサーバ側でpsコマンドを発行した結果に、監視対象のプロセス名を検索してプロセスがあるかないかを確認しています。

 

最近監視対象のサーバのpsコマンドの結果が途中の行でぶった切られてしまって、

ぶった切られたpsコマンド結果からプロセス名を検索していたので、本当は立ち上がっているはずのプロセスが検索に引っかからずにプロセスが死亡している旨のアラートが発砲されることがたびたびありました。

 

色々と探していたら、下記のサイトにたどり着きました。

 

http://lists.xymon.com/oldarchive/2010/01/msg00128.html

http://ymkx.net/cat63/linuxnetwork/hobbit_got_oversize_message.html

 

どうやらhobbitはサーバから報告する、またはその報告を受取るデータのサイズに上限を設定するパラメータがあるようです。

 

hobbitサーバ(受け取り側)は、hobbitserver.cfgで

 

MAXLINE

MAXMSG_STATUS

MAXMSG_NOTES

MAXMSG_DATA

MAXMSG_CLIENT

MAXMSG_CLICHG

 

の値を適切に設定します。

適切な値はhobbitd.logでログを見ながら調節すれば良いと思います。

 

hobbitクライアント(送り側)は、hobbitclient.cfgで

 

MAXLINE

MAXMSG_CLIENT

 

の値を適切に設定します。

適切な値はhobbitclient.logを見ながら調節すれば良いと思います。

 

ログには、Oversize status msg from XX.XX.XX.XX for hostname:procs truncated ( n=1054871, limit 1048576 )

 

とか出てるので、limitが1048576の場合は、おそらく

MAXMSG_CLIENT=1024

となってると思われるので、2048などにしておくと良いとおもいます。

 

ではではー。

2014/01/21 14:56 VMware vSphere HAがうまく動かなかった理由を考えていた。

こんにちは。会社から更新。社会人失格。ま、技術的なことですから。

 

さて、久しぶりにvmwareのお話。

タイトルのとおり、HAがうまく動かなかったわけです。具体的には以下の様な感じ。

 

ESXiホストのコネクション切れをvCenterServerが検出した。

vCenterServerはvSphere HAを発動した。

HAに失敗したというイベントログが残っていた。詳細なメッセージは忘れちゃった(笑)。

 

障害が起こったESXiは、マネジメントIPにPingも通らなくなっていた状態だった。

おそらくHW障害か、カーネルのバグかなんかでハングったと思われる。

他のところに移動したVMは、そのまま立ち上がって来たものもあれば、

Cancel

I move it.

I copy it.

の選択肢が出てきて、そのままじゃ起動しなかった。

 

ESXiのHWを電源断→入したら、ESXiは何事もなく上がってきた。

 

障害の原因、それはそれで追求しなければいけないんだけれど、

ここでの問題はなんでHAに失敗したかってこと。

 

で、いろいろググッて調べてみた。主に見ていたサイトは以下2つ。

 

http://techhead.co/vmware-esx-i-moved-it-or-i-copied-it-whats-the-difference/

http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2034571

 

で、限られた状況証拠から想像したみた。想像かよ(笑)。

 

HAのハートビート通信が切れたので、障害ESXiは孤立した。

で、他のESXiでインベントリ登録して起動しようと思っていたけれど、その時にVM自体は何事もなく上がっている状態だったものは、

ファイルがロックされていてロックできなかったので、HAのエラーが出た。

 

その後にESXi自体が全体的にハングった。

このときに他のESXiに移動したものに関しては他のESXiによってファイルのロックが取得できたので

普通にHA機能が動いて起動に成功した。

 

なんかおかしい。辻褄合ってないな(笑)。

 

さて、ここでちょっとしたFYIを。

VMを移動した時に、出る3つの選択肢

Cancel

I move it.

I copy it.

は、.vmxファイル内のuuid.locationと起動時に自動的に作成されるものと比較して一致してなかった時に出てきます。

 

じゃ、停止状態でストレージを移行した場合、storage vMotionした場合はどうなるのかってことなのですが、

停止状態でストレージを移行した場合、.vmxファイルの内容からuuid.locationの行自体がバッサリ消えます!

storage vMotionした場合はやってないのでわかりません。

 

んな感じで。メモ代わりに書いただけですので。

2013/09/24 19:06 vmwareconverterでの移行失敗

お久しぶりです。会社から更新。社会人失格。ま、技術の話題ですから。

 

最近HPの物理サーバをVM環境に移行する作業をやってます。

なんか、前職からこんなことばっかりやってるような気がします。

ま、それはいいとして。

 

いつものようにVMwareConverterを使って移行作業をしていたわけですが、

進捗率が6%で失敗してしまった事例がありました。

 

VMwareConverterのログをExportして、vmware-converter-server-11.logを見てみたら、

以下のログが大量に吐かれていました。

 

bin/tar_1.20: ./spool/clientmqueue/qfr4V8R13S031453: Cannot open: No space left on device

 

移行対象サーバの/var/spool/clientmqueueディレクトリの下を見たら、ファイルが万単位で存在し、サイズが6.4GBもありました。

あぁ、きっとConverterがtarコマンド実行した時にディスクの容量足りなくなったのが原因かな、と思って

 

ls | xargs rm

 

を実行。xargs使うの久しぶりでした。綺麗サッパリファイルが消えたところで再度Converterを移行タスクをやり直し実行。

今度は進捗が6%超えて進むようになりました。このまま移行タスクが完了したらこれが原因と決めつけたいと思います(笑)。

 

ではまたー。

2013/07/22 16:44 【自動化】【VMware】cobblerでゲストOSインストール時にEPELリポジトリも登録しておく

会社から更新。社会人失格。ま、技術の話題ですから。

タイトルの件、ザックリ。自分向けの備忘録。
/var/lib/cobbler/snippets/epel_repo_install
という空ファイルを作成し、以下の内容を記述します。

wget http://ftp.riken.jp/Linux/fedora/epel/RPM-GPG-KEY-EPEL-6
rpm --import RPM-GPG-KEY-EPEL-6
wget http://dl.fedoraproject.org/pub/epel/6/i386/epel-release-6-8.noarch.rpm
rpm -i epel-release-6-8.noarch.rpm

上2行はGPGキーを取得してインポートする内容。
下2行はEPELのパッケージ本体を取得してインストールする内容です。

保存したら、
/var/lib/cobbler/kickstarts/XXXX.ks(XXXXは任意のKickstartファイル名)
ファイルを開いて、
%post
$SNIPPET('epel_repo_install')
という感じで記述。

これで完了。簡単でしょ>自分

ではでは。

2013/07/17 19:13 LDAPサーバを立てようとしてやっぱりハマっちゃった話

会社から更新。社会人失格。ま、技術の話題ですから。しかも定時後だし。

タイトルの通り、立ててみようとしました。

参考にしたのは本で、「プロのための Linuxシステム・ネットワーク管理技術」というやつです。URLはアマゾンです。
http://www.amazon.co.jp/dp/4774146757

ほいで、構築の最後にldapaddコマンドでLDIFファイルを登録します。
# ldapadd -x -D "cn=Manager,dc=example,dc=com" -W -f base.ldif
ldap_bind: Invalid credentials (49)

ちょっ
おまっ
ふざけっ
なんでっ
(以下略)

てなわけでやっぱりうまくいかないわけです。
けっきょく
rm -rf /etc/openldap/slap.d
でslap.dディレクトリをまるごと吹き飛ばしてしまって登録できました。
正しいかどうかはわかりませんが。ソースは以下のとおり。
http://hryksbt.b.sourceforge.jp/archives/394

蛇足ですが、以下のサイトの方も悩んでいらっしゃったようで。
http://dminor11th.blogspot.jp/2012/08/centos-6-openldap.html

なんか、最近自分がやってることは必ず先行者がいらっしゃるのでなんとか乗り越えてますが、なんだかなぁ。

思ったんですが、レコード登録がメンドいですね。なんか便利な方法あるのかなー。