Food for thought: Fixing an over-engineered environment
-
@eddiejennings said in Food for thought: Fixing an over-engineered environment:
For a virtualized SQL server and IIS , does it make sense to have separate VHDs for the OS / application and actual database files / virtual folders?
These should not be lumped together, these are polar opposite workloads. IIS is a stateless system with essentially zero storage needs. It should be treated very differently than your most storage heavy system, SQL Server.
For IIS, you'd just use a single VHD and that's it. Easy peasy.
For SQL Server, it likely still makes sense to have a VHD for the OS and one for the data and one for the logs.
-
@eddiejennings said in Food for thought: Fixing an over-engineered environment:
Perhaps the greater question is there any advantage having such separation?
With SQL Server separation you can limit log growth, or snapshot data separately from other things that you don't care about in the same way.
-
REDIS and Postfix are way more likely, as stateful machines, to need special consideration compared to IIS. IIS is like Apache.
-
@scottalanmiller said in Food for thought: Fixing an over-engineered environment:
@eddiejennings said in Food for thought: Fixing an over-engineered environment:
For a virtualized SQL server and IIS , does it make sense to have separate VHDs for the OS / application and actual database files / virtual folders?
These should not be lumped together, these are polar opposite workloads. IIS is a stateless system with essentially zero storage needs. It should be treated very differently than your most storage heavy system, SQL Server.
For IIS, you'd just use a single VHD and that's it. Easy peasy.
For SQL Server, it likely still makes sense to have a VHD for the OS and one for the data and one for the logs.
I don't think I was clear. They are not lumped together. They'll be two separate VMs.
-
@eddiejennings said in Food for thought: Fixing an over-engineered environment:
@scottalanmiller said in Food for thought: Fixing an over-engineered environment:
@eddiejennings said in Food for thought: Fixing an over-engineered environment:
For a virtualized SQL server and IIS , does it make sense to have separate VHDs for the OS / application and actual database files / virtual folders?
These should not be lumped together, these are polar opposite workloads. IIS is a stateless system with essentially zero storage needs. It should be treated very differently than your most storage heavy system, SQL Server.
For IIS, you'd just use a single VHD and that's it. Easy peasy.
For SQL Server, it likely still makes sense to have a VHD for the OS and one for the data and one for the logs.
I don't think I was clear. They are not lumped together. They'll be two separate VMs.
I meant lumped together in your thinking and approach. You have many VMs, but are treated those two like they might have special storage needs. One is your most storage intense, the other is your least. Why treat the two of them as special and not, for example, your other database server?
-
@scottalanmiller said in Food for thought: Fixing an over-engineered environment:
@eddiejennings said in Food for thought: Fixing an over-engineered environment:
For a virtualized SQL server and IIS , does it make sense to have separate VHDs for the OS / application and actual database files / virtual folders?
These should not be lumped together, these are polar opposite workloads. IIS is a stateless system with essentially zero storage needs. It should be treated very differently than your most storage heavy system, SQL Server.
For IIS, you'd just use a single VHD and that's it. Easy peasy.
For SQL Server, it likely still makes sense to have a VHD for the OS and one for the data and one for the logs.
@scottalanmiller on the SQL Server -- Any reason to not use a single larger VHD and partition it as opposed to multiple VHDs?
-
@dafyre said in Food for thought: Fixing an over-engineered environment:
@scottalanmiller said in Food for thought: Fixing an over-engineered environment:
@eddiejennings said in Food for thought: Fixing an over-engineered environment:
For a virtualized SQL server and IIS , does it make sense to have separate VHDs for the OS / application and actual database files / virtual folders?
These should not be lumped together, these are polar opposite workloads. IIS is a stateless system with essentially zero storage needs. It should be treated very differently than your most storage heavy system, SQL Server.
For IIS, you'd just use a single VHD and that's it. Easy peasy.
For SQL Server, it likely still makes sense to have a VHD for the OS and one for the data and one for the logs.
@scottalanmiller on the SQL Server -- Any reason to not use a single larger VHD and partition it as opposed to multiple VHDs?
Yes. Partitions are blind to Hyper-V so if you do that you lose power.
-
I meant lumped together in your thinking and approach. You have many VMs, but are treated those two like they might have special storage needs. One is your most storage intense, the other is your least. Why treat the two of them as special and not, for example, your other database server?
I see what you're saying.
These should not be lumped together, these are polar opposite workloads. IIS is a stateless system with essentially zero storage needs. It should be treated very differently than your most storage heavy system, SQL Server.
For IIS, you'd just use a single VHD and that's it. Easy peasy.
There's about 500 GB of data that's stored on that IIS server which is used in some way by our application (working on figuring out exactly what/how). IIS has a virtual directory that points to it. Should that data live on the one VHD that's for the IIS VM?
-
@eddiejennings said in Food for thought: Fixing an over-engineered environment:
I meant lumped together in your thinking and approach. You have many VMs, but are treated those two like they might have special storage needs. One is your most storage intense, the other is your least. Why treat the two of them as special and not, for example, your other database server?
I see what you're saying.
These should not be lumped together, these are polar opposite workloads. IIS is a stateless system with essentially zero storage needs. It should be treated very differently than your most storage heavy system, SQL Server.
For IIS, you'd just use a single VHD and that's it. Easy peasy.
There's about 500 GB of data that's stored on that IIS server which is used in some way by our application (working on figuring out exactly what/how). IIS has a virtual directory that points to it. Should that data live on the one VHD that's for the IIS VM?
Why is IIS storing stuff?
-
@eddiejennings said in Food for thought: Fixing an over-engineered environment:
I meant lumped together in your thinking and approach. You have many VMs, but are treated those two like they might have special storage needs. One is your most storage intense, the other is your least. Why treat the two of them as special and not, for example, your other database server?
I see what you're saying.
These should not be lumped together, these are polar opposite workloads. IIS is a stateless system with essentially zero storage needs. It should be treated very differently than your most storage heavy system, SQL Server.
For IIS, you'd just use a single VHD and that's it. Easy peasy.
There's about 500 GB of data that's stored on that IIS server which is used in some way by our application (working on figuring out exactly what/how). IIS has a virtual directory that points to it. Should that data live on the one VHD that's for the IIS VM?
yeah, this is how our old EHR was - all the scanned in documents were stored on the IIS server. After 7 years we had 800 GB of documents there - it was a nightmare.
-
@scottalanmiller said in Food for thought: Fixing an over-engineered environment:
@eddiejennings said in Food for thought: Fixing an over-engineered environment:
I meant lumped together in your thinking and approach. You have many VMs, but are treated those two like they might have special storage needs. One is your most storage intense, the other is your least. Why treat the two of them as special and not, for example, your other database server?
I see what you're saying.
These should not be lumped together, these are polar opposite workloads. IIS is a stateless system with essentially zero storage needs. It should be treated very differently than your most storage heavy system, SQL Server.
For IIS, you'd just use a single VHD and that's it. Easy peasy.
There's about 500 GB of data that's stored on that IIS server which is used in some way by our application (working on figuring out exactly what/how). IIS has a virtual directory that points to it. Should that data live on the one VHD that's for the IIS VM?
Why is IIS storing stuff?
Here's where my ignorance of terms is probably going to shine. It's probably our application (which is on the IIS server) storing stuff, not IIS itself. I'm working on getting information from the folks who built this in the first place to figure out what's going on.
-
@eddiejennings said in Food for thought: Fixing an over-engineered environment:
@scottalanmiller said in Food for thought: Fixing an over-engineered environment:
@eddiejennings said in Food for thought: Fixing an over-engineered environment:
I meant lumped together in your thinking and approach. You have many VMs, but are treated those two like they might have special storage needs. One is your most storage intense, the other is your least. Why treat the two of them as special and not, for example, your other database server?
I see what you're saying.
These should not be lumped together, these are polar opposite workloads. IIS is a stateless system with essentially zero storage needs. It should be treated very differently than your most storage heavy system, SQL Server.
For IIS, you'd just use a single VHD and that's it. Easy peasy.
There's about 500 GB of data that's stored on that IIS server which is used in some way by our application (working on figuring out exactly what/how). IIS has a virtual directory that points to it. Should that data live on the one VHD that's for the IIS VM?
Why is IIS storing stuff?
Here's where my ignorance of terms is probably going to shine. It's probably our application (which is on the IIS server) storing stuff, not IIS itself. I'm working on getting information from the folks who built this in the first place to figure out what's going on.
Your app, I’m sure, runs in IIS. But generally, but there are exceptions, you don’t want it atoringbthings on the app server. That’s what the database is for.
-
@dashrender said in Food for thought: Fixing an over-engineered environment:
@eddiejennings said in Food for thought: Fixing an over-engineered environment:
I meant lumped together in your thinking and approach. You have many VMs, but are treated those two like they might have special storage needs. One is your most storage intense, the other is your least. Why treat the two of them as special and not, for example, your other database server?
I see what you're saying.
These should not be lumped together, these are polar opposite workloads. IIS is a stateless system with essentially zero storage needs. It should be treated very differently than your most storage heavy system, SQL Server.
For IIS, you'd just use a single VHD and that's it. Easy peasy.
There's about 500 GB of data that's stored on that IIS server which is used in some way by our application (working on figuring out exactly what/how). IIS has a virtual directory that points to it. Should that data live on the one VHD that's for the IIS VM?
yeah, this is how our old EHR was - all the scanned in documents were stored on the IIS server. After 7 years we had 800 GB of documents there - it was a nightmare.
Cheesy
-
@scottalanmiller said in Food for thought: Fixing an over-engineered environment:
@eddiejennings said in Food for thought: Fixing an over-engineered environment:
@scottalanmiller said in Food for thought: Fixing an over-engineered environment:
@eddiejennings said in Food for thought: Fixing an over-engineered environment:
I meant lumped together in your thinking and approach. You have many VMs, but are treated those two like they might have special storage needs. One is your most storage intense, the other is your least. Why treat the two of them as special and not, for example, your other database server?
I see what you're saying.
These should not be lumped together, these are polar opposite workloads. IIS is a stateless system with essentially zero storage needs. It should be treated very differently than your most storage heavy system, SQL Server.
For IIS, you'd just use a single VHD and that's it. Easy peasy.
There's about 500 GB of data that's stored on that IIS server which is used in some way by our application (working on figuring out exactly what/how). IIS has a virtual directory that points to it. Should that data live on the one VHD that's for the IIS VM?
Why is IIS storing stuff?
Here's where my ignorance of terms is probably going to shine. It's probably our application (which is on the IIS server) storing stuff, not IIS itself. I'm working on getting information from the folks who built this in the first place to figure out what's going on.
Your app, I’m sure, runs in IIS. But generally, but there are exceptions, you don’t want it atoringbthings on the app server. That’s what the database is for.
Makes 100% sense. Unfortunately, that's not going to be fixed. At least not in my lifetime :(.
-
@scottalanmiller said in Food for thought: Fixing an over-engineered environment:
@dashrender said in Food for thought: Fixing an over-engineered environment:
@eddiejennings said in Food for thought: Fixing an over-engineered environment:
I meant lumped together in your thinking and approach. You have many VMs, but are treated those two like they might have special storage needs. One is your most storage intense, the other is your least. Why treat the two of them as special and not, for example, your other database server?
I see what you're saying.
These should not be lumped together, these are polar opposite workloads. IIS is a stateless system with essentially zero storage needs. It should be treated very differently than your most storage heavy system, SQL Server.
For IIS, you'd just use a single VHD and that's it. Easy peasy.
There's about 500 GB of data that's stored on that IIS server which is used in some way by our application (working on figuring out exactly what/how). IIS has a virtual directory that points to it. Should that data live on the one VHD that's for the IIS VM?
yeah, this is how our old EHR was - all the scanned in documents were stored on the IIS server. After 7 years we had 800 GB of documents there - it was a nightmare.
Cheesy
They were so completely and utterly unprepared for the amount of documentation we would have it was ridiculous!.
-
EDIT: Design is now deprecated
Current idea.
- Take the SSDs (Intel S3500) out of Server 1 and 3, and add them to Server 2. Put these into a RAID5 providing 1.5 TB of storage
- Keep Winchester disks in Server 1 (either keep the RAID 10 or go to RAID 6).
- Put the four Intel S3700 SSDs into Server 3.
Server 1 serves block storage to the VM in Server 2 that would be running [the backup software]
Server 2 (with its massive RAM and better processor) becomes a Hyper-V hypervisor
Server 3 currently doesn't have a purpose.I remove the Dell Powerconnect 24 port switch, as it doesn't seem to serve a purpose and replace the Cisco ASA with an Edge Router Pro.
-
@eddiejennings Getting there. Hyper-V should be installed on all the servers. Even when you just have a single VM running on a hypervisor, the time savings in restoring after a hardware failure is worthwhile.
Server 3 could be you're testing/development area and with Hyper-V installed on all of them, you could quickly restore images to it if one of the other servers goes down. Yeah, the performance would just hurt, but at least you'd be running till actual hardware replacements arrive.
-
@travisdh1 said in Food for thought: Fixing an over-engineered environment:
@eddiejennings Getting there. Hyper-V should be installed on all the servers. Even when you just have a single VM running on a hypervisor, the time savings in restoring after a hardware failure is worthwhile.
Server 3 could be you're testing/development area and with Hyper-V installed on all of them, you could quickly restore images to it if one of the other servers goes down. Yeah, the performance would just hurt, but at least you'd be running till actual hardware replacements arrive.
I see. So I'd also make Server 1 a hypervisor with one VM, and that VM would provide block storage to the VM that would be running backup software. That make sense; since on second thought, there would be no reason not to just make it a hypervisor.
-
@eddiejennings said in Food for thought: Fixing an over-engineered environment:
@travisdh1 said in Food for thought: Fixing an over-engineered environment:
@eddiejennings Getting there. Hyper-V should be installed on all the servers. Even when you just have a single VM running on a hypervisor, the time savings in restoring after a hardware failure is worthwhile.
Server 3 could be you're testing/development area and with Hyper-V installed on all of them, you could quickly restore images to it if one of the other servers goes down. Yeah, the performance would just hurt, but at least you'd be running till actual hardware replacements arrive.
I see. So I'd also make Server 1 a hypervisor with one VM, and that VM would provide block storage to the VM that would be running backup software. That make sense; since on second thought, there would be no reason not to just make it a hypervisor.
Yep.
Where you'd see a major benefit in this case is if you ever needed to restore the backup storage from another backup. The hardware doesn't matter so long as it has the needed amount of storage.
-
@eddiejennings said in Food for thought: Fixing an over-engineered environment:
@travisdh1 said in Food for thought: Fixing an over-engineered environment:
@eddiejennings Getting there. Hyper-V should be installed on all the servers. Even when you just have a single VM running on a hypervisor, the time savings in restoring after a hardware failure is worthwhile.
Server 3 could be you're testing/development area and with Hyper-V installed on all of them, you could quickly restore images to it if one of the other servers goes down. Yeah, the performance would just hurt, but at least you'd be running till actual hardware replacements arrive.
I see. So I'd also make Server 1 a hypervisor with one VM, and that VM would provide block storage to the VM that would be running backup software. That make sense; since on second thought, there would be no reason not to just make it a hypervisor.
Yup, basically no exception to installing the hypervisor first.
