Admin Archive

• 要約: activateCmosToken 0xXXXX でDellのサーバマシンのBIOS設定は変えられます (但し、サポート外)

既に CentOS 5.x をインストール済みの Dell PowerEdge 830 サーバで、OS上でメモリがなぜか256MBしか認識されていませんでした。何か壊れてるのかと思い、既にインストールしてあったDell提供のサーバ管理ソフトウェア OpenManage でハードウェア情報を確認してみると、1GBのメモリが2枚認識されており、合計2GBと表示されていました。

そこで調べてみるとDellのサーバマシンのBIOSには、巨大なメモリが見えるとインストールが失敗するようなOSインストール用に OS Install Mode という設定があり、これが Enable になっているとメモリが256MBしか見えないようにハード的に制約を加えるようです。

というわけで、BIOSの設定を変えれば良いことが判りました。でも、このサーバは遠隔地に置いてあって、現地に行くのがちょっと大変です。こういう時にリモートKVMが使える別売りのDell Remote Access Controller(DRAC)が入っていれば、BIOS画面を直に見ながら簡単に設定できるのですが、残念ながらこのマシンにはDRACは入っていませんでした。というわけで、Linux上からBIOSの設定を変えられないのかなと調べたら変えられました。方法としては次の2つあります。

1. OpenManage 上のBIOS設定で変更
2. smbios に含まれるコマンドで変更

1は、WEB UIから設定する方法ですが、設定できる項目に限りがありました。基本的な項目以外は設定できないと思って良いでしょう。今回設定を変えたかった OS Install Mode も設定できませんでした。以下に、PowerEdge 830 で設定可能な項目と設定されていた値を記しておきます。

• 一般
  • Num Lock: オン
  • Diskette: 自動
  • NIC: PXE で有効
  • USB: BIOS サポートありで有効
  • IDE: 自動
  • Boot Sequence: デバイスリスト
  • Speaker: オン
  • CPU Logical Processor (HyperThreading): 有効
  • AC Power Recovery Mode: 最終
  • Embedded SATA Controller: ATA
  • SATA Port 0: 自動
  • SATA Port 1: 自動
  • SATA Port 2: オフ
  • SATA Port 3: オフ
  • IDE Primary Drive 0: 自動
  • IDE Primary Drive 1: オフ
  • Demand-Based Power Management: 無効
• シリアル通信
  • Serial Port 1: 不明
  • Console Redirection After Boot: 有効
  • Console Redirection: シリアルポート 1
  • Console Redirection Failsafe BAUD Rate: 19200

OpenManage はyumで簡単にインストールできるので、上記で設定した項目があれば、OpenManage で設定するのが良いと思います。

• 参考: Dell OMSA 6.1 Linux repository

2は、コマンドラインから設定する方法です。smbios と libsmbios は、OpenManage を入れると一緒にインストールされるDellのサーバマシンのBIOSにアクセスするためのユーティリティ群です。

• Command-line tools summary
• libsmbios – Trac

こちらはおそらくDellのサーバマシンに用意されているBIOSの設定項目すべてを設定できるのだと思います。ただし、BIOSの設定を変える activateCmosToken というコマンドは Unsupported Binaries に分類されています。従って、この記事を読んで設定したらBIOSが壊れてマシンが起動しなくなることもあるかもしれません。そうなっても自分で責任とれる方以外は絶対に行わない方が良いでしょう。

というわけで、設定の仕方です。設定を行うのはactivateCmosToken コマンドを使います。基本構文は次のとおりです。

# /usr/sbin/activateCmosToken 0x"Token Value"

Token Valueというのは、BIOS設定の項目とというる値に対してユニークに割り振られている値になります。Token Valueの一覧は以下にあります。先頭の項目がToken Valueになります。

• Token Value List

見てみれば判りますが、よくあるBIOS設定項目、最新の技術に関する設定項目、そして、Dell独自の設定項目があります。

現在の値を確認するには、isCmosTokenActive コマンドを使います。activateCmosToken 同様、引数に 0x"Token Value" を取ればいいだけです。出力の BITFIELD が 1 の場合、それが有効になっているという意味です。

では具体的に OS Install Mode を設定を変え、設定が変わっているか確認します。Token Value List より、OS Install Mode のとりうる値は Enable と Disable の2つで、それぞれに 0x008a と 0x008b の Token Value が割り当てられています。片方の Token Value に対して activateCmosToken を実行すると、もう片方の Token Value の BITFIELD が無効を示す 0 に自動的に変わります。

• Limit System Memory (OS Install Mode) を無効化する方法

