LVMとマトリョーシカの共通点は何ですか?

今日は。
md RAID + LVM を使用して KVM 用のデータ ストレージ システムを構築した実際の経験をコミュニティと共有したいと思います。

プログラムには以下が含まれます:

• NVMe SSD から md RAID 1 を構築します。
• SATA SSD と通常のドライブから md RAID 6 を組み立てます。
• SSD RAID 1/6 での TRIM/DISCARD 操作の機能。
• 共通のディスク セット上にブート可能な md RAID 1/6 アレイを作成します。
• BIOS で NVMe がサポートされていない場合に、NVMe RAID 1 にシステムをインストールする。
• LVM キャッシュと LVM シンの使用。
• BTRFS スナップショットを使用し、バックアップのために送受信します。
• BTRFS スタイルのバックアップに LVM シン スナップショットと Thin_delta を使用します。

興味のある方は猫をご覧ください。

Заявление

著者は、この記事の資料/例/コード/ヒント/データを使用した場合または使用しなかった場合の結果について、一切の責任を負いません。 何らかの形でこの資料を読んだり使用したりすることにより、お客様はこれらの行為によるすべての結果に対して責任を負うことになります。 考えられる影響は次のとおりです。

• サクサクしたNVMe SSD。
• 録画リソースを完全に使い果たし、SSD ドライブが故障しました。
• バックアップ コピーを含む、すべてのドライブ上のすべてのデータが完全に失われます。
• コンピューターのハードウェアの故障。
• 時間、神経、お金の無駄。
• 上記に記載されていないその他の結果。

鉄

利用可能なものは次のとおりです。

Z2013チップセットを搭載し、Intel Core i87 / Haswellを搭載した7年頃のマザーボード。

• プロセッサー 4 コア、8 スレッド
• 32 GB DDR3 RAM
• 1 x 16 または 2 x 8 PCIe 3.0
• 1×4 + 1×1 PCIe 2.0
• 6 x 6 GBps SATA 3 コネクタ

SAS アダプター LSI SAS9211-8I が IT / HBA モードにフラッシュされました。 RAID 対応ファームウェアは、次の目的で意図的に HBA ファームウェアに置き換えられています。

1. このアダプターはいつでも捨てて、他のアダプターと交換できます。
2. TRIM/Discard はディスク上で正常に機能しました。なぜなら... RAID ファームウェアでは、これらのコマンドはまったくサポートされておらず、HBA は一般に、バス上でどのようなコマンドが送信されるかを気にしません。

ハードドライブ - ラップトップ用と同様、8 フォームファクターで 7 TB の容量を持つ HGST Travelstar 1000K1 を 2.5 台。 これらのドライブは、以前は RAID 6 アレイ内にありました。 これらは新しいシステムでも使用される予定です。 ローカルバックアップを保存するため。

さらに次のように追加されました。

SATA SSD モデル Samsung 6 QVO 860TB 2 個。 これらの SSD は大容量を必要とし、SLC キャッシュの存在、信頼性、低価格が求められていました。 Discard/zero のサポートが必要でした。これは dmesg の行でチェックされます。

kernel: ata1.00: Enabling discard_zeroes_data

NVMe SSDモデル Samsung SSD 2 EVO 970GB 500枚。

これらの SSD では、ニーズに合わせたランダム読み取り/書き込み速度とリソース容量が重要です。 彼らのためのラジエーター。 必然的に。 絶対に。 それ以外の場合は、最初の RAID 同期中にカリカリになるまで揚げてください。

PCIe 8 2x スロットに取り付けられた 2 x NVMe SSD 用の StarTech PEX2M3.0E8 アダプタ。 これも単なる HBA ですが、NVMe 用です。 内蔵 PCIe スイッチの存在により、マザーボードからの PCIe 分岐サポートを必要としないという点で、安価なアダプターとは異なります。 x1 PCIe 1.0 スロットであっても、PCIe を備えた最も古いシステムでも動作します。 当然、適切な速度で。 そこには RAID はありません。 ボードには BIOS が組み込まれていません。 したがって、システムは魔法のように NVMe で起動することを学習することはなく、ましてやこのデバイスのおかげで NVMe RAID を学習することはありません。

このコンポーネントは、システム内に空き 8x PCIe 3.0 が 2 つだけ存在するためであり、空きスロットが 4 つある場合は、2 ペニーの PEX1M600EXNUMX または類似品 (XNUMX ドルでどこでも購入できる) で簡単に置き換えることができます。ルーブル。

すべてのデータを保持しながら、SSD/HDD 自体を除くシステム全体を完全に交換できるようにするために、あらゆる種類のハードウェアまたは内蔵チップセット/BIOS RAID の拒否が意図的に行われました。 理想的には、まったく新しい/別のハードウェアに移行するときに、インストールされているオペレーティング システムさえも保存できるようにします。 主なことは、SATAとPCIeポートがあることです。 これはライブ CD またはブート可能なフラッシュ ドライブのようなものですが、非常に高速で少しかさばるのみです。

Юморそうしないと、何が起こるかわかります。場合によっては、アレイ全体を緊急に持ち帰る必要がある場合があります。 でもデータは失いたくないんです。 これを行うには、前述のすべてのメディアが標準ケースの 5.25 ベイのスライド上に配置されていると便利です。

もちろん、Linux で SSD キャッシュのさまざまな方法を実験するためでもあります。

ハードウェアレイドは退屈だ。 それをオン。 それは機能するか、機能しないかのどちらかです。 そして、mdadm には常にオプションがあります。

柔らかい

以前は、EOL に近い Debian 8 Jessie がハードウェアにインストールされていました。 RAID 6 は、LVM とペアになった上記の HDD から組み立てられました。 kvm/libvirt で仮想マシンを実行しました。

なぜなら著者は、ポータブル起動可能な SATA/NVMe フラッシュ ドライブの作成において適切な経験を持っています。また、通常の適切なテンプレートを壊さないようにするために、Ubuntu 18.04 をターゲット システムとして選択しました。これは、すでに十分に安定していますが、まだ 3 年の使用期間があります。今後のサポート。

前述のシステムには、すぐに使える必要なハードウェア ドライバーがすべて含まれています。 サードパーティのソフトウェアやドライバーは必要ありません。

インストールの準備

システムをインストールするには、Ubuntu デスクトップ イメージが必要です。 サーバー システムにはある種の強力なインストーラーがあり、UEFI システム パーティションをディスクの XNUMX つに押し込んでも無効にできない過度の独立性を示し、すべての美しさを台無しにします。 したがって、UEFI モードでのみインストールされます。 オプションは提供しません。

私たちはこれに満足していません。

なぜですか？残念ながら、UEFI ブートはブート ソフトウェア RAID との互換性が非常に悪いです。 誰も UEFI ESP パーティションの予約を提供しません。 ESP パーティションを USB ポートのフラッシュ ドライブに配置することを提案するオンラインのレシピがありますが、これは失敗点です。 UEFI BIOS がこのパーティションを認識するのを妨げない、メタデータ バージョン 1 のソフトウェア mdadm RAID 0.9 を使用するレシピがありますが、これは、BIOS または別のハードウェア OS が ESP に何かを書き込み、それを他のハードウェアと同期するのを忘れる幸せな瞬間まで存続します。鏡。

さらに、UEFI ブートは NVRAM に依存しており、NVRAM はディスクと一緒に新しいシステムに移動されません。 マザーボードの一部です。

したがって、新しい車輪を再発明することはありません。 私たちはすでに、UEFI 互換システム上で CSM という誇り高き名前を冠した、レガシー/BIOS ブートと呼ばれる、既製の実績のある祖父用自転車を持っています。 棚から取り出して、注油し、タイヤに空気を入れて、湿らせた布で拭きます。

Ubuntuのデスクトップバージョンもレガシーブートローダーでは正しくインストールできませんが、彼らが言うように、ここには少なくともオプションがあります。

そこで、ハードウェアを収集し、Ubuntu Live ブート可能フラッシュ ドライブからシステムをロードします。 パッケージをダウンロードする必要があるため、適切に機能するネットワークをセットアップします。 それが機能しない場合は、必要なパッケージを事前にフラッシュ ドライブにロードできます。

デスクトップ環境に移動し、ターミナル エミュレーターを起動して、次の手順を実行します。

#sudo bash

どうやって…？上の行は、sudo に関するホリワーの標準的なトリガーです。 Cbоより大きなチャンスが到来し、оより大きな責任。 問題はそれを自分自身で引き受けられるかどうかです。 多くの人は、このように sudo を使用するのは少なくとも注意が必要だと考えています。 しかし：

#apt-get install mdadm lvm2 thin-provisioning-tools btrfs-tools util-linux lsscsi nvme-cli mc

なぜ ZFS ではないのでしょうか...?私たちがコンピューターにソフトウェアをインストールするとき、私たちは基本的に、このソフトウェアの開発者にハードウェアを貸して運転してもらうことになります。
このソフトウェアにデータの安全性を信頼するとき、私たちはこのデータを復元する費用と同額のローンを組むことになりますが、それはいつか返済しなければなりません。

この観点から見ると、ZFS はフェラーリであり、mdadm+lvm は自転車に似ています。

主観的には、著者はフェラーリではなく、見知らぬ個人にクレジットで自転車を貸すことを好みます。 そこでは、この問題の価格は高くありません。 権利など必要ありません。 交通ルールよりも簡単です。 駐車場は無料です。 クロスカントリー能力が向上します。 自転車はいつでも脚を取り付けることができ、自分の手で自転車を修理することができます。

ではなぜBTRFS...?オペレーティング システムを起動するには、レガシー/BIOS GRUB ですぐにサポートされ、同時にライブ スナップショットをサポートするファイル システムが必要です。 これを /boot パーティションに使用します。 さらに、作成者はこの FS を / (ルート) に使用することを好みますが、他のソフトウェアの場合は LVM 上に個別のパーティションを作成し、必要なディレクトリにマウントできることにも留意してください。

この FS には仮想マシンやデータベースのイメージは保存されません。
この FS は、システムの電源をオフにすることなくシステムのスナップショットを作成し、送信/受信を使用してこれらのスナップショットをバックアップ ディスクに転送するためにのみ使用されます。

さらに、著者は通常、最小限のソフトウェアをハードウェア上に直接保持し、GPU や PCI-USB ホスト コントローラーを IOMMU 経由で KVM に転送するなどの手段を使用して、他のすべてのソフトウェアを仮想マシンで実行することを好みます。

ハードウェア上に残るのは、データ ストレージ、仮想化、バックアップだけです。

ZFS をより信頼する場合は、原則として、指定されたアプリケーションについては交換可能です。

ただし、著者は、ZFS、BRTFS、および LVM が備えている組み込みのミラーリング/RAID および冗長性機能を意図的に無視しています。

