Movatterモバイル変換

blogs:
cles::blog
NP_cles()

»ArchiveList (Tag for "omnios"

)

«Prev ||1 ·2 ·|Next»

2023/03/25

OmniOS/ZFS サーバに wbadmin でイメージバックアップが取れない時に確認すべきこと

omnios

windows

以前、SMB 2.0 以降を使う Samba サーバの共有フォルダを対象にして Windows のイメージバックアップを取ろうとするとSparse File の関係でバックアップが取れたり取れなかったりするという問題がありました。

同じような問題がOmniOS(illumos) でも発生していたので困っていました。
OmniOS は Open Solaris の系譜なので、ファイル共有は Samba ではなくKernel 内蔵の smb です。
というわけで、Linux のSamba と同じテクニックは使えず、原因も Sparse File ではありません。

† まず、結論から

いつも通り、解決するための結論から書いて置きます。

以下のようなコマンドで zfs 共有のnbmand(Non Blocking mandatory locks)^*1^*2 プロパティをon にしてやります。

zfs set nbmand=on tank/share

どうもこのnbmand というプロパティがoff だとクライアントがファイルをうまくロックすることができず、これが原因になっていたようです。

nbmand のデフォルトはoff ですし、おそらくパフォーマンス等に対するペナルティもあると思われるので、今回はバックアップに使う共有でだけon にしています。Open Solaris の時からnbmand はcross-protocol locking （例えば NFS と SMB を同時に使う）が必要な時だけon にする必要がある^*3という認識だったのですが、どうやらちょっと僕の認識が間違っていたようです。これまでoff でもファイルサーバとしては特に問題になる挙動に当たったことがなかったのですが、このあたり近日中に詳しく調べてみたいと思います。

† 実際に発生するエラー

実際にバックアップを取ろうとすると発生するエラーは以下のような感じです。

Microsoft Windows [Version 10.0.22621.1413](c) Microsoft Corporation. All rights reserved.C:\Windows\System32>wbadmin start backup -backuptarget:\\192.168.0.1\path\to\dir -include:c: -allCritical -quietwbadmin 1.0 - バックアップコマンドラインツール(C) Copyright Microsoft Corporation. All rights reserved.注意: この保存先では、バックアップデータを安全に保護することはできません。リモート共有フォルダーに保存されたバックアップは、ネットワーク上の他のユーザーによってアクセスされる可能性があります。バックアップは、信頼できるユーザーがアクセスする場所か、セキュリティ対策が実施されているネットワークにのみ保存してください。ボリューム情報を取得しています...これにより (EFI システムパーティション),(C:),(\\?\Volume{00000000-0000-0000-0000-000000000000}\) が \\192.168.0.1\path\to\dir にバックアップされます。\\192.168.0.1\path\to\dir へのバックアップ操作を開始しています。バックアップに指定されたボリュームのシャドウコピーを作成しています...バックアップに指定されたボリュームのシャドウコピーを作成しています...ボリューム (EFI システムパーティション) (100.00 MB) のバックアップを完了できませんでした。エラー: プロセスはファイルにアクセスできません。別のプロセスがファイルの一部をロックしています。バックアップ操作の概要:-----------------------バックアップ操作が完了する前に停止しました。バックアップ操作が完了する前に停止しました。エラーの詳細: プロセスはファイルにアクセスできません。別のプロセスがファイルの一部をロックしています。正常にバックアップされたファイルのログ:C:\WINDOWS\Logs\WindowsBackup\Backup-25-03-2023_15-08-17.logバックアップに失敗したファイルのログ:C:\WINDOWS\Logs\WindowsBackup\Backup_Error-25-03-2023_15-08-17.logバックアップセットのいずれかのボリュームのバックアップイメージを準備しているときにエラーが発生しました。プロセスはファイルにアクセスできません。別のプロセスがファイルの一部をロックしています。

^*1:illumos: manual page: zfs.8

^*2:illumos: manual page: mount.8

^*3:Managing CIFS Shares (Task Map) (Solaris CIFS Administration Guide)

at 19:59 |

2023/03/16

新ファイルサーバができた

omnios

zfs

40GbE

100GbE

Broadcom 9400-16e interface cards/adapter SAS,SATA Internal

Mellanox ConnectX-5 EN - Network adapter - PCIe 3.0 x16 - 100 Gigabit QSFP28 x 2

