블록 스토리지와 오브젝트 스토리지의 이해

오브젝트 스토리지와 블록 스토리지 이해

오늘날의 데이터 스토리지 환경에 적합한 블록 스토리지와 오브젝트 스토리지는?

이 질문은 경험 많은 IT 스토리지 관리자도 머리를 긁적이게 만들었습니다. 이유? 엔터프라이즈 데이터 스토리지 선택이 블록, 파일 스토리지 및 오브젝트인 경우 충돌하는 것은 종종 블록 스토리지 대 오브젝트 스토리지 논쟁입니다. 미래의 데이터 저장을 엄청난 도전으로 만드는 대규모 데이터에 책임이 있습니다. 사용 사례에 따라 데이터를 처리하고, 저장하고, 액세스합니다. 각 유형의 아키텍처 배포에 따른 복잡성을 상상해 보십시오!

이 기사에서는 블록 스토리지와 객체 스토리지, 액세스 방법 및 사용 사례에 대해 논의합니다. 다시 말하지만, 각각에는 고유한 기능과 제한이 있습니다. 이 기사에서는 항상 최선의 선택이 아닌 이유를 비즈니스에 가장 잘 맞는 방법을 이해하기 위해 더 깊이 탐구해 보겠습니다.

다이빙 할 준비가 되셨습니까? 탐색해 봅시다.

객체 저장소

T간단히 말해서 개체 스토리지는 별개의 데이터 단위 또는 개체를 격리된 컨테이너로 저장할 수 있는 데이터 스토리지 아키텍처입니다. 오브젝트 스토리지는 플랫 주소 구조를 가지므로 여러 네트워크 시스템에서 동일한 액세스 권한으로 각 오브젝트를 저장할 수 있습니다. 이러한 저장소를 사용하는 가장 큰 장점은 데이터의 물리적 위치를 알지 못하더라도 개체를 찾을 수 있다는 것입니다. 오브젝트 스토리지가 테이블에 제공하는 속성 세트 덕분입니다. 이것들은:

  1. 자료. 가족 사진, 음악, 비디오, 5,00000페이지 분량의 매뉴얼 문서 파일부터 비정형 데이터까지 저장하고 싶은 모든 것이 가능합니다.
  2. 관련 메타데이터 데이터를 설명하는 정보(나이, 개인 정보 보호, 액세스 비상 상황과 같은 세부 정보 포함) 그리고
  3. 맞춤 식별자 OS가 분산 시스템을 통해 찾을 수 있도록 고유한 ID 주소를 포함합니다.

접근 방법

객체 스토리지는 RESTful(Representational State Transfer) API에 의존하는 객체에 액세스하기 위해 API를 사용한다는 점을 인식하는 것이 중요합니다. 결과적으로 아카이브된 파일을 더 빨리 검색하고 싶다면 클라우드 블록 스토리지에 API 요청을 쉽게 보내 원하는 객체를 찾을 수 있다. 따라서 개체 기반 스토리지는 퍼블릭 클라우드 워크로드에 탁월한 선택입니다. 또한 다른 계층에 걸쳐 개체를 이동하여 여러 지리적 위치에 개체를 배포할 수 있습니다.

흥미롭게도 Object Storage를 사용하면 파일 정보로 파일을 분류/구성하고 원할 때마다 데이터를 검색할 수 있도록 색인을 생성할 수 있습니다. 그러나 이 데이터는 대상 장치와 호환되는 OS 서버를 통해 드라이브 볼륨을 탑재하여 액세스할 수 있습니다. 예를 들어, 클라우드의 시장 리더인 AWS는 다음을 제공합니다. 아마존 S3 오브젝트 스토리지 제품입니다.

사용 사례

비정형 데이터 저장

오브젝트 스토리지는 계층 구조를 따르지 않기 때문에 지리적 위치에 분산 된 멀티미디어 컨텐츠, 파일, 폴더, 아카이브 및 정적 웹 컨텐츠와 같은 데이터를 저장하는 데 이상적입니다.

클라우드 애플리케이션 개발

오브젝트 스토리지는 네트워크를 분산하여 애플리케이션 가용성을 용이하게 합니다. 결과적으로 기본 시스템 응용 프로그램을 쉽게 구축 및 개발할 수 있습니다. 또한 빅데이터 분석을 위해 데이터를 쉽게 저장, 태그 지정 및 분석할 수 있습니다.

