Veeam 設計 維護 實務歷程

好幾個月沒寫 用這篇把 Veeam 最後一段補起來
這篇主要描述當初在Datacenter導入 Veeam B & R 設計, 踢到鐵板, 以及改善過程
主要分三個階段吧

一開始：槍在手 跟我走

最早Veeam 也只是在Lab做完POC.
也沒想過(機會)要跟遠在半個地球外的原廠 Consultant 討論架構
就直接腦子一熱 架構圖畫了 自認為可以衝了 就實裝在手上最大的 Datacenter了

當時很多覺得還不錯的新技術 無論是Veeam的 或是Windows File 想丟就全丟上去了

1. Veeam Proxy 直接去抓 VM Storage 的 VMDK. 完全不用透過 ESXi, 減少 ESXi 負擔
2. Veeam backup incremental policy, 只有第一次 VM backup 需要 Full backup, 之後永遠都是 incremental backup. 由 Veeam 在後端合成 full backup set. 可以減少 VM storage 負擔
3. 後端 Backup Repository 使用實體機 Windows Server + Storage (4T 7.2K x 84顆).
4. 利用 Windows File System level de-dupl + compress, 期望減少後端實際空間消耗

想當然爾  踩到超級大地雷  Lab 環境終究是 Lab.

在幾千個 VM 運作環境下 任何小問題都會被放大

1. 第一個踩到的地雷, 實體 Windows File Server 聯外 backup network 1G x 4 (LACP)
   要伺候十個 Veeam Proxy (1G x 1) 同時丟東西進來 炸了
2. 第二個爆炸的地雷 Windows de-duple 需要花兩到三天才會完成一輪 de-dupl/compress 程序, 結果配上 Veeam incremental backup policy. De-dupl/compress 還沒跑完 就被 Veeam 清掉, 又產生一份新的 full backup set. 永遠沒有拿到 de-dupl/compress的好處, 反而 de-dupl 產生的 library 越長越大

最後Daily VM backup 吃不下一百個...超過的話 Daily backup 就變成bi-day backup.

可是我有上千個 VM 耶

被地雷炸過之後：想辦法找到原廠聊聊天

一頭熱之後 被炸得七暈八素 當然是跟原本說明的人抱怨(幹礁)

還好老闆跟廠商關係好 想辦法找到原廠來幫忙看架構是否有得調整

結果就變成下面了

改變的地方

1. 放棄 Windows File System De-dupl/Compress, 列為拒絕往來戶
2. 改在 Veeam Proxy 讀取 Data, 送到 storage 之前
   靠 Veeam 自己的 in-line de-dupl/compress 把 data 縮小一圈才送出去
   免得 File server 變成 Fire server.
3. 消耗 Veeam Proxy (ESXi) 上面的 CPU, 不過相對於其他 resource, VM farm CPU 平均使用率算低的

修成這架構之後 總算可以吃下數百個 VM 的 daily backup

微調 微調 再微調：Password改改改, Patch上上上

後來因為策略需求 每隔一段時間都要上 Windows Patch

每隔一段時間也要改 service account password

就又改了一些地方

1. Veeam Proxy 不再直接進VM storage mount disk. 改成透過 ESXi 去讀取 VMDK
   因為之前設計 Veeam Proxy 一旦 mount VMDK, 若此時 Proxy 因為上Patch重開機, Backup job會掛掉就算了, VMDK 就會一直掛在這 Veeam Proxy上不會自己解除
   別的Proxy也不能繼續把 Backup 完成. 需要人為去把 mount 清掉
   
   要嘛, 要上Patch之前把所有Backup都停掉.  要嘛 每次手動清 mount disk
   個人雖然沒有一分鐘幾十萬上下, 我也是會發懶的.
   想來想去就犧牲掉一部分的 ESXi resource. 讓 Veeam Proxy去 ESXi抓資料囉
   其中要是 Proxy 重開機,  Job retry 會有另一個 Proxy 去接手完成
   
2. Service account 整併
   因為初期每次改Password都要去各地方改, 後來就盡量整併 可以少打Password的地方就少打  最後就是用 script + schedule job

結論：最後剩下的

1. Veeam forever incremental policy
2. File server 就單純作 File server
3. Proxy 消耗 ESXi CPU resource 作 data de-dupl/compress
4. 考慮減少避免Patch負擔 Veeam 直接讀 VM Storage 的方式捨棄, 確認隨時都可以上Patch, 隨時任何一個 Veeam component/server 都可以重開機

疑? 我好像是因為太愛玩才會在一開始被炸翻的吼

VMWare vSphere 為啥麼建議使用 vDS

這篇算是陳年議題  原本想說就捨棄不用..
不過最近聽到有公司還堅持在 vSphere 使用 vSS... 有 Enterprise license 喔...
就......拿出來消化一下....吧

在 VMware vSphere 環境下
網路設定大概可分兩類 Virtual Standard Switch (vSS) 與 Virtual Distributed Switch (vDS)
差別在哪網路上已經一堆教學文章 就不贅述
這邊會針對這兩種方式說明後續維護上的差異


一般來說 vSS 大概就是 一個個獨立的 Virtual Switch 在每個 ESXi 上
每個 ESXi 上的 vSS 都得個別獨立管理
今天一個 VM 在 ESXi A 上面跑 VLAN 1002
而 ESXi B, 上面的 vSS 也要有設定 VLAN 1002 才能完成 vMotion

