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 關於組織 資源 後端平台的應對方式

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

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

實體機環境 如何讓資料在最小企業營運衝擊的環境下 跨不同廠牌 Storage 搬家

現今而言 已經有不少系統都轉換到虛擬環境 或是根本就是活在雲端上
但終究還是有些還在地上 甚至還是實體設備
這些有可能是某些運作五年以上的系統
又或者是 根本就是被要求只能在實體環境運作

在這狀況下 一般資訊部門只需要每年跟老闆要點錢 繳繳設備軟硬體保護費即可
不過有時候會遇到一些很囉哩巴說的問題喔
某家廠商的硬體EoS (End of Support), 想巴著廠商說要繳保護費都不行
又或是 當初採購的設備 已經承擔不了新的服務進來 原有設備擴充性也已經到了極限
不然就是 舊設備(舊玩具)的 TCO 太高 新系統(新玩具) TCO 相較之下低很多

當有這需求出現的時候
Server 好解決 只要利用HA 即可搞定新舊設備切換
但是存放資料的 Storage 可就沒那麼容易了
尤其是想要從A廠家 換到B廠家的時候 一開始大概都很難很順利的切換過去

而且因為是 Storage, 必須要時時刻刻維持資料的一致性
從DB層搬家是比較容易的方式 像是透過現在的SQL AlwaysOn 等等 都可以減少切換停機時間

但如果是老舊系統 SQL 2008? 或者是AP原本就不支援SQL AlwaysOn?
就還是只能老老實實在Storage Level搬資料了

比較硬幹的方式 新舊 Storage 同時上線
由Server端 停掉Database service, 以OS file level方式Copy檔案

這在僅有少量資料要搬家的時候 User 還可以接受
但是如果你要搬家的資料以數百G來算 甚至以TB來計算的時候
User可能不允許讓你有長時間停機的可能 讓你慢慢搬完資料

可是咧 你真的不得不被逼著換Storage啊~~
10TB的資料 你也不能夠要求User整套關機 讓你慢慢搬

之前遇到這問題 廠商介紹了一套FalconStor NSS 來搬家

基本上就是下圖所示 作為中介Storage Device
在 Back-end side 本身是Initiator, 連接到 Storage A 的Target 並取用其中的資料
在 Front-end side 又把自己變成 Storage, 把Storage A的資料透過自己的Target 提供給 Server A
SAN Switch A1/2 基本上可以為同一台 只要Zoning設定正確即可

這種狀況下有很多玩法
像是下圖 可以組合多種高低階Storage在後端 利用類似Data Tiering的方式
SSD Storage 會被當成Cache, 低階Storage  只要有基本的儲存功能即可

而本篇主題 資料如何在不同廠商Storage之間搬家呢
原則上是利用其中一個功能 SED (Service Enabling Device) 功能
基本上就是資料原封不動從前端寫回後端Storage.
不會特別因為FalconStor NSS 加任何附屬資料 (放在別地方)
這樣子在後續把NSS斷線之後 Server A還是可以直接讀懂後續 Storage A/B 的資料


搬家方式如下
假設SAN Switch 沒有分Front-end, Back-end的狀況下

這是一開始起手式

1. Server A 還是直連 Storage A
2. Storage B 上線, NSS 也上線

Step 1. 接下來就是排個30分鐘停機時間
1. NSS 接上 Storage A 的資料
2. NSS 再把資料分出來 讓 Server A抓到
3. 然後就是系統回復上線 繼續提供服務

Step 2. NSS開始把資料順便同步到Storage B. 這段時間還是持續提供 Server A access
Storage A此時還是Primary, Storage B 只是 Data Copy
這段時間看你的資料有多少 基本上怎樣 Copy 都不會對 User 有 Impact

Step 3. (這步可以不用作)
當Storage B Copy完成 NSS會持續維護Storage A/B之間的資料一致性
這時候可以把Storage A/B對調, B 為 Primary, A 為 Copy

Step 4. 再排一個 30分鐘的停機時間 (可能是一個禮拜 或是一個月後 端看 User 協調)
這時候就是斷開 NSS to Storage B 連線, 讓 Server A 直連 Storage B
到此為止就是搬家完成

最後就是把 Storage A 跟 NSS 拆掉

基本上搬家過程還算順利 總共70+套系統 200TB data 一套一套跟 User 協調時間慢慢搬
每套系統不管資料再大 都只要排兩次30分鐘停機

熟練之後 速度快的話 script 事先全部寫好 可以拼到 兩次各15分鐘 就可以上線
沒辦法更快主要還是因為 Windows MPIO 抓新的 Storage 需要整套 Server 重開機
還有就是 NSS License by data capacity. 同時間只能提供一定數量的 capacity 搬家

