RHEL / CentOS 6.xでXFSファイルシステムが壊れています-それに対して何ができますか？
RHEL/CentOS（EL6）の最近のバージョンは、いくつかの興味深い変更を XFSファイルシステム にもたらしました。10年以上に大きく依存しています。私は昨年の夏の一部を、不十分に文書化されたカーネルバックポートに起因する XFSスパースファイルの状況 の追跡に費やしました。 EL6への移行以来、他の人は 不幸なパフォーマンスの問題 または 一貫性のない動作 を抱えていました。
XFSは、安定性、スケーラビリティ、およびデフォルトのext3ファイルシステムよりも優れたパフォーマンスの向上を提供するため、データと成長パーティションのデフォルトのファイルシステムでした。
EL6システムのXFSに2012年11月に表面化した問題があります。サーバーがアイドル状態でも異常に高いシステム負荷を示していることに気付きました。 1つのケースでは、アンロードされたシステムは、3 +以上の一定の負荷平均を示します。その他では、負荷に1以上のバンプがありました。マウントされたXFSファイルシステムの数は、負荷増加の重大度に影響を与えているようです。
システムには2つのアクティブなXFSファイルシステムがあります。影響を受けるカーネルへのアップグレード後の負荷は+2です。
さらに掘り下げてみると、 XFSメーリングリスト にいくつかのスレッドが見つかりました。これは、STAT D状態にあるxfsaildプロセスの頻度の増加を示しています。対応する CentOSバグトラッカー および Red Hat Bugzilla エントリは、問題の詳細の概要を示し、これはパフォーマンスの問題ではないと結論付けます。2.6.32-279.14.1.el6より新しいカーネルのシステム負荷のレポートでのエラーのみ。
WTF？！？
一時的な状況では、負荷レポートはそれほど重要ではない可能性があることを理解しています。 NMSと数百または数千のサーバーで管理してみてください！これは2012年11月のカーネル2.6.32-279.14.1.el6のEL6.3で確認されました。カーネル2.6.32-279.19.1.el6および2.6.32-279.22.1.el6は、この動作に変更を加えずに後続の月（2012年12月および2013年2月）にリリースされました。この問題が確認されてから、オペレーティングシステムの新しいマイナーリリースもありました。 EL6.4がリリースされ、現在カーネル2.6.32-358.2.1.el6にあり、同じ動作を示します。
新しいシステムビルドキューがあり、EL6.3の2012年11月以前のリリースでカーネルバージョンをロックするか、XFSを使用せずに ext4 または_を選択して、問題を回避する必要がありました。 [〜＃〜] zfs [〜＃〜] 、上で実行されている特定のカスタムアプリケーションの 重大なパフォーマンスペナルティ 。問題のアプリケーションは、アプリケーション設計の欠陥を説明するために、XFSファイルシステムの属性のいくつかに大きく依存しています。
Red Hatの paywalledナレッジベースサイト の後ろに、次のようなエントリが表示されます。
カーネル2.6.32-279.14.1.el6をインストールした後、高い負荷平均が観察されます。負荷平均が高いのは、XFSでフォーマットされたデバイスごとにxfsaildがD状態になるためです。
現在、この問題の解決策はありません。現在、Bugzilla＃883905を介して追跡されています。回避策インストールされているカーネルパッケージを2.6.32-279.14.1より前のバージョンにダウングレードします。
（RHEL 6.4のオプションではないカーネルのダウングレードを除く...）
したがって、この問題は4か月以上経過しており、EL6.3またはEL6.4 OSリリースでは実際の修正は計画されていません。 EL6.5の修正案とカーネルソースパッチが利用可能です...しかし、私の質問は次のとおりです。
アップストリームのメンテナが重要な機能を壊したときに、OS提供のカーネルとパッケージから離れることはどの時点で意味がありますか？
Red Hatはこのバグを導入しました。それらは修正をerrataカーネルに組み込む必要があります。エンタープライズオペレーティングシステムを使用する利点の1つは、 一貫した予測可能なプラットフォームターゲット を提供することです。このバグにより、パッチサイクル中にすでに稼働中のシステムが混乱し、新しいシステムの導入に対する信頼が低下しました。私は ソースコードに提案されたパッチ の1つを適用することができましたが、それはどのようにスケーラブルですか？ OSの変更に合わせて最新の状態に保つには、ある程度の警戒が必要です。
ここの正しい動きは何ですか？
- これは修正される可能性があることはわかっていますが、いつ修正されるかはわかりません。
- Red Hatエコシステムで独自のカーネルをサポートするには、独自の一連の警告があります。
- サポート資格への影響は何ですか？
- 適切にXFS機能を得るために、新しく構築されたEL6.4サーバーの上に稼働中のEL6.3カーネルをオーバーレイするだけでよいですか？
- これが正式に修正されるまで待つ必要がありますか？
- これは、エンタープライズLinuxのリリースサイクルに対する制御の欠如について何と言っていますか？
- 長い間、計画/設計の間違いをXFSファイルシステムに依存していましたか？
編集：
このパッチは、最新の CentOSPlus カーネルリリース（kernel-2.6.32-358.2.1.el6.centos.plus）に組み込まれました。私は自分のCentOSシステムでこれをテストしていますが、これはRed Hatベースのサーバーではあまり役に立ちません。
上流のメンテナが重要な機能を壊したときに、OS提供のカーネルとパッケージから離れることはどの時点で意味がありますか？
「ベンダーのカーネルまたはパッケージがひどく壊れてビジネスに影響を与える時点」が私の一般的な答えです（これは、偶然にも、これは、ベンダー関係から離れる方法を検討し始めるのが理にかなっていると言える点でもあります） 。
基本的に、あなたや他の人が言ったように、RedHatは（何らかの理由で）分散カーネルでこれにパッチを適用したくないようです。そのため、独自のカーネルをロールしなければならない（自分でパッチを最新に保つ、独自のパッケージを維持し、Puppetなどのシステムにインストールする、またはYumまたは、今日使用しているものなら何でも参照できます）、またはビー玉を持ち帰って家に帰ります。
はい、私はあなたのビー玉を取り、家に帰ることはしばしば高価な命題であることを知っています-特に管理の観点からフレーバーが根本的に異なるLinuxの世界では、OSベンダーの切り替えは大きな痛みです。
完全にCentOSに移行するなど、他のオプションも魅力的ではありません（サポートを失い、他の誰かがRedHatのコードを構築しているため、このバグが発生するため）。
残念ながら、十分な数の人々（つまり、「巨大な企業」）が彼らのビー玉を手に入れて家に帰らない限り、ベンダーは悪いコードを送って修正しないことによって人々をねじ込むことについてそれほど気にしません。
これはRed Hat 2013年4月23日 RHEL kernel-2.6.32-358.6.1.el6で修正されました（ quietly ））。 6.4エラッタ更新の一部として...
RHELカーネルにパッチを適用する必要がある場合は、can自分で行い、正式にthatカーネルでサポートされている場合は、それらを認定する必要があります。
RHELサポート契約には、そうするための規定があります-ISTRは四半期または年ごとに1または2に制限されていますが、確実に覚えることはできません。