HA's memo: 2020

2020年12月31日木曜日

Supremicro X11SDV-4C-TP8F購入

X11SDV-4C-TP8Fを購入してしまいました。
今年は家にいる時間が長いからかPCパーツをたくさん買ってしまったなぁ。

TDP 60WのXeon D-2123IT搭載なので省電力を期待していたのですが、結果はいまいちでした。
M2 SSDを一枚、メモリ32GBx2搭載状態で電源OFF時で16W、電源ON後15分程度経過した状態56Wという感じです。
BMCで15Wも消費しています。ASRock Rack X470D4UではBMC消費電力が3.5W程度だったのでかなり大食いな印象です。

X470D4U, X570M Pro4と同様にESXi6.7をインストール後省電力設定、BIOSでも省電力設定を行い、PCIeボード2枚とHDDを8台追加した構成のアイドル状態で80W程度となりました。X470D4U, X570M Pro4では上記に10G NIC(PCIe)を追加した構成で60W程度まで設定できていたので20Wの差です。
BMCの消費電力差12.5Wを引くと7.5W、10Gポートが2つ、SATAポートが4つ増えているのでこんなものかなと言う気がしなくも無いですが…。普段停止しておくにしても待機状態で16W消費とかもったいない感じがします。
BIOSでもう少し設定詰められると良いのですが。

2020年12月28日月曜日

raidz2のST4000DM004をWD40EZRZに交換

今年6月にHDD二台が故障したraidz2(ST4000DM004の8台構成)ですが、scrubを実行したところread failとなるHDDが二台出てしまいました。
うち一台は一時的なものだったようですが、他方は下記の感じでCurrent_Pending_Sector, Offline_Uncorrectableが3桁台に…。 8台中3台が3年未満で故障とは。

# smartctl -A /dev/sdf
smartctl 7.0 2018-12-30 r4883 [x86_64-linux-3.10.0-1160.6.1.el7.x86_64] (local build)
Copyright (C) 2002-18, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF READ SMART DATA SECTION ===
SMART Attributes Data Structure revision number: 10
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000f   059   055   006    Pre-fail  Always       -       10386248
  3 Spin_Up_Time            0x0003   096   096   000    Pre-fail  Always       -       0
  4 Start_Stop_Count        0x0032   100   100   020    Old_age   Always       -       96
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000f   087   060   045    Pre-fail  Always       -       513462226
  9 Power_On_Hours          0x0032   075   075   000    Old_age   Always       -       22634 (210 239 0)
 10 Spin_Retry_Count        0x0013   100   100   097    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   020    Old_age   Always       -       96
183 Runtime_Bad_Block       0x0032   099   099   000    Old_age   Always       -       1
184 End-to-End_Error        0x0032   100   100   099    Old_age   Always       -       0
187 Reported_Uncorrect      0x0032   088   088   000    Old_age   Always       -       12
188 Command_Timeout         0x0032   100   099   000    Old_age   Always       -       2 3 3
189 High_Fly_Writes         0x003a   100   100   000    Old_age   Always       -       0
190 Airflow_Temperature_Cel 0x0022   068   045   040    Old_age   Always       -       32 (Min/Max 27/45)
191 G-Sense_Error_Rate      0x0032   100   100   000    Old_age   Always       -       0
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       935
193 Load_Cycle_Count        0x0032   099   099   000    Old_age   Always       -       2628
194 Temperature_Celsius     0x0022   032   055   000    Old_age   Always       -       32 (0 20 0 0 0)
195 Hardware_ECC_Recovered  0x001a   070   064   000    Old_age   Always       -       10386248
197 Current_Pending_Sector  0x0012   098   098   000    Old_age   Always       -       720
198 Offline_Uncorrectable   0x0010   098   098   000    Old_age   Offline      -       720
199 UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       0
240 Head_Flying_Hours       0x0000   100   253   000    Old_age   Offline      -       21826h+07m+03.803s
241 Total_LBAs_Written      0x0000   100   253   000    Old_age   Offline      -       14648100184
242 Total_LBAs_Read         0x0000   100   253   000    Old_age   Offline      -       28880173058

longtestでもエラーとなり、smartdもsyslogにメッセージを出すようになったので交換しました。
Reallocated_Sector_Ctが0のままなんですが、こう言うものなんでしょうか。
SMARTの情報ってイマイチ見方が分からないんですよね。

さて、前回交換時は多重障害になってしまいましたがresilverに数日かかったので、今回はCMRのものを試そうとWD40EZRZに変えてみました。
たまたまセール中にあたりST4000DM004より安く買えたのでお財布にも優しくラッキーでした。

で、resilverにかかった時間ですが、17時間弱で完了しました。
私の用途ではST4000DM004でも普段使っている時は全く問題ないんですけど、resilverなど長時間書き込みが発生すると影響が出てしまうような感じです。
大容量で安いCMRのHDDって無いんですよね。

# zpool status
  pool: tank
 state: ONLINE
  scan: resilvered 3.27T in 0 days 16:47:29 with 0 errors on Sun Dec 27 03:04:23 2020