아카이브 스토리지

오브젝트 스토리지를 사용하면 자주 업데이트되는 비정형 데이터를 확장하기 위해 스토리지 노드를 추가 할 수 있습니다. 이렇게하면 즉시 액세스를 유지하면서 파일을 보관할 수 있습니다.

파일 백업

오브젝트 스토리지를 사용하여 파일, 로그 파일 및 데이터베이스 덤프를 백업 할 수 있습니다.

데이터를 여러 번 읽고 쓸 수 있습니다.

오브젝트 스토리지에서는 한 번 작성된 데이터를 여러 장치에서 읽을 수 있습니다. 이는 여러 클라이언트가 모든 위치에서 데이터에 액세스하고 데이터를 읽고 쓸 수 있으므로 전 세계적으로 분산된 리치 미디어 저장소에 매우 적합합니다.

정적 데이터에 최적화

데이터는 한 번 기록되면 여러 번 읽을 수 있습니다. 이제부터 개체 스토리지를 사용하여 대용량의 정적 및 비정형 데이터를 관리할 수 있습니다. 예를 들어 이미지, 비디오 파일, 음악 또는 트랜잭션 레코드를 개체로 저장할 수 있습니다.

왜 기업용 오브젝트 스토리지인가?

블록 스토리지와 오브젝트 스토리지의 차이점에 관해서는 전자가 비정형 데이터 스토리지에 대한 선호 옵션으로 유리합니다. 실제로 비정형 데이터는 구성, 관리 및 검색하기가 복잡합니다. 이것이 메타데이터를 사용하여 대용량 스토리지에서 데이터 통찰력을 추출할 때 오브젝트 스토리지가 의미가 있는 부분입니다.

다음은 선택하는 이유입니다. 개체 저장 기술 스토리지 요구 사항:

검색 가능성 :

개체 자체에 있는 메타데이터는 광범위한 검색 결과를 제공합니다. 예를 들어 특정 기준을 충족하는 특정 유형의 파일을 검색할 수 있습니다. 또한 메타데이터를 개체와 연결하기 위해 데이터베이스를 구축할 필요 없이 사용자 지정 메타데이터를 쉽게 생성하고 시간이 지남에 따라 속성을 추가할 수 있습니다.

무제한 확장 성:

오브젝트 스토리지를 사용하면 스토리지 공간을 활용하기 위해 여러 노드를 추가하여 방대한 양의 데이터를 저장할 수 있습니다. 따라서 고밀도 서버를 혼합 및 일치시켜 주문형 확장성을 충족할 수 있습니다. 이렇게 하면 동일한 개체의 여러 복사본이 여러 노드에 분산되므로 데이터의 고가용성이 보장됩니다.

빅 데이터 분석:

빅 데이터 분석을 활용하려면 오브젝트 스토리지에 의존하십시오. 각 개별 개체에는 기본 데이터에 더 많은 컨텍스트를 추가하여 관련성을 제공하는 메타데이터로 태그가 지정되기 때문입니다. 따라서 기존 블록에서 기대할 수 없는 빅 데이터에서 실행 가능한 통찰력을 추출할 수 있습니다.

여러 지역에 분산된 스토리지:

멀티 페타바이트 규모의 데이터 스토리지 빅타임의 분산 접근 기능을 활용할 수 있습니다! 확장 가능한 메타데이터와 객체 스토리지의 지리적 유연성 덕분입니다. 키워드 검색이 가능한 글로벌 네임스페이스를 사용하면 데이터를 쉽게 찾고, 마이그레이션하고, 보호할 수 있습니다. 또 다른 요점은 작업 부하 분산으로 인해 서버 전체에 강력한 기능을 배포할 수 있다는 것입니다. 이는 용량, 비용, 가용성을 최적화할 뿐만 아니라 규정 준수 요구 사항을 충족하여 비즈니스 목표를 달성하는 데 도움이 됩니다.

대용량 데이터 스토리지 요구 사항 충족 :

대용량 파일, 고객 데이터 및 비정형 엔터프라이즈 데이터를 스토리지 풀에 저장할 수 있습니다. 수백 페타바이트의 데이터를 확장할 수 있습니다. 이는 기업에 매우 매력적인 옵션인 플랫 네임스페이스로 인한 확장 제한을 제거합니다.

HTTP (s) 프로토콜을 사용한 애플리케이션 개발 :