追加の議論として、BTRFS にはランダムな書き込みをシーケンシャルな書き込みに変換する機能があり、これは HDD 上のスナップショット/バックアップの同期速度に非常に良い影響を与えます。

すべてのデバイスを再スキャンしてみましょう。

#udevadm control --reload-rules && udevadm trigger

周りを見回してみましょう:

#lsscsi && nvme list
[0:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sda
[1:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdb
[2:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdc
[3:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdd
[4:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sde
[5:0:0:0] disk ATA Samsung SSD 860 2B6Q /dev/sdf
[6:0:0:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdg
[6:0:1:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdh
[6:0:2:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdi
[6:0:3:0] disk ATA HGST HTS721010A9 A3B0 /dev/sdj
[6:0:4:0] disk ATA HGST HTS721010A9 A3B0 /dev/sdk
[6:0:5:0] disk ATA HGST HTS721010A9 A3B0 /dev/sdl
[6:0:6:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdm
[6:0:7:0] disk ATA HGST HTS721010A9 A3J0 /dev/sdn
Node SN Model Namespace Usage Format FW Rev
---------------- -------------------- ---------------------------------------- --------- -------------------------- ---------------- --------
/dev/nvme0n1 S466NXXXXXXX15L Samsung SSD 970 EVO 500GB 1 0,00 GB / 500,11 GB 512 B + 0 B 2B2QEXE7
/dev/nvme1n1 S5H7NXXXXXXX48N Samsung SSD 970 EVO 500GB 1 0,00 GB / 500,11 GB 512 B + 0 B 2B2QEXE7


ディスクレイアウト

NVMe SSD

しかし、私たちはそれらをいかなる方法でもマークしません。 それでも、BIOS はこれらのドライブを認識しません。 したがって、完全にソフトウェア RAID に移行することになります。 そこにセクションを作成することもありません。 「規範」または「原則」に従いたい場合は、HDD などの大きなパーティションを XNUMX つ作成します。

SATA HDD

ここで特別なことを考え出す必要はありません。 すべてに対して XNUMX つのセクションを作成します。 BIOS はこれらのディスクを認識し、そこから起動しようとする場合もあるため、パーティションを作成します。 後でこれらのディスクに GRUB をインストールして、システムが突然これを実行できるようにします。

#cat >hdd.part << EOF
label: dos
label-id: 0x00000000
device: /dev/sdg
unit: sectors

/dev/sdg1 : start= 2048, size= 1953523120, type=fd, bootable
EOF
#sfdisk /dev/sdg < hdd.part
#sfdisk /dev/sdh < hdd.part
#sfdisk /dev/sdi < hdd.part
#sfdisk /dev/sdj < hdd.part
#sfdisk /dev/sdk < hdd.part
#sfdisk /dev/sdl < hdd.part
#sfdisk /dev/sdm < hdd.part
#sfdisk /dev/sdn < hdd.part


SATA SSD

ここが私たちにとって興味深いところです。

まず、ドライブのサイズは 2 TB です。 これは MBR の許容範囲内であり、これを使用します。 必要に応じて GPT に置き換えることができます。 GPT ディスクには互換性レイヤーがあり、MBR 互換システムは最初の 4 つのパーティションが最初の 2 テラバイト内にある場合にそれを認識できます。 重要なことは、これらのディスク上のブート パーティションと bios_grub パーティションが先頭にある必要があることです。 これにより、GPT レガシー/BIOS ドライブから起動することもできます。

しかし、これは私たちの場合ではありません。

ここでは 1 つのセクションを作成します。 最初のサイズは 1 GB で、RAID XNUMX /ブートに使用されます。

6 つ目は RAID XNUMX に使用され、ドライブの端にある小さな未割り当て領域を除いて、残りの空き領域をすべて占有します。

このマークのない領域は何ですか?ネットワーク上の情報源によると、当社の SATA SSD には、6 ～ 78 GB のサイズの動的に拡張可能な SLC キャッシュが搭載されています。 ドライブのデータシートにある「ギガバイト」と「ギビバイト」の違いにより、6 ギガバイトを「無料」で取得できます。 残りの 72 GB は未使用のスペースから割り当てられます。

ここでは、SLC キャッシュがあり、そのスペースが 4 ビット MLC モードで占有されていることに注意してください。 これは事実上、4 GB の空き領域ごとに 1 GB の SLC キャッシュしか取得できないことを意味します。

72 ギガバイトを 4 で乗算すると、288 ギガバイトになります。 これは、ドライブが SLC キャッシュを最大限に活用できるようにするためにマークアウトしない空き領域です。

したがって、合計 312 台のドライブから最大 2 GB の SLC キャッシュを効果的に取得することになります。 すべてのドライブのうち XNUMX 台は冗長性を確保するために RAID で使用されます。

この量のキャッシュにより、実際には書き込みがキャッシュに行かない状況に遭遇することはほとんどなくなります。 これは、QLC メモリの最も残念な欠点、つまりキャッシュをバイパスしてデータを書き込むときの書き込み速度が非常に遅いことを非常にうまく補います。 負荷がこれに当てはまらない場合は、データシートの TBW を考慮して、そのような負荷の下で SSD がどのくらい持続するかをよく考えることをお勧めします。

#cat >ssd.part << EOF
label: dos
label-id: 0x00000000
device: /dev/sda
unit: sectors

/dev/sda1 : start= 2048, size= 2097152, type=fd, bootable
/dev/sda2 : start= 2099200, size= 3300950016, type=fd
EOF
#sfdisk /dev/sda < ssd.part
#sfdisk /dev/sdb < ssd.part
#sfdisk /dev/sdc < ssd.part
#sfdisk /dev/sdd < ssd.part
#sfdisk /dev/sde < ssd.part
#sfdisk /dev/sdf < ssd.part


配列の作成

まず、マシンの名前を変更する必要があります。 これが必要なのは、ホスト名が mdadm 内のどこかにある配列名の一部であり、どこかに影響を与えるためです。 もちろん、配列の名前は後で変更できますが、これは不要な手順です。

#mcedit /etc/hostname
#mcedit /etc/hosts
#hostname
vdesk0


NVMe SSD

#mdadm --create --verbose --assume-clean /dev/md0 --level=1 --raid-devices=2 /dev/nvme[0-1]n1

なぜ - クリーンだと仮定するのですか...?配列の初期化を避けるため。 これは RAID レベル 1 と 6 の両方で有効です。 新しい配列の場合は、初期化なしですべてが機能します。 さらに、SSD アレイの作成時に初期化すると、TBW リソースが無駄になります。 組み立てられた SSD アレイに対して可能な限り TRIM/DISCARD を使用して「初期化」します。

SSD アレイの場合、RAID 1 DISCARD はすぐにサポートされます。

SSD RAID 6 DISCARD アレイの場合は、カーネル モジュール パラメータで有効にする必要があります。

これは、このシステムのレベル 4/5/6 アレイで使用されているすべての SSD が、discard_zeroes_data を有効にサポートしている場合にのみ実行する必要があります。 この機能がサポートされているとカーネルに通知する奇妙なドライブに遭遇することがありますが、実際にはサポートされていないか、機能が常に動作するとは限りません。 現時点では、サポートはほぼどこでも利用できますが、古いドライブやファームウェアにはエラーが発生しています。 このため、RAID 6 では DISCARD サポートはデフォルトで無効になっています。

次のコマンドは、アレイを「ゼロ」で「初期化」することにより、NVMe ドライブ上のすべてのデータを破壊することに注意してください。

#blkdiscard /dev/md0

何か問題が発生した場合は、ステップを指定してみてください。

#blkdiscard --step 65536 /dev/md0

SATA SSD

#mdadm --create --verbose --assume-clean /dev/md1 --level=1 --raid-devices=6 /dev/sd[a-f]1
#blkdiscard /dev/md1
#mdadm --create --verbose --assume-clean /dev/md2 --chunk-size=512 --level=6 --raid-devices=6 /dev/sd[a-f]2

なぜこんなに大きいのか…？チャンク サイズを増やすと、チャンク サイズまでのブロックでのランダム読み取りの速度にプラスの効果があります。 これは、適切なサイズ以下の 99 つの操作が単一のデバイス上で完全に完了できるために発生します。 したがって、すべてのデバイスからの IOPS が合計されます。 統計によると、IO の 512% は XNUMXK を超えません。

書き込みあたりの RAID 6 IOPS 常に XNUMX つのドライブの IOPS 以下です。 ランダム読み取りの場合、IOPS が XNUMX 台のドライブの IOPS よりも数倍大きくなる可能性があり、ここではブロック サイズが重要になります。
著者は、設計上 RAID 6 で苦手なパラメータを最適化しようとする意味を理解しておらず、代わりに RAID 6 が得意とするパラメータを最適化しています。
NVMe キャッシュとシンプロビジョニングのトリックで、RAID 6 の貧弱なランダム書き込みを補います。

RAID 6 の DISCARD をまだ有効にしていないため、現時点ではこのアレイを「初期化」しません。 これは、OS をインストールした後で行います。

SATA HDD

#mdadm --create --verbose --assume-clean /dev/md3 --chunk-size=512 --level=6 --raid-devices=8 /dev/sd[g-n]1

NVMe RAID 上の LVM

速度を高めるために、ルート ファイル システムを NVMe RAID 1 (/dev/md0) に配置します。
ただし、スワップ、メタデータ、LVM キャッシュおよび LVM シン メタデータなどの他のニーズにはこの高速アレイが依然として必要となるため、このアレイ上に LVM VG を作成します。

#pvcreate /dev/md0
#vgcreate root /dev/md0

ルート ファイル システムのパーティションを作成しましょう。

#lvcreate -L 128G --name root root

RAMのサイズに応じてスワップ用のパーティションを作成しましょう。

#lvcreate -L 32G --name swap root

OSのインストール

合計すると、システムのインストールに必要なものがすべて揃っています。

Ubuntu Live 環境からシステム インストール ウィザードを起動します。 通常のインストール。 インストールするディスクを選択する段階でのみ、以下を指定する必要があります。

• /dev/md1、 - マウントポイント /boot、FS - BTRFS
• /dev/root/root (別名 /dev/mapper/root-root)、 - マウント ポイント / (ルート)、FS - BTRFS
• /dev/root/swap (別名 /dev/mapper/root-swap) - スワップ パーティションとして使用します
• ブートローダーを /dev/sda にインストールします

ルート ファイル システムとして BTRFS を選択すると、インストーラーは / (ルート) を表す「@」と /home を表す「@home」という名前の XNUMX つの BTRFS ボリュームを自動的に作成します。

インストールを開始しましょう...

インストールは終了し、ブートローダーのインストール中にエラーが発生したことを示すモーダル ダイアログ ボックスが表示されます。 残念ながら、標準的な方法ではこのダイアログを終了してインストールを続行することはできません。 システムからログアウトして再度ログインすると、最終的にはクリーンな Ubuntu Live デスクトップが表示されます。 ターミナルを開き、もう一度次のようにします。

#sudo bash

インストールを続行するには、chroot 環境を作成します。

#mkdir /mnt/chroot
#mount -o defaults,space_cache,noatime,nodiratime,discard,subvol=@ /dev/mapper/root-root /mnt/chroot
#mount -o defaults,space_cache,noatime,nodiratime,discard,subvol=@home /dev/mapper/root-root /mnt/chroot/home
#mount -o defaults,space_cache,noatime,nodiratime,discard /dev/md1 /mnt/chroot/boot
#mount --bind /proc /mnt/chroot/proc
#mount --bind /sys /mnt/chroot/sys
#mount --bind /dev /mnt/chroot/dev

chroot でネットワークとホスト名を設定しましょう。

#cat /etc/hostname >/mnt/chroot/etc/hostname
#cat /etc/hosts >/mnt/chroot/etc/hosts
#cat /etc/resolv.conf >/mnt/chroot/etc/resolv.conf

chroot 環境に入ってみましょう。

#chroot /mnt/chroot

まず、パッケージを配送します。

apt-get install --reinstall mdadm lvm2 thin-provisioning-tools btrfs-tools util-linux lsscsi nvme-cli mc debsums hdparm

システムのインストールが不完全なために誤ってインストールされたすべてのパッケージを確認して修正してみましょう。

#CORRUPTED_PACKAGES=$(debsums -s 2>&1 | awk '{print $6}' | uniq)
#apt-get install --reinstall $CORRUPTED_PACKAGES

何かがうまくいかない場合は、最初に /etc/apt/sources.list を編集する必要があるかもしれません。

TRIM/DISCARD を有効にするために RAID 6 モジュールのパラメータを調整しましょう。

#cat >/etc/modprobe.d/raid456.conf << EOF
options raid456 devices_handle_discard_safely=1
EOF

配列を少し調整してみましょう。

#cat >/etc/udev/rules.d/60-md.rules << EOF
SUBSYSTEM=="block", KERNEL=="md*", ACTION=="change", TEST=="md/stripe_cache_size", ATTR{md/stripe_cache_size}="32768"
SUBSYSTEM=="block", KERNEL=="md*", ACTION=="change", TEST=="md/sync_speed_min", ATTR{md/sync_speed_min}="48000"
SUBSYSTEM=="block", KERNEL=="md*", ACTION=="change", TEST=="md/sync_speed_max", ATTR{md/sync_speed_max}="300000"
EOF
#cat >/etc/udev/rules.d/62-hdparm.rules << EOF
SUBSYSTEM=="block", ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", RUN+="/sbin/hdparm -B 254 /dev/%k"
EOF
#cat >/etc/udev/rules.d/63-blockdev.rules << EOF
SUBSYSTEM=="block", ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", RUN+="/sbin/blockdev --setra 1024 /dev/%k"
SUBSYSTEM=="block", ACTION=="add|change", KERNEL=="md*", RUN+="/sbin/blockdev --setra 0 /dev/%k"
EOF

それが何だった..？以下を実行する一連の udev ルールを作成しました。

• RAID 2020 のブロック キャッシュ サイズを 6 年に適切な値に設定します。デフォルト値は、Linux の作成以来変更されていないようで、長い間適切ではありませんでした。
• アレイのチェック/同期の間、最小限の IO を予約します。 これは、アレイが負荷の下で永遠の同期状態に陥るのを防ぐためです。
• アレイのチェック/同期中の最大 IO を制限します。 これは、SSD RAID の同期/チェックによってドライブがパンクしないようにするために必要です。 これは特に NVMe に当てはまります。 (ラジエーターのことを覚えていますか?冗談ではありません。)
• APM を介してディスクがスピンドル回転 (HDD) を停止することを禁止し、ディスク コントローラーのスリープ タイムアウトを 7 時間に設定します。 ドライブで APM が可能な場合は、APM を完全に無効にすることができます (-B 255)。 デフォルト値では、ドライブは XNUMX 秒後に停止します。 その後、OS はディスク キャッシュをリセットしようとし、ディスクが再び回転し、すべてが最初からやり直しになります。 ディスクにはスピンドルの最大回転数が制限されています。 このような単純なデフォルト サイクルでは、数年でディスクが簡単に壊れてしまう可能性があります。 すべてのディスクがこの問題に悩まされるわけではありませんが、私たちのディスクは「ラップトップ」ディスクであり、適切なデフォルト設定があり、RAID がミニ MAID のように見えます。
• ディスク (回転) 1 メガバイトに先読みをインストール - 6 つの連続ブロック/チャンク RAID XNUMX
• アレイ自体の先読みを無効にします。

/etc/fstab を編集しましょう。

#cat >/etc/fstab << EOF
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
# file-system mount-point type options dump pass
/dev/mapper/root-root / btrfs defaults,space_cache,noatime,nodiratime,discard,subvol=@ 0 1
UUID=$(blkid -o value -s UUID /dev/md1) /boot btrfs defaults,space_cache,noatime,nodiratime,discard 0 2
/dev/mapper/root-root /home btrfs defaults,space_cache,noatime,nodiratime,discard,subvol=@home 0 2
/dev/mapper/root-swap none swap sw 0 0
EOF
何故ですか..？/boot パーティションを UUID で検索します。 配列の名前は理論的には変更される可能性があります。

残りのセクションは、/dev/mapper/vg-lv 表記の LVM 名で検索します。 これらはパーティションを非常に一意に識別します。

LVM には UUID を使用しません。 LVM ボリュームとそのスナップショットの UUID は同じであってもかまいません。/dev/mapper/root-root.. を XNUMX 回マウントしますか?はい。 その通り。 BTRFSの特徴。 このファイル システムは、異なるサブボリュームを使用して複数回マウントできます。

これと同じ機能のため、アクティブな BTRFS ボリュームの LVM スナップショットを作成しないことをお勧めします。 再起動すると驚くかもしれません。

mdadm 構成を再生成しましょう。

#/usr/share/mdadm/mkconf | sed 's/#DEVICE/DEVICE/g' >/etc/mdadm/mdadm.conf

LVM 設定を調整しましょう。

#cat >>/etc/lvm/lvmlocal.conf << EOF

activation {
thin_pool_autoextend_threshold=90
thin_pool_autoextend_percent=5
}
allocation {
cache_pool_max_chunks=2097152
}
devices {
global_filter=["r|^/dev/.*_corig$|","r|^/dev/.*_cdata$|","r|^/dev/.*_cmeta$|","r|^/dev/.*gpv$|","r|^/dev/images/.*$|","r|^/dev/mapper/images.*$|","r|^/dev/backup/.*$|","r|^/dev/mapper/backup.*$|"] issue_discards=1
}
EOF

それが何だった..？占有スペースの 90%、ボリュームの 5% に達すると、LVM シン プールの自動拡張が可能になりました。

LVM キャッシュのキャッシュ ブロックの最大数が増加しました。

LVM が以下の LVM ボリューム (PV) を検索できないようにしました。

• LVM キャッシュ (cdata) を含むデバイス
• LVM キャッシュを使用してキャッシュされたデバイスは、キャッシュをバイパスします ( _コリグ）。 この場合、キャッシュされたデバイス自体は引き続きキャッシュを通じてスキャンされます（単に）。
• LVM キャッシュ メタデータ (cmeta) を含むデバイス
• VG 内のイメージという名前のすべてのデバイス。 ここでは仮想マシンのディスク イメージを使用しますが、ホスト上の LVM がゲスト OS に属するボリュームをアクティブ化する必要はありません。
• VG 内のバックアップという名前のすべてのデバイス。 ここでは、仮想マシン イメージのバックアップ コピーを作成します。
• 名前が「gpv」で終わるすべてのデバイス (ゲスト物理ボリューム)

LVM VG の空き領域を解放するときに DISCARD サポートを有効にしました。 気をつけて。 これにより、SSD 上の LV の削除に非常に時間がかかります。 これは特に SSD RAID 6 に当てはまります。ただし、計画によれば、シン プロビジョニングを使用する予定ですので、これはまったく支障はありません。

initramfs イメージを更新しましょう。

#update-initramfs -u -k all

grub をインストールして構成します。

#apt-get install grub-pc
#apt-get purge os-prober
#dpkg-reconfigure grub-pc

どのディスクを選択すればよいでしょうか?SD*な皆さん。 システムは、動作している SATA ドライブまたは SSD から起動できる必要があります。

なぜ os-prober を追加したのでしょうか?過度の独立性と遊び心のある手のために。

RAID の XNUMX つが劣化状態にある場合、正しく動作しません。 このハードウェア上で実行されている仮想マシンで使用されているパーティション上の OS を検索しようとします。

必要な場合はそのままにしておいても構いませんが、上記のすべてに留意してください。 いたずら手を取り除くためのレシピをオンラインで探すことをお勧めします。

これで初期インストールが完了しました。 新しくインストールした OS で再起動します。 ブータブル Live CD/USB を忘れずに取り外してください。

#exit
#reboot

いずれかの SATA SSD をブート デバイスとして選択します。

SATA SSD 上の LVM

この時点で、すでに新しい OS を起動し、ネットワークと apt を設定し、ターミナル エミュレーターを開いて次のコマンドを実行しています。

#sudo bash

続けます。

SATA SSD からアレイを「初期化」します。

#blkdiscard /dev/md2

うまくいかない場合は、次のことを試してください。

#blkdiscard --step 65536 /dev/md2
SATA SSD 上に LVM VG を作成します。

#pvcreate /dev/md2
#vgcreate data /dev/md2

なぜ別の VG が...?実際、root という名前の VG がすでにあります。 すべてを XNUMX つの VG に追加してみませんか?

VG 内に複数の PV がある場合、VG が正しくアクティブ化されるためには、すべての PV が存在する (オンライン) 必要があります。 例外は LVM RAID ですが、これは意図的に使用しません。

RAID 6 アレイのいずれかで障害 (読み取りデータの損失) が発生した場合、オペレーティング システムが通常どおり起動し、問題を解決する機会が与えられることが本当に望ましいのです。

これを行うために、抽象化の最初のレベルで、各タイプの物理「メディア」を個別の VG に分離します。

科学的に言えば、異なる RAID アレイは異なる「信頼性ドメイン」に属します。 XNUMX つの VG にそれらを詰め込んで、さらに共通の障害点を作成すべきではありません。

「ハードウェア」レベルでの LVM の存在により、さまざまな方法で組み合わせることにより、さまざまな RAID アレイの断片を任意に切り出すことができます。 たとえば、実行します 同時に bcache + LVM Thin、bcache + BTRFS、LVM キャッシュ + LVM Thin、キャッシュを備えた複雑な ZFS 構成、またはその他の地獄のような組み合わせをすべて試して比較します。

「ハードウェア」レベルでは、古き良き「シック」LVM ボリューム以外は使用しません。 この規則の例外は、バックアップ パーティションである場合があります。

この時点で、多くの読者はすでに入れ子人形について何かを疑い始めていたと思います。

SATA HDD 上の LVM

#pvcreate /dev/md3
#vgcreate backup /dev/md3

また新しいVG…？データのバックアップに使用するディスク アレイに障害が発生した場合でも、バックアップ以外のデータへのアクセスを通常どおり維持しながら、オペレーティング システムが正常に動作し続けることを本当に望んでいます。 したがって、VG アクティベーションの問題を回避するために、別の VG を作成します。

LVMキャッシュの設定

NVMe RAID 1 上に LV を作成して、キャッシュ デバイスとして使用しましょう。

#lvcreate -L 70871154688B --name cache root

なんでこんなに少ないんだろう…？実際、当社の NVMe SSD には SLC キャッシュも搭載されています。 4 ビット MLC で占有される空きスペースにより、18 ギガバイトの「フリー」スペースと 3 ギガバイトのダイナミック スペースが発生します。 このキャッシュが使い果たされると、NVMe SSD はキャッシュ付きの SATA SSD よりもそれほど高速ではなくなります。 実際には、このような理由から、LVM キャッシュ パーティションを NVMe ドライブの SLC キャッシュのサイズの 32 倍より大きくすることは意味がありません。 使用する NVMe ドライブについては、64 ～ XNUMX GB のキャッシュを作成するのが妥当であると著者は考えています。

64 GB のキャッシュ、キャッシュ メタデータ、およびメタデータ バックアップを編成するには、指定されたパーティション サイズが必要です。

さらに、ダーティ システムのシャットダウン後、LVM はキャッシュ全体をダーティとしてマークし、再度同期することに注意してください。 さらに、システムが再度リブートされるまで、このデバイスで lvchange が使用されるたびにこれが繰り返されます。 したがって、適切なスクリプトを使用してキャッシュをすぐに再作成することをお勧めします。

SATA RAID 6 上に LV を作成して、キャッシュされたデバイスとして使用しましょう。

#lvcreate -L 3298543271936B --name cache data

なぜ XNUMX テラバイトしかないのですか?そのため、必要に応じて、他のニーズに SATA SSD RAID 6 を使用できます。 キャッシュされたスペースのサイズは、システムを停止することなく、その場で動的に増加できます。 これを行うには、キャッシュを一時的に停止して再度有効にする必要がありますが、たとえば bcache に対する LVM キャッシュの際立った利点は、これを実行中に実行できることです。

キャッシュ用の新しい VG を作成しましょう。

#pvcreate /dev/root/cache
#pvcreate /dev/data/cache
#vgcreate cache /dev/root/cache /dev/data/cache

キャッシュされたデバイス上に LV を作成しましょう。

#lvcreate -L 3298539077632B --name cachedata cache /dev/data/cache

ここでは、/dev/data/cache 上のすべての空きスペースを即座に使用し、他のすべての必要なパーティションが /dev/root/cache 上に即座に作成されるようにしました。 間違った場所に何かを作成した場合は、pvmove を使用して移動できます。

キャッシュを作成して有効にしてみましょう。

#lvcreate -y -L 64G -n cache cache /dev/root/cache
#lvcreate -y -L 1G -n cachemeta cache /dev/root/cache
#lvconvert -y --type cache-pool --cachemode writeback --chunksize 64k --poolmetadata cache/cachemeta cache/cache
#lvconvert -y --type cache --cachepool cache/cache cache/cachedata

なぜそのようなチャンクサイズ...?実際の実験を通じて、著者は、LVM キャッシュ ブロックのサイズが LVM シン ブロックのサイズと一致する場合に最良の結果が得られることを発見することができました。 さらに、サイズが小さいほど、構成のランダム記録でのパフォーマンスが向上します。

64k は、LVM Thin に許可される最小ブロック サイズです。

ライトバックには注意してください...!はい。 このタイプのキャッシュでは、キャッシュされたデバイスへの書き込み同期が延期されます。 つまり、キャッシュが失われると、キャッシュされたデバイス上のデータが失われる可能性があります。 このリスクを補うために、NVMe RAID 1 以外にどのような対策を講じることができるかについては、後ほど説明します。

このキャッシュ タイプは、RAID 6 の貧弱なランダム書き込みパフォーマンスを補うために意図的に選択されました。

何が得られたかを確認してみましょう:

#lvs -a -o lv_name,lv_size,devices --units B cache
LV LSize Devices
[cache] 68719476736B cache_cdata(0)
[cache_cdata] 68719476736B /dev/root/cache(0)
[cache_cmeta] 1073741824B /dev/root/cache(16384)
cachedata 3298539077632B cachedata_corig(0)
[cachedata_corig] 3298539077632B /dev/data/cache(0)
[lvol0_pmspare] 1073741824B /dev/root/cache(16640)

[cachedata_corig] のみを /dev/data/cache に配置する必要があります。 何か問題がある場合は、pvmove を使用してください。

必要に応じて、XNUMX つのコマンドでキャッシュを無効にすることができます。

#lvconvert -y --uncache cache/cachedata

これはオンラインで行われます。 LVM は単純にキャッシュをディスクに同期して削除し、cachedata_corig の名前を cachedata に戻します。

LVM シンのセットアップ

LVM シン メタデータに必要なスペースを大まかに見積もってみましょう。

#thin_metadata_size --block-size=64k --pool-size=6terabytes --max-thins=100000 -u bytes
thin_metadata_size - 3385794560 bytes estimated metadata area size for "--block-size=64kibibytes --pool-size=6terabytes --max-thins=100000"

4 ギガバイトに切り上げ: 4294967296B

LVM PV メタデータの場合、4194304 を掛けて 8594128896B を追加します: XNUMXB
NVMe RAID 1 上に別のパーティションを作成して、LVM シン メタデータとそのバックアップ コピーをそこに配置しましょう。

#lvcreate -L 8594128896B --name images root

何のために..？ここで、LVM シン メタデータが NVMe にキャッシュされて高速に動作するのに、なぜ LVM シン メタデータを別に配置する必要があるのか​​という疑問が生じるかもしれません。

ここでは速度が重要ですが、それは主な理由からは程遠いです。 問題は、キャッシュが障害点になるということです。 何かが起こった可能性があり、LVM シン メタデータがキャッシュされている場合、すべてが完全に失われます。 完全なメタデータがなければ、シン ボリュームを組み立てることはほぼ不可能になります。

メタデータを別の非キャッシュの高速ボリュームに移動することで、キャッシュの損失や破損が発生した場合でもメタデータの安全性が保証されます。 この場合、キャッシュ損失によって引き起こされるすべての損傷はシン ボリューム内で局所的に発生するため、回復手順が大幅に簡素化されます。 高い確率で、これらの損傷は FS ログを使用して復元されます。

さらに、シン ボリュームのスナップショットが以前に作成されており、その後キャッシュが少なくとも XNUMX 回完全に同期されている場合、LVM シンの内部設計により、キャッシュが失われた場合でもスナップショットの整合性が保証されます。 。

シンプロビジョニングを担当する新しい VG を作成しましょう。

#pvcreate /dev/root/images
#pvcreate /dev/cache/cachedata
#vgcreate images /dev/root/images /dev/cache/cachedata
プールを作成しましょう。

#lvcreate -L 274877906944B --poolmetadataspare y --poolmetadatasize 4294967296B --chunksize 64k -Z y -T images/thin-pool
なぜ -Z yこのモードの実際の目的 (スペースを再配分するときに、ある仮想マシンからのデータが別の仮想マシンに漏洩するのを防ぐこと) に加えて、ゼロ化は、64k 未満のブロックでのランダム書き込みの速度を上げるためにさらに使用されます。 シン ボリュームの以前に割り当てられていない領域への 64K 未満の書き込みは、キャッシュ内で 64K のエッジに揃えられます。 これにより、キャッシュされたデバイスをバイパスし、キャッシュを通じて操作を完全に実行できるようになります。

LV を対応する PV に移動しましょう。

#pvmove -n images/thin-pool_tdata /dev/root/images /dev/cache/cachedata
#pvmove -n images/lvol0_pmspare /dev/cache/cachedata /dev/root/images
#pvmove -n images/thin-pool_tmeta /dev/cache/cachedata /dev/root/images

小切手：

#lvs -a -o lv_name,lv_size,devices --units B images
LV LSize Devices
[lvol0_pmspare] 4294967296B /dev/root/images(0)
thin-pool 274877906944B thin-pool_tdata(0)
[thin-pool_tdata] 274877906944B /dev/cache/cachedata(0)
[thin-pool_tmeta] 4294967296B /dev/root/images(1024)

テスト用のシン ボリュームを作成しましょう。

#lvcreate -V 64G --thin-pool thin-pool --name test images

テストと監視用のパッケージをインストールします。

#apt-get install sysstat fio

これは、ストレージ構成の動作をリアルタイムで観察する方法です。

#watch 'lvs --rows --reportformat basic --quiet -ocache_dirty_blocks,cache_settings cache/cachedata && (lvdisplay cache/cachedata | grep Cache) && (sar -p -d 2 1 | grep -E "sd|nvme|DEV|md1|md2|md3|md0" | grep -v Average | sort)'

構成をテストする方法は次のとおりです。

#fio --loops=1 --size=64G --runtime=4 --filename=/dev/images/test --stonewall --ioengine=libaio --direct=1
--name=4kQD32read --bs=4k --iodepth=32 --rw=randread
--name=8kQD32read --bs=8k --iodepth=32 --rw=randread
--name=16kQD32read --bs=16k --iodepth=32 --rw=randread
--name=32KQD32read --bs=32k --iodepth=32 --rw=randread
--name=64KQD32read --bs=64k --iodepth=32 --rw=randread
--name=128KQD32read --bs=128k --iodepth=32 --rw=randread
--name=256KQD32read --bs=256k --iodepth=32 --rw=randread
--name=512KQD32read --bs=512k --iodepth=32 --rw=randread
--name=4Kread --bs=4k --rw=read
--name=8Kread --bs=8k --rw=read
--name=16Kread --bs=16k --rw=read
--name=32Kread --bs=32k --rw=read
--name=64Kread --bs=64k --rw=read
--name=128Kread --bs=128k --rw=read
--name=256Kread --bs=256k --rw=read
--name=512Kread --bs=512k --rw=read
--name=Seqread --bs=1m --rw=read
--name=Longread --bs=8m --rw=read
--name=Longwrite --bs=8m --rw=write
--name=Seqwrite --bs=1m --rw=write
--name=512Kwrite --bs=512k --rw=write
--name=256write --bs=256k --rw=write
--name=128write --bs=128k --rw=write
--name=64write --bs=64k --rw=write
--name=32write --bs=32k --rw=write
--name=16write --bs=16k --rw=write
--name=8write --bs=8k --rw=write
--name=4write --bs=4k --rw=write
--name=512KQD32write --bs=512k --iodepth=32 --rw=randwrite
--name=256KQD32write --bs=256k --iodepth=32 --rw=randwrite
--name=128KQD32write --bs=128k --iodepth=32 --rw=randwrite
--name=64KQD32write --bs=64k --iodepth=32 --rw=randwrite
--name=32KQD32write --bs=32k --iodepth=32 --rw=randwrite
--name=16KQD32write --bs=16k --iodepth=32 --rw=randwrite
--name=8KQD32write --bs=8k --iodepth=32 --rw=randwrite
--name=4kQD32write --bs=4k --iodepth=32 --rw=randwrite
| grep -E 'read|write|test' | grep -v ioengine

気をつけて！ リソース！このコードは 36 の異なるテストを実行し、それぞれのテストを 4 秒間実行します。 テストの半分は記録用です。 NVMe では 4 秒で大量の録画が可能です。 毎秒最大 3 ギガバイト。 したがって、書き込みテストを実行するたびに、最大 216 GB の SSD リソースが消費される可能性があります。

読み書きが混在していますか？はい。 読み取りテストと書き込みテストを別々に実行するのが合理的です。 さらに、以前に行われた書き込みが読み取りに影響しないように、すべてのキャッシュが同期されていることを確認することは理にかなっています。

結果は、最初の起動時とその後の起動時にキャッシュとシン ボリュームがいっぱいになるにつれて大きく異なります。また、システムが最後の起動時にいっぱいになったキャッシュを同期できたかどうかによっても異なります。

とりわけ、スナップショットを作成したばかりの、すでにいっぱいになっているシン ボリュームの速度を測定することをお勧めします。 著者は、最初のスナップショットを作成した直後、特にキャッシュがまだ完全にいっぱいになっていないときに、ランダム書き込みがどのように急激に加速するかを観察する機会がありました。 これは、コピーオンライト書き込みセマンティクス、キャッシュとシン ボリューム ブロックの配置、および RAID 6 へのランダム書き込みが RAID 6 からのランダム読み取りとその後のキャッシュへの書き込みに変わるという事実により発生します。 この構成では、RAID 6 からのランダム読み取りは書き込みよりも最大 6 倍 (アレイ内の SATA SSD の数) 高速です。 なぜならCoW のブロックはシン プールから順番に割り当てられ、記録もほとんどの場合順次になります。

これらの機能は両方とも有利に使用できます。

「一貫性のある」スナップショットをキャッシュする

キャッシュの損傷/損失が発生した場合のデータ損失のリスクを軽減するために、著者は、この場合にスナップショットをローテーションして整合性を保証する方法を導入することを提案しています。

まず、シン ボリュームのメタデータはキャッシュされていないデバイス上に存在するため、メタデータの一貫性が保たれ、損失の可能性はデータ ブロック内で分離されます。

次のスナップショット ローテーション サイクルにより、キャッシュ損失が発生した場合にスナップショット内のデータの整合性が保証されます。

1. <name> という名前のシン ボリュームごとに、<name>.cached という名前のスナップショットを作成します。
2. 移行のしきい値を適切な高い値に設定しましょう。 #lvchange --quiet --cachesettings "migration_threshold=16384" cache/cachedata
3. ループ内で、キャッシュ内のダーティ ブロックの数をチェックします。 #lvs --rows --reportformat basic --quiet -ocache_dirty_blocks cache/cachedata | awk '{print $2}' ゼロになるまで。 ゼロが長期間欠落している場合は、キャッシュを一時的にライトスルー モードに切り替えることでゼロを作成できます。 ただし、SATA および NVMe SSD アレイの速度特性とその TBW リソースを考慮すると、キャッシュ モードを変更せずにその瞬間を素早く捉えることができるか、ハードウェアがそのリソース全体を完全に消費してしまうかのどちらかになります。数日。 リソースの制限により、システムは原則として、常に 100% の書き込み負荷を下回ることができません。 当社の NVMe SSD は 100% の書き込み負荷にさらされると、リソースを完全に使い果たしてしまいます。 3-4日。 SATA SSD は XNUMX 倍しか寿命がありません。 したがって、負荷の大部分が読み取りに当てられ、比較的短期間の非常に高いアクティビティと書き込みの平均負荷の低さのバーストが発生すると仮定します。
4. ゼロをキャッチ (またはゼロを作成) したらすぐに、<name>.cached の名前を <name>.committed に変更します。 古い <name>.committed は削除されます。
5. オプションで、キャッシュが 100% いっぱいの場合は、スクリプトによってキャッシュを再作成し、キャッシュをクリアできます。 キャッシュが半分空の場合、システムは書き込み時にはるかに高速に動作します。
6. 移行しきい値をゼロに設定します。 #lvchange --quiet --cachesettings "migration_threshold=0" cache/cachedata これにより、キャッシュがメイン メディアと一時的に同期できなくなります。
7. かなり多くの変更がキャッシュに蓄積されるまで待機します #lvs --rows --reportformat basic --quiet -ocache_dirty_blocks cache/cachedata | awk '{print $2}' またはタイマーがオフになります。
8. もう一度繰り返します。

移行しきい値が難しいのはなぜですか...?実際には、「ランダム」録音は完全にランダムではないということです。 サイズが 4 キロバイトのセクターに何かを書き込んだ場合、次の数分以内に、同じセクターまたは隣接する (+- 32K) セクターの XNUMX つにレコードが作成される可能性が高くなります。

移行しきい値をゼロに設定することで、SATA SSD での書き込み同期を延期し、いくつかの変更をキャッシュ内の 64 つの XNUMXK ブロックに集約します。 これにより、SATA SSD のリソースが大幅に節約されます。

コードはどこにありますか?残念ながら、著者は 100% 独学で「Google」主導の開発を実践しているため、bash スクリプトの開発能力が不十分であると考えており、そのため、自分の手から生み出されたひどいコードは誰にも使用されるべきではないと考えています。それ以外。

この分野の専門家であれば、必要に応じて上記のロジックをすべて独立して表現でき、おそらく著者が試みたように、システム化されたサービスとして美しく設計することもできると思います。

このようなシンプルなスナップショット ローテーション スキームにより、XNUMX つのスナップショットを常に SATA SSD 上で完全に同期させることができるだけでなく、thin_delta ユーティリティを使用して、作成後にどのブロックが変更されたかを見つけて、損傷を局所的に特定することもできます。メイン ボリュームが削除され、リカバリが大幅に簡素化されます。

libvirt/KVM での TRIM/DISCARD

なぜならデータ ストレージは libvirt を実行する KVM に使用されるため、空き領域を占有するだけでなく、不要になったものを解放するように VM に教えることをお勧めします。

これは、仮想ディスク上で TRIM/DISCARD サポートをエミュレートすることによって行われます。 これを行うには、コントローラーのタイプを virtio-scsi に変更し、xml を編集する必要があります。

#virsh edit vmname
<disk type='block' device='disk'>
<driver name='qemu' type='raw' cache='writethrough' io='threads' discard='unmap'/>
<source dev='/dev/images/vmname'/>
<backingStore/>
<target dev='sda' bus='scsi'/>
<alias name='scsi0-0-0-0'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>

<controller type='scsi' index='0' model='virtio-scsi'>
<alias name='scsi0'/>
<address type='pci' domain='0x0000' bus='0x04' slot='0x00' function='0x0'/>
</controller>

ゲスト OS からのこのような DISCARD は LVM によって正しく処理され、ブロックはキャッシュとシン プールの両方で正しく解放されます。 私たちの場合、これは主に次のスナップショットを削除するときに遅延して発生します。

BTRFSバックアップ

既製のスクリプトを使用して、 крайней 注意と 自己責任で。 このコードは作者が自分自身のために、そして自分のためだけに書きました。 経験豊富な Linux ユーザーの多くが同様のツールを持っていると思います。他の人のツールをコピーする必要はありません。

バックアップ デバイス上にボリュームを作成しましょう。

#lvcreate -L 256G --name backup backup

BTRFS でフォ​​ーマットしましょう。

#mkfs.btrfs /dev/backup/backup

マウント ポイントを作成し、ファイル システムのルート サブセクションをマウントしましょう。

#mkdir /backup
#mkdir /backup/btrfs
#mkdir /backup/btrfs/root
#mkdir /backup/btrfs/back
#ln -s /boot /backup/btrfs
# cat >>/etc/fstab << EOF

/dev/mapper/root-root /backup/btrfs/root btrfs defaults,space_cache,noatime,nodiratime 0 2
/dev/mapper/backup-backup /backup/btrfs/back btrfs defaults,space_cache,noatime,nodiratime 0 2
EOF
#mount -a
#update-initramfs -u
#update-grub

バックアップ用のディレクトリを作成しましょう。

#mkdir /backup/btrfs/back/remote
#mkdir /backup/btrfs/back/remote/root
#mkdir /backup/btrfs/back/remote/boot

バックアップ スクリプト用のディレクトリを作成しましょう。

#mkdir /root/btrfs-backup

スクリプトをコピーしましょう。

恐ろしいbashコードがたくさんあります。 自己責任。 著者に怒りの手紙を書かないでください...#cat >/root/btrfs-backup/btrfs-backup.sh << EOF
#!/bin/bash
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

SCRIPT_FILE="$(realpath $0)"
SCRIPT_DIR="$(dirname $SCRIPT_FILE)"
SCRIPT_NAME="$(basename -s .sh $SCRIPT_FILE)"

LOCK_FILE="/dev/shm/$SCRIPT_NAME.lock"
DATE_PREFIX='%Y-%m-%d'
DATE_FORMAT=$DATE_PREFIX'-%H-%M-%S'
DATE_REGEX='[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]'
BASE_SUFFIX=".@base"
PEND_SUFFIX=".@pend"
SNAP_SUFFIX=".@snap"
MOUNTS="/backup/btrfs/"
BACKUPS="/backup/btrfs/back/remote/"

function terminate ()
{
echo "$1" >&2
exit 1
}

function wait_lock()
{
flock 98
}

function wait_lock_or_terminate()
{
echo "Wating for lock..."
wait_lock || terminate "Failed to get lock. Exiting..."
echo "Got lock..."
}

function suffix()
{
FORMATTED_DATE=$(date +"$DATE_FORMAT")
echo "$SNAP_SUFFIX.$FORMATTED_DATE"
}

function filter()
{
FORMATTED_DATE=$(date --date="$1" +"$DATE_PREFIX")
echo "$SNAP_SUFFIX.$FORMATTED_DATE"
}

function backup()
{
SOURCE_PATH="$MOUNTS$1"
TARGET_PATH="$BACKUPS$1"
SOURCE_BASE_PATH="$MOUNTS$1$BASE_SUFFIX"
TARGET_BASE_PATH="$BACKUPS$1$BASE_SUFFIX"
TARGET_BASE_DIR="$(dirname $TARGET_BASE_PATH)"
SOURCE_PEND_PATH="$MOUNTS$1$PEND_SUFFIX"
TARGET_PEND_PATH="$BACKUPS$1$PEND_SUFFIX"
if [ -d "$SOURCE_BASE_PATH" ] then
echo "$SOURCE_BASE_PATH found"
else
echo "$SOURCE_BASE_PATH File not found creating snapshot of $SOURCE_PATH to $SOURCE_BASE_PATH"
btrfs subvolume snapshot -r $SOURCE_PATH $SOURCE_BASE_PATH
sync
if [ -d "$TARGET_BASE_PATH" ] then
echo "$TARGET_BASE_PATH found out of sync with source... removing..."
btrfs subvolume delete -c $TARGET_BASE_PATH
sync
fi
fi
if [ -d "$TARGET_BASE_PATH" ] then
echo "$TARGET_BASE_PATH found"
else
echo "$TARGET_BASE_PATH not found. Synching to $TARGET_BASE_DIR"
btrfs send $SOURCE_BASE_PATH | btrfs receive $TARGET_BASE_DIR
sync
fi
if [ -d "$SOURCE_PEND_PATH" ] then
echo "$SOURCE_PEND_PATH found removing..."
btrfs subvolume delete -c $SOURCE_PEND_PATH
sync
fi
btrfs subvolume snapshot -r $SOURCE_PATH $SOURCE_PEND_PATH
sync
if [ -d "$TARGET_PEND_PATH" ] then
echo "$TARGET_PEND_PATH found removing..."
btrfs subvolume delete -c $TARGET_PEND_PATH
sync
fi
echo "Sending $SOURCE_PEND_PATH to $TARGET_PEND_PATH"
btrfs send -p $SOURCE_BASE_PATH $SOURCE_PEND_PATH | btrfs receive $TARGET_BASE_DIR
sync
TARGET_DATE_SUFFIX=$(suffix)
btrfs subvolume snapshot -r $TARGET_PEND_PATH "$TARGET_PATH$TARGET_DATE_SUFFIX"
sync
btrfs subvolume delete -c $SOURCE_BASE_PATH
sync
btrfs subvolume delete -c $TARGET_BASE_PATH
sync
mv $SOURCE_PEND_PATH $SOURCE_BASE_PATH
mv $TARGET_PEND_PATH $TARGET_BASE_PATH
sync
}

function list()
{
LIST_TARGET_BASE_PATH="$BACKUPS$1$BASE_SUFFIX"
LIST_TARGET_BASE_DIR="$(dirname $LIST_TARGET_BASE_PATH)"
LIST_TARGET_BASE_NAME="$(basename -s .$BASE_SUFFIX $LIST_TARGET_BASE_PATH)"
find "$LIST_TARGET_BASE_DIR" -maxdepth 1 -mindepth 1 -type d -printf "%fn" | grep "${LIST_TARGET_BASE_NAME/$BASE_SUFFIX/$SNAP_SUFFIX}.$DATE_REGEX"
}

function remove()
{
REMOVE_TARGET_BASE_PATH="$BACKUPS$1$BASE_SUFFIX"
REMOVE_TARGET_BASE_DIR="$(dirname $REMOVE_TARGET_BASE_PATH)"
btrfs subvolume delete -c $REMOVE_TARGET_BASE_DIR/$2
sync
}

function removeall()
{
DATE_OFFSET="$2"
FILTER="$(filter "$DATE_OFFSET")"
while read -r SNAPSHOT ; do
remove "$1" "$SNAPSHOT"
done < <(list "$1" | grep "$FILTER")

}

(
COMMAND="$1"
shift

case "$COMMAND" in
"--help")
echo "Help"
;;
"suffix")
suffix
;;
"filter")
filter "$1"
;;
"backup")
wait_lock_or_terminate
backup "$1"
;;
"list")
list "$1"
;;
"remove")
wait_lock_or_terminate
remove "$1" "$2"
;;
"removeall")
wait_lock_or_terminate
removeall "$1" "$2"
;;
*)
echo "None.."
;;
esac
) 98>$LOCK_FILE

EOF


それは一体何をするのでしょうか...?BTRFS スナップショットを作成し、BTRFS 送受信を使用して別の FS にコピーするための簡単なコマンドのセットが含まれています。

最初の起動は比較的時間がかかることがあります。なぜなら... 最初はすべてのデータがコピーされます。 それ以降の起動は非常に高速になります。なぜなら... 変更のみがコピーされます。

cron に追加する別のスクリプト:

もう少しバッシュコードを追加#cat >/root/btrfs-backup/cron-daily.sh << EOF
#!/bin/bash
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

SCRIPT_FILE="$(realpath $0)"
SCRIPT_DIR="$(dirname $SCRIPT_FILE)"
SCRIPT_NAME="$(basename -s .sh $SCRIPT_FILE)"

BACKUP_SCRIPT="$SCRIPT_DIR/btrfs-backup.sh"
RETENTION="-60 day"
$BACKUP_SCRIPT backup root/@
$BACKUP_SCRIPT removeall root/@ "$RETENTION"
$BACKUP_SCRIPT backup root/@home
$BACKUP_SCRIPT removeall root/@home "$RETENTION"
$BACKUP_SCRIPT backup boot/
$BACKUP_SCRIPT removeall boot/ "$RETENTION"
EOF


それは何をするためのものか..？リストされた BTRFS ボリュームの増分スナップショットをバックアップ FS 上に作成し、同期します。 その後、60 日前に作成されたすべての写真が削除されます。 起動後、リストされたボリュームの日付付きスナップショットが /backup/btrfs/back/remote/ サブディレクトリに表示されます。

コードに実行権限を与えましょう。

#chmod +x /root/btrfs-backup/cron-daily.sh
#chmod +x /root/btrfs-backup/btrfs-backup.sh

それを確認して cron に入れてみましょう。

#/usr/bin/nice -n 19 /usr/bin/ionice -c 3 /root/btrfs-backup/cron-daily.sh 2>&1 | /usr/bin/logger -t btrfs-backup
#cat /var/log/syslog | grep btrfs-backup
#crontab -e
0 2 * * * /usr/bin/nice -n 19 /usr/bin/ionice -c 3 /root/btrfs-backup/cron-daily.sh 2>&1 | /usr/bin/logger -t btrfs-backup


LVMシンバックアップ

バックアップ デバイス上にシン プールを作成しましょう。

#lvcreate -L 274877906944B --poolmetadataspare y --poolmetadatasize 4294967296B --chunksize 64k -Z y -T backup/thin-pool

ddrescue をインストールしましょう。なぜなら... スクリプトはこのツールを使用します。

#apt-get install gddrescue

スクリプト用のディレクトリを作成しましょう。

#mkdir /root/lvm-thin-backup

スクリプトをコピーしましょう。

内部ではたくさんのバッシュが...#cat >/root/lvm-thin-backup/lvm-thin-backup.sh << EOF
#!/bin/bash
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

SCRIPT_FILE="$(realpath $0)"
SCRIPT_DIR="$(dirname $SCRIPT_FILE)"
SCRIPT_NAME="$(basename -s .sh $SCRIPT_FILE)"

LOCK_FILE="/dev/shm/$SCRIPT_NAME.lock"
DATE_PREFIX='%Y-%m-%d'
DATE_FORMAT=$DATE_PREFIX'-%H-%M-%S'
DATE_REGEX='[0-9][0-9][0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]-[0-9][0-9]'
BASE_SUFFIX=".base"
PEND_SUFFIX=".pend"
SNAP_SUFFIX=".snap"
BACKUPS="backup"
BACKUPS_POOL="thin-pool"

export LVM_SUPPRESS_FD_WARNINGS=1

function terminate ()
{
echo "$1" >&2
exit 1
}

function wait_lock()
{
flock 98
}

function wait_lock_or_terminate()
{
echo "Wating for lock..."
wait_lock || terminate "Failed to get lock. Exiting..."
echo "Got lock..."
}

function suffix()
{
FORMATTED_DATE=$(date +"$DATE_FORMAT")
echo "$SNAP_SUFFIX.$FORMATTED_DATE"
}

function filter()
{
FORMATTED_DATE=$(date --date="$1" +"$DATE_PREFIX")
echo "$SNAP_SUFFIX.$FORMATTED_DATE"
}

function read_thin_id {
lvs --rows --reportformat basic --quiet -othin_id "$1/$2" | awk '{print $2}'
}

function read_pool_lv {
lvs --rows --reportformat basic --quiet -opool_lv "$1/$2" | awk '{print $2}'
}

function read_lv_dm_path {
lvs --rows --reportformat basic --quiet -olv_dm_path "$1/$2" | awk '{print $2}'
}

function read_lv_active {
lvs --rows --reportformat basic --quiet -olv_active "$1/$2" | awk '{print $2}'
}

function read_lv_chunk_size {
lvs --rows --reportformat basic --quiet --units b --nosuffix -ochunk_size "$1/$2" | awk '{print $2}'
}

function read_lv_size {
lvs --rows --reportformat basic --quiet --units b --nosuffix -olv_size "$1/$2" | awk '{print $2}'
}

function activate_volume {
lvchange -ay -Ky "$1/$2"
}

function deactivate_volume {
lvchange -an "$1/$2"
}

function read_thin_metadata_snap {
dmsetup status "$1" | awk '{print $7}'
}

function thindiff()
{
DIFF_VG="$1"
DIFF_SOURCE="$2"
DIFF_TARGET="$3"
DIFF_SOURCE_POOL=$(read_pool_lv $DIFF_VG $DIFF_SOURCE)
DIFF_TARGET_POOL=$(read_pool_lv $DIFF_VG $DIFF_TARGET)

if [ "$DIFF_SOURCE_POOL" == "" ] then
(>&2 echo "Source LV is not thin.")
exit 1
fi

if [ "$DIFF_TARGET_POOL" == "" ] then
(>&2 echo "Target LV is not thin.")
exit 1
fi

if [ "$DIFF_SOURCE_POOL" != "$DIFF_TARGET_POOL" ] then
(>&2 echo "Source and target LVs belong to different thin pools.")
exit 1
fi

DIFF_POOL_PATH=$(read_lv_dm_path $DIFF_VG $DIFF_SOURCE_POOL)
DIFF_SOURCE_ID=$(read_thin_id $DIFF_VG $DIFF_SOURCE)
DIFF_TARGET_ID=$(read_thin_id $DIFF_VG $DIFF_TARGET)
DIFF_POOL_PATH_TPOOL="$DIFF_POOL_PATH-tpool"
DIFF_POOL_PATH_TMETA="$DIFF_POOL_PATH"_tmeta
DIFF_POOL_METADATA_SNAP=$(read_thin_metadata_snap $DIFF_POOL_PATH_TPOOL)

if [ "$DIFF_POOL_METADATA_SNAP" != "-" ] then
(>&2 echo "Thin pool metadata snapshot already exist. Assuming stale one. Will release metadata snapshot in 5 seconds.")
sleep 5
dmsetup message $DIFF_POOL_PATH_TPOOL 0 release_metadata_snap
fi

dmsetup message $DIFF_POOL_PATH_TPOOL 0 reserve_metadata_snap
DIFF_POOL_METADATA_SNAP=$(read_thin_metadata_snap $DIFF_POOL_PATH_TPOOL)

if [ "$DIFF_POOL_METADATA_SNAP" == "-" ] then
(>&2 echo "Failed to create thin pool metadata snapshot.")
exit 1
fi

#We keep output in variable because metadata snapshot need to be released early.
DIFF_DATA=$(thin_delta -m$DIFF_POOL_METADATA_SNAP --snap1 $DIFF_SOURCE_ID --snap2 $DIFF_TARGET_ID $DIFF_POOL_PATH_TMETA)

dmsetup message $DIFF_POOL_PATH_TPOOL 0 release_metadata_snap

echo $"$DIFF_DATA" | grep -E 'different|left_only|right_only' | sed 's/</"/g' | sed 's/ /"/g' | awk -F'"' '{print $6 "t" $8 "t" $11}' | sed 's/different/copy/g' | sed 's/left_only/copy/g' | sed 's/right_only/discard/g'

}

function thinsync()
{
SYNC_VG="$1"
SYNC_PEND="$2"
SYNC_BASE="$3"
SYNC_TARGET="$4"
SYNC_PEND_POOL=$(read_pool_lv $SYNC_VG $SYNC_PEND)
SYNC_BLOCK_SIZE=$(read_lv_chunk_size $SYNC_VG $SYNC_PEND_POOL)
SYNC_PEND_PATH=$(read_lv_dm_path $SYNC_VG $SYNC_PEND)

activate_volume $SYNC_VG $SYNC_PEND

while read -r SYNC_ACTION SYNC_OFFSET SYNC_LENGTH ; do
SYNC_OFFSET_BYTES=$((SYNC_OFFSET * SYNC_BLOCK_SIZE))
SYNC_LENGTH_BYTES=$((SYNC_LENGTH * SYNC_BLOCK_SIZE))
if [ "$SYNC_ACTION" == "copy" ] then
ddrescue --quiet --force --input-position=$SYNC_OFFSET_BYTES --output-position=$SYNC_OFFSET_BYTES --size=$SYNC_LENGTH_BYTES "$SYNC_PEND_PATH" "$SYNC_TARGET"
fi

if [ "$SYNC_ACTION" == "discard" ] then
blkdiscard -o $SYNC_OFFSET_BYTES -l $SYNC_LENGTH_BYTES "$SYNC_TARGET"
fi
done < <(thindiff "$SYNC_VG" "$SYNC_PEND" "$SYNC_BASE")
}

function discard_volume()
{
DISCARD_VG="$1"
DISCARD_LV="$2"
DISCARD_LV_PATH=$(read_lv_dm_path "$DISCARD_VG" "$DISCARD_LV")
if [ "$DISCARD_LV_PATH" != "" ] then
echo "$DISCARD_LV_PATH found"
else
echo "$DISCARD_LV not found in $DISCARD_VG"
exit 1
fi
DISCARD_LV_POOL=$(read_pool_lv $DISCARD_VG $DISCARD_LV)
DISCARD_LV_SIZE=$(read_lv_size "$DISCARD_VG" "$DISCARD_LV")
lvremove -y --quiet "$DISCARD_LV_PATH" || exit 1
lvcreate --thin-pool "$DISCARD_LV_POOL" -V "$DISCARD_LV_SIZE"B --name "$DISCARD_LV" "$DISCARD_VG" || exit 1
}

function backup()
{
SOURCE_VG="$1"
SOURCE_LV="$2"
TARGET_VG="$BACKUPS"
TARGET_LV="$SOURCE_VG-$SOURCE_LV"
SOURCE_BASE_LV="$SOURCE_LV$BASE_SUFFIX"
TARGET_BASE_LV="$TARGET_LV$BASE_SUFFIX"
SOURCE_PEND_LV="$SOURCE_LV$PEND_SUFFIX"
TARGET_PEND_LV="$TARGET_LV$PEND_SUFFIX"
SOURCE_BASE_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_BASE_LV")
SOURCE_PEND_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_PEND_LV")
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
TARGET_PEND_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_PEND_LV")

if [ "$SOURCE_BASE_LV_PATH" != "" ] then
echo "$SOURCE_BASE_LV_PATH found"
else
echo "Source base not found creating snapshot of $SOURCE_VG/$SOURCE_LV to $SOURCE_VG/$SOURCE_BASE_LV"
lvcreate --quiet --snapshot --name "$SOURCE_BASE_LV" "$SOURCE_VG/$SOURCE_LV" || exit 1
SOURCE_BASE_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_BASE_LV")
activate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
echo "Discarding $SOURCE_BASE_LV_PATH as we need to bootstrap."
SOURCE_BASE_POOL=$(read_pool_lv $SOURCE_VG $SOURCE_BASE_LV)
SOURCE_BASE_CHUNK_SIZE=$(read_lv_chunk_size $SOURCE_VG $SOURCE_BASE_POOL)
discard_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
sync
if [ "$TARGET_BASE_LV_PATH" != "" ] then
echo "$TARGET_BASE_LV_PATH found out of sync with source... removing..."
lvremove -y --quiet $TARGET_BASE_LV_PATH || exit 1
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
sync
fi
fi
SOURCE_BASE_SIZE=$(read_lv_size "$SOURCE_VG" "$SOURCE_BASE_LV")
if [ "$TARGET_BASE_LV_PATH" != "" ] then
echo "$TARGET_BASE_LV_PATH found"
else
echo "$TARGET_VG/$TARGET_LV not found. Creating empty volume."
lvcreate --thin-pool "$BACKUPS_POOL" -V "$SOURCE_BASE_SIZE"B --name "$TARGET_BASE_LV" "$TARGET_VG" || exit 1
echo "Have to rebootstrap. Discarding source at $SOURCE_BASE_LV_PATH"
activate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
SOURCE_BASE_POOL=$(read_pool_lv $SOURCE_VG $SOURCE_BASE_LV)
SOURCE_BASE_CHUNK_SIZE=$(read_lv_chunk_size $SOURCE_VG $SOURCE_BASE_POOL)
discard_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
TARGET_BASE_POOL=$(read_pool_lv $TARGET_VG $TARGET_BASE_LV)
TARGET_BASE_CHUNK_SIZE=$(read_lv_chunk_size $TARGET_VG $TARGET_BASE_POOL)
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
echo "Discarding target at $TARGET_BASE_LV_PATH"
discard_volume "$TARGET_VG" "$TARGET_BASE_LV"
sync
fi
if [ "$SOURCE_PEND_LV_PATH" != "" ] then
echo "$SOURCE_PEND_LV_PATH found removing..."
lvremove -y --quiet "$SOURCE_PEND_LV_PATH" || exit 1
sync
fi
lvcreate --quiet --snapshot --name "$SOURCE_PEND_LV" "$SOURCE_VG/$SOURCE_LV" || exit 1
SOURCE_PEND_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_PEND_LV")
sync
if [ "$TARGET_PEND_LV_PATH" != "" ] then
echo "$TARGET_PEND_LV_PATH found removing..."
lvremove -y --quiet $TARGET_PEND_LV_PATH
sync
fi
lvcreate --quiet --snapshot --name "$TARGET_PEND_LV" "$TARGET_VG/$TARGET_BASE_LV" || exit 1
TARGET_PEND_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_PEND_LV")
SOURCE_PEND_LV_SIZE=$(read_lv_size "$SOURCE_VG" "$SOURCE_PEND_LV")
lvresize -L "$SOURCE_PEND_LV_SIZE"B "$TARGET_PEND_LV_PATH"
activate_volume "$TARGET_VG" "$TARGET_PEND_LV"
echo "Synching $SOURCE_PEND_LV_PATH to $TARGET_PEND_LV_PATH"
thinsync "$SOURCE_VG" "$SOURCE_PEND_LV" "$SOURCE_BASE_LV" "$TARGET_PEND_LV_PATH" || exit 1
sync

TARGET_DATE_SUFFIX=$(suffix)
lvcreate --quiet --snapshot --name "$TARGET_LV$TARGET_DATE_SUFFIX" "$TARGET_VG/$TARGET_PEND_LV" || exit 1
sync
lvremove --quiet -y "$SOURCE_BASE_LV_PATH" || exit 1
sync
lvremove --quiet -y "$TARGET_BASE_LV_PATH" || exit 1
sync
lvrename -y "$SOURCE_VG/$SOURCE_PEND_LV" "$SOURCE_BASE_LV" || exit 1
lvrename -y "$TARGET_VG/$TARGET_PEND_LV" "$TARGET_BASE_LV" || exit 1
sync
deactivate_volume "$TARGET_VG" "$TARGET_BASE_LV"
deactivate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
}

function verify()
{
SOURCE_VG="$1"
SOURCE_LV="$2"
TARGET_VG="$BACKUPS"
TARGET_LV="$SOURCE_VG-$SOURCE_LV"
SOURCE_BASE_LV="$SOURCE_LV$BASE_SUFFIX"
TARGET_BASE_LV="$TARGET_LV$BASE_SUFFIX"
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
SOURCE_BASE_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_BASE_LV")

if [ "$SOURCE_BASE_LV_PATH" != "" ] then
echo "$SOURCE_BASE_LV_PATH found"
else
echo "$SOURCE_BASE_LV_PATH not found"
exit 1
fi
if [ "$TARGET_BASE_LV_PATH" != "" ] then
echo "$TARGET_BASE_LV_PATH found"
else
echo "$TARGET_BASE_LV_PATH not found"
exit 1
fi
activate_volume "$TARGET_VG" "$TARGET_BASE_LV"
activate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
echo Comparing "$SOURCE_BASE_LV_PATH" with "$TARGET_BASE_LV_PATH"
cmp "$SOURCE_BASE_LV_PATH" "$TARGET_BASE_LV_PATH"
echo Done...
deactivate_volume "$TARGET_VG" "$TARGET_BASE_LV"
deactivate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
}

function resync()
{
SOURCE_VG="$1"
SOURCE_LV="$2"
TARGET_VG="$BACKUPS"
TARGET_LV="$SOURCE_VG-$SOURCE_LV"
SOURCE_BASE_LV="$SOURCE_LV$BASE_SUFFIX"
TARGET_BASE_LV="$TARGET_LV$BASE_SUFFIX"
TARGET_BASE_LV_PATH=$(read_lv_dm_path "$TARGET_VG" "$TARGET_BASE_LV")
SOURCE_BASE_LV_PATH=$(read_lv_dm_path "$SOURCE_VG" "$SOURCE_BASE_LV")

if [ "$SOURCE_BASE_LV_PATH" != "" ] then
echo "$SOURCE_BASE_LV_PATH found"
else
echo "$SOURCE_BASE_LV_PATH not found"
exit 1
fi
if [ "$TARGET_BASE_LV_PATH" != "" ] then
echo "$TARGET_BASE_LV_PATH found"
else
echo "$TARGET_BASE_LV_PATH not found"
exit 1
fi
activate_volume "$TARGET_VG" "$TARGET_BASE_LV"
activate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
SOURCE_BASE_POOL=$(read_pool_lv $SOURCE_VG $SOURCE_BASE_LV)
SYNC_BLOCK_SIZE=$(read_lv_chunk_size $SOURCE_VG $SOURCE_BASE_POOL)

echo Syncronizing "$SOURCE_BASE_LV_PATH" to "$TARGET_BASE_LV_PATH"

CMP_OFFSET=0
while [[ "$CMP_OFFSET" != "" ]] ; do
CMP_MISMATCH=$(cmp -i "$CMP_OFFSET" "$SOURCE_BASE_LV_PATH" "$TARGET_BASE_LV_PATH" | grep differ | awk '{print $5}' | sed 's/,//g' )
if [[ "$CMP_MISMATCH" != "" ]] ; then
CMP_OFFSET=$(( CMP_MISMATCH + CMP_OFFSET ))
SYNC_OFFSET_BYTES=$(( ( CMP_OFFSET / SYNC_BLOCK_SIZE ) * SYNC_BLOCK_SIZE ))
SYNC_LENGTH_BYTES=$(( SYNC_BLOCK_SIZE ))
echo "Synching $SYNC_LENGTH_BYTES bytes at $SYNC_OFFSET_BYTES from $SOURCE_BASE_LV_PATH to $TARGET_BASE_LV_PATH"
ddrescue --quiet --force --input-position=$SYNC_OFFSET_BYTES --output-position=$SYNC_OFFSET_BYTES --size=$SYNC_LENGTH_BYTES "$SOURCE_BASE_LV_PATH" "$TARGET_BASE_LV_PATH"
else
CMP_OFFSET=""
fi
done
echo Done...
deactivate_volume "$TARGET_VG" "$TARGET_BASE_LV"
deactivate_volume "$SOURCE_VG" "$SOURCE_BASE_LV"
}

function list()
{
LIST_SOURCE_VG="$1"
LIST_SOURCE_LV="$2"
LIST_TARGET_VG="$BACKUPS"
LIST_TARGET_LV="$LIST_SOURCE_VG-$LIST_SOURCE_LV"
LIST_TARGET_BASE_LV="$LIST_TARGET_LV$SNAP_SUFFIX"
lvs -olv_name | grep "$LIST_TARGET_BASE_LV.$DATE_REGEX"
}

function remove()
{
REMOVE_TARGET_VG="$BACKUPS"
REMOVE_TARGET_LV="$1"
lvremove -y "$REMOVE_TARGET_VG/$REMOVE_TARGET_LV"
sync
}

function removeall()
{
DATE_OFFSET="$3"
FILTER="$(filter "$DATE_OFFSET")"
while read -r SNAPSHOT ; do
remove "$SNAPSHOT"
done < <(list "$1" "$2" | grep "$FILTER")

}

(
COMMAND="$1"
shift

case "$COMMAND" in
"--help")
echo "Help"
;;
"suffix")
suffix
;;
"filter")
filter "$1"
;;
"backup")
wait_lock_or_terminate
backup "$1" "$2"
;;
"list")
list "$1" "$2"
;;
"thindiff")
thindiff "$1" "$2" "$3"
;;
"thinsync")
thinsync "$1" "$2" "$3" "$4"
;;
"verify")
wait_lock_or_terminate
verify "$1" "$2"
;;
"resync")
wait_lock_or_terminate
resync "$1" "$2"
;;
"remove")
wait_lock_or_terminate
remove "$1"
;;
"removeall")
wait_lock_or_terminate
removeall "$1" "$2" "$3"
;;
*)
echo "None.."
;;
esac
) 98>$LOCK_FILE

