Archive for June, 2012

OSX 移行記

June 30th, 2012 by naoya | No Comments | Filed in day

MacBook Air を購入してみたのですが、初めて前のマシンの TimeMachine から移行してみました。
移行直後、Dock というプロセス（ドックですね）が CPU 100% になり続けて、さっそく CPU を 100% 使う現象が発生しました。

Dock プロセスと何度か killall したり、com.apple.Dock.plist を削除してみたりとしてみたのですが、状況はいっこうに改善しませんでした。

調査してみると、Paralles や VMware Fusion を移行したときに発生するらしいことが分かりました。
情報源は、このあたりです。

OSX のバージョンは 10.7.4 で、VMware fusion 4 を使っています。

ということで、VMware Fusion 4 を、ここの公式情報に従いアンインストールしました。

VMware Fusion をアンインストールしたところ、Dock プロセスの CPU 使用率は通常に戻りました。原因がはっきりしていないのですが、別のマシンに OSX を移行するとき、VMware Fusion や Parallels を使っている人は要注意しましょう。
VMware Fusion を再度インストールしたところ、Dock プロセスの CPU 使用率があげることはありませんでした。

この他、基本的にすべてのデータを TimeMachine から移行することができたのですが、いくつか細かいところで移行できませんでした。

  • ホスト名（当然ですけれど・・・）
  • /etc/hosts（独自に定義している場合は気をつけましょう）
  • < システム設定（デスクトップのホットコーナー、スクリーンセイバー、一部のワークスペースの壁紙、言語設定 ATOK が無効になってた、Desktop の Hot Corners の設定、VPN のネットワーク設定）
  • Chrome の開いているタブ一覧（Firefox のタブ一覧はちゃんと復元されました）
  • Mail.app のデータ変換（なぜか、Mail.app の初回起動直後）
  • /private ディレクトリ以下の設定（Apache の httpd.conf など）

今のところこんなところですが、ほぼちゃんと移行できていて素晴らしいですね。

VMware Fusion ですが、再インストールして VM ファイルを起動したところ、vmware-tools がインストールされている Linux 系のゲストは起動できないので、vmware-tools を一度アンインストールする必要があるので注意しましょう。

あと、mds という spotlight のインデックスを作成するらしいプロセスも CPU 使用率 80% くらいしばらく使っている現象が発生していますが、しばらく時間がかかってしまいますが、これは仕方がないですねぇ。

そして、新しい Macbook Air、複数のゲストを同時に起動してもページングが発生しにくくなりました。とても、快適です☆

Tags:

KVM ではまったお話

June 18th, 2012 by naoya | No Comments | Filed in day

先日、Intel Xeon CPU L5410 x 2 の 1U サーバに、CentOS 5.8 x86_64 ベースで二つの KVM ゲストをインストールしようとしました。

当然ながら、Intel VT が有効になっていました。

# cat /proc/cpuinfo | grep vmx
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm syscall nx lm constant_tsc pni monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm
...

NIC は、いつものとおり br0 というブリッジデバイスを作成しました。
ゲスト OS は、koan でさくっとインストールしました。Virtio は、Network / Disk ともに組み込んでインストールしました。

まず、1つめのゲスト OS をインストールして、ネットワークに接続できることを確認して、1つめのゲスト OS を起動した状態で、2つめのゲスト OS をインストールしました。
2つめのゲスト OS をインストールしたところで、さて2つめのゲストを起動させようと思って、virsh list コマンドでチェックしてみると・・・

# virsh list
Id Name State
----------------------------------

なんと1つめのゲスト OS が起動していません。1つめのゲスト OS は起動させた状態のままだったはずなのに、なぜか起動していません。おかしいと思いながら、まず2つめのゲスト OS を起動した状態で、次に1つめのゲスト OS を起動すると起動してネットワーク接続のあたりで何も言わずに落ちてしまいます。

/var/log/messages をチェックしたところ、次のようなログが残っていました。

Jun 15 13:30:36 host kernel: br0: port 3(vnet1) entering disabled state
Jun 15 13:31:18 host kernel: device vnet0 entered promiscuous mode
Jun 15 13:31:18 host kernel: type=1700 audit(1339734678.391:16): dev=vnet0 prom=256 old_prom=0 auid=4294967295 ses=4294967295
Jun 15 13:31:18 host kernel: New device vnet0 does not support netpoll
Jun 15 13:31:18 host kernel: Disabling netpoll for br0
Jun 15 13:31:18 host kernel: br0: port 2(vnet0) entering learning state
Jun 15 13:31:33 host kernel: br0: port 2(vnet0) entering forwarding state

