- Details
- Category: Technology
As I am making my fork of FusionPBX, CoolPBX more MariaDB/MySQL compatible, I have found that the DATE_TRUNC() function doesn't work.
After googling, I found that some people suggest that the PostgreSQL DATE_TRUNC() function to MariaDB/MySQL is EXTRACT(), but it is not. For example, in PostgreSQL:
SELECT DATE_TRUNC('hour', NOW()) + (INTERVAL '1 hour') AS h;It will return something like 2024-08-09 09:00:00-04. While in MariaDB:
SELECT EXTRACT(hour FROM NOW() + INTERVAL 1 HOUR AS h;It will return only 9.
- Details
- Category: Technology
Syncing a filesystem in a cluster is one of the most challenging things. There are many ways to do it:
- iSCSI with GFS2: you require local computers with a fast iSCSI connection to make it work;
- Glusterfs: it is slow if your nodes are far from each other (as it is a synchronous filesystem);
- NFS: famous because it is one of the slowest filesystems;
- Syncthing: big footprint, especially when scanning the filesystem, file synchronization could be delayed.
These are some of the many approaches you may take. I am going to talk about a new one.
- CSync2 with Lsyncd: small footprint with almost real-time synchronization.
Read more: Filesystem Cluster Synchronization with Small Footprint
- Details
- Category: Technology
So you have your brand new cluster! You keep feeding it with your dialplans and start moving some customers there. All good so far!
Wait! You have to modify a dialplan; some servers get it while others don't. What is happening?
FusionPBX Caching Engines Explained
Memcache Engine
Since release 4.2 (maybe before), FusionPBX has supported Memcached. Memcache is a fantastic caching engine with the following features:
- LRU algorithm,
- Auto-expiring objects,
- 100% memory, zero I/O,
- Outsourcing is possible, and
- Key based.
However, the biggest challenge that Memcached presented (until today) was the difficulty of reading what was inside it.
File Engine
Since release 4.4, FusionPBX introduced field-based caching and made it its default engine. Yes, it resolved the issue of an easy way of knowing the cache content, with a trade of the following:
- objects won't auto-expire,
- there is always I/O, and
- cache can't be outsourced (as it writes into a local directory).
Where is the issue? If your deployment is a low-volume stand-alone server, none. If your deployment is a medium to high-volume cluster, you will notice that when you make a change in the UI, one server may take it but the rest nodes won't. The only workaround for this is flushing all the content in the /var/cache/fusionpbx directory. You will find that the more nodes you have, the more tedious this becomes (especially when debugging).
Why Don't We Have the Best of Both Caching Engines?
That is a good question, and frankly, I have no idea why this hasn't happened until now. My solution is as next:
- Switch back to the Memcache caching engine,
- Install memcache-fs (if you are under Memcached 1.4) or memcached-fs (if you are under Memcached 1.6), and
- Mount the memcache(d) FUSE filesystem on /var/cache/fusionpbx.
You will get the best of both worlds:
- You can outsource the Memcached (by default is localhost),
- No I/O at all,
- Auto-expiring objects (all nodes will get the changes),
- Easy way to sync all the servers by triggering a flush cache from the UI, and
- You can see the cached content.
Good luck!
- Details
- Category: Technology
A multi-home server is a server that has more than one interface and each interface is capable of routing. This sounds very exciting, especially if you are into low-budget high-availability. As sexy as it sounds, multi-homed systems are not as easy and transparent to configure.
Where is the catch? In Linux, multi-homed routers are possible, however, it is not what people think. Most may think a packet entered through eth0 will go out through the same interface. This is a false assumption. Each time a packet enters the interface, it is evaluated against rules and routing tables, and each time a packet (even from the same connection) is going out, it is re-evaluated against rules and routing tables.
That is the way it is. So here is how I did it on a RHEL
Ah, I forgot, in my example:
- ens18 faces the LAN,
- ens19 faces one ISP, and
- ens20 faces to another ISP.
- Details
- Category: Technology
The LCR for FusionPBX is an in-app for FusionPBX/CoolPBX that will allow you to not only add fault tolerance in your termination routes (outgoing calls) but to prioritize the routing (usually by cost). This software is not open-source yet, there is a campaign for that purpose.
