Опыт работы с MQ File Transfer Edition?
У нас есть несколько процессов, которые перемещают файлы между серверами - SFTP, FTP, SCP; Windows, Linux, AIX; есть компонент рабочего процесса (обычно требуется файл управления с именами файлов и значениями хеш-функции для перемещения пакета связанных файлов). На наших серверах часто запускается действие для получения файлов, поэтому мы должны убедиться, что они закончили писать.
Для этого у нас есть несколько собственных сценариев, но они не всегда работают должным образом, поэтому устранение неполадок, обслуживание и просмотр журналов не так просты. Серверов много, и наши скрипты не имеют централизованного ведения журнала или панели инструментов / консоли / и т. Д.
Мы ищем коммерческие продукты, чтобы сделать это. Кто-нибудь использовал MQ File Transfer Edition? Другая команда в нашей компании использует Aspera, у кого-нибудь есть какие-либо мысли по этому поводу или другие любимые продукты?
Я пока не знаю, какой у нас бюджет на это. Просто пытаюсь разобраться в пространстве продукта с точки зрения других администраторов.
/ edit - В моей ситуации мы перемещаем полезные данные из двух файлов (один двоичный файл, один метаданные) отсканированных изображений из разных источников в разные места назначения. Мы ждем, пока третий контрольный файл не будет записан с контрольными суммами - когда перемещение завершено, контрольный файл удаляется.
Источники - это, в основном, несколько файловых серверов Windows или Windows SFTP-серверов, которые получают эти файлы из процессов сканирования. У нас также есть источники, которые являются серверами FTP или SFTP, которые получают те же полезные данные от внешних сторон. Место назначения - это набор серверов AIX, которые загружают изображения в архив, поэтому файлы также не остаются в месте назначения. Надежность, безусловно, наша главная задача.
Я думаю, мы перемещаем несколько ГБ каждый день. (Без централизованного ведения журнала я не могу дать лучшего числа.) Бинарные файлы, вероятно, имеют в среднем около 100 МБ, метаданные немного меньше.
3 ответа
Я не использовал MQ File Transfer Edition, поэтому я не могу комментировать это. Я сделал много передач файлов, включая EDI, FTP, AS2, FTPS, SFTP, rsync, SCP, aspera, svn и т. Д. В конечном итоге мой ответ будет зависеть от ваших точных требований. Из того, что звучит, самое важное, что вам нужно, - это надежность передачи файлов.
Во-первых, я бы порекомендовал какую-то стандартизацию платформ, обслуживание и управление, что, похоже, вы и делаете. Сделайте так, чтобы каждый сервер независимо от ОС / конфигурации использовал один и тот же процесс для получения файлов на узлы и с них. Умножение устранения неполадок в разных конфигурациях может сделать простые задачи очень неприятными. Когда я думаю о надежности, я не думаю об окнах, но большую часть времени просто не существует способа избежать этого.
Хотя я не знаю ваших точных требований, я предоставлю вам некоторые возможные решения, если вы сможете уточнить именно ваши потребности (WAN, LAN, размер файла, количество передач в день, важность передач и т. Д.), Я могу предоставить вам более точный ответ. Передачи, которые я настраивал в прошлом, варьируются от небольших файлов <1 КБ до сотен ГБ данных, от людей не платят, если не происходит передача данных, которые могут даже никогда не использоваться, от открытых передач в Интернете до зашифрованные данные, зашифрованные передачи через зашифрованные VPN.
Что вам действительно нужно, так это полу-новый термин в отрасли, называемый управляемой передачей файлов. http://en.wikipedia.org/wiki/Managed_file_transfer
В конце дня получите отчет Gartner Magic Quadrant для этого, просмотрите его и выберите поставщика, который соответствует вашим потребностям. Вы заметите Aspera в списке, но примите во внимание CFI для своих нужд. Учитывая, что вы специально ищете коммерческий продукт, это ваш лучший выбор. Пришлите мне личное сообщение или комментарий, если хотите больше узнать о моих исследованиях в этом секторе.
Вот мой личный вклад.
Централизованный FTP:
Это хорошо, потому что FTP универсален, он используется во многих местах и имеет такую большую поддержку в разных системах. Многие популярные FTP-серверы обеспечат поддержку многих методов аутентификации, а также протоколов. Если вы можете централизовать сервер для всех узлов, то устранение неполадок становится намного проще, когда что-то идет не так, вы проверяете журнал сервера или, в идеале, автоматически отправляете отчеты по электронной почте, и если в этом нет ничего плохого, это довольно красиво. очистите его от проблемы клиента или сети. Проблема в том, что FTP не идеален, он может легко потерпеть неудачу и особенно медленен при работе с большими объемами небольших файлов. В разных ОС вы можете встретить проблемы с именами файлов и многое другое. Если вы собираетесь рассмотреть это решение, используйте клиенты и сервер, который может поддерживать простую проверку файлов. http://en.wikipedia.org/wiki/Simple_file_verification. Механизм, используемый для проверки файлов, прост и может быть проверен на разных платформах. Существует ряд серверов, которые поддерживают проверку файлов по мере их загрузки и могут автоматически сообщать, если файл не проходит проверку, наряду с проверкой полных наборов файлов, а не отдельных файлов, также обеспечивая некоторый процент загрузки всей структуры. gltfpd является популярным, но имейте в виду, что это очень удобно для настройки, но как только вы настроите его, вам, возможно, больше не придется его трогать. http://www.glftpd.com/. Gene6 также довольно популярен
Rsync файлы
Я использовал rsync со скриптами довольно много, и я обнаружил, что это очень надежно и довольно надежно при учете проверки ошибок. Из-за этого вы найдете rsync популярным среди скриптов резервного копирования. Я не знаю многих готовых программ для rsync, так что вы пытаетесь найти решение для этого, и снова у вас не будет централизованной регистрации, и вы можете столкнуться с множеством тех же проблем, но, честно говоря, я обнаружил, rsync достаточно надежный, и с дельта-передачей с большими наборами файлов и проверкой целостности это довольно быстрый и грязный способ добиться цели.
Aspera
Aspera - отличная технология в своей основе для передачи данных с высокой задержкой и высокой пропускной способностью. Если вы не передаете по глобальной сети и не передаете большие наборы данных, я бы не рекомендовал это делать. Я запускаю большое развертывание Aspera, и оно изобилует проблемами переноса и ошибками программного обеспечения. Если вам нужна базовая функциональность, это довольно хорошее решение, но когда дело доходит до более сложной обработки, будьте готовы написать свои собственные сценарии для передачи данных. Программное обеспечение, кажется, в большей степени ориентировано на малые нишевые компании, и они, похоже, борются в масштабах всего предприятия. Централизованное ведение журналов, которое они имеют с одним из своих продуктов, решит задачи централизованного ведения журналов, и их предварительная и последующая обработка также будут работать для ваших нужд, но просто имейте в виду, что в конечном итоге вы можете потратить приличную сумму денег на полуработающее решение, Я упомянул CFI выше, их продукт гораздо более корпоративный, но они борются за единый опыт. В зависимости от ваших потребностей, не поверьте мне на слово, попробуйте их продукты сами.
Система контроля версий
Сначала я скажу, что это не соответствует требованиям, но это еще один вариант. Если файлы, которые вы передаете, не являются транзакционными, рассмотрите возможность хранения этих файлов в системе контроля версий. В этом случае, когда файл необходимо передать, он регистрируется в хранилище версий, а при необходимости он синхронизируется на удаленном конце. В случае, когда вам нужен контроль версий и файлы, возможно, для взаимодействия друг с другом, а также централизованный сервер, это может быть хорошим вариантом.
В качестве заключительного примечания обратите внимание на то, что использует твиттер для передачи файлов конфигурации через множество узлов: http://engineering.twitter.com/2010/07/murder-fast-datacenter-code-deploys.html
Еще раз я не могу подчеркнуть, что правильный ответ основан на ваших точных требованиях.
Надеюсь, это поможет вам.
Я внедрил WMQ FTE для нескольких клиентов, и он определенно соответствует требованиям, которые вы описали. Вы можете настроить его так, чтобы он отслеживал контрольный файл, а затем перемещал файлы данных и удалял контрольный файл. Это также может быть вызвано сообщением MQ, которое отправляет объект, создающий файлы. Агенты FTE могут подключаться к WMQ в качестве клиентов, поэтому в небольшом развертывании вам нужен только один сервер WMQ, и агенты FTE могут быть на всех упомянутых вами платформах. Единственным исключением является то, что агент z/OS FTE должен иметь локального администратора очередей (из-за отсутствия клиента WMQ для платформы z / OS). Конечно, он также настроен для специальных, управляемых пользователем переводов.
FTE использует все непостоянные сообщения и легкий поток управления между двумя агентами (конечно, через WMQ), который получает поток данных. Предполагая, что обе стороны активны, вся передача происходит в памяти, при этом ничего не записывается на диск в администраторе очередей, поэтому он работает очень быстро. Если одна сторона выходит из строя, передача поднимается с того места, на котором она остановилась, как только сервис восстанавливается. Оба агента проверяют сумму данных и файлов, чтобы в случае сбоя исходного или целевого файла во время сбоя или во время передачи передача прекращалась с соответствующим сообщением об ошибке.
Любой вид автоматизации, который вам может понравиться, может быть выполнен с помощью Ant или любого исполняемого файла, который вы хотите вызвать, либо на стороне отправителя, либо на стороне получателя, до или после передачи. Например, у меня есть один клиент, который шифрует файлы, исходящие на SFTP-серверы своих клиентов, а затем расшифровывает файлы по прибытии. Это делается путем вызова Ant для запуска GPG перед исходящими и после входящих передач.
Когда я работал в крупной страховой компании, мы использовали Connect: Direct, чтобы автоматизировать и управлять передачей файлов (чаще всего через SSL/TLS) между различными серверами windows/linux/AIX/mainframe.