수백 개의 VM 웹 서버를위한 SAN 기술 선택

문제

기존 플랫폼의 성능에 문제가 있으므로 이에 대해 두 번째 의견을 제시하고자합니다. 지금까지 성능 문제는 처리량이 아니라 IOPS와 관련이 있습니다.

시나리오

각각 64GB의 RAM이있는 16 개의 호스트로 구성된 블레이드 센터. (M610s가 장착 된 Dell M1000e이지만 관련이 없을 수도 있음) 500 대의 VM, 모든 웹 서버 (또는 MySQL,로드 밸런서 등의 관련 웹 기술)는 약 90 %가 Linux 및 나머지 Windows입니다. 하이퍼 바이저는 VMWare vSphere입니다. 호스트 HA를 제공해야하므로 로컬 스토리지가 부족합니다. 따라서 호스트에는 부팅 할 SD 카드 만 있습니다.

약간의 배경 사고

현재 최대 6 개의 호스트가 있으며 (현재 성장에 따라 블레이드 센터의 용량은 몇 년 내에 전체 용량으로 유지됨) 확장을 위해 Dell MD3220i w / MD1220에 iSCSI를 실행하고 있습니다.

우리가 고려한 가능한 옵션과 함께 즉각적인 생각 :

• NFS 데이터 저장소에 VM을 확산시키고 지정된 수의 VM에 대한 성능 요구 사항을 충족하는 NFS 저장소를 실행합니다. NFS는 확장이 저렴할뿐만 아니라 블록 수준 스토리지보다 조금 더 추상화되어 필요에 따라 이동할 수 있습니다.
• 더 많은 MD3220i 컨트롤러 / 대상 추가 VMWare가 많은 대상을 처리하는 방식에이 방법을 사용하면 부정적인 영향을 줄 수 있습니다.
• Nearline SAS에서 SSD로 모든 디스크 교환. 이는 IOPS 문제를 완전히 해결해야하지만 스토리지 용량을 삭감하는 명백한 부작용이 있습니다. 또한 여전히 매우 비쌉니다.
• vSphere 5에는 스토리지 어플라이언스가 있습니다. 우리는 이것을 많이 연구하지는 않았지만 잘 작동해야합니까?

질문

이 모든 것 아래에서 어떤 종류의 스토리지를 실행 하시겠습니까? 다른 블레이드 센터로 확장 할 필요가 없으며 모든 VM에 대해 비교적 우수한 성능을 제공하기 만하면됩니다.

"SAN x가 최고이기 때문에 구입"답변을 찾고 있지 않습니다. 다양한 SAN 기술 (iSCSI, FC, FCoE, InfiniBand, NFS 등), 다양한 유형의 스토리지 (SATA, SAS, SSD) 및 100 대 VM (스토리지, 분리)에 대한 스토리지 처리 방법론에 대한 생각을 찾고 있습니다. , 샤딩 등).

절대적으로 모든 생각, 링크, 가이드, 포인터 등이 이에 환영합니다. 또한 우리가 이미 고려한 위의 옵션에 대한 생각을 듣고 싶습니다.

모든 의견에 미리 감사드립니다!

'12 년 3 월 5 일 업데이트

지금까지 환상적인 반응을 보여 주셔서 대단히 감사합니다!

지금까지이 질문에 대한 답변을 살펴보면 다음 경로가 방법이라고 생각하기 시작했습니다.

• 사용 가능한 스토리지를 VMWare 클러스터에 계층화하고 워크로드에 적합한 스토리지에 VM 디스크를 배치하십시오.
• 적절한 스토리지에 대한 데이터 배치를 자동으로 관리 할 수있는 SAN을 잠재적으로 활용하십시오.
• Infiniband는 전체 용량으로 호스트에 필요한 대역폭을 확보하는 데 가장 비용 효율적인 것으로 보입니다.

주요 SAN 공급 업체의 사전 판매 서비스를 사용하여 시나리오를 수행 할 가치가있는 것처럼 보입니다.

