Cloud Providers & Sizing

[cparker_RCT]

I recall seeing a thread about cloud instance sizing.
Love how lightweight 3CX is so I'm trying to figure out the most efficient sizing for 8SC to 16SC.

I currently use Digital Ocean, but they seem reluctant to sign a BAA for HIPAA purposes which isn't going to work for a medical office lead I have.
So I'm looking at places like Azure / Amazon (Lightsail)... unless deploying in AWS is more advised.

More of an on-prem guy, but would be great to have some options.

 

[AWS2P]

Amazon lightsail works
Google
OVH
those 3 ones are working well

 

[cobaltit]

https://www.3cx.com/docs/cloud-pbx-providers/

 

[cparker_RCT]

Appreciate the link, but I guess I should clarify some; what’s an efficient sizing for 8-16SC?

 

[cobaltit]

Well that's the beauty of the cloud. You can start at one size and then move up or down as needed with little to no downtime. 1 core 1GB memory is a good starting point but it really depends on how the system is used (queues, recording, lots of BLFs, etc)

 

[cparker_RCT]

Thanks! And I figured as much since 1c 1GB is still pretty fast.
Wish there was an EZ rule of thumb table

 

[cobaltit]

I mean there's this:

https://www.3cx.com/docs/recommended-hardware-specifications-for-3cx/
16 idle extensions isn't going to put as much load as a 8 extension call center. 4 extensions with 40 blfs and 1000 contacts is going to have more load. So all 3CX can do is recommend a baseline and it's up to you to fine tune from there.

 

[eddv123]

In regards to cloud providers you have a good choice. Google I like as the platform will actually tell you if you have over or under-spec'd your platform.

 

[cparker_RCT]

I've discovered that Digital Ocean will NOT sign a BAA if you don't have an account manager. Guess they're out of the picture for now while I start out :\

 

[YiannisH_3CX]

The sizing of the instance depends mainly on your use scenario. A system with 8 SC with no recordings and no queues will be sized differently from a system that requires all calls recorded and has multiple queues or BLF keys. You need to make sure that your system has plenty of resources to handle all scenarios to avoid crushes.

 

[abstractcure]

The original question is a valid question for someone starting their 3cx deployments. Someone like me for example. All I hear is "it depends". Of course it depends on a use case. It is why I'm here trying to find examples of real-life implementations. So, does any guru have an example of a specific configuration, short description of the environment, and LightSail specs?

This is what I'm looking for:

- 13 people law office, 8sc, no recording of calls, only regular voicemail: 1 CPU, 1GB RAM, 40 GB SSD ... ---> GOOD or BAD ?

- 45 administrative people in a manufacturing plant, 16sc, no recording of calls, only regular voicemail: 1 CPU, 2GB RAM, 60 GB SSD ... ---> GOOD or BAD ?

I could really use some hard facts. Thanks guys.

 

[cobaltit]

It's $5/month for lightsail. Fire it up and monitor it it. Not enough resources, upgrade and it's $10. Scalability is what the cloud was invented for and the cost is trivial.

 

[VISA MC]

The original question is a valid question for someone starting their 3cx deployments. Someone like me for example. All I hear is "it depends". Of course it depends on a use case. It is why I'm here trying to find examples of real-life implementations. So, does any guru have an example of a specific configuration, short description of the environment, and LightSail specs?

This is what I'm looking for:

- 13 people law office, 8sc, no recording of calls, only regular voicemail: 1 CPU, 1GB RAM, 40 GB SSD ... ---> GOOD or BAD ?

- 45 administrative people in a manufacturing plant, 16sc, no recording of calls, only regular voicemail: 1 CPU, 2GB RAM, 60 GB SSD ... ---> GOOD or BAD ?

I could really use some hard facts. Thanks guys.

I have 19 extensions all STUN with no call queues or recording, just ring groups. Specs of the AWS is 512mb ram, 1 core, 20gb ssd.

They have zero issues

 

[cparker_RCT]

You don't find the system choking for RAM? (since I auto-corrected to MB not GB )

 

[VISA MC]

You don't find the system choking for RAM? (since I auto-corrected to MB not GB )

I don’t think I’ve ever seen it go above 65%. Usually hovers around 45-55% but I don’t watch it all the time only when we are adding or reconfiguring extensions.

 

[cparker_RCT]

Hmm, fascinating.
total used free shared buff/cache available
Mem: 1461200 496688 249328 44884 715184 766748
Swap: 2095100 11752 2083348

I wonder if it scales based on available memory.

 

[BrenttG]

For any system over 4SC, that you plan to do any higher level functions on, including recording, use 2 cores at minimum, not because it is going to max out core 1, but because in a cloud environment all cores are shared, and if that 1 core suddenly gets spiked, your PBX will hickup, which will be reflected in the audio, and recordings. adding the second core helps with the SMP and keeps the system from peaking as the processes can pop to the second core if such a condition should momentarily occur.

we always spec 2GB RAM as a default and as a minimum, occasionally on heavy systems we have to step it up, but 99% of the time we dont. We also always provision linux instances with 50 GB as a default in thin provisioning mode in case recordings are enabled and the space is needed.

All of this is assuming Debian 9 3cx build, if Windows, 8GB RAM as a minimum due to windows itself and the mess that comes with that, and 2 cores absolute minimum, we resist doing windows builds at all costs, because they are in-efficient, and messy.

Another thing about the core count, remember that if the cloud your deploying to is using intel hyper-threaded CPUs, which 99% of them are, limiting a VM to 1 core, actually equates to half a normal core because hyper-threading splits all cores in half into 2, each getting 50% of the clock cycles. So a single core instance really only gets half a cpu at maximum, 90% of the techs out there either forget this, or never knew it in the first place....

@YiannisH_3CX thoughts on what ive said here?

 

[cparker_RCT]

Thank you @BrenttG for the good information.