Wednesday Sep 17, 2014

Working with SSL Certificates in OTD

An issue in Oracle Traffic Director (OTD) that has become somewhat common, is to get SSL certificate warnings similar to the one below:
SSL server certificate Admin-Server-Cert is expired.

This typically happens if the Admin SSL CA Cert has expired. So, to prevent this, the CA/SSL certificates should be renewed before their expiry dates by extending it, which could be from 1 to 10 years. There are 2 approaches:
1. To artificially set the Admin-Server host clock
2. To create a new Admin server to replace the old one (but may lose old configured SSL keys)

However, at that point it may also happen that you get a certificate for one year and would like it for ten years. And even when the the command below runs successfully, the expire dates are not changed:
./bin/tadm renew-admin-certs --user= --port= --validity=120

The problem there is that without applying the latest patch, currently the Admin Node(s) certificate will be valid for only 1 year and it requires renewal each year. So, to avoid renewing the Admin Node(s) certificate every year, you need to apply the patch MLR#2 (Apr 2014) for OTD version or later. After the patch, the startup banner will have a proper new date, and when you renew Admin Server certificates will also renew the Admin Nodes(s) certificates for same number of years.

For further information, please take a look at the following MOS notes:
- Oracle Traffic Director OTD Cannot Communicate Between Admin Server & Administration Node (Doc ID 1561339.1)
- Oracle Traffic Director Admin Server and Admin Node Certificate Validity (Doc ID 1603520.1)
- How to Renew Admin Server SSL Certificate for Oracle Traffic Director? (Doc ID 1549253.1)
- Available Versions, Patches, and Updates for Download for Oracle Traffic Director (OTD) (Doc ID 1676256.1)

Wednesday Jun 11, 2014

Setting MTU on Exalogic

For many reasons, a system administrator may want to change the MTU settings of a server. But in a system like Exalogic which contains lots of interconnected nodes and other various components, it's important to understand how this applies to the different networks.

For example, when bringing up bonding of InfiniBand an error like the following may be thrown:
Bringing up interface bond1: SIOCSIFMTU: Invalid argument
Both scripts ifcfg-ib0 and ifcfg-ib1 (from the /etc/sysconfig/network-scripts/ direectory) have MTU set to 65500, which is a valid MTU value only if all IPoIB slaves operate in connected mode and are configured with the same value, so the line below must be added to both network scripts and then restart the network:

By the way, an error of the form “SIOCSIFMTU: Invalid argument” indicates that the requested MTU was rejected by the kernel. Typically this would be due to it exceeding the maximum value supported by the interface hardware. In that case you must either reduce the MTU to a value that is supported or obtain more capable hardware. This problem has been seen when trying to modify the MTU using the ifconfig command, like the output of the example below:
[root@elxxcnxx ~]# ifconfig ib1 mtu 65520
SIOCSIFMTU: Invalid argument

It's important to insist that in most cases the nodes must be rebooted after the MTU size has been changed. Although in some circumstances it may work without a reboot, it is not how it is typically documented.

Now, in order to achieve a reduced memory consumption and improve performance for network traffic received on IPoIB related interfaces, it is recommend to reduce the MTU value in interface configuration files for IPoIB related bonds from 65520 to 64000. The change needs to be made to interface configuration files under the /etc/sysconfig/network-scripts directory and applies to the interface configuration files for bonds over IPoIB related slave devices, for example /etc/sysconfig/network-scripts/ifcfg-bond1. However, keep in mind that the numeric portion of the interface filenames that corresponding to IPoIB interfaces is expected to vary across compute nodes and vServers and so cannot be relied upon to identify which interface files are for bonds are over IPoIB rather than EoIB related slave interfaces.
To fix these MTU values to the recommended settings, there are very useful instructions and a script on the MOS Note 1624434.1, and it's applicable physical and virtual configurations of Exalogic.

Regarding the recommended MTU value for EoIB related interfaces, its maximum appropriate value is 1500. If for some reason a vServer has been created with a higher value (set on the /etc/sysconfig/network-scripts/ifcfg-bond0 file), then it must be fixed. An error like the following could be thrown under this circumstance:
[root@vServer ~]# service network restart
Bringing up interface bond0:  SIOCSIFMTU: Invalid argument

Also an error like the one below can be seen on the /var/log/messages file of the vServer:
kernel: T5074835532 [mlx4_vnic] eth1:vnic_change_mtu:360: failed: new_mtu 64000 > 2026
The MOS Note 1611657.1 is very useful for this purpose.

