Debian/proxmoxでのmpt-statusdによるRAIDステータスの監視


リモートでやるのが怖くて、実施できていなかったProxmoxのメジャーバージョンアップを実施した。

Debianのメジャーバージョンアップ、ということになるのだが、案の定、失敗。
(アップデートに必要なファイル群が404エラーで取得できなかった)
調査が面倒だったので、さくっと消去して新バージョンで再インストールした。

で、使用しているサーバはLSI Logic系のRAID/SCSIカードを使っているので、mpt-statusdによるRAIDステータス監視が行える。

古いバージョンのときは、以下のような/etc/default/mpt-statusdを書いていた。

# cat /etc/default/mpt-statusd
modprobe mptctl
ID="3 -n"
#

(「modprobe mptctl」を書かないと/dev/mptctlが作られず、mpt-statusがエラーになる)

通常は「ID=”3″」にするのだと思うが、これだと、syncのパーセンテージとかが表示されないという欠点がある。

root@ns5:/etc/init.d# mpt-status -i 3
ioc0 vol_id 3 type IM, 2 phy, 231 GB, state OPTIMAL, flags ENABLED
ioc0 phy 0 scsi_id 9 ATA      WDC WD2502ABYS-1 3B04, 232 GB, state ONLINE, flags NONE
ioc0 phy 1 scsi_id 4 ATA      WDC WD5000AAJS-5 3B01, 465 GB, state ONLINE, flags NONE
#

このため、syncのステータスが表示される「-n」オプション付にすることにしていた。

# mpt-status -i 3 -n
ioc:0 vol_id:3 type:IM raidlevel:RAID-1 num_disks:2 size(GB):231 state: OPTIMAL flags: ENABLED
ioc:0 phys_id:0 scsi_id:9 vendor:ATA      product_id:WDC WD2502ABYS-1 revision:3B04 size(GB):232 state: ONLINE flags: NONE sync_state: 100 ASC/ASCQ:0x11/0x00 SMART ASC/ASCQ:0xff/0xff
ioc:0 phys_id:1 scsi_id:4 vendor:ATA      product_id:WDC WD5000AAJS-5 revision:3B01 size(GB):465 state: ONLINE flags: NONE sync_state: 100 ASC/ASCQ:0xff/0xff SMART ASC/ASCQ:0xff/0xff
scsi_id:0 100%
scsi_id:1 100%
#

同期中のサンプル

# mpt-status -i 3 -n
ioc:0 vol_id:3 type:IM raidlevel:RAID-1 num_disks:2 size(GB):231 state: DEGRADED flags: ENABLED RESYNC_IN_PROGRESS
ioc:0 phys_id:0 scsi_id:9 vendor:ATA      product_id:WDC WD2502ABYS-1 revision:3B04 size(GB):232 state: ONLINE flags: NONE sync_state: 1 ASC/ASCQ:0x11/0x00 SMART ASC/ASCQ:0xff/0xff
ioc:0 phys_id:1 scsi_id:4 vendor:ATA      product_id:WDC WD5000AAJS-5 revision:3B01 size(GB):465 state: ONLINE flags: OUT_OF_SYNC sync_state: 1 ASC/ASCQ:0xff/0xff SMART ASC/ASCQ:0xff/0xff
scsi_id:0 1%
scsi_id:1 1%
#

壊れているときのサンプル

# mpt-status -i 3 -n
ioc:0 vol_id:3 type:IM raidlevel:RAID-1 num_disks:2 size(GB):231 state: DEGRADED flags: ENABLED
ioc:0 phys_id:1 scsi_id:9 vendor:ATA      product_id:WDC WD2502ABYS-1 revision:3B04 size(GB):232 state: ONLINE flags: NONE sync_state: 100 ASC/ASCQ:0x11/0x00 SMART ASC/ASCQ:0xff/0xff
ioc:0 phys_id:0 scsi_id:4 vendor: product_id: revision: size(GB):232 state: MISSING flags: OUT_OF_SYNC sync_state: 100 ASC/ASCQ:0x00/0x00 SMART ASC/ASCQ:0x00/0x00
scsi_id:1 100%
scsi_id:0 100%
#

これで問題ないだろうと思っていたのですが、ステータス変化が無くても2時間おきにメールが・・・

