Private/Public Cloud 對企業帶來的影響觀察

這篇文章不談技術
單就聊聊個人這幾年所觀察 新的技術或是概念 為企業環境所帶來的改變
因為個人畢竟還是接觸有限 所以大概也只就自己所知範圍來說明
難免有井底之蛙的可能 還請海涵
這篇文章也是想給自己五年後再來個回顧 看看業界如何變化了

自2000年時 第一次接觸 VMware 虛擬化
當時還是非常難使用 速度慢到無法提供企業生產環境使用
還記得那時自己所下的評語 "根本不能使用的爛東西"
誰知道短短不到十年 這不能使用的爛東西 已經變成業界標準
又在短短幾年 衍生的 Private/Public Cloud 開始改變現有資訊人員生態

大約十年前 一個部門要部署新系統
需經歷 規格評估 採購 部署 設定幾項流程
其中大概得牽涉到使用者 專案部門 資訊部門 採購部門
整套時間走完 可能得長達數個月

後來 2010之前 虛擬化成為大家的標準之後
新系統部署慢慢變成 規格制定 部署 設定.. 大概就是少了採購部門
當然 如果是大規模系統要部署 難免還是要採購新設備
不過總歸時間縮短成一至兩個月

後來在 AWS EC2 更多人接觸 也變成業界常用之後
部署 設定 直接上線...
有些時候使用者甚至跳過資訊部門 直接在 EC2 部署系統
先用再說 事後付款跟老闆解釋得通即可
也不用等資訊部門的人慢慢幫你開VM, 設定 DN, NLB, FW...

但是 AWS EC2 雖然又好又快 畢竟有些東西不適合放到公司外部
或是目前 AWS 提供的自由度沒那麼高
又或是 AWS 旗下的服務 在策略運用上 成本相對較高
這部分就還是乖乖留在地上

以往(短短三年 或五年前) 虛擬化為標準的時期
一套系統部署 花個一個月 溝通設定 部署 設定 VM, DN, NLB, FW..
使用者就是等 等 等 資訊部完成這堆工作
其實一個月還算進度很快了
不過因為 AWS 出現的關係
使用者在 AWS 發現前述工作 都不過是自己上去動動指頭就可以在數分鐘完成
這時候資訊部門的壓力就大了
為啥人家可以在這麼短時間之內完成我想完成的事情 資訊部門就做不到

之後就冒出了 另一朵雲 Private Cloud

當然 這朵雲的出現也是為了可以提供類似 AWS 的使用體驗
又可以把資料留在自家 或是提供比 AWS 更為特殊的企業專屬服務

不過一個企業小小資訊部門
再怎麼樣都比不上 AWS 有一大群研發部門
就是專門做 Public Cloud 供使用者使用
這時候就是看各資訊人員功力了
如何在資訊部門 事事都被使用者拿去跟 AWS 比較的狀況下
讓企業內部使用者沒有80分滿意 也有60分及格

況且
現在 AWS 上提供服務
衍生出來的 DevOps, Agile, Serverless 玩法
資訊部門的同仁大概就被這些名詞 以及需求追殺到沒日沒夜了
當然 這些東西也都是因應現在商業需求快速改變而產生的需求
所有東西都要快 還要更快
搶市場要快 系統部署要快 開發要快 改版也要快 因應使用者的需求變化 也要快
資訊部門也得要跟上腳步才行
跟不上的話 人家當然就往 AWS 跑囉
Private Cloud 大部分的目的就是為了解決上述需求

另一個帶來的影響
大概就是技術解決了一部分需求提供緩慢的問題
接下來就是要解決流程造成的緩慢了
之前要牽涉到很多人的動作 也就大幅簡化 甚至很多原本需要參與的人都沒了
以前資訊部門還要有專屬窗口 跟使用者溝通
現在不用了 使用者自己 UI 搞定就好
之前還得養一群人 就為了開 VM, 設定AP, FW, DN, NLB...
現在不用了 讓使用者自己上 UI 設定
再加上自動化 原本一堆手動花費幾個小時 一個人就卡在那邊的事情
全部就包含在 Private Cloud 後端自動化機制裡
這個人就可以去做其他更進階 更有價值的事情
人少了 職位跟角色也少了 可是速度更快了 規模更大了

