ZFSとゲストファイルシステムを使用するSmartOS
10台程度のディスクでRAIDZ2のようなことをした場合、ゲストオペレーティングシステムでext3/4のようなファイルシステムを使用すると、ゲストファイルシステムはZFSを使用しているかのように安全になりますか？
私が尋ねている理由は、いくつか読んだ後、ZFSを使用するときは、ストレージ1TBあたり1GBのRAM）を使用することをお勧めします（最終的には約20〜40TBになります）。ホストとゲストの両方にZFSがある場合、2倍のRAMが必要になります。
はいといいえ。下部にZFSがあり、zvolを作成してブロックプロトコルを使用して提供する場合、またはファイルレベルのプロトコル（NFS、CIFS）を提供し、ファイルをディスク（.vmdk、.vhdなど）として作成する場合、ある程度の安全性は得られますが、多くの場合、クライアント（この場合、VMオペレーティングシステム）は、ユーザーが保護されるようにデフォルトで設定されているとは限りません。期待します。
この理由は、多くのデフォルトのファイルシステムセットアップがパフォーマンスを選択し、場合によっては安全性を犠牲にするためです。これが、ローカルハードディスクを使用している場合でも、突然の電源イベントの後にWindowsマシンがCHKDSKを実行する必要がある場合がある理由です（同様に、Linuxはfsckを実行する必要がある場合があります）。問題のOSとファイルシステムを探し回って、基盤となるディスクとより定期的に同期するために必要な変更があるかどうかを判断したり、ファイルシステムのジャーナリングを有効にしたりする必要があります。サポートします。
さらに、使用するプロトコルでクライアント（VM OS）からサーバー（ZFS））に使用するオプションも、ある程度の影響を及ぼします。最も悪名高いオプションの1つは、iSCSI経由です。 illumos/Solaris派生物のCOMSTAR。ほとんどのデフォルトでは、COMSTARは「書き込みキャッシュ」を有効にして新しいLUをセットアップします。これは、デフォルトでは、すべての着信I/Oを同期としてZFSに渡さず、代わりに次の場合にのみ渡します。クライアントによってそのように特別にフラグが立てられます（VM OS）。他の設定によっては、VM OSが/ not /すべてを渡すことはかなり一般的です。 I/Oは同期としてダウンしているため、同期としてZFSに移行しないため、ディスクのZILメカニズムを利用していないため、電力損失イベントから安全ではありません。
ここでの主な問題は、基本的に、ZFS自体が破損のないことを意図しており、ZFS自体が「破損」することは一般に不可能であるため、文字通り「fsck」スタイルのユーティリティすら持っていないことですが、そのロジックは必ずしも.vmdkまたはzvols内のファイルシステムについては、それらの上位レベルのファイルシステムが取得した瞬間にすべてのI/Oをディスクに同期しない場合に当てはまります（デフォルトのオプションではほとんど同期されません）。また、ZFSセットアップがZILを利用していない場合（たとえば、無効にしたため）、またはZFSが置かれている基盤となるストレージがキャッシュフラッシュコマンドを無視しているか、送信されていない場合（たとえば、 ZFSにそうしないように言った）。これらのシナリオでは、ZFSは常にディスク上で一貫している必要がありますが、問題は、電源イベントが回復した後、「X」秒前に一貫性があります-ZFSで破損することなく起動しますが、それはどのようになりますか物事は5-30秒前でした。これはZFSには問題ありませんが、zvols/disks-as-files（.vmdk）内のファイルシステムには問題がない可能性があります。その5秒間の「ロールバック」は、その.vmdk内のファイルシステムにとって重要なメタデータであった可能性があり、上位レベルでは壊れたり、起動できなくなったりします。その間、ZFSはまだすべてが大丈夫だと考えています。
上位レベルのOSを人間が可能な限り安全にするには、次のすべてが当てはまる必要があります。
- zfsはzilを利用する必要があります。たとえば、sync = disableを実行しないでください。
- zfsは、それ自体がバッテリー/ NVRAMでバックアップされているディスクに書き込むか、キャッシュフラッシュコマンドに従う必要があります。 zfs_nocacheflushを1に変更しないでください
- ブロックプロトコルプロバイダー（おそらくCOMSTAR（SmartOSではCOMSTAR））は、「書き込みキャッシュ」設定を使用する必要はありません-これは、クライアントが同期を送信していると思っていても当てはまります-とにかくすべてを同期させたい場合は、なぜですかこれを有効のままにして、そのように扱われないものを危険にさらしますか？同様に、ファイルレベルのプロトコル（可能な場合は常にオーバーブロックする必要があります）を使用する場合は、同期に設定されていることを確認してください。これはNFSのデフォルトです（クライアントのNFSマウントオプションで「非同期」と表示されないようにしてください） ）。
- VMディスクを提供しているzfsのデータセット/ zvolにsync = alwaysを設定することをお勧めします
- ハイパーバイザーは、同期を送信するように構成するか、少なくともVMから同期要求を無視して削除しないように構成する必要があります（SmartOSでは問題ではありませんがAFAIKですが、VMwareでは可能です）
- あなたのVM OS 'は、書き込みキャッシュを行わないように設定する必要があります-少なくとも、書き込みをキャッシュするのではなく、すべての書き込みで同期することが望ましくない場合は、すぐにジャーナルする必要があります。これは個々のファイルシステムで行われ、OSオプションはこの投稿には多すぎますが、OSを「電源障害から安全」にするための情報を探してください。重要な用語：書き込みバリア、書き込みキャッシュ、同期/ fsync、ジャーナル
クライアントOSファイルシステムが書き込みを抑制しておらず、同期データ要求を処理する仲介者がなく、背面が同期するように適切に設定され、適切なストレージ自体に置かれている場合、その時点ですべての期待を持っている必要がありますあらゆる種類の電力損失イベントは、VMファイルシステムへの影響を最小限に抑えます。最悪の場合、起動時に迅速なchkdsk/fsckが必要になります。それでも、大幅に破損したり、破損したりすることはありません。上記のリストの多くが当てはまらないほど、重大な破損の可能性が高くなります。
いつものように、KEEPBACKUPSについても言及する必要があります。上記のすべてを実行し、完全に停電に対して安全な環境を構築したとしても、VM上のウイルス、ハッカー、36時間の覚醒時のミス、不満を持つ従業員、深刻な状況からユーザーを保護することはできません。ハードウェアの問題、または（不）自然災害。
RAIDは、ディスク障害によるデータ損失を防ぐために物理ディスクにのみ役立ちます。
RAIDZ2は、ディスクレベルではなくファイルレベルで動作することを除いて、RAID6と同様の機能を提供します。そのため、RAIDZ2によって提供される保護は、ゲストがファイルであるため、ゲストに自動的に拡張されます。