손 없는 관리자 = 하이퍼컨버전스?

이는 서버 하드웨어 분야에서 흔히 볼 수 있는 신화입니다. 실제로 하이퍼컨버지드 솔루션(모든 것이 하나로 통합된 경우)은 많은 경우에 필요합니다. 역사적으로 최초의 아키텍처는 Amazon과 Google이 서비스를 위해 개발했습니다. 그런 다음 각각 자체 디스크가 있는 동일한 노드에서 컴퓨팅 팜을 만드는 것이 아이디어였습니다. 이 모든 것은 일부 시스템 구성 소프트웨어(하이퍼바이저)에 의해 통합되었으며 가상 머신으로 분할되었습니다. 주요 목표는 하나의 노드를 서비스하기 위한 최소한의 노력과 확장 시 문제를 최소화하는 것입니다. 동일한 서버를 수천 대나 두 대 더 구입하여 근처에 연결하면 됩니다. 실제로 이는 고립된 사례이며 더 적은 수의 노드와 약간 다른 아키텍처에 대해 이야기하는 경우가 훨씬 더 많습니다.

그러나 장점은 동일합니다. 확장 및 관리가 매우 간편하다는 것입니다. 단점은 다양한 작업이 리소스를 다르게 소비하고 어떤 장소에는 로컬 디스크가 많고 다른 장소에는 RAM이 거의 없다는 것입니다. 즉, 다양한 작업 유형의 경우 리소스 활용도가 감소합니다.

설정의 용이성을 위해 10~15% 더 많은 비용을 지불하는 것으로 나타났습니다. 이것이 제목에 신화를 촉발시킨 것입니다. 우리는 이 기술이 어디에 최적으로 적용될 수 있을지 오랫동안 고민했고, 마침내 찾았습니다. 사실 Cisco는 자체 스토리지 시스템을 보유하지 않았지만 완전한 서버 시장을 원했습니다. 그리고 그들은 노드에 로컬 스토리지를 갖춘 솔루션인 Cisco Hyperflex를 만들었습니다.

그리고 이것은 갑자기 백업 데이터 센터(재해 복구)를 위한 매우 좋은 솔루션으로 밝혀졌습니다. 이제 그 이유와 방법을 알려 드리겠습니다. 그리고 클러스터 테스트를 보여드리겠습니다.

필요한 곳에

하이퍼컨버전스는 다음과 같습니다.

1. 디스크를 컴퓨팅 노드로 전송합니다.
2. 스토리지 하위 시스템과 가상화 하위 시스템의 완전한 통합.
3. 네트워크 하위 시스템과의 전송/통합.

이 조합을 사용하면 가상화 수준에서 많은 스토리지 시스템 기능을 하나의 제어 창에서 모두 구현할 수 있습니다.

우리 회사에서는 중복 데이터 센터를 설계하는 프로젝트에 대한 수요가 매우 높으며 기본적으로 제공되는 복제 옵션(최대 메트로 클러스터까지)으로 인해 하이퍼컨버지드 솔루션을 선택하는 경우가 많습니다.

백업 데이터 센터의 경우 일반적으로 도시 반대편이나 다른 도시에 있는 원격 시설을 이야기합니다. 이를 통해 메인 데이터 센터의 부분적 또는 전체적 장애가 발생하는 경우 중요한 시스템을 복원할 수 있습니다. 판매 데이터는 지속적으로 복제되며 이 복제는 애플리케이션 수준이나 블록 장치(스토리지) 수준에서 이루어질 수 있습니다.

따라서 이제 시스템 설계 및 테스트에 대해 이야기한 다음 절약 데이터를 사용한 몇 가지 실제 적용 시나리오에 대해 이야기하겠습니다.

테스트

우리 인스턴스는 10개의 서버로 구성되어 있으며 각 서버에는 960GB의 SSD 드라이브 XNUMX개가 있습니다. 쓰기 작업을 캐싱하고 서비스 가상 머신을 저장하기 위한 전용 디스크가 있습니다. 솔루션 자체는 네 번째 버전입니다. 첫 번째는 솔직히 조잡하고(리뷰로 판단), 두 번째는 습하고, 세 번째는 이미 상당히 안정적이며, 이것은 일반 대중을 위한 베타 테스트가 끝난 후의 릴리스라고 할 수 있습니다. 테스트하는 동안 아무런 문제도 발견하지 못했고 모든 것이 시계처럼 작동했습니다.

