Sizing Guide Exchange Server 2003 - Fujitsu

More documents

Recommendations

Info

White Paper Sizing Guide Exchange Server 2003 Version: 4.2, July 2006 Let us now summarize this chapter in a few clear-cut sentences: • An exact performance statement can only be realized by performing a customer-specific load simulation with a customer-specific user profile. • Through idealized load simulations it is possible to derive series of rules for server sizing, which are then used as an aid to good planning. These rules should not be mistaken for a formula. It is still necessary to interpret the rules, meaning that the basis on which the rules are founded must reflect the reality. In order for this to be translated into a real project, it will be necessary to determine the requirements of the real users and to place these in relation to the standardized medium user used in this paper. • Benchmark measurements should not be confused or equated with performance measurements. Benchmarks are optimized for maximum performance. With performance measurements, such as the ones on which this paper is based, the systems analyzed are configured for real operation. The rules shown below are based on measurements performed in the PRIMERGY Performance Lab with the load simulation LoadSim 2003 and the medium user profile. © Fujitsu Technology Solutions, 2009 Page 12 (69)
White Paper Sizing Guide Exchange Server 2003 Version: 4.2, July 2006 Exchange-relevant resources After having explained how to measure an Exchange server in the previous chapter, we now wish to analyze the performance-critical components of an Exchange server, before we then discuss the individual PRIMERGY models with regard to their suitability and performance as an Exchange server in the following chapter. Exchange architecture At this juncture, we are will indicate several important points which should be taken into consideration when designing an Exchange environment. This chapter is especially intended for the reader who is not conversant with the architecture of Exchange environments. Decentrally distributed Exchange server is designed for a decentralized net containing many servers. In other words, a company, for example, with 200,000 employees would not install one Exchange server for all of its employees, but would install 40, 50 or even 100 Exchange servers which reflect the organizational and geographical structure of the company. Exchange can by all means still be centrally and efficiently administered. The complete undertaking should be structured in such a way that the users can access the Exchange server allocated to them, as well as access all servers within a geographical location through a LAN-type connection. WAN connections suffice between the individual locations. This decentralized concept has to all intents and purposes several practical advantages: • The computing performance is available at the location where the user needs it. • If a system fails, not all the users are affected. • Data can be replicated, i.e. they are available on several servers. • Connections to Exchange servers in other locations of the company and to worldwide mail systems can be redundant in design. If a server or a connection fails, Exchange automatically looks for another route, otherwise the most favorably priced one is used. • The backup data size for the classic backup (compare chapter Backup) is spread over several servers, the backup can run in parallel. • User groups with very different requirements (mail volume, data sensitivity, etc.) can be separated from each other. But there are also disadvantages: • Administration personnel is required at every geographical location for backup and hardware maintenance. • Depending on the degree of geographical spread, more hardware - particularly for backup - is necessary. • If a great many small servers are used in contrast to a few large server systems, higher costs are incurred for software licenses. Consolidation In particular these decentralization disadvantages that affect the Total Cost of Ownership (TCO) result - in times of sinking company sales and increasingly difficult market conditions - in the request for consolidation in Exchange environments. Exchange Server 2003 will do justice to this trend toward consolidation. In addition to the classic platform consolidation (use of fewer, but larger servers), consolidation of locations is also made possible. Sinking costs for WAN lines and intelligent client-side caching, as provided by Outlook 2003, are prerequisite for this consolidation approach. Where geographically distributed servers were still required with Exchange 5.5 or Exchange 2000 Server, it is now possible in many scenarios to reduce the locations with Exchange Server 2003. In turn, several larger Exchange servers at one location provide the opportunity of combining the servers to form a cluster. Thus, in the event of hardware failure other server hardware can help out. In a very much decentralized scenario the hardware expenditure required for this would not be justified. © Fujitsu Technology Solutions, 2009 Page 13 (69)
Page 1 and 2: Sizing Guide Exchange Server 2003 A
Page 3 and 4: White Paper Sizing Guide Exchange S
Page 11: White Paper Sizing Guide Exchange S
Page 63 and 64:
White Paper Sizing Guide Exchange S
Page 65 and 66:
Page 67 and 68:
Page 69:
show all

Sizing Guide Exchange Server 2003 - Fujitsu

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?