IBM License Metric Tool 9.2.x. Scalability Guide. Version 2 IBM

Transcription

1 IBM License Metric Tool 9.2.x Scalability Guide Version 2 IBM

2

3 IBM License Metric Tool 9.2.x Scalability Guide Version 2 IBM

4 Scalability Guide This edition applies to ersion 9.2.x of License Metric Tool (product number 5724-T40) and to all subsequent releases and modifications until otherwise indicated in new editions. Copyright IBM Corporation 2002, US Goernment Users Restricted Rights Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp.

5 Contents Scalability Guidelines Introduction Scanning and uploading scan data Extract, Transform, Load (ETL) Decision flow Planning and installing License Metric Tool Hardware requirements Network connection and storage throughput.. 7 Diiding the infrastructure into scan groups Good practices for running scans and imports... 8 Enabling the cryptographic hash collection Change the mode of sorting bundling options on the IBM Software Classification pane Configuring the application and its database for medium and large enironments Increasing Jaa heap size Configuring the transaction logs size Configuring the transaction log location for DB2 13 Configuring swappiness in Linux hosting DB2 database serer Configuring the DB2_COMPATIBILITY_VECTOR ariable for improed UI performance Improing aggregation time in enironments with multiple computer groups Shrinking MS SQL Serer transaction log Configuring the transaction log location for MS SQL Serer Rebuilding database indexes Optimizing the tempdb database in Microsoft SQL Serer Preentie actions Recoering from accumulated scans Shortening the retention period gradually to aoid problems with growing database size IBM PVU considerations Web user interface considerations Using relays to increase the performance of IBM BigFix Reducing the BigFix serer load Appendix. Executie summary Notices Trademarks Terms and conditions for product documentation.. 25 Priacy policy considerations Copyright IBM Corp. 2002, 2018 iii

6 i IBM License Metric Tool: Scalability Guide Version 2

7 Scalability Guidelines This guide is intended to help system administrators plan the infrastructure of IBM License Metric Tool and to proide recommendations for configuring the application serer to achiee optimal performance. It explains how to diide computers into scan groups, schedule software scans, and run data imports. It also proides information about other actions that can be undertaken to aoid low performance. Introduction IBM BigFix clients report data to the BigFix serer that stores the data in its file system or database. The License Metric Tool serer periodically connects to the BigFix serer and its database, downloads the stored data and processes it. The process of transferring data from the BigFix serer to the License Metric Tool serer is called Extract, Transform, Load (ETL). By properly scheduling scans and distributing them oer the computers in your infrastructure, you can reduce the length of the ETL process and improe its performance. Scanning and uploading scan data To ealuate whether particular software is installed on an endpoint, you must run a scanner. It collects information about files with particular extensions, package data, and software identification tags. The software scan data must be transferred to the BigFix serer from which it can be later on imported to License Metric Tool. To discoer software that is installed on a particular endpoint, you must first install a scanner by running the Install Scanner fixlet. After the scanner is successfully installed, the Initiate Software Scan fixlet becomes releant on the target endpoint. The following types of scans are aailable: Catalog-based scan In this type of scan, the License Metric Tool serer creates scanner catalogs that are sent to the endpoints. Based on these catalogs, the scanner discoers exact matches and sends its findings to the BigFix serer. This data is then transferred to the License Metric Tool serer. Package data scan In this type of scan, the scanner searches the system registry (Windows) or package management system (Linux, UNIX) to gather information about packages that are installed on the endpoints. Then, it returns the findings to the BigFix serer where the discoered packages are compared with the software catalog. If a particular package matches an entry in the catalog, the software is discoered. Software identification tags scan In this type of scan, the scanner searches for software identification tags that are deliered with software products. Resource utilization scan In this type of scan, the scanner searches for software license metric (SLM) tags that contain information about internal product metrics. These metrics are periodically logged from software products enabled for SLM (standardized into ISO ) and can be used to track their usage. The scanner returns its findings to the BigFix serer, where the tags are processed. Based on the information that they contain, the maximum usage of license metrics oer the last 30 days and the trend alues are calculated. The scan collects information about license metrics that are releant for licensing models different than PVU or RVU MAPC (these two metrics do not need to be logged separately). Since the olume of the collected data might be large, do not run this scan unless you want to monitor metrics other than PVU and RVU MAPC. You should run the scans on a regular basis as they are responsible for software discoery. Copyright IBM Corp. 2002,

