web-dev-qa-db-ja.com

50TBボリュームでのzpoolインポートは永遠にかかります：それは何をしているのですか？

2台のOpenSolaris2009.06NFSサーバーによって管理されるファイバーチャネルがあります。

  • サーバー1は、3つの小さなボリューム（300GB 15K RPMドライブ）を管理しています。それは魅力のように働いています。
  • サーバー2は、1つの大容量の32ドライブ（2TB 7200 RPMドライブ）RAID6を管理しています。合計サイズは50TBです。
  • 両方のサーバーには、Zpoolバージョン14とZFSバージョン3があります。

低速の50TBサーバーは数か月前にインストールされ、正常に動作していました。ユーザーは2TBを埋めました。私は小さな実験を行いました（1000個のファイルシステムを作成し、それぞれに24個のスナップショットを作成しました）。スナップショットを使用してファイルシステムを作成、アクセスし、NFSがそれらのいくつかをマウントする場合のすべて。

1000個のファイルシステムを破棄しようとすると、最初のfsに数分かかり、その後fsが使用中であることを報告できませんでした。システムシャットダウンを発行しましたが、10分以上かかりました。私はそれ以上待たずに電源を切りました。

これで、起動時にOpenSolarisがハングします。 32台のドライブのライトがすばやく点滅しています。私はそれを24時間放置しました-まだ点滅していますが、進行はありません。

Zpoolが作成される前にシステムスナップショットを起動し、zpoolのインポートを試みました。

pfexec zpool import bigdata

同じ状況：LEDが点滅し、インポートが永久にハングします。

「zpoolimport」プロセスをトレースすると、ioctlシステムコールのみが表示されます。

dtrace -n syscall:::entry'/pid == 31337/{ @syscalls[probefunc] = count(); }'

ioctl                          2499

これを修正する方法はありますか？ 編集：はい。 OpenSolarisをsvn_134bにアップグレードすると、うまくいきました。

pkg publisher # shows opensolaris.org
beadm create opensolaris-updated-on-2010-12-17
beadm mount opensolaris-updated-on-2010-12-17 /mnt
pkg -R /mnt image-update
beadm unmount opensolaris-updated-on-2010-12-17
beadm activate opensolaris-updated-on-2010-12-17
init 6

現在、zfsバージョン3があります。Bigdatazpoolはバージョン14のままです。そして、本番環境に戻りました。

しかし、24時間以上（ソフトウェアがアップグレードされる前）の大量のI/Oアクセスで何をしていましたか？

zfsopensolaris
6
Aleksandr Levchuk

ZFSを使用すると、同時実行性が向上するため、ディスクを直接操作できるようにする必要があります。あなたがそれを与えた単一の50TBディスクはチョークポイントです。

そのDTraceスクリプトは、システムコールのみを追跡しています。実際のアクションはカーネル内で発生します。CPUの大部分を消費しているものを確認したい場合は、DTraceToolkitの「hotkernel」スクリプトを使用してください。

プールをインポートすると、ZFSはディスクから構成を読み取り、検証します。プールがインポートされると、作成した1000のファイルシステムとスナップショットがすべてマウントされます。これにはしばらく時間がかかる場合があります。重複排除を有効にしていた場合（snv_111を使用していたため有効にしていない場合）、重複排除テーブル（DDT）をロードする必要があるため、さらに時間がかかります。

特にOpenSolarissnv_111では、システムをシャットダウンすることは決して良い選択肢ではありません。プール構成（zpoolステータス）を投稿していませんが、slogデバイスがあり、それらが失敗した場合、プールをインポートできません（これは、最近Solaris 11 Express snv_151aで対処されています）。

私のアドバイスは、32個のディスクをそれぞれ個別にエクスポートし、複数のraidz2 vdevを作成して、読み取り/書き込みヘッドを増やすことです。パフォーマンスがひどくなるので、8ディスクを超える巨大なvdevを作成しないでください。

システムを長時間ダウンさせる余裕がない場合（ほとんどの人はそうしません）、ZFSスナップショットを注意深く調べ、zfs送信/受信を使用してそれらをリモートサーバーに複製する方法を調べてください。これにより、フェイルオーバーサーバーをすばやく起動できます。

5
Giovanni Tirloni

「zfsimport」は、多かれ少なかれ、vdevの構成を（「zpool.cache」から）直接読み取るだけです。ここで完了するのに永遠にかかっていたのは、削除トランザクションだったと思います。

ZFSがトランザクションであり、1000個のファイルシステムを削除したことを考えると、それぞれに24個のスナップショットがあり、24,000個のスナップショットへの参照ポインターをチェックする必要がある非常に集中的な削除がありました。これらのSATAヘッドのシーク時間と、実行する必要のあるすべてのツリー更新を考慮します。

2
jharley