RSS配信記事

アップデート情報

ミラクル・リナックス提供の 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 SSSGuestOSCLUSTERPROをインストールします。

 

GuestOS上のSW障害にはGuestOSにインストールされたCLUSTERPROが障害を検知し、待機系へ業務をフェイルオーバします。

 

物理サーバのHW障害時はサービスコンソールにインストールされたCLUSTERPRO SSSGuestOS上のCLUSTERPROにフェイルオーバのリクエストを送ります。リクエストを受けたGuestOS上で業務が待機系にフェイルオーバします。

 

上記のような構成をとることによって、物理サーバから仮想マシン上の業務まで障害を素早く検知し、速やかに業務をフェイルオーバ、業務を継続することが可能となります。

 

 

 

[環境構築]

環境構築方法を示します。

なお、本手順ではすでに物理サーバにVMware ESXがインストールされ、仮想マシンが作成されているものとします。

 

1.仮想マシンへGuestOSのインストール
仮想マシンにGuestOSをインストールします。
OSインストール後、VMwareToolsをインストール/設定を行ってください。

 

2.GuestOS上にCLUSTERPROの構築
GuestOS上にCLUSTERPROを構築します。

 

この際、クラスタ間処理要求機能を使って、サービスコンソール上のCLUSTERPRO SSSから仮想マシン上のCLUSTERPROへ処理要求を出せるよう、設定を行います。

 

GuestOS上にインストールされた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

 

 


グループリソース設定
グループ名
failover
floating ip resource
グループリソース名
fip
IPアドレス
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
監視方法
softdog

NIC 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回
活性最終動作
何もしない

 

 

3.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ではuserwuser空間監視)でipmisoftdogを指定しているとエラーとなります。

そのため、userwを利用する場合は監視方法を[keepalive]に変更します。
 

 

 

クラスタ間処理要求の設定を行います。

VMware ESXハイパーバイザ上のCLUSTERPRO SSSのモニタリソースが反応したら、GuestOS上のCLUSTERPROにフェイルオーバリクエストを発行し、GuestOS上で動作している業務を待機系にフェイルオーバさせます。

 

モニタリソースの[異常検出]タブで[最終動作前にスクリプトを実行する]にチェックを入れ、[設定]を選択します。
 

 

 

 
ここで、モニタリソース反応時に実行するスクリプトを登録します。

 

ここでは以下のようなスクリプトを実行しました。

 

preaction.sh

#! /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
監視方法
keepalive

NIC 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 SSSNICLink 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.フェイルオーバ完了

 

上記のように正しくフェイルオーバリクエストが送信されて、仮想マシン上で業務がフェイルオーバされることを確認できました。

 

 

 

 

 

[注意事項]

 

本ドキュメントの内容は、予告なしに変更される場合があります。

本ドキュメントは、限られた評価環境における検証結果をもとに作成しており、 全ての環境での動作を保証するものではありません。

本ドキュメントの内容に基づき、導入、設定、運用を行なったことにより損害が生じた場合でも、
弊社はその損害についての責任を負いません。あくまでお客様のご判断にてご使用ください。

 

VMware上でのCLUSTERPRO製品の販売、構築につきましては以下にご相談ください。
 

 

NetVault Backupの障害発生時の初動調査および情報採取のための事前準備

[概要]

障害発生に備え、あらかじめ初動調査を把握しておくことや、情報採取のために準備しておくことは、障害の原因を調査するうえで大変重要です。

本ドキュメントでは、NetVault Backupで障害発生時に、お問合せの前に事前に確認、準備すべき内容について説明します。

 

[対象となる製品のバージョン]

NetVault Backup 8.1以降

 

[注意事項]

本ドキュメントの内容は、予告なしに変更される場合があります。

 

[初動調査]

障害発生の際には、以下の点についてご確認ください。これらは、サポート窓口へお問合せいただいた際にも質問される内容ですので、事前に準備していただくことにより問題の早期解決に役立ちます。
使用環境の確認
・ハードウェアの構成
NetVaultサーバ、バックアップ対象のOSとバージョン
・シリアルナンバー
NetVaultバージョン
・利用しているAPM

 