EOF


それは何をするためのものか...？シン スナップショットを操作し、thin_delta 経由で受信した XNUMX つのシン スナップショットの差分を、ddrescue と blkdiscard を使用して別のブロック デバイスに同期するためのコマンド セットが含まれています。

cron に追加する別のスクリプト:

もう少しバッシュ#cat >/root/lvm-thin-backup/cron-daily.sh << EOF
#!/bin/bash
PATH="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

SCRIPT_FILE="$(realpath $0)"
SCRIPT_DIR="$(dirname $SCRIPT_FILE)"
SCRIPT_NAME="$(basename -s .sh $SCRIPT_FILE)"

BACKUP_SCRIPT="$SCRIPT_DIR/lvm-thin-backup.sh"
RETENTION="-60 days"

$BACKUP_SCRIPT backup images linux-dev
$BACKUP_SCRIPT backup images win8
$BACKUP_SCRIPT backup images win8-data
#etc

$BACKUP_SCRIPT removeall images linux-dev "$RETENTION"
$BACKUP_SCRIPT removeall images win8 "$RETENTION"
$BACKUP_SCRIPT removeall images win8-data "$RETENTION"
#etc

EOF


それは何をするためのものか...？前のスクリプトを使用して、リストされたシン ボリュームのバックアップを作成および同期します。 スクリプトは、リストされたボリュームの非アクティブなスナップショットを残します。これは、最後の同期以降の変更を追跡するために必要です。