오브젝트 스토리지는 HTTP (s) 프로토콜을 통한 액세스를 지원하므로 모든 요청이 HTTP (s) API를 통해 이루어 지므로 애플리케이션에 쉽게 통합 할 수 있습니다. 따라서 이제 모바일, 반응 형 및 기존 앱 개발을위한 클라우드 네이티브 애플리케이션을 빌드, 개발, 배포 할 수 있습니다.

오브젝트 스토리지가 항상 최선의 선택이 아닌 이유는 무엇입니까?

블록 스토리지와 오브젝트 스토리지를 이해하려면 오브젝트 스토리지가 적합하지 않은 경우를 평가해야 합니다. 여기 있습니다.

  • 개체 스토리지를 사용하면 개체가 파일의 일부가 아닌 전체 파일을 읽거나 쓰거나 덮어쓰도록 설계되었기 때문에 파일을 수정할 수 없습니다. 전체 파일의 새 버전을 업로드하는 경우 IO 성능에 영향을 줍니다. 이후로는 데이터베이스 작업에 적합하지 않습니다.
  • 개체 저장소는 읽기 요청 시 최신 버전의 파일을 받을 수 있다고 보장하지 않습니다. 이는 모든 위치에 배포된 업데이트가 최신이 아니거나 데이터가 지속적으로 변경되지 않기 때문에 항상 (최종 일관성) 있기 때문입니다.
  • 스토리지 성능을 우선시하는 조직의 경우 오브젝트 스토리지는 스토리지 전체의 워크로드에 대해 느린 I / O 활동 성능을 제공합니다. 메타 데이터 분석이 필요한 객체 기반 아키텍처를 비난하십시오. 데이터는 사용자 정의 된 메타 태그와 함께 번들로 제공되므로 응용 프로그램 및 워크 플로의 성능이 저하됩니다.

블록 스토리지

블록 스토리지(블록 수준 스토리지라고도 함)는 데이터베이스, 애플리케이션 등과 같은 구조화된 데이터를 저장하는 데 사용되는 가장 단순한 형태의 데이터 스토리지 기술입니다. SAN (Storage Area Network) 시스템, 더 빠른 성능으로 복잡한 파일과 응용 프로그램을 저장할 수 있습니다. 데이터에 더 빠르게 액세스할 수 있는 구조화된 워크로드 덕분입니다. 그러나 로컬로 액세스되는 스토리지 및 애플리케이션은 지원합니다.

블록 스토리지 기술에서는 각 블록을 PC의 개별 하드 디스크 드라이브처럼 작동하는 동일한 크기의 블록으로 분할할 수 있습니다. 여기에서 블록은 이러한 스토리지 드라이브에 액세스할 수 있는 외부 서버 OS에 의해 제어됩니다. 이를 통해 파일, 데이터베이스, VM 볼륨 등을 포함한 모든 종류의 애플리케이션을 저장할 수 있는 유연성이 향상됩니다. 또한 지원되는 타사 도구를 사용하여 스토리지 파일을 공유하거나 블록 스토리지에 있는 데이터를 백업할 수 있습니다. 예를 들어 AWS는 아마존 엘라스틱 블록 스토어(EBS) Amazon Elastic Cloud Compute(EC2)용으로 설계된 영구 블록 스토리지 서비스입니다.

접근 방법

고성능 워크로드 복원이 걱정된다면 블록 스토리지가 이에 대한 해답을 제공합니다. 액세스 블록 수준 데이터는 데이터 액세스를 더 빠르게 만드는 파이버 채널 및 인터넷 SCSI(Small Computer Systems Interface)와 같은 고성능 프로토콜을 사용하여 단순화됩니다.

흥미롭게도 각 블록에는 특정 데이터에 액세스하거나 특정 데이터를 검색하거나 블록 데이터를 빠르게 검색할 수 있는 고유한 ID 주소가 있습니다. OS는 필요에 따라 블록을 직접 읽고/쓰기/다시 쓸 수 있으므로 데이터를 (구조) 파일 시스템 또는 응용 프로그램별 구조로 쉽게 구성, 관리 및 구성할 수 있습니다.

이제 소프트웨어 오버헤드를 줄이면서 데이터 집약적인 애플리케이션을 쉽게 복원할 수 있습니다. 또한, 당신은 쉽게 블록 수정 이전 버전을 그대로 유지하면서 특별히 필요한 블록에 액세스합니다.

고객 사례

