Наша команда по системам внедряет Double Take на клиентских машинах для репликации в реальном времени на серверы аварийного восстановления. На рабочих столах разработчика обычно постоянно открыто несколько экземпляров Visual Studio, которые генерировать 4 ГБ операций ввода-вывода на запись в час. Даже когда Visual Studio простаивает, кажется, что каждые несколько секунд возникают большие всплески ввода-вывода. Double Take может реплицировать только около 800 МБ за тот же период времени, поэтому кажется, что он догоняет одно из ядер ЦП на клиенте на 100%. Машина почти полностью останавливается, Visual Studio перестает отвечать, поскольку кажется, что она конкурирует с Double Take for IO в тех же файлах.
Есть ли способ настроить Double Take так, чтобы он хорошо играл на машине разработчика? Есть ли у кого-нибудь опыт или советы по запуску Double Take на клиентских машинах в целом? Есть ли другое решение, которое лучше подходит для аварийного восстановления? Это не обязательно должна быть репликация в реальном времени.
Вопрос, который вы должны здесь задать (IMO), заключается в том, почему вы тратите время и усилия на покрытие клиентских рабочих станций в сценарии аварийного восстановления. Что на этих клиентских машинах критично и почему не хранится в сети?
Скорее всего, здесь скрывается больше проблем. Клиентские рабочие станции не предназначены для обеспечения высокой доступности. У большинства компонентов нет избыточности.
Я подозреваю, что даже если вы удвоите работу для репликации клиента, вы все равно будете накладывать пластырь на гораздо более глубокую проблему.
AFAIK, у DT нет ничего, что действительно применимо к вашему сценарию. Вы можете использовать диспетчер подключений DT, чтобы ограничить окно передачи (на основе времени и \ или порога очереди), или вы можете установить ограничение полосы пропускания, определяющее, какую полосу пропускания может использовать DT. Вы также можете заставить DT сжимать реплицированные данные. Ни один из этих вариантов не подходит для вас.
Кстати, почему именно DT? Это дорогое решение для машины разработки.
Я опаздываю на вечеринку, но Visual Studio создает много шума в пространстве TEMP на рабочей станции разработчика. Если бы вы могли исключить из репликации общие области временных файлов, это могло бы вас спасти.