このスクリプトを編集して、バックアップ コピーを作成するシン ボリュームのリストを指定する必要があります。 指定された名前は説明のみを目的としています。 必要に応じて、すべてのボリュームを同期するスクリプトを作成できます。

権利を与えましょう:

#chmod +x /root/lvm-thin-backup/cron-daily.sh
#chmod +x /root/lvm-thin-backup/lvm-thin-backup.sh

それを確認して cron に入れてみましょう。

#/usr/bin/nice -n 19 /usr/bin/ionice -c 3 /root/lvm-thin-backup/cron-daily.sh 2>&1 | /usr/bin/logger -t lvm-thin-backup
#cat /var/log/syslog | grep lvm-thin-backup
#crontab -e
0 3 * * * /usr/bin/nice -n 19 /usr/bin/ionice -c 3 /root/lvm-thin-backup/cron-daily.sh 2>&1 | /usr/bin/logger -t lvm-thin-backup

最初の起動は長くなるでしょう、なぜなら... シン ボリュームは、使用されているすべての領域をコピーすることによって完全に同期されます。 LVM シン メタデータのおかげで、どのブロックが実際に使用されているかがわかるため、実際に使用されているシン ボリューム ブロックのみがコピーされます。

後続の実行では、LVM シン メタデータを介した変更追跡のおかげで、データが段階的にコピーされます。

