Questions

What are the specifications for the right machine for a webserver like this

Tags:
+
0 Votes
Locked

What are the specifications for the right machine for a webserver like this

sysdevcbc24
I am developing an ASP.Net web application, with a Microsoft SQL Server 2008 R2 backend. I was given the task to come up with the machine and its underlying O/S specifications that would match the needs and usage of the web app and its backend.

Things you might need to know to help you in your suggestion:
>> The web app will be primarily used by 20 or more people from different branches of the company.
>> It is only an intranet site
>> It will also serve as a repository for the files that will be generated by this application

I only need to submit the specs to the requisition team, but I have to justify it first.

By the way, they prefer Microsoft products for uniformity. Im thinking of Microsoft Windows Server 2003 R2. It fits the bill for the backend, but i dunno if it can support the latest ASP.NET. About the machine specs, is there a "recommended" machine specs for my issue?

Thank you very much in advance for your help.
  • +
    0 Votes
    Rob Kuhn

    Without really knowing what your app is doing makes it a challenge to post a recommendation.

    I don't know if it's disk I/O intensive in which case you will want to look at using SAS drives instead of SATA drives. I don't recall how licensing is for SQL 2008 (don't recall if it's per core or per CAL). If the data base is just there to hold meta data and serve as a repository then you may not need more than one core dedicated to SQL.

    I assume you're going to go with the 64 bit version for both OS and SQL. Anything less and I would have to recommend you split the two. In other words you could have the frontend web server be Windows 2003 R2 -32 Bit with 4 GB of RAM and a single dual or quad core CPU (it just needs to run IIS). The backend SQL server I would go 64 bit with at at least 8 GB or RAM (more if budget allows) and a single dual or quad core CPU to start (but with a motherboard that can support a second or more CPUs).

    But since this is a "small" installation, a single dual or quad core CPU with at least 8 GB is where I'd start ... if you could get more RAM I'd go for it. Go RAID-1 for your boot drive and at least RAID-5 or 6 for your data. If you don't expect the data to grow too large you could get away with a pair of 2TB drive in a RAID-1.

    Just too many options without really knowning what your app is doing... :)

    +
    0 Votes
    sysdevcbc24

    Hello Rob.

    The web application im developing is a utilities application, etc. etc., but mainly acts as a reports generator. Before, we have medium-weight distributed applications per workstation that does a couple of small things. Since space, bandwidth, maintenance, and security (and the list of issues continue) are already taking its toll, we decided to centralize.

    Since this app plays as a reports generator, it get its data from another source. The data that forms the report output comes from another database from another machine. After generating the reports, we'll be storing them on the same machine where the app resides for easy download, through this app.

    Where will the SQL server come to play? Here goes one scenario. Some data, especially balances, from the source database change from time to time. The SQL server will then act as a middle-man and will store those volatile data for further use. We're doing this because they give us small leeway in terms of access and changes to the source database.

    I understood the points you've mentioned about the 32-64 bit comparison and memory needs, and the others. What I didn't understand is the RAID thing. To be honest, I don't have the slightest idea. If you're not too busy, I'd be grateful if you'd expound on it.

    Thank you very much by the way for the response.

  • +
    0 Votes
    Rob Kuhn

    Without really knowing what your app is doing makes it a challenge to post a recommendation.

    I don't know if it's disk I/O intensive in which case you will want to look at using SAS drives instead of SATA drives. I don't recall how licensing is for SQL 2008 (don't recall if it's per core or per CAL). If the data base is just there to hold meta data and serve as a repository then you may not need more than one core dedicated to SQL.

    I assume you're going to go with the 64 bit version for both OS and SQL. Anything less and I would have to recommend you split the two. In other words you could have the frontend web server be Windows 2003 R2 -32 Bit with 4 GB of RAM and a single dual or quad core CPU (it just needs to run IIS). The backend SQL server I would go 64 bit with at at least 8 GB or RAM (more if budget allows) and a single dual or quad core CPU to start (but with a motherboard that can support a second or more CPUs).

    But since this is a "small" installation, a single dual or quad core CPU with at least 8 GB is where I'd start ... if you could get more RAM I'd go for it. Go RAID-1 for your boot drive and at least RAID-5 or 6 for your data. If you don't expect the data to grow too large you could get away with a pair of 2TB drive in a RAID-1.

    Just too many options without really knowning what your app is doing... :)

    +
    0 Votes
    sysdevcbc24

    Hello Rob.

    The web application im developing is a utilities application, etc. etc., but mainly acts as a reports generator. Before, we have medium-weight distributed applications per workstation that does a couple of small things. Since space, bandwidth, maintenance, and security (and the list of issues continue) are already taking its toll, we decided to centralize.

    Since this app plays as a reports generator, it get its data from another source. The data that forms the report output comes from another database from another machine. After generating the reports, we'll be storing them on the same machine where the app resides for easy download, through this app.

    Where will the SQL server come to play? Here goes one scenario. Some data, especially balances, from the source database change from time to time. The SQL server will then act as a middle-man and will store those volatile data for further use. We're doing this because they give us small leeway in terms of access and changes to the source database.

    I understood the points you've mentioned about the 32-64 bit comparison and memory needs, and the others. What I didn't understand is the RAID thing. To be honest, I don't have the slightest idea. If you're not too busy, I'd be grateful if you'd expound on it.

    Thank you very much by the way for the response.