모든 애플리케이션을 위한 원시 스토리지 볼륨 생성

블록 스토리지를 사용하면 데이터베이스, 파일, VM 파일 시스템 등과 같은 모든 애플리케이션에 대해 개별 하드 드라이브를 만들 수 있습니다.

RAID 어레이

데이터 보호를 강화하는 RAID 볼륨 (* RAID는 데이터 가상화 스토리지 기술)로 블록 스토리지 시스템을 사용할 수 있습니다. 이는 개별 디스크를 RAID 어레이로 구성하여 수행됩니다.

일관된 I/O 작업

매우 짧은 지연 시간과 일관된 스토리지 작업 I / O (입력 / 출력 또는 읽기 / 쓰기)가 필요한 데이터베이스 지향 애플리케이션에 블록 스토리지를 사용할 수 있습니다.

이메일 서버

블록 스토리지는 더 많은 용량을 추가할 수 있으므로 다음과 같은 이메일 서버를 처리하는 데 블록 스토리지를 사용할 수 있습니다. 의 Microsoft Exchange.

VMware 서버

블록 수준 스토리지를 사용하면 VMFS(VM 파일 시스템) 볼륨을 저장하기 위해 VMware 서버를 배포할 수 있습니다.

부팅

블록 스토리지 아키텍처를 사용하여 블록 스토리지에서 직접 운영 체제 또는 외부 서버를 부팅할 수 있습니다.

왜 기업용 블록 스토리지인가?

블록 수준 스토리지가 IT 환경에 적합한 이유는 무엇입니까?

다음은 블록을 저장 매체로 널리 사용하는 이유입니다.

다재

사용 가능한 파일 시스템을 수용하도록 블록 수준 저장소를 포맷 할 수 있습니다. 예를 들어 VMware 서버는 VMFS를 사용합니다. Windows를 실행하는 경우 NTFS가 기본 형식입니다.

유연성

블록 스토리지를 사용하면 스토리지 용량을 업데이트하기 위한 빠른 구성이 가능합니다. 성능 저하 없이 스토리지 볼륨을 추가하거나 서버 간에 스토리지를 이동할 수 있습니다.

빠른 I/O 데이터 성능

블록 스토리지 메커니즘은 고성능 애플리케이션을위한 빠른 I / O 데이터 액세스 및 낮은 대기 시간을 위해 기본 파일 프로토콜 (NFS, CIFS, ext3 / ext4 등)을 지원합니다. 따라서 캐싱, 데이터베이스 작업, 로그 파일 등과 같은 활동이 많은 IO 작업을 수행 할 수 있습니다.

저장 용량 추가

고객을 위해 고성능 스토리지를 추가하여 표준 속도 스토리지로 쉽게 업그레이드 할 수 있습니다.

사용한 만큼 지불

할당 한 블록 스토리지 공간에 대한 비용 만 지불하면됩니다. 즉, 비용을 낮추는 블록 스토리지 볼륨을 쉽게 연결 / 분리 또는 다시 연결할 수 있습니다.

확장 성능

블록 스토리지 볼륨은 별도의 데이터 블록과 독립적으로 작동하므로 추가 블록 볼륨을 생성하여 확장 할 수 있습니다. 성능은 디스크 크기 또는 VM 인스턴스의 제한에 따라 확장됩니다. 좋은 소식은 더 많은 컴퓨팅 기능에 대해 비용을 지불 할 필요가 없다는 것입니다.

간편한 관리

운영 체제의 호스트 또는 블록 스토리지 볼륨이 데이터 권한을 직접 제어하므로 액세스를 쉽게 관리하고 권한을 제어 할 수 있습니다.

블록 기반 스토리지가 항상 최선의 선택이 아닌 이유는 무엇입니까?

