XenServer Export Performance Seems Poor
-
@DustinB3403 said:
But this doesn't answer why you have a 700GB VM, I'd move any data you can off of it and onto a protected network share.
This way you can restore the VM more rapidly rather than trying to import 700GB back into Xen.
That data is what is important - so other than perhaps having multiple drives, and exporting them individually, I'm not what I gain?
So let's say I two VMs, one for the actual application, and another for the data. Sure, if the small application VM dies, I can restore that quickly, but what about when the data VM dies? Then I'm still left in a long haul restore process.
I suppose you might say - well, you could break the application VM via an update, which is much more likely than breaking the data VM. OK that's true. Then I could restore my application VM quickly, connect to my data and be back online faster.
But that means either buying another Windows server license or making my data accessible to Windows application server from a free Nix box, which for all intents and purposes should be possible.
-
@Dashrender said:
But that means either buying another Windows server license or making my data accessible to Windows application server from a free Nix box, which for all intents and purposes should be possible.
that's just setting up Samba for file sharing. Super standard.
-
@scottalanmiller said:
@Dashrender said:
But that means either buying another Windows server license or making my data accessible to Windows application server from a free Nix box, which for all intents and purposes should be possible.
that's just setting up Samba for file sharing. Super standard.
Yeah I know. And assuming I use all internal networking, I should be at near 1 Gb between the VMs.
-
I would say that putting the data onto a protected NAS or Samba Share which is appropriately backed up would provide a higher level of protection for your Production VM.
As I see it the main purpose of the VM (in terms of recovery) is "how quickly can I recover this VM".
If it's a 700GB VM you'd be there for 30 hours with the system down until it completed its import. (assuming nothing goes wrong).
So by moving as much data off of the VM, you're offering a better level of protection to the business if you need to recover the VM.
The data can easily be protected between a Samba Share and a Data storage provider.
-
Right - but you missed what I was saying.
What makes the application VM any more vulnerable than the NAS/SAMBA share? Nothing really. Hardware wise, the VM is probably better off than the NAS. And a SAMBA share should be inside a VM assuming it's not a NAS, so the SAMBA share is exactly the same as the application VM.
As I mentioned... the main thing that puts the application at a greater risk is application/OS updates, of which the SAMBA share VM would only have OS updates.
I'm seeing you trying to say it's better to not have all of your eggs in one basket - which Scott has shown definitely isn't always true.
As for I'm using a VM mainly because how quickly can I recover this VM yeah, there may be something to that.. but that's not the main reason for me. For me is easy of recover-ability, and portability - meaning I can stand the VM up on pretty much any hardware, easily because it's a VM, not a bare metal restore that will require drivers, etc.
-
Add to all that this is nearly a read only system. Sadly I can't truly make it a read only system, I don't have to worry about backups once I have a good working backup in place. If someone makes changes to it, I don't care about those changes.
-
@Dashrender said:
Add to all that this is nearly a read only system. Sadly I can't truly make it a read only system...
Why one and not the other? Meaning, why is it read only but you can't make it read only?
-
@scottalanmiller said:
@Dashrender said:
Add to all that this is nearly a read only system. Sadly I can't truly make it a read only system...
Why one and not the other? Meaning, why is it read only but you can't make it read only?
As it was explained to me, there aren't user permissions in the system that allow full reading without also allowing for some level of writing.
The vendor EOL'ed it in 2013 and we jumped off as close to the date as possible. There are no devs around for it that we have access to.
-
@Dashrender said:
As it was explained to me, there aren't user permissions in the system that allow full reading without also allowing for some level of writing.
So this is a database that the vendor does not control? How does such a weird situation arise?
-
If you have it running on a VM, surely you can make it read only from a highly level so that there is no need to write?
-
@scottalanmiller said:
@Dashrender said:
As it was explained to me, there aren't user permissions in the system that allow full reading without also allowing for some level of writing.
So this is a database that the vendor does not control? How does such a weird situation arise?
I don't know what you mean?
We bought a product called Clinician. It was bought/sold 3 times while we were using it. The last company bought it and killed it, of course in the hopes that we (and the rest) would just jump onto the new owner's main product - which we did not do.
-
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
As it was explained to me, there aren't user permissions in the system that allow full reading without also allowing for some level of writing.
So this is a database that the vendor does not control? How does such a weird situation arise?
I don't know what you mean?
We bought a product called Clinician. It was bought/sold 3 times while we were using it. The last company bought it and killed it, of course in the hopes that we (and the rest) would just jump onto the new owner's main product - which we did not do.
I mean, if you don't want the system to be writeable... that's up to you, not up to the product, right? So if it is read only, you can make it so. That the product requires the ability to write seems to be inconsequential, how would it do that? You can make the system either refuse writes or just make it roll back on reboot. In either case, you have no needs to treat it any way other than RO.
-
@scottalanmiller said:
If you have it running on a VM, surely you can make it read only from a highly level so that there is no need to write?
I don't understand this either.
The VM presents an IIS .Net website that only works in IE with a back end of SQL 2008 Server.
Are you proposing that I could either
- make the VM read only
- make the SQL DB read only
- make the IIS site read only
In all of these cases I have to assume that making it read only would break the way it works - I don't know this, but I'm assuming this.
-
@Dashrender said:
Are you proposing that I could either
- make the VM read only
- make the SQL DB read only
- make the IIS site read only
In all of these cases I have to assume that making it read only would break the way it works - I don't know this, but I'm assuming this.
All, lock it down. If the data is read only, you don't want it changing, ever, right? So stop it from changing. IIS should be read only anyway, why would that not be stateless? The DB is probably doing something, but what do you care? You want it read only. So just roll it back with every reboot or forbid it to write at all.
-
@scottalanmiller said:
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
As it was explained to me, there aren't user permissions in the system that allow full reading without also allowing for some level of writing.
So this is a database that the vendor does not control? How does such a weird situation arise?
I don't know what you mean?
We bought a product called Clinician. It was bought/sold 3 times while we were using it. The last company bought it and killed it, of course in the hopes that we (and the rest) would just jump onto the new owner's main product - which we did not do.
I mean, if you don't want the system to be writeable... that's up to you, not up to the product, right? So if it is read only, you can make it so. That the product requires the ability to write seems to be inconsequential, how would it do that? You can make the system either refuse writes or just make it roll back on reboot. In either case, you have no needs to treat it any way other than RO.
Oh well sure - I can definitely make it role back on reboots - though, now that I think about it.. I can't do that either.. because while I want the data itself to be read only - I need access logs. Those logs are part of the system itself. Now those logs are in the SQL DB, and I could just backup the SQL DB or find a way to export them and only backup that part... then worry less about the rest...
-
I think what @scottalanmiller is saying is similar to what I was asking.
Why not make the VM "static" pushing all of the files off to something else. This way you're protecting the VM while still providing a good way to recover should something go sideways.
-
@Dashrender said:
Oh well sure - I can definitely make it role back on reboots - though, now that I think about it.. I can't do that either.. because while I want the data itself to be read only - I need access logs. Those logs are part of the system itself. Now those logs are in the SQL DB, and I could just backup the SQL DB or find a way to export them and only backup that part... then worry less about the rest...
So it is NOT read only, hence the problem.
-
@scottalanmiller said:
@Dashrender said:
Oh well sure - I can definitely make it role back on reboots - though, now that I think about it.. I can't do that either.. because while I want the data itself to be read only - I need access logs. Those logs are part of the system itself. Now those logs are in the SQL DB, and I could just backup the SQL DB or find a way to export them and only backup that part... then worry less about the rest...
So it is NOT read only, hence the problem.
Continuing discussion has brought this to the surface.. I wasn't intentionally just not mentioning it earlier.. so yeah... that part at least is not read only.
-
@DustinB3403 said:
Why not make the VM "static" pushing all of the files off to something else. This way you're protecting the VM while still providing a good way to recover should something go sideways.
But that amount of data is still going to take a while to recover, regardless of where it is.
Granted, you can get the applciation VM back up and start restoring the important pieces of the data. Is that what you mean?
-
@Dashrender said:
@scottalanmiller said:
@Dashrender said:
Oh well sure - I can definitely make it role back on reboots - though, now that I think about it.. I can't do that either.. because while I want the data itself to be read only - I need access logs. Those logs are part of the system itself. Now those logs are in the SQL DB, and I could just backup the SQL DB or find a way to export them and only backup that part... then worry less about the rest...
So it is NOT read only, hence the problem.
Continuing discussion has brought this to the surface.. I wasn't intentionally just not mentioning it earlier.. so yeah... that part at least is not read only.
Can the logs just go elsewhere? ELK for example?