v4의 변경 사항많은 버그가 수정되었습니다.

처음에 플랫폼은 VMware ESXi 하이퍼바이저에서만 작동할 수 있었고 소수의 노드를 지원했습니다. 또한 배포 프로세스가 항상 성공적으로 끝나지 않았고, 일부 단계를 다시 시작해야 했으며, 이전 버전에서 업데이트하는 데 문제가 있었고, GUI의 데이터가 항상 올바르게 표시되지는 않았습니다(성능 그래프 표시는 여전히 만족스럽지 않습니다). ), 때로는 가상화와의 인터페이스에서 문제가 발생했습니다.

이제 어린 시절의 모든 문제가 해결되었으므로 HyperFlex는 ESXi와 Hyper-V를 모두 처리할 수 있으며 다음과 같은 작업도 가능합니다.

1. 확장된 클러스터를 생성합니다.
2. Fabric Interconnect를 사용하지 않고 XNUMX~XNUMX개의 노드로 사무실용 클러스터를 생성합니다(서버만 구입).
3. 외부 스토리지 시스템으로 작업할 수 있는 능력.
4. 컨테이너 및 Kubernetes를 지원합니다.
5. 가용성 영역 생성.
6. 내장된 기능이 만족스럽지 않은 경우 VMware SRM과 통합됩니다.

아키텍처는 주요 경쟁사의 솔루션과 크게 다르지 않으며 자전거를 만들지 않았습니다. 모두 VMware 또는 Hyper-V 가상화 플랫폼에서 실행됩니다. 하드웨어는 독점 Cisco UCS 서버에서 호스팅됩니다. 초기 설정의 상대적 복잡성, 많은 버튼, 사소하지 않은 템플릿 및 종속성 시스템으로 인해 플랫폼을 싫어하는 사람들이 있지만 Zen을 배우고 아이디어에서 영감을 받아 더 이상 원하지 않는 사람들도 있습니다. 다른 서버와 함께 작업합니다.

VMware용 솔루션은 원래 VMware용으로 만들어졌고 더 많은 기능을 갖고 있으므로 경쟁업체를 따라잡고 시장 기대에 부응하기 위해 Hyper-V도 추가되었기 때문에 VMware용 솔루션을 고려할 것입니다.

디스크로 가득 찬 서버 클러스터가 있습니다. 데이터 저장용 디스크(귀하의 취향과 필요에 따라 SSD 또는 HDD)가 있고, 캐싱용 SSD 디스크가 하나 있습니다. 데이터 저장소에 데이터를 쓰면 해당 데이터는 캐싱 계층(서비스 VM의 전용 SSD 디스크 및 RAM)에 저장됩니다. 동시에 데이터 블록이 클러스터의 노드로 전송됩니다(노드 수는 클러스터 복제 요소에 따라 다름). 모든 노드에서 성공적인 기록을 확인한 후 기록 확인이 하이퍼바이저로 전송된 다음 VM으로 전송됩니다. 기록된 데이터는 백그라운드에서 중복 제거, 압축 및 스토리지 디스크에 기록됩니다. 동시에 큰 블록이 항상 스토리지 디스크에 순차적으로 기록되므로 스토리지 디스크의 부하가 줄어듭니다.

중복 제거 및 압축은 항상 활성화되어 있으며 비활성화할 수 없습니다. 데이터는 스토리지 디스크 또는 RAM 캐시에서 직접 읽습니다. 하이브리드 구성을 사용하는 경우 읽기 내용도 SSD에 캐시됩니다.

데이터는 가상 머신의 현재 위치에 묶여 있지 않으며 노드 간에 고르게 분산됩니다. 이 접근 방식을 사용하면 모든 디스크와 네트워크 인터페이스를 동일하게 로드할 수 있습니다. 분명한 단점이 있습니다. 로컬에서 데이터 가용성이 보장되지 않기 때문에 읽기 대기 시간을 최대한 줄일 수 없습니다. 하지만 이는 받은 혜택에 비하면 작은 희생이라고 생각합니다. 또한 네트워크 지연은 전체 결과에 실질적으로 영향을 미치지 않는 값에 도달했습니다.

