Позвольте от ссылающегося домена для основного HTTP защищенного апачского сайта SSL
Мы в настоящее время используем Сервер 2008 DFSR для передачи 900 ГБ файлов приблизительно с 3 ГБ, изменяющимися ежедневно. Наша топология является единственным концентратором с 3 спицами. Каждый говорил, находится на 4Mb/1Mb подключении ADSL, разделенном примерно 300-500KM. Наш узел связи имеет 10Mb/10Mb соединение.
Кроме отсутствия захвата файла, после некоторых начальных проблем конфигурации DFSR работал гладко, и мы очень довольны им. Я настоятельно рекомендовал бы Серверу использования 2008 или Сервер 2 008 R2 для DFSR, поскольку существует МНОГО улучшений, которые помогут с Вашими медленными каналами.
В ответе на Ваши вопросы:
- Можно предварительно отобрать данные с помощью внешнего жесткого диска на удаленном сайте, для сокращения начальной репликации.
- Я вполне уверен, Вы не можете добавить дополнительную информацию способом перед семенем (Ваш пример на 200 ГБ), как, после того как начальная репликация сделана, это становится мультиосновной топологией.
- Часовой пояс не должен иметь никакого влияния, особенно если Вы не изменяете расписания репликации по умолчанию.
- Офлайновый Доступ - локальная копия хранится в каждом, говорил сервер, таким образом, у Вас будет доступ к нему, если WAN снизится. После того как WAN возвращается, репликация продолжится.
- DFSR использует RDC и только копирует изменения, таким образом, Вы будете видеть большое сокращение размеров передачи. Наша текущая репликация сообщает о 57,88% сбережения с 74,36 ГБ, полученными от фактического реального размера на 176,55 ГБ. Это начиная с последнего сервисного перезапуска.
- Захват файла не поддерживается в DFSR, однако конфликты могут контролироваться через журналы событий.
- В то время как не идеальный, это должно работать с Вашими медленными каналами, поскольку у нас есть подобные ссылки.
Я не рекомендовал бы WAFS Globalscape, на основе последнего комментария (шахта) в этом сообщении в блоге: http://blogs.technet.com/b/askds/archive/2009/02/20/understanding-the-lack-of-distributed-file-locking-in-dfsr.aspx?CommentPosted=true&PageIndex=2#comments, Возможно, продукт изменился с тех пор, но это только были несколько месяцев.
Возможно, вы захотите немного улучшить свой механизм аутентификации; учитывая, что заголовок referer контролируется клиентом, я ожидаю, что кому-то понадобится около 18 секунд, чтобы понять, что вы делаете, и обойти это.
Механизм, который я бы использовал, вероятно, будет включать установку cookie для вашего сайта, что означает, что пользователь прошел предварительную аутентификацию. Затем вы можете проверить наличие (и криптографически достоверное) содержимое этого файла cookie в вашей конфигурации apache и разрешить доступ таким образом.
Я предлагаю вам использовать сценарий авторизации
т.е. mod_python http://modpython.org/live/current/doc-html/dir-handlers-auh.html
вы, вероятно, можете использовать что-то вроде этого:
def authenhandler(req):
if req.headers_in.get("referer") == 'yourhostname':
return apache.OK
pw = req.get_basic_auth_pw()
user = req.user
if user == "spam" and pw == "eggs":
return apache.OK
else:
return apache.HTTP_UNAUTHORIZED
mod_perl может обрабатывать аутентификацию по сценариям и, возможно, на других языках тоже