Мне нужно настроить SFTP-сервер, который, по сути, имеет очень большую емкость. Мне нужно передать данные для входа в систему через SFTP одному из наших партнеров на сервер, на который они загрузят миллионы файлов на общую сумму несколько сотен терабайт. Тогда я буду избирательным и довольно редко читаю некоторые из этих файлов. Это единственное актуальное требование, любой выбор технологии остается на усмотрение.
На ум приходит самый простой способ - это иметь какой-то экземпляр EC2, на котором запущен SFTP-сервер, таким образом, чтобы все загруженное либо напрямую отправлялось на S3, либо какой-то процесс обнаруживал новые файлы при их загрузке, копировал их в S3 и удаляет их с диска.
Это лучший способ? Есть ли другой способ получить сервер с «бесконечным и магически растущим дисковым пространством»?
Спасибо за вашу помощь! Даниэль
Я ответил этот же вопрос о переполнении стека.
s3fs - действительно разумное решение, и в моем случае я объединил его с proftpd с отличными результатами, несмотря на теоретические / потенциальные проблемы.
В то время, когда я писал ответ, я настроил это только для одного из моих клиентов-консультантов ... но с тех пор я также начал пить свой собственный kool-aid и использую его в производстве на моей основной работе. Компании, мы обмениваемся данными, загружая и скачивая файлы в течение всего дня на моем sftp-сервере, который хранит все прямо на S3. В качестве бонуса моя система экспорта отчетов, которая записывает таблицы Excel непосредственно в S3, может экспортировать отчеты «на FTP-сервер», просто помещая их прямо в корзину ftp-сервера с соответствующими метаданными для отображения uid, gid и режим каждого файла. (s3fs использует заголовки x-amz-meta-uid, -gid и -mode для имитации разрешений файловой системы). Когда клиент входит на сервер, файлы отчетов просто ... там.
Я действительно думаю, что идеальным решением, вероятно, был бы сервис шлюза sftp для S3, но я все еще не удосужился разработать его, так как это решение работает очень хорошо ... конечно, с некоторыми оговорками:
Не все значения по умолчанию для s3fs разумны. Вероятно, вы захотите указать эти параметры:
-o enable_noobj_cache # s3fs has a huge performance hit for large directories without this enabled
-o stat_cache_expire=30 # the ideal time will vary according to your usage
-o enable_content_md5 # it's beyond me why this safety check is disabled by default
Вероятно, лучше всего использовать регион, отличный от стандарта США, потому что это единственный регион, который не обеспечивает согласованность чтения после записи для новых объектов. (Или, если вам нужно использовать стандарт США, вы можете использовать почти недокументированное имя хоста your-bucket.s3-external-1.amazonaws.com из региона us-east-1, чтобы предотвратить гео-маршрутизацию ваших запросов, что может улучшить согласованность.)
У меня в ведре включено управление версиями объектов, о чем s3fs совершенно не знает. Преимущество этого состоит в том, что даже если файл должен быть «затоптанным», я всегда могу перейти к ведению версий, чтобы восстановить «перезаписанный» файл. Управление версиями объектов в S3 было блестяще разработано таким образом, что клиенты S3, которые не знают о версиях, никоим образом не отключены или запутаны, потому что, если вы не выполняете вызовы REST с учетом версий, ответы, возвращаемые S3, совместимы с клиентами, у которых есть нет концепции управления версиями.
Отметим также, что передача данных в S3 бесплатно платы за передачу данных. Вы платите только по цене за запрос. Передача данных из S3 в EC2 в пределах региона также бесплатна. Плата за перевод взимается только при переходе из S3 в Интернет, в Cloudfront или в другой регион AWS. Если вы хотите использовать более дешевое хранилище с уменьшенной избыточностью, s3fs поддерживает это с -o use_rrs.
В качестве забавного момента вы всегда будете испытывать теплое нечеткое ощущение, когда увидите 256 терабайт свободного пространства (и используется 0, поскольку реальный расчет размеров непрактичен из-за того, что S3 является хранилищем объектов, а не файловой системой. ).
$ df -h
Filesystem Size Used Avail Use% Mounted on
/dev/xvda1 7.9G 1.4G 6.2G 18% /
s3fs 256T 0 256T 0% /srv/s3fs/example-bucket
Конечно, вы можете установить ведро где угодно. Просто у меня он есть в / srv / s3fs.
Проверьте SFTP-шлюз на AWS Marketplace.
У нас возникли проблемы с надежностью s3fs, поэтому мы разработали специальное решение специально для этой цели. Мы без проблем использовали его в производственной среде в течение нескольких лет и недавно выпустили его на AWS Marketplace.
Есть два варианта. Вы можете использовать собственный управляемый сервис SFTP, недавно добавленный Amazon (который проще настроить). Или вы можете подключить корзину к файловой системе на сервере Linux и получить доступ к файлам, используя SFTP, как и любые другие файлы на сервере (что дает вам больший контроль).
В консоли Amazon AWS перейдите по ссылке AWS Transfer для SFTP и создайте новый сервер.
На странице SFTP-сервера добавьте нового пользователя (или пользователей) SFTP.
Разрешения пользователей регулируются соответствующей ролью AWS в сервисе IAM (для быстрого начала вы можете использовать AmazonS3FullAccess политика).
Роль должна иметь доверительные отношения с transfer.amazonaws.com.
Подробности см. В моем руководстве Настройка SFTP-доступа к Amazon S3.
Как уже @Michael ответил, просто установите ведро с помощью s3fs файловую систему (или аналогичную) на сервер Linux (Amazon EC2) и используйте встроенный сервер SFTP для доступа к корзине.
Вот основные инструкции:
s3fsaccess-key-id:secret-access-key к /etc/passwd-s3fsДобавьте монтажный ввод ковша в fstab:
<bucket> /mnt/<bucket> fuse.s3fs rw,nosuid,nodev,allow_other 0 0
Подробности см. В моем руководстве Настройка SFTP-доступа к Amazon S3.
Или используйте любую бесплатную «Клиент FTP / SFTP», это тоже «Клиент S3», и у вас ничего не настроено на стороне сервера. Например, мой WinSCP или Cyberduck.
AWS теперь предоставляет сервис SFTP через S3 под названием AWS Transfer для SFTP. Он обладает преимуществами S3 (высоконадежное, доступное, распределенное хранилище) в сочетании с хорошо известным и признанным протоколом SFTP.
По умолчанию пользователи проходят аутентификацию с использованием пар закрытого и открытого ключей, а с помощью политик IAM вы можете настроить разрешения для пользователей SFTP в корзинах S3. Вы можете добавить схемы аутентификации, реализовав собственные функции в AWS API Gateway и AWS Lambda.
Мы обернули AWS Transfer для SFTP в надстройку Heroku под названием SFTP To Go для обеспечения гибких схем аутентификации и снижения совокупной стоимости владения (поскольку конечная точка сервиса имеет фиксированную стоимость на AWS, но может использоваться многими пользователями без какого-либо ущерба для безопасности или производительности.