2020年5月31日日曜日

【製品比較】TP-LINK TL-SG108EとNETGEAR GS308Eを比較してみた!

最近では、3,000円台でVLAN設定ができるスイッチが販売されており、自宅では以前から「TP-LINK TL-SG108E」を使用している。

このスイッチとすごい見た目と機能が似ているスイッチとして「NETGEAR GS308E」があり気になっていた。

ちょうどスイッチがもう1つ必要だったので、買い足して比較してみた。

比較結果

以下に比較結果を記載する。NETGEAR GS308Eでは対応していない項目がいくつかあることから、「TP-LINK TL-SG108E」がおすすめとなる。

設定項目 TP-LINK TL-SG108E NETGEAR GS308E
価格 3,490円 (2016年購入時) 3,660円 (2020年購入時)
大きさ 158 x 101 x 25 mm 158 x 101 x 29 mm
重量 0.5kg 0.5kg
MACアドレステーブル 4K 4K
Buffer Size 192KB 192KB
Jumbo Frame 15K 9K
ユーザID変更 ×
バックアップ・リストア
工場出荷状態にリセット ● 管理画面・本体両方で可能
インタフェース管理 ● ポート単位でDisableが可能 × Disable不可
Port Statistics ● 受信/送信でエラーパケット確認が可能 ▲ 受信/送信の区別不可
LAG × 設定項目なし
IGMP Snooping
Loop検知
ポートミラーリング ● Ingress(受信)/Egress(送信)の選択が可能 ▲ 選択不可
ケーブルテスター
MTU VLAN × 設定項目なし
Port Based VLAN
802.1Q VLAN
帯域制御 ● 数値で指定 ▲ 512Kbps~512Mbpsの範囲のみ選択して設定可能
Storm Control ● UL-Frame/Multicast/Broadcastの指定が可能 ▲ Broadcastのみ

管理画面の比較

VLAN設定の管理画面で比較をしてみる。

VLAN設定は1画面で設定・確認できるようになっており、どのVLAN IDがどのポートにTagged/Untaggedで設定されているかわかるように表示される。

NETGEAR GS308E

VLAN設定は、まず「Basic」と「Advanced」に分かれている。

両方設定するのか、片方設定するのかさっそく分かりづらいが、これは「片方」しか設定できず、DisableをEnableにしようとすると、現在の設定が消去される旨の警告が表示される。

また、Tagged/Untaggedの設定は、VLAN IDを選択したうえで図示されたポートをクリックすることで設定することができる。

ただし、この設定を確認しようとすると、再度VLAN IDを選択して画面を表示させる必要がある。一覧表示する画面もあるのだが、残念ながらVLANに所属することしか確認できず、Tagged/Untaggedは表現されていない。

まとめ

すでに記載しているが、設定の豊富さ、管理画面の使いやすさ両方を考慮すると、「TP-LINK TL-SG108E」の選択が間違いないだろう。

2020年5月27日水曜日

【PowerCLI】ESXiのデータストアのアンマウントとパスの分離をコマンドで一気に実施する

vSphere環境でESXiからデータストアを取り外す際は、単純にアンマウントするだけではなく、「パスの分離」と呼ばれるSCSIデバイスの切断作業が必要となる。アンマウントはvSphere Clientを使えば全ESXiサーバで一気に実行することができるのでまだ負担が少ないが、パスの分離は、各ESXiサーバで実施する必要があり、作業負荷がかなり大きい作業となる。

そこで、以前からPowerCLIを使用することで一気にこの作業を実施できればよいと考えていたのだが、なかなか簡単にはできなさそうなので検証ができていなかったのだが、ようやくコマンドの調査と検証が終わったので、本記事にてPowerCLIを用いたアンマウントとパスの分離手順を記載する。

なお、手順検証はvSphere 6.7の環境で実施したが、データストア取り外し時にアンマウントとパスの分離を実施する手順自体は、vSphere 5.0の時代から続く作法となり、vSphere 6.7以前の環境でも利用できる可能性は高い。

環境

  • vCenter Server 6.7 Update 3b
  • ESXi 6.7 Update 3
  • PowerCLI 11.5

データストアのアンマウントとパスの分離手順

以下コマンドを上から順に実行すればよい。最初の変数は以下を指定する。
  • $dsLabel : アンマウント対象のデータストア名
  • $cluster : アンマウント対象のESXiが所属するクラスター名
# アンマウント対象のデータストアとクラスターを取得
$dsLabel = "MyDatastore"
$cluster = "MyCluster"

$ds = Get-Datastore $dsLabel
$vmfsUuid = (Get-View $ds).Info.Vmfs.Uuid
$lunUuid = (Get-View $ds).Info.Vmfs.Extent[0].DiskName

# 実行対象のESXi情報を取得
$vmhost = Get-Cluster $cluster | Get-VMHost

# アンマウント及びパスの分離を実行
$storSys = Get-View $vmhost.ExtensionData.ConfigManager.StorageSystem
$storSys.UnmountVmfsVolume($vmfsUuid)
$storSys.DetachScsiLun($lunUuid)
ストレージ側でLUNの削除または切断したのち、以下コマンドで「HBAデバイスのスキャン」と「VMFSボリュームのスキャン」を実施すれば、アンマウントしたデータストアは問題なくvSphere上から消えるはずだ。
Get-VMHost | Get-VMHostStorage -RescanAllHba -RescanVmfs

参考

2020年5月24日日曜日

Zabbix 5.0でGmailによるメール通知を行う手順

以前、以下記事でZabbix 3.0にてGmailによるメール通知の設定手順を記載した。

設定の流れは大きく変わっていなかったが、細かいところで手順に差異があったので、Zabbix 5.0におけるGmailによるメール障害通知を設定する手順を記載する。

設定概要

設定箇所が多いので、前回と同様、概要図を記載する。

  1. メディアタイプ:通知手段(メール、スクリプト、SMSなど)を設定。メールのメッセージ内容もメディアタイプで設定する
  2. ユーザのメディア:通知先メールアドレスと使用するメディアタイプを設定する。
  3. アクション:障害検知時の通知条件と通知するユーザを設定する。

Gmailによる障害通知設定方法

1. メディアタイプを作成

メディアタイプとは通知手段の設定となるが、Gmail送信用のメディアタイプは設定されていないので、新規に作成する。「管理」→「メディアタイプ」を選択し、「メディアタイプの作成」ボタンを押下し、以下の通り作成する。

  • 名前:Gmail
  • タイプ:メール
  • vSMTPサーバー:smtp.gmail.com
  • SMTPサーバーポート番号:465
  • SMTP helo:smtp.gmail.com
  • 送信元メールアドレス:<送信に用いるGmailアカウント>@gmail.com
  • 接続セキュリティ:SSL/TLS
  • 認証:ユーザー名とパスワード
  • ユーザー名:<送信に用いるGmailアカウント> ※「@gmail.com」は不要
  • パスワード:<送信に用いるGmailアカウントのパスワード>
  • メッセージフォーマット:HTML (プレーンテキストでも可。お好みで選択)
  • 有効:チェック