現象内容についての把握
・現象発生日時
・現象と問題点の詳細
・現象の再現性の有無について
・現象に再現性がある場合、その再現手順
・現象発生日時の近辺に行っていた操作内容
・コンソールに表示されるエラーメッセージ
・その他の気づいた点について

 

[情報採取のための事前準備]

ミラクル・リナックス カスタマーサポートセンターでは、[初動調査]と併せて、現象に応じた情報採取をお願いしています。採取依頼のあった情報を採取できるように、事前に準備をしていただくことをお勧めします。

 

OSの情報採取

MIRACLE LINUXAsianuxをお使いの場合は、/usr/sbin/mcinfo を利用します。

mcinfoコマンドは、現在稼動しているホストの各種ログやハードウェア情報、インストールされているパッケージ情報など、さまざまな情報を取得するコマンドです。

なお、mcinfoの取得情報の中には、rootユーザーでしか取得できないものもあるため、/usr/sbin/mcinfo コマンドはrootユーザーで実行します。

 

MIRACLE LINUX v4.0 SP2 より前のバージョンをご使用の場合

mcinfoコマンドの結果(mcinfo.log.gz)
 

# mcinfo | gzip > mcinfo.log.gz

 

MIRACLE LINUX v4.0 SP3Asinaux Server 3 == MIRACLE LINUX V.5 以降をご使用の場合

mcinfoコマンドの結果(mcinfo-***.tar.bz2)
 

# mcinfo

 

NetVault Backupのバイナリログ取得

NetVault BackupではNetVault GUILogsからログの参照が可能です。

障害を解析するには上記で参照できるログが必要となるため、ログの保存方法をご紹介します。

 

NetVault backupのログ収集はNetVault GUIを使いGUIで行う方法と、コマンドで行う方法があります。これらは、どちらの方法でも同じ情報が取得されます。

 

NetVault GUIからログを取得する方法

以下のコマンドを実行してnetVault GUIを起動します。

 

# nvgui

 

netVault GUIが起動したら、[ログ]を選択します。

 

 

 

以下のようなログウィンドウが表示されます。
メニューの[オプション]→[ログファイルへ保存]を選択します。
 

 

 

ログの保存先ファイル名を入力し、形式が[バイナリ]になっていることを確認してください。
このとき、テキスト形式でログを保存すると、障害解析に必要な一部のログが保存されません。
 

 

 

上記で[OK]を選択すると、/usr/netvault/logs/dumps/binary以下に指定したファイル名でログが保存されます。

 

・コマンドでログを取得する場合
先ほどは、ログの取得をGUI上から行いましたが、まったく同じことがコマンドラインからも行えます。最低限、ファイル名と開始と終了の日時を指定する必要があります。

以下の例では "nvbinlog20040607_02.nlg"というファイル名で20041100:00.002004123123:59.59までのログをとるよう指定しています。

 

# cd /usr/netvault/util/

# ./nvlogdump -filename nvbinlog20040607_02 -starttime 20040101000000 -endtime 20041231235959

 

上記コマンドを実行すると、NetVault GUIを使ってのログ取得と同様、/usr/netvault/logs/dumps/binary以下に指定したファイル名でログが保存されます。

 

 

[更新履歴]
2010715日 新規作成

 

CLUSTERPROの障害発生時の初動調査および情報採取のための事前準備

[概要]

障害発生に備え、あらかじめ初動調査を把握しておくことや、情報採取のために準備しておくことは、障害の原因を調査するうえで大変重要です。
本ドキュメントでは、CLUSTERPRO環境で障害発生時に、お問合せの前に事前に確認、準備すべき内容について説明します。

 

[対象となる製品のバージョン]

CLUSTERPRO X3

CLUSTERPRO X2.1

CLUSTERPRO X2.0

CLUSTERPRO X1.0

CLUSTERPRO for Linux Ver3.x SE/LE

 

[注意事項]

本ドキュメントの内容は、予告なしに変更される場合があります。

 

[初動調査]

