:検証/ログサーバのバックアップ(No.15)

Top / :検証 / ログサーバ

Ciscoスイッチ
ログサーバ
ログストレージ
- System Managerの起動（マニュアルより）
syslog-ng
syslog-ngで毎回DNSクエリを出さないようにする方法
- 設定方法
- 確認方法
sshログイン時に時間が掛かる問題
サポート連絡先
- 東芝ITサービス株式会社
  - 情報収集が必要な項目
- netappホームページ

Ciscoスイッチ †

ログサーバ †

ログストレージ †

http://127.0.0.1:49241/?sid=5476746509845483702118448220498744662
127.0.0.1 への接続に失敗しました。
→インターネットオプションの「信頼済みサイト」にhttp://127.0.0.1を追加する必要がある。

* syslog-ngのインストール
** RPMでインストールできる？
今回はインストールしたマシンを持っていくので、rpmファイルで確保する事は必須ではない。yumでインストールしたマシンを持っていくことでも問題ない。
http://d.hatena.ne.jp/kt_hiro/20140609/1402294759

* ベンダに聞くこと
- B側でcf takeoverを実行しテイクオーバできたが（cf statusで確認、プロンプトで確認）、TOされたA側のIPアドレスは、B側に付与されなかった。
- 次に、元に戻すため、B側でcf givebackを実行したが、以下の様に表示されるも、ギブバックされなかったが、原因がわかりますか。結局、cf giveback -f で強制的に切り戻し、A側にログインできるようになった。
sen-mstr0102(takeover)> cf status
sen-mstr0102 has taken over sen-mstr0101.
sen-mstr0101 is ready for giveback.
Takeover due to negotiated failover, reason: operator initiated cf takeover
sen-mstr0102(takeover)> cf giveback -f
sen-mstr0102(takeover)> Tue Mar 24 22:11:52 JST [sen-mstr0102:cf.misc.operatorGiveback:info]: Failover monitor: giveback -f initiated by operator

sen-mstr0102> cf status
Controller Failover enabled, sen-mstr0101 is up.
VIA Interconnect is up (link up).

- 背面の電源ユニットのLEDが片系は緑ーーー、もう片系はー橙橙ーの状態になっている。問題ないか。

sen-mstr0102> options cf
cf.giveback.auto.after.panic.takeover on
cf.giveback.auto.cancel.on_network_failure off
cf.giveback.auto.cifs.terminate.minutes 5
cf.giveback.auto.delay.seconds 600
cf.giveback.auto.enable      off
cf.giveback.auto.override.vetoes off
cf.giveback.check.partner    on
cf.hw_assist.enable          on
cf.hw_assist.partner.address 10.159.215.100
cf.hw_assist.partner.port    4444
cf.mode                      ha
cf.remote_syncmirror.enable  off        (same value required in local+partner)
cf.sfoaggr_maxtime           120        (value might be overwritten in takeover)
cf.takeover.bypass_optimization off
cf.takeover.change_fsid      on
cf.takeover.detection.seconds 15
cf.takeover.on_disk_shelf_miscompare off
cf.takeover.on_failure       on
cf.takeover.on_network_interface_failure off
cf.takeover.on_network_interface_failure.policy all_nics   (same value in local+partner recommended)
cf.takeover.on_panic         on
cf.takeover.on_reboot        off
cf.takeover.on_short_uptime  on
cf.takeover.use_mcrc_file    off        (value might be overwritten in takeover)

* やったこと
options cf.giveback.auto.enable on

* やるべきこと
ifconfig e0c nfo

* 作業の続き
- A面で options cf.giveback.auto.enable on
- 両面でnfoをe0cに設定し、e0cのリンクダウンでTOされるか実験
- NetAppサイトへのログインアカウントを確認する
-- マニュアルやソフトウェアをDLできそう。

▲

System Managerの起動（マニュアルより） †