각 스토리지 노드에 생성되는 특수 서비스 VM Cisco HyperFlex 데이터 플랫폼 컨트롤러는 디스크 하위 시스템의 전체 운영 로직을 담당합니다. 우리의 서비스 VM 구성에서는 vCPU 72개와 RAM 28GB가 할당되었는데, 이는 적지 않은 수준입니다. 호스트 자체에는 512개의 물리적 코어와 XNUMXGB RAM이 있다는 점을 상기시켜 드리겠습니다.

서비스 VM은 SAS 컨트롤러를 VM에 전달하여 물리적 디스크에 직접 액세스할 수 있습니다. 하이퍼바이저와의 통신은 I/O 작업을 가로채는 특수 모듈 IOVisor를 통해 이루어지며, 하이퍼바이저 API에 명령을 보낼 수 있는 에이전트를 사용합니다. 에이전트는 HyperFlex 스냅샷 및 클론 작업을 담당합니다.

디스크 리소스는 NFS 또는 SMB 공유로 하이퍼바이저에 마운트됩니다(하이퍼바이저 유형에 따라 어느 것이 어디에 있는지 추측). 내부적으로는 씬 볼륨 할당, 압축 및 중복 제거, Redirect-on-Write 기술을 사용한 스냅샷, 동기/비동기 복제 등 성인용 본격적인 스토리지 시스템의 기능을 추가할 수 있는 분산 파일 시스템입니다.

서비스 VM은 HyperFlex 하위 시스템의 웹 관리 인터페이스에 대한 액세스를 제공합니다. vCenter와의 통합이 있으며 대부분의 일상적인 작업을 여기에서 수행할 수 있지만, 예를 들어 데이터 저장소는 이미 빠른 HTML5 인터페이스로 전환했거나 본격적인 Flash 클라이언트를 사용하는 경우 별도의 웹캠에서 잘라내는 것이 더 편리합니다. 완전한 통합으로. 서비스 웹캠에서 시스템의 성능과 세부 상태를 볼 수 있습니다.

클러스터에는 컴퓨팅 노드라는 또 다른 유형의 노드가 있습니다. 내장 디스크가 없는 랙 또는 블레이드 서버일 수 있습니다. 이러한 서버는 디스크가 있는 서버에 데이터가 저장된 VM을 실행할 수 있습니다. 데이터 액세스의 관점에서 볼 때, 아키텍처에는 데이터의 물리적 위치로부터의 추상화가 포함되므로 노드 유형 간에 차이가 없습니다. 컴퓨팅 노드와 스토리지 노드의 최대 비율은 2:1입니다.

컴퓨팅 노드를 사용하면 클러스터 리소스를 확장할 때 유연성이 향상됩니다. CPU/RAM만 필요한 경우 디스크가 있는 추가 노드를 구입할 필요가 없습니다. 또한 블레이드 케이지를 추가하고 서버의 랙 배치 비용을 절약할 수 있습니다.

결과적으로 우리는 다음 기능을 갖춘 하이퍼컨버지드 플랫폼을 보유하게 되었습니다.

• 클러스터당 최대 64개 노드(최대 32개 스토리지 노드)
• 클러스터의 최소 노드 수는 XNUMX개(Edge 클러스터의 경우 XNUMX개)입니다.
• 데이터 중복 메커니즘: 복제 요소 2 및 3을 사용한 미러링.
• 메트로 클러스터.
• 다른 HyperFlex 클러스터에 대한 비동기식 VM 복제.
• VM을 원격 데이터 센터로 전환하는 작업을 조정합니다.
• Redirect-on-Write 기술을 사용하는 기본 스냅샷.
• 복제 팩터 1에서 중복 제거 없이 최대 3PB의 사용 가능한 공간. 복제 요소 2는 심각한 판매를 위한 옵션이 아니기 때문에 고려하지 않습니다.

