Configure and deploy Oracle NoSQL

When you are starting to use the Oracle NoSQL key-value store solution you are not done by simply installing the Oracle NoSQL database. Installing the database is quite simple and straightforward. It is a matter of deploying the software, run a commandline configuration wizard and start the NoSQL deamon. The next step before you can start using the NoSQL implementation is to configure your KVStore. During deployment you have created (most likely) a number of hosts running a NoSQL deployment. One of them is the KV Administrator node which runs a management webinterface on port 5001 (by default). Your first step should be to connect to this admin console.  The console will take you into a couple of steps.

In the above image you can see the first screen when you open the administrator console. You have to state 2 things. The Store name is a name your key-value store and you can select a meaningful name. Second part is to enter the datacenter name, this is the name of your physical datacenter and can be used to identify the location of your key-value store. You could however abuse this field for other information, for example the name of the customer or department using the key-value store.

As soon as you have completed the above step you will be presented with a screen similar to the screenshot above. On the right side of the screen you can see 3 steps are already completed with the state SUCCEEDED, namely; DeployDatacenterPlan, DeploySNPlan and DeplayAdminPlan. 

Next is to deploy storage nodes. You will have to do this for every hosts you would like to deploy a storageNode on. Do note that on your admin node you already have a storage node deployed. You have to provide some needed information.

Plan Name: The name of your plan, when directly deployed you can go for the default name, in case you want to store in and use it at a later stage it would make sense to give it a meaningful name.

Datacenter: state the datacenter you want to deploy your StorageNode

Host: The network host name of the host you want to deploy your StorageNode on. This should be a host where you have deployed a Oracle NoSQL stack.

Registry Port: The port number where your KVstore is running on the target host.
Comment (optional): as stated, optional.

Now you have the option to use the Create Plan option which will store you plan for later execution or do a Create and Execute Plan which will directly deploy your StorageNode. When directly executed you will see in the right side of your screen the progress and (hopefully) a message for Plan-4 DeploySNPlan with status SUCCEEDED.

Next step is to deploy a store (Key-value store) on top of your storage node cluster so you can really start to use your Oracle NoSQL implementation. In the same screen as you used to deploy a StorageNode you can now select “Deploy a Store”which will deploy the store for you on all storage nodes or a sub-set of the storage nodes. Some details have to be provided:

Plan Name: The name of your plan, when directly deployed you can go for the default name, in case you want to store in and use it at a later stage it would make sense to give it a meaningful name.

Storage Node Pool: In this case we have selected AllStorageNodes to deploy them on all nodes available.

Replication Factor: The replication factor is something you have to think about before you quickly state a number (currently in the above screenshot you see 3, in our real-life example we use 2 as we only have 2 nodes). Replication factor states how many times a partition of data is stored in the cluster. When stated 3 it means that at 3 locations in your cluster a copy of a partition is stored.

“The number of nodes belonging to a replication group is called its Replication Factor. The larger a group's Replication Factor, the faster its read performance (because there are more machines to service the read requests) but the slower its write performance (because there are more machines to which writes must be copied). You set the Replication Factor for the store, and then Oracle NoSQL Database makes sure the appropriate number of Replication Nodes are created for each replication group that your store contains.”

Number of partitions: Also named shards, this indicates the number of partitions you will chop your data into. A high number of partitions is good however if you have to many partitions this can again have a negative effect on your performance. Based upon the read/write intensity you have to check what the best number is for your setup.

When given all the parameters you can select “create plan” or “Create and Execute plan”

When you have deployed your store it can be good to check your entire setup of your cluster with the topology browser. Here you can see how your configuration is done and how things are arranged. This topology screen can also be used during day-to-day administration to get a good view of the current status of your NoSQL deployments.

Oracle Data Masking with Oracle Enterprise Manager

Commonly companies who are serious about IT and their IT infrastructure and their IT landscape do tend to a DTAP strategy. DTAP stands for Development, Test, Acceptance and Production environments. Commonly DTAP landscapes are used in environments where companies do create their own software or customizations on standard software. This means that for every production system you will have 3 separate environments to be used by developers, testers and the business to approve the changes before they will be deployed in your production environment.

In situations where multiple projects for the same production environments are done simultaneously it is not uncommon to have multiple DTA environments while having a single production environment. When you are working with multiple development projects at once it is of vital importance to have a correct version and configuration management in place to ensure that when the projects are combined in the single production instance it is able to work integrated and is not undoing some of the work done in the other project.

Almost as important as a good configuration and version management is the management of your none-production environments. This is not only the case when working with multiple projects and changes at the same time. This is evenly important when developing in a single DTA(P) setup.  Your developers and testers are in need of environments that are as close to the production situation as possible. Commonly production systems are cloned to Development, test and Acceptance environments to enable your developers and testers to do their job.

Technically it is a simple exercise to clone a production environment to a none-production environment. At least, this is the case for most Oracle products. Even though it is technically it is a simple exercise it can be a complicated exercise from a legal, risk and security perspective. Companies who do not pay attention to this process in their company can end up in the situation that confidential production data becomes available to developers. A developer for example working on customizations in the Oracle E-Business suite payroll modules can get access to the entire payroll information of your corporation. Secondly, when not paying attention your developers can gain access to production passwords as most developers have unlimited access to the application and database. An example of such an exploit on Oracle E-Business suite passwords can be found in my blogpost from December 2006. Currently most companies do understand that they have to reset production passwords during a clone before releasing it to developers and testers. The understanding of masking and/or sub-setting your production data before releasing it to none-production systems is however not that common. 

