GENERAL OVERVIEW
Does MicroStrategy 7.0 provide its own clustering strategy?
Yes. MicroStrategy 7.0 provides clustering at the MicroStrategy Intelligence Server level allowing users, connected through 4-tier mode, to access MicroStrategy Intelligence Server cluster.
What is the current clustering architecture of MicroStrategy 7.0?
The clustering architecture can be described as follows:
1. MicroStrategy Web users send requests from their web browsers.
2. A third party IP redistribution tool such as Cisco Local Router or Microsoft Windows Load Balancing Service is used to distribute requests coming from web clients among web servers.
3. Based on the load on each MicroStrategy Intelligence Server, the load balancers distribute the requests among the MicroStrategy Intelligence Servers. Each MicroStrategy Intelligence Server collects information about its own load and gives this information to the load balancer requesting this information. MicroStrategy Intelligence Server 7.0, 7.0 SP1 and 7.0 SP2 calculate load as being the number of user connections connected to the MicroStrategy Intelligence Server. When a new user connects to a MicroStrategy Web server, MicroStrategy Web opens a new user connection to the MicroStrategy Intelligence Server with the lightest load. All requests by that user will be routed to the same MicroStrategy Intelligence Server until the user is disconnected by MicroStrategy Web.
<>
After users are connected to a MicroStrategy Intelligencer Server node, the node may crash, causing users to be disconnected. If the users are not running any requests when the failure occurs, then MicroStrategy Web will automatically create a new connection to an available cluster node the next time the users submit a request. If the users are running a report request during the node failure, the report request will result in an error. MicroStrategy Web 7.0, 7.0 SP1 and 7.0 SP2 will trap this error and return a message to inform the users of the error in the report and asking them whether or not they would like to resubmit the report. If the users decide to resubmit the report, MicroStrategy Web will open a new connection to an available MicroStrategy Intelligence Server, with the same login credentials originally supplied by the users. Autoprompts will have to be re-answered during this report resubmission. MicroStrategy Web can be customized so that when an Intelligence Server goes down and a user is disconnected, resulting errors will be trapped and reports will be resubmitted without the end user knowing.
4. The MicroStrategy Intelligence Servers receive the requests and process them. In addition, the MicroStrategy Intelligence Servers communicate with each other to maintain metadata integrity and report cache synchronization across the system. Any report caches created by one MicroStrategy Intelligence Server node are accessible by any other MicroStrategy Intelligence Server node in the cluster.
5. The MicroStrategy Intelligence Servers send queries to the databases as usual.
When is clustering recommended?
Clustering is recommended in any mission-critical application in which permanent availability and system performance is of utmost importance. Availability is provided by failover support and performance improvements are provided by load balancing of job requests.
MICROSTRATEGY INTELLIGENCE SERVER CLUSTERING
What information is shared by the application across MicroStrategy Intelligence Server nodes?
Report caches are shared in a cluster and Object caches on each MicroStrategy Intelligence Server node are synchronized.
Is a copy of each report cache retained in each MicroStrategy Intelligence Server node?
No. Each MicroStrategy Intelligence Server retains a lookup table with information about the existence and location of report caches. When a cluster node creates a report cache, information about the location of the new cache is shared with the other cluster nodes. Each cluster node then updates its own lookup table with the location of the new cache.
If a MicroStrategy Intelligence Server node crashes, will report caches be lost?
Although report caches will not be lost, access to report caches may be affected, depending on the way in which the report cache is configured.
If a separate file server is used as a common report cache repository for all MicroStrategy Intelligence Server cluster nodes, then the loss of a cluster node will not affect access to the report cache by other nodes.
If the cluster is configured such that each node locally hosts the report cache created by that node, then those report caches residing in the lost node will naturally be inaccessible. If any report cached in that lost node is requested, then another node within the cluster will re-run and re-cache the report. When the cluster node is recovered and rejoined into the cluster, all report caches in that cluster node will be made available again to the rest of the cluster.
If a MicroStrategy Intelligence Server node is removed from a cluster manually, will report caches be lost?
If an administrator removes a cluster node from a cluster, then all report caches that had been created by that cluster node will be inaccessible by the rest of the cluster, whether or not a separate file server is used as a common report cache. This behavior is by design.
How does MicroStrategy Intelligence Server 7.0 clustering enable cache sharing?
Each node in a MicroStrategy Intelligence Server 7.0 cluster maintains indices of the caches available on the different nodes. When a report is submitted, these indices will be searched and once an existing cache is found (in any nodes), the cached results will be retrieved directly from cache locations in either the local or remote machine.
What methods can be used to guarantee availability of the MicroStrategy Intelligence Server report cache?
To prevent the loss of a MicroStrategy Intelligence Server cluster node from affecting report cache availability, the cluster can be configured such that a separate file server is used as a common report cache repository. In order to maintain cache availability, this separate file server can be configured for failover with third-party clustering software.
If a report cache is created by a MicroStrategy Intelligence Server cluster node, will that report cache be seen in the Cache Monitor of another cluster node?
No. Although the new report cache will be available for use by other cluster nodes, the cache will not appear in the Cache Monitor of other cluster nodes. In order to see all report caches within a cluster, the administrator will need to create a separate data source within Desktop for each cluster node. Then, the report caches within each node can be administered separately, using the same instance of the MicroStrategy Desktop application.
If objects are created, modified or deleted, will the change be reflected across all MicroStrategy Intelligence Server cluster nodes?
Yes. Object caches are synchronized across all cluster nodes. If any change affecting the Metadata is made by one cluster node, then the cluster node broadcasts the change to the other cluster nodes. The other cluster nodes will then update their local object caches.
NOTE: Client-side object caches will not be automatically be refreshed. In MicroStrategy Desktop, for example, a user may have to explicitly click on 'Refresh' to see an object change be reflected in the client application.
Should all MicroStrategy Intelligence Server cluster nodes be configured identically?
Technically, MicroStrategy Intelligence Servers in a cluster do not have to be configured identically. The only technical requirements are that all MicroStrategy Intelligence Servers point to the same metadata and that all MicroStrategy Intelligence Servers have the same projects registered and in the same state (i.e., if Node A has Project A in a 'Loaded' state, then Node B must also have Project A in a 'Loaded' state.).
However, in order to ease administration and to reduce the risk of unbalanced load across cluster nodes, it is recommended that all nodes use the same MicroStrategy Intelligence Server definition and that each machine shows identical characteristics (i.e., equal RAM, hard disk space, CPU).
Is it possible for different nodes of a MicroStrategy Intelligence Server cluster to run against different metadata repositories?
No, all the nodes in the same cluster must run against the same metadata.
Is it possible for different nodes of a MicroStrategy Intelligence Server cluster to run with different configuration settings under the same metadata repository?
Yes this is possible, using caution because users can configure different nodes at different settings. For example, differences in memory allocation for the cache, time out settings, etc can result in uneven performance across cluster nodes.
What communication protocol does MicroStrategy Intelligence Server use for intracluster communication?
MicroStrategy Intelligence Server 7.0 and MicroStrategy Intelligence Server 7.0 SP1 use TCP/IP when communicating between clusters. MicroStrategy Intelligence Server 7.1 will provide the option of using TCP/IP or UDP/IP (Universal Datagram Protocol). In 7.2, UDP support was removed as packet loss affects cluster synchronization.
If a MicroStrategy Intelligence Server cluster node is rebooted, will the node rejoin the cluster automatically?
Whenever a MicroStrategy Intelligence Server cluster node is stopped in any way besides explicitly shutting down the MicroStrategy Intelligence Server service, the node will automatically rejoin the cluster when the MicroStrategy Intelligence Server service is restarted. So, if the node crashes, then the node will rejoin the cluster automatically upon startup.
NOTE: All cluster nodes must have the same projects loaded. Therefore, MicroStrategy Intelligence Server must be configured to have the appropriate projects automatically load upon startup so that the node can successfully rejoin the cluster upon startup.
If the cluster node is stopped by explicitly shutting down the MicroStrategy Intelligence Server service (either through the MicroStrategy Desktop interface, the Windows Services window, or the MicroStrategy Service Manager), then the administrator must manually add the node back to the cluster when the node is restarted. This is by design. Since stopping the MicroStrategy Intelligence Server service requires intervention of the administrator, this behavior allows administrators to retain control over the MicroStrategy Intelligence Server application when the application is restarted.
Does MicroStrategy Intelligence Server support clustering via Microsoft Cluster Server or any other third-party clustering software?
Microsoft Cluster Server (MSCS) can be used for failover of MicroStrategy Intelligence Server. However, MSCS and other third-party clustering software will not provide the load-balancing and some of the failover capabilities of MicroStrategy Intelligence Server's native clustering solution.
Is it possible to run multiple instances of MicroStrategy Intelligence Server on the same Microsoft Windows NT machine?
MicroStrategy 7.0 does not support running multiple instances of MicroStrategy Intelligence Server on the same Microsoft Windows NT machine. This is because MicroStrategy Intelligence Server can support running multiple projects with different prioritization and configuration settings on one server. This functionality was not available in MicroStrategy DSS Server 5.x and thus, required running multiple instances of MicroStrategy Intelligence Server to accomplish the same functionality.
What is the maximum number of nodes that can be supported in a MicroStrategy Intelligence Server 7.0 cluster?
There is no technical hard limit on the maximum number of cluster nodes that can be supported by MicroStrategy Intelligence Server 7.0. However, when the number of nodes increases, there is increasing overhead put on the system by the clustering software. So, there will be practical limits related to the hardware configuration of the users' system.
MICROSTRATEGY WEB CLUSTERING
Does MicroStrategy Web support clustering via Cisco Local Router or any other third-party clustering software?
MicroStrategy Web relies on third-party web-clustering software to provide clustering functionality. MicroStrategy Web is designed to be stateless so that each individual MicroStrategy Web node can function without the knowledge of the existence of other nodes. Therefore, any third-party software used to cluster web servers can be used.
What information is shared by the application across MicroStrategy Web nodes?
MicroStrategy Web is designed to be as stateless as possible. Therefore, no information is shared by the MicroStrategy Web application across cluster nodes. All state information for running jobs is pushed to the client browser.
When a report is submitted by a MicroStrategy Web user, the user will receive a wait page in the client browser. This wait page will poll the MicroStrategy Web Server periodically for the status of the report. This polling is performed as new http requests. This http request will contain all state information, including encrypted login information and MicroStrategy Intelligence Server connection information.
Is MicroStrategy Web "cluster-aware"?
The MicroStrategy Web application is designed so that each MicroStrategy Web cluster node does not need to know that it is a member of a cluster. MicroStrategy Web is designed to be stateless, so that each client http request can be processed individually without having to persist information within the MicroStrategy Web application. Therefore, third-party Web-server clustering software can be used to cluster together multiple web servers running MicroStrategy Web.
Should MicroStrategy Web be specifically configured to access a MicroStrategy Intelligence Server cluster?
No. When the administrator configures MicroStrategy Web to access a particular MicroStrategy Intelligence Server, the MicroStrategy Web application will automatically detect that the MicroStrategy Intelligence Server is a member of a cluster. Once this detection is made, MicroStrategy Web will automatically add all the other members of the same cluster into the pool of available MicroStrategy Intelligence Servers.
No comments:
Post a Comment