RSS配信記事
authdパッケージアップデートで出力されるメッセージについて
パッケージのアップデートをすると最後に”設定を再読み込み: [失敗]”と出力される
[対象となる製品のバージョン]
Asianux Server 3 for x86(32bit)
Asianux Server 3 for x86-64(64bit)
[原因 ・対処]
Asianux TSN Updater（axtu）やAsianux Server 3 ==MIRACLE LINUX V5 のDVDメディアを使用して、SPのアップデートを実施した際に最後の以下のようなメッセージが出力されることがあります。
・・・・・
571:xorg-x11-drivers ##################################### [100%]
572:xorg-x11-drv-i810-devel##################################### [100%]
設定を再読み込み: [失敗]
#
このメッセージはauthdパッケージのアップデートにより出力されます。authdはアップデートされるとxinetdを再起動し、authd自身が更新されたもので動作するようになっています。このときxinetdが停止しているとauthdも再起動されないため本メッセージが出力されます。本メッセージが出力されても動作に影響はございません。
本ドキュメントは、各ソフトウェア開発元の情報およびマニュアル等を元にした参考情報です。
本ドキュメントの内容は、予告なしに変更される場合があります。
本ドキュメントは、限られた評価環境における検証結果をもとに作成しており、全ての環境での動作を保証するものではありません。
本ドキュメントの内容に基づき、導入、設定、運用を行なったことにより損害が生じた場合でも、弊社はその損害についての責任を負いません。あくまでお客様のご判断にてご使用ください。
2010年 11月15日 新規作成
VMware監視テンプレート
Zabbix VMware監視テンプレートのアップデート情報です。
Zabbix VMware監視テンプレートサポートサービスのご加入のユーザ様はユーザログインページからアップデートパッケージをダウンロード頂けます。
2011/01/25
2010/10/12
2010/04/05
2009/08/27
アップデート情報
ミラクル・リナックス提供の MIRACLE ZBX ソフトウェア、MIRACLE ZBX テンプレート・オプションのアップデート情報です。
アップデートパッケージはユーザー情報のページ（※製品をご購入頂いたお客様用）からダウンロード頂けます。
CLUSTERPROでVMware ESXのHW障害をトリガーに仮想マシン上の業務をフェイルオーバさせる方法
[概要]
本書では、VMwareサービスコンソール上にCLUSTERPRO X Single Server Safe、ゲストOS上にCLUSTERPRO Xを構築し、それぞれ連携させることで、堅牢な仮想化環境ソリューションを構築します。
[使用した製品のバージョン]
MIRACLE CLUSTERPRO X2.1
- Asianux Server 3 ==MIRACLE LINUX V5 SP3
- clusterpro-2.1.5-1
VMware ESX4.0
- clusterprosss-2.1.5-1
[ 検証内容]
VMware ESX4.0のサービスコンソールにはCLUSTERPRO Single Server Safe(以下SSS) または
CLUSTERPRO X2.1 をインストールすることができます。
CLUSTERPROのクラスタ間処理要求機能を使い、VMware ESXのサービスコンソール－GuestOS間で連携を行い、物理マシン のHW障害からGuestOS上の業務までの障害に対応できるよう設定します。
本検証ではサービスコンソール上にCLUSTERPRO SSS、GuestOSにCLUSTERPROをインストールします。
物理サーバのHW障害時はサービスコンソールにインストールされたCLUSTERPRO SSSがGuestOS上のCLUSTERPROにフェイルオーバのリクエストを送ります。リクエストを受けたGuestOS上で業務が待機系にフェイルオーバします。
[環境構築]
なお、本手順ではすでに物理サーバにVMware ESXがインストールされ、仮想マシンが作成されているものとします。
この際、クラスタ間処理要求機能を使って、サービスコンソール上のCLUSTERPRO SSSから仮想マシン上のCLUSTERPROへ処理要求を出せるよう、設定を行います。
# mkdir /opt/nec/clusterpro/work/clptrnreq
以下は、VMware ESXサービスコンソール上のCLUSTERPRO SSSからフェイルオーバリクエストを受信したメッセージを出力させるスクリプトです。
#!/bin/bash
/usr/sbin/clplogcmd -m "Receive Failover Request from ESX" -l warn
ここでは以下のように設定しました。
|
クラスタシステム設定
|
||
|
クラスタ構成
|
クラスタ名
|
VMcluister
|
|
サーバ数
|
2
|
|
|
1台目のサーバ
|
サーバ名
|
CLP-1
|
|
OS
|
Asianux Server 3
|
|
|
パブリックのIPアドレス
|
10.2.102.51
|
|
|
インタコネクトのIPアドレス
|
192.168.10.1
|
|
|
10.2.102.51
|
||
|
2台目のサーバ
|
サーバ名
|
CLP-2
|
|
OS
|
Asianux Server 3
|
|
|
パブリックのIPアドレス
|
10.2.102.52
|
|
|
インタコネクトのIPアドレス
|
192.168.10.2
|
|
|
10.2.102.52
|
||
-
グループリソース設定グループ名failoverfloating ip resourceグループリソース名fipIPアドレス10.2.102.50活性リトライ5回フェイルオーバー1回活性最終動作何もしない（次のリソースを活性しない）非活性リトライ0回非活性最終動作クラスタデーモン停止とOSシャットダウンmirror disk resourceグループリソース名mdマウントポイント/dataデータパーティション/dev/sda4クラスタパーティション/dev/sda3ディスクデバイス名/dev/sdaファイルシステムext3活性リトライ0回フェイルオーバー1回活性最終動作何もしない（次のリソースを活性しない）非活性リトライ0回非活性最終動作クラスタデーモン停止とOSシャットダウンexecute resourceグループリソース名exec活性リトライ0回フェイルオーバー1回活性最終動作何もしない（次のリソースを活性しない）非活性リトライ0回非活性最終動作クラスタデーモン停止とOSシャットダウン
-
モニタリソース設定user mode monitor
（自動登録）モニタソース名userw監視方法softdogNIC Link Up/Down
monitor
（全物理NICごと）モニタリソース名miiw-eth0監視デバイスeth0回復対象vmcluster活性リトライ0回フェイルオーバー0回活性最終動作何もしないNIC Link Up/Down
monitor
（全物理NICごと）モニタリソース名miiw-eth1監視デバイスeth1回復対象vmcluster活性リトライ0回フェイルオーバー0回活性最終動作何もしないmirror disk monitor
モニタリソース名mdw1ミラーディスクリソースmd回復対象VMcluster活性リトライ0回フェイルオーバー0回活性最終動作何もしないmirror disk
connect monitor
モニタリソース名mdnw1ミラーディスクリソースmd回復対象VMcluster活性リトライ0回フェイルオーバー0回活性最終動作何もしない
３．VMware ESXサービスコンソール上にCLUSTERPRO SSSの構築
VMware ESXのサービスコンソールにCLUSTERPRO SSSをインストールします。
なお、GuestOSの障害対策はGuestOS上のCLUSTERPROで行うため、仮想マシン自体はCLUSTERPRO SSSの管理外とします。
VMware ESX4.0のサービスコンソールはRHEL5-x86_64に相当するため、Linux版のCLUSTERPRO SSSをインストールすることができます。
# rpm -ivh clusterprosss-2.1.5-1.x86_64.rpm
VMware ESXではデフォルトではFireWallが有効になっているため、CLSUTERPRO SSSを利用する上で必要なポートを開放します。
# esxcfg-firewall -o 29003,tcp,in,clpwebmgr
# esxcfg-firewall -o 29002,tcp,out,clptrnsrv
VMware ESXではuserw（user空間監視）でipmi、softdogを指定しているとエラーとなります。
VMware ESXハイパーバイザ上のCLUSTERPRO SSSのモニタリソースが反応したら、GuestOS上のCLUSTERPROにフェイルオーバリクエストを発行し、GuestOS上で動作している業務を待機系にフェイルオーバさせます。
#! /bin/sh
#***********************************************
#* preaction.sh *
#***********************************************
*****************************************
ulimit -s unlimited
# ホストマシンが起動する仮想マシンのリソース名を記述
CLPRSC="exec"
# カンマ区切りで各ホストマシンの IP を記述
CLPIP="10.2.102.51,10.2.102.52"
/usr/sbin/clplogcmd -m "Send Failover Request to CLP-1" -l warn
/usr/sbin/clptrnreq -t EXEC_SCRIPT -h $CLPIP -s failover_message.sh
/opt/nec/clusterpro/bin/clptrnreq -t GRP_FAILOVER -r $CLPRSC -h $CLPIP
exit 0
以上で設定は完了です。
|
クラスタシステム設定
|
||
|
クラスタ構成
|
クラスタ名
|
bay7-esx
|
|
サーバ数
|
1
|
|
|
1台目のサーバ
|
サーバ名
|
bay7-esx
|
|
OS
|
VMware ESX 4
|
|
|
パブリックのIPアドレス
|
10.2.102.17
|
|
-
モニタリソース設定user mode monitor
（自動登録）モニタソース名userw監視方法keepaliveNIC Link Up/Down
monitor
（全物理NICごと）モニタリソース名miiw-vmnic0監視デバイスvmnic0回復対象bay7-esx活性リトライ0回活性最終動作何もしないNIC Link Up/Down
monitor
（理NICごと全物）モニタリソース名miiw-vmnic1監視デバイスvmnic1回復対象bay7-esx活性リトライ0回最終活性動作何もしないcustom monitor
（必要に応じて）モニタリソース名genw-CLP1監視方法□ユーザアプリケーション■スクリプトファイルGenw.sh監視スクリプト前述の仮想マシン監視スクリプト監視タイプ■同期□非同期ログ出力先正常な戻り値0回復対象bay7-esx活性リトライ0回活性最終動作何もしないcustom monitor
（必要に応じて）モニタリソース名genw-CLP2監視方法□ファイルGenw.sh監視スクリプト前述の仮想マシン監視スクリプト監視タイプ■ログ出力先正常な戻り値0回復対象bay7-esx活性リトライ0回活性最終動作何もしない
本検証では、VMware ESXがインストールされた物理マシンのNIC(vmnic1) を抜き、CLUSTERPRO SSSのNICLink Up/Down monitorがリンクダウンを検知したら、GuestOS上で動作しているApacheをフェイルオーバさせます。
VMware ESXサービス近ソース上のCLUSTERPRO SSS
2010/09/24 21:18:18 bay7-esx rm Detected an error in monitoring miiw-vmnic1. (20 : NIC vmnic1 link was down.) ←vmnic1リンクダウン検知
2010/09/24 21:18:18 bay7-esx logcmd Send Failover Request to CLP-1 ←最終動作前のスクリプト実行
GuestOS上のMIRACLE CLUSTERPRO
2010/09/24 21:18:18 CLP-1 logcmd Receive Failover Request from ESX ←メッセージ出力
2010/09/24 21:18:18 CLP-2 logcmd Receive Failover Request from ESX ←メッセージ出力
2010/09/24 21:18:19 CLP-1 apisv There was a request to move group(failover) from the clpgrp command(IP=::ffff:192.168.10.101). ←フェイルオーバ開始
2010/09/24 21:18:19 CLP-1 rc Stopping group failover has started.
2010/09/24 21:18:19 CLP-2 rc Moving group failover has started.
2010/09/24 21:18:31 CLP-1 rc Stopping group failover has completed.
2010/09/24 21:18:31 CLP-2 rc Activating group failover has started.
2010/09/24 21:18:42 CLP-2 rc Activating group failover has completed.
2010/09/24 21:18:42 CLP-2 rc Moving group failover has completed. ←フェイルオーバ完了
本ドキュメントは、限られた評価環境における検証結果をもとに作成しており、 全ての環境での動作を保証するものではありません。
NetVault Backupの障害発生時の初動調査および情報採取のための事前準備
[概要]
本ドキュメントでは、NetVault Backupで障害発生時に、お問合せの前に事前に確認、準備すべき内容について説明します。
[対象となる製品のバージョン]
NetVault Backup 8.1以降
[注意事項]
[初動調査]
[情報採取のための事前準備]
ミラクル・リナックス カスタマーサポートセンターでは、[初動調査]と併せて、現象に応じた情報採取をお願いしています。採取依頼のあった情報を採取できるように、事前に準備をしていただくことをお勧めします。
MIRACLE LINUX、Asianuxをお使いの場合は、/usr/sbin/mcinfo を利用します。
なお、mcinfoの取得情報の中には、rootユーザーでしか取得できないものもあるため、/usr/sbin/mcinfo コマンドはrootユーザーで実行します。
・MIRACLE LINUX v4.0 SP2 より前のバージョンをご使用の場合
# mcinfo | gzip > mcinfo.log.gz
・MIRACLE LINUX v4.0 SP3、Asinaux Server 3 == MIRACLE LINUX V.5 以降をご使用の場合
# mcinfo
■ NetVault Backupのバイナリログ取得
NetVault BackupではNetVault GUIのLogsからログの参照が可能です。
NetVault backupのログ収集はNetVault GUIを使いGUIで行う方法と、コマンドで行う方法があります。これらは、どちらの方法でも同じ情報が取得されます。
・NetVault GUIからログを取得する方法
以下のコマンドを実行してnetVault GUIを起動します。
# nvgui
netVault GUIが起動したら、[ログ]を選択します。
以下の例では "nvbinlog20040607_02.nlg"というファイル名で2004年1月1日 00:00.00〜2004年12月31日 23:59.59までのログをとるよう指定しています。
# cd /usr/netvault/util/
# ./nvlogdump -filename nvbinlog20040607_02 -starttime 20040101000000 -endtime 20041231235959
上記コマンドを実行すると、NetVault GUIを使ってのログ取得と同様、/usr/netvault/logs/dumps/binary以下に指定したファイル名でログが保存されます。
CLUSTERPROの障害発生時の初動調査および情報採取のための事前準備
[概要]
[対象となる製品のバージョン]
CLUSTERPRO X3
CLUSTERPRO X2.1
CLUSTERPRO X2.0
CLUSTERPRO X1.0
CLUSTERPRO for Linux Ver3.x SE/LE
[注意事項]
[初動調査]
[情報採取のための事前準備]
ミラクル・リナックス カスタマーサポートセンターでは、[初動調査]と併せて、現象に応じた情報採取をお願いしています。採取依頼のあった情報を採取できるように、事前に準備をしていただくことをお勧めします。
MIRACLE LINUX、Asianuxをお使いの場合は、/usr/sbin/mcinfo を利用します。
なお、mcinfoの取得情報の中には、rootユーザーでしか取得できないものもあるため、/usr/sbin/mcinfo コマンドはrootユーザーで実行します。
・MIRACLE LINUX v4.0 SP2 より前のバージョンをご使用の場合
# mcinfo | gzip > mcinfo.log.gz
・MIRACLE LINUX v4.0 SP3、Asinaux Server 3 == MIRACLE LINUX V.5 以降をご使用の場合
# mcinfo
# clplogcc -o <ログ出力先ディレクトリパス>
ネットワーク帯域制御CBQを使用するときの注意事項
[対象となる製品のバージョン]
Asianux Server 3 for x86(32bit)
Asianux Server 3 for x86-64(64bit)
[質 問]
CBQ(Class Baased Queueing)を使用しネットワークの帯域制御をすると極端にスループットが低下する
一部のネットワークカードで、CBQによる送信パケットの帯域制御を行うと設定値よりも大幅にスループットが制限されることがあります。
本問題の対処方法としてTSOを無効にすることで改善される場合があります。
例） eth0として認識しているネットワークカードのTSOを無効にする場合
# ethtool -K eth0 tso off
# ethtool -k eth0
Offload parameters for eth0:
Cannot get device udp large send offload settings: Operation not supported
rx-checksumming: on
tx-checksumming: on
scatter-gather: on
tcp segmentation offload: off ← offであることを確認してください
udp fragmentation offload: off
generic segmentation offload: off
[更新履歴]
2010年 5月 26日 新規作成
『/var/log/rflogview』ディレクトリが肥大化する
[対象となる製品のバージョン]
Asianux Server 3 ==MIRACLE LINUX V5 for x86(32bit)
Asianux Server 3 ==MIRACLE LINUX V5 for x86-64(64bit)
MIRACLE LINUX V4.0 - Asianux Inside for x86（32bit）
MIRACLE LINUX V4.0 - Asianux Inside for x86-64（64bit）
[質 問]
ディレクトリ 『/var/log/rflogview』 が肥大化する
『/var/log/rflogview』は後述のlime-logview(rflogview)※が使用するディレクトリです。サーバーのご使用の方法によってはこのディレクトリの容量が非常に大きくなることがありご運用の際は注意が必要です。
※プログラムの名称はOSにより下記のように異なります。
|
OS |
プログラム名
|
|
Asianux Server 3 ==MIRACLE LINUX V5 |
lime-logview |
|
MIRACLE LINUX V4.0 |
rflogview |
[lime-logview(rflogview)とは]
ログファイルを整形し、GUIで表示するツールです。syslogメッセージをシステム、ブート、セキュリティ、メールに分類して表示します。
[対処方法]
lime-logview(rflogview)を使用しない場合は下記の手順にて、このディレクトリへのログ出力を止め、ログファイルとパッケージを削除することが可能です。
1. 下記 syslogの設定ファイルから rflogview の設定項目を削除します。
ファイル: /etc/syslog.conf
下記の行を削除します。
###rflogview_begin#### this is begin flag line , do not midify it !
#do not insert your own rules between the begin flag line to the end flag line.
#system
kern.err;cron.err;daemon.err;lpr.err;news.err;uucp.err;syslog.err -/var/log/rflogview/system_errors
kern.=info;kern.=notice;cron.=info;cron.=notice;daemon.=info;daemon.=notice;lpr.=info;lpr.=notice;uucp.=info;uucp.=notice;sysl
og.=info;syslog.=notice;news.=info;news.=notice -/var/log/rflogview/system_info
kern.=warn;cron.=warn;daemon.=warn;lpr.=warn;news.=warn;uucp.=warn;syslog.=warn -/var/log/rflogview/system_warnings
#user
user.=info;user.=notice -/var/log/rflogview/user_info
user.=warn -/var/log/rflogview/user_warnings
user.err -/var/log/rflogview/user_errors
mail.=info;mail.=notice -/var/log/rflogview/mail_info
mail.=warn -/var/log/rflogview/mail_warnings
mail.err -/var/log/rflogview/mail_errors
#secure
auth.=info;auth.=notice;authpriv.=info;authpriv.=notice -/var/log/rflogview/secure_info
auth.=warn;authpriv.=warn -/var/log/rflogview/secure_warnings
auth.err;authpriv.err -/var/log/rflogview/secure_errors
#boot
local7.=info;local7.=notice -/var/log/rflogview/boot_info
local7.=warn -/var/log/rflogview/boot_warnings
local7.err -/var/log/rflogview/boot_errors
###rflogview_end#### this is end line flag line ,do not modify it!
2. syslog の設定を有効にするため、サービスの再起動を行います。
# service syslog restart
3. ログファイルの削除
# rm -rf /var/log/rflogview
4. パッケージの削除
下記のコマンドでパッケージを削除します。パッケージのバージョン番号は適宜お読みかえ下さい。
1) Asianux Server 3 ==MIRACLE LINUX V5 の場合
# rpm -e lime-logview-1.1.10-2AXS3
2) MIRACLE LINUX V4.0 の場合
# rpm -e rflogview-1.0-29AXS2
[注意事項]
本ドキュメントの内容は、予告なしに変更される場合があります。
本ドキュメントは、限られた評価環境における検証結果をもとに作成しており、 全ての環境での動作を保証するものではありません。
本ドキュメントの内容に基づき、導入、設定、運用を行なったことにより損害が生じた場合でも、
弊社はその損害についての責任を負いません。あくまでお客様のご判断にてご使用ください。
[更新履歴]
2010年 5月24日 新規作成
「warning: many lost ticks.」について
MIRACLE LINUX V4.0 - Asianux Inside
MIRACLE LINUX V4.0 - Asianux Inside for x86-64
syslogに以下のようなメッセージが出力されることがあります。
1. ネットワークが高負荷の場合
Warning : meny lost ticks.
If your CPU support 'CPU Frequency scaling',You could ignore this warning
else your time source seems to be instable or some driver is hogging interupts
rip e1000_update_stats+0x781/0x788[e1000]
2．システムが高負荷の場合
Warning: many lost ticks.
If your CPU support 'CPU Frequency scaling',You could ignore this warning
else your time source seems to be instable or some driver is hogging interupts
rip __do_softirq+0x4d/0xd0
1のメッセージは Miracle Linux V4.0 SP2( kernel-2.6.9-42.7AXsmp)で出力されることを確認しております。これはe1000ドライバの不具合によるものです。アップデートパッケージにて修正されています。kernel-2.6.9-42.10AX以上のバージョンにアップデートをお願いいたします。
2のメッセージはMiracle Linux V4.0 SP4で出力されることを確認しております。これはシステムが高負荷状態で、かつDVD-ROM装置などIDEデバイスにアクセスしている場合に出力されることがあります。その場合、2のメッセージに加えて、以下のようなメッセージが出力されることがあります。
hda: command error: status=0x51 { DriveReady SeekComplete Error }
hda: command error: error=0x54
ide: failed opcode was 100
ATAPI device hda:
Error: Illegal request -- (Sense key=0x05)
Illegal mode for this track or incompatible medium -- (asc=0x64, ascq=0x00)
The failed "Read 10" packet command was:
"28 00 00 04 b6 40 00 00 02 00 00 00 00 00 00 00 "
end_request: I/O error, dev hda, sector 1235200
Buffer I/O error on device hda, logical block 308800
Buffer I/O error on device hda, logical block 308801
このような場合はIDEデバイスへのアクセスを控えるか、またはカーネルのブートパラメータに”hda=none”を設定し、IDEデバイスを無効にすることで、メッセージ出力が解消される可能性があります。
grub edit> kernel /boot/vmlinuz-2.6.18-128.7AXS3 ro root=LABEL=/ hda=none
ただし”hda=none”を設定した場合は対象のIDEデバイスが使用できなくなります。
「warning: many lost ticks.」のメッセージが出力されることでOSの時刻がずれることはございません。
[更新履歴]
2010年 4月 6日 新規作成
/usr を別パーティションにしている場合のアップグレードの諸注意
Asianux Server 3 for x86(32bit)
Asianux Server 3 for x86-64(64bit)
/usr を別パーティションで構成している環境の場合、device-mapper-1.02.32-1.AXS3にアップデートをした後、再起動を行うとvmsetup、fsckにて「libreadline.so.5」が見つからないと表示されOSが起動できなくなる問題があります。
この問題はdevice-mapper-1.02.39-1.1.AXS3以降のバージョンで修正されていますので、 パッケージを最新バージョンにアップデートいただくことで解決します。また、下記の[対処]方法によっても解決することが可能です。
https://tsn.miraclelinux.com/tsn_local/index.php?m=errata&a=detail&eid=1030
/usr を別パーティションで構成している環境の場合は、device-mapper-1.02.32-1.AXS3へのアップデートは行わないでください。
# cp /usr/lib64/libncurses.so.5.5 /lib64/
# cp /usr/lib64/libreadline.so.5.1 /lib64/
# cp /usr/lib64/libdmraid.so.1.0.0.rc13-17 /lib64/
# ldconfig
2010年 3月 30日 新規作成
2010年 4月 19日 修正
"detected DSPD enabled in EEPROM"について
Asianux Server 3 for x86(32bit)
Asianux Server 3 for x86-64(64bit)
MIRACLE LINUX V4.0 - Asianux Inside
MIRACLE LINUX V4.0 - Asianux Inside for x86-64
intel社製のギガビット・イーサネットワークカード 82573(V/L/E)を使用しているハードウェア構成の場合、syslogに以下のようなメッセージが記録されることがあります。
kernel: e1000e 0000:0a:00.0: Warning: detected DSPD enabled in EEPROM
このメッセージは、intel社製のギガビット・イーサネットワークカード 82573(V/L/E)の省電力機能である、DSPD(Deep Smart Power Down)が有効(ON)になっていることを示すメッセージです。
DSPDが有効(ON)の場合は、通信障害が発生する可能性があるため、DSPDは無効(OFF)にすることを推奨いたします。詳細はintel社のURL先にある、"82573(V/L/E) TX Unit Hang Messages"の
ドキュメントを参照ください( http://downloadmirror.intel.com/9180/eng/README.txt )。
■ 82573(V/L/E)がeth0の場合の使用方法
# bash fixeep-82573-dspd.sh eth0
eth0: is a "82573E Gigabit Ethernet Controller"
This fixup is applicable to your hardware
executing command: ethtool -E eth0 magic 0x109a8086 offset 0x1e value 0xdf
Change made. You *MUST* reboot your machine before changes take effect!
EEPROMを書き換えた場合は、再起動を行ってください。
2010年 3月 1日 新規作成
HP社SmartArrayに接続したTAPEドライブが使用できない
[対象となる製品のバージョン]
Asianux Server 3 ==MIRACLE LINUX V5
MIRACLE LINUX V4.0 - Asianux Inside
MIRACLE LINUX V3.0 - Asianux Inside
MIRACLE LINUX Standard Edition V2.1
[問題]
HP社SmartArrayに接続したTAPEドライブが使用できない。
[注意事項]
本ドキュメントは、各ソフトウェア開発元の情報およびマニュアル等を元にした参考情報です。本ドキュメントの内容は、予告なしに変更される場合があります。本ドキュメントは、限られた評価環境における検証結果をもとに作成しており、全ての環境での動作を保証するものではありません。本ドキュメントの内容に基づき、導入、設定、運用を行なったことにより損害が生じた場合でも、弊社はその損害についての責任を負いません。あくまでお客様のご判断にてご使用ください。本ドキュメントで使用しているソフトウェアのセキュリティ等の詳細な設定につきましては、マニュアル等をご参照ください。
[問題詳細]
HP社のSmartArrayにTAPEドライブを接続した場合、通常のインストール作業だけではTAPEドライブは認識させず使用できません。
[回答]
1.TAPEドライブを使用する前に、以下のコマンドを実行します。
※起動時に自動的に認識させるには/etc/rc.localに下記のコマンドを追記してください。
# echo "engage scsi" > /proc/driver/cciss/cciss0
※すべてのファイル（/proc/driver/cciss/cciss[数字]）に対して同様にコマンドを実行します。
# echo "engage scsi" > /proc/driver/cciss/cciss0
# echo "engage scsi" > /proc/driver/cciss/cciss1
...
2.TAPEドライブが認識されたことを確認します。
# cat /proc/scsi/scsi
Host: scsi2 Channel: 00 Id: 00 Lun: 00
Vendor: HP Model: Ultrium 3-SCSI Rev: Q25W
Type: Sequential-Access ANSI SCSI revision: 05
Host: scsi2 Channel: 00 Id: 01 Lun: 00
Vendor: HP Model: 1x8 G2 AUTOLDR Rev: 2.80
Type: Medium Changer ANSI SCSI revision: 05
3.TAPEドライブのデバイスファイルが正常に作成されていることを確認します。
# ls -l /dev/st* /dev/nst*
crw-rw---- 1 root disk 9, 128 12月 25 04:24 /dev/nst0
crw-rw---- 1 root disk 9, 0 12月 25 04:24 /dev/st0
[参考情報]
・このドキュメントはHP社のページを参考に作成しました。あわせて以下のURLをご確認ください。
SmartArray/ccissでの TAPE(SCSI)サポートについて
SmartArray/ccissでの TAPE(SAS)サポートについて
・詳細情報は下記のドキュメントにも記載されています。
/usr/share/doc/kernel-doc-バージョン番号/Documentation/cciss.txt
[更新履歴]
2010年 2月 25日 新規作成
php実行時のWarningメッセージ出力について
[対象となる製品のバージョン]
Asianux Server 3 for x86(32bit)
Asianux Server 3 for x86-64(64bit)
MIRACLE LINUX V4.0 - Asianux Inside
MIRACLE LINUX V4.0 - Asianux Inside for x86-64
MIRACLE LINUX V3.0 - Asianux Inside
MIRACLE LINUX V3.0 - Asianux Inside for x86-64
[注意事項]
本ドキュメントは、各ソフトウェア開発元の情報およびマニュアル等を元にした参考情報です。本ドキュメントの内容は、予告なしに変更される場合があります。本ドキュメントは、限られた評価環境における検証結果をもとに作成しており、全ての環境での動作を保証するものではありません。本ドキュメントの内容に基づき、導入、設定、運用を行なったことにより損害が生じた場合でも、弊社はその損害についての責任を負いません。あくまでお客様のご判断にてご使用ください。
[現象]
一般ユーザー、または、rootユーザー権限で、コマンドラインからphpを実行すると以下の様なWarningメッセージが出力される場合があります。
# php -v
PHP Warning: PHP Startup: Unable to load dynamic library'/usr/lib/php/modules/oci8.so'
/usr/lib/php/modules/oci8.so: undefinedsymbol: xxxxxxx in Unknown on line 0
(xxxxxxxにはoci8.soライブラリ内のシンボル名が表示されます。)
[詳細]
このWarningメッセージは、php-oci8が使用するOracle Databaseのライブラリが正しく読み込まれなかったことを意味し、Oracle Databaseのライブラリへのパスが正しく設定がされていない場合に出力されます。 php-oci8はphpでOracle Databaseを操作する為のパッケージです。Oracle Databaseと連携していない場合、このWarningメッセージが出力されたとしても、phpの動作に影響はありません。Oracle Databaseを使用している場合、phpからOracle Databaseの操作が出来無い可能性があります。
[対処方法]
本問題の対処方法はOracle Databaseのインストールの有無によって異なります。
ご使用の環境に当てはまる方法を行って下さい。
-
Oracle Databaseを使用していない場合
Oracle Databaseと連携をしない場合、このWarningメッセージは無視することができます。また、php-oci8のパッケージを削除することでWarningメッセージを止める事ができます。このパッケージを削除することによるphpの動作への影響はありません。
# rpm -qa |grep php-oci8
php-oci8-5.1.6-23.2AXS3
# rpm -e php-oci8-5.1.6-23.2AXS3
-
Oracle Databaseを使用している場合
実行するユーザーの環境変数ORACLE_HOME,LD_LIBRARY_PATHにパスを正しく設定して頂く事でライブラリが正しく読み込まれるようになり、Warningメッセージの出力を止める事が出来ます。
インストールされているOracle Databaseのライブラリを設定します。
# export ORACLE_HOME=/opt/app/oracle/product/xx.x.xx/db_1
(ORACLE_HOMEにはOracle Databaseのインストール先ディレクトリを指定してください。)
# export LD_LIBRARY_PATH=$ORACLE_HOME/lib
常時使用する場合にはユーザーの設定ファイルに以下の設定を追記します。
例）ユーザー”user1”に対して設定を行う場合
/home/user1/.bashrc
export ORACLE_HOME=/opt/app/oracle/product/xx.x.xx/db_1
(ORACLE_HOMEにはOracle Databaseのインストール先ディレクトリを指定してください。)
export LD_LIBRARY_PATH=$ORACLE_HOME/lib
[更新履歴]
2010年 2月25日 新規作成
新 2010 インテル® Core™ プロセッサー・ファミリーでのAsianux Server 3のインストール方法
[対象となる製品のバージョン]
Asianux Server 3 for x86(32bit)
Asianux Server 3 for x86-64(64bit)
[問題詳細]
Core i5 600シリーズ、Core i3-500シリーズなどGPUが内蔵された新 2010 インテル® Core™ プロセッサー・ファミリー(開発コード名Clarkdale)を搭載した機種において、グラフィックが動作しない場合があります。その場合は通常のAsianux Server 3インストールに加え、アップデートをする必要があります。
[対処方法]
Asianux Server 3 ==MIRACLE LINUX V5 SP2のインストールを例に記述します。
1. Asianux Server 3 ==MIRACLE LINUX V5 SP2 をテキストモードでインストールします。
下記URLにあるAsianux Server 3 ==MIRACLE LINUX V5 SP2 の製品版インストレーションガイド「 第5章 テキストモード」をご覧ください。
https://users.miraclelinux.com/products/linux/axs3/pdf/axs3_install_guide_sp2.pdf
2. Asianux Server 3 ==MIRACLE LINUX V5 SP2 を起動します。
-
製品版インストレーションガイド「5.12 ランレベルとX設定のカスタマイズ」においてDefault Loginの項目で、ログインの種類に[Graphical]を選択した場合は、grubのカーネル選択画面で以下のようにブートパラメータに 3と記述し、テキストモードで起動してください。
grub edit> kernel /boot/vmlinuz-2.6.18-128.7AXS3 ro root=LABEL=/ 3
-
[Text]を選択してインストールした場合はそのままOSを起動してください。
3. /etc/X11/xorg.conf の設定を変更してください。
xorg.confのModesの行をコメントアウトしてください。
# vi /etc/X11/xorg.conf
・・・・・Section "Screen"
Identifier "Screen0"
Device "Videocard0"
DefaultDepth 24
SubSection "Display"
Viewport 0 0
Depth 24
# Modes "800x600" "640x480" ＜― この行をコメントアウトしてください
EndSubSection
EndSection
4. xorgのアップデートパッケージをダウンロードします。
下記URLよりxorgに関するパッケージをダウンロードします。ご利用のOSに合わせてRPMパッケージをダウンロードしてください。
5. ダウンロードしたRPMパッケージをインストールします。
# rpm -Uhv xorg-x11-server-*67*
準備中... ########################################### [100%]1:xorg-x11-server-Xorg ########################################### [ 20%]
2:xorg-x11-server-Xdmx ########################################### [ 40%]
3:xorg-x11-server-Xnest ########################################### [ 60%]
4:xorg-x11-server-Xvfb ########################################### [ 80%]
5:xorg-x11-server-sdk ########################################### [100%]
アップデート後、グラフィック画面の表示が可能となります。
[注意事項]
本ドキュメントは、各ソフトウェア開発元の情報およびマニュアル等を元にした参考情報です。
本ドキュメントの内容は、予告なしに変更される場合があります。
本ドキュメントは、限られた評価環境における検証結果をもとに作成しており、全ての環境での動作を保証するものではありません。
本ドキュメントの内容に基づき、導入、設定、運用を行ったことにより損害が生じた場合でも、弊社はその損害についての責任を負いません。あくまでお客様のご判断にてご使用ください。
[更新履歴]
2010年 2月 16日 新規作成
IPMI watchdogの設定方法
Asianux Server4 SP1 for x86(32bit)
Asianux Server4 SP1 for x86-64(64bit)
Asianux Server 3 for x86(32bit)
Asianux Server 3 for x86-64(64bit)
[概要]
本ドキュメントではカーネルのIPMI watchdogの設定方法について説明します。
IPMI watchdogとはIPMI(Intelligent Platform Management Interface) のwatchdog timer機能により、なんらかの原因でシステムがフリーズした状態を検出する機能です。これによりシステムのデッドロック、または無限ループなどの不具合を検出することが可能です。
また検出後にダンプ採取、自動でハードウェアリセットなど任意の動作をさせることができます。
[前提条件]
・IPMIコントローラがサーバに搭載されている必要があります。
確認するにはサーバのスペックを確認していだくか、下記の方法で確認が可能です。
IPMIコントローラが備わっている場合は以下のコマンドが成功しモジュールをロードすることができます。
# modprobe ipmi_si
[設定手順]
１．IPMI watchdogの設定
/etc/sysconfig/ipmiを任意のエディタで開き以下の行を編集します。以下は設定例です。
・・・
IPMI_WATCHDOG=yes
・・・
IPMI_WATCHDOG_OPTIONS="timeout=60 action=reset pretimeout=30 preaction=pre_int preop=preop_panic"
・・・
各パラメータの意味は以下になります。
| timeout | システムがフリーズ状態と判断する時間を指定します。watchdogが最後にリセットされてからaction=で指定した動作をさせるタイムアウト時間になります。単位は秒となります。 |
| action |
reset, none, power_cycle, power_offのいずれかを指定します。 ・resetはH/Wリセットでリブートします。 ・noneはなにもしません。 ・power_cycleはいったん電源をオフにしたあと、オンにます。 ・power_offは電源をオフにします。 |
| pretimeout | preaction=で指定した動作をさせるタイムアウト時間を指定します。単位は秒となります。 |
| preaction |
pre_none,pre_smi, pre_nmi, pre_intのいずれかを指定します。preopを動作させる通知手段を設定します。 ・pre_noneはなにもしません。 ・pre_smiはIPMI物理インターフェースであるSMI(System Management ・pre_nmiはNMI割り込みにより通知します。 ・pre_intは割り込みにより通知します。 |
| preop |
preop_none, preop_panic のいずれかを指定します。 ・preop_noneはなにもしません。 ・preop_panicはカーネルパニックを発生させます。 |
２．IPMI watchdogドライバのロード
(１) 以下のコマンドにて IPMI watchdogドライバをロードします。
# service ipmi start
Starting ipmi drivers: [ OK ]
Starting ipmi_watchdog driver: [ OK ]
(２) システムの起動時に自動でIPMI watchdogを有効にするには、以下のコマンドを実行します。
# chkconfig ipmi on
ドライバのロード後には以下のメッセージが出力されます。
# dmesg
・・・・
ipmi: Found new BMC (man_id: 0x0002a2, prod_id: 0x0000, dev_id: 0x20)
IPMI kcs interface initialized
ipmi device interface
IPMI Watchdog: driver initialized
以上でデバイスファイル/dev/watchdogが作成されます。
３．watchdogデーモンの起動
(１) /etc/watchdog.confを開いて以下の行をコメントアウトします。
#watchdog-device = /dev/watchdog
(２) watchdogデーモンを起動します。
# service watchdog start
(３) システムの起動時に自動でwatchdogデーモンを起動するには、以下のコマンドを実行します。
# chkconfig watchdog on
[注意事項]
本ドキュメントの内容は、予告なしに変更される場合があります。
本ドキュメントは、限られた評価環境における検証結果をもとに作成しており、全ての環境での動作を保証するものではありません。
本ドキュメントの内容に基づき、導入、設定、運用を行ったことにより損害が生じた場合でも、弊社はその損害についての責任を負いません。あくまでお客様のご判断にてご使用ください。
[更新履歴]
2012年 1月27日 watchdogの起動方法を追加
2010年 2月 9日 新規作成
ログローテートするログファイルの監視
[概 要]
本ドキュメントでは、Zabbix エージェントにおいて、ログローテートされるログファイルを監視する設定方法をご紹介します。この設定により、ログローテートされる直前にログファイルに記録されたログを取りこぼす可能性を減らすことができます。
[注意事項]
この機能はミラクル・リナックス配布の zabbix-agentd 1.6.8-3 以降の 1.6 系のバージョンにて利用可能です。
[確認環境]
Zabbixサーバ: ミラクル・リナックス配布のLinux版 zabbix-server 1.6.8-3 以降
Zabbixエージェント: ミラクル・リナックス配布の zabbix-agentd 1.6.8-3 以降
Zabbixサーバ動作確認OS: Asianux Server 3 ==MIRACLE LINUX V5(32bit、64bit)
Zabbixエージェント動作確認OS: Asianux Server 3 ==MIRACLE LINUX V5(32bit、64bit), Windows 2000 Server, Windows Server 2003 x86, Windows Server 2003 x64, Windows Server 2008 x86, Windows Server 2008 x64
[手 順]
■Zabbixに登録している監視対象ホストのホスト名と、設定ファイルzabbix_agentd.confのHostnameが一致していることを確認
Hostname=「監視対象ホストのホスト名」
この設定をしていない場合は、zabbix_agentd.confに設定してZabbixエージェントを再起動して下さい。
■ログローテートに対応したログファイルの監視設定
ログローテートされるログファイルの監視に対応するために、監視設定に使用するキーの引数を拡張しています。以下を参考にキーの設定をしてください。引数3, 4がミラクル・リナックスによる拡張部分になります。
log[ログファイル <, 正規表現, ログローテート後のログファイル名, エンコード指定>]
引数1: 監視対象のログファイル名を指定してください
引数2: 正規表現（省略可能）
引数3: 監視対象のログファイルのログローテート後のファイル名を指定してください（省略可能）
引数4: 監視対象のログファイルのエンコードを指定してください。「ACP」（SJISを使用する場合はこちら）もしくは「UTF8」を指定可能です。何も指定しない場合はASCII文字列として読み込みます。（省略可能）
今回の例では以下のような設定をしました。
名前: log[c:\out.log,,c:\out.log.1] ・・・任意の文字列を設定可能
タイプ: ZABBIXエージェント(アクティブ)
キー: log[c:\out.log,,c:\out.log.1] ・・・次のキーについての説明を参照のこと
データ型: ログ
更新間隔(秒): 1 ・・・ログの取りこぼしを避けるため、1秒に設定することを推奨
ヒストリの保存期間(日): 7 ・・・任意の期間を設定可能
ステータス: 有効
キーについての説明:
log[c:\out.log,,c:\out.log.1]
引数1: 監視対象のログファイル名として、c:\out.log を指定
引数2: なし
引数3: 監視対象のログファイルのログローテート後のファイル名として、c:\out.log.1 を指定
引数4: なし
■監視ログを確認
数分待つと以下のようにログが収集されはじめます。
[更新履歴]
2010年 2月 3日 新規作成
MIRACLE ZBX エージェントを複数 MIRACLE ZBX サーバーからアクティブチェック監視する設定
[概 要]
本ドキュメントでは、log[]、logrt[]キーなどのログ監視で特に使用されるアクティブチェック監視において、単一の Zabbix エージェントを複数の Zabbix サーバーから監視可能にするための設定をご紹介します。
[注意事項]
この機能はミラクル・リナックスで独自に追加した機能であるため、ミラクル・リナックス配布の zabbix-agent 1.6.9-12 以降の 1.6 系バージョン、もしくは、zabbix-agent 1.8.3-3 以降の 1.8 系バージョンにて利用可能です。
[確認環境]
Zabbixサーバー: ミラクル・リナックス配布のLinux版 zabbix-server 1.6.9-12 以降もしくは、zabbix-server 1.8.3-3 以降
Zabbixエージェント: ミラクル・リナックス配布のLinux版 zabbix-agent 1.6.9-12 以降もしくは、zabbix-agent 1.8.3-3 以降
[手 順]
■zabbix_agentd.conf ファイルに「ActiveCheckServer」設定を追加
以下のように /etc/zabbix/zabbix_agentd.conf ファイルに「ActiveCheckServer」オプションを設定し、アクティブチェックを行う Zabbix サーバーのアドレスを設定してください。
以下はアクティブチェック監視を行う Zabbix サーバーのアドレスが「xxx.xxx.xxx.xxx」と「yyy.yyy.yyy.yyy」だった場合の設定になります。「Server」の設定と同じ内容を「ActiveCheckServer」として登録していただければ問題ありません。
なお、「ActiveCheckServer」オプションを設定しない場合には、オリジナルの Zabbix と同様の動作になり、「Server」オプションの先頭に記述されたホスト1つのみに対してアクティブチェックの動作を行います。
Server=xxx.xxx.xxx.xxx,yyy.yyy.yyy.yyy
ActiveCheckServer=xxx.xxx.xxx.xxx,yyy.yyy.yyy.yyy ← この行を追加
■Zabbix エージェントサービスの再起動
「ActiveCheckServer」の設定後、Zabbix エージェントサービスの再起動を行います。
以下は Linux での例になります。Windows の場合は[管理ツール]内の[サービス]からZabbix Agentを再起動してください。その他 Unix 系 OS においても同様にサービスの再起動を行ってください。
# service zabbix-agent restart
上記設定を完了すると、単一の Zabbix エージェントを複数の Zabbix サーバーからアクティブチェック監視することが可能になります。
[更新履歴]
2010年 2月 3日 新規作成
Windowsにおける日本語ログファイルの監視
[概 要]
本ドキュメントでは、Windows版のZabbix エージェントにおいて、SJISおよびUTF-8で保存されている日本語ログファイルを文字化けすることなく収集する設定方法をご紹介します。
[注意事項]
この機能はミラクル・リナックス配布のWindows版 zabbix-agentd 1.6.8-4 以降の 1.6 系バージョンにおいてにて利用可能です。
[確認環境]
Zabbixサーバ: ミラクル・リナックス配布のLinux版 zabbix-server 1.6.8-4 以降
Zabbixエージェント: ミラクル・リナックス配布のWindows版 zabbix-agentd 1.6.8-4 以降
Zabbixサーバ動作確認OS: Asianux Server 3 ==MIRACLE LINUX V5(32bit、64bit)
Zabbixエージェント動作確認OS: Windows 2000 Server, Windows Server 2003 x86, Windows Server 2003 x64, Windows Server 2008 x86, Windows Server 2008 x64
[事前準備]
以降の手順を実施する前に、必ず以下の点について確認して下さい。
■MySQLのZabbixデータベースがutf8のテーブルで構成されている
以下コマンドでテーブルがutf8で構成されていることを確認してください。
utf8で構成されている場合には太字部分のように「DEFAULT CHARSET=utf8」と表示されます。
# echo "show create table history_log;" | mysql -u「Zabbixデータベースのユーザ名」 -p 「Zabbixデータベース名」
Enter password: ・・・Zabbixデータベースのパスワードを入力
Table Create Table
history_log CREATE TABLE `history_log` (\n `id` bigint(20) unsigned NOT NULL default '0',\n `itemid` bigint(20) unsigned NOT NULL default '0',\n `clock` int(11) NOT NULL default '0',\n `timestamp` int(11) NOT NULL default '0',\n `source` varchar(64) NOT NULL default '',\n `severity` int(11) NOT NULL default '0',\n `value` text NOT NULL,\n PRIMARY KEY (`id`),\n UNIQUE KEY `history_log_2` (`itemid`,`id`),\n KEY `history_log_1` (`itemid`,`clock`)\n) ENGINE=InnoDB DEFAULT CHARSET=utf8
この設定が存在しない場合には、再度Zabbixデータベースを以下オプションを付けて作成し直す必要があります。
mysql> create database 「Zabbixデータベース名」 default character set utf8;
なお、ミラクル・リナックス提供のZabbixインストール手順書は、utf8の設定がされる手順になっているため、ミラクル・リナックス提供の手順書に従ってインストールした場合にはすでにこの設定は完了しています。
■MySQLの設定ファイル/etc/my.cnfの[mysqld]セクションにutf8の設定が存在する
/etc/my.cnfの内容を確認し、[mysqld]セクションに以下の設定が存在することを確認してください。
[mysqld]
（略）
default-character-set=utf8
skip-character-set-client-handshake
（略）
なお、ミラクル・リナックス提供のZabbixインストール手順書は、utf8の設定がされる手順になっているため、ミラクル・リナックス提供の手順書に従ってインストールした場合にはすでにこの設定は完了しています。
[手 順]
■Zabbixに登録している監視対象ホストのホスト名と、設定ファイルzabbix_agentd.confのHostnameが一致していることを確認
Hostname=「監視対象ホストのホスト名」
この設定をしていない場合は、zabbix_agentd.confに設定してZabbixエージェントを再起動して下さい。
■Zabbixエージェントの設定ファイルzabbix_agentd.confに以下の記述が存在することを確認
Encoding=utf8
この設定が存在しない場合は、zabbix_agentd.confに追記してZabbixエージェントを再起動して下さい。
なお、ミラクル・リナックス配布のWindows版 zabbix-agentd にはデフォルトで設定が記述されています。
■日本語ログファイルの監視設定
日本語ログファイルの監視に対応するために、監視設定に使用するキーの引数を拡張しています。以下を参考にキーの設定をしてください。
log[ログファイル <, 正規表現, ログローテート後のログファイル名, エンコード指定>]
引数1: 監視対象のログファイル名を指定してください
引数2: 正規表現（省略可能）
引数3: 監視対象のログファイルのログローテート後のファイル名を指定してください（省略可能）
引数4: 監視対象のログファイルのエンコードを指定してください。「ACP」（SJISを使用する場合はこちら）もしくは「UTF8」を指定可能です。何も指定しない場合はASCII文字列として読み込みます。（省略可能）
今回の例では以下のような設定をしました。
名前: log[c:\out.log,,,ACP] ・・・任意の文字列を設定可能
タイプ: ZABBIXエージェント(アクティブ)
キー: log[c:\out.log,,,ACP] ・・・次のキーについての説明を参照のこと
データ型: ログ
更新間隔(秒): 1 ・・・ログの取りこぼしを避けるため、1秒に設定することを推奨
ヒストリの保存期間(日): 7 ・・・任意の期間を設定可能
ステータス: 有効
キーについての説明:
log[c:\out.log,,,ACP]
引数1: 監視対象のログファイル名として、c:\out.log を指定
引数2: なし
引数3: なし
引数4: SJISで記録されるファイルを監視するため、「ACP」を指定
■監視ログを確認
数分待つと以下のようにログが収集されはじめます。
[更新履歴]
2010年 2月 3日 新規作成
Windowsにおける日本語イベントログの監視
[概 要]
本ドキュメントでは、Windows版のZabbix エージェントにおいて、Windowsの出力する日本語のイベントログを文字化けすることなく収集する設定方法をご紹介します。
[注意事項]
この機能はミラクル・リナックス配布のWindows版 zabbix-agentd 1.4.6-1 以降にて利用可能です。
[確認環境]
Zabbixサーバ: ミラクル・リナックス配布のLinux版 zabbix-server 1.4.6-1 以降
Zabbixエージェント: ミラクル・リナックス配布のWindows版 zabbix-agentd 1.4.6-1 以降
Zabbixサーバ動作確認OS: Asianux Server 3 ==MIRACLE LINUX V5(32bit、64bit)
Zabbixエージェント動作確認OS: Windows 2000 Server, Windows Server 2003 x86, Windows Server 2003 x64
[事前準備]
以降の手順を実施する前に、必ず以下の点について確認して下さい。
■MySQLのZabbixデータベースがutf8のテーブルで構成されている
以下コマンドでテーブルがutf8で構成されていることを確認してください。
utf8で構成されている場合には太字部分のように「DEFAULT CHARSET=utf8」と表示されます。
# echo "show create table history_log;" | mysql -u「Zabbixデータベースのユーザ名」 -p 「Zabbixデータベース名」
Enter password: ・・・Zabbixデータベースのパスワードを入力
Table Create Table
history_log CREATE TABLE `history_log` (\n `id` bigint(20) unsigned NOT NULL default '0',\n `itemid` bigint(20) unsigned NOT NULL default '0',\n `clock` int(11) NOT NULL default '0',\n `timestamp` int(11) NOT NULL default '0',\n `source` varchar(64) NOT NULL default '',\n `severity` int(11) NOT NULL default '0',\n `value` text NOT NULL,\n PRIMARY KEY (`id`),\n UNIQUE KEY `history_log_2` (`itemid`,`id`),\n KEY `history_log_1` (`itemid`,`clock`)\n) ENGINE=InnoDB DEFAULT CHARSET=utf8
この設定が存在しない場合には、再度Zabbixデータベースを以下オプションを付けて作成し直す必要があります。
mysql> create database 「Zabbixデータベース名」 default character set utf8;
なお、ミラクル・リナックス提供のZabbixインストール手順書は、utf8の設定がされる手順になっているため、ミラクル・リナックス提供の手順書に従ってインストールした場合にはすでにこの設定は完了しています。
■MySQLの設定ファイル/etc/my.cnfの[mysqld]セクションにutf8の設定が存在する
/etc/my.cnfの内容を確認し、[mysqld]セクションに以下の設定が存在することを確認してください。
[mysqld]
（略）
default-character-set=utf8
skip-character-set-client-handshake
（略）
なお、ミラクル・リナックス提供のZabbixインストール手順書は、utf8の設定がされる手順になっているため、ミラクル・リナックス提供の手順書に従ってインストールした場合にはすでにこの設定は完了しています。
[手 順]
■Zabbixに登録している監視対象ホストのホスト名と、設定ファイルzabbix_agentd.confのHostnameが一致していることを確認
Hostname=「監視対象ホストのホスト名」
この設定をしていない場合は、zabbix_agentd.confに設定してZabbixエージェントを再起動して下さい。
■Zabbixエージェントの設定ファイルzabbix_agentd.confに以下の記述が存在することを確認
Encoding=utf8
この設定が存在しない場合は、zabbix_agentd.confに追記してZabbixエージェントを再起動して下さい。
なお、ミラクル・リナックス配布のWindows版 zabbix-agentd にはデフォルトで設定が記述されています。
■Windowsイベントログの監視設定
監視設定は通常のWindowsイベントログ監視設定と同様です。
今回の例では以下のような設定をしました。
名前: eventlog[System] ・・・任意の文字列を設定可能
タイプ: ZABBIXエージェント(アクティブ)
キー: eventlog[System] ・・・Application、Security、System等を設定可能
データ型: ログ
更新間隔(秒): 1 ・・・ログの取りこぼしを避けるため、1秒に設定することを推奨
ヒストリの保存期間(日): 7 ・・・任意の期間を設定可能
ステータス: 有効
■監視ログを確認
数分待つと以下のようにイベントログが収集されはじめます。
[更新履歴]
2010年 2月 3日 新規作成
4096を越えるMTUを設定した場合、igbドライバで性能が劣化する問題
[対象となる製品のバージョン]
MIRACLE LINUX V4.0 SP4 - Asianux Inside
MIRACLE LINUX V4.0 SP4 - Asianux Inside for x86-64
[質問]
igbドライバを使用して、4096を越えるMTUを設定した場合、数10%の性能劣化します。
[対処]
現在のところ対処はありません。
[注意事項]
本ドキュメントの内容は、予告なしに変更される場合があります。
本ドキュメントは、限られた評価環境における検証結果をもとに作成しており、全ての環境での動作を保証するものではありません。
本ドキュメントの内容に基づき、導入、設定、運用を行ったことにより損害が生じた場合でも、弊社はその損害についての責任を負いません。あくまでお客様のご判断にてご使用ください。
[更新履歴]
2010年 1月 20日 新規作成