Friday May 30, 2014

Running Mixed Physical and Virtual Exalogic Elastic Cloud Software Versions in an Exalogic Rack is now Supported

Although it was not supported on older versions, now as of EECS 2.0.6, an Exalogic rack now can be configured in a mixed-mode: half virtual and half physical Linux:
  • Flexibility to have physical and virtual environments on same rack. For example, production on physical and test/dev on virtual.
  • Exalogic Control manages the virtual compute nodes on the rack. Physical compute nodes are managed manually (including PKeys).
  • Option to change full physical to hybrid and hybrid to full virtual rack.
  • User has an option to choose either the top or bottom nodes for physical or virtual deployment.
For further information about how the compute nodes can be split up on the rack (into bottom or top half) to run either Oracle Virtual Server (OVS "hypervisor") or Oracle Linux, please take a look at MOS Note 1536945.1.

Note: Solaris is not yet supported in the mixed configuration.

Thursday Apr 10, 2014

Working with SCAN on Exalogic

During this last time, I have seen more Exalogic customers using SCAN, so decided to write a brief article about it, although there is a lot of documentation from Oracle about it (but not related to Exalogic itself).

Single Client Access Name (SCAN) is a JDBC driver feature that provides a single name for clients to access any Oracle Database running in a cluster. Some of its benefits and advantages include:
- Client’s connect information does not need to change if you add or remove nodes or databases in the cluster
- Fast Connection Failover (FCF)
- Runtime Connection Load-Balancing (RCLB)
- Can be implemented with MultiDataSource or GridLink
- It can also be used with Oracle JDBC 11g Thin Driver (this is clearly explained on MOS Note 1290193.1)

In the particular case of Exalogic, a typical architecture, widely used by customers, is having it connected to an Exadata machine (which hosts the database) through InfiniBand. Obviously the SCAN feature can be used within this Engineered Systems architecture. As a matter of fact, GridLink is part of the Exalogic-specific enhancements of Weblogic.