障害発生の際には、以下の点についてご確認ください。これらは、サポート窓口へお問合せいただいた際にも質問される内容ですので、事前に準備していただくことにより問題の早期解決に役立ちます。
使用環境の確認
・ハードウェアの構成
・使用OSとバージョン
・アプリケーションの種類、バージョン

 

現象内容についての把握
・現象発生日時
・現象と問題点の詳細
・現象の再現性の有無について
・現象に再現性がある場合、その再現手順
・現象発生日時の近辺に行っていた操作内容
・コンソールに表示されるエラーメッセージ
・その他の気づいた点について

 

[情報採取のための事前準備]

ミラクル・リナックス カスタマーサポートセンターでは、[初動調査]と併せて、現象に応じた情報採取をお願いしています。採取依頼のあった情報を採取できるように、事前に準備をしていただくことをお勧めします。

 

OSの情報採取

MIRACLE LINUXAsianuxをお使いの場合は、/usr/sbin/mcinfo を利用します。

mcinfoコマンドは、現在稼動しているホストの各種ログやハードウェア情報、インストールされているパッケージ情報など、さまざまな情報を取得するコマンドです。

なお、mcinfoの取得情報の中には、rootユーザーでしか取得できないものもあるため、/usr/sbin/mcinfo コマンドはrootユーザーで実行します。

 

MIRACLE LINUX v4.0 SP2 より前のバージョンをご使用の場合

mcinfoコマンドの結果(mcinfo.log.gz)
 

# mcinfo | gzip > mcinfo.log.gz

 

MIRACLE LINUX v4.0 SP3Asinaux Server 3 == MIRACLE LINUX V.5 以降をご使用の場合

mcinfoコマンドの結果(mcinfo-***.tar.bz2)
 

# mcinfo

 

CLUSTERPROの情報採取
CLUSTERPROにはCLUSTERPROの状況確認に必要なログと設定を全クラスタメンバで一括収集する機能があります。
CLUSTERPROの情報収集はブラウザを使いGUIで行う方法と、コマンドで行う方法があります。これらは、どちらの方法でも同じ情報が取得されます。

 

・ブラウザで行う方法
ブラウザより以下のURLへ接続し、WebManagerを起動します。
http://<サーバのIPアドレス>:29003
 

 

 

[ログ収集]ボタンをクリックすると以下の画面がポップアップされます。
 

 

 

パターンが両サーバとも[パターン1]となっていることを確認し、[OK]を選択します。
 

 

 

進捗ウィンドウが表示されます。進捗状況が100%となると、以下のウィンドウがポップアップされますので、ファイルを任意の場所に保存してください。

 

 

 

 

・コマンドで行う場合
/usr/sbin/clplogccコマンドはrootユーザで実効します。本コマンドは全クラスタメンバから情報を収集するため、完了するまでに時間がかかる場合があります。
 

# clplogcc -o <ログ出力先ディレクトリパス>

 
上記コマンドを実効すると指定したログ出力先ディレクトリに<ホスト名>-log.tar.gzが作成されます。

 

 

[更新履歴]
20107月15日 新規作成
2017年12月4日 対象バージョン追加
 

 

ネットワーク帯域制御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年 526日 新規作成

 

『/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

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

 

 

[注意事項]

本ドキュメントの内容は、予告なしに変更される場合があります。

本ドキュメントは、限られた評価環境における検証結果をもとに作成しており、 全ての環境での動作を保証するものではありません。

本ドキュメントの内容に基づき、導入、設定、運用を行なったことにより損害が生じた場合でも、

弊社はその損害についての責任を負いません。あくまでお客様のご判断にてご使用ください。

 

[更新履歴]

2010524日 新規作成

 

「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年 46日 新規作成

 

 

/usr を別パーティションにしている場合のアップグレードの諸注意

[対象となる製品のバージョン]

 

Asianux Server 3 for x86(32bit)

Asianux Server 3 for x86-64(64bit)

 

[質  問]

/usr を別パーティションで構成している環境の場合、device-mapper-1.02.32-1.AXS3にアップデートをした後、再起動を行うとvmsetupfsckにて「libreadline.so.5」が見つからないと表示されOSが起動できなくなる問題があります。
この問題はdevice-mapper-1.02.39-1.1.AXS3以降のバージョンで修正されていますので、 パッケージを最新バージョンにアップデートいただくことで解決します。また、下記の[対処]方法によっても解決することが可能です。

 

device-mapperのアップデート情報

https://tsn.miraclelinux.com/tsn_local/index.php?m=errata&a=detail&eid=1030

 

[対  処]

/usr を別パーティションで構成している環境の場合は、device-mapper-1.02.32-1.AXS3へのアップデートは行わないでください。

device-mapperのアップデートを必要とする場合は、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

 

x86-64版での例です。X86版ではlib64libに読みかえてください。

 

上記手順を行わず再起動した場合は、インストールCDまたはDVDrescueモードで起動し、上記ライブラリをコピーした後、システムをsingleモードで起動し、ldconfigを行ってください。

 

[注意事項]
本ドキュメントの内容は、予告なしに変更される場合があります。
本ドキュメントは、限られた評価環境における検証結果をもとに作成しており、全ての環境での動作を保証するものではありません。
本ドキュメントの内容に基づき、導入、設定、運用を行ったことにより損害が生じた場合でも、弊社はその損害についての責任を負いません。あくまでお客様のご判断にてご使用ください。

 

[更新履歴]

2010年 330日 新規作成

2010年 419日 修正

 

"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 )

 

[対  処]
DSPDを無効(OFF)にするため、82573(V/L/E)EEPROMを書き換えることにより、このメッセージは出力されなくなります。
82573(V/L/E)EEPROMDSPDを無効(OFF)にするためのスクリプトは以下のURLから入手できます。

 

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年 31日 新規作成

 

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

 

[問題]

HPSmartArrayに接続したTAPEドライブが使用できない。

 

[注意事項]

本ドキュメントは、各ソフトウェア開発元の情報およびマニュアル等を元にした参考情報です。本ドキュメントの内容は、予告なしに変更される場合があります。本ドキュメントは、限られた評価環境における検証結果をもとに作成しており、全ての環境での動作を保証するものではありません。本ドキュメントの内容に基づき、導入、設定、運用を行なったことにより損害が生じた場合でも、弊社はその損害についての責任を負いません。あくまでお客様のご判断にてご使用ください。本ドキュメントで使用しているソフトウェアのセキュリティ等の詳細な設定につきましては、マニュアル等をご参照ください。

 

[問題詳細]

HP社のSmartArrayTAPEドライブを接続した場合、通常のインストール作業だけでは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 1225 04:24 /dev/nst0

crw-rw---- 1 root disk 9, 0 1225 04:24 /dev/st0

 

[参考情報]

・このドキュメントはHP社のページを参考に作成しました。あわせて以下のURLをご確認ください。

SmartArray/ccissでの TAPE(SCSI)サポートについて

http://h50146.www5.hp.com/products/software/oe/linux/mainstream/support/doc/option/array/tape_cciss-scsi.html

 

SmartArray/ccissでの TAPE(SAS)サポートについて

http://h50146.www5.hp.com/products/software/oe/linux/mainstream/support/doc/option/array/tape_cciss-sas.html

 

・詳細情報は下記のドキュメントにも記載されています。

/usr/share/doc/kernel-doc-バージョン番号/Documentation/cciss.txt

 

 

[更新履歴]

  2010 225日 新規作成

 

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-oci8phpOracle 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

 

 

[更新履歴]

2010225日 新規作成

 

 

新 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パッケージをダウンロードしてください。

https://tsn.miraclelinux.com/tsn_local/index.php?m=errata&a=detail&eid=890&sType=&sProduct=&published=1

 

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年 216日 新規作成

 

 

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

 

[設定手順]

1.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
  Interface)を使用しIPMIへ通知します。

・pre_nmiはNMI割り込みにより通知します。

・pre_intは割り込みにより通知します。

preop

preop_none, preop_panic のいずれかを指定します。

・preop_noneはなにもしません。

・preop_panicはカーネルパニックを発生させます。

 

 

2.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が作成されます。

 

 

3.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サーバ: ミラクル・リナックス配布のLinuxzabbix-server 1.6.8-3 以降