8 When the status of the Initiate Software Scan fixlet shows complete (100%), it indicates that the scan was successfully initiated. It does not mean that the releant data was already gathered. After the scan finishes, the Upload Software Scan Results fixlet becomes releant on the targeted endpoint. It means that the releant data was gathered on the endpoints. When you run this fixlet, the scan data is uploaded to the BigFix serer. It is then imported to License Metric Tool during the Extract, Transform, Load (ETL) process. Extract, Transform, Load (ETL) The Extract, Transform, Load (ETL) is a process in the database usage that combines three database functions that transfer data from one database to another. The first stage, Extract, inoles reading and extracting data from arious source systems. The second stage, Transform, conerts the data from its original format into the format that meets the requirements of the target database. The last stage, Load, saes the new data into the target database, thus finishing the process of transferring the data. In License Metric Tool, the Extract stage inoles extracting data from the BigFix serer. The data includes information about the infrastructure, installed agents, and detected software. ETL also checks whether a new software catalog is aailable, gathers information about the software scan and files that are present on the endpoints, and collects data from VM managers. The extracted data is then transformed to a single format that can be loaded to the License Metric Tool database. This stage also inoles matching scan data with the software catalog, calculating processor alue units (PVUs), and conerting information that is contained in the XML files. After the data is extracted and transformed, it is loaded into the database and can be used by License Metric Tool.The hardest load on the License Metric Tool serer occurs during ETL when the following actions are performed: A large number of small files is retrieed from the BigFix serer (Extract). Many small and medium files that contain information about installed software packages are parsed (Transform). The database is populated with the parsed data (Load). At the same time, License Metric Tool prunes large olumes of old data that exceeds its data rentention period. Performance of the ETL process depends on the number of scan files, and package analyses that are processed during a single import. The main bottleneck is storage performance because many small files must be read, processed, and written to the License Metric Tool database in a short time. By properly scheduling scans and distributing them oer the computers in your infrastructure, you can reduce the length of the ETL process and improe its performance. An important factor that influences the duration of the ETL process is the amount of updates on the file system since the last scan. Such operations as security updates or significant system upgrades can cause ETL to run longer, because it has to process information about all modified files. For example, regular updates released by Microsoft on Tuesdays would significantly lengthen the Wednesday import in enironments with many Windows platforms. 2 IBM License Metric Tool: Scalability Guide Version 2

9 Extract, Transform, and Load Client computer - console Client computer - browser Endpoint Manager serer Endpoint Manager database Information about files Endpoint Manager file system Scan files Core business logic Relay 1. Extract Infrastructure information Installed agents Scan data files Capacity data files Package data files Files with VM manager information High-speed network connection Software catalog License Metric Tool serer Web user interface Core business logic 2. Transform Information from the XML files is processed. Data is transformed to a single format. Scan data is matched with the software catalog. PVU and RVU alues are calculated. The capacity scan is processed. License Metric Tool database 3. Load Data is loaded into the License Metric Tool database tables. Endpoint Manager Client on Windows, Linux and UNIX XML Scan data Catalog-based Capacity Package Software identification tags XML VM manager data (Windows and Linux x86/x64only) Endpoint Manager client on Linux on System z XML Scan data Catalog-based Capacity Package Software identification tags XML Capacity configuration Decision flow To aoid running into performance issues, you should diide the computers in your infrastructure into scan groups and properly set the scan schedule. You should start by creating a benchmark scan group on which you can try different configurations to achiee optimal import time. After the import time is satisfactory for the benchmark group, you can diide the rest of your infrastructure into analogous scan groups. Start by creating a single scan group that will be your benchmark. The size of the scan group might ary depending on the size of your infrastructure. Howeer, the recommendation is to aoid creating a group larger than endpoints. Scan the computers in this scan group. When the scan finishes, upload its results to the BigFix serer and run an import. Check the import time and decide whether its duration is satisfactory. For information about running imports, see section Good practices for running scans and imports on page 8. If you are not satisfied with the import time, check the import log and try undertaking one of the following actions: Scalability Guidelines 3

10 If you see that the duration of the import of package data takes longer than one third of the ETL time and the olume of the data is large (a few millions of entries), create a smaller group. For additional information, see section Diiding the infrastructure into scan groups on page 7. If you see that the duration of the import of package data takes longer than one third of the ETL time but the olume of the data is low, fine-tune hardware. For information about processor and RAM requirements as well as network latency and storage throughput, see section Planning and installing License Metric Tool on page 6. After you adjust the first scan group, run the software scan again, upload its results to the BigFix serer and run an import. When you achiee an import time that is satisfactory, decide whether you want to hae a shorter scan cycle. For example, if you hae an enironment that consists of endpoints and you created seen scan groups of 6000 endpoints each, your scan cycle will last seen days. To shorten the scan cycle, you can try increasing the number of computers in a scan group, for example, to It will allow you for shortening the scan cycle to six days. After you increase the scan group size, obsere the import time to ensure that its performance remains on an acceptable leel. When you are satisfied with the performance of the benchmark scan group, create the remaining groups. Schedule scans so that they fit into your preferred scan cycle. Then, schedule import of data from BigFix. Obsere the import time. If it is not satisfactory, adjust the configuration as you did in the benchmark scan group. Use the following diagram to get an oeriew of actions and decisions that you will hae to undertake to achiee optimal performance of License Metric Tool. 4 IBM License Metric Tool: Scalability Guide Version 2

