より良い環境を求めて このページをアンテナに追加 RSSフィード

2013-02-26

[][][] 無停止でサーバーデータセンターに引っ越し: OpenVPN, Ganeti, Xen, LVM, DRBD

社内に置いてあるサーバーOSごとデータセンターに移したのでその作業ログ。

はじめに。

  • 長いです
  • タイトルは大げさです
    • テストではうまくいったけど実際の社内サーバーではカーネルパニックが発生、再起動の時間分だけ停止
      • ライブマイグレーションがうまくいくかどうかは環境要因が色々ありすぎる
      • 2013-03-03 00:53 追記 原因の範囲はだいたい分かってきたが、やっぱり環境に依存するので要テスト
    • ネットワークの設定を切り替えるときに瞬停する
      • ipコマンドで設定すると瞬停しないが、/etc/network/interfaces に書いて ifdown, ifup やりたい
      • 再起動後の初期設定もチェックしたいのでやっぱり再起動して確認した方が良い
  • 同じような環境の参考情報が見つからなかったのでこれが妥当なやり方がは判別できていない
    • 普通はこうするよ、というのがあれば是非

  • 前提条件
    • Debian squeeze
    • Ganeti (Xen, DRBD, LVM)
    • 引っ越し前環境
    • 引っ越し後環境
      • 直HUB
      • 余っているサーバーが3台
        • 最低2台でもいけそうだが設定で混乱しそう
      • リモートからのコンソール表示
        • ないとネットワーク設定でミスったときに死ぬ
        • 一発成功はまずありえない

調べつつハマりつつやったので、まぁ知らなくても大丈夫。

Ganetiを使っているのでXenやLVM、DRBDを直接は触っていない。Ganetiを使っていない場合でも手動でLVMやDRBDを設定すればいけるはず。


IP環境など

  • NAT変換後のローカルのIPは 192.168.10.0/24
  • DRBD専用ネットワークは 192.168.9.0/24
  • 移動先のグローバルIPは10.1.1.0/24
    • 10.1.1.2 などをグローバルIPとして、HUBで直繋ぎだという想定で
    • OpenVPNのexampleにあるサンプル設定が10.x.x.xとなっているが、ここでは無関係。OpenVPN専用のIPは使わない。

VPN構築

x.x.x.2 と x.x.x.3 のIPを使う。

eth0 と eth1(つまり全てのNIC) をブリッジする。


ネットワーク設定

サーバー側の /etc/network/interfaces を変更。

auto br0
iface br0 inet static
        address 10.1.1.2
        netmask 255.255.255.255
        network 10.1.1.0
        broadcast 10.1.1.255
        gateway 10.1.1.1
        bridge_ports eth0 tap0
        pre-up openvpn --mktun --dev tap0
        post-down openvpn --rmtun --dev tap0

auto br0:0
iface br0:0 inet static
        address 192.168.10.2
        netmask 255.255.255.0
        network 192.168.10.0
        broadcast 192.168.10.255

auto br1
iface br1 inet static
        address 192.168.9.2
        netmask 255.255.255.0
        network 192.168.9.0
        broadcast 192.168.9.255
        bridge_ports eth1 tap1
        pre-up openvpn --mktun --dev tap1
        post-down openvpn --rmtun --dev tap1

VPNのためにeth0などを消してブリッジを作る。

NICが二枚しかないところに三つのネットワークを作るのでIPエイリアスで。

一つのHUBにネットワークが混在する環境になる。NICやHUBがあるのなら分けた方が良い。


続いてクライアント側。

auto br0
iface br0 inet static
        address 192.168.10.3
        netmask 255.255.255.0
        network 192.168.10.0
        broadcast 192.168.10.255
        gateway 192.168.10.1
        bridge_ports eth0 tap0
        pre-up openvpn --mktun --dev tap0
        post-down openvpn --rmtun --dev tap0

auto br1
iface br1 inet static
        address 192.168.9.3
        netmask 255.255.255.0
        network 192.168.9.0
        broadcast 192.168.9.255
        bridge_ports eth1 tap1
        pre-up openvpn --mktun --dev tap1
        post-down openvpn --rmtun --dev tap1


