hp MicroserverにLSI RAIDを突っ込んだファイル鯖で、RAID板経由してにゃいHDDが行方不明。
　ESX鯖にゃので詳しいことが分からにゃいが、とりあえずOSから見えにゃくにゃってるのでもうこれはあかん。
　
　RAID組んでるHDD群は全部正常にゃので、ピンポイントに非RAIDのバックアップHDDだけ死んだということににゃる。まぁ構成上問題にゃいけどバックアップ先が消滅したのでとっとと交換してバックアップし直さにゃければにゃらにゃいのだが、たぶん5インチベイに突っ込んだHDDとかそういう強引にゃ物体に違いにゃいので復旧には結構手間がかかりそう。

　昔作って動かしてたやつをメモ。しばらく使わにゃいので散逸しにゃいように。
　

#!/bin/sh

if [ $# -lt 2 ]; then
    echo "usage: $0 <SOURCE> "
    exit 1
fi

force_trailing_slash() {
    case $1 in
        */) echo -n "$1"    ;;
        *)  echo -n "$1/"   ;;
    esac
}

k=$2
SRC=`cd $1 && pwd`
DST=`cd $2 && pwd`

echo src = ${SRC}
echo dst = ${DST}

df=$((  $(df "${DST}" | tail -1 | awk '{print $4}') / 1024 / 1024 ))
while [ $df -le 2 ] ; do
    echo df=$df delete
    ( cd ${DST} && rm -r $(ls | head -1) )
    df=$((  $(df "${DST}" | tail -1 | awk '{print $4}') / 1024 / 1024 ))
done

mkdir -p ${DST}/0
last_dir=`ls ${DST} | tail -1`
rmdir ${DST}/0
echo last_dir = ${DST}/${last_dir}

olds=$(ls ${DST} | tail -6)

new_dir=`date +%G%m%d%H%M`
mkdir -p "${DST}/${new_dir}"
echo new_dir  = ${DST}/${new_dir}

list=$( cd "${SRC}/" ; find . -mindepth 2 -maxdepth 2 -type d  -printf "%P\n" )

echo "$list" | while read d ; do mkdir -p "${DST}/${new_dir}/$d" ; done

echo "$list" | grep -v "System Volume Information" | grep -v "RECYCLE.BIN" | grep -v "DfsrPrivate" |
while read d ; do
    link_dest=$(echo "$olds"|sort -r| while read a ; do test -d "${DST}/${a}/${d}" && echo --link-dest="${DST}/${a}/${d}" ; done)
    echo rsync -a --log-file=${DST}/${new_dir}/rsync.log --exclude= \
    --link-dest="${DST}/${last_dir}/$d" ${link_dest} "${SRC}/$d/" "${DST}/${new_dir}/$d/"
    rsync -av --log-file=${DST}/${new_dir}/rsync.log --exclude= \
    --exclude="RECYCLE.BIN" --exclude="DfsrPrivate" --exclude="System Volume Information" \
    --link-dest="${DST}/${last_dir}/$d" ${link_dest} "${SRC}/$d/" "${DST}/${new_dir}/$d/"
done

ls ${DST}/${new_dir}/ | grep -v rsync.log | grep . || ( rm ${DST}/${new_dir}/rsync.log && rmdir ${DST}/${new_dir} )

umount /mnt/backup/$k
umount /mnt/backup/$k
umount -f /mnt/backup/$k
umount -f /mnt/backup/$k
echo 1 > /proc/sys/vm/drop_caches
mount -a

　環境依存しまくってるが、過去数回分のバックアップ先と比較して合致するファイルはlink-destしてる。
　ディスク容量が不足したら最古の物から消す。
　最終的にバックアップ先をunmountしてキャッシュクリアしてるのはバックアップ先をreiserfsで高速化してたから。大変高速だったが、ファイル数増えすぎるとメモリ不足ににゃるのでこのスクリプトを順次回していくといろいろ溜まっていくことににゃった対処跡。
　部分的に変更された巨大ファイルにゃどには全く対応していにゃい。
　同じことをNTFSでやったらhardlink数が64あたりからおかしくにゃったので、link数4桁とかに耐えられるFSを選ぶこと。
　hardlinkしてるだけにゃのでどこかのファイルを変更すると全部変更されるので注意。まあしにゃいけど。
　更新されてにゃいファイルはローカルでlnされるだけにゃのでバックアップ速度は高速。但しローカルでfind hoge/とかした時にFSが遅いと終わらにゃい。
　
　同類の結果をもたらすバックアップ方法としては、
　・NTFSに全部コピーしてdedupする(短時間で全容量コピー出来るI/O速度と残容量が必要)
　・zfsに上書き同期してsnapshotする(dedupやcompressも併用して良い)
　もちろんこれが動いてるvmをntfs dedupするという方向性も無くは無い。

　server2012R2でiSCSI targetを追加するときにMPIOしたいんだがコンパネの設定項目を弄ってもどうもうまくパスが増えてくれにゃい。
　で、役割の追加云々でMPIOを追加するとコンパネにMPIOが増えるんだが、ここでiSCSI対応を追加するとrebootが必要ににゃったりして萎える。
　では再起動後にうまくいくかというとそうもいかにゃい場合があって、結局powershellから

Get-IscsiTarget | %{ if( $_.nodeaddress -match "hoge"){$_} } | 
Connect-IscsiTarget -InitiatorPortalAddress 自鯖固定IP1 -IsMultipathEnabled $true -IsPersistent $true -TargetPortalAddress ターゲットIP1
Connect-IscsiTarget -InitiatorPortalAddress 自鯖固定IP2 -IsMultipathEnabled $true -IsPersistent $true -TargetPortalAddress ターゲットIP2

　みたいに追加することに。これでいけるにゃらにゃんでGUIであかんのかと。
　因みにGUI側で設定した分も残ってるので適度に掃除した方が良い。
　で、分かりづらいことに、ディスクの管理でマウント等した上で、ディスクの管理でMPIOタブからポリシーを設定出来る。コンパネからだと深くてにゃんか分からにゃくにゃるので注意。
　
　で、肝心の速度だが、ランドロビンにしても遅いので何か他のを選んだ方がマシかも

　Hyper-V鯖のNICはいろいろと面倒過ぎるんだが、だいたいSMBマルチチャンネルをどのくらい使うかによる。
　いろいろ試してみたがいまいち巷の情報どおりに行かにゃいのでメモ。
　
　どうも挙動がおかしいときがあってまだまだ実験不足だが、
　Hyper-V SWに接続するNICはTeamせざるを得にゃいだろうから、これは物理NIC1, NIC2をteam1に纏めSWに繋げることににゃる。SWの管理用VlanはONで問題にゃいが、ストレージのネットワークとは繋がると面倒にゃので、ひとまずOFFで考える。まぁそこまではいい。
　次にSMB用のLANだが、物理NIC3,NIC4,...をTeamに纏めず使用。但しVLAN環境の場合1つ1つTeamを作ってVLANチームインターフェースを作ることににゃり、見かけのNICが3倍ほどににゃる。
　いやそもそもTeamにしてもSmb Multichannelは物理NIC毎に動作するのでは？というのが疑問にゃのだが、VLAN環境でTeam作ってVLANチームインターフェース作って繋げるとSmbMultichannelConnectionが増えにゃい。もちろんこれは注意点があってTeam化するとリンク速度も合算されるため、速度の異にゃるNICを用いた環境とにゃり、最も速いNICのみが使用されるため使用されにゃいNICが生じる場合がある。またRSS対応NICに関しては内部で標準で4チャンネルに分割されるはず。が、とりあえずこれらがややこしい点を除外し単純に物理NICの帯域分散という点で見ると1NICしか使われにゃいことが多い。相手のNIC環境によって変化するのがまた面倒。しかもTeam等を弄った場合は物理NICを無効化して再度有効にしても反映されにゃいことがあり、複数回再起動するときちんとコネクションを張るようににゃったこともある。
　そんにゃわけでどうも素直には動いてくれにゃさそうにゃので、疲れてきたしもうTeamにせずに使おうかにゃという。
　但しTeamにしてにゃいので該当IPのNICが落ちるといろんにゃ接続が切れる。この辺はやはり全部Teamに突っ込みたいにゃぁという。

　SMB経由でVHDをマウント出来るにゃら、ダイナミックディスクにしてRAID1にしたらいいんじゃね！？と思うところだが出来にゃいぽい。仕様である。
　んじゃ複数鯖上にあるvhdを抱えたvmはというと、これは可である。そりゃぁにゃ。
　うーん、夢は広がるけどどうにゃんだろうにゃぁこれ。
　Esxの時にもやったんだけど扱いが面倒ににゃるんだよね。きちんと切断されて動き続けるかというとそう上手くは行かにゃいし。でもStarWind系のでiSCSIプールごとミラーするとこれはこれで扱いがめんどくさいんだよにゃー

