
테이프 백업 방식을 시작하려고 하며 데이터가 충분한 방식으로(120MB 이상의 목표 지속) 테이프 드라이브로 계속 흐르도록 하려고 하지만 그렇지 않을 때 유휴 상태가 되는 전용 소스 드라이브/어레이 없이는 그렇게 하는 방법을 알 수 없습니다. 테이프 쓰기. 특정 드라이브에 대한 문서에는 필요한 최소 처리량이 없다고 언급되어 있습니다.
환경
- mt 및 tar를 사용하여 테이프에 Linux Debian 쓰기 복구 기록이 있는 RAR 아카이브 백업(각각 ~1GB-300GB 크기)
- 외부 SFF 케이블을 통해 SAS를 통해 Quantum TC-42BN 테이프 드라이브의 LTO-4 테이프
- 서버는 파일 백업에만 사용되며 네트워크 서비스나 파일 서버에는 사용되지 않습니다.
- 낮/밤 내내 간헐적으로 데이터를 읽고 쓰는 MD RAID 어레이입니다.
테이프 쓰기 중에 소스 어레이에 상당한 읽기/쓰기(예약된 백업에서)가 있는 경우 일시적이라도 테이프에 대한 처리량이 급격하게 떨어집니다. 따라서 소스 어레이/테이프 쓰기 처리량을 중심으로 한 몇 가지 질문은 다음과 같습니다.
- 테이프 쓰기 중에 소스에서 처리량이 10-20MB/s(또는 그 이하) 미만으로 지속적으로 떨어지는 것이 문제가 될 것이라고 가정합니까?
- 백업이 예약되지 않도록 보장된 소스가 있어야 합니까? 기본적으로 최소 2개의 어레이; 하나는 백업용이고 다른 하나는 아카이브 및 테이프 쓰기용인가요?
- 다른 모든 것보다 테이프 쓰기를 우선시할 수 있는 드라이브/어레이용 QOS가 있습니까?
- LTO-4 테이프 드라이브가 조절되므로 LTO-4에 대해 유지해야 하는 일반적인 처리량 하한 제한이 있습니까, 아니면 드라이브마다 크게 달라집니까? 다시 말하지만 문서에는 최대 설계 속도와 "가변 속도 전송"이 언급되어 있지만 얼마나 가변적인지는 언급되어 있지 않습니다.
- 이 소스-처리량 방정식에서 뭔가 빠졌나요, 아니면 근거 없는 걱정이 있나요?
업데이트:
소비자 SATA를 사용하여 4드라이브 RAID 6에서 테이프에 tar가 기록되는 동안 약 30MB/s의 속도로 어레이에서 읽는 600GB 아카이브 작업을 통해 단일 I/O 스트림으로 작업에 최소한의 부담을 주기로 결정했습니다. 드라이브 청취를 통해 테이프 속도가 확실히 느려졌지만 데이터가 부족하거나 구두닦이가 부족한 것 같지는 않았습니다. 이는 전체 예약 백업 중에 작업이 계속 진행되지 않을 것이라고 예상한다는 뜻입니다.우리의 하드웨어 구성그러나 테이프에 기록하는 동안 부담이 덜한 I/O 작업을 처리할 수 있습니다.
참고로, LOT4 테이프는 56개의 엔드투엔드 패스를 수행해야 하므로 효과적으로 ~14GB 청크에 기록한 후 몇 초 동안 멈춰서 속도를 늦춘 다음 다른 방향으로 "이동"합니다. 나는 이것이 내가 그랬던 것처럼 더 낮은 처리량에서 드라이브에 데이터를 "공급"하는 데 도움이 되었다고 생각합니다.미리 읽어보세요그리고비동기 쓰기에 설정stinit.def.
또 다른 참고 사항은 "dd if=/dev/st0 of=/dev/null"을 읽으면 107MB/s의 결과만 생성된다는 것입니다. 이것은 실제 최대 유효 처리량이라고 가정합니다.이것120MB/s가 아닌 드라이브입니다. 드라이브가 현재 다른 PCIe 카드가 설치되지 않은 전용 SAS PCIe HBA에 있습니다.
그동안 1TB RAID0을 Disk2Tape 버퍼로 설정하고 이를 실현하려면 서버에 다른 디스크를 추가해야 했습니다.
저는 여전히 테이프 드라이브에 대해 일종의 QOS를 수행하고 테이프 쓰기를 최우선 순위로 설정하여 어레이를 단순화하고 기생적인 하드웨어 비용을 줄일 수 있는 방법을 찾고 싶습니다.그러나 그 동안에는 예약된 작업이 어레이에 도달하더라도 지속적인 쓰기를 보장하려는 경우 전용 disk2tape 버퍼를 사용하지 않는 방법을 찾을 수 없습니다.
답변1
그만큼엠버퍼는 당신을 도울 수 있는 작고 편리한 도구입니다 maintain sustained data flow to the tape drive
. 대부분의 Linux 배포판에서 사용할 수 있습니다.
mbuffer - I/O 작업을 버퍼링하고 처리량 비율을 표시합니다. 다중 스레드이고 네트워크 연결을 지원하며 표준 버퍼보다 더 많은 옵션을 제공합니다.
실시간 멀티스레드 압축 사용 예:
tar cvf - /backupdir | lbzip2 | mbbuffer -m 4G -L -P 80 > /dev/st0
- tar 파일 아카이브에 파일 추가 시작
- (선택 사항) 모든 CPU 코어를 사용하려면 lbzip2로 압축하세요.
- 메모리 버퍼 채우기 시작
- 80%까지 채워지면 테이프 드라이브로 데이터 전송을 시작합니다.
엠버퍼설명된 매개변수:
-m 4
4GB 메모리 버퍼 크기. 필요하거나 가능하다면 더 큰 버퍼를 사용하십시오.-L
메모리에 잠겨 있음(선택 사항)-P 80
버퍼의 80%가 채워진 후 테이프에 쓰기를 시작합니다. 테이프 드라이브가 쓰기를 시작하는 데 시간이 좀 걸리고 그때쯤이면 100%가 채워질 것이므로 100을 입력할 필요는 없습니다.
이 예에서는 버퍼가 용량의 80%까지 채워지면 데이터를 테이프로 보내기 시작하고 mbbuffer는 계속해서 아카이브 스트림을 수신합니다.
보관 프로세스가 느리고 mbbuffer가 테이프 드라이브를 따라잡을 만큼 빠른 속도로 데이터를 수신하지 못한 경우, 0%에 도달하면 테이프 드라이브로의 데이터 전송을 중지합니다. 메모리 버퍼가 80%까지 채워지면 테이프 드라이브로 데이터 전송이 시작되고 기록은 최고 속도로 계속됩니다.
이렇게 하면 테이프의 "구두 광택"이 최소로 줄어들고 테이프 드라이브는 항상 스트림을 유지하는 데 필요한 최대 속도로 데이터를 가져옵니다.
또한 mbbuffer를 역방향으로 사용하여 테이프 드라이브에서 백업 데이터를 읽고 스트림을 일부 느린 미디어에 저장하거나 네트워크를 통해 보낼 수도 있습니다.
답변2
그만큼내가 찾은 매뉴얼30.5에서 120MB/s까지의 가변 속도를 ~7MB/s 단위로 나열합니다.
또한 LTO 드라이브는 합리적인 크기의 버퍼를 사용하여 데이터 스트림을 균등화하고 속도 조정을 위한 표시기를 제공하므로 읽기 속도가 크게 달라지거나 매우 낮지 않는 한 백히칭은 최소화되어야 합니다.
어느 정도 괜찮은 배열과 대용량 파일의 데이터를 사용하면 120MB/s는 큰 문제가 되지 않습니다(파일 시스템이 고도로 조각화되지 않는 한). 우리의 테이프 버퍼는 RAID 0에서 두 개의 (느린) 4TB 드라이브를 사용하여 대략적인 속도를 유지할 수 있습니다. 270MB/s이지만 테이프를 쓰는 동안에는 버퍼에 쓰지 않습니다.