
First, a few words about ODA. This is an engineering system, which is a ready-made stack - storage, servers and software, which are matched to each other to ensure maximum performance. Other manufacturers have no analogs because the entire stack was tested by the hardware and software manufacturer to identify bottlenecks in performance. As a result, there are no fans of different configurations in the EAP, and all that can be done is to add an extra shelf with disks. The system has a standard amount of memory, a standard amount of disks, standard processors - there are no special additions or configuration options.
In our review, the ODA of the first generation is used, which in the dimensions of 4 units, includes 2 servers, each with:
')
2x Intel Xeon X5675
96 Gb RAM
3 USB 2.0
2x 1GbE
1x 4-port 1GbE NIC
1x2-port 10GbE NIC
And data storage system:
24x 3.5 600Gb 15K SAS
4x 3,5 73 Gb SSD

Photo - ODA from behind, a double power supply is visible, both server nodes (hot plug).
Deployment
Since I deployed the ODE several times (for exhibitions, partners and tests), I can say that this is a fairly simple procedure that requires minimal knowledge in the field of Linux and database installations.
You come to the new equipment, unpacking it, connecting the cables and inserting in the rack, you can immediately turn on and deploy the system. Oda comes from the already installed OS and the latest patches at the time of purchase, all that remains to be done is to download a bundle of several GB from the Internet. It is called End-User GI / RDBMS Clone files and contains the latest patch database compiled for Oda. Next, you need to upload it to one of the nodes of the engineering system, run the simplest wizard and in 1-1.5 hours you will have 2 servers + DSS with a configured and ready to work
Oracle database in one of the modes: RAC, RAC one node or Fail- over. In case 1C will be used, or some non-standard settings of the database itself are needed, they will need to be created via the dbca console.
You can take the available analogues: some servers, other storage systems, the third OS, the fourth database of the components, most likely from different manufacturers. It will be necessary to spend a lot of time to configure the OS and the base on 2 servers as a cluster, spend time setting up the storage system, as well as pairing and testing the entire system. Here, a total waste of time is 3 hours and as a result, a fully working DB machine. Also important role played by the number of people needed to configure. In normal cases, a specialist in gland is required + a specialist in DB + testing is possible, here - 1 person and a couple of hours of time. Well, the maximum assistant to shove in the rack, the weight is rather big :).


Photos 2 and 3 - from the back of the PSU and the available ports.
Licensing
In the
Oracle database
, all licensing goes by core — oddly enough called processor licenses. If you don’t even have the most modern server for 2 processors with 4 cores - just 8 cores, then according to the licensing policy it’s 8 processor licenses, each of which costs a lot. If you run a virtual machine to save on licenses, then a very limited number of products will be suitable for this (more
here )
ODA has one big and unique advantage - it allows you to license out of the box a database only for the necessary cores, which is called capacity on demand. This allows you to start licensing from 2 cores and further grow to 16. The main point of this approach is to save on licenses, with the possibility of simple growth.
In case you need to increase the number of licenses and increase performance, you need to buy additional licenses, generate a key on the technical support site and feed the script to the system, immediately obtaining the hardware performance of the added cores. On another system, you will need to perform additional work, such as stopping the backup transfer of the database to a new, more powerful system.



Photos 4,5, 6 - inside the system.
Deployment options
Starting from version 2.5, ODA has become possible to deploy in two ways: virtual and “iron” configurations.
The first option - “Iron” is installed Linux and the database directly on the server, it is not very beneficial in terms of the use of resources, if you do not have the maximum load. As a result, if you use 2 cores under the database, the rest are not occupied and are therefore idle.
The second option is a virtual one. To do this,
Oracle VM hypervisors are installed on both servers and the template is loaded in the form of ODA (ie, OS + DB), which, after deployment, begins to use the storage system. Deploying a virtual system is almost the same as deploying an iron, but as a result, you can use the remaining resources for other virtual machines. But even here there are some drawbacks, namely the support of exclusively templates of a certain format, with the extension tgz. For those interested - you can download them
here .
If you try, you can create your own template. Also, a small spoon of tar adds a restriction of disk space available to servers, since virtual machines use internal disks, not storage.


After reading a lot of reviews, both official and unofficial, about this engineering solution, I decided that it was worthwhile to focus attention on
what they sometimes do not talk about .
1. Bundle need to download separately
2. Orakl always tries to have the latest software version upon receipt, but sometimes during delivery, a newer version may be released.
3. The absence of different configurations of iron.
4. The inability to use embedded storage for virtualization.
5. Not the most convenient management of virtual machines.
6. The latest version of the database at the moment 11.2.0.4.0
My personal and subjective conclusions after the experience of using ODE:
1. Save on deployment time. Easy and quick installation. Setting up a cluster usually takes a lot of time. Here, after the launch of a small wizard by 15 steps - the cluster is ready.
2. For servicing the entire system, 1 person is needed, separate admins for hardware, databases, and storage systems are not needed.
3. Save space for installation. Oda only takes 4 units in rack. What can have a very positive impact on the placement, for example, in the data center.
4. Since everything from one vendor will not be all familiar and unpleasant surprises in the form of incompatibility, since all the equipment has been tested in advance.
5. There is no obsolescence of equipment. Even the old ODE, even if it is not already for sale, is still updated with functionality not inferior to the modern version.
6. Savings on licenses with the possibility of instant growth (it was said above).
7. Very convenient monitoring and control of the equipment itself. ODE is pretty easy to reconfigure, reboot, and even reinstall entirely.
8. Fault tolerance, because in it everything is duplicated doubly and even triple.
9. ODU can be deployed to a sufficiently large number of cores, close to those of the minimally available Exadata, but this is a decision of a much more serious level and the topic of a completely different article.
And the last - the ODE version at the moment is X4-2. View the main features
here .
Contact infoAll questions can be sent: oracle@muk.ua
Post sponsor:
Cosmonova: data centers & telecom & software developer