Zabbix 3.0と異なり、Zabbix 5.0ではメディアタイプで送信されるメールのメッセージ内容を設定する。「メッセージテンプレート」タブを選択し、「追加」を選択し、以下設定をする。今回はとりあえず、メッセージはデフォルトのままとした。

  • メッセージタイプ:障害
  • 件名:Problem: {EVENT.NAME}
  • メッセージ:<b>Problem started</b> at {EVENT.TIME} on {EVENT.DATE}<br><b>Problem name:</b> {EVENT.NAME}<br><b>Host:</b> {HOST.NAME}<br><b>Severity:</b> {EVENT.SEVERITY}<br><b>Operational data:</b> {EVENT.OPDATA}<br><b>Original problem ID:</b> {EVENT.ID}<br>{TRIGGER.URL}

2. ユーザのメディアを作成

作成したメディアタイプを使って、メディアを作成する。今回はAdminユーザーに対してメディアを作成することとした。

「管理→「ユーザー」→「Admin」→「メディア」タブに移動し、「追加」を選択して以下の通り設定する。

  • タイプ:Gmail
  • 送信先:<送信先のメールアドレス>
  • 有効な時間帯:1-7,00:00-24:00
  • 指定した深刻度のときに使用:すべてチェック
  • 有効:チェック

3. アクションを作成

最後にアクションを設定する。「設定」→「アクション」を選択し、「アクションの作成」ボタンを押下し作成する。

「アクション」タブでは以下の通り設定した。トリガーの深刻度の条件は、監視設計に応じて適切に設定すること。

  • 名前:Send Gmail
  • 計算のタイプ:And
  • 実行条件:
    • メンテナンス期間外 (「メンテナンス期間中」を「いいえ」で設定)
    • トリガーの深刻度 以上 _軽度の障害
  • 有効:チェック

「実行内容」タブでは、以下の通り設定する。実行条件が満たされた際に、AdminユーザーのGmail送信のメディアを使ってメール送信を行う設定となる。

  • 実行内容のタイプ:メッセージの送信
  • ユーザーに送信:Admin
  • 次のメディアのみ使用:Gmail

以上で設定は完了となる。

障害通知テスト

SNMP Trapにて障害を発生させると、ダッシュボードにて「アクション」が実行されたことが確認できる。オレンジで実行中、灰色で実行済み、赤で失敗を示す。

Gmail経由でメールが送信されることが確認できた。以下は、スマホのGmailアプリで確認したメール内容であり、HTMLメールなので各項目名が太字になっていることがわかる。


2020年5月20日水曜日

Zabbix 5.0.0rc1 (リリース候補版) を正式版にバージョンアップしてみた

先日Zabbix 5,0.0rc1 (リリース候補版) がリリースされたが、その後の2020年5月12日に正式にZabbix 5.0がリリースされたので、正式版にバージョンアップした。

バージョンアップは、10分で完了する。バージョンアップ手順を本記事では記載する。

バージョンアップ手順

まずは、zabbix-releaseをバージョンアップする。

# rpm -Uvh https://repo.zabbix.com/zabbix/5.0/rhel/8/x86_64/zabbix-release-5.0-1.el8.noarch.rpm
https://repo.zabbix.com/zabbix/5.0/rhel/8/x86_64/zabbix-release-5.0-1.el8.noarch.rpm を取得中
Verifying...                          ################################# [100%]
準備しています...              ################################# [100%]
更新中 / インストール中...
   1:zabbix-release-5.0-1.el8         ################################# [100%]

zabbix-releaseを更新した後でdnf check-updateでアップデートを確認すると、「5.0.0」のバージョンが利用可能になっていることがわかる。

# dnf check-update
Zabbix Official Repository - x86_64              29 kB/s |  14 kB     00:00

zabbix-agent.x86_64                         5.0.0-1.el8                   zabbix
zabbix-apache-conf.noarch                   5.0.0-1.el8                   zabbix
zabbix-server-mysql.x86_64                  5.0.0-1.el8                   zabbix
zabbix-web.noarch                           5.0.0-1.el8                   zabbix
zabbix-web-japanese.noarch                  5.0.0-1.el8                   zabbix
zabbix-web-mysql.noarch                     5.0.0-1.el8                   zabbix

あとは、dnf updateで正式版にバージョンアップする。

# dnf update -y
メタデータの期限切れの最終確認: 0:00:47 時間前の 2020年05月12日 19時49分55秒 に 実施しました。
依存関係が解決しました。
================================================================================
 パッケージ                Arch         バージョン           リポジトリー サイズ
================================================================================
アップグレード:
 zabbix-agent              x86_64       5.0.0-1.el8          zabbix       453 k
 zabbix-apache-conf        noarch       5.0.0-1.el8          zabbix        16 k
 zabbix-server-mysql       x86_64       5.0.0-1.el8          zabbix       2.6 M
 zabbix-web                noarch       5.0.0-1.el8          zabbix       3.0 M
 zabbix-web-japanese       noarch       5.0.0-1.el8          zabbix        16 k
 zabbix-web-mysql          noarch       5.0.0-1.el8          zabbix        15 k

トランザクションの概要
================================================================================
アップグレード  6 パッケージ

