- Best Practices for Your Compute Instance
- IP Addresses Reserved for Use by Oracle
- 169.254.0.0/16
- Class D and Class E
- Three IP Addresses in Each Subnet
- Essential Firewall Rules
- System Resilience
- Uninterrupted Access to the Instance
- User Access
- NTP Service
- Fault Domains
- Scenario 1: Highly Available Application Architecture
- Scenario 2: Single Web Server and Database Instance Architecture
- Customer-Managed Virtual Machine (VM) Maintenance
- Oracle best practices linux
- About Personas
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.
169.254.0.0/16
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 224.0.0.0 to 239.255.255.255 (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.
System Resilience
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.
User Access
If you created your instance using a Linux platform 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 a Windows platform 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 to an Instance. For steps to log in to an instance, see Connecting to an Instance.
NTP Service
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). The NTP service is enabled by default on all of the platform images that are available in Oracle Cloud Infrastructure . For information about this service, see Configuring the Oracle Cloud Infrastructure NTP Service for an Instance.
Fault Domains
A fault domain is a grouping of hardware and infrastructure that is distinct from other fault domain s in the same availability domain . Each availability domain has three fault domain s. By properly leveraging fault domain s, you can increase the availability of applications running on Oracle Cloud Infrastructure . See Fault Domains for more information.
Your application’s architecture determines whether you should separate or group instances using fault domain s.
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 placement 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 should be placed in the same fault domain to minimize customer outages. This placement ensures that your application is only impacted by the failure of that single fault domain , providing greater application availability overall.
Customer-Managed Virtual Machine (VM) Maintenance
When an underlying infrastructure component needs to undergo maintenance, by default, Oracle Cloud Infrastructure sends a notification about the upcoming maintenance event. After 14 to 16 days, the VM instances are live migrated from the physical VM host that needs maintenance to a healthy VM host without disrupting running instances. Alternately, you can choose to have your instances automatically live migrated without a notification. If a VM cannot be live migrated, a short downtime occurs 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 migrates 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.
Источник
Oracle best practices linux
Oracle Cloud Infrastructure provides infrastructure and platform services for a wide range of enterprise workloads. In each service, you can choose from a rich array of features based on your goals. Oracle recommends a set of best practices to design and operate cloud topologies that deliver the maximum business value.
For each business goal, the best practices are organized based on key focus areas, as follows:
| Business Goal | Key Focus Areas |
|---|---|
| Security and compliance |
|
| Reliability and resilience |
|
| Performance and cost optimization |
|
| Operational efficiency |
|
About Personas
Many of the topics within the articles in this Best Practices solution list one or more «personas,» intended to map to architect roles within typical Oracle Cloud Infrastructure organizations. You can use these personas as a guideline for which members of your organization are responsible for each of the best practices areas described.
Each persona is listed in this table with some suggested Oracle Cloud Infrastructure certifications offered by Oracle University. The focus areas indicate the best practices solution playbooks that present the most topics directed to that persona.
| Persona | Description | Suggested Certifications | Focus Areas |
|---|---|---|---|
| Application Architect | Creator and curator of custom applications to be hosted on a cloud platform. Goals include understanding the tool set, utilizing the platform securely and efficiently, and maintaining stability. Focuses on taking advantage of the agility and scalability of a cloud platform to enhance the user experience. |
|
|
| Cloud Architect | Responsible for taking the needs and requirements of a workload or environment and selecting and organizing the best services and solutions for the deployed state of the host environment. Can see across the different cloud domains and interconnect the policies and requirements into a complete solution. |
|
|
| DevOps Architect | Responsible for identifying the utility of virtualization and automation tools from the operations side and the process and skill set of the development side. Understands what is happening with a cloud application and develops and manages the tools to automatically respond. Collects and applies data from monitoring and alerting to establish a dynamic, reactive environment. Identifies tools and programs that best fit a workload and how best to incorporate them into system that meets requirements. |
|
|
| Enterprise Architect | Responsible for an organization’s overall technology strategy. Often a C-Level executive accountable for budget, service availability, and other applicable business metrics. May be responsible for selecting cloud providers, sponsoring a cloud business office, and aligning the organizational structure to enable cloud deployments. |
|
|
| Infrastructure Architect | Responsibile for matching application requirements to compute and storage capabilities. Accountable for the strategy and lifecycle of datacenter equipment including hypervisor, containerization, physical servers, block and file-based storage, and operating systems. May also be responsible for defining cloud Infrastructure as Code strategies, additional components such as object storage, and data migration strategies. |
|
|
| Network Architect | Responsible for ensuring application connectivity is resilient, performant, and secure. Accountable for hybrid cloud connectivity, on-premises/WAN connectivity, ingress/egress connectivity, and lateral (East ↔ West) connectivity. May also be responsible for cloud VCN design, security group stategy, load balancer configuration, inter and intra-region peering, and FastConnect connectivity. Ensures capacity is available for steady-state workloads, and spikes caused by migration or data loads. |
|
|
| Security Architect | Responsible for ensuring application components are implemented securely. Accountable for defining strategies for intrusion detection systems, intrusion prevention systems, incident response, logging, data loss prevention, and regulatory compliance. May also be responsible for cloud IAM strategy, network security strategy, encryption, and secrets management. |
|
|
Best practices framework for Oracle Cloud Infrastructure
Copyright © 2020, 2021, Oracle and/or its affiliates.
Источник
