BBWC : 이론 상으로는 좋은 아이디어이지만 데이터를 저장 한 적이 있습니까?

나는 BBWC (Battery-backed write cache)가 무엇을 하려는지 잘 알고 있으며 이전에는 우수한 UPS로도 서버에서 사용했습니다. 보호 기능을 제공하지 않는 명백한 장애가 있습니다. 실제로 실제로 이점을 제공하는지 이해하고 싶습니다.

(NB는 특히 BBWC를 가지고 있고 충돌 / 실패한 사람들과 BBWC가 회복에 도움이되었는지 아닌 사람들의 답변을 찾고 있습니다)

최신 정보

여기에 피드백을 한 후, BBWC가 어떤 가치를 추가하는지에 대해 회의적입니다.

데이터 무결성에 대한 확신을 갖기 위해 파일 시스템은 데이터가 비 휘발성 스토리지에 커밋 된 시점을 반드시 알아야합니다. 데이터가 디스크에 커밋되었을 때 많은 디스크가 놓여 있다는 점에 주목할 가치가 있습니다 ( http://brad.livejournal.com/2116715.html ). 온 디스크 캐시를 비활성화하면 디스크를 더 정직하게 만들 수 있다고 가정하는 것이 합리적이지만 여전히이 경우에 대한 보장은 없습니다.

BBWC의 일반적으로 큰 버퍼로 인해 배리어는 디스크에 커밋하는 데 훨씬 더 많은 데이터가 필요하므로 쓰기 지연이 발생할 수 있습니다. 일반적인 조언은 비 휘발성 쓰기 백 캐시를 사용할 때 배리어를 비활성화하는 것입니다. 디스크 캐싱). 그러나 이는 쓰기 작업의 무결성을 손상시키는 것으로 보입니다. 비 휘발성 스토리지에 더 많은 데이터가 유지된다고해서 더 일관성이 있다는 의미는 아닙니다. 실제로 논리적 트랜잭션들 사이의 경계가 없다면 논란의 여지가없는 것보다 일관성을 보장 할 기회가 적어 보인다.

BBWC가 디스크에 커밋하지 않고 데이터가 비 휘발성 스토리지에 들어가는 시점에서 장벽을 인식해야한다면 성능 저하없이 데이터 무결성 요구 사항을 충족하는 것으로 보이며 장벽이 여전히 활성화되어 있어야 함을 의미합니다. 그러나 이러한 장치는 일반적으로 데이터를 물리적 장치로 플러시 (방벽이 있으면 상당히 느림)하고 방벽을 비활성화하는 광범위한 조언과 일치하는 동작을 나타내므로 이러한 방식으로 작동 할 수 없습니다. 왜 안돼?

OS의 I / O가 일련의 스트림으로 모델링 된 경우 OS에서 쓰기 캐싱을 관리 할 때 쓰기 장벽의 차단 효과를 최소화 할 수있는 범위가 있습니다.이 수준에서는 논리적 트랜잭션 (단일 스트림 만) )를 커밋해야합니다. 반면, 어떤 비트의 데이터가 트랜잭션을 구성하는지 알지 못하는 BBWC는 전체 캐시를 디스크에 커밋해야합니다. 커널 / 파일 시스템이 실제로 이것을 구현하는지 여부는 현재 투자하려는 것보다 훨씬 많은 노력이 필요합니다.

디스크에 결합 된 것을 디스크에 결합하면 커밋 된 내용과 갑작스런 전원 손실로 인해 손상이 발생합니다. 저널링 또는 로그 구조 파일 시스템을 사용하면 정전 후 전체 fsck를 수행하지 않아 손상이 단독으로 감지되지 않을 가능성이 높습니다. 그것을 수리하려는 시도.