開始する前に
- Windows Server オペレーティングシステムと Internet Explorer を使用している場合は、Internet Explorer で、信頼済みサイトに http://127.0.0.1 を追加します。
- プロキシサーバを使用している場合は無効にします。
- Linux システムを使用している場合は、Oracle Java Runtime Environment 7 （JRE 7）をインストールし、デフォルトの JRE に設定する必要があります。 java -d32 -version コマンドおよび java -d64 -version コマンドを使用して、正しいバージョンの JRE および関連付けられているプラットフォームを使用していることを確認することができます。
- VMware Fusion を使用して、Windows または Linux ゲスト OS を Mac OS 上で実行している場合は、以下を確認します。
- 共有フォルダ機能を無効にします。
- ミラーフォルダ機能のデスクトップオプションを無効にします。
- Windows 7 および Windows Server 2008 を実行しているマシンで VPN 接続を利用して System Manager にアクセスする場合は、Microsoft Web サイト（support.microsoft.com/kb/2750841）で提供されている修正プログラムをインストールしておく必要があります。

▲

syslog-ng †

▲

syslog-ngで毎回DNSクエリを出さないようにする方法 †

▲

設定方法 †

/etc/syslog-ng/syslog-ng.confに以下の行を追加。

options {
    ～
    use_dns(yes);        #既に入ってる
    dns_cache(yes);      #これを追加
    dns_cache_expire(86400);   #DNSレコードの更新ペースを考えるとこのくらいで
    ～
};

syslog-ngに反映させる。
```
/etc/init.d/syslog-ng reload
```

▲

確認方法 †

まず旧設定のままで、DNSクエリが飛ぶ事を確認する。
1. kra-mlog01でキャプチャを仕掛ける。
```
tcpdump -i eth1 -A -n port domain
```
2. syslog送信(例:kra-mrems01)からログを送信する。
  1. /etc/syslog.confに以下の設定を追加する（試験用）
```
local7.debug   @10.159.213.12    #ログサーバ(kra-mlog01)のIP
```
  2. syslogデーモンに反映させる。
```
/etc/init.d/syslog reload
```
  3. syslogを送信する。
```
logger -p local7.debug "hoge $(date)"
```
3. キャプチャに

▲

sshログイン時に時間が掛かる問題 †

事象

sshログイン時に10秒くらい待たされる。以下の様な警告が出る。

reverse mapping checking getaddrinfo for kra-mlog01 [10.159.213.12] failed - POSSIBLE BREAK-IN ATTEMPT!

対処方法
- /etc/ssh/sshd_config に "UseDNS no"を設定して、/etc/init.d/sshd restartで再起動。
対処方法（別観点）
- sshのGSSAPI認証とやらが効いている模様。クライアント側の/etc/ssh/ssh_config（sshd_configじゃないよ）を修正する。
- /etc/ssh/ssh_confg のGSSAPIAuthenticaton yes を no に変える。

▲

サポート連絡先 †

よく聞かれる情報

連絡先
- 岡崎広和
- hirokazu.okazaki@east.ntt.co.jp
- 03-5825-4956（DC内A0）
バージョン情報
- NetApp? Release 8.2.2P1 7-Mode: Wed Oct 8 00:00:44 PDT 2014
  - 上記はシリアル接続して version コマンドで確認できる。

▲

東芝ITサービス株式会社 †

0120-302-733
mv@support-itsc.jp
蔵前
- 契約番号: NTAP-T4601515519
- 対象製品: 12057673
- シリアル番号
  - 451451000198,451451000199
卸町
- ご契約番号: NTAP-T4601515529
- 対象製品: 12057710
- シリアル番号
  - 451450000238,451450000239
有明
- ご契約番号: NTAP-T4601515520
- 対象製品: 12057603
- シリアル番号
  - 451450000236,451450000237

▲

情報収集が必要な項目 †

sysconfig -a
rdfile /etc/rc
ifconfig -a
cf monitor

▲

netappホームページ †

http://mysupport.netapp.com

アカウント: ntt_esight
パスワード: kuraesig1#

( 訪問者数: 134, 本日: 1, 昨日: 0 )

:検証/ログサーバ のバックアップ(No.15)