Advise on Licensing SSRS on NLB IIS farm

Hi All,
I have the following question, in my organization we employ a policy of
splitting out our enterprise infrastructure, IIS separated from SQL Server
etc.
We currently have a number of SQL Server 2000 and 2005 clusters and also two
NLB IIS farms (each with 4 nodes).
If I install SQL Server Reporting Services on the NLB farms (databases on
two of the SQL Server Clusters) to make this product available to to people
here then am I right in assuming that firstly I will need Enterprise Edition
of Reporting Services 2005 installed on my NLB's as this is the only edition
capable of scale out SSRS deployment.
Secondly and more importantly will I also need in addition a separate SQL
Server 2005 Enterprise Edition license on each of the nodes involved in the
NLB's (8 nodes therefore 8 licenses)?
If this is the case then I am really concerned at this supposed low cost
reporting solution from Microsoft, as I would then for this scenario need
minimum 10 Enterprise Edition SQL Server 2005 licenses (8 for the NLB nodes
and 1 for each failover cluster (Active/Passive) )
This is no longer a cheap solution for our reporting needs.
Thanks for your help.
Kind Regards,
DesYou have the licensing correct. Enterprise is the only one which supports a
web farm and any server that has Reporting Services installed must have a
server license. How expensive it is for you depends on how you license (CAL
or per processor).
If you price Crystal in such a configuration you will find that it is even
more expensive.
Unless you have one heck of a lot of reports and users then I sincerely
doubt that you need such a configuration.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Des FitzGerald" <dfitz@.dr-sql.com> wrote in message
news:C3A94D89.73DF%dfitz@.dr-sql.com...
> Hi All,
> I have the following question, in my organization we employ a policy of
> splitting out our enterprise infrastructure, IIS separated from SQL Server
> etc.
> We currently have a number of SQL Server 2000 and 2005 clusters and also
> two
> NLB IIS farms (each with 4 nodes).
> If I install SQL Server Reporting Services on the NLB farms (databases on
> two of the SQL Server Clusters) to make this product available to to
> people
> here then am I right in assuming that firstly I will need Enterprise
> Edition
> of Reporting Services 2005 installed on my NLB's as this is the only
> edition
> capable of scale out SSRS deployment.
> Secondly and more importantly will I also need in addition a separate SQL
> Server 2005 Enterprise Edition license on each of the nodes involved in
> the
> NLB's (8 nodes therefore 8 licenses)?
> If this is the case then I am really concerned at this supposed low cost
> reporting solution from Microsoft, as I would then for this scenario need
> minimum 10 Enterprise Edition SQL Server 2005 licenses (8 for the NLB
> nodes
> and 1 for each failover cluster (Active/Passive) )
> This is no longer a cheap solution for our reporting needs.
> Thanks for your help.
> Kind Regards,
> Des
>|||Hi Bruce,
Its not a case of a lot of users or reports - it is a case of a fault
tolerance / disaster recovery solution, we have network load balanced web
farms to facilitate this setup.
The 2 web NLB farms are for integration and production, these need to be
there for our environment, the decision was taken as we are a multi site
organization to have 2 nodes of each NLB in each of our main offices and
then of these 2 nodes each one is in a separate server room, thus 4 nodes =2 per site and of the 2 per site each is separated per server room, disaster
recovery and fault tolerance taken care of.
We will need per processor licensing as intranet reports are made and CAL
will be too expensive.
This is an extremely expensive solution in this case - I have no idea of the
cost of Crystal reports and this is no place to get into this argument as it
does not help.
I just think that Microsoft should de-couple SSRS from SQL Server and make
it Microsoft Reporting Server or something like this with its own licensing
model, the databases can still be stuck to SQL Server but this would make it
more transparent and quite possibly cheaper as Enterprise SQL Server 2005
Processor licenses are not cheap and if the database and reporting server
sides are split as recommended my MS then this does lead to an expensive
solution when each of the IIS NLB nodes need separate licenses.
Thanks for the answer though.
Cheers,
Des
On 08/01/2008 18:00, in article OyC$EghUIHA.280@.TK2MSFTNGP03.phx.gbl, "Bruce
L-C [MVP]" <bruce_lcNOSPAM@.hotmail.com> wrote:
> You have the licensing correct. Enterprise is the only one which supports a
> web farm and any server that has Reporting Services installed must have a
> server license. How expensive it is for you depends on how you license (CAL
> or per processor).
> If you price Crystal in such a configuration you will find that it is even
> more expensive.
> Unless you have one heck of a lot of reports and users then I sincerely
> doubt that you need such a configuration.
>|||Hi Bruce,
A final question for you, if I have SSRS 2000 and SSRS 2005 installed on
these NLBs (8 nodes total as mentioned) do I therefore also need separate
SQL Server 2000 and SQL Server 2005 Enterprise Edition CPU licenses for
these nodes?
So a total of 16 Enterprise Edition CPU licenses for the Reporting Services
setup?
Cheers,
Des
On 08/01/2008 18:00, in article OyC$EghUIHA.280@.TK2MSFTNGP03.phx.gbl, "Bruce
L-C [MVP]" <bruce_lcNOSPAM@.hotmail.com> wrote:
> You have the licensing correct. Enterprise is the only one which supports a
> web farm and any server that has Reporting Services installed must have a
> server license. How expensive it is for you depends on how you license (CAL
> or per processor).
> If you price Crystal in such a configuration you will find that it is even
> more expensive.
> Unless you have one heck of a lot of reports and users then I sincerely
> doubt that you need such a configuration.
>|||I'm confused, you want to have both RS 2000 and RS 2005 installed on each
server?
Why would you do that? RS 2000 reports run fine in RS 2005. And they run
much faster.
In case you do want to do this, I believe a SQL 2005 license allows running
both 200 and 2005 so you would not need two licenses. However, I would check
with whoever you buy licenses from.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Des FitzGerald" <dfitz@.dr-sql.com> wrote in message
news:C3AA8E77.7B74%dfitz@.dr-sql.com...
> Hi Bruce,
> A final question for you, if I have SSRS 2000 and SSRS 2005 installed on
> these NLBs (8 nodes total as mentioned) do I therefore also need separate
> SQL Server 2000 and SQL Server 2005 Enterprise Edition CPU licenses for
> these nodes?
> So a total of 16 Enterprise Edition CPU licenses for the Reporting
> Services
> setup?
> Cheers,
> Des
>
> On 08/01/2008 18:00, in article OyC$EghUIHA.280@.TK2MSFTNGP03.phx.gbl,
> "Bruce
> L-C [MVP]" <bruce_lcNOSPAM@.hotmail.com> wrote:
>> You have the licensing correct. Enterprise is the only one which supports
>> a
>> web farm and any server that has Reporting Services installed must have a
>> server license. How expensive it is for you depends on how you license
>> (CAL
>> or per processor).
>> If you price Crystal in such a configuration you will find that it is
>> even
>> more expensive.
>> Unless you have one heck of a lot of reports and users then I sincerely
>> doubt that you need such a configuration.
>

Advice please - x64 Std Ed best value for money?

Hi
We need to part ways with our 32 Bit SQL 2000 Enterprise Ed server this
year and finally upgrade to 2005.
Purely from a MS / Licensing viewpoint, it would appear that the best
value for money seems to be x64 Std Ed on the per processor license
option on a W2003 x64 Std Ed? (~US$ 5000 / processor)
Rationale
=> It doesn't seem to make sense to go back to 32 bit [PAE / 3GB AWE
and the like]
=> It seems hard to justify the 4 fold price differential between x64
SE and EE - in SQL 2000 we haven't used any of the EE only features
like Indexed Views, and the major reason for EE was for the > 2GB
memory usage.
The server will host about 5 mostly OLTP / LOB Databases Total size of
around 250GB, with around 200 concurrent users. Our current EE 32 bit
setup is 2 x 3Ghz Xeon MP with 6GB RAM and usually runs at about 40%
utilisation.
I have been through
http://www.microsoft.com/sql/prodinfo/features/compare-features.mspx
Am I missing something obvious? (SE x64 can use >> 4GB RAM, has no DB
Size Limitations, and unlimited concurrent connection limitations,
right?)
Thanks in advance
Stuart
Hi Stuart
I am not sure if this will be posted twice!
I think your reasoning is fine if memory was the only issue that you need
Enterprise Edition. If you are definately not going to be using any of the
features available only in EE such as partitioning, online restores, online
indexing etc then SE will be sufficient.
John
"NonNB" wrote:

