웹사이트 검색

스토리지 아키텍처 사용을 위한 MinIO 서버 설정


이 페이지에서

  1. 1. 작동 원리
  2. 2. 설치 단계
  3. 3. 구성 단계
  4. 4. 테스트 단계

이 튜토리얼에서는 스토리지 아키텍처 사용을 위해 MinIO 서버를 설정하는 방법을 설명합니다. MinIO가 무엇인지 아직 모르는 사람은 고성능 분산 개체 스토리지 시스템입니다. 소프트웨어로 정의되고 산업 표준 하드웨어에서 실행되며 100% 오픈 소스입니다. 타협하지 않고 필요한 모든 기능을 달성하기 위해 개체를 단일 계층 아키텍처로 제공하도록 의도적으로 구축되었습니다. 그 결과 확장성과 경량성을 동시에 갖춘 클라우드 네이티브 개체 서버로 나타납니다.

클라우드 엔지니어링의 세계가 점점 더 성숙해지면서 애초에 MinIO가 필요한 이유가 떠오릅니다.

클라우드에서 솔루션을 제공할 때 결국 AWS S3, Azure Blob Storage 및 Alibaba OSS와 같은 솔루션 스토리지를 사용하게 될 수 있다는 점을 고려하십시오. Minio가 제공되는 클라우드 스토리지 서비스와 동일한 스토리지 아키텍처의 대안 역할을 하므로 솔루션이 여전히 온프레미스에 남아 있는 경우 개념도 마찬가지입니다.



1. 작동 원리

간단한 개념으로 Minio는 클라이언트 부분과 서버 부분의 두 부분으로 나뉩니다. 이 개념에는 웹 UI 또는 파일 브라우저를 통한 대시보드도 포함됩니다. 각각의 클라이언트와 서버 측은 상대적으로 설정하기 쉽고 CLI(Command Line Interface)에 익숙하다면 쉽게 이해할 수 있을 것입니다.

그러나 프로덕션 수준으로 설계할 때 모든 것이 분산되어야 합니다. 즉, 제공된 솔루션은 대규모로 잘 수행되고 자체 확장 및 고가용성 준비가 되어 있어야 합니다. 이를 고려하여 minio에는 Distributed Erasure Code라는 자체 개념이 있습니다.

이 개념은 일부 드라이브를 사용할 수 없는 경우에도 여러 드라이브에 걸쳐 데이터를 분할하고 다시 가져오는 안정적인 접근 방식입니다. 이 개념을 사용하면 드라이브의 절반을 잃어도 데이터는 계속 보장받을 수 있습니다.

이 튜토리얼에서는 MinIO 서버를 분산 삭제 코드로 설치하고 구성하는 방법을 보여드리겠습니다. 그런 다음 최종 사용자로서 MinIO 서비스를 활용하는 방법에 대해 클라이언트 측에서 간단히 살펴보십시오.

2. 설치 단계

설치 단계에서는 서버 2개를 minio 클러스터로 구성하여 분산 삭제 코드 구성을 준비하겠습니다.

이제 minio 사용을 위한 블록 장치로 분할하는 데 사용되는 4개의 디스크 드라이브를 나열합니다. 우리 아키텍처는 다중 서버를 설정하기로 결정했기 때문에 서버에 필요한 최소 드라이브는 2개이지만 단일 서버를 사용하는 경우 드라이브의 최소 요구 사항은 1개입니다. 이레이저 코드 설계에 필요한 세부 요구 사항을 볼 수 있습니다. 여기 .

다음은 단계입니다.

 [ ~]# fdisk -l 

Disk /dev/sda: 107.4 GB, 107374182400 bytes, 209715200 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk label type: dos
Disk identifier: 0x000a4fd8

Device Boot Start End Blocks Id System
/dev/sda1 * 2048 2099199 1048576 83 Linux
/dev/sda2 2099200 209715199 103808000 8e Linux LVM