mpt-statusdってどういう仕組みなのか/etc/init.d/mpt-statusdの中身を確認・・・
単純に一定時間間隔でmpt-statusコマンドを実行し、その結果を比較しているだけ、と判明。

        if (mpt-status -i $ID) |grep -q 'state OPTIMAL' ; then
            BADRAID=false
        else
            BADRAID=true
            logger -t mpt-statusd "detected non-optimal RAID status"
        fi

今回、問題となっているのは上記の部分だった。
-nのときは「state: OPTIMAL」と、コロン入りのステータス表示になっているためだった。

なので、下記のように「state: OPTIMAL」を見るように変更することで解決した。

        if (mpt-status -i $ID) |grep -q 'state: OPTIMAL' ; then
            BADRAID=false
        else
            BADRAID=true
            logger -t mpt-statusd "detected non-optimal RAID status"
        fi

Windows7でGet-AzureVM | Out-GridViewが動作しない


Azure環境をCLIで操作するためのMicrosoft Azure PowerShellですが、最近のバージョンでは、Windows 7 SP1のPowerShell 3.0では正常に動作しないコマンドがあるようです。

まず、現在のPower Shellのバージョンは「$PSversiontable」で確認できます。

PS C:\> $PSversiontable

Name                           Value
----                           -----
PSVersion                      3.0
WSManStackVersion              3.0
SerializationVersion           1.1.0.1
CLRVersion                     4.0.30319.34209
BuildVersion                   6.2.9200.16398
PSCompatibleVersions           {1.0, 2.0, 3.0}
PSRemotingProtocolVersion      2.2


PS C:\>

上記の「PSVersion」がPower Shellのバージョンになります。

次に、Azure Power Shellのバージョンは「(Get-Module Azure).version」で確認できます。

PS C:\> (Get-Module azure).version

Major  Minor  Build  Revision
-----  -----  -----  --------
0      9      2      -1

PS C:\>

上記の場合「0.9.2」です

この場合、「$vm = Get-AzureVM | Out-GridView -Title “Select a VM …” -PassThru」を実行すると、

PS C:\> $vm = Get-AzureVM | Out-GridView -Title "Select a VM ..." -PassThru
Get-AzureVM : パイプラインが停止されています。
発生場所 行:1 文字:7
+ $vm = Get-AzureVM | Out-GridView -Title "Select a VM ..." -PassThru
+       ~~~~~~~~~~~
    + CategoryInfo          : CloseError: (:) [Get-AzureVM]、PipelineStoppedException
    + FullyQualifiedErrorId : Microsoft.WindowsAzure.Commands.ServiceManagement.IaaS.GetAzureVMCommand

Out-GridView : インデックスが範囲を超えています。負でない値で、コレクションのサイズよりも小さくなければなりません。
パラメーター名:index
発生場所 行:1 文字:21
+ $vm = Get-AzureVM | Out-GridView -Title "Select a VM ..." -PassThru
+                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Out-GridView], ArgumentOutOfRangeException
    + FullyQualifiedErrorId : System.ArgumentOutOfRangeException,Microsoft.PowerShell.Commands.OutGridViewCommand

PS C:\>

Out-GridViewが「ArgumentOutOfRangeException」ということで実行できません。
(「(Get-AzureVM).Name | Out-GridView -PassThue」は実行できるんだけど、得られる出力では次の処理ができない)

この現象はMicrosoftがgithubに開設しているアカウントに報告されている。
Possible breaking change Get-AzureVM breaks pipeline with Out-Gridview (#3047) #13

これによると、どうやら、Power Shell 4.0が必要らしい。

Windows Management Framework 4.0」の一部としてPower Shell 4.0が配布されているので、こちらからダウンロードしてインストールする。
リンク先でダウンロードすると、いくつかのファイルがダウンロードできるが、Windows7の64bit環境で必要なものは「Windows6.1-KB2819745-x64-MultiPkg.msu」だけである。Windows7 32bitの場合は Windows6.1-KB2819745-x86.msu」

インストール&再起動後にPower Shellの状況を確認すると、以下のようになる。

PS C:\>  $PSversiontable

Name                           Value
----                           -----
PSVersion                      4.0
WSManStackVersion              3.0
SerializationVersion           1.1.0.1
CLRVersion                     4.0.30319.34209
BuildVersion                   6.3.9600.16406
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0}
PSRemotingProtocolVersion      2.2


PS C:\> (Get-Module azure).version

Major  Minor  Build  Revision
-----  -----  -----  --------
0      9      2      -1


PS C:\>

で・・改めて「$vm = Get-AzureVM | Out-GridView -Title “Select a VM …” -PassThru」を実行!

