仮想ファイルサーバーとしてのFreeNASのリスク
FreeNASを仮想マシンとして実行できるかどうかについては多くの議論があります。
公式の見解は「はい」ですが、 追加の構成が必要 があります。
これらの推奨事項に従うことができることを保証できない場合、EXT4/XFSでVanillaLinuxシステムを実行する場合、またはUFSでFreeBSDを実行する場合よりも、障害（特に壊滅的な障害）に対して脆弱ですか？
具体的には、PCIパススルーを実行できず、書き込みキャッシュを無効にできないと想定します。さらに、ストレージ用のvDisk（ハードウェアRAIDでバックアップされたVMDK）は1つしかないため、RAIDZはありません。明らかに、バックアップがあります。
[〜＃〜] edit [〜＃〜]：これを実行する理由を明確にするために-ファイルサーバーが必要です。これがインフラストラクチャです。私は一緒に仕事をしなければなりません。必要に応じて、RAIDZをセットアップするための追加のvDiskを入手できますが、それ以外の場合はそれだけです。私は良いファイルサーバーソリューションを探していました、そしてFreeNASはその法案に合うようでした。 ZFSの仮想化と、すべてのデータを失い、バックアップを破壊する方法について、これらの悲惨な警告がすべてあったことを除いて。
このインフラストラクチャにFreeNASを導入するのは危険だと思います。私の質問は：それは代替案よりも危険ですか？
EDIT2：意図を伝えるのに問題があるようです。 ZFSを備えたFreeNASは堅実なNASプラットフォームです。しかし、私が持っているものから 読み取り 、ZFSをベアメタルファイルサーバーとしてより信頼できるものにする機能のようです標準のVM構成で実行すると、実際に問題が発生する可能性があります。その場合は、標準のVM設定（VM $ ===）で別のファイルシステムを使用することをお勧めします。つまり、直接IOがなく、書き込みキャッシュが有効になっています）。これは正しい評価ですか？
一般的な答え
これらの推奨事項に従うことができることを保証できない場合、EXT4/XFSでVanillaLinuxシステムを実行する場合、またはUFSでFreeBSDを実行する場合よりも、障害（特に壊滅的な障害）に対して脆弱ですか？
リスクは異なり、直接比較することはできません。
- データ整合性の知識のためだけであれば（バックアップから復元する必要がある場合でも）、冗長なvdevがなくても、常にZFSシステムを好みます。 that私が気付いていないサイレントな破損の代わりに、バックアップから復元する必要があることを知りたい）。また、
send/recvやスナップショットなどの機能により、ライブがはるかに簡単になり、整合性とは何の関係もありません。 - 壊滅的な障害と言えば、バックアップだけがそれを防ぐことができ、通常のシステムの信頼性が高い場合でもバックアップが必要になるため、最初に行うのが理にかなっています（すでに行ったように）バックアップから始めて、それを邪魔にならないようにし、次に、必要な他のサービス品質と、どのような欠点を抱えて生きることができるかを考えます。
- 理論的には、より複雑なシステムはエラーが発生しやすくなりますが、言及されているすべてのファイルシステムは10年以上前のものであり、積極的に使用および保守されているため、バグの大部分はすでに解決されていると言えます（つまり、バグが残っていないわけではありません） 、 もちろん）。
- コピーオンライトファイルシステムは、ライブデータを上書きせず、したがってデータを破壊できないため、本質的に安全であると主張する人もいるかもしれません。このリスクはより理論的であり、実際の実装やメタデータの処理など、他のものによってはるかに影響を受けると思います。
あなたのケースに固有
参照されている推奨事項を見て分析すると、いくつかのことに気付くでしょう。
- PCIパススルーを使用していない場合（詳細は以下を参照）、ZFSでスクラブタスクを無効にする必要があります。ハードウェアはZFSに「うそをつく」ことができるので、スクラブは良いよりも多くのダメージを与える可能性があり、場合によってはzpoolを永久に破壊することさえあります。
Scrubは、基礎となるvdevのすべてのブロックを読み取り、それらのチェックサムを検証するだけです。仮想ディスクがこれに対応しない場合、それはゴミであり、ZFSではなくそれについて心配する必要があります。一方、仮想ディスクがすでにSANでチェックサムされている場合、追加のスクラブは追加のI/Oを引き起こす以外は何もしません（役に立たない）。
- 2番目の予防措置は、SAN、NAS、またはRAIDコントローラー自体で発生している書き込みキャッシュを無効にすることです。書き込みキャッシュは、ディスクに書き込まれたものと書き込まれていないものについてZFSを簡単に混乱させる可能性があります。この混乱により、壊滅的なプール障害が発生する可能性があります。
ハードウェアを信頼できない場合、これは良いアドバイスです。もちろん、欠点はパフォーマンスが大幅に低下することです。また、SAN設定を制御できない場合もあるため、ebayから購入してシステムに組み込んだ安価なディスクとして扱う必要があります。少なくとも理論的には、何が起こる可能性もあります。
- 単一のディスクを使用すると、プールのメタデータが破損しやすくなり、プールが失われる可能性があります。これを回避するには、ストライプまたはRAIDZ構成のいずれかで少なくとも3つのvdevが必要です。 ZFSプールメタデータは、使用可能な場合は3つのvdev間でミラーリングされるため、プールを構築するために少なくとも3つのvdevを使用する方が、単一のvdevよりも安全です。理想的には、独自の冗長性を持つvdevが推奨されます。
これは一般的なアドバイスとしては問題ありませんが、ちょっとした落とし穴です。 SANが悪いと仮定すると、これは特定の場合に役立ちます（少なくとも運が良ければ）。 SANが適切であると仮定すると、これは何もせず、スペースとパフォーマンスを犠牲にするだけです。私の意見では、物理ディスクからSAN、ネットワーク、VMホスト、VMゲストまでのチェーンが同じように優れていることを確認する方がはるかに優れているため、各レイヤーですべてをやり直す必要はありません。
FreeNAS対他
FreeNASの推奨事項についての一言-それらは推奨事項、つまり一般の聴衆のためのガイドラインやヒントとして確かに大丈夫です。あなたがそれらに従うならば、あなたはそうでない場合よりも悪くなることはなく、さらに良くなるかもしれません。それから再び、FreeNASコミュニティの通常の口調のように（少なくとも特定のフォーラムのポスターから判断すると）、それらは厳しい言葉です。私は彼らがそれで安全な側になりたいだけだと思います。私は常に ZFSベストプラクティスガイド を好みました。なぜなら、それはかなり中立的な言葉であり、事実を提示するだけであり、決定はあなたに任されているからです。
FreeNASのドキュメントとフォーラムによると、OmniOS（またはSmartOSまたはillumos）のメーリングリストにいる間に、哀れな4GB未満のRAMでファイルサービス用のZFSシステムを実行しようとすると、恐ろしい死を迎えることも興味深いですまたはNexenta、現時点では覚えていません）人々は512MBのRAMでシステムをテストし、それらを構成する方法の提案を共有しました。全体として、それは詳細の知識に関するものであり、あなたが従うべきルールを確立するのではなく、選択は各人に任されていました。
時間の経過とともに、この問題の重要性は低下し、推奨事項は変更されます。通常のデスクトップおよびサーバーエディションでZFSに切り替えるシステムが増えるにつれてです。 Ubuntuはすでにそれを行っており、他の人もきっと続くでしょう。 2、3年以内にディストリビューションの80％がZFSまたはbtrfsを使用する場合、それらのほとんどは仮想化されて実行されるため、これは重要なポイントです。
代替案について言えば、StarWindFreeを試すことができます。 RAMおよびSSDキャッシング、オプションの重複排除があり、同期レプリケーションを使用して高可用性を実現します。
私の唯一の不満は、私ができないことですSMB VMから直接）現在使用しているRDMA実装にはSR-IOVにいくつかの問題があるためです。Mellanoxがリリースされることを願っていますWindows Server2012r2および2016ドライバーの修正はまもなく行われます。
ここで私たちに何を求めているのかわかりません。
これらの推奨事項に従うことができることを保証できない場合は、...
推奨事項に従うことができることを保証できない場合は、サポートされていない環境があります。
彼が「あなたは大丈夫だと確信している」と言った場合、それはあなたがそのアドバイスから何を期待しているのではありませんか？