Integrated Analytics System 1.0.24.0 release notes (November 2020)

Version 1.0.24.0 introduces GPFS and RHEL upgrades, a number of new features and fixes.

Important:
  1. If you are on IAS 1.0.19.2 or lower, you must upgrade to IAS 1.0.19.7 before you can upgrade to IAS 1.0.2x.x.
  2. If you want to preserve SSL certificate files during upgrade, you must specify the old certificates by using SSL environment variables in the dashdb.env file. For more information, see Preserving old certificate files during upgrade.

What's new

GPFS
Upgraded to 5.0.5.2.
The value of the disableDIO parameter was set to no as per the recommendation for GPFS 5 upgrade. After you upgrade the system, you must change the value to yes. For more information, see Steps after upgrade.
RHEL
Upgraded to 7.8.
Call Home
  • Call Home text (CSP case log) now includes software versions for all major components.
  • Call Home notification emails include more details of an event or events, which generated the case. The General Information Classification Additional data and General system information sections are now included in the email.
  • Introduced enhancements to the CSP Case Subject and Description fields.

    The subject line of a Call Home case indicates specifics of the nature of the error/alert, which prompted the Call Home request to be generated. Additional information is displayed in the Subject line to distinguish between cases that were opened from related alerts.

Lift container
Removed lift container.
Backup and restore
After you restore a schema (or any of its tables) that is using the 1.0.22 or 1.0.23 version of db_restore from a schema-level backup that was taken with version v1.0.21, you must recreate the tables and reinsert their rows. Recreating the tables and reinserting their rows ensures that all the rows are included in subsequent backups if the schema was enabled for row modification tracking when it was backed up.
FSN battery replacement
Introduced a utility that must be installed and run to back up battery quorum before a battery replacement. The procedure must be done by an IBM service representative, only for battery replacements.
FIPS and SELinux
Added configure_fips.py and configure_selinux.py scripts. configure_fips.py manages the FIPS settings, and configure_selinux.pymanages the SE Linux settings. For more information see Enabling FIPS modes on IAS and Setting SELinux to Enforcing on IAS.

Components

Db2 Warehouse 11.5.5
Db2 Engine 11.5.5
The What's new information will be available on November 18th.

Known issues

GPFS
The value of the disableDIO parameter was set to no as per the recommendation for GPFS 5 upgrade. After you upgrade the system, you must change the value to yes. For more information, see Steps after upgrade.
apupgrade
mgtsw reports status UNKNOWN in ap issues -hw after you upgrade to 1.0.24.

WORKAROUND:

  • If --update-switches is not used, the workaround should not be necessary.
    Important: For IAS 1.0.24.0 it's recommended that you don't use --update-switches if possible.
  • If --update-switches is used, and the status of any of the switches is reported UNKNOWN in the web console, or when you run ap issues -hw after apupgradeis completed:
    1. Run this command for all switches listed:
      /opt/ibm/appliance/platform/xcat/scripts/security/known_hosts_cleaner.py switch [switch [switch] ...]
    2. If you completed step 1 and the patch panel configuration wasn't restored successfully, use the KVM console or SCP to connect to node0101 and run:
      /opt/ibm/appliance/platform/comms/tools/apnetApplySetup.py -t <switch_type>
      Where switch_type is either mgtsw or fabsw.
Failure to recover after SAN HW is physically removed
The system is in the down state. The reason might be because:
  1. The external SAN is physically disconnected, removed, or lost/failed.
  2. There are stale connections to the failed SAN filesystem.
  3. When attempting to manually remove the SAN filesystem by using storage_setup -d san, the command fails because SAN is disconnected.
When you review the HA logs and find df: ‘/external_mnt/SAN’: Stale file handle, contact IBM Support. IBM Support might reference this document.
AFM-DR
  1. AFM-DR replication is down after upgrading to 1.0.24.0.

    Run apdr status --replqueue to confirm whether the filesets are in the Down state or not.

    WORKAROUND:

    If the head node on the primary system is rebooted, follow this steps to bring filesets to the Active state. If filesets remain Inactive and or Down, subsequent snapshots are going to fail.

    1. As the apuser, determine which filesets are inactive after the GPFS recovery:
    apdr status --replqueue
    Example:
    [apuser@node0101 ~]$ apdr status --replqueue
    Directory                                                         Queue Status        Sync Status
    /opt/ibm/appliance/storage/head/home/db2inst1/db2/keystore        Down                    Unknown
    /opt/ibm/appliance/storage/data/db2inst1                          Ready                   In-Sync
    /opt/ibm/appliance/storage/local/db2inst1                         Ready                   In-Sync
    /opt/ibm/appliance/storage/scratch/db2archive                     Down                    Unknown
    /opt/ibm/appliance/storage/head/db2_config                        Down                    Unknown
    2. Touch a file in the directories that are Down in step 1:
    cd /opt/ibm/appliance/storage/scratch
    touch abc.txt
    Example:
    [apuser@node0101 ~]$ cd /opt/ibm/appliance/storage/scratch
    [apuser@node0101 scratch]$ touch abc.txt
    Repeat step 2 for all the filesets that are showing as Down.
    Note: For the head partition, you need to touch the file as the root user.
    3. Verify that all filesets are back to Active:
    apdr status --replqueue
    Example:
    [apuser@node0101 ~]$ apdr status --replqueue
    Directory                                                         Queue Status        Sync Status
    /opt/ibm/appliance/storage/head/home/db2inst1/db2/keystore        Ready                    In-Sync
    /opt/ibm/appliance/storage/data/db2inst1                          Ready                   In-Sync
    /opt/ibm/appliance/storage/local/db2inst1                         Ready                   In-Sync
    /opt/ibm/appliance/storage/scratch/db2archive                     Ready                    In-Sync
    /opt/ibm/appliance/storage/head/db2_config                        Ready                    In-Sync