OpenVPNサーバーインストール・設定
aptitude install openvpn

cd
mkdir openvpn
cd openvpn
cp -a /usr/share/doc/openvpn/examples/easy-rsa/ .
cd easy-rsa/2.0
vi vars
# KEY_COUNTRYなどを変更する、自分用なのでそのままいく

. ./vars
./clean-all
./build-ca
# すべてデフォルトで
./build-key-server vpn.example.com
# すべてデフォルトで
./build-dh

cp keys/ca.crt /etc/openvpn/
cp keys/vpn.example.com.crt /etc/openvpn/
cp keys/vpn.example.com.key /etc/openvpn/
cp keys/dh1024.pem /etc/openvpn/

cd /etc/openvpn/
cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz .
gunzip server.conf.gz 
vi server.conf
port 1194
proto tcp
dev tap0
ca ca.crt
cert vpn.example.com.crt
key vpn.example.com.key
dh dh1024.pem
server-bridge
keepalive 10 120
comp-lzo
persist-key
persist-tun
status openvpn-status2.log
verb 3
cp server.conf  server2.conf
vi server2.conf
  • port 1195
  • dev tap1

NICが二枚あるので、設定ファイルも二つ。ポートを分ける必要がある。

変なトラブルにハマるのも嫌なのでudpではなくtcpで。



OpenVPN クライアントインストール・設定
aptitude install openvpn
cd /etc/openvpn/
cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf .
cp -a /usr/share/doc/openvpn/examples/easy-rsa/ .
cd easy-rsa/2.0

. ./vars 
./clean-all 
./build-req vpnc.example.com

echo "10.1.1.2 vpn.example.com" >> /etc/hosts
scp keys/vpnc.example.com.csr vpn.example.com:~/openvpn/easy-rsa/2.0/keys/

easy-rsa を置く場所がサーバーと違うが、そこは適当に。


VPNサーバー側で署名
cd ~/openvpn/easy-rsa/2.0
./sign-req vpnc.example.com
クライアント側で署名済み証明書設定
scp vpn.example.com:~/openvpn/easy-rsa/2.0/keys/ca.crt keys/
scp vpn.example.com:~/openvpn/easy-rsa/2.0/keys/vpnc.example.com.crt keys/
cp keys/ca.crt /etc/openvpn/
cp keys/vpnc.example.com.crt /etc/openvpn/
cp keys/vpnc.example.com.key /etc/openvpn/

cd /etc/openvpn/
cp client.conf client.conf.org
vi client.conf

client.conf

client
dev tap0
proto tcp
remote vpn.example.com 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert vpnc.example.com.crt
key vpnc.example.com.key
ns-cert-type server
comp-lzo
verb 3

client2.conf も dev tap1 と port 1195 作る。


chmod og-r vpnc.example.com.key 

echo "192.168.10.3 vpnc.example.com" >> /etc/hosts
echo "10.1.1.2 vpn.example.com" >> /etc/hosts

動作確認

サーバー側、クライアント側で openvpn stop start する。

サーバーからクライアントクライアントからサーバーでローカルIPping確認。また、ネットワーク上の他のマシンからも確認。


/proc/sys/net/ipv4/ip_forward を 1 にし、ついでにブロードキャストも応答するようにすると分かりやすい。

# cat /etc/sysctl.d/ipforward.conf
net.ipv4.ip_forward = 1
#
# cat /etc/sysctl.d/broadcast.conf
net.ipv4.icmp_echo_ignore_broadcasts = 0
#
# sysctl -p /etc/sysctl.d/ipforward.conf
net.ipv4.ip_forward = 1
#
# sysctl -p /etc/sysctl.d/broadcast.conf
net.ipv4.icmp_echo_ignore_broadcasts = 0
#
# ping -b 192.168.10.255
...

ネットワークのマシンは全部ブロードキャストに答えるようにしている。

そうするとVPNを通じて双方から大量の応答が返ってくるようになる。


データセンター側にGanetiノード追加