可是哪天 ESXi 越來越多 VLAN 越來越多的時候

MIS 應該會管道抓狂才對 而且失誤機率又高 自然造成問題的機率也高

如果換成 vDS 呢?

基本上就是 vSphere vCenter Server 代管了

想像下圖上半部有一個橫跨 ESXi 的 Virtual Switch.

所有在這個 Virtual Switch 上面開了四個 VLAN.. 

vSphere vCenter 會把這四個 VLAN 帶到旗下所有 ESXi.. (黃色箭頭)

這樣子再多的 ESXi 都只要針對 vDS 做管理即可

MIS 會省事很多

況且

如果要走 NSX 的話 大概也只能運作在 vDS 的環境下了

這又是另一段故事了.

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 會比較重 就看需求囉

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災難復原 直接傳送資料到遠端
這部分就是看各公司需求了

vRealize Automation 管理員與客戶端 Blueprint 管理概念

回來扯扯 vRealize Automation 吧
vRA 其中一項功能 Blueprint 算是 vRA 的主要功能
用來幹嘛的 大抵上來說就是
你的整套系統藍圖 包含其中的任何設定 都可以建立在 Blueprint 裡面
然而這已經太多文章講過這些 這邊就不來廢話這些了

一般來說 vRA 導入之後
vRA Admin 都會對 Blueprint 該如何使用
以及內部的 software component, XaaS 該如何寫都會有一定的熟悉度
但是最終還是要讓你的 User 使用這些 Blueprint, 甚至是開始做自己的 Blueprint

然而 一般來說 User 一開始剛開始接觸 vRA 應該不會了解 Blueprint 該如何建立
當然 vRA Admin 可以教 User 怎麼使用 Blueprint
不過不管再怎麼教 當 User 第一手拿到自己的新 Tenant 的時候
Blueprint 一定是一片空白
如果這時候要讓 User 自己設計自己的第一個 Blueprint
而且要等第一個 User 的 Blueprint 設定好之後 User 才能開始開第一個 VM
User 一開始就遇到如此高的門檻絕對會幹在心裡  就算原本再有熱情都會被澆熄

另外就是 公司大都會有自己的 server policy.
例如每個 server 都要安裝防毒軟體 資產管理軟體 OOXX 等等
複雜一點的還會有 Software 管理軟體. 強制 Join AD Domain, DNS..
如果開放給 User 自行設計管理 Blueprint 的話
就算 User 想乖乖 follow policy 可是當遇到這一堆有的沒的公司 Policy 設定 往往也會打退堂鼓
又何況當 User 一多, Tenant 一多
哪天 Policy 更動 vRA Admin 大概也就沒那種美國時間去幫每個 User 一個個更新 Blueprint
久而久之 User 反應不佳, vRA Admin 累得跟狗一樣


後來思考出另一種方式 就來把權責切開吧 如下圖

• vRA Admin 提供一個基本的 Blueprint
  包含基礎的 VM Template, Network, 以期其他零零種種的基本設定
• User 可以自己製作自己的 Blueprint
  但是 VM 相關部分 一律用 vRA Admin 提供的 Blueprint 包起來
  後續相關的 User system 安裝程序 全部由 User 處理

這樣的好處是 User 拿到新的 Tenant 時 就立刻有可使用的基本 Blueprint
User 立刻就可以享受到 Self-Service 好處 一個按鈕 立刻就有自己的 VM 可用

而後一旦 Base blueprint 有需要更新
一律由 vRA Admin 處理 並發散到所有 User 端
或是把樣板提供給 User 自行替換

當然 後續如果 User 刻意不用 vRA Admin 提供的 Blueprint 樣板
則是靠安全稽核來做事後控管
或者是跟 User 講明 不用 vRA Admin 提供的 Base Blueprint 當底 則享受不到這些好處
一般來說 User 聽到可以省事 也都會很樂意照此作法處理


過一段時間之後 當 User 比較知道 Blueprint 的設計方式
User 就可以開始自己變出更多玩法 這時候開始就是讓 User 自己發揮了
大部分 User 會玩得比 vRA Admin 還透徹
例如就直接自己變出下面的 3 tiers 架構來玩
Web/AP tier 可以根據需求 scale out/in

話說 圖雖然都是自己畫的 但是小 icon 都是網路抓的
會不會被"吉"啊...XD

Compellent Auto-Tiering 設計注意事項

這次要廢話的主題回到 Compellent 吧
前面介紹了 Compellent 與其他廠牌 Storage 最大不同
在於他是業界最早導入 Auto-Tiering 機制的 Storage.
而且 Tiering block 細度可以到 4MB, 2MB, 512KB
目前似乎還沒有其他家廠商有做到這個
(不過後來好像也慢慢不是很重要了, 畢竟現在 Storage 廠商也被打得亂七八糟就是了)

這邊就來廢話一下 當要規劃 Compellent Storage with Auto-Tiering 的時候的注意事項