Migration tools
  1. db_size

    db_size is failing to calculate BLUDB, SUM (SCHEMA), OTHER METADATA/CACHE/CONFIG FILES size while running from the client container.

  2. db_migrate_iias

    db_migrate_iias fails when you run it as the AD user from inside the container.

Data Replication for Availability
  1. Replication of external tables (files)

    Replication of external tables (files) is not supported. External tables display in the console as tables that you can add to a replication set and have an N value in the Viable key column, but you should not select these tables. If you do select an external table, the console shows error ASN7527I after the set finishes configuring and you must manually start the set."

  2. SSL certificates

    After you upgrade your Db2 source or target databases, you must take steps to ensure that the correct Secure Sockets Layer (SSL) certificates are in place at the source and target databases and that the trust target certificate process is run. For more information, see this link.

Growth on Demand
  1. To set up the Grow on Demand feature for IAS, contact IBM Support. IBM Support might reference this document.
  2. The apgodmgr --set command returns permission denied error.
    Traceback (most recent call last):
      File "/usr/bin/apgodmgr", line 255, in <module>
        main()
      File "/usr/bin/apgodmgr", line 245, in main
        rc = set_params(args.set, unknown_args)
      File "/usr/bin/apgodmgr", line 154, in set_params
        transfer_file(node, GODFILE)
      File "/usr/bin/apgodmgr", line 104, in transfer_file
        sftp_client.put(filename, filename)
      File "/usr/lib/python2.7/site-packages/paramiko/sftp_client.py", line 676, in put
        return self.putfo(fl, remotepath, file_size, callback, confirm)
      File "/usr/lib/python2.7/site-packages/paramiko/sftp_client.py", line 634, in putfo
        with self.file(remotepath, 'wb') as fr:
      File "/usr/lib/python2.7/site-packages/paramiko/sftp_client.py", line 327, in open
        t, msg = self._request(CMD_OPEN, filename, imode, attrblock)
      File "/usr/lib/python2.7/site-packages/paramiko/sftp_client.py", line 730, in _request
        return self._read_response(num)
      File "/usr/lib/python2.7/site-packages/paramiko/sftp_client.py", line 781, in _read_response
        self._convert_status(msg)
      File "/usr/lib/python2.7/site-packages/paramiko/sftp_client.py", line 809, in _convert_status
        raise IOError(errno.EACCES, text)
    IOError: [Errno 13] Permission denied
    To resolve the issue, contact IBM Support. IBM Support might reference this document.
Schema backup images taken on IAS 1.0.24 and Db2 Warehouse might contain inaccurate data for tables that contain the BINARY or VARBINARY data types. All other tables are backed up normally.
Backup image of -type ONL on IAS 1.0.24 captures data for tables that contain the BINARY or VARBINARY data types as of timestamp when an individual table is processed by the backup operation. All other tables are captured as of timestamp when the db_backup command is issued.
If no concurrent workload was running while db_backup was in progress, the backup image is consistent.
If there was a concurrent write access activity into that table during backup, the image might not be consistent. A restore of the -type ONL backup image might not produce affected table data that is consistent with other tables. A restore of the -type INC or -type DEL backup image restores data for the affected table multiple times. As a result, the affected table data is incorrect.
To find out if any tables have BINARY or VARBINARY columns, run:
select TABSCHEMA, TABNAME from syscat.columns C, syscat.schemata S where
     S.ROWMODIFICATIONTRACKING='Y' and
     C.TABSCHEMA = S.SCHEMANAME    and
    (C.TYPENAME='BINARY' or C.TYPENAME='VARBINARY')
group by (C.TABSCHEMA, C.TABNAME)
If any table is affected, contact IBM Support.