AWS DRS 第二部分 - 測試與監控

昨天配置好 DRS 的源伺服器和複寫主機後，
我們來測試是否有成功複寫至次要區域！

六、測試故障轉移

我們可以做一個假設情境的故障轉移，來測試我們的災難備援策略的可執行性

1. 在 DRS 控制台中創建一個演練
2. 選擇要包括在演練中的伺服器
3. 啟動演練並監控進度
4. 驗證原本環境功能及資料是否完整
5. 完成後，執行清理步驟

七、設定持續複製

1. 確保源伺服器和AWS之間的網絡連接穩定
2. 監控複製延遲和複製狀態
3. 根據需要調整頻寬使用設置

八、配置監控和警報

1. 設置Amazon CloudWatch警報以監控關鍵指標
2. 配置EventBridge規則以響應特定的DRS事件
3. 設置通知機制，如SNS主題

本次30天文章中，之前有提到配置CloudWatch的指標及警示
可以到連結複習一下唷！
Day11 帳號監控 > CloudWatch 指標 Metrics
Day13 帳號監控 > CloudWatch 警報 Alarms

這邊我們建立指標時可以選用下列：

• ReplicationServerState: 監控複製服務器的狀態
• DataReplicationLatency: 監控數據複製的延遲
• RecoveryInstanceState: 監控恢復實例的狀態

建立後，再使用警示來套用建立的指標，可發送SNS或者email來通知

以下建議配置指標及警示條件：

1. 複製延遲警報：

監控指標：DataReplicationLatency
警示條件：大於 30 分鐘
描述："資料複製延遲超過 30 分鐘"

2. 複製伺服器狀態警報：

監控指標：ReplicationServerState
警示條件：不等於 "HEALTHY"
描述："複製伺服器狀態異常"

3. 恢復實例狀態警報：

指標：RecoveryInstanceState
條件：等於 "STOPPED" 或 "TERMINATED"
描述："恢復實例已停止或終止"

4. 演練狀態警報：

指標：DrillStatus
條件：等於 "FAILED"
描述："DRS 演練失敗"

九、執行實際故障轉移

1. 評估故障轉移的需求
2. 在DRS控制台中啟動恢復
3. 監控恢復進度
4. 驗證應用程序功能
5. 更新DNS或負載均衡器以指向恢復的實例

十、持續維護和優化

做完一整套的災難備援規畫及實行後，
還是需要持續的維護，以及根據未來使用狀況，不斷優化災難備援策略

1. 定期執行故障轉移演練
2. 根據應用程序變化更新復原設置
3. 監控和優化成本
4. 保持AWS Replication Agent為最新版本

災難備援，在難不慌，大家要有未雨綢繆的好習慣唷!