When deploying databases in the cloud, there are some infrastructure considerations to be aware of. We list them below.
Different Types Of Discs Are Designed For Other Tasks
For example, in the cloud, SSD, High-IOPS SSD, and Low Latency NVMe disks are available when creating a database. SSD features out-of-the-box fault tolerance, reliability and geo-distribution. For systems with higher IOPS (Input / Output Operations Per Second) requirements, fast High-IOPS SSDs are recommended.
And for high-load applications where response speed is critical, ultra-fast Low Latency NVMe disks are best suited. Unlike other disks, they are located locally, directly on hypervisors, and provide a guaranteed response time – in our cloud no more than 0. 5 ms. A quick summary of the drives is shown below.
The Performance Of Disks In The Cloud Is Directly Related To Their Size
For cloud disks, the I / O limit is always determined for a specific step of disk space. If you need to increase the speed of data processing, then sometimes it is enough to increase the size of the required disk.
For example, a High-IOPS SSD disk was chosen, a 50 GB database was deployed on it, but it became clear that IOPS was not enough during testing, although the disk was high-speed. This is because any cloud has QoS (Quality of Service): so that a client who rented 50 GB does not entirely utilize a 2 TB disk, resources are allocated, including depending on the requested volume. And to get better performance, you need to increase the size of the disk.
Changing The Disk Type And Size Is Available On The Fly
These operations are performed without downtime via API or UI. It should bear in mind that changing the size of the disk is possible only upwards – to avoid data loss.
VM Performance Depends On Flavour Type
Before creating a database, it is essential to correctly select the style and size of disks and the type of processor, the number of cores, and the amount of RAM. The combination of these parameters is called flavour.
In addition, on request, it is possible to create individual configurations, for example, using high-frequency processors. Standard Intel (R) Xeon (R) Gold 6238R CPU @ 2.20GHz processors are good for 90% of tasks. High-Freq Intel (R) Xeon (R) Gold 6238R CPUs starting at 3.00GHz, pluggable on demand, are designed for high-performance computing and can be used in areas such as machine learning, distributed analytics, media coding, gaming, distribution advertising and so on.
The maximum number of virtual cores for a VM instance on standard processors is 80 vCPU, for High Frequency – 40 vCPU. Vertical scaling of a VM is possible, changing its resources after creation, but it requires little downtime – approximately within a minute.
Several Database Configurations Are Available
In the cloud, the database, depending on the type of DBMS, can be deployed in one or more configurations from the following list:
- Single-Instance is a single instance of a DBMS. It is recommended for development and testing purposes only.
- Master-Slave – two or more DBMS instances with replication in Master / Slave (Active / Passive) mode. This approach allocates the central database server, Master, to which all data changes are sent (INSERT / UPDATE / DELETE). Another server, Slave, synchronously copies all changes from the Master and processes data read requests (SELECT). Thus, the Master is responsible for changing the data, and the Slave is accountable for reading. If any of them fails, the other temporarily takes over the functions of both reading and writing. Typically no more than 20 Slave servers should be used when working with one Master. The configuration is recommended for industrial use.
- Cluster – a cluster with data replication. In this case, there is also a Master, and there is a server where data replicas are sent in asynchronous mode. If something happens to the Master Server, the system automatically switches to another server. If necessary, replacing the Master is also available in a manual way. You can add asynchronous replicas, change their number and distribute them across different data centres. The failover load balancer is the entry point to the cluster. In the event of a failure on the balancer, a seamless switch to another active one occurs. The configuration is recommended if there are high requirements for the reliability and fault tolerance of the system.
Consider Network Delays Between Data Centres When Configuring Synchronous Database Replicas
Network delays between our data centres are usually 1–2 milliseconds, but depending on the load, this value can vary. Therefore, when spreading synchronous replicas across different data centres, you can get a slowdown in the database since transactions on the Master server will wait for confirmation from an image in another data centre. To prevent such problems, we recommend placing the Master and synchronous replicas in one data centre and asynchronous models in another.
Also Read: How Humanoid Robots Are Used
