minioテクノロジーの選択と展開テスト

前書き

MinIOは、最速のオブジェクトストレージサーバーであると主張しています。標準ハードウェアでは、オブジェクトストレージの読み取り/書き込み速度は最大183 GB/sおよび171GB/sです。オブジェクトストレージは、Spark、Presto、TensorFlow、H2O.aiなどのさまざまな複雑なワークロードのプライマリストレージレイヤーとして、またHadoopHDFSの代わりとして使用できます。つまり、機械学習、分析、およびアプリケーションデータのワークロードのための高性能インフラストラクチャを構築します。

テクノロジーの選択（なぜminioを選ぶのか）

このセクションで説明したいのは、なぜminioを選択するのか、より広い方向でオブジェクトストレージを使用するのかということです。私が見つけた情報と個人的な理解に基づいて、以下で予備的な紹介を行います。

オブジェクトストレージとファイルストレージ

知乎にはこの質問の非常に詳細な分析があります。多くの大物が独自の理解を書いています。ここでいくつかの表現を選びます：ブロックストレージ、ファイルストレージ、オブジェクトストレージの本質的な違いは何ですか？

• オブジェクトストレージ（Key-Valueデータベース）：インターフェイスはシンプルです。オブジェクトはファイルと見なすことができ、完全に読み書きすることしかできません。通常、大きなファイルが主なファイルであり、十分なIO帯域幅が必要です。
• ブロックストレージ（ハードディスク）：そのIO特性は、従来のハードディスクと一致しています。ハードディスクは、一般的なニーズを満たすことができる必要があります。つまり、大きなファイルの読み取りと書き込みを処理でき、小さなファイルの読み取りと書き込みも処理できます。しかし、ハードディスクは大容量と明らかなホットスポットが特徴です。したがって、ブロックストレージは主にホットな問題に対処できます。さらに、ブロックストレージに必要なレイテンシは最小です。
• ファイルストレージ（ファイルシステム）：ファイルストレージをサポートするインターフェイスのシステム設計は、Ext4などの従来のローカルファイルシステムの特性と難しさと一致しています。ブロックストレージよりもインターフェイスが豊富で、ディレクトリのサポートを考慮する必要があります。並列化をサポートするファイルストアを実装するファイル属性などは、最も難しいはずです。ただし、独自の標準を定義するHDFSやGFSのようなシステムでは、実装に応じてインターフェイスを定義できるため、より簡単になります。

私の理解によると、ファイルストレージとオブジェクトストレージの本質的な違いは、分散ファイルストレージファイルがディレクトリツリー、つまりLinuxのツリー形式として編成され、オブジェクトストレージがフラットな編成方法を採用していることです。本質的な違いはデータの「ユーザー」は異なります。ブロックストレージのユーザーは、従来のファイルシステムやデータベースなどのブロックデバイスの読み取りと書き込みが可能なソフトウェアシステムです。ファイルストレージのユーザーは自然人です。ユーザーはオブジェクトストレージのは他のコンピュータソフトウェアです。

ブロックストレージの場合、遅延は非常に小さいですが、データはRAIDやLVMなどの手段で保護され、並列書き込み方式では10ミリ秒の遅延を実現できますが、コストが高く、ホスト間の接続に役立ちません。データ共有などの問題も危険にさらされています。ファイルストレージについては、コストが低く、異なるホスト間でファイルを共有でき、FTPおよびNFSサービスを使用して分散できますが、ボトルネックがあり、ファイル数が増えると効率が低下するという問題を克服できません。 。

オブジェクトストレージが登場した理由は、ブロックストレージとファイルストレージの欠点を克服し、それぞれの利点を促進するためです。つまり、ブロックストレージは読み取りと書き込みが高速であり、共有に役立ちません。また、ファイルストレージは読み取りと書き込みが遅く、共有に役立ちます。共有に役立つ高速な読み取りと書き込みを取得できますか。したがって、オブジェクトストレージ。

オブジェクトストレージは、ファイルをストレージ用のオブジェクトに分解することと理解できます。簡単に言えば、メタデータの一部がストレージファイルに添付されます。クエリを実行するときは、メタデータを見つけてファイルを見つけます。不正確で有用なアナロジーを使用するために、オブジェクトストレージは、ブロックストレージのブロックに説明ラベルを追加することと同等です。これにより、ファイルのクエリ可能性が向上し、管理が容易になります。オブジェクトストレージは、ファイルストレージとブロックストレージの利点を組み合わせたものと言え、ストレージの開発の方向性です。これは、プログラムやシステムに最適なファイルストレージ方法です。

分散ストレージの比較

すべてのオープンソースソフトウェアを試すことは不可能であるため、ここでは主に2つのブログを引用しています。最初にそれらを比較して選択しました。

分散ファイルストレージシステムのインベントリ

分散ストレージシステムのCephVSMinIO比較

分散ストレージの比較：

ファイルシステム	開発者	開発言語	オープンソースプロトコル	使いやすさ	該当シーン	特性	欠点
GFS	グーグル		オープンソースではありません
HDFS	Apache	Java	Apache	簡単なインストールと専門的なドキュメント	非常に大きなファイルを保存する	ビッグデータのバッチ読み取りと書き込み、高スループット; 1回の書き込み、複数回の読み取り、順次読み取りと書き込み	ミリ秒レベルでの低遅延データアクセスに対応することは困難です。複数のユーザーによる同じファイルの同時書き込みをサポートしていません。多数の小さなファイルには適していません。
Ceph	セージウェイル、カリフォルニア大学サンタクルーズ校	C ++	LGPL	簡単なインストールと専門的なドキュメント	単一クラスター内の大、中、小のファイル	分散型、単一の依存点なし、Cで記述、パフォーマンスの向上	未成熟なbtrfsに基づいているため、成熟しておらず、十分に安定していないため、本番環境での使用はお勧めしません。
TFS	アリババ	C ++	GPLV2	インストールは複雑で、公式文書はほとんどありません	クラスタ全体の小さなファイル	小さなファイル向けに調整されたランダムIOパフォーマンスは、比較的高いです。ソフトRAIDを実装し、システムの同時処理機能とデータフォールトトレラントリカバリ機能を強化します。アクティブスタンバイホットスワップをサポートしてシステムの可用性を向上させます。読み取り/スタンバイ機能を提供します。	大きなファイルの保存には適していません;POSIXをサポートしていない、汎用性が低い、カスタムディレクトリ構造とファイル権限制御をサポートしていない、APIを介したダウンロード、パフォーマンスのボトルネックが1つある、公式ドキュメントが少ない、学習コストが高い
光沢	太陽	C	GPL	複雑でカーネルに大きく依存しているため、カーネルを再コンパイルする必要があります	大きなファイルの読み取りと書き込み	エンタープライズレベルの製品、非常に大規模で、カーネルとext3に大きく依存しています
MooseFS	コアSp。z oo	C	GPLV3	簡単なインストール、多くの公式文書、および管理と監視のためのWebインターフェイス	多数の小さなファイルの読み取りと書き込み	比較的軽量で、perlで書かれており、中国ではより多くの人が使用しています	マスターサーバーへの依存点が1つあり、パフォーマンスが比較的低い
MogileFS	ダンガインタラクティブ	Perl	GPL		主にウェブ分野で大規模な小さな写真を処理するために使用されます	Key-Valueメタファイルシステム;mooseFSよりもはるかに効率的	FUSEはサポートされていません
FastDFS	国内開発者YuQing	C	GPLV3	簡単なインストールと比較的活発なコミュニティ	単一クラスター内の中小規模のファイル	システムはPOSIXをサポートする必要がないため、システムの複雑さが軽減され、処理効率が向上します。ソフトRAIDを実現し、システムの同時処理機能とデータフォールトトレラントリカバリ機能を強化します。マスタースレーブファイルとカスタム拡張機能をサポートします。マスタースレーブトラッカーサービス、システムの可用性の向上	大容量ファイルの保存には適さない再開可能なアップロードをサポートしていません。POSIXをサポートしておらず、汎用性が低く、パブリックネットワーク間でのファイルの同期に大きな遅延があり、対応するフォールトトレランス戦略が必要です。適用;同期メカニズムはファイルの正確性の検証をサポートしていません;APIを介したダウンロード、パフォーマンスのボトルネックの単一のポイントがあります
GlusterFS	Zリサーチ	C	GPLV3	簡単なインストールと専門的なドキュメント	大きなファイルに適しており、小さなファイルのパフォーマンスを最適化する余地はまだたくさんあります	メタデータサーバーなし、スタッキングアーキテクチャ（基本的な機能モジュールをスタッキングして強力な機能を実現できます）、線形水平拡張機能、mooseFSよりも大きい	メタデータサーバーがないため、クライアントの負荷が増大し、CPUとメモリを大量に消費しますが、ファイルディレクトリをトラバースする場合、実装はより複雑で非効率的であり、すべてのストレージノードを検索する必要があります。より深いパスを使用することはお勧めしません
GridFS	MongoDB	C ++		簡単インストール	通常、大きなファイル（16M以上）を処理するために使用されます	ファイル全体をメモリにロードせずに部分的なファイルにアクセスでき、高いパフォーマンスを維持します。ファイルとメタデータは自動的に同期されます

分散ストレージシステムの比較のためのCephVSMinIO：

	Ceph	MiniO
アドバンテージ	・成熟した・Red Hatの継子、Cephの創設者がRed Hatに参加しました・強力な機能・数千のノードをサポートします・ノードの動的な増加をサポートし、データ分散のバランスを自動的に取ります。・強力な構成可能性、さまざまなシナリオに合わせて調整できます	・低学習コスト、簡単なインストール、操作とメンテナンス、およびすぐに使用可能・現在、MinIOフォーラムは非常に人気があり、質問に答えることができます。・javaクライアントとjsクライアントがあります。データ保護：Distributed MinIOは、イレイジャーコードを使用して、複数のノードのダウンタイムとビット減衰ビットの腐敗を防ぎます。分散型MinIOには少なくとも4台のハードディスクが必要であり、分散型MinIOを使用してイレイジャーコーディング機能が自動的に導入されます。整合性：分散モードおよびスタンドアロンモードのMinIO、すべての読み取りおよび書き込み操作は、書き込み後の読み取り整合性モデルに厳密に従います。・フェデレーションモード拡張クラスターをサポートする
欠点	・高い学習コストと複雑な設置、運用、保守。・中国にはいわゆるCeph中国人コミュニティがあり、民間機関が活動しておらず、文書が遅れており、更新の兆候はありません。	・ノードの動的な増加には対応していません。MinIOの創設者の設計コンセプトは、ノードを動的に増加させるには複雑すぎるということであり、将来的には他のソリューションを採用して拡張をサポートする予定です。
開発言語	・c	・ 行け
データの冗長性	コピー、イレイジャーコーディング	・リードソロモンコード
一貫性	・強い一貫性	・強い一貫性
動的拡張	・ハッシュ	・動的ノードの追加はサポートされていません
中央ノード	・オブジェクトストレージセンターレス	CephFSにはメタデータサービスの中心点があります
保管方法	ブロック、ファイル、オブジェクト	・オブジェクトストレージ
アクティビティ	・高い、中国のコミュニティはあまり活発ではありません	・高い、中国のコミュニティはありません
成熟	・ 高い	・ 真ん中
ファイルシステム	・EXT4、XFS	・EXT4、XFS
クライアント	C、python、S3	java、s3
http	· 兼容S3，分段上传，断点下载	· 兼容S3，分段上传，断点下载
学习成本	· 高	· 中
开源协议	· LGPL version 2.1	· Apache v2.0
管理工具	· Ceph-admin,Ceph-mgr,zabbix插件	· web管理工具 命令行工具 mc

个人理解

第一张表中，针对中小文件作为主要区分分布式存储的特征，以及还有具有web界面与便于安装这两者具有简化操作的功能能判断是否足够友好，相对而言我觉得简单易用的是MooseFS，MogileFS，FastDFS，GlusterFS；除了fastdfs，其它三款我好像了解也不是很多，但单说fastdfs，可能作为单节点来说，确实很不错，操作用其它语言api来讲也还行，反正根据我之前搭建的过程来讲，没有编译C++的东西复杂，但多节点听说就很复杂了，而且我看B站上的视频讲得也很长，顿时就有了种不想看的感觉，emmm。

第二张表中，可以很明显的看到，ceph各方面都比minio优秀，但是它的缺点尤其明显，太过于复杂和难于管理，我也有针对ceph看过相关资料，ceph是一款面向团队的产品，它的高度自动化带来遍历的同时，系统的运行状态不完全在管理员控制之下，系统中会有若干自动触发而不是管理员触发的操作，这需要运维团队针对这些可能出现的情况进行预案以及适应。但我仅仅一个人，别说运行起这个东西，就算真运行起来了，我感觉也会自己把自己坑死，emmm。。

所以minio毫不意外的成为了我的选择，即最开头引言的最后一句话，“为机器学习、分析和应用程序数据工作负载构建高性能基础架构”。因为我本身工作涉及视频图像算法，上面这句话是在GitHub中作为minio的第一段介绍中强调，我感觉如果对业务足够敏感，对于身兼PPT技术的大佬来讲，这一句话瞬间能醍醐灌顶。为啥？这star量，加上开头这句话，这不就是PPT素材嘛，甚至都不用考虑能不能用。别给我扯什么分布式，高可用，云原生，老夫敲代码就是一把梭（滑稽），最主要呢，还是得老板开心，老板开心我就很开心，虽然疫情挺严重，还是得过个好年的，emmm。。。

minio部署与测试

minio的单节点部署

关于部署这一块，作为用go语言所写的底层，minio展现出了非常强大的跨系统以及兼容性，我之前是用了两台非docker下部署了集群，还不错，操作很简单。但因为写本篇的时候是在家，刚好试试在之前买的腾讯云部署。

docker pull minio/minio
mkdir -p /data/minio/config
mkdir -p /data/minio/data

docker run -p 9000:9000 -p 9090:9090 --net=host --name minio -d --restart=always -e "MINIO_ACCESS_KEY=minioadmin" -e "MINIO_SECRET_KEY=xxx" -v /data/minio/data:/data -v /data/minio/config:/root/.minio minio/minio server /data --console-address ":9090" -address ":9000"

minio的本地部署与docker部署都很简单，上面secret_key是密码，填写完运行即启动了minio，不过上面命令需要注意的是docker安装完后会有三种网络模式，-p使用的是bridge模式，而–net=host使用的是host模式，并且host模式优先级强于前者，所以上面-p指定的端口是无效的，因为网络默认绑定宿主机了。我也是去看了下别人运行的命令，不过有些确实没啥必要。

没报错启动后，我们就能输入localhost:9090进入登录界面，登录成功后如下图：

我这里因为刚部署上去，加了一个bucket，并丢了几张图上去，bucket应该不用多说，对象存储s3存储单元都叫这个。minio的操作界面非常友好了，基本小白都能懂，然后我原先还没发现，它能显示的格式是真的多，连webp这种小众格式还有PDF都能看：

PDF还内置双页打开，如果不是窗口太小，都能拿来划水了。。同样，之前用公司搭的上传了部分视频，如果玩过音视频的可能知道，视频编码格式有非常多种，web端最能接受的是avc1，而其它格式在网页端很难直接播放，但minio就我测试来看，似乎很强。这里就不再演示了，更多的可以去官网直接看它对此做的改进。

minio上传与下载

minio上传测试：

import logging
from minio import Minio
from minio.error import S3Error

logging.basicConfig(
    level=logging.INFO,
    filename='test.log',
    filemode='a',
    format='%(asctime)s %(name)s %(levelname)s--%(message)s'
)

# 确定要上传的文件
file_name = "self_introduction.m4a"
file_path = "/home/video/{}".format(file_name)


def upload_file():
    # 创建一个客户端
    minioClient = Minio(
        'IP:Port',
        access_key='xxxx',
        secret_key='xxxx',
        secure=False
    )

    # 判断桶是否存在
    check_bucket = minioClient.bucket_exists("pdf")
    if not check_bucket:
        minioClient.make_bucket("pdf")
    try:
        # logging.info("start upload file")
        print("start upload file")
        minioClient.fput_object(bucket_name="pdf", object_name="data/{}".format(file_name),
                                file_path=file_path)
        # logging.info("file {0} is successfully uploaded".format(file_name))
        print("file {0} is successfully uploaded".format(file_name))
    except FileNotFoundError as err:
        logging.error('upload_failed: '+ str(err))
    except S3Error as err:
        logging.error("upload_failed:", err)


if __name__ == '__main__':
    upload_file()

网页上可以看到为：

minio下载测试：

import logging
from minio import Minio
from minio.error import S3Error

logging.basicConfig(
    level=logging.INFO,
    filename='test.log',
    filemode='a',
    format='%(asctime)s %(name)s %(levelname)s--%(message)s'
)

# 要下载文件
file_name = "self_introduction.m4a"
file_path = "G:\\360Downloads\\img\\{}".format(file_name)


def download_file():
    # 创建一个客户端
    minioClient = Minio(
        'IP:Port',
        access_key='xxxx',
        secret_key='xxxx',
        secure=False
    )
	
    try:
        minioClient.fget_object(
            bucket_name="pdf",
            object_name="data/{}".format(file_name),
            file_path=file_path
        )
        logging.info("file '{0}' is successfully download".format(file_name))
    except S3Error as err:
        logging.error("download_failed:", err)

if __name__ == '__main__':
    download_file()

这里就不再举例，关于批量上传 or 下载，可以加个for循环，以及去官网查看更多的api，GitHub地址为：

https://github.com/minio/minio-py

当然官网也有api的介绍，这里推荐的官网也英文版本的，虽然它有中文，不过毕竟不是官方在维护，有所滞后，所以能看懂英文还是推荐英文。

minio纠删码技术

这里算是分布式的高可用应用场景，这里我了解不深，根据官网的说法来讲，docker是按如下方式启动：

docker run -p 9000:9000 --name minio \
  -v /mnt/data1:/data1 \
  -v /mnt/data2:/data2 \
  -v /mnt/data3:/data3 \
  -v /mnt/data4:/data4 \
  -v /mnt/data5:/data5 \
  -v /mnt/data6:/data6 \
  -v /mnt/data7:/data7 \
  -v /mnt/data8:/data8 \
  minio/minio server /data1 /data2 /data3 /data4 /data5 /data6 /data7 /data8

然后就能随意插拔小于等于一半阵列数量的硬盘，它会采用Reed-Solomon code将对象拆分成N/2数据和N/2 奇偶校验块，来保证数据安全。关于里面是啥逻辑我不知道，但就我试验情况，我两台使用此方式启动，其中一台reboot，另一台开始错误日志起飞，可能这算是一种预警，然后恢复数据倒没观察，因为本身玩也没多久，还算一个预案，只能说还行。未完待续，后续如果有测试出其它问题会进行补充。