10 年くらい増強しながら使い続けてきた仕事場のファイルサーバがさすがにやばくなってきたので、新しい構成に入れ替えました。
筐体は年初くらいに届いていたのですが、結局忙しくて 2 ヶ月くらい放置モードでした。

今回のサーバ構成はこんな感じ。

Dell PowerEdge R7515 (8C, 64GB)
OmniOS CE
HDD 10TB × 18（本体 3.5″ 14 Bay + エンクロージャー 3.5″12 Bay）
Mellanox® ConnectX®-5 100GbE Dual^*1（ただし、接続は 40GbE）
Broadcom HBA 9400-16e^*2

OS や構成的には安定したものを選んでいるのと、移行は zfs のsend/recv を使ったので特に苦戦しませんでした。
シーケンシャルなスループットは現状で 4～5Gbps (SSD 未搭載なので)くらいなので、普通にファイルサーバとして使うには十分な性能です。

とりあえず動くようになったので、今後は SSD を搭載したりメモリ増やしたりする予定です。

† HBA からはカーネルの warning が出るけど・・・

起動するたびにポートが 21 個あるとか言ってますが、何なんでしょうね？

Mar 15 01:12:55 host scsi: [ID 107833 kern.warning] WARNING: /pci@b6,0/pci1022,1483@1,1/pci1000,3020@0 (mpt_sas1):#012#011Number of phys reported by HBA SAS IO Unit Page 0 (21) is greater than that reported by the manufacturing information (16). Driver phy count limited to 16. Please contact the firmware vendor about this.

Broadcom HBA 9400-16e のポートは miniSAS HD × 4 で、MiniSAS HD 1 ポートあたり SAS 4 ポートなので物理的にも 16 ポートしか存在しないはずなので、mpt_sas1 のバグでしょうか。
ひとまず実害はないようなので無視することにします。

^*1:NVIDIA Mellanox ConnectX-5 アダプター - NVIDIA

^*2:Broadcom 9400 Series Tri-Mode Storage HBAs

at 21:15 |

2022/01/08

zfs のディスク交換で「new device has a different optimal sector size」と言われたので

zfs

omnios

zpool のディスクが 1 つ壊れてしまったので、zpool replace で交換しようとしたら見慣れないエラーが出たのでメモ。

$ zpool replace tank c1t1d1 c1t2d1cannot replace c1t1d1 with c1t2d1: new device has a different optimal sector size; use the option '-o ashift=N' to override the optimal size

これは512B セクタで作った zpool に 4kB セクタのディスクを追加したときにこのエラーが発生するようです。

ちなみにashift 値のデフォルトは 512B セクタのときashift=9、4KB セクタの時ashift=12です。
パフォーマンスの問題を除いて 4kB セクタのディスクと 512B セクタの混在は問題にならないようなので、今回は強制的にashift=9 を指定して replace することにしました。

zpool replace -o ashift=9 tank c1t1d1 c1t2d1

† 参考

Can't replace drive in older array because of ashift differences? (ashift=9 vs 12) : zfs

Yes, it is absolutely safe.
It's not ideal, as the messages you've seen indicate, but the only disadvantage is that of speed: ashift=12 will (probably) be faster.

at 10:40 |

2021/06/11

OmniOS CE の syslog を rsyslog に切り替え

omnios

OmniOS CE も昨年11月にアップデートされた r151036 からrsyslog が使えるようになっています^*1。
というわけで、syslogd からrsyslogd に切り替えを行ってみました。

切り替え方法は Oracle が公開しているSolaris 11.3^*2と同様の方法で問題ありませんでした。

pkg install rsyslogsvcadm disable svc:/system/system-log:defaultsvcadm enable svc:/system/system-log:rsyslogsvcs -xv

^*1:OpenSolaris-Derived OmniOS CE Updated With A Ton Of Changes - Phoronix

^*2:rsyslogd コマンドを使用した拡張システムロギング - Oracle® Solaris 11.3 でのシステム管理のトラブルシューティング

at 19:09 |

2021/05/03

OmniOS bloody を pkg update しようとしたらエラーが出たので

omnios

OmniOS bloody をインストールしているマシンをpkg updateしようとしたら、The following packages all deliver file actionsというエラーが出てアップデートさせてくれなくて困ったので、忘れないうちに対応方法をメモ。

