MicroStrategy - Installation

mstr

Setting up a clustered environment:

What are the overview steps to configure a clustered environment?

  1. Confirm that you have fulfilled the pre-requisites for clustering Intelligence Servers. See page 432 of the System Administration Guide version 9.2.1
  2. Back up the existing token files. Look in webapps/MicroStrategy/WEB-INF/xml
  3. Configure the caches to synchronize information across nodes. Before Intelligence Servers can be clustered, the information such as report caches and History Lists must be synchronized between them. See page 435 of the System Administration Guide version 9.2.1
  4. Join nodes. See page 442 of the System Administration Guide version 9.2.1
  5. Configure history list
  6. Decide on whether to use User Affinity Clustering or not
  7. Test the clustered system. Once the cluster has been created, you should test it to make sure that the caches and metadata are being shared properly between nodes. See page 443 of the System Administration Guide version 9.2.1

What are the pre-requisites for clustering?

  1. Licensing: You must have purchase a license that allow clustering. To determine the license information, use the License Manager tool and verify that the Clustering feature is available for Intelligence Server
  2. Version number: The computers to be clustered must have the same version of Intelligence Server installed
  3. Same metadata: All MicroStrategy projects on the clustered machines must be based on the same metadata
  4. At least one project must be defined in the metadata.
  5. Only one Intelligence Server per machine. We can only run one Intelligence Server on each machine.
  6. System user account: The system user account which the Intelligence Server service is running must have full control of cache and History List folders on all nodes. Otherwise, Intelligence Server will not be able to create and access cache and History List files.
  7. Same server definition: Server definition store Intelligence Server configuration information
  8. MicroStrategy Desktop: MicroStrategy Desktop must be installed on a Windows machine to administer the cluster. This version of MicroStrategy Desktop must be the same as the version of Intelligence Servers
  9. Same intra-cluster communication settings: The computer that will be clustered must have the same intra-cluster communication settings. To configure these settings, on each Intelligence Server machine, in Desktop, right-click on the project source and select Configure MicroStrategy Intelligence Server. The Intelligence Server Configuration Editor opens. Under the Server definition category, select General
  10. Same caching method: The same caching method (Local Cache or Centeralized Cache) should be used for both result caches and file-based History Lists
  11. Same OS version: The machines to be clustered must be running the same version of the same operating system. You cannot cluster two machines when one is running on Windows 2008 and one is running on Windows 2003.
  12. Identical hardware: Load balancing and system configuration are simpler if identical hardware is used for each of the clustered nodes.
  13. Clock synchronization: All of the nodes in the clustered must have their clocks synchronized.
  14. RDBMS containing the metadata and warehouse databases must be set up on machines separate from the Intelligence Server nodes.
  15. DSNs must be created and configured on each machine: The required data source names (DSNs) must be created and configured for Intelligence Server on each machine. MicroStrategy strongly recommends that you configure Intelligence Servers to use the same metadata database, warehouse, port number, and server definition.
  16. All nodes must join the cluster before you make any changes to any governing settings
  17. Netbios: On all machines to be clustered, each network care must be configured to enable Netbios over TCP/IP. Otherwise, cache sharing is not possible using Netbios names (ClusterCaches, ClusterCube, and ClusterInbox)
  18. OS Trust Relationship: When Intelligence Server is installed, the last step is to choose a user identity under which the service will run. To run a clustered configuration, the user must be a domain account that has a trust relationship with each of the computers in the cluster. This allows resources to be shared across the network.
  19. Regional Options: The service user's Regional Options settings must be the same as the clustered system's Regional Options settings.

How to configure caches in a cluster on Windows?

There are two methods for caching: "Local Cache" and "Centralized Cache". For now, I believe that "Local Cache" is better than "Centralized Cache". See page 429 of the System Administration Guide version 9.2.1. This question covers using "Local Cache"

