Oracle Cloud Infrastructure Compute provides bare metal compute capacity that delivers performance, flexibility, and control without compromise. It is 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 an API. The bare metal compute instance, once provisioned, provides you with access to the host. This gives you complete control of your instance.
While you have full management authority for your instance, Oracle recommends 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.
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.
Windows 2008 Server R2 images do not support restricting certain firewall rules for local principals, such as "Administrators", so any authenticated user on an instance can make outgoing connections to the iSCSI network endpoints (169.254.0.2:3260, 169.254.2.0/24:3260) that serve the instance's boot and block volumes.
All Oracle-provided images include rules that allow only "root" on Linux instances or "Administrators" on Windows Server 2012 R2 and Windows Server 2016 instances to make outgoing connections to the iSCSI network endpoints (169.254.0.2:3260, 169.254.2.0/24:3260) that serve the instance's boot and block volumes.
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.
Oracle Cloud Infrastructure runs on Oracle's high-quality Sun servers. However, any hardware can experience a failure. Follow industry-wide hardware failure best practices to ensure the resilience of your solution. Some best practices include:
- 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.
If you experience a hardware failure and have followed these practices, you can terminate the failed instance, launch your custom image to create a new instance, and then apply the backup data.
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.
For more information about user access, see Adding Users on an 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). Oracle recommends 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, we notify you in advance of the planned maintenance downtime. To avoid this planned downtime, you have the options to reboot, or stop and restart your instances prior to the scheduled maintenance. This makes it easy for you to control your instance downtime during the notification period. The reboot, or stop and restart of a VM instance during the notification period is different than a normal reboot. The reboot, or stop and start workflow will stop your instance on the existing VM host that needs maintenance and restart it on a healthy VM host. If you choose not to reboot during the notification period, then Oracle Cloud Infrastructure will reboot your VM instance before proceeding with the planned infrastructure maintenance. For information on rebooting or restarting your instance prior to planned maintenance, see Rebooting Your Virtual Machine (VM) Instance During Planned Maintenance.