X

Oracle Solaris, Oarcle ハードウェア製品に関する情報

  • Sun
    October 29, 2008

ssh を使わない zfs send/recv

Guest Author


ZFS send/recv は、単純なデータのバックアップ機能の他、リモート・レプリケーション機能も併せ持っていますが、今回は、そんな ZFS send/recv を使ったリモートホストとの連携についてちょっとした tips をご紹介したいと思います。



ZFS send/recv を使い、リモートホストにデータ(ZFS data stream) を受け渡す際、よく目にするのが、ssh を使ったものです。
# zfs send testpool/userpool@snap | ssh user@remote zfs recv testpool

また、やっぱり blog の過去記事にも解説があります。
やっぱり Sun がスキ!: ZFS のレプリカを作成する

http://blogs.sun.com/yappri/entry/zfs_replica

送り出す ZFS data stream を ssh に渡し、リモートホストにて zfs recv を起動することで、容易なオペレーションによりリモートホストにデータを複製することが可能です。



また、ssh による転送は、安全性を確保しつつ ZFS data stream を転送することが可能となりますが、同時に暗号化処理のオーバーヘッドが少なからず発生してしまいます。



ローカル接続な環境では、暗号化処理を行わないことで、僅かでも転送処理にかかる時間を減らしたいという要求もあるかと思います。

そこで、ZFS data stream を ssh を使わずにリモートホストに転送する方法をご紹介致します。

zfs コマンド自体は、ネットワークを利用して data stream を送受信する機能を持っていないため、この部分を補ってくれるのが ssh の役目でした。



ということは、ssh に替わる別な何かを用意する必要がありますね。



そこで、今回は、mbuffer と呼ばれるものを使ってみることにします。

mbuffer は、渡される data stream をバッファリングし高速なテープドライブやテープライブラリに対するデータ書き込みのスループットをあげる目的で作成されたプログラムですが、マルチスレッド対応による書き込みの高速化やメモリマップドファイル I/O を利用した巨大なバッファのサポート、ネットワークによる data stream 転送機能などを提供します。



mbuffer は、Solaris 標準のコマンドではなく、GPLv3 にて配布される OSS となりますが、Solaris 10 で簡単に build することができます。

ソースコードの入手は、下記 URL から。Solaris (primary target) と書かれている部分にも注目です。
~mbuffer/the home of the measuring buffer

http://www.maier-komor.de/mbuffer.html



コンパイルに必要な手順は、下記となります。


$ gzip -cd mbuffer-20081023.tgz | tar xvf -

$ cd mbuffer-20081023

$ env CC=/usr/sfw/bin/gcc ./configure --prefix=/opt/sfw



mbuffer は、単体のコマンドのみで構成されているので、できあがったものを PATH が通っている適当なディレクトリへコピーすることで利用可能となります。

本稿では、/opt/sfw/bin/mbuffer として配置します。

この作業を送信側と受信側に仕込んで完了です。



それでは適当な zfs snapshot をリモートホストへ送信してみます。

zfs send を実行するホストを send_host というホスト名とし、zfs recv を実行するホストを recv_host というホスト名とします。


<受信側の設定>

まずは、 zfs recv を実行するホストにて、data stream の待ち受けます。

send_host からやってくる data stream を port 10000 にて待ち受ける指示を -I オプションで指定し、mbuffer コマンドを起動、そして mbuffer コマンドが受信した data stream を zfs recv に渡し、rpool/testpool@snap に復元します。



    recv_host# /opt/sfw/bin/mbuffer -I 10000 | zfs recv -v rpool/testpool@snap


以上で、受信側の作業は完了です。



次に送信側の作業です。
<送信側の設定>

recv_host に複製したい領域の snapshot を取得し、zfs send で出力された data stream を mbuffer コマンドに渡し recv_host の port 10000 めがけて投げつけます。

届け!この思い!



    send_host# zfs send rpool/testpool@snap  | /opt/sfw/bin/mbuffer -O recv_host:10000


<送信側からssh 経由で実行する場合>



recv_host にログインすることなく上記のコマンドを実行する場合は、下記のようにしてみるのもよいでしょう。

(あらかじめ、recv_host へ root で login できる設定が必要となります。)



    send_host# ssh -e none root@192.168.0.209 '/opt/sfw/bin/mbuffer -I 10000 | zfs recv rpool/testpool@snap'




これで、data stream の転送を開始します。



試しに 7.54GB の zfs data stream をリモートに複製してみました。

使用したネットワークは 100M で、互いのマシンの条件もいろいろと揃っていない中で計測したものとなりますので、参考程度に捉えて頂ければと思います。


<ssh を使ってみた例>

# ptime  zfs send rpool/testpool | ssh root@192.168.0.209 zfs recv -v rpool/testpool


real    31:06.561

user        0.011

sys        53.245


<mbuffer を使ってみた例>

<send>

#  ptime zfs send rpool/testpool@snap | /opt/sfw/bin/mbuffer -O 192.168.0.209:10000

in @  0.0 kB/s, out @ 9224 kB/s, 7719 MB total, buffer   0% full

summary: 7719 MByte in 19 min 50.1 sec - average of 6642 kB/s


<recv>

# /opt/sfw/bin/mbuffer -I 10000 | zfs recv -v rpool/testpool@snap
receiving full stream of rpool/testpool@snap into rpool/testpool@snap

in @ 7329 kB/s, out @ 7329 kB/s, 7719 MB total, buffer   0% full

summary: 7719 MByte in 19 min 50.1 sec - average of 6642 kB/s



ちなみに、zfs recv の -v オプションを利用すると、全ての data stream 受信完了後、受信にかかった時間や受信データ量、1 秒間の平均転送速度を出してくれます。
received 7.54GB stream in 1193 seconds (6.47MB/sec)

ssh によるトンネリング処理が入らない分、mbuffer 同士の通信が少し速いですね。

セキュアな通信が必要ないローカルな環境であれば、このような方法でも zfs send/recv が可能です。

また、大容量メモリと高速ネットワークと巨大なデータを用意して mbuffer のチューニングなんていうのも色々と楽しそうですね。

Join the discussion

Comments ( 2 )
  • guest Thursday, October 30, 2008

    「やっぱり Sun がスキ!: ZFS のレプリカを作成する」のリンクをクリックしたところ、アクセス拒否されてしまいました。。


  • Naoyuki Yamada Friday, October 31, 2008

    ZFS のレプリカを作成する」のリンク切れのご指摘ありがとうございました。早速正常にアクセスできるよう変更させて頂きました。


Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha