Showing posts with label active. Show all posts
Showing posts with label active. Show all posts

Sunday, March 25, 2012

BEST RECOMMENDATION FOR A TESTING SCENARIO

guys:
I would like to have your best advise.
We am planning to install Passive/Active SQL server Clustering in the
production environment that includes two identical Dell PowerEdge 6650 dual
processor servers with a External Disk Storage PoweVault 220S. We have
bought two copies of Windows 2003 enterprise (for each one of the servers)
and one only copy of SQL Server 200 enterprise Edition licensed per
processor (I was told that only one copy of this software ins needed in an
Active/Passive mode)
On the other hand, since the configuration above would be in production at
all times, we would like to have similar scenario for development and
testing purposes.I was advised to replicate the same hardware and software
scenario described above, however, as you can see, it would be a costly
endeavor. Each Dell 6650 costs approximately $20,000 (two processors, 8 GB
RAM, 2 MB cache) the External Raid $8,000, the Windows 2003 Enterprise
server software $3,000 (for the two servers), and the SQL Server 200
enterprise software about $24,000 (license for two processor, for just one
server)
Could you please if you see any issue in the production scenario? Are we Ok
using only one copy of SQL server there?
Secondly, do we have any other choice for a development and testing
scenario? Most people recommend that a development and testing scenario
would be, if not identical, at least very similar to the production
scenario. I was planning to get those Dell 6650 server but with a single
processor, only 1 GB of RAM, and 1 MB cache (or even 512 KB). In terms of
software I was also told that one economical approach would be to acquire
the MSDN Universal subscription that allows use software for testing
(Windows and SQL server)
Thirdly, do you have any other (most economical recommendation in terms of
hardware and software for our development and testing scenario? How critical
is that this has to be very similar (or identical) to the production
scenario?
Thanks for all your answers
White
First off, what you are implementing is a single instance cluster, not an
active/passive cluster. It may just look like a term, but there is a very
dramatic difference between the two.
As for licensing SQL Server in a cluster, you have exactly what you need.
The easiest way to tally up licensing for a cluster is to ask how many SQL
Servers you can connect to from an application. In your case, it would be
1.
For the dev/testing environments, you do not need to purchase the Enterprise
Edition of SQL Server. You can use the Developer Edition which gives you
the full functionality of Enterprise Edition without all of the cost and
hardware requirements. This even allows you to simulate a cluster, you just
don't get full clustering functionality. But, you do NOT need to stuff
clusters into your dev/test environments. There is no case that I'm aware
of where a clustered SQL Server behaves differently with respect to an
application than a standalone SQL Server.
My recommendation would be to purchase a Dell 6650 with the external RAID
array. Depending on your testing and development scenario, you can very
easily place BOTH dev and test on the same machine in different SQL Server
instances without collisions. The only real reason to have completely
different systems for the two would be if you are doing a lot of very heavy
performance related work. If not, you can get away with a single machine
with external array + Windows 2003 Server + SQL Server 2000 Developer
Edition.
I can send you my address so you can send a check for the ~$54,000 that I
just saved you.
Mike
Principal Mentor
Solid Quality Learning
"More than just Training"
SQL Server MVP
http://www.solidqualitylearning.com
http://www.mssqlserver.com

Sunday, March 11, 2012

Best Practice for Domain Account for SQL Services?

Hello,

I've done some searching, but have found no definite answer yet. Our SQL 2005 servers are members of Active Directory Services. We want to run SQL services using an ADS account.

I see 7 SQL services in the SQL Server Configuration Manager: Integration Services, FullText Search, SQL Server, Analysis Services, Reporting Services, Browser, and Agent.

Question: Is it a bad move to run them all using the same domain account? I mean, wouldn't this give, say the Browser service, more privileges than it needs by allowing its account access to the same resources as, for example, the Agent service? What I'm concerned about is a vulnerability in one service compromising another service.

I would like to be able to use one domain account for all 7 services on two SQL servers, but I have a feeling this is a poor choice.

What is the best method for running SQL services using a domain account?

Thanks,

-Tony

Perhaps these articles will help you in your decison process:

Configuration -Service Accounts, SQL Server 2005 - Setting Up Windows Service Accounts
http://msdn2.microsoft.com/en-us/library/ms143691.aspx
http://msdn2.microsoft.com/en-us/library/ms143504.aspx

Configuration -Service Accounts, SQL Server or SQL Server Agent service account
http://support.microsoft.com/kb/283811/en-us
http://msdn2.microsoft.com/en-us/library/ms143691.aspx

Configuration -Service Accounts,Selecting an Account for the SQL Server Agent Service
http://msdn2.microsoft.com/en-us/library/ms191543.aspx
http://support.microsoft.com/kb/907557

Often, SQL Agent needs a higher level of access to network resources than the SQL Server Service. It is a good practice to provide the minimum level of access to local and network resources as is required for the task. It would not be unusual to have multiple domain accounts for the various SQL Services. In fact, for those services that require network resources, some folks will have separate domain accounts for each server. I have seen every SQL Agent service running under a unique account -the theory is if one server is compomised, unique accounts protect the remaining servers from compromise.

It is a balance between amount of security desired vs. amount of effort required to maintain that security. (As always...)