Hey guys how are you doing? Today I’ll continue with the Oracle always free cloud offering and we’ll finally start to provisioning a VM in our environment. If you want to know more about how it works (Part 1) or the overview about the Dashboard (Part 2) please check my previous posts.
The first thing we need to do is check for the best practices and see if everything in our environment is adequate.
- 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.
- Three IP Addresses in Each Subnet
- 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
- All Oracle-provided images include rules that allow only “root” on Linux instances or “Administrators” on Windows Server 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.
- Oracle recommends 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.
- Oracle recommends 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, Oracle recommends that you do not enable UFW on your instances.
- All Oracle-provided images include rules that allow only “root” on Linux instances or “Administrators” on Windows Server 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.
- System Resilience
- Oracle Cloud Infrastructure runs on Oracle’s high-quality Sun servers. However, any hardware can experience a failure:
- 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.
- Oracle Cloud Infrastructure runs on Oracle’s high-quality Sun servers. However, any hardware can experience a failure:
- 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 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 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.
- 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).
- We recommend that you configure your instances to use the Oracle Cloud Infrastructure NTP service.
- Fault Domains
- 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.
- Your application’s architecture will determine whether you should separate or group instances using fault domains.
- 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. You can control how and when your applications experience maintenance downtime by proactively rebooting (or stopping and starting) your 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 reboot and migrate your instances before proceeding with the planned infrastructure maintenance.
When you work with Oracle Cloud Infrastructure, one of the first steps is to set up a virtual cloud network (VCN) for your cloud resources. I was thinking to do a more detail explanation here but this topic is very big. Then I decide to try do a simple step by step in how to set you Network for you to access your resources from your computer.
This is not the best way to create an complex network or anything like that, is just a way to quick start using your always free components and test your VM and DB.
To start we will click in the “Setup a network with wizard” quick link:
After you click there you have 2 options:
Select VCN with Internet Connectivity, and then click Start VNC Wizard. In the next page, just insert the name of your VCN and leave averything else as it is (unless you have a reason to change). Click Next.
In the next page, it’ll show everything that will be create by the Wizard. Note that you can create manually piece by piece of it, but for simplicity, the wizard should be enough.”Click in Create.
Next screen will show the installation of what was requested:
And that’s it for the network. Now we can start to create our databases and VM’s all inside our network, and they all going to “see” each-other.
That’s it for the network. Again, this is a very simple way to set your Network and every single step above can be setup individually with greater complexity but I’m for sure, but that will be impossible to be done in the always free since a lot of the complexity stuff needs to be paid for.
You can get a lot more information in the Jumpstart your Cloud Skills on the Start Explore. There are a lot of videos there explaining a lot of things. For simplicity, I’ll post here all links available there just for people that wants to see the videos before they subscribe to the OCI.
| Module Name | Number of Submodules | Run Time (Minutes) | |
| Core Infrastructure | Getting Started with Oracle Cloud Infrastructure | 1 | 13 |
| Core Infrastructure | Virtual Cloud Network L100 | 10 | 116 |
| Core Infrastructure | Virtual Cloud Network L200 | 4 | 71 |
| Core Infrastructure | Compute L100 | 6 | 60 |
| Core Infrastructure | Compute L200 | 6 | 70 |
| Core Infrastructure | VPN Connect L100 | 2 | 28 |
| Core Infrastructure | FastConnect L100 | 2 | 18 |
| Core Infrastructure | VPN Connect L200 | 2 | 15 |
| Core Infrastructure | FastConnect L200 | 2 | 24 |
| Core Infrastructure | Block Volume L100 | 6 | 47 |
| Core Infrastructure | File Storage L100 | 4 | 55 |
| Core Infrastructure | Object Storage L100 | 3 | 40 |
| Core Infrastructure | Storage L200 | 3 | 41 |
| Core Infrastructure | Load Balancing L100 | 3 | 30 |
| Core Infrastructure | Load Balancing L200 | 2 | 24 |
| Core Infrastructure | HA and DR L300 | 2 | 31 |
| Database | Database L100 | 4 | 45 |
| Database | Database Capacity Planning L200 | 4 | 66 |
| Database | Database HA L200 | 2 | 36 |
| Database | Database Migration L200 | 3 | 33 |
| Database | Database CLI L200 | 1 | 10 |
| Database | Data Safe L100 | 1 | 15 |
| Database | Autonomous Database L100 | 5 | 52 |
| Database | Autonomous Database L200 | 5 | 79 |
| Database | Exadata Cloud Service Overview L300 | 1 | 100 |
| Database | Exadata API and CLI L300 | 1 | 95 |
| Database | Exadata Patching L300 | 1 | 61 |
| Database | Exadata Backup and Recovery L300 | 1 | 57 |
| Solutions and Platform | Functions L100 | 3 | 48 |
| Solutions and Platform | Events L100 | 3 | 48 |
| Solutions and Platform | Container Engine for Kubernetes L100 | 3 | 27 |
| Solutions and Platform | Registry L100 | 4 | 21 |
| Solutions and Platform | DNS Traffic Management L100 | 3 | 26 |
| Solutions and Platform | DNS Zone Manager L100 | 2 | 12 |
| Solutions and Platform | Resource Manager L100 | 1 | 22 |
| Solutions and Platform | Monitoring L100 | 1 | 35 |
| Solutions and Platform | Streaming L100 | 1 | 11 |
| Migration | Data Migration L100 | 3 | 38 |
| Migration | OCI-Classic to OCI Migration | 1 | 36 |
| Migration | OCI-Classic to OCI Migration Tools | 1 | 71 |
| Governance and Administration | Identity and Access Management L100 | 5 | 65 |
| Governance and Administration | Identity and Access Management L200 | 1 | 107 |
| Governance and Administration | Billing and Cost L100 | 2 | 37 |
| Governance and Administration | Service Requests and SLAs | 1 | 19 |
| Governance and Administration | Security Overview L100 | 10 | 61 |
| Governance and Administration | Web Application Firewall L100 | 2 | 30 |
| Governance and Administration | Key Management L100 | 1 | 18 |
Next thing we can do is create a load balancing. To do that, we just have to click in the Create Load Balancer in the Quick Actions and then fill the new page like this:
The most important thing here is to make sure you selected the Micro in the Bandwidth selection. This one is free (you can also see the Always free Eligible logo there. Click Next after this.
In the next page we need to choose the load balance policy, and for that, depending of your application you’ll select one specific one. We have 3 options:
- Weighted Round Robin: This one distribute the load sequentially in the servers (one each)
- IP Hash: This one guarantee that the request from one specific client always go to the same server
- Least Connections: this one always select the server with less connections
Next you need to add Back-ends. We don’t have any create now, but we can add this later. And finally we can change the Health Check policy, but for what we are doing we can just leave as it is. Click Next. In this screen we have to create a listener:
Here we have 3 options of traffic listener, HTTPS, HTTP and TCP. I’ll going to select TCP without SSL for simplicity, but if you select HTTPS you’ll need to have SSL certificate files and private keys. It’s safer but if you want just o play around its better to select HTTP or TCP.
For TCP we just have this options:
If you select USE SSL you also need to provide the Digital Certificate and private keys.
After you select yours, just finish the process. You’ll be taking to the Load Balance Monitoring page where’ll see something like this:
And that’s it for the network. Next time we’ll provisioning a VM and we’ll set our machine to connect into the VM.
I hope you guys enjoy this and see you soon.
DEV EPM 