Separate Citrix server justification

[david7777777777]

What is the breakpoint where performance would be noticeably better if I separate my app server (which will be running SQL 2000) and my Terminal/Citrix server? I'll be supporting about 900 users, but not all will be connecting at the same time all the time. Not sure of the base connectivity load yet, this is a proposed project. Helpful FAQ's in here too. The project includes users in NY and San Francisco accessing SQL 2000 database on a server in SF using an Access 2000 user interface across what I'm guessing I'll make a Citrix connection. I've configured Citrix client connections but never built a Citrix server from scratch before. Appreciate any battle stories and advice. Thanks.

 

[polymath5]

Are you talking about ONE server to do both SQL and Citrix?? It would have to be a HECK of a server to pull that off.

I'm supporting 60 users at one site, 10 are using Citrix. I have a Quad Xenon for the SQL and a dual Xenon for the Citrix. I wouldn't think of trying to combine them both onto one box.

I'll be curious to see what others chime in with, but if you have even half of your users logged in at one time, you should seperate them between boxes.

 

[CitrixEngineer]

I agree with polymath;

Certainly run (and publish) the front end on the Citrix server(s), but Databases give servers a real pounding, so keep them on separate servers.

Which flavour of Citrix will you be running? If you will be implementing MetaFrame XP, you could use the Database server for your Data Store - a SQL database has far more resilience and is more scalable than a local Access one.


I hope this helps

 

[cnorris517]

The way I like to look at this question is this. Is the application something I would install on a users desktop? If it is then it is reasonable to assume that running it in a metaframe environment is ok. If it is not and I think it's fair to say SQL isn't then I would sepperate them every time.

 

[MikePP]

David

We have an application which has upto 50 users using a VB6 App which uses SQL Server 2000.

SQL Server, Terminal Services, Domain Controller and all other functions reside on the same server.

These servers are installed overseas. The above arrangement allows us to do all configuration work for the server before it is shipped.

This seems to work well.

We have used twin-processor servers with 512MB RAM and fast hard drives. We have yet to see more than 25 simultaneous users, however.

Microsoft documentation advises that application servers should be physically separate, but we have not suffered any technical or performance problems, as yet. We currently have four operational, and are planning a further 7.

Regards

Sadcow

 

[CitrixEngineer]

The reason you can only get 25 users per box, I would suggest, is that you are running SQL server and DC on the same box.

You say you have 4 servers - are they all in their own separate domains with their own individual SQL databases?

(Just curious)

CE

 

[polymath5]

One other down side (IMHO) to having everything on 1 box is it's a single point of failure.

If our SQL server is off line for some reason, everyone can still access the network, print, use Office, etc.

 

[david7777777777]

Hey wait a minute everybody, this conversation wasn't supposed to get this heplful and informative. Shouldn't we paying someone for all of this help? Anyway, thanks for the insight, this brainstorming is just what I need. Now I'm wondering what the functional limits (specifically of Win2K Terminal Services)are of a scenario where I would be using one box handling just the connections with Windows Terminal services and the front-end app (be it Access or some VB app pages) and having the SQL running on its own box. I'm headed to look for the limits for terminal services connection capabilities.

 

[CitrixEngineer]

You can make a donation to Imperial Cancer Research on my behalf, if you like...

The main limitations of T/S (IMO) are;

1. RDP uses higher bandwidth than ICA. Over a WAN link the performance difference is noticeable. ICA wins every time. This also = less users per box. With bespoke VB apps especially, this can be quite a restriction.

2. No shadowing functionality. If you don't use this you won't miss it, but if, like me, you use it regularly to help end-users and occasionally provide training, it's a real limitation.

3. No clipboard support, client drive mapping, limited printer support, lower colour resolutions - in other words, a less productive end-user environment.

4. No load-balancing, no ability to publish applications rather than the entire desktop, less overall control of the user environments.

5. You cannot use any of Citrix's "Value-Add" products, like NFuse, Resource Manager, Installation Manager or the 128-bit encryption of Secure ICA.

Those are my top 5.

CE

 

[MikePP]

Sadcow again

We are only limited to 25 users, because we've never had more users want to get on. I think (but am not sure) we'll be ok for up to about 60.

Regards

Sadcow

 

[CitrixEngineer]

It has been (correctly) pointed out to me that Windows 2000 servers have features which would seem to contradict parts of 3 my above points.

In the name of accuracy, here are the rectifications;

W2k supports "randomised" load-balancing. Actually, on investigation I discovered that this is a kind of DNS round-robin, not LB in the Citrix sense.

W2k features Session Remote Control. While not as flexible as Citrix shadowing, it achieves much the same thing.

Clipboard redirection. With a bit of fudging, data can be transferred from RDP session to local client applications.

I hope this is helpful

 

[MikePP]

Sadcow Again

I am not sure what shadowing is, but it is possible to take remote control of a user's session. You can both see and control the same session at the same time.

In terms of band-width requirements, I don't know how ICA performs - but we get adequate performance over standard dodgy dial-up connections between UK and Africa, Carribean, and also within Africa.

The only limitations we seem to have, by not having Citrix, is the ability to automatically map to local workstation drives.

Sadcow