XFS 파일 시스템이 RHEL / CentOS 6.x에서 손상되었습니다. 어떻게해야합니까?


28

RHEL의 최신 버전은 / CentOS는 (EL6)는 몇 가지 흥미로운 변화 가져 XFS는 특정 파일 시스템 난에 의존 한 많이 10 년 이상. 지난 여름 에 문서화가 잘 안된 커널 백 포트로 인해 XFS 스파 스 파일 상황을 추적하는 데 시간을 보냈습니다 . 다른 사람들은 EL6으로 전환 한 후 불행한 성능 문제일관되지 않은 동작 을 경험했습니다.

XFS는 기본 ext3 파일 시스템보다 안정성, 확장 성 및 우수한 성능 향상을 제공하므로 데이터 및 성장 파티션의 기본 파일 시스템이었습니다.

2012 년 11 월에 등장한 EL6 시스템의 XFS에 문제가 있습니다. 유휴 상태 일 때도 서버에서 시스템로드가 비정상적으로 높은 것으로 나타났습니다. 하나의 경우, 언로드 시스템은 3+의 일정한로드 평균을 보여줍니다. 다른 경우에는 부하가 1 이상 증가했습니다. 마운트 된 XFS 파일 시스템의 수는로드 증가의 심각도에 영향을주는 것으로 보입니다.

시스템에는 두 개의 활성 XFS 파일 시스템이 있습니다. 영향을받는 커널로 업그레이드 한 후로드는 +2입니다. 여기에 이미지 설명을 입력하십시오

더 깊이 파고 들자면 XFS 메일 링리스트xfsaild 에서 STAT D 상태 에있는 프로세스의 빈도가 증가했음을 나타내는 몇 개의 스레드를 발견했습니다 . 해당 CentOS 버그 추적기Red Hat Bugzilla 항목은 문제의 세부 사항을 설명하고 성능 문제가 아니라고 결론을 내립니다. 2.6.32-279.14.1.el6 이전의 커널에서 시스템로드를보고 할 때만 오류가 발생합니다 .

WTF?!?

일회성 상황에서는로드보고가 그다지 중요하지 않다는 것을 이해합니다. NMS와 수백 또는 수천 대의 서버로 관리하십시오! 이는 2012 년 11 월 EL6.3의 커널 2.6.32-279.14.1.el6 에서 확인되었습니다. 커널 2.6.32-279.19.1.el62.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의 월급 지식 기반 사이트 뒤에는 다음 과 같은 항목이 나타납니다.

커널 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은이 버그를 소개했습니다. 그들은 해야 에라타 커널에 수정을 통합합니다. 엔터프라이즈 운영 체제를 사용하는 이점 중 하나는 일관되고 예측 가능한 플랫폼 대상 을 제공한다는 것 입니다. 이 버그는 패치주기 동안 이미 생산중인 시스템을 중단시키고 새 시스템 배포에 대한 신뢰를 줄였습니다. 제안 된 패치 중 하나를 소스 코드에 적용 할 수 있지만 얼마나 확장 가능한가요? 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 지원을 지불하는 경우 항상 해결해야 할 책임이 있다고 생각했습니다.
Tom O'Connor

6
그렇습니다. Red Hat은 그것을 고칠 것입니다 ... 그들 자신의 시간표에! -이 문제는 2012 년 말에 발생했습니다. 아직 해결되지 않았습니다. 이는 RHEL 6.5의 출시, 그래서 기술적으로, 그들은 때까지 수리를 위해 예정 아니에요 있습니다 ... 그것을 돌보는
ewwhite

글쎄, Red Hat이 보여주는 태도 (버그 추적기 참조) 나는 더 이상 XFS를 괴롭 히고 있다고 믿지 않습니다. 여기서는 커스텀 커널이 의미가 있지만 지원 비용은 얼마입니까? 아마 CentOS가 당신의 길입니다 ..
pauska