所以就是 大家先排時段先贏拉

SAN Switch 中間那條線ISL 要不要連?

長久以來 Datacenter storage network 不論是FC SAN or IP SAN 都會導入多重路徑 MPIO設計
為的是避免實體線路中斷導致的設備失效
多重路徑 MPIO 的好處也可以提供更高的頻寬支援更多設備IO需求

一般來說MPIO不外乎 兩座SAN Switch A 與 B
Storage與Server 各至少有一條線路接上 SAN Switch A 跟 B


以圖下的標準設計來說

Server A 到 Storage 的路徑就會有下列四條

1. AA1 -> Switch A -> A1
2. AA1 -> Switch A -> A2
3. AB1 -> Switch B -> B1
4. AB1 -> Switch B -> B2

任何一條路線掛掉 都還是有機會走其他路線



可是也聽過有另一種說法
SAN Switch A/B 中間如果也把它聯起來 像是下圖的ISL接線方式呢?

Server A 到 Storage 的路徑就會有下列四 + 四條

1. AA1 -> Switch A -> A1
2. AA1 -> Switch A -> A2
3. AB1 -> Switch B -> B1
4. AB1 -> Switch B -> B2
5. AA1 -> Switch A -> Switch B -> B1
6. AA1 -> Switch A -> Switch B -> B2
7. AB1 -> Switch B -> Switch A -> A1
8. AB1 -> Switch B -> Switch A -> A2

乍看之下 HA 容量加倍耶 不過後續問題可能比較多喔

• 首先是,當初為了HA而切出來的Switch A, Switch B 隔離的路徑就相通了,
  這樣就有可能導致Switch A or 路徑A上面出事, 連帶把B一整串拖下水
  比如說 某個豬頭 Switch A 設定錯誤 連帶整個環境一起掛點
  路徑 B 某個點用量過高 可能連 路徑A一起爆炸
• Storage / Server OS Path 可管理上限
  Storage 本身 每個 Volume or Share 可能只有1024路徑, 甚至 Storage全部就只能有1024路徑
  Server OS 本身 如ESXi 6 maximum 1024 paths. 換算4 paths MPIO 可以接到256 datastores. 但是如果用 8 paths, 只能接到128 datastores. 某方面來說很有機會超過
• MPIO Paths多一倍 但是Server可用總頻寬 並不會多一倍
  原因還是卡在Storage -> SAN Switch, SAN Switch -> Server 這邊
• ISL license 也是要錢 錢 錢

比較這些問題過後 HA double 好像就沒來的那麼有用
畢竟所有設備都已經有Multi paths了 Switch A/B 中間接個ISL 來個錦上添花
得到的好處好像也不見得比上面會遇到的問題來的多
究竟是 Z > B or B > Z.
就看Architect 決定囉

vSphere 5 storage 部份的改變

2013 舊文章

＝＝＝＝＝＝＝＝＝＝

Production environment 轉上vSphere 5也ㄧ段時間了.

老實說..實際使用上.ESXi 5跟ESX/ESXi 4 差異比較大的應該就是storage部份

說好用嬤?..我倒覺得各有利弊

好處是多了Storage DRS + VAAI (Storage 有支援時).

Storage DRS主要是針對datastore 空間耗用上.可以自動去調配移動VM到比較有空位的Datastore

這點雖然在現在我們已經不使用VM level Thin Provision.還是有ㄧ些好處在

另外VM在Create時.也不用特定去選擇要放置在哪個Datastore. 只要選定你設定好的SDRS即可

這點到是可以減少不少人為錯誤發生

VAAI的話則是可以把原本ESXi需要對Storage作的動作.降級到Storage level即可運作..

自然速度就快非常多..實際測試下ESXi 5 與 ESX 4搬動差不多大小的VM..速度大概差了兩倍多..

當然Storage也要支援才行

至於這次比較不好用的地方呢?

大概是因為VMWare HA增加了Storage heartbeat.

避免因為單方面Networking issue造成的split brain.

這點個人相當同意也贊成這項功能..

畢竟之前VMWare HA也曾因networking問題造成誤動作.引發災難..

不過在vSphere 5實際上線ㄧ段時間.反而發現意料之外的問題出現

結果是砍Datastore/Storage變得非常麻煩..

ESX/ESXi 4時代.砍datastore只要直接Delete 就可以..然後叫storage回收即可

ESXi 5時代, 必須要先把Storage IO Control Disable,

然後ㄧ台ㄧ台ESXi host去unmount, 接著是ㄧ台ㄧ台ESXi Host detach......

如果你有20個VMhosts + 10 Datastores, 就代表你要作200次Detach這動作.

