[Solaris]コールドスタンバイ動作に挑んだ
Solarisには変わったカードスロットが備わっておりまして。それがSystem Configuration Card (SCC)と言う奴でありまして。具体的にはこんなカードでございます。
これの中には、サーバのMACアドレスなどなどが登録されているそうで。今回、ためしにこんなことをやってみました。
- 元々動いてるサーバを停止する。
- 電源も抜線する。
- SCCと搭載ハードディスクをもう一台にそのままそっくり移し変える
- 動作確認をする
つまりは、コールドスタンバイの動作確認って奴ですね。それで起動してみました。
なんと、ALOMは以前の設定のまますんなり稼動しました。ログインもいたって普通。ifconfigの実行結果についても全くおんなじ。
移行前のifconfig結果
# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
bge0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.100.207 netmask ffffff00 broadcast 192.168.100.255
groupname ybkmp
ether 0:14:4f:8e:6f:f2
bge0:1: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu 1500 index 2
inet 192.168.100.107 netmask ffffff00 broadcast 192.168.100.255
bge1: flags=69040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER,STANDBY,INACTIVE> mtu 1500 index 3
inet 192.168.100.117 netmask ffffff00 broadcast 192.168.100.255
groupname ybkmp
ether 0:14:4f:8e:6f:f3
違う筐体で実行させたifconfig -aの結果
# ifconfig -a
lo0: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL> mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
bge0: flags=1000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4> mtu 1500 index 2
inet 192.168.100.207 netmask ffffff00 broadcast 192.168.100.255
groupname ybkmp
ether 0:14:4f:8e:6f:f2
bge0:1: flags=9040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER> mtu 1500 index 2
inet 192.168.100.107 netmask ffffff00 broadcast 192.168.100.255
bge1: flags=69040843<UP,BROADCAST,RUNNING,MULTICAST,DEPRECATED,IPv4,NOFAILOVER,STANDBY,INACTIVE> mtu 1500 index 3
inet 192.168.100.117 netmask ffffff00 broadcast 192.168.100.255
groupname ybkmp
ether 0:14:4f:8e:6f:f3
おおぅ、MACアドレスが完全に一致しとる。これには本当に驚いた。
移行先のディスク状態についても確認してみる。
# metastat d7: Mirror Submirror 0: d17 State: Needs maintenance Submirror 1: d27 State: Needs maintenance Pass: 1 Read option: roundrobin (default) Write option: parallel (default) Size: 62918208 blocks (30 GB)
d17: Submirror of d7 State: Needs maintenance Invoke: metasync d7 Size: 62918208 blocks (30 GB) Stripe 0: Device Start Block Dbase State Reloc Hot Spare c1t0d0s7 0 No Okay Yes
d27: Submirror of d7 State: Needs maintenance Invoke: metasync d7 Size: 62918208 blocks (30 GB) Stripe 0: Device Start Block Dbase State Reloc Hot Spare c1t1d0s7 0 No Okay Yes
d3: Mirror Submirror 0: d13 State: Needs maintenance Submirror 1: d23 State: Needs maintenance Pass: 1 Read option: roundrobin (default) Write option: parallel (default) Size: 8395200 blocks (4.0 GB)
d13: Submirror of d3 State: Needs maintenance Invoke: metasync d3 Size: 8395200 blocks (4.0 GB) Stripe 0: Device Start Block Dbase State Reloc Hot Spare c1t0d0s3 0 No Okay Yes
d23: Submirror of d3 State: Needs maintenance Invoke: metasync d3 Size: 8395200 blocks (4.0 GB) Stripe 0: Device Start Block Dbase State Reloc Hot Spare c1t1d0s3 0 No Okay Yes
d1: Mirror Submirror 0: d11 State: Needs maintenance Submirror 1: d21 State: Needs maintenance Pass: 1 Read option: roundrobin (default) Write option: parallel (default) Size: 33560448 blocks (16 GB)
d11: Submirror of d1 State: Needs maintenance Invoke: metasync d1 Size: 33560448 blocks (16 GB) Stripe 0: Device Start Block Dbase State Reloc Hot Spare c1t0d0s1 0 No Okay Yes
d21: Submirror of d1 State: Needs maintenance Invoke: metasync d1 Size: 33560448 blocks (16 GB) Stripe 0: Device Start Block Dbase State Reloc Hot Spare c1t1d0s1 0 No Okay Yes
d0: Mirror Submirror 0: d10 State: Needs maintenance Submirror 1: d20 State: Needs maintenance Pass: 1 Read option: roundrobin (default) Write option: parallel (default) Size: 38302464 blocks (18 GB)
d10: Submirror of d0 State: Needs maintenance Invoke: metasync d0 Size: 38302464 blocks (18 GB) Stripe 0: Device Start Block Dbase State Reloc Hot Spare c1t0d0s0 0 No Okay Yes
d20: Submirror of d0 State: Needs maintenance Invoke: metasync d0 Size: 38302464 blocks (18 GB) Stripe 0: Device Start Block Dbase State Reloc Hot Spare c1t1d0s0 0 No Okay Yes
Device Relocation Information: Device Reloc Device ID c1t1d0 Yes id1,sd@SFUJITSU_MAW3073NCSUN72G_000748B0PD9D____DAN0P7B0PD9D c1t0d0 Yes id1,sd@SFUJITSU_MAW3073NCSUN72G_000747B0PAB1____DAN0P7B0PAB1
あら、Needs Maintenanceと出てる・・後でチョイと調べておこうかね。
でも、一応ちゃんとマウントは出来ているみたい。
# df -h
Filesystem size used avail capacity Mounted on
/dev/md/dsk/d0 18G 4.7G 13G 27% /
/devices 0K 0K 0K 0% /devices
ctfs 0K 0K 0K 0% /system/contract
proc 0K 0K 0K 0% /proc
mnttab 0K 0K 0K 0% /etc/mnttab
swap 5.5G 1.4M 5.5G 1% /etc/svc/volatile
objfs 0K 0K 0K 0% /system/object
sharefs 0K 0K 0K 0% /etc/dfs/sharetab
/platform/sun4u-us3/lib/libc_psr/libc_psr_hwcap1.so.1
18G 4.7G 13G 27% /platform/sun4u-us3/lib/libc_psr.so.1
/platform/sun4u-us3/lib/sparcv9/libc_psr/libc_psr_hwcap1.so.1
18G 4.7G 13G 27% /platform/sun4u-us3/lib/sparcv9/libc_psr.so.1
fd 0K 0K 0K 0% /dev/fd
/dev/md/dsk/d1 16G 97M 16G 1% /var
swap 5.5G 0K 5.5G 0% /tmp
swap 5.5G 24K 5.5G 1% /var/run
/dev/md/dsk/d7 30G 30M 29G 1% /export/home
#
ということで、コールドスタンバイする際はおそらくSCCも変更しなきゃならないんだろうね。hostidに紐づくソフトウェアも多いことだし。
hostidに関しては、MACアドレスが全く同じだったこともあり、全く同じでした。
[筐体交換前]
# hostid
848e6ff2
[筐体交換後]
# hostid
848e6ff2