5
<rant> 귀하의 불만을 이해하고 있으며, 이전에 혼합 된 RHEL / CentOS 환경을 책임졌으며 RH는 중요한 버그를 해결하기 위해 지속적으로 "무시"하는 방식을보고 때로는 스스로를 소개하는 것을 어렵게합니다. . 그런 다음 다음 메이저 릴리스에 대한 수정을 예약하지만 다음 메이저 버전으로의 업그레이드를 지원하지 않으므로이 기능이 도움이되지 않습니다. 어떤 시점에서 나는 특정 기능의 부족으로 인해 RHEL5 박스에 공식 커널을 버렸습니다. </ rant>
Adrian Frühwirth

1
@ MartinSchröder SLES는 미국에서 특히 인기가 없지만 옵션이 될 수 있습니다. XFS 자체는 망가지지 않지만 Red Hat은이를 처리합니다. 고려해 볼 가치가 있습니다.
ewwhite

답변:


14

업스트림 관리자가 중요한 기능을 깨 뜨렸을 때 OS 제공 커널 및 패키지에서 출발하는 것이 어떤 시점에서 의미가 있습니까?

"공급 업체의 커널 또는 패키지가 너무 무너져서 비즈니스에 영향을 미치는 시점"이 제 일반적인 대답입니다 (동시 적으로 이것은 공급 업체 관계를 벗어나는 방법을 찾기 시작하는 것이 합리적이라고 생각합니다). .

기본적으로 당신과 다른 사람들이 말했듯이, RedHat은 (이유가 무엇이든) 분산 커널에서 이것을 패치하고 싶지 않은 것 같습니다. 그것은 당신 자신의 커널을 굴려야 할 상황 (패치 자체를 최신 상태로 유지하고, 자신의 패키지를 유지 관리하며 Puppet 또는 이와 유사한 시스템에 설치하거나 Yum 또는 그와 관계없이 패키지 서버를 실행하는 상황에 처하게합니다) 오늘 사용할 수 있습니다.) 또는 구슬을 가지고 집으로 돌아갑니다.


예, 대리석을 가지고 집에가는 것이 종종 비싼 제안이라는 것을 알고 있습니다. OS 공급 업체를 바꾸는 것은 특히 관리 측면에서 풍미가 근본적으로 다른 Linux 세계에서 큰 고통입니다.
완전히 CentOS를 사용하는 것과 같은 다른 옵션도 매력적이지 않습니다 (지원을 잃어 버렸고 다른 사람이 빌드 한 RedHat 코드를 계속 얻으므로 여전히이 버그가 있습니다).

불행히도 충분한 사람들 (즉, "거대한 회사")이 대리석을 가져와 집으로 돌아 가지 않는 한 공급 업체는 잘못된 코드를 배송하고 수정하지 않음으로써 사람들을 망치는 것에 크게 신경 쓰지 않을 것입니다.


14

이것은 6.4 에라타 업데이트의 일부로 RHEL 커널 -2.6.32-358.6.1.el6 에서 2013 년 4 월 23 일 Red Hat에 의해 조용히 수정 되었습니다 ...


2
버그 보고서 20 주 후, 여기 게시물 2 주 후, redhat이 "걷다"라고 말하는 모든 조언을 보았을 것이라고 생각하십니까
Jasen

아마도? 잘 모르겠습니다.
ewwhite

3

RHEL 커널을 패치해야하는 경우 직접 할 있고 해당 커널에서 공식적으로 지원 될 수 있으며 ,이를 인증하기 만하면됩니다.

이를 위해 RHEL 지원 계약에 조항이 있습니다. ISTR 분기 또는 연도 당 1 또는 2로 제한되어 있지만 반드시 기억할 수는 없습니다.


알고 아주 좋아요!
ewwhite

이것은 정확하지 않습니다. Red Hat에 가속화 된 수정 프로그램을 요청할 수 있지만이 문제를 해결하기 위해 문제가 충족해야하는 기준과 지원되는 빠른 수정 사항을 제공하는 여러 가지 방법이 있습니다. 자신의 커널을 다시 컴파일하면 Red Hat은 해당 커널을 지원하지 않습니다.
suprjami 2016 년

정확히이 일을하는 고객이 있습니다. 나는 그들이 모든 사람을 위해 그것을 생각하지 않지만 그들은 않습니다.
MikeyB
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.