ダウンロードサイズの合計: 6.1 M
パッケージのダウンロード:
(1/6): zabbix-apache-conf-5.0.0-1.el8.noarch.rp  46 kB/s |  16 kB     00:00
(2/6): zabbix-agent-5.0.0-1.el8.x86_64.rpm      575 kB/s | 453 kB     00:00
(3/6): zabbix-web-japanese-5.0.0-1.el8.noarch.r 141 kB/s |  16 kB     00:00
(4/6): zabbix-web-mysql-5.0.0-1.el8.noarch.rpm  135 kB/s |  15 kB     00:00
(5/6): zabbix-server-mysql-5.0.0-1.el8.x86_64.r 2.3 MB/s | 2.6 MB     00:01
(6/6): zabbix-web-5.0.0-1.el8.noarch.rpm        3.1 MB/s | 3.0 MB     00:00
--------------------------------------------------------------------------------
合計                                            4.6 MB/s | 6.1 MB     00:01
トランザクションの確認を実行中
トランザクションの確認に成功しました。
トランザクションのテストを実行中
トランザクションのテストに成功しました。
トランザクションを実行中
  準備             :                                                        1/1
  scriptletの実行中: zabbix-web-mysql-5.0.0-1.el8.noarch                    1/1
  アップグレード中 : zabbix-web-mysql-5.0.0-1.el8.noarch                   1/12
  アップグレード中 : zabbix-web-5.0.0-1.el8.noarch                         2/12
  scriptletの実行中: zabbix-web-5.0.0-1.el8.noarch                         2/12
  アップグレード中 : zabbix-apache-conf-5.0.0-1.el8.noarch                 3/12
  scriptletの実行中: zabbix-apache-conf-5.0.0-1.el8.noarch                 3/12
  アップグレード中 : zabbix-web-japanese-5.0.0-1.el8.noarch                4/12
  scriptletの実行中: zabbix-web-japanese-5.0.0-1.el8.noarch                4/12
  scriptletの実行中: zabbix-server-mysql-5.0.0-1.el8.x86_64                5/12
  アップグレード中 : zabbix-server-mysql-5.0.0-1.el8.x86_64                5/12
  scriptletの実行中: zabbix-server-mysql-5.0.0-1.el8.x86_64                5/12
  scriptletの実行中: zabbix-agent-5.0.0-1.el8.x86_64                       6/12
  アップグレード中 : zabbix-agent-5.0.0-1.el8.x86_64                       6/12
  scriptletの実行中: zabbix-agent-5.0.0-1.el8.x86_64                       6/12
  scriptletの実行中: zabbix-web-japanese-5.0.0-0.7rc1.el8.noarch           7/12
  整理             : zabbix-web-japanese-5.0.0-0.7rc1.el8.noarch           7/12
  整理             : zabbix-apache-conf-5.0.0-0.7rc1.el8.noarch            8/12
  scriptletの実行中: zabbix-web-5.0.0-0.7rc1.el8.noarch                    9/12
  整理             : zabbix-web-5.0.0-0.7rc1.el8.noarch                    9/12
  整理             : zabbix-web-mysql-5.0.0-0.7rc1.el8.noarch             10/12
  scriptletの実行中: zabbix-server-mysql-5.0.0-0.7rc1.el8.x86_64          11/12
  整理             : zabbix-server-mysql-5.0.0-0.7rc1.el8.x86_64          11/12
  scriptletの実行中: zabbix-server-mysql-5.0.0-0.7rc1.el8.x86_64          11/12
  scriptletの実行中: zabbix-agent-5.0.0-0.7rc1.el8.x86_64                 12/12
  整理             : zabbix-agent-5.0.0-0.7rc1.el8.x86_64                 12/12
  scriptletの実行中: zabbix-agent-5.0.0-0.7rc1.el8.x86_64                 12/12
  scriptletの実行中: zabbix-agent-5.0.0-1.el8.x86_64                      12/12
  scriptletの実行中: zabbix-agent-5.0.0-0.7rc1.el8.x86_64                 12/12
  検証             : zabbix-agent-5.0.0-1.el8.x86_64                       1/12
  検証             : zabbix-agent-5.0.0-0.7rc1.el8.x86_64                  2/12
  検証             : zabbix-apache-conf-5.0.0-1.el8.noarch                 3/12
  検証             : zabbix-apache-conf-5.0.0-0.7rc1.el8.noarch            4/12
  検証             : zabbix-server-mysql-5.0.0-1.el8.x86_64                5/12
  検証             : zabbix-server-mysql-5.0.0-0.7rc1.el8.x86_64           6/12
  検証             : zabbix-web-5.0.0-1.el8.noarch                         7/12
  検証             : zabbix-web-5.0.0-0.7rc1.el8.noarch                    8/12
  検証             : zabbix-web-japanese-5.0.0-1.el8.noarch                9/12
  検証             : zabbix-web-japanese-5.0.0-0.7rc1.el8.noarch          10/12
  検証             : zabbix-web-mysql-5.0.0-1.el8.noarch                  11/12
  検証             : zabbix-web-mysql-5.0.0-0.7rc1.el8.noarch             12/12

アップグレード済み:
  zabbix-agent-5.0.0-1.el8.x86_64         zabbix-apache-conf-5.0.0-1.el8.noarch
  zabbix-server-mysql-5.0.0-1.el8.x86_64  zabbix-web-5.0.0-1.el8.noarch
  zabbix-web-japanese-5.0.0-1.el8.noarch  zabbix-web-mysql-5.0.0-1.el8.noarch

完了しました!

以上!

2020年5月18日月曜日

iSCSI + DM-multipathで冗長構成を組んだ際の、障害時のパス切り替わり動作を確認してみた

先日、DM-multipathを使ってマルチパス構成のiSCSIストレージを認識させる手順を記載した。
マルチパス構成となっているため、片方のパスがダウンしたとしても、問題なくI/Oができる。実際にパスが切り替わる際の動作確認をしてみた。

環境

  • OS:Red Hat Enterprise Linux 7.6
  • iSCSIターゲット:QNAP NAS
  • iSCSIディスク:5GB、2GB、1GBの3つ


監視設定を確認する

iSCSI設定

RHELのiSCSIイニシエータは、pingによるターゲットの状態監視を行う。以下2つのパラメータで時間が設定されている。デフォルトでは5秒間隔でpingを行い、5秒間応答がないとエラーとして検知する。
パラメータ 内容 デフォルト値
timeo.noop_out_interval ping監視間隔 5秒
timeo.noop_out_timeout ping監視タイムアウト 5秒
実際の設定は、/etc/iscsi/iscsid.confに記載されている。
# cat /etc/iscsi/iscsid.conf | grep "noop_out"
node.conn[0].timeo.noop_out_interval = 5
node.conn[0].timeo.noop_out_timeout = 5

DM-multipath設定

DM-multipathでは、以下2つのパラメータでストレージデバイスの監視を行う。最初は5秒間隔でポーリングを行い、徐々に間隔を増加させ、最終的には4倍の20秒間隔でポーリングするよう動作するらしい。パスのチェック方式はストレージごとに設定が異なるので注意。
パラメータ 内容 デフォルト値
polling_interval 初期ポーリング間隔 5秒
max_polling_interval 最大ポーリング間隔 5秒 x 4倍 = 20秒
path_checker パスチェック方式 directio (直接I/Oを行い最初のセクタ読み取りを行う)
実際の設定は、multipath -tコマンドで確認できる。下記はポーリング間隔設定を確認したコマンド例となる。
# multipath -t | grep interval
        polling_interval 5
        max_polling_interval 20

サーバ側のNIC切断時

まずは、サーバ側のNIC切断時に、どのようにパスが切り替わるかを確認してみることにする。
通常状態は以下のように「ready」ステータスとなる。
# multipath -ll mpathc
mpathc (36e843b6ffaab030d3806d4741db0c1d5) dm-3 QNAP    ,iSCSI Storage
size=1.0G features='0' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=50 status=active
  |- 35:0:0:2 sdd 8:48 active ready running
  `- 36:0:0:2 sde 8:64 active ready running
サーバ側のNICを切断する。undef→faultyとステータスが遷移する。
# multipath -ll mpathc
mpathc (36e843b6ffaab030d3806d4741db0c1d5) dm-3 QNAP    ,iSCSI Storage
size=1.0G features='0' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=50 status=active
  |- 35:0:0:2 sdd 8:48 active undef running
  `- 36:0:0:2 sde 8:64 active ready running

