Mission-Critical Microsoft Exchange 2000: Building Highly-Available Messaging and Knowledge Management Systems
Mission-Critical Microsoft Exchange 2000 is the definitive book on how to design and maintain extremely reliable and adaptive Exchange Server messaging systems that rarely crash and that preserve valuable data and services in spite of technical disruptions. E-mail systems are now a primary means of communication for organizations, which can afford e-mail down-time no more than they can afford to be without phones. Further, messaging systems increasingly are supporting vital applications in...
Search in google:
Mission-Critical Microsoft Exchange 2000 is the definitive book on how to design and maintain extremely reliable and adaptive Exchange Server messaging systems that rarely crash and that preserve valuable data and services in spite of technical disruptions. E-mail systems are now a primary means of communication for organizations, which can afford e-mail down-time no more than they can afford to be without phones. Further, messaging systems increasingly are supporting vital applications in addition to e-mail, such as workflow and knowledge management, making the data they store both voluminous and incredibly valuable.Mission-Critical Microsoft Exchange 2000 teaches system designers, administrators and developers the strategies, tools, and best practices they'll need to plan and implement highly-available systems on Exchange 2000 and on earlier versions of Exchange. The book explains Exchange back-up and disaster recovery techniques, Windows clustering technologies for Exchange systems, and security planning to resist messaging-based attacks. Written by Jerry Cochran, an authority on large-scale Exchange systems, Mission-Critical Microsoft Exchange 2000 helps readers create Exchange systems upon which they can build large and growing organizations.Unique book on a crucial Exchange topic Part of Digital Press's Exchange Server Cluster Author is Compaq's expert on high-end Exchange systems
Chapter 1: Mission-Critical Exchange\ 1.1 Mission-Critical Defined and Understood\ mission-criticax A term applied to various systems on which the success of an organization or project depends. The loss of a mission-critical system results in unacceptable operational, functional, or financial harm to the organization or project.\ 1.1.1 And Size Doesn't Matter\ It should be noted upfront that the term mission-critical need not apply specifically or solely to large systems or even large Exchange deployments. Certainly, larger deployments in larger organizations may have millions of dollars of revenue per day riding nn the availability of their messaging and knowledge management systems. However, in the eyes of a small/medium business owner or IT manager, a small deployment of 50 users may be equally important to his existence. Moreover, since a large portion of the total deployed Exchange servers in the market reside W small/medium businesses, we must not limit our discussions or focus to include only large deployments. Mission-critical refers not to the size of our messaging system but to the importance of our data and the medium itself. Therefore, even small and mid-sized companies can have a need for and deploy mission-critical Exchange servers. It is not the size that matters-both large and small Exchange deployments need the tools, concepts, and methods I will discuss throughout this book. Planning and implementing mission-critical systems is like buying insurance for your home or car. We accept the fact that, at some point along the road, something may happen, and we will have to file a claim. It doesn't pay to have an "It won't happen tome" attitude. We select our insurance vendor in terms of price and service but also in terms of our confidence that we will be without our home or vehicle for a minimal amount of time. As part of this insurance-selection process, we also look for a policy that will protect us from liability. Maybe if downtime were treated more seriously and made more of a business requirement, we would do a better job of setting servicelevel requirements and putting plans in place to meet them. Unfortunately, not all organizations treat disaster recovery and high availability planning as a business requirement.\ Many see downtime and outages for their Exchange servers as something that will most likely happen to the other guy. The other problem is that, in order to "do it right" for any environment, you must have qualified staff and lots of money. On a yearly basis, Comdisco does a survey, called the Comdisco Vulnerability Index, of the largest IS shops in the world. According to this survey in 1997, only 12 % had an effective disaster recovery and system availability program in place for their most key business-critical enterprise applications. In another study by the Gartner Group, only about 20% of companies running web-based e-commerce sites have proactive reliability plans in place. In 1998, a similar study by IBM Recovery Services showed that number to be only about 8% or less. This illustrates to me how businesses have generally neglected the whole process of ensuring mission-critical environments. This may be simply because many organizations are so resource constrained because it is a very resource-intensive and time-consuming process.\ As we endeavor down the path of building mission-critical Exchange Server deployments, we must inevitably begin by defining exactly what is meant by mission-critical. We must also address sometimes-overused terms such as availability and reliability in that same vein. Disaster recovery planning and implementation within the context of messaging systems must be addressed in terms of the key topics and goals important to administrators, planners, and implementers of Microsoft Exchange Server environments. Since any enterprise-wide distributed application, including Exchange Server, can be perceived as mission-critical, we need to establish what the reasons, objectives, and steps are for disaster recovery planning exercises. In this chapter, I will look at what is meant by mission-critical and its various facets applied to an Exchange server deployment. Next we will discuss how to evaluate the risks in your Exchange server environment. This risk-assessment process for your Exchange server environment will serve as a valuable precursor in determining your availability requirements for your Exchange Server deployment. Finally, we will look at defining service-level agreements (SLAB) for availability in an Exchange environment.\ 1.1.2 How Did "Mission-Critical" Become So Important to Exchange?\ In the days (in the not-so-distant past) of Exchange Server version 4.0 as well as version 5.0, the information store was limited to 16GB. Thus, the maximum amount of mail storage (the private information store) that a single server could hold was 16GB.The public information store was also subject to this limit. This hard limitation in software was imposed by Microsoft's desire to get an already-delayed product (version 4.0) shipped, and it provided Exchange Server's first recognized scalability limitation. This limitation was soon encountered by many implementers eager to deploy thousands of users per server who quickly realized that the 16GB limit also effectively limited the number of users one could deploy on an Exchange server. If an administrator desired to give each Exchange user 30MB of mail storage, a simple calculation revealed that only around 500 users could be supported on any one Exchange Server. What was alarming about this was that both the hardware and software could support much higher user loads from a pure performance point of view. The end result was that scalability was limited by an administrative parameter-maximum mailbox size.\ The 16GB limit also made disaster recovery operations fairly simple since 16GB per server was the maximum that would need to be backed up or restored.This information store limitation in Exchange Server 4.0 and 5.0 presented would-be implementers with few challenges as far as disaster recovery was concerned. Sixteen gigabytes could easily be backed up and restored within reasonable timeframes and well within the capabilities of the existing hardware and software technologies available at the time. For example, software products like Computer Associates' (then Cheyenne) ArcServe or Seagate's (now Veritas) Backup Exec products provided backup agents for Exchange Server. With hardware vendors shipping standard DLT drives that could easily backup 5GB to lOGB per hour or more, there seemed to be no real issues with Exchange server disaster recovery. The focus seemed to be still on performance and scalability and how Exchange Server could scale not only on a perserver basis but organizationally as well...
Mission Critical Exchange; Analyzing Downtime Outages; Exchange Database Technology Foundations; Exchange Disaster Recovery Technology; Exchange 2000 Disaster Recovery Best Practices; Leveraging Storage Technology; Leveraging Cluster Technologies for Exchange; Don't Overlook Security as a Powerful High-Availability Measure; Bringing it all Together with Proactive Management Appendices: Supplemental Information and Documentation; Exchange Backup/Restore API (ESEBCL12.DLL)Reference