나는이 문제를 잠시 동안 계속 고려할 것입니다. 그 사이에 더 이상 조언을 부탁드립니다!

좋은 VMWare 스토리지 플랫폼의 핵심은 VMWare가 어떤 종류의로드를 생성하는지 이해하는 것입니다.

• 첫째, 많은 서버를 호스팅하기 때문에 작업량은 일반적으로 임의적입니다. 동시에 진행중인 IO 스트림이 많으므로 성공적으로 사전 캐시 할 수있는 스트림이 많지 않습니다.
• 둘째, 변수입니다. 정상 작업 중에는 70 %의 임의 읽기가 표시 될 수 있지만 VM을 새로운 데이터 스토어 또는 다른 것으로 이동하기로 결정한 순간 60GB의 대규모 쓰기가 표시됩니다. 아키텍처에주의하지 않으면 스토리지의 정상적인 IO 처리 능력이 손상 될 수 있습니다.
• 셋째, 환경의 작은 부분은 일반적으로 많은 양의 스토리지 워크로드를 생성합니다.

VMWare 플랫폼 용 스토리지 구축에 접근하는 가장 좋은 방법은 기본부터 시작하는 것입니다.

• 대용량 랜덤 읽기 워크로드를 처리 할 수있는 기능이 필요합니다. 이는 SSD뿐만 아니라 더 작은 드라이브를 의미합니다. 대부분의 최신 스토리지 시스템에서는 액세스 방식에 따라 자동으로 데이터를 이동할 수 있습니다. SSD를 사용하려는 경우 이것이 SSD를 사용하는 방식인지 확인하려고합니다. 핫스팟을 점진적으로 줄이는 방법으로 있어야합니다. SSD 사용 여부에 관계없이 모든 드라이브에서 모든 작업을 수행 할 수 있으면 스토리지 풀링 유형의 것이 유리합니다.
• 간헐적 인 대규모 쓰기를 처리 할 수있는 기능이 필요합니다. 기본 드라이브의 스핀들 속도는 중요하지 않지만 컨트롤러 스택의 효율성 및 캐시 크기는 중요합니다. 미러링 된 캐싱을 사용하는 경우 (컨트롤러 오류가 발생할 때마다 백업으로 돌아 가지 않는 한 선택 사항이 아닌 경우) 미러링에 사용되는 두 캐시 간의 대역폭은 일반적으로 큰 순차적 쓰기의 병목 현상이됩니다. 쓰기 캐싱을위한 고속 컨트롤러 (또는 클러스터) 상호 연결을 확보하십시오. 실제 가격을 유지하면서 최대한 많은 포트를 갖춘 고속 프런트 엔드 네트워크를 구축하기 위해 최선을 다하십시오. 프론트 엔드 성능을 높이려면 스토리지로드를 가능한 많은 프론트 엔드 리소스에 두어야합니다.
• 씬 프로비저닝뿐만 아니라 우선 순위가 낮은 스토리지 계층을 확보함으로써 비용을 크게 절감 할 수 있습니다. 시스템이 개별 블록을 저렴한 대형 / 저속 드라이브 (7200RPM 및 2TB + 크기의 니어 라인 SAS 또는 SATA)로 자동 마이그레이션하지 않는 경우 수동으로 시도하십시오. 대형 느린 드라이브는 아카이브, 백업, 일부 파일 시스템 및 심지어 사용량이 적은 서버에 대한 훌륭한 대상입니다.
• VMWare가 데이터 스토어뿐만 아니라 VM의 사용되지 않은 부분을 할당 해제 할 수 있도록 스토리지가 VAAI 통합되어 있어야합니다.

내 큰 VMWare 배포는 10GbE를 통한 NFS 및 iSCSI입니다. 이는 서버 및 스토리지 헤드에 듀얼 포트 10GbE HBA가 있음을 의미합니다. 저는 ZFS 기반 스토리지의 팬입니다. 필자의 경우 상용 NexentaStor로 감싸 져 있지만 일부는 자체 롤링을 선택합니다.