# multipath -ll mpathc
mpathc (36e843b6ffaab030d3806d4741db0c1d5) dm-3 QNAP    ,iSCSI Storage
size=1.0G features='0' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=50 status=active
  |- 35:0:0:2 sdd 8:48 failed faulty running
  `- 36:0:0:2 sde 8:64 active ready running
tail -f /var/log/messagesを実行し、NW切断時の挙動を確認してみる。以下ような動作をしていることがわかる。iSCSIは約5秒でping監視エラーを検知し、DM-multipathはストレージデバイスによって検知時間が異なるようだが、いずれも最大11秒でパスダウンを検知しているようだ。
  • 15:01:50 OSがLink Down検知
  • 15:01:56 DM-multipathがmpathaのストレージデバイスのパスダウンを検知
  • 15:01:56 iSCSIのping監視エラーを検知
  • 15:02:01 DM-multipathがmpathbとmpathcのストレージデバイスのパスダウンを検知
Mar 21 15:01:50 localhost kernel: vmxnet3 0000:13:00.0 ens224: NIC Link is Down
Mar 21 15:01:56 localhost multipathd: mpatha: sdc - readsector0 checker reports path is down
Mar 21 15:01:56 localhost multipathd: checker failed path 8:32 in map mpatha
Mar 21 15:01:56 localhost multipathd: mpatha: remaining active paths: 1
Mar 21 15:01:56 localhost kernel: connection3:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4379116259, last ping 4379121264, now 4379126272
Mar 21 15:01:56 localhost kernel: connection3:0: detected conn error (1022)
Mar 21 15:01:56 localhost kernel: connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4379116259, last ping 4379121264, now 4379126272
Mar 21 15:01:56 localhost kernel: connection1:0: detected conn error (1022)
Mar 21 15:01:56 localhost kernel: device-mapper: multipath: Failing path 8:32.
Mar 21 15:01:56 localhost iscsid: Kernel reported iSCSI connection 3:0 error (1022 - Invalid or unknown error code) state (3)
Mar 21 15:01:56 localhost iscsid: Kernel reported iSCSI connection 1:0 error (1022 - Invalid or unknown error code) state (3)
Mar 21 15:02:01 localhost multipathd: mpathb: sdf - readsector0 checker reports path is down
Mar 21 15:02:01 localhost multipathd: checker failed path 8:80 in map mpathb
Mar 21 15:02:01 localhost multipathd: mpathb: remaining active paths: 1
Mar 21 15:02:01 localhost kernel: session3: session recovery timed out after 5 secs
Mar 21 15:02:01 localhost kernel: sd 35:0:0:1: rejecting I/O to offline device
Mar 21 15:02:01 localhost kernel: sd 35:0:0:1: [sdf] killing request
Mar 21 15:02:01 localhost kernel: device-mapper: multipath: Failing path 8:80.
Mar 21 15:02:01 localhost kernel: device-mapper: multipath: Failing path 8:48.
Mar 21 15:02:01 localhost multipathd: checker failed path 8:48 in map mpathc
Mar 21 15:02:01 localhost multipathd: mpathc: remaining active paths: 1
NICを接続すると、即座にパスが復旧する。
# multipath -ll mpathc
mpathc (36e843b6ffaab030d3806d4741db0c1d5) dm-3 QNAP    ,iSCSI Storage
size=1.0G features='0' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=50 status=active
  |- 35:0:0:2 sdd 8:48 active ready running
  `- 36:0:0:2 sde 8:64 active ready running
パス復旧時の挙動も再度ログから確認してみる。
  • 15:03:02 OSがLink Up検知
  • 15:03:06 DM-multipathがmpatha、mpathb、mpathcのストレージデバイスのパス復旧を検知
  • 15:03:06 iSCSIの接続復旧を検知
Mar 21 15:03:02 localhost kernel: vmxnet3 0000:13:00.0 ens224: NIC Link is Up 10000 Mbps
Mar 21 15:03:02 localhost NetworkManager[5551]: <info>  [1584770582.1065] device (ens224): carrier: link connected
Mar 21 15:03:03 localhost iscsid: connect to 192.168.33.13:3260 failed (No route to host)
Mar 21 15:03:03 localhost iscsid: connect to 192.168.33.13:3260 failed (No route to host)
Mar 21 15:03:06 localhost multipathd: mpatha: sdc - readsector0 checker reports path is up
Mar 21 15:03:06 localhost multipathd: 8:32: reinstated
Mar 21 15:03:06 localhost multipathd: mpatha: remaining active paths: 2
Mar 21 15:03:06 localhost kernel: device-mapper: multipath: Reinstating path 8:32.
Mar 21 15:03:06 localhost kernel: device-mapper: multipath: Reinstating path 8:80.
Mar 21 15:03:06 localhost multipathd: mpathb: sdf - readsector0 checker reports path is up
Mar 21 15:03:06 localhost multipathd: 8:80: reinstated
Mar 21 15:03:06 localhost multipathd: mpathb: remaining active paths: 2
Mar 21 15:03:06 localhost kernel: device-mapper: multipath: Reinstating path 8:48.
Mar 21 15:03:06 localhost multipathd: mpathc: sdd - readsector0 checker reports path is up
Mar 21 15:03:06 localhost multipathd: 8:48: reinstated
Mar 21 15:03:06 localhost multipathd: mpathc: remaining active paths: 2
Mar 21 15:03:06 localhost iscsid: connection3:0 is operational after recovery (8 attempts)
Mar 21 15:03:06 localhost iscsid: connection1:0 is operational after recovery (9 attempts)

ストレージ側のNIC切断

NW切断時の挙動を確認してみる。以下ような動作をしていることがわかる。
  • 14:57:36 iSCSIのping監視エラーを検知
  • 14:57:36 DM-multipathがmpathaのストレージデバイスのパスダウンを検知
  • 14:57:41 DM-multipathがmpathbとmpathcのストレージデバイスのパスダウンを検知
