Application Server Design for .Net

[Chris Gatto]

Hello,

My organization is currently considering the purchase of a new intranet
application server and we are looking for opinions from those who have been
down this road before. In brief the server must support the following:
- 600+ users using various ASP.Net based applications, only 2 currently but
growing over time as old legacy apps are converted;
- Some applications are mission critical, others not so much;
- DB back-end is a seperate SQL-Server 2000 failover cluster (2 machines)
with a shared RAIDed disk array;
- Service must be available 24/7/365;
- App server will act as combo web server (IIS) and application server (.Net
Framework);

We are considering the following specs:
- A 2-machine fail-over cluster with a shared RAIDed disk array (same as our
db design);
- Duel processor machines (2+ GHz cpu's);
- 4 to 8 Gb RAM;

I'd be interested in hearing what others have done for thier setups (pros,
cons, experiences).

Thanks in advance,
C Gatto

 

[William Stacey [MVP]]

The machine sounds good. I would get from a good vendor (i.e. Dell) and not
try to put pieces together to save a few bucks. That support really can
come in handy. RAID 5 is always good. Get the dual channel failover too
and internal failover power supplies. Rack mount *everthing IMO (even the
dog). Buy the rack(s) from the same vendor and get one of the 2U slide out
Keyboard/Monitor rack units with a KVM. Naturally, get a good UPS. Two
things normally fail - power supplies and hard disks. With RAID5 (hot-spare
drive), dual power supplies and UPS, you should have a good start on HW.
The CPUs will depend on your needs. You also did not mention backups. That
is the most import thing. Buy the fastest and best backup drives you can
get your hands on (e.g. DLTs) and good bkup software. Another reason to pick
a good vender as, these days, they all sell OEM solutions configured for the
machine/SAN they sell you. Only way to tell is by perf testing your own
needs or extrapolating from current machine perf. Make sure all the HW is
on the MS supported list or there is a good reason it is not. Management is
also key. Include good management sofware (i.e. ms mom, etc.) in the budget
upfront (don't think you will add it on latter - as you probably will not).
As far as clusters go, I still have a bad taste in my mouth back in the day
using LifeKeeper. They are probably better now, but you may not need for
web stuff. Your ASP and WS apps are stateless, so your client should be
able to fail over to a working server (the SQL cluster is probably required
however but have never did one.) The options here are far and wide.

 

[Nick Malik [Microsoft]]

I would recommend against the shared RAID array on the App servers. You
won't be hosting data on your app servers. Instead, each machine can have a
simple RAID 0 configuration (mirrored drives) for reliability, and good
backup. It is far more important that you be able to publish changes to
your application server than it is to keep data on them, so good management
and publishing software is essential. Make sure to mirror your system
partition as well as your application partition (some folks forget to
mirror the system partition, and end up with costly downtime). Keep your
applications off of your system partition (configure IIS to run from the D:
drive). Make sure that both machines can be backed up with a nice fast
backup unit.

Practice restoring them.

Don't plan to run Biztalk on this config. If you want Biztalk, it will need
its own servers.

Also, you are going to want to put in load balancing so that the same apps
will run on both machines. Normally, for an app server farm, I *start* at
three servers and go up from there, depending on load. Sounds like your
load is light, but if you wait until you have a heavy load, it may be
difficult to fix this. Get three servers in a load balancing configuration.
As for load balancing, Windows Server 2003 supports an excellent software
solution. If you are looking for a hardware solution, I've been happy with
products from F5 in the past, and I recommend them.

Make sure that you have a staging/testing configuration that mirrors the
load balancing, so that you don't wait until your app gets to production to
discover that the developer is storing the application state locally. (This
is much less of a problem in .Net than it was in ASP). Get a server to host
your Application Center Test and a couple of smaller machines to act as
agents, so that you can stress the test configuration and (after hours) the
production configuration as well.

The switches need to be fast and configurable. You will need to either
configure VLANs or have isolated switches. (Configuring the VLAN requires a
little more expertise, but it is considerably more flexible). Get machines
with dual Gigabit Ethernet cards and configure the cards to run as failover
for one another.

I agree with William about the racks and UPS and keyboard drawer. I would
add that you want a digital KVM solution over IP, so that you don't need a
keyboard and screen in every rack, and so that you can control the servers
from a remote location if you need to. This will save real headaches and
can make it much less expensive to live up to that uptime promise.
(especially if you want to get within any real chance of hitting four
nines).

Hope this helps,

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--

 

[Chris Gatto]

William, Nick,

Thank you for your extensive replies. The information you provided has been
very helpful.

Regards,
Chris Gatto

 

[Andrew Robinson]

How about creating a Network Load Balancing cluster. Your web and app server
does not contain data. By creating a web farm, you can add more than 2
machines if you need to. Also, no need for shared RAID systems.

Hardly an expert in the area, but we are looking to do the same thing.

-Andrew