Риски связанного сервера


10

Я реализую новую функцию, которая требует данных из баз данных на нескольких серверах. Мне просто нужно объединить данные со всех этих серверов и отсортировать их. На ум приходят два варианта:

  1. Используйте связанные серверы и напишите простой запрос для объединения и сортировки данных, которые будут запускаться с одного сервера и собирать данные с других.

  2. Используйте приложение для сбора данных со всех серверов и отправки их обратно на SQL Server для сортировки (не нужно реализовывать сортировку в приложении).

Мы запускаем наши серверы в активных / активных кластерах в SQL Server 2008 r2. Все базы данных имеют одинаковые разрешения. Если у вас есть доступ к одной базе данных / серверу, у вас есть разрешение для всех них. Это общедоступное приложение (которое требует входа пользователя).

Каковы риски использования связанных серверов? Есть ли какие-либо недостатки в безопасности, с которыми я должен быть связан? Есть ли проблемы с запуском связанных серверов в активных / активных кластерах? Будут ли существенные проблемы с производительностью по сравнению с альтернативой?

Похоже, что в отношении связанных серверов наблюдается общее негативное «жужжание», но я не могу найти ничего конкретного, что могло бы заставить меня поверить, что здесь есть какие-то реальные проблемы.


В будущем лучше не задавать вопросы несколько раз. У вас уже есть комментарии, касающиеся SO по вашему вопросу, вы можете просто пометить вопрос для модератора и попросить его перенести вопрос в DBA.SE. stackoverflow.com/questions/16045441/linked-server-risks

Ответы:


13

Связанные серверы могут работать очень хорошо, если вы продумали последствия:

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

  2. Пропускная способность: если все серверы находятся в одном DC с хорошим, быстрым, неизмеренным соединением между собой, вам, возможно, не стоит беспокоиться об этом, но будьте более осторожны с более удаленными соединениями, особенно если ваши пользователи смогут запускать специальные запросы некоторого разнообразия. Сжатие на уровне канала VPN очень поможет здесь для большинства наборов данных, но имейте в виду, что это будет происходить за счет большей задержки, что может усугубить проблему эффективности (см. Ниже).

  3. Эффективность: если вы просто перемещаете порции данных по линии, тогда это не является большой проблемой (но рассмотрите возможность блокировки: см. Мой следующий пункт), но как только вы что-то делаете с помощью объединений и т. Д., Существуют ограничения на то, что планировщик запросов может оптимизировать ваши запросы. Если необходимо выполнить много запросов на индексирование, что приведет к очень медленным запросам, если серверы не являются локальными по отношению друг к другу из-за задержки в сети (такая же проблема определенно присутствует и для локальных серверов, но, конечно, в меньшей степени), и вместо этого он может использовать сканирование индекса (использование полосы пропускания для получения выгоды от задержек), потребляя полосу пропускания, и если он удерживает блокировки (чтобы избежать проблем с грязным чтением и т. д.), это также повлияет на другие части приложения.

  4. Блокировка / параллелизм. Отключение от сервера увеличит время выполнения запросов, что усугубит проблемы с блокировкой, о которых вы, возможно, еще не подозревали, и тем самым значительно сократит параллелизм и масштабируемость вашего приложения. Вы должны быть очень осторожны при использовании регулярных и / или длительных кросс-серверных запросов, которые следят за проблемой блокировки и дают соответствующие подсказки планировщику.

Пока у вас есть достаточные средства для управления проблемами безопасности и производительности, я не вижу проблем с использованием связанных серверов, хотя могут быть более эффективные / более безопасные / более надежные / более безопасные способы достижения того же самого результат.


1

Я испытывал такое же негативное «жужжание», но единственная проблема, с которой я столкнулся при работе со связанными серверами, - это легкость, с которой вы можете передавать большие объемы данных по сети. С точки зрения администратора баз данных, это страшно, если у вас есть не администраторы баз данных, которые могут это сделать, даже если они обещают не злоупотреблять этим.

В вашем случае, по-видимому, нет никакой пользы от написания собственного приложения, так как для этого все равно придется перемещать данные. Похоже, у вас очень простая модель разрешений, поэтому в зависимости от среды может быть целесообразно установить некоторые специальные разрешения, чтобы ссылка не использовалась там, где она не нужна.


0

Связанные серверы создают почти «волшебное» состояние для разработчиков. Но может оказаться очень просто переполнить сеть одним запросом, который может вернуть сотни тысяч записей с 5 серверов за один запрос, и вы также можете заблокировать записи на всех 5 серверах. Я не позволил бы никому, кроме опытных администраторов баз данных, писать запросы, пока вы не обучите одного или двух ведущих разработчиков опасностям блокировки всех баз данных одним запросом.

Связанные серверы - это как наркотик. Когда вы их используете, вы никогда не будете возвращаться и удивляться, почему вы никогда не использовали их раньше. У меня никогда не было проблем, но я всегда был осторожен.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.