IBM License Metric Tool Version 9. Scalability Guide. Version 1

Transcription

1 IBM License Metric Tool Version 9 Scalability Guide Version 1

2

3 IBM License Metric Tool Version 9 Scalability Guide Version 1

4 Scalability Guide This edition applies to versions 9.0 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 Government 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 Dividing the infrastructure into scan groups Good practices for running scans and imports... 8 Plan the scanning schedule Avoid scanning when it is not needed Limit the number of computer properties that are to be gathered during scans Ensure that scans and imports are scheduled to run at night Run the initial import Review import logs Maintain frequent imports Configuring the application and its database for medium and large environments Configuring the transaction logs size Configuring the transaction log location Increasing Java heap size Backing up and restoring the database Backing up the database Restoring the database Preventive actions Recovering from accumulated scans Cleaning up high volume of License Metric Tool scans uploaded since the last import IBM PVU considerations Improving user interface performance Using relays to increase the performance of IBM Endpoint Manager Reducing the Endpoint Manager server load.. 16 Appendix. Executive summary Notices Trademarks Privacy policy considerations Copyright IBM Corp. 2002, 2014 iii

6 iv

7 Scalability Guidelines This guide is intended to help system administrators plan the infrastructure of IBM License Metric Tool and to provide recommendations for configuring the application server to achieve optimal performance. It explains how to divide computers into scan groups, schedule software scans, and run data imports. It also provides information about other actions that can be undertaken to avoid low performance. Introduction IBM Endpoint Manager clients report data to the Endpoint Manager server that stores the data in its file system or database. The License Metric Tool server periodically connects to the Endpoint Manager server and its database, downloads the stored data and processes it. The process of transferring data from the Endpoint Manager server to the License Metric Tool server is called Extract, Transform, Load (ETL). By properly scheduling scans and distributing them over the computers in your infrastructure, you can reduce the length of the ETL process and improve its performance. Scanning and uploading scan data To evaluate 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 Endpoint Manager server from which it can be later on imported to License Metric Tool. To discover 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 relevant on the target endpoint. The following types of scans are available: Catalog-based scan In this type of scan, the License Metric Tool server creates scanner catalogs that are sent to the endpoints. Based on these catalogs, the scanner discovers exact matches and sends its findings to the Endpoint Manager server. This data is then transferred to the License Metric Tool server. 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 Endpoint Manager server where the discovered packages are compared with the software catalog. If a particular package matches an entry in the catalog, the software is discovered. Software identification tags scan In this type of scan, the scanner searches for software identification tags that are delivered with software products. You should run the scans on a regular basis as they are responsible for software discovery. 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 relevant data was already gathered. After the scan finishes, the Upload Software Scan Results fixlet becomes relevant on the targeted endpoint. It means that the relevant data was gathered from the endpoint. When you run this fixlet, the scan data is uploaded to the Endpoint Manager server. 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, involves reading and extracting data from various source systems. The second stage, Transform, converts the data from its original format into the format that meets the requirements of the target database. The last stage, Load, saves the new data into the target database, thus finishing the process of transferring the data. In License Metric Tool, the Extract stage involves extracting data from the Endpoint Manager server. The data includes information about the infrastructure, installed agents, and detected software. ETL also checks whether a new software catalog is available, 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 involves matching scan data with the software catalog, calculating processor value units (PVUs), and converting 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. 2

9 Extract, Transform, and Load Client computer - console Client computer - browser Endpoint Manager server 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 server 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 values 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 Capacity configuration XML The hardest load on the License Metric Tool server occurs during ETL when the following actions are performed: v A large number of small files is retrieved from the Endpoint Manager server (Extract). v Many small and medium files that contain information about installed software packages are parsed (Transform). v The database is populated with the parsed data (Load). At the same time, License Metric Tool prunes large volumes 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 over the computers in your infrastructure, you can reduce the length of the ETL process and improve its performance. Scalability Guidelines 3

