Latest Posts

Get your Oracle 18c Instance in the Oracle Infrastructure Cloud OCI Classic

Do you want to work with Oracle 18c in the Oracle Cloud but the database version is not selectable in the webinterface? You can create an 18c instance in the command-line interface with the PaaS Service Manager (psm). The installation is very well described here, for example you need Python and OpenSSL. My personal installation of the psm executable runs in the Windows 10 integrated Ubuntu system.

Link to the PaaS Service Manager: https://docs.oracle.com/en/cloud/paas/java-cloud/pscli/abouit-paas-service-manager-command-line-interface.html

After the successful psm setup, you can create an DBaaS instance with this command

The file db18c-ee.json contains all the information you need to create an 18c instance. Here is my example – I have created a cloud storage container called dbcsbackup in advance because I want to use the OCI backup service.

Some minutes later you can login by terminal and user SQL*Plus. Oracle 18c: Here we are!

And in the OCI dashboard it looks fine too.

Addtional Info: If you want a Standard Edition, just replace the line „edition“: „SE“, happy 18c.

 

Alexa: Storen Büro schliessen – Teil 1

Angefangen hat alles mit einem WLAN-fähigen Storenschalter, und als später noch mit Amazon Echo Dot Alexa den Weg in mein Büro zuhause fand war die Sache klar: Ich will meine Storen im Büro mit Alexa steuern können. In der Schweiz sind Storen übrigens nichts anderes als Rolladen. Was mit der Suche nach neuen Smart Home Komponenten begonnen hat, endete im Programmieren von Alexa Skills. In diesem Blogeintrag will ich aufzeigen was eingesetzt werden kann, um Smart Home Geräte welche eine REST API Schnittstelle besitzen via Alexa Sprachkommando steuern zu können. Bei meinem Projekt habe ich nicht unmittelbar mit dem Programmieren vom Alexa Skill begonnen, sondern ich habe am Ende beim Storenschalter begonnen und mich nach vorne vorgearbeitet. Spassfaktor: hoch, Lernkurve: steil.

Heimautomation muss her

Auf der Suche nach neuen Komponenten für Heimautomation bin ich auf das Produkt zeptrionAIR der Schweizer Firma Feller gestossen. zeptrionAIR ist die Produktbezeichnung für wireless-fähige Schalter für die Steuerung von Licht und Storen. Mir gefällt an diesem Produkt, das die Produkte zwar mit einer App steuerbar sind, aber von Haus aus keinerlei Verbindung in irgendeine Cloud haben. Zudem können die Geräte via REST API angesteuert werden. Zuhause habe ich bereits Feller-Schalter und Steckdosen installiert, die WLAN-Module passen in die bestehenden Dosen. Die Module benötigen einen einen Pol- und einen Neutralleiter und werden hinter der Schalterabdeckung platziert. Die Schalterabdeckungen können mit beliebigen Funktionen und Szenarien bestückt werden.

Testaufbau

Mein Elektriker hat den Storenschalter im Büro mit einem zeptrionAIR Schalter ausgetauscht, den neuen Schalter habe ich mit folgenden Funktionen programmiert:

  • Storen hoch/runter
  • Szenario 1: Storen halb hoch
  • Szenario 2: Storen ganz unten, Lamellen 1/3 offen

Die Einrichtung via App und die Anbindung ans WLAN ging problemlos, die von Feller mitgelieferte Anleitung ist gut aufgebaut und leicht verständlich. Via Online-Formular kann beim Feller Kundendienst die API-Dokumentation kostenlos bestellt werden. Darin werden alle Möglichkeiten aufgezeigt, mit REST Kommandi die Komponenten zu steuern.

REST API Beispiel: zeptrionAIR Storen schliessen mit curl:

Das Kommando beinhaltet nebst der IP-Adresse der zeptrionAIR Komponente den Kanal / Schalter welchen man ansteuern will und welche Funktion ausgeführt werden soll (cmd=close).