# /usr/sbin/activateCmosToken 0x008b
DMI type 0xd4  Handle 0xd401  Index Port 0x70  Data Port 0x71  Type 0x008b  Location 0x55 AND(fe) OR(0)  BITFIELD: 1
# /usr/sbin/isCmosTokenActive 0x008a
Running...
DMI type 0xd4  Handle 0xd401  Index Port 0x70  Data Port 0x71  Type 0x008a  Location 0x55 AND(fe) OR(1)  BITFIELD: 0
# /usr/sbin/isCmosTokenActive 0x008b
Running...
DMI type 0xd4  Handle 0xd401  Index Port 0x70  Data Port 0x71  Type 0x008b  Location 0x55 AND(fe) OR(0)  BITFIELD: 1

• Limit System Memory (OS Install Mode) 有効化する方法

# /usr/sbin/activateCmosToken 0x008a
DMI type 0xd4  Handle 0xd401  Index Port 0x70  Data Port 0x71  Type 0x008a  Location 0x55 AND(fe) OR(1)  BITFIELD: 1
# /usr/sbin/isCmosTokenActive 0x008a
Running...
DMI type 0xd4  Handle 0xd401  Index Port 0x70  Data Port 0x71  Type 0x008a  Location 0x55 AND(fe) OR(1)  BITFIELD: 1
# /usr/sbin/isCmosTokenActive 0x008b
Running...
DMI type 0xd4  Handle 0xd401  Index Port 0x70  Data Port 0x71  Type 0x008b  Location 0x55 AND(fe) OR(0)  BITFIELD: 0

以上です。設定はマシンを再起動すると反映されます。

実際に上記の OS Install Mode を無効化する方法で実際に設定しました。その結果、次のように正常にメモリ2GB認識されるようになりました。

• 設定前

# free
             total       used       free     shared    buffers     cached
Mem:        252164     232364      19800          0       9264     129620
-/+ buffers/cache:      93480     158684
Swap:      2097144        236    2096908

• 設定後

# free
             total       used       free     shared    buffers     cached
Mem:       2059368     220968    1838400          0      10396     134724
-/+ buffers/cache:      75848    1983520
Swap:      2097144          0    2097144

無事、サーバのある現地に行くことなく、BIOS設定を変えることができました。遠隔地にあるサーバマシンのBIOS設定をどうしてもリモートで変えたい場合は、試してみると良いかもしれません。ただし、サポート外の方法ですので、BIOSが壊れて起動しなくなるかもしれないことは覚えておいてくださいね！

最近XenとKVMのHVM環境を比較して試していますが、これまで1台のマシン環境を毎回壊して作り直していました。これが毎回面倒なため、現在、他の用途だったマシンを2台潰して再構築しています。

仮想化環境をテストするのに、PVM環境をテストするなら適当な仮想化環境上(例: VMwareの上でXen PVM環境)で問題ないものの、HVM環境をテストするにはVT対応のCPUが載った実機が必要になるので面倒です。最近のCPUでないとVT対応していないし、VMをたくさん動かすにはメモリもたくさん必要で、そこらへんに余ってる古いマシンで試せず困りものです。

最終的にあと2台用意してXenとKVMを2ノードづつ計4台の環境にしたいものの残り2台をどうしようかな。

この日記が動いてるサーバはまだXenですが、新しく仮想マシンをたくさん作る機会があったので、XenからKVMに乗り換えました。OSはdebootstrapになっていますが、virt-installで強引なことしているのでDebianじゃなくてCentOSに入れ替わっています。

# gnt-instance list
Instance           Hypervisor OS          Primary_node    Status     Memory
admin1.example.org   kvm        debootstrap node1.example.org running      1.0G
admin2.example.org   kvm        debootstrap node2.example.org running      1.0G
cron1.example.org    kvm        debootstrap node1.example.org running      1.0G
db1.example.org      kvm        debootstrap node1.example.org running      1.0G
ftp1.example.org     kvm        debootstrap node2.example.org running      512M
irc1.example.org     kvm        debootstrap node1.example.org running      512M
lvs1.example.org     kvm        debootstrap node2.example.org running      512M
lvs2.example.org     kvm        debootstrap node1.example.org running      512M
mail1.example.org    kvm        debootstrap node1.example.org running      1.0G
mail2.example.org    kvm        debootstrap node2.example.org running      1.0G
nouse.example.org    kvm        debootstrap node2.example.org ADMIN_down      -
template.example.org kvm        debootstrap node1.example.org ADMIN_down      -
web1.example.org     kvm        debootstrap node2.example.org running      1.0G
web-ssl1.example.org kvm        debootstrap node1.example.org running      1.0G
web-ssl2.example.org kvm        debootstrap node2.example.org running      1.0G

ディスクイメージもファイルからLVMへ乗り換えました。I/O的にも早くなりましたし、1仮想マシンに1LV割り当てたのでライブマイグレーションも出来るようになりました。

