Cross Column

Showing posts with label OCI. Show all posts
Showing posts with label OCI. Show all posts

Monday, January 21, 2019

OCI―Knowing Database Service Basics

Video 1.  OCI Level 100 - Database (Demo starts at 30:20; YouTube link)

The Oracle Cloud Infrastructure (OCI) Database service (DS) offers autonomous and user-managed Oracle Database solutions:
  • Fully-managed 
    • Autonomous databases are preconfigured, fully-managed environments that are suitable for either transaction processing or for data warehouse workloads. 
    • See OCI―Knowing Autonomous Database Basics for more information
  • User-managed
    • User-managed solutions are bare metal (BM), virtual machine (VM), and Exadata DB systems that you can customize with the resources and settings that meet your needs.
You can quickly provision a user-managed DB system or autonomous database. You have full access to the features and operations available with the database, but Oracle owns and manages the infrastructure:

In this article, we will cover mainly on Oracle provided user-managed solutions and use DS to mean either DB System or Database Service.



Virtual Machine (VM)Bare Metal (BM)Exadata
ScalingStorage (number of
CPU cores on VM DB
cannot be changed)
CPU (amount of available
storage cannot be
changed)
CPU can be scaled within
a ¼, ½ and Full rack.
Storage cannot be scaled
Multiple
Homes/Databases
No, single DB and Home onlyYes (one edition, but
different versions
possible)
Yes
StorageBlock StorageLocal NVMe disksLocal spinning disks and NVMe flash cards.
Real Application Clusters (RAC)Available (2-node)Not AvailableAvailable
Data GuardNot AvailableAvailable*Available*

*: You can manually configure Data Guard on Exadata DB systems using native Oracle Database Utilities and commands.  dbcli is not available on Exadata Data systems.

Figure 1.  Exadata Database System with the Maximum Availability Architecture:

DS Features


OCI Database Service has the following features:
  • Comprehensive offerings to cover all enterprise database needs
    • 3 Shape Types:
      • Exadata, Bare Metal, Virtual Machine 
      • Each type with different shapes 
    • Supports various Oracle database software editions, license types, database versions, and database workloads (OLTP vs DSS)
  • Lifecycle Automation
    • Provisioning, Patching, Backup & Restore
  • High Availability 
  • Scalability
    • Dynamic CPU and Storage scaling
  • Security
    • Infrastructure (IAM, Security Lists, Audit logs)
    • Database (TDE, RMAN backup/Block volume encryption)
  • OCI Platform integration
    • Tagging, Limits and Usage Integration
  • License Type
    • License Included with OCI provisioning
    • Bring Your Own License (BYOL)
With Exadata DS, all types of failures are protected against, including disk, server, network and data.

Managing DS


You can use the console to perform the following tasks:
  • Launch DS 
    • Which also create a database system
  • Start, stop or reboot DS
    • Billing continues in stop state for BM DB Systems because its attached local NVMe, but not for VM 
  • Scale CPU cores (except for VM)
  • Scale up storage (VM only)
  • Terminate
    • When you terminate a DB system or a database, all of its resources are deleted, along with any automatic backups. 
    • Full backups remain in Object Storage as standalone backups. 
      • You can use a standalone backup to create a new database.
      Figure 2.  Db System patch (upper) vs Database patch (lower)

Patching DS


Because patching a system requires a reboot, plan to run the operations at a time when they will have minimal impact on users. To avoid system interruption, consider implementing a high availability strategy such as Oracle Data Guard.