如果是以前傳統 Storage, 很簡單 User 要多少空間 要多少 IOPS
就換算成要多少 Disk, 哪種形態的 Disk, 直接買齊給他就好 (當然 User 出$$的話)
不過當你要把 User 系統放在 Enable Auto-Tiering 的 Compellent 上面的話呢.
建議就要再細部一點 例如
1. 預計 User 每天寫入資料量
2. 預計 User 資料熱門程度
3. 短 中 長期 資料熱門程度以及趨勢分析
4. 中 長期各型態 Disk 空間利用 及 負荷狀況
5. 短期 長期 不同資料型態的升降級

第一項 如果是現有系統的話就很好估算

跑個一段時間的 Dell DPACK 就可以估算到每天的資料寫入量
加個 buffer 50% ~ 200% 不等 (看老闆要給你多少$$) 就可以當成你的 Tier 1 空間

但如果是新系統的話就會比較麻煩
問 User 大概也都會估很鬆 (畫大餅) 出錢的老闆也都知道 這些大餅都是畫的
管 Storage 的 大概就是想辦法取中間值
一般來說 Tier 1 大概是 User 預估資料成長量的 10% ~ 20% 不等

第二項 關於資料的熱門程度

如果你的 Compellent Auto-Tiering 打算分成三層式架構
這項估出來的結果就是 Tier 2 所需的空間及 Disk 型態
不過比較麻煩的是 這部分資料就算是 Dell DPACK 都跑不出來
因為 DPACK 不會知道哪些資料是熱門資料
跟 User 談的話 一般絕對都會想把他們的資料全部放在 Tier 2.
同樣的 Storage Admin 要是膽敢拿 User 提的需求直接去跟老闆要錢 不被殺頭才怪
當然 如果那部分都是 User 自己出錢 當然 Happy Happy 囉

所以無論新舊系統 大概估算都是整體資料量的 20~40%
要是跟老闆提案的時候 當然一定會被要求 先從 20% 開始吧 吧 吧 吧 (回音~~~~)

不過依照經驗 老闆出過一次$$之後 幾乎不可能要求老闆在針對同一件事情花第二次$$
所以 能爭取多少就多少吧
不然哪天就是 Tier 2 空間使用爆炸 User 抱怨效能有些問題
Storage Admin 得想辦法跟老闆多要一點 co co 解決 User 效能問題

第三項 短 中 長期 資料熱門程度與趨勢分析

這又更虛無飄渺了~~
如果是 User 系統已經是一套很穩定的生產系統
這樣的話每天寫入資料量 熱門資料量 應該就是很穩定了

但是很不幸的 在現實面就算是很穩定運作的系統
也可能因為因為一次事件 辦個活動 User Import 資料而改變平衡
例如說 某個 User 明明每天正常寫入量就是 100G, 可是因為 User 一次系統改版
Database 要來改個 Schema, 當天給你來個寫入 2T
更有可能的是 User 要做這件事情也不會事先跟 Storage Admin "告知"
等到 User 發現效能下降的時候才緊急”找“你求救 (幹樵)
你除了發現 Tier 1 空間爆炸 開始把資料直接寫入 Tier 2.
更慘的是 Tier 3 都要開始來幫忙承接資料
你大概也只能頭殼抱著讓他燒吧

該怎麼避免這狀況發生呢
平常多多跟 User "教育" 他們所在的 Storage 需要多一點照顧
平常都處於某種平衡 如果有需要做任何事情 請"記得"找 Storage Admin 先問過
假設 有 User 問說 既然 Compellent 做事情那麼多限制 那為啥還用它咧...
因為很便宜 很便宜 非常便宜啊~~~~~  (很重要 要說三次.)
Auto Tiering 可以讓冷門熱門資料分布在該在的 Disk 上
不用全部採購高規格 SAS15K 甚至 SSD. 就可以提供一樣該有的效能
照顧得好 可以用低很多的成本做到傳統 Storage 做到的事情與效能

另外就是 Storage Admin 可以定期出各個 Tier 空間 負荷趨勢
這樣可以先讓老闆有個心理準備 是否該增加投資了
就算沒有決定增加投資 也可有個準備 是否該 review 該降到全 Tier 3的系統
或是乾脆該下線的系統

第四項 中 長期各型態 Disk 空間利用 及 負荷狀況

一般來說 當 Compellent 規劃出三層架構 大概都會是 WISSD(SLC), SAS 15K, SAS 7K
不過近來因為 RISSD(TLC) 價格越降越多 單位成本已經跟 SAS15K 相同
也開始有以 WISSD(SLC), RISSD (TLC), SAS 7K 為規劃方式
也就是像下圖的規劃方式
Tier 1 Disk 為 SLC SSD, 專門承接寫入的資料
Tier 2 Disk 為 TLC SSD, 專門負擔熱門資料的讀取 以及 SLC 降下來的資料
Tier 3 Disk 為 SAS 7K, 就是空間大 單位成本低 用來負擔比較少需要讀取的資料

上述圖表 依照"完美比例" 各Tier 3%, 26%, 71% 配置
我們只要買全部空間 3%的 SLC SSD, 跟 26%的 TLC SSD 就可提供該有的 Service Level
老闆看到他的 coco 被這樣省著花用不知道會不會來摸摸頭..