PS C:\> $vm = Get-AzureVM | Out-GridView -Title "Select a VM ..." -PassThru
Get-AzureVM : パイプラインが停止されています。発生場所 行:1 文字:7
+ $vm = Get-AzureVM | Out-GridView -Title "Select a VM ..." -PassThru
+       ~~~~~~~~~~~
    + CategoryInfo          : CloseError: (:) [Get-AzureVM]、PipelineStoppedException
    + FullyQualifiedErrorId : Microsoft.WindowsAzure.Commands.ServiceManagement.IaaS.GetAzureVMCommand

Out-GridView : インデックスが範囲を超えています。負でない値で、コレクションのサイズよりも小さくなければなりません。
パラメーター名:index発生場所 行:1 文字:21
+ $vm = Get-AzureVM | Out-GridView -Title "Select a VM ..." -PassThru
+                     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [Out-GridView], ArgumentOutOfRangeException
    + FullyQualifiedErrorId : System.ArgumentOutOfRangeException,Microsoft.PowerShell.Commands.OutGridViewCommand

PS C:\>

・・・あの・・・?

というわけで、当初もくろんでいたPower Shellを4.0にすることで対処できる、というわけではなく
アップデートしても、なんともならない、という救いようのない状態に・・・・

う~ん・・・


2015/07/21追記

githubのissue」にコメントが付いた

It’s a bug in PS 3.0 and 4.0 in that it fails to load the object and/or type info, if TableControl is not correctly configured.

This will be patched on our end for 3.0/4.0 in the incoming release. Stay tune. Thanks.

PowerShell 3.0と4.0におけるバグで、今度のリリースで修正される、とのこと。

Azure上の仮想ディスクを拡張する


このページの内容は「Azure上の仮想マシンのディスク拡張手法 2016年1月版」に置き換わりました。


Azure上にある仮想マシンで使用しているディスクの残り容量が減ってきた。
拡張するための手順を確認すると、一度VHDをダウンロードし、ローカルで拡張操作をした後に、再アップロードする、といったものが出てくる。

そんなバカな、と調べてみたところ、現在はそんなことをしなくてもいようだ。

Resizing Data Disks in the Cloud on Microsoft Azure with Windows PowerShell

Azure Power Shellモジュールのversion 0.8.15.1以降であれば、「Update-AzureDisk」のオプションとして「-ResizedSizeInGB」が追加されており、それを使用することで拡張することができる、とのこと。

ただ、2015/06/01現在、Azureのドキュメントの「Update-AzureDisk」は、version 0.8.10準拠ということで、このオプションが載っておらず、半ば隠しオプションとなってしまっている。

いや・・・ちゃんとしてくれよ・・・

しかも、Windows7で試したところ、Azure PowerShellモジュールを2015/06/01時点での最新ver 0.9.2にしても、このページ記載のコマンドが実行できないという事態も発覚。

「$vm = Get-AzureVM | Out-Gridview -PassThru」が失敗するという・・・