MicroStrategy strongly recommends that each node in your cluster use the same server definition. And as long as each node is using the same server definition, you only need to configure the cache location one time. However, you must create the shared folder on each node separately. To configure cache sharing using "Local Cache":

  1. Open the Project Configuration Editor for the project. One of the pre-requisite: At least one project must be defined in the metadata.
  2. Select Caching -> Result Caches -> Storage
  3. In the Cache file directory box, type: .\Caches\ServerDefinition where ServerDefinition is the name of the server definition. This tells the other clustered nodes to search for caches in the following path on all machines in the cluster: <Intelligence Server Application Folder>\Caches\SeverDefinition
  4. On the left pane, drill down on Intelligence Cubes -> General
  5. In the Intelligence Cube file directory box, type: .\Cube\ServerDefinition where ServerDefinition is the name of the server definition. This tells the other clustered nodes to search for Intelligence Cubes in \\<Intelligence Server Application Folder>\Caches\ServerDefinition
  6. Click OK
  7. On each machine in the cluster, open Window Explorer and navigate to the cache file folder. The default location is: C:\Program Files\MicroStrategy\Intelligence Server\Caches. Create a folder ServerDefinition where ServerDefinition is the name of the server definition, if it does not exist.
  8. Right click on this folder, and select Sharing. The [Server Definition] Properties dialog box opens.
  9. On the Sharing tab, select the Shared as option. In the Shared Name box, delete the existing text and type ClusterCaches
  10. Click OK.
  11. On each machine in the cluster, open Window Explorer and navigate to the Intelligence Cube file folder. The default location is: C:\Program Files\MicroStrategy\Intelligence Server\Cube\. Create a folder ServerDefinition where ServerDefinition is the name of the server definition, if it does not exist.
  12. Right click on this folder, and select Sharing. The Properties dialog box opens.
  13. On the Sharing tab, select the Shared as option. In the Shared Name box, delete the existing text and type ClusterCube
  14. Click OK.
  15. After you have completed these steps, you can cluster the nodes using the Cluster Monitor

How to configure History List sharing using "Local Caches"?

If we are using a file-based History List, we can set up History Lists to use multiple local disk backups on each node in the cluster, using a procedure similar to the procedure above. The History List messages are stored in the History folder. To locate this folder, in the Intelligence Server Configuration Editor, select Governing, then select History settings. The History List location is .\Inbox\ServerDefinition, where ServerDefinition is the name of the folder containing the History Lists. This folder must be shared with the share name "ClusterInbox".

How to configure the History List governing settings for a clustered environment?

  1. Using MicroStrategy Desktop, log into a project source.
  2. From the Administration menu, point to Server and then select Configure MicroStrategy Intelligence Server.
  3. Expand the Server Definition category, and then select Advanced.
  4. Do one of the following: To enable user affinity clustering, select the User Affinity Clustering checkbox. If we do not want to use user affinity clustering, then in the Backup frequency (minutes) field, type 0 (zero).
  5. Click OK.
  6. Restart Intelligence Server

How can I configure Intelligence Server to use a database-based History List repository?

  1. Log into the project source
  2. From the Administration menu, select Server -> Configure MicroStrategy Intelligence Server. The Intelligence Server Configuration Editor opens.
  3. On the left, expand Server Definition -> General. When the Intelligence Server Configuration Editor opens, this is the default screen that is displayed.
  4. Under Content Server Location -> Database Instance, select the History List Database option
  5. On the left, expand History Settings and select General
  6. Select "Database based"
  7. A warning is displayed. Click Yes to close the warning message.
  8. From the "Database Instance" menu, select the database instance that points to the History List repository in the database.
  9. Click OK. The Intelligence Server Configuration Editor closes.
  10. Restart Intelligence Server for the changes to take effect.

How can I confirm that the History List repository has been configured correctly?

  1. Log in to the project source
  2. From the Administration menu, select "Server", the "Configure MicroStrategy Intelligence Server". The "Intelligence Server Configuration Editor" opens.
  3. On the left, expand History Settings, and select General. If you have configured Intelligence Server properly, following message is displayed in the Repository Type area of the Intelligence Server Configuration Editor: Server is currently connected to the History List Repository.

If the above step indicates that the Intelligence Server is not connected to the Content Server Repository, we will have to:

  • Drill down on Administration -> Configuration Managers -> Database Instances
  • Right click on History List Database and select Edit
  • In the bottom section, select MicroStrategy_History and click Modify
  • In the bottom section, select appropriate Database Login Name, and click Modify
  • Make sure that the login ID and password fields contain correct values.
  • Click OK until the Database Instance Editor dialog disappear.
  • Restart the Intelligence Servers.

How to enable / disable User Affinity Clustering?

  1. Launch MicroStrategy Desktop
  2. Log into appropriate project source
  3. From the Administration menu, select Server -> Configure MicroStrategy Intelligence Server
  4. Check or uncheck the checkbox next to User Affinity Cluster

In the 9.2.x series, we should be aware of the following documented issues related to User Affinity Clustering: TN39940, and TN37386

My gut feeling is that we should not be using User Affinity Clustering with 9.2.x yet, not only because of the above issue, but because I am storing history list items in the database (not sure if database-based history list is more efficient than file-based history list), and because I do not fully understand TN40623.