10 Decision flow To avoid running into performance issues, you should divide 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 achieve optimal import time. After the import time is satisfactory for the benchmark group, you can divide the rest of your infrastructure into analogical scan groups. Start by creating a single scan group that will be your benchmark. The size of the scan group might vary depending on the size of your infrastructure. However, avoid creating a group larger than endpoints. Scan the computers in this scan group. When the scan finishes, upload its results to the Endpoint Manager server and run an import. Check the import time and decide whether it 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: v If you see that the duration of the import of package data takes longer than one third of the ETL time and the volume of the data is large (a few millions of entries), create a smaller group. For additional information, see section Dividing the infrastructure into scan groups on page 7. v If you see that the duration of the import of package data takes longer than one third of the ETL time but the volume 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 Endpoint Manager server and run an import. When you achieve an import time that is satisfactory, decide whether you want to have a shorter scan cycle. For example, if you have an environment that consists of endpoints and you created seven scan groups of 6000 endpoints each, your scan cycle will last seven 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, observe the import time to ensure that its performance remains on an acceptable level. 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 form Endpoint Manager. Observe 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 overview of actions and decisions that you will have to undertake to achieve optimal performance of License Metric Tool. 4

11 Installation Plan and install License Metric Tool Configuration Create a scan group (up to computers) Initiate the scan and upload scan results Run an import and check its time Fine tune hardware (if possible) Create a smaller scan group Is the import time satisfactory? No Yes Increase the size of the scan group Yes Do you want to have 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 activities Scalability Guidelines 5

12 Planning and installing License Metric Tool Your deployment architecture depends on the number of endpoints that you want to have in your audit reports. For information about the Endpoint Manager requirements, see Server requirements available in the documentation. Hardware requirements If you already have the Endpoint Manager server in your environment, plan the infrastructure for the License Metric Tool server. License Metric Tool server stores its data in a dedicated DB2 database. The following tables are applicable for environments in which the scans are run weekly, imports are run daily, and 60 applications are installed per endpoint (on average). Table 1. Processor and RAM requirements for Environment size Topology Processor Memory Small environment 1 server IBM Endpoint Manager, License Metric Tool, and DB2 At least 2,5 GHz - 4 cores 8GB Up to endpoints Medium environment endpoints* Large environment More than endpoints** 2/3 servers IBM Endpoint Manager 2-3 GHz - 4 cores 16 GB License Metric Tool and DB2 At least 2 GHz GB A distributed environment is advisable. If you separate DB2 from License Metric Tool, the DB2 server should have at least 16 GB RAM. cores 3 servers IBM Endpoint Manager 2-3 GHz cores GB License Metric Tool At least 2 GHz GB cores DB2 At least 2 GHz - 16 cores 64 GB * For environments with up to endpoints, there is no requirement to create scan groups. If you have more than endpoints in your infrastructure, you must create scan groups. For more information, see section Dividing the infrastructure into scan groups on page 7. ** For larger environments, scan groups are required. Medium-size environments You can use virtual environments for this deployments size, but it is advisable to have dedicated resources for processor, memory, and virtual disk allocation. The virtual disk that is allocated for the virtual machine should have dedicated RAID storage, with dedicated input-output bandwidth for that virtual machine. Large environments For large deployments, use dedicated hardware. For optimum performance, use a DB2 server that is dedicated to License Metric Tool and is not shared with Endpoint Manager or other applications. Additionally, you might want to designate a separate disk that is attached to the 6

13 computer where DB2 is installed to store the database transaction logs. You might need to do some fine-tuning based on the provided recommendations. Plan and prepare for installation Small environment Size: Up to endpoints Install License Metric Tool and DB2 on one computer Install or reuse IBM Endpoint Manager License Metric Tool and DB2 Small What is the size of your environment? Medium Medium environment Size: endpoints Install License Metric Install or reuse Tool and DB2 IBM Endpoint on one computer Manager License Metric Tool and DB2 Large Large environment Size: endpoints Install License Metric Tool and DB2 on two computers Install or reuse IBM Endpoint Manager License Metric Tool server DB2 server A separate disk or storage might be necessary. Network connection and storage throughput The Extract, Transform, Load (ETL) process extracts a large amount of scan data from the Endpoint Manager server, processes it on the License Metric Tool server, and saves it in the DB2 database. The following two factors affect the time of the import to the License Metric Tool server: Gigabit network connection Because of the nature of the ETL imports, you are advised to have at least a gigabit network connection between the Endpoint Manager, License Metric Tool, and DB2 servers. Disk storage throughput For large deployments, you are advised to have dedicated storage, especially for the DB2 server. The expected disk speed for writing data is approximately 400 MB/second. Dividing the infrastructure into scan groups It is critical for License Metric Tool performance that you properly divide your environment 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 environments larger than endpoints, divide your endpoints into separate scan groups. The system administrator can then set a different scanning schedule for every scan group in your environment. Example Scalability Guidelines 7