Ganetiのインストールは割愛。本家のマニュアルを上から順にやっていくのが一番失敗がない。自分の環境では一度設定した流れをシェルスクリプトに書いていて、そのまま実行したり所々変えながら実行したりしている。xengrubの共通設定、Debianの共通設定はひな形からコピー。


ネットワーク設定
auto xen-br0
iface xen-br0 inet static
        address 10.1.1.4
        netmask 255.255.255.0
        network 10.1.1.0
        broadcast 10.1.1.255
        gateway 10.1.1.1
        bridge_ports eth0
        bridge_stp off
        bridge_fd 0

auto xen-br0:0
iface xen-br0:0 inet static
        address 192.168.10.4
        netmask 255.255.255.0
        network 192.168.10.0
        broadcast 192.168.10.255

auto eth1
iface eth1 inet static
        address 192.168.9.4
        netmask 255.255.255.0
        network 192.168.9.0
        broadcast 192.168.9.255
#       mtu 9000

Xenの普通の設定。eth1はDRBD用。普段はmtuを上げているが、今回はトンネルするので通常のままで。


こんな感じで datacenter1.example.com x.x.x.4 と datacenter2.example.com x.x.x.5 を追加する。

Ganetiマスターノードでの設定
vi /etc/hosts
# datacenter1.example.com、datacenter2.example.com を追加
gnt-cluster command ifconfig eth1 mtu 1500
gnt-cluster command ifconfig eth1|grep MTU

gnt-node add -s 192.168.9.4 datacenter1.example.com
gnt-node add -s 192.168.9.5 datacenter2.example.com

gnt-cluster command は全ノードで同じコマンドを走らせるユーティリティ。

gnt-node add はノード追加。 -s はDRBD通信用。


テスト用Xen仮想インスタンスを追加する。

vi /etc/hosts

192.168.10.11  dctest.example.com dctest
gnt-instance add -n datacenter1:datacenter2 -t drbd --disk 0:size=1G -B memory=1G,vcpus=1 -o debootstrap+default \
  -H xen-pvm:kernel_path=/boot/vmlinuz-2.6-xenU,initrd_path=/boot/initrd-2.6-xenU \
  --net 0:ip=192.168.10.11 dctest.example.com

datacenter1に入って

watch -n 1 pstree -al

で進捗確認。


gnt-node list
gnt-instance list -o name,pnode,snodes,status,oper_ram,oper_vcpus,nic.ips,disk.sizes

gnt-instance console dctest
passwd

vi /etc/network/interfaces
auto eth0
iface eth0 inet static
        address 192.168.10.11
        netmask 255.255.255.0
        network 192.168.10.0
        broadcast 192.168.10.255
        gateway 192.168.10.1
/etc/init.d/networking start

aptitude update
aptitude upgrade
aptitude install ssh vim

exit
^]
instance移動テスト

ssh で dctestに繋ぎ

vmstat 1

などを実行しておく。接続が途切れないかの確認用。


masterでの操作。

gnt-instance list -o name,pnode,snodes,status,oper_ram,oper_vcpus,nic.ips,disk.sizes
gnt-node list

gnt-instance replace-disks --new-secondary node1 dctest.example.com

node1 は移動前のLAN側にあるGanetiノード。

タイムアウトエラーになったら

gnt-job list
gnt-job watch <id>

gnt-instance migrate dctest

今回はデータセンター側から逆に移動。


動作が確認できたら削除。

gnt-instance remove dctest

引っ越し

ネットワーク設定

引っ越しする仮想マシンに入る。

vi /etc/iproute2/rt_tables

# 追加
100     dc

ifdown eth0
vi /etc/network/interfaces 
auto eth0
iface eth0 inet static
        address 192.168.10.21
        netmask 255.255.255.0
        network 192.168.10.0
        broadcast 192.168.10.255
        gateway 192.168.10.1
        post-up ip addr add 10.1.1.21/24 dev eth0 brd 10.1.1.255
        post-up ip route add 10.1.1.0/24 dev eth0 src 10.1.1.21 table dc
        post-up ip route add default via 10.1.1.1 table dc
        post-up ip rule add from 10.1.1.21 table dc
        pre-down ip rule del from 10.1.1.21 table dc
        pre-down ip route del default via 10.1.1.1 table dc
        pre-down ip route del 10.1.1.0/24dev eth0 src 10.1.1.21 table dc
        pre-down ip addr del 10.1.1.21/24 dev eth0 brd 10.1.1.21