觀察重點 最簡單的部分就是各層空間 尤其是 Tier 1 SLC, Tier 2 TLC 最好不要塞好塞滿
因為 SLC 滿了 會開始有 TLC 開始承接原本 SLC 該支援的資料
更慘的是 TLC 也滿了 連 7K disk 都得一起進來支援

這時候就是開始 頭殼抱著燒拉~~~~

最好的方式 就是長期觀察各層 尤其是 Tier 1, 2 的資料成長狀況

將趨勢抓下來 好作為跟老闆提案要求投資的依據

不然也可以開始準備趕人 給 User 各系統也來個劃分階級制度

跟 User 協調 比較不需要高效能空間的系統 可以慢慢限制在只能用下層空間

另外就是傳統 Storage 比較不會去注意到的部分
Compellent 除了各Tier 空間使用率被當成一種資源
Disk IO 也是需要特別去注意

依據之前跟 Compellent Consultant 口頭敘述 數字可能有些誤差 完全憑記憶
各種不同型態Disk 建議可乘載的 IOPS 最大值如下
SLC Read 2000, Write 2000
MLC Read 2000, Write 1000
TLC Read 2000, Write 200
SAS15K Read 200, Write 200
SAS7K Read 80, Write 80

當然 這些 Disk 一定可以乘載更高的數字 但是 Consultant 說明
這數字是在開始出現比較嚴重的 latency 之前的建議上限
當Disk 開始要求提供超過建議上限的 IOPS 時
Disk 就會開始出現較高的 Latency 了

而有了這資料 就是要進去 Compellent 看每個 Disk IO狀況是否有超過上述建議值
當然不是要你一顆一顆去看 通常同一個 Group, 同一個 Type Disk Loading 都會很接近
每個 Disk Group 每一種 Type 挑幾顆看就好
如果超過上述建議 IOPS, 就算該 Tier 還沒滿 也是有可能的
就開始上面的做法吧 請老闆投資 或是開始敢人了

第五項 短期 長期 不同資料型態的升降級

會有這狀況 通常就是上面兩種資源 要馬 Tier 1/2 空間快滿了 要嘛 Disk IOPS超過建議值了
此時老闆要是覺得增加投資來維持原來的 Service Level 不是很有效益
這時候通常就是 Storage Admin 要開始跟 User 談 系統要分階級拉
不大重要的系統 就給我往貧民區 Tier 3 Disk 趕
比較重要的賺錢系統 繼續住在 Tier 1,2,3 VIP套房
這些動作 User 完全不需要針對系統做任何更動 完全由 Storage Admin來處理即可
不過問題通常不是技術面上的問題
你說我的系統要住貧民區 我就答應讓你搬啊

另外一種狀況
有些系統可能一季也才跑那一次 平常閒閒沒事幹 都在睡覺
可是當他要跑的時候 必須要有非常高的效能
這時候 User 跟 Storage Admin 就可以協調 Tiering 的更動
當平常時間 就降到 Tier 3 讓他好好睡覺
當需要開跑前幾天 Storage Admin 就將 Data 先昇到 Tier 1, 2
之後改成 Tier 1,2,3 全Tier
這樣的話一樣可以達成省成本 又符合系統需求的經濟效益

結論

廢話那麼多 總結就是
因為 Compellent Auto-Tiering 的關係
投資 Storage 成本效益上 會比一般傳統 Storage 高上許多
老闆永遠希望 可以用最少成本 達到一樣的目的
不過也因為這特性 要多花一點時間照顧 也最好及早知道 Auto-Tiering 限制或是極限所在

所以... 老闆 我可以把 SAS15K 都換成 SSD TLC 嗎... :p
我想讓 User 通通升級總統套房拉~~~~

MS Failover Cluster 常見設計錯誤

接續上篇 再來就是一般常看到
大家在安裝 MS Failover Cluster 以及安裝於上面的AP 常發生的錯誤

以下列為例

Cluster 也會有一個 Manage Point
Cluster Admin可以透過 Manage Point 管理整個Cluster
Cluster Manage Point 同時間也只會在一個 Server Node 上面

左圖為例 Cluster Manage Point 與 Service Access Point 同時 Active 在 Server Node 1










Cluster Admin 透過 Cluster Manage Point 來管理整座 Cluster
Service User 透過 Service Access Point 來取用服務



但是 假設下列狀況

Service User 不知怎麼得知 改由 Cluster Manage Point access Service.

此時狀況下 Service User 一樣可以取得 Service 的回應 因為 Cluster Manage Point 與 Service Access Point 都在 Service Node 1














但是假設有天 Cluster Manage Point 飄走了 跑到了 Server Node 2.
而 Service 還是停留在 Node 1.

這時候狀況下 Service 還是活著喔
但是 User 卻無論如何都無法取用到 Service
因為 Cluster Manage Point 已經在 Node 2.
而且此時 Node 2 Service 是 Standby 狀況 自然就沒回應
















另外還有一種狀況如下

一個 Cluster 上面同時有兩種 Service
Service 1, Service 2 各自有各自的 AP
(Cluster Manage Point 省略不畫)

一般來說鍋話
Service 1 AP 會用到 Storage 1
Service 2 AP 會用到 Storage 2
各自分開










可是有哪位大哥 在安裝 Service 2 AP 的時候 把資料放在 Storage 1 上面了
當下當然不會有問題 可是哪天呢