14 If you have endpoints, you can create six scan groups (every group containing endpoints). The first scan group has the scanning schedule set to Monday, the second to Tuesday, and so on. Using this configuration, every endpoint is scanned once a week. At the same time, the Endpoint Manager server receives data only from 1/6 of your environment daily and for every daily import the License Metric Tool server needs to process data only from endpoints (instead of endpoints). This environment configuration shortens the License Metric Tool import time. The image below presents a scan schedule for an infrastructure that is divided into six scan groups. You might achieve 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 Endpoint Manager server 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 have a powerful server computer and longer import time is not problematic, you can create fewer scan groups with greater number of endpoints in the Endpoint Manager 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 available in the Endpoint Manager documentation. Good practices for running scans and imports 8 After you enable the License Metric Tool site in your Endpoint Manager console, carefully plan the scanning activities and their schedule for your deployment. Plan the scanning schedule After you find the optimal size of the scan group, set the scanning schedule. It is the frequency of software scan on an endpoint. The most common scanning schedule is weekly so that every endpoint is scanned once a week. If your environment has more than endpoints, consider performing scans less frequently, for example monthly. Avoid scanning when it is not needed The frequency of scans depends both on how often software products change on the endpoints in your environment and also on your reporting needs. If you have systems in your environment that have dynamically-changing software, you can group such systems into a scan group (or groups) and set more frequent scans, for

15 example once a week. The remaining scan groups that contain computers with a more stable set of software can be scanned less frequently, for example once a month. Limit the number of computer properties that are to be gathered during scans By default, the License Metric Tool server includes four primary computer properties from the Endpoint Manager server that is configured as the data source: computer name, DNS name, IP address, and operating system. Imports can be substantially longer if you specify more properties to be extracted from the Endpoint Manager database and copied into the License Metric Tool database during each import. As a good practice, limit the number of computer properties to 10 (or fewer). Ensure that scans and imports are scheduled to run at night Some actions in the License Metric Tool user interface cannot be processed when an import is running. Thus, try to schedule imports when the application administrator and Software Asset Manager are not using License Metric Tool or after they finished their daily work. Run the initial import It is a good practice to run the first (initial) import before you schedule any software scans and activate any analyses. Examples of when imports can be run: v The first import uploads the software catalog from the installation directory to the application and extracts the basic data about the endpoints from the Endpoint Manager server. v The second import can be run after the scan data from the first scan group is available in the Endpoint Manager server. v The third import should be started after the scans from the second scan group are finished, and so on. Review import logs Review the following INFO messages in the import log to check how much data was transferred during an ETL. Information about Items specified in the import log Description Infrastructure Computer items The total number of computers in your environment. A computer is a system with an Endpoint Manager agent that provides 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 have input data for the following items: v Catalog-based scan information (SAM::CitFact items) v 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 have been gathered by the package data scan. The total count of information pieces about UNIX packages that have been gathered by the package data scan. Scalability Guidelines 9

16 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. However, you might want to change the hour when the import starts. If your import is longer than 24 hours, you can: v Improve the scan groups configuration. v Preserve the current daily import configuration because License Metric Tool handles overlapping imports gracefully. If an import is running, no other import is started. Configuring the application and its database for medium and large environments 10 To avoid performance issues in medium and large environments, configure the location of the transaction log and adjust the log size. Apart from that, you can also adjust the Java heap size. Configuring the transaction logs size If your environment consists of many endpoints, increase the transaction logs size to improve 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 value that can be used for this parameter, you must first calculate the total disk space that is required for transaction logs in your specific environment and then divide it, thus obtaining the size of one transaction log. The required amount of disk space depends on the number of endpoints in your environment and the number of endpoints for which new scan results are available and processed during the data import. Important: Use the provided 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 remove the data source. Procedure 1. Use the following formula to calculate the disk space for your transaction logs: <The number of endpoints> x1mb+<the number of endpoints for which new scan results are imported> x1mb+1gb 2. Divide the result by to obtain the size of a single transaction log file. 3. Run the following command to update the transaction log size in your database. Substitute value with the size of a single transaction log. UPDATE DATABASE CONFIGURATION FOR SUADB USING LOGFILSIZ value 4. For the changes to take effect, restart the database. Run the following commands:

17 DEACTIVATE DB SUADB DB2START DB2STOP ACTIVATE DB SUADB 5. Restart the License Metric Tool server. a. To stop the server, run the following command: /etc/init.d/suaserver start b. To start the server, run the following command: Example v /etc/init.d/suaserver stop Calculating the single transaction log size for endpoints and scan results: x1MB+15000x1MB+1GB=114 GB 114 / = Configuring the transaction log location To increase database performance, move the DB2 transaction log to a file system that is separate from the DB2 file system. About this task Medium environments: Large environments: Strongly advised Required Procedure 1. To move 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 SUADB USING NEWLOGPATH value Where value 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 advised. 2. For the changes to take effect, restart the database. Run the following commands: DEACTIVATE DB SUADB DB2START DB2STOP ACTIVATE DB SUADB 3. Restart the License Metric Tool server. a. To stop the server, run the following command: /etc/init.d/suaserver start b. To start the server, run the following command: /etc/init.d/suaserver stop Increasing Java heap size The default settings for the Java heap size might not be sufficient for medium and large environments. If your environment consists of more than 5000 endpoints, increase the memory available to Java client processes by increasing the Java heap size. Scalability Guidelines 11

18 Procedure 1. Go to the <INSTALL_DIR>/wlp/usr/servers/server1/ directory and edit the jvm.options file. 2. Set the maximum Java heap size (Xmx) to one of the following values, depending on the size of your environment: v For medium environments ( endpoints), set the heap size to 6144m. v For large environments (over endpoints), set the heap size to 8192m. 3. Restart the License Metric Tool server. Backing up and restoring the database 12 Perform regular backups of the data that is stored in the database. It is advisable to back up the database before updating the software catalog or upgrading the server to facilitate recovery in case of failure. Backing up the database You can save your database to a backup file. Procedure 1. Stop the License Metric Tool server. 2. Check which applications connect to the database and then close all active connections: a. List all applications that connect to the database: db2 list applications for database SUADB b. Each connection has a handle number. Copy it and use in the following command to close the connection: db2 force application "( <handle_number> )" 3. Optional: If you activated the database before, deactivate it: db2 deactivate db SUADB 4. Back up the database to a specified directory: db2 backup database SUADB to <PATH> Restoring the database You can restore a damaged or corrupted database from a backup file. Procedure 1. Stop the License Metric Tool server. 2. Check which applications connect to the database and then close all active connections: a. List all applications that connect to the database: db2 list applications for database SUADB b. Each connection has a handle number. Copy it and use in the following command to close the connection: db2 force application "( <handle_number> )" 3. Optional: If you activated the database before, deactivate it: db2 deactivate db SUADB 4. Restore the database from a backup file: db2 restore db SUADB from <PATH> taken at <TIMESTAMP> REPLACE EXISTING

19 Preventive actions Example: db2 restore db SUADB from /home/db2inst1/ taken at REPLACE EXISTING Turn off scans if the License Metric Tool server is to be unavailable for a few days due to routine maintenance or scheduled backups. If imports of data from Endpoint Manager to License Metric Tool are not running, the unprocessed scan data is accumulated on the Endpoint Manager server. After you turn on the License Metric Tool server, a large amount of data will be processed leading to a long import time. To avoid prolonged imports, turn off scans for the period when the License Metric Tool server is not running. Recovering from accumulated scans To recover from a situation when you have a large amount of accumulated scan data, you need to clean up the License Metric Tool scans and then verify if the data was removed correctly. Cleaning up high volume of License Metric Tool scans uploaded since the last import To clean up accumulated scan data, use an SQL query that removes scan file entries from the BFEnterprise tables. Procedure 1. Stop all fixlets that scan and upload data. 2. Back up the Endpoint Manager databases: SQL server BFEnterprise and BESReporting In SQL Server Management Studio, right click the database and select Tasks > Back Up. DB2 BFENT and BESREPOR If the SQL1015N The database is in an inconsistent state. SQLSTATE = error is returned when you try to back up the DB2 database, check if the database is in an inconsistent state by running the following command: db2 get db cfg for database_name. Note: Verify whether the parameter All committed transactions have been written to disk is set to NO. If the database is in the inconsistent state, run the following commands: a. DB2 restart database DATABASE_NAME b. DB2 force applications all c. db2stop d. db2start 3. Move all files in the Upload Manager/sha1 directory on the Endpoint Manager server to a backup location. Linux: /install_dir/uploadmanagerdata/bufferdir/sha1 (that is install_dir = /var/opt/besserver) Scalability Guidelines 13