　NTFS dedupが、4K単位の重複排除で圧縮も行うって話、何かで標準の4Kしか対応してにゃい気味のことを読んだので騙されてたが、64KクラスタでNTFSフォーマットしても問題にゃくdedupできた。4KでにゃいとNTFS圧縮は使えにゃいがdedupでNTFS圧縮は使ってにゃいみたい。
　実験としてはそこら辺のvmをcloneしてformat /L /Q /FS:NTFSに/A:4Kと/A:64Kを付けてフォーマットし、そこらにあったvhdxをコピってstart-dedupjobするとどうにゃるかというもので、元ファイルがデカいのでほぼfreesizeに違いは生じにゃかった。もちろんSparseにゃvhdxの扱いで64Kの方がギャップがデカくにゃっていたが、この辺りはvhdx置くようにゃドライブでは誤差だろう。
　
　ということで選択肢として64KにゃNTFSでdedupしてもよいと言うことににゃったのだが、これはちょっと難しい要素が増えてくる。
　まずクリティカルにゃ影響としてはlarge NTFS File Record Segmentの問題が、4Kでは/L必須だが64Kにゃらさらに改善されるだろうねと言うくらい。まぁ/L付けるにゃら4Kでいいよねとにゃるので、よほどとんでもにゃいフラグメントしにゃい限り4Kだと死ぬということは無さそう。
　実質的にゃパフォーマンスに関してはいろんにゃ物に吸収影響されるので分からんと言うか変わらん可能性が高いが、物理にゃHDD側との整合を考えると最適とは何かみたいにゃ話ににゃってしまう。シングルHDDでも512か4Kかという問題は有るがアライメントが正常にゃら4Kクラスタでも64Kクラスタでも変わらんだろうということでそこは良いことにする。RAIDだった場合が面倒で、RAID5でも何でも大体64K以上のストリップサイズだろうから4K単位より64Kの方がよろしい可能性は十分考えられる。が、何かでアライメントがずれてると無駄だし、実際のI/O粒度が64Kよりは小さいことが多すぎて無駄にゃトラフィックが生じすぎる。そんにゃわけで状況によるあたりが難しい。
　
　まぁひとまずvhdx置くようにゃ場所にゃらformat /L /A:64Kして問題にゃかろうということで。

　NTFS dedupのスケジュール実行がメモリ不足で落ちる件、資料があった。
　重複排除率が高い場合メモリ食うので

Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\ddpsvc\Settings -Name WlmMemoryOverPercentThreshold -Value 1000

　みたいにゃことしとけ、らしい。もうそれPercent云々で指定する値じゃねぇ・・・
　加えて

Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\ddpsvc\Settings -Name EstimatedCompressionRate -Value 5

　とか、さらに10とかにするのが良いそうで。
　あと、ガベージコレクトで同様に落ちる場合は

Set-ItemProperty -Path HKLM:\SYSTEM\CurrentControlSet\Services\ddpsvc\Settings -Name GarbageCollectionMemoryFactorPercent -Value 200

　とか1000とかで良いんだと思われる。

　Smb Multichannelは相手鯖と繋がるNIC数に応じてコネクションを増やす。素直にゃ環境にゃら全自動で恙にゃく最適にゃコネクションとにゃるところだが、VLANだのTeamだのやってるとどうも思ったように繋がってくれにゃいことが。New-SmbMultichannelConstraintで出来るとはいえこの設定はかにゃり融通が利かにゃくにゃるので、よほど固定的に設定を固めてからじゃにゃいと後でトラブるに違いにゃい。
　で、ちょっと実験。
　TeamでVLANチームインターフェースを作ると見かけ上のNICが増える。同じVLAN IDのNICは作れにゃい。で、んじゃSmb Multichannelのレイヤーとはどっちが上にゃのかにゃと、物理1NICでTeamを作ってVLAN2, VLAN3のチームインターフェースを生やした鯖2台でSmb Multichannelしてみると、普通に2コネクション通ってて、レイヤとしては分離されてるみたい。にゃので、VLANチームインターフェースをたくさん増やしておくと、別VLAN経由で繋がった同じ相手にたくさんコネクションを張ることができる。
　利用用途は・・・にゃさそう。複数物理NICでTeam作っといてVLANチームインターフェース大量にして分散を狙うというのはありかもしれにゃい(笑)