Linux-PowerEdgeML ウォッチ 2007

このページではLinux-PowerEdgeのメーリングリストの2007年のものをまとめています。最新のものはLinux-PowerEdgeMLのページ参照してください。

ロードならcheck_snmp_loadというプラグインがある。パフォーマンスを見たいなら、操作と監視を分け、net-snmpを使うのがいい。

デルから提供されているMIBを利用すればいい。ヴァーチャルディスクの場合、OMSAがインストールされていれば、/opt/dell/srvadmin/sm/mibs/dcstorag.mibにあるはず。/opt/dell/srvadmin/omsa/mibs/や/opt/dell/srvadmin/rac5/mibs/なども参考に。SNMPのリファレンスガイドもある。

DRACにローカルアクセスできるなら、System > Main System Chassis > Remote AccessでDRACの情報にアクセスできる。OMSAがインストールされていれば、「racadm getsysinfo」、「racadm getniccfg」、「omreport chassis remoteaccess」というコマンドで調べる手もある。

<kernel-source>/Documentation/networking/bonding.txtに情報がある。

Firefoxでうまく見えた。IE7ではProxyソフトウェアを利用するように設定していて、これがOMSAへのアクセスをブロックしていたようだ。設定を見直してみる。

いまそのようなプロジェクトをやっているところだが、Windowsを使う構成は良くない印象を持っている。私はNFSとSMBのサーバーを構成し、ネイティブプロトコルを使っている。NFSのほうが高速で、CIFS経由より信頼できるだろう。

64ビットは4GB以上のメモリが使えることが利点。計算やDBを使うところでは有用だ。大規模なサイトでは64ビットで運営している。クライアント向けには64ビットであるメリットは少ない。商用アプリケーションのようなバイナリしか配布していないものなどでは、64ビットに対応していないこともある。

omreportは使わずに、dmidecodeを使って「dmidecode | grep -i serial」のようにしたほうがいい。デルの公式見解ではlibsmbiosで取得することとなっている。dmidecodeは信頼できない。

support.dell.comにOpenManage Client Instrumentation applicationというのがある。

「/etc/init.d/dataeng enablesnmp」と実行すればいい。

そのエラーはprocmailがインストールされていないためだ。

OMSAのRPMパッケージが32ビットライブラリに依存していることをきちんと反映できるように改善をしているところだ。OMSAが32ビットなのは、64ビットにするメリットがないためだ。やがてこれはかわるだろう。

http://download.adaptec.com/pdfs/user_guides/aar2410Sa_iug.pdfやhttp://download.adaptec.com/pdfs/user_guides/sata-scsi_raid_iug.pdfを参照。OpenはUnix Openedの意味。Validはvalid containerの意味で、Linuxから認識され、マウントのようなクエリーがあったことを意味する。

バージョン5.1.1-0040も問題がある。5.2.1-0067は良好だ。Debian etchで5.1.1-0040から5.2.1-0067へのアップデートはうまくいった。

RAIDコントローラは関係ない。ディスク領域はLVMで管理している。

EMCpower.LINUX-5.0.1-022.rhel5.x86_64.rpmをインストールして、powermtコマンドでセットアップしていけばよい。

NRPE(Nagios Remote Plugin Executor)を使って、このスクリプトを動作させるのはどうか。cronでipmitoolの出力をファイルに落とし、このスクリプトでチェックする。

利用できる。PowerEdge 840はBroadcom 5721Jであり、DOSツールのb57udiagや、WindowsのBACS2(Broadcom Advanced Control Suite 2)、Linuxのethtoolから設定する。

それはLVMの仮想ボリュームとなっているため。LVM関連のコマンドで操作すればいい。

バージョン5.1.1-0040も不安定。5.2.1-0067は安定しているようだ。

ルートファイルシステムがリードオンリーでマウントされていたためのようだ。BIOSファイルにはBIN形式のものであればDebianでも使えるはず。DebianでOMSAを使う話は、https://subtrac.rc.sara.nl/oss/omsa_2_debにまとめてある。

LSIベースのRAIDコントローラならmegaCLIが使える。PERC/2 (IIRC)とCERCはAdaptecのチップセットで、afacliが使える。Zenossを使う方法もある。これは、SNMPでトラップして、Emailを送れる。OMSA向けのNRPEプラグインも使える。

/etc/init.d/dataengの前に「modprobe mptctl」を実行する必要がある。Webインターフェイスを利用するには、32ビットのPAMが必要だった。また、ファームウェアは最新のものにアップグレードする。RHEL用となっているBINファイルはDebianでも動作するだろう。

ずばり、MegaCLIを使う。

最新のシステムBIOSもlinux.dell.comのリポジトリに追加した。

カーネルオプションの「root」が間違っているのではないだろうか? そのとおり「root=LABEL=/1」とすべきところが「root=LABEL=/」だった。