20 Windows: install_dir\uploadmanagerdata\bufferdir\sha1 (that is install_dir = c:\program Files (x86)\bigfix Enterprise\BESServer\ UploadManagerData\BufferDir\sha1) 4. Delete scan files entries from the BFEnterprise tables: SQL Server use BFEnterprise delete from dbo.uploads where (FileName LIKE %itsitsearch% OR FileName LIKE %citsearch% ) delete from dbo.uploads_availability where (FileName LIKE %itsitsearch% OR FileName LIKE %citsearch% ) DB2 connect to BFENT delete from dbo.uploads where (FileName LIKE %itsitsearch% OR FileName LIKE %citsearch% ) delete from dbo.uploads_availability where (FileName LIKE %itsitsearch% OR FileName LIKE %citsearch% ) 5. Run an import. What to do next You can either: Rescan the infrastructure 1. Rescan the computers in your infrastructure. 2. Upload new scan results. 3. Run an import. 4. Repeat the procedure for every computers. Tip: Avoid importing more than or scans within one License Metric Tool import. Such an import takes a few hours even on systems that meet the License Metric Tool hardware requirements. 5. Restart all fixlets. Restore scans in small chunks 1. Move a subset of the sha1 folders from the backup location to the original sha1 folder. The sha1 directory contains folder names that match the last 2 digits of the endpoint (computer) ID. The folder names can be used to identify a specific endpoint or endpoints from a specific scan group. The Presentation Debugger can be used to run session relevance queries to retrieve computer information. The following examples show queries that retrieve information for computers that are associated with the sha1 folder. Example 1: (id of it, hostname of it, name of it, ip addresses of it, operating system of it) of bes computers whose (id of it mod 100 = name_of_sha1_subdirectory_moved) returns the following when "name_of_sha1_subdirectory_moved" is replaced with "14": Query output: , nc tivlab.austin.ibm.com, nc , , Linux Red Hat Enterprise Server 6.4 ( el6.x86_64) Example 2: 14

21 (id of it, hostname of it, name of it, ip addresses of it, operating system of it) of bes computers whose ((id of it mod 100 = name_of_sha1_subdirectory_moved) or (id of it mod 100 = name_of_sha1_subdirectory_moved)) returns the following when "name_of_sha1_subdirectory_moved" is replaced with "14" and "5": Query output: , nc tivlab.austin.ibm.com, nc , , Linux Red Hat Enterprise Server 6.4 ( el6.x86_64) , nc tivlab.raleigh.ibm.com, NC038067, , Win Verify that new rows are created in the BFEnterprise tables after you copy the sha1 folders back to the original location. SQL Server: use BFEnterprise select * from dbo.uploads where (FileName LIKE %itsitsearch% OR FileName LIKE %citsearch% ) select * from dbo.uploads_availability where (FileName LIKE %itsitsearch% OR FileName LIKE %citsearch% ) DB2: connect to BFENT select * from dbo.uploads where (FileName LIKE %itsitsearch% OR FileName LIKE %citsearch% ) select * from dbo.uploads_availability where (FileName LIKE %itsitsearch% OR FileName LIKE %citsearch% ) IBM PVU considerations 3. Run the import to load endpoint data into License Metric Tool. 4. Move another subset of the sha1 folders from the backup location and run an import. Repeat the steps until all of the original sha1 folders are imported into License Metric Tool. 5. Restart all fixlets. 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 perspective, the License Metric Tool Regions must be applied requiring separate License Metric Tool deployments. For more information, see Virtualization Capacity License Counting Rules. Improving user interface performance If you experience problems with the performance of the user interface while working with reports, increase the number of rows that are loaded into the user interface. Adjust the number of rows to the size of your environment. About this task When you open a report, 50 rows of data are loaded to the user interface by default. When you scroll past those 50 rows, next 50 rows must be loaded. To improve the response time of the user interface, you can increase the number of rows that are loaded to the user interface. Procedure 1. Stop the License Metric Tool server. Scalability Guidelines 15

