急に上がったものは落ちたとはみなされません。 組み込みシステムの耐障害性を向上

1年前、彼はエレクトロニクス企業向けの組み込みコンピューターを開発するという非常に興味深い仕事をしました。 このコンピューターは、基本的に興味深いものではありませんでした。サブGHz周波数で動作するCortex A-8プロセッサー、512Mb DDR3、1Gb NAND、軽量Linuxアセンブリーです。 しかし、コンピューターが組み込まれたデバイス、したがって自分自身は、かなり厳しい条件で動作する必要がありました。 広い温度範囲（-40から+85℃）、耐湿性、電磁放射線への耐性、電力用キロボルトパルス、4 kVの静電気に対する保護、および特殊な機器のさまざまな状態標準仕様で詳しく説明されている多くの興味深いもの-これがすべてです彼。 顧客の主な要件の1つは、少なくとも10年間の障害に対する開発期間です。 同時に、メーカーは製品の保証修理を5年間提供しているため、質問は修辞的ではなく、金銭的で深刻です。 対応する元素ベースが製品に配置されました。 デバイスは名誉をもってテストに合格し、必要な証明書を受け取りましたが、会話はそれについてではありません。 問題はインストールバッチが作成されたときに始まり、デバイスは部門に分散し、アプリケーションソフトウェアを作成するために局を設計しました。 返品は「何かがロードされていません」という文言で行われました。

失敗でした

検査中に、100％の障害が発生した場合、ファイルシステム（rootfs）を含むNANDパーティションが破損し、他のすべてのパーティションは無傷で、マウントされ、正常に読み取られることが判明しました。 目撃者の調査では、ハード緊急電源オフ後にデバイスが起動を拒否したことが示されました。 研究の方向性は明確です。 ファイルシステムの障害は、メディアへの記録中に電源を切ると発生する可能性があります。 テストベンチを構築しています。そのタスクは、デバイスに電源を供給し、Linuxが起動してテストスクリプトを実行し（ファイルを生成し、Flashに書き込む）、電源を切ることです。 そして円で。 合計で、サイクルは1分強続きました。 いくつかのデバイスをテストしました。 平均して、2000回の反復の後、各デバイスは起動を拒否し、rootfsパーティションがクラッシュしました！ 見つかったようです。



耐久性と信頼性の理由から、当社のデバイスはROMとしてSLC NANDを使用しています。 eMMC（埋め込みマルチメディアメモリカード）のオプションは、書き換えサイクルが少ないため、すぐに拒否されました。 今日、eMMCは産業用アプリケーションの標準ではありません。おそらくこの理由から、-40°Cの動作温度範囲の下限を持つそのような超小型回路の提供はほとんどありません。 産業用システムでの使用に関する主な制限は、データストレージの短い保証期間です。 SLC NANDの場合、これは約10年ですが、eMMCの場合は約1年です。



物理メディア（FTL-Flash Translation Layer）とのソフトウェアレベルの相互作用がメモリに統合されたコントローラーによって実装されるeMMC（または通常のSD「Secure Digital」カード）に基づくソリューションとは対照的に、FTLは中央プロセッサを使用して実装する必要があります。 実装の複雑さが増しているにもかかわらず、これは最終システムの構成の柔軟性に明確な利点をもたらします。また、物理メモリセルの消耗を平準化する特別なアルゴリズムを使用できるため、メディアの耐久性が向上します。 （実際、ウェアレベリングアルゴリズムはeMMCに組み込まれたFTLレベルにも実装されていますが、これは「ブラックボックス」です）。



Linuxオペレーティングシステムは、多くのファイルシステムを使用して物理NANDメディアを操作します。JFFS2とその進化的開発-UBI / UBIFS （これはNokiaに感謝します）、および競合他社-LogFSです。 パラメーターのセットによれば、UBI / UBIFSバンドルが優先されました。 UBI / UBIFSは2つのソフトウェアレイヤーです。UBI（Unsorted Block Images）-物理メディアで直接作業を提供し、UBIFS（UBI File System）-実際にはファイルシステムそのものです。



UBIの主な機能：

• パーティションを操作し、パーティションを作成、削除、またはサイズ変更できます。
• 媒体のボリューム全体で記録のアライメントを提供します。
  
  不良ブロックで動作します。
• 緊急停電やその他の障害が発生した場合のデータ損失の可能性を最小限に抑えます。

UBIFSは、とりわけジャーナリングに取り組んでいます。



一般に、UBIおよびUBIFSは、特定の条件下でのデバイスの動作中に、緊急シャットダウン（言い換えると、電源オフ）後の練習で示されているように、停電に対する耐性の要件を考慮して開発されたという事実にもかかわらず、セクションが破損しています。 これがrootfsを持つパーティションの場合、デバイスは一般に機能を失います。 このイベントの可能性はそれほど高くありません。デバイスは数か月間または数年にわたって安定して動作し、単一の電源障害をうまく乗り切ることができます。 ただし、デバイスがアクセスできない場所で動作するように設計されている場合、この要因を無視することはできません。アクセスが制限されている場合、またはその障害が致命的な結果を招く可能性があります。