同事有找到同時砍Multi datastores + Multi Hosts script..

結果20VMHost x 10 Datastores 跑了十幾個小時才跑完

如果你用之前的方式砍Datastore.

那很可能會在你Storage unmap/delete volume的時候造成ESX APD (All Path Dead)

結果就是這個ESXi 5 management agent no response, 上面的VM沒掛..可是你也不能再vMotion..

你得找方法把management agent restart. 目前只試成功hostd service整個砍才有機會restart service.

你的VM才有辦法移到其他ESXi 5上面..

VMware 應該會對這塊有所修正才對..不然APD還真的蠻容易造成問題的.

VMWare Virtual SAN

下午 (2014/04/23)溜去參加VMware VSAN seminar.

上次跑去應該是兩年前了吧..這次是衝的準備要導入的心態去看看

大約五年前 就有使用過HP Lefthand virtual storage.

架構幾乎跟現在的VSAN差不多.

當時遇到的問題就是1G network latency 導致IOPS過低

最後還是不得不選擇貴死人的share storage

不過這次VMWare VSAN架構倒是有些許不同

最大特徵是把VSAN function直接綁進ESXi kernal.

這比之前以Virtual appliance 的方式有效率的多

也建議不要使用RAID. 直接讓ESXi抓去餵VSAN.

使用ESXi內建RAID演算法搞定data HA

這又少了一次performance overhead.

與VMware cluster 為單位綁在一起.

也就是說現在VMware cluster會再加入VSAN設定

在管理上也不用像之前NetApp or Compellent

需要先做過一定程度的教育訓練才趕上場

這點對一天到晚人員來來去去的公司到還蠻重要的

會後特別找講師確認過

fail disk 更換跟一般的storage沒啥差異.

data HA policy 也可以照自己的意思變動.

Network partition 特性也還在可接受範圍.

以實體CPU為單位計價.15W list price.

配上近來一堆server出的2U server 塞上24~26 disk HDD

及宣稱2M IOPS, 4.4PB 能力.

而且現在10G network 似乎也差不多到了成本可接受的範圍

再加上可以省下不少機櫃空間

算是很有潛力取代不少中低階storage了

唯一比較可惜的地方 就是只能夠VMWare ESXi使用

不過也應該夠了

Scale up? or scale out?

前陣子忙碌..一下子就累積了一堆想要碎碎念的題目..

今天就來聊聊最近遇到的問題.. scale up or out.

scale up, 就是系統數量不變.但是增加cpu core, 換更快cpu, 加大ram 來加大承載量

scale out, 增加系統數量來增加服務承載

兩者沒衝突都可以併行..

但是我們一般都是處於有限度資源的環境 這時候就得去考量要以哪種方式優先

在十年前.一般企業用主機還是比較昂貴的狀況下.

換更快的CPU 或是加大RAM 總比加買新主機來的成本低

所以那時候 mainframe, 大冰箱主機相當流行

但在現在幾年中低階主機運算越來越強. virtualization, cloud computing也越來越流行.

scale out慢慢變成大家選擇的方向

例如Amazon AWS的設計概念.幾乎都是用一堆VM去構築整個系統..

當服務需求增加.就多加一些VM來搞定即可

兩種選擇其實沒有好壞.端看系統本身特性.

舉個例子.

一筆固定的國防預算.可以建造三艘密蘇里級戰列艦 或是10艘派理級巡防艦 二擇一

要選哪好哩...

如果我要對付外星人.裝甲超厚..非得用15吋砲才幹的掉的外星船..那就是密蘇里艦囉..

核彈這種地圖兵器保留後面在講..而且電影也沒這樣演..:P

但是如果我只是要抓抓小海盜..偶爾開去人家門口踩點.那一次兩艘巡防艦就可以搞定

換作我們的環境.

如果系統內每個工作運算都很複雜..幾乎沒法拆開分成數個運算..

那也只能選擇快的CPU, 大RAM.

如果每個工作都可以拆成小運算..而且可以高度平行化..那就可以來個螞蟻大軍了

在更深入討論的話..

一般常看到的三層式架構..AP, Web, DB

其中AP, Web都是可以用許多小VM, 

橫向擴充scale out的方式來達到系統承載容易擴充的設計

當然如果AP搞得太複雜.非得吃那麼大CPU RAM 那也拿他沒辦法

但是DB的部分 因為要維持資料的一致性..

目前大都只能用大砲巨艦主義來搞定..就是big ram, big CPU.

不過近來開始流行的No SQL, MySQL Cluster 完全就是螞蟻雄兵 分散式架構..

其實個人想法.將來趨勢應該會持續往scale out發展.

