ソフトウェア」カテゴリーアーカイブ

CentOS から Fedora に直接アップグレードしてみる

どうも、みむらです。

気がついたら 2022 年になっていましたし、オリンピックも終わっていました。
年が進むのは早いものですね。

同じく年が早いと気づかされたものとして、CentOS Linux 8 のサポート切れがあります。

CentOS Stream 8 にアップグレードしましょう、という話もありますが、
“Stream” は RHEL の “Nightly” の立ち位置になっていますし、
今までのRHEL 互換を求めるなら、Alma Linux Rocky Linux に切替えていくのが正しいように見えます。

Fedora/CentOS Stream/CentOS/RHELの関係性 – 赤帽エンジニアリングブログ
https://rheb.hatenablog.com/entry/202007-fedora-distribution

GitHub の CentOS などから Alma Linux に移行するためのツール (Almalinux-deploy):
https://github.com/AlmaLinux/almalinux-deploy

上記の移行ツールの使用について日本語で書かれた記事:
https://www.server-memo.net/memo/centos8_to_almalinux.html

他方、 CentOS Stream 9 からミラーが変わるようで、
執筆時点 (2022/01/17) では日本のサーバがなく寂しい所でもあります。

CentOS Stream 9 Mirror list:
https://admin.fedoraproject.org/mirrormanager/mirrors/CentOS

今実験用に稼働させているサーバのひとつが CentOS なのですが、
実験用ですし CentOS Stream が “Nightly” の立場に変わるのであれば、
更に上流の Fedora にアップグレード出来るのではないか・・と試してみました。


注意:
下記の手法を試したことにより生じた損害や被害などは当方では全く関知しません。
また、公式ではない方法かつ危険が伴う可能性もあるため、バックアップ等を取り、リスクを取ることが出来る環境でのみお試しください。


続きを読む

Jumbo Frame + WinServer 2019 の Hyper-V の通信は妙に遅い。

どうもみむらです。
最近梅雨に入ったのか夏に入ったのか、色々パッとしなくて困る日々が続いております。

先日 Windows Server 2019 (もしくは Hyper-V Server 2019) を Jumbo Frame 環境下で用いると、通信が遅くなるということが分かりましたのでメモがてら。
同じような問題に遭遇した方の一助のとなればありがたいです。


事象:

Windows Server 2019 上の Hyper-V に展開された VM において
RSC (Receive Side Coalescing, Linux では Large Receive Offload で知られている) が有効
かつ VM が Jumbo Frame の環境において、VMから見て受信方向の通信が遅くなる。

注1:Windows Server 2019 では RSC は既定で有効になっています。
注2:MTU が 2850 bytes を上回る ( >2850 ) 場合に速度低下が発生するようです。

原因:

VMSwitch において Reassemble されたパケットが VMに届かなくなる。

回避方法:

RSC を無効にするか MTU を 1500 にする

方法1:ゲスト VM の MTU を 1500 にする。
 例) ip l set mtu 1500 dev eth0

方法2:ホスト側でRSC 機能を VMSwitch 単位で無効にする
 例)Set-VMSwitch (Switch名) -EnableSoftwareRsc $false

方法3:ゲストVM において ethtool 等を用いて “large-receive-offload” を off にする
 Linux) ethtool -K eth0 large-receive-offload off
 Windows) Set-NetAdapterAdvancedProperty “*” -DisplayName “Recv Segment Coalescing” -RegistryValue 0


パケットの気持ちになってみる

最近パケットの気持ちになる、が一部界隈で有名ですので「なってみよう」と思います。

ざっくりと構成は下記の通り。
Hyper-V サーバ内に立てられた VM-01 との通信について Hyper-V サーバの前段のミラー (CAP-01) と VMSwitch のミラー (CAP-02) で通信をキャプチャして挙動を確認しよう、という構成になっています。

なお、各キャプチャは同タイミングでのものではありません。ご了承ください


VM-01 での curl での速度比較

事象を確認するためにまずは curl で適当な通信を発生させて速度を見てみます。

MTU 1500 の場合は Average Speed が 10.7M となっているのに対し
MTU 9000 の場合は Average Speed が 44024 となっています。


MTU 9000 の時の VM-01 のキャプチャ

