@Dashrender said in Veeam Replication to Azure:

@travisdh1 said in Veeam Replication to Azure:

@Jimmy9008 said in Veeam Replication to Azure:

Hi folks,

I am looking to potentially use the replication tool within Veeam B&R to send replicas of key VMs to Azure/AWS for DR purposes. We would not send everything over, only key servers. 1 x Domain Controller, 3 x Web Server and 1 x Database Server. Possibly more, but that is the current list.

How can I calculate prices for running this? The replicas would be offline, so I would expect to only pay storage costs and data inbound costs but no other costs until in a DR situation. I could look at the pricing calculator and add up for generic VMs, but... these are replicas of specific VMs and do not meet templates...

Any pointers would be appreciated.

Cheers.

Why aren't you looking at Glacier, Backblaze B2, or Wasabi? If it's only a few VMs for cold storage, then those 3 will be much cheaper, and B2 and Wasabi are vastly simpler to figure out pricing on.

Do those providers provide a DR situation? If they are only storage, then this is likely not the solution he's looking for.

Correct. I must not have been clear in the original post. Veeam has replication which has advantages over Hyper-V replica native. This can replicate to on site servers, or to DRaaS providers. (I don't think Azure or AWS actually support Veeam Cloud Connect from earlier research).

It looks like ill have to contact providers and get some cold callers hitting me.

@scottalanmiller said in Veeam Replication to Azure:

@Jimmy9008 said in Veeam Replication to Azure:

Veeam Cloud Connect

Who do they support? I think that Veeam CC is a service, not something you use to connect to your own storage options like you are looking for.

I think you just want a normal backup, nothing more. I have a feeling you are mixing the idea of having a cloud DR strategy with the search for storage for your backups. They are separate items and what makes sense for the one, doesn't make sense for the other. The products are fundamentally wrong.

Example... it's S3 or Glacier from Amazon, not EC2, that you'd be looking for.

Im not looking to connect and use them for storage. That would be useless to me. This is for DR.

@Dashrender said in Veeam Replication to Azure:

ants is offsite backups, then S3 or Glacier BB etc are all likely candidates, but if DR is the need, the others he listed seem like some of the prime candid

Backups are already sorted using Veeam with scale out to Azure. To be clear, I am not talking about backups. I am talking about DR. Backups are as they need to be.

The DR part is using Veeam Replica to replicate a from backup, or from the origin host a copy 'replica' of any VM I wish to. I am able to do a replica using Veeam to 1) another host within my own on site/systems globally, or 2) to a cloud provider.

What I am specifically trying to do is find costs to use this Veeam technology to send replicas to a cloud provider. DRaaS. If my site goes down, I can use this DRaaS service to spin up my VMs pretty much instantly. Just like I could do with a replica HyperV VM on a different host...

The question I am trying to answer is getting costs for this. I cant just quote up several VMs in Azure, or AWS or whatever. They are not my replicas. They are standardized templates. Useless to me for this purpose.

@travisdh1 said in Veeam Replication to Azure:

@Jimmy9008 said in Veeam Replication to Azure:

Hi folks,

I am looking to potentially use the replication tool within Veeam B&R to send replicas of key VMs to Azure/AWS for DR purposes. We would not send everything over, only key servers. 1 x Domain Controller, 3 x Web Server and 1 x Database Server. Possibly more, but that is the current list.

How can I calculate prices for running this? The replicas would be offline, so I would expect to only pay storage costs and data inbound costs but no other costs until in a DR situation. I could look at the pricing calculator and add up for generic VMs, but... these are replicas of specific VMs and do not meet templates...

Any pointers would be appreciated.

Cheers.

Why aren't you looking at Glacier, Backblaze B2, or Wasabi? If it's only a few VMs for cold storage, then those 3 will be much cheaper, and B2 and Wasabi are vastly simpler to figure out pricing on.

Ill add them to the list to look at. From research I have done today, it looks like Azure / AWS are not a Veeam Cloud Connect provider anyway. So that removed them from the list.

Hi folks,

I am looking to potentially use the replication tool within Veeam B&R to send replicas of key VMs to Azure/AWS for DR purposes. We would not send everything over, only key servers. 1 x Domain Controller, 3 x Web Server and 1 x Database Server. Possibly more, but that is the current list.

How can I calculate prices for running this? The replicas would be offline, so I would expect to only pay storage costs and data inbound costs but no other costs until in a DR situation. I could look at the pricing calculator and add up for generic VMs, but... these are replicas of specific VMs and do not meet templates...

Any pointers would be appreciated.

Cheers.

Hi folks,

