2010-07-16 1 views
2

Мне нужно найти решение для сложной передачи файлов. Я могу это сделать, но я хочу знать, знает ли кто-нибудь о решении с открытым исходным кодом, которое уже делает 90% того, что я хочу сделать.Передача файла с нечетными требованиями: отказоустойчивая, но не дублирующая

Требования очень странные. Не пытайтесь их понять, это адское сочетание политики, территории и бюрократии.

Я управляю двумя серверами, каждый из которых захватывает файлы из группы источников восходящего потока. У меня есть некоторое влияние (но не полный контроль) на источники. Мои два сервера собирают эти файлы и связывают новые файлы с каталогом обработки (это немного упрощается).

Два моих сервера, назовем их A и B, теперь должны отправить эти файлы на пару серверов вниз по течению. Я почти не контролирую нисходящие серверы, назовем их X и Y.

  1. Файлы уникально идентифицируются по их имени файла. Если у него одинаковое имя файла, это тот же файл.
  2. Существует потенциально бесконечный поток файлов. Их имена содержат метку времени.
  3. Серверы A и B (мои серверы) обычно получат одинаковые файлы. Если файл появляется на сервере A, он будет 98%, вероятно, отображаться на сервере B с тем же именем файла.
  4. A и B должны нажимать файлы, которые они получают на X и Y, используя sftp или аналогичный. Мне не разрешено устанавливать программное обеспечение на X и Y. Мне не разрешена учетная запись оболочки, даже ограниченная. Теперь становится странно:
  5. Каждый файл, полученный A и/или B, должен быть скопирован ONCE на A или B (но не на оба) до X или Y, но не для обоих.
  6. Источники, расположенные выше меня, могут содержать дубликаты одного и того же файла (это не проблема для меня на серверах A/B, каждый из них может отслеживать, что они тянут).
  7. Должны быть допущены отказы A, B, X или Y (пока его партнер все еще активен). Поток файлов из ==> A/B ==> X/Y не должен останавливаться.

Что мне нужно, так это то, что мой местный отдел хотел бы, чтобы файлы, дублированные между A и B, были безопасны, но нижестоящие приемники (другой отдел) настаивают на том, что им нужны X и Y для отказоустойчивости ... но каждый файл должен быть скопирован только в A или B, ни один из них (или только в редких ситуациях). Если бы нисходящие люди просто управляли дублирующимися файлами, это было бы легко (er). Учитывая, что имена файлов быстро идентифицируют дублирование, это действительно не сложно. Ну, они не хотят этого делать. Даже если отказ X или Y потенциально потеряет некоторые файлы. Идите фигуру.

Итак, я работаю над алгоритмом, чтобы сделать все это, и я сделал некоторый прогресс, но будет немного сложно справляться с условиями гонки, сбоем узлов, перезапуском узлов, в основном -независимый характер A и B и т. д. Я буду немного расстроен, если через месяц усилия друг скажет: «Почему вы просто не использовали SuperOpenSourceSolution? У вас могло получиться работать за один день!»

Итак ... кто-нибудь знает о готовом (или почти таком) решении? Я знаю, что там есть общие решения MFT, но я не слышал, чтобы они могли делать такие вещи.

Я взглянул на rsync, но я не вижу, как он справится с странным распределением.

Спасибо.

+0

Ничего себе! выглядит почти, но не совсем совсем не похоже на реальную жизнь! –

+0

Вам нужно повторно передать файлы, уже отправленные в X, если X не удается? (Я имею в виду ... отправить его на Y) –

+0

Это банк? Звучит типично. – Mau

ответ

1

Похоже, что условие (5) является жестким и немного смягчено, если A и B могут запросить состояние X и Y, которое вы не укажете.

Это напоминает мне протокол NNTP Ihave/Sendme, который может пригодиться.

Если вы не свободно в состоянии сделать «у вас есть P» запросы машин X и Y, у меня есть ощущение, что задача может быть доказуемо невозможно, как классический Two Army Problem. Если это так, тогда вам нужно делать то, что проектировщики сталкиваются с невозможными ограничениями, и либо предоставить удовлетворительное решение (например, TCP 4,3-way handshake), которое работает достаточно времени, либо если «достаточно хорошо» недостаточно, вы должны показать управление что они буквально попросили невозможного.

Я знаю, что вы сказали, что не спрашивайте, но зачем запрещать идемпотентные переводы, как в случае ограничения (5)?

+0

Спасибо, msw! Смешно упоминать протокол usenet, поскольку usenet был первым интернет-сервисом, который я когда-либо использовал, и мне это нравилось. Я буду держать протокол ihave/sendme в своей следующей встрече с проектировщиками, расположенными ниже по течению, может быть, мы сможем договориться. Ссылка на две армии может дать моему запросу некоторый вес. Еще раз спасибо! – dougkiwi

+0

Что касается «двух армий»: для таких проблем нужны ОПЕРАЦИИ. Но вам нужно сотрудничество между двумя частями для их реализации. Тем не менее, чтобы убедиться, что файлы действительно (или нет), вам понадобится двухфазная фиксация ... –