또 다른 큰 장점은 관리 및 배포가 쉽다는 것입니다. UCS 서버 설정의 모든 복잡성은 Cisco 엔지니어가 준비한 전문 VM에서 처리됩니다.

테스트 벤치 구성:

• 관리 클러스터 및 네트워크 구성 요소로 사용되는 Cisco UCS Fabric Interconnect 2UP 6248개(이더넷 48G/FC 10G 모드에서 작동하는 16개 포트)
• Cisco UCS HXAF240 M4 서버 XNUMX개.

서버 특성:

CPU

2 x 인텔® 제온® E5-2690 v4

램

16 x 32GB DDR4-2400-MHz RDIMM/PC4-19200/듀얼 랭크/x4/1.2v

네트워크

UCSC-MLOM-CSC-02(VIC 1227). 2개의 10G 이더넷 포트

스토리지 HBA

Cisco 12G 모듈형 SAS 패스스루 컨트롤러

스토리지 디스크

SSD Intel S1 3520GB 120개, SSD 삼성 MZ-IES1D 800개, SSD 삼성 PM10a 863GB 960개

추가 구성 옵션선택한 하드웨어 외에도 현재 다음 옵션을 사용할 수 있습니다.

• HXAF240c M5.
• Intel Silver 4110부터 Intel Platinum I8260Y까지의 CPU XNUMX개 또는 XNUMX개. XNUMX세대 사용 가능.
• 24개의 메모리 슬롯, 16GB RDIMM 2600에서 128GB LRDIMM 2933까지 스트립.
• 6~23개의 데이터 디스크, 캐싱 디스크 XNUMX개, 시스템 디스크 XNUMX개, 부팅 디스크 XNUMX개.

용량 드라이브

• HX-SD960G61X-EV 960GB 2.5인치 기업용 가치 6G SATA SSD(1X 내구성) SAS 960GB.
• HX-SD38T61X-EV 3.8TB 2.5인치 기업용 가치 6G SATA SSD(1X 내구성) SAS 3.8TB.
• 캐싱 드라이브
• HX-NVMEXPB-I375 375GB 2.5인치 Intel Optane 드라이브, 뛰어난 성능 및 내구성.
• HX-NVMEHW-H1600* 1.6TB 2.5인치 Ent. 성능 NVMe SSD(3배 내구성) NVMe 1.6TB.
• HX-SD400G12TX-EP 400GB 2.5인치 Ent. 성능 12G SAS SSD(10배 내구성) SAS 400GB.
• HX-SD800GBENK9** 800GB 2.5인치 Ent. 성능 12G SAS SED SSD(10배 내구성) SAS 800GB.
• HX-SD16T123X-EP 1.6TB 2.5인치 엔터프라이즈 성능 12G SAS SSD(3배 내구성).

시스템/로그 드라이브

• HX-SD240GM1X-EV 240GB 2.5인치 Enterprise Value 6G SATA SSD(업그레이드 필요)

부트 드라이브

• HX-M2-240GB 240GB SATA M.2 SSD SATA 240GB.

40G, 25G 또는 10G 이더넷 포트를 통해 네트워크에 연결합니다.

FI는 HX-FI-6332(40G), HX-FI-6332-16UP(40G), HX-FI-6454(40G/100G)일 수 있습니다.

테스트 자체

디스크 하위 시스템을 테스트하기 위해 HCIBench 2.2.1을 사용했습니다. 이는 여러 가상 머신에서 로드 생성을 자동화할 수 있는 무료 유틸리티입니다. 로드 자체는 일반적인 fio에 의해 생성됩니다.

우리 클러스터는 3개의 노드, 복제 팩터 XNUMX으로 구성되어 있으며 모든 디스크는 플래시입니다.

테스트를 위해 데이터 저장소 XNUMX개와 가상 머신 XNUMX개를 만들었습니다. 쓰기 테스트에서는 캐싱 디스크가 가득 차지 않은 것으로 가정합니다.

테스트 결과는 다음과 같습니다.

100% 읽기 100% 무작위

0% 읽기 100% 무작위

블록/큐 깊이

128

256

512

1024

2048

