Позвольте мне выделить минутку, чтобы объяснить предысторию проблемы, с которой я столкнулся. У моей компании есть офисы в США и Азии. Пользователи работают с большими файлами САПР. В офисе в США есть NAS (сетевое хранилище), где хранятся все файлы. У пользователей из США нет проблем с открытием файлов, однако пользователям в Азии приходится ждать очень долго. Иногда открытие файла занимает до 30 минут. Это влияет на их продуктивность. Проблема вызвана задержкой в сети (300 мс). В Азии около 300 пользователей.
Ниже приведены некоторые из изученных вариантов.
Я открыт и для других идей. Однако я хотел бы узнать ваше мнение и предложения по программному обеспечению, которое блокирует файл и синхронизирует данные в режиме реального времени. Если кто-то уже внедрил или использует такое программное обеспечение, укажите плюсы и минусы.
У вас уже есть основные варианты:
При работе с большими файлами данных последний дает нам лучшие результаты с дополнительным преимуществом, так как он также позволяет лучше контролировать наши данные и улучшает возможности работы на дому для местного персонала.
Протокол Citrix ICA доказал свою эффективность при использовании каналов связи с относительно высокой задержкой / низкой пропускной способностью и по-прежнему обеспечивает приемлемый пользовательский интерфейс для наших пользователей.
Новые решения для виртуальных рабочих столов даже лучше предоставляют такие вещи, как ускорение видео, которые могут потребоваться в САПР.
Из-за разницы во времени вы можете избежать конфликта файлов, который вас беспокоит. DFS определенно не предназначена для такого сотрудничества. Однако есть способы настроить пространство имен, чтобы пользователи указывали на его / ее локальный сайт. Таким образом, они всегда будут открывать файл ближе к себе. Как только они закроют файл, DFS выполнит репликацию на другой сайт. В случае конфликта (два пользователя на разных сайтах внесли изменения в один и тот же файл) файл, сохраненный последним, будет иметь приоритет, более свободный файл будет помещен в папку Conflict and Deleted, так что работа не будет полностью потеряна.
Для меня это намного лучше, чем централизация файлов и зависимость от доступности сети, устройств оптимизации WAN и т. Д., Которые должны использоваться в качестве дополнения к решению DFS.
С учетом сказанного, для репликации DFS требуются серверы Windows на обоих концах. Таким образом, NAS в США должен быть подключен к серверу Windows для репликации DFS для репликации с Windows Box в Азии.
Вы описываете причину, по которой была изобретена фирма RIVERBED -
«Проблема вызвана задержкой в сети (300 мс)»
Проведите небольшое исследование - у вас есть так называемая «длинная толстая сеть».
мы видим это все время - даже при наличии «надежной связи 1 Гбит / с» между Нью-Йорком и Сан-Франциско.
пользователи никогда не получают больше 8 Мбит / с на TCP-соединение (в Windows 2008 R2 оно было еще ниже в 2003 г.).
Вы, ребята, должны купить Riverbed и покончить с этим ... они стоят 120 000 долларов за пару на сайт, но чего вам стоит эта сеть?
Читая ваш пост, кажется, что проблема в задержке.
Вы уверены, что пропускная способность сети между вашими двумя сайтами вообще не задействована? Насколько это хорошо? Если действительно задержка является единственным виновником, я бы попытался использовать другой протокол, чем CIFS (я предполагаю, что это то, что вы используете, как вы считали dfs). CIFS - действительно болтливый протокол, который создает много обмена данными, что затрудняет использование в сети с высокой задержкой. Можете ли вы вместо этого использовать такие вещи, как NFS?
Правильный индикатор ECM поможет вам более эффективно обмениваться этими файлами. взгляните на Alfresco (версия с открытым исходным кодом и бесплатная версия для сообщества или платная версия), она поддерживает множество протоколов, блокировку и передачу / репликацию файлов.
300 мсек - это нормальная задержка для вашей сети или это вызвано узким местом? если это из-за узкого места, и вы не можете позволить себе обновление канала, некоторое QoS на канале поможет вам определить приоритеты потоков.
относительно вариантов, которые вы разместили:
1: обязательно. помимо кеширования посмотрите QoS.
2: RDP обычно плохо работает и в сетях с высокой задержкой.
3: если вы можете позволить себе размещать данные в облаке ... но убедитесь, что вы не получите более счастливых азиатских пользователей, но не понравитесь нам, пользователям
4: все еще вариант, если вы застряли на CIFS между сайтами.