용량 계획을위한 정확한 I / O 성능 추이

내가 일하는 곳에 Xen Hypervisor를 사용하여 많은 가상 머신을 호스팅하는 데 사용되는 수많은 "큰 아이언"서버가 있습니다. 이들은 일반적으로 32GB RAM, 듀얼 쿼드 코어 프로세스 및 I / O 용량이있는 고속 디스크로 구성됩니다.

우리는 현재 기존 하드웨어 구성이 약간 길어지고 있고, 더 크고, 더 빠르고, 더 빛나는 새로운 하드웨어를 출시 할시기입니다.

위에서 언급했듯이 기존 키트는 32GB RAM으로 배포되었으며 호스트에 배포 할 수있는 VM의 수를 효과적으로 제한했습니다.

그러나 최신 하드웨어를 조사 할 때 단일 섀시 내에 64, 72 또는 96GB의 단일 시스템에서 더 많은 RAM을 확보 할 수 있습니다. 분명히 이것은 우리가 항상 승리하는 주어진 호스트에 더 많은 기계를 얻을 수있게합니다. 지금까지 분석이 완료되면 제한 요소가 이제 디스크 하위 시스템으로 이동됩니다.

문제는 이제 우리가 어디에 있는지에 대한 아이디어를 얻으려고 노력하는 것입니다. 사용법 덕분에 우리는 I / O 대역폭, 더 나아가 무작위 I의 수에 제한이 없다는 것을 알고 있습니다. / O 작업은 완료 될 수 있습니다. 우리는이 시점에 도달하면 iowait가 급등하고 전체 기계 성능이 개에게 전달 될 것이라는 것을 알고 있습니다.

이제 이것은 내가 묻는 질문의 요점입니다. 누구나 완료되는 임의의 I / O 연산의 수와 관련하여 기존 I / O 성능을 정확하게 추적 / 경향시키는 방법을 아는 사람이 있습니까?

내가 실제로 메트릭을 얻으려고하는 것은 "이 구성은 X 개의 임의 I / O 요청을 성공적으로 처리 할 수 ​​있으며 현재 (평균적으로) 피크 Z Zs로 Y ops를 수행하고 있습니다."

미리 감사드립니다!

sar여기서 일을 훌륭하게 수행합니다. 초당 읽기 / 쓰기 된 섹터뿐만 아니라 트랜잭션 수를 수집하여 IO 워크로드를 상대적으로 적절한 정확도 (읽기 / 쓰기 비율과 트랜잭션 크기 측면에서)로 재생하는 데 사용할 수 있습니다. IO가 얼마나 "무작위"인지를 결정하는 요소). 그것은 완벽하지는 않지만 내 경험상 당신이보고있는 일종의 추정을하기에 충분한 일을합니다.

따라서 이것은 모니터링 및 용량보고 문제처럼 보입니다. 추세 통계를 측정하기 시작하면 전반을 살펴보고 비교하고 상관시킬 수 있습니다.

도구의 관점에서 볼 때 오픈 소스 세계에는 신경절, 제노스, 나 지오 등이 있으며 수많은 다른 벤더 제품이 있습니다.

관심있는 KPI를 추적, 측정 및 저장하고 주기적으로보고하도록 구성 할 수 있습니다.

RAM 사용량에 대한 쿼리가 주어지면 메모리 통계, 스왑 사용량 및 CPU도 포함하는 것이 합리적이므로 동일한 기간 동안 보드 전체에서이를 비교하고 어느 것이 제한되는지 확인할 수 있습니다.

데이터를 캡처 한 후에는 기록을 위해 예를 들어 기록 데이터를 삭제할 수있는 멋진 큰 DB에 모두 저장할 수 있습니다. 6 초 동안 5 초마다 저장 한 다음, 분 단위로, 5 분, 1 시간마다 다시 저장하십시오. 이러한 종류의 스크립트는 cron, autosys 등을 통해 스크립팅하고 실행할 수 있습니다.

이러한 보고서는 경영진이 원하는 것을 제공합니다. 예쁜 그래프로 무언가.

또한 일상적인 관리를 위해 콘솔을 통해 차트 / 그림의 실시간 정보를보고 특정 순간에 수행중인 성과를 확인할 수 있습니다.

필요한 모든 정보를 단일 파일로 가져 와서 필요한 통계를 재생할 수 있으므로 collectl 을 사용 합니다. 이를 통해 기록 간격, 컨텍스트 스위치, 메모리 통계 당 IOPS 수를 볼 수 있습니다. 디스크별로이를 분류하거나 시스템을 전체적으로 살펴볼 수 있습니다. Collectl은 또한 광택을 지원합니다.

