VMware VMFS5 및 LUN 크기 조정-여러 개의 작은 데이터 저장소 또는 하나의 큰 데이터 저장소?

VMFS5에 더 이상 VMFS 볼륨에 대한 2TB 제한이 없어서 어느 시나리오가 전반적으로 더 유리한지 고려하고 있습니다.

• 더 큰 LUN의 크기가 적거나
• 더 작은 크기의 더 많은 LUN.

필자의 경우 600GB 디스크가 장착 된 새로운 24 디스크 스토리지 어레이가 있습니다. 약 7.2TB 정도의 RAID10을 사용하고 하나의 큰 7TB 데이터 저장소 또는 각각 1TB의 여러 저장소를 사용할 것인지 결정하려고합니다.

각 접근법의 장단점은 무엇입니까?

업데이트 : 물론 계산에 핫 스페어를 포함하는 것을 무시 했으므로 7.2TB 미만이지만 일반적인 아이디어는 동일합니다. :-)

업데이트 2 : 60 개의 VM과 3 개의 호스트가 있습니다. 우리의 VM 중 어느 것도 특히 I / O 집약적이지 않습니다. 이들 중 대부분은 웹 / 앱 서버이며 모니터링 (munin / nagios), 최소로드의 Windows DC 2 개 등입니다. 매우 낮은 I / O 요구 사항이없는 한 DB 서버는 거의 가상화되지 않습니다. 지금 우리가 가지고있는 유일한 가상 DB 서버는 MSSQL 상자이고 그 상자의 DB는 <1GB라고 생각합니다.

업데이트 3 : 어레이 및 FC 연결에 대한 추가 정보 어레이는 각각 2GB 캐시가있는 2 개의 컨트롤러 인 IBM DS3524입니다. 컨트롤러 당 4 개의 8Gbit FC 포트. 각 ESXi 호스트에는 2x 4Gbit FC HBA가 있습니다.

보유하고있는 VM 수 또는 수행 할 작업을 지정하지 않았습니다. 이러한 정보가 없어도 블록 크기 / 성능, 경합 및 유연성을 위해 하나의 큰 LUN을 만드는 것을 피합니다.

데스크톱이 아닌 서버를 가상화한다고 가정하겠습니다. 다음으로 여러 ESX / ESXi 서버를 사용하여 스토리지에 액세스하고이를 vCenter Server에서 관리한다고 가정합니다.

LUN 크기와 VMFS 수를 결정할 때 지원되는 인프라의 최대 구성으로 인해 성능, 구성 유연성 및 리소스 사용률과 같은 여러 요소의 균형을 유지하게됩니다.

1 개의 VM에서 1 개의 LUN / VMFS 매핑으로 최고의 성능을 얻을 수 있습니다. 동일한 VMFS의 시스템간에 경쟁이없고, 잠금 경합이 없으며, 각로드가 분리되고 모든 것이 처리됩니다. 문제는 불필요하게 많은 양의 LUN을 관리하고, 지원되는 최대 한도에 도달하고, VMFS 크기 조정 및 마이그레이션으로 인해 어려움을 겪고, 활용률이 낮은 리소스 (VMFS의 단일 백분율 포인트 여유 공간이 추가되는) 리소스가 있고 일반적으로 관리하기 좋지 않습니다.

다른 하나는 모든 것을 호스팅하도록 지정된 하나의 큰 VMFS입니다. VMFS Y가 유휴 상태 인 동안 VMFS X의 위치와 문제점을 핫스팟으로 배치하는 데 어떤 문제가 있는지 결정하는 데 아무런 문제가 없을 것입니다. 비용은 집계 된 성능이됩니다. 왜? 잠금으로 인해. 하나의 ESX가 지정된 VMFS에 쓰면 IO를 완료하고 다시 시도해야하는 시간 동안 다른 ESX가 잠 깁니다. 성능이 저하됩니다. 놀이터 / 테스트 및 개발 환경 외부에서는 스토리지 구성에 대한 잘못된 접근 방식입니다.

허용되는 방법은 여러 VM을 호스팅 할 수있을만큼 큰 데이터 스토어를 생성하고 사용 가능한 스토리지 공간을 적절한 크기의 청크로 분할하는 것입니다. VM의 수는 VM에 따라 다릅니다. VMFS에서 하나 또는 두 개의 중요한 프로덕션 데이터베이스를 원하지만 동일한 데이터 스토어에 3-4 개의 테스트 및 개발 시스템을 허용 할 수 있습니다. 데이터 스토어 당 VM 수는 하드웨어 (디스크 크기, rpm, 컨트롤러 캐시 등) 및 액세스 패턴 (특정 성능 수준에서 메일 서버보다 동일한 VMFS에서 훨씬 더 많은 웹 서버를 호스팅 할 수 있음)에 따라 다릅니다.

