ZFS L2ARC(Brendan Gregg) (2008-07-22)および ZFS and the Hybrid Storage Concept(Anatol Studler's Blog) (2008-11-11)次の図を含める:
SSDレイヤーの垂直の白い線を、使用する設定として解釈する必要があります個別 SSD –
個人的には、自宅では、L2ARCとZILのどちらも、私が利用できるコンピュータで使用することはほとんどありません。 (私の日常のコンピュータは、8 GBのメモリとハイブリッドSeagate ST750LX003-1AC154を搭載したMacBookPro5,2です。光学式ドライブをSSDに交換する予定はありません。)
他の場所:職場ではキットの目的が変更される可能性がありますが、日付や詳細はわかりません。 (Xserve RAID x2が混在している…現時点では、それらをZFSに提供することは想像していませんが、私は心を開いています。)
私のSSDのベストプラクティスに関する好奇心は、L2ARCとZILの両方について、ZEVO領域でのパフォーマンス関連の議論、特にユーザーが単一のディスクにL2ARCとZILの両方を持っている、以下で言及されているトピックに従っている間に始まりました。
L2ARCスクリーンショット(Brendan Gregg) (2009-01-30)
SLOGスクリーンショット(Brendan Gregg) (2009-06-26)
[zfs-discuss] ZFSルートバックアップ/「障害」回復、およびルートプールの移動 (2011-01-10)は、3つの混合に対して推奨しています単一ディスク上のもの(ルートプール、ZIL、L2ARC)–
…同じディスク上で3つすべてを管理しようとするときに発生する可能性がある頭痛の種には値しません。たとえば、データプールのZILのコンテンツを再インストールして誤って上書きすることにした場合。管理とリカバリをシンプルに保つために、プールコンポーネントまたはプール間でディスクを共有しないでください。 …
– 1つのディスクでこれらの要素を2つ混在させないことが推奨されるかどうかに、より関心があります。
https://superuser.com/a/238744/84988 (2011-01-28)は、「キャッシュ(L2ARCキャッシュ)とSSDへのログ(ZIL)の書き込み」に言及しています(単数)。ただし、FuseとWindowsに関連しているため、ZFSのより一般的でパフォーマンス重視の使用に特に関連する回答としては扱いません。
@ChrisS Comms RoomのZILおよびL2ARCについて 2011-08-16。
http://forums.macrumors.com/showpost.php?p=14248388 (2012-01-31)が議論multiple SSD:
ZFSについて理解する必要があること:キャッシュには、読み取りと書き込みの2種類(L2ARCとZIL)があり、通常SSDに格納されます。 ZILは書き込みキャッシュです。これがおそらくこの誤解の原因です。 ZILは、zpoolに発生するすべての書き込みで(アクティブなシステムを想定して)攻撃されています。問題は、mlcベースのSSDをZILとして使用すると、摩耗して非常に早く故障することです。 ZILドライブとして使用するには、(はるかに高価な)slcベースのSSDが必要です。
SSDだけでzpoolを構成することは可能であるだけでなく、非常にうまく機能します。また、ZILとL2ARCに別々のドライブを用意する必要もありません。はい、TRIMのサポートはありませんが、ZFSのコピーオンライトの性質に基づいているため、おそらくそれは良いことです。
そうは言っても、ZFSはほぼフル(たとえば85%以上)のzpoolではうまく機能しません。回転磁気メディアを使用しているかソリッドステートを使用しているかに関係なく、パフォーマンスは大幅に低下し始めます。 TRIMサポートの欠如はおそらくその問題を悪化させますが、それはすでに問題です。
https://serverfault.com/a/397431/91969 (2012-06-11)の推奨事項:
https://superuser.com/a/451145/84988 (2012-07-19)はsingular「ZFSを高速化するためのZILおよびL2ARCのSSD」について言及しています。
zevo.getgreenbytes.com•トピックを表示-FW800接続順序でのパフォーマンスの問題? (2012-09-24)は、FireWireバス上のものの順序にsingle = ZILおよびL2ARCのSSD
より具体的には、上の図の白い線の解釈について疑問に思いました…
短い答えです。解決しようとしている問題がわかりません...
可能であれば、別のデバイスを使用してください。これは環境の規模に依存します...それが単純なホームシステムまたは仮想化されたもの、あるいは オールインワンZFSソリューション の場合、単一のデバイスを使用できます。
大規模または高性能のZFSソリューションでは、ZILまたはL2ARCの役割に特に適したデバイスを使用しています。 STEC ZeusRAM または DDRDrive (ZILおよびすべてのエンタープライズSLCまたはMLC SAS SSD for L2ARC)。
何してるの?
ZILについて最初から根本的な誤解があり、続行する前に修正する必要があります。
これを理解する:「通常の」状況では、ZIL/SLOGは変更されません。
それはonly同期書き込みがコマンドされたとき、またはsync = alwaysが特定のプール/データセットで有効な場合に書き込まれます( "zfs get sync pool/dataset")
ZILは通常の状況では読み取られません。これは災害復旧機能です。
IE:ZILは、電源がオフになったときにのみ存在します。データがプールにコミットされる前にOSにアックバックされたデータを再生するために使用されます。プールへのすべてのZFS書き込み(同期または非同期)は、メモリーバッファーからのものです。
通常の状況では、データがプールに到達すると、slogエントリーが蒸発することが許可されます。これは大きな循環書き込みバッファーであり、非常に大きくする必要はありません(ほとんどの状況では、1GBでも過剰です)。
非同期書き込みは、RAMにバッファリングされ、照合されて、適切なタイミングでディスクに書き込まれます。電源がオフになると、そのデータは失われますが、FS=整合性は維持されます(これが、sync = alwaysを設定したい理由です)
一方、L2ARCは、読み取りと書き込みの両方のレベルで大きな打撃を受けています。
L2arcにあるもののメタデータがARC RAMから出てくるため、「L2ARCが多すぎる」などの問題があります(つまり、L2ARCサイズを増やす場合は、RAMを増やす必要があります。そうしないと、パフォーマンスが大幅に低下し、最終的には、l2arcの使用は、「使用可能なすべてのスペース」よりもかなり低いレベルで横ばいになります)
一部のメーカーの抗議にもかかわらず、l2arcサイズを増やすことでメモリ不足を補うことはできません(ZFSアプライアンスに分岐したハードウェアRAIDアレイのいくつかのメーカーがこの仮定を行っています)
tl; dr:IOロードがデータベースアクティビティである場合、ZILは激しく非難される可能性があります。それ以外の場合は、軽く触れるだけである可能性が高くなります。アクティビティの99.9%のZIL関数は決して起動しません。
これを知ることで、ZILにSLOGパーティションが必要かどうか、それがl2arcパーティションと共存できるかどうか、またはスタンドアロンドライブが必要かどうか(およびスタンドアロンドライブのパフォーマンスレベル)を決定できるようになります。