|
|
|
SSC-Dedicated
           
Group: Administrators
Last Login: Today @ 3:30 PM
Points: 31,436,
Visits: 13,751
|
|
I'm sure Mr. Poole might give Andy, Brian, and myself a small tap on the noggin. We indeed run IIS and SQL on one box, more a matter of economics than preference. Also the hosting costs tend to jump up like Daffy when Bugs sets the dynamite under him.
I agree with the article for the most part. SQL doesn't need to be admin, but it usually is. In either case, your web server and SQL server need to have strong passwords, be patched, and sit behind a firewall. I always recommend separate boxes, mostly because people blame SQL for issues when their application is causing them. Having SQL on it's own box usually limits these arguements.
With W2K3, however, the resilience of IIS has grown along with the ability to stop and start sections of it without affecting other processes. Not that I'd want to do it, but there are cases where you need to.
Steve Jones sjones@sqlservercentral.com http://www.sqlservercentral.com/columnists/sjones www.dkranch.net
Follow me on Twitter: @way0utwest
 Forum Etiquette: How to post data/code on a forum to get the best help
|
|
|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Tuesday, February 22, 2011 9:03 AM
Points: 171,
Visits: 16
|
|
Great article that addresses a classic question. We, for the most part, keep SQL and IIS apart. There are a few cases where it makes sense, especially for a small uncritical app to run it all on one box.
This will be an article I keep!
|
|
|
|
|
SSC Eights!
      
Group: General Forum Members
Last Login: Tuesday, July 31, 2007 8:20 AM
Points: 885,
Visits: 1
|
|
Hi
I tend to take this article as relating purely to production server envs only, although, it brings up some interesting chnge control and testing problems when you dont have a "similar" config in TEST/Pre-Prod. Anyhow, my experience has shown that the seperate web/app server and DBMS servers are mandatory for any serious app that requires stability and scalability. Many a time has IIS or COM+ gone wild, and perf tuning, problem resolution, and patching is much easiser to manage, measure and plan for in the future running seperated servers. Another key reason is security, remembering the servers inside and outside of the DMZ, private networks etc, all make hacking a damn site more difficult in the long term and can really "save your bacon".
Price is always an interesting arguement in the long term, i have had really cpu intensive apps that generally do bugger all work at the db end, and then people start asking questions about how we can utilise all the grunt we have in all the servers. This is a problem for those IT managers that want to cut some dollars here and there and want to host larger numbers of incompatible apps and other 3rd party SW onto a smaller and smaller number of servers and wonder why there are performance problems.
If you app has definable tiers, is a security/performance concern, differing patch/sw requirements at a variety of levels, always run seperate servers.
Ive never seen how large scale hosted envs work so I cant comment on any of that :)
Cheers
Ck
Chris Kempster www.chriskempster.com Author of "SQL Server Backup, Recovery & Troubleshooting" Author of "SQL Server 2k for the Oracle DBA"
|
|
|
|
|
SSCertifiable
       
Group: General Forum Members
Last Login: Friday, May 17, 2013 8:10 AM
Points: 5,955,
Visits: 272
|
|
Hi David,
quote:
I wish that there was a specific book, course or single point reference for SQL Server security.
http://www.securitytracker.com maintains a weekly security email update, which shows the latest flaws, bugs, security holes discovered.
Not only SQL Server related, but how good is a secure SQL Server when the environment is insecure?
Cheers, Frank
-- Frank Kalis Microsoft SQL Server MVP Webmaster: http://www.insidesql.org/blogs My blog: http://www.insidesql.org/blogs/frankkalis/
|
|
|
|
|
SSCrazy
      
