2014年6月18日水曜日

tips:nfsの調査!

NFS server(Windows2008R2)  +  NFS Client(CentOS6.4)にてデバッグをおこなったので、その時の備忘録。

 調査1.NFS Client側で統計情報取得

 # nfsstat -c

 Client rpc stats:
 calls      retrans    authrefrsh
 259        0          265

 Client nfs v3:
 null         getattr      setattr      lookup       access       readlink
 0         0% 118      46% 5         1% 5         1% 101      39% 0         0%
 read         write        create       mkdir        symlink      mknod
 0         0% 0         0% 4         1% 2         0% 0         0% 0         0%
 remove       rmdir        rename       link         readdir      readdirplus
 0         0% 0         0% 0         0% 0         0% 0         0% 4         1%
 fsstat       fsinfo       pathconf     commit
 0         0% 10        3% 5         1% 0         0%

 アクセス種別に応じた回数や比率が出力される。

 調査2.NFS Client側でtcpdump

 # tcpdump host [nfs server ip]

調査3.NFS Clientのデバッグ

 # rpcdebug -m nfs -s vfs
 # tail -f /var/log/messages

 (NFS Client)# touch test
 Jun 17 16:07:34 localhost kernel: NFS: permission(0:14/981489865), mask=0x1, res=0
 Jun 17 16:07:34 localhost kernel: NFS: nfs_update_inode(0:14/981489865 ct=2 info=0x7e7f)
 Jun 17 16:07:34 localhost kernel: NFS: permission(0:14/981489865), mask=0x1, res=0
 Jun 17 16:07:34 localhost kernel: NFS: permission(0:14/981489865), mask=0x3, res=0
 Jun 17 16:07:34 localhost kernel: NFS: create(0:14/981489865), test ※touch test(create)
 Jun 17 16:07:34 localhost kernel: NFS: nfs_update_inode(0:14/981489865 ct=2 info=0x1feff)
 Jun 17 16:07:34 localhost kernel: NFS: nfs_fhget(0:14/1409289744 ct=1)
 Jun 17 16:07:34 localhost kernel: NFS: permission(0:14/1409289744), mask=0x0, res=0
 Jun 17 16:07:34 localhost kernel: NFS: nfs_update_inode(0:14/1409289744 ct=1 info=0x1feff)
 Jun 17 16:07:34 localhost kernel: NFS: nfs_update_inode(0:14/1409289744 ct=1 info=0x7e7f)
 Jun 17 16:07:34 localhost kernel: NFS: dentry_delete(/test, 8)

 (NFS Client)# touch test

 Jun 17 16:08:38 localhost kernel: NFS: nfs_update_inode(0:14/981489865 ct=2 info=0x7e7f)
 Jun 17 16:08:38 localhost kernel: NFS: permission(0:14/981489865), mask=0x1, res=0
 Jun 17 16:08:38 localhost kernel: NFS: nfs_update_inode(0:14/981489865 ct=2 info=0x7e7f)
 Jun 17 16:08:38 localhost kernel: NFS: permission(0:14/981489865), mask=0x1, res=0
 Jun 17 16:08:38 localhost kernel: NFS: nfs_update_inode(0:14/981489865 ct=2 info=0x7e7f) 
 Jun 17 16:08:38 localhost kernel: NFS: nfs_update_inode(0:14/1409289744 ct=1 info=0x7e7f) ※touch test(modify)
 Jun 17 16:08:38 localhost kernel: NFS: nfs_update_inode(0:14/1409289744 ct=1 info=0x7e7f)
 Jun 17 16:08:38 localhost kernel: NFS: permission(0:14/1409289744), mask=0x22, res=0
 Jun 17 16:08:38 localhost kernel: NFS: nfs_update_inode(0:14/1409289744 ct=1 info=0x1feff)
 Jun 17 16:08:38 localhost kernel: NFS: nfs_update_inode(0:14/1409289744 ct=1 info=0x7e7f)
 Jun 17 16:08:38 localhost kernel: NFS: dentry_delete(/test, 8)

 (NFS Client)# rm test

 Jun 17 16:11:10 localhost kernel: NFS: nfs_update_inode(0:14/981489865 ct=2 info=0x7e7f)
 Jun 17 16:11:10 localhost kernel: NFS: permission(0:14/981489865), mask=0x1, res=0
 Jun 17 16:11:10 localhost kernel: NFS: nfs_update_inode(0:14/981489865 ct=2 info=0x7e7f)
 Jun 17 16:11:10 localhost kernel: NFS: permission(0:14/981489865), mask=0x1, res=0
 Jun 17 16:11:10 localhost kernel: NFS: nfs_update_inode(0:14/981489865 ct=2 info=0x7e7f)
 Jun 17 16:11:10 localhost kernel: NFS: permission(0:14/981489865), mask=0x3, res=0
 Jun 17 16:11:10 localhost kernel: NFS: unlink(0:14/981489865, test)
 Jun 17 16:11:10 localhost kernel: NFS: safe_remove(/test) ※rm test
 Jun 17 16:11:10 localhost kernel: NFS: nfs_update_inode(0:14/981489865 ct=2 info=0x1feff)
 Jun 17 16:11:10 localhost kernel: NFS: dentry_delete(/test, 18)

 上記のようにログが残る。ちなみに

 Jun 17 16:08:38 localhost kernel: NFS: nfs_update_inode(0:14/1409289744 ct=1 info=0x7e7f) 