Using the Console, API, or the database CLI (dbcli), you can perform below tasks:
  • Managed/On-Demand Patching
    • Automated applicable patch discovery and pre-flight checks/tests
  • On Demand Patching
    • N-1 patching (previous patch is available if it hasn't been applied), pre-check and patching at the click of a button
  • Availability during Patching 
    • For Exadata and RAC shapes, patches are rolling.
    • For single node systems, Active Data Guard can be leveraged by the patch service if it is configured
  • 2-Step Process
    • Patching is a 2 step process.  To perform a patch operation on a
      1. DB System
      2. Database
  • Identity and Access Controls
    • Controls who can list patches, apply them, etc

Backup / Restore


If you plan to back up your DB system to Object Storage, you can use a service gateway with a private subnet or an internet gateway with a public subnet.  To recover a database from Object Storage, you can use the Console, API, or by using RMAN.[2]

For backup and restore, OCI Database Service supports:

Manged Backups vs. Unmanaged Backups

Automatic Backups (Incremental)
  • Default Policy 
    • Not changeable at this time
    • Are written to Oracle owned object storage (not visible to customers)
    • Backup window is defined by Oracle
      • New backup window time will be between midnight and 6 AM in the time zone of the DS's region
      • To migrate yours to the new behavior, contact Oracle Support 
    • All backups are encrypted with the same master key used for Transparent Data Encryption (TDE) wallet encryption.  
  • Automatically retried
    • Oracle will get notified if the job is stuck

High Availability (HA)

  • Cloud Infrastructure HA
    • Region with 3 Availability Domain architecture
      • While the availability domains provide the facility for high availability, regions provide the basis for disaster recovery. 
    • Fully redundant and non-blocking Networking Fabric
  • Database HA
    • Disk Redundancy
      • Normal (2-way mirroring) vs High (3-way mirroring―recommended for production) 
    • Database RAC option
    • Automated Data Guard within and across ADs
Read Oracle's whitepaper on HA for more information.

Scalability

  • Exadata 
    • Two kinds of scaling operations are supported for an Exadata DB system:
      • Scaling within an Exadata DS lets you modify compute node processing power within the system.
      • Scaling across Exadata DS configurations lets you move to a different configuration, for example, from a  ¼  to a ½ rack.
    • To learn how to scale an Exadata DS, see To scale an Exadata DB system.
  • Bare Metal 
    • # of CPU cores can be scaled
    • Total raw storage is fixed based on a chosen shape
      • However, the amount of usable storage on the BM DS can be affected by options like 2- or 3-way mirroring and the space allocated for data files.
  • Virtual Machine 
    • 1-node or 2-node RAC 
    • Storage can be scaled
      • For 2-node RAC VM DB systems, storage capacity is shared between the nodes.
    • # of CPU cores on an existing VM DS cannot be changed.

References

  1. Overview of Database Service (OCI)
  2. Recovering a Database from Object Storage
  3. Developer Tools (OCI)
  4. Updating a DB System (OCI)
    • Includes information and instructions on how to update the OS of a bare metal or virtual machine DB system.
  5. Updating an Exadata DB System (OCI)
  6. Securing Database (OCI)
    • Includes information on security best practices for databases in Oracle Cloud Infrastructure.
  7. OCI Database Service Troubleshooting 
  8. Oracle Cloud Infrastructure Object Storage FAQ
  9. Oracle Database CLI Reference (dbcli)
  10. Standalone Backups (OCI)
  11. Backing Up to Oracle Cloud Infrastructure Object  (OCI)
  12. Migrating Databases to the Cloud (OCI)
  13. Developer Tools (OCI)
  14. Introduction to Oracle Automatic Storage Management (ASM)
  15. Best Practices for Deploying High Availability Architecture on Oracle Cloud Infrastructure (must read)
  16. OCI API Documentation 

Friday, January 18, 2019

OCI―Knowing File Storage Service Basics

Video 1.  OCI Level 100 - File Storage (Demo starts at 23:00)


Oracle Cloud Infrastructure (OCI) File Storage Service (FSS) is a managed file storage service that
  • Provides a durable, scalable, distributed, enterprise-grade network file system.
    • Using industry-standard Network File System (NFSv3) file access protocols and file system semantics
    • You can start with a file system that contains only a few kilobytes (KB) of data and scale to exabytes (EB) of data without upfront provisioning. 
    • It protects your data by maintaining multiple replicas, providing transparent encryption, and enabling frequent snapshots.
  • Can be accessed concurrently by thousands of compute instances
    • You can connect to a FSS file system from any bare metal, virtual machine, or container instance in your Virtual Cloud Network (VCN)
    • You can also access a file system from outside the VCN using Oracle Cloud Infrastructure FastConnect and Internet Protocol security (IPSec) virtual private network (VPN)


FSS Security


You create users and groups in OCI. Then, you can use policies to specify which users and groups can create, access, or modify resources such as file systems, mount targets, and export options.

There are four distinct and separate layers of security to consider when using the FSS. Each layer has its own authorization entities and methods which are separate from the other layers.

This security layer...Uses these...To control actions like...
IAM ServiceOCI Users and policiesCreating instances (NFS clients) and VCNs. Creating, listing, and associating file systems and mount targets.
Network SecurityIP addresses, CIDR blocks, security listsConnecting the client instance to the mount target. This is on an ‘all or nothing’ basis - the client either can or cannot access the mount target, and therefore all file systems associated with it.
NFS export optionsFile system exports, IP addresses, Unix usersApplying access control per-file system based on source IP CIDR blocks that bridges the Security Lists layer and the NFS v.3 Unix Security layer. See Working with NFS Export Options to specify granular controls on a per-file system basis.
NFS v.3 Unix securityUnix users, file mode bitsMounting file systems, reading and writing files.

Unix User ≠ OCI User

Remember that users in UNIX aren’t the same as users in OCI - they’re not linked or associated in any way. The OCI policy layer doesn’t govern anything that happens inside the file system, the UNIX security layer does. Conversely, the UNIX security layer doesn’t govern creating file systems or mount targets in OCI.

Mount Target


Mount Target is an NFS endpoint that lives in a subnet.  It has the following features:
  • Must be in the same availability domain as the file system.
    • When you create a file system, you can create a mount target or use an existing one.
  • Each mount target has an export set
    • A collection of one or more exports that control what file systems the mount target exports using NFSv3 protocol and how those file systems are found using the NFS mount protocol. 
    • The information stored in an export includes the file system OCID, export path, and export options. For more information, see Working with NFS Export Options.
    • Exports and export sets are managed through the Console by the FSS. More advanced configuration options for exports and export sets are available in the Command Line Interface (CLI) and API.
  • Provides the IP address or DNS name that is used in the mount command when connecting NFS clients to the FSS. 
  • Requires three private IP addresses in the subnet (don't use /30 or smaller subnets for the FSS)
  • Should be placed in its own subnet
    • Placing NFS clients and mount target in the same subnet can result in IP conflicts, as users are not shown which private IP;s are used for mount target.
  • Mount Target Limits
    • By default, you can create two mount targets per account per availability domain.

File System


File System is a way that your Compute instances use to organize files on your storage.  You can create a shared file system in the cloud using the FSS.  To access your file systems, you need to create a new (or use an existing) mount target.

When you use the Cloud Console, creating a file system also creates a mount target that your Compute instances use to access and write to the file system.   Once set up, file systems can be accessed from any OCI BM/VM instance in the same or other regions.  They can also be accessed from your on-premise environment using FastConnect or IPSec VPN.[3]

1 Mount Target : N File systems

Using the API or the Command Line Interface (CLI), you can create file systems and mount targets independently of each other.  Both file systems and mount targets are associated with an availability domain.

Once a mount target is created, multiple file systems can be associated with it. You can create up to 100 file systems per mount target.  However, no two file systems associated with the same mount target can have overlapping export path (e.g., FS paths like /example and /example/path are not allowed)

Paths in File Systems


In the discussions below, we will use this mount command example:
sudo mount 10.0.0.6:/example/path /mnt/mountpointA 
where  
10.0.0.6 is the mount target IP address and /example/path is the export path
There are three kinds of paths that are used in the FSS:
  • Export Paths
    • Specified when a file system is associated with a mount target
    • Appended to the mount target IP address, and used to mount (logically attach) to the file system
    • Used only to distinguish one file system from another within a single mount target
    • Syntax Rules
      • Must start with a slash (/) followed by a sequence of zero or more slash-separated elements.
      • Cannot end in a slash
      • Cannot be a period (.) or two periods in sequence (..)
      • Cannot exceed 255 bytes
  • Mount Point Paths
    • Are paths within a client instance to a locally accessible directory to which the remote file system is mounted
    • /mnt/mountpointA is the path to the directory on the client instance on which the external file system is mounted.
  • File System Paths
    • Are paths to directories within the file system, and contain the contents of the file system. 
    • For example, snapshots of the file system can be accessed using the file system path, under the file system's root directory at .snapshot/name.
      • The following example shows the path to a snapshot called 'January 1' when navigating from the instance:
        • /mnt/mountpointA/.snapshot/January1

Creating a File System


Follow these steps to create a File System on OCI:
  1. From the Core Infrastructure, select File Storage. 
  2. Choose a compartment in which you have permission to work. 
  3. Click Create File System. 
  4. In the Create File System dialog box, provide the following information: 
    • Enter a name for the File System. 
    • Choose an availability domain. 
    • Choose Edit Details for Mount Target
      • Choose CREATE MOUNT TARGET (or you can SELECT AN EXISTING MOUNT TARGET)
        • Enter a name for the Mount Target 
        • Choose a VCN for Mount Target
        • Choose a subnet for Mount Target (e.g., FSS-subnet as in the video)
      • Click Show Advanced Options
        • Before you can mount this file system, you must configure security rules to allow traffic to subnet FSS-subnet.  
        • Choose IP ADDRESS
        • Choose HOSTNAME
        • Choose PATH
          • Path name cannot be currently in use in the Mount Target
        • Choose MAXIMUM FREE SPACE (IN GiB)
  5. Click Create File System.

Configuration Details
  • File System Information
  • Mount Target Information
    • File systems must be associated with a mount target in order to be mounted by any instance.
    • By default, the mount target is created in your current compartment.
    • The mount target must be in the same availability domain as the file system. You cannot change the availability domain.
    • Virtual Cloud Network
      • The first VCN listed in the selected compartment is used as default.
    • Subnet
      • The first subnet listed in the selected availability domain is used as default.
      • FSS requires ingress TCP ports 111, 2048,2049, and 2050, in addition to standard ingress UDP ports 111 and 2048.  Opening these ports enables traffic from Solaris, Linux, and Windows instances.  Read Configuring VCN Security List Rules for File Storage for more information.
      • Don't place NFS client(s) and mount target in the same subnet
    • IP Address (Optional)
      • You can specify an unused, local, private IP address, for example, between 10.0.0.2 and 10.0.0.254 for the new mount target.
    • Hostname (Optional)
      • You can specify a hostname you want to assign to the mount target.
      • Which will be used to created a fully qualified domain name (FQDN) which cannot be changed in this dialog.
    • Path Name (Optional)
      • You can replace the default export path (default path using new file system's name) with a new one.
    • Maximum Free Space (in GiB; Optional)
      • Specifies the maximum free space (default: 8 exabytes) reported to applications by the FSS.
        • Some applications fail to install because a capacity check reports too much available capacity (i.e. the default 8 exabytes). 
        • Setting the Maximum Free Space reported as available to a value acceptable by your application prevents this issue. 
      • Setting the maximum free space affects each file system associated with the mount target. 
      • Setting the maximum free space does not limit the amount of data you can store.
    • Export Options (Important)

Summary


File Storage Service is an AD-local service, available in all OCI regions and Availability Domains, which supports
  • NFS v.3
  • Network Lock Management (NLM) for file locking
  • Full POSIX semantics
  • Data Protection
    • Snapshot capabilities; 10,000 snapshots per file system
  • Security
    • 128-bit, data-at-rest encryption for all file systems & metadata
  • Management Options
You can create 100 file systems and 2 mount targets per AD per account.  But you can request an increase. See Service Limits for a list of applicable limits and instructions for requesting a limit increase.

Tuesday, January 15, 2019

OCI―Knowing Compute Service Basics

Video 1.  OCI Core 100 - Compute (Demo starts at 24:00)

Oracle Cloud Infrastructure (OCI) Compute Service lets you provision and manage compute hosts,  known as instances.  

Instance Type


OCI offers two types of instances:
  • Bare Metal
    • Gives you dedicated physical server access (single-tenant model) for highest performance and strong isolation
    • Allows direct hardware access with all the security, capabilities, elasticity and scalability of OCI
  • Virtual Machine
    • A hypervisor to virtualize the underlying Bare Metal server into smaller VMs (multi-tenant model)
      • The virtualization makes it possible to run multiple VMs that are isolated from each other
      • VMs are ideal for running applications that do not require the performance and resources (CPU, memory, network bandwidth, storage) of an entire physical machine
Both types of instances are run on the same OCI stacks.


Figure 1.  Bare Metal Instances
Figure 2.  VM Standard Instances (Intel X7 & AMD)
Figure 3.  VM Dense I/O Instances
Figure 4.  GPU Instances (BM and VM)

Instance Shape


A shape is a template that determines the number of CPUs, amount of memory, and other resources allocated to a newly created instance.  OCI Compute Service enables you to select from a range of predefined shapes for both Bare Metal (BM) and Virtual Machine (VM) instances (see Figure 1-4):
  • Compute Standard E2 is based on AMD EPYCTM processor
  • 2 x 25 Gbps implies two NIC cards with 25 Gbps bandwidth
  • Network bandwidth is based on expected bandwidth for traffic within a VCN
  • Max vNICs numbers are for Linux
  • GPU (Nvdia)[2]
    • Volta is based on Tesla Volta GPUs
    • Pascal is based on Tesla Pascal GPUs
  • VM standard vs VM Dense IO shapes
    • VM Dense IO will provide NVMe drivers and VM Standard will provide block storage only

Figure 5.  Image Tab for Selecting the Image Build (highlighted: Oracle Images)

Instance Image


An image is a template of a virtual hard drive. The image determines the operating system and other software for an instance. 

On the Image tab (see Figure 5) you can optionally change the image build. By default, the latest build of the image is used to create the instance. You can select an older build of the image that is compatible with the shape you selected. Only compatible image builds are displayed in the list. You need to select a shape before you can change the image build.

The following images of different categories can be browsed on OCI Console:
  • Platform Images
    • Pre-built images for Oracle Linux, Microsoft Windows, Ubuntu and CentOS
      • Linux Images
        • Default set of firewall rules allow only SSH access (port 22)
          • Users (e.g. opc for Oracle/CentOS or ubuntu for Ubuntu) with sudo privileges are created automatically for instances and are configured for remote access over the SSH v2
        • Provide a startup script using cloud-init
      • Windows Images
        • User name opc created automatically with an one-time password
        • Include the Windows Update utility to get the latest Windows updates from Microsoft
    • See Oracle-provided images for more information
  • Oracle Images
    • Pre-built Oracle enterprise images and solutions enabled for OCI
  • Partner Images
    • Trusted third-party images published by Oracle partners
  • Custom Images
    • Custom images created (from an instance's boot disk) or imported into your OCI environment.  
      • When you create an image of a running instance, the instance shuts down and remains unavailable for several minutes. When the process is complete, the instance restarts.
      • Instances you launch from your custom image include customization, configuration, and software installed when you create the image
      • Custom images do not include the data from any attached block volumes
      • A custom image cannot exceed 300 GB
    • See Managing Custom Images for more details.
  • Boot Volumes
  • Image OCID
Image Import/Export
Read this Oracle whitepaper for more details.

Creating an Instance from a Custom Image


Follow these steps to launch a virtual machine instance on OCI by using a previously created custom image:
  1. From the Compute tab, select Instances. 
  2. Choose a compartment in which you have permission to work. 
  3. Click Create Instance. 
  4. In the Create Instance dialog box, provide the following information: 
    • Enter a name for the instance. 
    • Choose an availability domain. 
    • Choose Change Image Source
    • Choose Custom Image as the boot volume. 
    • Choose the custom image to use. 
    • Choose Virtual Machine as the instance type.
    • Choose a shape (only compatible shapes are available). 
    • Configure Boot Volume
      • You can change boot volume size and/or choose a key from Key Management to encrypt this volume
    • Choose to upload or paste SSH keys (public keys). 
    • Choose a VCN. 
    • Choose a subnet. 
  5. Click Create Instance.

Configuration Details
  • Name
    • You can add or change instance name later. The name doesn't need to be unique; an Oracle Cloud Identifier (OCID) uniquely identifies the instance.
  • Availability domain 
  • Image Source
    • When you click Change Image Source, the Browse All Images dialog opens with the operating system or image source options. The following options are available:
      • Platform Images, Partner Images, Oracle Images, Custom Images, Boot Volumes, Image OCID
  • Instance Type
    • Select Virtual Machine or Bare Metal Machine.
  • Instance Shape
    • When you click Change Shape, the Browse All Shapes dialog opens and is populated with the list of available VM or bare metal shapes based on what you selected for instance type.
    • See Compute Shapes for a list of the available bare metal and VM shapes. 
  • Boot Volume Size
    • The specified size must be larger than the selected image's default boot volume size.
    • See Custom Boot Volume Sizes for more information.
  • Encryption
    • Boot volumes are encrypted by default but you can optionally encrypt the data in this volume using your own Key Management encryption key. 
    • See Overview of Key Management for more information.
  • SSH key
    • The public key portion of the key pair you want to use for SSH access to the instance. 
  • Virtual Cloud Network Compartment
    • The compartment containing the network in which to create the instance.
  • Virtual Cloud Network
    • The network in which to create the instance.
  • Subnet Compartment
    • The compartment containing a subnet within the cloud network to attach the instance to.
  • Subnet
    • A subnet within the cloud network to attach the instance to. 
    • The subnets are either public or private. 
      • Private means the instances in that subnet can't have public IP addresses. 
    • For more information, see Access to the Internet.
  • Fault Domain (Advanced Options)
    • If you do not specify the fault domain, the system selects one for you. 
    • Once the instance has been created, if you want to change the fault domain you need to terminate the instance and launch a new instance in the preferred fault domain. 
    • For more information, see Fault Domains and Best Practices for Your Compute Instance. 
  • User Data (Advanced Options)
    • Data to be used by Cloud-Init to run custom scripts or provide custom Cloud-Init configuration. 
    • The file or script does not need to be base64-encoded, as the Console performs this encoding when the information is submitted. For information about how to take advantage of user data, see the Cloud-Init Documentation.
  • Tags (Optional)
    • To apply a defined tag, you must have permissions to use the tag namespace. 
    • For more information about tagging, see Resource Tags. 
  • Instance Configuration(Optional)[5]
    • Instance configurations allow you to define the configuration to use when creating Compute instances as part of an instance pool.
    • See Managing Compute Instances for more information.
  • VNIC (Optional)
    • A VNIC enables an instance to connect to a VCN and determines how the instance connects with endpoints inside and outside the VCN. 
    • Each instance automatically comes with a primary VNIC, and you can add secondary ones.
    • See Virtual Network Interface Cards (VNICs) for more information.
  • Console Connection (Optional)
  • Attached Block Volume (Optional)
    • You can attach  a block volume to an instance in order to expand the available storage on the instance. 
    • See Attaching a Volume for more information.

References

  1. Compute Service (OCI)
  2. General Availability of Virtual Machines with NVIDIA GPUs on Oracle Cloud Infrastructure
  3. Deploying Custom Operating System Images onOracle Cloud Infrastructure
  4. Oracle Cloud Infrastructure―OCI Key Management Basics
  5. Creating an Instance Configuration (OCI)
  6. Fault Domains (OCI)
  7. Best Practices for Your Compute Instance (OCI)
  8. Cloud-Init Documentation (OCI)

Monday, January 14, 2019

OCI―Knowing Block Volume Service Basics

Video 1.  OCI Level 100 - Block Volume (Demo starts at 27:00)

Oracle Cloud Infrastructure (OCI ) offers two main storage services:
  • Block Volume Service
    • Integrates with IAM for authentication and authorization, for all interfaces (the Console, SDK or CLI, and REST API)
    • Block storage operates at the raw storage device level and manages data as a set of numbered, fixed-size blocks using protocols such as iSCSI
    • Block Volume Service lets you dynamically provision and manage block storage volumes
    • Block Volume uses the Advanced Encryption Standard (AES) algorithm with 256 bit key for encryption
      • Data is encrypted at rest in both volumes and backups
    • You can create, attach, connect, and move volumes, as needed, to meet your storage and application requirements
      • Once attached and connected to an instance, you can use a volume like a regular hard drive
      • Volumes can also be disconnected and attached to another instance without the loss of data
      • Volumes are only accessible to instances in the same Availability Domain (AD) 
        • You cannot move a volume between availability domains or regions
        • However, block volume backups can be restored as new volumes to any availability domain within the same region they are stored
  • Object Storage Service 
    • See [1] for more details
In this article, we will cover Block Volume Service.  But, before we start, we will begin with a related OCI Storage Option―local NVMe SSD.

Figure 1.  OCI Storage 


Local NVMe SSD Storage


OCI provides a variety of instance configurations in both bare metal (BM) and virtual machine (VM) shapes. Each shape varies on multiple dimensions including memory, CPU cores, network bandwidth, and the option of local NVMe SSD storage found in Dense IO shapes.

NVMe SSD Devices are locally attached to some instance shapes in OCI.  It has the following features:
  • It can be used for workloads (e.g., Big Data, OLTP) requiring high storage performance 
  • Data are persisted during reboot or pause
  • These devices are not protected 
    • Customers are responsible to protect and manage the durability the data on these devices
    • A protected RAID array is the recommended way to protect against an NVMe device failure. There are three RAID levels that can be used for the majority of workloads:
      • RAID 1
        • Blocks mirrored
      • RAID 10
        • Blocks mirrored and striped
      • RAID 6
        • Blocks striped with dual parity across drives
  • OCI provides a service-level agreement (SLA) for NVMe performance

Block Volume Service


A common usage of Block Volume Service is to add storage capacity to an instance.  Block volumes provide you persistent and durable storage.  All volumes are automatically replicated for you, helping to protect against data loss.  Any data will remain intact until you reformat or delete the volume.  There are two types of volumes:
  • Block volume
    • A detachable block storage device for your data storage
  • Boot Volumes
    • Detachable system disks for your Compute instances
    • When you terminate an instance, you can keep the associated boot volume and use it to launch a new instance using a different instance type or shape
To use a block storage volume, you need to follow below four steps:
  1. Create a block storage volume through the console (see Figure 3) or the API 
  2. Attach the volume to an instance using a volume attachment (See Figure 2)
  3. Connect to the volume from your instance's guest OS using iSCSI 
  4. Mount the volume and use within your instance

Figure 2.  Attach Block Volume

Backup Policy (Options in Step 1)


The OCI Block Volume service provides you with the capability to perform volume backups automatically on a schedule and retain them based on the selected backup policy. Each backup policy has a set backup frequency and retention period.  This allows you to adhere to your data compliance and regulatory requirements.  See Overview of Block Volume Backups for more information.

When you create a new volume on OCI, you can select the appropriate backup policy at that time:
  • None
    • If your requirements change
      • You can adjust the schedule and retention period by selecting a different backup policy
      • You can also do manual backups
  • Bronze 
    • Monthly incremental backups
      • Run on the first day of the month. Incremental backups are retained for 12 months
    • Yearly full backup
      • Run yearly on January 1st. Full backups are retained for 5 years
  • Silver 
    • Weakly incremental backups
      • Run on Sunday.  Incremental backups are retained for 4 weeks
    • Monthly full backup
      • Run on the first day of the month and are retained for 12 months 
    • Yearly full backup
      • Run yearly on January 1st. Full backups are retained for 5 years
  • Gold 
    • Daily incremental backups
      • Incremental backups are retained for 7 days
    • Weakly incremental backups
      • Run on Sunday.  Incremental backups are retained for 5 weeks
    • Monthly full backup
      • Run on the first day of the month and are retained for 12 months 
    • Yearly full backup
      • Run yearly on January 1st. Full backups are retained for 5 years

iSCSI vs Paravirtualized (Options in Step 2)


At step 2, you can choose how to attach your block volume in two ways:
  • iSCSI
    • A TCP/IP-based standard used for communication between a volume and attached instance
    • Are the only option when connecting block volumes to 
      • Bare metal instances
      • VM instances based on Windows images published prior to February 2018
      • VM instances based on Linux images published prior to December 2017. 
  • Paravirtualized
    • A virtualized attachment available for VMs
    • Once you attach a volume using the paravirtualized attachment type, it is ready to use, you do not need to run any additional commands. 
    • However, due to the overhead of virtualization, this reduces the maximum IOPS performance for larger block volumes
Note that you should only attach Linux volumes to Linux instances and Windows volumes to Windows instances.

Step 3 and 4


You connect (step 3) or mount (step 4) block volumes differently based on below considerations:
  • Volume Attachment Type
    • Paravirtualized
      • The volumes are connected automatically
      • iSCSI
    • OS Type
      • Linux-Based Instances
        • On Linux operating systems, the order in which volumes are attached is non-deterministic, so it can change with each reboot
          • If you refer to a volume using the device name, such as /dev/sdb, and you have more than one non-root volume, you can't guarantee that the volume you intend to mount for a specific device name will be the volume mounted
        • If you want to mount automatically volumes on instance boot, you need to set some specific options in the /etc/fstab file, or the instance may fail to launch. This applies to both iSCSI and paravirtualized attachment types. 
        • Consistent Device Path
      • Windows-Based Instances

    Figure 3.  Create Block Volume


    References

    1. OCI―Knowing Object Storage Basics
    2. Protecting Data on NVMe Devices
    3. OCI―Knowing Identity and Access Management Basics (XML and More)
    4. Backing up a volume (OCI)
    5. Overview of Block Volume Backups (OCI)
      • Backups are encrypted and stored in the Object Storage Service, and can be restored as new volumes to any Availability Domain within the same region
    6. Connecting to Volumes With Consistent Device Paths (OCI)
    7. Cloning a Volume (OCI)
      • Cloning enables you to make a copy of an existing block volume without needing to go through the backup and restore process
    8. Block Volume Performance (OCI)
    9. Volume Groups (OCI)
    10. What is iSCSI?
    11. Oracle Linux Administrator's Guide for Release 7 - About iSCSI Storage
    12. Oracle Linux Administrator's Guide for Release 6 - About iSCSI Storage
    13. Troubleshooting iSCSI Configuration Problems
    14. iscsiadm Basics

    Saturday, January 12, 2019

    OCI―Knowing Virtual Cloud Network Basics

    An Oracle Cloud Infrastructure (OCI) Virtual Cloud Network (VCN) is a virtual version of a traditional network on which your instances run.

    Video 1.  OCI Level 100 - Virtual Cloud Network (YouTube link)

    Key Features of VCN


    Virtual Cloud Network resides within a single region but can cross multiple Availability Domains and it has the following key features:
    • Includes subnets, route tables, security lists, and gateways
    • Covers a single, contiguous IPv4 CIDR block of your choice
    • Supports either private IP address ranges or a publicly routable range
      • Oracle recommends using one of the private IP address ranges in RFC 1918 (10.0.0.0/8, 172.16/12, and 192.168/16) for VCN address space.  However, you can use a publicly routable range
    • Allows VCN size range to be from /16 to /30
      • VCN reserves the first two IP addresses and the last one in each subnet's CIDR
    To create a VCN refer to section "Task1: Set up the VCN and Subnet" in the document OCI VCN with Public and Private Subnet.  To peer your on-premise network with OCI VCN, you must whitelist for the public endpoint.  Refer to this document and peer using either VPN Connect or FastConnect.

    Figure 1. Overview of VCN Key Components

    Default VCN Components


    Your VCN automatically comes with some default components:
    • Default route table, with no rules
    • Default security list, with default rules
    • Default set of DHCP options, with default values
    You can’t delete these default components; however, you can change their contents (for example: individual route rules). And you can create more of each kind of component in your VCN (for example: additional route tables). 

    Subnets


    Each VCN network is subdivided into subnets, and each subnet is contained within a single Availability Domain.  But, you can have more than one subnet in an AD for a given VCN.

    Each subnet has the following features:
    • It acts as a unit of configuration
      • All instances in a given subnet use the same route table, security lists, and DHCP options
      • Instances draw their internal IP address and network configuration from their subnet
      • Subnets can have one route table and up to 5 security lists associated with it
    • It has a contiguous range of IPs
      • Subnet IP ranges may not overlap
      • IP ranges are described in CIDR notation
    • It contains virtual network interface cards (VNICs), which attach to instances
      • You can add secondary VNICs to an existing instance and remove them as you like.  
      • All the VNICs must be in subnets in the same availability domain as the instance.
    • It can be designated as either Public or Private
      • Private subnet doesn't have access to Internet

    Figure 2.  Internet Gateway (IGW) and Dynamic Routing Gateway (DRG)

    Figure 3. IPSec VPN Overview
    Figure 4. IPSec VPN vs FastConnect



    Gateways


    Read below article for more information:
    OCI―Knowing Gateway Basics

    Security List


    When you create a subnet, you may optionally specify one or more security lists for the subnet to use (up to five). You can change which security list the subnet uses at any time. 

    Security list is a common set of firewall rules associated with a subnet and applied to all instances launched inside the subnet. Each security list has the following features:
    • Provides ingress and egress rules 
      • Which specify the types of traffic allowed in and out of the instances
    • Rules can be either stateful (default) or stateless
      • Stateful security lists
        • When an instance receives traffic matching the stateful ingress rule, the response is tracked and automatically allowed regardless of any egress rules
        • Similarly for sending traffic from the host.
      • Stateless security lists
        • Response traffic is not automatically allowed
          • To allow the response traffic for a stateless ingress rule, you must create a corresponding stateless egress rule
        • Are better for scenarios with large numbers of connections
    Default Security List

    If you don't specify any security list for a subnet, the subnet uses the VCN's default security list which has the following features:
    • Allows TCP traffic on destination port 22 (SSH) from source 0.0.0.0/0 and any source port
      • Makes it easy for you to create a new cloud network and public subnet, launch a Linux instance, and then immediately connect through SSH to that instance without needing to write any security list rules yourself
    • Allows ICMP traffic type 3 code 4 from source 0.0.0.0/0 and any source port
    • Allows ICMP traffic type 3 (all codes) from your VCN's CIDR IPs and any source port.
      • Makes it easy for your instances to receive connectivity error messages from other instances within the VCN
    • Allows all outgoing traffic
      • Makes it easy for your instances talk to any Internet IP address if the cloud network has an Internet Gateway

    Route Table


    When you create a subnet, you may optionally specify a route table for the subnet to use. If you don't, the subnet uses the cloud network's default route table. You can change which route table the subnet uses at any time.

    Each route table has the following features:
    • Has a set of route rules 
      • Which provide mapping for the traffic from subnets through gateways (represented by route target) to destinations (represented by CIDR blocks) outside the VCN
      • Route table at a subnet is used only if the destination IP address is not within the VCN's CIDR block
        • No route rules are required in order to enable traffic within the VCN itself
      • Each rule specifies 
    For example, to configure your VCN to route all Oracle Service access via Service Gateway, refer to Access to Oracle Services via ServiceGateway.

    DHCP Options (DNS)


    When you create a subnet, you may optionally specify choices for DNS name resolution using the subnet's set of DHCP options.  Domain Name System (DNS) lets computers use hostnames instead of IP addresses to communicate with each other.[1]

    You can choose the DNS for each subnet from two options
    • Internet and VCN Resolver (Default) 
      • This is an Oracle-provided option that includes two parts: 
        • Internet Resolver
          • Lets instances use host names that are publicly published on the Internet.
          • The instances do not need to have Internet access by way of either an IGW or an IPSec VPN DRG. 
        • VCN Resolver
          • Lets instances use host names (which you can assign) to communicate with other instances in the VCN.
    • Custom Resolver
      • Use your own DNS servers. 
        • These could be Internet IP addresses for DNS servers in your VCN, or DNS servers in your on-premises network, which is connected to your VCN by way of an IPSec VPN
    Note that you can't change which set of DHCP options is associated with a subnet after the subnet is created. If you don't want to use the default set, make sure to create your desired set of DHCP options before creating the subnet. However, you can still change the values of these options at your discretion. For more details, see Important Notes about Your Instances and DHCP Options.

    Video 2. OCI Level 100 - Connectivity (YouTube link)

    References

    1. Oracle Cloud Infrastructure―OCI DNS Service Basics
    2. Virtual Cloud Network Overview and Deployment Guide
    3. Oracle Cloud Infrastructure Fundamentals
    4. FastConnect Partners
    5. IPSec VPN Overview
    6. Configuring Your CPE (OCI)
    7. Oracle’s Next Generation Cloud Infrastructure
      • Off-box virtualization: storage and network IO virtualization is put out into the network
    8. Best Practices for Deploying High Availability Architecture on Oracle Cloud Infrastructure (must read)
    9. Access to Your On-Premises Network (OCI)
    10. Hybrid DNS Configuration (OCI)
      • This document describes the process to enable resolution of DNS names of instances in the VCN from on-premises clients and vice-versa, when the on-premises datacenter is connected with the VCN (through VPN or FastConnect).
    11. Oracle Cloud Infrastructure―OCI DNS Service Basics
    12. OCI―Knowing Gateway Basics

    © Travel for Life Guide. All Rights Reserved.

    Analytical Insights on Health, Culture, and Security.