Service 2 流浪到另一個Server Node
那就.... Service 2 無法抓到 Storage 1
因為 Storage 1 屬於 Service 1, 目前 Active 在 Node 1.

而 Service 2 正在 Node 2
想抓也抓不到
此時 Service 2 就掛掉了









另外還有一個常見到的設定錯誤 或者一般人比較不會去注意的地方
一般來說各種 Cluster Resource 之間或有相依性
如下圖 Service 1 必須要配置在 Access Point 以及 Storage 上面
有些比較複雜的系統 可能會有多個 Service, 期間也可能有相依性
像下圖 Service 2 就必須要在 Service 1 起來之後 才能夠跑起來

但是大部份時候 這些相依性必須由 Cluster Admin 自行設定

而 Cluster Admin 一般又是由 AP/Service Admin 兼任

這時要是 Service Admin 沒有顧慮到 要設定相依性的話
往往有時候 Cluster Resource 啟動順序沒有照自己所規劃
例如上圖範例 Service 2 比 Service 1 還早啟動
或是 Service 1, 2 沒有等 Storage 啟動完成 就急著啟動
此時就是... 掛掉拉
所以設定 Cluster Resource 相依性 可以強迫限制 Resource 的啟動順序
避免順序錯亂的問題發生



上述幾種狀況 大概是這幾年下來 看過 發生過的案例
這些錯誤的設計 或是設定 往往當下不會發生問題 也不會被發現有問題
大概也是因為大部分系統上線之後 大家都不敢去動 也不敢先做 Drill Failover 測試
往往等到許久 幾個月 甚至三年五年後 真正要 Failover 發生的時候才發現有問題
此時有可能會有幾種結局

知道怎麼改設定的 例如相依性 改改就好
Service Access Point 指錯地方的 去翻翻 AP connection string 看有沒有機會修正回來
Service 檔案裝錯地方的 這大概就要人命了 這時候大家大概不想 也不敢去動它了
正是所謂 假 HA...

下篇原本想講 MS Cluster HA 投票機制
不過...先換換別的口味好了

MS Failover Cluster 基本概念

突然想到要插入這篇 MS Failover Cluster 因為好像(最近)會用到
這篇先簡單講概念 下篇再講常看到的設計錯誤

MS Failover Cluster 是常見的AP HA 架構之一
對於必須要維持資料一致性的系統來說 這種架構已經存在十幾年 算相當成熟

一般來說架構如下

一個對最上層 User 提供服務的 AP
有兩台Server Node 1, Node 2 做備援

外部有一個 Access Point 供外部 User 存取
Server Node 1, Node 2 並不直接讓 User 存取
一律經過 Access Point

平常 Access Point host 在 Node 1.
AP 也跑在 Node 1, Storage 由 Node 1 的 AP來存取

當哪天 Server Node 1 掛掉的時候

AP 會立刻在 Server Node 2 跑起來
Access Point 也會立刻由 Node 2 Hosting
Storage 也改由 Server Node 2 AP 來存取





如此一來 可以維持系統的可用度
也可以確保資料的一致性 同一時間 一份資料只會有一台Server 讀寫









說穿了 Server Node 1, Node 2 都有 AP這支程式

在 Node 1 Hosting AP 的狀況下
AP 只有跑在 Node 1, Storage 也只能由 Node 1 Access

Node 2 AP 是關機狀態 Node 2 也無法存取 Storage

而當 AP 切換到 Node 2 的時候
AP 只有跑在 Node 2, Storage 也只能由 Node 2 Access

Node 1 AP 反過來是關機狀態 也無法存取 Storage
















當然 有些時候會希望平常兩台 Server node都可以提供服務 不要處於閒置狀態
如此就會有下列的配置方式

Service 1, Service 2 各自跑在這兩台 Server Node

Service 1 平常跑在 Node 1
Service 2 平常跑在 Node 2

比照上面的架構
Service 1 與 Service 2 有各自的 AP, Storage. 彼此互相不干擾

當哪天 Node 1 掛點的時候
Service 1, Service 2 同時都會跑在 Node 2
此時 Node 2 的 AP全開 Storage 也正好可以同時Access

此時就要很小心 Node 2 要有足夠的能力可以同時撐起 Service 1, 2 不然就是兩個 Services 一起掛點
















當然 除了 MS Failover Cluster 之外 許多有需要存放資料的 HA 架構大概都差不多
後來也有些變形應用 或是設計出現
不過大都維持 同時間只能有一個人(AP) 對同一份資料做讀寫
當然如果有多份 Copy 做 HA, 那也只能提供"讀" 的功能
如果有需要對資料做更動 還是只能回到那唯一一個可以寫入的點去做寫入
如此方可維持資料的一致性

下篇就來聊聊 MS Failover Cluster 常遇到的錯誤設計吧

Compellent Data Progression 原理

傳統 Storage 大都是把所有資料放在同一種型態的硬碟
如 SSD, 15K RPM, or 7K RPM
因為這幾種硬碟的單位成本不同 當然效能越高 單位價格就越貴
有時候會為了作效能與成本的有效運用 就會根據不同的資料型態 配置不同的硬碟
例如 熱門的交易資料 就在放置在 SSD 或是 15K RPM
沒有高效能需求的資料 比如說Log, Backup. 就放置在 7K RPM 硬碟

