Cart before the Horse with RPO and RTO - Growing Core Infrastructure with the Company
-
@Jason said:
@johnhooks said:
@NetworkNerd said:
Unifi controller VM (servicing all sites) - 1 VM as controller for APs across all sites
This probably won't make a big difference at all, but could this be put on a hosted VM somewhere? That would at least alleviate restoring this VM if something happens.
That wouldn't make sense. At least not for the reasons you state. Remember there needs to be valid business reasons for doing this. In the Case of DR it's to provide business continuity. What business disruption will be caused if the unifi controller is down?
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
Since those two servers were put in, the number of users has grown, the number of VMs has grown, and the amount of storage in use has grown. We're at the point where neither server would have enough storage to run all VMs from the other server if one of them failed. That's a problem and creates an interesting DR situation.
It could most likely be run on the lowest tier DO or Vultr server for ~$5 a month. It was also listed as a core application, so having that off site if possible would be better.
-
@johnhooks said:
@Jason said:
@johnhooks said:
@NetworkNerd said:
Unifi controller VM (servicing all sites) - 1 VM as controller for APs across all sites
This probably won't make a big difference at all, but could this be put on a hosted VM somewhere? That would at least alleviate restoring this VM if something happens.
That wouldn't make sense. At least not for the reasons you state. Remember there needs to be valid business reasons for doing this. In the Case of DR it's to provide business continuity. What business disruption will be caused if the unifi controller is down?
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
You wouldn't be worrying about something that provides no business continuity in a DR situation. That would be something you can deal with much later. The focus should be on things that directly have a monetary impact on the business.
-
@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.
-
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.