Mar 21 14:57:36 localhost kernel: connection3:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4378856640, last ping 4378861648, now 4378866656
Mar 21 14:57:36 localhost kernel: connection3:0: detected conn error (1022)
Mar 21 14:57:36 localhost kernel: device-mapper: multipath: Failing path 8:32.
Mar 21 14:57:36 localhost multipathd: mpatha: sdc - readsector0 checker reports path is down
Mar 21 14:57:36 localhost multipathd: checker failed path 8:32 in map mpatha
Mar 21 14:57:36 localhost multipathd: mpatha: remaining active paths: 1
Mar 21 14:57:36 localhost iscsid: Kernel reported iSCSI connection 3:0 error (1022 - Invalid or unknown error code) state (3)
Mar 21 14:57:36 localhost kernel: connection1:0: ping timeout of 5 secs expired, recv timeout 5, last rx 4378856760, last ping 4378861776, now 4378866784
Mar 21 14:57:36 localhost kernel: connection1:0: detected conn error (1022)
Mar 21 14:57:37 localhost iscsid: Kernel reported iSCSI connection 1:0 error (1022 - Invalid or unknown error code) state (3)
Mar 21 14:57:41 localhost multipathd: mpathb: sdf - readsector0 checker reports path is down
Mar 21 14:57:41 localhost kernel: session3: session recovery timed out after 5 secs
Mar 21 14:57:41 localhost kernel: sd 35:0:0:1: rejecting I/O to offline device
Mar 21 14:57:41 localhost kernel: sd 35:0:0:1: [sdf] killing request
Mar 21 14:57:41 localhost kernel: device-mapper: multipath: Failing path 8:80.
Mar 21 14:57:41 localhost kernel: device-mapper: multipath: Failing path 8:48.
Mar 21 14:57:41 localhost multipathd: checker failed path 8:80 in map mpathb
Mar 21 14:57:41 localhost multipathd: mpathb: remaining active paths: 1
Mar 21 14:57:41 localhost multipathd: checker failed path 8:48 in map mpathc
Mar 21 14:57:41 localhost multipathd: mpathc: remaining active paths: 1
パス復旧時の挙動も再度ログから確認してみる。
  • 14:58:09 iSCSIの接続復旧を検知
  • 14:58:11 DM-multipathがmpatha、mpathb、mpathcのストレージデバイスのパス復旧を検知
Mar 21 14:58:09 localhost iscsid: connection3:0 is operational after recovery (3 attempts)
Mar 21 14:58:09 localhost iscsid: connection1:0 is operational after recovery (3 attempts)
Mar 21 14:58:11 localhost multipathd: mpatha: sdc - readsector0 checker reports path is up
Mar 21 14:58:11 localhost kernel: device-mapper: multipath: Reinstating path 8:32.
Mar 21 14:58:11 localhost multipathd: 8:32: reinstated
Mar 21 14:58:11 localhost multipathd: mpatha: remaining active paths: 2
Mar 21 14:58:11 localhost multipathd: mpathb: sdf - readsector0 checker reports path is up
Mar 21 14:58:11 localhost multipathd: 8:80: reinstated
Mar 21 14:58:11 localhost multipathd: mpathb: remaining active paths: 2
Mar 21 14:58:11 localhost kernel: device-mapper: multipath: Reinstating path 8:80.
Mar 21 14:58:11 localhost kernel: device-mapper: multipath: Reinstating path 8:48.
Mar 21 14:58:11 localhost multipathd: mpathc: sdd - readsector0 checker reports path is up
Mar 21 14:58:11 localhost multipathd: 8:48: reinstated
Mar 21 14:58:11 localhost multipathd: mpathc: remaining active paths: 2

参考

2020年5月13日水曜日

iSCSI + DM-multipathを使ってRHELにiSCSIストレージを認識させる

以前Windowsでは以下記事にてiSCSIイニシエータの設定手順を記載している。
今回はRHELにおいて、iSCSIイニシエータの設定を行いiSCSIストレージを認識させ、さらにDM-multipathを使ったマルチパス設定の手順検証をしてみた。

環境

  • OS:Red Hat Enterprise Linux 7.6
  • iSCSIターゲット:QNAP NAS
  • iSCSIディスク:5GB、2GB、1GBの3つ



iSCSI (iscsi-initiator-utils) の設定

1. 「iscsi-initiator-utils」をインストール

RHELでiSCSIを認識させるため、「iscsi-initiator-utils」をインストールする。「iscsi-initiator-utils」を使うためには、iscsi-initiator-utilsとiscsi-initiator-utils-iscsiuioの2つのパッケージをインストールする必要がある。
# rpm -ivh iscsi-initiator-utils-6.2.0.874-10.el7.x86_64.rpm iscsi-initiator-utils-iscsiuio-6.2.0.874-10.el7.x86_64.rpm
準備しています...              ################################# [100%]
更新中 / インストール中...
   1:iscsi-initiator-utils-iscsiuio-6.################################# [ 50%]
   2:iscsi-initiator-utils-6.2.0.874-1################################# [100%]

2. イニシエータのiqnの確認

イニシエータのiqnは/etc/iscsi/initiatorname.iscsiに記載される。これを確認し必要に応じて修正して、ストレージ側でアクセス許可を設定しておく。
# cat /etc/iscsi/initiatorname.iscsi
InitiatorName=iqn.1994-05.com.redhat:9122a7a91a1
なお、今回はQNAPでiSCSIターゲットの設定をしているが、手順は割愛する。

3. ターゲットを登録

iSCSIの各種設定はiscsiadmコマンドで行う。
まずは、ターゲットの検出を行う。-t stは「sendtargets」の略となり、-pでターゲットのIPアドレスを指定する。
# iscsiadm -m discovery -t st -p 192.168.11.13
192.168.33.13:3260,1 iqn.2004-04.com.qnap:ts-231p:iscsi.t3013qnap.06d5ba
192.168.11.13:3260,1 iqn.2004-04.com.qnap:ts-231p:iscsi.t3013qnap.06d5ba
192.168.33.13:3260,1 iqn.2004-04.com.qnap:ts-231p:iscsi.target.06d5ba
192.168.11.13:3260,1 iqn.2004-04.com.qnap:ts-231p:iscsi.target.06d5ba
登録されたターゲットの確認コマンドはiscsiadm -m nodeとなる。
# iscsiadm -m node
192.168.33.13:3260,1 iqn.2004-04.com.qnap:ts-231p:iscsi.t3013qnap.06d5ba
192.168.11.13:3260,1 iqn.2004-04.com.qnap:ts-231p:iscsi.t3013qnap.06d5ba
192.168.33.13:3260,1 iqn.2004-04.com.qnap:ts-231p:iscsi.target.06d5ba
192.168.11.13:3260,1 iqn.2004-04.com.qnap:ts-231p:iscsi.target.06d5ba

4. ターゲットにログイン

iscsiサービスはターゲットが登録されていない場合、起動しない設定となっている。
# systemctl status iscsi
● iscsi.service - Login and scanning of iSCSI devices
   Loaded: loaded (/usr/lib/systemd/system/iscsi.service; enabled; vendor preset: disabled)
   Active: inactive (dead)
Condition: start condition failed at 金 2020-03-20 14:43:08 JST; 6min ago
           none of the trigger conditions were met
     Docs: man:iscsid(8)
           man:iscsiadm(8)
