Once we have an understanding of the need to separate the different Zabbix components in different hardware, we need to list what specifications are needed for each piece of hardware.
To make this decision, we must know the behavior of each component. Consider the following:
- Zabbix server
- This basically receives all of the environment data and forwards it to the Zabbix database.
- It doesn't supply the data immediately. It keeps it in the Caches history and delivers it later with DBSyncers.
- This has large amount of network connections because of the data gathering.
- It performs many mathematical calculations involving, mainly, triggers.
- It has very low disk usage.
- Zabbix GUI
- This basically displays, the data in the Zabbix database to users
- It has reasonable disk usage (this can still keep the GUI files in a memory area)
- Zabbix database
- This basically receives data from the Zabbix server
- It delivers data to the Zabbix GUI
- It needs a lot of memory to cache/buffer stock
- It requires a multicore CPU (the more the better)
- It has intensive disk usage (reading and writing)
With this basic list of tasks and behaviors of each component, we can start our review and determine the settings for the hardware that we will use for each task.
Since Zabbix version 1.8, we are getting more and more functions related to cache and data buffering, and it is clear that this will require more memory in the hardware in which we have the Zabbix server installed.
This table will help you understand the maximum amount of memory that we can allocate to the Zabbix cache/buffer:
As we can see, the Zabbix server can require quite a large amount of RAM. The trick is to start with low values (4 GB) and increase as the requirement grows. Caches that I like to keep high (preferably with the maximum value) are HistoryCacheSize and HistoryTextCacheSize. This is because they are the "safe areas" where the Zabbix server stores data to be delivered to the database. In other words, it is the time when we run out of space for recording data in the database or the times when the storage/bank is slower to write to.
Other than this, we have the memory footprint of internal processes (pollers, syncers, trappers, and so on). They do not require much memory but can't be disregarded.
It is important to emphasize that Zabbix's process of data collection does not depend on the database, and (to some extent) it is possible for pollers and trappers to continue to receive environmental data and put in History caches until they are completely full. Similarly, pollers and trappers continue reading configuration data directly from the Config cache.
The following diagram helps us understand the relationships of caches and buffers with the internal processes of Zabbix, and how memory consumption can be high for the Zabbix server:
Caches, buffers, and internal processes
The CPU is also very important for the Zabbix server because it is the CPU that will run all the mathematical calculations for the functions, triggers, calculated items and aggregates. The trick is to use—undoubtedly—a good multicore CPU.
With the Zabbix GUI, things are not very different. We need to know how much memory each thread or connected user may require from the hardware. It also depends on the web server being used. However, we don't have a very strong requirement of hardware for the Zabbix GUI. In most situations, a fast multicore CPU and 4 GB (8 GB if there are many screens, maps, graphs, and so on) of RAM will suit the environment without any problems.
We can also think of keeping the Zabbix GUI in a virtualized environment, or more than one piece of hardware attending this service (DNS round-robin or a hardware/software balancer).
An important point to pay attention to is that the Zabbix API accesses Zabbix data through its PHP gateway. When there is a high pressure from invoking Zabbix API, such as data ETL, the box where the Zabbix GUI is running will take the most amount of pressure. When we need to optimize the performance of the Zabbix GUI, we can use a load balancer, such as Nginx, and put several PHP servers behind it.
What about the Zabbix database? Well, here the hardware necessary to ensure good performance in a large environment can be really high. We must remember that when we reach the point of targeting components and different hardware, we have already made every suggested adjustment possible to maintain the environment within a single piece of hardware. Moreover, the Zabbix database is the component that will require segmentation because it needs to consume more hardware resources than the other two components. So, it is natural that this is the biggest hardware component.
And what should the hardware be? We should start by considering a 16 or 24 core CPU. The Zabbix database will really demand a lot of CPU resources, and so we can't neglect this item. Memory will also be of utmost importance to ensure good environmental performance of the Zabbix database. We must remember that for MySQL, it is recommended to have 80 percent of the memory dedicated to BufferPoolSize, which is the bank's portion that we will handle in the memory. With this in mind, our Zabbix database must begin with something between 16 GB and 32 GB of memory, and it may require 64 GB or more, depending on the environment size.
With this segmentation and the appropriate hardware for each component, we will achieve a few thousand vps without hassle.