# cat /proc/drbd
version: 8.3.2 (api:88/proto:86-90)
GIT-hash: dd7985327f146f33b86d4bff5ca8c94234ce840e build by mockbuild@v20z-x86-64.home.local, 2009-08-29 14:07:55

 1: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----
    ns:1030228 nr:0 dw:1030228 dr:515856 al:499 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
 2: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r----
    ns:0 nr:684592 dw:684592 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
 3: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----
    ns:282556 nr:0 dw:282556 dr:432780 al:226 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
 4: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r----
    ns:0 nr:594628 dw:594628 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
 5: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----
    ns:281224 nr:0 dw:281224 dr:433112 al:242 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
 6: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r----
    ns:0 nr:281116 dw:281116 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
 7: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----
    ns:281048 nr:0 dw:281048 dr:432008 al:227 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
 8: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r----
    ns:0 nr:283900 dw:283900 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
 9: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----
    ns:286256 nr:0 dw:286256 dr:430084 al:242 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
10: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r----
    ns:0 nr:281384 dw:281384 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0
11: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----
    ns:306608 nr:0 dw:306608 dr:532548 al:286 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

13: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----
    ns:681680 nr:0 dw:681680 dr:823276 al:468 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
14: cs:Connected ro:Secondary/Primary ds:UpToDate/UpToDate C r----
    ns:0 nr:571076 dw:571076 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:f oos:0

100: cs:Connected ro:Primary/Secondary ds:UpToDate/UpToDate C r----
    ns:48640 nr:0 dw:48640 dr:217 al:23 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0
101: cs:Connected ro:Secondary/Secondary ds:UpToDate/UpToDate C r----
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:188

今回KVMを使ってみて、XenとKVMでは、ホストマシン上でのCPU(uptime)とメモリ(free)の表示が違っていることに気付きました。

Xenを使った時のuptimeの表示は、ホスト側も特殊なDom0 Kernelなのでゲスト側でCPUに負荷が掛かってもホスト側のuptimeにその負荷具合が反映されませんでした。一方、KVMの場合はゲストマシンは1プロセスとして見えるので、ゲスト側に負荷を与えるとホスト側のuptimeの表示に負荷具合が反映されました。

Xenを使った時のfreeの表示は、dom_mem0を指定していない場合、割り当てたメモリ分だけtotalの値が減り、ホスト側では見えなくなります。一方、KVMの場合は起動時に指定したメモリを上限とし、実際にゲスト上でメモリが使用されるとホスト側のfreeが消費されてusedが増えていき、totalの値は常に物理メモリの量のままでした。つまり常に動的なバルーン機能が働いているような状態。もしくは、Sparseファイルのメモリ版のような状態。

どちらが良いかは好みですが、ホスト側で状況を把握できるKVMの方が良い気がしています。あと、最近はXenよりKVMが推されているようなので今後はXenとKVMどちらでも良い場合はKVMを使っていこうと思っています。

• DRBD 8.3.x + Heartbeat 2.1.4 を使用する場合、この修正が必要です。
• DRBD 8.2.x + Heartbeat 2.1.4 を使用する場合、この修正は不要です。

DRBD 8.3.x にアップデートしたら、HeartbeatでCRMのDRBDリソースが上手く動かなくなりました。以下のようなエラー。

lrmd[11950]: 2009/09/03_14:15:12 info: rsc:drbd1:0: start
crmd[11953]: 2009/09/03_14:15:12 info: do_lrm_rsc_op:
 Performing op=drbd1:1_start_0 key=xx:4:0:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)
crmd[11953]: 2009/09/03_14:15:12 info: do_lrm_rsc_op:
 Performing op=drbd1:0_start_0 key=xx:4:0:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)
lrmd[11950]: 2009/09/03_14:15:12 info: RA output: (drbd1:0:start:stdout) 1:
 Failure: (124) Device is attached to a disk (use detach first)
 Command 'drbdsetup 1 disk /dev/VolGroup01/DRBD1 /dev/VolGroup01/DRBD1 internal
  --set-defaults --create-device' terminated with exit code 10
drbd[12636]:    2009/09/03_14:15:12 ERROR: drbd1 start: not in Secondary mode after start.
crmd[11953]: 2009/09/03_14:15:12 info: process_lrm_event:
 LRM operation drbd1:0_start_0 (call=16, rc=1) complete

原因はDRBDリソースが drbdadm state コマンドを使っているせいです。8.3からは drbdadm role コマンドを使うのが正しいそうです。以下、drbdadmコマンドの実行例です。

# drbdadm state drbd1
drbdadm state' is deprecated, use 'drbdadm role' instead.
Primary/Secondary

1行目の警告が邪魔してHeartbeatが上手く動かないようです。しょうがないので手動でDRBDリソース /usr/lib/ocf/resource.d/heartbeat/drbd を修正しましょう。以下、修正後のdiffです。