上記のようになります。

No. 12 において Seq=141, Ack=1409 をサーバに対して返答していますが
その次にやってきたパケット (No.13) は Seq=16897 になっています。
(通常は直前の Ack と同じ番号の Seq が返ってきます)

そのため No.14 において Ack=1409 を再度送信され、
サーバ側からは No.16 において Seq=1409 の返答(再送)が起きてしまっています。


MTU9000 の時の CAP-02 のキャプチャ

上記のようになります。
No. 13 までは先ほどの VM-01 と同じような流れになっています。

ですが No.14 付近から 1474 bytes ではないパケットが流れはじめます。
またそれを境にして、 Ack と Seq の関係が壊れはじめるのも確認が出来ます。

たとえば No.14 は Seq=1409 として 2882 bytes の通信が行われていますが
その後の ACK (No.16) では Ack=1409 として返答が行われていることが分かり、
通信が正常に行われていないことがここから読み取れます。

またこの 1475 bytes でないパケットについては先述の VM-01 のキャプチャにおいては確認出来ず、その後発生した No.25 の Ack に対する No.26 の 1474 bytes の通信が行われて初めて VM-01 側にパケットが到達しているように見受けられます。


MTU9000 の時の CAP-01 のキャプチャ

上記のようになります。

インターネットを介して No.10 ~ No.19 に掛けて勢いよく通信が行われていますが
その後 No.20 において Ack=1 が返され、No.23 において再送が行われています。

この間 Seq は 12673 まで増えており、この No.19 に当該するパケットは先述の CAP-02 においても No.21 として観測できているように見受けられます。


以上の事象、また CAP-02 においてパケットをとり続けると、 reassemble されたパケットが送信された後に再送要求が発生していること、そして RSC を Disable にするとこれらの事象が解決することから RSC (LRO) が原因と判断しました。

また繰り返しではありますが、
Windows Server 2022 (Preview) や Windows 10 (21H1) では発生しないことを確認していますので Windows Server 2019 特有の問題 ( 1809 ベースの Hyper-V 特有? ) と判断しています。


番外:ドライバベースで治せないかやってみる

Linux のドライバは自由に修正したりして実験できますので、
これで何か出来ないかやってみます。

1.そもそも機能を切る:

netvsc の 603 行目に下記のような記述があります
https://github.com/torvalds/linux/blob/master/drivers/net/hyperv/netvsc.c#L603

/* Negotiate NVSP protocol version */
static int negotiate_nvsp_ver(struct hv_device *device,
			      struct netvsc_device *net_device,
			      struct nvsp_message *init_packet,
			      u32 nvsp_ver)
{

/// 省略 ///

	if (nvsp_ver >= NVSP_PROTOCOL_VERSION_61)
		init_packet->msg.v2_msg.send_ndis_config.capability.rsc = 1;

/// 省略 ///

	return ret;
}

この nvsp_ver で Windows Server 2019 とそれ以降の区別を試みましたが
共に NVSP_PROTOCOL_VERSION_61 (0x60001) が返るため、区別は出来ませんでした。

もちろんですが、”init_packet->msg.v2_msg.send_ndis_config.capability.rsc = 0;” とすると RSC の機能が恒久的に無効になります。


2.別パラメータから値を推測する等で値を修正する:

こちらですが、そもそも VMBus 経由での VMQ の割込が来ないため
修正は難しいという形になりました。

Hyper-V のネットワーク通信は下記のようなアーキテクチャになっています。

vmq コンポーネント

引用元 : https://docs.microsoft.com/ja-jp/windows-hardware/drivers/network/vmq-components

親(ホスト)が持つ NetVSP (VMSwitch) に対して VMBus 経由で接続するアーキテクチャになっており、Linux の netvsc ドライバにおいても 1665 行目付近でその接続が行われていることが伺えます。