22 2. On the computer where the License Metric Tool server is installed go to the lmt_installation_dir\tema\work\tema\webapp\javascripts\report_components directory and open the grid.js file. 3. Find the following lines: $.widget("bigfix.grid", {options: {pagesize: 50, gridoptions: {} } 4. Increase the value of the pagesize parameter according to the size of your environment. Table 2. Number of rows loaded into License Metric Tool user interface Environment size Value of the pagesize parameter computers computers 1600 over computers Start the License Metric Tool server. 6. Clear the cache in the web browser. Using relays to increase the performance of IBM Endpoint Manager To take advantage of the speed and scalability that is offered by IBM Endpoint Manager, it is often necessary to tune the settings of the Endpoint Manager deployment. A relay is a client that is enhanced with a relay service. It performs all client actions to protect the host computer, and in addition, delivers content and software downloads to child clients and relays. Instead of requiring every networked computer to directly access the server, 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 server. Relays can connect to other relays as well, further increasing efficiency. Reducing the Endpoint Manager server load For all but the smallest Endpoint Manager deployments (< 500 Endpoint Manager clients), a primary Endpoint Manager relay should be set for each Endpoint Manager client even if they are not in a remote location. The reason for this is that the Endpoint Manager server performs many tasks including: v Gathering new Fixlet content from the Endpoint Manager server v Distributing new Fixlet content to the clients v Accepting and processing reports from the Endpoint Manager clients v Providing data for the Endpoint Manager consoles v Sending downloaded files (which can be large) to the Endpoint Manager client, and much more. By using Endpoint Manager relays, the burden of communicating directly with every client is effectively moved to a different computer (the Endpoint Manager relay computer), which frees the Endpoint Manager server to do other tasks. If the 16

23 relays are not used, you might observe that performance degrades significantly when an action with a download is sent to the Endpoint Manager server (you might even see errors). Setting up Endpoint Manager 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: v Allow the clients to auto-select their closest Endpoint Manager relay. v Manually configure the Endpoint Manager clients to use a specific relay. For more information, see Managing relays. Scalability Guidelines 17

24 18

25 Appendix. Executive summary Table 3. Summary of the scalability best practices Step Activities 1. Environment planning Review the summary information that matches your environment size: Small v v v Up to endpoints License Metric Tool and DB2 installed on the same server Scan groups (optional) Medium v endpoints v Scan groups (advisable) v License Metric Tool and DB2 installed on separate computers v It is possible to use virtual environments for this deployments size, however it is advisable to have dedicated resources for processor, memory, and virtual disk allocation. Large v v v v endpoints Scan groups (required) License Metric Tool and DB2 installed on separate computers, dedicated storage for DB2 Fine-tuning might be required 2 Good practices for creating scan groups v Plan the scan group size v Create a benchmark scan group v Check the import time and decide whether it is satisfactory v When you achieve an import time that is satisfactory, decide whether you want to have a shorter scan cycle. v When you are satisfied with the performance of the benchmark scan group, create the remaining groups. 3 Good practices for running scans, imports and uploads v Run the initial import before scanning the environment v Plan the scanning schedule v Avoid scanning when it is not needed v Limit the number of computer properties to the ones that are relevant for software inventory management v Ensure that scans and imports are scheduled to run at night v Configure regular imports. Daily imports are advisable. v Review import logs v Maintain frequent imports v Ensure that scans and imports are run at night v Run imports once a day v Configure upload schedule (daily) 4 End of cycle activities v Regularly import a new software catalog, for example monthly v Generate audit snapshot Copyright IBM Corp. 2002,

26 20

27 Notices This information was developed for products and services offered in the U.S.A. IBM may not offer the products, services, or features discussed in this document in other countries. Consult your local IBM representative for information on the products and services currently available in your area. Any reference to an IBM product, program, or service is not intended to state or imply that only that IBM product, program, or service may be used. Any functionally equivalent product, program, or service that does not infringe any IBM intellectual property right may be used instead. However, it is the user's responsibility to evaluate and verify the operation of any non-ibm product, program, or service. IBM may have patents or pending patent applications covering subject matter described in this document. The furnishing of this document does not grant you any license to these patents. You can send license inquiries, in writing, to: IBM Director of Licensing IBM Corporation North Castle Drive Armonk, NY U.S.A. For license inquiries regarding double-byte character set (DBCS) information, contact the IBM Intellectual Property Department in your country or send inquiries, in writing, to: Intellectual Property Licensing Legal and Intellectual Property Law IBM Japan, Ltd , Shimotsuruma, Yamato-shi Kanagawa Japan The following paragraph does not apply to the United Kingdom or any other country where such provisions are inconsistent with local law: INTERNATIONAL BUSINESS MACHINES CORPORATION PROVIDES THIS PUBLICATION AS IS WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF NON-INFRINGEMENT, MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Some states do not allow disclaimer of express or implied warranties in certain transactions, therefore, this statement may not apply to you. This information could include technical inaccuracies or typographical errors. Changes are periodically made to the information herein; these changes will be incorporated in new editions of the publication. IBM may make improvements and/or changes in the product(s) and/or the program(s) described in this publication at any time without notice. Any references in this information to non-ibm Web sites are provided for convenience only and do not in any manner serve as an endorsement of those Web sites. The materials at those Web sites are not part of the materials for this IBM product and use of those Web sites is at your own risk. Copyright IBM Corp. 2002,

28 IBM may use or distribute any of the information you supply in any way it believes appropriate without incurring any obligation to you. Licensees of this program who wish to have information about it for the purpose of enabling: (i) the exchange of information between independently created programs and other programs (including this one) and (ii) the mutual use of the information which has been exchanged, should contact: IBM Corporation 2Z4A/ Burnet Road Austin, TX U.S.A Such information may be available, subject to appropriate terms and conditions, including in some cases, payment of a fee. The licensed program described in this information and all licensed material available for it are provided by IBM under terms of the IBM Customer Agreement, IBM International Program License Agreement, or any equivalent agreement between us. Information concerning non-ibm products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products and cannot confirm the accuracy of performance, compatibility or any other claims related to non-ibm products. Questions on the capabilities of non-ibm products should be addressed to the suppliers of those products. This information contains examples of data and reports used in daily business operations. To illustrate them as completely as possible, the examples include the names of individuals, companies, brands, and products. All of these names are fictitious and any similarity to the names and addresses used by an actual business enterprise is entirely coincidental. Trademarks IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at Copyright and trademark information at Java and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle and/or its affiliates. Linux is a registered trademark of Linus Torvalds in the United States, other countries, or both. Microsoft, Windows, Windows NT, and the Windows logo are trademarks of Microsoft Corporation in the United States, other countries, or both. UNIX is a registered trademark of The Open Group in the United States and other countries. 22

29 Privacy policy considerations IBM Software products, including software as a service solutions, ( Software Offerings ) may use cookies or other technologies to collect product usage information, to help improve the end user experience, to tailor interactions with the end user or for other purposes. In many cases no personally identifiable information is collected by the Software Offerings. Some of our Software Offerings can help enable you to collect personally identifiable information. If this Software Offering uses cookies to collect personally identifiable information, specific information about this offering s use of cookies is set forth below. This Software Offering does not use cookies or other technologies to collect personally identifiable information. If the configurations deployed for this Software Offering provide you as customer the ability to collect personally identifiable information from end users via cookies and other technologies, you should seek your own legal advice about any laws applicable to such data collection, including any requirements for notice and consent. For more information about the use of various technologies, including cookies, for these purposes, See IBM s Privacy Policy at and IBM s Online Privacy Statement at the section entitled Cookies, Web Beacons and Other Technologies and the IBM Software Products and Software-as-a-Service Privacy Statement at Notices 23

30 24

31

32 Printed in USA