고장 모드와 관련하여 필자의 경험에 따르면 대부분의 갑작스런 정전은 주 전원 손실로 인해 발생합니다 (UPS 및 관리 종료로 쉽게 완화됨). 랙에서 잘못된 케이블을 뽑는 사람들은 데이터 센터 위생이 불량하다는 것을 의미합니다 (라벨 및 케이블 관리). UPS에 의해 방지되지 않는 일부 유형의 갑작스런 전원 손실 이벤트가 있습니다. PSU 또는 VRM의 장애로 장애가있는 BBWC는 장애 발생시 데이터 무결성을 제공하지만, 이러한 이벤트가 얼마나 흔한가? 여기에 응답이 없기 때문에 매우 드문 판단입니다.

확실히 내결함성을 스택에서 더 높이 옮기는 것은 BBWC에 비해 훨씬 더 비쌉니다. 그러나 서버를 클러스터로 구현하면 성능 및 가용성에 대한 다른 많은 이점이 있습니다.

갑작스런 전원 손실로 인한 영향을 완화 할 수있는 다른 방법은 SAN을 구현하는 것입니다. AoE는이를 실용적인 제안으로 만들지 만 (실제로 iSCSI의 요점을 볼 수는 없지만) 비용이 더 높습니다.

확실한. 배터리 백업 캐시 (BBWC)와 이후 플래시 백업 쓰기 캐시 (FBWC)는 충돌 및 갑작스런 전원 손실 후 기내 데이터를 보호합니다.

HP ProLiant 서버에서 일반적인 메시지는 다음과 같습니다.

POST Error: 1792-Drive Array Reports Valid Data Found in Array Accelerator

어떤 수단 " 이봐, 재부팅 / 전력 손실을 살아 쓰기 캐시의 데이터가 !! 지금은 디스크가 다시 쓰기 거기 갈거야 있어요! "

흥미로운 사례는 토네이도 동안 전력을 잃은 시스템의 사후 사후 였습니다. 배열 순서는 다음과 같습니다.

POST Error: 1793-Drive Array - Array Accelerator Battery Depleted - Data Loss
POST Error: 1779-Drive Array Controller Detects Replacement Drives
POST Error: 1792-Drive Array Reports Valid Data Found in Array Accelerator

1793 POST 오류는 고유합니다. -시스템을 사용하는 동안 데이터가 Array Accelerator 메모리에있는 동안 전원이 차단되었습니다. 그러나 이것이 토네이도 였기 때문에 4 일 이내에 전원이 복원되지 않아 어레이 배터리가 고갈 되어 내부 데이터가 손실되었습니다. 서버에는 두 개의 RAID 컨트롤러가 있습니다. 다른 컨트롤러에는 배터리보다 훨씬 오래 지속되는 FBWC 장치가 있습니다. 드라이브가 제대로 복구되었습니다. 빈 배터리로 백업 된 어레이에서 일부 데이터 손상이 발생했습니다.

시설에서 배터리 사용 시간이 많음에도 불구하고 전원 및 위험 조건이없는 4 일 동안 누구나 서버를 안전하게 종료 할 수 없었습니다.

그렇습니다.

데이터 센터에 UPS가없는 서버 (데이터 센터에 UPS가 있음). PDU 오류-시스템이 갑자기 충돌했습니다. 데이터 손실이 없습니다.

그리고 그것은 기본적으로입니다. BBWC의 장점은 머신에 있다는 것입니다. UPS를 믿으십시오. 때로는 누군가가 잘못된 케이블을 뽑는 것과 같은 어리석은 짓을합니다. UPS는 외부입니다. 아, 그 케이블;)

HW RAID 컨트롤러의 배터리 백업 캐시가 완전히 고장난 경우가 2 건있었습니다 (2 개의 별도 회사에서).

BBC는 배터리가 작동한다는 놀라운 아이디어에 의존합니다. 캐치의 어느 시점에서 컨트롤러의 배터리가 고장 나고 파괴적인 것은 많은 HW 레이드 컨트롤러에서 자동으로 실패한다는 것 입니다. 전원 손실로부터 보호되는 캐시가 있다고 생각했지만 그렇지 않았습니다.