struct netvsc_device *netvsc_device_add(struct hv_device *device,
				const struct netvsc_device_info *device_info)
{

/// 省略 ///

	/* Enable NAPI handler before init callbacks */
	netif_napi_add(ndev, &net_device->chan_table[0].napi,
		       netvsc_poll, NAPI_POLL_WEIGHT);

	/* Open the channel */
	device->channel->rqstor_size = netvsc_rqstor_size(netvsc_ring_bytes);
	ret = vmbus_open(device->channel, netvsc_ring_bytes,
			 netvsc_ring_bytes,  NULL, 0,
			 netvsc_channel_cb, net_device->chan_table);

	if (ret != 0) {
		netdev_err(ndev, "unable to open channel: %d\n", ret);
		goto cleanup;
	}

	/* Channel is opened */
	netdev_dbg(ndev, "hv_netvsc channel opened successfully\n");

	napi_enable(&net_device->chan_table[0].napi);

	/* Connect with the NetVsp */
	ret = netvsc_connect_vsp(device, net_device, device_info);
	if (ret != 0) {
		netdev_err(ndev,
			"unable to connect to NetVSP - %d\n", ret);
		goto close;
	}

/// 省略 ///

}

https://github.com/torvalds/linux/blob/9d31d2338950293ec19d9b095fbaa9030899dcb4/drivers/net/hyperv/netvsc.c#L1648


試しに netvsc_receive 関数を下記のように編集してみると下記のような出力が得られました。