同じような経験をした。この問題は、コントローラのライトキャッシュの設定で解決した。この際、OMSAを使ってはいけない。DellのドライバTARファイルにあるlsiutilを使う。詳細はhttp://kerneltrap.org/mailarchive/openbsd-misc/2007/7/15/152340を参照。

http://backuppc.sourceforge.net/faq/BackupPC.html#other_installation_topicsを参考にするといい。もしくはボリュームやパーティションイメージでコピーするのはどうだろうか。

最新のcheat sheetはhttp://tools.rapidsoft.de/から入手できる。直リンクはhttp://tools.rapidsoft.de/perc/perc-cheat-sheet.pdf。

アイドル時で375MHzが199~207W、3GHzが203~209W、フルロード時で375MHzが210W、3GHzが255W~262W。P4-clockmodでいくらかのW数は下がるが、タスクが終了するのにとても長い時間がかかるので、消費電力を抑えたことにはならない。

http://www.vmware.com/pdf/vi3_systems_guide.pdfやhttp://support.dell.com/support/edocs/software/eslvmwre/で確認するとよい。

Func(https://hosted.fedoraproject.org/projects/func/)にはSMARTをリモートから監視するモジュールがいくつか含まれている。

RHEL 5.0のExt3に8TBの制限があるが、5.1では16TBまでサポートしている。ただし、フォーマットの際「-F」オプションが必要。

残念ながらできない。1つないし複数のスイッチでPrivate VLANを構成する機能はない。

WSにはDNSとDHCPのパッケージが用意されていない。ASとES向けにはある。バージョン番号が古くても最新の修正が適当されていることもある。CVEの適用状況を確認したければ、「rpm -q --changelog bind|grep 'CVE XXX-XXX'」とすればよい。

DRACのWebインターフェイスやOMSAから変更できる。ただし、VMware ESX上のOMSAは簡単ではない。

そのとおり。自動でマウントさせるためには、GNOME環境であればgnome-volume-managerがデフォルトで動作しているはず。KDEの場合にこれを動作させるには、手動で起動・設定する。

linux.dell.comにCentOSにOMSAの入ったLive CDがあるので、それから起動してログを取り、Dell Techに送れば原因がわかるかもしれない。交換したハードディスクがちょっとだけセクタが足りないなど、原因はたくさん考えられる。PERCのBIOSにCrtl+Aキーで入って、「SCSI Disk Utilities」から表面チェックができる。

URLはhttp://wiki.mandriva.com/en/Docs/SysAdmin/Dell_OpenManage。

カーネルのI/Oサブシステムのパラメータを適切に設定する必要がある。デフォルト設定はおそらくデスクトップ用。deadlineに設定するのが良い。

Dell Product Configuration Calculatorが参考になる。ファンも電源消費の大きな要素であり、ラック内の温度が高いとファンがフル回転して電源を消費してしまう。メモリを減らす、そもそもデータセンターを変えたほうがいいのでは?

fdiskなどでパーティションを変更した際には、通常はカーネルに読み込ませるために再起動が必要だが、partprobeコマンドが使える場面がある。SCSIコントローラを再認識させるには、Red Hat系のOSなら「echo "scsi scsi-scan-devices" > /proc/scsi/scsi」とする方法がある。

いくつかのhdparamコマンドの結果が投稿される。hdparamでは正確な値を計測できないので、ddコマンドでの値を紹介。

いくつかの理由によって、RAIDのステイタスはIPMIにマップされていない。MegaCliとNRPE2を使う必要がある。

OMSAでの警告送付は主にSNMPを使っているので、ローカルでsnmptrapdを動作させれば、メールを送ることができる。

SCSIコントローラなので、2TBの制限がある。もし、2TB以上を構成するのなら、VDを2つ以上構成してから、それらをソフトウェアRAIDかLVMで結合する必要がある。

PERCはより多くのRAIDレベルをサポートし、キャッシュがあり、ホットスペアにも対応する。SASにはない。一般にPERCのほうがSAS iRより優れている。

EMCのサポートがあるからだろう。承認されたものしかサポートしない。PE1855と1955のDebianで問題なく動いている。ロードバランサやフェイルオーバーを機能させたいのなら、multipath-toolsパッケージの導入が必要。

シングル・マルチの両方のビットエラーを監視できる。メモリのテストなら、Dell MPmemoryを使って欲しい。これはmemtest86を改良したものだ。起動時にBIOSがメモリを確保しているため、通常のmemtest86は利用できない。MPmemoryはSELイベントとして結果を出力するので、ログをクリアしておくことをお勧めする。

そのようなシグナルで終了してしまうのは見たことがないが、とりあえずは、auditのルールにシグナル58のトラップを追加することだ。

RAIDのシグネチャが壊れた可能性がある。その場合はローレベルフォーマット後に再構成が必要なので、まずは、ディスクのエラーがあるか、PERC BIOSから調べる。具体的には、ConfigureからView/Add ConfigurationにいってディスクごとにF2キーを押していく。また、ファームウェアの可能性も高い。

チップセットは8rank(チャンネルやバンクともいう)まで利用できるので、メモリのrank次第。スロット数は関係ない。たとえば、2rankのメモリなら4つまで。rank数の情報は、「omreport chassis fru」や「dmidecode | grep -B2 -A20 "Memory Device"」で取得できる。

アップグレードしてもいい。RHELのどのバージョンを選んでもいいし、PowerEdge 1850ではRHEL 5をサポートしているので、DELLのサポートも受けられる。

リンクにあるように、backports.orgからAMD64 Etch用の2.6.22カーネルに入れ替えたら、この問題は直った。

PowerEdge 350はハードウェアモニターの機能がない。当時のOMSAを使えば、温度と電圧はモニターできるが、最新のOMSAだと350はサポート対象から外れている。350はIPMIの機能を持っていない点に注意。LibSMBIOSを使ってみるのはいかがだろう。

PERC2/SCカードは外して、ハードディスクは直接SCSIコントローラに接続したほうがいい。PERC2/SCカードはサポートされておらず、性能自体も悪い。

電源プラグを少しの間外してみた? 同じようなトラブルで、それが解決できた。リブートは意味がない。確かにうまくいった。で、原因は何なんだろう?

基本的なパッケージはOracle Unbreakable Linuxでも動くので、yumのリポジトリからインストールしてみては。何か問題があれば、知らせてくれ。

カーネルインストールで「rpm -aq | grep kernel」としては、別のものも入れることになるので失敗するのは当たり前。そもそもRed Hat Enterprise Linux 5ならQLogic HBAのドライバのインストールは必要ない。

PowerEdge SC1430上のCentOS、1950上のDebianで同様の質問。OMSA(Dell OpenManage Server Administrator)でできると思うがどうだろう? OMSAのSNMPデーモンは、ネイティブなSMTPデーモンと繋ぐものなので、トラップを受け取れるようにtrapsinkで適切な設定が必要。

これはi586カーネルで起きてしまう一般的な問題。i686カーネルへの入れ替えはFedoraのバグのページ参照するといい。BMCのファームウェアアップデートもDell Update Package(DUP)から行うといい。

SCシステムはOMSAをサポートしていないが、600SCと1600SCは例外。DRAC3/XTカードを導入すれば利用できる。OpenSUSEもOMSAはサポートしていないので、マニュアルインストールなどが必要。

これは気にする必要はない。PERC 5/iのコントローラは定期的にバッテリの状態を学習している。

依存関係にあるunshieldパッケージは、Fedoraの開発者によって提供されているEPEL(Extra Packages for Enterprise Linux)から入手できる。

 PowerEdge 1950で4月に買ったものと10月に買ったものでパフォーマンスが違うから、ファーム/BIOSをアップデートしたいという話。Ubuntuを使えばできる、ほかにアップデート方法はないのか?、PXEのrawイメージを提供してくれ、firmware-toolsにその機能を追加したらどうだろうか。

 GRUBのトラブルはフロッピーディスクから起動すればよい、でもフロッピーディスクはないよ、ddでフロッピーイメージを作り、マウントしてsetupコマンドを使う方法や、おそらくブータブルCDでもうまくいくはず。

 1750で動かした、サンのページに1900のリポートがあり1955ではCertifiedを取っているなど。


代表的な略語

  • PE:PowerEdge
  • OMSA:Dell OpenManage Server Administrator
  • EPEL:Extra Packages for Enterprise Linux
  • RHEL:Red Hat Enterprise Linux
  • RHN:Red Hat Network
  • SLES:Novell Suse Linux Enterprise Server


メーリングリストへの参加方法

  1. メーリングリストのページにアクセス
  2. ページ中ほどにある「Subscribing to Linux-PowerEdge」のところで、メールアドレスとパスワードを入力して、「Subscribe」ボタンを押す(このパスワードは厳密な管理をされない、念のための確認キーワードのようなものなので、使い捨てのパスワードなどを登録したほうが良い)
  3. すぐに(ちょっとしてから)「linux-poweredge-request@dell.com」から「confirm~」というタイトルで確認メールが届く(迷惑メールと判断されやすいので注意)。メール内に記載された「http://lists.us.dell.com/mailman/confirm/linux-poweredge/~」というリンクをクリックする
  4. またすぐに(ちょっとしてから)「linux-poweredge-request@dell.com」から「Welcome to the "Linux-PowerEdge" mailing list~」というメールが届いて完了