How to join a node to a cluster?

  1. Using MicroStrategy Desktop, log into a project source.
  2. Expand Administration, then expand System Administration, and then select Cluster. Information about each node in the cluster displays on the right-hand side.
  3. From the Administration menu, point to Server, then select Join cluster. The Cluster Manager dialog box opens.
  4. Type the name of the machine running the Intelligence Server to which you wish to add this node, or click … to browse and select it.
  5. Once you have specified or selected the server to join, click OK.
  6. From the Administration menu, select Server -> Configure MicroStrategy Intelligence Server, drill down on Clustering, select the checkboxes, and hit OK

How to verify that the clustered system is working?

To verify using MicroStrategy Desktop:

  1. Verify the Cluster view:
    1. Connect to one Intelligence Server in the cluster and ensure that the Cluster view in Desktop (under Administration -> System Administration) is showing all the proper nodes as members of the cluster)
  2. Verify the cache:
    1. Connect to any node and run a large report.
    2. User the Cache Manager and view the report details to make sure the cache is created. (The Cache Monitor is part of MicroStrategy Desktop. Log into a project source, drill down on Administration -> System Monitors -> Caches)
    3. Connect to a different node and run the same report. Verify that the report used the cache created by the first node.
  3. Verify the History List:
    1. Connect to any node and run a report
    2. Add the report to the History List
    3. Without logging out that user, log onto a different node with the same user name
    4. Verify that the History List contains the report added in the first node

To verify from MicroStrategy Web:

  1. Open MicroStrategy Web Administrator page.
  2. Connect to any node in the cluster. MicroStrategy Web should automatically recognize all nodes in the cluster and show them as connected. If MicroStrategy Web does not recognize all nodes in the cluster, it is possible that the machine itself cannot resolve the name of that node. MicroStrategy cluster implementation uses the names of the machines for internal communication. Therefore, MicroStrategy Web machine should be able to resolve names to IP addresses. You can edit the lmhost file to related IP addresses to machine names.
  3. You can also perform the same cache and History List tests described above.

How to distribue projects across nodes in a cluster?

  1. In MicroStrategy Desktop, from the Administration menu -> Projects -> Select Projects. The Intelligence Server Configuration Editor opens at the Projects: General category
  2. One column is displayed for each node in the cluster that is detected at the time the Intelligence Server Configuration Editor opens. Select the corresponding checkbox to configure the system to load a given project on a given node. A selected box at the intersection of a project row and a node column signifies that the project is to be loaded at startup on that node. If no check boxes are selected for a project, the project is not loaded on any node at startup. Likewise, if no check boxes are selected for a node, no projects are loaded on that node at startup.
  3. Select whether to display only the selected projects, and whether to apply the startup configuration on save.
  4. Click OK.

How to configure MicroStrategy to use a shared network cache?

To set up a shared network cache on a network file server, create a directory to hold the caches on the file server and give it a shared name as desired. In the project configuration, set the cache location to be \\MachineName\ShareName. This only needs to be done once per server definition.

Similarly, to create history lists on a network file server, create a directory to hold the history lists on the file server, and give this directory a shared name. In the Intelligence Server Configuration, set the history list location to be \\MachineName\ShareName. This also needs to be done only once per server definition.

Notice that report cache settings are done per project and different projects may use a different methods of report cache storage. Different projects may also use different locations for their cache repositories. However, history list settings are done per server definition. As a result, different projects cannot use different locations for their history list.

Configuring Intelligence Server to log statistics:

What are the high level steps to configure a project to log statistics?

  1. Create the statistics database
  2. Create the statistics tables in the statistics database
  3. Configure your project to log statistics to the specified database
  4. Specify what statistics to log for each project

How to create the statistics database?

You can store Intelligence server statistics in an existing database, or create a new database. Do not store the statistics in the same database that you are using for either MicroStrategy metadata or your data warehouse. To use an existing database, note the Data Source Name (DSN) for it. This DSN is used when you create the statistics tables. If you choose to use Enterprise Manager to analyze the statistics, this DSN is also used to specify the data warehouse location for the Enterprise Manager.

To create a new statistics database:

  1. Create the empty data warehouse database. This is generally performed by your database administrator.
  2. Use the MicroStrategy Connectivity Wizard to create a Data Source Name (DSN) for the data warehouse. Note this DSN for later. To access the Connectivity Wizard, from the Windows Start menu -> Programs -> MicroStrategy -> Tools -> Connectivity Wizard