config:

        NAME                                                STATE     READ WRITE CKSUM
        tank                                                ONLINE       0     0     0
          raidz2-0                                          ONLINE       0     0     0
            ata-ST4000DM004-2CV104_aaaaaaaa-part1           ONLINE       0     0     0
            ata-ST4000DM004-2CV104_bbbbbbbb-part1           ONLINE       0     0     0
            ata-ST4000DM004-2CV104_cccccccc-part1           ONLINE       0     0     0
            ata-ST4000DM004-2CV104_dddddddd-part1           ONLINE       0     0     0
            ata-ST4000DM004-2CV104_eeeeeeee-part1           ONLINE       0     0     0
            ata-WDC_WD40EZRZ-22GXCB0_WD-ffffffffffff-part1  ONLINE       0     0     0
            ata-ST4000DM004-2CV104_gggggggg-part1           ONLINE       0     0     0
            ata-ST4000DM004-2CV104_hhhhhhhh-part1           ONLINE       0     0     0

errors: No known data errors

2020年12月5日土曜日

送信者アドレスで接続先MTAを変更してSMTPSとSMTP認証を使用する

いくつかのISPのメールアドレスを利用しているのですが、受信はISPの転送設定を利用してVPSのMTAに集め、送信はISPのメールサーバを利用せずにVPSのMTAを経由させて直接配送していました。

MUAでFromアドレス毎にISPのメールサーバを指定するのが面倒なので、このように利用していたのですがDMARCも普及してきているようなので正しくISPのメールサーバを経由させるように設定変更することにしました。

まあ、なりすましメールと同じなので仕方ないですが、SPFの認証結果は気にはなっていたけど面倒なので長年放置していたと言う感じです。
ちなみに独自ドメインについては一応SPF設定はしてありますが、こちらのアドレスでメールを送信することはほとんどありません。

前置きが長くなりましたが、環境と条件は下記になります。

CentOS 8.2
postfix 3.3.1
Envelope FromがISPのメールアドレスの場合は、ISPのメールサーバを経由する。
上記以外のメールアドレスの場合は、直接配送する。
ISPのメールサーバは、SMTP over SSLで認証(SMTP Auth)ありとする。

まずは、/etc/postfix/main.cfに下記の設定を追加します。

sender_dependent_default_transport_maps = hash:/etc/postfix/sender_dependent_transport
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/password_maps
smtp_sasl_security_options = noanonymous

クライアントサイドのSMTP Auth有効化と、送信者アドレスによるtranspot mapの定義を行っています。
次にsmtp_sasl_password_mapsに指定した/etc/postfix/password_mapsを下記の形式で記述します。

[ISPメールサーバ]:ポート  アカウント名:パスワード

ファイルの作成後、postmapコマンドでハッシュファイルを作成します。
password_maps, password_maps.dbはプレーンなパスワード情報を含むため、rootのみ参照可能に設定します。
例えば、下記のようになります。

# cd /etc/postfix
# cat password_maps
[mail.example1.com]:465   foo@example1.com:password1
[mail.example2.com]:465   var@example2.com:password2
#
# postmap hash:password_maps
# chmod og-rxw password_maps*

sender_dependent_default_transport_mapsに設定した/etc/postfix/sender_dependent_transportは下記の形式で記述します。

メールアドレス  relay-smtps:[ISPメールサーバ]:ポート

こちらもファイルの作成後、postmapコマンドでハッシュファイルを作成します。
例えば、下記のようになります。

＃ cat sender_dependent_transport
foo@example1.com  relay-smtps:[mail.example1.com]:465
var@example2.com  relay-smtps:[mail.example2.com]:465
#
# postmap hash:sender_dependent_transport

relay-smtpsサービスを指定しているのがポイントになります。
次に/etc/postfix/master.cfに下記のようにrelay-smtpsサービスを追加します。

relay-smtps unix  -     -       n       -       -       smtp
        -o smtp_tls_security_level=encrypt
        -o smtp_tls_wrappermode=yes

設定後、postfixを再起動すれば完了です。
これで通常は適宜STARTTLSを使用し直接配送、設定したメールアドレスの場合はSMTPS(SMTP over SSL)を使用し各ISP経由で配送するようになります。

最後にsyslogに下記のメッセージを出し認証に失敗する場合は、SMTP Authの認証メカニズムが不足しているのでSASLのパッケージを追加します。

warning: SASL authentication failure: No worthy mechs found

恐らくcyrus-sasl-md5, cyrus-sasl-plainパッケージをインストールすれば解決するはずです。
認証アルゴリズムは、CRAM-MD5, DIGEST-MD5, PLAINがあれば問題ないかと思います。

参考)
Postfix Configuration Parameters: sender_dependent_default_transport_maps
Postfix TLS Support: Sending only mail for a specific destination via SMTPS

iPad Air 4購入

iPad Air 2を愛用してきましたが、iPad Air 4を購入してしまいました。
調べるとiPad Air 2は2014年12月に購入していました。
丸6年毎日使ってきたので一番使い込んだ機器かもしれません。

性能的には全く問題なかったのですが、ストレージが手狭になったのとバッテリーがへたってきたので新モデルを購入しましたが、バッテリー交換してもう少し使ってやればよかったかな…と思わなくもないです。

2020年10月11日日曜日

お名前.comのVPS

DNS、メールサーバとして利用しているVPSで障害が発生していた。
Webの障害情報で復旧完了のアナウンス後も、管理画面でメンテナンス中となり何も操作できない、問合せの回答もないなどイマイチな対応だった。

結局、復旧時刻から4時間程度遅れてサービス再開した感じである。24時間以上のサービス停止、また管理画面からVPSの電源を入れても起動しなかったので中身は空っぽになってしまったようでデータ全損。

