Red Hat Summit4.4. 스토리지에서 사용되는 아키텍처
4.4.4절. “스토리지에서 사용되는 아키텍처 고려 사항”
4.4.1. 스토리지에서 사용되는 아키텍처 유형
클라우드 스토리지 모델은 물리적 스토리지 장치의 논리 풀에 데이터를 저장합니다. 이러한 아키텍처는 종종 통합 스토리지 클라우드라고 합니다.
클라우드 스토리지는 일반적으로 호스팅된 오브젝트 스토리지 서비스를 나타냅니다. 그러나 용어에는 서비스로 사용할 수 있는 다른 유형의 데이터 스토리지도 포함될 수 있습니다. OpenStack은 Block Storage(cinder) 및 Object Storage(swift)를 모두 제공합니다. 클라우드 스토리지는 일반적으로 가상 인프라에서 실행되며 인터페이스 접근성, 탄력성, 확장성, 멀티 테넌시 및 측정된 리소스의 광범위한 클라우드 컴퓨팅과 유사합니다.
온프레미스 또는 오프-프레미스 클라우드 스토리지 서비스를 사용할 수 있습니다. 클라우드 스토리지는 중복 및 데이터 배포로 높은 내결함성을 가지며 버전 지정된 사본으로 매우 내구성이 뛰어나며 일관된 데이터 복제를 수행할 수 있습니다.
클라우드 스토리지 애플리케이션의 예는 다음과 같습니다.
- 활성 아카이브, 백업 및 계층적 스토리지 관리
- 개인 DropBox 서비스와 같은 일반 콘텐츠 스토리지 및 동기화
- 병렬 파일 시스템을 통한 데이터 분석
- 소셜 미디어 백엔드 스토리지와 같은 서비스를 위한 비정형 데이터 저장소
- 영구 블록 스토리지
- 운영 체제 및 애플리케이션 이미지 저장소
- 미디어 스트리밍
- 데이터베이스
- 콘텐츠 배포
- 클라우드 스토리지 피어링
OpenStack 스토리지 서비스에 대한 자세한 내용은 1.2.2절. “OpenStack Object Storage(swift)” 및 1.2.1절. “OpenStack Block Storage(cinder)” 을 참조하십시오.
4.4.2. 데이터 분석 아키텍처
대규모 데이터 세트의 분석은 스토리지 시스템의 성능에 따라 크게 달라집니다. 병렬 파일 시스템은 고성능 데이터 처리를 제공할 수 있으며 대규모 성능 중심 시스템에 권장됩니다.
설치 및 배포 문서는 5장. 배포 정보 에서 참조하십시오.
4.4.2.1. 설계 정보
OpenStack Data Processing(sahara)은 HDFS와 통합되어 클라우드 내에서 HDFS 클러스터를 관리합니다. 다음 다이어그램에서는 고성능 요구 사항이 있는 OpenStack 저장소를 보여줍니다.
하드웨어 요구 사항 및 구성은 4.4.3절. “고성능 데이터베이스 아키텍처” 에 설명된 고성능 아키텍처와 유사합니다. 이 예에서 아키텍처는 캐싱 풀에 연결하고 사용 가능한 풀을 가속화하는 Ceph Swift 호환 REST 인터페이스를 사용합니다.
4.4.2.2. 아키텍처 구성 요소
| Component | 설명 |
|---|---|
| Compute | 컨트롤러에서 실행되는 컴퓨팅 관리 및 스케줄링 서비스. Compute 서비스는 각 컴퓨팅 노드에서도 실행됩니다. |
| 대시보드 | OpenStack 관리를 위한 웹 콘솔. |
| ID | 기본 인증 및 권한 부여 기능 |
| 이미지 | 인스턴스 부팅 및 스냅샷 관리에 사용할 이미지를 저장합니다. 이 서비스는 컨트롤러에서 실행되며 작은 이미지 세트를 제공합니다. |
| 네트워킹 | 네트워킹 서비스. OpenStack 네트워킹에 대한 자세한 내용은 2장. 네트워킹 In-Depth 을 참조하십시오. |
| telemetry | 기타 OpenStack 서비스에 대한 모니터링 및 보고. 이 서비스를 사용하여 인스턴스 사용량을 모니터링하고 프로젝트 할당량을 조정합니다. |
| 오브젝트 스토리지 | HDFS 백엔드에 데이터를 저장합니다. |
| 블록 스토리지 | 0.0.0.0 백엔드와 함께 볼륨을 저장합니다. |
| 오케스트레이션 | 인스턴스 및 블록 스토리지 볼륨의 템플릿을 관리합니다. 자동 확장을 위해 Telemetry를 사용하여 스토리지 집약적인 처리를 위해 추가 인스턴스를 시작하려면 이 서비스를 사용합니다. |
4.4.2.3. 클라우드 요구 사항
| 요구 사항 | 설명 |
|---|---|
| 성능 | 성능을 높이기 위해 특수 솔루션을 선택하여 디스크 활동을 캐시할 수 있습니다. |
| 보안 | 전송 중 및 미사용 중 데이터를 보호해야 합니다. |
| 스토리지 근접성 | 고성능 또는 대량의 스토리지 공간을 제공하려면 각 하이퍼바이저에 스토리지를 연결하거나 중앙 스토리지 장치에서 제공해야 할 수 있습니다. |
4.4.2.4. 설계 고려 사항
3장. 설계 에 설명된 기본 설계 고려 사항 외에도 4.4.4절. “스토리지에서 사용되는 아키텍처 고려 사항” 에 설명된 고려 사항도 따라야 합니다.
4.4.3. 고성능 데이터베이스 아키텍처
데이터베이스 아키텍처는 고성능 스토리지 백엔드의 이점을 제공합니다. 엔터프라이즈 스토리지는 필수 사항은 아니지만 많은 환경에 OpenStack 클라우드가 백엔드로 사용할 수 있는 스토리지가 포함되어 있습니다.
스토리지 풀을 생성하여 인스턴스 및 오브젝트 인터페이스에 OpenStack Block Storage에 블록 장치를 제공할 수 있습니다. 이 아키텍처 예에서 데이터베이스 I/O 요구 사항은 빠른 SSD 풀의 높은 스토리지입니다.
4.4.3.1. 설계 정보
스토리지 시스템은 기존 스토리지 어레이에서 SSD 세트와 함께 지원되는 LUN을 사용하며 OpenStack 블록 스토리지 통합 또는 Ceph와 같은 스토리지 플랫폼을 사용합니다.
이 시스템은 추가 성능 기능을 제공할 수 있습니다. 데이터베이스 예에서 SSD 풀의 일부가 데이터베이스 서버에 대한 블록 장치로 작동할 수 있습니다. 고성능 분석 예에서 인라인 SSD 캐시 계층은 REST 인터페이스를 가속화합니다.
이 예제에서 Ceph는 Swift 호환 REST 인터페이스와 분산 스토리지 클러스터의 블록 수준 스토리지를 제공합니다. 유연하며 자동 복구 및 자동 분산과 같은 기능을 통해 운영 비용을 줄일 수 있습니다. 코딩된 풀 삭제는 사용 가능한 공간을 극대화하는 것이 좋습니다.
코딩된 풀에는 높은 컴퓨팅 요구 사항 및 개체에서 작업을 허용하는 제한과 같은 특수한 고려 사항이 필요합니다. 코딩된 풀 삭제는 부분 쓰기를 지원하지 않습니다.
4.4.3.2. 아키텍처 구성 요소
| Component | 설명 |
|---|---|
| Compute | 컨트롤러에서 실행되는 컴퓨팅 관리 및 스케줄링 서비스. Compute 서비스는 각 컴퓨팅 노드에서도 실행됩니다. |
| 대시보드 | OpenStack 관리를 위한 웹 콘솔. |
| ID | 기본 인증 및 권한 부여 기능 |
| 이미지 | 인스턴스 부팅 및 스냅샷 관리에 사용할 이미지를 저장합니다. 이 서비스는 컨트롤러에서 실행되며 작은 이미지 세트를 제공합니다. |
| 네트워킹 | 네트워킹 서비스. OpenStack 네트워킹에 대한 자세한 내용은 2장. 네트워킹 In-Depth 을 참조하십시오. |
| telemetry | 기타 OpenStack 서비스에 대한 모니터링 및 보고. 이 서비스를 사용하여 인스턴스 사용량을 모니터링하고 프로젝트 할당량을 조정합니다. |
| 모니터링 | 프로젝트 할당량을 조정할 목적으로 Telemetry 서비스를 사용하여 미터링을 수행합니다. |
| 오브젝트 스토리지 | Ceph 백엔드와 함께 데이터를 저장합니다. |
| 블록 스토리지 | Ceph 백엔드와 함께 볼륨을 저장합니다. |
| 오케스트레이션 | 인스턴스 및 블록 스토리지 볼륨의 템플릿을 관리합니다. 자동 확장을 위해 Telemetry를 사용하여 스토리지 집약적인 처리를 위해 추가 인스턴스를 시작하려면 이 서비스를 사용합니다. |
4.4.3.3. 하드웨어 요구 사항
SSD 캐시 계층을 사용하여 블록 장치를 하이퍼바이저 또는 인스턴스에 직접 연결할 수 있습니다. REST 인터페이스는 SSD 캐시 시스템을 인라인 캐시로 사용할 수도 있습니다.
| Component | 요구 사항 | 네트워크 |
|---|---|---|
| 수평으로 확장 가능한 스파인-리프트 백엔드 스토리지 및 프론트 엔드 네트워크 10GbE | 스토리지 하드웨어 | * 캐싱 계층 24x1 TB SSD를 위한 5 스토리지 서버 * 각 서버에 대해 12x4TB 디스크가 12x4TB인 10개의 스토리지 서버, 3개의 복제본 후 약 160TB의 사용 가능한 공간이 있는 480TB의 총 공간 |
4.4.3.4. 설계 고려 사항
3장. 설계 에 설명된 기본 설계 고려 사항 외에도 4.4.4절. “스토리지에서 사용되는 아키텍처 고려 사항” 에 설명된 고려 사항도 따라야 합니다.
4.4.4. 스토리지에서 사용되는 아키텍처 고려 사항
3장. 설계 에 설명된 기본 설계 고려 사항 및 3.3절. “스토리지 리소스” 에 설명된 스토리지 노드 설계 외에도 스토리지 집약적인 아키텍처에서는 다음 항목을 고려해야 합니다.
- 연결
- 연결이 스토리지 솔루션 요구 사항과 일치하는지 확인합니다. 중앙 집중식 스토리지 어레이를 선택하는 경우 하이퍼바이저를 배열에 연결하는 방법을 결정합니다. 연결은 대기 시간과 성능에 영향을 줄 수 있습니다. 네트워크 특성이 설계의 전반적인 성능을 높이기 위해 대기 시간을 최소화하는지 확인합니다.
- 밀도
- 인스턴스 밀도. 스토리지 중심 아키텍처에서는 인스턴스 밀도 및 CPU/RAM 초과 구독이 더 낮습니다. 특히 설계에서 듀얼 소켓 하드웨어 설계를 사용하는 경우 예상되는 규모를 지원하기 위해 더 많은 호스트가 필요합니다.
- 호스트 밀도. 쿼드 소켓 플랫폼으로 더 높은 호스트 수를 처리할 수 있습니다. 이 플랫폼은 호스트 밀도를 줄이고 랙 수를 늘립니다. 이 구성은 전원 연결 수에 영향을 미치며 네트워크 및 공약 요구 사항에도 영향을 미칩니다.
- 전력 및 연약. 전력 및 혼합 밀도 요구 사항은 블레이드, 슬라이 또는 1U 서버 설계보다 2U, 3U 또는 4U 서버로 더 낮을 수 있습니다. 이 구성은 이전 인프라가 있는 데이터 센터에 권장됩니다.
- 유연성
- 조직은 온프레미스 클라우드 스토리지 옵션과 온프레미스 클라우드 스토리지 옵션 중에서 선택할 수 있는 유연성을 갖추고 있어야 합니다. 예를 들어 운영, 재해 복구, 보안 및 기록의 연속성은 보존 법률, 규정 및 정책을 기록하여 스토리지 공급자의 비용 효율성에 영향을 미칠 수 있습니다.
- latency
- SSD(Solid-State Drive)는 인스턴스 스토리지의 대기 시간을 최소화하고 스토리지 대기 시간이 발생할 수 있는 CPU 지연을 줄일 수 있습니다. 컴퓨팅 호스트에서 RAID 컨트롤러 카드를 사용하여 기본 디스크 하위 시스템의 성능을 개선할 때의 이점을 평가합니다.
- 모니터 및 경고
모니터링 및 경고 서비스는 스토리지 리소스에 대한 높은 요구 사항이 있는 클라우드 환경에서 중요합니다. 이러한 서비스는 스토리지 시스템의 상태 및 성능에 대한 실시간 보기를 제공합니다. 통합 관리 콘솔 또는 SNMP 데이터를 시각화하는 다른 대시보드는 스토리지 클러스터 문제를 검색하고 해결하는 데 도움이 됩니다.
스토리지 중심 클라우드 설계에는 다음이 포함되어야 합니다.
- 온도 및 유해와 같은 물리적 하드웨어 및 환경 리소스 모니터링.
- 사용 가능한 스토리지, 메모리 및 CPU와 같은 스토리지 리소스 모니터링.
- 스토리지 시스템이 예상대로 수행되도록 고급 스토리지 성능 데이터 모니터링.
- 스토리지 액세스에 영향을 주는 서비스 중단에 대한 네트워크 리소스 모니터링.
- 중앙 집중식 로그 수집 및 로그 분석 기능.
- 티켓팅 시스템 또는 티켓팅 시스템과의 통합을 통해 문제를 추적합니다.
- 스토리지 문제가 발생할 때 문제를 해결할 수 있는 책임이 있는 팀 또는 자동화된 시스템에 대한 경고 및 알림.
- NOC(Network Operations Center) 직원이 근무하고 항상 문제를 해결할 수 있습니다.
- 스케일링
- 스토리지 중심 OpenStack 아키텍처는 확장 대신 확장에 중점을 두어야 합니다. 비용, 전력, 순환, 물리적 랙 및 플로어 공간, 지원 경고 및 관리 용이성과 같은 요인에 따라 더 적은 수의 대규모 호스트 또는 더 적은 수의 호스트를 확인해야 합니다.