Via Amazon Cloud zurück nach Kestenholz / Jürasüdfuss / Schweiz

Das Alexa Sprachkommando wandert zuerst in die Amazon Cloud und wird auch dort verarbeitet. Mein Storenschalter ist aber nur lokal ansteuerbar. Das erfordert einen entsprechenden Aufbau. Für die Kommunikation mit der Cloud und meinem Zuhause habe ich diese Komponenten eingesetzt:

  • Amazon Echo Dot: „Meine Alexa“ zuhause im Büro (lokal)
  • AWS Lambda: Nimmt das Sprachkommando von Echo Dot entgegen, prüft die Korrektheit (Cloud)
  • AWS IoT: MQTT Broker (Cloud)
  • NodeRed: IoT Baukasten, läuft auf einem lokalen Raspberry Pi3 (lokal)
  • zeptrionAIR: Storenschalter (lokal)

Der Ablauf:

  1. Echo Dot nimmt den Sprachbefehl entgegen, beispielsweise „Storen Büro schliessen“
  2. AWS Lambda prüft den Sprachbefehl und schickt eine Message an AWS IoT (MQTT Broker)
  3. Node-Red auf den lokalen Raspberry PI liest regelmässig die Messages aus der AWS IoT Queue
  4. Die neuen Messages werden auf Textinhalt ausgewertet und das entsprechende Kommando an zeptrionAIR gesendet

Soweit die Ausgangslage. In einem zweiten Teil werde ich euch die Installation und Konfiguration von Node-Red und das Zusammenspiel mit Amazon AWS IoT erläutern.

Oracle Cloud Infrastructure Storage Software Appliance – Installation and Configuration

The Oracle Cloud Infrastructure Storage Software Appliance – also known as Oracle Storage Cloud Software Appliance OSCSA – acts as a gateway between classic storage and the Oracle Cloud Infrastructure Object Storage Service. The appliance can be installed on an on-premises Linux system or in an Oracle Compute Cloud machine and runs in a Docker container. It offers a local cache where clients can place their files before the OSCSA moves them into the Storage Service. The communication between a client with a filesystem to the OSCSA works with NFSv4, from the OSCSA to the Object Storage Service, Oracle is using their REST interface. Traffic from the OSCSA to and from the Oracle cloud can be encrypted and compressed.

In this blog post first I will show you how you can install and configure the OSCSA in an on-premises environment. In a second step I configure an on-premises database server which uses the Object Storage Service as Oracle RMAN backup location.

Key Features

  • Compression and Exncryption
  • File Versioning
  • End-to-end Data Integrity with Checksum Verification
  • Support for Data Archival (Oracle Storage Archive Class)
  • Pin files to the appliance cache for faster access

Where to get the OSCSA and more Information

Requirements

  • Two dual-core CPUs (4-core CPUs recommended)
  • Minimum memory requirements (based on the maximum number of files that can be uploaded to the appliance filesystem):
    • 16 GB for filesystems up to 1 million files
    • 32 GB for filesystems up to 5 million files
    • 64 GB for filesystems up to 10 million file
  • Minimum disk size required to install Docker: 10 GB
  • Oracle Linux 7 with UEK Release 4 or later
  • Docker 1.12.6
  • NFS version 4.0

The installation and configuration of the required Oracle Linux components OL7 with UEK4, Docker and NFS is very well described in the „Using Oracle…“ guide. Please take a look in the guide, it’s straight forward. The OSCSA installer does not start when the requirements are not fullfilled. 

My Test Environment

OSCSA breitenbach.martinberger.local Oracle Linux 7.4 100GB Storage
Database Server zuchwil.martinberger.local Oracle Linux 7.4 Oracle RDBMS 12.1.0.2
Traditional Cloud Account cloud.oracle.com Zone EM2 Oracle Cloud Infrastructure Object Storage Classic

Firewall

