В настоящее время мы используем репликацию транзакций в SQL Server 2008, чтобы синхронизировать вторичный сервер отчетов с первичным сервером базы данных. Это хорошо работает и снижает нагрузку на основной сервер. Можно ли масштабировать это решение на несколько серверов отчетов? Мы ожидаем увеличения нагрузки запросов только для чтения, и было бы неплохо иметь возможность добавлять серверы отчетов по мере необходимости.
Общая идея была следующая:
Похоже, для меня это сработает. Пока вы выполняете запросы только к имени NLB. Тем не менее, я бы долго и глубоко изучил документацию по развертыванию и архитектуре MS SQL, чтобы увидеть, есть ли что-нибудь, в котором говорится: «Постройте это таким образом, позаботившись о том, чтобы вы выполняли X, а не Y» или «Это не сработает. вовсе не из-за Фроба ".
Обычно узким местом является дистрибьютор. Убедитесь, что издатель не выступает в качестве собственного дистрибьютора, поскольку при большом количестве («неограниченном») масштабирование нагрузки подписчиков на дистрибьютора становится весьма значительным. Одно из решений - организовать распространение, когда один из подписчиков (или несколько) также будет выступать в качестве издателя / дистрибьютора. Таким образом, можно добавить больше подписчиков в качестве подписчиков на эту подержанную публикацию без дополнительной нагрузки на первоначального распространителя.
Но учитывая возможности кэширования служб Reporting Services и обширные встроенные возможности масштабирования (см. Планирование горизонтального развертывания), возникает вопрос, действительно ли нужна такая топология репликации.
Не было бы лучше иметь несколько серверов, на которых работают службы Reporting Services, и все они запрашивают один сервер компонента Database Engine?
Для RS вообще нет необходимости использовать DE на одной машине.
О службах NLBing Reporting Services: да, можно, но с некоторыми оговорками. Видеть http://technet.microsoft.com/en-us/library/cc281307.aspx.