Next to changing passwords when you move your data from production to none-production systems you will have to consider the strategy on which data can be accessed by your developers which is not critical or confidential data. Oracle is providing a solution for this in the form of Oracle Data Masking solutions which are an integrated part of Oracle Enterprise Manager. By using Oracle data masking you can create profiles of your data and make sure confidential data is masked (changed to none confidential data) and you can do sub-setting.

As you can see in the above diagram you can create an Application Data Model in which you  can define which data has to be extracted from your production system. The extracted data will be pumped to the datamasking and/or subsetting 

Subsetting:
The intention of subsetting is to decrease the amount of data that is transported to your none-development environments. For example, in your Application Data Model you stated you want to extract all the information from your Order Management module. This will ensure that you get ALL the data from your Order Management module you have indicated that needs to be extracted. In subsetting you can define you would like to have for example only the orders from the past 2 months. In most cases your developers and testers do not need the full set of data to perform their job. This is not only resulting in shorter times to move the data it will also reduce the amount of storage needed in your none-production environments.

Datamasking:
The intention of datamasking is to ensure no confidential data is moved out of your production database to your none-production database. This is done while keeping the integrity of your data. For example, you might have customer creditcard numbers in your Order Management module data. You do not want this data to be moved and to be accessed by your developers and testers however you do want to have creditcard numbers with the same logic in it. You could for example have some logic in your application to check if the creditcard number is a valid number. Due to this reason you cannot simply substitute the original creditcard number with a random number, you want it to have the same structure as a official creditcard number. The same applies for example for social security numbers, zip-code information, etc etc.

In the above screenshot you can see the format library, here you can define the format of a to-be substituted value. You can define how a creditcard number should be formed. By using this you can substitute values by “random” values while keeping the integrity. This enables your developers and testers to work on production data which is made anonymous and where the confidential data is substituted by none-confidential data.

For some Oracle products there are standard libraries available, if you have a custom build application you will have to create your own strategy. Even though it takes some knowledge and effort to initially create this you will benefit from it and the security of your confidential data is not compromised.

The below video shows you an example of Oracle Data Masking while using Oracle Enterprise Manager 11G. Do keep in mind that a newer version of Oracle Enterprise Manager is currently available.

customize Oracle Enterprise Manager

When using Oracle Enterprise Manager in your organization it will most likely be used by a number of people with all different kind of roles and responsibilities. DBA’s will be interested in the information from the database at first hand, Technical Application Maintenance consultants will most likely be interested in how the middleware is doing and infrastructure specialist will focus on their own parts of the stack.

Within Oracle Enterprise Manager you can give everyone the option to look at all the parts of the stack however based upon a certain role people do want to have focus on their part of the stack. This means that a standard dashboard is not very usable, some people will want to focus on the entire stack for a specific department or customer. Some want to focus on the database and others want to focus on hardware.

Oracle Enterprise Manager provides you with a couple of standard dashboards which do provide a point from which you can start. Selecting a dashboard that is close to your role is the first step, after that you can customize your dashboard to show exactly what you want.

The below video shows how you can customize your dashboard. In this video you get a quick first impression to help you getting started.

Oracle Enterprise Manager authentication framework

Oracle Enterprise Manager, which is current version Oracle Enterprise Manager 12C, can used within Oracle dominated IT landscapes for monitoring and maintenance purposes. Oracle Enterprise Manager 12C is the cloud enabled version of the previous versions of Oracle Enterprise Manager. The main goal of Oracle Enterprise Manager is to be the central hub for administrators to monitor and maintain all components within the landscape. This can include the Oracle databases and Oracle applications within the landscape however it can (and commonly will) include components like hypervisors, operating systems and hardware components. This enables you to have a 360 degree view of all components that are part of your infrastructure and will provide you the option to see a full chain of components when pinpointing the root cause of an issue.

Having a central Oracle Enterprise Manager system within your landscape will provides numerous benefits to your IT operations as well as to your business operations. It will however mean that you have one central point linking to all components and all systems will communicate with the centralized Oracle Enterprise Manager installation. Due to this reason it is of vital importance that, when implementing, a good portion of time is dedicated to security questions. To ensure save and encrypted communication and to ensure that users who are allowed access to the application have only access to what is needed for their role can be done via setup. One of the things you will need to consider at the beginning of the implementation of Oracle Enterprise Manager is how your users will be authenticated.

A number of options are available within the Enterprise Manager’s authentication framework. The authentication framework within Oracle Enterprise Manager provides pluggable authentication
Schemes which can be used to handle user Authentication.

Oracle Access Manager (OAM) SSO:  Oracle Access Manager is the Oracle Fusion Middleware single sign-on solution. The underlying identity stores will be the Enterprise Directory Identity Stores being supported by Oracle Access Manager.

Repository-Based Authentication: This is the default authentication option. An Enterprise Manager administrator is also a repository (database) user.

SSO-Based Authentication: The single sign-on based authentication provides strengthened and centralized user identity management across the enterprise. After you have configured Enterprise Manager to use the Oracle Application Server Single Sign-On, you can register any single sign-on user as an Enterprise Manager administrator.

Enterprise User Security Based Authentication: The Enterprise User Security (EUS) option enables you to create and store enterprise users and roles for the Oracle database in an LDAP-compliant directory server.

Oracle Internet Directory (OID) Based Authentication: Oracle Internet Directory is a LDAP v3 compliant directory built on the Oracle database and is fully integrated into Oracle Fusion Middleware and Oracle Applications.

By default the authentication framework will be using the Repository-Based Authentication schema to authenticate users during login. When operating with a rather small team of administrators this can be the best way of working. However, as team sizes grow it is advisable to investigate other options of authentication. My personal rule of thumb is that if the number of users using Oracle Enterprise Manager is more than 25 it is beneficial to look for more centralized solutions.