128

256

512

1024

2048

4K

0,59ms 213804 IOPS

0,84ms 303540 IOPS

1,36ms 374348 IOPS

2.47ms 414116 IOPS

4,86ms 420180 IOPS

2,22ms 57408 IOPS

3,09ms 82744 IOPS

5,02ms 101824 IPOS

8,75ms 116912 IOPS

17,2ms 118592 IOPS

8K

0,67ms 188416 IOPS

0,93ms 273280 IOPS

1,7ms 299932 IOPS

2,72ms 376,484 IOPS

5,47ms 373,176 IOPS

3,1ms 41148 IOPS

4,7ms 54396 IOPS

7,09ms 72192 IOPS

12,77ms 80132 IOPS

16K

0,77ms 164116 IOPS

1,12ms 228328 IOPS

1,9ms 268140 IOPS

3,96ms 258480 IOPS

3,8ms 33640 IOPS

6,97ms 36696 IOPS

11,35ms 45060 IOPS

32K

1,07ms 119292 IOPS

1,79ms 142888 IOPS

3,56ms 143760 IOPS

7,17ms 17810 IOPS

11,96ms 21396 IOPS

64K

1,84ms 69440 IOPS

3,6ms 71008 IOPS

7,26ms 70404 IOPS

11,37ms 11248 IOPS

굵은 글씨는 생산성이 증가하지 않고 때로는 성능 저하가 눈에 띄는 값을 나타냅니다. 이는 네트워크/컨트롤러/디스크의 성능에 의해 제한되기 때문입니다.

• 순차 읽기 4432MB/s.
• 순차 쓰기 804MB/s.
• 컨트롤러 하나에 오류가 발생하면(가상 머신이나 호스트 오류) 성능 저하가 두 배로 늘어납니다.
• 스토리지 디스크에 오류가 발생하면 손실률은 1/3이 됩니다. 디스크 재구축에는 각 컨트롤러 리소스의 5%가 사용됩니다.

작은 블록에서는 컨트롤러(가상 머신)의 성능에 의해 제한되고, CPU는 100% 로드되며, 블록이 증가하면 포트 대역폭에 의해 제한됩니다. 10Gbps는 AllFlash 시스템의 잠재력을 발휘하기에 충분하지 않습니다. 불행하게도 제공된 데모 스탠드의 매개변수로는 40Gbit/s에서의 작동을 테스트할 수 없습니다.

테스트와 아키텍처 연구에서 느낀 점은 모든 호스트 간에 데이터를 배치하는 알고리즘 덕분에 확장 가능하고 예측 가능한 성능을 얻을 수 있지만 이는 로컬 디스크에서 더 많은 것을 짜낼 수 있기 때문에 읽을 때 한계이기도 합니다. 여기서는 보다 생산적인 네트워크를 절약할 수 있습니다. 예를 들어 40Gbit/s의 FI를 사용할 수 있습니다.

또한 캐싱 및 중복 제거를 위한 디스크 XNUMX개가 제한될 수 있습니다. 실제로 이 테스트베드에서는 SSD 디스크 XNUMX개에 쓸 수 있습니다. 캐싱 드라이브 수를 늘려서 차이를 확인할 수 있으면 좋을 것 같습니다.

실제 사용

백업 데이터 센터를 구성하려면 두 가지 접근 방식을 사용할 수 있습니다(원격 사이트에 백업을 배치하는 것은 고려하지 않음).

1. 능동 수동. 모든 애플리케이션은 메인 데이터 센터에서 호스팅됩니다. 복제는 동기식 또는 비동기식입니다. 메인 데이터 센터에 장애가 발생하면 백업 센터를 활성화해야 합니다. 이는 수동/스크립트/오케스트레이션 애플리케이션으로 수행할 수 있습니다. 여기서는 복제 빈도에 비례하는 RPO를 얻을 것이며, RTO는 관리자의 반응과 기술, 전환 계획의 개발/디버깅 품질에 따라 달라집니다.
2. 액티브-액티브. 이 경우에는 동기식 복제만 있으며, 데이터 센터의 가용성은 엄격하게 세 번째 사이트에 위치한 쿼럼/중재자에 의해 결정됩니다. RPO = 0이고 RTO는 0(애플리케이션이 허용하는 경우)에 도달하거나 가상화 클러스터에 있는 노드의 장애 조치 시간과 동일할 수 있습니다. 가상화 수준에서는 Active-Active 스토리지가 필요한 확장된(Metro) 클러스터가 생성됩니다.