What do you think about using Netwrix Auditor Video Recording? We use Netwrix on our servers already and collect logging on user actions and changes, but we have not enabled session recording. Do you think that is overkill?

I have done some testing, and it feels valuable to be able to click on a session and actually see what the sysadmin did on the server. My use case is to monitor backup servers and file server with video recording. All other servers can go without, but those two types of servers hold very privileged information, and I think having a recording of what is done on the system would be useful.

May be overkill though, and I know a lot of syadmins will not be happy about having their sessions recorded. But again, only being done on the servers holding the privileged data.

What do you think? Video or no video?

Best,
Jim

@pmoncho said in Huge Mistake:

@WrCombs said in Huge Mistake:

There's apparently a theory that you can "freeze a hard drive, and get it to read again"
Anyone ever hear of this?

Yep. Spinners only. I've been successful 3 out of 12 times. It only works when the drive heads or a platter is "stuck"

Wrap in saran wrap and Freeze for 2-3 hours, give a decent love tap along the side of the drive on the floor and plug it in to see if it will start.

Yep, I did this too. Problem is as it heats up the drive fails pretty quickly. So, if you have lots of data to get off the drive, with little time... good luck with that!

@Obsolesce said in Deduplication on CSV storage:

@scottalanmiller said in Deduplication on CSV storage:

@Obsolesce said in Deduplication on CSV storage:

No, as others pointed out. If you want dedupe, do it inside of the VMs on the data volumes there for that kind of stuff, not on the CSV.

Why not on the CSV?

That does it across the board then for everything in it. If that's what he wants, go for it. Just know what you need to do to do it properly. It also depends on a few variables.

Just look over the docs well and know it first.

Sorry, was supposed to quote that. I mean, such as what variables? I've looked at various resources and can't see definitive information about doing this on a csv with VM files and drives...

Not sure if it's sensible. Won't it have an overhead too?

@Obsolesce said in Deduplication on CSV storage:

@Jimmy9008 said in Deduplication on CSV storage:

Hi folks,

We have a three node Windows Failover Cluster, with several CSVs, each provided by Starwind using local storage.

One interesting idea has been brought up internally and i'd like to know if it sounds sensible or possible.

Is it possible to enable deduplication of CSV storage within the cluster? My initial thoughts are that as VM files are open in vmms.exe, the deduplication process will not be able to work on those open files. Is that wrong though? I would expect iso files to dedup a they are offline/not in use, but have a feeling live running VM VHD(X) files on the host will be unable to run through the process...

I could try this, but don't want to risk causing issues to the storage. So, thought best to put the idea out first.

Best,
Jim

No, as others pointed out. If you want dedupe, do it inside of the VMs on the data volumes there for that kind of stuff, not on the CSV.

Such as? I mean, I thought it shouldn't be done. A few people have said no in this thread, some have said yes...

Hi folks,

We have a three node Windows Failover Cluster, with several CSVs, each provided by Starwind using local storage.

One interesting idea has been brought up internally and i'd like to know if it sounds sensible or possible.

Is it possible to enable deduplication of CSV storage within the cluster? My initial thoughts are that as VM files are open in vmms.exe, the deduplication process will not be able to work on those open files. Is that wrong though? I would expect iso files to dedup a they are offline/not in use, but have a feeling live running VM VHD(X) files on the host will be unable to run through the process...

I could try this, but don't want to risk causing issues to the storage. So, thought best to put the idea out first.

Best,
Jim

Yes, the end solution is to make our application have a form of application level HA, but that's up to development to make, not IT.

@scottalanmiller said in Windows Failover Clustering... what are your views and why?:

@Dashrender said in Windows Failover Clustering... what are your views and why?:

@Obsolesce said in Windows Failover Clustering... what are your views and why?:

The thing is, they are VMs, you can move shit around whenever, to wherever, should the need arise.... and without any downtime if needed. I think each server/service/system should have it's own "SLA" (it's almost midnight can't think of the word now) and should be placed appropriately. Only you can answer whether or not it needs HA. You can do the math to figure out exactly what the cost of each GB of SSD capacity, vCPU, Memory, etc. costs for HA placement versus non HA and decide appropriately where to put the VM. I really don't think Hard Drive life is a concern here, you'll pull through the lifespan of the drive easily, or you won't because it's defective which in that case doesn't matter anyways on your decision. So I don't think that's a factor here. It all comes down to math regarding costs vs what is being considered for placement.

wait a second - this whole box was likely built to be 100% HA - so anything running on it, or planned to be running on it was likely scoped with the expectation of being on HA, wither or not HA was needed - at least that's my expectation.