Zabbixエージェント: ミラクル・リナックス配布の zabbix-agentd 1.6.8-3 以降

 

Zabbixサーバ動作確認OS: Asianux Server 3 ==MIRACLE LINUX V5(32bit64bit)

Zabbixエージェント動作確認OS: Asianux Server 3 ==MIRACLE LINUX V5(32bit64bit), Windows 2000 Server, Windows Server 2003 x86, Windows Server 2003 x64, Windows Server 2008 x86, Windows Server 2008 x64

 

 

[手  順]

Zabbixに登録している監視対象ホストのホスト名と、設定ファイルzabbix_agentd.confHostnameが一致していることを確認

 

 

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 23日 新規作成

 

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 23日 新規作成

 

Windowsにおける日本語ログファイルの監視

[概  要]

本ドキュメントでは、Windows版のZabbix エージェントにおいて、SJISおよびUTF-8で保存されている日本語ログファイルを文字化けすることなく収集する設定方法をご紹介します。

 

 

[注意事項]

この機能はミラクル・リナックス配布のWindowszabbix-agentd 1.6.8-4 以降の 1.6 系バージョンにおいてにて利用可能です。

 

 

[確認環境]

Zabbixサーバ: ミラクル・リナックス配布のLinuxzabbix-server 1.6.8-4 以降

Zabbixエージェント: ミラクル・リナックス配布のWindowszabbix-agentd 1.6.8-4 以降

 

Zabbixサーバ動作確認OS: Asianux Server 3 ==MIRACLE LINUX V5(32bit64bit)

Zabbixエージェント動作確認OS: Windows 2000 Server, Windows Server 2003 x86, Windows Server 2003 x64, Windows Server 2008 x86, Windows Server 2008 x64

 

 

[事前準備]

以降の手順を実施する前に、必ず以下の点について確認して下さい。

 

MySQLZabbixデータベースがutf8のテーブルで構成されている

以下コマンドでテーブルがutf8で構成されていることを確認してください。

utf8で構成されている場合には太字部分のように「DEFAULT CHARSET=utf8」と表示されます。

 

 

# echo "show create table history_log;" | mysql -uZabbixデータベースのユーザ名」 -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.confHostnameが一致していることを確認

 

 

Hostname=「監視対象ホストのホスト名」

 

 

この設定をしていない場合は、zabbix_agentd.confに設定してZabbixエージェントを再起動して下さい。

 

Zabbixエージェントの設定ファイルzabbix_agentd.confに以下の記述が存在することを確認

 

 

Encoding=utf8

 

 

この設定が存在しない場合は、zabbix_agentd.confに追記してZabbixエージェントを再起動して下さい。

なお、ミラクル・リナックス配布のWindowszabbix-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 23日 新規作成

 

Windowsにおける日本語イベントログの監視

[概  要]

本ドキュメントでは、Windows版のZabbix エージェントにおいて、Windowsの出力する日本語のイベントログを文字化けすることなく収集する設定方法をご紹介します。

 

 

[注意事項]

この機能はミラクル・リナックス配布のWindowszabbix-agentd 1.4.6-1 以降にて利用可能です。

 

 

[確認環境]

Zabbixサーバ: ミラクル・リナックス配布のLinuxzabbix-server 1.4.6-1 以降

Zabbixエージェント: ミラクル・リナックス配布のWindowszabbix-agentd 1.4.6-1 以降

 

Zabbixサーバ動作確認OS: Asianux Server 3 ==MIRACLE LINUX V5(32bit64bit)

Zabbixエージェント動作確認OS: Windows 2000 Server, Windows Server 2003 x86, Windows Server 2003 x64

 

 

[事前準備]

以降の手順を実施する前に、必ず以下の点について確認して下さい。

 

MySQLZabbixデータベースがutf8のテーブルで構成されている

以下コマンドでテーブルがutf8で構成されていることを確認してください。

utf8で構成されている場合には太字部分のように「DEFAULT CHARSET=utf8」と表示されます。

 

 

# echo "show create table history_log;" | mysql -uZabbixデータベースのユーザ名」 -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.confHostnameが一致していることを確認

 

 