작은 데이터 스토어는 한 가지 장점이 더 있습니다. 즉, 데이터 스토어 당 너무 많은 가상 머신을 실제로 크 래밍하지 못합니다. 테라 프로비저닝 및 중복 제거에 대한 정보가 들릴 때까지 테라 바이트 급 스토리지에 테라 바이트 규모의 가상 디스크를 추가로 투입 할 필요가 없습니다.

한 가지 더 : 해당 데이터 저장소를 만들 때 단일 블록 크기로 표준화하십시오. 데이터 스토어에서 무언가를 수행하고 추악한 "호환되지 않는"오류를 볼 때 나중에 많은 작업을 단순화합니다.

업데이트 : DS3k에는 액티브 / 패시브 컨트롤러가 있습니다 (즉, 지정된 LUN은 컨트롤러 A 또는 B에서 서비스를 제공 할 수 있으며, 비 소유 컨트롤러를 통해 LUN에 액세스하면 성능이 저하됩니다). 컨트롤러간에 균등하게 분배됩니다.

공간이 20 개 정도로 늘어난 15 개의 VM / LUN으로 시작하는 것을 상상할 수 있습니다.

귀하의 질문에 대한 짧은 대답은 IO 패턴이 무엇인지에 달려 있으며 이는 환경에 따라 다릅니다.

http://www.yellow-bricks.com/2011/07/29/vmfs-5-lun-sizing/ 여기에서 예상 IOPS와 몇 개의 LUN이 적합한 지 고려하는 데 도움이 될 수 있습니다. 즉,주의를 기울여야 할 경우 일부 사람들은 많은 LUN을 사용하도록 조언 할 것입니다 (이전 답변에 대한 수정이 승인되면 어레이 측의 LUN IO 대기열에 대한 내 의견 참조). 나는 동의하는 경향이 있지만 더 나아가서 단일 / 몇 개의 VMFS 볼륨으로 확장하려고합니다 (FUD는 범위에 대해 FUD를 믿지 말고 다른 VMFS 제한은 http://virtualgeek.typepad.com/virtual_geek/2009/03 /vmfs-best-practices-and-counter-fud.html). 이는 vSphere 내에서 단일 / 몇 개의 데이터 스토어를 관리 할 수있는 이점이 있으며, vSphere는 각 범위의 첫 번째 블록부터 사용 가능한 범위에서 VM의 균형을 자동으로 조정하므로 IO를 여러 LUN에 분산시키는 성능 이점이 있습니다.

고려해야 할 사항 ... 특히 IO를 많이 사용하는 VM은 없습니다. 이 경우 RAID5와 RAID10의 조합을 고려하여 공간과 속도를 모두 최대한 활용할 수 있습니다.

또한 여러 VMDK로 VM을 구성한 경우 해당 가상 디스크 (예 : OS, 웹, DB, 로그 등 각각 별도의 VMDK)에 OS 및 응용 프로그램 IO 패턴이 분산되어 있으면 각 VMDK를 찾을 수 있습니다. 물리적 LUN의 IO 기능과 일치하는 다른 데이터 저장소 (예 : OS on RAID5, Logs on RAID10) 예를 들어 한 VM의 로그 쓰기가 다른 VM의 웹 읽기 속도에 영향을 미치지 않도록 기본 디스크의 기계적 동작을 활용하기 위해 유사한 IO 패턴을 함께 유지하는 것이 중요합니다.

