To encrypt drives for AlwaysOn, I would suggest these steps:
- – Do encryption during low usage hours.
- – encrypt drives on SECONDARY first. Without taking AlwaysOn offline. Do this during a low usage time slot.
- – Do one drive at a time.
- – Give a bit of time for IO to catch up. I’d wait 10-15 minutes after each drive encryption completes before starting a new one. This maybe over kill. But maybe not, since we are doing this on live PRODUCTION.
- – Repeat the same steps PRIMARY AlwaysOn node.
To encrypt drives on PRIMARY, you have few options.
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 get a good chance this will go fairly unnoticed to SQL.
Option 3
Encrypt volumes on SECONDARY.
Then set AlwaysOn to asynchronous commit (currently it’s in Synchronous). Perform steps are 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:
- Synchnronizing – 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.
And if you are trying to encrypt *all* drives for compliance with SOC2 or similar regulation and need to encrypt quorum drives – you can. Nothing special about this drive.
I would just encrypt without any special steps.
