無停止でサーバーをデータセンターに引っ越し： OpenVPN, Ganeti, Xen, LVM, DRBD
社内に置いてあるサーバーをOSごとデータセンターに移したのでその作業ログ。
はじめに。
- 長いです
- タイトルは大げさです
- 同じような環境の参考情報が見つからなかったのでこれが妥当なやり方がは判別できていない
- 普通はこうするよ、というのがあれば是非
- 前提条件
調べつつハマりつつやったので、まぁ知らなくても大丈夫。
Ganetiを使っているのでXenやLVM、DRBDを直接は触っていない。Ganetiを使っていない場合でも手動でLVMやDRBDを設定すればいけるはず。
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 tap1VPNのために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/
クライアント側で署名済み証明書設定
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 する。
サーバーからクライアント、クライアントからサーバーでローカルIPのping確認。また、ネットワーク上の他のマシンからも確認。
/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のインストールは割愛。本家のマニュアルを上から順にやっていくのが一番失敗がない。自分の環境では一度設定した流れをシェルスクリプトに書いていて、そのまま実行したり所々変えながら実行したりしている。xenやgrubの共通設定、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 9000Xenの普通の設定。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通信用。
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.21ifup eth0
eth0:0でやろうとしたのだが、post-upなどはエイリアスには設定できなさそうだったので。
ip route と rule を使ってマルチホーミングの設定。ゲートウェイをネットワークごとに持てる。ping -I ip_or_iface でIPやインターフェースを指定してpingを打てるので、どちらのIPでも通信できていることを確認する。
外部からも古い方のグローバルIPと新しい方のグローバルIPにpingを打ってテスト。
移動
Ganetiマスターノードでの作業。引っ越しするホストをhost1とする。
gnt-instance replace-disks --new-secondary datacenter1 host1.example.com
時間がかかるので、その間に
などをやっておく。
本来の引っ越し作業は、引っ越し時刻のTTL秒前からTTLを徐々に減らしていって引っ越し時刻に数分にすることでDNSキャッシュを調節するのだが、今回はVPNによって両方のグローバルIPが生きているので神経質になる必要はない。VPNを通す側のグローバルIPはちょっと遅くなるが。
セカンダリノードの付け替えが終わったらライブマイグレーションする。
gnt-instance migrate host1
残念ながら、正常終了したように見えたがカーネルパニックで止まっていた。
Dom0から見たら生きているが仮想マシンのコンソールを表示すると例のスタックトレースで停止している。
気を取り直して起動。
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接続を終了する作業が待っているが、まだまだ先になりそう。
安全にいくならライブマイグレーションはやめて一度停止した方がいいかもしれない。
補足１：引っ越し先を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なので大丈夫でしょう。
補足２：DSRも一応考えた
参考: http://www.os.cis.iwate-u.ac.jp/wikky/wikky.cgi?s-book%3A%3ASLB%3A%3A3
iptables のmanpageを眺めていたら、arptables というコマンドがあってそれでmacアドレスを書き換えられそう。
ただ、負荷分散しないのにNATの代わりに…ってのでやっぱり複雑だから却下。こちらは試していない。
補足３：カーネルパニックログ
一部抜粋。
[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
ひたすら長い。
Xenでiptables使ったのがまずい？
domUを起動した後にdomUでカーネルイメージを入れたら起動時のカーネルからアップデートがかかって、domUのカーネルモジュールにだけ更新がかかった気もする…。
再現させるのも大変だし、dom0のカーネルアップデートもすぐにはできないので一旦保留。
他のサーバーも試したけれどダメだった。
カーネルが停止するか、停止しなくてもエラーログが流れるようになる。
考えられるのは…
- ネットワーク設定が間違っている、間違っていないまでも推奨されないことをやっている
- CPUなどのハードが違う
- Xenのバグ
- ネットワークで何らかのエラーまたは遅すぎてアウト
- HDDなどのトラブル
上から確率が高そうな順に。
一度はうまくいったんだけどなぁ。。。
今読み返していたら、成功した時はデータセンターから社内LANへの移動で、移動の方向が逆だった。
CPUとか移動先のハードが原因？