Group: General Forum Members
Last Login: Today @ 8:46 AM
Points: 2,750,
Visits: 1,410
|
|
quote:
SQL Server can run perfectly fine if it's not an administrator on the system.
I think this is worth an article in its own right. When I did the MS courses for SQL6.5 it said that the logon under which SQL Server or SQL Agent runs should be an admin. Now that this is no longer the case I should like to know how tightly I can lock down the user accounts for my MSSQLSERVER and SQLSERVERAGENT services. Ideally I want them tighter than two coats of paint!
quote: I'm sure Mr. Poole might give Andy, Brian, and myself a small tap on the noggin.
Not unless I was feeling particularly suicidal! First off I should like to reitterate that the article is intended for a production or non-development environments. Secondly, it is the stuff I don't know that worries me. I'm not stupid or lazy but there are gaps in my knowledge that could leave my servers exposed to outside attack. I am sure that you three have 99.99999999% of the bases covered with regard to security.
The world has moved on significantly since SQL6.5. You could be a DBA without having to know that much about general NT administration. Now I am convinced that any serious DBA should become Win 2Kx MCSE standard.
LinkedIn Profile
|
|
|
|
|
SSC-Enthusiastic
      
Group: General Forum Members
Last Login: Tuesday, March 13, 2012 9:34 AM
Points: 141,
Visits: 61
|
|
Completely agree with the points made about security David, it's usually what you don't know about that the latest hack will take advantage of. Recognising that, whilst at the same time testing and applying the latest patches as they become available keeps you from becoming complacent and alert to the risk.
Security issues aside, I've experience running SQL Server 7 & 2000 against IIS and have found that the two most definitely DO compete for memory even on relatively lightly loaded systems. I'm sure it's possible to get a good compromise between the two on a system with plenty of RAM, although personally I don't like limiting the memory that SQL Server can allocate to itself, especially if it is being used in a changing environment and hosting more than just one database, as memory requirements can grow and cause problems you didn't expect when first tuning for optimal memory needs. In a sentence, IIS and SQL Server don't make good bedmates. You can spend more time sorting out the issues than buying a new server.
The other practical problem I've found is that third party vendors like to release patches to their (web based) software on a regular basis, and some of these require server re-boots to initialise IIS components. Obviously this is hardly ideal if the database server is hosted on the same box, serving up data to more than a single set of users using different apps, as the outage will take down all of the apps., not just the one that needs patching.
However, for hosting internal development sites or a single non-profit making site, with a single database, I would imagine the cost implications will almost always outweight the resiliance arguments. Just hosting SQL Server is expensive, without putting it on a separate box.
Edited by - jonreade on 06/23/2003 03:20:56 AM
Jon
|
|
|
|
|
SSCertifiable
       
Group: Moderators
Last Login: Thursday, May 09, 2013 12:38 PM
Points: 6,462,
Visits: 1,384
|
|
|
|
|
|
Keeper of the Duck
Group: Moderators
Last Login: Today @ 1:13 PM
Points: 6,584,
Visits: 1,790
|
|
quote: I think this is worth an article in its own right. When I did the MS courses for SQL6.5 it said that the logon under which SQL Server or SQL Agent runs should be an admin. Now that this is no longer the case I should like to know how tightly I can lock down the user accounts for my MSSQLSERVER and SQLSERVERAGENT services. Ideally I want them tighter than two coats of paint!
I cover the basics here, but I do need to update because it doesn't go into specifics and doesn't cover file/registry permissions.
K. Brian Kelley http://www.truthsolutions.com/ Author: Start to Finish Guide to SQL Server Performance Monitoring http://www.netimpress.com/shop/product.asp?ProductID=NI-SQL1
K. Brian Kelley, CISA, MCSE, Security+, MVP - SQL Server Regular Columnist (Security), SQLServerCentral.com Author of Introduction to SQL Server: Basic Skills for Any SQL Server User | Professional Development blog | Technical Blog | LinkedIn | Twitter
|
|
|
|
|
SSC Rookie
      
Group: General Forum Members
Last Login: Thursday, August 30, 2012 12:27 PM
Points: 49,
Visits: 38
|
|
Good article. In my environment, security is constantly under review. IIS + SQL (same server) = BAD. Enjoyed seeing the other reasons.
|
|
|
|
|
Forum Newbie
      
Group: General Forum Members
Last Login: Friday, June 04, 2004 4:15 PM
Points: 1,
Visits: 1
|
|
Hi,, I like your article, great and many thanks, I like your writing style, And then there was this. .......OK I know that hackers are developers in much the same way that terrorists of which we approve are called freedom fighters!....... Coming from South Africa and having grown up in an extremely oppressive regime I know that it will take a lot more explaining about what freedom fighters are than you are attempting here. Keep up the good work! Antonio
|
|
|
|