Veeam Backup & Replication 基礎架構與元件

虛擬化已經是顯學 大部分企業已經都在生產環境部署
當然 有資料就有需要去保護 或是叫 備份
業界也有不少虛擬化資料保護解決方案
從免費的 到貴死人的 各個優缺點都有

其中 個人環境 現役的解決方案之一
Veeam 算其中之一要花很多錢, 但是相當好用, 相當省事的中大型環境解決方案
基本上只要一開始架構設計搞定 後續的運作維護上相當省工程師
這次就來講講 Veeam Backup & Replication 的基礎架構吧

Veeam Backup & Replication (簡稱 Veeam B&R)本身幾個比較基礎的元件

• Backup Server
  整套系統的大腦 舉凡排程 設定 監控 通知 全部透過這原件處理
  當然 CPU/RAM resource 耗用有點兇, 既然也是 VM, 視情況事後增加即可
• Backup & Replication Console
  管理員用來管理 Backup Server 的 Client
• Backup Proxy
  實際工作的角色 Backup Server 會把工作分配給 Proxy 去執行
  可以是需求增加更多的 Proxy 來支援所需的備份工作
• Backup Repository
  VM Image 實際存放的地點, Veeam B&R v9(?) 後來也增加了 Scale out Repository 功能, 可以讓多個 Backup Storage 合併成一個 Pool 使用.

各角色關係圖如下

而 Veeam B & R 貴桑桑的解決方案 當然有許多特異功能在

這邊就列舉我目前有在用的 而且感覺很好用的功能

• Application-aware, image-based backup
  基本上就是 VM Backup 完之後 Veeam Proxy 可以再去把裡面的資料抽出來做單獨 restore. 目前有支援最基本的 file level restore. exchange mail box, MS Active directory, Database MS SQL, MS Sharepoint.
  而且可以設定當VM backup 的時候 就立刻去把裡面資料做 index. 這樣子平常你的 backup 系統就會比較忙碌些
  或是當需要 restore 的時候, 再去 VM image 撈. 當然速度就慢一些 
• Built-in compression and de-duplication
  VM backup 的時候 再進 backup repository 之前 就順便做 De-dupl 跟 Compress
  可以有效減少 backup storage 使用量 甚至資料的傳輸量
• Backup IO Control
  這對我們環境也很好用 Veeam 會自動判斷目前被備份的環境 loading. 來決定是否要放慢 Backup 速度
• Image Incremental Block Backup
  就是只 Backup VM 自從上次 Backup 改變的部分, 而且是 Block level. 當然最後還是得在 Backup Repository 作合併的動作
  如此一來 可以在有限的 backup storage 保留多份 backup/recovery point
  而且每次 Backup job 只需要從 production 環境讀取一小部分 changed block.
  之後就完全在後端 Backup 環境上做運算. 對 Production 環境 Impact 非常小
• Quick rollback restore
  當 restore VM 的時候就非常實用 一樣只要 restore 自從那次 Backup 之後 被更動的 block. 然後可立刻開機
  當然 Veeam 還有另一種功能 SureBackup. 可以直接把 VM 在 Veeam 環境上開機
  不過我們的環境倒是沒使用到

下篇如果還是 Veeam 的話 就來講 Veeam VM backup chain 的概念

企業資訊平台 自動化處理概念

最近大家應該上Patch上得很開心
老實說 個人影響不大 因為平常就常被追殺 Patch 完成度 :P
而且已經丟上 MS SCCM, 手上有的系統 有辦法就是讓 SCCM 自動上 Patch

當然 系統維護不會是只有 Patching. 任何系統維護都可能會造成服務中斷
重點在於 如何設計 可以減少系統中斷之後 要復原所需的人力資源

這邊講的大都是 Infra 部分設計方向

1. 系統中任何元件, 任何 Server 都可以在任何時候重開
   而且當下會有另一個備用元件補上 避免服務中斷過久
   加上 重開的元件 一旦重開完成 必須要可以自動接上變成另一個備用元件才行
   如果有考慮到 HA, 就得考慮要用 VMware HA 即可 還是要搭配 MSCS, NLB 之類
   
   個人曾經看過有些比較"沒那麼好"的系統 DB 斷線之後 必須要人為去將服務啟動
   
2. 任何程序 都要考慮到在任何階段 中斷時的自動復原機制
   MQ是種方式, 被挑走的 task 最好有個 timeout 設定
   Transaction 別包太大包也是種方式 免得跑到一半要 rollback. 要花太多成本
   還有如果系統有多種運作方式 得考慮哪種方式可以允許跑到一半 剛好重開 又可以自動復原, 並不是速度快的方式才是優先選項, 個人有個 Veeam Backup 範例 等之後再詳細聊
   
3. Patching, 或是其他類似動作 最好可以自動並且分群組完成
   例如
   自動上Patch, 最好分兩到三群, 每群隔一個禮拜
   Patch 有問題至少可以控制範圍 沒法 rollback 也還有一半系統回應能力
   MS Patch 也有出過事低~~~ 個人血淚的教訓 T___T
   
4. 監控部分 最好每個端點都可以 End to End 監控到
   例如 Server, Service, Port, Web Service response, 最好是都有監控到
   避免像是有些只看ping, 結果service死掉都不知道
   或是只看 Port 通不通 結果 page都掛了 還在那邊亮綠燈
   這部分當然要靠 System Owner 跟監控部門合作才行
   不過塞郎有事後會 偷偷關一下 看看有沒有人會發現 並通知
   
5. 一堆小小 Schedule Task 是你的小幫手, 有啥事情 靠 script 即可
   從十幾年前 VB Script, Java Script, 後來的 Powershell, 最近還自在摸索 Python.
   Error Control + Reporting 都要搞好 重點是 失敗了也一定要通知到你
   每天早上到公司只要看 email 就知道他們有沒有乖乖工作
   
   例如
   自動清理 Snapshot, 不用再自己 或是找人定期去清理
   自動排序 Backup Task Schedule, 避免過度集中 造成 Backup system 壓力過大
   週期性的系統自動健康檢查報表 看看有哪邊該注意的 該處理還沒處理的
   自動掃VM的通用設定 並且更正 避免系統設定不一致的情形發生
   每個月的資料備份清理 準備轉 Tape 的動作
   
6. 還有一個很重要的
   手上一定有一堆大大小小的 schedule task, 而且包準還會越寫越多
   要想辦法集中管理 就算沒法集中管理 文件一定要記錄清楚
   這對之後的 Troubleshooting 很重要
   有時候就是會遇到找不到問題在哪的狀況 被遺忘的 schedule task 往往是原因之一
   
   塞郎我 曾經有事沒事就是搞了一堆小 schedule task.
   然後就忘了他們的存在 十年後一次偶然的機會還發現他們還在默默的工作...
   趕快替他們上香 請下來....
   

其實還有一堆有的沒的 一下子想不了那麼多

那麼 祝大家 patching 愉快.. :p

vSphere 自動清理 snapshot

管 VM infra 的小管理員
基本上就是都會收到 User VM snapshot 需求
不過大都 User 只會要求要建 snapshot. 沒人會去管 snapshot 要定期清理
身為 VM Infra 小小管理員 就得自己想辦法記得去清理

不過就算是小小 VM Infra Admin 不需要到大老闆的日理萬機
總會還是會一堆雜事在身邊吧
這時就可以弄個簡單的 snapshot 自動清理 script.
自動清理超過一段時間的 snapshot.

script 很簡單 就兩行 自動清理超過30天的 snapshot

$Days = 30
Get-VM | Get-Snapshot | Where {$_.Created -lt (Get-Date).AddDays($Days)} | Remove-Snapshot

剩下的 把它變成 schedule task 吧
如果想要搞個更完整一點的 把 try catch 放進去吧
順便在每次跑完寄個 email 到你的 mail box 通知執行狀況

當然 在你開始這樣做之前 事先得先教育 User snapshot 的用法
一般來說 snapshot 只是供短期, ad-hot 保留系統狀態, 快速rollback用
如果有需要做資料長期保存 還是建議 user 使用 VM backup 的方式

that's all

企業資料保護類型 方式 以及 使用情境

資料保護 這邊講的就是 Backup
通常就是看你得資料有多重要 資料不見的時候會造成多少損失
一般來說會照下面兩點來判斷

• 允許多少資料救不回來 (Recovery Point Objective / RPO)
• 救得回來的資料 最長多久時間一定要回來 (Recovery Time Objective / RTO)

之後就是再根據你系統類型 來判斷所需要的資料保護方式了
這邊就只講資料中心內部可能的方式
同一套系統的資料保護方式 有時候會並存 並不會相互衝突

一般常見類型如下

備份種類	一般運作方式	最短的 RPO 建議	通常使用情境
OS Level Backup	OS level file copy	日	實體機
Database Backup	Database backup	15 mins	資料庫備份
VM Level Backup	VM Image backup	日	虛擬機
Storage Level Backup	Storage Volume Snapshot backup	日 (可更短 看Storage/備份軟體)	備份軟體可直接控制Storage時

在組合情境下 可能搭配的方式

• 當你要保護的系統是 虛擬機 + 資料庫 時 同時使用下列兩種備份機制
  • VM Level Backup: 提供 OS Level 復原機制
  • Database Backup: 提供最短15分鐘的 RPO
• 當你要保護的系統是 實體機 + 後端接 Storage + 資料庫 (下列選其一)
  • Database Backup: 提供最短15分鐘的 RPO
  • Storage Level Backup: 如果備份軟體有支援直call storage的話
  • OS Level Backup: 實體機環境 通常不做此選項 直接重裝OS囉
• 當你要保護的系統是 虛擬機 + 後端透過 RDM 接 Storage + 資料庫
  • Database Backup: 提供最短15分鐘的 RPO
  • Storage Level Backup: 如果備份軟體有支援直call storage的話
    用來備份虛擬機OS用
  • VM Level Backup: 不可能做了 因為幾乎VM備份軟體都是透過Snapshot做備份
    接了RDM, 是不可能做Snapshot的 要用上面的 Storage Level Backup來替代
• 當你要保護的系統是 虛擬機 內含 File Server, 可是又想要有跟 Database 一樣的15mins RPO (下列選其一)
  • OS Level Backup: 看看備份軟體的極限囉 可以做到15mins RPO的可能性最高
  • Storage Level Backup: VM Storage Snapshot. 應該難度很高 時間越短 對 Storage 造成的壓力越大
  • VM Level Backup: 難度更高 試想一個 VM 每十五分鐘 create snapshot, remove snapshot. ESXi 與 Storage 的壓力應該超級大

基本上 所有資料保護方針都是圍繞著 RTO, RPO來看
你的資料越重要 遺失的時候造成的損失越大 就有必要利用更好(通常也是更貴)的方式來保護
到最後都是把多個解決方案與需要花費的成本一併列出 看出錢的老闆決定囉

當然還有上述沒列出的許多變形玩法
像是前端接 low cost storage, 後面再往遠端送 remote site/cloud
或是配上DR災難復原 直接傳送資料到遠端
這部分就是看各公司需求了