失敗の理由は、NANDの物理構造です。 データの記録はページごとに行われます。最初に、ページを消去する必要があります。すべてのユニットがエリアに書き込まれます。 消去はブロック単位で行われ、そのようなブロックはPEB（物理消去ブロック）と呼ばれます。 ページを消去するには、ブロック全体を消去する必要があります。 1つのブロックには、4KBページや256Kブロックなど、多くのページを含めることができます。 UBI / UBIFSの開発者はこの問題を認識しており、あらゆるもののいわゆる「不安定ビット」を非難しています。 これらは、メディアからのデータが失われる可能性がある4つの主なイベントを示します。





すべての場合において、緊急電源オフ後、メモリ領域は正しく読み取れるため、ロギングシステムはキャッチを認識しません。 ただし、この領域へのその後のアクセスにより、データが破損する可能性があります。 このような「不安定なビット」の数は、ECCアルゴリズムが調整できる数よりも多い場合があります。 したがって、以前に読み取ったページが読み取れなくなる、またはその逆の場合、以前に読み取れなかったページが突然読み取り可能になります。 統計的には、このNANDエリアはほとんどの場合変更されるため、ファイルシステムログに不安定なビットが発生する可能性があるという事実によって、問題はさらに悪化します。

システムを保存する

ファイルシステムの存続可能性を高めるために、ルートファイルシステム（CFS）のアーキテクチャに冗長性を導入することにしました。 これは、メディア上の2つの物理パーティションから「仮想」パーティションを作成するという考え方です。 1つのセクションには読み取り専用のrootfsイメージが含まれており、オペレーティングシステムの実行中、すべての変更は2番目のセクションに記録され、読み取りと書き込みが行われます。 録音は2番目のセクションでのみ行われるため、非常時の電源オフ時には損傷する可能性があります。 2番目のセクションは元のままです。 この技術は、カスケード統合マウントとして知られています。



さらに、システムソフトウェア（rootfsを意味し、カーネルはもともと別の読み取り専用パーティションにありました）とアプリケーションソフトウェアを異なる物理パーティションに配布することにしました。 デバイスの仕様により（大規模なデータベースで動作します）、バックアップ用のセクションが割り当てられています。 この場所で、デバイスに十分なメモリが確保されたことを嬉しく思います（1 GiB）。







aufs補助ファイルシステムは、カスケード統合パーティションのマウントに使用されます。 上記のように、2つの物理セクションの結合があります。 作業中のCFSのイメージが最初に書き込まれた最初のセクションは読み取り専用（RO-読み取り専用）、最初は空の2番目のセクションはそれぞれ変更を保存する役割を果たし、読み取りと書き込みの両方で使用できます（RW-読み取り書き込み） aufに関しては、最初と2番目のセクションはブランチと呼ばれます。 ブランチのマージは、マウントプロセス中に発生します。 その結果、オペレーティングシステムは、マウントされた領域全体を認識します。 データアクセスは、カーネルドライバーによって提供されます。 ドライバーはまず、ファイルを読み取る要求をRWブランチに送信します。 データがある場合は発行され、データがない場合はファイルがROブランチから読み取られます。 書き込み時に、データはRWブランチに分類されます。 ファイルが削除されると、このファイルが削除されたというラベルがRWブランチに追加されます（名前に特定のプレフィックスを持つ対応する空の隠しファイルが作成されます）。 物理的に、ファイルは整数としてROブランチに残ります。 このアプローチにより、重要な情報セクションでの書き込み操作が回避されます。 さらに、ROブランチは読み取り専用であるため、原則として追加のデータ整合性制御を追加できます。 UBIFSを使用してこれを実装し、作成されたパーティションを静的にすることができます。 静的セクションは読み取り専用で、そこにあるデータはチェックサム（CRC-32）で保護されています。



全体として、CFSのこのようなアーキテクチャを取得したいと考えています。







「rootfs_」セクションには、Linuxオペレーティングシステムの操作性を保証するCFSのシステム部分が含まれます。「data_」セクションは、アプリケーションソフトウェア、設定ファイル、およびデータベースを保存するためのものです。 「バックアップ」セクションは、現在のシステム設定とデータベースを定期的にバックアップすることを目的としています。 冗長性はアプリケーションソフトウェアによって提供されます。

ベイク

現時点では、aufsはLinuxカーネルのメインブランチに含まれていないため、テクノロジを使用するためのユーティリティに加えて、カーネルソースに個別にパッチを適用する必要があります。 Linuxターゲットプラットフォームにaufsテクノロジーを展開するには、次のものが必要です。

