CentOS

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

「yum module install php:remi-8.0」をansibleで書く

CentOS8にphp:remi-8.0をインストールするコマンドは以下のとおりです。
# sudo rpm -ivh http://rpms.remirepo.net/enterprise/remi-release-8.rpm
# sudo rpm --import http://rpms.remirepo.net/RPM-GPG-KEY-remi
# sudo yum config-manager --set-enabled remi
# sudo yum module install php:remi-8.0
これをansibleで書くと以下のようになります。
- name: phpのインストール
  dnf:
    name: "@php:remi-8.0"
    enablerepo: remi
    state: present
php:remi-8.0の前の@については、ansible.builtin.dnf – Manages packages with the dnf package managerのExamplesの「Install a modularity appstream with defined stream and profile」を参照。

pgpoolのlog_destination

この話題は、pgpoolとCentOS8の話です。

pgpoolの設定の一つである「log_destination」はログの出力先を指定します。
設定値は、「stdder」、「syslog」、「stdder,syslog」の3種類です。

log_destinationを「stdder,syslog」に設定し、rsyslog.confをそれなりに設定し、これで/var/log/pgpool/pgpool.logにだけログが出力されると思ったら、/var/log/pgpool/pgpool.logにも、/var/log/messagesにも出力されていました。
log_destinationを「syslog」に設定して、思ったとおりの動作になりました。

「stdder,syslog」と設定すると、pgpoolはstdderにもsyslogにもログを出力します。
stdderに出力されたログは、systemdがjournaldに渡します。
journaldは渡されたログをrsyslogdに渡します。
# cat /etc/rsyslog.conf
<中略>
module(load="imjournal"             # provides access to the systemd journal
       StateFile="imjournal.state") # File to store the position in the journal

log_destinationを「stdder,syslog」に設定すると、「syslog」の設定がrsyslogd経由でログを書き込み、「stdder」の設定が、journald→rsyslogd経由でログを書き込む、動作になります。

log_destinationを「syslog」にしてログを保存する場合の設定は公式マニュアル、「stdder」にしてログを保存する場合はpgpool logging on centos 7 | Pierre Timmermansを参照するといいと思います。

nothing provides module(perl:5.26) needed by module perl-DBD-Pg:3.7:8010020200204214655:0d1d6681-0.x86_64

契機はわかりませんが、以下のとおりModular dependency problemsが発生していました。
[root@localhost ap2]# yum list installed
モジュラーの依存に関する問題:

 問題 1: conflicting requests
  - nothing provides module(perl:5.26) needed by module perl-DBD-Pg:3.7:8010020200204214655:0d1d6681-0.x86_64
 問題 2: conflicting requests
  - nothing provides module(perl:5.26) needed by module perl-DBI:1.641:8010020191113222731:16b3ab4d-0.x86_64
 問題 3: conflicting requests
  - nothing provides module(perl:5.26) needed by module perl-FCGI:0.78:8010020191114031513:16b3ab4d-0.x86_64

以下略
結論から書くと、CentOS 8 conflicting requestsのと同じで、dnf module enable perl:5.26で回復しました。
[root@localhost ap2]# dnf module enable perl:5.26
メタデータの期限切れの最終確認: 0:15:24 時間前の 2020年05月05日 12時03分44秒 に実施しました。
依存関係が解決しました。
============================================================================================================================
 パッケージ                   アーキテクチャー            バージョン                     リポジトリー                 サイズ
============================================================================================================================
モジュールストリームの有効化:
 perl                                                     5.26

トランザクションの概要
============================================================================================================================

これでよろしいですか? [y/N]: y
完了しました!
[root@localhost ap2]# yum list installed | more
インストール済みパッケージ
ModemManager-glib.x86_64                   1.10.4-1.el8                                      @BaseOS
NetworkManager.x86_64                      1:1.20.0-5.el8_1                                  @BaseOS
以下略
dnf module enable perl:5.26の前の状態は以下
[root@localhost ap2]# dnf module list perl
CentOS-8 - AppStream
Name             Stream                  Profiles                        Summary
perl             5.24                    common [d], minimal             Practical Extraction and Report Language
perl             5.26 [d]                common [d], minimal             Practical Extraction and Report Language

ヒント: [d]efault, [e]nabled, [x]disabled, [i]nstalled
dnf module enable perl:5.26の後の状態は以下です。
[root@localhost ap2]# dnf module list perl
CentOS-8 - AppStream
Name             Stream                  Profiles                        Summary
perl             5.24                    common [d], minimal             Practical Extraction and Report Language
perl             5.26 [d][e]             common [d], minimal             Practical Extraction and Report Language

ヒント: [d]efault, [e]nabled, [x]disabled, [i]nstalled
なぜdnf module enable perl:5.26で依存関係の問題が解消されるのか分かりませんでした。

yum remove "php*"