Some facts to keep in mind when using it:
- SCAN feature is supported on JDBC version and above
- Just as any situation when a connection to database is involved, need to be careful that firewalls may cause some network adapter or timeout issues, which must be solved so the connection can be established
- If using VIP hosts, instead of cluster configuration having the short host name for the VIP hosts, you should set LOCAL_LISTENER to the fully qualified domain name (e.g.

Wednesday Aug 21, 2013

Resource allocation on vServers

A few facts to keep in mind.

The number of vCPUs to existent vServer cannot be modified. Currently vDC resource management (changing vCPU, memory, etc.) after a vServer has been created is not supported in Exalogic Virtual environments. However, a customer vServer type with required memory can be created and used instead of the default VM types.

Note that the Server pool management is handled by Exalogic, manual management of it is not available. Also, keep in mind that there is no way to control which physical host is assigned a given vServer. The scheduler algorithms are sophisticated but it is fine-grained and there is no reason to assume that the scheduler will not be maximally efficient. EMOC will look at the resources allocated to the vServer that is being planned on creating (CPUs/memory), then look at what is available on each of the compute nodes and make a decision on where to place the vServer. System administrators can try to use Distribution groups and separate the vServers they have to run across different Oracle VM Servers.

If need to increase Root File System and Swap Space of an Exalogic Guest Virtual Machine, then the MOS Note 1575790.1 is useful for that purpose.

Thursday Jun 20, 2013

Exachk 2.2.2 released - Now Includes Support for Exalogic Solaris Environments

This new Exachk 2.2.2 release includes several new improvements and features.

The following are additional checks as part of this new 2.2.2 release for Solaris:
Compute Nodes
- Hardware and Firmware Profile
- Software Profile
- NTP Synchronization
- DNS Setup
- Correct Slot Installation of IB Card for Solaris
- Subnet Manager
- Root Partition Usage Limit for Solaris
- Lockd Configuration for Solaris Compute Node
- ib_ipoib Module for Solaris
- ib_sdp Module for Solaris
- IP Configuration - net0 and bond0
- Recent Reboot Info for Solaris
- Probe Based IPMP for Solaris
- Swap Space for Solaris
- Free Physical Memory for Solaris
- MTU for Solaris
- IPMP Configuration for Solaris
- Fault Management Log for Solaris
- BIOS Settings
- NFS Mount Point - Version for Solaris
- Hostname Consistency with DNS on the Physical Compute Node
- NFS Mount Point - Attribute Caching for Solaris
- NFS Mount Point - Rsize Wsize for Solaris
- NIS domain (YPBind) for Solaris

Also, the following checks have been enhanced as part of this new 2.2.2 release:
Compute Nodes
- Connectivity To OVMM
- MTU Value for Infiniband Interface
- Hostname Matches the DNS on the Physical Compute Node
- Non-sequential Even-numbered Gateway Instance
- NTP Configuration for Switch Nodes Matches Physical Compute Nodes
- NTP Configuration for Switch Nodes Matches Oracle VM Servers
- Hostname Matches the DNS on Oracle VM Server
- Hostname Matching with DNS on Switches
- NTP Configuration for ZFS Matches Oracle VM Servers
- NTP Configuration for ZFS Matches Physical Compute Nodes
Multiple Components
- MTU for InfiniBand Link in Control vServers

Exachk is available via MOS Doc Id. 1449226.1

Friday Jan 18, 2013

Two New Exalogic ZFS Storage Appliance MOS Notes

This week I have closed 2 Service Requests related to the ZFS Storage Appliance and I created My Oracle Support (MOS) notes from both of them as, despite they were not complicated issues and the SRs were both closed in less than one week, these procedures were still not formally documented on MOS. Below can be seen the information about these created documents.

MOS Doc Id. 1519858.1 - Will The Restart Of The NIS Service On The ZFS Storage Appliance Affect The Mounted Filesystems?

On this case, for a particular reason it was necessary to restart the NIS service. So, if for any reason, the NIS service needs to be restarted on the ZFS Storage Appliance, will the mounted filesystems be affected during the restart?

The default cluster configuration type of the ZFS storage appliance is active-passive and the storage nodes are supposed to be mirrored, so the restart of NIS should not be causing any issues; it can be done.

Note that restart of NIS should be done on the active storage head. Restarting the NIS itself will not cause any ZFS failover from Active to Passive.

In general terms, even in the event of a storage node failure, the appliance will automatically fail over to the other storage node. Under that condition, an initial degradation in performance can be expected because all of the cached data on the failed node is gone, but this effect decreases as the new active storage node begins caching data in its own SSDs.

MOS Doc Id. 1520223.1 - Exalogic Storage Nodes Hostnames Are Displayed Incorrectly

This was not the first time I saw something like this, so decided to create a note because clearly is a problem that may affect to more than one Exalogic user.

The Exalogic storage node hostnames displayed on the BUI were different than the ones displayed when accessing the node through SSH or ILOM.

This happens because for any reason the hostname is misconfigured on the ZFS Storage Appliance.

To solve this problem, it is necessary to set the system name and location accordingly on the Storage Appliance nodes BUI:
1. Login on the ZFS Storage Appliance BUI
2. Go to the "Configuration" tab, and select the "Services" subtab
3. Under the "Systems Settings" section, click on "System Identity"
4. Set the system name and location accordingly

Monday Jan 07, 2013

Exalogs - Exalogic Diagnostic Collection Tool now available on My Oracle Support

What is Exalogs?
Exalogs is a command-line tool for gathering logs, diagnostics, environment/configuration information, and other data from the following components in an Exalogic virtual rack:
- Enterprise Manager Ops Center Enterprise Controller
- Enterprise Manager Ops Center Proxy Controllers
- Oracle VM Manager
- Database VM (RDBMS)
- Compute nodes (Domain0/Dom0's)
- ZFS storage appliance
- InfniBand switches

You can target Exalogs at either the entire rack or for individual components.

Note that Exalogs is not a health-check or monitoring/reporting tool, and it is not a replacement for Exachk health-check tool.

Exalogs is available for download immediately from My Oracle Support using MOS Note 1512323.1 and further information (including a very complete README file) can be seen on that note.

Monday Jun 11, 2012

Exalogic Exachk - Exalogic Health Check Tool now available on My Oracle Support

This is a new tool for Exalogic which automates the process of determining whether an Exalogic system is in a healthy state.

Exachk is available via MOS Doc Id. 1449226.1

Check the Quick Start Guide (available in the MOS Doc. Id. mentioned above) for further informarion.

Information about the Exachk healtcheck tool for Exadata can be seen at MOS Doc Id. 1070954.1

Principal Technical Support Engineer in the Engineered (Systems) Enterprise Support Team - EEST.
Former member of the Coherence and Java Technologies Support Teams.


« March 2015