몇 개의 Xen VM에서 기가비트 연결을 통해 동일한 네트워크의 전용 서버에 있는 일부 스토리지로 수백 기가바이트의 현장 백업을 수행해야 합니다. 데이터는 대부분 MySQL 데이터입니다. 저는 Percona XtraDB Cluster를 사용합니다. Xtrabackup을 사용하여 서버에서 로컬로 백업되므로 이 데이터는 압축 가능성이 높아야 합니다.
현재 저는 이중성으로 생성된 백업 볼륨을 일부 오프사이트 저장소에 rsync하기 때문에 암호를 사용한 암호화와 함께 이중성 0.6.08b를 사용하고 있습니다(키를 사용하지 않습니다). 압축 수준은 현재 6이고 볼륨 크기는 250입니다. 백업에 하루 이상이 걸리기 때문에 너무 많은 공간을 차지하지 않고 로컬 네트워크 공유 스토리지에 빠르게 백업할 수 있는 권장 이중성 설정을 찾고 있습니다.
어떤 아이디어?
답변1
귀하는 해당 백업에서 약 50MB/s의 처리량을 보고 있다고 의견을 밝혔습니다.
50MB/초는순서대로단일 회전-녹 디스크(즉, 처리량을 높이기 위해 읽기를 디스크 전체에 분산시킬 수 있는 미러링 또는 스트라이프 RAID가 아님)를 사용하여 준 무작위 디스크 처리량에 대해 기대할 수 있는 것입니다. 일부 RAID 구성에서는 최상의 처리량도 가장 느린 드라이브의 처리량으로 효과적으로 제한합니다. 예, 많은 HDD의 정격은 최대 200MB/s입니다. 하지만 이 수치는 최상의 순차 액세스 번호라는 점을 명심하세요. 50MB/s는 또한 약 400Mbit/s이며, IP 오버헤드 등에 대한 약간의 퍼지를 사용하면 네트워크 회선에서 500-600Mbit/s에 도달하므로 그것만으로 기가비트 링크를 포화시키지 않는 동안 충돌 가능성이 있는 영역에 상당히 가까워지고 있습니다.
백업이 실행되는 동안 CPU 사용률에 대한 수치는 제공하지 않습니다. "하이퍼바이저 3개가 있고 각각에 여러 VM이 있고 사용량이 많거나 적습니다"라고 말합니다. 그러나 데이터 복사 및 압축은 CPU를 많이 사용하지 않으며, 백업이 실행되는 동안 여유 CPU 시간이 있으면 CPU에 바인딩되지 않습니다.이 질문에 실제로 대답하는 유일한 방법은 처리량을 제한하는 요인이 무엇인지 파악하는 것입니다.그런 다음 거기에 노력을 집중하십시오.
내 추측읽기나 쓰기 모두 I/O 바인딩되어 있으며~할 것 같다네트워크에 묶여 있어야 합니다. 기가비트 이더넷 연결을 갖춘 전용 백업 스토리지 서버에 대해 이야기하지만 해당 연결의 특성에 대해서는 아무 말도 하지 않습니다. 물리적 호스트 간의 백업용 네트워크 연결은 공유됩니까 아니면 전용입니까? (한 번에 하나의 VM 또는 HV만 백업 데이터를 푸시하는 경우 각 HV를 백업 서버에 연결하는 별도의 물리적 네트워크가 허용됩니다.)
백업 서버에 대한 물리적 네트워크 연결이 다른 네트워크 트래픽과 공유되는 경우 전용 연결 아키텍처로 이동할 수 있습니다. 이로부터 얻을 수 있는 이점의 정도는 데이터가 압축된 위치와 현재 실제로 보고 있는 충돌 수에 따라 크게 달라집니다.~할 것 같다네트워크 처리량을 두 배로 늘릴 수 있으므로 네트워크에 바인딩된 경우 백업 시간을 절반으로 줄일 수 있습니다.
읽기 및/또는 쓰기에 I/O 바인딩된 경우 디스크 I/O를 여러 디스크로 분산시킬 수 있는 미러링 또는 스트라이프 설정으로 이동하면 처리량을 늘리는 데 도움이 될 수 있습니다. 전체 디스크 버스 처리량이 증가합니다. 물론 그 자체로 단점이 있습니다. 한 번에 푸시하는 데이터의 양에 따라 더 많은 데이터를 추가할 수 있습니다.빠른백업 스토리지 서버에 대한 디스크 캐시~할 것 같다또한 도움이 되지만, I/O 바인딩된 경우 쓰기가 다소 순차적이기 때문에 읽기 측에 있을 것이라는 의심이 듭니다. 이 경우 캐시를 추가해도 큰 도움이 되지 않습니다.
디스크에 기록된 데이터를 즉시 압축하는 VM 또는 HV 및/또는 백업 스토리지 서버의 파일 시스템으로 이동하거나 지원되는 경우 이러한 압축을 활성화하는 것을 고려할 수도 있습니다. . CPU 시간이 소요되지만효과적인저장된 사용자 공간 데이터의 동일한 양에 대해 물리적 플래터에서 이동해야 하는 데이터가 적기 때문에 디스크 데이터 전송 속도가 향상됩니다. 어떤 상황에서든 그것이 순이익이 될지 아닐지 여부는 기본적으로 동전 던지기이고 사례별로 평가해야 하지만 확실히 하나의 문제입니다.가능성특히 데이터가 처음부터 압축 가능성이 높은 경우 I/O 바인딩된 상황에 적합합니다. 데이터를 20%(압축 비율 1.25:1에 해당)만 압축할 수 있고 예를 들어 자연어 텍스트로 확실히 달성할 수 있는 경우에도 비교를 위해 gzip-9 압축을 사용하는 ZFS는 샘플링에서 1.20:1 압축을 제공합니다. 인터넷 홈페이지,이미지 포함), 동일한 50MB/s 플래터 전송 속도는 호스트 CPU가 압축 및 압축 해제를 따라갈 수 있다고 가정할 때 갑자기 60MB/s 이상의 유용한 데이터 전송을 제공합니다.암호화된 데이터는추정된무작위 노이즈와 유사하므로 압축률이 매우 낮습니다. 데이터를 암호화하려는 경우 일반적으로 암호화하기 전에 압축합니다. 이 경우 암호화된 쪽의 파일 시스템 수준 압축은 아무 소용이 없습니다.