У меня есть сервер A, который работает с частью задания и генерирует файл на выходе. Сервер B работает со второй частью задания, но ему нужен файл, созданный службой A.
Как лучше всего передать файл с сервера A на сервер B? Это будет происходить много раз, и может быть несколько переводов одновременно.
(Эти файлы почти всегда имеют размер <50 КБ, но могут достигать 15 МБ)
Я знаю, что могу использовать rsync или scp, но меня беспокоит эффективность таких частых передач. Это обоснованное беспокойство?
Я также рассмотрел вариант NFS, но мне нужна возможность легко указывать разные серверы, и мне не кажется разумным монтировать новую nfs каждый раз, когда мне нужно определить новый сервер.
Это некрасиво, но сейчас я просто помещаю файлы через http в скрипт, который записывает их в файловую систему. Идея заключалась в том, чтобы переписать это как простой клиент / сервер и вырезать из него веб-сервер. Но я подумал, что должен существовать инструмент, который делает что-то подобное.
В Лучший путь полностью субъективен.
Для меня лучший способ - все, что надежно и проверяемо передает файл с ServerA на ServerB, с использованием инструментов, с которыми я наиболее знаком / которые легче всего поддерживать.
Таким образом, я бы отправил файл (в вашем случае, вероятно, с помощью rsync) и связанный с ним хэш-файл (MD5, SHA1 и т.д.), а затем включил бы его в задание ServerA, чтобы сделать это автоматически. Затем я включил бы его в ваше задание ServerB, чтобы проверить файл данных с помощью хеш-файла и продолжить процесс.
Скорее всего, я также хотел бы убедиться, что ServerB не начинает работать с частично переданным файлом, поэтому я, вероятно, прибегну к копированию в «промежуточный» каталог на ServerB, а затем перейду в «готовый» каталог - выбрав только опрос или inotify "готовый" каталог.
Как только это будет сделано, ваша немедленная работа будет сделана, и вы сможете продолжить выполнение основных этапов своего проекта, а позже сможете вернуться к ускорению транспортировки.
Максимум, что я мог бы сделать на ранних этапах, - это структурировать каталоги на ServerA, чтобы я мог сказать, что создается на ServerA, а что копируется на ServerB; вероятно, с 'ожидающим' каталогом, в который ServerA записывает, 'копирующим' каталогом, в который ServerA перемещает готовый файл и из которого процессы хеширования / rsync забирают файл, и 'архивным' каталогом, в который ServerA перемещает файл, когда делается копирование на ServerB. Таким образом, я могу получить приблизительное представление о задержке / длине очереди, проверив количество файлов в папке «копирование».
Если вы обнаружите, что вам необходимо улучшить время передачи, вы, вероятно, обнаружите, что оптимизация сетевого стека будет лучшим способом сделать это. Более толстые каналы между серверами будут в порядке (например, обновление со 100 Мбит / с до 1 Гбит / с или даже 10 Гбит / с). У вас может возникнуть соблазн попробовать связать несколько сетевых интерфейсов, но, если вы это сделаете, убедитесь, что ваш алгоритм связывания не выбирает каждый раз один и тот же интерфейс на основе IP-адресов источника и назначения (или некоторых других критериев, которые не изменятся - даже источника- IP + порт к порту назначения-IP + не будет предлагать увеличенную пропускную способность, если вы не сможете открыть несколько одновременных подключений из разных исходных портов и распараллелить процесс копирования).
Если вы по-прежнему обнаруживаете, что транспорт является слишком узким местом, постарайтесь устранить его в процессе обновления. Попробуйте выполнить повторный факторинг, чтобы задания на ServerA и ServerB могли в конечном итоге выполняться более новым, более мощным ServerC. Если это который Для руководства важно, чтобы эти файлы обрабатывались быстро, это будет достаточно легкое время для проверки проекта.
Здесь есть два вопроса. Первый из них очевиден, когда вы хотите обмениваться файлами между серверами. Вы должны иметь возможность использовать NFS или какую-то кластерную файловую систему, например блеск сделать это. Да, вам придется изменять конфигурации по мере добавления серверов.
Второй вопрос заключается в том, как вы будете распространять это изменение конфигурации на все рассматриваемые серверы при добавлении серверов. Это больше область системы управления конфигурацией, лайк кукольный или повар. При таком подходе управление, скажем, конфигурацией gluster между различными серверами As и серверами B может осуществляться централизованно, будет больше контролироваться версиями и т. Д.
В качестве альтернативы вы также можете использовать внешнее хранилище для рабочих файлов, например, сервер A, отправляющий их в Amazon S3, и сервер B, извлекающий из этого общего расположения. Трудно сказать, жизнеспособен ли этот вариант, не зная больше о вашей ситуации.