phpという名前で始まるパッケージを削除したい場合、「yum remove php-*」でなく、「yum remove "php*"」とphp*をダブルクォーテーションで囲む必要があります。
[ap2@postgresql11-testserver-1 ~]$ rpm -qa | grep php
php-pecl-igbinary-2.0.8-1.el7.remi.7.1.x86_64
php-pear-1.10.6-1.el7.remi.noarch
php-json-7.1.24-1.el7.remi.x86_64
php-mbstring-7.1.24-1.el7.remi.x86_64
php-snmp-7.1.24-1.el7.remi.x86_64
php-pgsql-7.1.24-1.el7.remi.x86_64
php-common-7.1.24-1.el7.remi.x86_64
php-opcache-7.1.24-1.el7.remi.x86_64
php-xml-7.1.24-1.el7.remi.x86_64
php-process-7.1.24-1.el7.remi.x86_64
php-pecl-msgpack-2.0.2-1.el7.remi.7.1.x86_64
php-pdo-7.1.24-1.el7.remi.x86_64
php-mysqlnd-7.1.24-1.el7.remi.x86_64
php-soap-7.1.24-1.el7.remi.x86_64
php-pecl-memcached-3.0.4-2.el7.remi.7.1.x86_64
php-gd-7.1.24-1.el7.remi.x86_64
php-ldap-7.1.24-1.el7.remi.x86_64
php-7.1.24-1.el7.remi.x86_64
php-xmlrpc-7.1.24-1.el7.remi.x86_64
php-cli-7.1.24-1.el7.remi.x86_64
php-fedora-autoloader-1.0.0-1.el7.noarch
php-devel-7.1.24-1.el7.remi.x86_64
[root@postgresql11-testserver-1 ap2]# yum remove php-*
Loaded plugins: fastestmirror, langpacks, priorities
No Match for argument: php-fedora-autoloader-1.0.0-1.el7.src.rpm
No Packages marked for removal
[root@postgresql11-testserver-1 ap2]# yum remove "php*"
Loaded plugins: fastestmirror, langpacks, priorities
Resolving Dependencies
--> Running transaction check
---> Package php.x86_64 0:7.1.25-2.el7.remi will be erased
---> Package php-cli.x86_64 0:7.1.25-2.el7.remi will be erased
---> Package php-common.x86_64 0:7.1.25-2.el7.remi will be erased
---> Package php-devel.x86_64 0:7.1.25-2.el7.remi will be erased
---> Package php-fedora-autoloader.noarch 0:1.0.0-1.el7 will be erased
---> Package php-gd.x86_64 0:7.1.25-2.el7.remi will be erased
---> Package php-json.x86_64 0:7.1.25-2.el7.remi will be erased
---> Package php-ldap.x86_64 0:7.1.25-2.el7.remi will be erased
---> Package php-mbstring.x86_64 0:7.1.25-2.el7.remi will be erased
---> Package php-mysqlnd.x86_64 0:7.1.25-2.el7.remi will be erased
---> Package php-opcache.x86_64 0:7.1.25-2.el7.remi will be erased
---> Package php-pdo.x86_64 0:7.1.25-2.el7.remi will be erased
---> Package php-pear.noarch 1:1.10.7-3.el7.remi will be erased
---> Package php-pecl-igbinary.x86_64 0:2.0.8-1.el7.remi.7.1 will be erased
---> Package php-pecl-memcached.x86_64 0:3.1.3-1.el7.remi.7.1 will be erased
---> Package php-pecl-msgpack.x86_64 0:2.0.3-1.el7.remi.7.1 will be erased
---> Package php-pgsql.x86_64 0:7.1.25-2.el7.remi will be erased
---> Package php-process.x86_64 0:7.1.25-2.el7.remi will be erased
---> Package php-snmp.x86_64 0:7.1.25-2.el7.remi will be erased
---> Package php-soap.x86_64 0:7.1.25-2.el7.remi will be erased
---> Package php-xml.x86_64 0:7.1.25-2.el7.remi will be erased
---> Package php-xmlrpc.x86_64 0:7.1.25-2.el7.remi will be erased
--> Finished Dependency Resolution

Dependencies Resolved

============================================================================================================================
 Package                            Arch                Version                              Repository                Size