不過近幾年來 總會有人注意到 就算都是熱門的交易之料
也總會有一部分比例的資料 一個月才會需要查詢到一次
比較冷門的資料 有時候就是會在某個時間點冒出尖峰查詢時間
以往以 Volume Base 的切割方式 並沒辦法做更細微的控制
如 資料庫為例 就是很難去把同一個資料庫中 特定資料根據熱門程度分不同效能的硬碟存放
往往就只能全部放在 15K 硬碟 或是乾脆就是全放貴到快被鬼抓走的 SSD
為了維持系統的效能 老闆大概都還是只能乖乖花錢買單

不過這幾年 業界開始有發展不少 可以提高效能 成本 的技術
像是更好的 Cache 演算法, Server side cache..
而 Compellent 算是非常早就開始提出另一種玩法 Data Progression
其實就是我們這次要提的 Data Auto-Tiering.

Compellent Data Progression 搭配之前說明的 Block Level RAID
Block size 可以是 512K, 2M, 4M
就可以達到根據每個 Block 冷熱程度 在不同形態的硬碟中移動
Server 端完全不會察覺目前 Block 在 SSD, 15K, or 7K
完全是 Compellent Controller 底層運作

因為一般來說 一整個 Database 內部大概都只有 20% 是熱門資料
如果只需要採購 20% size 的高速空間 其他 80% 可以配置在低成本空間
這樣整體成本會下降非常多
當然 不同系統 或是不同產業 可能比率也會不同 這得先做過行為分析才知道
Dell 有提供類似的評估軟體 可以先錄下 Server 端的行為
作為評估 不同分層 size 的依據

如下圖 標準配置下 Compellent 會把 SSD, SAS 15K, SAS 7K 分成三種 Disk Group
每個 Block 會根據被存取的狀況 在這三種 Disk Group 中移動
而在這三層 Disk Group 中, Compellent 還會去判斷 Block 要以哪種 RAID 來存放
當然 都是以效能優先

而根據 Compellent 標準
熱門資料 三天後會往上移一層
冷門資料 十四天後會往下降一層
每天會啟動一次 看需要移動的資料量 少則數十分鐘 多則數小時完成
而且還得配上 Storage Snapshot 把 Block 變成 read only 狀態
啟動 Data Progression 搬資料的時候 只會搬已經被 Snapshot read only 的 Block
這些規則目前還是沒法修改 一定會有人吐槽 哪來的那麼死 那麼呆的規則
當然 後面會有不少變化方式來解決這問題
上述配置是完全由 Compellent 內定的配置方式

而 如果對上面的配置方式不滿意
或是手癢 想玩玩看 Compellent Data Progression 可以到何種程度的
可以選擇手動配置

不過咧 你想決定要玩手動配置的時候 需要去 Compellent Controller 作設定
而且是 Storage 整台變成手動配置 改不回來喔
如果擔心的話 可以不用去改這設定
不過我手上的全改拉... 因為自己設定有一定的好處

一旦改成手動配置 第一種玩法可以如下
SSD (R10), SAS15K (R5), SAS7K (R6)

這種配置的好處是 超級熱門資料 可以由 SSD 支援 且利用 R10 提供資料保護且避免 IO 消耗
比較不熱門的資料 就配置 SAS 15K, 且 R5 資料保護 且避免 R10 設定導致的空間消耗
冷門資料 就全丟 SAS 7K, 會使用 R6 是因為 SAS7K 一般來說容量都較大
萬一 Disk 毀損 會需要比較久的時間重建, 重建的當下資料保護性會較差 所以選用 R6

之後就讓 Controller 根據資料冷熱門程度來決定放置位置了
一樣的 Block 根據存取頻率在不同 disk 之間移動


當然 並不是所有 Volume 需要到 SSD
這時候就可以根據需求 設定特定 Volume 可使用的 Disk Group 及 Raid Type

如上圖
Volume 1 需要比較好效能 所以 SSD, SAS15K, SAS7K 都可用
而且 SSD 還是 R10, 提供最好的效能
Volume 2 不需要那麼好的效能 所以設定只能使用 SAS15K, SAS7K
這樣就不會佔用到 SSD 的空間


當然還有另一種進階玩法 如下圖
搭配上 Storage Snapshot 機制 當資料寫入的時候 一律往 SSD R10 丟
而 Compellent 在跑 Daily Data Progression 的時候 因為只搬 Snapshot Read Only Block
這些 Block 會被立刻往下一層 SAS15K 搬 此時 SSD 又會有空間繼續承接資料寫入
而 熱門資料除了是剛被寫入 SSD 的部分 就屬被下轉到 SAS15K的部分了
這好處就是 SAS 15K 專心供應熱門讀取需求 不會因為同時要應付寫入需求而降低讀取效能
當然 冷門資料還是會在十四天之後降至 SAS7K

這種玩法可以把這三種型態的 Disk 優點利用到極致 且避開各自的缺點

而這兩年 SSD 也開始有多種型態出現 價格也下降到一個程度
所以 Compellent 也提供另一種玩法 SSD 也開始分型態分層
SSD 分為三種 SLC, MLC, TLC
當然 一分錢一分貨 三種SSD 單位成本與效能 SLC > MLC > TLC

