IBM BigFix Lifecycle 9.5

Transcription

1 Software Product Compatibility Reports Product IBM BigFix Lifecycle 9.5

2 Contents Included in this report Operating systems (Section intentionally removed by the report author) Hypervisors (Section intentionally removed by the report author) Prerequisites (Section intentionally removed by the report author) Supported software (Section intentionally removed by the report author) Hardware Packaging list (No packaging list specified for this product) Glossary Disclaimers Report data as of :20:10 EDT 1

3 Included in this report This report can be generated with filters applied to operating system platforms, components, and/or software capabilities. This section reflects how the report was filtered when it was generated. Legend The information about this item is included in this report. The information about this item is not included in the report filter. Platforms Component list Capabilities AIX Linux Mac OS Solaris Windows BigFix Console BigFix Remote Control Agent or client BigFix Relay BigFix Software Distribution / Agent OS Deployment Power Mgmt Remote Control Broker Remote Control Gateway Remote Control Target/CLI Prerequisites Databases Related Software LDAP s Virtualization Management Web Browsers Report data as of :20:10 EDT 2

4 Hardware IBM BigFix Lifecycle 9.5 requires the following hardware, organized by type of hardware, deployment units, or components. Installable software Operating System Families Windows Windows Disk Space BigFix Console IBM BigFix Console Capacity Planning Recommendations All supported Windows operating systems IBM BigFix Consoles are typically installed on personal workstations and Terminal or Citrix s. For complete details, please see: ismlibrary?navcode=1tw10ep0h Users with high-speed network connections (10 mbps+) to the IBM BigFix database can use any computer that meets the requirements below. Remote users will typically need to use a Terminal or Citrix because their network connection is too slow. The hardware requirements are based on the number of managed computers, which is the number of computers that a IBM BigFix Console Operator will see in their IBM BigFix Console. In most deployments, a IBM BigFix Console Operator Report data as of :20:10 EDT 3

5 will see a subset of the total number of computers while a Master IBM BigFix Console Operator will see all of the computers. Workstation Installations Deployment Size CPU Memory (GB) Storage (GB) < 10, < 100, > 100, > 200, The following network configurations are recommended: TCP and UDP must be completely unblocked at all internal routers and internal firewalls on port The firewalls should allow bidirectional traffic. BigFix BigFix Management Capacity Planning Recommendations For complete details, please see: ismlibrary?navcode=1tw10ep0h The following table describes the BigFix management serverâ##s capacity planning recommendations as a function of the scale of the â##managed toâ## estate. The recommendations are for a collocated server configuration. Finer grained, non-collocated recommendations will be provided in a future update of this paper. Note the storage requirements for IBM BigFix are typically quite low. However, suitable storage is recommended to accommodate the growing database size and associated management overhead (e.g. a working set of database backups). The BigFix application directory also contains a download cache which defaults to 1GB. We recommend increasing this cache size to somewhere between 100GB and 1TB (or higher) depending on needs. The storage requirements below should be increased to account for the desired cache size. Network requirements are for a 1 Gbps network or better for the management server infrastructure. Additional requirements based on BigFix function enablement are also provided. All supported Windows operating systems Report data as of :20:10 EDT 4

6 Deployment Size CPU Memory (GB) Storage (GB) < ,000-10, ,000-50,000 50, , , , , , , , Note: The Hard Disk configurations listed above are focused on providing high performance disks for the database and IBM BigFix. RAID arrays must support using the disk cache for both reading and writing. The disk cache should be set to 50/50 read write. Memory BigFix BigFix Management Capacity Planning Recommendations For complete details, please see: ismlibrary?navcode=1tw10ep0h The following table describes the BigFix management serverâ##s capacity planning recommendations as a function of the scale of the â##managed toâ## estate. The recommendations are for a collocated server configuration. Finer grained, non-collocated recommendations will be provided in a future update of this paper. All supported Windows operating systems Note the storage requirements for IBM BigFix are typically quite low. However, suitable storage is recommended to accommodate the growing database size and associated management overhead (e.g. a working set of database backups). The BigFix application directory also contains a download cache which defaults to 1GB. We recommend increasing this cache size to somewhere between 100GB and 1TB (or higher) depending on needs. The storage requirements below should be increased to account for the desired cache size. Report data as of :20:10 EDT 5