何が起きたのか見てみましょう：

#time /root/btrfs-backup/cron-daily.sh
real 0m2,967s
user 0m0,225s
sys 0m0,353s

#time /root/lvm-thin-backup/cron-daily.sh
real 1m2,710s
user 0m12,721s
sys 0m6,671s

#ls -al /backup/btrfs/back/remote/*
/backup/btrfs/back/remote/boot:
total 0
drwxr-xr-x 1 root root 1260 мар 26 09:11 .
drwxr-xr-x 1 root root 16 мар 6 09:30 ..
drwxr-xr-x 1 root root 322 мар 26 02:00 .@base
drwxr-xr-x 1 root root 516 мар 6 09:39 [email protected]
drwxr-xr-x 1 root root 516 мар 6 09:39 [email protected]
...
/backup/btrfs/back/remote/root:
total 0
drwxr-xr-x 1 root root 2820 мар 26 09:11 .
drwxr-xr-x 1 root root 16 мар 6 09:30 ..
drwxr-xr-x 1 root root 240 мар 26 09:11 @.@base
drwxr-xr-x 1 root root 22 мар 26 09:11 @home.@base
drwxr-xr-x 1 root root 22 мар 6 09:39 @[email protected]
drwxr-xr-x 1 root root 22 мар 6 09:39 @[email protected]
...
drwxr-xr-x 1 root root 240 мар 6 09:39 @[email protected]
drwxr-xr-x 1 root root 240 мар 6 09:39 @[email protected]
...