ここに記載されている1409289744 は、inode番号なので、

 # find -inum 1409289744 

  ./test

 と対象のファイル名を調べることができる。

 調査4.NFS Serverのネットワークパケット取得(NetworkMonitor)


Tips:Windowsのネットワークあたりのトピックス

Windowsネットワーク周りの備忘録

・ネットワークパケットを取得する

 Microsoft標準だと、NetworkMonitor3.4などがある。GUIでもCUI (nmcap.exe)でも取得可能。
 コマンドラインは以下のような感じ。

 >nmcap /network * /capture /StartWhen /Time 00:00 6/1/2014 /StopWhen /Time 18:00 6/1/2014 /file .\test1.cap:100M /CaptureProcesses

 
 詳しくはnmcap /helpや/examleで見れる。開始(/StartWhen)・終了(/StopWhen)の時間が指定できたり、
 取得しているOS上のプロセスとの紐づけ(/CaptureProcesses)ができるので、ちょっと便利そう。

 wiresharkを使って取得することもできる。GUIでもCUI でも。コマンドラインは以下のような感じ。


 >tshark -b filesize:5000 -b files:1000 -w C:\temp\test


 今のところパケット取得自体であれば、MS純正との差異は思いつかない。プロセスとの紐付けなどができる点

 では、NetworkMonitorなのかな?

・WindowsのTCPポートの上限数の変更

 Windows2003までは、ポートはデフォルトだと、1025~5000となっている。Windows2008以降では49152~65535が
 既定の動的割り当てポートの範囲となっている。

 >netsh int <ipv4|ipv6> show dynamicport <tcp|udp>


 これで現在のポート範囲を表示することができる。変更もコマンドラインできる。

 >netsh int <ipv4|ipv6> set dynamic <tcp|udp> start=数値 num=範囲

・Windows2008 R2の複数IP割当時のPrimaryIP(OutBoundの時のデフォルトのソースIP)

 Windows2008(R2なし)までは、複数IPがあった場合でも、割り当て欄の一番上のIPがPrimaryIPとなった。


 Windows2008 R2では1枚のNICに複数IPをアサインした場合、IPの中で一番小さいIPアドレスがPrimaryIPとなる。

 そのためFirewallのなど通信時にソースIP制限をかけている環境では、あとつけでIPを追加する場合、IP次第では
 ソースIPが変わってしまうため注意が必要(仕様らしいが、メリットがあるのかな?改悪な気がする。)

・TCP Ack Frequency

  
 TCP遅延ACKの頻度を指定する。

 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{Interface GUID}*

  値の名前:TcpAckFrequency
  値:(DWORD) デフォルト2。変更する際は1。
  ※デフォルトでは、セグメントを2個受信したらACKを返す。1にするとセグメント毎にACKを返す(つまり
    TCP遅延ACKを無効化)。

・TimeWaitの時間変更
 セッションをたくさん張るようなサーバーの場合、TCPセッションがたくさん残ってしまい、ポートを消費してしまう
 ことがあるので、その時のチューニングの1つとして、TimeWaitを短くする。レジストリを変更する。

  HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters

  値の名前:TcpTimedWaitDelay
  値:DWORDで秒単位で記載(Windows2008のデフォルトは120秒)。
 
  参考)http://technet.microsoft.com/en-us/library/cc938217.aspx

 本来Time Waitは、通信相手に正常に終了のパケットが届いたと思われる十分な時間が経過するまでの間、同じ
 プロトコル、発信元 IP アドレス、ポート、宛先 IP アドレス、ポートが接続に使用されないようにするための時間。
 あるいは再利用のための待ち時間。
 RFC 793 では、ソケット ペアの再使用禁止時間の長さを 2 MSL (セグメントの最大有効期間の 2 倍) または 
 4 分と規定している。時間を短くする場合は、このあたりは認識しておかないと。


 ※ちなみにPort数(49152~65535)÷TcpTimedWaitDelayが1秒あたりの最大セッション数になりますね。

