樓主只聽到表面, 卻忽略了過程.
AP/DB 效能不佳, 原本就應該進行調校, 調校得宜者, 不論實體虛擬都不會有問題.
現在問題在於: 原先的實體機管理者, 不善系統調校, 只能放著給他爛. 此時如果由這個管理者自行導入虛擬化, 結果還是一樣爛.
但是一個專業的虛擬建置顧問, 在導入前, 勢必會先做實地勘察(Site survey), 看看哪些適合虛擬化? 那些不適合? 而那些原本就重拖的系統, 是否有機會先進行調校, 之後再來虛擬化? 如果不能調校, 是否可以事先配置足夠的硬體資源, 來滿足這些重拖的系統?
Site Survey -> Sizing -> Deployment 是專業顧問的基本程序, 上了虛擬化會變好, 是因為顧問在前面做了很專業的 Site Survey 和 Sizing, 所以在虛擬化的過程中, 一併解決了原本實體機上面, 管理者應該要做, 卻沒有去做的調校或是資源分配的工作.
有這樣的過程, 才會真的變快.
事實上,這是新客戶的提問。一直以來,我們都建議客戶將 AP/DB 分開,而此新客戶就問說,我們都是虛擬主機了,這樣分開還有意義嗎?
AP/DB 分開, 不是只有效能上的考量, 還有維護上的問題.
假設你的 AP 出問題, 整個系統要重新安裝的話, 此時若 DB 是在另外一台伺服器上, 你一定會感謝神明, 不必沒事毀了一個好好的 DB, 還要重新備份幾百 GB 的資料再倒回來. 而且萬一該 DB 是多個 AP 共用的話, 你這樣一重裝, 豈不是所有 AP 都要停擺?
此外, 當你發現 DB 負荷很重, 想要從系統數據去察看的時候, 你也不希望 CPU 的用量是跟 AP 混在一起, 分不出到底是 DB 用得多? 還是 AP 用得多? Physical Disk I/O 也不會混在一起, 看不出是 DB 用得多? 還是 AP 用得多?
以查修經驗來看, 微軟的架構, 最好是一個作業系統, 只執行一件事情, 這樣最容易查修. 多用途共用一個作業系統, 查修時會礙手礙腳的, 因為你不知道動了這個參數, 會不會去影響另外一個原本功能正常的任務? 互相牽扯的因素多了, 查修需要更謹慎, 也更花時間, 才能避免引發更多的故障. 原本任務分開, 查修一台需要一小時; 把它們合在同一台, 查修起來可能會變成三小時.