ターゲット登録後はiscsiサービスを起動させることができる。iscsiサービスを起動すると、登録されたターゲットに自動ログインする。
# systemctl start iscsi
# systemctl status iscsi
● iscsi.service - Login and scanning of iSCSI devices
   Loaded: loaded (/usr/lib/systemd/system/iscsi.service; enabled; vendor preset: disabled)
   Active: active (exited) since 金 2020-03-20 14:50:30 JST; 1s ago
     Docs: man:iscsid(8)
           man:iscsiadm(8)
  Process: 16041 ExecStart=/sbin/iscsiadm -m node --loginall=automatic (code=exited, status=0/SUCCESS)
  Process: 16038 ExecStart=/usr/libexec/iscsi-mark-root-nodes (code=exited, status=0/SUCCESS)
 Main PID: 16041 (code=exited, status=0/SUCCESS)
   CGroup: /system.slice/iscsi.service

 3月 20 14:50:30 localhost.localdomain iscsi-mark-root-nodes[16038]: iscsiad...
 3月 20 14:50:30 localhost.localdomain systemd[1]: Started Login and scannin...
 3月 20 14:50:30 localhost.localdomain iscsiadm[16041]: Logging in to [iface...
~(以下略)~
ターゲットへのログイン状態の確認コマンドはiscsiadm -m sessionとなる。
# iscsiadm -m session
tcp: [1] 192.168.33.13:3260,1 iqn.2004-04.com.qnap:ts-231p:iscsi.t3013qnap.06d5ba (non-flash)
tcp: [2] 192.168.11.13:3260,1 iqn.2004-04.com.qnap:ts-231p:iscsi.t3013qnap.06d5ba (non-flash)
tcp: [3] 192.168.33.13:3260,1 iqn.2004-04.com.qnap:ts-231p:iscsi.target.06d5ba (non-flash)
tcp: [4] 192.168.11.13:3260,1 iqn.2004-04.com.qnap:ts-231p:iscsi.target.06d5ba (non-flash)

5, ディスクの認識状況を確認

OSにてiSCSIのディスクを認識するはずなので、ログから確認しておく。今回の環境では、3つのディスクが2パスのマルチパス構成となっていることから、sdb、sdc、sdd、sde、sdf、sdgの計6個のディスクが認識される。
# cat /var/log/messages | grep SCSI
~(中略)~
Mar 20 14:50:30 localhost kernel: scsi 35:0:0:0: Direct-Access     QNAP     iSCSI Storage    4.0  PQ: 0 ANSI: 5
Mar 20 14:50:30 localhost kernel: scsi 36:0:0:0: Direct-Access     QNAP     iSCSI Storage    4.0  PQ: 0 ANSI: 5
Mar 20 14:50:30 localhost kernel: scsi 35:0:0:2: Direct-Access     QNAP     iSCSI Storage    4.0  PQ: 0 ANSI: 5
Mar 20 14:50:30 localhost kernel: scsi 36:0:0:2: Direct-Access     QNAP     iSCSI Storage    4.0  PQ: 0 ANSI: 5
Mar 20 14:50:30 localhost kernel: scsi 35:0:0:1: Direct-Access     QNAP     iSCSI Storage    4.0  PQ: 0 ANSI: 5
Mar 20 14:50:30 localhost kernel: scsi 36:0:0:1: Direct-Access     QNAP     iSCSI Storage    4.0  PQ: 0 ANSI: 5
Mar 20 14:50:30 localhost systemd: Started Login and scanning of iSCSI devices.
Mar 20 14:50:30 localhost kernel: sd 36:0:0:1: [sdg] Attached SCSI disk
Mar 20 14:50:30 localhost kernel: sd 35:0:0:1: [sdf] Attached SCSI disk
Mar 20 14:50:30 localhost kernel: sd 36:0:0:2: [sde] Attached SCSI disk
Mar 20 14:50:30 localhost kernel: sd 35:0:0:2: [sdd] Attached SCSI disk
Mar 20 14:50:31 localhost kernel: sd 36:0:0:0: [sdc] Attached SCSI disk
Mar 20 14:50:31 localhost kernel: sd 35:0:0:0: [sdb] Attached SCSI disk

マルチパス (DM-multipath) の設定

ここまでの手順でiSCSIのディスクを認識させることができたが、同一ディスクを複数ディスクとして認識してしまっているため、「DM-multipath」にてマルチパス設定を行う。

1. 「DM-multipath」をインストール

# rpm -vih device-mapper-multipath-0.4.9-123.el7.x86_64.rpm device-mapper-multipath-libs-0.4.9-123.el7.x86_64.rpm
準備しています...              ################################# [100%]
更新中 / インストール中...
   1:device-mapper-multipath-libs-0.4.################################# [ 50%]
   2:device-mapper-multipath-0.4.9-123################################# [100%]

2. multipath.confを作成

# multipath -ll
Mar 20 15:19:50 | DM multipath kernel driver not loaded
Mar 20 15:19:50 | /etc/multipath.conf does not exist, blacklisting all devices.
Mar 20 15:19:50 | A default multipath.conf file is located at
Mar 20 15:19:50 | /usr/share/doc/device-mapper-multipath-0.4.9/multipath.conf
Mar 20 15:19:50 | You can run /sbin/mpathconf --enable to create
Mar 20 15:19:50 | /etc/multipath.conf. See man mpathconf(8) for more details
Mar 20 15:19:50 | DM multipath kernel driver not loaded
# ls -l /etc/multipath.conf
ls: /etc/multipath.conf にアクセスできません: そのようなファイルやディレクトリはありません

# mpathconf --enable --with_multipathd y

# ls -l /etc/multipath.conf
-rw-------. 1 root root 2415  3月 20 15:27 /etc/multipath.conf

3. ストレージ用の設定をmultipath.confに追記

大抵のストレージにおいてはDM-multipathの推奨設定が公開されており、必要とされる場合はmultipath.confに設定を追記する必要がある。なお、DM-multipathに設定済みのストレージも多数あり、その設定はmultipath -tにて確認できる。例えばNetAppの設定が組み込み済みであることが、以下の通り確認できる。
[root@localhost ~]# multipath -t
~(中略)~

        device {
                vendor "NETAPP"
                product "LUN.*"
                path_grouping_policy "group_by_prio"
                path_checker "tur"
                features "3 queue_if_no_path pg_init_retries 50"
                hardware_handler "0"
                prio "ontap"
                failback immediate
                rr_weight "uniform"
                rr_min_io 128
                flush_on_last_del "yes"
                dev_loss_tmo "infinity"
                user_friendly_names no
                retain_attached_hw_handler yes
                detect_prio yes
        }

~(以下略)~
QNAPの場合は、以下URLに推奨されるマルチパス設定が記載されている。
ただし、上記はdefaults設定を書き換える手順となっているため、少し修正して、QNAPのストレージのみに設定がされるよう、以下の通りdevice設定を追加する。
# cat /etc/multipath.conf | grep -v -e "^#" -e "^$"
~(中略)~

devices {
        device {
                vendor                  "QNAP"
                product                 "iSCSI Storage"
                user_friendly_names     yes
                path_selector           "round-robin 0"
                path_grouping_policy    multibus
                uid_attribute           ID_SERIAL
                prio                    alua
                path_checker            readsector0
                rr_min_io               100
                rr_weight               priorities
                failback                immediate
                no_path_retry           fail
        }
}

~(以下略)~

4. 設定反映

設定反映のため、DM-multipathのサービスを再起動する。
# systemctl restart multipathd
通常これだけで、マルチパスのディスクを自動認識するはずだ。以下の通り、mpatha、mpathb、mpathcの3つのiSCSIディスクを認識していることがわかる。
# multipath -ll
mpathc (36e843b6ffaab030d3806d4741db0c1d5) dm-3 QNAP    ,iSCSI Storage
size=1.0G features='0' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=50 status=active
  |- 35:0:0:2 sdd 8:48 active ready running
  `- 36:0:0:2 sde 8:64 active ready running
mpathb (36e843b658a5009cd6630d4824d923fde) dm-4 QNAP    ,iSCSI Storage
size=2.0G features='0' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=50 status=active
  |- 35:0:0:1 sdf 8:80 active ready running
  `- 36:0:0:1 sdg 8:96 active ready running
mpatha (36e843b6fcf19e40dadaed44f9d978ad1) dm-2 QNAP    ,iSCSI Storage
size=5.0G features='0' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=50 status=active
  |- 35:0:0:0 sdc 8:32 active ready running
  `- 36:0:0:0 sdb 8:16 active ready running

5. ファイルシステムのとしてフォーマット

後は通常のディスクと同様、パーティションを作成し、ファイルシステムとしてフォーマットする。指定するストレージデバイスは、/dev/mapper/mpathN (Nはアルファベット連番(a,b,c,…)) となる。
以前記載した以下記事通りに作成すればよい。
# dev="/dev/mapper/mpathc"
# parted -s ${dev} "mklabel gpt mkpart ' ' 0% 100% set 1 lvm on print"
モデル: Linux device-mapper (multipath) (dm)
ディスク /dev/mapper/mpathc: 1074MB
セクタサイズ (論理/物理): 512B/512B
パーティションテーブル: gpt
ディスクフラグ:

番号  開始    終了    サイズ  ファイルシステム  名前  フラグ
 1    1049kB  1073MB  1072MB                          lvm

# pvcreate "${dev}1"
  Physical volume "/dev/mapper/mpathc1" successfully created.
# vgcreate "vg_${dev##*/}1" "${dev}1"
  Volume group "vg_mpathc1" successfully created
# lvcreate -n "lv_${dev##*/}1" -l 100%FREE "vg_${dev##*/}1"
  Logical volume "lv_mpathc1" created.
# mkfs.xfs /dev/"vg_${dev##*/}1"/"lv_${dev##*/}1"
meta-data=/dev/vg_mpathc1/lv_mpathc1 isize=512    agcount=8, agsize=32640 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=0, sparse=0
data     =                       bsize=4096   blocks=261120, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=855, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
/mntにマウントしてみる。
# mount /dev/mapper/"vg_${dev##*/}1"-"lv_${dev##*/}1" /mnt/
# df -h
ファイルシス                      サイズ  使用  残り 使用% マウント位置
/dev/mapper/rhel-root                14G  1.1G   13G    8% /
devtmpfs                            908M     0  908M    0% /dev
tmpfs                               920M     0  920M    0% /dev/shm
tmpfs                               920M  8.9M  911M    1% /run
tmpfs                               920M     0  920M    0% /sys/fs/cgroup
/dev/sda1                          1014M  146M  869M   15% /boot
tmpfs                               184M     0  184M    0% /run/user/0
/dev/mapper/vg_mpathc1-lv_mpathc1  1017M   33M  985M    4% /mnt

まとめ

以上で設定は完了となる。iSCSIもDM-multipathも、何一つ設定方法を知らなかったので躊躇していたが、今回調査と検証をすることで設定手順を整理することができたので、今後は迷わずに設定をすることができそうだ。

参考

2020年5月9日土曜日

Zabbix 5.0.0rc1 (リリース候補版) をインストールしてみた

2020年5月6日にZabbixの最新バージョンである5.0.0のrc1 (リリース候補版)がリリースされた。

※(2020/5/16追記) 2020年5月12日に正式版のZabbix 5.0がリリースされました!

リリースノートは以下にて確認できる。

正式なリリース版ではないが、ほぼ完成形となるリリース候補版となるので、一足早くインストールして使ってみることにした。

※ちなみに、2018年10月にZabbix 4.0.0がリリースされた際も、今回と同様にリリース候補版をインストールして試している。先に言っておくと、手順は4.0.0の時と大きく変更はないようだ。

環境

環境は以下の通り。最新のCentOS 8.1で環境を構築する。なお、dnf (yum)を使うため、インターネット接続できる環境であることが前提となる。

  • OS:CentOS 8.1
  • DB:MariaDB
  • Web Server:Apache (※Zabbix 4.4以降はNGINXも選択可能)

インストール手順

1. SELinuxとfirewalldを停止する

これらが動いているとうまく動作しないことが多いので停止しておく。

[root@t1024cent ~]# sed -i.org 's/SELINUX=enforcing/SELINUX=disabled/' /etc/sysconfig/selinux
[root@t1024cent ~]# systemctl stop firewalld
[root@t1024cent ~]# systemctl disable firewalld
[root@t1024cent ~]# reboot

2. MariaDBをインストール

dnfでMariaDBをインストールする。設定は特に変更せずデフォルトで起動させておく。

[root@t1024cent ~]# dnf install mariadb mariadb-server -y
[root@t1024cent ~]# systemctl start mariadb
[root@t1024cent ~]# systemctl enable mariadb

3. Zabbix 5.0.0rc1をインストール

以下コマンドを実行することで、Zabbix 5.0.0rc1をインストールすることができる。

[root@t1024cent ~]# rpm -Uvh https://repo.zabbix.com/zabbix/4.5/rhel/8/x86_64/zabbix-release-4.5-2.el8.noarch.rpm
https://repo.zabbix.com/zabbix/4.5/rhel/8/x86_64/zabbix-release-4.5-2.el8.noarch.rpm を取得中
警告: /var/tmp/rpm-tmp.nWafDd: ヘッダー V4 RSA/SHA512 Signature、鍵 ID a14fe591: NOKEY
Verifying...                          ################################# [100%]
準備しています...              ################################# [100%]
更新中 / インストール中...
   1:zabbix-release-4.5-2.el8         ################################# [100%]

dnfでZabbix関連のパッケージをインストールする。Web画面を日本語化するため、「zabbix-web-japanese」のインストールも実施すること。

[root@t1024cent ~]# dnf install zabbix-server-mysql zabbix-web-mysql zabbix-apache-conf zabbix-agent zabbix-web-japanese -y
Zabbix Official Repository - x86_64             155 kB/s |  84 kB     00:00
Zabbix Official Repository non-supported - x86_ 5.4 kB/s | 1.2 kB     00:00
依存関係が解決しました。
================================================================================
 パッケージ       Arch   バージョン                             Repo      サイズ
================================================================================
インストール:
 zabbix-agent     x86_64 5.0.0-0.7rc1.el8                       zabbix    453 k
 zabbix-apache-conf
                  noarch 5.0.0-0.7rc1.el8                       zabbix     16 k
 zabbix-server-mysql
                  x86_64 5.0.0-0.7rc1.el8                       zabbix    2.6 M
 zabbix-web-mysql noarch 5.0.0-0.7rc1.el8                       zabbix     15 k
 zabbix-web-japanese
                  noarch 5.0.0-0.7rc1.el8                       zabbix     16 k

~(以下略)~

4. DBの初期設定

DBの初期設定として、DB作成とユーザーへの権限付与を行う。

まずは、MariaDBに接続し、DB「zabbix」を作成する。DB「Zabbix」に対する全権限をユーザー「zabbix」に付与しておく。パスワードは好みで設定すればよい。

[root@t1024cent ~]# mysql -u root
MariaDB [(none)]> create database zabbix character set utf8 collate utf8_bin;
MariaDB [(none)]> grant all privileges on zabbix.* to zabbix@localhost identified by 'password';
MariaDB [(none)]> quit;

Zabbix初期化用SQLファイルが用意されているので、以下コマンドで流し込みを行う。特にエラー等なく、プロンプトが返ってくれば問題なさそうだ。

[root@t1024cent ~]# zcat /usr/share/doc/zabbix-server-mysql*/create.sql.gz | mysql -u zabbix -p zabbix
Enter password:
[root@t1024cent ~]#

5. Zabbixの初期設定

以下2つのファイルにそれぞれ変更を加える。

/etc/zabbix/zabbix_server.confは、先ほど設定したDB「Zabbix」に接続するためのzabbixユーザのパスワードを設定する。

[root@t1024cent ~]# vi /etc/zabbix/zabbix_server.conf
DBPassword=password

/etc/php-fpm.d/zabbix.confはデフォルトでは; php_value[date.timezone] = Europe/Rigaとなっているので、アンコメントしてAsia/Tokyoに変更する。この設定ファイルはZabbix 4.0.0の頃からディレクトリのパスが変わっているようだ。

[root@t1024cent ~]# vi /etc/php-fpm.d/zabbix.conf
php_value[date.timezone] = Asia/Tokyo

6. Zabbixを起動

以上で準備が整ったので、Zabbixを起動させる。

[root@t1024cent ~]# systemctl restart zabbix-server zabbix-agent httpd php-fpm
[root@t1024cent ~]# systemctl enable zabbix-server zabbix-agent httpd php-fpm

7. Web画面で初期セットアップを行う

以下URLにアクセスし、初期セットアップを行う。

http://<Zabbixサーバーのホスト名 or IPアドレス>/zabbix/

最初の画面では、「Next step」を選択する。

「Check of pre-requisites」では、すべて「OK」となっていることを確認する。通常はデフォルト設定ですべて「OK」となっているはずである。

「Configure DB connection」では、事前に設定したパスワードを入力し、他はデフォルトのままとする。なお、Zabbix 4.0.0と異なり、「TLS encryption」のチェックボックスが増えている。

「Zabbix server details」では、「Name」がデフォルト空白なのでホスト名など入れてもよい。「Name」で設定した名前が何に使われるかというと、操作画面の右上に表示されるだけのようなので、空白のままでも動作に支障はない。

「Pre-installation summary」で設定を再確認できる。

問題なければ以下のような画面が表示されるはずだ。これでインストール作業は完了となる。

8. Zabbix 5.0.0にログインする

初期設定が終わるとログイン画面に遷移するので、早速ログインしてみよう。初期ID/パスワードは以下の通り。

  • ID:Admin
  • パスワード:zabbix

初回ログイン時は言語が英語になっているので、 左メニューの「User settings」を選択し、ユーザープロファイルの画面から、「Language」を「Japanese (ja_JP)」に変更しておこう。

以上で完了となる。特に問題なければ、1時間もあればインストールできてしまう。今までの上部にメニューが並ぶスタイルから、左側にメニューが並ぶスタイルとなっており、今までのバージョンのZabbixとは、見た目も変化しているようだ。

2020年5月4日月曜日

プロキシ環境でWindows Updateがいつまでも完了しない場合の対処

先日、Windows Server 2016に手動で累積パッチを適用する手順を記事にした。
そもそも、プロキシ環境でWindows Updateをする場合、「インターネットオプション」のプロキシ設定だけでは、いつまでもUpdateが完了しないことがわかった。

Windows Update失敗パターン

いくつかパターンがあるようだが、Windows Server 2019では「更新サービスに接続できませんでした」というエラーで失敗する。

Windows Server 2016の場合は、「更新プログラムをダウンロードしています 0%」から進捗することがなく、いつまでも更新が完了しない。

時折、ダウンロードしようとする更新プログラムの内容が表示されたり消えたりする謎の動きをするが、いつまでも進捗は0%から変化しなかった。

IEだけでなく、コマンドプロンプトのプロキシ設定を行うことで解消する

Windowsのプロキシ設定は、GUIとコマンドプロンプトの2か所で設定できるが、Windows Updateを実行する際には両方の設定が必要となるようだ。
  • 「インターネットオプション」の設定
  • コマンドプロンプトの設定
コマンドプロンプトの設定方法を以下に記載する。この手順は、以前「Windowsのライセンス認証を最速で実施する方法」においても記載している。
PS C:\> netsh winhttp prpxy
次のコマンドは見つかりませんでした: winhttp prpxy
PS C:\> netsh winhttp show proxy

現在の WinHTTP プロキシ設定:

    直接アクセス (プロキシ サーバーなし)。

PS C:\> netsh winhttp set proxy <プロキシIP>:<プロキシポート>

現在の WinHTTP プロキシ設定:

    プロキシ サーバー:  <プロキシIP>:<プロキシポート>
    バイパス一覧     : (なし)
本設定を実施したのち、Windows Updateを実行することでパッチ適用に成功した。

なお、Windows Server 2016の初期状態から実施したところ、OS再起動まで含めると1時間強(正確には20:00開始~21:08終了の68分)の時間を要したことも報告しておく。

人気の投稿