Friday May 15, 2015

Deleting stale VNICs

When there are stale VNICs in an Exalogic rack, a "Stale VNICs are present in the switches" warning is thrown in Exachk report. When looking deeper into that warning, the following risk can be seen:
VNICs in states other than "UP" can cause network outages. In a virtual rack, excessive number of unused vNICs can cause performance issues.

Sometimes the steps to delete these stale VNICs can be confusing to some guys, so I am posting here simple steps to achieve it.

The syntax of the deletevnic command is:
# deletevnic connector vnic_id

Ok, but how can I know the connector and vnic_id of each stale VNIC?
Well, they are listed in Exachk.
But also, you can check what VNICs are stale by running the following command:
# showvnics|grep -i WAIT-IOA
And then you will see the vnic_id in the first column and the conector in the last column.

The output would be something like:
74 WAIT-IOA N 27ABA53803F429048 rackcn02 192.168.8.2 0000 00:14:4F:FB:70:D7 13 0x8007 0A-ETH-2
30 WAIT-IOA N 5E6C31804046A4361 rackcn04 192.168.8.4 0000 00:14:4F:FA:50:D4 13 0x8007 0A-ETH-3
51 WAIT-IOA N BDC7F7A200761E5E0 rackcn01 192.168.8.1 0000 00:14:4F:FA:91:3F 13 0x8007 0A-ETH-3
16 WAIT-IOA N A584D51705DA41538 rackcn01 192.168.8.1 0000 00:14:4F:F8:8D:84 13 0x8007 0A-ETH-4


But, as several times the VNICs are associated to compute nodes, some people may think that deleting the VNIC would affect the networking performance of the compute node.
The answer for that perfectly valid concern is that, as the vnic_id is unique, then you can safely use the deletevnic command for each one of the stale VNICs.

Tuesday Aug 12, 2014

A "ZFS Storage Appliance is not reachable" message is thrown by Exachk and the ZFS checks are skipped. WAD?

Sometimes it may happen that something like the following can be seen on the "Skipped Nodes" section:

Host NameReason
myexalogic01sn01-mgm1ZFS Storage Appliance is not reachable
myexalogic01sn01-mgm2ZFS Storage Appliance is not reachable

Also, a message like the following can be seen when executing Exachk:
Could not find infiniband gateway switch names from env or configuration file.
Please enter the first gateway infiniband switch name :
Could not find storage node names from env or configuration file.
Please enter the first storage server :


This is because the way Exachk works on this is based on the standard naming convention of "<rack-name>sn0x" format.

To solve this, make sure there is an o_storage.out file in the directory where Exachk is installed. If the file is missing, create a blank one.

The o_storage.out must contain the right storage nodes hostnames in the format they have in hosts file. This format should typically be something like "<rack-name>sn0x-mgmt" For example an o_storage.out should look quite simply as below:
myexalogic01sn01-mgmt
myexalogic01sn02-mgmt


This way it is ensured that the o_storage.out file has valid ZFS Storage Appliance hostnames.


If the switch checks are skipped, then a similar procedure should be performed with the o_switches.out file.

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
Switch
- Non-sequential Even-numbered Gateway Instance
Cross-Components
- 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

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
About


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

Search

Archives
« August 2015
SunMonTueWedThuFriSat
      
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
     
Today