============================================================================================================================
Removing:
 php                                x86_64              7.1.25-2.el7.remi                    @remi-php71              9.4 M
 php-cli                            x86_64              7.1.25-2.el7.remi                    @remi-php71               14 M
 php-common                         x86_64              7.1.25-2.el7.remi                    @remi-php71              7.9 M
 php-devel                          x86_64              7.1.25-2.el7.remi                    @remi-php71               10 M
 php-fedora-autoloader              noarch              1.0.0-1.el7                          @epel                     15 k
 php-gd                             x86_64              7.1.25-2.el7.remi                    @remi-php71              204 k
 php-json                           x86_64              7.1.25-2.el7.remi                    @remi-php71               80 k
 php-ldap                           x86_64              7.1.25-2.el7.remi                    @remi-php71              129 k
 php-mbstring                       x86_64              7.1.25-2.el7.remi                    @remi-php71              2.8 M
 php-mysqlnd                        x86_64              7.1.25-2.el7.remi                    @remi-php71              850 k
 php-opcache                        x86_64              7.1.25-2.el7.remi                    @remi-php71              800 k
 php-pdo                            x86_64              7.1.25-2.el7.remi                    @remi-php71              386 k
 php-pear                           noarch              1:1.10.7-3.el7.remi                  @remi-php71              2.1 M
 php-pecl-igbinary                  x86_64              2.0.8-1.el7.remi.7.1                 @remi-php71              314 k
 php-pecl-memcached                 x86_64              3.1.3-1.el7.remi.7.1                 @remi-php71              335 k
 php-pecl-msgpack                   x86_64              2.0.3-1.el7.remi.7.1                 @remi-php71              160 k
 php-pgsql                          x86_64              7.1.25-2.el7.remi                    @remi-php71              363 k
 php-process                        x86_64              7.1.25-2.el7.remi                    @remi-php71              180 k
 php-snmp                           x86_64              7.1.25-2.el7.remi                    @remi-php71              110 k
 php-soap                           x86_64              7.1.25-2.el7.remi                    @remi-php71              616 k
 php-xml                            x86_64              7.1.25-2.el7.remi                    @remi-php71              855 k
 php-xmlrpc                         x86_64              7.1.25-2.el7.remi                    @remi-php71              165 k

Transaction Summary
============================================================================================================================
Remove  22 Packages

Installed size: 52 M
Is this ok [y/N]:

CentOSでソフトウェアRAIDを使用する場合のraid-checkについて

CentOSでソフトウェアRAIDを使用すると毎週日曜日にraid-checkというスクリプトが動きます。
raid-checkはRAIDのHDDのverifyをします。

raid-checkの動作については「RHEL系のmdadmのraid-check を調べてみた - うまい棒blog」の文書がいいかなと思います。

raid-checkは優先度が低く動作する…renice -n 5、ionice -c2 -n7で動きます。
ErogameScapeは日曜日に一番アクセスが多いことと、ErogameScapeのraid-checkは1日経っても終わらないことから火曜日に変更しています。

以下がraid-checkが動いているときのDiskスループットです。
無題2

最初にソフトウェアRAIDを導入したときに「なんなんだこれは!」と思ったので、同じように「なんなんだこれは!」と思う方のためにメモします。

cronの設定ファイル場所は以下の通りです。
[ap2@erogamescape14 ~]$ cat /etc/cron.d/raid-check
# Run system wide raid-check once a week on Sunday at 1am by default
0 1 * * Tue root /usr/sbin/raid-check
raid-checkの設定ファイルは「/etc/sysconfig/raid-check」、raid-check本体は「/usr/sbin/raid-check」です。

CentOSのソフトウェアRAID1を構成するHDDの1つが故障したので、新HDDに交換する手順

ErogameScapeはLinuxのソフトウェアRAID1でHDDを冗長化しています。
ソフトウェアRAID1を採用してはじめてHDDが壊れましたので、その復旧手順をメモしておきます。

ErogameScapeではHDDが壊れてもメールする…という仕組みを設定してなくて、Muninのグラフを見て「あ、壊れた」と判断します。
ちなみに壊れたことにまったく気がついていなくて、気がついたときには5日くらい経っていました…
HDDが壊れたときのMUninのグラフを以下に示します。

無題
いつもは100%ですが、1つ壊れると50%になります。

/proc/mdstatの出力は以下のようになりました。
[ap2@erogamescape13 ~]$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdf1[1](F) sde1[0]
      1060244 blocks super 1.0 [2/1] [U_]
      bitmap: 0/1 pages [0KB], 65536KB chunk

md1 : active raid1 sdf3[1](F) sde3[0]
      942138801 blocks super 1.1 [2/1] [U_]
      bitmap: 7/8 pages [28KB], 65536KB chunk

