Cart before the Horse with RPO and RTO - Growing Core Infrastructure with the Company
-
@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.
-
@scottalanmiller said:
@NetworkNerd said:
I think someone can help quantify the gap, and I'm hoping I can find that individual and get them to help me. I seem to be the one who is most interested in gap insurance.
If factors change, IT reminding people that RTO has expanded due to load changes, presenting new costs because things have changed or whatever is one thing. But trying to convince the owners that their financial planning isn't as good as yours and that you should be driving the financial decisions of the company is a fundamentally wrong course for IT. If this is even slightly the case, you should be in the CFO's office running finance, not in IT, because you'd be far more valuable there.
You're right. I should not be worried if no one else is. I should seek to educate. They at least need to know what the numbers have become and the recommendation from us to decrease that window (if they want one, that is). What I don't know at this point is if my boss's lack of concern about the state of these windows will be the same for those at the executive level.
The DR topic is not one that comes up often. I think execs really don't think about it or whether the corporate growth plan has an infrastructure support plan to go with it.
Maybe the next step is to have some conversations with one of the head operations execs.
-
@NetworkNerd said:
You're right. I should not be worried if no one else is. I should seek to educate. They at least need to know what the numbers have become and the recommendation from us to decrease that window (if they want one, that is). What I don't know at this point is if my boss's lack of concern about the state of these windows will be the same for those at the executive level.
You don't need recommendations. You just need to education. Don't introduce your own opinion here, that's extra. Figure out the current RTO/RPO, send out a memo. That's all that you really need. If they are concerned, they are free to request more info.
Why spend IT time and effort to produce recommendations that may not be wanted? They need to know that factors have change, inform them. They can figure out what to do from there.
-
@NetworkNerd said:
The DR topic is not one that comes up often. I think execs really don't think about it or whether the corporate growth plan has an infrastructure support plan to go with it.
Mention to them that ANY planning without IT involved means IT cannot be responsible in any way. How do they expect the company to have a plan if they ignore the planning process?