일반적으로 클라이언트가 이미 메인 데이터 센터에 클래식 스토리지 시스템으로 아키텍처를 구현한 것을 확인하므로 복제용으로 또 다른 시스템을 설계합니다. 앞서 언급했듯이 Cisco HyperFlex는 비동기식 복제 및 확장된 가상화 클러스터 생성을 제공합니다. 동시에 두 스토리지 시스템에 대한 고가의 복제 기능과 Active-Active 데이터 액세스를 갖춘 Midrange 수준 이상의 전용 스토리지 시스템이 필요하지 않습니다.

1 스크립트 : 우리는 VMware vSphere 기반의 가상화 플랫폼인 기본 및 백업 데이터 센터를 보유하고 있습니다. 모든 생산 시스템은 기본 데이터 센터에 위치하며 가상 머신의 복제는 하이퍼바이저 수준에서 수행됩니다. 이렇게 하면 백업 데이터 센터에서 VM이 켜져 있는 상태가 유지되지 않습니다. 내장된 도구를 사용하여 데이터베이스와 특수 애플리케이션을 복제하고 VM을 켜진 상태로 유지합니다. 메인 데이터 센터에 장애가 발생하면 백업 데이터 센터에서 시스템을 가동합니다. 우리는 약 100개의 가상 머신을 보유하고 있다고 생각합니다. 기본 데이터 센터가 작동하는 동안 대기 데이터 센터는 기본 데이터 센터가 전환되면 종료될 수 있는 테스트 환경 및 기타 시스템을 실행할 수 있습니다. 양방향 복제를 사용하는 것도 가능합니다. 하드웨어 관점에서는 아무것도 바뀌지 않습니다.

기존 아키텍처의 경우 각 데이터 센터에 FibreChannel을 통해 액세스할 수 있는 하이브리드 스토리지 시스템, 계층화, 중복 제거 및 압축(온라인은 아님), 각 사이트당 서버 8대, FibreChannel 스위치 2개 및 10G 이더넷을 설치합니다. 클래식 아키텍처의 복제 및 전환 관리를 위해 VMware 도구(복제 + SRM) 또는 타사 도구를 사용할 수 있는데, 이는 조금 더 저렴하고 때로는 더 편리합니다.

그림은 다이어그램을 보여줍니다.

Cisco HyperFlex를 사용하면 다음과 같은 아키텍처가 얻어집니다.

HyperFlex의 경우 CPU/RAM 리소스가 큰 서버를 사용했습니다. 리소스 중 일부는 HyperFlex 컨트롤러 VM으로 이동하며, CPU와 메모리 측면에서는 Cisco와 협력하지 않고 나머지 VM에 대한 리소스를 보장하지 않도록 HyperFlex 구성을 약간 재구성하기도 했습니다. 그러나 FibreChannel 스위치를 버릴 수 있으며 각 서버마다 이더넷 포트가 필요하지 않습니다. 로컬 트래픽은 FI 내에서 전환됩니다.

그 결과 각 데이터 센터에 대한 구성은 다음과 같습니다.

서버

8 x 1U 서버(384GB RAM, 2 x Intel Gold 6132, FC HBA)

8 x HX240C-M5L(512GB RAM, 2 x Intel Gold 6150, 3,2GB SSD, 10 x 6TB NL-SAS)

SHD

FC 프런트엔드(20TB SSD, 130TB NL-SAS)를 갖춘 하이브리드 스토리지 시스템

-

LAN

2 x 이더넷 스위치 10G 12 포트

-

SAN

2 x FC 스위치 32/16Gb 24포트

2개의 Cisco UCS FI 6332

라이선스

VMware Ent Plus

VM 스위칭의 복제 및/또는 조정

VMware Ent Plus