ifup eth0

eth0:0でやろうとしたのだが、post-upなどはエイリアスには設定できなさそうだったので。

ip route と rule を使ってマルチホーミングの設定。ゲートウェイネットワークごとに持てる。ping -I ip_or_iface でIPインターフェースを指定してpingを打てるので、どちらのIPでも通信できていることを確認する。

外部からも古い方のグローバルIPと新しい方のグローバルIPpingを打ってテスト。


移動

Ganetiマスターノードでの作業。引っ越しするホストをhost1とする。

gnt-instance replace-disks --new-secondary datacenter1 host1.example.com

時間がかかるので、その間に

などをやっておく。


本来の引っ越し作業は、引っ越し時刻のTTL秒前からTTLを徐々に減らしていって引っ越し時刻に数分にすることでDNSキャッシュを調節するのだが、今回はVPNによって両方のグローバルIPが生きているので神経質になる必要はない。VPNを通す側のグローバルIPはちょっと遅くなるが。


セカンダリノードの付け替えが終わったらライブマイグレーションする。

gnt-instance migrate host1

残念ながら、正常終了したように見えたがカーネルパニックで止まっていた。

Dom0から見たら生きているが仮想マシンのコンソールを表示すると例のスタックトレースで停止している。


2013-03-03 00:58 追記: 続き

気を取り直して起動。

gnt-instance reboot host1

gnt-instance console host1

このままではVPNを通してDRBDミラーされているので、セカンダリも移動する。

gnt-instance replace-disks --new-secondary datacenter2 host1

これで完了。




まとめ

だいたい以下の流れ

色々ハマったが、実機での引っ越しに比べるとかなり楽にできたように思う。

書き忘れたが、DRBDのセカンダリ移動中は該当サーバーがかなり重い。せっかくNICやHUBを分けているのに、VPNしてるから結局同じ回線通るっていうね…。移動中のサーバーにあるwikiにこれをメモしていたのだが、ページ表示に数秒の待ち時間があった。これはDRBDの転送速度を調整してのんびり移行すればマシになるのかもしれない。


この後は旧環境のサーバーを全て移動して旧IPを破棄してVPN接続を終了する作業が待っているが、まだまだ先になりそう。

安全にいくならライブマイグレーションはやめて一度停止した方がいいかもしれない。




補足1:引っ越し先をNAT on Linux にする場合

一応試した。

Xen仮想マシンLinuxルーター

IPは x.x.x.31 とする。


debootstrapではカーネルが入らないので、iptables利用のためのカーネルを入れる。

参考: http://shell.burgas.org/2009/06/debian-50-xen-domu-iptables-kernel-module-problem-on-fresh-install/

aptitude install linux-modules-2.6.32-5-xen-amd64

cat > /etc/sysctl.d/ipforward.conf
net.ipv4.ip_forward = 1
^D

sysctl -p /etc/sysctl.d/ipforward.conf 

NAT設定

参考: http://d.hatena.ne.jp/mirans/20120710/1341921817

# NAT 外から内
iptables -t nat -A PREROUTING -d 10.1.1.32 -j DNAT --to 192.168.10.32

# NAT 内から外
iptables -t nat -A POSTROUTING -s 192.168.10.32 -j SNAT --to 10.1.1.32

NATするIPを x.x.x.32とした場合。


OS起動時のiptables実行は、Debianでは iptables-persistentを使う。

aptitude install iptables-persistent

vi /etc/init.d/iptables-persistent
# Default-Start:     2 3 4 5
# Default-Stop:      0 1 6

update-rc.d iptables-persistent defaults

移動する仮想マシン上での設定

一つのIPマルチホーミング


参考: http://d.hatena.ne.jp/hirose31/20120822/1345626743 http://ap.atmarkit.co.jp/bbs/core/flinux/27359

aptitude install linux-modules-2.6.32-5-xen-amd64

