| <![CDATA[<cite id="jscwd"><track id="jscwd"></track></cite>]]>
|
|
| |
|
|
|
谷歌云為服務(wù)器添加了內(nèi)存，重新啟動服務(wù)器，眼睜睜看著情況變得更糟糕……所幸現(xiàn)在重新掌握了局面。
發(fā)生在3月26日的那次故障導(dǎo)致谷歌在多個地區(qū)的云服務(wù)癱瘓，包括Dataflow、Big Query、DialogFlow、Kubernetes Engine、Cloud Firestore、App Engine和Cloud Console。這些系統(tǒng)受影響的時間總共長達14個小時。
許多云服務(wù)依賴身份和訪問管理（IAM）中的分布式訪問控制列表（ACL）來驗證權(quán)限、激活新的API或創(chuàng)建新的云資源。這些權(quán)限存儲在一個分布式數(shù)據(jù)庫中，被大量緩存起來。兩個進程確保數(shù)據(jù)庫內(nèi)容最新：一個是實時進程，一個是批處理進程。然而，如果實時管道遠遠落在后面，提供的會是過時數(shù)據(jù)，這可能導(dǎo)致下游服務(wù)的操作受到影響。
據(jù)谷歌最近發(fā)布的一項內(nèi)部調(diào)查顯示，故障是該公司的緩存服務(wù)器內(nèi)存不足導(dǎo)致的。調(diào)查稱：“觸發(fā)這起事件的誘因是批量更新組成員（group membership ），結(jié)果修改后權(quán)限的數(shù)量增加到了超出預(yù)期的程度，因而生成了大量積壓的隊列突變（queued mutation）需要實時生效?！?/section>
“由于緩存服務(wù)器存在一個潛在的問題，處理積壓的隊列突變的能力下降，這導(dǎo)致緩存服務(wù)器內(nèi)存不足；而這反過來又導(dǎo)致對IAM的請求超時中斷。為了緩解內(nèi)存使用量高企而執(zhí)行的緊急部署措施在各個地區(qū)更是短暫加劇了這個問題?！?/section>
谷歌通過在緩存服務(wù)器中安裝更多的內(nèi)存并重新啟動服務(wù)器解決了該問題。但是到這個時候，已積累了一大堆過時的數(shù)據(jù)，這導(dǎo)致了進一步的問題，系統(tǒng)工程師不得不另花費幾個小時來處理。第二天早上05點55分，系統(tǒng)恢復(fù)正常運行。
谷歌表示，為了應(yīng)對這些問題，它“現(xiàn)在確保緩存服務(wù)器可以處理引發(fā)這起事件的那種批量更新”，并且“正在努力優(yōu)化緩存服務(wù)器上的內(nèi)存使用和保護機制，在無需重新啟動的情況下面對緊急情況時可以進行配置變更?！?/section>
“為了讓我們將來可以更迅速地應(yīng)對數(shù)據(jù)過時問題，我們還將對數(shù)據(jù)庫批處理進行切分處理，以便支持并行化和更頻繁的運行。我們明白區(qū)域可靠性對我們的用戶來說有何等重要，并為該事件表示歉意?！?/section>
故障報告鏈接：https://status.cloud.google.com/incident/zall/20003#20003014
旺旺客服
-
速度網(wǎng)絡(luò)服務(wù)商
絡(luò)服務(wù)商&site=cntaobao&s=1&charset=utf-8)
電子郵箱
-
sudu@yunjiasu.cc