・IPv6の無効化

 ネットワークのアダプタでIPv6を無効化するだけ。

・SNP(Scalable Networking Pack)の無効化

 ネットワーク性能が出ないことがある時に、無効化してみる。設定の確認は

 >netsh int tcp show global




 赤枠のところがenabledに。これを無効化するには以下を実施


 >netsh int tcp set global chimney=disabled

 >netsh int tcp set global rss=disabled
 >netsh int tcp set global netdma=disabled

 再度確認してみる。

 >netsh int tcp show global
 


 ・共有フォルダのアクセスが遅い、できない場合はLanManagerの認証レベルを変更してみるといいらしい。設定は、


 「ローカルセキュリティポリシー」-「ローカルポリシー」-「セキュリティオプション」-「ネットワークセキュリティ:LAN Manager認証レベル」の値を、「NTLM応答のみ送信する」に変更。


・ネットワークスロットルを無効にする


HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Multimedia\SystemProfile\

NetworkThrottlingIndex
この値をFFFFFFFFにする

・オフロードの無効化


オフロードは、ネットワーク処理の一部をCPUではなく、NICなどに任せ(オフロード)、効率を上げる仕組み。ただしこれがうまく動作しないケースもあるみたいで、ネットワークが遅い時は、オフロード機能の無効化を試す。


NICアダプタ単位で設定を変えるには、NICアダプタの構成情報から変更する








上記のOffloadとなっている項目が対象。


またHyper-V環境上の仮想OSでも、かなり性能劣化を及ぼすことがあるみたいで、オフロードの無効化が有効になるかもしれない。



・共有フォルダのアクセスでキャッシュの無効化

共有フォルダのプロトコルSMB(ServerMessageBlock)の仕様で、キャッシュに関する仕様が問題になることがある(主にサーバー環境で)。



・自動チューニング

Windows7,windows2008からの機能で、ネットワークの自動チューニング機能がある。ネットワークの性能を改善したい場合、この設定を変更することも検討する。


>netsh interface tcp set global autotuninglevel=xxx


xxの取りうる値は以下の通り。

normal:デフォルト
disabled:自動チューニング無効
highlyrestricted:デフォルトより大きく(チョッと?)
restricted:デフォルトより拡大(一部で制限あり)
experimental:restrictedの制限対応

disabled: uses a fixed value for the tcp receive window. Limits it to 64KB (limited at 65535).

highlyrestricted: allows the receive window to grow beyond its default value, very conservatively
restricted: somewhat restricted growth of the tcp receive window beyond its default value
normal: default value, allows the receive window to grow to accommodate most conditions
experimental: allows the receive window to grow to accommodate extreme scenarios (not recommended as it can degrade performance in common scenarios; only intended for research purposes. It enables RWIN values of over 16 MB)

・受信ウィンドウサイズの変更


RWIN(Recieve WINdow)の変更 
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters」にある「TcpWindowSize」の値を修正することで、設定を変更できた。

・MTUの変更


>netsh interface ipv4 set interface "インターフェース名" mtu=xxxx store=persistent

MTUを変更して、有効にかどうかを確認するには


>ping [ホスト] -f -l [サイズ]


で返ってくるかどうか?で確認する。


2014年6月13日金曜日

Tips:FTPクライアントでのファイルの移動と、WindowsのIIS FTPの仮想ディレクトリ

Windows標準のFTPサーバの環境で、
 ・ディレクトリ間のデータの移動ができるのか?
 ・ドライブをまたがって移動ができるか?
ってのを調べて見る機会があたので、メモ。

結論からすると、ケースによるが、移動はできた。ポイントは以下の通り。

 ・移動というより、RNFRとRFTOコマンドで実装されているみたい。

 ・FTPクライアントでリモート側(つまりFTPサーバー)のディレクトリがツリーで表示される
  ようなものでないと、実際には使いづらい。下位のディレクトリにしか移動ができない。
  FFFTPはできなかった(最新版では試してないが)。WinSCPだとツリー表示ができた。  


 ・サーバー上で、FTPの仮想ディレクトリを使って、物理ドライブをまたがるような構成を組ん
  だ場合、ドライブをまたがる移動はできない。











  という構成を組んでいる時、FTPクライアントでDirAからDirBへのファイルの移動はできるが、
  DirAからDirCへの移動はできなかった(エラーになった)。

 ・ファイルの移動とは異なるトピックスになるが、

  上記のような仮想ディレクトリを組んでいる場合、FTPクライアントツールでは、DirA,DirB,DirC
  が表示されなかった。ただコマンドベースでアクセスする分にはアクセスができる
  (例:cd \DirBとか)。
  これはセキュリティ上の仕様だそうだ。でもこれだとつかいづらいので、、対策としては

  C:\wwwroot
     |
     ├--- DirA
     |