vi /etc/iproute2/rt_tables
# 100     dc を追加

外部からのpingに対応するMACアドレスtcpdump -e で調べる。(192.168.10.31のmacアドレスになっていればOK)

mac アドレスを判別してマーク設定し、ゲートウェイを分ける。

iptables -t mangle -A PREROUTING -m mac --mac-source 00:00:00:00:5e:aa -j MARK --set-mark 1
iptables -t mangle -A PREROUTING -j CONNMARK --save-mark
iptables -t mangle -A OUTPUT -j CONNMARK --restore-mark

ip rule add priority 100 fwmark 1 table dc
ip route add default via 192.168.10.31 dev eth0 table dc

192.168.10.31のmacアドレス 00:00:00:00:5e:aa で入ってきたパケットにマークを付けて、それを返すときは 192.18.10.31 に向ける。



設定がややこしくてNATなのに各サーバーiptables設定が必要なので結局この案は中止。

グローバルIPノーガードでいくことに。Debianなので大丈夫でしょう。


補足2:DSRも一応考えた

参考: http://www.os.cis.iwate-u.ac.jp/wikky/wikky.cgi?s-book%3A%3ASLB%3A%3A3


iptables のmanpageを眺めていたら、arptables というコマンドがあってそれでmacアドレスを書き換えられそう。

ただ、負荷分散しないのにNATの代わりに…ってのでやっぱり複雑だから却下。こちらは試していない。


補足3:カーネルパニックログ

一部抜粋。