How to create the statistics tables in the statistics database?

  1. Start the MicroStrategy Configuration Wizard (Start menu -> Programs -> MicroStrategy -> Configuration Wizard)
  2. On the welcome page, select Metadata, History List, and Statistics Repository Tables and click Next
  3. Select the Statistics Tables option and clear all other options.
  4. Click Next
  5. From the DSN drop-down list, select the DSN for the statistics database. Any table in this database that has the same name as the MicroStrategy statistics table is dropped.
  6. In the User Name and Password fields, enter a valid login and password for the statistics database. The login that you specify must have permission to create and drop tables, and permission to create views in the statistics database.
  7. Click Advanced
  8. In the Script field, the default script is displayed. The selected script depends on the database type that you specified previously. To select a different script, click … (the Browse button) to browse to and select a script that corresponds to the DBMS that you are using. The default location for these scripts is: C:\Program Files\Common Files\MicroStrategy
  9. Click Next
  10. Click Finish

How to configure the project to log statistics?

MicroStrategy recommends that you configure your system to use Single Instance Session Logging. In this configuration, statistics for all projects in a project source are logged to a single database. To enable single instance session logging:

  1. Launch MicroStrategy Desktop
  2. Log into appropriate project source (drill down on appropriate project source)
  3. Right click on the project source and select Configure Intelligence Server. The Intelligence Server Configuration Editor opens.
  4. Expand Statistics -> General, and select Single Instance Session Logging
  5. From the drop-down list, select a project.
  6. Continue from step 4 of the procedure for how to set up a project to log statistics (see below)

How to setup a project to log statistics?

To tell MicroStrategy to log statistics for a particular projects:

  1. Launch MicroStrategy Desktop
  2. Log into appropriate project source (drill down on appropriate project source)
  3. Right click on appropriate project and select Project Configuration. If you are using Single Instance Session Logging, the project that you select must be the project that you selected when you set up Single Instance Session Logging
  4. Expand the Database Instances category, and select SQL Data Warehouse sub-category.
  5. You need to create a new database instance for the statistics database. Click New. The Database Instances dialog box opens.
  6. In the Database instance name field, type in a name for the statistics database instance
  7. From the Database connection type drop-down list, select the database type and version that corresponds to the statistics database DBMS.
  8. You need to create a new database connection to connect to the database instance. Click New. The Database Connections dialog box opens.
  9. In the Database connection name field, type a name for the database connection.
  10. From the ODBC Data Sources list, select the Data Source Name (DSN) used to connect to the statistics database.
  11. If your database supports parameterized queries, you can improve the efficiency of the statistics logging process by enabling parameterized queries in the statistics database instance. To do this, on the Advanced tab, select the Use Parameterized Queries check box.
  12. You need to create a new database login to log into the database instance. On the General tab, click New. The Database Logins dialog box opens.
  13. Type a name for the new database login in the Database login field. If this database login is more than 32 characters long, the statistics logging will generate errors in the DSS Errors log.
  14. Type a valid database login ID and password in the corresponding fields. MicroStrategy does not validate this login ID and password, so be careful to type them correctly.
  15. Click OK 3 times to return to the Project Configuration Editor. Each time you click OK, make sure your new database login and database connection are selected before clicking OK.
  16. In the Database Instances category, select the Statistics sub-category
  17. From the Statistics DB Instance drop-down list, select your new statistics database instance.
  18. Click OK.

See page 333 of System Administration Guide version 9.2.1

How to specify which statistics to log?

After you specified a statistics database instance for a project, you can select what statistics to log. You must specify what statistics to log for all projects that log statistics. Single Instance Session Logging causes all projects on a project source to share the same statistics database, but not to log the same statistics. To log information from the performance counters, use the Diagnostics and Performance Logging Tools. To specify which statistics to log for a project:

  1. Launch MicroStrategy Desktop
  2. Log into appropriate project source (drill down on appropriate project source)
  3. Right click on appropriate project and select Project Configuration
  4. Expands Statistics -> General
  5. Select the Basic Statistics check box.
  6. To log advanced statistics, select the check boxes for the statistics you wish to log
  7. Click OK
  8. To begin logging statistics, unload and reload the project:
    • In MicroStrategy Desktop, expand Administration -> System Administration -> Projects. A list of all projects on this project source is displayed.
    • Right click on the project -> Administer Project, and select Unload
    • Right click on the project -> Administer Project, and select Load. The project is reloaded and configured to log statistics.

How many servers can be part of a cluster?

Up to 4 Intelligence Server machines

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License