├--- DirB
├--- DirC
 
  という仮想ディレクトリ名と同名のディレクトリを作成すると、FTPクライアント上でも表示された。
  ディレクトリにアクセスをすると、実態のディレクトリではなく 仮想ディレクトリのほうにアクセス
  できるようになる。例えば上記のようなディレクトリを作成した場合、

  FTP > cd \DirA

  とすると、C:\wwwroot\DirAではなく、C:\tempに移動する。
  何とも不思議な仕様だ。だったら仮想ディレクトリのプロパティに、見せる・見せないという機能
  を持たせればよいのに、、

ちょっと変わった仕様なので書いてみた。


2014年6月7日土曜日

Tips:ネットワークあたりのトピックス


MSS(MaximumSegmentSize:最大セグメントサイズ)
MTU(MaximumTransmissionUnit)
MSSはTCP/IPにおいて1セグメントで送信できる最大サイズ。IPヘッダ(20バイト)、TCPヘッダ(20バイト)は含まない。
MTUは1回の転送(1フレーム)で転送できる最大サイズ。



PPPoEの場合は、ヘッダーが追加されるので、、


となる。ちなみにRWIN ( Receive Window Size ) は、ACKを待たずに送信できるサイズ。受信側のバッファサイズとなる

Nagleアルゴリズム
IPヘッダーやTCPヘッダーのオーバーヘッドを軽減することが目的。よくある例は、telnetのように1バイトずつ送信するような場合、実際にはこの1バイトにに対してIPヘッダー20バイト、TCPヘッダー20バイトが付き、計41バイト送付することになり、伝送効率が非常に悪くなる(「小さなパケット問題」)。

Nagleアルゴリズムでは、MSS以下の複数の送信メッセージを一つに束ね、まとめて送信する。特に、送信パケットで送信側が ACK を受け取っていないのがある場合、送信するに値するまで送信側はバッファリングを行い、そして、一度にまとめて送信することで、効率を上げる。送信をする条件としては

  • 未送信データが最大セグメントサイズ以上になる
  • 過去の送信パケットで ACK が未受信の物がなくなる(*)
  • タイムアウトになる

がある。これに関する各OSの設定は、以下の通り。

■Windows

 Nagleアルゴリズムを無効化するオプション
 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSMQ\Parameters
  値の名前:TcpNoDelay
  値:(DWORD)0が有効、1が無効
 
■Linux

 socketオプションでTCP_NODELAYを指定し、マシンA側でNagleアルゴリズムをオフにする。

TCP遅延ACK
小さなデータを受信した際に、毎回ACKを返すのは効率が悪いので、ちょっとだけ待ち(最大500ms)、その後のデータの応答とACKをまとめて返すことで効率を上げる仕組み。ただしMSS以上のデータを受信した際には、2回目の受信でACKを返さなければならない。

がある。これに関する各OSの設定は、以下の通り。

■Windows

 TCP遅延ACKの頻度を指定する
 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{Interface GUID}*
  値の名前:TcpAckFrequency
  値:(DWORD) デフォルト2。変更する際は1。
  ※デフォルトでは、セグメントを2個受信したらACKを返す。1にするとセグメント毎にACKを返す(つまり
    TCP遅延ACKを無効化)。

 ACKのタイムアウト値の設定
 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\{Interface GUID}*
  値の名前:TcpDelAckTicks
  値:(DWORD)2(200ms)がデフォルト。1-6(100-600ms)を指定できる。0,1は200msになるらしい。

■Linux

 socketオプションでTCP_QUICKACKを指定することで、遅延ACKを無効化できるみたい(でも永続的ではないよう
 なので、使用の際には注意が必要みたい)。

 もう1つ遅延ACKの送信のタイムアウトの設定は以下の設定でできるみたい。
 Redhat系:echo 1 > /proc/sys/net/ipv4/tcp_delack_min ※ミリ秒単位で指定


2014年6月4日水曜日

Tips:ウィルス検知ソフトの誤検知確認

ウィルス検知ソフトで、前からおいてるファイルが検知された。誤検知の可能性が高い。
本当に誤検知かどうか?どうやって調べるのが一般的なのか?を調査してみた。

ここが一番まとまっているみたい。

やっぱり

 1.ファイルの出所を確かめる(ダウンロード先が信頼できるか?)

 2.オンラインスキャンサービス(VIrusTotal)や、他のウィルス対策ソフトを使ってチェック(2つ
   だと心ともないが、そんなにいくつも製品が導入されているケースも少ないからしょうが
   ないか。。)
 
 3.最後は自分で判断

という感じかなと。