Sunday, December 16, 2018

AWS VPC 與 Azure VNet 互通


既然都上了Cloud, 多少會想要不同家平台互通
這次就來試試目前大家最常用的 AWS, 與後來急起直追的 Azure 互通
有參考不少文章 會一併列在後面

在開始之前 先列出大概架構圖 下面是大概

基本上就是 AWS 端 弄一台 Windows 2012 server 當 router
當然 Linux 版會更好 不過這邊先用 Windows 2012 來玩
Azure 端則是直接 Local Network Gateway, Virtual Private Gateway 接 VPN Tunnel
因為步驟有點多 AWS, Azure UI又常在改版 乾脆就只付簡單的圖就好


起始架構

首先是最原始狀態 兩邊都還各自獨立的時候
Azure Vnet, Subnet, VM1, AWS VPC, AWS VPC, Subnet, VM2
各自已經是完成 這部分的實作就不贅述

Step 1: 在AWS 開一個Windows 2012 R2 當 Router

Windows 2012 R2版本, 記得掛一個 Public EIP, 晚點要給 Azure 對接用


Step 2: AWS 端 Routing Table 指向修改

Route Table 修改 加一筆 10.1.0.0/16 導向剛剛建立的 Windows Server


還有在剛剛建立的VM上面 把 Source/Dest check 關閉
這樣network package就可以往這邊送了




Step 3: Azure 端 建立 Virtual Private Gateway

建立Virtual Private Gateway, 記得掛對 Virtual network, 相關設定如下
這時候會拿到 Azure 配給你的 VPG Public IP (圖上為 104.211.51.17)
這動作會花不少時間 建議先放著不管 大概半小時會完成


Step 4: Azure 端 建立 Local Network Gateway

這邊在建立 Local Network Gateway的時候 會要你另外開一個gateway 專用network
這裡是指定10.1.0.0/24
另外 Local Network Gateway 的 IP address 為 AWS 端 剛剛拿來要當 Gateway 的 Windows server EIP (35.165.73.8)


Step 5: Azure 端 設定 VPN Tunnel


記得這個 Connection Local Network Gateway 跟 Virtual Private Gateway 都要掛到剛剛設定的
Share Key 也記得要設定記下來 待會AWS那一端會用到
這時候因為 AWS 端還沒設定 所以 Connection status 會是 "Connecting"


Step 6: AWS 端 Windows Router VPN Tunnel

這邊比較麻煩 有現成的 PowerShell 可以用
https://github.com/Azure/Azure-vpn-config-samples/blob/master/Microsoft/microsoft-rras-windows-server-2012-r2.ps1.xslt


前面第5~78行 直接copy 到 PowerShell IDE 下跑

後面加interface那一段 黃色標籤記得修改 SharedSecet 就是上一步的 Share Key 這邊先放這裡的版本
Add-VpnS2SInterface -Protocol IKEv2 -AuthenticationMethod PSKOnly -NumberOfTries 3 -ResponderAuthenticationMethod PSKOnly
 -Name toAzure -Destination 104.211.51.17 -IPv4Subnet @("10.1.0.0/16:100")
 -SharedSecret 12345

Set-VpnServerIPsecConfiguration -EncryptionType MaximumEncryption

Set-VpnS2Sinterface -Name toAzure -InitiateConfigPayload $false -Force

# Set S2S VPN connection to be persistent by editing the router.pbk file (required admin priveleges)
Set-PrivateProfileString $env:windir\System32\ras\router.pbk “toAzure"IdleDisconnectSeconds" "0"
Set-PrivateProfileString $env:windir\System32\ras\router.pbk "toAzure" "RedialOnLinkFailure" "1"

# Restart the RRAS service
Restart-Service RemoteAccess

# Dial-in to Azure gateway
Connect-VpnS2SInterface -Name toAzure

在這之後 大致就完成了
AWS 端 Windows Routing and Remote Access 應該會看到如下畫面

Azure 端 剛剛建立的物件 Connection Status 就會變成 Connected

基本上這時候兩邊VM就已經互通了


== 然後....就把 AWS 跟 Azure 上的所以有VM都砍掉了 免得被收太多$$ ==



參考文章如下
https://blogs.technet.microsoft.com/canitpro/2016/01/11/step-by-step-connect-your-aws-and-azure-environments-with-a-vpn-tunnel/

RRAS configure source
https://github.com/Azure/Azure-vpn-config-samples/tree/master/Microsoft

Sunday, November 5, 2017

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 都可以重開機

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



Thursday, July 13, 2017

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 的環境下了
這又是另一段故事了.



Wednesday, June 28, 2017

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 還是覺得很笨 很難使用
誰知道又是十幾年前 我對虛擬化的評語 ”又慢又難用“ 一樣

Friday, June 9, 2017

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







Monday, May 29, 2017

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 的概念

Wednesday, May 17, 2017

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


最近大家應該上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