DNS/メールサービス自体は、他業者のVPSと冗長構成を組んでいるので影響ないのですがOSからの再構築はかなり面倒くさい。
それにしても障害自体は仕方がないと思うのですが、障害時に正確な情報開示と進捗状況の適宜開示が出来ないのは何故なんですかね。
かなり長期の利用でしたが次回更新はないかな。

2020年8月22日土曜日

fail2ban on CentOS8

先日CentOS8化したメール中継サーバですが、firewalldとipsetをCentOS7のこの記事と同じようにpublic, domesticゾーンを利用するように設定していました。

sshとsmtp-submissionは国内IPのみ許可するように設定したのでそれほどでもないのですが、smtpはIP制限することもできず鬱陶しいアクセスが多く辟易してきたので対処することにしました。

CentOS6の時は、iptablesでルールを書いていたりしましたが今回はfail2banを利用します。
firewall-cmdとipsetを使用する場合は、以下のようになります。

# dnf install fail2ban

# cat << EOF > /etc/fail2ban/jail.local
[DEFAULT]
banaction = firewallcmd-ipset[actiontype=<multiport>]
banaction_allports = firewallcmd-ipset[actiontype=<allports>]

bantime = 604800
findtime = 86400
maxretry = 3

[sshd]
enabled = true

[postfix]
enabled = true
mode = aggressive
maxretry = 2
EOF
#

# cat << EOF > /etc/fail2ban/action.d/firewallcmd-common.local
[Init]
blocktype = DROP
EOF
#

これで、sshdとpostfixの不正アクセス対策が動作します。
動作状況は下記のようにfail2ban-clientコマンドで確認できます。

# fail2ban-client status
Status
|- Number of jail:	2
`- Jail list:	postfix, sshd
#
# fail2ban-client status postfix
Status for the jail: postfix
|- Filter
|  |- Currently failed:	5
|  |- Total failed:	90
|  `- Journal matches:	_SYSTEMD_UNIT=postfix.service
`- Actions
   |- Currently banned:	18
   |- Total banned:	31
   `- Banned IP list:	x.x.x.x y.y.y.y .......
#

nftablesやipsetの定義は下記のように、iptables、ipsetコマンドで確認できます。

# iptables -nL
Chain INPUT (policy ACCEPT)
target     prot opt source               destination
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 22 match-set f2b-sshd src
DROP       tcp  --  0.0.0.0/0            0.0.0.0/0            multiport dports 25,465,587 match-set f2b-postfix src

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
#
# ipset --list --name
f2b-postfix
DOMESTICv4
DOMESTICv6
f2b-sshd
#
# ipset --list f2b-postfix
Name: f2b-postfix
Type: hash:ip
Revision: 4
Header: family inet hashsize 1024 maxelem 65536 timeout 600
Size in memory: 1944
References: 1
Number of entries: 18
Members:
x.x.x.x timeout 342227
y.y.y.y timeout 214654
~
#

f2b-xxxがfail2banで作成されたipsetです。
ipsetのDOMESTICv4は、firewalldのdomesticゾーンに紐づけています。
本サーバでは、IPv6のアドレスをアサインしていないのでDOMESTICv6は未使用です。

上記設定で暫く運用していたのですが、smtpポートアクセスで遮断できないものが多かったのでpostfix用フィルターを下記のように改造してみました。

# cd /etc/fail2ban/filter.d
# diff -uw postfix.conf.original  postfix.conf
--- postfix.conf.original	2020-04-16 21:41:47.000000000 +0900
+++ postfix.conf	2020-08-10 21:45:56.232418891 +0900
@@ -44,9 +44,13 @@
 mdre-extra = %(mdre-auth)s
             %(mdre-normal)s
 
-mdpr-aggressive = (?:%(mdpr-auth)s|%(mdpr-normal)s|%(mdpr-ddos)s)
+mdpr-ddos2 = disconnect from
+mdre-ddos2 = ^unknown\[<HOST>\].+commands=\d/\d
+
+mdpr-aggressive = (?:%(mdpr-auth)s|%(mdpr-normal)s|%(mdpr-ddos)s|%(mdpr-ddos2)s)
 mdre-aggressive = %(mdre-auth2)s
                   %(mdre-normal)s
