Planning Capacity

Planning for appropriate levels of capacity ensures that all design requirements are met, such as scalability and resource availability, as described in Chapter 2. Capacity planning helps you determine how much your architecture needs to scale, and it helps you select appropriate software and hardware (network, servers, and storage).

In modeling capacity planning, formulate initial capacity planning based upon estimated usage or industry averages, and plan to support scaling for maximum capacity.

We recommend that you perform capacity planning in the following order:

If you have not created a high-level network design of your physical design, we recommend that you read the information in the preceding section “Creating a High-Level Network Design” on page 124.

Estimate Software Capacity

Estimate the software capacity, including the operating environment, before planning capacity for servers and network equipment.

Refer to the following sections:

• “Basic Services” on page 133

• “Infrastructure Services” on page 143

• “Operation and Management Service” on page 149

• “Operating Environment” on page 153

Basic Services

Estimate capacity for basic services such as email, web, news, and FTP. Refer to the following sections:

• “Email Service” on page 133

• “Web Service” on page 136

• “News Service” on page 138

• “FTP Service” on page 142

Email Service

To plan capacity for email, estimate the storage and memory by using the information in TABLE 5-4 and TABLE 5-5.

Storage for email software and other plug-ins (antivirus, antispamming, etc.) is usually negligible in comparison to storage for MailStore and mail queue.

The mail queue is the temporary storage area for outgoing email messages that cannot be sent immediately and need to be queued until the next retry. We recommend that you configure the mail queue on the MailStore and the mail relay. (Mail proxy does not need mail queue.)

The mail proxy usually requires a large amount of memory and sufficient CPU to handle post office protocol (POP) and Internet mail access protocol (IMAP) connections when users retrieve email. The mail relay usually does not require as much memory or CPU as the mail proxy. The message store requires large CPU and memory for email storage and management.

Table 5-4. Estimating Storage for Email Service

Variable	Value	Description
T	Environment dependent	Total number of subscribers
Pact	Environment dependent	Percentage of active email users
Save	Environment dependent	Average email message size
Nrev	Environment dependent	Average email messages received per user per day
Smsa	T × Pact × Save × Nrev	Average storage for active email users
Smsp	Environment dependent	Average storage for email queue
Smsm	Environment dependent	Maximum email storage quota per subscriber
Smsq	Environment dependent	Maximum storage for email queue
Smss	Application dependent	Storage requirement for email software and various plug-ins
Sms(proxy)= Smss Sms(relay)= Smsp + Smss Sms(average·mailstore)= Smsa + Smsp + Smss Sms(maximum·mailstore)= (T × Smsm) + Smsq + Smss

Table 5-5. Estimating Memory for Email Service

Variable	Value	Description
T	Environment dependent	Total number of subscribers
Pcon	Environment dependent	Percentage of concurrency
Pact	Environment dependent	Percentage of active email users
Ppop	Environment dependent	Percentage of POP users
Pima	Environment dependent	Percentage of IMAP users
Mmsi	Application dependent	Memory footprint per IMAP connection
Mmsp	Application dependent	Memory footprint per POP connection
Mmst	Application dependent	Memory footprint per simple mail transfer protocol (SMTP) connection
Mmsb	Application dependent	Memory requirement for email server
Mmp= T × Pcon × Pact × Ppop × Mmsp Mmi= T × Pcon × Pact × Pima × Mmsi Mmt= T × Pcon × Pact × Mmst Mms(proxy)= Mmp + Mmi + Mmsb Mms(relay)= Mmt + Mmsb Mms(mailstore)= Mmp + Mmi + Mmt + Mmsb

Web Service

To plan capacity for web service, estimate the storage and memory by using the information in TABLE 5-6 and TABLE 5-7.

Storage for the web server is minor in comparison to storage required for web content. Additionally, the storage requirement is dependent on software selected, additional modules or plug-ins required, and online documentation. The sizing depends upon the vendor’s recommendation. After selecting software, refer to the vendor’s installation manual for web storage sizing recommendations.

