4 ms·

I don't know when this was written, but MinIO does not have a great story (or really any story) around horizontal scalability. Yes, you can set it up in "distri

by heipei 5y ago

I don't know when this was written, but MinIO does not have a great story (or really any story) around horizontal scalability. Yes, you can set it up in "distributed mode", but that is completely fixed at setup time and requires a certain number of nodes right from the beginning. For anyone who wants HA and horizontal elastic scalability, checkout SeaweedFS instead, it is based on the Facebook "Haystack" paper: https://github.com/chrislusf/seaweedfs https://github.com/chrislusf/seaweedfs

killingtime74 5y ago
I agree it’s great (and mostly used) for integration testing, do significant number of users actually use it for storage?
- gunapologist99 5y ago
  Seaweedfs has made some questionable security decisions (https://github.com/chrislusf/seaweedfs/issues/1937 https://github.com/chrislusf/seaweedfs/issues/1937).
  - mosselman 5y ago
    You can still pass the -ip flag right? This mostly means you probably need to read some 'Seaweedfs in production' sort of guide.
    - gunapologist99 5y ago
      > you probably need to read some 'Seaweedfs in production' sort of guide. This comes across as slightly condescending. As I'm sure you'd agree, secure by default is very important, and it's what most responsible distributions aim for (i.e., Debian/Ubuntu). Starting up a daemon should not launch it in the most open way possible, but instead the most restricted way possible. A reasonable expectation is that you should not have to pass the -ip flag; daemons should default to a secure configuration (which probably means defaulting to -ip 127.0.0.1, which you should be able to easily override, if that is your intention, and achieve the default behavior by simply passing -ip 0.0.0.0/0).
      - mosselman 5y ago
        > This comes across as slightly condescending. As does: > As I'm sure you'd agree, secure by default is very important I just meant it in a practical sense, you (as in people), need to read a guide in order to make it production ready instead of seafweed being production ready by default. I checked, there even is a guide in the repo, so I guess people need to read it.
- tuananh 5y ago
  is it ready for production use? i can't find docs on how to run multiple master anywhere.
Already__Taken 5y ago
wow that's got everything and almost the kitchen sink.
- chrislusf 5y ago
  Actually SeaweedFS already supports asynchronous backup to data sinks such as S3,GCP,Azure,etc. I did not heard of this "kitchen" sink before. :) But adding one more sink should be trivial.
chrislusf 5y ago
Thanks! SeaweedFS has a linearly scalable architecture and performs much better. It is also very easy to run. Just run this: "docker run -p 8333:8333 chrislusf/seaweedfs server -s3"
- hardwaresofton 5y ago
  SeaweedFS is an amazing project, thanks so much for making it. I know I'm asking quite a biased source but are there any shortcomings of SeaweedFS that are well known? Any hangups/weird corners that you can think of just off the top of your head?
  - yencabulator 5y ago
    I spent some hours looking at SeaweedFS, and walked away with the impression that most of the code outside of the happy paths wasn't exercised much. For example, if you batch upload data, and the default 8 volumes happen to fill at the same time, you get transient errors until it has managed to create new volumes.
    - hardwaresofton 5y ago
      I haven't looked at it as deeply -- thanks for pointing this out. Up until now I actually wanted to use MinIO for running an S3 service (Ceph + RadosGW is also an option for me, and this thread make me consider it over MinIO though it was always a strong contender). In the process of researching I earmarked SeaweedFS and cortx[0], but SeaweedFS attracted me way more -- looks like it would fit me "just right". It'd be nice if there were an issue to explain this shortcoming, does the project know it happens and it's like a "hopefully we'll have auto scaling/adjusting volumes/online configuration update in the future" or something? How would one mitigate that? [0]: https://github.com/Seagate/cortx https://github.com/Seagate/cortx
      - yencabulator 5y ago
        Well, the author has to be aware of it: https://github.com/chrislusf/seaweedfs/issues/2216 https://github.com/chrislusf/seaweedfs/issues/2216

by heipei 5y ago

killingtime74 5y ago

I agree it’s great (and mostly used) for integration testing, do significant number of users actually use it for storage?

gunapologist99 5y ago
Seaweedfs has made some questionable security decisions (https://github.com/chrislusf/seaweedfs/issues/1937 https://github.com/chrislusf/seaweedfs/issues/1937).
- mosselman 5y ago
  You can still pass the -ip flag right? This mostly means you probably need to read some 'Seaweedfs in production' sort of guide.
  - gunapologist99 5y ago
    > you probably need to read some 'Seaweedfs in production' sort of guide. This comes across as slightly condescending. As I'm sure you'd agree, secure by default is very important, and it's what most responsible distributions aim for (i.e., Debian/Ubuntu). Starting up a daemon should not launch it in the most open way possible, but instead the most restricted way possible. A reasonable expectation is that you should not have to pass the -ip flag; daemons should default to a secure configuration (which probably means defaulting to -ip 127.0.0.1, which you should be able to easily override, if that is your intention, and achieve the default behavior by simply passing -ip 0.0.0.0/0).
    - mosselman 5y ago
      > This comes across as slightly condescending. As does: > As I'm sure you'd agree, secure by default is very important I just meant it in a practical sense, you (as in people), need to read a guide in order to make it production ready instead of seafweed being production ready by default. I checked, there even is a guide in the repo, so I guess people need to read it.
tuananh 5y ago
is it ready for production use? i can't find docs on how to run multiple master anywhere.

Already__Taken 5y ago

wow that's got everything and almost the kitchen sink.

chrislusf 5y ago
Actually SeaweedFS already supports asynchronous backup to data sinks such as S3,GCP,Azure,etc. I did not heard of this "kitchen" sink before. :) But adding one more sink should be trivial.

chrislusf 5y ago

Thanks! SeaweedFS has a linearly scalable architecture and performs much better. It is also very easy to run. Just run this: "docker run -p 8333:8333 chrislusf/seaweedfs server -s3"

hardwaresofton 5y ago
SeaweedFS is an amazing project, thanks so much for making it. I know I'm asking quite a biased source but are there any shortcomings of SeaweedFS that are well known? Any hangups/weird corners that you can think of just off the top of your head?
- yencabulator 5y ago
  I spent some hours looking at SeaweedFS, and walked away with the impression that most of the code outside of the happy paths wasn't exercised much. For example, if you batch upload data, and the default 8 volumes happen to fill at the same time, you get transient errors until it has managed to create new volumes.
  - hardwaresofton 5y ago
    I haven't looked at it as deeply -- thanks for pointing this out. Up until now I actually wanted to use MinIO for running an S3 service (Ceph + RadosGW is also an option for me, and this thread make me consider it over MinIO though it was always a strong contender). In the process of researching I earmarked SeaweedFS and cortx[0], but SeaweedFS attracted me way more -- looks like it would fit me "just right". It'd be nice if there were an issue to explain this shortcoming, does the project know it happens and it's like a "hopefully we'll have auto scaling/adjusting volumes/online configuration update in the future" or something? How would one mitigate that? [0]: https://github.com/Seagate/cortx https://github.com/Seagate/cortx
    - yencabulator 5y ago
      Well, the author has to be aware of it: https://github.com/chrislusf/seaweedfs/issues/2216 https://github.com/chrislusf/seaweedfs/issues/2216