パッケージ名が変わっているものがあると、コンフリクトしたような感じになるみたいですね。
以下のスレッドにあるとおり、pkg のキャッシュをリフレッシュしたら問題なくアップデートできました。

Update of OmniOS bloody fails due to Python package conflict | Topicbox

Can you try again after doing an explicit package refresh?
% pfexec pkg refresh --full
% pfexec pkg update -f

at 14:44 |

2020/11/28

Omnios で「Not on system console」と言われたので・・・

omnios

Omnios の設定を変更して rsh から root でログインしようとしたら、「Not on system console」と怒られてしまいました。
どうも Solaris ではセキュリティ強化のためにコンソール以外からの root ログインが認められていないようです。

対応方法はオフィシャルなマニュアルにありますが、以下にあるとおり安易な設定変更は止めた方が良さそうです。今回の対象のマシンは外部からアクセスできず、rsh のトラフィックが流れるネットワークも他のマシンから見えないようにあらかじめ分離してあるという条件が揃っているので、ログインを許可する設定に変更しました。

Not on system console (主要メッセージの手引き)

対処方法
一般ユーザーとしてそのシステムにログインし、su(1M) を実行してスーパーユーザーになります。どの端末からもスーパーユーザーとしてログインできるようにするには、/etc/default/login の CONSOLE 行をコメントにします (ただし、セキュリティ上の理由から、この方法は推奨しません)。

at 02:08 |

2020/09/20

DTrace で smb へのアクセスをリアルタイムに見る

omnios

ファイルサーバに使っている OmniOS の入ったマシン上で DTrace を使って smb へのアクセスをリアルタイムに見てみました。

OmniOS CE は元々は OpenSolaris ということもあって DTrace が使えるので、こういうことはやろうと思えばすぐにできることは知っていたんですが、使われている言語がちょっと特殊なのでこれまで重い腰が上がらなかったんですよね。今回は[Dtrace SMB-related snippets] All things SMB #tags: smb, dtrace, io に掲載されている smb-read-write-lat-by-path.d を少し改造させてもらいました。

smb-read-write-lat-by-path-rt.d

dtrace -qn 'char m[string];BEGIN { m["smb_fsop_read"] = 0x52; m["smb_fsop_write"] = 0x57;}::smb_fsop_read:entry,::smb_fsop_write:entry { self->arg0 = args[0]; self->node = args[2]; self->t = timestamp;}::smb_fsop_read:return,::smb_fsop_write:return /self->arg0/ { this->delta = timestamp - self->t; this->a_family = self->arg0->session->ipaddr.a_family; this->l_a_family = self->arg0->session->local_ipaddr.a_family; this->addr = &self->arg0->session->ipaddr.au_addr.au_ipv4; this->l_addr = &self->arg0->session->local_ipaddr.au_addr.au_ipv4; printf("%Y\tsrc: %s\tdst: %s\t(%c) %s\t%d\n", walltimestamp, inet_ntop(this->a_family, this->addr), inet_ntop(this->l_a_family, this->l_addr), m[probefunc], stringof(self->node->vp->v_path), this->delta/1000); self->arg0 = 0; self->t = 0; self->node = 0;}/*　tick-1200sec {　exit(0);　}　*/END {}'

実際にこれを走らせたときのログはこんな感じ。
これでファイルサーバの負荷やレイテンシをリアルタイムに見ることができるようになりました。