It has been estimated that approximately 25 percent of ISP subscribers have personal web pages. The average web storage size per user is estimated to be 250 Kbytes.

In large-scale ISPs with multiple POPs, cache server can be used to cache data that are frequently accessed, especially in environments where content is static. Web caching can also be done at the web server. Storage for web cache is estimated to be 20 percent of the overall web page storage. While this value varies in different environments, it is sufficient for initial sizing and can be adjusted accordingly.

Table 5-6. Estimating Storage for Web Service

Variable	Value	Description
T	Environment dependent	Total number of subscribers
Pact	Environment dependent	Percentage of active users with web pages
Save	Environment dependent	Average web storage size per user
Swsa	T × Pact × Save	Average storage for active users with web pages
Swsd	Environment dependent	Average storage for web cache
Swsw	Environment dependent	Maximum web storage quota per subscriber
Swsc	Environment dependent	Maximum storage for web cache
Swss	Application dependent	Storage requirement for web software and various plug-ins
Sws(average)= Swsa + Swsd + Swss Sws(maximum)= (T × Swsw) + Swsc + Swss

There are two sizing models for web servers: threads and fork/exec model. The difference between the two models is how memory is initially allocated when a web server is instantiated.

For more information about multi-threaded process architecture and modeling for web servers, refer to the following sources:

• For details on multi-threaded process architecture, see Solaris Internals: Core Kernel Architecture and Threads Primer: A Guide to Multithreaded Programming.

• For the list of common web servers and their associated models, refer to:

  http://www.acme.com/software/thttpd/benchmarks.html

• For detail modeling for web servers, see Capacity Planning for Web Performance: Metrics, Models, & Methods.

Table 5-7. Estimating Memory for Web Service

Variable	Value	Description
T	Environment dependent	Total number of subscribers
Pcon	Environment dependent	Percentage of concurrency
Nweb	Environment dependent	Number of web servers
Npar	1	Number of parent processes
Npro	Environment dependent	Number of child processes (fork/exec model)
Nthr	Environment dependent	Number of threads (thread model)
Ncon	Environment dependent	Peak number of HTTP connections
Mwsc	Application dependent	Memory footprint per HTTP connection
Mwss	Application dependent	Memory footprint per child process (fork/ exec model)
Mwst	Application dependent	Memory footprint per thread (thread model)
Mwm(thread)= (Nweb × Nthr × Mwst) + (Ncon × Mwsc) Mwm(fork)= (Nweb × Npar + Npro) × Mwss) + (Ncon × Mwsc)

News Service

To plan capacity for news service, estimate the storage and memory by using the information in TABLE 5-8 and TABLE 5-9.

Storage for news service is extremely large, and growing exponentially. News service is often outsourced to a UseNet provider, such as UUnet, to reduce an ISP’s up-front and on-going costs.

As of June 2001, it was estimated that 300 Gbytes of storage is required for a full feed for daily news articles. It has been estimated that storage for daily news feed will reach approximately 550 Gbytes by the end of 2001. For more information, refer to:

http://newsfeed.mesh.ad.jp/flow/size.html

Currently, approximately 1.5 million articles are generated per day. Thus, to have enough storage to handle a large number of files, the file system must be designed with a sufficient number of inodes. See FIGURE 5-3 for a sample graph of daily news articles, indicating the steady rise in the number of news articles and showing a current value of 1.5 million articles per day.

FIGURE 5-4 shows the current storage requirements for a full news feed. Estimating based on 300 Gbytes of disk and 1.5 million news articles, the file system must have at least 200,000 inodes per gigabyte of disk space.

In FIGURE 5-5, we show sample trends for storage over the next 12 months, based upon current usage.

News spooler, history, and index is estimated to be 10 percent of news storage. This value varies in different environments and depends upon many factors, such as how newsgroups are moderated, how stale newsgroups are managed, and how many upstream and downstream feeds are made. We recommend that you adjust overhead accordingly.

Table 5-8. Estimating Storage for News Service