저는 Hyperflex용 복제 소프트웨어 라이센스를 제공하지 않았습니다. 이는 즉시 사용 가능하기 때문입니다.

클래식 건축의 경우 품질이 좋고 가격이 저렴한 제조업체로 자리매김한 공급업체를 선택했습니다. 두 옵션 모두 특정 솔루션에 대해 표준 할인을 적용했으며 결과적으로 실제 가격을 받았습니다.

Cisco HyperFlex 솔루션은 13% 더 저렴한 것으로 나타났습니다.

2 스크립트 : 두 개의 활성 데이터 센터 생성. 이 시나리오에서는 VMware에서 확장된 클러스터를 설계하고 있습니다.

클래식 아키텍처는 가상화 서버, SAN(FC 프로토콜), 그리고 이들 사이에 확장된 볼륨을 읽고 쓸 수 있는 두 개의 스토리지 시스템으로 구성됩니다. 각 스토리지 시스템에는 유용한 스토리지 용량을 배치했습니다.

HyperFlex에서는 두 사이트 모두에 동일한 수의 노드가 있는 Stretch Cluster를 생성하기만 하면 됩니다. 이 경우 2+2의 복제 인수가 사용됩니다.

결과는 다음과 같은 구성입니다.

고전 건축

하이퍼플렉스

서버

16 x 1U 서버(384GB RAM, 2 x Intel Gold 6132, FC HBA, 2 x 10G NIC)

16 x HX240C-M5L(512GB RAM, 2 x Intel Gold 6132, 1,6TB NVMe, 12 x 3,8TB SSD, VIC 1387)

SHD

2 x AllFlash 스토리지 시스템(150TB SSD)

-

LAN

4 x 이더넷 스위치 10G 24 포트

-

SAN

4 x FC 스위치 32/16Gb 24포트

4개의 Cisco UCS FI 6332

라이선스

VMware Ent Plus

VMware Ent Plus

모든 계산에서 네트워크 인프라, 데이터 센터 비용 등은 고려하지 않았습니다. 이는 클래식 아키텍처와 HyperFlex 솔루션에서 동일할 것입니다.

비용 측면에서는 HyperFlex가 5% 더 비싼 것으로 나타났습니다. 구성에서 메모리 컨트롤러 채널을 균등하게 채웠기 때문에 CPU/RAM 리소스 측면에서 Cisco에 대한 편향이 있었다는 점에 주목할 가치가 있습니다. 비용은 약간 높지만 엄청난 수준은 아닙니다. 이는 하이퍼컨버전스가 반드시 "부자를 위한 장난감"은 아니지만 데이터 센터 구축에 대한 표준 접근 방식과 경쟁할 수 있음을 분명히 나타냅니다. 이는 이미 Cisco UCS 서버와 이에 상응하는 인프라를 보유하고 있는 사람들에게도 흥미로울 수 있습니다.

장점 중에는 SAN 및 스토리지 시스템 관리, 온라인 압축 및 중복 제거, 지원을 위한 단일 진입점(가상화, 서버, 스토리지 시스템이기도 함), 공간 절약(모든 시나리오에 적용되는 것은 아님), 운영 단순화.

지원에 관해서는 Cisco라는 한 공급업체로부터 지원을 받습니다. Cisco UCS 서버 사용 경험으로 판단하면 마음에 듭니다. HyperFlex에서 열 필요가 없었고 모든 것이 동일하게 작동했습니다. 엔지니어는 즉각적으로 대응하고 일반적인 문제뿐만 아니라 복잡한 특수 사례도 해결할 수 있습니다. 때때로 나는 그들에게 "이것이 가능합니까, 조이나요? "라는 질문을 던집니다. 또는 “여기서 뭔가를 구성했는데 작동하고 싶지 않습니다. 돕다!" - 그들은 인내심을 가지고 그곳에서 필요한 가이드를 찾고 올바른 조치를 지적할 것이며 "우리는 하드웨어 문제만 해결합니다."라고 대답하지 않을 것입니다.

참조

• 명세서
• 가상 데이터 센터
• 책상 서랍 속 데이터 센터
• 내 메일 - [이메일 보호]

출처 : habr.com