> Hi
> We need to part ways with our 32 Bit SQL 2000 Enterprise Ed server this
> year and finally upgrade to 2005.
> Purely from a MS / Licensing viewpoint, it would appear that the best
> value for money seems to be x64 Std Ed on the per processor license
> option on a W2003 x64 Std Ed? (~US$ 5000 / processor)
> Rationale
> => It doesn't seem to make sense to go back to 32 bit [PAE / 3GB AWE
> and the like]
> => It seems hard to justify the 4 fold price differential between x64
> SE and EE - in SQL 2000 we haven't used any of the EE only features
> like Indexed Views, and the major reason for EE was for the > 2GB
> memory usage.
> The server will host about 5 mostly OLTP / LOB Databases Total size of
> around 250GB, with around 200 concurrent users. Our current EE 32 bit
> setup is 2 x 3Ghz Xeon MP with 6GB RAM and usually runs at about 40%
> utilisation.
> I have been through
> http://www.microsoft.com/sql/prodinfo/features/compare-features.mspx
> Am I missing something obvious? (SE x64 can use >> 4GB RAM, has no DB
> Size Limitations, and unlimited concurrent connection limitations,
> right?)
> Thanks in advance
> Stuart
>
|||Thanks John - SE x64 will definitely be on the shortlist.
Regards
Stuart
John Bell wrote:[vbcol=seagreen]
> Hi Stuart
> I am not sure if this will be posted twice!
> I think your reasoning is fine if memory was the only issue that you need
> Enterprise Edition. If you are definately not going to be using any of the
> features available only in EE such as partitioning, online restores, online
> indexing etc then SE will be sufficient.
> John
> "NonNB" wrote:

Advice please - x64 Std Ed best value for money?

Hi
We need to part ways with our 32 Bit SQL 2000 Enterprise Ed server this
year and finally upgrade to 2005.
Purely from a MS / Licensing viewpoint, it would appear that the best
value for money seems to be x64 Std Ed on the per processor license
option on a W2003 x64 Std Ed? (~US$ 5000 / processor)
Rationale
=> It doesn't seem to make sense to go back to 32 bit [PAE / 3GB AWE
and the like]
=> It seems hard to justify the 4 fold price differential between x64
SE and EE - in SQL 2000 we haven't used any of the EE only features
like Indexed Views, and the major reason for EE was for the > 2GB
memory usage.
The server will host about 5 mostly OLTP / LOB Databases Total size of
around 250GB, with around 200 concurrent users. Our current EE 32 bit
setup is 2 x 3Ghz Xeon MP with 6GB RAM and usually runs at about 40%
utilisation.
I have been through
http://www.microsoft.com/sql/prodinfo/features/compare-features.mspx
Am I missing something obvious? (SE x64 can use >> 4GB RAM, has no DB
Size Limitations, and unlimited concurrent connection limitations,
right?)
Thanks in advance
StuartThanks John - SE x64 will definitely be on the shortlist.
Regards
Stuart
John Bell wrote:
> Hi Stuart
> I am not sure if this will be posted twice!
> I think your reasoning is fine if memory was the only issue that you need
> Enterprise Edition. If you are definately not going to be using any of the
> features available only in EE such as partitioning, online restores, online
> indexing etc then SE will be sufficient.
> John
> "NonNB" wrote:
> > Hi
> >
> > We need to part ways with our 32 Bit SQL 2000 Enterprise Ed server this
> > year and finally upgrade to 2005.
> >
> > Purely from a MS / Licensing viewpoint, it would appear that the best
> > value for money seems to be x64 Std Ed on the per processor license
> > option on a W2003 x64 Std Ed? (~US$ 5000 / processor)
> >
> > Rationale
> > => It doesn't seem to make sense to go back to 32 bit [PAE / 3GB AWE
> > and the like]
> > => It seems hard to justify the 4 fold price differential between x64
> > SE and EE - in SQL 2000 we haven't used any of the EE only features
> > like Indexed Views, and the major reason for EE was for the > 2GB
> > memory usage.
> >
> > The server will host about 5 mostly OLTP / LOB Databases Total size of
> > around 250GB, with around 200 concurrent users. Our current EE 32 bit
> > setup is 2 x 3Ghz Xeon MP with 6GB RAM and usually runs at about 40%
> > utilisation.
> >
> > I have been through
> > http://www.microsoft.com/sql/prodinfo/features/compare-features.mspx
> >
> > Am I missing something obvious? (SE x64 can use >> 4GB RAM, has no DB
> > Size Limitations, and unlimited concurrent connection limitations,
> > right?)
> >
> > Thanks in advance
> >
> > Stuart
> >
> >

