Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Big Client Hardware Configuration Suggestion
Message
De
13/05/2003 13:04:56
 
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Divers
Thread ID:
00787332
Message ID:
00787803
Vues:
14
Kirk

As other comments have suggested, have more than one Citrix box (your "Application Server"). From what I have heard from various other Citrix implementations, 60 users per Citrix Box (1Gb RAM, single 833Mhz processor) sounds like the limit per server. When you run reporting apps, the user limit is even lower. If you have to choose betwen RAM v Number of Processors per server, go for more RAM.

Your Citrix boxes should be as close as poss to the SQL Database (in network terms).

All the Citrix boxes can be set up as a Citrix farm. If you have the load balancing module in Citrix, the boxes will actually spread the load over the servers, a very useful feature.

Watch out for printing issues. Because Citrix apps load up the local machines' printer driver names when users log on, you must make sure that the printer driver is available on every Citrix box for EACH and EVERY type of printers on your network (therefore standardise on the same make/model of printers if you can).

Citrix pricing works on "per seat" basis - so it costs the same for licensing whether you have 1, 2, or 10 Citrix boxes.

I will be very surprised if all 900 users are on board all the time. You can get half the number or example, and use part of the savings to employ an admin person to terminate inactive Citrix connections! It is very easy to add Citrix licences.

Database Server - SQL clustering works. However please note this. I was originally under the impression that clustering means that you have continuous availability within the context of a single transaction. By this I mean that say you are updating 100 records within a batch/transaction, if your server fails midway, you will not have all your transactions posted. Here, you will need to go back and rollback the SQLServer trans log.

So, clustering simply means that if one of the cluster falls, the other node will start up, and fire up the SQL Server services automatically. The DBA needs then to go and decide whether or not to roll back uncommitted transactions.

Tau



>Wayne
>
>Thanks for your input. I was thinking that you could use the clustering for both, performance and failover. That really is more of a question. Our client is looking for our hardware recommendation for this and not the cost issue. I just tallied up 900 TS-CAL and they were about 62K...that's a lot. I can't imagine 900 simitatious users, but there specs were 30 facilities with 30 users each.
>
>With the sql server portion I was under the impression (I may very well be wrong here) that you can cluster SQL 2000 machines to provide automatic fail-over.
>
>Kirk
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform