在 AWS 上執行 Dell PowerProtect 備份的組織面臨一個經常性挑戰：多設備生態系統——PPDM（PowerProtect Data Manager）、DDVE（Data Domain Virtual Edition）和 DDMC（Data Domain Management Center）——需要仔細且有序的佈建，這很難在不同區域和帳戶之間一致地重複。
本文介紹一種使用 Terraform 進行基礎設施佈建，以及使用 AWS Step Functions 進行部署後協調，以自動化 Dell PowerProtect 在 AWS 上部署的方法。此處描述的模式適用於任何在 AWS 上執行 Dell 備份設備，並希望從手動或半自動化部署轉向完全編碼、可重複框架的企業。
為什麼要在 AWS 上自動化 Dell 備份？
Dell PowerProtect 元件在 AWS 上通常是從 Marketplace AMI 以 EC2 執行個體的形式部署。雖然部署本身很直接，但挑戰在於之後的步驟：
- DDMC 需要互動式首次登入精靈（EULA 接受、密碼變更、檔案系統設定）
- PPDM 需要 REST API 驅動的設定（授權、NTP、憑證設定、原則建立）
- DDVE 必須透過協調的 API 呼叫同時向 PPDM 和 DDMC 註冊
- DNS 解析 必須包含正向和反向記錄——PPDM 在接受整合合作夥伴之前會驗證雙向 DNS
- 憑證 需要從第一天起就進行安全儲存和輪換
手動進行此程序會導致設定漂移、產生未記錄的部落知識，且無法擴展。基礎設施即程式碼可消除這些風險。
參考架構
一個生產級的 Dell PowerProtect 自動化框架在 AWS 上橫跨四層：
┌─────────────────────────────────────────────────────────────────────┐
│ Layer 1: Terraform - Infrastructure │
│ VPC / Subnets / Security Groups / Route53 / IAM / KMS / Secrets │
├─────────────────────────────────────────────────────────────────────┤
│ Layer 2: Terraform - Appliance Deployment │
│ PPDM EC2 Instance / DDVE EC2 Instance / DDMC EC2 Instance │
│ EBS Volumes / Network Interfaces / Instance Profiles │
├─────────────────────────────────────────────────────────────────────┤
│ Layer 3: Step Functions - Configuration │
│ Lambda: Configure DDMC (SSH) │
│ Lambda: Configure PPDM (REST API) │
│ Lambda: Integrate DDVE ↔ PPDM/DDMC (REST API) │
│ Lambda: Credential Rotation (Secrets Manager) │
├─────────────────────────────────────────────────────────────────────┤
│ Layer 4: Operational Monitoring │
│ EventBridge → Monitor Lambda → DynamoDB → ITSM Integration │
└─────────────────────────────────────────────────────────────────────┘
Enter fullscreen mode Exit fullscreen mode
每一層都有明確的職責邊界，且其中一層的變更不會不可預測地波及到其他層。
第一層：網路與安全基礎
VPC 與子網路設計
Dell 備份設備在特定連接埠（2051、2052、3009 用於 Data Domain 通訊協定，443 用於管理 API）進行通訊。您的網路模組應佈建：
- 為備份設備專用的 VPC（或現有 VPC 內的子網路範圍）
- 跨多個可用區域的私有子網路以確保復原能力
- 具有細粒度輸入/輸出規則的安全群組，範圍限定於 Dell 通訊協定連接埠
- NAT 閘道存取，用於 Marketplace 授權驗證和更新
DNS：隱藏的需求
PPDM 常見的部署失敗是因 DNS 解析問題導致整合被拒絕。PPDM 會執行雙向 DNS 驗證——它會將 DDVE 主機名稱解析為 IP，然後將該 IP 反向解析回主機名稱，並期望兩者相符。
您必須自動化兩者：
- 在 Route53 私有託管區域中的正向 DNS（A 記錄）
- 在反向查詢區域中的反向 DNS（PTR 記錄）（例如
10.in-addr.arpa）
如果沒有 PTR 記錄，PPDM 會失敗並出現如「網路驗證失敗」或「無法解析 FQDN/IP 位址」的錯誤。這沒有被充分記錄，且許多團隊會措手不及。
# Terraform reverse DNS zone and PTR record
resource "aws_route53_zone" "reverse" {
name = "10.168.192.in-addr.arpa"
vpc {
vpc_id = aws_vpc.backup.id
}
}
resource "aws_route53_record" "ppdm_ptr" {
zone_id = aws_route53_zone.reverse.zone_id
name = "15.10.168.192.in-addr.arpa"
type = "PTR"
ttl = 300
records = ["ppdm.backup.internal"]
}
Enter fullscreen mode Exit fullscreen mode
IAM 與密鑰管理
每個設備角色都應遵循最小權限原則：
- PPDM 執行個體角色：存取 Secrets Manager（自己的憑證）、S3（備份目標）、SSM（用於代理程式部署）
- DDVE 執行個體角色：用於加密磁碟區的 KMS 解密、用於輪換的 Secrets Manager
- DDMC 執行個體角色：用於參數擷取的 SSM、用於探索的 EC2 DescribeInstances
從一開始就將初始和輪換後的憑證儲存在 AWS Secrets Manager。避免將憑證嵌入 EC2 使用者資料或依賴執行個體 ID 作為預設密碼。
第二層：使用 Terraform 部署設備
每個 Dell 設備都是從 Marketplace AMI 佈建的 EC2 執行個體。主要考量事項：
PPDM 部署
- 執行個體類型：
m5.xlarge或更大（最低 4 個 vCPU、16 GB RAM） - 根磁碟區：100 GB gp3
- 根據目錄大小的額外資料磁碟區
- 用於 DNS 一致性的彈性 IP 或穩定的私有 IP
DDVE 部署
- 執行個體類型：儲存最佳化（
m5.2xlarge或r5.xlarge，視容量層級而定） - 多個 EBS 磁碟區用於中繼資料和資料（DDVE 使用特定的磁碟區佈局）
- 用於重複資料刪除工作負載的高 IOPS 設定
- 對於大型部署，請考慮 io2 Block Express
DDMC 部署
- 執行個體類型：
m5.large（作為管理平面，需求較輕） - 用於其內部資料庫的資料磁碟區
- 對其將管理的所有 DDVE 執行個體的網路存取
# Parameterized appliance deployment
module "ppdm" {
source = "./modules/dell-appliance"
appliance_type = "ppdm"
ami_id = var.ppdm_ami_id
instance_type = var.ppdm_instance_type
subnet_id = module.network.private_subnet_ids[0]
security_groups = [module.network.ppdm_sg_id]
iam_profile = module.iam.ppdm_instance_profile
tags = {
Application = "dell-backup"
Component = "ppdm"
Environment = var.environment
}
}
Enter fullscreen mode Exit fullscreen mode
關鍵原則：Terraform 處理「是什麼」（基礎設施狀態），但不處理「如何做」（設備內部設定）。這就是 Step Functions 的用武之地。
第三層：使用 Step Functions 進行部署後設定
為什麼不使用 Terraform Provisioners？
Terraform provisioners（remote-exec、local-exec）很誘人，但對於多步驟設備設定來說有問題：
- 它們在
terraform apply時執行，且無法獨立重試 - 它們沒有內建狀態機器來處理具有等待條件的順序步驟
- 失敗會使 Terraform 狀態處於不一致的位置
- 它們破壞了宣告式模型——基礎設施與執行階段行為耦合
AWS Step Functions 提供了更好的解決方案：具有重試、逾時、分支和獨立執行的可見狀態機器。
設定 Lambda 函式
DDMC 設定（基於 SSH）
DDMC 的首次登入程序是一個互動式 SSH Shell 精靈。使用 Paramiko（Python SSH 函式庫）的 Lambda 函式可自動化此程序：
- 透過 SSH 連線到 DDMC（從 Secrets Manager 取得初始預設憑證）
- 透過模式比對終端機輸出接受 EULA 提示
- 將 sysadmin 密碼變更為產生的值
- 完成設定精靈（時區、主機名稱、網路確認）
- 以定義的配額建立備份檔案系統
- 將新憑證儲存在 Secrets Manager 中
關鍵挑戰：精靈提示文字會因 DDMC 韌體版本而異。使用逾時和回退偵測建立防禦性模式比對。
PPDM 設定（基於 REST API）
PPDM 在啟動後於連接埠 443 公開 REST API，但在 EC2 進入「執行中」狀態後，API 通常需要 3-8 分鐘才會回應。您的 Lambda 需要：
- 以指數退避輪詢 PPDM API 健康狀態端點
- 使用預設憑證進行驗證
- 透過 API 接受 EULA
- 變更管理員密碼
- 設定 NTP 設定
- 啟用授權
- 建立預設保護原則
DDVE-PPDM-DDMC 整合
整合 Lambda 協調跨設備註冊：
- 向 PPDM API 驗證
- 在 PPDM 中新增 DDVE 作為儲存目標（需要 DDVE 憑證）
- 向 DDMC API 驗證
- 在 DDMC 中註冊 DDVE 執行個體
- 透過狀態檢查驗證整合
- 執行測試備份以確認端到端連線
Step Function 定義
{
"StartAt": "WaitForAppliances",
"States": {
"WaitForAppliances": {
"Type": "Wait",
"Seconds": 300,
"Next": "ConfigureDDMC"
},
"ConfigureDDMC": {
"Type": "Task",
"Resource": "arn:aws:lambda:...:configure-ddmc",
"Retry": [
{
"ErrorEquals": ["States.ALL"],
"IntervalSeconds": 30,
"MaxAttempts": 3,
"BackoffRate": 2.0
}
],
"Next": "ConfigurePPDM"
},
"ConfigurePPDM": {
"Type": "Task",
"Resource": "arn:aws:lambda:...:configure-ppdm",
"Retry": [
{
"ErrorEquals": ["States.ALL"],
"IntervalSeconds": 60,
"MaxAttempts": 5,
"BackoffRate": 2.0
}
],
"Next": "IntegrateDDVE"
},
"IntegrateDDVE": {
"Type": "Task",
"Resource": "arn:aws:lambda:...:integrate-ddve",
"Retry": [
{
"ErrorEquals": ["States.ALL"],
"IntervalSeconds": 30,
"MaxAttempts": 3,
"BackoffRate": 2.0
}
],
"End": true
}
}
}
Enter fullscreen mode Exit fullscreen mode
第四層：營運監控與 ITSM 整合
部署完成後，Dell 備份設備需要主動監控。無伺服器監控模式效果良好：
監控架構
- EventBridge 排程規則——每 10 分鐘觸發一次監控 Lambda
- 監控 Lambda——向 DDMC REST API 驗證，擷取 DDVE 健康狀態和作用中警示
- DynamoDB 資料表——儲存目前的警示狀態以進行去重複和追蹤
- DynamoDB Streams——在有新的或變更的警示時觸發 ITSM Lambda
- ITSM Lambda——格式化事件並轉送至您的事件管理系統（ServiceNow、Jira Service Management 等）
警示事件結構描述
將您的事件格式標準化以供下游使用：
{
"event_id": "unique-uuid",
"source": "dell-backup-monitor",
"severity": "critical",
"appliance": "ddve-01.backup.internal",
"alert_name": "Appliance Not Responding",
"timestamp": "2026-07-15T10:30:00Z",
"region": "eu-west-1",
"action_required": "Investigate DDVE connectivity"
}
Enter fullscreen mode Exit fullscreen mode
事件封存
將所有事件以結構化路徑封存到 S3 以進行稽核和合規：
s3://backup-events/{service}/{account_id}/{region}/{date}/{event_id}-{severity}.json
Enter fullscreen mode Exit fullscreen mode
大規模 EC2 備份納管
最後的自動化步驟是將 EC2 執行個體納入 Dell Backup 保護：
-
基於標籤的定位——標記為
Backup: enabled的執行個體會被發現 - SSM 自動化——AWS Systems Manager 在無需 SSH 存取的情況下安裝 PPDM 代理程式
- 代理程式註冊——代理程式使用預先設定的伺服器端點向 PPDM 註冊
-
原則指派——根據工作負載標籤指派保護原則（例如
BackupPolicy: daily-30day-retention） - 健康狀態驗證——安裝後檢查確認代理程式與 PPDM 的連線
將備份納管作為獨立的自動化——不要將其與一般 EC2 生命週期管理耦合。備份原則的變更獨立於作業系統修補或擴展事件。
常見陷阱及其避免方法
| 陷阱 | 影響 | 解決方案 |
|---|---|---|
| 缺少 PTR 記錄 | PPDM 整合靜默失敗 | 在您的網路模組中自動化反向 DNS |
| 預設密碼未變更 | 安全性漏洞 | 在首次啟動時輪換，並儲存在 Secrets Manager 中 |
| 使用 Terraform provisioners 進行設定 | 脆弱、無法重試的部署 | |
| 步驟之間沒有健康檢查 | 在設備未就緒時嘗試整合 | 在每個 Lambda 中實作帶有退避的輪詢 |
| 將備份與作業系統管理耦合 | 一方的變更會破壞另一方 | 分離 Terraform 模組和管道 |
| 沒有監控監控系統 | 靜默警示失敗 | 在 Lambda 錯誤指標上設定 CloudWatch 警示 |
摘要
在 AWS 上自動化 Dell PowerProtect 需要分層思考：
- Terraform 用於基礎設施——VPC、EC2、IAM、DNS（包括反向）、KMS、Secrets Manager
- Step Functions 用於協調——透過 Lambda 對設備進行順序、可重試的設定
- EventBridge + Lambda 用於監控——主動健康檢查與 ITSM 整合
- SSM 用於納管——在無需 SSH 存取的情況下大規模部署代理程式
此模式清晰地分離了關注點：Terraform 擁有狀態、Step Functions 擁有工作流程、Lambda 擁有設備特定邏輯。這種分離使每一層都能獨立測試、更新和偵錯。
對於目前在 AWS 上手動部署 Dell 備份的團隊而言，採用這種分層自動化方法可消除設定漂移、改善安全態勢，並在無需額外工程工作量的情況下擴展至各個區域。
Alpesh Kumbhare 是 Atos 業務的雲端架構師，專精於 AWS 基礎設施自動化和企業資料保護解決方案。請在 LinkedIn 上與他聯繫。
0 Comments
Log in to join the conversation.No comments yet. Be the first to share your thoughts.