7 Network requirements are for a 1 Gbps network or better for the management server infrastructure. Additional requirements based on BigFix function enablement are also provided. Deployment Size CPU Memory (GB) Storage (GB) < ,000-10, ,000-50,000 50, , , , , , BigFix Console 200, , Note: The Hard Disk configurations listed above are focused on providing high performance disks for the database and IBM BigFix. RAID arrays must support using the disk cache for both reading and writing. The disk cache should be set to 50/50 read write. IBM BigFix Console Capacity Planning Recommendations All supported Windows operating systems IBM BigFix Consoles are typically installed on personal workstations and Terminal or Citrix s. For complete details, please see: ismlibrary?navcode=1tw10ep0h Users with high-speed network connections (10 mbps+) to the IBM BigFix database can use any computer that meets the requirements below. Remote users will typically need to use a Terminal or Citrix because their network connection is too slow. Report data as of :20:10 EDT 6

8 The hardware requirements are based on the number of managed computers, which is the number of computers that a IBM BigFix Console Operator will see in their IBM BigFix Console. In most deployments, a IBM BigFix Console Operator will see a subset of the total number of computers while a Master IBM BigFix Console Operator will see all of the computers. Workstation Installations Deployment Size CPU Memory (GB) Storage (GB) < 10, < 100, > 100, > 200, The following network configurations are recommended: TCP and UDP must be completely unblocked at all internal routers and internal firewalls on port The firewalls should allow bidirectional traffic. Other Hardware BigFix Console Terminal/Citrix Installations All supported Windows operating systems The following table shows capacity planning requirements for a terminal or Citrix server based implementation. The expectation is data center level network speeds are available for the server, and each server may be managing on the order of concurrent users (remote users, meaning they may not reside in the data center). In the event a greater number of concurrent users are in effect, the general rule of thumb is to add on the order of 1 CPU and 2-6 GB of RAM for every additional concurrent user (RAM is dependent on the deployment size). As always, requirements are workload dependent so monitoring of the system under load is always recommended. As a result, ranges are given where appropriate with the expectation that monitoring may be used to fine tune in the customer environment. Deployment Size CPU Memory (GB) Storage (GB) < 10, < 100, > 100, The question often arises how many console operators may be supported by BigFix. A primary selling feature of BigFix is the ability of a small number of operators to manage a large estate. Report data as of :20:10 EDT 7

9 However, in the event that fine grained management is required, a base of 300 operators may be managed with careful attention to the console infrastructure. Proceeding beyond this value would require understanding of the infrastructure and associated workload impact. Important Note: For larger deployments that expect over 50,000 IBM BigFix Agents OR over 50 IBM BigFix Console operators, consult a IBM BigFix deployment specialist for specific recommendations on Terminal/Citrix configurations BigFix The following table describes additional capacity planning requirements based on enablement of specific BigFix function, broken down by platform where necessary. Notes on the specific functions are provided. For complete details, please see: ismlibrary?navcode=1tw10ep0h Function Enabled Platform Additional CPU Additional Memory (GB) All supported Windows operating systems Message Level Encryption BigFix WebUI ETL All All BigFix WebUI Windows +6/10 Concurrent Users +4/10 Concurrent Users BigFix WebUI Linux +3/10 Concurrent Users +2/10 Concurrent Users Message Level Encryption (MLE) provides data encryption support for clients, and is particularly valuable for insecure networks or when secure communication in general is required. It is worth noting MLE does not affect actions taken from the console or fixlets that are already protected by digital signatures. More information on MLE is provided in the References section. The BigFix WebUI offers a new scalable and highly responsive management interface for BigFix. As part of the implementation, an Extract-Transform- Load (ETL) infrastructure must be enabled. This function, once enabled, has the above server requirements. The BigFix WebUI in general, once enabled, will drive additional system utilization as a function of the number of concurrent administrators (as described earlier, this is the population of Report data as of :20:10 EDT 8

10 administrators active at any one time, and the number of concurrent administrators is typically >> the total number of administrators). In terms of the scalability characteristics of the WebUI, the initial release is targeted at the activities of non-master operators (versus the broader administrative role of master operators). A realistic upper bound for the initial release of the WebUI would be management by 30 concurrent users on Windows, and 60 concurrent users on Linux, over an estate of 60k devices. The concurrent users would typically be non-master operators, managing a subset of the estate. For example, some nonmaster operators may only be managing a handful of devices, while others may be managing on the order of 20k devices. It is possible to manage at a larger scale based on user operations, infrastructure capability, etc. However, the stated bounds should be considered a good "rule of thumb" for the scale of the solution. Report data as of :20:10 EDT 9