11 Installation Plan and install License Metric Tool Configuration Create a scan group (up to computers) Initiate the scan and upload scan results Fine tune hardware (if possible) Create a smaller scan group Run an import and check its time Is the import time satisfactory? No Yes Increase the size of the scan group Yes Do you want to hae a shorter scan cycle? No Create the remaining scan groups Fine tune hardware (if possible) Schedule the scans to fit into the scan cycle Create a smaller scan group Schedule daily imports Is the import time still satisfactory? No Yes Plan for end-of-cycle actiities Scalability Guidelines 5

12 Planning and installing License Metric Tool Your deployment architecture depends on the number of endpoints that you want to hae in your audit reports. For information about the BigFix requirements, see Serer requirements aailable in the documentation. Hardware requirements If you already hae the BigFix serer in your enironment, plan the infrastructure for the License Metric Tool serer. License Metric Tool serer stores its data in a dedicated database, either DB2 or MS SQL Serer. The following tables are applicable for enironments in which the scans are run weekly, imports are run daily, and 60 applications are installed per endpoint (on aerage). Table 1. Processor and RAM requirements for License Metric Tool installed with Microsoft SQL serer Enironment size Topology Processor Memory Small enironment 1 serer IBM BigFix, License Metric Tool, and SQL Serer 2-3 GHz, 4 cores 8 GB Up to endpoints Medium enironment endpoints* Large enironment endpoints* Very large enironment More than endpoints* 2/3 serers** 2/3 serers** 2/3 serers** IBM BigFix 2-3 GHz, 4 cores 16 GB License Metric Tool and SQL Serer 2-3 GHz, 4 cores GB IBM BigFix 2-3 GHz, 4-16 cores License Metric Tool and SQL Serer 2-3 GHz, 8-16 cores GB GB IBM BigFix 2-3 GHz, 16 cores GB License Metric Tool and SQL Serer 2-3 GHz, 8-16 cores GB*** Table 2. Processor and RAM requirements for License Metric Tool installed with DB2 Enironment size Topology Processor Memory Small enironment 1 serer IBM BigFix, License Metric Tool, and DB2 (All-in-One) 2-3 GHz, 4 cores 8 GB Up to endpoints Medium enironment endpoints* Large enironment endpoints* 2/3 serers** 2/3 serers** IBM BigFix 2-3 GHz, 4 cores 16 GB License Metric Tool and DB2 2-3 GHz, 4 cores GB IBM BigFix 2-3 GHz, 4-16 cores License Metric Tool and DB2 2-3 GHz, 8-16 cores GB GB 6 IBM License Metric Tool: Scalability Guide Version 2

13 Table 2. Processor and RAM requirements for License Metric Tool installed with DB2 (continued) Enironment size Topology Processor Memory Very large enironment More than endpoints* 2/3 serers** IBM BigFix 2-3 GHz, 16 cores License Metric Tool and DB2 2-3 GHz, 8-16 cores GB GB * For enironments with up to endpoints, there is no requirement to create scan groups. If you hae more than endpoints in your infrastructure, you must create scan groups. For more information, see section Diiding the infrastructure into scan groups. ** A distributed enironment, where License Metric Tool is separated from the database, is adisable. *** SQL Serer must be throttled to 3/4 RAM capacity. Medium-size enironments You can use irtual enironments for this deployments size, but it is adisable to hae dedicated resources for processor, memory, and irtual disk allocation. The irtual disk that is allocated for the irtual machine should hae dedicated RAID storage, with dedicated input-output bandwidth for that irtual machine. Large and ery large enironments For large deployments, use dedicated hardware. For optimum performance, use a database serer that is dedicated to License Metric Tool and is not shared with BigFix or other applications. Additionally, you might want to designate a separate disk that is attached to the computer where the application database is installed to store the database transaction logs. You might need to do some fine-tuning based on the proided recommendations. Network connection and storage throughput The Extract, Transform, Load (ETL) process extracts a large amount of scan data from the BigFix serer, processes it on the License Metric Tool serer, and saes it in the DB2 or MS SQL database. The following two factors affect the time of the import to the License Metric Tool serer: Gigabit network connection Because of the nature of the ETL imports, you are adised to hae at least a gigabit network connection between the BigFix, License Metric Tool, and database serers. Disk storage throughput For large deployments, you are adised to hae dedicated storage, especially for the database serer. The minimum expected disk speed for writing data is approximately 400 MB/second. Diiding the infrastructure into scan groups It is critical for License Metric Tool performance that you properly diide your enironment into scan groups and then accurately schedule scans in those scan groups. If the configuration is not well-balanced, you might experience long import times. For enironments larger than endpoints, diide your endpoints into separate scan groups. The system administrator can then set a different scanning schedule for eery scan group in your enironment. Example If you hae endpoints, you can create six scan groups (eery group containing endpoints). The first scan group has the scanning schedule set to Monday, the second to Tuesday, and so on. Using this configuration, eery endpoint is scanned once a week. At the same time, the BigFix serer receies Scalability Guidelines 7

