Безопасность: ключевым моментом является то, что если у вас есть связанные серверы, если один из них скомпрометирован, все они подвергаются значительному риску. Даже если у вас разные учетные данные для каждого пользователя на разных серверах (что остановит доступ злоумышленника к другим ресурсам, если единственным вектором атаки будут утечки / обнаружены / угаданы учетные данные), ссылка может эффективно обойти все это. Ссылка также будет обходить средства защиты, которые скрывают другие базы данных от общедоступной сети, например, в случае, когда один или несколько серверов не передают данные в общедоступный интерфейс, поэтому обычно не видны через ваши брандмауэры каким-либо образом. Вы можете подумать: «Ну, разве такой же риск не проблема с репликацией?» на что ответ да, норепликация между отдельными базами данных приложений и маршрутом связанного сервера может поставить под угрозу другие базы данных на том же сервере (ах), так как связь находится на уровне сервера, а не на уровне базы данных (конечно, вы можете уменьшить этот риск, тщательно контролируя доступ пользователей прав, но вы по крайней мере должны знать об этом при планировании). В качестве дополнительного примечания по безопасности: если серверы не находятся на одном сайте, убедитесь, что вы используете какую-то форму VPN для их соединения, вместо того, чтобы делать SQL Server доступным через общедоступный интерфейс.
Пропускная способность: если все серверы находятся в одном DC с хорошим, быстрым, неизмеренным соединением между собой, вам, возможно, не стоит беспокоиться об этом, но будьте более осторожны с более удаленными соединениями, особенно если ваши пользователи смогут запускать специальные запросы некоторого разнообразия. Сжатие на уровне канала VPN очень поможет здесь для большинства наборов данных, но имейте в виду, что это будет происходить за счет большей задержки, что может усугубить проблему эффективности (см. Ниже).
Эффективность: если вы просто перемещаете порции данных по линии, тогда это не является большой проблемой (но рассмотрите возможность блокировки: см. Мой следующий пункт), но как только вы что-то делаете с помощью объединений и т. Д., Существуют ограничения на то, что планировщик запросов может оптимизировать ваши запросы. Если необходимо выполнить много запросов на индексирование, что приведет к очень медленным запросам, если серверы не являются локальными по отношению друг к другу из-за задержки в сети (такая же проблема определенно присутствует и для локальных серверов, но, конечно, в меньшей степени), и вместо этого он может использовать сканирование индекса (использование полосы пропускания для получения выгоды от задержек), потребляя полосу пропускания, и если он удерживает блокировки (чтобы избежать проблем с грязным чтением и т. д.), это также повлияет на другие части приложения.
Блокировка / параллелизм. Отключение от сервера увеличит время выполнения запросов, что усугубит проблемы с блокировкой, о которых вы, возможно, еще не подозревали, и тем самым значительно сократит параллелизм и масштабируемость вашего приложения. Вы должны быть очень осторожны при использовании регулярных и / или длительных кросс-серверных запросов, которые следят за проблемой блокировки и дают соответствующие подсказки планировщику.
Пока у вас есть достаточные средства для управления проблемами безопасности и производительности, я не вижу проблем с использованием связанных серверов, хотя могут быть более эффективные / более безопасные / более надежные / более безопасные способы достижения того же самого результат.