With this upcoming project of virtualizing our production stuff, I've been thinking through the appropriate use of checkpoints. I'm sure there are other articles on this, but this seemed to be a good read.
My grand idea is that checkpoints would be used before installing Windows updates or some upgrade to an application. You take the checkpoint, apply the update, and if everything breaks, you apply the checkpoint. If nothing breaks, then you delete the checkpoint.
I'm curious how this would be handled with a SQL Server VM or Redis VM. You'd update your VM, transactions start happening, then things break causing you to have to apply the checkpoint. Any transactions that were done would be lost, which upon further thinking probably doesn't matter, since you probably couldn't trust any data put into the database while the stuff was in the process of breaking.
You have to make sure you don’t have transactions coming in. Simple as that. Anything is a headache waiting to happen.
Makes sense. When I do maintenance on these normally, I stop IIS once downtime’s been announced, then do my work. So I’d just take the checkpoints at that point. I imagine once stuffs back up and I confirm things aren’t broken, Hyper-V just handles merging the avhdx file in such a way that SQL Server, etc is none the wiser. Or is there significant risk of stuff breaking if it’s running while that merge process takes place?
No real risk. Just performance loss.
And never enought to matter to any SMB workload I have ever had to deal with.
@scottalanmiller why install a proxy when Apaches here and working what is the benefit to having a proxy on the same server. Let’s Encrypt perfectly with Apache
Security and flexibility typically. Here is the admitted marketing material from Nginx on security: "Security and anonymity – By intercepting requests headed for your backend servers, a reverse proxy server protects their identities and acts as an additional defense against security attacks. It also ensures that multiple servers can be accessed from a single record locator or URL regardless of the structure of your local area network."
One of the biggest issues is the lack of logging. Things fail, no explanation why. Just "go figure it out". The documentation is abysmal and it appears that no one is using it. Do a search and you can only find their own useless, internal docs.
... I don't see how just using some flashy marketing terms would actually get good talent.
my point exactly! 🙂
Not really what companies using recruiters like that want. It's mostly a myth that people want to hire great talent. Most places want to hire cool sounding, middling talent.
