У нас есть сервер Windows Server 2008, которому требуется очень много времени безотказной работы. Нам нужна отработка отказа в случае, если по какой-то причине нам потребуется отключить его, например, обновление оборудования, обновление программного обеспечения и т. Д.
Он работает в основном с FTP (и несколькими другими менее важными службами).
Это не обязательно должно быть автоматическим. Это можно сделать вручную, но это должно быть гладко, чтобы исключить человеческую ошибку.
У нас есть дополнительный Windows Server, который мы думаем использовать в качестве шлюза. Мы думаем о предоставлении NAT, чтобы просто перенаправить порт FTP на другой сервер для аварийного переключения. Это лучшее решение с учетом наших обстоятельств?
PS: Я знаю, что с FTP сложно, например: нам нужно убедиться, что внешний IP-адрес установлен в программном обеспечении FTP, что мы имеем дело с пассивными портами, зеркалированием файлов и т. Д.
Использование компьютера с Windows Server для предоставления услуг NAT кажется излишним и создает потребность в техническом обслуживании (обновления Windows), что неизменно вызывает сбои в обслуживании FTP-сайта (поскольку вам придется регулярно перезагружать машину «шлюз» NAT). . Я думаю, вам лучше использовать встроенное устройство, которое поддерживает либо решение уровня 3 (например, NAT), либо решение уровня 7 (например, прокси TCP или FTP).
Возможно, вы просто загружаете файлы по FTP и не заботитесь о возможности удаленных пользователей загружать файлы. В этом случае вам, вероятно, удастся уйти от чего-то вроде того, о чем вы говорите, если у вас есть способ объединить любые файлы, полученные во время восстановления после отказа, обратно в корпус рабочих файлов. (Вероятно, это просто XCOPY или что-то в этом роде, и это не имеет большого значения, но, не зная свои серверные системы, трудно сказать.)
Если вы ожидаете загрузки от удаленных пользователей во время аварийного переключения, тогда более серьезной проблемой, чем доступ на уровне сети или на уровне протокола приложения, будет непрерывность доступа к файлам, размещенным на FTP-сервере. Если у вас нет способа смягчить проблему единой точки отказа внутреннего файлового хранилища, вы можете делать все, что захотите, в сети или на уровне приложения и все равно оставаться мертвым в воде.
Возможно, вы сможете использовать что-то простое, например репликацию DFS (или даже просто сценарии репликации с такими инструментами, как ROBOCOPY или rsync), чтобы синхронизировать производственный и резервный FTP-серверы. Окна SLA будут определять, насколько близка к реальному времени должна быть согласованность репликации.