Hostname=「監視対象ホストのホスト名」

 

 

この設定をしていない場合は、zabbix_agentd.confに設定してZabbixエージェントを再起動して下さい。

 

Zabbixエージェントの設定ファイルzabbix_agentd.confに以下の記述が存在することを確認

 

 

Encoding=utf8

 

 

この設定が存在しない場合は、zabbix_agentd.confに追記してZabbixエージェントを再起動して下さい。

なお、ミラクル・リナックス配布のWindowszabbix-agentd にはデフォルトで設定が記述されています。

 

Windowsイベントログの監視設定

 

監視設定は通常のWindowsイベントログ監視設定と同様です。

今回の例では以下のような設定をしました。

 

 

名前: eventlog[System] ・・・任意の文字列を設定可能

タイプ: ZABBIXエージェント(アクティブ)

キー: eventlog[System] ・・・ApplicationSecuritySystem等を設定可能

データ型: ログ

更新間隔(): 1 ・・・ログの取りこぼしを避けるため、1秒に設定することを推奨

ヒストリの保存期間(): 7 ・・・任意の期間を設定可能

ステータス: 有効

 

 

 

 

監視ログを確認

 

数分待つと以下のようにイベントログが収集されはじめます。

 

 

 

 

[更新履歴]

  2010 23日 新規作成

 

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 120日 新規作成

 

cpuspeed の出力するエラーメッセージについて

[対象となる製品のバージョン]

 

MIRACLE LINUX V4.0 SP4 - Asianux Inside

MIRACLE LINUX V4.0 SP4 - Asianux Inside for x86-64

 

[質問]

syslogに以下のようなメッセージが記録されることがあります。

 

cpuspeed: No cores spec'd, trying to figure it out...

cpuspeed: cpuspeed startup succeeded

 

 [原因]

このメッセージは、複数のcoreを持つCPUからcpuspeedに関する情報を1度に取得できない場合

に、このようなメッセージが出力されます。このメッセージを出力した後、複数coreに対して個別に

問い合わせを行い、適切な情報を取得するため、このメッセージが出力されたとしても、動作上問題はありません。

 

また、将来のcpuspeedパッケージには、このメッセージを抑制するようになっており、実害はありません。

 

 [対処]

メッセージを抑制する対処方法はありません。

メッセージが出力された場合は、無視してください。

 

 [注意事項]

本ドキュメントの内容は、予告なしに変更される場合があります。

本ドキュメントは、限られた評価環境における検証結果をもとに作成しており、全ての環境での動作を保証するものではありません。

本ドキュメントの内容に基づき、導入、設定、運用を行ったことにより損害が生じた場合でも、弊社はその損害についての責任を負いません。あくまでお客様のご判断にてご使用ください。

 

 [更新履歴]

  2010 120日 新規作成

 

MIRACLE LINUX V4.0 SP4 について

[概  要]

MIRACLE LINUX V4.0 SP4 (別名 Asianux 2.0 SP4) は、MIRACLE LINUX V4.0 の性能と機能の向上を実現させた、マイナーバージョンアップです。x86 アーキテクチャ (32bit) が動作対象となる MIRACLE LINUX V4.0 SP4、x86-64アーキテクチャ (64bit) が動作対象となる MIRACLE LINUX V4.0 SP4 for x86-64の2種類がありますが、これらの導入方法に違いはありません。

以降、この文書ではこれら2つのことを SP4 と称します。

 

SP4 には、2009年12月18日までに弊社ウェブサイトで公開された修正をすべて含んだ上で、新しい修正や機能が追加されています。
SP4 で新たに追加・修正が行われたパッケージの一覧は以下の通りです。 

MIRACLE LINUX V4.0 SP4 追加・修正パッケージ一覧

 

また、SP4 DVDメディアに含まれるパッケージの一覧は以下の通りです。 

MIRACLE LINUX V4.0 SP4 rpm 一覧

MIRACLE LINUX V4.0 SP4 for x86-64 rpm 一覧

 

対応する Developer CD の収録物は以下の通りです 

  MIRACLE LINUX V4.0 SP4 Developer CD 収録 rpm 一覧

 