當然 原本工作簡化 或是被自動化取代的人
也得願意或是跟得上去學更深入的技術
這時候就有一批跟不上的人會被甩到後方
要嘛就是找一間技術比較不需要跟太快的公司待著
要嘛就是轉換跑道

現在業界變化那麼快的環境 資訊業人員包含我都會有種感想
每次新技術出來 學到手 大概頂多可以靠它吃飯吃三年吧
之後大概要嘛被另一種新的概念或繼續取代
或是內化成必備技術 然後又有基於此技術發展的新的東西冒出來
個人一直都以電話接線生被電話交換機取代的例子警惕自己
當然 比較現代的就是高速公路收費員被ETC所取代
誰知道十年後再來看這篇文章 那時資訊部門 infra 管理人員被啥東西取代
就好像現在我們看 AI 還是覺得很笨 很難使用
誰知道又是十幾年前 我對虛擬化的評語 ”又慢又難用“ 一樣

Veeam VM Backup Mode 簡介

Veeam 主要用途就是 VM backup
以往 backup job 大概都會選擇 Full, Incremental/Difference 兩種類型
Database 的話 會加上 Transaction log 的方式

而 Veeam 因為是 VM backup, 大概就只有 Full, Incremental 兩種可選
但是 Veeam 又把這兩種搭配 changed block tracking 的技術
只 backup 上次之後的 changed block, 可減少很多 VM infra loading
而 Veeam 可設定的 backup 存放方式大約分成下列三類

• Forever Forward Incremental Backup
• Forward Incremental Backup
• Reverse Incremental Backup

就借用原廠的圖來一個一個說明吧

Forever Forward Incremental Backup

如下圖 Daily Backup 的方式
只會在 backup job 第一次跑一次 Full backup, 之後全部都是 incremental backup

每天一個 backup/restore point

但是只有最後一天是 Full backup/data
假設有新的 daily incremental 進來
最舊的 daily incremental 就會跟 full backup 合併

Forward Incremental Backup

如下圖 Daily backup, 再配上特定幾天 例如每個星期四"合成"一份 full backup

這邊不講作 full backup, 原因是 Veeam 並不是真的在星期四會做一次完整的 full VM backup. 而是在星期四做完 incremental backup 之後 會利用之前幾天的 full + incremental. 合成 (Veeam 稱作 synthetic) 一份完整的 full backup 

在這設定下 一樣只會在第一次 VM backup 作 full, 之後一樣全部都是 incremental

過期的 daily incremental 一樣是合併到 full backup

但是在這種設定下 過期的 increment / full data 並不會每天去合併 刪除
因為已經有另一份 full backup 了
Veeam 會等這一份 full backup 之前所有的 backup point 都過期了 一起砍

Reverse Incremental Backup

顧名思義 反過來 最新的一份都是 Full data, 比較早的時間點都是 increnmental

每次每天新的 daily incremental 進來, Veeam 就比對 changed block 並把他趕出去變成昨天 incremental data

過期的一份 incremental data 直接就砍了

上述三種方式 要選擇哪種其實是見仁見智 看使用環境
Forward 或是 Reverse 其實 Veeam 在 backup repository 要做的事情都一樣
尤其是 backup job 開始有 retention 的時候 差異真的不大
只是full data 放在前面或是後面的差別而已

唯一比較有差異的方式是 Forward Increment Backup. 因為會多產生一天的 full backup
所以 backup repository 會需要多一點空間 存放多的 backup data

當然 因為 Veeam 除了第一次跑 backup 是 full, 每次 VM backup 都是 incremental.
之後 Veeam 在後端 backup repository 搞東搞西
如果有需要 Veeam 還有提供另一種設定就是 強制作 VM full backup
例如每個星期六晚上 作一次完整的 VM full backup. 而不是靠 Veeam 在後端組合 block
理所當然 VM storage loading 會比較重 就看需求囉