To configure the Board Server run the Board Server Configuration program on the machine where the Board server is installed.
The following program will open
The Board Server Configuration parameters are
Board Path: Board’s data directory where Capsules, Databases and other Board’s folders are located. The system automatically creates a subdirectory of the specified path, named Board, containing different sub-directories such as Board\Capsules and Board\Database and others.
Communication port: sets the TCP/IP port number for the client-server communications. The Board service needs to use 5 ports, by default the ports used are 9700, 9701, 9702, 9703, 9710. If you change the default port from 9700 to another value, other 4 ports will be used in sequence, adding 1,2,3 and 10. This same port number must be configured on the Board Client when setting the Base Port of the Hosts definitions (found under Board Options | Hosts configuration window).
About ports,
ports 9700 and 9701 are used in the communication with Board Client when using SSO authentication and the Board Client is in the same domain of the Board Server.
ports 9702 and 9703 are used in communication with Board Client when SSO authentication is not used (the Board Client and Board Server can be in different domains).
port 9710 is used by the client Auto-update service.
When configuring the firewall rules for the Board Server,
open ports 9700 and 9701 if users are connecting using the SSO authentication option and only to PCs located in the same domain of the Board Server.
open ports 9702 and 9703 if there are users connecting without the SSO authentication method. These usually are either remote or travelling users, or guests such as external consultants which need to connect to the Board Server from PCs that are not within you company's domain or that don't have a network account.
open port 9710 only if you are using Board's autopudate service to distribute updates of the Board Client program on the user's PCs.
Maximum Concurrent Threads: This parameter sets the maximum number of concurrent execution threads that the server will potentially allocate for executing multidimensional requests. The parallel requests in excess of this threshold are queued and assigned to the first thread that becomes idle.
Report Rows Upper Limit: Maximum number of rows allowed in a report. The purpose of this threshold is to avoid executing very large reports (run-away queries).
Note that this value should be set equal to (or higher than) the highest value set for the same field when configuring the Board Client program on users’ computers.
When a user requests a report, before executing it, the Board Server estimates the number of rows the report has by multiplying the number of selected occurrences of the entities set by row. If the number of estimated rows exceeds the limit, then the report is not executed.
If a user requests a report with one entity by row, then the estimated number of rows is given by the number of selected occurrences of this entity. For example, for a report which has the Customer entity by row, the estimate is the number of selected Customers (open the select window to view the selected occurrences).
If a user requests a report which has two independent entities by row, for example Month then Customer, and has selected 3 Months and 1000 Customers, the estimated number of rows is 3000.
First user: Allows to create the first user on the server. After the first installation of the Board Server, since no users are defined yet, it is necessary to create the first user in order to be able to connect to the Board Server service from a Board Client.
Enable Username/Password authentication: Enable Board Client users to connect to the Service by providing a username and password. You should disable this option only if all users authenticate using the Single Sing-on (SSO) which uses the Windows authentication. Note that SSO requires that the computer of the user is authenticated on the same domain of the Board Server. SSL Encryption allows to encrypt communications using an SSL certificate.
Enable LDAP/AD authentication: configures the Board Server to validate the user credentials (username and password) against an LDAP server or a Microsoft Windows Active Directory server.
Allow non encrypted connections inside Windows domain: When enabled, the communications between the Board Client and Board Server aren't encrypted but only if the client is inside the local domain. Note that by default all communications are encrypted.
Enable clients auto-update service: Enables the service which automatically downloads and installs updates of the Board Client software when users connect to the Board server.
The configuration parameters are saved in the file Server_config.xml located in the installation directory (i.e. the directory where the program BoardEngine.exe is located).
The Board Server program has one additional tab which allows to configure the Settings for the HBMP engine.
Database Mode
- In-Memory: loads all the database in RAM: the data dictionary, entities, entity members, relationships, the bitmaps (cube addressing structures) and the cube data.
- Hybrid: loads all the database in RAM: the data dictionary, entities, entity members, relationships and the bitmaps but not the cube data, leaving it by default on disk.
If the full In-Memory option is chosen, all the data of a database is loaded in memory, this will result in an amount of RAM used greater than the size of the database on disk.
Hybrid should be chosen when the in-memory option is not viable because the memory required is too high. This option reduces RAM consumption and grants huge scalability because the amount of RAM needed for a loading in memory a database will depend on the multidimensional space mapping and is no longer proportional to the amount of measures or transactions loaded. Though this option can save a huge amount of memory and grant scalability as no other in-memory technique can, it affects performance only by 15% to 20% because most of the query processing is anyhow performed in-memory (all the computation of what data to fetch and where) and requires a disk access only at the very end of the process chain.
Moreover the Hybrid mode allows still allows to selectively define per each single Board cube (in-RAM) if it should be managed fully In-Memory or not, therefore the cubes which are more frequently used can be configured fully in-memory for best performance, while the lesser used cubes can be left on disk and will be loaded only on demand when required by a query.
NOTE !!
For planning applications or in general solutions providing user data-entry and execution of procedures, the In-Memory mode should be preferred, however if not possible due to RAM constraints, use the Hybrid mode but set all cubes on which users perform data-entry or run procedures to be in-RAM.
Max number of databases to keep in memory
This parameter defines the maximum number of databases that the Board Server may keep simultaneously open therefore in memory (even with the Hybrid configuration opening a database implies loading parts of it in memory). A database is loaded in memory the first time a query or request on that database is received (for example when a user opens a Capsule using the database). The database is never unloaded unless the service is stopped or the Board administrator manually unloads it.
On a production server, this parameter should be set equal or greater to the number of Board databases residing on this server but it should also be verified that the server capacity is sufficient to open all the databases.
Multi-core layout processing
Tick this check-box to enable parallel processing of multiple blocks of a single Layout. This setting should generally always be switched on, unless the server has limited CPU resources available. Disabling the parallel processing of Layouts will reduce performance of single user queries (Layouts) and may improve overall throughput in case of concurrency but only when in case the server CPUs are saturated. If the server CPU capacity is sufficient (CPUs don't fully saturate to 100%) then parallel processing of Layout grants better performance for the individual user and in high concurrency situations.
Multi-core on loading cubes
This option should always be switched on, unless you need to perform a test for tracing the amount of RAM used for loading into memory entities, cubes, sparse structure etc.. To perform a test:
- stop the Board Server service,
- disable this option, set the In-Memory or Hybrid mode as desired and then restart the service,
- open the database to analyse from the BoardClient.
This action will trigger the loading in memory of the database. When completed, a log file named HBMP_DatabaseName_InMemory.Log is created in the directory Board\Dataset\Log. Open the log file with a text to editor.
At the end of the test remember to switch this option back on.
Note:
After changing any of the parameters, stop and restart the Board Server service.
Board Server has the following hardware and software prerequisites
- Operating system must be a 64-bit system: Microsoft Windows 2008 R2 (64-bit edition), Microsoft Vista Professional (64-bit edition), Microsoft Windows 7 (64-bit edition).
- Microsoft .Net Framework 3.5 and Microsoft .Net Framework 4.5 and ADOMD.Net
- RAM: minimal amount of RAM depends on the size of the Board database(s) used . Generally a Board database will occupy an amount of RAM which can be 1.5 to 3 times more than the size of the database on disk (in HBMP format) in case the option full in-Memory is used. When the Hybrid configuration is chosen, then the amount of RAM necessary is more limited since only the data dictionary (entities, members, cube definitions and bitmaps) are loaded in memory. As a rule of thumb, you may consider three typical RAM requirements:
- small server: 8 to 16 GB of RAM for small databases. These are generally databases that in version 7.3 are below 1GB in disk size and in B7.4 are below 500MB.
- medium server: 16 to 32GB of RAM for mid size databases. These generally are databases that in version 7.3 have a size between 10 to 30GB and once converted range between 2 to 4GB.
- large server: 32 to 64 GB of RAM for large databases. These databases could have a size of 50 to over 100GB in version 7.3 and after conversion range between 5 and 20GB.
Note that the number of concurrent users also affects RAM utilisation however only in a very limited manner. For example, if a database takes 5 GB of RAM when fully loaded in memory (single user), then if the server is accesses by 30 or even 50 users simultaneously the RAM consumption will generally increase to no more than 1 or 2 GB to a total of 6GB or 7GB.
In order to server a high number of concurrent users, your server must have multiple CPU cores. As a rule of thumb you may consider the following as references:
- small server: a system generally serving 5 to 50 concurrent users, for a standard Business Intelligence application should have no less than a CPU hexa-core or two quad-core CPUs.
- medium server: a system generally serving 100 concurrent users, for a standard Business Intelligence application or 20 to 40 concurrent users working on a simple planning application should have two to four CPUs hexa-core for a total of 12 to 24 cores.
- large server: a system generally serving several hundred concurrent users on a standard Business Intelligence application or 50+ concurrent users working on a planning application should have no less than four CPUs hexa-core, but this dimensioning may vary depending on the frequency of utilisation or the complexity of the processing involved in the simulation or planning solution.
The above guidelines are rough estimates based on average cases. It is possible and sometimes necessary to make a more accurate dimensioning of hardware requirements by running some a workload tests with a Board database and Capsules that represent the complexity and nature of the solution to deploy.