+                  %(mdre-ddos2)s
 
 mdpr-errors = too many errors after \S+
 mdre-errors = ^from [^[]*\[<HOST>\]%(_port)s$

逆引きが出来ず、かつ必要なコマンドを発行していない接続は大体検知出来ています。
漏れはありますが9割以上遮断できているので一先ず良しとしています。

sshdのアクセス制限については、TCP Wrapperが利用できなくなり不便になりました。
ipsetとhosts.allowを併用して許可IPを絞り込んでいたのですが、良い代替方式が見つかりません。

2020年8月9日日曜日

MikroTik CRS326-24G-2S+IN購入

eurodkで購入。送料込みで＄200以下、発送も速くてとても良い。

MikroTik CRS326-24G-2S+IN : 24 Gigabit ports, 2 SFP+

以前購入したMikroTik CRS309-1G-8S+INと筐体サイズが同じでいい感じです。
「server room power for your home!」とのこと。

postfixのメール中継設定

メール中継サーバで利用しているCentOS6のEOLが迫ってきたので、CentOS8に入れ替えました。その際にpostfixのメール中継サーバ設定で少しはまったのでメモしておきます。

結論から言うと「パラメータのデフォルト値が変わっているのでマニュアルを確認しよう」です。

CentOS8ではpostfix 3.3.1がインストールされますが、compatibility_levelの設定値によりパラメータのデフォルト値が変わります。
postconfの出力からcompatibility_levelを抜き出すと、下記になります。

# postconf | grep compatibility_level
append_dot_mydomain = ${{$compatibility_level} < {1} ? {yes} : {no}}
compatibility_level = 2
mynetworks_style = ${{$compatibility_level} < {2} ? {subnet} : {host}}
relay_domains = ${{$compatibility_level} < {2} ? {$mydestination} : {}}
smtpd_relay_restrictions = ${{$compatibility_level} < {1} ? {} : {permit_mynetworks, permit_sasl_authenticated, defer_unauth_destination}}
smtputf8_enable = ${{$compatibility_level} < {1} ? {no} : {yes}}
#

デフォルトのmain.cfでは、compatibility_levelが2に設定されています。
このためrelay_domainsのデフォルトが空となり、リレーが許可されません。
リレーを許可するには、明示的にrelay_domainsを設定する必要があります。
また、これらパラメータを参照しているパラメータも影響を受けるので注意が必要です。

今回のリプレースでは旧サーバの設定ファイルをコピーせず、デフォルトの設定ファイルから書き直しました。 main.cf内のコメントを読みながら設定していて「The default relay_domains value is $mydestination.」と記載があったため、旧バージョンと同じと考えてしまい、リレーできない原因が分からず暫くはまりました。

マニュアルにはバッチリ記載がありましたので、横着せずマニュアルを確認しようと言うことかと思います。ちなみにcompatibility_levelのデフォルトは0なので、旧サーバの設定をコピーした場合は挙動が変わることはなかったようです。

2020年6月17日水曜日

ASRock Rack X470D4U購入

ESXiで利用しているPC(ASRock X570M Pro4)は、GPUパススルーのVMでwindows 10を使用してデスクトップPCのように使用しようと考えていたのですが、windowsの利用頻度に対して消費電力が高すぎることに気がつきました。大体100W強なので省電力化したい。

BIOSやESXiの設定をいじってみたのですがイマイチ効果がでず、結局GPUを外すことにしました。省電力GPUも検討しましたが、ASRock Rack X470D4Uを購入してしまいました。

マザーボードを入れ替えて大体70W程度、AMDのCPU特性なのか大して負荷をかけなくても消費電力が細かく変動するようです。 70Wから100W位を行き来して、大体70W中位という感じ、60W以下にしたかった。
あとは、VMがほぼアイドル状態でもデータストアには常に書き込みがあるようで、HDDがアイドルにならないことが消費電力に影響しているように思います。8台のHDDが常に書き込み状態となるので。
HDDはデータ置き場にして、データストアはSSDに置きたい気もしますが、安物のSSDだと耐久性が心配、エンタープライズ向けは高すぎて手が出ない。

ちなみに、X470D4Uは国内在庫がなく納期1.5ヶ月以上とのことだったので、amazon.comから買いました。 5日で届いたので国内通販とたいして変わりません。初期不良があると面倒ですが。

2020年6月12日金曜日

10Gbps Network

10GBASE-Tの2ポートスイッチGS110MX-100NASを使用していますが、10Gbps接続を増やしたくなり下記を購入しました。

ラトビアから

MikroTik CRS309-1G-8S+IN : Cloud Router Switch (SFP+ 8port)
MikroTik S+RJ10 : SFP+ RJ45 10Gbps Module

シンセンから

10Gtek X520-10G-2S-X8 : SFP+ 2port, Intel X520-DA2 equivalent
10Gtek XL710-10G-2S-X8 : SFP+ 2port, Intel X710-DA2 equivalent
10Gtek ASF-10G-T : SFP+ RJ45 10Gbps Module

10GBASE-Tの多ポートスイッチはまだ高いので、今回はSFP+で揃えました。
MikroTikと10GtekのそれぞれからSFP+ DAC twinaxケーブルも買いましたが、どちらも問題なく利用できています。
また、10GtekのNICはどちらもESXi 6.7で問題なく認識したので、XL710-10G-2S-X8をESXiで、X520-10G-2S-X8はLinuxで利用予定です。

CRS309-1G-8S+INの電源ランプがすごく眩しいので、テープを貼って使用しています。
何でこんなに強烈な明るさにするのか不思議です。

raidz2のST4000DM004交換

raidz2(ST4000DM004の8台構成)で運用中のHDDが一台、I/Oエラー頻発ということなく突然死という感じで故障しました。
他HDDのSMART情報から大体17740時間で壊れたようです。

予備と交換してresilver中にもう一台壊れました...。
たまたま二台とも故障時にPCの近くにいましたが、どちらも突然カッコン、カッコンと嫌な音を立てたあと鳴り止み御臨終です。
どちらもSMART情報も取れない状態。

まだ、1台目のresilverが完了していない状況ですが、zpool statusで進捗を確認するとDEGRADED状態のHDDが1台発生。
こちらはSMART情報が取れたので確認するとエラーが記録されていました。
何とか完了まで持ち堪えて欲しい。

初ST4000DM004ですが、2年で二台故障、一台エラー発生と耐久性が低いような感じがします。

2020/6/20追記)
一台目のresilver中に全HDDがDEGRADEDステータスになりヒヤッとしましたが、リブート後無事再開することができました。
一台目のresilver完了後に、二台目のHDDを入れ替えresilverを開始しましたが何方も6日程度時間がかかり、およそ12日で復旧となりました。