static int netvsc_receive(struct net_device *ndev,
			  struct netvsc_device *net_device,
			  struct netvsc_channel *nvchan,
			  const struct vmpacket_descriptor *desc)
{
	struct net_device_context *net_device_ctx = netdev_priv(ndev);
	struct vmbus_channel *channel = nvchan->channel;
	const struct vmtransfer_page_packet_header *vmxferpage_packet
		= container_of(desc, const struct vmtransfer_page_packet_header, d);
	const struct nvsp_message *nvsp = hv_pkt_data(desc);
	u32 msglen = hv_pkt_datalen(desc);
	u16 q_idx = channel->offermsg.offer.sub_channel_index;
	char *recv_buf = net_device->recv_buf;
	u32 status = NVSP_STAT_SUCCESS;
	int i;
	int count = 0;

  // 下記行を追記
	netif_info(netdevice_ctx, rx_err, ndev, "BUF-SIZE : %u, SEC-SIZE : %u, RSC-PKTLEN %u\n",
    net_device->recv_buf_size, net_device->recv_section_size,
    nvchan->rsc.pktlen);

	/* Ensure packet is big enough to read header fields */
	if (msglen < sizeof(struct nvsp_message_header)) {
		netif_err(net_device_ctx, rx_err, ndev,
			  "invalid nvsp header, length too small: %u\n",
			  msglen);
		return 0;
	}

/// 以下省略 ///

BUF-SIZE が Window Size にちょっと足したもの、SEC-SIZE が MTU にちょっと足したものの値になり、 RSC-PKTLEN がフレームサイズと同じ値を指し示すようです。

RSC-PKTLEN の値は 1474 を示しており、冒頭のパケットキャプチャと同じような感じになっていることが読み取れます。

なお、同じ VM を同じ設定で Windows 10 の上に構築した場合は下記のようになります。

RSC-PKTLEN が十分に大きな値になっており、 RSC にて reassemble されたパケットが受信出来ていることが分かります。

ドライバを追いかけてみたのですが、正しい値が別パラメータに入っていることなどはなく、また NetVSP の割込が来ないため修正は難しいと考えられました。


まとめ

Windows Server 2019 の Hyper-V を使用して VM を作成する場合は

・MTU を 1500 以下に設定して RSO が正常に機能するようにして使う
・Jumbo Frame を有効にしたい場合は RSO を Disable にする

のどちらかで利用しないと、落とし穴があるという話です。

執筆時点の最新版である “10.0.17763.1999” でもこの事象は発生していますので、
お気をつけくださいませ。


P.S.

割と海外のフォーラムだと “RSO を無効にしたら良くなった!” 的なのはちらほら報告されているみたいですね。。修正されたらいいなとぼんやり思ってます。。

https://social.technet.microsoft.com/Forums/en-US/8aa6a88c-ffc8-4ede-abfc-42e746ff5996/windows-server-2019-hyperv-guest-on-windows-server-2019-hyperv-host?forum=winserverhyperv

https://www.doitfixit.com/blog/2020/01/15/slow-network-speed-with-hyper-v-virtual-machines-on-windows-server-server-2019/

SARA の更新はじめます。

どうも、みむらです。

サポート掲示板でよく「擬似言語シミュレータ SARA」のお問い合わせを受けるのですが、
ソースコードの欠損やバージョンの差異などによりサポートが難しい状況でした。

今回、一部データの補足を加えて Visual Studio 2019 にてビルドが出来る状況になりましたので、リファクタリングと機能追加含めてはじめていこうと考えています。
(もう Windows Forms でなくて XAML で良いよね、とか、 .NET Framework 4.8 ベースとかにしても良いよね・・とか色々と。。)

にしても最初のリリースは10年前だったんですね。。。
https://xtech.nikkei.com/it/article/NEWS/20101004/352568/

ということで、ボチボチはじめていきますー。

コンソールで Optane Memory を有効にする

あけましておめでとうございます。
今年も宜しくお願い致します。

自宅内で Windows Server 2019 が走っているのですが、
大きなデータを保存しておく場所として HDD が搭載されており
これの高速化として “Optane Memory” を使おうとしてみました。

入れてみて、さて有効にしようと画面を開こうとしたところ・・

The Intel Optane memory application ran into a problem と表示される

ということで、起動が出来ません。でも Optane Memory での高速化はしたい。

ただコンソールで Optane Memory の有効化操作を行ったところ
上手く有効になりましたので、今後のメモとしてここに記録します。


記事にあたり:

インテル公式としては、 Windows Server での Optane Memory の動作は保証していないようです。
本番環境に導入するなどして障害が起きてもこちらではカバー出来ませんので、あくまでも実験用やデータが飛んでも問題ない環境でお試しください。

インテル® Optane™メモリー: 購入する前に、主な要件https://www.intel.co.jp/content/www/jp/ja/support/articles/000023994/memory-and-storage/intel-optane-memory.html


1.ドライバを入れる

セットアッププログラムを使用したり、
pnputil コマンド ( 例 : pnputil /add-driver iaStorAC.inf /install ) などでドライバをインストールします。

18.x 系のドライバが必要なため、マザーボードベンダなどで提供されているドライバが古い場合は最新版のドライバを入れておけば大丈夫だと思います。

インテル® Optane™・メモリーを備えたインテル®ラピッド・ストレージ・テクノロジードライバー・インストール・ソフトウェア
https://downloadcenter.intel.com/ja/download/29978

また、ドライバが上手く当たらない場合 (古いバージョンのまま、等) は
devcon.exe を Windows Driver Kit (WDK) から持ってきて更新することも可能です。

DevCon Update – Windows drivers | Microsoft Docs
https://docs.microsoft.com/ja-jp/windows-hardware/drivers/devtest/devcon-update


2. RSTCliPro を用意する

下記のサイトから RSTCliPro.exe をダウンロードし、
当該端末 (今回の私の場合は Windows Server 2019) にコピーしておきます。

インテル® Optane™メモリー向けインテル® RSTCLI Pro
https://downloadcenter.intel.com/ja/download/29986/-Optane-RSTCLI-Pro


3. Optane Memory と 高速化したい HDD の ID を確認する

下記のコマンドを実行します

RstCliPro.exe -I

実行すると下記のようにデバイス一覧が出てきます

そのうち、高速化したいデバイスの ID と Optane Memory の ID を探して控えます。
今回の場合は “0-0-5-0” が高速化したいデバイスで、 “0-1-0-0” が Optane Memory の ID になります。


4. Optane Memory を有効化する

先ほどメモをした ID を元に次のようなコマンドを実行します。

RstCliPro --OptaneMemory --enable --fast-drive <Optane MemoryのID> --drive-to-accel <高速化したいドライブ>

私の場合は、
“RstCliPro.exe –OptaneMemory –enable –fast-drive 0-1-0-0 –drive-to-accel 0-0-5-0”
というコマンドになります。

実行して “Enable completed” と出れば OK です。


以上で設定は完了です。

上記が完了した後 “RstCliPro.exe –OptaneMemory –info” を実行することで設定内容を確認することも可能です。

というわけで、素敵な Optane Memory ライフを!

PrimoCache を使って Intel の最新チップセットでも HDD を SSD を使って高速化する

どうもみむらです。
先日 PC が故障しまして第9世代の Intel CPU (i7-9700) を用いて組み直していました。

故障する数日前からビープ音(長音)の連続で起動に失敗したりしていたので
なんか気持ち悪いなとは思っていたのですが。。

テレワークが推奨されており、お仕事に甚大な影響が出ることもありましたので
ツクモ電機さんのレジの横にあるリーダーにクレジットカードをシャコシャコッと何度も差し入れしてきました。。来月の引き落としに今から震えています。

ただ今回買い換えを行ってみて
Intel Smart Response Technology (iSRT, HDD を SSD キャッシュで高速化するやつ) が
Intel Optane Memory との組み合わせ専用かつ、RAID 不可に変更
されており
iSRT を使って RAID-5 を高速化していた身としてはかなりショックでした。。

では iSRT の代替としていいものは無いのかと探していたところ
PrimoCacheという良さそうなものを見つけたので試してみました。


PrimoCacheとは

HDD を SSD でキャッシュして高速化するソフトです。
まさしく Intel の Smart Response Technology で実現していたものを実現してくれます。

ほかにも FuzeDrive (AMD 環境では StoreMI という名前で提供されています) というソフトなどもありますが、いくつか試してみたところ PrimoCache がよさそうな感じでした。

PrimoCache は Romex Software 社の製品で、1つ当たり $29.95 の製品になっています。
https://www.romexsoftware.com/en-us/primo-cache/

なお私自身はメーカーさんから
今回の記事に関して何か支援を受けてはいませんのであしからず。。

PrimoCache の設定をする

左上のボタンを押してドライブを追加します。

図3 : ドライブの追加ボタン

次の画面で「高速化したいドライブ」を選択します。

図4: 高速化したいドライブを設定。今回は Intel RAID 1 ドライブ。

次にキャッシュの方法についての設定です。
Level-1 Cache が “DRAM 上” のキャッシュ、 Level-2 Cache がストレージとなります。

またキャッシュについては文字通り Level1, Level2 の階層構造になっています。

今回の場合は SSD キャッシュのみを有効にするため、
Level-1 Cache は 0MB に設定します。

図5: Level-1 Cache を 0MBに設定する

次に Level-2 Cache を設定するために、画面中央の小さなボタンを押下します。

図6: Level-2 Cache の設定ボタン

ボタンを押下すると次のような画面が表示され
キャッシュ用のドライブを選択する画面になります。

今回は Intel Optane Memory を使うため
INTEL MEMPEK.. で始まるドライブを選択します。

注:もちろん Intel Optane Memory を使わずに通常の SSD でも利用可能です。
注2:認識されている容量が小さい場合は何らかのパーティションを作ってから再試行してみてください。

図7: キャッシュ用ドライブを設定している図¥

設定後、 “Size” を “MAX” に変更し、その横にあるボタンを押下します。

図8: キャッシュ設定を行う

特に何もなければ
“Individual Read/Write Cache Space” のチェックを無効にします。

これが ON の時はそれぞれのキャッシュが設定した割合で行われますが
無効の場合は割合を気にせずに Read / Write キャッシュを行うようになります。

図9: Read/Write Cache の割振設定を無効にする。

最後にお好みで Defer-Write (遅延書き込み) の設定を行います。

遅延書き込みを有効にすると応答速度が速くなりますが、
ディスクへの書き込み(キャッシュ内容の反映)が遅くなります。

図10: 設定がほぼ完了した図

設定が完了したら “Start” を押下します。

画面UI について

稼働を始めると下記のようにキャッシュ率などが表示されます。

図11: 稼働が開始した画面

ある程度動きはじめたら、画面を閉じて仕事に戻りましょう。


冒頭のとおり PC の故障で買い替えたところ
Intel RAID 構成に対する SSD キャッシュが使えなくなって呆然としていたところ
こういうソフトを見つけることができてよかったです。。!

また前回の構成では Intel RAID の RAID-5 だったのですが
iSRT が有効な環境だと最新のマザーボードや mdadm ではマウントできず焦りましたが
dmraid を使うことでマウントができました。

PrimoCache の場合は Intel RAID と SSD Cache が別の機構なため
同じようにマウントできなくなることは(きっと)ないと思いますし安心です・・!

ではでは、素敵なテレワークライフを!