14 data only from 1/6 of your enironment daily and for eery daily import the License Metric Tool serer needs to process data only from endpoints (instead of endpoints). This enironment configuration shortens the License Metric Tool import time. The image below presents a scan schedule for an infrastructure that is diided into six scan groups. You might achiee such a schedule after you implement recommendations that are contained in this guide. The assumption is that both software scans and imports of scan data to License Metric Tool are scheduled to take place at night, while uploads of scan data from the endpoints to the BigFix serer occur during the day. Day 1 Day 2 Day 3 Day 4 Day 5 Day 6 Day 7 Night Import Group 1 Import Group 2 Import Group 3 Import Group 4 Import Group 5 Import Group 6 Scan Group 1 Scan Group 2 Scan Group 3 Scan Group 4 Scan Group 5 Scan Group 6 Day Upload Group 1 Upload Group 2 Upload Group 3 Upload Group 4 Upload Group 5 Upload Group 6 If you hae a powerful serer computer and longer import time is acceptable, you can create fewer scan groups with greater number of endpoints in the BigFix console. Remember to monitor the import log to analyze the amount of data that is processed and the time it takes to process it. For information how to create scan groups, see the topic Computer groups that is aailable in the BigFix documentation. Good practices for running scans and imports After you enable the License Metric Tool site in the BigFix console, carefully plan the scanning actiities and their schedule for your deployment. Run the initial import It is a good practice to run the initial import before you schedule scans and actiate analyses. This import uploads the software catalog from the installation directory to License Metric Tool and extracts basic data about endpoints from the BigFix serer. Run the second import after scan data from the first scan group is aailable in BigFix. Run the next import, when data from the second computer group is aailable. Plan scan frequency After you find the optimal size of scan groups, set the frequency of software scans. The most common frequency is weekly so that eery endpoint is scanned once a week. If your enironment has more than endpoints, consider performing scans less frequently, for example monthly. If scans are running daily, take into account system updates. When many files are modified, the next data import runs longer. Aoid scanning when it is not needed Scan frequency depends on how often software changes on the endpoints and on your reporting needs. Group endpoints on which software changes dynamically together and scan them more frequently, for example once a week. Group endpoints with a more stable set of software together and scan them less frequently, for example once a month. 8 IBM License Metric Tool: Scalability Guide Version 2

15 Schedule scans and imports to run at night Some actions in the License Metric Tool user interface cannot be performed when an import is running. Thus, try to schedule imports when users are not using License Metric Tool or after they finished their daily work. Limit the number of computer properties gathered during scans By default, License Metric Tool retriees four computer properties from the BigFix serer: computer name, DNS name, IP address, and operating system. Imports can be much longer if you extract more properties from BigFix during each import. It is a good practice to limit the number of computer properties to 10 or fewer. Limit the number of License Metric Tool computer groups Create only as many computer groups as are needed. Import of data gets longer with a growing number of computer groups. Reiew import logs Reiew the following INFO messages in the import log to check how much data was transferred during the import. Information about Items specified in the import log Description Infrastructure Computer items The total number of computers in your enironment. A computer is a system with a BigFix client that proides data to License Metric Tool. Software and hardware Installed packages SAM::ScanFile items SAM::CitFact items SAM::IsotagFact items SAM::PackageFact items SAM::UnixPackageFact items The number of files that hae input data for the following items: Catalog-based scan information (SAM::CitFact items) Software identification tag scan information (SAM::IsotagFact items) The total count of information pieces from catalog-based scans (contained in the processed scan files). The total count of information pieces from software identification tag scans (contained in the processed scan files). The total count of information pieces about Windows packages that were gathered by the package data scan. The total count of information pieces about UNIX packages that were gathered by the package data scan. Example: INFO: Computer items: INFO: SAM::ScanFile items: INFO: SAM::IsotagFact items: 0 INFO: SAM::CitFact items: INFO: SAM::PackageFact items: INFO: SAM::UnixPackageFact items: Maintain frequent imports After the installation, imports are scheduled to run once a day. Do not change this configuration. Howeer, you might want to change the hour when the import starts. If your import is longer than 24 hours, you can improe the scan groups configuration. Alternatiely, you can presere the current configuration because License Metric Tool handles oerlapping imports. If an import is running, no other import is started. Scalability Guidelines 9