処理時速度は、resilver開始後に暫くして3桁MB/sになるも、直ぐに70MB/s程度になり徐々に減速し終了間際は52MB/s程度になり非常に低速です。
SMRが原因と思われるので、次に入れ替える時はCMRを選んでみようと思います。 4TBのHDD入れ替えで6日は、厳しいかなと思います。
ちなみに、プールの使用率は90%程度で空きが1.5TB程度ある状態、正常時の書き込みが激遅になっていないので、空き容量としては許容範囲かなと考えています。

Seagate BarraCudaはコスパが良くて気に入っていたのですが、SMRとzfsの相性はやはり悪そうです。
普段利用している時は特に不都合は感じないのですが、resilverの長時間書き込みではデメリットが顕著になるように感じました。

最近組んだPCのHDDもBarraCudaなのでSMRなんですよね、しかも6TBにしてしまいました。

2020年5月16日土曜日

Ascork X570M Pro4のオンボードUSBホストコントローラとUSBポート

ESXi 6.7でAsrock X570M Pro4のオンボードUSBホストコントローラをパススルー利用するため、USBホストコントローラとUSBポートの対応を調べました。

下記、lspciの実行結果。

[root@esxi:~] lspci |grep -i usb
0000:08:00.1 USB controller: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller
0000:08:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller
0000:0d:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller

root@esxi:~] lspci |grep 0000:0[8d]
0000:08:00.0 Non-Essential Instrumentation: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP
0000:08:00.1 USB controller: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller
0000:08:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller
0000:0d:00.0 Non-Essential Instrumentation: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Reserved SPP
0000:0d:00.1 Encryption controller: Advanced Micro Devices, Inc. [AMD] Starship/Matisse Cryptographic Coprocessor PSPCPP
0000:0d:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller
0000:0d:00.4 Audio device: Advanced Micro Devices, Inc. [AMD] Starship/Matisse HD Audio Controller

PCIとUSBポートの対応は下記になります。

0000:08:00.1 マザーボード上のUSB2ヘッダ
0000:08:00.3 下図リアパネルの赤枠＋マザーボード上のUSB3ヘッダ
0000:0d:00.3 下図リアパネルの青枠

リアパネル (画像はAsrockのX570M Pro4の製品ページより)

2020年5月14日木曜日

ESXi 6.7でオンボードUSBホストコントローラのパススルー

Asrock X570M Pro4のオンボードUSBホストコントローラをESXi 6.7でPCIパススルーできました。

当初、PCIパススルー設定をして仮想マシンを起動すると、下記メッセージが表示されパワーオンに失敗していました。

モジュール「DevicePowerOn」のパワーオンに失敗しました。
ハードウェアまたはソフトウェアのサポートが使用できないため、デバイス pciPassthru0 の 13:0.3 への登録に失敗しました。
仮想マシンの起動に失敗しました。

この時に仮想マシンのログ(vmware.log)には、次の記録が残っていました。

vmx| I125: PCIPassthru: Failed to register device 0000:0d:00.3  error = 0xffffffff
vmx| I125: Msg_Post: Error
vmx| I125: [msg.pciPassthru.createAdapterFailedPlatformNotSupported] Failed to register the device pciPassthru0 for 013:00.3 due to unavailable hardware or software support.
vmx| I125: ----------------------------------------
vmx| I125: Module 'DevicePowerOn' power on failed.

vmkernel.logには、次の記録がありました。

cpu10:2100020)WARNING: PCI: 384: Dev @ 0000:0d:00.3 did not complete its pending transactions prior to being reset; will apply the reset anyway but this may cause PCI errors
cpu7:2100020)WARNING: PCI: 471: Dev 0000:0d:00.3 is unresponsive after reset

ふと、リセット設定をすれば上手くいくのでは？と思い試したところうまく行きました。

リセット設定は、ESXiの/etc/vmware/passthru.mapに記述するようです。
フォーマットの説明はファイルの初めの方に記載されていますが、vendor-id device-id resetMethod fptShareableの順で記述します。

vendor-idとdevice-idは、次のようにlspciで調べることができます。

[root@esxi:~] lspci |grep -i usb
0000:08:00.1 USB controller: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller 
0000:08:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller 
0000:0d:00.3 USB controller: Advanced Micro Devices, Inc. [AMD] Matisse USB 3.0 Host Controller 

[root@esxi:~] lspci -n |grep -E '0000:0(8:00.[13]|d:00.3)'
0000:08:00.1 Class 0c03: 1022:149c 
0000:08:00.3 Class 0c03: 1022:149c 
0000:0d:00.3 Class 0c03: 1022:149c

上記からvendor-idが1022、device-idが149cとなります。ファイル内の他デバイスの記載を参考にresetMethodをd3d0、fptShareableはdefaultで指定しました。

[root@esxi:~] tail -2 /etc/vmware/passthru.map 
# AMD USB host controller
1022  149c  d3d0     default

この設定で0000:0d:00.3のコントローラはPCIパススルーで利用できるようになりました。
仮想マシンも問題なく起動します。

また、0000:08:00.1と0000:08:00.3は、PCIデバイスの設定でパススルーをアクティブにできなかったのですが、上記調査中にvmkernel.logに下記を見つけました。

