Cart before the Horse with RPO and RTO - Growing Core Infrastructure with the Company
-
It's also now removed off of two servers that are already over committed. With both it and elastix gone, that frees up resources for something else. While both VMs are minimal it could still help.
-
@scottalanmiller said:
@johnhooks said:
There most likely wouldn't be a disruption, but it's one less thing to worry about in a DR situation and it helps with this issue
No disruption means no DR worry. Paying for DR facilities to eliminate IT effort that has no business impact cost is very hard to justify. It's a difficult conversation to have with the CEO "Well, we are going to pay for this extra project and monthly cost so that I don't have to do as much work." There are cases where the work reduction really does justify that, but this doesn't feel like one of those.
No worry for that, but there is still worry about the other systems that won't all fit on a single server. It may be minimal, but it's still freeing up resources. And it's only $5 a month.
-
@johnhooks said:
It's also now removed off of two servers that are already over committed. With both it and elastix gone, that frees up resources for something else. While both VMs are minimal it could still help.
True, that helps with capacity a little. Although VERY little, we assume.
-
@scottalanmiller said:
@johnhooks said:
It's also now removed off of two servers that are already over committed. With both it and elastix gone, that frees up resources for something else. While both VMs are minimal it could still help.
True, that helps with capacity a little. Although VERY little, we assume.
Right but if you're that low on resources, every little bit helps. Especially if you have to overtax by trying to add more to an already over committed server in a bad scenario.
-
@scottalanmiller said:
@johnhooks said:
It's also now removed off of two servers that are already over committed. With both it and elastix gone, that frees up resources for something else. While both VMs are minimal it could still help.
True, that helps with capacity a little. Although VERY little, we assume.
Probably wouldn't even really be a noticeable difference in resources. I wouldn't be surprised if it's actual used resource was 256-512mb and less than 700mhz of a single CPU when it's not actively being used (99% of the time). Heck you can even leave them powered off it you wanted.
-
@Jason said:
@scottalanmiller said:
@johnhooks said:
It's also now removed off of two servers that are already over committed. With both it and elastix gone, that frees up resources for something else. While both VMs are minimal it could still help.
True, that helps with capacity a little. Although VERY little, we assume.
Probably wouldn't even really be a noticeable difference in resources. I wouldn't be surprised if it's actual used resource was 256-512mb and less than 700mhz of a single CPU when it's not actively being used (99% of the time). Heck you can even leave them powered off it you wanted.
My constraint is not RAM and CPU. It's disk space. So I can get on board with moving a couple of VMs off of the hosts for extra capacity's sake. We'd probably only be talking 40 - 60 GB max for those two servers, but it is something.
-
@NetworkNerd said:
My constraint is not RAM and CPU. It's disk space. So I can get on board with moving a couple of VMs off of the hosts for extra capacity's sake. We'd probably only be talking 40 - 60 GB max for those two servers, but it is something.
With thin provisioning and dedupe, should be more like 2GB. If that.
-
15 GB is the min disk size and then I read a few places where people had issues with Java overtaking resources if they had below 1 GB of RAM. So it is minimal, but it also seems like a lot for what it does.
-
@johnhooks said:
15 GB is the min disk size and then I read a few places where people had issues with Java overtaking resources if they had below 1 GB of RAM. So it is minimal, but it also seems like a lot for what it does.
Min size for what? We provision new PBXs smaller than that. Uses almost nothing. We have them running in 256MB without a problem (although 380MB would be nice.)
-
@scottalanmiller said:
@johnhooks said:
15 GB is the min disk size and then I read a few places where people had issues with Java overtaking resources if they had below 1 GB of RAM. So it is minimal, but it also seems like a lot for what it does.
Min size for what? We provision new PBXs smaller than that. Uses almost nothing. We have them running in 256MB without a problem (although 380MB would be nice.)
The database will crash if you have less than 15 GB disk space. I tried 10 and it wouldn't work until I gave it 15. It's terrible, but everyone else I read had the same issue.
-
@johnhooks said:
The database will crash if you have less than 15 GB disk space. I tried 10 and it wouldn't work until I gave it 15. It's terrible, but everyone else I read had the same issue.
What system are you talking about?
-
@scottalanmiller said:
@johnhooks said:
The database will crash if you have less than 15 GB disk space. I tried 10 and it wouldn't work until I gave it 15. It's terrible, but everyone else I read had the same issue.
What system are you talking about?
Ubuntu. They only have a .deb package.
Oh sorry, the Unifi controller.
-
Gotcha, but that's the portion you just shut down. PBX you need to get back up soon-ish. Controller.. just leave that off.
-
But since we found out the constraint is disk size, that's a decent amount of space for what it's actually doing. So even when off it's still taking up space that could be used somewhere else.
He said above between both it's about 40-60 GB max that's being used.
-
@johnhooks said:
15 GB is the min disk size and then I read a few places where people had issues with Java overtaking resources if they had below 1 GB of RAM. So it is minimal, but it also seems like a lot for what it does.
That doesn't mean that's what is actually used. Also Dedupe like @scottalanmiller will make the base OS images take the same just just one instance. and the unifi controller itself is very little storage.
-
@johnhooks said:
@scottalanmiller said:
@johnhooks said:
15 GB is the min disk size and then I read a few places where people had issues with Java overtaking resources if they had below 1 GB of RAM. So it is minimal, but it also seems like a lot for what it does.
Min size for what? We provision new PBXs smaller than that. Uses almost nothing. We have them running in 256MB without a problem (although 380MB would be nice.)
The database will crash if you have less than 15 GB disk space. I tried 10 and it wouldn't work until I gave it 15. It's terrible, but everyone else I read had the same issue.
Think provisioning will still use less. I haven't ran into that issue.
-
@Jason said:
@johnhooks said:
15 GB is the min disk size and then I read a few places where people had issues with Java overtaking resources if they had below 1 GB of RAM. So it is minimal, but it also seems like a lot for what it does.
That doesn't mean that's what is actually used. Also Dedupe like @scottalanmiller will make the base OS images take the same just just one instance. and the unifi controller itself is very little storage.
I assume you mean dedupe as it relates to backup and replication jobs and not to the data stored in the actual datastore running on local storage of each host.
-
Here's the quote from someone I originally found that helped me:
/usr/lib/unifi/log/server.log and mongod.log which indicated the DB could not be started because there was not enough disk space avaliable.
I ended up with the same issue. I figured a 10 GB minimal install would be enough, but it needs 15 allocated to run.
-
@NetworkNerd said:
@Jason said:
@johnhooks said:
15 GB is the min disk size and then I read a few places where people had issues with Java overtaking resources if they had below 1 GB of RAM. So it is minimal, but it also seems like a lot for what it does.
That doesn't mean that's what is actually used. Also Dedupe like @scottalanmiller will make the base OS images take the same just just one instance. and the unifi controller itself is very little storage.
I assume you mean dedupe as it relates to backup and replication jobs and not to the data stored in the actual datastore running on local storage of each host.
You can dedupe the live storage, if you are using local and not a SAN with ESXi you'd need to use something between that local storage and ESXi to do it (like a VSAN software).
-
@NetworkNerd said:
@Jason said:
@johnhooks said:
15 GB is the min disk size and then I read a few places where people had issues with Java overtaking resources if they had below 1 GB of RAM. So it is minimal, but it also seems like a lot for what it does.
That doesn't mean that's what is actually used. Also Dedupe like @scottalanmiller will make the base OS images take the same just just one instance. and the unifi controller itself is very little storage.
I assume you mean dedupe as it relates to backup and replication jobs and not to the data stored in the actual datastore running on local storage of each host.
Live in many cases. Local storage limits dedupe option but does not remove them.
