胡凱,bilibili運維負責人,曾經就任於金山軟件、金山網絡、獵豹移動,負責運維相關工做。Bilibili是國內最大的年輕人潮流文化娛樂社區,銀河系知名彈幕視頻分享UGC平臺。git
95後二次元新人類的追捧,讓以視頻彈幕、UP主聞名於世的bilibili(如下簡稱B站)愈發火爆,無數年輕人經過電腦、手機、電視等終端設備在B站上追番、看彈幕,特別是新番上線時的訪問壓力是很是大的,這就給B站的IT運維團隊帶來了巨大壓力。胡凱在去年加入B站剛剛成立的運維部,人少事多,遇到了不少坑。github
本文根據做者在「監控與性能分享羣」中的分享內容整理。後端
B站運維痛點主要有3個:人手不足、故障多、運維繫統跟不上,針對這三個痛點,B站採用了三種方式進行破冰。瀏覽器
一、解放勞動力安全
目前B站的CDN主要是自建的,TB級帶寬,視頻存儲也已達到N個PB,運維壓力很是大。招人確實能夠解決問題,但在上海這座魔都招聘合適的運維人員非一朝一夕可以完成的,人手不足怎麼辦?那就想辦法把勞動力從繁雜的平常運維工做中釋放出來。服務器
因爲以前沒有專門的運維部門,IT系統的權限都在開發手上,出問題了之後運維總得跟在開發後面查緣由,效率低不說,溝通每每容易出現問題。
因此咱們第1步作的就是:用Ansible + Jenkins搞定自動發佈。Ansible是相對簡單的批量管理工具,支持模板管理等高級功能。搞定了自動發佈,開發的服務器需求已經明顯降低,只要把代碼提交到 Git主幹,就會自動觸發發佈。網絡
Git使用的是 GitLab,同時爲了安全咱們作了一層LDAP代理,效果至關於「將軍令」,操做機、Git和Jenkins用 OpenLDAP 作統一認證,後續用到的Redmine、Grafana、Zabbix 等都接入了OpenLDAP認證,每一個人都有個動態口令,每次驗證都須要用到。app
二、一棒子監控告警系統運維
因爲原始的監控不知足快速增加的業務,咱們部署了開源監控系統 Zabbix,雖然運維同事可以很好的使用Zabbix,但其餘部門同事總以爲易用性不高、並且不少定製化監控實現起來很麻煩。分佈式
而後,咱們開始折騰監控系統——「一棒子監控」,爲何這麼說呢,由於要把監控細化,不是一兩天的事情。而B站的幾乎全部請求都要通過CDN,入口在手上,出問題想知道還難嗎?因而,咱們在入口處作了監控,全部 5xx 的錯誤都打到ELK,那麼不管是什麼業務出問題了都會及時告警,讓相關人員來處理,後續再細化。
另外,要把精力投入到最重要的事情上。咱們能夠花很長的時間去搞好Zabbix、Open-Falcon,但結果多是 從80分 到 90分這種並不顯著的效果,而不少監控並非 Zabbix、Open-Falcon擅長的,不如打個差別戰。
上圖中有個 StatsD推薦給你們,StatsD能夠很是靈活的嵌入到代碼裏進行監控(Shell均可以),由於使用UDP協議,因此服務端性能和故障不會影響到調用的程序,能夠實現業務級的 QPS、響應時間等統計類監控。
其中一個報警最終的效果以下:
B站是自建CDN的,在國內有覆蓋全國的好幾百個CDN節點,CDN的監控一直是個難點,當某1個鏈路出現問題,用傳統的Zabbix、Open-Falcon監控很難發現問題。雖然咱們自研了Http-monitor監控,可用於網站的可用性監控告警,但考慮到獨立資源和數據可靠性,還有用戶端網絡質量的檢測,仍是同時使用了第三方監控寶的服務。監控寶使用簡單,功能實用,監控點多,分佈式監控能夠及時發現網絡上出現的問題,提供的快照功能能夠快速定位問題和查看詳細信息。並且監控寶屬於第三方獨立的,還能出具網站的SLA證書,做爲B站內部工做考覈的依據。
三、開源系統的愛與恨
B站技術氛圍濃厚,愛開源、愛新技術,因此使用了大量的開源組件,包括SheepDog(丟過數據)和GlusterFS(卡成翔),其中最大的坑是 SD卡 + Ceph存儲。Ceph自己的設計很是好,可是姿式不對也會死很慘。好比B站的某套服務器集羣用 SD卡來跑系統,結果 SD卡跪了致使系統也跪了,全部虛擬機的磁盤io都卡頓甚至死機,通過不斷調優終於仍是穩定了。Ceph給我最大的安慰是:它沒有丟數據,沒有丟!
此外,Redis3.0、Codis、Twemproxy等開源系統都在B站獲得了使用,最後咱們自研了 BiliTW(已開源),主要緣由是 Codis如今沒更新了,Twemproxy的性能比較差,特別是後端Redis多的狀況下(並且它和Redis同樣、只吃單核)。BiliTW最大的改進是支持多核,增長了一些易於運維的功能。
最後總結一下B站運維團隊的成長過程:
因爲人手不足,因此事情得挑着作;因爲故障多,得先抓入口、抓大的;因爲運維繫統跟不上,得先拿開源的頂着;因爲用了大量開源系統,因此踩了不少坑。
問:請問動態口令是怎麼作的,本身開發仍是開源auth?
答:用的是谷歌動態口令,開源的Google身份驗證器。
問:Ceph部署到線上須要什麼特別的處理嗎?都遇到什麼問題了?
答:Ceph要注意版本,必定要用穩定版,要用大廠用過的版本。另外 Ceph很是耗資源,B站所有用的SSD,Ceph的內部交換是獨立的萬兆網絡。Ceph遇到最大的問題就是感受Ceph成了分佈式單點存儲,都是幾個節點、幾個副本,大的kvm塊存儲集羣有64節點的集羣,數據3副本,解決起來很複雜,須要有愛研究,能看懂代碼的人。
問:B站運維團隊多少人?
答:去年是從0開始,目前20多人,包含應用、研發、安全、信息等。
問:GlusterFS這個存儲用起來卡嗎?
答:GlusterFS 我認爲只適合作大文件的冷存儲。
問:爲何不用Docker而用kvm
答:咱們也用Docker,Docker一直有關注,但實際用的人很少,能用起來的都是投了不少資源進去的大公司。在 Docker 1.9.0 開始,咱們把核心SLB跑在Docker上了,用Host方式。今年下半年,咱們的一個大目標就是Docker接入其它線上業務。目前使用的Mesos Macvlan方式已經在踩水過程當中。
問:Hadoop 相關的運維須要作嗎
答:大數據也作,暫無專職人員。技術研究這塊因爲缺乏專人,我都是給每一個應用運維分任務。大數據就分給了一個應用運維在搞,和開發一塊兒學習。
問:大家服務器網卡作綁定了嗎?
答:咱們所有作了雙網卡的綁定,萬兆bond0。
問:故障多,這種麻煩如何快速解決?
答:這個很難,一方面須要瞭解業務,二方面須要有數據和手段。剛開始咱們查問題很是慢,後來逐步改進,好比完善監控,加故障錨點,故障總結。最近在作 Drapper 連接追蹤,好多公司也都有作,實際上就是在請求的連接各個環節加標記,而後選擇性作實時分析。Drapper最終實現的效果就像瀏覽器的審查元素同樣,哪裏慢一下就看到了。
問:mode0模式的話總帶寬仍是一個網卡的吧?我在測試mode=4,結合交換機的動態聚合,遇到的問題是服務器相互傳輸的話,帶寬是一個網卡的速度。
答:Mode 0 最好在交換機上作下配置,帶寬是跑2張網卡的,既能冗餘,也能上量。咱們自建CDN帶寬很高,單臺機器帶寬就按20G準備。在獵豹用的是Mode4,也挺好的,Mode6不須要特殊配置,但有一個方向不均衡。以前測試Mode4效果最好,但公司最後用了Mode6,由於易維護。
關於帶寬的問題,必須2個客戶端向一個服務端同時傳輸才能達到雙網卡帶寬,之前測試mode0的時候遇到過跑不滿的現象,後來就用了mode6。不過是好多年前的事情了,當時應該是CentOS5或6,如今B站用的是 Debian 8,Mode 0 並無發現問題。
問:大家的Redis集羣3.0穩定嗎?
答:Redis 3.0 挺穩定的,它的 Java客戶端會好些,其它語言可能得本身開發。這邊語言不少,有些業務仍是用 Proxy的方式在跑。咱們正在開發一個Cache管理系統,最終會兼容各類方式,將來會開源。
問:BiliTW是 https://github.com/anewhuahua/bilitw 嗎?
答:不是,這個是前同事作的,是基於Twemproxy 改的多進程版本。將來會重構一個新的,放在 https://github.com/bilibili 下面。
問:B站的雲用的多嗎?
答:內部至關因而私有云了,遊戲業務用公有云多些。
歡迎你們投搞:lily.qi@cloudwise.com