1. カーネルにパッチを適用します。 すべてのパッチとハウツーは、プロジェクトのWebサイトで見つけることができます。
2. コアで、aufsを有効にします。
3. コアを組み立てます。
4. aufsを操作するためのビルドユーティリティ。
5. カーネルとユーティリティをターゲットに転送します。

以下を実行することにより、ターゲットでテクノロジーをテストできます。

mount -t aufs -o br=/tmp/rw=rw:${HOME}=ro none /tmp/aufs
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その結果、ホームディレクトリの内容は/ tmp / aufsにあり、そこに書き込んでファイルを削除できます。$ {HOME}の内容は変更されません。



いいね！ aufsが接続されました。現在最も興味深いのは、システムをそこから起動する方法ですか？ デフォルトでは、ブート時に、cmdlineを介してrootfsからaufsへのパーティションを指定できません。 カーネルの開始時点では、そのようなセクションはまだ存在せず、まだ作成されていません。 これは、システムの起動時に、初期化プロセス（PID = 0のプロセス、私の場合はsystemd）が開始する前に、補助セクションaufsをマウントし、chrootして、そのrun / sbin / initの後にのみ実行する必要があることを意味します。 このようなタスクには、予備的な初期化メカニズムがあります。 cmdlineで 、スクリプトへのパスを指定します。これは、初期化デーモンの開始前に解決する必要があります。 コマンドラインでパラメーターを追加します。

 init=/sbin/preinit
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

スクリプトはシェルに書き込まれるため、実行時には、システムに必要なすべてのユーティリティがすでに備わっているはずです。 つまり、実際には、スクリプトを実行するには、rootfsパーティションが既にマウントされている必要があります！ これらの目的のために、RAMディスクでrootfsを使用するか、rootfsを使用してバトルパーティションから最初に起動できますが、読み取り専用モードではこれが選択です。 cmdlineを適宜編集し、パラメーターを追加します（9はmtdのセクション番号で、rootfs_roがあります）：

 root=ubi0:rootfs_ro ro ubi.mtd=9
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Preinitスクリプト

システムパーティションをマウントします（シェルが機能するために必要）：

 mount -t proc none /proc mount -t tmpfs tmpfs /tmp mount -t sysfs sys /sys
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すでにrootfs_roセクションをマウントし、そこからブートし、rootfs_rwを一時フォルダーにマウントします。

 ubiattach -m 10 -d 1 > /dev/null mount -t ubifs ubi1:$rootfs_rw /tmp/aufs/rootfs_rw
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

マウントプロセス中に何か問題が発生した場合は、rootfs_rwを大胆にフォーマットし、それでも動作しない場合は、パーティションを削除して再度作成します。 再度マウントを試みます。 コードは提供しませんが、NANDアーキテクチャで定義されている「マジックナンバー」が多すぎます。 UBIユーティリティのセットが必要だとしか言えません。



現在のrootfsのマウントポイントを一時ディレクトリにコピーします。

 mkdir -p /tmp/aufs/rootfs_ro mount --bind / /tmp/aufs/rootfs_ro
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

パフケーキを接着する-aufsセクションをマウントします。

 mount -t aufs -o br:/tmp/aufs/rootfs_rw :/tmp/aufs/rootfs_ro=ro none /aufs
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

その後、rootfsを持つ新しいパーティションが/ aufsで利用可能になります。



耳を傾ける：rootfs_roとrootfs_rwのマウントポイントを新しいパーティションに移動します。

 mount --move /tmp/aufs/ rootfs_ro /aufs/aufs/ rootfs_ro mount --move /tmp/aufs/ rootfs_rw /aufs/aufs/ rootfs_rw
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そして同時に/ devを転送します：

 mount --move /dev /aufs/dev
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

マウントポイントが転送されるディレクトリは、事前に作成する必要があることは明らかです。



システムパーティションをオフにします。

 umount -l /proc umount -l /tmp umount -l /sys
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

CFSを変更し、初期化を開始します。

 exec /usr/sbin/chroot /aufs /sbin/init
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

バトルスクリプトでは、同じ原理により、/ applおよびマウント/バックアップの「パイ」を収集します。 次の図は、最終的なCFSの結果のアーキテクチャを示しています。







信頼性を高めるために、/ backupセクションには、バックアップとリカバリを担当する1つのユーティリティのみに排他的にアクセスできます。 ユーティリティ自体は「data_ro」セクションにあります。

おわりに

その結果、緊急停電時のシステム全体の生存率が急激に増加しました。 カスケードCFSマウントテクノロジーのアプリケーションはNANDの例で示されていますが、この原理はデータキャリアの物理タイプに限定されず、eMMC、SDなどに簡単に移行できます。 動作中にシステムがデータを蓄積せず、特定のアルゴリズム（通常のルーターなど）のみを使用する場合、aufsパーティションをマウントするときにRWブランチとしてRAMディスクを使用することをお勧めします。



そして、PSの代わりに、誰もまだバックアップ電源をキャンセルしていません。