[注意事項]

1.MIRACLE LINUX V4.0 SP4 のインストールメディアは、システムの新規インストールのみに対応しています。
現在運用中のシステムを SP4 相当にアップグレードするには mlupdater-1.4.0-8AX 以降をご利用ください。SP4 でアップグレードされるパッケージあるいは SP4 より更に改善が加えられたパッケージが全て mlupdater 経由でご利用いただけます。


mlupdater
のかわりに rpm コマンドによりアップグレードする方法につきましては、以下のリンク先の文章をご覧ください。

 

MIRACLE LINUX V4.0 SP3 から SP4 へ アップグレードする方法 (x86版)

MIRACLE LINUX V4.0 SP3 から SP4 へ アップグレードする方法 (x86-64版)

 

2.SP3 より ISO イメージが DVD 用に変更されています。DVD-ROMドライブをご用意下さい。

 

3.SP4 をご利用になる際は、必ずリリースノートに書かれた注意事項を確認してください。リリースノートは PDF またはテキスト形式で、ISO イメージと一緒に配布されています。

 

4.SP2 より前のシステムを SP4 相当にアップグレードする場合、リリースノートに加えて以下もご覧下さい。

 

4-1.フォント探索パス追加による影響について

MIRACLE LINUX V4.0 SP2 以降では、/usr/X11R6/lib/X11/fonts/75dpi が fontconfig ライブラリのフォント検索パスの先頭に追加されます。この影響で、MIRACLE LINUX V4.0 SP2 以降で X Window System 利用時のフォント表示が変更されることがあります。

以前の表示に戻したい場合は、以下の手順で /usr/X11R6/lib/X11/fonts/75dpi をフォント探索パスより削除してください。

 

/etc/fonts/fonts.conf を適当なエディタで開きます。

25行目付近の、"<dir>/usr/X11R6/lib/X11/fonts/75dpi</dir>" の文字列を削除します。

 

4-2.閉鎖環境におけるアップデートについて

インターネットに接続されていないシステムをアップデートするには、mlupdater マニュアルにある手動ミラー配布サーバを用意していただき、mlupdater 1.4.0-8AX 以降で、アップデート作業を行ってください。

 

4-3Oracle 関連パッケージのカーネルへの統合について

以前は oracleasm および ocfs2295 パッケージで提供していた Oracle ASM library kernel driver および OCFS2 driver については、SP2 以降では kernel パッケージが提供します。そのため両パッケージは不要となりました。ただし、Oracle ASM を利用するには引き続きoracleasm-support パッケージのインストールが必要です。

 

[DVD(ISO) イメージの利用方法]

1.SP4 より前の MIRACLE LINUX V4.0 をお持ちの方は、アップデートキットのページより ISO イメージがダウンロードいただけます。

ダウンロードには製品付属のシリアル番号が必要となります。

 

2.ダウンロード後、ダウンロードした ISO イメージが正しいかどうか、MD5SUM 値を確認してください。

以下は、ISO イメージを置いたディレクトリが /tmp の場合の実行例です。

 

# cd /tmp

# md5sum Asianux-20-SP4-ia32-dvddisc-200911261554.iso

ebac8a9496a387382c15404e0f00db29 Asianux-20-SP4-ia32-dvddisc-200911261554.iso

 

表示された値が、ISO イメージをダウンロードしたページに書かれた MD5SUM 値と一致すれば、ダウンロードは成功しています。

 

3.普段ご利用DVD-R/RW 作成ソフトで、入手した ISO イメージを DVD に記録します。

MIRACLE LINUX 上で記録する場合は、cdrtools (cdrecord) が使用できます。

 

4.SP3 インストールするサーバーの電源を入れ、作成した DVD-R/RW DVD-ROM ドライブに挿入します。

 

5.インストーラが起動した後のインストール方法は、全ての MIRACLE LINUX V4.0 のバージョンで同一です。製品付属、または以下のURLに掲載のインストレーションガイドを参照し、インストールを進めてください。

 

MIRACLE LINUX V4.0 SP4 インストレーションガイド

 

[更新履歴]
2010120日 新規作成

 

コンテンツの配信