Understanding Organizational Reporting Requirements
| Designing reports is one of the initial steps in designing a BusinessObjects Enterprise system, and easily is the most obvious consideration. An equally important consideration, and one that is most often left until much later in the implementation process, is how and when the reports will be run. Answering some of the questions asked earlier in the chapter will pay off when reports are actually published to BusinessObjects Enterprise. Additional related questions include the following:
Such questions are examples of key planning considerations that must be considered in conjunction with a report's design. Primarily, this needs to be analyzed from a business perspective. For example, perhaps end users need to run reports with impunity because the data is constantly changing and they always need an up-to-date view of the data. However, this perspective then must be tempered by a technological "sanity check" to determine whether such requirements are technologically feasible. For example, does it really make sense to run a 3,000-page report dynamically? Can parameters be added to the report so that less data is brought back to reduce the resultset of the database query? The benefits of different reporting approaches will be explored through the next few sections of the chapter. Deploying Business Views or UniversesAlthough the use of Business Views or Universes might at first seem a technical decision which most affects development time, business requirements drive the utilization of Business Views or Universes more than any other requirement. First, you must understand end-user requirements with regard to how end users view data: If data is organized to the end user in one way, but captured in the database in another, Business Views or Universes bridge the gap and show end users data as they see it. For instance, you might want to see revenue per headcount, which requires the headcount value from an HR system and the revenue total from a finance application. A Business View or Universe can connect to both databases and present a unified logical view of revenue per headcount. The two most significant impacts of business views, however, have everything to do with end users:
Through the development of browser-based report modification and creation capabilities, BusinessObjects Enterprise now offers end users greater possibilities in interacting with data. By encapsulating the database connection and query aspects of the reporting process, end users can now be shielded from the more technical aspects of report creation and instead focus on what to show and how to show it. The development of Business Views and Universes allows organizations to extend this model to develop a more efficient business intelligence model. Most organizations use developers to build the vast majority of reports, referred to as the developer-centric model. End users can now develop more reports themselves instead of a developer-centric model of report development, usually resulting in trivial work for developers, long wait time for end users, poor communication of end-user requirements, and a high opportunity cost. In the end-user centric model, developers and DBAs handle database connectivity, database and table joins, filtering and security, parameterization, formulas, and the like. Report creators then start designing by placing fields on the report and formatting the data. This separation of tasks into distinct roles of DBA versus end user facilitates more efficient report creation and a lower total cost of ownership. It places those who know the business uses of the data closer to report creation, yet allows for tight organizational control over data sources. Using BusinessObjects Enterprise to control access to data via Business Views or Universes tightens and secures access to databases, even for report creation, by asking users to connect to BusinessObjects Enterprise, which provides access to Business Views or Universes according to a particular user's permissions. Because Business Views or Universes can secure the row- and column-level access to data sources, very fine control over data access can be attained. Although this model might not be practical for all organizations, it yields cost savings and speeds time-to-market when implemented. In addition, because total security can be attained while still allowing appropriate access to data, confidentiality requirements can be met across organizations. Use Cases for Scheduled ReportingAs alluded to previously, BusinessObjects Enterprise allows two modes of report execution: on-demand and scheduled. In the scheduled reporting case, a report template is scheduled to run either right now or at a future point in time or possibly on a recurring basis. When it is time for the report to run, the Crystal Report Job Server accesses the report template, the report is processed against the reporting database, and then the report is saved with data under a different file. This report with saved data is commonly referred to as a report instance. This instance is a snapshot of the data in a moment of time. End users can then view an instance to see the report's data from when it was run. The advantages of scheduling reports and creating instances are numerous. The most important advantage of report instances is that when a user views an instance, the report loads almost instantaneously in the report viewer because the report does not need to execute the database query. In addition, because instances are a snapshot of data in time, you can leverage them as historical reports. For example, when reporting against a transactional information system, the database often contains volatile data. Consequently, running the report with the exact same parameters on different days might return different data because the database contains fewer records because of deletion and so on. Determining Scheduling Permissions and Report RuntimesIf scheduled reports are the preferred method of reporting in BusinessObjects Enterprise, you must determine who will be allowed to schedule reports and when those reports can actually be scheduled. In a tightly controlled environment, a system administrator individually schedules reports either singly or on a recurring basis (for example, weekly, monthly). End users are not allowed to run reports; they can only view instances. Thus, by having a central scheduling authority, you can govern what and when database queries will be executed from your reporting application. Additionally in this scenario, if scheduling is completed with regards to end-user viewing use, hardware use can be minimized. For example, if end users view reports only during the day, reports could be batch scheduled to run only at night or on the weekend. This means that report execution and report viewing are mutually exclusive, which they are. Report execution is processor-intensive and primarily the responsibility of the BusinessObjects Enterprise Job Server component. Report viewing can be processor-intensive and a major responsibility of the BusinessObjects Enterprise Page Server component. In this scenario, common hardware can be shared between the Job and Page Servers because their functions will be used mutually exclusively. Otherwise, if report execution and report viewing occur at the same time, and the Job and Page Servers are on the same shared hardware, they might contend with one another for CPU or operating system resources. Because the Page Server plays a key part in report viewing, report viewing responsiveness might be negatively affected during this period. Although administrator-controlled scheduling makes for a tightly regulated system, it can be constrained by its potential inflexibility. For example, if the report has parameters, these parameters must be determined by the administrator. Thus, report instances might contain too much data or too little data for end users. In addition, if the database is updated and a user wants to see the latest data, he will have to wait until the next scheduled runtime because he cannot run the report manually. As a result, timely access to data can be an issue. If these issues of data scope and timeliness can be acceptable or managed, controlled scheduling is an excellent solution for organizations with tight server access or hardware restrictions. For example, some data warehouses are updated at fixed intervals (weekly, for example), so the administrator can schedule the reports to run after the update process is complete. Thus, in this case, if data scope is also not an issue, it doesn't make much sense to allow end users to run reports because the data is unchanged between database update periods. Note Data scope is the specific range or breadth of the data. For example, some reports are useful only if the user provides parameters. If you're checking frequent flyer points you're only interested in data related to you. Thus, a prescheduled report with all data for all customers in this case would not be relevant to you because you're only concerned with your personal data. On the other end of the spectrum is the scenario where end users are allowed to schedule reports on their own, whenever they want. This allows for maximum flexibility for the end users because they can run reports at their leisure with the parameters they choose. However, if the parameters are unchecked, poor parameter selection (because of user inexperience) can cause rogue database queries that tie up the DBMS if they become unnecessarily large or complex. This can lead to the scheduling queue backing up as other jobs waiting to execute are idling for a free spot on the Job Servers. If the Job Servers are configured to run too many concurrent jobs, this can overrun the DBMS with too many simultaneous queries. Thus, the Job Servers should be scaled back so that the number of concurrent jobs allowed is small enough that DBMS access is appropriately managed. If the Page Server and Job Server are on the same shared hardware, the issue might arise where these processes contend for server resources (CPU time, memory, file system, network bandwidth, and so on). On-Demand ReportingThe second mode with which reports can be executed is called on-demand reporting. When used correctly and in the right situation this can be a very powerful function in a BusinessObjects Enterprise deployment. To determine which situations should use on-demand reporting, apply the eight-second rule as a guideline: "Users have eight seconds worth of patience while waiting for a Web page to load." To use this measurement, run the report on a test system or in the Crystal Reports designer and determine how long the report takes to execute. If it takes fewer than eight seconds, that report may be a good candidate for on-demand reporting in BusinessObjects Enterprise. Another consideration with on-demand reporting is whether the database driver and database client are thread safe (meaning that multiple threads can access the driver at the same time without unwanted interaction). If these components are not thread safe, database queries from the Page Servers will be serialized. Using the ODBC database drivers that ship with BusinessObjects Enterprise will ensure this concurrency because they are thread safe and thoroughly tested. Comparing Scheduled Versus On-demand ReportingEven if reports are ideal candidates for on-demand reporting, scheduling reports still might offer additional benefits. For example, scheduled reporting helps set the right expectations and context for a report. When end users schedule a report, even if it is scheduled to run right now, they will expect the report to take some time to process. Thus, they can better tolerate delays. Users who are utilizing on-demand reporting typically don't understand that doing so actually requires the database query to execute. They expect the report to come up in the viewer instantly and are less tolerant of delays and might become frustrated when the only feedback they get is the spinning Web browser logo. Determining Data Access Control MethodsIf the BusinessObjects Enterprise reporting system is designed so that users can schedule reports or run reports on demand, you must decide how to control access to the database. That is, what database user account is used to access the reporting database? With some implementations, individual users are given distinct database accounts that they would provide before running the report. In other implementations, a generic data reader account is used as the default database login for all reports. Having individual users with separate database accounts allows for better auditing if auditing is done at the DBMS level. You can easily track who is running what type of queries against your database. However, this comes with some costs. First, more database administration is required because these user accounts must be managed. Second, users will potentially have to remember an additional set of usernames and passwords. Additionally, by providing individual users with database credentials, they do not necessarily need to use BusinessObjects Enterprise to access the database. They could freely use any database access tool to communicate directly with the DBMS. By using a generic database reader account, the shortcomings of individual accounts are eliminated. Database administration is simpler because only one account must be managed. The password for this account is abstracted from the end user, so she won't be able to use any other database tool to access the DBMS directly. However, this data access model might not be able to leverage databases that have data-level security invoked for users. For example, some databases have data-level security in that different users see different data from the same query based on who they are. This security often is based on which credentials were used to access the database. If an organization were using a generic database account for BusinessObjects Enterprise, such a security model would not integrate well. As part of designing the BusinessObjects Enterprise system, this determination of data access authentication should be agreed upon by all project stakeholders. Note The deciding factor for using a generic database user account or individual user accounts typically is the data access level to be enforced. Using Business Views can alleviate much of this complexity because Business Views can secure the data at the column and row level, and even apply at report development time. The use of Business Views can also alter the development process because the BusinessObjects Enterprise logon becomes the paramount logon, giving access to the databases, via Business Views, as well as the BusinessObjects Enterprise objects, even during the design process. Planning a BusinessObjects Enterprise ArchitectureBusinessObjects Enterprise is a system that can scale up on a single server by adding processors, memory and storage. In addition, adding servers can scale BusinessObjects Enterprise out. Scaling BusinessObjects Enterprise provides benefits such as greater performance, high availability, fault tolerance, and redundancy. However, determining how to scale a system can be a bit of a challenge. A few best practices and guidelines can be followed to guide you. Ultimately, scaling will be determined by usage profile and behavior of the BusinessObjects Enterprise system. One key point is for system administrators to not be fearful of experimenting and trying different configurations to achieve better performance. Different architectures each have benefits and considerations. The idea is to choose those that have the best fit for the given requirements. Determining Processing RequirementsThe four key BusinessObjects Enterprise server components that require some considerable thought in sizing are the Cache Server, Page Servers, Report Application Server, and Job Server. Additionally, because most BusinessObjects Enterprise actions query the CMS, optimizing the CMS database can greatly speed overall system response. Tip Crystal Enterprise 10, and subsequently BusinessObjects Enterprise XI, relies more heavily on the database for key data retrieval functions than in previous versions of the Enterprise product. Paying attention to tuning the system database and DBMS will result in faster system response. This section focuses on how many instances of the services, processors, and physical servers are required and what the settings for these system services should be. The first step in sizing a BusinessObjects Enterprise environment is to answer a few important questions:
One key metric also needs to be determined: What is the number of concurrent users of BusinessObjects Enterprise? Even if you have an overall Web application into which BusinessObjects Enterprise will integrate, it is important to remain concerned only with the number of concurrent BusinessObjects Enterprise users when sizing BusinessObjects Enterprise. A concurrent user of BusinessObjects Enterprise can be described as someone who is interacting with BusinessObjects Enterprise. This includes logging into BusinessObjects Enterprise, processing CSP or other pages that utilize the SDK, scheduling reports, querying the system, or viewing reports. If the number of concurrent users is unknown but the size of your total user base is known, a general guide to estimate what the number of concurrent users might be is about 10% to 20% of the total application user base. For example, if your application has 1,000 total users, you can estimate the number of concurrent users for BusinessObjects Enterprise to be between 100 and 200. Often you can use Web logs of previous applications to determine utilization as well. When reports are processed on-demand or report instances are viewed, a complex chain of processes takes place involving the Web browser, Web server, Application Server, Web Component Adapter, Cache Server, and Page Server or Report Application Server. When sizing the system for on-demand reporting and viewing, the last two components in the process are the most critical for consideration. Sizing the Cache ServerThe Cache Server is responsible for storing and forwarding epf cache pages created by the Page Servers. The Page Servers are primarily responsible for generating epf cache pages either from reports that are opened from report instances or opened and processed from report templates. Consider one individual viewing request or on-demand reporting request to be equivalent to one thread being used by the Cache Server and one thread being used by the Page Server. This is an oversimplification of the viewing process but is a good starting point when making considerations and conservative considerations for sizing. Thus, if 200 concurrent users will be running on-demand reports or viewing report instances, then ideally 200 Cache Server threads and 200 Page Server threads should be available. Typically, 100 cache server threads per processor are recommended with up to a maximum of 400 threads per physical cache server service. Thus, on a quad processor server, a single cache server service could be set to 400 threads whereas with an eight-way server two cache server services would need to be installed, each set to 400 threads for a total thread count of 800 threads. It is important to note that BusinessObjects Enterprise allows a physical server to host multiple copies of the same logical server service for the same or different BusinessObjects Enterprise system environments. This further increases the scalability of BusinessObjects Enterprise. In the preceding example with the eight-way server, two cache server services were configured. Sizing the Page ServerWhether viewing reports or running reports on-demand, Page Servers can optimally manage up to 75 threads per processor. In previous versions such as Crystal Enterprise 10 and earlier, it was common practice to run a Page Server for each processorthis is no longer done. With the new re-architecting of the Page Server, it is only necessary to install one Page Server service and it will detect the number of physical processors and self-tune. If the Page Server is sharing the processors with other processes, it will be necessary to reduce the maximum 'Simultaneous Report Jobs'. Also, keep the total number of cache server threads exactly equal to the total number of Page Server threads in the entire system for optimal performance. Consider the following example. A particular environment has a requirement for 300 concurrent users all running on-demand reports with some redundancy also built into the architecture. Because this is more than a single cache server can optimally handle, two cache server services will be needed. A good choice would be to have two cache server services set to 150 threads each. Because this requires two processors per service, at least a server with four processors will be needed. However, because a level of fault tolerance was required, the cache server services will be split over two dual processor servers. Therefore, the final architecture for the cache servers would have two dual processor servers each with a cache server service set to 150 threads each. For the Page Servers, 300 concurrent users will consume 300 threads with a split over 2 servers for high availability (150 threads per processor) so 2 dual processor servers will be required. Therefore, the final architecture for the Page Servers would be two dual processor servers with one Page Server service each set to 150 threads per service. Sizing the Report Application ServerThe Report Application Server (RAS), much like the Page server, handles 75 threads. However, some important additional configurations affect RAS performance due to its high level of interaction with the reporting database. You can set these values by going to the Central Management Console and locating the Servers section, in the Report Application Server area, within the Database tab. Setting the Maximum Number of Records to read prevents end users from inadvertently creating runaway queries. Specifying a Batch Size determines the number of records to be retrieved from the database at a time; for instance a batch size of 100 means that to retrieve 1,000 records 10 batches will need to be run. Setting this value very high will allow large amounts of data to be processed quickly, but might slow retrieval of smaller data sets. Because report creation and modification can often call for browsing data, for instance when choosing a data value to filter results, you set the browse data size to determine the number of sample values brought back from the database. Although setting a smaller number can speed retrieval, this will also constrain the possible values returned, which might affect some end-user scenarios. Because the RAS caches report data itself instead of using the Cache Server, setting the Data Refresh value determines the oldest data that should be returned to an end user. Setting a value of 20 minutes means that no query will return data more than 20 minutes old. Higher values speed performance but might show old data, whereas low values show very recent data, but at the cost of report performance. Setting the Report Job Database Connection determines when to close the connection to the database. Keeping the connection open, by selecting the When the Job is Closed option, saves the time required to reconnect to the database for subsequent queries, but uses additional database connections, which might require additional database licenses with some database licensing methods. Additionally, RAS processes should be monitored for usage patterns. A typical report modification session might retrieve and format many records from the database and have high processor utilization, For instance, a user can group, filter, and re-format results, causing another full retrieval of records from the database and high processing load on the RAS machine. Additionally, certain types of viewerssuch as the Interactive Vieweralso use the RAS. Thus you cannot simply equate RAS use with Page Server use, but must instead monitor the RAS from time to time to ensure that your projections are correct. Sizing the Job ServerIf scheduled reporting is part of the BusinessObjects Enterprise deployment, it will be necessary to determine how many Job Servers will be required to support the total BusinessObjects Enterprise end-user base. Optimally, a Job Server service can process roughly five concurrent jobs per CPU. Given a quad processor server, no more than four Job Server services should be installed on a single server. Having too many Job Servers in the BusinessObjects Enterprise system can overwhelm the DBMS because too many jobs try to process concurrently. Alternatively, having too few Job Servers could mean that users have to wait a long time as their job gets queued up waiting for other jobs to complete processing. If the BusinessObjects Enterprise environment has a fixed reporting time window in which all reports can only be processed, the following formulas can be used as a rough guide to determine how many servers to dedicate as Job Servers:
A company needs to run 58 reports where each report takes on average 20 minutes to run. Because they will be reporting off a production database, they will be given a time window of only one hour nightly. How many Job Servers and processors will they need?
Therefore, for BusinessObjects Enterprise to process 58 20-minute reports in one hour, four Job Server services set to process five concurrent jobs each on four processors would be required. Given the fact that four processors are required for the Job Server services, a single quad processor server, two dual processor servers, or four single processor servers could be used with the BusinessObjects Enterprise system. The option to use a single server does not provide any logical Job Server redundancy; that is, if a report processing job fails on one server it isn't picked up by another. Only physical hardware "high availability" is achieved. The four-server implementation also requires added administration and maintenance. In this situation, it would be advisable to use two dual processor servers because it provides a good balance between a level of physical fault tolerance, less resource contention/conflicts, and ease of maintainability. As mentioned before, if report processing of scheduled reports happens during office hours, it is advantageous if the Job Server services reside on dedicated physical servers. If report processing of scheduled reports occurs off-hours, the Job Server services can potentially reside on the same physical servers as the Page Server services, given that the number of processors required is also satisfied. Monitoring the BusinessObjects Enterprise System: AuditingThe Auditing features of BusinessObjects Enterprise can provide feedback on the current configuration of the system. With the results of the auditing captured in an auditing database, system performance can be examined to determine if services are operating outside of requirements and also to determine how resources are being used. For instance, if you see that a particular report is being viewed many times by many different users, you might elect to schedule that report so that users will not be causing high load on the reporting database. In addition to the auditing capabilities of BusinessObjects Enterprise, the operating system's native monitoring can help you determine how a system is performing. For instance, in Windows environments, perfmon (the Windows Performance Monitor) can trace the amount of processor time a particular server uses and thus whether a particular server is over- or underutilized. The use of Auditing in BusinessObjects Enterprise creates a nominal increased load on the overall BusinessObjects Enterprise system. Small sets of data are written to a separate auditing database on a set frequency. The overhead involved is barely noticeable in both small and large deployments. Sample BusinessObjects Enterprise Deployment ScenariosThis section describes several different classes of BusinessObjects Enterprise configurations. The first is a centralized BusinessObjects Enterprise architecture followed by a distributed architecture and then a fault-tolerant architecture. A Centralized, Single-Server DeploymentA centralized architecture (see Figure 26.1) has all BusinessObjects Enterprise system components installed on the same server. This is the simplest configuration and the easiest to manage because the entire system is self-contained. Figure 26.1. Centralized architecture: single-server configuration. This also is the easiest configuration to maintain; for example, it takes the guesswork out of performing backups because Web pages, report templates, and the system database all reside on this server. This is advantageous for smaller implementations and yet it still allows for outward scalability by adding more servers when and if they are required. This setup is perfect for workgroup applications, small projects, or Web applications that have modest and light report processing and viewing needs. Such a configuration can be very CPU-intensive because all the BusinessObjects Enterprise components, as well as the DBMS and Web server, are running concurrently. A system administrator must be proactive in identifying potential system bottlenecks and thus scale those components out onto other separate servers accordingly. Also, this configuration offers little in terms of fault tolerance because all components are centralized. Distributed Computing: Three-Server ImplementationThe benefits of distributing components over multiple servers are numerous. By separating BusinessObjects Enterprise components onto separate physical servers, contention for resources that would normally have to be shared in a single server configuration is reduced. For example, components on the same server usually contend with CPU time, context switching, memory substructure, and the disk subsystem sharing. Admittedly, there are considerations involved with such a configuration. Although separate physical servers help resolve resource conflicts, components now must inter-communicate across the local area network. This adds network traffic and introduces network latency to the whole equation. Although this probably is a negligible issue when compared to the benefits, it is worthwhile to point out that there is always a trade-off. Additionally, adding more servers to the BusinessObjects Enterprise architecture increases server operation and maintenance costs. This three-server configuration (see Figure 26.2) is the most commonly used deployment by most organizations. The main feature of this configuration is the separation of the intelligence components from the report-processing tier. By separating these processes, user interaction processes have the highest priority and are not affected by CPU contention issues. Server 1 is responsible for Web server interaction, such as processing of Web scripts and presentation of Web pages, as well as caching of repetitive requests. Server 2 handles system database inquiries. Server 3 processes reports and stores processed results. Figure 26.2. Distributed computing: three-server configuration. Server 3 is tasked mainly with report-processing duties. Report processing is a highly CPU-intensive activity. It's advisable to assign the best performing hardware for this server. As an example, most companies use a dual-processor server for Server 1 and 2 and have a quad-processor server for Server 3. In this simple example, Server 3 is processing on-demand reports, generating epf cache pages, and processing scheduled reports. Processing on-demand reports and cache page generation are also response timesensitive tasks and should have high CPU-processor precedence. Thus, if these tasks are not mutually exclusive with the processing of scheduled jobs, it is advisable to separate Page Servers from Job Servers onto separate servers. Notice that with this configuration, Server 1 houses only the Web server and the CMS is on a separate server. Often companies already have a Web server and DBMS in place that they would like to leverage. In these cases, these BusinessObjects Enterprise components can be offloaded from Server 1 and 2 (see Figure 26.3). Figure 26.3. Three-server configuration with offloaded system database and Web server. Depending on hardware availability, this can have either a positive or negative effect on system performance (that is, network traffic, shared Web, and DBMS services). The CMS database must be highly available to the CMS. Thus, it is advisable not to put the CMS database on the same DBMS as reporting databases (the databases that report access for end-user data). For those reasons it's also advisable not to place the CMS database on the same server that houses either the Page or Job Servers because of their CPU-intensive activities. The BusinessObjects Enterprise system administrator must examine issues such as leveraging of existing services, performance, and maintainability to determine which route to go. A BusinessObjects Enterprise Distributed Architecture: Multiple Report Processing ServersFuture growth commonly comes from more concurrent users and thus more report processing and viewing. In most BusinessObjects Enterprise environments the report processing servers are the first to be "extended" (see Figure 26.4). If this is the case, additional Page, RAS, or Job Servers can be added to the architecture without impact or major change to the rest of the system. Figure 26.4. Configuration with multiple report processing servers. Note Page and Job Servers must access the Input File Repository to find the report template to process. The Job Server must access the Output File Repository to write out the completed processed reports. When duplicating BusinessObjects Enterprise components onto different physical servers, it is ideal if those servers have reasonable server affinity. That is, it is suggested that the servers with duplicated components should have similar hardware and run the same applications and services as their other counterparts. In addition, duplicated BusinessObjects Enterprise components should all have the same configuration settings (number of threads, timeouts, and so on) to better use the BusinessObjects Enterprise load-balancing algorithms. The fault-tolerant configuration (see Figure 26.5) is for organizations that are looking for a highly available, reliable, and robust system architecture. This configuration can tolerate a higher level of server failures than previous configurations, thus eliminating single points of failure. Figure 26.5. BusinessObjects Enterprise in a fault-tolerant configuration. The key design feature of a fault-tolerant BusinessObjects Enterprise architecture is each BusinessObjects Enterprise service or daemon has a minimum of two separate instances running on physically separate servers. With the distribution of each component over two or more servers rather than just a single server, fault tolerance is gained. If one server becomes unavailable but the other is still functioning, your entire system is effectively functioning. In this configuration, additional fault tolerance is gained by using a separate fault-tolerant RDBMS for the CMS database, and a SAN (Storage Area Network) or other fault-tolerant file system for the File Server storage location. However, the price paid for this redundancy is the increase in number of servers and maintenance of those servers. For the File Repository Servers, all the services should be clustered and pointed to the same file locations for Input and Output respectively. The File Repository Servers would also be installed onto this second server; however, they are running but dormant by default. These File Repository Servers will become "active" only if the primary server fails. Note that this implementation also has redundancy at the Web server level; however, some method of redirecting Web requests to either Web server is required. This can be accomplished through the use of any Web farm load-balancing mechanism (such as Hardware load balancer, DNS round robin, or Microsoft Network Load Balancing [NLB]). Caution Although using Microsoft's Network Load Balancing (NLB) on a Web server works very well, using NLB on any machine that has any BusinessObjects Enterprise services running on it will damage the BusinessObjects Enterprise Installation. NLB acts by changing effective IP addresses on several machines, which allows external requests to one IP to contact several machines. BusinessObjects Enterprise, however, expects that a particular service on a particular machine will always have the same IP address. Using NLB results in system corruption such that the system must be totally uninstalled and reinstalled, losing all system data. Remember that BusinessObjects Enterprise automatically load balances, so an external load balancer is unnecessary and indeed can make the system unstable. |
EAN: 2147483647
Pages: 365