Advice please - x64 Std Ed best value for money?

Hi
We need to part ways with our 32 Bit SQL 2000 Enterprise Ed server this
year and finally upgrade to 2005.
Purely from a MS / Licensing viewpoint, it would appear that the best
value for money seems to be x64 Std Ed on the per processor license
option on a W2003 x64 Std Ed? (~US$ 5000 / processor)
Rationale
=> It doesn't seem to make sense to go back to 32 bit [PAE / 3GB AWE
and the like]
=> It seems hard to justify the 4 fold price differential between x64
SE and EE - in SQL 2000 we haven't used any of the EE only features
like Indexed Views, and the major reason for EE was for the > 2GB
memory usage.
The server will host about 5 mostly OLTP / LOB Databases Total size of
around 250GB, with around 200 concurrent users. Our current EE 32 bit
setup is 2 x 3Ghz Xeon MP with 6GB RAM and usually runs at about 40%
utilisation.
I have been through
http://www.microsoft.com/sql/prodin...e-features.mspx
Am I missing something obvious? (SE x64 can use >> 4GB RAM, has no DB
Size Limitations, and unlimited concurrent connection limitations,
right?)
Thanks in advance
StuartHi Stuart
I am not sure if this will be posted twice!
I think your reasoning is fine if memory was the only issue that you need
Enterprise Edition. If you are definately not going to be using any of the
features available only in EE such as partitioning, online restores, online
indexing etc then SE will be sufficient.
John
"NonNB" wrote:

> Hi
> We need to part ways with our 32 Bit SQL 2000 Enterprise Ed server this
> year and finally upgrade to 2005.
> Purely from a MS / Licensing viewpoint, it would appear that the best
> value for money seems to be x64 Std Ed on the per processor license
> option on a W2003 x64 Std Ed? (~US$ 5000 / processor)
> Rationale
> => It doesn't seem to make sense to go back to 32 bit [PAE / 3GB AWE
> and the like]
> => It seems hard to justify the 4 fold price differential between x64
> SE and EE - in SQL 2000 we haven't used any of the EE only features
> like Indexed Views, and the major reason for EE was for the > 2GB
> memory usage.
> The server will host about 5 mostly OLTP / LOB Databases Total size of
> around 250GB, with around 200 concurrent users. Our current EE 32 bit
> setup is 2 x 3Ghz Xeon MP with 6GB RAM and usually runs at about 40%
> utilisation.
> I have been through
> http://www.microsoft.com/sql/prodin...e-features.mspx
> Am I missing something obvious? (SE x64 can use >> 4GB RAM, has no DB
> Size Limitations, and unlimited concurrent connection limitations,
> right?)
> Thanks in advance
> Stuart
>|||Thanks John - SE x64 will definitely be on the shortlist.
Regards
Stuart
John Bell wrote:[vbcol=seagreen]
> Hi Stuart
> I am not sure if this will be posted twice!
> I think your reasoning is fine if memory was the only issue that you need
> Enterprise Edition. If you are definately not going to be using any of the
> features available only in EE such as partitioning, online restores, onlin
e
> indexing etc then SE will be sufficient.
> John
> "NonNB" wrote:
>