У нас есть несколько процессов, которые перемещают файлы между серверами - SFTP, FTP, SCP; Windows, Linux, AIX; есть компонент рабочего процесса (обычно требуется контрольный файл с именами файлов и хеш-значениями для перемещения пакета связанных файлов). Действие часто инициируется на наших серверах для получения файлов, поэтому нам нужно убедиться, что они уже записаны.
Для этого у нас есть собственные сценарии, но они не всегда работают должным образом, и устранение неполадок, обслуживание и просмотр журналов в этом случае не из легких. Серверов много, а в наших скриптах нет центрального журнала, панели управления / консоли и т. Д.
Для этого мы изучаем коммерческие продукты. Кто-нибудь использовал MQ File Transfer Edition? Другая команда в нашей компании использует Aspera, есть ли у кого-нибудь мысли по этому поводу или другим популярным продуктам?
Я пока не знаю, каков наш бюджет на это. Просто пытаюсь разобраться в пространстве продукта с точки зрения других администраторов.
/ edit - В моей ситуации мы перемещаем полезные данные с двумя файлами (один двоичный файл, одни метаданные) сканированных изображений из разных источников в разные места назначения. Дожидаемся, пока будет записан 3-й контрольный файл с контрольными суммами - по завершении перемещения контрольный файл удаляется.
Источниками в основном являются файловые серверы Windows или SFTP-серверы Windows, которые получают эти файлы в процессе сканирования. У нас также есть источники, которые являются серверами FTP или SFTP, которые получают те же данные от внешних сторон. Место назначения - это набор серверов AIX, которые загружают образы в архив, поэтому файлы также не остаются в месте назначения. Надежность - определенно наша главная забота.
Думаю, мы перемещаем несколько ГБ каждый день. (Без централизованного ведения журнала я не могу назвать лучшего числа.) Бинарные файлы, вероятно, в среднем составляют около 100 МБ, а метаданные - немного меньше.
Я внедрил WMQ FTE для нескольких клиентов, и он определенно отвечает требованиям, которые вы описали. Вы можете настроить его на отслеживание контрольного файла, а затем переместить файлы данных и удалить контрольный файл. Он также может управляться сообщением MQ, которое отправляет объект, создающий файлы. Агенты FTE могут подключаться к WMQ в качестве клиентов, поэтому вам понадобится только один сервер WMQ в небольшом развертывании, а агенты FTE могут быть на всех платформах, которые вы упомянули. Единственное исключение - агент z / OS FTE должен иметь локальный администратор очередей (поскольку для платформы z / OS нет клиента WMQ). Конечно, он также настроен для специальных передач, управляемых пользователем.
FTE использует все непостоянные сообщения и легкий поток управления между двумя агентами (конечно, через WMQ), который подтверждает поток данных. Предполагая, что обе стороны активны, вся передача происходит в памяти, и ничего не записывается на диск в диспетчере очередей, поэтому он быстро кричит. Если одна сторона выходит из строя, передача возобновляется с того места, где она была прервана, как только обслуживание восстанавливается. Оба агента проверяют сумму данных и файлов, так что, если исходный или целевой файл изменяется во время простоя или во время передачи, передача прерывается с соответствующим сообщением об ошибке.
Любой вид автоматизации, который вам может понадобиться в сценарии, может быть выполнен с помощью Ant или любого исполняемого файла, который вы хотите вызвать, как на стороне отправителя, так и на стороне получателя, до или после передачи. Например, у меня есть один клиент, который шифрует файлы, исходящие на серверы SFTP своих клиентов, а затем расшифровывает файлы по прибытии. Это делается путем вызова Ant для запуска GPG перед исходящими передачами и после входящих передач.
Я не использовал версию MQ для передачи файлов, поэтому не могу это комментировать. Я выполнял множество операций по передаче файлов, включая 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 - отличная технология по своей сути для передачи данных с высокой задержкой и высокой пропускной способностью. Если вы не выполняете передачу по WAN и не передаете большие наборы данных, я бы не рекомендовал это. Я запускаю большое развертывание Aspera, и оно изобилует проблемами передачи и ошибками программного обеспечения. Если вам нужны очень простые функции, это довольно хорошее решение, но когда дело доходит до более сложной обработки, будьте готовы написать свои собственные сценарии для передачи данных. Программное обеспечение, кажется, больше ориентировано на небольшой нишевый бизнес, и они, похоже, испытывают трудности при развертывании на предприятии. Централизованное ведение журнала, которое они имеют с одним из своих продуктов, решило бы потребности централизованного ведения журнала, а их предварительная и постобработка также подойдет для ваших нужд, но просто имейте в виду, что вы можете в конечном итоге потратить изрядную сумму денег на наполовину рабочее решение. . Я упомянул CFI выше, их продукт гораздо более корпоративный, но им сложно реализовать единый опыт. В зависимости от ваших потребностей, не верьте мне на слово, попробуйте сами их продукты.
Система контроля версий
Сначала я скажу, что это не похоже на то, чтобы соответствовать требованиям, но это другой вариант. Если файлы, которые вы передаете, не являются транзакционными, рассмотрите возможность хранения этих файлов в системе контроля версий. В этом сценарии, когда файл необходимо передать, он регистрируется в репозитории версий и при необходимости синхронизируется на удаленном конце. В случае, когда вам нужен контроль версий и файлы, которые могут взаимодействовать друг с другом, а также централизованный сервер, это может быть хорошим вариантом.
В качестве последнего примечания проверьте, что использует твиттер для передачи файлов конфигурации через их множество узлов: http://engineering.twitter.com/2010/07/murder-fast-datacenter-code-deploys.html
Еще раз я не могу не подчеркнуть, что правильный ответ основан на ваших точных требованиях.
Надеюсь, это тебе поможет.
Когда я работал в крупной страховой компании, мы использовали Подключение: прямое, для автоматизации и управления передачей файлов (в большинстве случаев через SSL / TLS) между различными серверами windows / linux / AIX / мэйнфреймов.