이러한 맥락에서 ZFS 기반 스토리지의 주요 기능은 ARC / L2ARC 캐싱 기능으로 스토리지를 계층화 할 수 있습니다. 가장 활동적인 데이터는 RAM 및 SSD 스토리지에서 두 번째 계층으로 사용됩니다. 주 스토리지 풀을 10k 또는 15k SAS 드라이브에서 실행하는 것도 도움이됩니다.

워크로드를 프로파일 링하고 이해하는 또 다른 경우입니다. 스토리지 패턴을 분석하고 계획을 세우는 데 도움을 줄 수있는 사람과 협력하십시오. ZFS / NexentaStor 측에서는 PogoStorage가 좋습니다 . 이러한 유형의 통찰력이 없으면 전송 방법 (FC, FCoE, iSCSI, NFS)은 중요하지 않을 수 있습니다. 기존 인프라에 대한 모니터링이 있습니까? 이제 I / O 활동은 어떤 모습입니까?

중요한 질문은 "병목 현상이 어디에 있습니까?"입니다. IOPS를 언급했지만 디스크 자체에 병목 현상이 있거나 SAN 포트가 용량에서 실행되고 있지 않거나 VM이 원하는 것보다 훨씬 더 많은 대기 시간에 있다는 것을 긍정적으로 식별 했습니까?

디스크가 제한 요소라는 것을 분명히 확인한 경우 NFS 또는 무한대로 전환하거나 성능에 영향을 미치지 않는 모든 것-SSD (또는 SSD가 혼합 된 최소 계층 형 스토리지) 또는 전체 번들 더 많은 스핀들 (세계 스테퍼 모터 생산이 바다로 씻겨 진 이후 최근에 훨씬 비싸진 솔루션).

병목 현상의 실제 위치를 100 % 확신 할 수없는 경우, 먼저 다른 사람들의 추측에 따라 스토리지 인프라의 일부를 무작위로 교환하거나 교환하지 않을 것입니다. 매우 효과적입니다 (특히 변경 비용이 얼마나 비싼지를 감안하면).

iscsi 또는 nfs를 원한다면 최소한 10 / 40gb 포트 또는 infiniband를 원할 것입니다. 이는 가장 저렴한 옵션이지만 infiniband의 기본 스토리지 솔루션은 제한적인 것으로 보입니다. 문제는 블레이드 센터 용 모듈이며 일반적으로 8gb fc 또는 10 \ 1gbe 및 무한대의 옵션이 있습니다. infiniband는 nfs와 함께 사용할 수 있으며 performance \ price와 관련하여 아무것도 닫히지 않습니다. 블레이드 센터가 qdr infiniband를 지원하는 경우 nfs를 통해 qdr infiniband tca를 사용하는 일종의 Linux 호스트로 처리하십시오. 이 http://www.zfsbuild.com/2010/04/15/why-we-chose-infiniband-instead-of-10gige를 설명하는 좋은 링크가 있습니다 .

그러나 블레이드 센터가 qdr 인피니 밴드를 지원할 수 있고 네이티브 인피니 밴드를 감당할 수 있다면 그 솔루션을 선택해야합니다.

현재 10gbe 스위치보다 40gbe 스위치가 훨씬 저렴하지만 (이상한 생각) 10gbe 스위치가 가능하지만 블레이드 센터가이를 지원할 것입니다.

로컬 스토리지가 부족합니까? DRBD8과 함께 XEN 머신의 클러스터 파트너에 미러링 된 로컬 RAID 5의 쓰기 처리량에 매우 만족합니다 (물론 "지원되지 않음").

그 외에도 mySQL이 성능 문제라고 확신합니다 (더 나쁜 DB는 보지 못했습니다). 그것을 조정하거나 전체 DB를 파일 시스템 캐시에 넣으십시오 (읽기 액세스 용) ...