Page tree

This section describes the new features and enhancements that have been introduced in the release of BMC Atrium Discovery version 10.2.

If you are new to BMC Atrium Discovery, BMC recommends that you refer to Getting started as an introduction to using the product.

You can only upgrade to 10.2 from 10.1. The upgrade procedure is described in Upgrading BMC Atrium Discovery.

No architecture changes required

No architecture changes required

When upgrading from 9.x to 10.1 and from there to 10.2 there is no need to change your deployment architecture. Rather, BMC strongly recommend that you upgrade using your existing architecture and test version 10.x in a known configuration. If testing reveals that you require the performance improvements offered by a cluster, you can then add hardware and replace one or more version 10.x machines with a cluster.

 

Updated SSH server

The SSH server installed on the BMC Atrium Discovery 10.2 appliance has been modified. This modification removes some weak ciphers and HMAC algorithms (and non-FIPS approved) from the list of allowed connections. In practice this should not affect most users, however, some older versions of ssh clients will be unable to connect.

The following versions, or later, of the following clients have been tested and are known to work:

  • PuTTY (0.64)
  • WinSCP (5.7.2)
  • mRemoteNG (1.72 using ssh2)
  • MobaXterm (6.5)
  • KiTTY (0.63.2.2)
  • Bitvise SSH Client (6.22)

What's new in BMC Atrium Discovery version 10.2?

This section describes the new features and enhancements that have been introduced in the release of BMC Atrium Discovery version 10.2.

This release of BMC Atrium Discovery is scheduled for release in May 2015.

CMDB Synchronization improvements

In previous releases, at each synchronization, BMC Atrium Discovery had to query the CMDB to determine the current state, and this was where most of the time was spent in synchronization. From this release BMC Atrium Discovery maintains an authoritative model of its view of the world in the datastore, the shadow copy. From there it is quicker and simpler to determine the changes that need to be sent to the CMDB. Typically data centers do not change very much between scans, so it is just these changes that are sent to CMDB, and this can be done very quickly.

Occasionally the model stored in the CMDB dataset becomes out of step with the shadow copy for a CMDB connection and require resynchronization. For example, if CMDB tools have been used to modify the dataset. A tool is provided in the UI which resynchronizes the CMDB with BMC Atrium Discovery.

The CMDB sync feature now supports connections to multiple CMDBs.

The filtering UIs have been improved to make them more intuitive, and you can preview the synchronization results for a set of items using CMDB Sync Preview.

A command line tool, tw_sync_control, is provided so that synchronization operations can be scripted.

Blade enclosure discovery

This release supports the discovery of blade enclosures and relating enclosures to contained blades. The blade chassis is modeled as a Host Container node and the blades are modeled as Host nodes.

At the time of the release of BMC Atrium Discovery 10.2, we support:

  • Cisco UCS
  • Dell M1000e
  • HP BladeSystem c7000
  • IBM BladeCenter
  • Sun Blade 6000 system

Management controller discovery

In addition to that already mentioned in blade enclosure discovery, this release introduces support for management controller discovery. These are modeled as Management Controller nodes.

At the time of the release of BMC Atrium Discovery 10.2, we support:

  • Dell DRACs
  • Dell CMC
  • HP iLO
  • IBM RSA
  • SUN ILOM and Oracle (Sun) ILOMs
  • Cisco IMC

A new credential type for the XML API, is provided to discover some management controllers. At the time of release, HP iLO and Cisco IMC are discovered using this credential type.

The HP Integrity iLO devices are not discovered at the time of release.

Host/Storage linking

In this release we have made improvements in linking hosts to the storage that they are actually using on storage arrays or local disks.

Local drives

Where a host has a file system on a local disks we now link the FileSystem to the DiskDrive. On Linux hosts, BMC Atrium Discovery expands the logical volume managers and/or software RAID configuration to find the actual physical drives and link the DiskDrive nodes representing them to the FileSystem. In this way a single FileSystem can be linked to multiple physical disks. The software RAID configuration is not modeled. Physical drives in these cases means physical or virtual (for a VM) rather than logical volumes.

Linux can mount drives using UUIDs, these can now be linked to the physical disk drives.

The DiskDrive nodes are also linked to the Host node to cater for disks without file systems.

Storage

For storage arrays we now link FileSystems to the StorageVolume (LUN) which provides the storage. On Linux we support multipath as well as simple (single path) access. We also link the StorageVolume nodes to the Host. This enables you to identify LUNs which the host can use but is not currently using. This may be misconfiguration, or an opportunity for expansion.

VMware ESX

VMware ESX data stores (modeled as file systems in BMC Atrium Discovery) have been discovered in previous releases, they are now linked to the storage volumes on which they consume storage, or the local DiskDrive. This uses the vSphere API so is not supported though ssh discovery of older ESX hosts.

On Linux VMs, Raw Disk Maps appear as a SAN LUN.

Storage mounted as a SCSI LUN is now linked. This enables you to see all storage volumes that the host has mounted, even if they are unused and there is no file system. It provides information on the volume itself, for example the visible capacity.

SAN Switch discovery

Discovery of SAN switches is now supported for Brocade and Cisco. The basic SNMP identification of SAN switches is available to all customers. For customers with the Storage TKU, retrieval of Fibre Channel Ports information is supported.

Miscellaneous

The following miscellaneous features have been added:

Changes in the Extended RDB adapter mapping set

In the Extended RDB adapter mapping set, the following fields are no longer exported with the Network Interface CI information by default: 

  • interface_name
  • interface_speed
  • interface_duplex
  • interface_negotiation

To export the mentioned details, you could customize the Extended RDB adapter mapping set by uploading these host.xml and networkinterface.xml files. For more information on customizing a mapping set, see Managing mapping sets.

When importing data to the external database, you need to modify the default database scripts used for initial configuration on the RDB side to match the introduced changes in the export schema. You can download a sample customized scripts for Oracle, MySQL, and for SQLServer: SQLServer.sql and SQLServer.osql.

New TPL function

A new TPL function binary.toValue has been added which enables you to convert a given binary value into a specified format. The binary value is typically a value retrieved via SNMP using the binary settings on discovery.snmpGet or discovery.snmpGetTable.

 

  • No labels