unused devices: 
正常時は以下の通りです。
[ap2@erogamescape13 ~]$ cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sde1[0] sdf1[2]
      1060244 blocks super 1.0 [2/2] [UU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

md1 : active raid1 sdf3[2] sde3[0]
      942138801 blocks super 1.1 [2/2] [UU]
      bitmap: 2/8 pages [8KB], 65536KB chunk

unused devices: 
/dev/sdfが壊れているので、/dev/sdfをRAIDから切り離します。
[root@erogamescape13 ap2]# mdadm /dev/md0 -r /dev/sdf1
mdadm: hot removed /dev/sdf1 from /dev/md0
[root@erogamescape13 ap2]# mdadm /dev/md1 -r /dev/sdf3
mdadm: hot removed /dev/sdf3 from /dev/md1
[root@erogamescape13 ap2]# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sde1[0]
      1060244 blocks super 1.0 [2/1] [U_]
      bitmap: 0/1 pages [0KB], 65536KB chunk

md1 : active raid1 sde3[0]
      942138801 blocks super 1.1 [2/1] [U_]
      bitmap: 7/8 pages [28KB], 65536KB chunk
/proc/mdstatから/dev/sdfがいなくなりました。
/dev/sdfを交換します。

※HDDを交換するとき、今回で言うとどのHDDが/dev/sdfなのかが、ぱっと見分からないです…
 同じHDDを積んでいないのでHDD本体を見れば「こっちか」と分かるのですが、外さないと型番が見にくいです。
 何かいい方法はないでしょうか、おそらくあると思うのですが…

交換が終わりましたら、/dev/sdeと同じようにfdiskで領域を確保します。
/dev/sdfの領域は以下のようになっています。
[root@erogamescape13 ap2]# fdisk -l /dev/sde

ディスク /dev/sde: 1000.2 GB, 1000204886016 バイト
ヘッド 255, セクタ 63, シリンダ 121601
Units = シリンダ数 of 16065 * 512 = 8225280 バイト
セクタサイズ (論理 / 物理): 512 バイト / 512 バイト
I/O size (minimum/optimal): 512 bytes / 512 bytes
ディスク識別子: 0x000b174e

デバイス ブート      始点        終点     ブロック   Id  システム
/dev/sde1   *           1         132     1060258+  fd  Linux raid 自動検出
/dev/sde2             133        4310    33559785   82  Linux スワップ / Solaris
/dev/sde3            4311      121601   942139957+  fd  Linux raid 自動検出

[root@erogamescape13 ap2]# fdisk /dev/sdf
デバイスは正常な DOS 領域テーブルも、Sun, SGI や OSF ディスクラベルも
含んでいません
新たに DOS ディスクラベルをディスク識別子 0x1fd65b05 で作成します。
あなたが書き込みを決定するまで、変更はメモリ内だけに残します。
その後はもちろん以前の内容は修復不可能になります。
警告: 領域テーブル 4 の不正なフラグ 0x0000 は w(書き込み)によって
正常になります

The device presents a logical sector size that is smaller than
the physical sector size. Aligning to a physical sector (or optimal
I/O) size boundary is recommended, or performance may be impacted.

警告: DOS互換モードは廃止予定です。このモード (コマンド 'c') を止めることを
      強く推奨します。 and change display units to
         sectors (command 'u').

コマンド (m でヘルプ): m
コマンドの動作
   a   ブート可能フラグをつける
   b   bsd ディスクラベルを編集する
   c   dos 互換フラグをつける
   d   領域を削除する
   l   既知の領域タイプをリスト表示する
   m   このメニューを表示する
   n   新たに領域を作成する
   o   新たに空の DOS 領域テーブルを作成する
   p   領域テーブルを表示する
   q   変更を保存せずに終了する
   s   空の Sun ディスクラベルを作成する
   t   領域のシステム ID を変更する
   u   表示/項目ユニットを変更する
   v   領域テーブルを照合する
   w   テーブルをディスクに書き込み、終了する
   x   特別な機能 (エキスパート専用)

コマンド (m でヘルプ): n
コマンドアクション
   e   拡張
   p   基本パーティション (1-4)
p
パーティション番号 (1-4): 1
最初 シリンダ (1-121601, 初期値 1):
初期値 1 を使います
Last シリンダ, +シリンダ数 or +size{K,M,G} (1-121601, 初期値 121601): +1G

コマンド (m でヘルプ): p

ディスク /dev/sdf: 1000.2 GB, 1000204886016 バイト
ヘッド 255, セクタ 63, シリンダ 121601
Units = シリンダ数 of 16065 * 512 = 8225280 バイト
セクタサイズ (論理 / 物理): 512 バイト / 4096 バイト
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
ディスク識別子: 0x1fd65b05

デバイス ブート      始点        終点     ブロック   Id  システム
/dev/sdf1               1         132     1060256+  83  Linux
パーティション 1 は、シリンダ境界で終わっていません。
Partition 1 does not start on physical sector boundary.

コマンド (m でヘルプ): a
パーティション番号 (1-4): 2
警告: 領域 2 は空のタイプです。

コマンド (m でヘルプ): n
コマンドアクション
   e   拡張
   p   基本パーティション (1-4)
p
パーティション番号 (1-4): 2
最初 シリンダ (132-121601, 初期値 132):
初期値 132 を使います
Last シリンダ, +シリンダ数 or +size{K,M,G} (132-121601, 初期値 121601): +32G

コマンド (m でヘルプ): p

ディスク /dev/sdf: 1000.2 GB, 1000204886016 バイト
ヘッド 255, セクタ 63, シリンダ 121601
Units = シリンダ数 of 16065 * 512 = 8225280 バイト
セクタサイズ (論理 / 物理): 512 バイト / 4096 バイト
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
ディスク識別子: 0x1fd65b05

デバイス ブート      始点        終点     ブロック   Id  システム
/dev/sdf1               1         132     1060256+  83  Linux
パーティション 1 は、シリンダ境界で終わっていません。
Partition 1 does not start on physical sector boundary.
/dev/sdf2             132        4310    33551756   83  Linux

コマンド (m でヘルプ): n
コマンドアクション
   e   拡張
   p   基本パーティション (1-4)
p
パーティション番号 (1-4): 3
最初 シリンダ (4310-121601, 初期値 4310):
初期値 4310 を使います
Last シリンダ, +シリンダ数 or +size{K,M,G} (4310-121601, 初期値 121601):
初期値 121601 を使います

コマンド (m でヘルプ): p

ディスク /dev/sdf: 1000.2 GB, 1000204886016 バイト
ヘッド 255, セクタ 63, シリンダ 121601
Units = シリンダ数 of 16065 * 512 = 8225280 バイト
セクタサイズ (論理 / 物理): 512 バイト / 4096 バイト
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
ディスク識別子: 0x1fd65b05

デバイス ブート      始点        終点     ブロック   Id  システム
/dev/sdf1               1         132     1060256+  83  Linux
パーティション 1 は、シリンダ境界で終わっていません。
Partition 1 does not start on physical sector boundary.
/dev/sdf2             132        4310    33551756   83  Linux
/dev/sdf3            4310      121601   942147988+  83  Linux

コマンド (m でヘルプ): m
コマンドの動作
   a   ブート可能フラグをつける
   b   bsd ディスクラベルを編集する
   c   dos 互換フラグをつける
   d   領域を削除する
   l   既知の領域タイプをリスト表示する
   m   このメニューを表示する
   n   新たに領域を作成する
   o   新たに空の DOS 領域テーブルを作成する
   p   領域テーブルを表示する
   q   変更を保存せずに終了する
   s   空の Sun ディスクラベルを作成する
   t   領域のシステム ID を変更する
   u   表示/項目ユニットを変更する
   v   領域テーブルを照合する
   w   テーブルをディスクに書き込み、終了する
   x   特別な機能 (エキスパート専用)

コマンド (m でヘルプ): t
パーティション番号 (1-4): 1
16進数コード (L コマンドでコードリスト表示): fd
領域のシステムタイプを 1 から fd (Linux raid 自動検出) に変更しました

コマンド (m でヘルプ): t
パーティション番号 (1-4): 2
16進数コード (L コマンドでコードリスト表示): 82
領域のシステムタイプを 2 から 82 (Linux スワップ / Solaris) に変更しました

コマンド (m でヘルプ): t
パーティション番号 (1-4): 3
16進数コード (L コマンドでコードリスト表示): fd
領域のシステムタイプを 3 から fd (Linux raid 自動検出) に変更しました

コマンド (m でヘルプ): p

ディスク /dev/sdf: 1000.2 GB, 1000204886016 バイト
ヘッド 255, セクタ 63, シリンダ 121601
Units = シリンダ数 of 16065 * 512 = 8225280 バイト
セクタサイズ (論理 / 物理): 512 バイト / 4096 バイト
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
ディスク識別子: 0x1fd65b05

デバイス ブート      始点        終点     ブロック   Id  システム
/dev/sdf1               1         132     1060256+  fd  Linux raid 自動検出
パーティション 1 は、シリンダ境界で終わっていません。
Partition 1 does not start on physical sector boundary.
/dev/sdf2             132        4310    33551756   82  Linux スワップ / Solaris
/dev/sdf3            4310      121601   942147988+  fd  Linux raid 自動検出

コマンド (m でヘルプ): w
パーティションテーブルは変更されました!

ioctl() を呼び出してパーティションテーブルを再読込みします。
ディスクを同期しています。
[root@erogamescape13 ap2]#
[root@erogamescape13 ap2]#
[root@erogamescape13 ap2]# fdisk /dev/sdf

The device presents a logical sector size that is smaller than
the physical sector size. Aligning to a physical sector (or optimal
I/O) size boundary is recommended, or performance may be impacted.

警告: DOS互換モードは廃止予定です。このモード (コマンド 'c') を止めることを
      強く推奨します。 and change display units to
         sectors (command 'u').

コマンド (m でヘルプ): a
パーティション番号 (1-4): 1

コマンド (m でヘルプ): p

ディスク /dev/sdf: 1000.2 GB, 1000204886016 バイト
ヘッド 255, セクタ 63, シリンダ 121601
Units = シリンダ数 of 16065 * 512 = 8225280 バイト
セクタサイズ (論理 / 物理): 512 バイト / 4096 バイト
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
ディスク識別子: 0x1fd65b05

デバイス ブート      始点        終点     ブロック   Id  システム
/dev/sdf1   *           1         132     1060256+  fd  Linux raid 自動検出
パーティション 1 は、シリンダ境界で終わっていません。
Partition 1 does not start on physical sector boundary.
/dev/sdf2             132        4310    33551756   82  Linux スワップ / Solaris
/dev/sdf3            4310      121601   942147988+  fd  Linux raid 自動検出

コマンド (m でヘルプ): w
パーティションテーブルは変更されました!


ioctl() を呼び出してパーティションテーブルを再読込みします。
ディスクを同期しています。
/dev/sdfをRAIDに組み込みます。
[root@erogamescape13 ap2]# mdadm /dev/md0 --add /dev/sdf1
mdadm: added /dev/sdf1
[root@erogamescape13 ap2]# mdadm /dev/md1 --add /dev/sdf3
mdadm: added /dev/sdf3
組み込むとRebuildがはじまります。
/dev/md0は1Gしかないのであっという間に終わりますが、/dev/md1は相当時間がかかります。
[root@erogamescape13 ap2]# mdadm --detail /dev/md0
/dev/md0:
        Version : 1.0
  Creation Time : Thu Jul 28 04:17:57 2011
     Raid Level : raid1
     Array Size : 1060244 (1035.57 MiB 1085.69 MB)
  Used Dev Size : 1060244 (1035.57 MiB 1085.69 MB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

  Intent Bitmap : Internal

    Update Time : Tue Jun 24 23:21:19 2014
          State : active
 Active Devices : 2
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 0

           Name : localhost.localdomain:0
           UUID : 02707424:61b2b644:717d3829:948376d3
         Events : 223

    Number   Major   Minor   RaidDevice State
       0       8       65        0      active sync   /dev/sde1
       2       8       81        1      active sync   /dev/sdf1
[root@erogamescape13 ap2]# mdadm --detail /dev/md1
/dev/md1:
        Version : 1.1
  Creation Time : Thu Jul 28 04:17:59 2011
     Raid Level : raid1
     Array Size : 942138801 (898.49 GiB 964.75 GB)
  Used Dev Size : 942138801 (898.49 GiB 964.75 GB)
   Raid Devices : 2
  Total Devices : 2
    Persistence : Superblock is persistent

  Intent Bitmap : Internal

    Update Time : Tue Jun 24 23:21:51 2014
          State : active, degraded, recovering
 Active Devices : 1
Working Devices : 2
 Failed Devices : 0
  Spare Devices : 1

 Rebuild Status : 0% complete

           Name : localhost.localdomain:1
           UUID : e1c4e9e4:ed5a8be1:2e5318e8:3fc28250
         Events : 1335745

    Number   Major   Minor   RaidDevice State
       0       8       67        0      active sync   /dev/sde3
       2       8       83        1      spare rebuilding   /dev/sdf3
[root@erogamescape13 ap2]# cat /proc/mdstat
Personalities : [raid1]
md0 : active raid1 sdf1[2] sde1[0]
      1060244 blocks super 1.0 [2/2] [UU]
      bitmap: 0/1 pages [0KB], 65536KB chunk

md1 : active raid1 sdf3[2] sde3[0]
      942138801 blocks super 1.1 [2/1] [U_]
      [>....................]  recovery =  0.3% (3171840/942138801) finish=218.2min speed=71696K/sec
      bitmap: 7/8 pages [28KB], 65536KB chunk

unused devices: 
/dev/sdfから起動できるようにgrubを書き込んでおきます。
/dev/sdfがhd0なのかhd1なのか分からないので(いや…分かる方法はあると思うのですが…)、とりあえずhd0にもhd1にも書き込んでおればいいかーということで、両方にgrubを書き込んでおきます。
Rebuild中でも大丈夫です。
[root@erogamescape13 ap2]# grub
Probing devices to guess BIOS drives. This may take a long time.


    GNU GRUB  version 0.97  (640K lower / 3072K upper memory)

 [ Minimal BASH-like line editing is supported.  For the first word, TAB
   lists possible command completions.  Anywhere else TAB lists the possible
   completions of a device/filename.]
grub> root(hd0,0)
root(hd0,0)

Error 2: Unrecognized command
grub> root (hd0,0)
root (hd0,0)
 Filesystem type is ext2fs, partition type 0xfd
grub> setup (hd0)
setup (hd0)
 Checking if "/boot/grub/stage1" exists... no
 Checking if "/grub/stage1" exists... yes
 Checking if "/grub/stage2" exists... yes
 Checking if "/grub/e2fs_stage1_5" exists... yes
 Running "embed /grub/e2fs_stage1_5 (hd0)"...  26 sectors are embedded.
succeeded
 Running "install /grub/stage1 (hd0) (hd0)1+26 p (hd0,0)/grub/stage2 /grub/grub.conf"... succeeded
Done.
grub> root (hd1,0)
root (hd1,0)
 Filesystem type is ext2fs, partition type 0xfd
grub> setup (hd1)
setup (hd1)
 Checking if "/boot/grub/stage1" exists... no
 Checking if "/grub/stage1" exists... yes
 Checking if "/grub/stage2" exists... yes
 Checking if "/grub/e2fs_stage1_5" exists... yes
 Running "embed /grub/e2fs_stage1_5 (hd1)"...  26 sectors are embedded.
succeeded
 Running "install /grub/stage1 (hd1) (hd1)1+26 p (hd1,0)/grub/stage2 /grub/grub.conf"... succeeded
Done.
grub> quit
quit
以上で作業は完了です。

HDDが毎日とか週単位で壊れる環境だったら問題ないですが、個人でRAIDを使っているレベルだとごく稀にしか壊れないため、実際に壊れた場合に「さて、どうするんだっけ?」となると思います。
RAIDを組む際には、組んだ際に壊れたときの対処方法を何回か練習しておくべきだと思っています。
実際に壊すことはできないので、SATAのケーブルを抜いてみるとかそういう感じになってしまいますが…

ソフトはソースからインストールしない

はじめに

CentOS等のパッケージ管理があるLinuxのディストリビューションにおいて、ソフトをソースからインストールするのは極力やめた方がよいです。
昔はそうでもなかったのですが、現在、たいていのソフトは新しいVerがでるとすぐにパッケージがリリースされますので、ソースからインストールしなければいけない場面は、そんなにない…と思います。

ソースからインストールしない方がよい理由は以下の通りです。
  • ソースからインストールしたソフトは、何がどこに入ったか、make installのログ等を追わないと分からない
  • インストールはmake insatllでめっちゃ簡単にインストールできるが、アントンストールは手動
  • パッケージ管理されているソフトと競合する

導入

サーバーにmemcashedをインストールしたのでmuninで監視することにしました。

memcashedをmuninで監視するはとても簡単…muninがインストールされていれば、多分デフォルトでmemcashed監視用のスクリプトがついてくるので、スクリプトにシンボリックリンクをはるだけ…なのですが、何を血迷ったのか、当時の私はmuninをソースからインストールするという手順を実行していました。

その結果
  • ソースからインストールしたmunin
  • パッケージを使ってインストールしたmunin
の2つがサーバーに混在することになりました。

/etc/init.d/munin-node start
すると、ソースからインストールしたmuninが起動します。

これはまずい…ということで、ソースからインストールしたmuninを削除するべく行動し始めました。


ソースからインストールしたソフトをアンインストールする

「ソースからインストールしたソフト アンインストール」でぐぐると
make uninstall
してみろ、そんなオプションがあったらラッキー、と書いてありました。
残念ながらmuninにuninstallというオプションはありませんでした。

インストールされたファイルを削除していく

find / -name munin
で、見つかったそれっぽいディレクトリを削除していきます。

rm -rf /opt/munin
rm -rf /opt/munin/log/munin
rm -rf /etc/opt/munin
rm -rf /var/opt/munin

そして、
/sbin/service munin-node start
Starting Munin Node: ERROR: Cannot open '/etc/opt/munin/munin-node.conf':  at /usr/sbin/munin-node line 60

パッケージでインストールしたmuninの設定ファイルは
/etc/munin/munin-node.conf

一方ソースからインストールしたmuninの設定ファイル
/etc/opt/munin/munin-node.conf 

/etc/munin/munin-node.confを見に行くように変更しなければいけません。
Starting Munin Node: ERROR: Cannot open '/etc/opt/munin/munin-node.conf':  at /usr/sbin/munin-node line 60
ですので、 /usr/sbin/munin-nodeのline 60を確認します。

/usr/sbin/munin-nodeを読む

munin-nodeは先頭行に
#!/usr/bin/perl -wT
と書いてあるperlのスクリプトです。

60行目の内容は以下の通りです。
$config->parse_config_from_file($conffile);

$conffileの定義は以下の通りです。
my $conffile   = "$Munin::Common::Defaults::MUNIN_CONFDIR/munin-node.conf";

$Munin::Common::Defaults::MUNIN_CONFDIRに/etc/opt/muninが入っているのですが、$Munin::Common::Defaults::MUNIN_CONFDIRがどこで定義されているか、さっぱり分かりませんでした。

/usr/sbin/munin-nodeにおいて、$Munin::Common::Defaults::MUNIN_CONFDIRの前に書いてある内容は以下の通りです。

use strict;
use warnings;

# Trust PERL5LIB from environment
use lib map { /(.*)/ } split(/:/, ($ENV{PERL5LIB} || ''));

use Getopt::Long;
use Munin::Node::Config;
use Munin::Common::Defaults;
use Munin::Node::OS;
use Munin::Node::Server;

my $servicedir = "$Munin::Common::Defaults::MUNIN_CONFDIR/plugins";
my $sconfdir   = "$Munin::Common::Defaults::MUNIN_CONFDIR/plugin-conf.d";
my $conffile   = "$Munin::Common::Defaults::MUNIN_CONFDIR/munin-node.conf";

Perlをちゃんと扱っている方であれば、
  • $ENV{PERL5LIB}はperl -e 'foreach(@INC){print "$_\n";}'で確認できる
  • $Munin::Common::Defaults::MUNIN_CONFDIRは、$ENV{PERL5LIB}に格納されているディレクトリの中にあるMunin/Common/Defaults.pmのour $MUNIN_CONFDIRに書いてある
ことを知っている…と思うのですが、そんなことを知らない私は$Munin::Common::Defaults::MUNIN_CONFDIRがどこで定義されているかに悩みました。

/usr/local/share/perl5/を消す

$ find / -name Munin
したら
/usr/share/perl5/vendor_perl/Munin/Common/Defaults.pm
/usr/local/share/perl5/Munin/Common/Defaults.pm
の2つがひっかかりました。

前者には
our $MUNIN_CONFDIR    = q{/etc/munin};
後者には
our $MUNIN_CONFDIR    = q{/etc/opt/munin};
と書いてあったので、後者がいらないと分かりました。

もう一つのサーバーとディレクトリの構造を見比べたら、もう一つのサーバーには、そもそも/usr/local/share/perl5/がなかった…つまりmuninをソースからインストールしたときに作られたディレクトリでしたので、ディレクトリごと削除しました。
※ソースからインストールすると/use/localにいろいろ入るので、ここを見てみるべきでした…というか、make installしたときのログを見ればよかったのですが…


$ perl -e 'foreach(@INC){print "$_\n";}'
/usr/local/lib64/perl5
/usr/local/share/perl5
/usr/lib64/perl5/vendor_perl
/usr/share/perl5/vendor_perl
/usr/lib64/perl5
/usr/share/perl5

なので、 /usr/share/perl5/vendor_perlよりも、/usr/local/share/perl5の方を先読みするということも確認できました。

この後、もう少し紆余曲折があった(muninのVerが2系になっていて、今使っている1系のrpmがなかなか見つからなかった)のですが、最終的に/sbin/service munin-node startできるようになりました。

以上で3時間かかりました。


学んだこと
  • ソースからインストールするとアンインストールが大変
  • パッケージでインストールされたソフトの設定ではなく、ソースからインストールしたソフトの設定が優先されることがある
  • Perlを知らないと困ることがある
  • 簡単な作業でも眠いときに作業しない

CentOSでphpをインストールする場合に設定するEPELリポジトリのドメインの変更について

CentOSでphpやmysqlの最新版をインストールする場合、EPELリポジトリを設定します。
EPELリポジトリのドメインが変更になっていた(だいぶ前のようですが…) ので書いておきます。

旧:download.fedora.redhat.com
新:dl.fedoraproject.org

php5.4系の最新版をインストールする | レンタルサーバー・自宅サーバー設定・構築のヒントの記事で知りました。

すでにEPELリポジトリの設定がしてある場合は特に何かする必要は無い…と思います。ErogameScapeのサーバーは仕組みは分からないのですが、ちゃんとEPELリポジトリの最新の情報をftp.iij.ad.jpに取りに行ってました。

これからサーバーを新規構築する場合に気をつける項目かなと思います。

VMwareにCentOSをいれて日本語環境にして日本語入力できるようにする

VMwareにCentOS6をいれると簡易インストールと呼ばれるインストールの仕方になります。
※他のVerだとどうなるかわからないのでCentOS6と書いておきます。

実マシンにCentOS6をいれると、いろいろなことを聞かれる(パッケージは何をいれると等々)のですが、VMwareの簡易インストールの場合、何も聞かれないので、とりあえずインストールしてからいろいろ設定をする必要があります。

日本語環境にする
 → CentOS 6 - 日本語環境にする : Server World 

日本語入力できるようにする
 → Cent OS 6 で日本語入力 - The Serenity Prayer

VMwareをいれようと思った理由はPHP5.4が動く環境を作ろう!でした。
自分はそれなりにCentOSを使ってきたので、VMwareいれてOSインストールして、いつものサーバーの設定をしていけばいいかなーくらいに思っていたのですが、そうそううまくいかないもんだなあと思いました。

一度、そういうもんだと分かれば大丈夫ですが、慣れるまではやっぱりちょっと大変かなと思いました。

VMware便利ですね。

何個でも仮想サーバーが作れるので、パソコン1つで、たとえば複数台の冗長構成を作って障害があった場合にちゃんと切り替わるかの設定が正しいかとかの試験ができると思いました。
前にそんな設定の検証をしたときには実家から古いパソコンを2台持ってきてやってました…
便利な世の中になったものです…
記事検索