MinIO
开源分布式文件存储
minIO是一款高性能的对象存储系统，是开源的。类似于阿里的oss系统
兼容亚马逊S3云存储服务接口，非常适合于存储大容量非结构化的数据，例如图片、视频、日志文件、备份数据和容器/虚拟机镜像等，而一个对象文件可以是任意大小，从几kb到最大5T不等。
minIO本身，使用Golang语言开发的
支持Java/Golang/.Net/Python/Js等语言，提供了对应的sdk和example，接入较简单
官网
https://min.io/docs/minio/linux/index.html
备份、防误删除、加密、水平扩展、权限、大文件上传、断点续传
水平扩展
minIO支持3种部署方式
-
单节点单硬盘 (SNSD or “Standalone”)
Local development and evaluation with no/limited reliability -
单节点多硬盘 (SNMD or “Standalone Multi-Drive”)
Workloads with lower performance, scale, and capacity requirements Drive-level reliability with configurable tolerance for loss of up to 1/2 all drives
Evaluation of multi-drive topologies and failover behavior.
-
多节点多硬盘 (MNMD or “Distributed”)
Enterprise-grade high-performance object storage
Multi Node/Drive level reliability with configurable tolerance for loss of up to 1/2 all nodes/drives
Primary storage for AI/ML, Distributed Query, Analytics, and other Data Lake components
Scalable for Petabyte+ workloads - both storage capacity and performance
https://min.io/docs/minio/linux/operations/installation.html
备份
MinIO supports server-side and client-side replication of objects between source and destination buckets.
服务端备份：指的是，在将一个minIO集群中的文件，备份到另一个集群中。这个是自动备份的，不需要人工手动触发
备份的级别是bucket级别
客户端备份：指定是，手动输入命令，将某个对象，备份到另一个地方
mc mirror
https://min.io/docs/minio/linux/reference/minio-mc/mc-mirror.html#command-mc.mirror
另外，还提供了一直纠缠码技术，即使丢失了一半的硬盘数据，也能够恢复
防误删除
minIO，类似于git，提供version的功能。假设，删除了一个文件a.txt，此时这个文件只是做逻辑删除，给这个文件打了一个deleteMarker标记，没有物理删除
https://min.io/docs/minio/linux/administration/object-management/object-versioning.html
对一些重要的文件，为了防止误删除，还提供了对象锁定机制Object Retention。能够保护文件，是一段时间内，不能被修改和删除
https://min.io/docs/minio/linux/administration/object-management/object-retention.html
大文件上传和断点续传
https://docs.aws.amazon.com/AmazonS3/latest/userguide/mpuoverview.html
https://huaweicloud.csdn.net/638752f1dacf622b8df8ada1.html
https://blog.csdn.net/Tuine/article/details/113996848
权限
提供了S3协议的权限机制。后面，详细说明
加密
还提供了加密机制，https://min.io/docs/minio/linux/operations/server-side-encryption.html
MinIO和现有的.Net文件系统比较
和虎子总，沟通了下，做了下比较：
| 功能 | .Net文件系统 | MinIO | |
|---|---|---|---|
| 备份 | 暂不支持，但开发工作量不大 | 支持 | |
| 防误删除 | 暂不支持，但开发工作量不大 | 支持 | |
| 水平扩展 | 暂不支持 | 支持 | |
| 权限 | 由业务系统自行开发 | 由业务系统自行开发 | |
| 目录层级遍历 | 暂不支持，正在开发中，通过树形虚拟目录实现 | 支持 | |
| 大文件上传、断点续传 | 暂不支持，但开发工作量不大 | 支持 | |
结论：
从几个功能项来看，使用现有的.Net文件系统，已经能满足现有的业务场景。未来的其他的功能，.Net文件系统，可能需要做开发，但总体来看，工作量不大。
如果选用MinIO，现成的功能，支持的更多，可以考虑，在新项目中，尝试使用，也能方便踩踩坑。
权限demo
租户
现在，有2个租户：
- 滁州三污
- 海峡环保
每个租户，创建对应的User
滁州三污:
username:CZSW-u1
password:CZSW-u112345
海峡环保：
username:HXHB-u1
password:HXHB-u112345
每个租户，各自创建一个根bucket
滁州三污:czsw-bucket/
海峡环保：hxhb-bucket/
创建完根bucket后，下面在各自bucket下，分别创建几个directory，存放各种业务数据：
- cloud-graph 云组态
- technology-reference 工艺资料
- technical-specification 技术规范
每个业务模块，创建对应的directory，这个是根据业务功能，可扩展的
创建后，结果如下：
mc mb --with-versioning local/czsw-bucket/cloud-graph
mc mb --with-versioning local/czsw-bucket/technology-reference
mc mb --with-versioning local/czsw-bucket/technical-specification
mc mb --with-versioning local/hxhb-bucket/cloud-graph
mc mb --with-versioning local/hxhb-bucket/technology-reference
mc mb --with-versioning local/hxhb-bucket/technical-specification
每个directory，各自上传对应的txt文件
业务权限 和 MinIO 权限的对应关系
业务系统中的用户，在上传文件后，可以配置，让这个文件，被哪些用户看见；可以被哪些用户修改等。这个场景，minIO是支持的
如果业务系统中，为了批量配置，将这里的多个用户，整合成用户组，直接配置某个文件，可以被用户组中的所有用户可见。那么对应到MinIO中，也是一个group，将这个文件的读写权限，分配给这个group即可。
超级管理员，能看到所有的bucket下的内容
某个租户下的管理员，能看到本租户对应的bucket下的内容
这里给2个租户，分别创建1个管理员用户 、2个普通用户
滁州三污:
username:CZSW-u1 能看到czsw-bucket下所有文件
password:CZSW-u112345
--------------------
username:CZSW-u2 只能看到czsw-bucket/cloud-graph下的所有文件
password:CZSW-u212345
--------------------
username:CZSW-u3 只能看到czsw-bucket/cloud-graph 和 technology-reference下的所有文件
password:CZSW-u312345
海峡环保：
username:HXHB-u1 能看到hxhb-bucket下所有文件
password:HXHB-u112345
---------------------
username:HXHB-u2 只能看到hxhb-bucket/cloud-graph下的所有文件
password:HXHB-u212345
----------------------
username:HXHB-u3
password:HXHB-u312345 只能看到hxhb-bucket/cloud-graph 和 technology-reference下的所有文件
目前不支持的场景：
假设czsw-bucket/cloud-graph文件夹下，有2个文件，a.txt 和 b.txt，张三只能看到a.txt文件，看不到b.txt文件
但是张三虽然能看到a.txt 和 b.txt。但是能够支持，只能下载其中一个文件，另一个文件不能下载 这种场景
CZSW-u1-policy
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:*"
],
"Resource": [
"arn:aws:s3:::czsw-bucket/*"
]
}
]
}
CZSW-u2-policy
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetBucketLocation"
],
"Resource": [
"arn:aws:s3:::czsw-bucket/*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::czsw-bucket"
],
"Condition": {
"StringLike": {
"s3:prefix": [
"cloud-graph/*"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:GetObjectVersion"
],
"Resource": [
"arn:aws:s3:::czsw-bucket/cloud-graph/a.txt*"
]
}
]
}
CZSW-u3-policy
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"s3:GetBucketLocation"
],
"Resource": [
"arn:aws:s3:::czsw-bucket/*"
]
},
{
"Effect": "Allow",
"Action": [
"s3:ListBucket"
],
"Resource": [
"arn:aws:s3:::czsw-bucket"
],
"Condition": {
"StringLike": {
"s3:prefix": [
"technology-reference/*",
"cloud-graph/*"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"s3:GetObject",
"s3:GetObjectVersion"
],
"Resource": [
"arn:aws:s3:::czsw-bucket/*",
"arn:aws:s3:::technology-reference/*"
]
}
]
}
总结
通过demo发现，minIO对bucket的访问策略，较为完善；但是对于bucket内的对象，访问策略还有较大的不足。
所以，对于权限校验，建议由 业务系统+文件存储系统，共同来完成。其中 文件存储系统实现粗粒度的权限校验，业务系统实现细粒度的权限校验
结合具体的业务场景，就是现在文件夹下，有a.txt b.txt c.txt
其中，张三只能看到a.txt，李四能a.txt b.txt，王五，能看到a.txt b.txt c.txt。
这个文件的可见性方面，需要由业务系统来实现，或者单独开发一个组件
讨论的问题
wp
wp/d1 业务系统，自己创建虚拟目录
wp/d2
wp/d1/d11 业务系统，需要自行开发遍历目录
wp/d1/a.txt
wp/d1/b.txt
文件名重复----根据业务，自行决定是否覆盖
暂时没有备份功能，后续开发
暂时没有误删除的功能
权限，有业务系统自行控制
暂时大文件上传的功能
-----------------------------------------
目录遍历，需要业务自行实现---虚拟目录
备份、误删除、大文件上传 功能开发，工作量不大
支持http