0:00:00:04.808 cpu0:2097152)PCI: 1305: Found a PCIe-to-PCIe bridge at 0000:00:08.1                        
0:00:00:04.808 cpu0:2097152)PCI: 423: 0000:00:08.1: PCIe v2 PCI Express Root Complex Port                 
0:00:00:04.808 cpu0:2097152)PCI: 427: Not a ACS capable device                                            
0:00:00:04.808 cpu0:2097152)PCI: 488: 0000:00:08.2: PCIe v2 PCI Express Root Complex Port                 
0:00:00:04.808 cpu0:2097152)PCI: 248: 0000:00:08.2: Found support for extended capability 0xb (Vendor Spec
0:00:00:04.808 cpu0:2097152)PCI: 248: 0000:00:08.2: Found support for extended capability 0x19 (Secondary 
0:00:00:04.808 cpu0:2097152)PCI: 248: 0000:00:08.2: Found support for extended capability 0x25 (Data Link 
0:00:00:04.808 cpu0:2097152)PCI: 248: 0000:00:08.2: Found support for extended capability 0x26 (Physical L
0:00:00:04.808 cpu0:2097152)PCI: 248: 0000:00:08.2: Found support for extended capability 0x27 (Lane Margi
0:00:00:04.808 cpu0:2097152)PCI: 1305: Found a PCIe-to-PCIe bridge at 0000:00:08.2                        
0:00:00:04.808 cpu0:2097152)PCI: 423: 0000:00:08.2: PCIe v2 PCI Express Root Complex Port                 
0:00:00:04.808 cpu0:2097152)PCI: 427: Not a ACS capable device                                            
0:00:00:04.808 cpu0:2097152)PCI: 488: 0000:00:08.3: PCIe v2 PCI Express Root Complex Port                 
0:00:00:04.808 cpu0:2097152)PCI: 248: 0000:00:08.3: Found support for extended capability 0xb (Vendor Spec
0:00:00:04.808 cpu0:2097152)PCI: 248: 0000:00:08.3: Found support for extended capability 0x19 (Secondary 
0:00:00:04.808 cpu0:2097152)PCI: 248: 0000:00:08.3: Found support for extended capability 0x25 (Data Link 
0:00:00:04.808 cpu0:2097152)PCI: 248: 0000:00:08.3: Found support for extended capability 0x26 (Physical L
0:00:00:04.808 cpu0:2097152)PCI: 248: 0000:00:08.3: Found support for extended capability 0x27 (Lane Margi
0:00:00:04.808 cpu0:2097152)PCI: 1305: Found a PCIe-to-PCIe bridge at 0000:00:08.3                        
0:00:00:04.808 cpu0:2097152)PCI: 423: 0000:00:08.3: PCIe v2 PCI Express Root Complex Port                 
0:00:00:04.808 cpu0:2097152)PCI: 427: Not a ACS capable device

「Not a ACS capable device」とあるので、ACSを無効化すれば動作するようです。
試しに、ESXiのシステム>詳細設定でVMkernel.Boot.disableACSCheckをtrueに設定したところアクティブにでき、それぞれ仮想マシンからも利用できました。

参考URL
vSphere VMDirectPath I/O and Dynamic DirectPath I/O: Requirements for Platforms and Devices (2142307)

2020年5月6日水曜日

ESXi 6.7でPT3をPCIパススルー

ひとまず静音対策は置いておき、TV録画環境が移行できるか確認することにします。

Linux VM上でPT3を動作させるためESXiでPCIパススルー設定をしたのですが、リブート後も「有効/再起動が必要」と表示されたままアクティブになりません。
何か対処が必要なんだろうかと、VMKernel logを確認すると下記ワーニングが記録されていました。

cpu8:2097649)WARNING: PCIPassthru: PCIPassthruAllowed:175: Device passthru not possible on this system (no PCI ACS support)
cpu8:2097649)PCIPassthru: PCIPassthruAttachDev:217: Passthru not possible on device 0000:05:00.0

ログメッセージが若干異なりますが、VMware KBにある PCI Passthrough with PCIe devices behind a non-ACS switch in vSphere (1036811) が原因のようです。
PCIのAccess Control Services(ACS)を有効にする必要があるとのこと。

BIOSで設定すればいいだろうと確認したのですが、これがなかかな分かりにくい仕様でした。
デフォルト状態だとACS設定が非表示で、AER Capを有効にするとACS設定が出現するという分かり難さ。
ACS設定の説明欄には、AER Cap設定に依存する旨の記述がありましたが、そもそも表示されてなければ設定自体があるのかどうか分からないような...。
Advanced Error Reporting (AER) capabilityとACSの関係ってよく知られているものなのかな？

ASRock X570M Pro4では、下記BIOS設定でPT3をPCIパススルーで有効化できるようになります。もちろんIOMMUは有効にしておく必要があります。

Advanced > AMD CBS > NBIO Common Options > Enable AER Cap : Enabled
Advanced > AMD CBS > NBIO Common Options > ACS Enalbed: Auto (AER有効化後のデフォルトのまま)

安定性は追々確認するとして、取り敢えずVMでPT3を利用できることは確認できました。

ちなみにカードリーダーはUSBパススルーで利用しています。
オンボードのUSBホストコントローラをPCIパススルーしてVMでUSBキーボードを利用したかったのですが、動作させることが出来ませんでした。

2020年5月4日月曜日

FreeNAS on ESXi

FreeNASは、下記リソースのVMにインストールしました。

vCPU: 2
memory: 16GB
HDD: 32GB (ローカルデータストア)
HDD: RDM Disk x8
NIC: VMXNET3 x2

