Table of contents
- Introduction
- ORDS and Database: to share or not to share (machine)
- Factors impacting the final design
- How to deal with this (potential) complexity
- Summary
- Additional sources
1. Introduction
This article is a continuation of the previous one, in which we described how to build a highly scalable configurations Oracle API for MongoDB. As our customers start to use this solution in very sophisticated environments, consisting of multiple applications, application servers and database systems, they often ask us about some best practices related to deploy ORDS instances in a way, which is aligned with their existing infrastructure, as ORDS/MongoDB API offers full deployment flexibility: from strictly technical point of view it is possible to configure a single ORDS instance to work against multiple backend databases, also multiple ORDS instances can work on a single database. It means that relationship between ORDS instances and Oracle databases is many-to-many. So, in a complex case, where we have multiple databases and plan to deploy multiple ORDS instances, the final result, if not planned carefully, might be difficult to maintain.
As every infrastructure has its own specifics, we are not able to provide a generic template describing one, the best possible design as it simply does not exist. Instead we would like to discuss different aspects, which should be considered during designing stage.
Note:
In this article we assume, that the reader has a knowledge related to installation and configuration of Oracle API for MongoDB as this is well documented in Oracle official documentation and described in many additional publications.
- One of the most frequently questions raised by our customers is if it is better to install ORDS on a separate machine or on a machine running the database server. Of course there is no best answer for this question. In the simplest, non-production cases, when no security regulations are violated, it is acceptable to install both layers on the same machine. But – this scenario may drive to some security-related problems (ORDS requires opening additional ports), maintenance or availability issues (which are discussed in this article in next points). Therefore, in most cases, especially, when we’re building a production environment, we should consider using a separate machine (bare-metal or virtual) for the ORDS instance or instances.
- Another specific case is when we plan to use Oracle AI Autonomous Database services. In that case ORDS is integrated with the service and is scaled and maintained automatically. Because of that in most cases it is recommended to use this integrated instance – at least unless any special requirements must be met.
- And last but not least – how to configure ORDS in a Oracle Database multitenant architecture. With exception of the simplest case (described at the beginning of this point) we should consider installing separate ORDS for every PDB. It allows for avoiding all the problems with maintenance, versions etc, discussed in more details in the next point. Since then – in general – if in this article an “Oracle database” is mentioned, it can be understood as a pluggable database.
3. Factors impacting the final design
In most real cases, where we have multiple databases, applications and plan to deploy multiple ORDS instances, there are multiple factors, which should be considered and may lead to the decision that the simplest possible scenario is not acceptable. List of such factors cover the following points:
- Security. In case, when our databases store some sensitive data, isolation of particular environments or even layers of a single environment may be one of key elements deciding about deploying ORDS instances in a separate machine or machines (virtual or bare metal). The reason is simple: even if, at the moment of building the system, any security threads related to ORDS are not known, no one can guarantee, that they will not be discovered in the future. Also opening additional network port (27017 for MongoDB) on a machine running an Oracle instance can be in conflict with existing security rules.
- Availability. Most of readers, for sure remember Oracle’s MAA Reference Architecture template. Although it has been designed for the purpose of simplifying designing the database layer, it is also true for other layers, including ORDS and load balancers as they are equally responsible for an application availability.
- As you can see, different systems can have different requirements related to availability. For example, a critical system, which can be described as Gold or Platinum usually uses RAC, (Active) Data Guard and/or GoldenGate to reduce the time of failover to minimum at the database layer. At the level of MongoDB API the same requirement can be met by multiplying ORDS instances and load balancers. On the other hand, there can be systems, described as “Bronze”, which are not critical, even if they are used by the same set of applications, for example DEV and QA. They don’t work on a production data and often don’t use advanced HA/DR options.
- Maintenance. Installing everything on a single set of machines may drive to serious problems related to maintenance. One of the most obvious examples is patching. Some patches may be required by only specific applications, while others need to be applied to fix another set of applications. Patches can be related to different layers – from operating systems up to load balancers. In a case, when we have everything installed in a single place, the following problems may appear:
- A single patching operation may require planning a maintenance window covering all applications – even the most critical ones.
- Also some patches may be in conflict – installing them on a single server will be technically impossible.
- Performance/Scalability. We should try to avoid situations, in which different workloads (like ETL/ELT) running periodically impact their performance. Of course – sometimes it is possible to use, for example, Resource Manager at the database or operating system layers to manage resource consumption, but in some other cases, especially when some extraordinary overlapping processes are running, it is impossible to do this – as every, even the largest machine has limited number of CPUs and IO performance.
- Software version requirements. Different applications may have (and usually have) different software version requirements. They have been tested on a specific combination of versions of database and ORDS. Separating environments used by them, at least temporary, is sometimes the only applicable solution – at least at that moment, when the oldest application does not pass tests on the newer version of software.
Of course, the real list of topics to consider can be longer and cover additional points – or shorter, if we have a simpler case – everything depends on an existing infrastructure to which we need to be aligned. For example, in some scenarios there is a need to take into account potential isolation of different services provided by ORDS such as REST, APEX and MongoDB API. This is very important: every case has its own specific and the only common requirement to all cases is that the target solution must comply with the existing architecture.
4. How to deal with this (potential) complexity
As it was mentioned at the beginning of this article, ORDS offers full deployment and configuration flexibility and the list of points to consider can be quite long, since then designing the system may be a very complex task. So let’s try to simplify it. For this purpose, let’s consider the following, simple example: we have to design a system for 5 applications, from app01 to app05, where app01,app02 and app03 are in production stage, all of them can be described as “platinum” and – additionally app03 works on sensitive data. App04 is still under development, while app05 is in QA stage. Let’s also assume for simplicity, that applications having the same requirements can use the same database and ORDS instances (which may be not true in a real scenario). The case can be reflected in the below matrix.
It is obvious, that app01and app02 can share the database and ORDS installation, while app03 should be (due to fact, that it works on a sensitive data) isolated. Also app04 and app05 cannot share the environment, as they use different versions of database and ORDS.
So, the final design can look as following:
This architecture has the following advantages
- Applications with different MAA requirements are isolated
- Sensitive data are isolated from non-sensitive one
- And finally – applications with different software versions are isolated – there won’t be any compatibility conflicts
Of course, once again, real use cases are usually significantly more complex, than school examples, but the process of designing an architecture described here can be used as a template to work with real systems.
5. Summary
This article should not be considered as a generic design template, which can be applied in all possible scenarios. Such design simply does not exist. Instead, it only discusses some of the most important points, which need to be taken into account. When we plan to build a system, which needs to comply with existing infrastructure, without violating any rules related to security, availability or maintenance. Real cases can be significantly more complex, than the sample architecture presented here. In addition, the list of aspects, which need to be considered can be significantly longer. However – thanks to ORDS flexibility – in all cases it can be deployed in a way, which does not violate anything.
6. Additional sources
ORDS best practices (Oracle official documentation)
Oracle API for MongoDB best practices (blog post)
Oracle API for MongoDB – building and scaling on-premises deployments (blog post)