所以 Compellent all flush 玩法就變成如下

基本上 依照 Compellent 的資料 三種 SSD 讀取效能都差不多
差別在於寫入效能 SLC 最快, TLC 最慢 不過還是比 SAS15K 快
尤其是兩年前 Compellent TLC SSD 出現之後 因為單位成本跟 SAS 15K差不多
再加上單位密度比 SAS15K高很多 同樣2.5吋 有4.8TB 版本
所以近年來非 all flush 的三層配置方式變成如下

這是目前看來C/P最高的配置方式
有 SLC的寫入效能, TLC 的讀取效能 成本也不至於太高
再加上 SAS 7K 每顆HDD 動輒 4T, 6T 的低成本高密度優勢

說到這邊 為啥不能同時 SLC, MLC, TLC, SAS7K 一起用耶
因為 Compellent 最多一個Group 支援三層

再來就是每層的配置比例是多少?
一般就是先找Dell 幫忙跑過分析軟體 DPACK
此時會知道所有系統IO, 資料寫入讀出的狀況 以此判斷各層的配置比例
不過照經驗大概是實際可用空間 1:2:7 的配置比例


那 下篇來廢話這幾年Compellent Admin的抱怨..

Storage Snapshot 原理

本來以為 snapshot 可以跳過 因為一般 IT 大都講到爛了
不過後來因為想廢話 Compellent Auto-Tiering 的時候 要把這部分擺進去 怎麼擺位置都不對
乾脆就獨立出來先針對這大家都知道的功能打打屁吧

因為大家都知道了 就快速哈拉就好

一般來說 Storage 內部 大概就是Controller 把Data 分散寫入 一堆 Block 裡面
需要的時候 Controller 知道要去哪個 Block 去取 Data 送到前端使用
例如下圖 目前有 A, B, C 三個 Block 存放 Data 供複寫 或是讀取

假設第一個 Snapshot 1 產生, Block A, B, C 會變成 Read Only Block (圖示以實心表示)
這時候讀取還是沒問題 一樣去 Block A, B, C 讀出來

假設這時候 有兩份資料要寫進來
一份是要改原本 Block A的內容
另一份是要新增在新的區域 Block D

這樣的話 目前供寫取的區域會變成 A1, B, C, D
但是如果要回去當初 Snapshot 1 時間點 取資料的話會變成取用 A, B, C
不會去讀取 D, 因為產生 Snapshot 1的時間點 Block D 並不存在


這時候如果又產生 Snapshot 2, 一樣 Block A1, D 會變成 Read Only Block

同樣的 又有資料進來 要改A1區域的資料 會直接存放在 A2
並且新的資料 E 也被加進來

此時會有三個時間點可以取用
目前供讀寫的為 A2, B, C, D, E
Snapshot 1 時間點資料為 A, B, C
Snapshot 2 時間點資料為 A1, B, C, D


之後 哪天已經不需要 Snapshot 1 時間點的資料了 就把 Snapshot 1 刪除

Snapshot 1 時間點 Block A 因為在 Snapshot 2 時間點 已經有 A1 取代 所以直接刪除
而 Snapshot 1 剩兩個 Block B, C 會被合併到 Snapshot 2

當然 Block B, C 並不會真的搬 只是直接把 Snapshot 1 指標刪除即可


搞定 下篇就可以專心廢話 Compellent Auto-Tiering

Compellent Block Level RAID

"玩" Compellent 有幾年了

從早期的 DAS RAID, Dell MD, EqualLogic, NetApp FASxxx

其他家Storage EMC, HDS, HP EVA 因為沒接觸過 所以無從得知

但是初接觸 Compellent 時 確實有不少沒看過的技術出現在上面

比較特別的有 Block Level RAID, Auto Tiering

這次就來聊聊 Compellent Block Level RAID 吧

一般來說 Storage RAID 大都是以實體 Disk 來切割 Vol / RAID 

如左圖
Vol 1: 抓 4 顆 Disk, 切 RAID 10
        有兩顆會是 Parity Check Disk

Vol 2: 抓 5 顆 Disk, 切 RAID 5
        有一顆會是 Parity Check Disk

Vol 3: 抓 6 顆 Disk, 切 RAID 6
        有兩顆會是 Parity Check Disk


當然 也有先包成 Disk Group 例如 Disk Group 1 with RAID 6, 然後在內部切割多個 Volume
大抵上都不會差太多

不過Compellent RAID 卻是以 Data Block 的方式來切
Block size可以為 512KB, 2MB, 4MB. 就看一開始開Disk Group的時候怎麼選擇

在 Block Level RAID 的開法 實際資料的放法如下

RAID 10-2, 兩個Block為一組 (Compellent 稱之為一個 Stripe, 一個虛線匡即是)
                其中一個Block為Parity Check
                資料分成多組分散在下面八個 Disk

RAID 5-5. 五個Block為一個 Stripe 其中一個Block為Parity Check
               資料一樣分散多組配置在下面所有八個 Disk

RAID 6-6. 六個Block為一個 Stripe 其中兩個Block為Parity Check
               資料也是分散多組配置在下面所有八個 Disk

而 Block Level RAID 玩法 看來就跟 Disk 數量 設定 沒了硬性關聯
也就可有另一種變形 全部參在一起作成撒尿牛丸吧~~~~