[42698172.104748] Setting capacity to 16777216
[42698172.109068] Setting capacity to 16777216
[42698173.097889] general protection fault: 0000 [#1] SMP 
[42698173.097903] last sysfs file: /sys/module/ip_tables/initstate
[42698173.097910] CPU 0 

...

[42698173.098096] Stack:
[42698173.098100]  ffffffff810cf60f ffff88000000da00 000000103fda9300 00000000000280d0
[42698173.098112] <0> ffff88000000da08 ffff88003d915fd8 00007f4ee5cf4fff ffff880002ae8b80
[42698173.098127] <0> ffff88003e53f180 ffff880001805180 ffff88003ee8a7f0 ffff88003d8c17f0
[42698173.098143] Call Trace:
[42698173.098152]  [<ffffffff810cf60f>] ? copy_page_range+0x3e0/0x711
[42698173.098163]  [<ffffffff810e81d5>] ? kmem_cache_alloc+0x8c/0xf0
[42698173.098173]  [<ffffffff8104d2b9>] ? dup_mm+0x2d9/0x40a
[42698173.098181]  [<ffffffff8104de5b>] ? copy_process+0xa3c/0x115f
[42698173.098192]  [<ffffffff8100c3a5>] ? __raw_callee_save_xen_pud_val+0x11/0x1e
[42698173.098202]  [<ffffffff8104e6d5>] ? do_fork+0x157/0x31e
[42698173.098211]  [<ffffffff8130f906>] ? do_page_fault+0x2e0/0x2fc
[42698173.098220]  [<ffffffff81011e63>] ? stub_clone+0x13/0x20
[42698173.098229]  [<ffffffff81011b42>] ? system_call_fastpath+0x16/0x1b
[42698173.098236] Code: 00 00 00 01 74 05 e8 78 9a e8 ff 48 89 d0 5e c3 ff 14 25 40 eb 47 81 3e 81 2f 00 00 00 01 74 05 e8 5e 9a e8 ff c3 b8 00 00 01 00 <3e> 0f c1 07 0f b7 d0 c1 e8 10 39 c2 74 07 f3 90 0f b7 17 eb f5 
[42698173.098330] RIP  [<ffffffff8130d3f8>] _spin_lock+0x5/0x1b
[42698173.098340]  RSP <ffff88003d915c58>
[42698173.098348] ---[ end trace 492cb45db99e2316 ]---
[42698178.613836] BUG: Bad page map in process cron  pte:fffffffffffff145 pmd:0cc15067
[42698178.613851] addr:00007ff84e3cc000 vm_flags:08100073 anon_vma:ffff88003d8c8720 mapping:ffff88003f8bc840 index:8
[42698178.613864] vma->vm_ops->fault: filemap_fault+0x0/0x2f6
[42698178.613879] vma->vm_file->f_op->mmap: generic_file_mmap+0x0/0x47
[42698178.613889] Pid: 3006, comm: cron Tainted: G      D    2.6.32-5-xen-amd64 #1
[42698178.613897] Call Trace:
[42698178.613905]  [<ffffffff810cbe1b>] ? print_bad_pte+0x232/0x24a
[42698178.613915]  [<ffffffff8100c2f1>] ? __raw_callee_save_xen_pte_val+0x11/0x1e
[42698178.613924]  [<ffffffff810cbe83>] ? vm_normal_page+0x50/0x6b
[42698178.613933]  [<ffffffff810cf7ac>] ? copy_page_range+0x57d/0x711
[42698178.613942]  [<ffffffff810e81d5>] ? kmem_cache_alloc+0x8c/0xf0
[42698178.613951]  [<ffffffff8104d2b9>] ? dup_mm+0x2d9/0x40a
[42698178.613960]  [<ffffffff8104de5b>] ? copy_process+0xa3c/0x115f
[42698178.613968]  [<ffffffff8104e6d5>] ? do_fork+0x157/0x31e
[42698178.613977]  [<ffffffff810f3187>] ? sys_newstat+0x23/0x30
[42698178.613986]  [<ffffffff81011e63>] ? stub_clone+0x13/0x20
[42698178.613994]  [<ffffffff81011b42>] ? system_call_fastpath+0x16/0x1b
[42698178.614013] BUG: Bad page map in process cron  pte:fffffffffffff145 pmd:0ccfe067
[42698178.614023] addr:00007ff84e5fe000 vm_flags:08100073 anon_vma:ffff88003d8c8e00 mapping:ffff88003f883b30 index:3
[42698178.614034] vma->vm_ops->fault: filemap_fault+0x0/0x2f6
[42698178.614042] vma->vm_file->f_op->mmap: generic_file_mmap+0x0/0x47
[42698178.614050] Pid: 3006, comm: cron Tainted: G    B D    2.6.32-5-xen-amd64 #1
[42698178.614058] Call Trace:
[42698178.614065]  [<ffffffff810cbe1b>] ? print_bad_pte+0x232/0x24a
[42698178.614073]  [<ffffffff8100c2f1>] ? __raw_callee_save_xen_pte_val+0x11/0x1e
[42698178.614083]  [<ffffffff810cbe83>] ? vm_normal_page+0x50/0x6b
[42698178.614091]  [<ffffffff810cf7ac>] ? copy_page_range+0x57d/0x711
[42698178.614100]  [<ffffffff810e81d5>] ? kmem_cache_alloc+0x8c/0xf0
[42698178.614109]  [<ffffffff8104d2b9>] ? dup_mm+0x2d9/0x40a
[42698178.614117]  [<ffffffff8104de5b>] ? copy_process+0xa3c/0x115f
[42698178.614126]  [<ffffffff8104e6d5>] ? do_fork+0x157/0x31e
[42698178.614134]  [<ffffffff810f3187>] ? sys_newstat+0x23/0x30
[42698178.614142]  [<ffffffff81011e63>] ? stub_clone+0x13/0x20
[42698178.614150]  [<ffffffff81011b42>] ? system_call_fastpath+0x16/0x1b
[42698178.614503] BUG: unable to handle kernel paging request at ffffc7fffffff240
[42698178.614518] IP: [<ffffffff8100e15a>] make_lowmem_page_readonly+0x1b/0x38
[42698178.614531] PGD 0 
[42698178.614537] Oops: 0000 [#2] SMP 
[42698178.614545] last sysfs file: /sys/module/ip_tables/initstate
[42698178.614552] CPU 0 

...

[42698374.424004] BUG: soft lockup - CPU#0 stuck for 61s! [cron:9707]

...

[42698374.424004] Call Trace:
[42698374.424004]  [<ffffffff8100dd87>] ? xen_exit_mmap+0xf8/0x136
[42698374.424004]  [<ffffffff8100922a>] ? hypercall_page+0x22a/0x1001
[42698374.424004]  [<ffffffff810d14e8>] ? exit_mmap+0x5a/0x148
[42698374.424004]  [<ffffffff8104b9b0>] ? __cond_resched+0x1d/0x26
[42698374.424004]  [<ffffffff8104cc6d>] ? mmput+0x3c/0xdf
[42698374.424004]  [<ffffffff81050872>] ? exit_mm+0x102/0x10d
[42698374.424004]  [<ffffffff8100ec89>] ? xen_irq_enable_direct_end+0x0/0x7
[42698374.424004]  [<ffffffff81052297>] ? do_exit+0x1f8/0x6c6
[42698374.424004]  [<ffffffff8100ece2>] ? check_events+0x12/0x20
[42698374.424004]  [<ffffffff811ba6e0>] ? dummycon_dummy+0x0/0x3
[42698374.424004]  [<ffffffff8130e2cd>] ? oops_end+0xaf/0xb4
[42698374.424004]  [<ffffffff810333a4>] ? no_context+0x1e9/0x1f8
[42698374.424004]  [<ffffffff81033559>] ? __bad_area_nosemaphore+0x1a6/0x1ca
[42698374.424004]  [<ffffffff8130f68f>] ? do_page_fault+0x69/0x2fc
[42698374.424004]  [<ffffffff8130d7a5>] ? page_fault+0x25/0x30
[42698374.424004]  [<ffffffff8100e15a>] ? make_lowmem_page_readonly+0x1b/0x38
[42698374.424004]  [<ffffffff8100e151>] ? make_lowmem_page_readonly+0x12/0x38
[42698374.424004]  [<ffffffff8100e1cf>] ? xen_alloc_ptpage+0x58/0x70
[42698374.424004]  [<ffffffff810cd7c2>] ? __pte_alloc+0x6b/0xc6
[42698374.424004]  [<ffffffff810cb674>] ? pmd_alloc+0x28/0x5b
[42698374.424004]  [<ffffffff810cd8eb>] ? handle_mm_fault+0xce/0x80f
[42698374.424004]  [<ffffffff8130d7a5>] ? page_fault+0x25/0x30
[42698374.424004]  [<ffffffff8130d9da>] ? error_exit+0x2a/0x60
[42698374.424004]  [<ffffffff8101251d>] ? retint_restore_args+0x5/0x6
[42698374.424004]  [<ffffffff8130d42a>] ? _spin_unlock_irqrestore+0xd/0xe
[42698374.424004]  [<ffffffff8130f906>] ? do_page_fault+0x2e0/0x2fc
[42698374.424004]  [<ffffffff8130d7a5>] ? page_fault+0x25/0x30

ひたすら長い。

Xeniptables使ったのがまずい?

domUを起動した後にdomUカーネルイメージを入れたら起動時のカーネルからアップデートがかかって、domUカーネルモジュールにだけ更新がかかった気もする…。

再現させるのも大変だし、dom0のカーネルアップデートもすぐにはできないので一旦保留。



2013-02-28 23:18追記

typo修正。


他のサーバーも試したけれどダメだった。

カーネルが停止するか、停止しなくてもエラーログが流れるようになる。

考えられるのは…

  • ネットワーク設定が間違っている、間違っていないまでも推奨されないことをやっている
  • CPUなどのハードが違う
  • Xenバグ
  • ネットワークで何らかのエラーまたは遅すぎてアウト
  • HDDなどのトラブル

上から確率が高そうな順に。

一度はうまくいったんだけどなぁ。。。


今読み返していたら、成功した時はデータセンターから社内LANへの移動で、移動の方向が逆だった。

CPUとか移動先のハードが原因?

2013-02-25

[] IP変更やOSインストール時のssh警告を削除

メモ。

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.

などと警告が出た場合は

Offending key in /home/user/.ssh/known_hosts:97

というメッセージに従って .ssh/known_hosts の該当行を削除すればOK。


で、手動で削除するのも大変なのでコマンドで。

ssh-keygen -R <host_or_ip>