블록 스토리지는 일부 인스턴스에 대한 최선의 대안이 아닐 수 있습니다. 여기 이유가 있습니다.

  • 블록 스토리지 아키텍처에는 메타데이터가 없기 때문에 데이터 분석 기능이 제한적입니다. 따라서 메타데이터를 별도로 저장하려면 추가 데이터베이스가 필요합니다. 이것은 클라이언트가 동시에 다른 서버의 특정 파일에 액세스하는 것을 제한합니다.
  • 계층 기반 가격 책정과 달리 전체 블록 스토리지 볼륨 가격 책정은 사전 정의됩니다. 즉, 하나의 데이터에 액세스하려면 저장된 데이터의 양, 수행되는 작업 유형 및 데이터 전송 비용을 포함하는 전체 블록 저장 공간에 대한 비용을 지불해야 합니다. 실제로 이것은 더 높은 성능을 위해 스토리지 용량을 최적화하는 데 비용이 많이 듭니다.
  • 블록 스토리지에서는 각 데이터 단위가 분리되어 별도로 저장되기 때문에 파일 배포가 복잡합니다. 결과적으로 인프라 비용으로 인해 컴퓨팅 인스턴스가 상당히 낭비될 수 있습니다. 게다가 자원의 비효율적인 사용으로 이어질 수도 있습니다.
  • 블록 스토리지의 SAN 환경은 데이터를 저장하기 위해 고가의 하드웨어가 필요하므로 스토리지 요구 사항을 충족시키는 데 더 많은 비용이 소요됩니다.

블록 스토리지와 오브젝트 스토리지의 차이점을 요약한 비교 차트를 간단히 살펴보세요.

객체 저장소
블록 스토리지
데이터는 확장 가능한 버킷에 객체로 저장됩니다. 데이터는 고정 된 크기의 블록으로 저장됩니다.
페타 바이트 이상으로 무한 확장 할 수 있습니다. 요구 사항에 따라 고정 크기 블록으로 제한된 확장 성.
데이터 (메타 데이터)에 대한 더 많은 컨텍스트를 사용하여 데이터를 쉽게 구성, 찾기 또는 검색 할 수 있습니다. 메타 데이터가 없습니다.
비정형 데이터는 여러 지리적 위치에 효율적으로 저장할 수 있습니다. 스토리지 간 거리가 멀수록 지연 시간이 길어집니다.
비정형 콘텐츠 및 높은 스트림 처리량을위한 최고의 성능. 관계형 데이터베이스 및 트랜잭션 데이터에 대한 최상의 성능.
HTTP (S) 기반 API 연결. 파이버 채널 및 iSCSI (Internet Small Computer Systems Interface)를 통해 액세스 할 수 있습니다.
무제한 파일 저장 용량. 용량을 늘리기 위해 노드를 추가 할 수 있습니다.
데이터 백업, 정적 컨텐츠, 아카이브 이미지, 풍부한 멀티미디어 컨텐츠 (비디오, 사진 또는 음악)와 같은 정적 파일 및 애플리케이션에 가장 적합합니다. 높은 IOPS와 낮은 대기 시간이 필요한 엔터프라이즈 데이터베이스 및 트랜잭션 데이터와 같은 애플리케이션에 이상적입니다.

이제 한 스토리지가 다른 스토리지를 추월하는 방법을 알았으므로 개체 기반 스토리지가 IT 스토리지 환경에 더 적합하다고 말할 수 있습니다. 그러나 어떤 저장 옵션을 사용하든지 간에 장기 보관을 위해 데이터를 저장할 수 있습니다. 이것은 덜 자주 사용되거나 전혀 액세스되지 않지만 귀중한 저장 장소를 소모하는 데이터에 적용됩니다.

스토리지 시스템이 무엇이든, 제대로 관리되지 않는 스토리지 시스템은 전체 비즈니스를 위험에 빠뜨릴 수 있습니다. 전체 데이터 세트에 쉽게 액세스하거나 복구할 수 있는 강력한 백업 및 스토리지 아키텍처가 필요합니다. 이것이 Zmanda가 도울 수 있는 곳입니다.

Zmanda를 사용한 효과적인 스토리지 백업 및 복구

이있는 마음으로, 즈 만다 개체 및 블록 스토리지에 대한 포괄적인 스토리지, 백업 및 복구를 위해 설계되었습니다. Zmanda를 사용하면 백업된 데이터를 원하는 오프사이트 위치로 쉽게 복제할 수 있습니다. 현재 Zmanda 백업 엔진은 장기 데이터 저장을 위해 다음 유형의 개체 저장 리포지토리를 지원합니다.

그것들을 시험해보십시오! 또는 이상적인 확장 가능한 스토리지 솔루션으로서 아키텍처 접근 방식의 유형 사이에서 여전히 고민하고 있다면 귀하의 요구 사항에 맞는 하이브리드/컨버지드 솔루션이 있습니다. 연락처 TCO(총 소유 비용)를 대폭 낮추면서 각 솔루션을 활용하는 방법을 이해합니다.


더 많은 주제 탐색