Variable	Value	Description
Snsa	Time dependent	Storage requirement for daily news articles for a full feed
Snsh	Environment dependent	Storage requirement for news spooler, history, and index
Snss	Application dependent	Storage requirement for news software
Sns=Snsa+Snsh+Snss

The Internet Software Consortium (ISC) (http://www.isc.org) recommends that systems with less than 256 Mbytes of RAM use a tagged hash table for history database. This approach, although somewhat slower, consumes less memory. How much RAM is required for the news server depends on several factors:

• Is the news feed received from a UseNet provider a full feed or partial feed?

• Are there any downstream feeds?

• How are newsgroups moderated, filtered, maintained, etc?

InterNetNews^SM (INN) administrators recommend 1 Gbyte of memory for the news reader. If the history hash doesn’t fit in memory, article expiration takes longer. The news feeder requires a lot of memory, because of the high number of sockets open to handle the volume of data.

Table 5-9. Estimating Memory for News Service

Variable	Value	Description
T	Environment dependent	Total number of subscribers
Pcon	Environment dependent	Percentage of concurrency
Pact	Environment dependent	Percentage of active news users
Mnss	Application dependent	Memory footprint per news server
Nnfd	Environment dependent	Number of downstream feeds
Mnfd	Application dependent	Memory requirement per downstream feed
Nnco	T × Pcon × Pact	Peak number of news connection
Mnco	Application dependent	Memory footprint per news connection
Mnm=Mnss + (Nnfd × Mnfd) + (Nnco × Mnco)

FTP Service

To plan capacity for FTP (file transfer protocol) service, estimate the storage and memory by using the information in TABLE 5-10 and TABLE 5-11.

How much storage is required for a spooler varies greatly in different environments. An FTP spooler usually doesn’t have to be very large, but it must be cleared regularly, for example, with shell scripts and cron jobs.

Content updates for subscribers’ personal web pages are infrequent, and concurrency for FTP sessions is very low, because only a small percentage of subscribers have web pages and a smaller number of those subscribers update their web pages. Memory required for FTP is minimal. Each FTP process is approximately 400 Kbytes.

Table 5-10. Estimating Storage for FTP Service

Variable	Value	Description
Sfss	Application dependent	Storage requirement for FTP software
Sfsu	Environment dependent	Storage requirement for FTP spool
Sfs=Sfss + Sfsu

Table 5-11. Estimating Memory for FTP Service

Variable	Value	Description
Mftp	Application dependent	Memory footprint per FTP process
Nftp	Environment dependent	Number of concurrent FTP connections
Mfs=Mftp × Nftp

Infrastructure Services

Estimate the capacity needed for infrastructure services such as domain name system (DNS), remote authentication dial-in user service (RADIUS), lightweight directory access protocol (LDAP), dynamic host configuration protocol (DHCP), and network time protocol (NTP). Refer to the following sections:

• “DNS Service” on page 143

• “RADIUS Service” on page 144

• “LDAP Service” on page 145

• “DHCP Service” on page 147

• “NTP Service” on page 148

DNS Service

To plan capacity for DNS service, estimate the storage and memory by using the information in TABLE 5-12 and TABLE 5-13. In general, DNS consumes very little CPU and memory resources.

Table 5-12. Estimating Storage for DNS Service

Variable	Value	Estimation
Sdns	Application dependent	Storage requirement for DNS software
Sdnd	Environment dependent	Storage requirement for DNS zone databases
Sdn= Sdns + Sdnd

Table 5-13. Estimating Memory for DNS Service

Variable	Value	Description
Mdns	Application dependent	Memory requirement per DNS server
Mzon	Environment dependent	Memory requirement for zone database
Mdn= Mdns + Mzon

RADIUS Service

To plan capacity for RADIUS service, estimate the storage and memory by using the information in TABLE 5-14 and TABLE 5-15.

In general, RADIUS usually does not require a large amount of memory. Allowing for variances based on the software and the vendor’s recommendation, use the following guidelines:

• 64 Mbytes of RAM for a small- to mid-sized ISP

• 128 Mbytes for a large ISP

Table 5-14. Estimating Storage for RADIUS Service

Variable	Value	Description
T	Environment dependent	Total number of subscribers
Srse	Application dependent	Average size for a RADIUS database entry
Srsd	T × Srse	Storage requirement for RADIUS database
Srss	Application dependent	Storage requirement for RADIUS software
Srsl	Environment dependent	Storage requirement for RADIUS log
Srs= Srsd + Srss + Srsl

Table 5-15. Estimating Memory for RADIUS Service

Variable	Value	Description
T	Environment dependent	Total number of subscribers
Pcon	Environment dependent	Percentage of concurrency
Nrsc	T × Pcon	Peak number of RADIUS authentication
Mrse	Application dependent	Memory footprint per RADIUS authentication
Mrsa	Nrsc × Srse	Memory requirement for RADIUS authentications
Mrss	Application dependent	Memory requirement for RADIUS server
Mrs= Mrsa + Mrss

LDAP Service

To plan capacity for directory service, estimate the storage and memory by using the information in TABLE 5-16 and TABLE 5-17.

The storage requirement for directory software is usually quite large, because of the complexity of the application and availability of support for various platforms and applications. The size of the directory application is dependent upon the vendor. The LDAP database can be large; however, the size depends on the number of entries in the database, number of fields populated per LDAP entry, and complexity of directory schema.

Table 5-16. Estimating Storage for Directory Service

Variable	Value	Description
T	Environment dependent	Total number of subscribers
Sdse	Environment dependent	Average size for a directory database entry
Sdsd	T × Sdse	Storage requirement for directory database
Sdsi	2 × Sdsd	Storage requirement for directory index
Sdss	Application dependent	Storage requirement for directory software
Sds= Sdsd + Sdss + Sdsi

Index databases can get very large, depending on what attributes are indexed and what type of indexing is used. You can easily have index databases that are equal to or larger than the entry database. In most cases you can figure out how much space the entries take up and double it to allow for indexing, which is what we recommend in the formula in the preceding table. Note that this calculation affects memory requirements too.

A typical configuration for directory servers is putting more memory on LDAP replicas, because these servers are used for LDAP searches and queries. If the LDAP master is dedicated for replication only, you can configure less memory for it.

For more information on LDAP, see Understanding and Deploying LDAP Directory Services.

Table 5-17. Estimating Memory for Directory Service

Variable	Value	Description
T	Environment dependent	Total number of subscribers
Mdss	Application dependent	Memory requirement for directory server
Mds= Mdss

DHCP Service

To plan capacity for DHCP service, estimate the storage and memory by using the information in TABLE 5-18 and TABLE 5-19.

Storage for DHCP is usually very small. Even for a large ISP, the storage requirement is minor compared to other services. An average entry in the DHCP database is approximately 256 bytes.

Table 5-18. Estimating Storage for DHCP Service

Variable	Value	Description
T	Environment dependent	Total number of subscribers
Sdhe	Application dependent	Average size for a DHCP database entry
Sdhd	T × Sdhe	Storage requirement for DHCP database
Sdhs	Application dependent	Storage requirement for DHCP software
Sdh= Sdhd + Sdhs

Memory sizing for DHCP is quite different from other services, because it is allocated up-front for leases. How much memory is required depends upon how many leases are allocated in the lease table. The size of the DHCP database doesn’t dictate the amount of memory required for DHCP. Allocate enough memory for the lease table to serve the number of concurrent users. Anything larger than that provides no additional benefit.

According to the ISC, the average memory consumption per lease is approximately 256 bytes. A small single-CPU system with 32 Mbytes of RAM can efficiently be configured as a DHCP server for small- to mid-sized ISPs.

Table 5-19. Estimating Memory for DHCP Service

Variable	Value	Description
T	Environment dependent	Total number of subscribers
Pcon	Environment dependent	Percentage of concurrency
Ndhc	T × Pcon	Peak number of DHCP leases
Mdhl	Application dependent	Memory footprint per DHCP lease
Mdhd	Ndhc × Mdhl	Memory requirement for DHCP leases
Mdhs	Application dependent	Memory footprint for DHCP server
Mdh= Mdhd + Mdhs

For more information on DHCP, refer to The DHCP Handbook: Understanding, Deploying, and Managing Automated Configuration Services.

NTP Service

To plan capacity for NTP service, estimate the storage and memory by using the information in TABLE 5-20 and TABLE 5-21.

Storage and memory for NTP is very small and negligible. There are no special considerations for NTP service and no extra storage and memory requirements other than for the software.

Table 5-20. Estimating Storage for NTP Service

Variable	Value	Description
Snts	Application dependent	Storage requirement for NTP software
Sns= Snts

Table 5-21. Estimating Memory for NTP Service

Variable	Value	Description
Mnts	Application dependent	Memory requirement for NTP server
Mns= Mnts

Operation and Management Service

Estimate the capacity needed for operation and management services such as backup, firewalls, and logging. Refer to the following sections:

• “Backup Service” on page 149

• “Firewall Service” on page 151

• “Log Service” on page 152

Backup Service

To plan capacity for backup service, estimate the storage and memory by using the information in TABLE 5-22 and TABLE 5-23.

For backup servers such as Sun Solstice Backup™, VERITAS NetBackup Datacenter™, or Legato NetWorker®, the major storage required is for backup index. The index is used to track files that are backed up online.

The browse policy determines how long files are kept on index for online browsing. Each entry in the browse policy takes approximately 220 bytes. The size of the backup index depends on the following factors:

• Volume of data being backed up

• Level of backup

• Frequency of backup

• Browse and retention policies

To conserve disk space, your ISP may need to establish a shorter browse policy. Complementing the browse policy is the retention policy, which tracks save sets stored on each backup volume, thus, consuming less storage for indexing.

Table 5-22. Estimating Storage for Backup Service

Variable	Value	Description
Sbsi	Environment dependent	Storage requirement for backup indexes
Sbss	Application dependent	Storage requirement for backup software
Sbs= Sbsi + Sbss

In general, memory requirements are dictated by the number of backup instances and the number of clients backed up simultaneously. After selecting software, refer to the vendor’s recommendation for memory sizing for backup.

Table 5-23. Estimating Memory for Backup Service

Variable	Value	Description
Mbsd	Application dependent	Memory requirement for backup server
Mbs= Mbsd

Firewall Service

To plan capacity for firewall service, estimate the storage and memory by using the information in TABLE 5-24 and TABLE 5-25.

Table 5-24. Estimating Storage for Host-Based Firewall Service

Variable	Value	Description
Sfws	Application dependent	Storage requirement for firewall software, objects, and policy
Sfwl	Environment dependent	Storage requirement for firewall logs
Sfw = Sfws + Sfwl

How much memory is required for a firewall server depends upon the following:

• Graphical remote administration

• Short or long logging

• Encryption

• Network address translation

• Firewall state table size

After selecting software, refer to the vendor’s recommendation for memory sizing.

Table 5-25. Estimating Memory for Firewall Service

Variable	Value	Description
Mfws	Platform dependent	Memory requirement for firewall
Mfw = Mfws

Log Service

To plan capacity for log service, estimate the storage and memory by using the information in TABLE 5-26 and TABLE 5-27.

The log spooler is the temporary storage area for new logs that have not been archived. Storage for the log spooler is usually small compared to storage for log archives. How much storage is required for archives is dependent on the volume of logs and how long logs are kept.

There are no special considerations for memory for log service. Sufficient memory must be present to support the underlying operating environment, with some overhead.

Table 5-26. Estimating Storage for Log Service

Variable	Value	Description
Slss	Environment dependent	Storage requirement for log spooler
Slsa	Environment dependent	Storage requirement for log archive
Sls= Slss + Slsa

Table 5-27. Estimating Memory for Log Service

Variable	Value	Description
Mlss	Environment dependent	Memory requirement for log server
Mls= Mlss

Operating Environment

Model the capacity planning for the file system layout for system disk, file system layout for data, and system disk storage. Refer to the following sections:

• “Storage Capacity” on page 153

• “Filesystem Layout for System Disk” on page 154

• “Filesystem Layout for Data” on page 155

Storage Capacity

Estimate the storage capacity for the operating system (root file system, swap space, log archive, and applications) by using the information in TABLE 5-28.

A special consideration for sizing the system disk is allocating enough disk space for swap and log archive. The rule of thumb for swap space is twice the amount of physical memory or RAM.

Keep in mind that swap space does not necessarily always equal twice the amount of physical memory, especially for systems that have a very large amount of memory where swap is never needed. In such cases, you can set swap space less than twice the amount of physical memory; for example, you can set it to equal the amount of memory.

Based upon the environment, the amount of log archive storage needed is dependent on how many logs are generated, the type of logging that is performed, and how long logs are kept.

In general, you need much less disk space for applications than for logs.

Table 5-28. Estimating Storage for System Disk

Variable	Value	Description
Soss	Vendor dependent	Storage requirement for operating system
Sswp	Recommend at least twice the amount of RAM	Storage requirement for swap space
Sosl	Environment dependent	Storage requirement for log archive
Sapp	Environment dependent	Storage requirement for native and third-party applications
Sos= Soss + Sswp + Sosl + Sapp

Filesystem Layout for System Disk

Plan the file system layout for the system disk by using the information in TABLE 5-29.

It’s important to plan the file system layout to ensure availability and scalability. If there is not enough room for growth, the system could run out of disk space. For example, if the /var partition were to run out of disk space, the system would freeze because logs could not be saved.

In UNIX, you can partition any disk up to eight partitions. Partition numbering is from 0 to 7.

• Partition 0 is always root partition.

• Partition 1 is usually swap.

• Partition 2 to 7 is operating system dependent.

We recommend spreading multiple swap partitions, if available, across multiple physical disks for performance enhancement.

Be aware that some vendors prefer a different scheme for partitioning and allocating disk space. After selecting an operating environment (refer to Chapter 6), consult the vendor’s documentation for recommendations applicable to the operating environment.

Table 5-29. Filesystem Layout for System Disk

Partition	Filesystem	Description
0	/	Root (the first partition is always the root partition).
1	swap	Swap (the second partition is usually the swap partition)
2-7	Operating system dependent	/usr (binaries and libraries), /var (logs and patches), and /export (home directories)

Filesystem Layout for Data

Plan the file system layout for data by using the information in TABLE 5-30.

For management purposes, it is important to separate data from the system disk. Isolating data from the system disk ensures that if the system disk fails, data are not affected. Additionally, if data become corrupted, we don’t want corrupted data to affect the system disk.

Table 5-30. Filesystem Layout for Data

Variable	Value	Description
/data	Environment dependent	Data (MailStores, web contents, news articles, etc.)

Estimate Server Capacity

After planning software capacity, determine what kind of server is appropriate to support the software design.

A benefit of server capacity planning is that it helps you understand application usage and resource utilization required, which will help you select the applicable hardware in the next chapter.

For an ISP’s infrastructure, enterprise servers are the servers of choice. These servers vary in size, depending on the usage purpose. They are designed for scalability, performance, NEB-compliance, and rack-mounting. To estimate the size of enterprise servers for your ISP customer, use the information in TABLE 5-31.

Table 5-31. Sizing an Enterprise Server

Type	Size	Specification
Front-End Servers (DNS, DHCP, NTP, RADIUS, firewalls, mail relays, mail proxies, news readers, web servers, boot/install, etc.)	Small (horizontal scalability only)	Uniprocessor (1 CPU, ≤ 1 GB RAM)
Mid-Size Servers (application, backup, LDAP replicas, management, etc.)	Medium (horizontal and limited scalability)	Multiprocessor (≤ 4 CPU, ≤ 4 GB RAM)
Back-End Servers (NFS, MailStore, database, LDAP master, billing system, etc.)	Large (horizontal and high scalability)	Multiprocessor (≥ 4 CPU, ≥ 4 GB RAM)

Front-end servers are usually small and lightweight, such as web servers, mail relays, and mail proxies. These are typically uniprocessor with sufficient RAM and are coupled with front-end load balancers for load distribution. Front-end servers scale horizontally; therefore, multiprocessor systems are not required.

Servers for middle tier, such as application, management, and LDAP replica servers, are multiprocessor systems with limited scalability. While application servers can take advantage of a multiprocessor system, they don’t require as much vertical scalability as that of back-end servers.

Back-end servers, such as the MailStore, NFS, database, and LDAP master, are large-scale multiprocessor systems with maximum vertical scalability. How much scalability is required depends on the environment and customer requirements.

Estimate Network Capacity

Estimate network capacity for the infrastructure so that the design provides bandwidth to support traffic load and sufficient modems and high-speed trunks are available for Internet connectivity and dial-up access.

Calculate the average utilization per user, and use that value in estimating bandwidth, modem, and trunk capacity.

Refer to the following sections:

• “Bandwidth” on page 157

• “Modems and High-Speed Trunks” on page 158

• “Network Components” on page 160

Bandwidth

On average, dial-up ISPs estimate that each user consumes approximately 1.7 Kbit/ sec of network bandwidth. For example, if you have 1,250 concurrent users (total 10,000 subscribers with 12.5 percent concurrency), the network must be able to sustain 2.04 Mbit/sec.

Estimate the network bandwidth capacity for users by using the information in TABLE 5-32.

Table 5-32. Estimating Network Bandwidth for Users

Variable	Value	Description
T	Environment dependent	Total number of subscribers
Pcon	Environment dependent	Percentage of concurrent users
Busr	Environment dependent	Average network bandwidth consumption per user
Bthe	Hardware dependent	Theoretical network bandwidth
Bsat	40% × Bthe	Network bandwidth saturation level
Bove	10% × Bthe	Network bandwidth overhead
B= (T × Pcon × Busr) + Bove

Modems and High-Speed Trunks

Determine the total number of modems to support the projected number of concurrent users. Using this number, you can then determine the number of high-speed trunks needed for dial-up and Internet access.

Modems

Based upon the projected number of concurrent users, estimate how many modems are required for dial-up access. Calculate it by using the information in TABLE 5-33.

Percentage of concurrency is often calculated from modem-to-user ratio. This value represents how many users a single modem can support. Traditionally, ISPs used 1:10 as the modem-to-user ratio, that is, 10 percent concurrency, which is one modem for every 10 active subscriber sessions.

Today, most ISPs use a 1:8 modem-to-user ratio, which is 12.5 percent concurrency. However, it is becoming difficult for ISPs to sustain their levels of concurrent users because more users are online and they stay online longer. More and more ISPs are increasing ratios to 1:6 (16.7 percent) to support the same number of subscribers.

If you do not have an estimate for number of concurrent users, base the number on industry usage for ISPs. A minimum ratio of 1:8 is industry usage for most ISPs, which represents a 12.5 percent concurrency.

Table 5-33. Estimating Modems Needed for Dial-up Access

Variable	Value	Description
T	Environment dependent	Total number of subscribers
Pcon	Environment dependent	Percentage of concurrency
NM= T × Pcon

High-Speed Trunks

To estimate trunk capacity, determine links needed for Internet connectivity and dial-up access.

Estimate Links for Internet Connectivity– Estimate the size of bandwidth required for Internet connectivity by using the information in TABLE 5-34.

The simplest approach is to determine the average bandwidth that will be consumed by concurrent users. The number of Internet connections required is dependent on the environment. Multiple links are usually required to ensure availability.

Table 5-34. Estimating Links Needed for Internet Connectivity

Variable	Value	Description
T	Environment dependent	Total number of subscribers
Pcon	Environment dependent	Percentage of concurrent users
Busr	Environment dependent	Average bandwidth consumption per user
L	Hardware dependent	Bandwidth supported per high-speed trunk

Estimate Links for Dial-Up Access– Estimate the size of links for dial-up access by using the information in TABLE 5-35.

Many network access servers support multiple T1 links and one channelized T3 (CT3) link. If your link estimate is a small number of T1 links, it is probably cost effective to use T1 links. However, if your link estimate requires many T1 links, it is more cost effective to use one CT3 link.

CT3 links are best for large-scale environments where a large number of channels are required to support a large number of concurrent users. A single CT3 supports up to 672 channels, where each channel supports 64 Kbit/sec.

Table 5-35. Estimating Links Needed for Dial-up Access

Variable	Value	Description
T	Environment dependent	Total number of subscribers
Pcon	Environment dependent	Percentage of concurrent users
C	Hardware dependent	Number of channels supported per high-speed trunk

Network Components

If you have not already done so, identify the major network components of your network design. Identifying components helps you ensure that the network is scalable and performs at the level desired.

Estimate the port capacity for routers, switches, and consoles. Refer to the following sections:

• “Routers” on page 161

• “Switches” on page 162

• “Console Servers” on page 163

Routers

Capacity planning for routers is different from switches. When planning for routers, consider the following:

• Number of WAN interfaces

• Type of high-speed trunks

• Number of fixed LAN ports

Planning WAN interfaces and associated high-speed trunks ensures that the appropriate bandwidth is achieved for WAN backhaul with corresponding types of high-speed trunks. In addition, planning support for WAN interfaces ensures that redundant Internet connections can be achieved for HA in the event of link failure.

In addition to planning for WAN interfaces, plan for LAN interfaces. When multiple routers and switches are interconnected for availability, planning for LAN interfaces becomes critical.

Estimate the port capacity for routers by using the information in TABLE 5-36.

Table 5-36. Estimating Ports for Routers

Variable	Value	Description
Nwan	Environment dependent	Number of WAN interfaces slots (T1, T3, etc.)
Nlan	Environment dependent	Number of fixed LAN ports (10/100 Mbps)
PR= Nwan + Nlan

Switches

It is important to plan for the number of network ports (10/100 Mbit/sec) needed, plus overhead for immediate and future growth. We recommend adding 20 percent overhead for immediate growth. For future growth, plan for overall scalability of the switches. Estimate the network port for switches by using the information in TABLE 5-37.

All switches have at least one dedicated port for uplink, usually Fast Ethernet (FE) for small switches and Gigabit Ethernet (GE) for large switches. The serial port is usually for failover, but you can use 10/100 Mbps as well. We recommend that the uplink port be large enough to handle upstream and downstream traffic.

Perform your capacity planning for switches by network layer. Depending on the role of each network layer, your total number of network ports vary. For example, switches at the services network might require a larger number of network ports than switches at the content network, because the services network has many small servers compared to the content network, which has a few large servers.

Table 5-37. Estimating Network Ports for Switches

Variable	Value	Description
Nser	Environment dependent	Number of servers connected to the switch (mail relays, mail proxies, web servers, application servers, DNS servers, etc.)
Napl	Environment dependent	Number of network appliances connect to the switch (firewalls, load balancers, cache engines, IDS sensors, console servers, access servers, etc.)
Nadm	Environment dependent	Number of network ports required for administrative purposes (trunking, heartbeats, failover, etc.)
Nove	Environment dependent	Number of network ports required for immediate growth.
PS= Nser + Napl + Nadm + Nove

Console Servers

Capacity planning for console ports is simple and straightforward. Start by using the same number as the total number of devices to be managed by the console server. Then, add an appropriate amount of overhead for immediate growth. Estimate the port capacity for console servers by using the information in TABLE 5-38.

Table 5-38. Console Port Estimation for Console Servers

Variable	Value	Description
Nser	Environment dependent	Number of servers connected to the console server (mail relays, mail proxies, web servers, application servers, DNS servers, etc.)
Napl	Environment dependent	Number of network appliances connected to the console server (firewalls, load balancers, cache engines, IDS sensors, access servers, routers, switches, etc.)
Nove	Environment dependent	Number of console ports required for immediate growth
PS= Nser + Napl + Nove