AlmaLinux

Disk utilizationがあがった原因が分かりません…

CentOS8からAlmaLinuxへの移行後、/dev/sdaのDisk utilizationが6%ほどから18%ほどにあがりました。
おそらく直接的な原因はAlmaLinuxへの移行ではなくて、kernelのVerUPによるものだと思っています。(とてもよくないのですが)1年間kernelを更新しておらず、AlmaLinuxへの移行を契機にrebootしました。
CentOS8とAlmaLinuxのパッケージはほぼすべて一緒なので、移行前後でかわったものはkernelしかないと思っています。

Disk utilizationが100%になっているわけではないので、たぶん、問題ないのだとは思うのですが、サーバーの使い方は何もかわっていないのに、Disk utilizationだけがあがった理由が分かりません。

以下、調べた情報を書きます。
ErogameScapeではmuninでサーバーのリソースを監視しています。
muninのdiskstatsというプラグインに、Disk utilizationという監視項目があります。
Screenshot_1
赤矢印の部分がAlmaLinuxへの移行のためにrebootをしたタイミングです。
Disk utilizationが突然あがっています。
そもそも、Disk utilizationはなんなのかについて、マニュアルを見ると
Linux provides a counter which increments in a millisecond-interval for as long as there are outstanding I/O requests. If this counter is close to 1000msec in a given 1 second timeframe the device is nearly 100% saturated. This plugin provides values averaged over a 5 minute time frame per default, so it can’t catch short-lived saturations, but it’ll give a nice trend for semi-uniform load patterns as they’re expected in most server or multi-user environments.
とのことで…、DeepLで訳すと
Linuxでは、未処理のI/O要求がある限り、ミリ秒間隔で増分するカウンタが用意されています。このカウンタが1秒の時間枠で1000msecに近い場合、デバイスはほぼ100%飽和しています。このプラグインは、デフォルトでは5分間の平均値を提供するので、短時間の飽和を捉えることはできませんが、ほとんどのサーバーやマルチユーザー環境で予想されるような半均一の負荷パターンの傾向を知ることができます。
とのことです。
Munin disk utilization」でぐぐると、Munin disk utilization calculation.という質問がヒットしまして、回答に、
From reading the diskstats plugin source, munin calculates the disk utilization percentage by looking at the total time spent doing IO over a given monitoring period. If the device is spending all it's time doing IO, then it's at 100% utilization. This is somewhat independent of actual IOPS and read/write speeds, as these will have a very access-pattern dependent effect. (I presume you're actually asking how munin calculates the utilization percentage, rather than specifically how to use IOPs and read/write sizes to calculate the same thing)

Munin gets this data from /proc/diskstats. The column in question is the 10th field after the device name (and munin does the usual thing of storing the value the first time it reads it, and the second time it reads it calculating the difference between the old and new values, in order to work out the delta over the monitoring period).
とあります。DeepLで訳しますと
diskstatsプラグインのソースを読むと、muninは所定の監視期間中にIOに費やされた合計時間を見て、ディスク使用率を計算します。デバイスがすべての時間をIOに費やしている場合、利用率は100%になります。これは、実際のIOPSや読み書きの速度とは多少独立していますが、これらはアクセスパターンに大きく影響されるからです。(あなたは、IOPsや読み書きのサイズを使って同じことを計算する方法ではなく、muninがどのように利用率を計算するかを実際に尋ねているのだと思います)

Muninはこのデータを/proc/diskstatsから取得します。問題の列は、デバイス名の後の10番目のフィールドです(そして、muninは、最初に読み込んだときに値を保存し、2回目に読み込んだときには、監視期間中の差分を計算するために、古い値と新しい値の差を計算するという通常のことを行います)。
とのことです。
/proc/diskstatsから、デバイスがI/Oに使用した時間を取得できるので、例えば5分の間にデバイスがI/Oに使用した時間を取得して、デバイスがI/Oに使用した時間 / 5分、とすると5分間のデバイスの使用率が分かるということのようです。
一応、diskstatsプラグインのソースを読んでみます。プラグインのソースは「/usr/share/munin/plugins/diskstat_」を読んでもいいですし、マニュアルのSource Codeというボタンを押しても読めます。
    # Utilization - or "how busy is the device"?
    # If the time spent for I/O was close to 1000msec for
    # a given second, the device is nearly 100% saturated.
    my $utilization = $tot_ticks / $interval;
これが、Disk utilizationを求めているところです。
$intervalは
my $interval = time() - $prev_time;
ですので、現在時刻と1つ前にmuninがデータを取得した時刻の差分です。muninは5分おきに動かしているので、$intervalは、だいたい300となります。
$tot_ticksは
my $tot_ticks = subtract_wrapping_numbers($cur_stats->{'tot_ticks'}, $prev_stats->{'tot_ticks'});
なので、現在のtot_ticksの値と1つ前にmuninがデータを取得したtot_ticksの差分です。
tot_ticksはどこで取得しているかというと、
        @devstat{
            qw(major minor devname
              rd_ios rd_merges rd_sectors rd_ticks
              wr_ios wr_merges wr_sectors wr_ticks
              ios_in_prog tot_ticks rq_ticks)
          }
          = @{$entry};
の部分です。
/proc/diskstatsを取得して、major minor devname…tot_ticks rq_ticksという変数に格納しています。 /proc/diskstatsは、
$ cat /proc/diskstats
   8       0 sda 1329537 16925 80987603 35548923 4020342 216704 112010832 1095361766 154 26533813 1130910690 0 0 0 0
   8       1 sda1 981 0 103554 25718 128 195 2584 9718 0 6755 35437 0 0 0 0
   8       2 sda2 1328484 16925 80880689 35522960 4020214 216509 112008248 1095352048 154 26532460 1130875008 0 0 0 0
 253       0 dm-0 885790 0 80697097 14647953 3995311 0 111499848 1134259478 165 26236727 1148907431 0 0 0 0
 253       1 dm-1 21680 0 177048 158335 64063 0 512504 15535543 0 188377 15693878 0 0 0 0
   7       0 loop0 53 0 988 450 0 0 0 0 0 368 450 0 0 0 0
   7       1 loop1 1632 0 5614 3283 0 0 0 0 0 604 3283 0 0 0 0
   7       2 loop2 16264 0 33416 13069 0 0 0 0 0 2317 13069 0 0 0 0
   7       3 loop3 7558 0 15962 19005 0 0 0 0 0 1144 19005 0 0 0 0
   7       4 loop4 54 0 2406 593 0 0 0 0 0 342 593 0 0 0 0
   7       5 loop5 46 0 938 283 0 0 0 0 0 263 283 0 0 0 0
   7       6 loop6 4 0 8 2 0 0 0 0 0 2 2 0 0 0 0
な感じです。
一番上の行でしたら、majorに8、minorに0、devnameにsda、rd_iosに1329537…と入っていきます。 tot_ticksには、26533813が入ります。
※/proc/diskstatsの内容についてはこちらに記載があります。tot_ticksは「Field 10 -- # of milliseconds spent doing I/Os」です。

    my $utilization = $tot_ticks / $interval;
の、$tot_ticksは単位がmillisecond、$intervalは単位がsecondですので、使用率(%)にするため、
my $util_print = $utilization / 10;
として、$util_printを表示します。
なるほど、表示している内容は分かりましたが、使用率があがった理由はまったく分かりません…
100%ではないし、iowaitも前後でかわっていないので…、特に何かする必要はないかな…と思っています。
Screenshot_2

さくらインターネットの専用サーバ スタンダードシリーズをCentOS8からAlmaLinux8に移行した際のトラブル

さくらインターネットの専用サーバ スタンダードシリーズをCentOS8からAlmaLinux8に移行した際、ネットワークインターフェイスの名前がifconfigとnetwork-scripts配下のファイルで不一致が発生したため、rebootしたらNICがupしませんでした。
結論から書くと、network-scripts配下のファイルを書き換えて再度rebootしました。

[借用しているサーバー]
専用サーバ Fujitsu RX1330 M3 Xeon 4Core (20-04)
※これがリリースされた後、すぐにPHYがリリースされてとても悲しかったです。また、PHYしかOSインストールの選択肢としてAlmaLinuxに対応していないので、とても悲しいです。

AlmaLinuxに移行しrebootした後、NICがupしませんでした。
ifconfigの出力は
[sakura ~]$ ifconfig
eth0: flags=4099  mtu 1500
(中略)
eth1: flags=4163  mtu 1500
(中略)
lo: flags=73  mtu 65536
と、IFの名前が昔のeth0、eth1という表現。
network-scripts配下のファイルは
[root@sakura ap2]# ls -l /etc/sysconfig/network-scripts/
total 12
-rw-r--r--. 1 root root 285 May  2  2020 ifcfg-eno1
-rw-r--r--. 1 root root 138 May  2  2020 ifcfg-eno2
と、eno1、eno2という表現でした。
移行前は問題なかったので…、なぜ問題でなかったのかはさっぱり分からないのですが…、IFの名前をあわせればいいので…、
linux - RHEL7 で NIC の名前を eno1 から従来の eth0 に変更するには? - スタック・オーバーフロー
のとおりに、ifcfg-eth1というファイルを作って
NAME=eth1
DEVICE=eth1
の部分をeno1からeth1に書き換えて再起動し、無事NICがupしました。

/etc/default/grubを見ると
GRUB_CMDLINE_LINUX=" resume=/dev/mapper/cl-swap rd.lvm.lv=cl/root rd.lvm.lv=cl/swap  net.ifnames=0  biosdevname=0 consoleblank=0 nomodeset crashkernel=auto"
となっていて、赤字の設定があると、IFの名前が昔のeth0、eth1という表現になるのがデフォルトで、名前をかえたい場合は、network-scripts配下のファイルの設定で、HWADDR=を指定してあげると、HWADDR=で指定されたNICの名前がNAMEとDEVICEに書かれたものになる…ようなのですが、もともとの設定にはHWADDR=がなかったので、IFの名前がeno1になってちゃんと起動できていたのか分かりませんでした。

専用サーバーを借用するとネットワークの設定は自分でやらないので、トラブルが発生したとき困るなあ…と思いました。
次は借用したら、最初にネットワークの設定関連のバックアップを取得しておこう…と思いました。
また、こんなことが起きることを想定して、借用する場合はコンソール接続ができること、を条件にしているのですが、コンソール接続できてよかったです。使わないときは、何年も使わないのですが…

"cmd": ["dnf", "config-manager", "--set-enabled", "PowerTools"],"stderr": "エラー: 修正用の一致する repo はありません: PowerTools."

AlmaLinuxにmuninをインストールするためPowerToolsリポジトリを使用可能にしようとしたところエラーが発生しました。
結論から書くと、
yum config-manager --set-enabled powertools
で使用可能にできました。

[ansibleのplaybook]
- name: enable PowerTools repository
  command: dnf config-manager --set-enabled PowerTools
  args:
    warn: false
[ansibleのエラー]
fatal: [local_101]: FAILED! => {"changed": true, "cmd": ["dnf", "config-manager", "--set-enabled", "PowerTools"], "delta": "0:00:00.373923", "end": "2021-08-21 15:38:40.940575", "msg": "non-zero return code", "rc": 1, "start": "2021-08-21 15:38:40.566652", "stderr": "エラー: 修正用の一致する repo はありません: PowerTools.", "stderr_lines": ["エラー: 修正用の一致する repo はありません: PowerTools."], "stdout": "", "stdout_lines": []}
[実行したコマンド]
# dnf config-manager --enable PowerTools
エラー: 修正用の一致する repo はありません: PowerTools.
[原因]
コマンドのPowerToolsのPとTが小文字でなければならなかった。
CentOS8では
yum config-manager --set-enabled powertools
yum config-manager --set-enabled PowerTools
のどちらでもOKでしたが、AlmaLinuxでは小文字の方のコマンドでないといけなくなりました。
記事検索