16 Recommendations for the serice proider enironments The serice proider functionality is used to create separate subcapacity reports for different sets of computers. You can create such a report for each computer group. By default, the calculation of PVU and RVU MAPC consumption is disabled for new computer groups. After you enable it, a computer group becomes a subcapacity computer group, and can hae its own subcapacity report. This, howeer, impacts performance due to increased number of subcapacity calculations. If you decide to create more than 10 subcapacity computer groups, adjust the use of CPU resources and tune the default configuration of License Metric Tool. The most important processes for subcapacity computer groups are aggregation and reaggregation. Performance of these processes depends on the maximum number of threads that can be run for the calculations, which by default is 2. You improe performance by increasing the number of aailable threads. To increase the number of aailable threads, specify the alues of the maxaggregationthreads and maxreaggregationthreads parameters. To specify the alues of these parameters, log in to License Metric Tool and go to Management > Adanced Serer Settings. In general, you should proide two processor cores for each thread on your database serer. For example, if you can proide 12 processor cores for the aggregation process itself, increase the number of threads to 6 by specifying maxaggregationthreads=6. Enabling the cryptographic hash collection Each change to the configuration of the cryptographic hash collection (enabling, disabling, adding new types) significantly lengthens the first data import that follows the change. Because of multiple modifications on the file system, the new configuration triggers a complete data import instead of the delta one, in which only modifications are imported. This first data import might take up to three times longer, and the subsequent ones about 10% longer than data imports without file hashes. The impact of subsequent data imports is considered as moderate. Before enabling the collection of file hashes, it is recommended to diide your enironment into scan groups to distribute the load of the imported data. If the extended data import (three times longer) is acceptable, enable the collection of file hashes for all scan groups, and collect the data according to schedule. If the extended data import does not meet your expectations, rearrange your scan groups into smaller ones with fewer endpoints to lower the amount of data included in a single data import. After the first import is completed for all scan groups, you can go back to the preious setup. In general, scan groups are highly recommended for enironments with more than 35,000 endpoints. For smaller enironments, you must decide whether the extended data import is acceptable, or you want to distribute it among seeral smaller ones by using scan groups. Example In an enironment with endpoints diided into 6 scan groups (each with endpoints), where each scan group is scanned on a different day, the file hashes will be collected in 6 days. The initial import for each scan group after enabling the collection might be three times longer. Next imports will take about 10% longer. Impact of file hashes on the BigFix Inentory database size For both DB2 and SQL Serer databases, the collection of file hashes (MD5 and SHA-256) is expected to result in a 20% growth of the disk space consumption. 10 IBM License Metric Tool: Scalability Guide Version 2

17 Impact of file hashes on the BigFix client File hashes are calculated during the software scan and the results are gathered on the endpoint. The size of scan results will increase by about 5%. For an aerage endpoint with 30 matched and 800 unmatched raw data files, an additional 0.5 MB of disk space might be consumed. To reduce the impact on the import time and the size of the database, consider limiting the number of scanned signature extensions. Change the mode of sorting bundling options on the IBM Software Classification pane By default, the bundling options that are displayed when you reassign a software component on the IBM Software Classification pane are sorted by confidence. You might want to change this mode of sorting bundling options if the IBM Software Classification pane is running slowly or the License Metric Tool serer is under a heay load. If you set the alue of the blockuibundlingcomputations parameter to true, the bundling options are sorted alphabetically and are displayed more quickly because no additional computation is added to the serer workload. Procedure To set the parameter alue to true, open the REST add-on in your web browser, for example Adanced REST client, and run the following REST API query. PUT name=blockuibundlingcomputations&alue=true Example: PUT name=blockuibundlingcomputations&alue=true To run the query with the curl tool, start curl and enter the following command: curl - PUT name=blockuibundlingcomputations&alue=true Example: curl - PUT name=blockuibundlingcomputations&alue=true Configuring the application and its database for medium and large enironments To aoid performance issues in medium and large enironments, configure the location of the transaction log and adjust the log size. If you are using MS SQL as License Metric Tool database, you might want to shrink the transaction log or update query optimization statistics. Component Configuration tasks License Metric Tool serer Increasing Jaa heap size on page 12 DB2 Configuring the transaction logs size on page 12 Configuring the transaction log location for DB2 on page 13 Configuring swappiness in Linux hosting DB2 database serer on page 14 Configuring the DB2_COMPATIBILITY_VECTOR ariable for improed UI performance on page 14 Scalability Guidelines 11

18 Component Configuration tasks Microsoft SQL serer Shrinking MS SQL Serer transaction log on page 15 Configuring the transaction log location for MS SQL Serer on page 15 Rebuilding database indexes on page 15 Optimizing the tempdb database in Microsoft SQL Serer on page 16 Note: In Microsoft SQL Serer, the transaction log is increased automatically - no further action is required. Increasing Jaa heap size The default settings for the Jaa heap size might not be sufficient for medium and large enironments. If your enironment consists of more than 5000 endpoints, increase the memory aailable to Jaa client processes by increasing the Jaa heap size. Procedure 1. Go to the <INSTALL_DIR>/wlp/usr/serers/serer1/ directory and edit the jm.options file. 2. Set the maximum Jaa heap size (Xmx) to one of the following alues, depending on the size of your enironment: For medium enironments ( endpoints), set the heap size to 6144m. For large enironments ( endpoints), set the heap size to 8192m. For ery large enironments (oer endpoints), set the heap size to 12288m. 3. Restart the License Metric Tool serer. Configuring the transaction logs size If your enironment consists of many endpoints, increase the transaction logs size to improe performance. About this task The transaction logs size can be configured through the LOGFILSIZ DB2 parameter that defines the size of a single log file. To calculate the alue that can be used for this parameter, you must first calculate the total disk space that is required for transaction logs in your specific enironment and then multiply it, thus obtaining the size of one transaction log. The required amount of disk space depends on the number of endpoints in your enironment and the number of endpoints in the biggest scan group for which data is processed during the import. Important: Use the proided formula to calculate the size of transaction logs that are generated during the import of data. More space might be required for transaction logs that are generated when you remoe the data source. Procedure 1. Use the following formula to calculate the disk space that is needed for transaction logs: <The number of computers> 1.2 MB + <the number of computers in the biggest scan group> 1.2 MB + 17 GB 2. To obtain the size of a single transaction log file that can be specified in the LOGFILSIZ DB2 parameter, multiply the result by Note: The number 1852 expresses the relation between the primary and secondary log files and is necessary to calculate the size of a single transaction log file (LOGFILSIZ). The factor was calculated assuming the default number of log files (LOGPRIMARY = 25 and LOGSECOND = 110). 12 IBM License Metric Tool: Scalability Guide Version 2