#lvs -olv_name,lv_size images && lvs -olv_name,lv_size backup
LV LSize
linux-dev 128,00g
linux-dev.base 128,00g
thin-pool 1,38t
win8 128,00g
win8-data 2,00t
win8-data.base 2,00t
win8.base 128,00g
LV LSize
backup 256,00g
images-linux-dev.base 128,00g
images-linux-dev.snap.2020-03-08-10-09-11 128,00g
images-linux-dev.snap.2020-03-08-10-09-25 128,00g
...
images-win8-data.base 2,00t
images-win8-data.snap.2020-03-16-14-11-55 2,00t
images-win8-data.snap.2020-03-16-14-19-50 2,00t
...
images-win8.base 128,00g
images-win8.snap.2020-03-17-04-51-46 128,00g
images-win8.snap.2020-03-18-03-02-49 128,00g
...
thin-pool <2,09t


これは入れ子人形と何の関係があるのでしょうか？

LVM LV 論理ボリュームが他の VG の LVM PV 物理ボリュームになる可能性があることを考えると、おそらく可能です。 LVM は、入れ子人形のように再帰的に実行できます。 これにより、LVM に極めて高い柔軟性が与えられます。

PS

次の記事では、ホーム デスクトップ、ホーム インターネット、P2P ネットワークを使用して、複数の大陸に冗長性を備えた地理分散ストレージ/VM クラスターを作成するための基礎として、いくつかの同様のモバイル ストレージ システム/KVM を使用してみます。

出所： habr.com