インストールは特に問題なく完了。
プールは、RDMしたHDD8台で作成し問題なく動作したのですが...。
煩い、シーク音がとても煩い。
FreeNAS単体で動作させた状態でも何か書き込みをしているらしく、数秒毎にシーク音がします。

SeagateのHDDは、ST3000MD002, ST3000MD007, ST4000DM004をそれなりの数を利用してきたのですが、シーク音が煩いと感じたことがありませんでした。

今回のPCは、 2年に組んだPCと同型のPCケースを使っているのでケースの静音性は同一で比較しやすく、並べて聴き比べるとST4000DM004が「ククククク」、ST6000DM003は「ピリピリピリパリパリ」という感じで高音で耳障りな音がし、音量も大きいように思います。
音を文字で表現するのは難しいのですが雰囲気は伝わりますかね？

BarraCuda 3.5 HDDの仕様書にあるマニュアルを確認すると3TB,4TBモデルと6TBモデルでは、ディスク数が異なるようなのでこの影響だろうか？
いずれにしても、これでは現行PCのリプレースとして居室で24H稼動は厳しいかもしれない。
他HDDを試すとしたらコスト的にWesternDigitalのWD60EZAZ-RTあたりだけど、うーん。

FreeNASの定期的な書き込みについては、レポート情報の書き込みらしく、System > System DatasetのSystem Dataset Poolを変更すれば出力先を変更できるようです。
とりあえず、HDDのプールではなくfreenas-bootに変更したところ、FreeNAS単体動作時のHDDシーク音はしなくなりました。まあ、freenas-bootだとブートディスク(SSD)に書き込むことになるので、別な意味で心配な感じではあります。

RDM on ESXi 6.7

ESXi 6.7は、次の構成を考えています。

FreeNAS(VM)をESXiのローカルデータストアから起動する。
FreeNASは、iSCSIかNFSでHDD領域を公開する。
ESXiは、FreeNASの領域をデータストアとして利用する。
その他VMは、FreeNASのデータストアから起動する。

伝わるだろうか？簡単な図にするとこんな感じになります。

+ESXi 
|
+SSD==datastore(local)==+FreeNAS
|                       |
+HDD==(RDM)=============+datastore(iSCSI or NFS)+VM1
                                                +VM2
                                                +VM3

ESXiとFreeNASは、USBデバイスからの起動も可能でサイズも小さいため冗長化していないNVMe SSDから起動させても障害時の対応が容易だろうとの考えです。
設定情報を保存しておけば、再インストールが必要になっても大した手間をかけず復旧できるかなと考えています。

HDDはZFSで利用したい。FreeBSDやLinuxでZFSを利用してもいいのですが、せっかくVMにするのなら用途を絞って楽に管理したとの思いからFreeNASを利用することにしました。FreeNASは初めて使いますがFreeBSDベースなので問題ないかなと思っています。

で、特にハマることなく構築できました。
RDM(Raw Device Mapping)の設定についてメモしておきます。
RDMはVMware Host Clientだけでは設定できないようで、ESXiにsshログインしvmkfstoolsコマンド操作が必要でした。

まず、HDDのデバイス名を調べます。