19 3. Run the following command to update the transaction log size in your database. Substitute alue with the size of a single transaction log. Note: TEMADB is the default database name. If you are unsure whether it applies to your database, see: Checking the database name. db2 update database configuration for TEMADB using logfilsiz alue 4. For the changes to take effect, restart the database. Run the following commands: db2 deactiate db TEMADB db2stop db2start db2 actiate db TEMADB 5. Restart the License Metric Tool serer. a. To stop the serer, run the following command: /etc/init.d/lmtserer stop b. To start the serer, run the following command: Example /etc/init.d/lmtserer start Calculating the single transaction log size for endpoints and scan results: MB MB + 17 GB = 155 GB = is the alue to be specified in the LOGFILSIZ parameter. Configuring the transaction log location for DB2 To increase database performance, moe the DB2 transaction log to a file system that is separate from the DB2 file system. About this task Medium enironments: Large enironments: Very large enironments Strongly adised Required Required Procedure 1. To moe the DB2 transaction log to a file system that is separate from the DB2 file system, update the DB2 NEWLOGPATH parameter for your License Metric Tool database: UPDATE DATABASE CONFIGURATION FOR TEMADB USING NEWLOGPATH alue Where alue is a directory on a separate disk (different from the disk where the DB2 database is installed) where you want to keep the transaction logs. This configuration is strongly adised. 2. For the changes to take effect, restart the database. Run the following commands: DEACTIVATE DB TEMADB DB2STOP DB2START ACTIVATE DB TEMADB 3. Restart the License Metric Tool serer. a. To stop the serer, run the following command: /etc/init.d/lmtserer stop b. To start the serer, run the following command: /etc/init.d/lmtserer start Scalability Guidelines 13

20 Configuring swappiness in Linux hosting DB2 database serer Swappiness determines how quickly processes are moed from RAM to hard disk to free memory. It can assume the alue A low alue means that your Linux system swaps out processes rarely while a high alue means that processes are written to disk immediately. Swapping out runtime processes should be aoided on the DB2 serer on Linux, so it is adisable to set the swappiness kernel parameter to a low alue or zero. Procedure 1. Log in to the Linux system as root. 2. Set the swappiness parameter to a low alue or 0. Option A: a. Open the file /etc/sysctl.conf in a text editor and enter the m.swappiness parameter of your choice. Example: m.swappiness = 0 b. Restart the operating system to load the changes. Option B: To change the alue while the operating system operating, run the following command: sysctl -w m.swappiness=0. Configuring the DB2_COMPATIBILITY_VECTOR ariable for improed UI performance For enironments with 5000 or more clients in your infrastructure, it is adisable to set the alue of the DB2_COMPATIBILITY_VECTOR ariable to MYS. This change might result in a UI response time that is significantly faster on some License Metric Tool installations. Procedure For information about how to modify this registry ariable, see DB2_COMPATIBILITY_VECTOR registry ariable in IBM Knowledge Center. Improing aggregation time in enironments with multiple computer groups When you create multiple computer groups in which aggregation of license metrics is enabled, the import of data lengthens. To reduce the time that is spent on aggregation during eery import, disable statement concentrator in DB2. When you disable it, the first import after you upload a new software catalog is lengthened by 1 hour. Howeer, all other imports of data are shortened thanks to reducing the time of aggregation. Before you begin The following procedure is applicable only if you use DB2 as the License Metric Tool database. You must be a DB2 Administrator to perform this task. About this task To identify the length of aggregating license metrics, check the import log and look for the following fragments :14:55 (+0:00:00.000) INFO: Loading Signatures :14:57 (+0:00:01.718) INFO: Loaded configuration of file scanner :26:48 (+0:11:50.714) INFO: Processed Signatures :50:55 (+0:00:00.003) INFO: ETL from Aggregation: Start :51:17 (+0:00:21.300) INFO: (ImportThread) 14 IBM License Metric Tool: Scalability Guide Version 2

