Avaya Aura System Platform R6.2 Release Notes

Transcription

Avaya Aura® System Platform R6.2 Release Notes
Issue 1.3
June 2012
INTRODUCTION
This document introduces the Avaya Aura® System Platform Release 6.2 and describes
known issues and the issues resolved in this release.
WHAT’S NEW IN SYSTEM PLATFORM 6.2
•
Enhanced High Availability
System Platform supports multiple modes of high availability operation, facilitating
efficient failover from a primary node to a secondary node with little or no interruption in
system services.
The modes are:
• Fast Reboot High Availability (FRHA)
• Machine Preserving High Availability (MPHA)
• Live Migration High Availability (LMHA, used only with MPHA)
System Platform FRHA mode was available prior to System Platform version 6.2. The
two new HA modes (MPHA/LMHA) implement a new Virtual Server Synchronization
Technology (VSST) offering on System Platform.
Note: Your Avaya Aura® solution template must specifically support MPHA mode
for it to be configurable in pages of the System Platform Management Console.
•
SAL deployment on Services Virtual Machine
Beginning with System Platform release 6.2, the Secure Access Link Gateway (SAL
gateway) no longer runs on the System Platform Console Domain (CDOM) virtual
machine. Instead, SAL 2.1 (upgraded from SAL 1.8) runs on an independent Services
Virtual Machine (services_vm domain) on your Avaya Aura® solution server. As with
the prior implementation of the SAL gateway running on the CDOM virtual machine, this
new configuration supports secure remote access to local server resources, and
forwards alarms (SNMPv2 traps) from your local solution server to a remote Network
Management System (NMS).
As a result of the Services Virtual Machine, the System Platform first boot interval has
decreased.
System Platform R6.2
June 2012
1
•
Kernel and RPM patching and rollback
Using Patch Management features of the Management Console, you can install,
commit, roll back (undo), or remove kernel patches applied to the System Platform, or
RPM patches applied to either the System Platform or to an installed Avaya Aura®
solution template. The manual rollback feature allows you to test a patch before
committing it to the system. The automatic rollback feature enables the system to
autonomously recover from problems resulting from patch installation, or from an
administrative lockout after installing a patch remotely over the Secure Access Link.
•
System Platform R6.2.0.2.27 Service Pack
The service pack resolves an issue with System Platform 6.2 where a new version of a
template has a decreased number of VMs and the plugin artifacts associated with the
VM are not cleaned up during an upgrade. This may cause issues with the backup
feature from the backup/restore page. This System Platform service pack need only be
applied to the Solution for Midsize Enterprise or for an approved template prior to
upgrading from 6.2.0.0.27 to a future service pack 6.2.X.
June 2012
2
SOFTWARE RELEASE VERSIONS
Application
Avaya Aura® System Platform R1.1
Avaya Aura® System Platform R1.1.1
Avaya Aura® System Platform R1.1.1.4.2
File Name
vsp-1.1.0.0.10.iso
vsp-1.1.1.0.2.iso
vsp-patch-1.1.1.4.2.noarch.rpm
vsp-6.0.0.0.11.iso
vsp-patch-6.0.0.1.11.nonarch.rpm
vsp-6.0.1.0.5.iso
vsp-6.0.2.0.5.iso
vsp-6.0.3.0.3.iso
vsp-6.2.0.0.27.iso
June 2012
3
Release History:
Date
August 2009
November 2009
February 2010
February 2010
April 2010
June 2010
June 2010
August 2010
August 2010
August 2010
November 2010
November 2010
November 2010
February 2011
February 2011
April 2011
August 2011
September 2011
December 2011
March 2012
April 2012
Build
1.0.0.1.12
1.1.0.0.10
1.1.1.0.2
1.1.1.4.2
1.1.1.7.2
1.1.1.9.2
6.0.0.0.11
6.0.0.1.11
6.0.1.0.5
1.1.1.93.2
1.1.1.94.2
6.0.2.0.5
6.0.2.1.5
6.0.2.3.5
6.0.3.0.3
6.0.3.1.3
6.0.3.3.3
6.0.3.4.3
6.0.3.6.3
6.2.0.0.27
6.2.0.2.27
Change(s)
Controlled Introduction R1.0
General Availability R1.1
Service Pack R1.1.1
Service Pack Patch R1.1.1.4.2
Service Pack R1.1.1.7.2
Patch R6.0.0.1.11
Service Pack Patch 6.0.3.1.3
Service Pack 6.2.0.2.27
June 2012
4
Upgrades
Upgrades to R6.2 are supported from R6.0.3.0.3 + patch (6.0.3.1.3 is the minimum patch
from which upgrade to R6.2 is supported), but Avaya recommends you use the latest
approved patch for your Template. Please refer to the Template documentation for the
correct patch to apply to your system:
https://support.avaya.com/css/P8/documents/100135000).
Resolved Issues and Enhancements
1.
System Platform OS security increased in response to notification of certain rpm
vulnerabilities. The appropriate rpms have been removed from the system.
2.
Improved security via stricter file permissions has been implemented.
3.
The Tomcat version is now hidden for increased system security.
4.
The option to view installed Enterprise LDAP Certificate has been added.
5.
Full password rules are now displayed if a password that does not meet the rules is
entered for the LDAP password.
6.
User account administration changes within high availability are now immediately
copied to the standby.
7.
Fixed an issue regarding the removal of an Ethernet cable from ‘eth0’ that would stop
traffic between machines on ‘avpublic’.
8.
Removed an unnecessary dummy clock entry in the ‘ntpd.conf’ and improved the
hardware clock setting.
9.
Resolved an issue where the System Platform firewall was not updated on a DNS or
subnet change on the IP network configuration page.
10. Resolved the issue where the default netmask could not be larger than 24 bits.
June 2012
5
Known Issues and Workarounds
1.
Applying System Platform patches on High Availability (HA) failover systems.
Unless the release notes for a patch specify otherwise, apply the patch on both
machines if the patch includes a Domain-0 patch. Always check the patch release
notes for the detailed information on how to apply the patch on HA systems. On a HA
failover system, stop HA and remove the HA configuration before applying the
patch and apply it on the System Platform Management Consoles of both the
primary and secondary nodes.
For any operation that requires HA to be stopped (platform upgrade, template upgrade
and patch application), the stop HA should be followed by the removal of the HA
configuration. The user may then configure and start HA after the operation is
completed.
Failure to remove HA before performing a platform upgrade could lead to an incorrect
configuration of the system and the inability to start HA. This condition could lead to
the necessity of re-installing System Platform on the affected systems.
2.
In a HA configuration, any hardware maintenance (e.g. replacing hard disks or
power modules) must be conducted on the standby server after it is powered
down.
If the current active server needs hardware maintenance, perform an interchange to
make it a standby server and then perform the maintenance operation after the server
is powered down.
If this guide line is not followed, it is possible that the HA system may not work as
desired once the hardware is replaced.
3.
Changing the system time zone via the Management Console ‘Date / Time’
configuration page requires a reboot.
If the system time zone is changed, reboot the system. If the time is changed or NTP
is turned on after setting the time zone, the system will reboot automatically. To only
change the time zone, ensure the server is rebooted via the ‘Server Reboot/Shutdown’
Management Console page. Failure to reboot the system will cause some processes
not to pick up the new time zone.
4.
Configure the System Platform internal network ‘avprivate’ before template
installation.
Before installing a template, check the ‘Network Configuration’ page on the System
Platform Management Console (select ‘Server Management’ | ‘Network
Configuration’) to view the addresses allocated on the bridge named ‘avprivate’.
System Platform creates an internal, private bridge that allows virtual machines to
communicate with each other. This private bridge does not have any connection to
the user’s LAN. During installation, System Platform runs an algorithm to find a set of
IP addresses that do not conflict with the addresses configured on the ‘System
June 2012
6
Domain Network Configuration’ screen. However, it is still possible that the addresses
selected will conflict with other addresses in the network. Since this private bridge is
not connected to the user’s LAN, this address conflict could result in the failure of
System Platform or an installed template to route packets correctly. The internal
routing tables might not differentiate between the private bridge and the user’s LAN,
causing an application to direct packets to some host on the user’s LAN rather than to
another application within the System Platform server that has that same IP address
on the private bridge.
If the IP address for Domain-0’s interface on ‘avprivate’ is changed (which appears in
the bridge section of the ‘Network Configuration’ page) or for CDOM’s interface on
‘avprivate’ (which appears under CDOM in the Group by Domain section), the
addresses must be consecutive with Domain-0’s address 1 less than CDOM’s (i.e., if
CDOM’s IP address for its interface on ‘avprivate’ is 172.20.30.5, then Domain-0’s
must be 172.20.30.4). Also, the netmask for Domain-0’s interface on avprivate must
be the same as the netmask for CDOM’s interface on ‘avprivate’ (i.e., if one is
changed, the other must change).
In the event that there is a conflict in the network with the private IP address range,
some functions may fail to work properly in System Platform and the installed
template. For example, the System Platform Management Console may be
inaccessible from a system that has an IP address in conflict with the private address
range.
Another example includes an IP phone that registers with Communication Manager
with the same IP address as Domain-0’s or CDOM’s address on ‘avprivate’. Packets
targeted for the phone might actually instead go to Domain-0 or CDOM.
5.
Changing the password for the first time while logged into WebLM causes
Tomcat catalina.out to error and lists exceptions.
This issue resides in WebLM standalone releases (all releases up to 4.5.5). The issue
does not impact WebLM functionality.
6.
The CDOM fully qualified hostname in /etc/hosts is not correct after being
renamed from the Management Console.
If a user renames the CDOM hostname using an extension of the old hostname, the
CDOM hostname in /etc/hosts hosts file will be misconfigured as shown in the
following example:
Old hostname: hostname.example.com
New hostname: hostname-2.example.com
Resulting misconfigured new fully qualified hostname in the /etc/hosts file:
hostname-2-2.example.com
When changing the CDOM hostname, do not use an extension of the existing
hostname.
June 2012
7
7.
System Platform Management Console will not be accessible if the Domain-0
disk becomes full.
Domain-0 should not be used for file storage. System Platform will rotate log files and
remove old tmp files to ensure files and directories are prevented from growing larger
than their allowed sizes. However, directly loading large files unrelated to System
Platform onto Domain-0 could fill the hard drive and result in system issues.
8.
Internet Explorer (IE) may not load pages when accessing the Management
Console.
When accessing the Management Console page, IE (versions 7, 8 or 9) may display
the following error: “Internet Explorer cannot display the webapp”, or it may stay within
the current page instead of navigating to the selected page. This happens when a
page cannot respond to IE within 30 seconds. The problem has been observed on
some template installation/upgrade pages, on the ‘High Availability Configuration’
page and on the ‘Network Configuration’ page. If IE is your preferred browser,
consider applying the proposed solutions form the Microsoft Knowledge Base 181050
(http://support.microsoft.com/kb/181050).
9.
Upgrading from System Platform 6.0 requires the installation of the pre-upgrade
patch 6.0.3.X.3 (this patch 6.0.3.X.3 needs to be applied on 6.0.3.0.3 build or
higher).
If presented with a blank table when upgrading from 6.0 to 6.2, install the latest
6.0.3.X.3 patch.
10. Do not use the media check on an HP DL360 G7, the installation will hang.
If this occurs, reboot the server and proceed with the installation without performing
the media check.
11. System Platform upgrades using a USB device are not supported on a HP
DL360G7.
When used for System Platform upgrades, USB drives cause boot problems on the
HP DL360G7. USB devices may be used for template upgrades although the USB
drive must not be attached when the System Platform upgrade is performed.
12. Depending on the BIOS version, it is possible to receive “Invalid checksum”
errors during ACPI processing at boot time.
These errors occur when the ACPI tables in the BIOS contain incorrect checksums.
BIOS vendors often only test their BIOS on Windows. Windows is more lenient with
ACPI checksums. As a result, invalid checksums in ACPI tables escape this type of
testing. Linux is less forgiving of checksum errors and they are occasionally received
during start up.
These errors are dependent purely on the version of BIOS installed. Sometimes,
upgrading the BIOS will resolve the errors. Linux ignores the offending ACPI table
June 2012
8
and System Platform makes no use of ACPI power management, so these errors are
completely benign.
13. When running System Platform on a S8300D from the gateway, the ‘session icc’
command will not work unless the gateway is running firmware version 30.13.0
or higher.
14. Patch search results may not display.
When searching for a patch on the ‘Patch Search’ screen (by selecting the media type
(e.g. HTTP), entering the patch URL for the patch file, and select the ‘Search’ button)
search results may not be displayed.
There are a number of workarounds for this issue by selecting different media types.
If HTTP is preferred, enter in the URL pointing to the patch file's parent directory. If
this doesn't work (normally due to the HTTP server not configured to allow directory
browsing), select a different media type.
15. Kernel Patching Rollback limitation – automatic fall back to a previous kernel
will not occur if the new kernel panics.
The RHEL 5 based distribution of CentOS is missing the grub-set-default command
which causes the system to not automatically fall back to a previous kernel if the new
kernel panics. Additional information on the CentOS bug may be obtained at
https://bugzilla.redhat.com/show_bug.cgi?id=212649.
16. If the reboot button is selected, but the VM never shuts down or restarts, the
Management Console will display the “rebooting” status indefinitely.
Workaround: In the case where the VM is a Windows HVM, log into Windows from
vnc and shutdown the instance gracefully (consult documentation for applications
running on Windows operating systems for more information). For other VMs that
hang in the shutdown process, manually issue an ‘xm destroy’ command (ensure the
VM is actually stuck, some VMs are slow to shutdown and may take up to 30
minutes). Using the ‘xm destroy’ command on a VM that is in the process of shutting
down rather than one that has hung may result in issues. Advanced users may be
able to use ‘xm console <machine name>’ to check the state of the machine from its
console.
17. Do not install AE Services on System Platform R6.2 until System Platform
service pack R6.2.1 is released (June 2012).
AE Services is not certified with System Platform R6.2. AE Services will be certified
against System Platform R6.2.1 service pack (June 2012), until then, AE Services
systems should remain on System Platform R6.0.X. Once System Platform R6.2.1 is
released and certified for AE Services, AE Services systems can be upgraded to
System Platform R6.2 and the R6.2.1 service pack then immediately installed before
the AE Services template is upgraded. There is an interaction between System
Platform R6.2 and certain Dell R610s that can cause system crashes under high I/O.
June 2012
9
18. CDOM and Services VM IP addresses cannot be directly swapped on the
network configuration page and then the page submitted.
If this is done, CDOM will become unreachable. Instead, the process to swap the IP
address of CDOM with the IP address of the Services VM is as follows:
a. Uncheck ‘Enable Services VM’ from the ‘Network Configuration’ page and click the
save button.
b. Swap Services VM IP address into the CDOM IP address field and apply changes.
c. Check the ‘Enable Services VM’ and set the former CDOM IP address into the
Services VM IP address field and click the save button.
The Services VM and CDOM will now have successfully changed IP addresses.
19. Service Pack rpm R6.2.0.2.27 may invalid vsp-all.log entries.
After installing service pack rpm R6.2.0.2.27, the /var/log/vsp/vsp-all.log on CDOM
may have entries in it such as:
“ERROR [com.avaya.vsp.webconsole.util.patch.StatusParser] The key "This"
is not supported”.
“ERROR [com.avaya.vsp.webconsole.util.patch.StatusParser] The key
"Check" is not supported”.
These entries may appear when installing a future service pack or patch after this
service pack rpm has been applied. These log entries should be ignored.
June 2012
10

Avaya Aura System Platform R6.2 Release Notes

Transcription

Documents pareils

patch Bad Company Map Pack 7

Smoking Cessation Guide v.1

! SMARTT!e(Patch,!a!new!electronic!transdermal!patch,! is!a!winner

A donation for helping Optimists help Canadian kids. - ccof

Fact sheet partnership with Avaya

GSM-Med - Observatoire Océanologique de Villefranche sur Mer

Cotton Patch Quilt Shop Spider Web Topper