# diff /usr/lib/ocf/resource.d/heartbeat/drbd.default /usr/lib/ocf/resource.d/heartbeat/drbd
235c235
<       DRBD_STATE=$(do_drbdadm state $RESOURCE)
---
>       DRBD_STATE=$(do_drbdadm role $RESOURCE)

これで上手く起動するようになります。たぶん、Heartbeat 2.1.5 がリリースされれば修正されたものがインストールされます。

• Linux-HA Dev: resources/OCF/drbd@3317a881ba21

ちなみに Heartbeat 2.1.3 の Master/Slaveリソースはバグってて、1個のMaster/Slaveリソースでフェイルオーバが始まると他のすべてのMaster/Slaveリソースも一旦ダウンしてしまうので使わない方が良いです。

後輩から教えて貰いました。CentOS 4 と CentOS 5 のDRBDパッケージにDRBD 8.3系が加わるようです。来週リリースされるらしいので準備しておきましょう。

• DRBD packages in CentOS 4 and CentOS 5 to be updated

今までCentOS 5では、DRBD 8.0系と8.2系があって、それぞれdrbd-8.0.x, kmod-drbd-8.0.xとdrbd82-8.2.x, kmod-drbd82-8.2.xというパッケージがありましたが、これにdrbd83-8.3.x, kmod-drbd83-8.3.xが加わるようです。

パッケージ名が違うので勝手に入ることはないと思いますが既に使っている方は把握しておいた方が良いでしょう。既に使っていて8.3系に更新する場合は、上記のブログではセカンダリノードから更新していく手順が書かれています。

手元の環境はたすき掛けにしているので、結果的に一気にやることになりますね。

[追記] 9/2にリリースされました。

そんなことしてる暇もない気がすごくするものの、ちょっと前にビデオドライバを入れ直したあたりから動作が怪しくなっていたVista 64-bit版環境から脱出するためにWindows 7 64-bit版をクリーンインストールして移行してみた。Vista 64-bit版で動いていたソフトやJava関係は軽く使ってみた感じどれも問題無さそう。ウィルスバスター2009 64-bit版も一応動くらしいけど念のためこれだけまだ入れてない。

1.5.x系か1.6.x系にあげることも考えましたが今回はとりあえずパッチで済ませました。パッチは以下のどっちでもOK。1箇所だけ中身違う箇所があるけどやってることは一緒でした。

• [RHSA-2009:1203-01] Important: subversion security update のSRPMの中の subversion-1.4.2-CVE-2009-2411.patch
• Patch to 1.4.x branch for CVE-2009-2411 の添付ファイルのパッチ

Atlassianのサポートの方から64-bit JVMは推奨していないと教えていただき、32-bitに変えてみたところ、多少重い時は相変わらずあるものの全くアクセス不能になることはなくなりました。

ポインタとして示していただいたFishEyeのSystem Requirements にも下記のように急激にメモリを消費するってちゃんと明記されていました。

We strongly recommend the use of a 32-bit JDK/JRE rather than a 64-bit JDK/JRE. 64-bit JDK/JREs will consume the available RAM more rapidly, and this may result in poor performance.

他のインストール方法や管理、パフォーマンスチューニングのドキュメントは読んでたけど、肝心のSystem Requirementsはスルーしてました。。

32-bit JVMに変えたのでVMのパラメータも変更しました。

FISHEYE_OPTS="-Xms512m -Xmx2048m -XX:NewSize=256m -XX:MaxNewSize=256m \
-XX:PermSize=128m -XX:MaxPermSize=128m"

• FishEyeが重い
• FishEyeが重い (2)

どうやらSVNへのアクセス中にSVNKitの例外が発生すると、その後ひどいことになるらしい。

FishEyeのソースは見れないのでAtlassianにサポートをお願いしてみました。

2009-08-04追記: とりあえず解決しました。

• FishEyeが重い
• FishEyeが重い (2)
• FishEyeが重い (とりあえず解決)

ソースコードブラウザをFishEye & Crucibleへ移行したら重すぎて全然表示出来ていませんでした。富豪的にメモリを割り当てて、VMのパラメータを変えてみました。

FISHEYE_OPTS="-Xms1024M -Xmx3072M -XX:NewSize=768M -XX:MaxNewSize=768M \
-XX:PermSize=128M -XX:MaxPermSize=256M -XX:+UseConcMarkSweepGC"

でもまだ重いです。また、変えるかもしれません。iowaitしているわけでも、load averageが高いわけでもなく、ただただJavaのオブジェクト生成が大量にありGCが掛かって遅いように見えます。

2009-08-04追記: とりあえず解決しました。

• FishEyeが重い
• FishEyeが重い (2)
• FishEyeが重い (とりあえず解決)