This chapter is from the book
This chapter is from the book
This chapter is from the book
Choose the Right Equipment
In general, it's good to use switches with redundant power and redundant supervisor modules such as the Catalyst 4507R and Catalyst 6500 series. Making your access layer switches as redundant as possible results in greater network availability should something fail.
Choose a Server Hardware Vendor
First, use the Cisco IP Telephony SRND to determine the desired number of each type of server in the cluster, the redundancy strategy the cluster uses, and the physical server placement. (For the SRND, go to http://www.cisco.com/warp/public/779/largeent/it/ese/srnd.html, or search Cisco.com for "IP Telephony Solutions Reference Network Design.") Then you must decide whether to use the Cisco-branded Media Convergence Servers (MCS) or the private-label servers from Compaq and IBM. In addition to the design guidelines provided in the SRND, you must consider other important ramifications when choosing a server hardware vendor.
In general, it's difficult to make a blanket recommendation, because there are so many variables to consider. Surely the easiest and most hassle-free option is to choose all Cisco MCS. These servers are specially built, thoroughly tested, and easily ordered, and they provide a single-vendor solution. However, the decision is not always so simple.
You must consider other factors when deciding whether to purchase Cisco MCS or Cisco-certified hardware from Compaq or IBM:
Relationship with the server vendors—Perhaps you have a great relationship with your Cisco account team and support structure, and you prefer all Cisco hardware to get a single point of support for the CallManager software, hardware, and network infrastructure. On the other hand, maybe you have a large server farm that is all IBM, and you prefer to keep your environment all-IBM hardware.
Pricing and discounts—You might have an aggressive pricing structure with a particular server vendor that you want to leverage when purchasing servers for your CallManager implementation.
Service and support—Purchasing non-Cisco branded hardware causes your solution to be implemented using equipment from multiple vendors, potentially adding a layer of complexity when you're trying to determine whether a problem's cause is hardware or software. If the problem is the hardware, you must contact a different support organization to troubleshoot or replace the non-Cisco branded hardware.
Hardware availability—Both Compaq and IBM frequently release new hardware. Cisco does not certify every platform available from every vendor, so only certain models are tested and approved for use with CallManager. It's quite possible that Cisco will not support new hardware at the time of its release, and older models might not be available except through Cisco. Any hardware used must be approved by Cisco. For a list of supported platforms, check the Cisco 7800 Series Media Convergence Servers brochure at http://www.cisco.com/go/swonly.
Server Memory Requirements
You should also consider another server specification: the amount of memory required by the various applications. You should have at least 1 GB of RAM in your server, but additional memory is advisable. The general rule is that you can never have too much memory. However, no matter how much memory is present in a server running Windows 2000 Server, no more than 2 GB of memory can be allocated to a particular process. For example, the CallManager service controls call processing on all CallManager servers. If you have a server with 3 GB of memory, CallManager can use all the memory it can get and leave the rest for other processes. Cisco MCS 7845 servers use Windows 2000 Advanced Server, which can address 3 GB of RAM per process, the amount of RAM that is recommended for large clusters with tens of thousands of phones.
If you want a server with less than 2 GB of RAM, you must consider the number of device weights and dial plan weights supported by the server when determining the minimum amount of RAM required for each CallManager server. For the latest information on device weights and their effect on memory requirements, refer to the SRNDs on Cisco.com (see the earlier section "Read the Solution Reference Network Designs").
Adding Hard Drives to a Server
The CallManager redundant array of independent disks (RAID) configuration uses two mirrored disks. Each drive is partitioned into a C:\ partition containing the operating system and program files and a D:\ or E:\ partition containing some operating system installation files.
Adding a disk to the system might be a good idea for these reasons:
Storing log files—When troubleshooting CallManager, the trace facility can produce numerous log files. Rather than limit the number of log files you can keep, using an extra disk to store log files might be the best way of keeping the install drive from running out of space.
In addition, you can send the extra drive to the Cisco Technical Assistance Center (TAC) when the log files contain so much data that they cannot easily be sent over the Internet. A good example of this is SDL trace files.
Storing downloads and patches—The size of the various CallManager upgrade files and operating system (OS) patches has been growing since CallManager was released. Often, administrators download the images from the Voice Software Center on Cisco.com (http://www.cisco.com/kobayashi/sw-center/sw-voice.shtml) and place them on the CallManager server's C:\ drive. The result is excessive clutter and the potential to overload the drive, which usually causes CallManager failures. Instead, as a best practice, use a spare drive or a network share to store these files.
Choosing Phone Types
Company policy often dictates the right phone for the various user classes. In the absence of established policy, common Cisco IP Phone-to-user pairs are shown in Table 1-4.
The choice of the standard employee phone often depends on company culture. Some organizations believe that everyone should have headset capability, speakerphones, and speed dials. Other organizations have policies that oppose the use of speakerphones in cubicles and other unenclosed areas.
Table 1-4 User Type and Phone Model Pairings
|
User Type |
Cisco IP Phone Model |
|
Call center employee |
Cisco 7940G (XML is required for phone agent) |
|
Standard employee |
Cisco 7912G, 7940G, 7960G, Cisco IP Communicator |
|
Executive assistant |
Cisco 7960G with Cisco IP Phone 7914 Expansion Module(s) |
|
Executive |
Cisco 7970G Cisco 7960G Cisco 7936G |
|
Attendant operator |
Cisco 7960G with Cisco IP Phone 7914 Expansion Module(s) |
|
User Type |
Cisco IP Phone Model |
|
Conference rooms |
Cisco 7936G |
|
Warehouse employee |
Cisco 7920 |
|
Telecommuter |
Cisco 7902G, 7905G, Cisco IP Communicator |
|
Common/public area phones |
Cisco 7902G |
NOTE
One option that is often discussed but almost never implemented is an "all-SoftPhone" solution, in which Cisco IP SoftPhone or Cisco IP Communicator is deployed with no physical phones placed at users' desks. Although this is an economically appealing option, the idea often gets declined. Many companies want the phone to be separate or don't consider users' PCs to be "always-on" devices, which makes management and tracking a bit more difficult with software-based phones.
As discussed earlier, using an inventory of the existing system (in the case of a PBX migration) is the best way to achieve parity. Many customers make a matrix of the existing phones in use and then map Cisco devices to those of the existing vendor. This works extremely well and is recommended because it keeps the amount of change for users to a minimum.