鐺鐺~~~~~

Vol 1, 2, 3 全部都以不同的 RAID type 存在同樣這八顆 Disk
也就是說 同一顆 Disk, 同時屬於多種不同的 RAID Type
當然 IO 還是分散在這八顆 Disk

這樣有好有壞 端看怎麼選擇
基本上 同樣Disk數量 可以提供的 IOPS 不會變
當然 Disk 如果多個 RAID Type 都混在同一群 Disk 上 管理上要比較多花心思
但總是彈性大很多

Compellent Block Level RAID 共有提供下列 RAID
RAID 10: Data x 1, Parity x 1
RAID 10-DM: Data x 1, Parity x 2
RAID 5-5: Data x 4, Parity x 1
RAID 5-9: Data x 8, Parity x 1
RAID 6-6: Data x 4, Parity x 2
RAID 6-10: Data x 8, Parity x 2

當有Disk 掛掉的時候 Compellent 還是會抓Spare disk來頂替位置
不過有觀察到 他是一組一組 Stripe 照順序重建資料

總歸來說 Block Level RAID 也是 Compellent 另一種技術 Auto Tiering 的基礎
Auto Tiering 的酸甜苦鹹可以寫一大篇...所以下次再來講... 嘿嘿嘿嘿

vRealize Automation 企業組織架構與資源池概念

這邊主要是講 VMware vRealize Automation 的~~~ 一小部分

整個 vRealize Suite 算是 VMware 整個 IT 自動化及軟體定義資料中心的產品

整套 vRealize Suite 就是架構在現有 VMware Infrastructure (vSphere, VSAN, NSX)上層

這次不打算聊這個 哪天想換換胃口 再來聊聊這一大片 怎樣摸也摸不完的產品線

今天就算只講 vRealize Automation 也只打算其中的一小部分 也是主軸的部分

個人打算先從這一小片開始 慢慢把 VMWare vRealize Suite 整片拼圖拼齊

當然 如果趕得上VMware 產品改版及新產品線出現的速度的話.....

基本上 vRealize Automation (之後就叫vRA吧) 主體就是多租戶概念

多個用戶可以上來租用 運作他們所需要資源

不用每次都還要請資訊部門進 vSphere 開VM

用戶可以自己開 立刻用 用不到 自己記得砍

基本租戶架構如下圖

Tenant: 即是租用戶的個體 多個租戶之間 互相看不到對方任何資訊 設定 完全獨立

           也可以將其視為個別公司

Business Group: 可以是該租戶本身自行定義的邏輯個體 可以是部門, 任何邏輯分類皆可

Reservation: 就是你可以使用的資源, 資源類型及可使用多少都是在這邊定義

Virtual Machine: 就是虛擬機拉
基本上都是上對下 一對多的關係


對應到最基本的公司組織架構 就會像下圖

該公司自己開一組租戶 然後下面分多個部門 每個部門都有自己的資源池可自行分配


當然 如果部門夠大 自己就維護一堆系統 也可以自己出來承租資源 這時候就像下圖做法

部門下面依照各種不同系統切割資源


還有一種玩法 超級大部門 多切一層分為幾個小部門

這樣子各個小部門之間都有自己的獨立資源可以運用


兩個子部門出現的時候 就會像下圖

不過此時有個問題 子部門A 只能使用 資源池A的資源 不能使用(搶劫) B部門 資源池B


所以可能會有下面玩法

老闆有令  子部門 A, B就乖乖合再一起 共享(爭奪) 同一個資源



當然也還有另一種作法 大部門同時維護多套系統 那就依照系統邏輯來切割

至於資源池的部分 目前 vRA 可以串接的後端平台不少
目前有自家的 vSphere, AWS EC2, MS Hyper-V, MS SCVMM, KVM, XenServer
設定資源池的時候就可以同時指定後端串接平台 如下圖

同一個部門 透過同一套 vRA API 可以呼叫後端不同類型的平台


另外也有另一種玩法
每種資源池都會有各自的服務等級 比如說 CPU 種類, RAM, Storage Performance.
這時候就可以根據這些類別分別定義資源池

一分錢一分貨 Gold Level, Sliver Level 價格不同 效能不同 (該怎麼用呢 老闆在看喔..)

綜合上述哩哩摳摳 如果還沒昏頭的話 來個小範例吧

某個財務部門 手上的預算系統 根據 Database, AP 不同 分別配屬於 Gold, Sliver 等級資源(VM)
而且還有一部分的測試開發用 VM, 配置使用 Copper 低階 VM
而ERP系統 因為使用量大 DB, AP都直接配屬比較高級的資源
當然ERP也有開發需求 但因為這部門偶爾才會需要開發ERP新功能 就把開發系統丟在EC2.



不過部門主管想了想 預算系統跟ERP 並不是同時都會遇到使用巔峰期
其中一套系統閒置的時候 如果另一套系統可以使用的話不是可以減少預先配置資源嗎

所以就 噹噹~~~~~ 資源就合併再一起互相調配資源吧

這部分是vRA 關於組織 資源 後端平台的應對方式

後面還有一大片拼圖 後續再慢慢補上

別問我為啥都是用藍色圖塊 等我想到的時候已經懶了 就將就著看吧