Comments 16
А вот реальный usecase из жизни: S3 билинг в основном состоит из исходящего трафика и количество запросов на отдачу статики, так вот перед тем как городить свой облачный S3, более разумно найти ту самую золотую середину:
Ставим nginx прокси на свои сервера — где дешевый трафик(не амазон) и кешируем запросы к s3, благо уже есть готовые сборки под это дело.
https://github.com/coopernurse/nginx-s3-proxy
nginx compiled with aws-auth support, suitable for S3 reverse proxy usage.
proxy_cache_lock on;
proxy_cache_lock_timeout 60s;
proxy_cache_path /data/cache levels=1:2 keys_zone=s3cache:10m max_size=30g;
server {
listen 8000;
location / {
proxy_pass https://your-bucket.s3.amazonaws.com;
aws_access_key your-access-key;
aws_secret_key your-secret-key;
s3_bucket your-bucket;
proxy_set_header Authorization $s3_auth_token;
proxy_set_header x-amz-date $aws_date;
proxy_cache s3cache;
proxy_cache_valid 200 302 24h;
}
}
Работы на минуты 3, у нас счёт уменьшился раз в 5-6, если настроить кешинг более агрессивно, то можно сэкономить еще. Плюсы — продолжаем юзать облако и не обретаем головняк в виде Минио.
У вас в документации написано:
«The maximum size of a single object is limited to 5TB. putObject transparently uploads objects larger than 5MiB in multiple parts. This allows failed uploads to resume safely by only uploading the missing parts. Uploaded data is carefully verified using MD5SUM signatures.».
Вы не могли бы уточнить, что конкретно будет происходить?
Например, вот ситуация. Приложение получает какой-то файл на 100 мегабайт. То есть, он будет разбит на несколько частей. Допустим, когда 53 мегабайта были вроде как получены, произошел внезапный обрыв соединения. Как будет осуществлено возобновление? Мне нужно будет узнать текущее число загруженных байт и начать просто записывать недостающие? Или что там должно вообще происходить? Как-то не вполне очевидно написано. Как клиент поймёт, какие части ему нужно отправить?
И второе, как можно приблизительно оценить объёмы и количество единиц хранимой информации, которые можно будет эффективно хранить? Пара миллиардов мелких файлов вперемешку с тысячами больших — нормально лягут?
Заранее спасибо!
Например, вот ситуация. Приложение получает какой-то файл на 100 мегабайт. То есть, он будет разбит на несколько частей. Допустим, когда 53 мегабайта были вроде как получены, произошел внезапный обрыв соединения. Как будет осуществлено возобновление? Мне нужно будет узнать текущее число загруженных байт и начать просто записывать недостающие? Или что там должно вообще происходить? Как-то не вполне очевидно написано. Как клиент поймёт, какие части ему нужно отправить?
очевидно да. запросить загруженные части, начать загружать отсутствующие.
С другой стороны, в библиотеке для ноды я вижу такие методы как initiateNewMultipartUpload, что вроде как подразумевает необходимость каких-то дополнительных действий. Но это по какой-то причине не содержится в примерах и документации. То есть, похоже нельзя просто так взять и начать пихать недостающие байты. Причём, я так и не вижу, каким именно способом можно получить размер уже закачанных данных. Метод, который возвращает список незавершенных загрузок почему-то отказывается возвращать размер:
{ key: 'test.bin',
uploadId: '648d7c8a-176b-4d01-9a16-8823edc8ab0b',
initiated: 2017-03-21T13:43:16.134Z,
size: NaN }
Сколько смотрю на все эти файловые хранилища — везде одна проблема — переусложнённый append данных в уже имеющийся файл. Хотя, надо ещё порыться в потрохах. В крайнем случае, наверное можно попробовать подмонтировать эту штуку в виде раздела, хотя мне не очень нравится эта идея.
http://docs.minio.io/docs/distributed-minio-quickstart-guide
https://docs.minio.io/docs/minio-erasure-code-quickstart-guide
вроде все ключевые понятия фигурируют.
Для получения более подробной информации о настройке NGINX или NGINX Plus в качестве прокси для Minio см. документацию по Minio.
Я может быть туплю, но в документации виден только пример для обычного nginx, а примеров того, чем поможет Plus нет ни в документации, ни в статье.
Быть может, Plus вы тут упоминали из-за health check и режима балансировщика least_conn. Справедливо, ведь это удобно, когда строишь целый кластер. Но если платить от $1,900 за установку не хочется, то можно обойтись другими способами.
Например, в Ubuntu есть пакет nginx-full, в состав которого входит сторонний модуль Upstream Fair Queue. Это, конечно, не least_conn, но уже и не round-robin.
Если этого мало, и хочется и балансировщик, который не закинет на бэкэнд больше нужного коннектов, и health check устраивать не во время обработки запросов, а отдельно, то можно посмотреть в сторону haproxy, там всё это есть. А судя по документации, Minio не ожидает какую-то nginx-магию в плане рерайтов, хитрых location с разными и прочего.
Облачное хранилище корпоративного класса на базе NGINX Plus и Minio