Consider these recommendations when configuring your service:
Limit the amount of custom analytics reports that are configured and running on the ZFSSA to prevent overloading the storage device with analytic query processing rather than provisioning storage devices. This will ensure the best performance from the ZFSSA.
Do not modify or destroy the default aggr1 or aggr1_vnic1 network datalink and interface provided in your Oracle-installed compute instance. These devices provide the only initial means by which you can access an instance, and modifying or deleting them is likely to cause a compute instance to become inaccessible, which would require you to open a service request (SR) to Oracle to recover the network configuration.
Do not modify /etc/system settings without specific recommendations from Oracle. Each instance has been pre-configured to limit the ZFS arc caches based on current best practices.
Do not delete the primary interface (data link or first VNIC interface) or modify the IP address that your instance was delivered with. In doing so, you risk losing connectivity to your instance, which would require you to file a service request (SR) to restore connectivity.
Do not use the shutdown command, init 0, 1, 2, 3, 4, 5, S, or take any other action that would prevent the system booting into multi-user mode. Doing so will cause your instance to become inaccessible because there is no console access. Remember to also factor in the CPU and memory resources that are necessary for the operating system if using kernel zones or legacy support zones.
If your instance is (or becomes) unavailable, submit a service request (SR) with Oracle Support. For information about opening an SR, see Step 5: Learn About Opening Service Requests and Cloud Support Help: Service Requests.
It is highly recommended that you make backups of each instance for your service. In the case of a catastrophic error that requires the instance to be rebuilt, the instance is re-created to its initial state, which is the same state it was when you first accessed the service. Any changes to the instance will be lost.
Oracle recommends that you use ZFSSA iSCSI LUN storage volumes instead of using local storage.
Change any default passwords that the system is delivered with.
To ensure that Oracle SPARC Model 300 Service instances provide a resilient platform for your workloads, ensure that the latest security patches are applied to the operating system running on the instances and zones. In addition, before deploying applications on an instance, review the security configuration of the operating system and verify that it complies with your security policies and standards. For security and patching-related guidelines, see the documentation for your operating system (for example, refer to Administering CVE Updates: Oracle Solaris 11.3 Security Compliance Guide and Oracle Solaris 11 Security and Hardening Guidelines).
When you create zones and storage volumes, select the name of the object carefully. Pick a name that helps you quickly identify the key characteristics of the object later. For example, when creating a bootable storage volume, consider including the operating system name and the image disk size in the name of the storage volume.
While configuring the size for a zone, consider the nature of the applications that you plan to deploy on the instance, the number of users that you expect to use the applications, and also how you expect the load to scale in the future. Remember to also factor in the CPU and memory resources that are necessary for the operating system if using kernel zones or branded zones.
Configure the zone that meets the requirements of your workload with a sufficient buffer for intermittent spikes in the load. If youâre not sure what shape is appropriate for an instance, then start small, experiment with a representative workload, and then settle on a zone configuration. This approach may help you achieve an optimal trade-off between resource allocation and performance.
If you're creating an Oracle Solaris instance, try to determine, up front, how many users you expect to access the instance and plan for a separate SSH key pair for each user.
Keep your SSH keys secure. Lay down policies to ensure that the keys aren't lost or compromised when employees leave the organization or move to other departments. If you lose your private key, then you can't access your instances. For business continuity, ensure that the SSH keys of at least two IT system administrators are added to your instances.
Limit the number of volumes (iSCSI LUNs) provided by each ZFSSA head to 500. This is not a hard restriction, but doing so will limit extended failover times seen by users in the event of a failure of one or other of the ZFSSA heads, and the resultant take over by the remaining head. This will help prevent unintended application failures that might result from extended storage wait times when trying to access storage that is being transitioned from the failed head to the remaining head.
Storage volumes are iSCSI LUNs. Typically, you should mount them to the instance first, and then map them to the zones that require the dedicated or shared storage volume.
You might be able to improve the transfer speeds, and thus the performance, of applications running on Oracle Solaris 11.3 by switching the mediator implementation you use to OpenSSH. For more information about using OpenSSH with Oracle Solaris 11.3, refer to How to Use the OpenSSH Implementation of Secure Shell in Managing Secure Shell Access in Oracle Solaris 11.3.