21 com.ibm.license.mgmt.etl.core.actions.runaggregationaction::execute::statistics: Aggregation is completed for group All Computers : :51:17 (+0:00:00.009) INFO: ETL from Aggregation: Success Procedure 1. On the DB2 instance where the License Metric Tool database exists, run the following command to disable the statement concentrator. db2 UPDATE DB CFG USING STMT_CONC OFF IMMEDIATE 2. Optional: If you want to restore the original setting, run the following command. db2 UPDATE DB CFG USING STMT_CONC LITERALS IMMEDIATE Shrinking MS SQL Serer transaction log Shrink the transaction log once a month. If the enironment is large, it is adisable to shrink the log after eery data import. For more information, see How to: Shrink a File (SQL Serer Management Studio). Configuring the transaction log location for MS SQL Serer The transaction log in MS SQL Serer records all transactions and the database changes caused by each transaction. For information how to configure the database transaction log, see Moe the Database Transaction Log to Another Drie. Rebuilding database indexes Use the following SQL script to rebuild all indexes in all License Metric Tool database tables. USE TEMADB SELECT ALTER INDEX ALL ON + t.[table_schema] +. + t.[table_name] + REBUILD; FROM INFORMATION_SCHEMA.TABLES t USE TEMADB GO IF EXISTS (SELECT * FROM dbo.imports WHERE success IS NULL) BEGIN PRINT N CANNOT RUN index rebuild. LMT import is running! PRINT N Wait until LMT import finishes END ELSE BEGIN DECLARE table_cursor CURSOR FOR SELECT table_schema, table_name FROM INFORMATION_SCHEMA.TABLES WHERE table_type = BASE TABLE OPEN table_cursor sysname sysname FETCH NEXT FROM -1 BEGIN PRINT N START alter index all on + N. + N rebuild ; EXECUTE (N alter index all on + N. Scalability Guidelines 15

22 + N rebuild ) PRINT N END alter index all on + N. + N rebuild ; FETCH NEXT FROM END CLOSE table_cursor DEALLOCATE table_cursor PRINT N START sp_updatestats ; EXECUTE sp_updatestats PRINT N END sp_updatestats ; END GO Optimizing the tempdb database in Microsoft SQL Serer tempdb is a system database in SQL Serer whose main functions are to store temporary tables, cursors, stored procedures, and other internal objects that are created by the database engine. By default, the database size is set to 8 MB and it can grow by 10% automatically. In large enironments, its size can be as large as 15 GB. It is therefore important to optimize the tempdb database because the location and size of this database can negatiely affect the performance of the License Metric Tool serer. For information about how to set the database size and how to determine the optimal number of files, see the TechNet article Optimizing tempdb Performance. Preentie actions Turn off scans if the License Metric Tool serer is to be unaailable for a few days due to routine maintenance or scheduled backups. If imports of data from BigFix to License Metric Tool are not running, the unprocessed scan data is accumulated on the BigFix serer. After you turn on the License Metric Tool serer, a large amount of data will be processed leading to a long import time. To aoid prolonged imports, turn off scans for the period when the License Metric Tool serer is not running. Recoering from accumulated scans If scan results are not imported to License Metric Tool for a longer period of time, they accumulate on the BigFix serer. They are all processed during the first import after the break which might lead to long import times. To aoid the problem, skip importing the results of the software scan during the first import after the break. Then, apply good practices for distributing scans in your infrastructure, including diiding the computers into scan groups, and planning the scan schedule. It will allow for importing scan results from the consecutie scan groups without oerloading the import. About this task Recoering from accumulated scans is necessary in the following situations: Import of data to License Metric Tool was failing for a longer period of time If the import of data fails for a longer period of time, scan results accumulate on the BigFix serer. They are all processed during the first import after the break which might lead to long import times. License Metric Tool was reinstalled and scans were run in the past With each reinstallation of License Metric Tool, a new instance of License Metric Tool database is created. A fresh installation triggers the import of all historically collected scan files. 16 IBM License Metric Tool: Scalability Guide Version 2

23 License Metric Tool V9.x coexists with Software Use Analysis V1.3, V2.2, License Metric Tool V7.x or Tioli Asset Discoery for Distributed V7.x Different ersions of License Metric Tool 9.x and BigFix Inentory 9.x can coexist with each other and the earlier ersions as well as Tioli Asset Discoery for Distributed. For each additionally installed or reinstalled instance of the License Metric Tool 9.x or BigFix Inentory 9.x serer, a new database is created. It triggers the import of all historically collected scan files. Procedure For more information about coexistence scenarios, see Coexistence scenarios on the wiki. 1. Log in to License Metric Tool and go to the following URL: 2. Check the Disable the import of accumulated software scan results (next import only) check box. 3. Run the import of data (ETL). If the accumulated scan results are successfully skipped, the following information is written in the import log: :11:35 (+0:00:00.003) INFO: Accumulated results of software scans are SKIPPED :11:35 (+0:00:00.119) INFO: Accumulated results of software scans were successfully skipped during the import. The setting applied only to this import. The subsequent imports will contain the results of the software scan. If the import is successful, the function will be disabled. What to do next If the computers in your enironment are diided into scan groups, run the scans according to the specified schedule and wait for the scan results. Otherwise, diide the computers into scan groups and distribute scans oer the days of the week according to the good practices for running scans. Then, schedule incremental imports of data to License Metric Tool. Shortening the retention period gradually to aoid problems with growing database size Since License Metric Tool 9.2.1, retention period is set to 7 days in a fresh installation, so this procedure does not apply in case of fresh installations. If you did not configure the retention period after installation in earlier ersions of License Metric Tool and the data accumulation continued for seeral months, you must enable and repeatedly change the data retention configuration to make the retention period as short as possible. With each successie import, the historical data is deleted gradually and thus problems with growing database size are aoided. About this task For information about how to configure the retention period in the product web user interface, see Configuring data retention period. Note: After this configuration was applied, the transaction log is used heaily because all the data is deleted in one transaction. The database size is not decreased automatically. If you want to reclaim disk space that is occupied by database tables, run the command that is appropriate for your database management system. If the data imports during which historical data was deleted failed, increase the retention period and run the import again. Procedure 1. Determine the date of the first successful import. Scalability Guidelines 17

