우리는 2017년 전 KubeCon 2018에서 Diamanti를 처음 알게 되었으며 마이크로서비스 및 클라우드 네이티브 환경을 위해 특별히 제작되고 Kubernetes 또는 기본적으로 하이퍼컨버지드에 최적화된 베어메탈 컨테이너 플랫폼을 제공한다는 그들의 비전에 깊은 인상을 받았습니다. Kubernetes용 인프라 어플라이언스. 우리는 이것을 흥미로운 플레이로 보았고 작년 KubeCon XNUMX에서 우리는 그들과 함께 Kubernetes의 스토리지를 이해하고 Kubernetes 스토리지를 테스트하고 체계적인 방식으로 정량화하여 테스트 및 문서화를 시작할 수 있는 방법에 대해 이야기하기 시작했습니다. Kubernetes 스토리지 성능.
우리는 2017년 전 KubeCon 2018에서 Diamanti를 처음 알게 되었으며 마이크로서비스 및 클라우드 네이티브 환경을 위해 특별히 제작되고 Kubernetes 또는 기본적으로 하이퍼컨버지드에 최적화된 베어메탈 컨테이너 플랫폼을 제공한다는 그들의 비전에 깊은 인상을 받았습니다. Kubernetes용 인프라 어플라이언스. 우리는 이것을 흥미로운 플레이로 보았고 작년 KubeCon XNUMX에서 우리는 그들과 함께 Kubernetes의 스토리지를 이해하고 Kubernetes 스토리지를 테스트하고 체계적인 방식으로 정량화하여 테스트 및 문서화를 시작할 수 있는 방법에 대해 이야기하기 시작했습니다. Kubernetes 스토리지 성능.
Diamanti는 함께 일하기에 좋았고 테스트 방법론을 만드는 데 필요한 Kubernetes 및 Kubernetes 스토리지에 대한 깊은 이해를 제공할 수 있었습니다. Diamanti는 이전 VMware, VERITAS 및 Cisco 엔지니어가 시작했으며 Goldman Sachs 및 기타 잘 알려진 VC가 자금을 지원했습니다. 인상적인 것은 Diamanti가 스토리지 및 네트워킹 표준(즉, FlexVolume/CSI)에 크게 기여했다는 것입니다. 및 CNI) 업스트림 Kubernetes 코드에 허용되었습니다.
엔터프라이즈 비즈니스는 빛의 속도로 진화하고 있으며 기업은 애플리케이션의 전체 생산 주기를 가속화하기 위해 새로운 기술로 이러한 진화에 보조를 맞추려고 노력하고 있습니다. 컨테이너는 애플리케이션 개발 및 배포를 가속화하도록 설계된 기술이었지만 레거시 인프라에 컨테이너를 구축하는 것은 복잡할 수 있으며 완전한 기능을 갖춘 컨테이너 스택을 구성하는 데 상당한 장애물이 됩니다. 컨테이너는 기존 스토리지 및 네트워크 인프라와 호환되지 않으므로 컨테이너 환경 구축에 대한 DIY(Do-it-Yourself) 접근 방식은 IT가 어렵고 비용이 많이 들며 속도가 느립니다. Diamanti Enterprise Kubernetes Platform은 인프라 아키텍트, IT 운영 및 애플리케이션 소유자에게 컨테이너화된 상태 저장 애플리케이션을 대규모로 실행하는 데 필요한 속도, 단순성, 효율성 및 제어 기능을 제공하기 위한 것입니다.
Diamanti Enterprise Kubernetes 플랫폼은 특히 대기업을 위해 빠르게 시작하고 실행하는 네트워킹 및 스토리지 측면에 중점을 둔 베어메탈 컨테이너 플랫폼입니다. 오픈 소스 Docker와 Kubernetes가 완전히 통합되고 전용 하드웨어와 전체 스택에 대한 완벽한 지원을 갖춘 Diamanti Enterprise Kubernetes Platform은 몇 분 안에 배포할 수 있는 전체 컨테이너 솔루션입니다. Diamanti는 Enterprise Kubernetes Platform에서 타의 추종을 불허하는 성능과 활용도를 자랑합니다. 이 성능의 비결은 Kubernetes 컨테이너가 네트워크 및 스토리지 리소스를 사용하는 방식을 위해 특별히 설계된 고유한 하이퍼 컨버지드 아키텍처를 사용하는 것입니다.
디아만티 D10 사양
| 네트워크 | 단일 QSFP+ 연결을 통한 4개의 10GbE(노드당) |
| 스토리지 | |
| 데이터 저장매체 | 4TB 구성(노드당 4x 1000GB NVMe SSD) 8TB 구성(노드당 4x 2000GB NVMe SSD) 32TB 구성(노드당 4x 8000GB NVMe SSD) |
| 호스트 OS 및 Docker 이미지 저장소 | 960GB(노드당 2GB SATA SSD 480개) |
| Compute | |
| CPU | 2/20/32 코어(노드당)가 있는 44x Intel Xeon 프로세서 |
| 램 | 192GB/384GB/768GB(노드당) |
| 물리적 | |
| 폼 팩터 | 1U |
| 크기 및 무게(노드당) | 17.25″W x 28″D x 1.72″H / 52lbs. 43.8cm x 71.1cm x 4.4cm / 24kg |
| 출력 | 이중 중복 110/220V 전원 공급 장치 |
| 환경 | 작동 온도 : 50 ° C ~ 95 ° C (10 ° F ~ 35 ° F) |
빌드 및 디자인
Diamanti 어플라이언스는 Diamanti 컨테이너 스택 솔루션의 물리적 하드웨어입니다. 이 어플라이언스는 최소 1노드 클러스터에서 제공되며 각 노드는 최대 32TB의 데이터 스토리지 용량과 호스트 OS 및 Docker 이미지 스토리지용 960GB를 제공하는 XNUMXU 랙입니다.
노드의 전면에는 효율적인 공기 흐름을 위해 설계된 알루미늄 그릴이 있으며 중앙에는 회사 로그가 있고 왼쪽 상단에는 잠금 장치가 있습니다. 전면 오른쪽 상단에는 시스템 상태를 나타내는 LED 표시등과 함께 전원 스위치를 제공하는 컨트롤 패널이 있습니다. 알루미늄 그릴을 제거하면 드라이브 슬롯 위치, VGA XNUMX개 및 USB 포트 XNUMX개가 나타납니다.
어플라이언스 후면으로 이동하면 장치의 포트가 보입니다. 여기서는 왼쪽 두 개의 독립 전원 공급 장치와 통풍 시스템을 강조합니다. 중간/오른쪽에는 10개의 관리 포트, 고성능 및 짧은 대기 시간으로 노드를 연결하는 4GbE 포트, QSFP+ 포트(10x4G SFP+용), 키보드 및 기타 주변 장치를 연결하는 XNUMX개의 USB 포트가 있습니다.
어플라이언스는 OS, Docker, Kubernetes 및 기타 컨테이너 융합 서비스를 포함하여 사전 통합된 전체 소프트웨어 스택과 함께 제공됩니다. 브라우저, CLI 또는 REST API 및 Diamanti OS를 통해 대시보드 및 보고 기능을 제공합니다. Diamanti Enterprise Kubernetes 플랫폼은 K8s 인증을 받았습니다. CNCF 조직에서 설계한 인증입니다.
관리를 위해 Diamanti 콘솔을 살펴봅니다. 그것을 열면 빠르게 읽을 수 있는 기본 정보가 있는 대시보드로 바로 이동합니다. 여기에서 실행 중인 노드 수, 컨테이너 수, 포드 수를 확인할 수 있습니다. CPU, 스토리지, 메모리 및 네트워크 사용량도 왼쪽에서 백분율로 쉽게 볼 수 있습니다. 오른쪽에는 Kbps 단위의 대역폭이 있습니다.
다음 기본 탭은 응용 프로그램 만들기입니다. 사용자가 원하는 애플리케이션을 갖게 되면 하위 탭은 작은 Kubernetes 아이콘이 있는 배포입니다. 여기에서 사용자는 이름, 이미지, 환경, 포트, 볼륨 마운트, CPU 및 메모리 양과 같은 정보를 입력해야 합니다.
다음 기본 탭은 응용 프로그램입니다. 기본 탭 아래에는 포드, 복제 컨트롤러, 복제 세트, 상태 저장 세트, 데몬 세트, 배포 및 작업과 같은 하위 탭이 있습니다. 포드는 사용자에게 선택한 포드의 상태에 대한 간략한 요약과 속성 컴퓨팅, 네트워크 및 스토리지를 제공합니다.
상태 저장 세트 하위 탭에서는 사용자가 세트를 더 자세히 살펴보고 필요한 경우 내보낼 수 있습니다. 여기에는 이름, 네임스페이스, 원하는 번호, 현재 번호, 준비된 번호, 연령 및 수행할 작업에 대한 옵션과 같은 기본 정보가 표시됩니다.
사용자는 포드 로그를 드릴다운하여 활동 및 잠재적인 문제를 볼 수 있습니다.
다음 기본 탭은 K8S 구성입니다. 여기에서 사용자는 서비스 계정과 같은 Kubernetes 관련 애플리케이션 구성을 관리하고 비밀, 구성 맵을 확인하고 네임스페이스를 생성할 수 있습니다.
노드 관리 탭에서 사용자는 노드 리소스 사용률을 모니터링할 뿐만 아니라 노드를 보거나 추가 또는 삭제할 수 있습니다. 여기서도 사용자는 컴퓨팅, 네트워크 및 스토리지와 같은 지정된 노드와 리소스의 전반적인 상태를 모니터링할 수 있습니다.
탭 이름에서 알 수 있듯이 스토리지 관리를 통해 사용자는 볼륨, 스냅샷, 드라이브, 영구 볼륨, 영구 볼륨 클레임, 스토리지 클래스 및 백업을 포함한 모든 스토리지를 볼 수 있습니다. 볼륨 하위 탭에서 새 볼륨을 생성하거나 상태, 스토리지 처리량 및 사용량을 포함하여 기존 볼륨의 요약을 볼 수 있는 기능이 제공됩니다.
Drives(드라이브) 하위 탭을 통해 사용자는 드라이브가 있는 슬롯, S/N, 원시 용량, 사용 가능한 용량, 할당된 용량, 펌웨어 및 현재 상태와 같은 정보와 함께 물리적 드라이브 활용을 볼 수 있습니다. 드라이브 이 하위 탭에서 형식을 지정할 수 있습니다.
Persistent Volumes(영구 볼륨) 하위 탭에서는 사용자가 영구 볼륨을 생성하거나 내보낼 수 있을 뿐만 아니라 이름, 유형 용량, 액세스, 회수, 상태, 클레임, 스토리지 가용성, 사용 기간 및 편집, 내보내기 및 작업을 포함한 작업 목록과 같은 정보를 제공할 수 있습니다. 삭제.
영구 볼륨 클레임은 PVC에 대해 위와 동일합니다.
다음 기본 탭은 네트워크 관리 탭입니다. 여기에서 사용자는 네트워크를 생성, 삭제, 편집 또는 내보낼 수 있습니다. 여기에는 이름, 그룹, 기본 네트워크 여부, 호스트 네트워크, 해당 서브넷, 게이트웨이, 시작 주소, 끝 주소 및 IP 주소와 같은 정보가 제공됩니다.
사용자 관리는 매우 간단합니다. 여기에서 관리자는 사용자 및 그룹을 생성하고 액세스 제어를 위한 다양한 정책을 설정할 수 있습니다.
고급 설정을 통해 관리자는 클러스터 및 성능 계층을 만들고 조정할 수 있습니다.
우리는 일반적으로 다양한 관리 기능을 통해 독자가 무언가를 진행할 때 무엇을 기대해야 하는지에 대한 일반적인 아이디어를 제공하지만 이번에는 약간 다른 작업을 수행하고 있습니다. 또한 우리는 벤치마크를 실행하여 더 많은 워크로드가 실행될 때 GUI가 무엇을 하는지 확인할 수 있었습니다. 이러한 각 벤치마크에 대해 Node Administrations 탭에 있습니다.
기본(무작위 및 순차) 테스트를 통해 오른쪽에 있는 성능 메트릭뿐만 아니라 컴퓨팅에 대한 무승부를 쉽게 확인할 수 있습니다.
우리의 SQL 테스트는 스토리지가 거의 1만 IOPS에 도달하는 동안 컴퓨팅 및 네트워크에 상당히 가벼운 피해를 입혔습니다.
마지막으로 Oracle 테스트가 실행되는 동안 기대되는 사항에 대한 예를 제공합니다.
퍼포먼스
VDBench 워크로드 분석
스토리지 어레이를 벤치마킹할 때 애플리케이션 테스트가 가장 좋고 합성 테스트가 두 번째입니다. 실제 워크로드를 완벽하게 나타내지는 못하지만 합성 테스트는 경쟁 솔루션 간의 비교를 쉽게 수행할 수 있는 반복성 요소로 스토리지 장치의 기준선을 만드는 데 도움이 됩니다. 이러한 워크로드는 "포 코너" 테스트 및 일반적인 데이터베이스 전송 크기 테스트에 이르는 다양한 테스트 프로필과 다양한 VDI 환경의 추적 캡처를 제공합니다. 이러한 모든 테스트는 스크립팅 엔진과 함께 공통 Vdbench 워크로드 생성기를 활용하여 대규모 컴퓨팅 테스트 클러스터에서 결과를 자동화하고 캡처합니다. 이를 통해 플래시 어레이 및 개별 저장 장치를 포함한 광범위한 저장 장치에서 동일한 작업 부하를 반복할 수 있습니다.
프로필 :
- 4K 임의 읽기: 100% 읽기, 128 스레드, 0-120% iorate
- 4K 임의 쓰기: 100% 쓰기, 64 스레드, 0-120% iorate
- 64K 순차 읽기: 100% 읽기, 16 스레드, 0-120% iorate
- 64K 순차 쓰기: 100% 쓰기, 8개 스레드, 0-120% 속도
- 합성 데이터베이스: SQL 및 Oracle
모든 VDBench 테스트에서 한 번에 3, 6, 9 또는 12개의 Vdbench 포드를 실행하는 다양한 배포를 기반으로 Diamanti 어플라이언스를 테스트하여 어플라이언스의 한계를 뛰어 넘었습니다. 무작위 4K 읽기 성능으로 시작하여 모든 Vdbench 포드는 120μs의 대기 시간으로 시작했습니다. 3 IOPS의 95,863개 포드와 12 IOPS의 269,208개 포드 사이의 IO 성능. 최고 성능을 살펴보면 모든 구성이 600μs 대기 시간 미만으로 유지되었습니다. 3개의 Vdbench 포드를 사용하여 947,619μs의 대기 시간에서 최고 370 IOPS를 확인했습니다. 포드 6개, 최대 1,745,344 IOPS, 대기 시간 436μs 9개의 포드, 2,492019μs의 대기 시간에서 최고 447 IOPS; 마지막 배포인 12개의 포드는 2,753,170μs의 대기 시간과 함께 554 IOPS로 정점을 찍었습니다.
4K 쓰기 성능을 살펴보면 모든 테스트 배포는 300μs의 대기 시간에서 시작되었지만 최대 성능에 도달하면 26ms에서 28ms 사이에서 빠르게 증가했습니다. 성능은 3 IOPS에서 13,719개의 포드로 정점을 찍었습니다. 6 IOPS에서 포드 27,747개; 9 IOPS에서 포드 42,805개; 12 IOPS에서 58,559개의 포드가 있습니다. 더 많은 팟(Pod)을 추가할 때 꾸준한 성능 향상을 보여줍니다.
순차 워크로드로 전환하면서 어플라이언스의 64K 읽기 성능을 살펴보고 여기에서 3개의 포드 배포가 14,560μs의 대기 시간으로 910 IOPS 또는 297MB/s에서 시작되었습니다. 다른 모든 배포는 대기 시간이 18,000μs인 1.1 IOPS 또는 227GB/s 근처에서 시작되었습니다. 배포의 최고 성능과 관련하여 3개의 팟 배포는 143,431μs의 대기 시간에서 9 IOPS 또는 327GB/s로 정점에 도달했습니다. 다른 모든 배포는 179,000 IOPS 또는 11.1GB/s의 거의 동일한 성능으로 정점을 찍었으며 12개의 포드 배포는 1ms 대기 시간을 통과한 유일한 배포였습니다.
64K 순차 쓰기에서 Vdbench의 모든 배포는 350μs에 가까운 대기 시간에서 시작되었습니다. 배포는 다음과 같이 정점에 달했습니다. 3 IOPS 또는 9,693MB/s에서 606ms의 지연 시간을 갖는 4.9개의 포드; 6개의 포드, 22,202 IOPS 또는 1.39GB/s, 대기 시간 4.3ms 9개의 포드는 30,475 IOPS 또는 1.9GB/s, 대기 시간은 4.7ms입니다. 마지막으로 12개의 팟은 32,052ms의 대기 시간과 함께 2.4 IOPS 또는 4.9GB/s로 정점을 찍었습니다.
다음 테스트 세트는 SQL, SQL 90-10 및 SQL 80-20과 같은 SQL 워크로드입니다. SQL의 경우 모든 배포가 180μs 대기 시간에서 시작되었습니다. 3개의 포드는 26,291 IOPS에서 시작하여 261,573μs의 대기 시간과 함께 366 IOPS에서 정점에 도달했습니다. 6개의 팟은 57,061 IOPS에서 최대 570,642 IOPS, 지연 시간은 336μs였습니다. 9개의 포드는 86,197 IOPS에서 시작하여 885,269μs의 대기 시간과 함께 332 IOPS에서 정점에 도달했습니다. 그리고 12개의 포드 배포는 101,753 IOPS에서 시작하여 1,106,860μs의 대기 시간과 함께 346 IOPS에서 최고조에 달했습니다.
SQL 90-10의 경우 모든 배포가 200μs 대기 시간에 가깝게 시작되었습니다. 3개의 포드 배포는 10,753 IOPS에서 시작하여 105,877μs의 대기 시간과 함께 904 IOPS에서 최고조에 달했습니다. 6개의 팟은 49,361 IOPS에서 최대 245,158 IOPS, 대기 시간은 782μs였습니다. 9개의 포드는 80,157 IOPS에서 시작하여 401,444μs의 대기 시간과 함께 716 IOPS에서 정점에 도달했습니다. 그리고 12개의 포드 배포는 55,748 IOPS에서 시작하여 554,685μs의 대기 시간과 함께 690 IOPS에서 최고조에 달했습니다.
마지막 SQL 테스트인 80-20에서는 Vdbench 배포가 200μs 대기 시간에 매우 가깝게 시작되는 것을 확인했습니다. 배포는 다음과 같이 최고조에 달했습니다. 지연 시간이 3ms인 57,944 IOPS의 1.6개 포드 배포 6개의 포드는 132,384ms의 대기 시간과 함께 1.4 IOPS로 정점을 찍었습니다. 대기 시간이 9ms인 포드 217,273개는 1.3 IOPS입니다. 그리고 12개의 포드 배포는 305,426ms의 대기 시간과 함께 1.2 IOPS로 정점을 찍었습니다.
다음은 Oracle 워크로드인 Oracle, Oracle 90-10 및 Oracle 80-20입니다. Oracle을 사용하면 모든 배포가 210μs 미만에서 시작되었습니다. 여기에서 배포의 최고 성능을 볼 수 있습니다. 3개의 팟은 54,844ms의 대기 시간과 함께 2.2 IOPS로 정점을 찍었습니다. 6개의 포드는 125,633ms의 대기 시간과 함께 1.9 IOPS로 정점을 찍었습니다. 9개의 포드는 206,024ms의 대기 시간과 함께 1.7 IOPS로 정점을 찍었습니다. 그리고 12개의 포드 배포는 290,313ms의 대기 시간과 함께 1.6 IOPS로 최고조에 달했습니다.
Oracle 90-10에서 배포는 200μs 미만에서 시작되었습니다. 3개의 포드 배포는 106,182μs의 대기 시간과 함께 620 IOPS에서 최고조에 달했습니다. 6개의 포드는 243,383μs의 대기 시간과 함께 541 IOPS로 정점을 찍었습니다. 9개의 포드는 393,727μs의 대기 시간과 함께 502 IOPS로 정점을 찍었습니다. 그리고 마지막으로 12개의 포드 배포는 544,584μs의 대기 시간과 함께 483 IOPS로 최고조에 달했습니다.
Oracle 80-20의 경우 모든 배포가 210μs의 대기 시간에서 시작되는 것을 한 번 더 확인했습니다. 배포의 최고 성능을 살펴보면 3개의 팟이 58,037ms의 대기 시간과 함께 1.1 IOPS로 정점을 찍는 것을 볼 수 있습니다. 6μs의 대기 시간과 함께 132,911 IOPS에서 정점에 도달한 991개의 포드; 9μs의 대기 시간과 함께 215,817 IOPS에서 정점에 도달한 915개의 포드; 마지막으로 12개의 포드 배포는 304,391μs의 대기 시간과 함께 865 IOPS에서 최고조에 달했습니다.
결론
쿠버네티스는 소규모 기업에서 받아들여졌고 이제 Fortune지 선정 500대 기업 전부는 아니더라도 대부분의 기업이 검토하고 있으며 일부 더 미래 지향적인 기업이 구현하기 시작한 기술로 성숙해 가고 있습니다. 쿠버네티스는 출시된 지 5년 밖에 되지 않았지만 기술 채택 곡선에서 혁신가의 트랑슈를 통과했으며 확고하게 얼리 어답터 진영에 있습니다. 쿠버네티스 커뮤니티가 쿠버네티스를 실행하는 방법을 알아냈고 이제 제대로 실행되도록 하는 데 집중하고 있기 때문에 기술 채택 곡선에 대한 이러한 포지셔닝이 중요합니다. 우리는 이와 같은 테스트가 쿠버네티스 소비자가 어떤 공급업체와 함께 갈지 결정하는 데 도움이 되기를 바랍니다. 판매자에게 자신을 비교할 수 있는 표준을 제공함으로써 판매자를 돕습니다.
Diamanti는 D10 컨테이너 어플라이언스와 함께 강력한 Kubernetes 솔루션을 구축하여 유익하고 사용하기 쉬운 관리 인터페이스와 컨테이너 호스팅을 위한 매우 빠른 백엔드 스토리지 플랫폼을 제공합니다. 이것은 여전히 신흥 분야이기 때문에 시장에 완전히 구체화된 솔루션이 많지는 않지만 D10은 우리가 전통적으로 스토리지 또는 HCI 솔루션. 성능은 일반적으로 환상적이며 클러스터 테스트에서 2.7~4개의 포드에서 3만 이상의 IOP 12K 무작위 읽기를 제공합니다. 대기 시간 관점에서 우리는 100마이크로초를 약간 넘는 수준에서 시작하여 600마이크로초에서 정점을 찍었습니다. 믿을 수 없을 정도로 뛰어난 스토리지 측면과 매우 놀라운 신흥 기술 플랫폼에서 말입니다. 쓰기 관점에서 어플라이언스는 50k IOPS 4K 랜덤을 제공했는데, 이것이 유일한 약점인 것 같지만 회사가 소프트웨어 또는 스토리지 미디어를 통해 해결할 수 있어야 합니다. 순차 대역폭은 11GB/s를 초과하는 읽기 속도를 제공했으며, 다시 한 번 매우 강력하고 사용 가능한 성능을 제공했으며 쓰기 속도는 최대 2.4GB/s입니다.
전반적으로 환경에 Kubernetes를 배포하는 고객을 위해 Diamanti D10 컨테이너 어플라이언스는 빠르고 느슨한 컨테이너 시장을 진지하게 살펴보려는 사람들을 위해 호스팅 및 스토리지 관점에서 훌륭한 턴키 접근 방식을 제공합니다. 공정하게 말하면 이것은 모든 사람을 위한 것이 아니며 클러스터는 대상 지정이 매우 구체적입니다. 그러나 Diamanti는 해당 고객이 원하는 것을 정확하게 제공하는 대상에 맞으면 이러한 유형의 새로운 컨테이너 워크로드를 위해 특별히 제작되었습니다. 물론 PKS for VMware 또는 엔터프라이즈 중심의 대체 솔루션을 활용하는 것은 전적으로 가능하지만 Diamanti는 복잡성이 낮고 기존 엔터프라이즈 스택보다 비용 이점이 있는 시스템을 제공합니다. 솔루션의 완성도(변경에 적합한 GUI가 있음)와 매우 우수한 성능 프로필로 인해 우리는 D10을 StorageReview Editor's Choice Award의 수상자로 결정했습니다.
