XHELファイルシステムはRHEL / CentOS 6.xで壊れています-どうすればいいですか?


28

RHEL / CentOS(EL6)の最近のバージョンは、私が10年以上にわたって強く依存しきたXFSファイルシステムにいくつかの興味深い変更をもたらしました。昨年の夏の一部で、文書化されていないカーネルバックポートに起因するXFSスパースファイルの状況を追いかけました。EL6に移行してから、不幸なパフォーマンスの問題一貫性のない動作をしている人もいます。

XFSは、デフォルトのext3ファイルシステムよりも安定性、スケーラビリティ、および優れたパフォーマンスの向上を提供したため、データおよび成長パーティションのデフォルトのファイルシステムでした。

2012年11月に表面化したEL6システム上のXFSに問題があります。アイドル状態でも、サーバーが異常に高いシステム負荷を示していることに気付きました。あるケースでは、アンロードされたシステムは、3 +の一定のロード平均を示します。他では、負荷に1+のバンプがありました。マウントされたXFSファイルシステムの数は、負荷増加の重大度に影響するように思われました。

システムには2つのアクティブなXFSファイルシステムがあります。影響を受けるカーネルへのアップグレード後、負荷は+2です。 ここに画像の説明を入力してください

深く掘り下げてみると、XFSメーリングリストxfsaildで、STAT D状態にあるプロセスの頻度が増加していることを示すスレッドがいくつか見つかりました。対応するCentOSバグトラッカーRed Hat Bugzillaのエントリは、問題の詳細を概説し、これはパフォーマンスの問題ではないと結論付けています。2.6.32-279.14.1.el6より新しいカーネルでのシステム負荷のレポートのエラーのみ。

WTF?!?

1回限りの状況では、負荷レポートは大した問題ではないかもしれないことを理解しています。NMSと数百または数千のサーバーで管理してみてください!これは、2012年11月EL6.3のカーネル2.6.32-279.14.1.el6で特定されました。カーネル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月以前のリリースでカーネルバージョンをロックするか、ext4またはZFSを選択してXFSを使用しないだけで、パフォーマンス大幅に低下します。上で実行される特定のカスタムアプリケーション用。問題のアプリケーションは、アプリケーション設計の欠陥を説明するために、XFSファイルシステム属性のいくつかに大きく依存しています。

Red Hatのペイウォール付きナレッジベースサイトの背後に行くと、次のようなエントリが表示されます。

カーネル2.6.32-279.14.1.el6をインストールした後、高い負荷平均が観察されます。平均負荷が高いのは、xfsaildが各XFS形式のデバイスでD状態になるためです。

現在、この問題の解決策はありません。現在Bugzilla#883905で追跡されています。回避策インストールされたカーネルパッケージを2.6.32-279.14.1より前のバージョンにダウングレードします。

(RHEL 6.4のオプションではないカーネルのダウングレードを除く...)

したがって、EL6.3またはEL6.4 OSリリースに対して実際の修正は予定されておらず、この問題に4か月以上かかります。EL6.5の修正案と利用可能なカーネルソースパッチがあります...しかし、私の質問は次のとおりです。

アップストリームのメンテナーが重要な機能を壊した場合、OSが提供するカーネルとパッケージから離れることはどの時点で意味がありますか?

Red Hatはこのバグを導入しました。彼らはすべき errataカーネルに修正を組み込みます。エンタープライズオペレーティングシステムを使用する利点の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ベースのサーバーにはあまり役立ちません。


3
EL6を使用していてRHELのサポートにお金を払っている場合、それを修正するのは彼らの責任だと、私はいつも信じていましたか?
トム・オコナー

6
はい... Red Hatが修正します... 自分の時間割で!! -この問題は2012年末に表面化しました。まだ修正されていません。RHEL 6.5のリリースまで修理の予定はないので、技術的には彼ら面倒をみています
...-ewwhite

さて、Red Hatが示している態度(バグトラッカーを参照)では、彼らがもうXFSに悩まされているとは思わない。ここではカスタムカーネルが理にかなっていますが、サポートにお金を払う意味は何ですか?たぶんCentOSのは、あなたのパスは..です
pauska

5
<rant>私はあなたのフラストレーションを理解し、以前はRHEL / CentOSの混合環境を担当していました。 。その後、次のメジャーリリースの修正をスケジュールしますが、次のメジャーバージョンへのアップグレードをサポートできないため、これはほとんど役に立ちません。私は特定の機能の不足に起因していたので、いくつかの時点で私は単にいくつかRHEL5ボックスの上に彼らの公式カーネルを捨てることにしました。</暴言>。
エイドリアンFrühwirth

1
@MartinSchröderSLESは米国では特に人気がありませんが、オプションになる可能性があります。XFS自体は壊れていませんが、Red HatによるXFSの取り扱いは壊れています。検討する価値があります。
ewwhite

回答:


14

アップストリームのメンテナーが重要な機能を壊した場合、OSが提供するカーネルとパッケージから離れることはどの時点で意味がありますか?

「ベンダーのカーネルまたはパッケージがひどく壊れてビジネスに影響を与える時点」が私の一般的な答えです(偶然にも、これはベンダー関係から離れる方法を検討し始めることが理にかなっている点についてです) 。

基本的にあなたや他の人が言っているように、RedHatは(何らかの理由で)分散カーネルでこれにパッチを適用したくないようです。それはあなた自身のカーネルをロールしなければならない状況をあなたに残します(あなた自身のパッチでそれを最新に保ち、あなた自身のパッケージを維持し、Puppetまたは同様のものを使用してシステムにインストールするか、Yumまたはそれらが何であれパッケージサーバを実行する今日使用することができます参照)、またはあなたのビー玉を取り、家に帰る。


はい、私はあなたのビー玉を持ち帰って帰ることはしばしば高価な命題であることを知っています-特にOSのベンダーを切り替えることは、管理の観点からフレーバーが根本的に異なるLinuxの世界では大きな苦痛です。
完全にCentOSに移行するなどのその他のオプションも魅力的ではありません(サポートを失い、他の誰かが本質的にRedHatのコードをビルドしているため、このバグが発生します)。

残念ながら、十分な人数(つまり「巨大企業」)がビー玉を持ち帰って帰らない限り、ベンダーは悪いコードを出荷して修正しないことで人々を台無しにすることをあまり気にしません。


14

この問題は、2013年4月23日のRHEL kernel-2.6.32-358.6.1.el6の6.4エラータ更新の一部として(静かに)修正されました...


2
バグ報告の20週間後、ここの投稿の2週間後、redhatがすべてのアドバイスを「歩く」と言ったのを見たと思いますか
Jasen

多分?よく分かりません。
ewwhite

3

あなたはRHELカーネルにパッチを適用する必要がない場合は、あなたがすることができ、それを自分で行うと正式にサポートされている彼らは、それを証明するために、カーネル、あなただけが必要です。

RHELサポート契約には、そのための規定があります。ISTRは、四半期または年に1〜2に制限されていますが、確実に思い出せません。


知っておくといい!
ewwhite

これは正しくありません。Red Hatに高速修正をリクエストできますが、これを配信するために問題が満たさなければならない基準と、サポートされている高速修正を配信するいくつかの異なる方法があります。独自のカーネルを再コンパイルする場合、そのカーネルはRed Hatでサポートされていません。
suprjami

まさにこれを行う顧客がいます。私は彼らが皆のためにそれを行うとは思わないが、彼らはそれを行う。
MikeyB
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.