참고로 ... DB 서버를 성공적으로 가상화 할 수 있습니다 . IO 패턴 및 IOPS 속도를 분석하고 해당 IO를 적절한 LUN으로 대상 지정하면됩니다. LUN이 이미 수행하고있는 IO 패턴과 IOPS를 인식하고 있습니다. 많은 관리자가 좋지 DB 성능 virtualiseation을 비난하는 이유 왜냐하면 이것은 ...이다 가 조심스럽게 IO / IOPS를 계산하지 않았을 때 여러 서버가 생성하는 것이 그들이 공유 LUN에 넣어 (예. 그것 관리자 '잘못을하지 가상화의 잘못 ).

각 볼륨 (LUN)에는 자체 큐 용량이 있으므로 IO 경합을 피하기 위해 많은 구현에서 더 작은 LUN을 사용합니다. 즉, 데이터 저장소를 LUN에 매우 쉽게 적용 할 수 있습니다. 더 크고 적은 VMWare 데이터 저장소의 단점은 내가 아는 한 동시에있을 수있는 VM 수에 제한이있을 수 있다는 것입니다.

다른 고려 사항은 컨트롤러 성능입니다. SAN을 구체적으로 알지는 못하지만 대부분의 SAN에서 LUN을 한 번에 단일 컨트롤러가 소유해야하는 것은 아닙니다. 컨트롤러간에 작업 부하를 분산시킬 수 있도록 시스템에 충분한 LUN이 필요합니다.

예를 들어 LUN이 하나 뿐인 경우 한 번에 하나의 활성 컨트롤러 만 사용하게됩니다. 다른 하나는 할 일이 없기 때문에 유휴 상태입니다.

두 개의 LUN이 있지만 하나가 다른 것보다 훨씬 더 바쁜 경우 두 컨트롤러를 모두 사용하지만 동일하게 사용하지는 않습니다. 더 많은 LUN을 추가하면 컨트롤러가 작업 부하를보다 균등하게 공유합니다.

구체적인 조언 :

성능 요구 사항 측면에서 VM은 모두 동일합니다. 컨트롤러 당 하나씩 두 개의 LUN을 생성합니다. 첫 번째 LUN에 VM을 배치하고 VM이 설정 될 때 시간이 지남에 따라 I / O 대기 시간 및 대기열 깊이를 측정하십시오. 두 번째 LUN을 아직 사용하지 마십시오. LUN 1을 계속 채우십시오. LUN이 꽉 찼음을 나타내는 성능 표시기가 나타나기 시작하거나 VM의 절반을 해당 LUN으로 마이그레이션 한 후에도 성능이 유지됩니다.

성능 문제가 발생하면 LUN 1에서 30 %의 VM을 제거하고 LUN 2로 옮깁니다. 그런 다음 동일한 방식으로 LUN 2를 채 웁니다. 필요한 경우 LUN 3으로 이동하십시오. 이는 퍼지 룸에 대한 약 30 %의 오버 헤드와 함께 주어진 LUN에서 최대 VM 밀도를 달성하는 것입니다.

또한 적중하는 모든 VM에 대해 "고성능"LUN 쌍을 만들려고합니다. 다시 한 번 컨트롤러 당 하나씩 워크로드를 공유하십시오.

위의 설명에 따라 1 개의 데이터 스토어를 사용하면됩니다. 3 개가 넘는 60 개의 vm은 그렇게 나쁘지 않습니다 (20 : 1). 그러나 파이버 스위치가 최소 8Gb 스위치 인 경우 하나 이상의 호스트에서 재정적으로 가능한 경우 HBA를 8Gb로 업그레이드하는 것이 좋습니다.

즉, 어레이에 3 개의 데이터 저장소가 아닌 경우 최소 2 개를 만들 것입니다. 모든 서버가 vMotion을 위해 다른 서버에 액세스하는 호스트 당 1 개의 데이터 스토어. IBM 어레이에 대해 잘 모릅니다. EMC를 통해 각 데이터 스토어마다 3 개의 LUN이있는 단일 RAID10 그룹을 생성합니다. 이 설정을 통해 8Gb HBA가있는 호스트는 더 높은 I / O 시스템에 적합합니다.

하나의 데이터 저장소 / 서버를 수행 할 수 있으며 직접 수행하는 인스턴스가 있지만 특수 서버의 SAN 복제로만 수행합니다. vMotion에 대해 9 개의 서버를 통해 87 개의 서로 다른 데이터 스토어를 관리하면 설정시 혼란스러워집니다! 내 VM의 대부분은 필요한 공간의 양에 따라 5-10 대의 서버가있는 공유 데이터 스토어에 있습니다.

마지막 메모. 장애 조치 쌍 / 클러스터 또는로드 밸런싱에 모든 종류의 서버가있는 경우 다른 데이터 스토어에서 서버를 원할 것입니다. 데이터 스토어에 장애가 발생하지 않도록하고 서버가없는 상태로 두십시오. 물론, 어레이를 잃으면 모든 것을 잃어 버렸지 만 이것이 바로 우리가 백업하는 이유입니다.