看看cloud design的精神..其中就是許多VM兜成一整套系統

每個VM/component都被預期會掛掉..且隨時都可以被替換.

scale out也比較不容易遇到scale up所遇到的極限

每個主機CPU core, RAM總有上限..

但是如果多個VM.除非AP自己定義的最多node.一般來說都是無限橫向擴充..

回到之前我們提到的..要蓋密蘇里艦好..還是蓋巡防艦好..

其實現在敵人真正怕的都是核彈..

30顆巡弋飛彈+核彈 分散在三艘大船.或是十艘小船

如果我們把可能戰損考慮進去..似乎答案呼之欲出..

這大概也是現在很少在看到新的大砲巨艦建造的關係吧

如果我們AP or Web考慮到everything will crash的條件下..

大概也是走向同樣的設計吧...

NetApp Snapmirror

話說..去年一整年(2014)都在乾坤大挪移..

Data 在不同的storage之間搬來搬去.

要如何減少service downtime. 一直是能不能得到service owner 允許搬家的關鍵

不同的系統有不同的data量..如果是TB等級的data要從某個storage搬到另一台storage.

這時候還傻傻的用OS level copy, 八成需要半天以上的downtime. 

更不用說可以得到user的停機許可

所以一些中高階($_$)storage功能就派的上用場拉

以NetApp來說..全系列都有支援Snapmirror..當然要有license ($_$)

原本Snapmirror是被NetApp定義用來作DR..可以在遠端保留一份一樣的資料

最短的RPO可以到5 mins.

不過在我的經驗中..則是完全被利用來data大搬家.

說穿了 snapmirror 不過就是snapshot copy

都是先在原來volume作snapshot

然後再把這時間點的snapshot copy到另一部NetApp.

snapshot copy期間, 原本的volume不受影響可以繼續讀寫..寫入就直接寫到新的空間

直到snapshot copy完成..新寫入的data合併snapshot

如果data大搬家就是 snapmirror每隔5分鐘做一次snapshot, copy 到新地方

等到最後一刻..server關機..同步最後一份snapshot..切換到新的NetApp..server開機

動作快的話15mins搞定..就算10TB data 系統只要停機15mins即可完成搬家

當然這之前有許多準備動作要做..也有許多需要注意的技巧..

沒注意到 有可能就是DR目的還沒達到..反而變成另一個incident..

1.保留足夠空間.

記得在原來的aggrgate多保留一倍空間給volume. 

因為volume的snapmirror有可能會斷..斷掉的話, snapshot 會持續重傳..

如果這時候持續有新data寫入..就會佔用volume之外aggregate的空間

如果aggregate滿了..或是volume可使用disk size上限到了..這時snapshot還是傳不完

這時候netapp就會把volume offline保護...incident就來拉

又不然某次user把某個volume當backup pool. 

跑backup的時候寫入就多..snapshot長的就很快..就爆了

所以記得多保留一點空間給snapshot volume

2.多一點頻寬

snapshot copy需要不少頻寬..尤其是第一次full volume copy.

如果頻寬太少.可能第一次full volume copy就要花上幾天.

這時候也只能多用一點aggregate空間先撐住 snapshot吧

當然如果data 一直持續寫入..寫入量比mirror 頻寬高..

那還是乖乖加頻寬吧

3.早一點開始

如果snapshot是要用來作netapp之間的data搬家. 

資料量越大.最好是越早開始做snapmirror

讓netapp至少先花一個禮拜同步data. 

不然最後要切換的時間到了 data還沒同步完就糗了

4.精神好的時候再動手設定

data很重要, 所以會動用到snapmirror 貴森森的功能.

設定說複雜 不算複雜..不過如果眼花. source 跟 destination看錯..

或是蓋到不該蓋的volume..

這可不是網路斷線.修好就行..

5.多個volumes不要同時initial snapmirror

initial snapmirror就是啟動第一次full volume snapshot copy.

這時候時間花最長.之後第二次.第三次.才會慢慢加快.直到跟上data變動量

如果這次同時N個volumes啟動initial snapmirror.

多個volume大家搶頻寬.同時作full volume snapshot copy.

就得確保你的aggregate有足夠空間讓所有volumes 新資料寫入才行

說了那麼多..重點就是小心.小心.再小心.

storage, database管理與一般network device管理最大不同

network 斷線, 連的回來就好, 

database 不小心砍到data, 說不定還有機會從log救回來

storage 蓋到不該蓋的data... 只能從backup回來

而且很不幸的 data backup在怎麼做都有一定的RPO..

怎麼救都會有一定時間的data lost.

就算丟了一分鐘的finance data 大家也都會捲鋪蓋

所以拉...轉network好像比較好玩哩..:P