11 Glossary Bitness Compatibility of the product with the bit version support that is provided by an operating system. Different parts of a product might run on the same operating system but support different application bitness. For example, one part of the product might run only in 32-bit mode, whereas another might support 64-bit tolerate mode. 31: The product or part of the product runs as a 31-bit application in a 31-bit operating environment. 32: The product or part of the product runs as a 32-bit application in a 32-bit operating environment. 64-tolerate: The product or part of the product runs as a 32-bit application in a 64-bit operating environment. 64-exploit: The product or part of the product runs natively as a 64-bit application in a 64-bit operating environment. Co-packaged Additional products that are included in the product package. Co-installed Additional products that are included in the product package and installed when the product is installed. Deployment unit Deployment Structure identifies pieces of a product that can be independently deployed onto one or more machines in a distributed infrastructure. The top level of the deployment structure consists of one or more deployment units. There are four possible deployment units that a product might support: Desktop,, Agent or client, Mobile. Deployment units may be further divided into deployable components Desktop deployment unit: Part of the deployment structure intended for use by a single user, typically installed on the user desktops. Examples of desktop deployment units include development tools, administrative tools, stand-alone business applications. deployment unit: Part of the deployment structure that can provide services to multiple clients, providing the server in a client-server architecture. Examples of server deployment units include application servers, management servers, database servers and server-based business applications. Agent or client deployment unit: Part of the deployment structure that allows remote connection between software. Examples of agent of client deployment Report data as of :20:10 EDT 10

12 units include agents in management system that are installed in the same tier as the managed resources, a remote application, or database clients that are installed with the software accessing the remote services. Mobile deployment unit: Part of the deployment structure intended for use by a single user, typically installed on a mobile device. An example of a mobile deployment unit is a mobile application. Hypervisor A virtual machine in which a product can run on a guest operating system. Limited operating system support By default, the supported guest for a product and a hypervisor are the that are supported by both the product and the hypervisor. If a product restricts support to a subset of these, this restriction will be indicated by specifying that there is Limited Operating System Support. Operating system minimum The minimum operating system maintenance level that is required to run on the product. Prerequisite minimum The minimum maintenance level that is required for the prerequisite to work with the product. Product minimum The minimum maintenance level that is required for the product to run on the operating system, on an hypervisor, or work with a prerequisite product or supported software. Supported software minimum The minimum maintenance level that is required for the supported software to work with the product. Long Term Support Release A Long Term Support Release is a recommended product level for which support, including defect and security updates, will be provided over a specified period of time. Continuous Delivery Product Continuous Delivery Product - Long Term Support Release A Continuous Delivery Product delivers new function to clients more frequently. A Continuous Delivery Product delivers new function to clients more frequently. Since frequent releases may not be suitable for all client environments, Long Term Support Releases provide a package that will be supported for a longer period of time. Report data as of :20:10 EDT 11

13 Disclaimers This report is subject to the Terms of Use ( and the following disclaimers: The information contained in this report is provided for informational purposes only. While efforts were made to verify the completeness and accuracy of the information contained in this publication, it is provided AS IS without warranty of any kind, express or implied, including but not limited to the implied warranties of merchantability, non-infringement, and fitness for a particular purpose. In addition, this information is based on IBM s current product plans and strategy, which are subject to change by IBM without notice. IBM shall not be responsible for any direct, indirect, incidental, consequential, special or other damages arising out of the use of, or otherwise related to, this report or any other materials. Nothing contained in this publication is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in this report to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in this presentation may change at any time at IBM s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. The underlying database used to support these reports is refreshed on a weekly basis. Discrepancies found between reports generated using this web tool and other IBM documentation sources may or may not be attributed to different publish and refresh cycles for this tool and other sources. Nothing contained in this report is intended to, nor shall have the effect of, stating or implying that any activities undertaken by you will result in any specific sales, revenue growth, savings or other results. You assume sole responsibility for any results you obtain or decisions you make as a result of this report. Notwithstanding the Terms of Use ( users of this site are permitted to copy and save the reports generated from this tool for such users own internal business purpose. No other use shall be permitted. Report data as of :20:10 EDT 12