br0 は、eth0 のブリッジデバイスで、ゲスト OS 二つとも br0 を設定してインストールしました。
他の Xeon 5600 番台のサーバでは何の問題もなかったのに不思議です・・・原因を調べてみたのですが、さっぱり原因が分からず、KVM から Xen 3.4 系に切り替えたところ問題なく2つ同時にゲスト OS を起動させることができました。ちなみに Xen 4 系だと起動してしばらくするとネットワークに接続できなく現象が遭遇してしまったので Xen 3.4 系にしました…（これもはまりました・・・）。

原因がさっぱり分からず相当気持ち悪いのですが、Nehalem 以前の CPU は Xen を使うのが安定なのかもしれませんね。

Tags:

CentOS 5.x 系で IPv6 を無効にする方法

June 11th, 2012 by naoya | No Comments | Filed in day

CentOS 5.x 系で IPv6 を無効にする方法を調べていたのですが、バージョンごとに微妙に方法が違うようなのでまとめておきます。
公式情報は、CentOS 5 FAQ になります。

1. /etc/sysconfig/network で “NETWORKING_IPV6″ を “yes” から “no” に変更します
2. バージョンごとに設定方法が違います
（CentOS 5.4 以降の場合）
– /etc/modprobe.conf に alias ipv6 off と options ipv6 disable=1 を追加します
– /etc/modprobe.d/disable-ipv6.conf を作成して、”install ipv6 /bin/true” を追加します
（CentOS 5.3 以前の場合）
– /etc/modprobe.conf に alias ipv6 off と alias net-pf-10 off を追加します
3. IPv6 のファイアーウォールを無効にします
# /sbin/chkconfig ip6tables off
4. 最後に /etc/sysctl.conf に “net.ipv6.conf.all.disable_ipv6 = 1″ を追加します（これは推奨設定です、/proc/sys/net/ipv6 がない場合は設定しませんので、通常は設定しなくても問題ないでしょう）

あとは、network サービスを再起動するか、OS を再起動することで IPv6 が無効になります。

僕の場合、CentOS 5.3 以前から運用しているサーバがあり、アップグレードをしていたのですが、そのときに設定を変更するのを忘れていました。。。

Tags:

トラブル☆しゅーたーず＃02に参加してきた

June 3rd, 2012 by naoya | No Comments | Filed in day

トラブル☆しゅーたーず＃02　～あいつがまたやらかした～ on Zusaarに参加してきました。

とても勉強になりましたが、まずは課題の複数を環境があるうちに試してみましたので、手順を紹介します。

復習してみた自分なりのオペレーション手順

1. ローバランサーから EC1/2 をはずして、Sorry ページ（メンテナンス中）をすぐに表示する
=> メンテナンス中の旨とこれから対策を実施することをお客様に報告する

2. Nifty Cloud カスタム – プライベートから「EC1Backup」からサーバを作成する（バックアップの作成日時が「2012/06/02 11:13:19」であるのに対して、既存の EC1 の作成日時が「2012/06/02 09:01:43」であることからEC1Backupはちゃんとしたバックアップであることが分かる）、なお作成したサーバ名は EC3 としておく

3. EC3 を起動すると、そうすると Nginx が起動するという罠があるので Nginx を停止して Apache を起動する

EC3# /sbin/service nginx stop
EC3# /sbin/chkconfig nginx off
EC3# /sbin/service httpd start
EC3# /sbin/chkconfig httpd on

4. リニューアルサイト用のバックアップをとってから、/var/www へ展開する

EC3# cd /var/www
EC3# mv data1 data1-old
EC3# mv site site-old
EC3# cp /root/files/20120602renewal.tar.gz .
EC3# tar zxfv 20120602renewal.tar.gz

5. Apache の設定をすこし変更してから、Apache を再起動する

EC3# vi /etc/httpd/conf/httpd.conf
空の VirtualHost をコメントする
ecX.sotm.jp の VirtualHost に「ServerName test.sotm.jp」を追加する
EC3# /sbin/service httpd graceful

6. 自分の PC の /etc/hosts を書き換えて、test.sotm.jp にアクセスできるようにする

7. ブラウザから test.sotm.jp を閲覧して、サイトの内容がおかしいことを確認する

8. 原因はデータベースが古いことが原因なので、mysqlに接続する（データベースサーバは EC3 ではなく EC1 なので注意すること）

EC1$ mysql -u root -h localhost -p
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
+--------------------+

9. すべてのデータベースが閲覧することができない、原因は root ユーザの localhost に対するアクセス権限がないのが原因なので、127.0.0.1 で接続する

EC1$ mysql -u root -h 127.0.0.1 -p
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
...
（略）
...