24 2. Calculate the number of days since the first successful import. For example: If the import occurred 6 months ago: 6 months * 30 days = 180 days. 3. Set the retention period to begin 30 days after the first successful data import. Example: 5 months * 30 days = 150 days. 4. Run the data import. 5. Set the retention period to begin 60 days after the first successful data import, that is, set the retention period to 120 days. Example: 4 months * 30 days = 120 days. 6. Repeat the step as many times as necessary, each time decreasing the retention period by 30 days. 7. When the retention period is short enough, enter the target configuration of 7 days. IBM PVU considerations If you need to generate PVU reports for an IBM compliance purposes, the best practice is to generate the report at least monthly. For organizations that span continents, from IBM compliance perspectie, the License Metric Tool Regions must be applied requiring separate License Metric Tool deployments. For more information, see Virtualization Capacity License Counting Rules. Web user interface considerations Data import is a computation-intensie task so be prepared to experience slower user interface response times while you are using. Thus, it is better to schedule the imports to take place at other times when you are not likely to use the application web UI. If, in case of huge deployments, loading any report takes substantial amount of time, see: r_ui_problems.html. Using relays to increase the performance of IBM BigFix To take adantage of the speed and scalability that is offered by IBM BigFix, it is often necessary to tune the settings of the BigFix deployment. A relay is a client that is enhanced with a relay serice. It performs all client actions to protect the host computer, and in addition, deliers content and software downloads to child clients and relays. Instead of requiring eery networked computer to directly access the serer, relays can be used to offload much of the burden. Hundreds of clients can point to a relay for downloads, which in turn makes only a single request to the serer. Relays can connect to other relays as well, further increasing efficiency. Reducing the BigFix serer load For all but the smallest BigFix deployments (< 500 BigFix clients), a primary BigFix relay should be set for each BigFix client een if they are not in a remote location. The reason for this is that the BigFix serer performs many tasks including: Gathering new Fixlet content from the BigFix serer Distributing new Fixlet content to the clients Accepting and processing reports from the BigFix clients Proiding data for the BigFix consoles Sending downloaded files (which can be large) to the BigFix client, and much more. 18 IBM License Metric Tool: Scalability Guide Version 2

25 By using BigFix relays, the burden of communicating directly with eery client is effectiely moed to a different computer (the BigFix relay computer), which frees the BigFix serer to do other tasks. If the relays are not used, you might obsere that performance degrades significantly when an action with a download is sent to the BigFix serer. Setting up BigFix relays in appropriate places and correctly configuring clients to use them is the most important change that has highest impact on performance. To configure a relay, you can: Allow the clients to auto-select their closest BigFix relay. Manually configure the BigFix clients to use a specific relay. For more information, see Managing relays. Scalability Guidelines 19

26 20 IBM License Metric Tool: Scalability Guide Version 2

27 Appendix. Executie summary Reiew the following executie summary that contains the list of the most important configuration and optimization tasks for your License Metric Tool enironment. Table 3. Summary of the scalability best practices Step Actiities 1. Enironment planning Reiew the summary information that matches your enironment size: Small Medium Large Very large Up to endpoints License Metric Tool and DB2 or MS SQL Serer installed on the same serer Scan groups (optional) endpoints Scan groups (adisable) License Metric Tool and DB2 or MS SQL Serer installed on separate computers It is possible to use irtual enironments for this deployments size, howeer it is adisable to hae dedicated resources for processor, memory, and irtual disk allocation endpoints Scan groups (required) License Metric Tool and DB2 or MS SQL Serer installed on separate computers, dedicated storage for the database software Fine-tuning might be required More than endpoints Scan groups (required) License Metric Tool and DB2 or MS SQL Serer installed on separate computers, dedicated storage for the database software Fine-tuning might be required 2 Good practices for creating scan groups Plan the scan group size Create a benchmark scan group Check the import time and decide whether it is satisfactory When you achiee an import time that is satisfactory, decide whether you want to hae a shorter scan cycle. When you are satisfied with the performance of the benchmark scan group, create the remaining groups. Copyright IBM Corp. 2002,