iT邦幫忙

第 11 屆 iThome 鐵人賽

DAY 3
2
DevOps

就是「懶」才更需要重視DevOps系列 第 3

Day3 又愛又恨的「虛擬機」

昨天看了三個「虛擬機」的機器服務架構,但其實昨天說的第三個架構(微服務時代),仍然有不少隱性的問題:

  • 浪費機器資源:
    每一台虛擬機都只放一個服務,對於連線數量小的服務可以開小規格的「虛擬機」資源。但是每次開一台虛擬機時,總是需要浪費一點資源提供給系統使用,且每一個服務本身都還需要保有備援機器,以防主要服務loading過高或者機器死亡,保持隨時可以救援狀態。

  • 高成本:
    就算服務放置在「虛擬機」上,也不能任意在實體機身上大量建制「虛擬機」,畢竟「虛擬機」的資源仍然依附在實體機。所以當「虛擬機」數量過多時,也容易造成互相搶奪實體機器資源的情況。為了避免有這樣的情況發生,只好不斷的購買實體機器,避免「虛擬機」互搶資源。

  • 管理不便:
    隨著公司成長,服務相對的也會越來越多。假設每個服務都有三台虛擬機(兩台在線上做負載平衡,一台作為備援機器),當你有10個線上服務就會有30台虛擬機,但是剛剛只有提到線上服務機器,也許你會有「測試環境」的機器 + 「開發環境」的機器,這一些加一加10個服務可能就具備將近50台虛擬機器。

    而且當機器建制是由不同人經手時,難免會有一些些差異,這是最容易導致服務異常卻又難以找bug的問題。時常會有莫名其妙的特例問題發生,導致時常會聽到工程師在抱怨,環境不一致所以有些bug在測試環境無法順利測試。

  • 版本升級不容易:
    你可能會遇到作業系統太過於老舊,不得不採用「先建後拆」的行為,此時新版作業系統的「虛擬機」器建制完成後,還需要考量code是否可以在新機器上正常服務。有可能會因為建制過程中某些套件版本過於老舊,或者資安問題不得不被迫升級版本,這時候就得更改code撰寫方式,為了配合新機器版本,本機套件跟作業系統也必須跟著升級,避免版本落差導致服務上至開發環境才發現異常,大多時間往往浪費在這時候。

當然還有更多的不便利性,但就光是以上幾點項目,加上管理的機器數量龐大,就足以每天都反覆處理類似的問題,雖然培養出打指令速度很快,但卻總是重複著相同行為,在工作上也漸漸失去熱忱。


因此接下來要介紹一個容器架構,但是此架構仍不是最好版本,可以思考一下以下架構解決的什麼問題,但是又有什麼問題尚未解決,答案明天揭曉。


上一篇
Day2 熟悉的「虛擬機」時代
下一篇
Day4 該如何規劃虛擬世界的架構
系列文
就是「懶」才更需要重視DevOps30

尚未有邦友留言

立即登入留言