Best Practices for Your Compute Instance
Oracle Cloud Infrastructure Compute provides bare metal and virtual machine (VM) compute capacity that delivers performance, flexibility, and control without compromise. It's powered by Oracle’s next generation, internet-scale infrastructure, designed to help you develop and run your most demanding applications and workloads in the cloud.
You can provision compute capacity through an easy-to-use web console or the API, SDKs, or CLI. The compute instance, once provisioned, provides you with access to the host. This gives you complete control of your instance.
Though you have full management authority for your instance, we recommend a variety of best practices to ensure system availability and top performance.
IP Addresses Reserved for Use by Oracle
Certain IP addresses are reserved for Oracle Cloud Infrastructure use and may not be used in your address numbering scheme.
These addresses are used for iSCSI connections to the boot and block volumes, instance metadata, and other services.
Class D and Class E
All addresses from 184.108.40.206 to 220.127.116.11 (Class D) are prohibited for use in a VCN, they are reserved for multicast address assignments in the IP standards. See RFC 3171 for details.
All addresses from 240.0.0.0 to 255.255.255.255 (Class E) are prohibited for use in a VCN, they are reserved for future use in the IP standards. See RFC 1112, Section 4 for details.
Three IP Addresses in Each Subnet
These addresses consist of:
- The first IP address in the CIDR (the network address)
- The last IP address in the CIDR (the broadcast address)
- The first host address in the CIDR (the subnet default gateway address)
For example, in a subnet with CIDR 192.168.0.0/24, these addresses are reserved:
- 192.168.0.0 (the network address)
- 192.168.0.255 (the broadcast address)
- 192.168.0.1 (the subnet default gateway address)
The remaining addresses in the CIDR (192.168.0.2 to 192.168.0.254) are available for use.
Essential Firewall Rules
We recommend that you do not reconfigure the firewall on your instance to remove these rules. Removing these rules allows non-root users or non-administrators to access the instance’s boot disk volume.
We recommend that you do not create custom images without these rules unless you understand the security risks.
Running Uncomplicated Firewall (UFW) on Ubuntu images might cause issues with these rules. Because of this, we recommend that you do not enable UFW on your instances. See Ubuntu instance fails to reboot after enabling Uncomplicated Firewall (UFW) for more information.
- Design your system with redundant compute nodes in different availability domains to support failover capability.
- Create a custom image of your system drive each time you change the image.
- Back up your data drives, or sync to spare drives, regularly.
Uninterrupted Access to the Instance
Make sure to keep the DHCP client running so you can always access the instance. If you stop the DHCP client manually or disable NetworkManager (which stops the DHCP client on Linux instances), the instance can't renew its DHCP lease and will become inaccessible when the lease expires (typically within 24 hours). Do not disable NetworkManager unless you use another method to ensure renewal of the lease.
Stopping the DHCP client might remove the host route table when the lease expires. Also, loss of network connectivity to your iSCSI connections might result in loss of the boot drive.
If you created your instance using an Oracle-provided Linux image, you can use SSH to access your instance from a remote host as the
opc user. After logging in, you can add users on your instance.
If you do not want to share SSH keys, you can create additional SSH-enabled users.
If you created your instance using an Oracle-provided Windows image, you can access your instance using a Remote Desktop client as the
opc user. After logging in, you can add users on your instance.
Oracle Cloud Infrastructure offers a fully managed, secure, and highly available NTP service that you can use to set the date and time of your Compute and Database instances from within your virtual cloud network (VCN). We recommend that you configure your instances to use the Oracle Cloud Infrastructure NTP service. For information about how to configure instances to use this service, see Configuring the Oracle Cloud Infrastructure NTP Service for an Instance.
A fault domain is a grouping of hardware and infrastructure that is distinct from other fault domains in the same availability domain. Each availability domain has three fault domains. By properly leveraging fault domains you can increase the availability of applications running on Oracle Cloud Infrastructure. See Fault Domains for more information.
Your application's architecture will determine whether you should separate or group instances using fault domains.
Scenario 1: Highly Available Application Architecture
In this scenario you have a highly available application, for example you have two web servers and a clustered database. In this scenario you should group one web server and one database node in one fault domain and the other half of each pair in another fault domain. This ensures that a failure of any one fault domain does not result in an outage for your application.
Scenario 2: Single Web Server and Database Instance Architecture
In this scenario your application architecture is not highly available, for example you have one web server and one database instance. In this scenario both the web server and the database instance must be placed in the same fault domain. This ensures that your application will only be impacted by the failure of that single fault domain.
Customer-Managed Virtual Machine (VM) Maintenance
When an underlying infrastructure component needs to undergo maintenance, you are notified before the impact to your VM instances. During an infrastructure maintenance event, where applicable, Oracle Cloud Infrastructure live migrates Standard VM instances from the physical VM host that needs maintenance to a healthy VM host without disrupting running instances. If a VM cannot be live migrated, there might be a short downtime while the instance is reboot migrated.
You can control how and when your applications experience maintenance downtime by proactively rebooting (or stopping and starting) the instances at any time before the scheduled maintenance event. A maintenance reboot is different from a normal reboot. When you reboot an instance for maintenance, the instance is stopped on the physical VM host that needs maintenance, and then restarted on a healthy VM host.
If you choose not to reboot before the scheduled time, then Oracle Cloud Infrastructure will migrate the instances before proceeding with the planned infrastructure maintenance. Optionally, you can configure the instances to remain stopped after they are reboot migrated. For more information, see Recovering a Virtual Machine (VM) During Planned Maintenance.