Encrypting drives for AlwaysOn
To encrypt drives for AlwaysOn, I would suggest these steps:
- Do encryption during low usage hours.
- Encrypt drives on the SECONDARY first without taking AlwaysOn offline.
Perform this during a low-usage time slot. - Encrypt one drive at a time.
- Give it a bit of time for the IO to catch up.
I’d wait 10-15 minutes after each drive encryption completes before starting a new one. This may be overkill, but maybe not, considering we do this in a live PRODUCTION environment.
- Repeat the same steps for the PRIMARY AlwaysOn node.
Several options are available for encrypting drives on PRIMARY
Option 1
Failover AlwaysOn to SECONDARY, and encrypt drives then. Just as described above.
Option 2
I don’t think AlwaysOn failover is a must for drive encryption.
It may be safe to simply encrypt on PRIMARY.
Just pay attention to the latencies of SQL operations. And how long SPIDs are taking.
Start with the smallest drive or least active drive.
I think there may be a good chance this will go fairly unnoticed by SQL Server.
Option 3
- Encrypt volumes on SECONDARY.
- Then set AlwaysOn to asynchronous-commit (currently it’s in synchronous-commit).
Perform the steps as described above. - When complete, set AlwaysOn back to synchronous-commit.
Your workload is quite heavy. On some days, your PRIMARY is spewing out 800MB worth of logs in 5min.
So if PRIMARY gets affected for too long – there is a good chance this will cause issues.
AlwaysOn dashboard.
Use it to make sure AlwaysOn is good.
There you can see AlwaysOn in two statuses:
- Synchronizing – which means, if you failover, you may have data loss. And there is no auto-failover at this point.
- Synchronized – which means both replicas are caught up. All good. And auto-failover is ready to kick in if needed.
If you are trying to encrypt *all* drives for compliance with SOC2 or similar regulations and need to encrypt quorum drives – you can.
Nothing special about this drive.
I would just encrypt without any special steps.