The VM's being put on it now that the OP is talking about, likely were never originally on the board for this cluster/hardware - where they? I mean - where/why are these VMs a thing now and what was the plan for their placement? Did whomever wanted these VMs get the sign off from the ones that paid for the cluster? (devil's advocate)

I think he said that the originally engineering plan was NOT this. It was designed to be non-HA for some or most of the workloads. Super high HA just for select workloads.

Correct. We had to get HA for the subset of our workload. So, this had to be built. We needed less budget to extend the storage, RAM and CPU on these three machines for the non HA compared to having to build entirely separate machines for that workload.

Purely, that was the plan. My mind, it still is. Just some folk are pushing to make all HA. Even, for example, PDQ. We do not need PDQ to be HA. It's a small VM, sure. But it 100% does not need HA. Even if 50GB, we don't need that replicated three times! If it is on a host that does die, if need be, I can start the backup on my veeam box. Once the host is fixed, I can migrate it to the fixed hardware.

Even our webservers don't need HA. Stick one on each host and use HAProxy so when one is down, the we server is taken out of the pool. Sure, make the HAProxy HA, or roll out a HAProxy cluster (I'm sure that would have built in application level HA of some form) but, sure, make that HA if need be.

We have proprietary software on top of windows that isn't made with application level HA. That's why we need the failover clustering. Those VM for sure need to migrate should a physical die. Outside of that, we just don't need it. But for that special case, we do. That's why we have it.

Even domain controllers don't need to be on the CSV. Have one local to each server with the DC in the cluster, but not on shared storage. If a host does die, you still have two DCs online and cam migrate fmso roles (if the holder died). No need to be in the CSV.

But, some folk want all in CSV, and want to waste lots of CSV storage for things that don't need it.

The point of the CSV was that as we increase our proprietary tool over the next few years, there is room to do so. If that space is full of data that doesn't need HA, we have lost the opportunity to use it.

@dbeato said in Windows Failover Clustering... what are your views and why?:

The way we have used StarWind VSAN is that we set it up on an Windows Failover Cluster with the VSAN Storage as a CSV and it synced with the nodes minimum of two. Then all the VMs are placed on the CSV unless you want a VM outside that CSV that is not important at all. With the VMS on the CSV you can have one or more servers down and your enviroment will continue to work without interrupting the VMs as long as you have enough Memory and CPU power to have all the VMs on one host or more.

That's what we pretty much have here. What's happening though, is some want to add ALL virtual machines to the CSV, even when they don't need HA. Like you, I want those to not be on CSV.

@scottalanmiller said in Windows Failover Clustering... what are your views and why?:

@Jimmy9008 said in Windows Failover Clustering... what are your views and why?:

@scottalanmiller said in Windows Failover Clustering... what are your views and why?:

@Dashrender said in Windows Failover Clustering... what are your views and why?:

@scottalanmiller said in Windows Failover Clustering... what are your views and why?:

d business isn't always a goal, but it seems like someone has a bee in their bonnet about somethings that it might no

Would you? or would you move it down to a 2 node setup (or the 3 node setup you mentioned above) and use the extra host for something else?

I don't know abotu the compute needs. I'm given the benefit of the double that the CPU and RAM were properly sized.

We can lose 1/3 of the hosts and the remaining VMs have plenty of room to run on the other 2/3 hosts. Tested.

But could you lose 1/2 and keep running, that's the question.

Probably, actually. The HA VM total around 600 GB RAM used. Each server has 768 GB RAM. So, in theory, yes... We could go down to 1/2 hosts and be up. Not sure how the CPU would cope though, and notich to for growth of the HA VM over the next 3 years or so.

Those VM spread over 2/3 have plenty of RAM available, and CPU, plenty of room for growth which is forecast.

If we lost those non important VM on the 3rd host, and dell couldn't get the part to fix the 3rd for say a week or two, we would even have room on the 2/3 that are up to restore the non critical VM from Veeam.

We do back them all up. It's just my position is we lose a lot adding them to the cluster. Technically, we could start the failed VM from Veeam directly using that instant recovery feature.

It's just hard to justify not using all the CSV space 'as it's there'.... When the reason the space is there... Is for expected growth. If we use for these VM we don't really care about... We lose the ability to grow that actually needs HA.

I think it'll be fine. Just trying to get more logical reasoning why adding to the CSV is silly where HA is not a requirement.

@scottalanmiller said in Windows Failover Clustering... what are your views and why?:

@Jimmy9008 said in Windows Failover Clustering... what are your views and why?:

The problem I have is that some people are pushing to just put all VM on the clustered storage. Which is against the design. It wasnt designed to make everything HA, as everything doesn't need HA.
It was designed to make everything that needs HA get HA, with room for ability to run VMs, lots of them, that need no HA at all.

The problem there, is that one group designed it for one purpose. Now the group deploying it is requesting that the design be used for another purpose.

Indeed. It's deployed for and been in use for months now. Just folk don't want to create VMs outside of the CSVs. Where, I'm trying to cover that when deploying a VM, you need to do an analysis bro decide if it needs HA. And if, only if it does, then put it on the CSV. Otherwise, pick one of the three and create the VM on local only. Hell, add the VM to the cluster for management, but keep it local. Sure, it won't failover, but we don't care if it can go down.

@scottalanmiller said in Windows Failover Clustering... what are your views and why?:

@Dashrender said in Windows Failover Clustering... what are your views and why?:

@scottalanmiller said in Windows Failover Clustering... what are your views and why?:

d business isn't always a goal, but it seems like someone has a bee in their bonnet about somethings that it might no

Would you? or would you move it down to a 2 node setup (or the 3 node setup you mentioned above) and use the extra host for something else?

I don't know abotu the compute needs. I'm given the benefit of the double that the CPU and RAM were properly sized.

We can lose 1/3 of the hosts and the remaining VMs have plenty of room to run on the other 2/3 hosts. Tested.

@Dashrender said in Windows Failover Clustering... what are your views and why?:

@scottalanmiller said in Windows Failover Clustering... what are your views and why?:

d business isn't always a goal, but it seems like someone has a bee in their bonnet about somethings that it might no

Would you? or would you move it down to a 2 node setup (or the 3 node setup you mentioned above) and use the extra host for something else?

We do have some VMs that do require HA. That's why we built this system. The cost is totally within the budget and the system meets the needs.

The problem I have is that some people are pushing to just put all VM on the clustered storage. Which is against the design. It wasnt designed to make everything HA, as everything doesn't need HA.

It was designed to make everything that needs HA get HA, with room for ability to run VMs, lots of them, that need no HA at all.

@scottalanmiller said in Windows Failover Clustering... what are your views and why?:

@Jimmy9008 said in Windows Failover Clustering... what are your views and why?:

Another thought. CSV data is replicated to all three hosts. So, 100 GB is actually 300 GB. 1 TB is actually 3 TB. Why would it make sense to add VMs (applications) the company can sustain long downtime with to an area where it takes up 3 x the space, on expensive SSDs. Why not put that application you dont care about, on one host, where it takes up one lot of space, leaving the other space for things the company does care about...

Well, the logic would be... if the space is available, why waste it. If the space isn't available, seems like your choice is made for you by design.

The available space has been made for growth expectation over the next few years. If I make all of the local storage CSV and replicated, and copy all VM (including the ones that aren't important) for three times, we won't have that room to grow in to... As it's used for storing the mirror of VMs that don't need HA. Just seems like a waste.

@scottalanmiller said in Windows Failover Clustering... what are your views and why?:

@Jimmy9008 said in Windows Failover Clustering... what are your views and why?:

Data in the CSV will replicate over all three nodes because of Starwind. So, each write to a CSV is actually three fold. If all VMs are in CSV storage and writing to all three hosts, we could considerably lower the life of our SSDs.

Are you sure that this is the setup? If so, this is non-standard for Starwind (or anyone.) That's a triple mirror RAID 1 design. Really fast and really safe, but generally seen as overkill. Standard on Starwind would be three standard double mirror RAID 1 arrays, one between Node 1 and Node 2, one between Node 2 and Node 3, and one between Node 3 and Node 1. So any data would be replicated, but only once, not twice.

Yeah, we had that originally but moved to three node replication. Some local storage for vsan, rest for non vsan. The original plan (still is other than this internal argument) was to use the CSV for machines that need HA, and the rest of the local for machines that don't. Just some folk are pushing for making the whole lot of the local CSV storage and making all VM HA in the cluster...

Just trying to see if any reason why that's a good idea. Seems to be bad from all thought processes I have.

@scottalanmiller said in Windows Failover Clustering... what are your views and why?:

@Jimmy9008 said in Windows Failover Clustering... what are your views and why?:

We have a Windows Failover Cluster here using Starwind vSAN over three hosts, all local SSD storage.

I'm sure that this was covered somewhere, but are you saying that this is hyperconverged and that there are three total nodes and that Starwind VSAN is what is clustering them? So not three compute nodes hooked to a remote VSAN, but just standard three node HC?

Yeah, same system but we eventually decided to have each image on all three hosts rather than two. So, all three hosts now have the starwind provided clustered target.