Port 32771 (Appliance Web Interface) ,  32772 (NFS) and 32773 (REST) have to be opened on the appliance machine. If you don’t want to use these port numbers, you can set them during the installation process. Execute as user root:

File Content

All installation steps are executed as OS user root. The Oracle Storage Cloud Software Appliance Software Release 16.3.1.3 is available on my local machine in folder /stage. The extracted OSCSA file contains a file called OSCSA_GATEWAY_README.txt where you can get more information about the installation and configuration possibilities like proxy etc.

Installation

The installation starts by executing oscsa-install.sh. I have added the parameter -a = advanced so I am able to set ports for NFS, Administrative Web Interface and REST. Oracle recommends for the cache storage a minimal size. I have ignored that for my test environment.

Appliance Start

Now the Oracle Storage Cloud Software Appliance can be started. A server reboot is not problem. The docker image will be started after server startup automatically.

 

Configure a OSCSA FileSystem in the Appliance Web Interface

In this step, the OSCSA will be connected to the Oracle Cloud. At the moment, no <OSCSA FileSystem name> is configured. An OSCSA  filesystem is like a namespace containing a set of data. Now we can log in into the Appliance Web Interface to create our first Object Storage filesystem. URL for the interface is https://<servername>:<port>. The port for the interface was set during the installation process.  

For the connection to the cloud, you need to know your Identity Domain, Username, Password and REST Storage Endpoint URL. The FileSystem name will be reused later for the NFS mount.

Create a FileSystem called OCIClassicStorage01

Enter Domain, Username, Password and REST Storage Endpoint URL. Below this screenshot you can see where you find the URL in your Traditional Cloud Account.

Here you can see the REST URL.

Click on Validate

If the account informations are verified, you are able to enable compression and encryption. I have enable encryption here. Click Save.

The OSCSA storage is now ready to synchronize with the cloud. Click Connect.

Now you can see the the connection between the Oracle Storage Cloud Software Appliance and the Oracle Cloud Infrastructure Object Storage Service is ready.

In the Traditonal Cloud Account in the Storage Classic dashboard is a new object storage filesystem available.

Connect the Database Server to the Oracle Storage Cloud Software Appliance

Let’s connect the database server to the OSCSA to store data in the Object Storage Service. First we check again on the OSCSA server if the service is running.

On the database server a new mountpoint will be created.

We mount the OSCSA with NFS v4 to the local server. This entry can be added later to autofs or whatever you use to automatically mount an NFS filesystem. Permission of the mountpoint is drwxrwxrwx – so everybody can write into it at the moment.

Check.

Execute an Oracle RMAN Backup to the Cloud

A new subdirectory on the NFS mountpoint will be created.

Start Oracle Recovery Manager RMAN database backup.

The backup files are created locally in the specified mountpoint directory.

At the moment where the backup sets are arrived on the mountpoint, the OSCSA begins to encrypt  (this was my selections during filesystem creation) and transfer them into the Oracle Cloud. This is visible in the Appliance Web Interface.

Now the files are uploaded into the Oracle Cloud. This can be verified in the Traditional Cloud Account in the specific filesystem. The files are encrypted and have file names like 10101-v1, 10103-v1 etc.

 

Anything else?

Sure, this was just a basic overview how to configure the on-premises Oracle Storage Cloud Software Appliance. There are many more features like retrieve data, cloud access via command line, preserve filesystem cache, create directory permissions, set user permissons, monitor the appliance, backup the appliance, encryption key handling, use the archive storage and so on which are worth to spend more time for investigation in the future.

Summary

The Oracle Storage Cloud Software Appliance is a nice piece of software which helps you to use the Oracle Cloud Infrastructure Object Storage Service. The appliance is easy to install and configure, local encryption is possible and the documentation is very good. Database Backups and Database Export a perfect candidates for this service. The price is hot, $0.0204 per GB for the first TB, and $0.0201 per GB for the next 49TB.

Thumbs up!