총 시스템 성능에 대한 개요를 얻을 수있는 훌륭한 도구입니다. 관찰에 따르면 행운의 경우, SATA 디스크는 일반적으로 임의 액세스를 수행 할 때 200-300 IOPS 사이에서 최고가됩니다.

다른 모든 메트릭을 수행하는 것과 동일한 방식으로 디스크 I / O를 기록하고 그래프로 표시합니다.

• SNMP를 사용하여 호스트에서 데이터를 가져옵니다. NAS / SAN 박스는이를 기본적으로 수행합니다. 모든 Linux 호스트에서 net-snmp 를 사용 하며 USB-DISKIO-MIB 에서이 정보를 제공합니다 .

• 데이터는 RRD 형식으로 저장되고 Cacti를 사용하여 그래프로 표시됩니다 . 일부 Disk IO 템플릿 은 일반적인 현재, 평균 및 피크 형식으로 표시되는 트랜잭션 수와 크기를 제공합니다.

이러한 메트릭은 호스트에서 iostat/ dstat/ sar를 사용하는 것만 큼 유한 할 필요는 없습니다 . 그러나 새로운 머신이 시운전되고 중앙에 저장되어 나중에 참조 할 수 있도록 유지 될 때 자동으로 설정되는 화재 및 잊어 버리기입니다.

이 데이터를 사용하여 운영상 비정상적인 추세를 경고하고 용량 계획을 수행 할 때마다 항상이를 되돌아 봅니다.

내가 실제로 메트릭을 얻으려고하는 것은 "이 구성은 X 개의 임의 I / O 요청 [..]을 성공적으로 처리 할 수 ​​있습니다"입니다.

이것에는 몇 가지 문제가 있습니다.

• 순차 I / O에서 랜덤 I / O를 분리하고 정량화하는 것은 매우 어렵습니다. 이 둘의 근본적인 차이점은 디스크 플래터에 저장된 블록의 물리적 위치입니다. 많은 소규모 트랜잭션은 아마도 디스크에 점이있는 작은 파일과 관련이 있다는 사실을 바탕으로 트랜잭션 크기를 정확하게 추측 할 수 있습니다 . 그러나 보장은 없습니다. 그것은 수도 순차적으로 하나의 파일에서 데이터의 소량을 읽거나 디스크에 블록을 인접 될 수있다.

• 측정 항목을 기록하면 오늘날의 약속이 무엇인지, 시간이 지남에 따라 어떻게 바뀌 었는지, 그리고 앞으로 어떻게 변할 것인지에 대한 아주 좋은 그림을 얻을 수 있습니다. 그것이 말하지 않는 것은 천장이 무엇인지입니다. 적어도 너무 늦기 전에는 안됩니다. 이를 결정하려면 하드웨어 사양에서 일부 수학, 벤치마킹 ( bonnie++나 자신이 좋아함 )을 수행해야하며 해당 domU가 무엇을하고 / 사용하고 있는지에 대한 물류 아이디어를 갖는 것이 도움이됩니다.

스토리지 백엔드 (IBM SVC / DS8000)에 따라 임의 IOPS와 관련된 통계를 직접 가져올 수 있습니다.

서버에서 통계를 가져 오기 위해 nmon 을 사용할 수 있습니다 . 무료입니다 (맥주 에서처럼). 원래 IBM for AIX에서 개발 한 Linux에서도 실행됩니다.

사람들이 SAR을 사용한다면 적어도 몇 초 동안 데이터를 샘플링하기를 바랍니다. collectl을 사용할 때 샘플을 한 번 / 초씩 채 웁니다. 랜덤 I / O에서 얼마나 잘 수행하고 있는지 측정하는 한, Robin Miller의 dt (google it)와 같은 도구를 사용하면 많은 랜덤 I / O를 쉽게 생성 한 다음 collectl로 측정하여 몇 개의 초당 할 수 있습니다. 일반적인 디스크는 일반적으로 회전 대기 시간에 따라 최대 200-300 I / O / 초를 수행합니다. 디스크가 올바른 위치에있을 때까지 1/2 회전을 기다리는 동안 블록 크기는 최소한의 영향을 미쳤습니다.

btw-iowait는 가장 오해 된 측정 중 하나입니다. CPU 부하와 관련이 없으며 입출력이 발생하는 동안 CPU가 다른 작업을 수행하지 않았 음을 의미합니다. 실제로 당신이 100 % iowait에 있다면 그것은 본질적으로 약 100 %의 유휴 상태를 의미합니다!

-표