정전시 RAID 어레이 데이터 손실이 너무 커서 모든 디스크 내용을 복구 할 수 없게되었습니다. 모든 것이 없어졌습니다. 하나의 사례는 전적으로 테스트 전용 기계와 관련이 있지만 여전히 그렇습니다.

그 후 "절대로 다시는 말하지 않겠다"고 Linux + 저널 기반 fs에서 소프트웨어 기반 디스크 미러링 (mdadm)으로 전환하여 전원 손실 (ext4)에 대한 복원력이 우수하고 다시 돌아 보지 않았습니다. 물론 IO 사용량이 극히 적은 서버에서 사용했습니다.

이 질문에 대한 두 번째 대답이 필요한 것 같습니다 ...

방금 독립형 VMware ESXi 호스트가 RAID 5 어레이에서 드라이브를 잃어 버렸습니다. 저하 된 어레이는 VM 및 응용 프로그램 수준의 성능에 영향을 미쳤습니다.

Smart Array P410i in Slot 0 (Embedded)    (sn: 5001438011138950)

   array A (SAS, Unused Space: 0  MB)

      logicaldrive 1 (1.6 TB, RAID 5, Recovering, 42% complete)

      physicaldrive 1I:1:1 (port 1I:box 1:bay 1, SAS, 300 GB, OK)
      physicaldrive 1I:1:2 (port 1I:box 1:bay 2, SAS, 300 GB, Rebuilding)
      physicaldrive 1I:1:3 (port 1I:box 1:bay 3, SAS, 300 GB, OK)
      physicaldrive 1I:1:4 (port 1I:box 1:bay 4, SAS, 300 GB, OK)
      physicaldrive 2I:1:5 (port 2I:box 1:bay 5, SAS, 300 GB, OK)
      physicaldrive 2I:1:6 (port 2I:box 1:bay 6, SAS, 300 GB, OK)
      physicaldrive 2I:1:7 (port 2I:box 1:bay 7, SAS, 300 GB, OK)
      physicaldrive 2I:1:8 (port 2I:box 1:bay 8, SAS, 300 GB, OK, spare)

이 회사의 IT 담당자는 드라이브가 고장났다는 사실을 알지 못했고 서버를 하드 리셋 했습니다 (모두 더 좋게 만들까요? ).

사용량이 많은 가상 머신이 실행중인 상태에서 손상된 어레이에이를 수행하면 다음과 같은 흥미로운 효과가 있습니다.

캐시 상태 세부 정보 : 현재 어레이 컨트롤러에는 마지막으로 재설정하거나 전원을 켰을 때 배터리 / 커패시터 백업 쓰기 캐시에 유효한 데이터가 저장되어 있습니다. 이는 시스템이 정상적으로 종료되지 않았 음을 나타냅니다. 어레이 컨트롤러가이 데이터를 드라이브에 자동으로 쓰거나 쓰려고했습니다. 이 메시지는 다음 번 어레이 컨트롤러의 전원을 껐다 켜거나 다시 켤 때까지 계속 표시됩니다.

따라서 시스템이 갑자기 중단 되더라도 기내 데이터는 BBWC에 의해 보호됩니다. 가상 머신이 모두 올바르게 복구되었으며 이제 시스템 상태가 양호합니다.

"데이터 저장"외에 다른 것들에도 좋습니다. 또한 디스크 쓰기 큐를 낮게 유지하여 IO 서브 시스템의 성능을 향상시키기 위해 캐시에 쓰기 버퍼링에 능숙합니다. 이는 대화 형 성능이 가장 중요한 서버 (예 : Citrix XenApp 또는 Windows Terminal Services)에 특히 중요합니다.

이것은 웹 서버 나 파일 서버에서 덜 중요합니다. 약간의 시차를 느끼지 못하거나 익숙하지 않을 수도 있습니다. 그러나 Office 응용 프로그램에서 아이콘을 클릭하면 응답 성이 기대됩니다. 그리고 CEO도 마찬가지입니다.