![]() | Oracle System Handbook - ISO 7.0 May 2018 Internal/Partner Edition | ||
|
|
![]() |
||||||||||||||||||||||||
Solution Type Predictive Self-Healing Sure Solution 2288649.1 : SuperCluster: Best Practice - Establish Threshold Alerts on the ZFSSA
In this Document
Applies to:Oracle SuperCluster Specific Software - Version 1.x to 2.x [Release 1.0 to 2.0]Oracle SuperCluster M7 Hardware - Version All Versions to All Versions [Release All Releases] SPARC SuperCluster T4-4 Half Rack - Version All Versions to All Versions [Release All Releases] SPARC SuperCluster T4-4 Full Rack - Version All Versions to All Versions [Release All Releases] SPARC SuperCluster T4-4 - Version All Versions to All Versions [Release All Releases] Information in this document applies to any platform. PurposeBest Practice: Establish Threshold Alerts on the ZFSSA to ensure that availability and performance are not degraded for iSCSI LUNs consumed by SuperCluster tenant rpools ScopeBenefit: A properly monitored and maintained internal ZFSSA will ensure the optimum operations of all LDoms and zones that consume iSCSI LUNs off the internal ZFSSA. While the internal ZFSSA is also available for general-purpose shared storage with NFS, the single JBOD ZFSSA is not designed for heavy IO for extended periods of time. Proper monitoring of the utilization will also let you know which one of your virtual tenants may be using the ZFSSA excessively, negatively impacting other tenants on the SuperCluster. Risk : An improperly utilized ZFSSA without monitoring can lead to one or many tenants experiencing local IO operations that are so slow that rpools can become non responsive. This could have all sorts of database and or application repercussions.
DetailsMandatory actions: Run the attached zfs_thrsh_alert.sh script and follow prompts to create the analytics worksheet and IOPS threshold so that you will be alerted if the ZFSSA is too heavily loaded and be able to obtain some more detail as to what is overloading it.
If you do not have an RSA public key for the user you are running the script as (see above), create one :
Make sure the script has the execute bit set, and run it twice, each time passing one the names of the ZFSSA head nodes for your SuperCluster. If you do not know the ZFSSA node name, you can use the IP address which should also be set for solaris and exa-family publishers if you issue the command “pkg publisher”, connect to that node and find the hostname. If hostname is *-h1-* then the other ZFSSA head node will be *-h2-* and vice versa; you can look in /etc/hosts to find both head nodes if that standard is not adhered to for your SuperCluster.
If you see a current worksheet with a name like zfssa_threshold_collection and a threshold with a name like io.utilization, you probably have already had this setup manually and do not need to continue (ctrl-c). If you don't see such items, proceed by pressing return/enter key and you will see something like:
This is indicative of the worksheet, threshold, and alert being set as desired.
Run the script again on the second ZFSSA node, where it will only create the analytics and then you can exit with ^C as you will see the threshold already exists :
References<NOTE:1957864.2> - xAttachments This solution has no attachment |
||||||||||||||||||||||||
|