2020 Sep 20 13:02:38src: 192.168.1.1dst: 192.168.100.100(W) /path/to/file1322020 Sep 20 13:02:38src: 192.168.1.2dst: 192.168.100.100(W) /path/to/file2312020 Sep 20 13:02:38src: 192.168.1.2dst: 192.168.100.100(W) /path/to/file3182020 Sep 20 13:02:38src: 192.168.1.2dst: 192.168.100.100(W) /path/to/file4112020 Sep 20 13:02:38src: 192.168.1.4dst: 192.168.100.100(W) /path/to/file5172020 Sep 20 13:02:40src: 192.168.1.1dst: 192.168.100.100(W) /path/to/file6202020 Sep 20 13:02:40src: 192.168.1.3dst: 192.168.100.100(W) /path/to/file8182020 Sep 20 13:02:40src: 192.168.1.3dst: 192.168.100.100(W) /path/to/file9102020 Sep 20 13:02:40src: 192.168.1.3dst: 192.168.100.100(R) /path/to/file1032020 Sep 20 13:02:40src: 192.168.1.3dst: 192.168.100.100(R) /path/to/file1142020 Sep 20 13:02:40src: 192.168.1.3dst: 192.168.100.100(R) /path/to/file1222020 Sep 20 13:02:40src: 192.168.1.3dst: 192.168.100.100(R) /path/to/file1362020 Sep 20 13:02:40src: 192.168.1.3dst: 192.168.100.100(R) /path/to/file1412020 Sep 20 13:02:40src: 192.168.1.3dst: 192.168.100.100(R) /path/to/file1552020 Sep 20 13:02:40src: 192.168.1.3dst: 192.168.100.100(R) /path/to/file1622020 Sep 20 13:02:40src: 192.168.1.3dst: 192.168.100.100(R) /path/to/file1732020 Sep 20 13:02:40src: 192.168.1.3dst: 192.168.100.100(R) /path/to/file1812020 Sep 20 13:02:40src: 192.168.1.3dst: 192.168.100.100(R) /path/to/file1932020 Sep 20 13:02:40src: 192.168.1.3dst: 192.168.100.100(R) /path/to/file2012020 Sep 20 13:02:40src: 192.168.1.3dst: 192.168.100.100(R) /path/to/file215

at 14:08 |

2019/02/10

zfs で Permanent error が出たら

zfs

omnios

zfs の send/recv で旧サーバから新サーバにスナップショット転送しようとしたら、何度やっても以下のようなエラーを吐いて失敗するファイルシステムがあるので困ってしまいました。

warning: cannot send 'tank/foo@snap-daily-1-2019-02-10-030100': I/O errorcannot receive new filesystem stream: checksum mismatch or incomplete stream

イヤな予感がしてふと zpool の状態を確認してみてびっくり。
Permanent error とか言われていました。。。。

root@fileserver:~# zpool status -v tank pool: tank state: ONLINEstatus: One or more devices has experienced an error resulting in data corruption. Applications may be affected.action: Restore the file in question if possible. Otherwise restore the entire pool from backup. see: http://illumos.org/msg/ZFS-8000-8A scan: scrub in progress since Mon Feb 11 20:14:01 2019 66.7M scanned out of 3.85T at 1.45M/s, (scan is slow, no estimated time) 0 repaired, 0.00% doneconfig: NAME STATE READ WRITE CKSUM tank ONLINE 0 0 17 c1t0d0 ONLINE 0 0 34 logs c1t2d0 ONLINE 0 0 0 cache c1t3d0 ONLINE 0 0 0errors: Permanent errors have been detected in the following files: tank/share@snap-daily-1-2019-02-10-030100:/path/to/file tank/foo@snap-daily-1-2019-02-10-030100:/some/file tank/foo:<0x1ea362> tank/foo:<0x1ea363> /tank/foo/some/file /tank/bar/other/file

どうもこれが問題の原因のようです。
そもそも zfs って checksum を勝手に照合しているからファイルの不整合って起きないんじゃ・・・と思っていましたが、破損が検出できるだけで壊れるときは壊れるんですね。
最近、電源の事故があってブッチリ切れたりしましたから、そのときかなぁとは思います。

こうなってしまうと破損したファイルは諦めるしかなく、当該のファイルやスナップショットを削除することで send/recv ができるようになります。

† 参考

at 14:55 |

2018/03/31

OpenIndiana で HP Smart Array P420i を使う

openindiana

omnios

smartos

HP Smart Array P420i を HBA モードで使っていると、OpenIndiana からはディスクが認識できません。
これは標準でインストールされているcpqary3 ドライバが HBA モードに対応していないためです。

これをなんとかする方法がないかと思って調べてみたら、同じ illumos 系のSmartOS にHBA モードに対応した smrt というドライバ^*1を発見。

ただ、SmartOS は OpenIndiana や OmniOS と違って、Zones や KVM を備えた仮想化ホストなので、Global Zone にソフトウェアをあれこれインストールして使うことは想定されておらず、実際にサーバとして使うためにはそのための環境を構築しなければならないという問題があります。

そんなわけで、SmartOS に載っている smrt ドライバを OpenIndiana にインストールして使えるようにしてみたのでメモ。

[OpenIndiana で HP Smart Array P420i を使うの続きを読む]