Pull to refresh

Comments 16

Статья ни о чем. Директивы проксирования в nginx знает уже каждая домохозяйка.
Почему именно Nginx Plus? Всё что вы написали можно сделать и в бесплатной версии.

А вот реальный 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, если настроить кешинг более агрессивно, то можно сэкономить еще. Плюсы — продолжаем юзать облако и не обретаем головняк в виде Минио.
А зачем тогда S3? Только хранить?
А можно я вам (автору статьи) пару вопросов задам, раз уж вы тут.

У вас в документации написано:
«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 данных в уже имеющийся файл. Хотя, надо ещё порыться в потрохах. В крайнем случае, наверное можно попробовать подмонтировать эту штуку в виде раздела, хотя мне не очень нравится эта идея.
Что-то там совсем всё не очевидно, если честно

ну очевидно что так должно работать, если декларируется наличие возможности (а как по другому?). Вопрос: реализовано ли в клиентской библиотеке, которую вы смотрите.


Вот на примере go:


Что-то в документации не увидел, как инстансы minio взаимодействуют между собой? Отпадет винт, нода и т.п., что будет делать minio, ребалансировка? Как работает? Лучше бы про сам minio написали ))
Для получения более подробной информации о настройке 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 с разными и прочего.

Sign up to leave a comment.