Disk /dev/sdb: 8589 MB, 8589934592 bytes, 16777216 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/sdc: 8589 MB, 8589934592 bytes, 16777216 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/sdd: 8589 MB, 8589934592 bytes, 16777216 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/sde: 8589 MB, 8589934592 bytes, 16777216 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/centos-root: 104.1 GB, 104144568320 bytes, 203407360 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/mapper/centos-swap: 2147 MB, 2147483648 bytes, 4194304 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

위에서 볼 수 있듯이 서버에는 각각 8GB 크기의 드라이브 4개가 장착되어 있습니다.

다음으로 각 드라이브에서 파티션을 만든 다음 잘 만들어진 각 파티션에 마운트할 전용 디렉터리를 만듭니다. 다음은 단계입니다.

 
[ ~]#

완료되면 동일한 프로세스를 반복하여 나머지 드라이브에 파티션을 생성한 다음 생성한 각 디렉토리에 마운트합니다. 최종 결과는 다음과 같습니다.

 [ ~]# df -h 
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/centos-root 97G 3.8G 94G 4% /
devtmpfs 1.9G 0 1.9G 0% /dev
tmpfs 1.9G 0 1.9G 0% /dev/shm
tmpfs 1.9G 8.6M 1.9G 1% /run
tmpfs 1.9G 0 1.9G 0% /sys/fs/cgroup
/dev/sda1 1014M 145M 870M 15% /boot
tmpfs 379M 0 379M 0% /run/user/0
/dev/sdb1 8.0G 33M 8.0G 1% /opt/drive1
/dev/sdc1 8.0G 33M 8.0G 1% /opt/drive2
/dev/sdd1 8.0G 33M 8.0G 1% /opt/drive3
/dev/sde1 8.0G 33M 8.0G 1% /opt/drive4

드라이브의 전제 조건이 서버 1에 대해 완료되었으므로 위와 같이 서버 2에서 동일한 구성을 반복합니다.

3. 구성 단계

이제 두 서버 구성이 모두 완료되었으므로 계속해서 minio 서비스를 설치하겠습니다. 먼저 아래와 같이 minio 패키지를 다운로드합니다.

 [ ~]# wget https://dl.min.io/server/minio/release/linux-amd64/minio && chmod +x minio 
--2019-09-29 22:23:57-- https://dl.min.io/server/minio/release/linux-amd64/minio
Resolving dl.min.io (dl.min.io)... 178.128.69.202
Connecting to dl.min.io (dl.min.io)|178.128.69.202|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 43831296 (42M) [application/octet-stream]
Saving to: ‘minio’

3% [=> ] 1,335,296 106KB/s eta 6m 33s

이제 서버 2에서 위와 동일하게 반복합니다.

모든 작업이 완료되면 minio 구성을 시작하겠습니다. MINIO_ACCESS_KEY 및 MINIO_SECRET_KEY를 인증 액세스로 정의합니다. 구성은 아래와 같습니다.

 [ ~]# ./minio server http://10.124.12.{141..142}:9000/opt/drive{1..4} 
Waiting for a minimum of 4 disks to come online (elapsed 0s)

Waiting for a minimum of 4 disks to come online (elapsed 2s)

Waiting for a minimum of 4 disks to come online (elapsed 3s)

Waiting for a minimum of 4 disks to come online (elapsed 3s)

Waiting for all other servers to be online to format the disks.
Status: 8 Online, 0 Offline.
Endpoint: http://10.124.12.141:9000 http://10.124.12.142:9000
AccessKey: shahril
SecretKey: shahril123

Browser Access:
http://10.124.12.141:9000 http://10.124.12.142:9000

Command-line Access: https://docs.min.io/docs/minio-client-quickstart-guide
$ mc config host add myminio http://10.124.12.141:9000 shahril shahril123

Object API (Amazon S3 compatible):
Go: https://docs.min.io/docs/golang-client-quickstart-guide
Java: https://docs.min.io/docs/java-client-quickstart-guide
Python: https://docs.min.io/docs/python-client-quickstart-guide
JavaScript: https://docs.min.io/docs/javascript-client-quickstart-guide
.NET: https://docs.min.io/docs/dotnet-client-quickstart-guide

이제 서버 1에서 구성이 완료되었으며 구성을 위해 서버 2에서 동일한 단계를 반복합니다.

모든 것이 완료되면 결과 테스트를 진행할 수 있습니다.

4. 테스트 단계

모든 작업이 완료되면 minio 서비스의 유용성을 살펴보겠습니다. 위의 구성에서 볼 수 있듯이 브라우저를 통해 UI의 대시보드에 액세스할 수 있습니다. 예를 들어 구성된 대로 액세스 키 shahril 및 비밀 키 shahril123을 사용하여 http://10.124.12.141:9000에 로그인할 수 있습니다.

결과는 아래와 같이 표시됩니다.

완료되면 버킷 대시보드로 리디렉션됩니다. 이제 첫 번째 버킷을 생성해 보겠습니다.

더하기 버튼이 있는 아이콘 폴더를 클릭하고 첫 번째 버킷 이름을 mylove로 지정합니다. 아래와 같은 예:

완료되면 새 버킷이 생성되고 아래 스크린샷과 같이 왼쪽 패널에 표시됩니다.

완료되면 새 버킷이 생성되고 아래 스크린샷과 같이 왼쪽 패널에 표시됩니다.

다음으로 버킷에 삽입할 로컬 측의 파일을 추가하겠습니다.

아래와 같이 새 파일이 버킷에 성공적으로 업로드되었음을 알 수 있습니다.

분산의 개념이 잘 구현되도록 합니다. 다른 서버를 통해 minio 대시보드에 접속하여 간단한 테스트를 해보겠습니다. 다른 서버 URL은 http://10.124.12.142:9000입니다.

예상대로 우리가 삽입한 버킷과 파일은 위와 같이 다른 서버 URL에도 존재합니다.

이제 다른 테스트를 해보자. 이번에는 mc라는 클라이언트 콘솔을 사용하여 minio 서버에 액세스할 다른 워크스테이션을 사용합니다.

클라이언트 측에서 파일을 생성한 다음 기존 버킷에 업로드합니다.

그러면 최종 결과로 클라이언트 측에서 업로드된 새 파일이 자동으로 존재한다는 것을 대시보드에서 확인할 수 있습니다.

먼저 클라이언트 워크스테이션을 열고 minio 클라이언트 패키지를 다운로드합니다. 아래에 예가 나와 있습니다.

 [ ~]# chmod +x mc 

그런 다음 액세스 키 및 비밀 만들기를 사용하여 전용 버킷에 액세스하도록 클라이언트 측에서 구성을 만듭니다. 아래와 같은 예:

 [ ~]# ./mc config host add myminio http://10.124.12.142:9000 shahril shahril123 
mc: Configuration written to `/root/.mc/config.json`. Please update your access credentials.
mc: Successfully created `/root/.mc/share`.
mc: Initialized share uploads `/root/.mc/share/uploads.json` file.
mc: Initialized share downloads `/root/.mc/share/downloads.json` file.
Added `myminio` successfully.

구성된 후에는 기존 버킷 내의 콘텐츠를 볼 수 있어야 합니다. 아래와 같은 예:

 [ ~]# ./mc ls myminio/mylove/ 
[2019-09-30 11:16:25 +08] 55KiB myself.jpg

이제 클라이언트 측에서 버킷으로 기존 파일을 생성하거나 업로드합니다. 아래에 따른 예 :-

 [ ~]# ./mc ls myminio/mylove/ 
[2019-09-30 11:16:25 +08] 55KiB myself.jpg
[2019-09-30 11:58:16 +08] 38B new_file.txt

완료되면 예상대로 서버 URL을 통해 대시보드 쪽에서 새로 고칠 때 아래와 같이 새 파일이 표시되는 것을 볼 수 있습니다.

아래와 같이 오른쪽에 있는 공유 아이콘을 클릭하면 이미지의 전체 링크가 표시됩니다. curl 또는 API를 통해 애플리케이션 측에서 사용할 수 있는 버킷 내부의 각 객체에 대한 고유한 링크입니다.

엄지척! 이제 Minio를 사용하여 온프레미스에서 자체 호스팅 스토리지 서비스를 성공적으로 설정하고 구성했습니다. 더 자세한 내용은 여기에서 해당 문서를 확인할 수 있습니다.