$ ls /vmfs/devices/disks/*ATA* 
/vmfs/devices/disks/t10.ATA_____ST6000DM0032D2CY186__________________________________WCTaaaaa
/vmfs/devices/disks/t10.ATA_____ST6000DM0032D2CY186__________________________________WCTbbbbb
/vmfs/devices/disks/t10.ATA_____ST6000DM0032D2CY186__________________________________WCTccccc
/vmfs/devices/disks/t10.ATA_____ST6000DM0032D2CY186__________________________________WCTddddd
/vmfs/devices/disks/t10.ATA_____ST6000DM0032D2CY186__________________________________WCTeeeee
/vmfs/devices/disks/t10.ATA_____ST6000DM0032D2CY186__________________________________WCTfffff
/vmfs/devices/disks/t10.ATA_____ST6000DM0032D2CY186__________________________________WCTggggg
/vmfs/devices/disks/t10.ATA_____ST6000DM0032D2CY186__________________________________WCThhhhh
$

名前が長いですね。ファイル名の末尾がシリアル番号のようです。

次に適当なディレクトリを作成し、vmkfstoolsでRDMを作成します。
RDMには仮想互換モードと物理互換モードがあるようですが、今回は物理互換モードで設定します。
仮想互換モードでは、スナップショットなども利用できるようです。
最後の引数のファイル名は何でもいいのですが、シリアル番号が分かるようにしておくとメンテナンスが楽になるかもしれません。

$ mkdir rdm
$ cd rdm
$ vmkfstools -z /vmfs/devices/disks/t10.ATA_____ST6000DM0032D2CY186__________________________________WCTaaaaa ST6000DM0032D2CY186_WCTaaaaa.vmdk
$ vmkfstools -z /vmfs/devices/disks/t10.ATA_____ST6000DM0032D2CY186__________________________________WCTbbbbb ST6000DM0032D2CY186_WCTbbbbb.vmdk
$ vmkfstools -z /vmfs/devices/disks/t10.ATA_____ST6000DM0032D2CY186__________________________________WCTccccc ST6000DM0032D2CY186_WCTccccc.vmdk
$ vmkfstools -z /vmfs/devices/disks/t10.ATA_____ST6000DM0032D2CY186__________________________________WCTddddd ST6000DM0032D2CY186_WCTddddd.vmdk
$ vmkfstools -z /vmfs/devices/disks/t10.ATA_____ST6000DM0032D2CY186__________________________________WCTeeeee ST6000DM0032D2CY186_WCTeeeee.vmdk
$ vmkfstools -z /vmfs/devices/disks/t10.ATA_____ST6000DM0032D2CY186__________________________________WCTfffff ST6000DM0032D2CY186_WCTfffff.vmdk
$ vmkfstools -z /vmfs/devices/disks/t10.ATA_____ST6000DM0032D2CY186__________________________________WCTggggg ST6000DM0032D2CY186_WCTggggg.vmdk
$ vmkfstools -z /vmfs/devices/disks/t10.ATA_____ST6000DM0032D2CY186__________________________________WCThhhhh ST6000DM0032D2CY186_WCThhhhh.vmdk
$

成功するとファイル名に「-rdmp」がついたファイルが増えていました。

$ ls -1
ST6000DM0032D2CY186_WCTaaaaa-rdmp.vmdk
ST6000DM0032D2CY186_WCTaaaaa.vmdk
ST6000DM0032D2CY186_WCTbbbbb-rdmp.vmdk
ST6000DM0032D2CY186_WCTbbbbb.vmdk
ST6000DM0032D2CY186_WCTccccc-rdmp.vmdk
ST6000DM0032D2CY186_WCTccccc.vmdk
ST6000DM0032D2CY186_WCTddddd-rdmp.vmdk
ST6000DM0032D2CY186_WCTddddd.vmdk
ST6000DM0032D2CY186_WCTeeeee-rdmp.vmdk
ST6000DM0032D2CY186_WCTeeeee.vmdk
ST6000DM0032D2CY186_WCTfffff-rdmp.vmdk
ST6000DM0032D2CY186_WCTfffff.vmdk
ST6000DM0032D2CY186_WCTggggg-rdmp.vmdk
ST6000DM0032D2CY186_WCTggggg.vmdk
ST6000DM0032D2CY186_WCThhhhh-rdmp.vmdk
ST6000DM0032D2CY186_WCThhhhh.vmdk
$

ここまでくればVMware Host Clientで仮想マシンの編集>ハードディスクの追加でvmdkファイルを選択できるようになります。

下記参照URL
vmkfstools コマンドのオプション
物理互換モードの Raw デバイスマッピングの作成
RDM の仮想および物理互換モード

2020年5月3日日曜日

SyntaxHighlighterが動かなくなっていた

しばらく更新していなかったので気がつきませんでしたが、SyntaxHighlighterが上手く動かなくなっていました。

オリジナルサイトのhostingを利用させてもらっていたのですが、shBrushPerl.jsがNot Foundになっていました。どうもhttpsにリダイレクトされた先にファイルがない感じ。

下記CDNでも提供されているようなので、こちらを利用させてもらうことにしました。

https://cdnjs.com/libraries/SyntaxHighlighter

Bloggerの「テーマ> HTMLの編集」で該当URLを修正して対応完了。ついでにHTTPSリダイレクトも有効にしておきました。

2020年5月2日土曜日

Transcend PCIe SSD200SはESXi 6.7で認識されない

NVMe SSDにESXi 6.7をインストールしようとしたのですが、Transcend PCIe SSD200Sはディスクとして認識されませんでした。
コスパでパーツを選択したので、ESXiで利用できるかどうかは調査していませんでした…。

仕方がないのでUSBメモリにインストール後確認すると、PCIデバイスとしては認識されているようです。
NVMeドライバについて調べてみると、Crucial NVMe SSDがESXiのアップグレードで認識されなくなると情報があったので試してみるとディスクとして認識させることができました。

Quick Tip – Crucial NVMe SSD not recognized by ESXi 6.7

ESXi6.5 Update2のドライバを利用すれば良いようなので、ESXi650-201905001の1.2.1.34-1vmw.650.2.50.8294253を利用すると認識されるようになります。
パッチの内容を確認するとESXi650-201912002からドライバが変更になっているようでした。

ESXi650-201905001

vib20/nvme/VMW_bootbank_nvme_1.2.1.34-1vmw.650.2.50.8294253.vib

ESXi650-201912002

vib20/nvme/VMW_bootbank_nvme_1.2.2.28-1vmw.650.3.96.13932383.vib

しばらくUSBブートで利用していましたが、ブートデバイスをSSDにしたかったのでIntel SSD 760pを買い足してしまいました。
パッチ当てが面倒なので、SSD200SはRDMで利用することにします。

2020年4月30日木曜日

新PC

先日、検証用として使っていたHP ProLiant ML110 G7の電源が入らない状態になってしまいました。
最近も問題なくWindows Server評価版を試したりしていたので、電源かな？と思い電源を交換してみましたが治らず、残念ながらハードウェアの知識がないためお手上げ。とうとう壊れたか。

検証環境がないと少し不便なので、下記構成でPCを作りました。

ASRock X570M Pro4
AMD Ryzen5 3600
DDR4-2666 32GB x2
Seagate ST6000DM003 x8
M2.SSD Transcend TS512GMTE220S x1
M2.SSD Intel SSD 760p SSDPEKKW256G8XT x1
MSI GeForce GTX1060 ARMOR 6G

GPUはそこらにあったものを流用。Intel SSD 760pは、ESXiのインストーラーがTranscendのSSDを認識しなかったので後から追加しています。

現在KVMで運用しているVMを巻き取り、検証環境を含めた仮想環境をESXiで作ろうと目論んでいるのですが...。

登録: 投稿 (Atom)