10. 念のため、root ユーザの localhost に対するアクセス権限を復活させておく

mysql> GRANT ALL PRIVILEGES ON *.* To root@localhost;
mysql> flush privileges;

11. サイトの表示内容がおかしいのは、データベース名の設定がおかしいことが原因なので、設定を変更する

$ cd /var/www/data1
$ vi config/config.php
10c10
< define ('DB_NAME', 'ec_2012');
---
> define ('DB_NAME', 'eccube_new');

12. ブラウザでリロードして、正しく商品画像などが表示されることを確認する

13. 商品をかごに入れるとEC-Cubeからシステムエラーが発生することを確認する、原因は設定ファイルのURLが違っていることが原因なので修正する（DEBUG_MODE を有効にすると、便利かもしれない）

$ vi config/config.php
3,4c3,4
< define ('HTTP_URL', 'http://ecun.sotm.jp/');
< define ('HTTPS_URL', 'http://ecun.sotm.jp/');
---
> define ('HTTP_URL', 'http://test.sotm.jp/');
> define ('HTTPS_URL', 'http://test.sotm.jp/');

14. 正しくカートに追加できること、/admin以下にアクセスして管理者でログインできることを確認する

15. ロードバランサーに、EC3 のみを追加して、サービスを再開させる（その際に test.sotm.jp は本番の URL に書き直すことを忘れずに！）
=> お客様に不具合が解消されたこと、サービスを再開させたこと、負荷対策を実施する旨（あわせてコストがかかること）を事前に連絡する

16. 次に負荷対策に移行する、今回は EC Cube という PHP 製のプログラムのため、次のような構成をとるとよいと思われる、負荷対策までプログラムなどをチューニングしている時間はないのでサーバを増やすことで暫定対処する。

EC3# /sbin/service mysqld stop
EC3# /sbin/chkconfig mysqld off
EC3# /sbin/service iscsi stop
EC3# /sbin/chkconfig iscsi off
EC3# /sbin/service iscsid stop
EC3# /sbin/chkconfig iscsid off
EC3# /sbin/service yum-updatesd stop
EC3# /sbin/chkconfig yum-updatesd off
EC3# vi /etc/httpd/conf/httpd.conf

<IfModule prefork.c>
StartServers 40
MinSpareServers 40
MaxSpareServers 40
ServerLimit 40
MaxClients 40
MaxRequestsPerChild 4000
</IfModule>

17. EC3 をシャットダウンして、EC3 をイメージ化してオートスケールするように設定する（これには10〜20分くらい時間を要する）

18. EC1（Apache を落として、MySQ Lのみにして InnoDB まわりを軽くチューニングをする）

19. EC3 のコピーサーバ EC4 を作成して、ロードバランサーに追加して問題がないかどうかチェックする

20. EC3 を起動させて、オートスケールの設定を行う
=> 負荷対策が完了したことをお客様に報告する

その他、次の事項を提案する
- 今度、同じような問題が発生しないための提案をする
- 管理画面、カートなど個人情報を扱う部分のセキュリティを強化する（管理画面は ADMIN_FORCE_SSL を有効にすればよいと思われる）

今回のトラしゅを振り返ってみての反省は、次のとおりです。

  • チームの中で比較的作業ができる人たちでがんがん作業しまった結果、チーム全体として大きな成果を出すことができなかった
  • お客様にとっても「最大の問題点」をすぐに把握することができず、最初のメンテナンス画面を表示するのに、たしか二時間ほどかかってしまった
  • クラウドの場合、サーバを捨てることで対策が早くできる場合があるので、まずサーバを捨てることができるか検討すれば良かった
  • EC Cube というよく分からないプログラムの調査にかなりの時間がかかってしまった、この作業は僕が全部やってしまったけれど、みんなで分担してやれば良かった
  • 最終的な負荷対策まで、とても手が回らなかった、最初の不具合が治った時点で、負荷対策をどうするべきか検討に入るべきだった
  • お客様の立場になって、お客様と密接に情報の共有ができなかった（僕はひたすら治すことに集中してしまったし、時間がないなかで落ち着きがなくなってしまった、深呼吸本当に大事・・・）

というわけで、チーム５の皆さん、ありがとうございました！！！
また、会場や環境を提供してくださいましたニフティの皆さん、スタッフの皆さん（スタッフの皆さんは徹夜で作業されたようです・・・大変お疲れ様でした）、ありがとうございました！！！

第三回目も何らかの形で協力ができる機会があればいいなぁと思いました。次回参加する機会があれば、もっと積極的にチームでコミュニケーションをとるようにリーダーをやってみたいと思いました！

Tags: