3.3. 스토리지 리소스

클라우드 스토리지 솔루션을 효과적으로 사용하려면 애플리케이션이 기본 스토리지 하위 시스템을 알고 있어야 합니다. 기본적으로 사용 가능한 복제를 사용할 수 없는 경우 운영 직원은 복제 서비스를 제공하도록 애플리케이션을 구성할 수 있어야 합니다.

기본 스토리지 시스템을 감지할 수 있는 애플리케이션은 다양한 인프라에서 작동할 수 있으며 기본 인프라의 차이점에 관계없이 동일한 기본 동작을 수행합니다.

입력 출력 성능에 대한 벤치마크에서는 예상되는 성능 수준에 대한 기준을 제공합니다. 벤치마크 결과 데이터는 다양한 로드 하에서 동작을 모델링하는 데 도움이 될 수 있으며 적합한 아키텍처를 설계하는 데 도움이 될 수 있습니다.

아키텍처 라이프사이클 동안 스크립팅된 소형 벤치마크는 다른 시간에 시스템 상태를 기록하는 데 도움이 될 수 있습니다. 스크립팅된 벤치마크의 데이터는 범위를 지원하고 조직의 요구 사항을 보다 깊이 이해하는 데 도움이 될 수 있습니다.

오브젝트 데이터에 필요한 가용성 수준을 제공하도록 오브젝트 스토리지 리소스 풀을 설계합니다. 필요한 복제본 수를 수용하려면 랙 수준 및 영역 수준 설계를 고려하십시오. 복제본의 지연 수는 3입니다. 각 데이터 복제본은 특정 영역에 서비스를 제공하는 독립적인 전력, 혼잡 및 네트워크 리소스가 있는 별도의 가용성 영역에 있어야 합니다.

OpenStack Object Storage 서비스는 특정 수의 데이터 복제본을 리소스 노드에 오브젝트로 배치합니다. 이러한 복제본은 클러스터의 모든 노드에 존재하는 일관된 해시 링을 기반으로 클러스터에 배포됩니다. 또한 오브젝트 노드에 저장된 데이터에 대한 액세스를 제공하는 Object Storage 프록시 서버 풀은 각 가용성 영역을 서비스해야 합니다.

복제본 수에 필요한 최소 응답을 제공하기 위해 충분한 영역 수를 사용하여 Object Storage 시스템을 설계합니다. 예를 들어 Swift 클러스터에서 복제본 3개를 구성하는 경우 Object Storage 클러스터 내부에 구성할 권장 영역 수는 5개입니다.

영역 수가 적은 솔루션을 배포할 수 있지만 일부 데이터를 사용할 수 없으며 클러스터에 저장된 일부 오브젝트에 대한 API 요청이 실패할 수 있습니다. 따라서 Object Storage 클러스터의 영역 수를 고려해야 합니다.

각 리전의 오브젝트 프록시는 로컬 읽기 및 쓰기 선호도를 활용하여 가능한 경우 오브젝트에 대한 액세스를 용이하게 합니다. 프록시 서비스가 여러 영역에 분산되도록 업스트림 로드 밸런싱을 배포해야 합니다. 경우에 따라 서비스의 지리적 배포를 지원하기 위해 타사 솔루션이 필요할 수 있습니다.

Object Storage 클러스터 내의 영역은 논리 분할이며 단일 디스크, 노드, 노드 컬렉션, 여러 랙 또는 여러 DC로 구성할 수 있습니다. 사용 가능한 중복 스토리지 시스템을 제공하는 동안 Object Storage 클러스터를 확장할 수 있어야 합니다. 특정 영역의 스토리지 설계에 영향을 줄 수 있는 복제본, 보존 및 기타 요인에 대한 다양한 요구 사항으로 스토리지 정책을 구성해야 할 수 있습니다.

OpenStack Object Storage에 대한 하드웨어 리소스를 설계할 때 주요 목표는 각 리소스 노드의 스토리지 크기를 최대화하면서 테라바이트당 비용이 최소로 유지되도록 하는 것입니다. 이는 종종 많은 회전 디스크를 보유할 수 있는 서버를 활용하는 것과 관련이 있습니다. 연결된 스토리지와 함께 2U 서버 폼 인수를 사용하거나 더 많은 수의 드라이브를 보유하는 외부 섀시와 함께 사용할 수 있습니다.

OpenStack Object Storage의 일관성 및 파티션 허용 특성은 특수한 데이터 복제 장치를 사용하지 않고도 데이터가 최신 상태를 유지하고 하드웨어 결함을 유지할 수 있도록 합니다.

OpenStack Object Storage는 swift 링 내부의 가중치와 함께 드라이브를 혼합하고 일치시킬 수 있는 기능을 제공합니다. 신속한 스토리지 클러스터를 설계할 때 가장 비용 효율적인 스토리지 솔루션을 사용할 수 있습니다.

많은 서버 섀시는 랙 공간의 4U에 60개 이상의 드라이브를 저장할 수 있습니다. 따라서 테라바이트당 최상의 비용으로 각 랙 유닛의 스토리지 용량을 최대화할 수 있습니다. 그러나 오브젝트 스토리지 노드에서 RAID 컨트롤러를 사용하지 않는 것이 좋습니다.

스토리지 솔루션을 설계할 때 Object Storage 서비스에 필요한 최대 파티션 전원을 확인한 다음 생성할 수 있는 최대 파티션 수를 결정해야 합니다. 오브젝트 스토리지는 전체 스토리지 클러스터에 데이터를 배포하지만 각 파티션은 두 개 이상의 디스크에 걸쳐 있을 수 없습니다. 따라서 최대 파티션 수는 디스크 수를 초과할 수 없습니다.

예를 들어 초기 단일 디스크가 있는 시스템과³의 파티션 전원이 8개(23 ) 파티션을 보유할 수 있습니다. 두 번째 디스크를 추가하면 각 디스크가 4개의 파티션을 유지할 수 있습니다. one-disk-per-partition 제한은 이 시스템에 디스크가 8개를 초과할 수 없고 확장성을 제한할 수 없음을 의미합니다. 그러나 초기 단일 디스크와 파티션 전원이¹⁰인 시스템은 최대 1024(210 ) 파티션을 가질 수 있습니다.

시스템 백엔드 스토리지 용량을 늘릴 때마다 파티션 맵은 스토리지 노드에서 데이터를 재배포합니다. 경우에 따라 이 복제는 매우 큰 데이터 세트로 구성됩니다. 이러한 경우 데이터에 대한 테넌트 액세스와 충돌하지 않는 백엔드 복제 링크를 사용해야 합니다.

더 많은 테넌트가 클러스터의 데이터에 액세스하고 데이터 세트가 증가하면 서비스 데이터 액세스 요청에 프런트 엔드 대역폭을 추가해야 합니다. Object Storage 클러스터에 프런트 엔드 대역폭을 추가하려면 테넌트가 프록시 계층을 확장할 수 있는 고가용성 솔루션과 함께 테넌트가 데이터에 액세스하는 데 사용할 수 있는 Object Storage 프록시를 설계해야 합니다.

테넌트와 소비자가 클러스터 내에 저장된 데이터에 액세스하기 위해 사용하는 프런트 엔드 로드 밸런싱 계층을 설계해야 합니다. 이 로드 밸런싱 계층은 영역, 지역 또는 지역에 분산될 수 있습니다.

프록시 서버와 스토리지 노드 간에 서비스 요청을 하는 네트워크 리소스에 대역폭과 용량을 추가해야 하는 경우도 있습니다. 따라서 스토리지 노드 및 프록시 서버에 대한 액세스를 제공하는 네트워크 아키텍처는 확장 가능해야 합니다.

애플리케이션의 IOPS(초당 입출력) 수요는 RAID 컨트롤러를 사용해야 하는지 여부와 필요한 RAID 수준을 결정합니다. 중복성의 경우 RAID 5 또는 RAID 6과 같은 중복 RAID 구성을 사용해야 합니다. 블록 스토리지 볼륨의 자동화된 복제와 같은 일부 특수 기능에는 높은 수요를 처리하기 위해 타사 플러그인 또는 엔터프라이즈 블록 스토리지 솔루션이 필요할 수 있습니다.

블록 스토리지에 대한 극단적인 수요가 있는 환경에서는 여러 스토리지 풀을 사용해야 합니다. 각 장치 풀에는 해당 풀의 모든 하드웨어 노드에서 유사한 하드웨어 설계 및 디스크 구성이 있어야 합니다. 이러한 설계를 통해 애플리케이션은 다양한 중복성, 가용성 및 성능 특성을 갖춘 다양한 Block Storage 풀에 액세스할 수 있습니다.

네트워크 아키텍처는 인스턴스에서 사용 가능한 스토리지 리소스를 사용하는 데 필요한 동부 서부 대역폭의 양도 고려해야 합니다. 선택한 네트워크 장치는 대규모 데이터 블록을 전송하기 위해 점보 프레임을 지원해야 합니다. 네트워크 리소스에 대한 부하를 줄이기 위해 인스턴스 및 블록 스토리지 리소스 간 연결을 제공하기 위해 추가 전용 백엔드 스토리지 네트워크를 생성해야 하는 경우도 있습니다.

여러 스토리지 풀을 배포할 때 리소스 노드에 스토리지를 프로비저닝하는 Block Storage 스케줄러에 미치는 영향을 고려해야 합니다. 애플리케이션이 특정 네트워크, 전원 및 단조 인프라가 있는 여러 리전의 볼륨을 예약할 수 있도록 합니다. 이 설계를 통해 테넌트는 여러 가용성 영역에 분산된 내결함성 애플리케이션을 빌드할 수 있습니다.

블록 스토리지 리소스 노드 외에도 스토리지 노드를 프로비저닝하고 액세스를 제공하는 API 및 관련 서비스의 고가용성 및 중복을 설계하는 것이 중요합니다. 중단되지 않는 서비스를 제공하기 위해 REST API 서비스의 고가용성을 달성하려면 하드웨어 또는 소프트웨어 로드 밸런서 계층을 설계해야 합니다.

경우에 따라 블록 스토리지 볼륨의 상태를 서비스하고 저장하는 백엔드 데이터베이스 서비스에 대한 액세스를 제공하기 위해 추가 로드 밸런싱 계층을 배포해야 할 수 있습니다. MariaDB 및 Galera와 같은 Block Storage 데이터베이스를 저장하려면 고가용성 데이터베이스 솔루션을 설계해야 합니다.

블록 스토리지 서비스는 하드웨어 벤더가 개발한 플러그인 드라이버를 사용하여 엔터프라이즈 스토리지 솔루션을 활용할 수 있습니다. OpenStack 블록 스토리지와 함께 기본적으로 제공되는 다수의 엔터프라이즈 플러그인과 타사 채널을 통해 다른 플러그인을 사용할 수 있습니다.

범용 클라우드는 일반적으로 대부분의 블록 스토리지 노드에서 직접 연결된 스토리지를 사용합니다. 따라서 테넌트에 추가 수준의 서비스를 제공해야 할 수 있습니다. 이러한 수준은 엔터프라이즈 스토리지 솔루션에서만 제공될 수 있습니다.

전체 블록 스토리지 서비스에 중단되지 않고 블록 스토리지 풀을 업그레이드하여 스토리지 용량을 추가할 수 있습니다. 적절한 하드웨어 및 소프트웨어를 설치하고 구성하여 풀에 노드를 추가합니다. 그런 다음 메시지 버스를 사용하여 적절한 스토리지 풀에 보고하도록 새 노드를 구성할 수 있습니다.

블록 스토리지 노드는 노드 가용성을 스케줄러 서비스에 보고하므로 새 노드가 온라인 상태이고 사용 가능한 경우 테넌트는 새 스토리지 리소스를 즉시 사용할 수 있습니다.

경우에 따라 인스턴스의 블록 스토리지에 대한 수요가 사용 가능한 네트워크 대역폭을 소모할 수 있습니다. 따라서 용량 및 대역폭을 원활하게 추가할 수 있도록 블록 스토리지 리소스를 서비스하도록 네트워크 인프라를 설계해야 합니다.

이는 종종 다운스트림 장치에 용량을 추가하기 위한 동적 라우팅 프로토콜 또는 고급 네트워킹 솔루션을 포함합니다. 프런트 엔드 및 백엔드 스토리지 네트워크 설계에는 용량 및 대역폭을 빠르고 쉽게 추가할 수 있는 기능이 포함되어야 합니다.

노드 하드웨어는 클라우드 서비스에 충분한 스토리지를 지원해야 하며 배포 후 용량을 추가할 수 있도록 해야 합니다. 하드웨어 노드는 RAID 컨트롤러 카드에 의존하지 않고 다수의 저렴한 디스크를 지원해야 합니다.

하드웨어 노드는 또한 하드웨어 기반 스토리지 성능과 중복성을 제공하기 위해 고속 스토리지 솔루션과 RAID 컨트롤러 카드를 지원할 수 있어야 합니다. 손상된 배열을 자동으로 복구하는 하드웨어 RAID 컨트롤러를 선택하면 성능이 저하되거나 삭제된 스토리지 장치를 교체 및 복구하는 데 도움이 됩니다.

확장성은 스토리지 솔루션의 주요 아키텍처 요소입니다. 50P로 확장되는 스토리지 솔루션은 10 PB로만 확장되는 솔루션보다 확장 가능한 스토리지 솔루션으로 간주됩니다. 이 메트릭은 워크로드가 증가함에 따라 솔루션의 성능을 측정하는 확장성과 다릅니다.

예를 들어 개발 플랫폼 클라우드를 위한 스토리지 아키텍처에는 상용 제품 클라우드와 동일한 확장 가능성 및 확장성이 필요하지 않을 수 있습니다.

Object Storage 리소스 노드에는 하드웨어 내결함성 또는 RAID 컨트롤러가 필요하지 않습니다. Object Storage 서비스는 기본적으로 영역 간 복제를 제공하므로 Object Storage 하드웨어에서 내결함성을 계획할 필요가 없습니다.

블록 스토리지 노드, 컴퓨팅 노드 및 클라우드 컨트롤러에는 하드웨어 RAID 컨트롤러와 다양한 RAID 구성이 있는 하드웨어 수준에서 내결함성이 내장되어 있어야 합니다. RAID 수준은 클라우드의 성능 및 가용성 요구 사항과 일치해야 합니다.

Object Storage 서비스를 실행하는 디스크가 빠른 성능 디스크일 필요는 없습니다. 따라서 스토리지를 위해 테라바이트당 비용 효율성을 극대화할 수 있습니다. 그러나 블록 스토리지 서비스를 실행하는 디스크는 고성능 블록 스토리지 풀을 제공하기 위해 SSD 또는 플래시 스토리지가 필요할 수 있는 성능 향상 기능을 사용해야 합니다.

인스턴스에 사용하는 단기 디스크의 스토리지 성능도 고려해야 합니다. 컴퓨팅 풀에 단기 스토리지의 높은 사용률이 필요하거나 성능이 매우 높은 경우 Block Storage에 배포하는 솔루션을 유사한 하드웨어 솔루션을 배포해야 합니다.