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」を導入する必要がある、とのこと。

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

ワークグループ設定のWindowsでは管理共有にアクセスできるのは「Administrator」だけ


Windowsがドメイン参加ではなく、ワークグループ設定である場合、そのホストの管理共有「ADMIN$」に対してアクセスできるのは、ローカルの「Administrator」ユーザのみとなっているようです。
「Administrator」という文字列以外のユーザが管理者とは認められていません。

別の管理用ユーザ(たとえばmachineadmユーザ)を作成し、管理者権限(Administratorsグループに参加)を与え、「Administrator」ユーザを無効化してしまった場合、ネットワーク越しで管理共有「ADMIN$」にアクセスできるユーザがいなくなってしまいます。

回避するには、UACを無効化する必要があります。
無効化することによって、Administrator以外のユーザ名を持つ管理者ユーザであっても管理共有「ADMIN$」に対してアクセスできるようになります。

このUAC無効化の操作ですが、Windows Server 2008R2の場合は、コントロールパネルから行って問題ありません。
しかし、Windows Server 2012の場合、コントロールパネルから設定を行ってもこの操作ができるようにはなりませんでした。

インフラSEの設定・構築メモ「[Windows] 管理共有 (C$, D$など) にビルトイン administrator 以外は接続できない

上記にあるようにレジストリを変更する必要がありました。
「HKLM¥SOFTWARE¥Microsoft¥Windows¥CurrentVersion¥Policies¥System」内のDWORD「EnableLUA」の値を「1」→「0」として再起動するか
「HKLM¥SOFTWARE¥Microsoft¥Windows¥CurrentVersion¥Policies¥System」内にDWORDで「LocalAccountTokenFilterPolicy」を作成し、値を「0」として再起動

Microsoftのオフィシャル記述としては全体的な解説を「Windows Server でユーザー アカウント制御 (UAC) を無効にする方法」(英語版)で行い、実際の設定内容についてはKB951016「Windows Vista でのユーザー アカウント制御とリモート制限の説明」(英語版 How to change the Remote UAC LocalAccountTokenFilterPolicy registry setting in a Windows Vista image)で説明しています。

全体的な解説にあるようにLocalAccountTokenFilterPolicyの設定変更はセキュリティ的なリスクがあるものとなりますので、注意が必要です。

なお、この制約は、ワークグループ設定のみです。
Active Directory参加(ドメイン参加)の場合は、この制約がありません。

ジャンクでDynaBook RX3 TM240Eを手に入れたのでWin10TPを入れた



秋葉原のジャンク屋をまわっていたら Core i5-520M(2.4GHz)搭載のDynaBook RX3 TM240Eが1万円、という値段で転がっていた。

CPU Core i5-520M(2.4GHz)
メモリ 2GB
HDD 160GB
13.3インチ液晶 1366×768
(DVDは内蔵されていないモデル)

と、十分なスペック。

「ジャンク」扱いとなっている理由のマイナスポイントとしては
・液晶に色むらがある
・キーボード入力が入りにくい
・キートップが一部はげている
・Win7Proのプロダクトシールがあるんだけど、読めない
と書かれていたものの、電源を入れてみることができ、BIOS表示できたし、そのレベルだとおかしな表示も無いし、外見もキートップ以外はまぁ普通なので、いいかなぁ、と買ってみた。

Windows10TPを入れてみたところ
・色むらは大したことない
・指紋認証デバイス以外は認識できる
・キーボード入力のうち「U」「I」が入りにくい。特に「I」
・ドラクエXを動かしていると、15分ぐらいすると画面が乱れ、ハングアップする
・ハングアップ後、しばらくは電源が入らない。
という状況であることが分かった。

キーボードについては探してみると3千円ぐらいで入手できることが判明。

ハングアップについては、高負荷になると駄目なのかな?とBIOS設定で、Turbo Boost機能オフ、CPUもLow設定にしてみると、ハングアップをしなくなった。

足らないドライバについては東芝ページを捜索。

まず、DynaBook RX3は企業向けモデル。
一般(コンシューマ)向けモデル名だとDynaBook R730。
また、筐体は同じの後継機 DynaBook R731になるようだ。

Windows8.1アップデートに関係するページを見ても、この世代だと無いようで、一番近そうなの「dynabook R632/H、R632/Gシリーズ用 Windows 8.1 アップデートモジュール」が使えそうなので、そこからいろいろ試して見ると、指紋認証デバイスのほかにもいくつかアップデートできるものを発見できた。

TOSHIBA Fingerprint Utility
※指紋センサー搭載モデルのみ 【Windows 8.1アップデート用】
(version 2.0.0004.00404)
 → win10tp標準:ドライバなし からドライバが適用された

Synaptics Touch Pad Driver 【Windows 8.1アップデート用】(version 17.0.9.1)
 → win10tp標準:PS/2標準マウス からアップデートできた

Atheros Wireless LAN Driver
※Atheros無線LANモデルのみ 【Windows 8.1アップデート用】
(version 10.0.0.263)
 → win10tp標準:3.0.2.170 からアップデートできた

Intel Display Driver 【Windows 8.1アップデート用】(version 9.17.10.3223/10.18.10.3308)
win10tp標準:8.15.10.2900
 → 適用されない?

Intel Management Engine Interface
※vPro非対応モデルのみ 【Windows 8.1アップデート用】
(version 9.5.13.1706)
win10tp標準:6.0.0.1179
 → これは適用できない。(unsupported device)

TOSHIBA System Driver 【Windows 8.1アップデート用】 (version 1.00.0032)
 → 入れてはみたものの、何が更新されたのかわからなかった・・・。

TOSHIBA Function Key 【Windows 8.1アップデート用】 (version 1.1.0002.01)
 → これを入れると、WiFi ON/OFFキーなどが使えるようになる。
  Fnキー周りの設定を一部変更することができる。

東芝サービスステーション
※Ver.2.6.8へアップデート済みの場合は必要ありません 【Windows 8.1アップデート用】
(version 2.6.8)
 → 東芝からのお知らせを表示するだけだったので、入れる必要が無かった。