下記の問題と同様のようだ。
Possible breaking change Get-AzureVM breaks pipeline with Out-Gridview (#3047) #13

どうやらPower Shell 3.0では、動かず、Power Shell 4.0にする必要があるらしい。

そして、Power Shellは、Windows Management Framework 4.0に含まれるため
Windows Management Framework 4.0」を導入する必要がある、とのこと。

めんどくさいなぁ・・・・

vRealize Configuration Managerで401 Unauthorizedのエラーがでる


vRealize Configuration Manager v5.7.3.211(旧vCenter Configuration Manager)を設定中、以下のメッセージが表示される場面がいくつかあった。

vcm-001

An error has occurred during report processing.

HTTP ステータス 401: Unauthorized で要求が失敗しました。

エラーの内容としては「SSRS authentication must be configured in two-tier and three-tier installation environments that use Basic authentication (2000082)」にあるものと同じ。

「rsreportserver.config内の認証設定を書き換えろ」とあるけど、既に書き換えてるし、そもそも、うちの環境one-Tier構成だしなぁ・・・と悩む。
あとで分かるんだけど、実は、ここに誤りがありました・・・

で、いろいろ試していった結果、次のblogを発見。

Adventures in a Virtual World:「vCenter Configuration Manager – First Run
同じようにone-tier構成で現象が発生していて、IEの設定を変更して直った、とのこと。

なるほど、と[インターネットオプション]-[セキュリティタブ]にて、「信頼済みサイト」のレベルをカスタマイズ。
「Display mixed contentをEnableにする」というのは日本語だと「混在したコンテンツを表示する、を、有効にする」になる。
vcm-004

が・・・設定しても変わらない。

で・・・もう1度、インストールガイドを読み直したところ、自分が実施した手順に誤りを発見。
one-Tier構成の場合、rsreportserver.configの認証設定の変更は不要、ということ。

・・・最初うまく動かなかったところがあったから、設定したはずなんだけど、と思いつつ、rsreportserver.configの設定を元に戻すと・・・
vcm-005
表示できた・・・

初期設定通りの

<Authentication>
    <AuthenticationTypes>
        <RSWindowsNegotiate/>
        <RSWindowsNTLM/>
    </AuthenticationTypes>

であれば問題なかったという・・・

なぜ、最初はうまく動かなかったんだろうか・・・・

hp ProLiant Gen8サーバのiLOをESXiからアップデートする


VMware ESXiサーバとして動作しているhp ProLiant DL380p Gen8サーバのiLOをアップデートした。

まず、ESXi上から、iLOのバージョンと、iLOに割り当てられているIPアドレスを確認するため「hponcfg」コマンドを実行

/tmp # /opt/hp/tools/hponcfg -g
HP Lights-Out Online Configuration utility

Version 4.4-0 (c) Hewlett-Packard Company, 2014
Firmware Revision = 1.40 Device type = iLO 4 Driver name = hpilo
iLO IP Address: 172.17.15.99
Host Information:
                        Server Name: esxi1.osakana.local
                        Server Serial Number: SGH421XXXX
/tmp #

iLOのアップデータファイル CP025110.scexe を、/tmpに配置し、実行権限を与え、実行。

/tmp # chmod a+x CP025110.scexe
/tmp # ./CP025110.scexe
OS Version found  [5.5.0]
sh: 6.0=./ESXi_5.5: unknown operand
./CP025110.scexe: Okay process the path [./ESXi_5.5 6.0]
sh: 6.0: unknown operand
./CP025110.scexe:  Update flash engine from ./ESXi_5.5 6.0
sh: 6.0/clean_target_location.sh: unknown operand
sh: 6.0/copy_FE_to_target_location.sh: unknown operand
Copy Flash Engine files from [./ESXi_5.5 6.0] to [/tmp/sctmpdir4924713]
cp: './ESXi_5.5' and './ESXi_5.5' are the same file
cp: can't stat '6.0/*': No such file or directory

iLO Flasher v1.0.2-2 for VMware ESXi (Jan  7 2014)
(C) Copyright 2002-2014 Hewlett-Packard Development Company, L.P.
Firmware image: ./ilo4_203.bin
Current iLO 4 firmware version  1.40; Serial number ILOSGH421XXXX

Component XML file: ./CP025110.xml
./CP025110.xml reports firmware version 2.03
This operation will update the firmware on the
iLO 4 in this server with version 2.03.
Continue (y/N)?y
Current firmware is  1.40 (Jan 14 2014 00:00:00)
Firmware image is 0x1001b1c(16784156) bytes
Committing to flash part...
******** DO NOT INTERRUPT! ********
Flashing is underway... 100 percent programmed. \
Succeeded.
***** iLO 4 reboot in progress (may take up to 60 seconds.)
***** Please ignore console messages, if any.
iLO 4 still rebooting. Try again...
iLO 4 reboot completed.
/tmp #

firmwareのバージョンが上がっていることを確認。

/tmp #  /opt/hp/tools/hponcfg -g
HP Lights-Out Online Configuration utility

Version 4.4-0 (c) Hewlett-Packard Company, 2014
Firmware Revision = 2.03 Device type = iLO 4 Driver name = hpilo
iLO IP Address: 0.0.0.0
Host Information:
                        Server Name: esxi1.osakana.local
                        Server Serial Number: SGH421XXXX
/tmp #

・・・と、実行が早すぎたようで、DHCPで割り当てているIPアドレスが「0.0.0.0」となっている。
時間をおいて再実施

/tmp #  /opt/hp/tools/hponcfg -g
HP Lights-Out Online Configuration utility

Version 4.4-0 (c) Hewlett-Packard Company, 2014
Firmware Revision = 2.03 Device type = iLO 4 Driver name = hpilo
iLO IP Address: 172.17.15.99
Host Information:
                        Server Name: esxi1.osakana.local
                        Server Serial Number: SGH421XXXX
/tmp #

これで、問題なしですね。