Thank you, Ashok. On behalf of the project we want to express our gratitude for your
and your team's involvements and assistance. Everybody, welcome! Welcome to
this presentation of Oracle's NoSQL Database Maximum Available Architecture, MAA.
Let's present a team involved with this concept. Welcome, I'm Stephane Duprat
and I've been working with relational databases for almost 25 years.
Hi, I am Dennis Federico and I have been
working with Java for the last 14 years and with Big Data technologies 4 or 5 years.
and I'm Michael Ellison. This presentation is divided into four sections:
the use case, the project where this concept was conceived,
why MAA, why reliable data, how it works and a brief demo. This solution came from
a real client's use case. We generalized it so others may see its benefits in
their own businesses. This customer wants to analyze their business activities in
real time. Anyone in the retail business or the logistics sector can understand
this need. Especially with the holiday shopping season upon us, Cyber Monday,
Black Friday you can understand the benefits of analyzing your business
activities in real time during periods of intense activities. To achieve this
their remote offices and regional sites must send their business activities in
real time. These activities.. these transactions are received by corporate
data dock, a transaction receiving center, a store fast enough reliable enough to
handle vast amount of individual transactions. This data dock is Oracle
NoSQL. Their real-time applications are implemented with other Oracle Middleware
products like coherence which requires a persistent store. Again this is Oracle NoSQL.
Whenever you incorporate a new technology into your data center you
obviously study its features and functionalities. You must also study its
compatibility to keep your business continuity, Business continuity as your
infrastructure resilience to disturbances. So, this new technology must
be consistent with your business continuity and the investments made in
your data centers like high availability and disaster recovery. You cannot afford
to introduce a weak link that could increase your system susceptibility to
outages or data loss. Oracle NoSQL database has been
conceived with high availability and disaster recovery in mind. The maximum
availability architecture is a blueprint of the best HA and DR practices
based on expert recommendations and customers experiences. In our demo, you
will see an application's resilience to switch over maintenance outages and a
secondary data center failure. On a primary data center failure that
requires a manual intervention much similar to a data guard failover, we
claim HA with no data loss. We will explain it and prove it. Ask the
representatives of other NoSQL products if they can make the same statement.
To understand NoSQL MAA, one must understand the functionality of the
product itself. Here are some basic concepts. The zone is
a grouping of machines with good network connectivity. Let's draw two each in
different sites. These zones can be either primary or secondary.
The replication factor of a zone is the number of copies kept. 3 is a typical
number used to ensure replication and to ensure quorum votes producers of majority.
A primary zone will host the master copy of a piece of data and maintains a
quorum to enforce consistent operations. The secondary zones only contain data
which can only serve as replicas for rates. The switchover is the
interchanging of zone roles in a fully operative system. For example, like we
have currently drawn.
The secondary zone failure does not have major impacts for the reason stated
earlier. For example if this side fails the system continues to operate. If the
primary zone fails, we must perform a failover which tell the surviving zones
to remove a quorum and to downgrade the failed primary to secondary. This is the
foundation of NoSQL MAA. Dennis will discuss the concept of
durability which will tie everything together and now Michael explains this topology.
Be a small conceptual change, let's provide a NoSQL
administrator with controls and options to resolve issues.
A zone is the logical
construct which aggregates physical elements. Let's split these zones with RF of 3s into
3 zones of RFs of 1s. All this is done by dividing logical constructs.
Lets make one more change. Let's move one primary zone. Having a
primary zone in each of the two sides is very important in MAA. Obviously the
administrator now has more maneuver room. One last point, we need to redefine the
standard concept of primary site. You see both sides have primary zones but the
primary site is that which has a simple majority of primary zones while the
secondary site does not. The durability of NoSQL can be compared to
committing a transaction in an Oracle database by writing into the grid blocks.
The application does not receive an acknowledgement from the kvstore until the
decided to the ability is achieved. There are three levels of durability in terms of
functionalities. Let's see with our example when we have a replica factor of 3.
With all replicas acknowledged durability, all 3 replicas must
acknowledge they receive the data. With simple majority at least two replicas
must acknowledge to meet this condition. And lastly
with no actual replicas only masters participate. But we don't include this in
the maximum availability architecture. Let's compare NoSQL durability with
data guards protection nodes. Maximum protection is like all replicas acknowledged.
It guarantees the secondary site has committed transactions and we block
application until this occurs. Maximum performance is like simple majority.
The secondary site may not have the latest committed transactions but the
applications are not blocked by secondary site failures which leads us
to maximum availability. The native NoSQL driver does not support this and may
require a change but we have prototype this change. We ensure no data loss for the
secondary site is active and we don't block application with the secondary
fails just like with data guard you choose your level of protection.
Okay, let's have a look at all four topologies. In the name of each topology the capital
letter represents the primary site as defined earlier by Michael. The lowercase
letter indicates that the secondary site contains a primary zone these are the
standard topologies for business as usual and these are the topologies for
planned or unplanned outages. These four topologies are created in the kvstore but
only one is active at a given time. The default active topology is topAB.
Now, let's explain a site switchover. We plan an outage on Site A. Therefore we execute
the switchover from topAB to top B. The animation shows how some zones are
switching their type. And once we are done with the maintenance tasks, we
switch back to topAB topology which is our normal operations topology.
Note that the steps we have just explained would be similar in case of an unplanned
outage. But the failover command would perform additional actions to ensure
quorum consistency. And now Mike let's introduce the demo.
This demo is based on an actual deployment of two Big Data appliance
starter racks, each in separate sites. 6 nodes in each, 4 networks in total,
2 Infinibands and 2 Ethernets. This demo simulates 2 sites, 4 networks but
only half the nodes, 6.
We shall fast-forward the videos to best utilize our time.
Additionally to facilitate the maintenance of a KVStore, we have an SQL CTL, a proof-of-concept utility.
Here's a quick overview with a minimal amount of setup you can create
start, stop, remove, switchover, failover with the single command the entire
KVStore cluster. The network and host sections will configure the /etc/host
files in the entire cluster ensuring proper traffic in each of the network's.
This topology set is created with each of the KVStores. The prime topology
defines the structures and the zone types while the additional topology only
reconfigures the zone types. These are the four topologies mentioned by Stephane.
Here, we have three KVStores utilizing the same hardware each with default values
with the exception of the ports and disks.
Here's an example of a KVStore administrator starting, stopping, removing
and creating a store.
NoSQL connects to each of the nodes and performs the appropriate action.
For further information concerning NoSQL CTL this prototype utility please contact Ashok.
Let's say you have a planned outage on your primary site for the weekend.
You will want to reconfigure your topology online.
We will switch over to topB for the weekend and then back to topAB, all the
time keeping the application running.
To save time we will fast forward the video. Notice how the VirtualBox machines
are shut down and restarted.
Notice how NoSQL is always running.
Now, let's verify the rows processed by the application and compare it to the
rows in the KVStore. We query the KVStore row number from both sites and
compare the results with the number of rows inserted by the application.
They match. We have just reconfigured the topology twice online and that was
transparent to the application. No downtime, no data loss.
In order to easily compare the counts we will stop the kvstore, remove it and recreate it.
Let's assume your site B has failed unexpectedly.
You will notice how the application drops from maximum protection to maximum performance.
Because this could last several hours or days will want to return all 3
primary zones to site A. We will call this a site level failover.
NoSQL control will launch all the appropriate comments.
Now we see all the primary zones are inside A.
Notice that the application returns to maximum protection.
When Site B gets online again we'll want to return to our standard
configuration. First, we must fail back and we
incorporate the failed zones.
Note that all the zones are active again. Now, we switch over to Site A.
Notice again the zone status.
Let's compare counts once more. No data loss, no application outage and
we are back in business as usual.
We hope you enjoyed this presentation.
We explained Oracle's NoSQL Maximum Available Architecture and demonstrated it.
We proved it. Dennis, Stephane do you have any closing remarks?
Oracle provides NoSQL
solution that complements your Oracle Database data guard solution with no data loss.
Oracle provides transparent no data loss and no service loss features in
its NoSQL solution, as we have demonstrated. Can any other NoSQL product make the same kind.
Oracle NoSQL Database. Its spinning,
it's fast, it's reliable, It's worthy to be in your portfolio. And you can trust
it in your data center.
Enjoy the rest of your visit here at Oracle OpenWorld 2015.