Database Reference
In-Depth Information
RESULT: Random read throughput of SSD_E0_S20_805674815 is 4144 IOPS 328 MBPS
RESULT: Random read throughput of SSD_E0_S21_805674571 is 4143 IOPS 328 MBPS
RESULT: Random read throughput of SSD_E1_S22_805674882 is 4146 IOPS 328 MBPS
The results can vary depending on the workload currently performing on the ODA. The results in Listing 7-11
are from a very low workload time period, and thus are very close to the I/O speeds that Oracle advertises in its
marketing material.
■
oDa X3-2 Disk Calibration results are broken and the command shows that the action is unsupported and not
working as of the oDa 2.7 software release.
Note
Automatic Service Requests
ASR is a feature of the ODA that allows for hardware failures to be reported to the Oracle Corporation via a Service
Request. Results are reported back to the user. This allows for an expedited resolution for common hardware failures.
ASR is completely integrated into My Oracle Support (MOS), which allows for ease of creation of Service Requests
for any hardware-related issuesthat is, hardware faults due to hardware failure. The ODA is a hardware component
that is registered as an asset with MOS during the setup and deployment of an ODA. A local ASR service per ODA
can be used. Alternatively, if an organization has multiple ODAs and other Oracle hardware that it is managing, it is
advisable to have an external, centralized ASR server.
Oracle added validation and testing of ASR in ODA 2.6. This software upgrade brought forward the ability to not
only validate ASR connectivity and ensure that ASR is setup right, but also to test various scenarios to ensure that
alerts are actually being generated.
Automatic Service Requests provide the ability to automatically open Oracle service requests for specific
hardware faults. ASR is an optional utility that can be set up during deployment of the ODA or after. In ODA 2.5
and above, ASR deployment can use the built-in ASR packages or a standalone ASR server to manage the fault
management process. Prior to ODA 2.5, the only official option was to use the ASR built into the box, and thus connect
each ODA to the Internet to provide ASR capability.
Let's look at the ASR validation process. The ASR validation process is the same for ODA V1 and X3-2, but in ODA
X3-2, the ILOM and the server nodes have different serial numbers, which is not the case in a V1 box. The validation
process checks for a number of things:
•
Is ASR installed?
•
Are SNMP traps set on the ILOM to point to the ASR server?
•
Are the assets registered in an ASR server?
•
Can an event be tested?
Listing 7-12 shows the output that is expected from a server that has ASR running on the ODA box.
Listing 7-12.
Running an ASR Validation
root@odab1 bin]# ./oakcli validate -c asr
INFO: oak Asr information and Validations
RESULT: /opt/oracle/oak/conf/asr.conf exist
RESULT: ASR Manager ip:x.x.x.x
RESULT: ASR Manager port:1162
SUCCESS: ASR configuration file validation successfully completed
RESULT: /etc/hosts has entry 141.146.156.46
transport.oracle.com
