ViciBox v.9.0.2 and some oddities upon pending release

[Kumba]

So ViciBox v.9.0.2 seems to have an oddity due to something breaking upstream in the installer. This oddity might actually be a nicety given some of the issues with Dell/HPE servers and their UEFI implementations.

So what is the oddity? Its this:

Previously the installer would select a disk, partition it, install the image onto it, reboot, and resize the disk during that reboot.

What is happening now is the installer does not reboot after installing the image. Instead it drops you to a login prompt. If you login and type reboot it will resize the disk during the reboot. Since there's quite a few fixes in 9.0.2 I'm likely going to release it with this oddity in place.

The one upside to this will be that if you need to load drivers, change command line options, etc, prior to rebooting it to make things work with your hardware/software, you can now. So it's not a bug, it's a 'feature'.

Anyways, 9.0.2 will be released soon. Here's what is going into it:

1) reworked and fixed vicibox-certbot for acmev2 APIs
2) Fixed dynamic portal issues
3) WebRTC viciphone ready
4) kernel-firmware and other driver firmwares included to help some hardware issues

[vkad]

Why can't you create a script based installer as that would allow for the raid, etc to be setup beforehand?

Also, I tried to set up vicibox on lxd and its running fine. We have been testing with 50 agents with 1:10 autodialling and its working perfectly fine.

All that on a single server 2x E5-2680V3 and 128gb ram with a h710 raid controller with intel s3600s 800gb in raid 1

We have an express (sort of install) and then 10 telephony lxd containers with 2 virtual cores each and max 50 calls each with 2cps.

"Unlimited" cores to the db.

Or is it not possible to virtualisee/dockerise just the Telephony servers while keeping the db and web dedicated?


Also, any chance of integrating s3 or sftp in the recording server?

[Kumba]

Script based installers are very tempermental. We initially did have a script based installer for ViciBox way way back but every time a repository hiccuped, a package updated, or the OS got installed in some random way it just caused problems. Not to mention there are tons of things in ViciBox that would have to be stripped out due to their level of integration.

I'll see about a basic installer script after I push 9.0.1 out since everyone keeps asking for it.

[vkad]

Or even an lxd image version would work beautifully?
Or Maybe something that works with proxmox or have own web interface that allows to deploy lxds on the current server.

Also, it will be a lot easier to maintain lxds from a development point of view. Infact it may be easier than a script.

Or dockerize the platform...
1) Docker or LXD image of MySQL - Maybe the only component that can be installed directly, but I have only observer around 2-5% drops in fysnc IOPS and Latency when using a mounted sub-volume.
2) Docker or LXD image of Telephony Server - It would be beautiful to be able to scale this by deploying this image with easily over underutilised servers.
3) Docker or LXD image of Web Server - This is fairly simple image. Maybe just nginx or apache with PHP7
4) Docker or LXD image of Archive Server (allow the option to connect to S3 or SFTP or RSYNC) -

5) Self Installation Script, Docker Or LXD image that's sole purpose to store and push configuration files, or manage the deployment of MySQL, Telephony....or so servers.

Benefits:
Easy to Deploy and Scale
Easy to Upgrade, Downgrade, Backup
Centralised Management - Control what versions of installation is deployed.

Imagine being able to pull the latest image from your working configuration and then the central management basically restarts the whole cluster one by one.
Separation of concerns
Easy to test out different versions, deploy, delete, restart and so on....for us and for you....
-----------------------

E5-2680V2 - 128GB DDR4 - H730 Raid - Intel Enterprise SSDs

CPU Usage at Peak: 25%
500 Lines + 50 Agents + All Recorded Calls + AMD

IT took me about 5 days to set this up, but now it works for us over LXD and it works beautifully, so easy to backup. The server doesn't even break a sweat when dialing 500+ calls.

I would be more than willing to help out with the coding part, so message me if I can be of any help, should you decide to undertake this.

[Kumba]

I'm not opposed to a container if it can run in realtime. The biggest problem with traditional VMs is that 20ms isn't always 20ms. Since LXD looks like it's more of a sandbox/emulation/paravirt then traditional virtualization that might be plausible. I'd need to look into what it takes to build a container in kiwi and if the same level of tuning can happen as bare hardware. It also looks like most containers are very heavily ubuntu/debian centric which isn't what we normally deploy on.

[vkad]

The good thing about containers is that you can have an opensuse container on debian while still sharing all the resources. Only a few things such as /dev/proc /dev/, and so are shared with the parent hypervisor.

So the container can run over debian/ubuntu with LXD as the base for containerisation. Docker itself is a wrapper for LXC (but stateless, so, doesn't have ssh or anything, but just an app).

LXC is a full blown separation of concerns with a shared kernel with the host OS.

Containers, do not miss clock-ticks, since the applications run directly on base OS under different user space. The performance in terms of CPU is pretty much on PAR with the bare metal.

WHERE I DO SEE PROBLEMS with the TIMINGS is in :
- KVM - That is full kernal virtualiasation / different from LXC. Think running windows on Linux, or anything on ESXI
- When the BIOS is set to SAVE POWER or BALANCED.
Note: Disable C_STATES, set everything to Performance, and even KVM usually cleans its act up. You can test this yourself and see a huge difference in your performance of your apps, especially with the latest generation of processors.

What really bugs me is when SYSADMINS would enable POWER SAVE or BALANCED Mode for their servers and complain about performance with their KVM/ESXI machines. You are running a server, a multi thousand dollar machine, with your own costs on top. Stop trying to "save" the company money and the planet some CO2 through "reduced" electricity consumption by sacrificing the performance of the VMs. Its counter-intuitive, as then the SYSADMINS ask for more Servers or run each app on its own server, due to "virtualisation" problems; and eventually end up costing more.


BUT, with LXC I have never seen issues, so avoid full blown virtualisation like KVM/ESXI and only use LXC containerisation.

(LXC is safe from these issues and runs like on par a bare metal OS as it shares the host OS kernel and other things....)

[vkad]

Additionally, less work for you in terms of migration, since you are not developing a lot of custom code just to support virtualisation. You can keep working on what ever you are working on and just create a containerised version to run on another OS.

[kpv]

Hi, I would like to corroborate vkad's experience and suggestions, I think supporting LXC / LXD would be an excellent idea.

There are already pre-built images for OpenSUSE Tumbleweed at images.linuxcontainers.org (although you could also consider an Ubuntu-based Vicibox distro - Ubuntu LTS offers 5 year support, which can be extended to 10 years with HWE).