免責聲明

以下內容旨在概述 Oracle 產品之大致方向,僅供參考之用,不得納入任何合約之中;且該等內容並非交付任何材料、程式碼或功能之承諾,不應作為採購決策之依據。Oracle 擁有對於前述任何 Oracle 產品功能之開發、發行、時間與價格安排之單方決定/變更權。

這份常見問題針對 Oracle 如何讓核心基礎架構服務與代管平台實現抗逆力和持續可用性,提供相關的解答。Oracle Cloud 的客戶可能會對這些解答感興趣,因為:

  • 有助於客戶評估 Oracle 的代管平台與服務時,進行詳細調查。
  • 許多解答都討論了對所有雲端規模系統而言相當重要的挑戰和解決方案,因此可針對客戶想要在雲端建置的系統架構和設計提供資訊。

Oracle Cloud Infrastructure 服務與平台抗逆力和持續可用性的常見問題

Oracle 是否會區分不同類別的服務,例如關鍵服務、持續可用的服務或單一位置服務?

這並不是我們採用的區分方式。我們是依相依性層次、可用性範圍以及資料層與控制層將服務分類。這些類別的設計目的是要在可用性、持久性、效能及便利性之間,提供各種實用的權衡取捨。

相依性層次

您可以將這些層次視為架構區塊圖中的階層或分層。每一層只依存於底下的其他層。

由下而上的各層分別為:

  • 核心服務:這些服務構成 Oracle Cloud Infrastructure 的基礎。包括身分識別與存取管理 (IAM)、金鑰管理、網路、運算、區塊磁碟區、物件儲存、遙測及數個共用的內部服務。這些服務被設計成即使在彼此之間,也僅擁有最低限度的相依性。(如需有關相依性的詳細資訊,請參閱本文件的後續部分。)
  • IaaS:這一層建置在核心服務之上,提供更多基礎架構層次的功能。這一層的服務包括檔案儲存、資料庫及 Kubernetes 的容器引擎。
  • SaaS:這一層建置在各低層之上,提供豐富的軟體即服務。
可用性範圍

為了達成服務的可用性與持久性目標,每項服務適用下列其中一個可用性範圍:

  • 可用性網域本機:每個可用性網域都包含一個獨立的服務執行處理。這類服務會藉由在同一可用性網域內的複本之間使用同步複寫 (如需詳細資訊,請參閱本文件稍後有關容錯域的小節),提供已儲存資料的高持久性。視服務的本質而定,這些服務可以忍受可用性網域中三分之一或甚至更多基礎架構發生中斷的情形。可用性網域本機服務藉由在可用性網域內使用兩種不同類型的邏輯資料中心,也就是錯誤隔離與效能隔離邏輯群組,在此層次達到容錯目標。如需詳細資訊,請參閱本文件後續有關容錯域與服務單元的小節。最終即使可用性網域無法與任何其他可用性網域進行通訊,這些服務仍能繼續如常運作。因此它們可忍受無法與其他可用性網域通訊,或區域內的廣域網路完全故障。
  • 多個可用性網域區域:每個具有多個可用性網域的區域都包含一個獨立的服務執行處理,其中元件都位於該區域中的每個可用性網域內。這些服務會在同一區域中的多個可用性網域之間同步複寫,讓已儲存資料的持久性非常高。這些服務可以忍受區域中任何單一可用性網域發生中斷,或無法與區域中的任何單一可用性網域進行通訊。
  • 單一可用性網域區域:如果區域只包含單一可用性網域,則區域服務的可見特性會與稍早所述可用性網域本機服務的特性相符。只有單一可用性網域區域透過新增一或多個可用性網域進行擴充時,可用性網域本機服務與單一可用性網域區域服務之間的區別才會變得相關。當發生該情況時,每個區域服務會自動擴充以適當地使用新的可用性網域,同時仍維持為單一服務執行處理。例如,物件儲存資料層會擴充以使用額外的可用性網域,即可提升現有資料的持久性。就可用性網域本機服務而言,每個新可用性網域則會收到自己的每個可用性網域本機服務新的個別執行處理。
  • 分散在各個區域:Oracle Cloud Infrastructure 的基本原則是每個區域在操作上儘可能與其他區域各自獨立。限定為可能反映了一個事實,就是區域至少共用了某些基礎架構,例如區域間的骨幹網路。我們不會在區域之間建立緊密耦合機制 (例如通透式高可用性或容錯移轉),該機制可能會造成同時影響多個區域的問題。而改為提供兩個機制,以鬆散耦合的方式將服務分散在各個區域:
    • 災害復原 (DR):讓客戶打造具有災害復原特性的系統,是雲端策略與投資的基石。數個核心服務已經提供災害復原機制,例如區塊磁碟區的區域間備份和物件儲存的區域間複製。我們的所有服務藍圖都以災害復原功能作為高優先順序項目。
    • 區域間訂閱:我們目前僅針對 IAM 資料提供區域間訂閱。在概念上,IAM 資料屬全域範圍。客戶可以訂閱 (選擇加入) 一組區域,系統會自動將相關的 IAM 資料及後續更新複寫至指定的區域。為了避免緊密耦合,複寫是以非同步方式進行,並最終達到一致。客戶對他們所指定「主要」區域中的 IAM 資料進行修改。如果目前的主要區域因某種原因而變得無法使用或不適用,則可以指定其他區域。
控制層與資料層

服務的資料層是資料處理介面和元件的集合,此集合將導入應用系統所需的服務功能。例如,虛擬雲端網路 (VCN) 資料層包含網路封包處理系統、虛擬化路由器及閘道,而區塊磁碟區資料層則包含 iSCSI 協定的導入,以及適用於磁碟區資料的容錯複寫儲存系統。

服務的控制層是一組負責下列工作的 API 和元件:

  • 處理客戶對佈建、重新設定、縱向擴展/縮減或終止資源的要求
  • 以快速且安全的方式執行大型機組的自動化打補丁
  • 偵測失敗、效能降低或設定錯誤的資源
  • 執行自動化修復,或呼叫人工操作員以取得協助
  • 與其他控制層協同合作 (例如運算、VCN、區塊儲存會在 LaunchInstance 時一起運作)
  • 管理未使用的容量
  • 協調人力,例如新設備抵達及進行實際的修復與維護時
  • 提供操作可見性和控制
 
 

Oracle 如何確保服務具有復原能力且持續可用?

針對所有類型的服務,我們使用一組相同的工程原則來達到抗逆力和可用性,因為對於所有類型的服務來說,建置容錯、可擴展分散式系統的基本工程挑戰都相同。

為了達到抗逆力和持續可用性,必須先瞭解雲端規模系統中所有導致無法使用的原因 (例如效能降低和無法處理失敗情況),然後加以處理。這類原因的數量龐大,因此我們根據原因的本質加以分類。

傳統上,企業 IT 系統的可用性分析是將焦點放在硬體故障類別。對雲端系統來說,硬體故障是相對較不嚴重且已詳細探討的問題。因此現在要避免或降低大多數單點硬體故障的風險已相對簡單。例如,機架可使用雙電源供電和關聯的電源分配器,同時許多元件都可進行熱插拔。大規模硬體故障和遺失當然可能,例如因為天然災害。不過,我們的經驗及來自其他雲端供應商的公開檢討報告顯示,相對於其他導致無法使用的原因,整個資料中心的故障或遺失為罕見。大規模硬體故障仍然必須處理 (例如運用災害復原及其他機制),但它不算是主要的可用性問題。

對雲端規模系統造成無法使用的主要原因如下:

  1. 軟體錯誤
  2. 組態錯誤
  3. 人工操作員所犯的錯誤
    注意:業界的經驗認為,以上三種人為錯誤顯然是造成無法使用的主要原因。雖然透過工具、自動化及訓練可以降低發生頻率,但卻無法加以消除。因此必須在系統的架構、設計及導入中,視為主要考量並加以處理。
  4. 效能 (延遲或傳輸量) 因任何原因而產生無法接受的變異,包括下列各項:
    • 多租用戶被「其他客戶干擾」(QoS 機制失靈)
    • 持續進行有用的工作時,無法有效率地拒絕超載 (意外或惡意)
    • 分散式超負荷執行、訊息風暴、重試風暴及其他突然出現的耗費資源互動方式
    • 重新開機 (特別是多個系統同時重新開機) 後的冷休克 (空白快取)
    • 調整系統規模 (例如重新分區) 時的額外負荷
  5. 無法限制上述任何問題的影響範圍 (受影響客戶和系統的數目)

這些挑戰普遍存在,就像是雲端規模分散式系統的「物理定律」一樣。

針對上述每個類別,我們透過經實證的工程策略來處理問題。這些當中最重要的是:

  • 架構與系統設計的原則
  • 新的架構概念 (通常是因套用上述原則而產生)
  • 服務工程程序
架構與系統設計的原則

這些原則當中許多早已存在,我們把焦點放在與抗逆力和可用性最相關的原則。

復原導向運算

為了處理操作員對局部影響的軟體錯誤和人為失誤,我們依照復原導向運算1 的原則處理。概要來說,這意謂我們不會保證永遠不會發生問題 (無法測試),而是將焦點放在以可測試的方式低調處理任何問題。具體來說,焦點會放在將平均復原時間 (MTTR) 縮到最短,這段時間包括平均偵測時間、平均診斷時間及平均降低風險時間。

我們的目標是迅速復原,讓人員不會因問題而感到不便。下列幾點有助於達成這個目標:

  • 在程式碼中普遍使用宣告,以及在所有層次主動監控並發出警訊,可快速且自動偵測操作員發生錯誤的徵兆。
  • 將功能封裝成許多鬆散耦合的個別精細隔離單位 (繫線、處理作業、纖維、狀態機器等);也就是說,它們並不直接共用可能損毀的記憶體。
  • 偵測操作員發生錯誤的徵兆時,自動儘快重新啟動封閉的隔離單位。重新啟動是一種嘗試從任意故障情況復原的實用方法,因為它會嘗試重新建立已經過妥善測試的狀態,所以可以回復不變的項目。
  • 如果精細隔離層次復原沒有發揮作用 (例如,宣告繼續在該層次過度頻繁地觸發而導致旋轉當機),便提升至下一個更大的單位 (處理作業、程式實際執行、主機、邏輯資料中心、呼叫人工操作員)。
  • 建立機制來啟用「全系統還原」(包括所有持續性狀態和組態的版本控制),以快速識別並還原錯誤的確認。

將問題的影響降到最低

為了處理影響較為廣泛的錯誤,我們會建立機制將任何問題的影響範圍縮減到最小。也就是說,我們的焦點放在將受任何問題影響的客戶、系統或資源數目降到最低,這些問題包括一些特別具挑戰性的問題,例如多租用戶被「其他客戶干擾」、提供的超載、處理能力降低,以及分散式超負荷執行。我們會透過使用各種隔離界限和變更管理做法 (請參閱下列各節) 來達到此目的。

由設計原則產生的架構概念

這些概念當中許多早已存在,我們把焦點放在限制影響範圍的概念。

深深刻劃在公用 API 的佈局概念:區域、可用性網域及容錯域

由於容錯域觀念相對較為新穎,我們將以更詳細的方式說明容錯域。

容錯域可用來限制系統進行主動變更時所發生問題的影響範圍,這類主動變更包括:部署、打補丁、虛擬機器管理程式重新啟動及實體維護。

系統可保證在指定的可用性網域中,任一時間點最多只會變更一個容錯域中的資源。如果在變更過程中發生問題,則該容錯域中的部分或全部資源可能會一時無法使用,但可用性網域中的其他容錯域則不受影響。每個可用性網域都至少包含三個容錯域,以便允許在單一可用性網域內,以高可用性方式代管法定型複寫系統 (例如 Oracle Data Guard)。

因此針對主要類別的可用性問題 (軟體錯誤、組態錯誤、操作員失誤,以及變更程序期間發生的效能問題),每個容錯域都可作為可用性網域內個別的邏輯資料中心。

容錯域也可以防止某些類型的局部硬體故障。容錯域的特性會以最大的實際程度,保證放在不同容錯域中的資源不會在可用性網域內共用任何潛在的單點硬體故障。例如,不同容錯域中的資源不會共用同一個「機架頂端式」網路交換器,因為這類交換器的標準設計缺少備援。

不過,容錯域對硬體問題或實體環境問題的防護能力僅止於本機層次。與可用性網域和區域對比之下,容錯域並未提供任何大規模的基礎架構實體隔離。在天然災害或全可用性網域基礎架構故障等罕見案例中,多個容錯域中的資源可能會同時受到影響。

我們內部服務使用容錯域的方式與客戶的使用方式相同。例如,區塊磁碟區、物件儲存及檔案儲存服務會將資料複本儲存在三個不同的容錯域。所有控制層和資料層的所有元件都由這三個容錯域 (或多重可用性網域區域、多個可用性網域) 代管。

服務單元

服務單元可用來限制發生問題 (甚至是系統未進行主動變更) 時的影響範圍。之所以會發生這類問題,是因為多租用戶雲端系統的工作負載可能隨時發生劇變,也因為任何大型分散式系統都可能隨時發生複雜的局部故障。這些案例可能觸發隱藏的細微錯誤或突然出現的效能問題。

服務單元也可以在系統進行主動變更時的某些罕見但具挑戰性的案例中,限制問題的影響範圍。其中一個經典的範例是,部署至個別容錯域雖顯示成功 (沒有任何錯誤或效能變更),但在第二個或最後一個容錯域更新之後,系統 (具有生產環境工作負載的完整雲端規模) 內的新互動立即造成效能問題。

請注意,使用服務單元是一個架構模式,並非 Oracle Cloud API 或 SDK 中明確指定的概念。任何多租用戶系統都可以使用此架構模式;它並不需要雲端平台的特殊支援。

服務單元的運作方式如下:

  • 每個服務執行處理 (例如在特定區域中,或在可用性網域本機服務的特定可用性網域中) 都是由服務軟體堆疊的多個個別部署所組成。每個個別的部署稱為一個單元。每個單元都會儘可能由其自己的基礎架構代管。至少要讓單元不共用主機或 VM。
  • 服務在每個可用性網域或區域中一開始可能只有少數幾個單元。隨著服務擴展規模以滿足增加的需求,將新增更多單元以維持任何問題影響範圍大小的限制。大型的熱門服務可能會有許多單元。換句話說,單元提供 n 對 m 的客戶工作負載多工處理,以便區隔代管環境 — 區隔資源隔離島。單元沒有像針對容錯域存在的明顯基數。(如先前提到的,容錯域基數的明顯選擇是每一可用性網域三個容錯域,這讓單一可用性網域以高可用性方式代管法定型複寫系統。)
  • 每個客戶工作負載「自然單位」都會指定給特定的單元。「自然單位」的定義取決於特定服務的本質。例如,就我們的內部共用工作流程服務 (稍後將會說明) 而言,自然單位可能是「這個可用性網域或區域中用於特定控制層的所有工作負載」。
  • 在每個單元群組的前面不是簡約的路由層,就是用於探索單元端點的 API。例如,串流處理/訊息傳遞系統具有 API,可探索特定主題的目前資料層端點,而內部描述資料存放區的每一單元則具有一個個別的端點。不過,其他單元型服務則為一個單一資料層端點和一個共用路由層。路由層是多個單元發生關聯性故障的潛在原因,但透過讓路由層維持極度簡單、可預測且高效能 (沒有任何耗費資源的作業),並為其佈建大量的空餘空間容量和精密的 QoS 配額與節流機制,即可降低這項風險。
  • 服務擁有者可以視需要將工作負載從一個單元搬移至另一個單元。以下是一些範例案例:
    • 透過搬移繁重的工作負載,有助於避免多租用戶被「其他客戶干擾」問題,讓單元的其他使用者不受影響。
    • 協助從超載或電壓不足的情況 (可能是由分散式阻斷服務攻擊所造成) 復原。我們以配額和節流機制抵禦這類攻擊,但有時會發生邊緣案例,其中特定使用案例 (API、存取模式) 對服務而言,比配額或節流系統目前所理解的更為費力。單元提供一個短期降低風險的機制。
    • 將關鍵工作負載分成不同的單元,以大幅降低發生關聯性故障的可能性。例如,就控制層的內部共用工作流程而言,「關鍵核心」控制層 (例如平台、運算、網路及區塊磁碟區) 皆個別被指定給不同的單元,因此與不使用單元或指定給相同單元的情況相比,故障關聯性大幅降低。
      注意:這個使用單元的方式可讓客戶不太需要考量服務的內部相依性,即可建置具有復原能力的應用系統。考量相依性圖表仍然是一個很好的做法 (本文件稍後將會進一步說明),但去關聯性機制已經運作時,此做法的需求就大幅降低。

結果就是每個服務單元都是單一可用性網域或區域內另一種類型的「邏輯資料中心」(效能隔離和錯誤隔離的邏輯群組)。

總而言之,服務單元和容錯域以下列方式彼此互補:

  • 容錯域可防止在系統進行主動變更時發生問題。
  • 服務單元可在系統發生潛在嚴重問題時限制問題的影響範圍 (不論系統是否是進行主動變更)。

我們執行部署和打補丁時,會將容錯域與服務單元的特性結合成整合策略。

服務工程程序

由於測試及操作上的優異表現對雲端系統的可靠性至關重要,因此我們有大量的工程程序。以下是一些運用前一節所述概念的重要程序:

  • 我們以遞增方式部署服務,每個步驟之間會仔細進行驗證,並在發生任何意外狀況時立即倒回。具體流程如下:
    • 在每個可用性網域中,我們一次部署至一個服務單元。針對每個單元,我們一次部署至一個容錯域,直到完成該單元的所有容錯域為止。接著,我們會進展到該可用性網域中的下一個單元。
    • 在每個部署步驟之後 (在每個容錯域和單元之後),我們會驗證變更是否如預期般運作,也就是不論是內部或外部,都沒有造成效能降低或任何錯誤。如果發生任何錯誤或意外狀況,我們就會立即倒回變更。我們非常注重倒回程序的準備與測試 (包括自動化測試),這些倒回程序包括會影響持續性狀態或綱要的變更。
    • 基於這個原因,我們採用一次只對一個可用性網域進行部署的方式,將變更部署至每個區域。透過這種方式部署至範圍中的所有區域,使得我們不會同時修改客戶可能用於主要網站和災害復原網站的任何一組區域。
  • 我們會定期確認錯誤處理機制及其他風險降低措施如預期般運作,而不會讓問題大規模惡化。如果沒有這類測試,錯誤處理機制 (例如重試、損毀復原演算法,以及狀態機器重新組態設定演算法) 通常會有錯誤、太耗費資源或以意外方式進行互動,因而造成分散式超負荷執行或其他嚴重的效能問題。
  • 我們會確認能夠快速且安全地倒回上一個已知的良好軟體和組態,包括先前所述的持續性狀態和綱要。
 
 

包含多個可用性網域的 Oracle 區域中,所有關鍵服務是否分散在各個可用性網域?

是,在每個區域中,所有可用性網域都提供一組相同的服務。

 
 

Oracle 及其客戶如何避免讓關鍵服務依存於單一邏輯資料中心?

在單一可用性網域區域中,客戶可以使用容錯域 (在群組間採用去關聯性故障模式的邏輯群組) 實現個別「邏輯資料中心」的絕大多數特性。客戶也可以使用多個區域來進行災害復原 (DR)。

在多重可用性網域區域中,客戶可以透過相同的方式運用容錯域。客戶也可以透過可用性網域本機服務、可用性網域間容錯移轉功能 (例如搭配 Data Guard 的 DBaaS) 及區域服務 (物件儲存、串流處理) 的組合,實現更高層次「邏輯資料中心」(可用性網域) 的完整高可用性。最後,客戶也可以使用多個區域來進行災害復原。

在所有情況下,客戶都可以使用服務單元的概念進一步實行隔離,甚至面對最嚴重的問題 (例如分散式超負荷執行) 也可以這麼做。

 
 

Oracle 如何既進行維護活動又不會讓任何客戶暫時無法使用任何關鍵服務?

我們透過容錯域、服務單元及增量部署與驗證操作程序來達到此目的。請參閱本文件稍早的討論。

 
 

無伺服器平台服務是否會部署至多個邏輯資料中心以獲得更高的可用性?

是,所有類別的服務都會跨多個邏輯資料中心部署,隔開錯誤隔離與效能隔離邏輯群組,以提供抗逆力和持續可用性。

 
 

如果抗逆力不是預設組態,客戶是否可以選擇多重邏輯資料中心部署 (例如多重可用性網域或跨區域組態)?

如同本文件其他地方討論的內容,在單一可用性網域區域中,我們提供容錯域作為「多個邏輯資料中心」的機制。

在多重可用性網域區域中,我們提供的服務和功能提供甚至更高層次的同步複寫資料實體持久性 (由於區域中可用性網域之間的距離,因此可提供適中的效能和成本,以及光速般的速度)。

我們並未提供跨區域的自動高可用性或容錯移轉機制,因為這會在區域之間建立緊密耦合關係,導致多個區域可能同時發生問題的風險。我們改為在區域之間啟用各種形式的非同步複寫,並提供不斷擴增的清單功能 (例如非同步複製與備份),以實現跨區域災害復原。

 
 

Oracle 如何協助客戶避免各種基礎架構與平台服務之間產生內部相依性,而導致應用系統發生關聯性故障?

這是一個複雜的問題,因此為了釐清,我們再以幾個不同方式重新敘述:

  • 如果客戶想要使用兩個 Oracle 服務 (服務 A 和服務 B),並且想要建置能夠在其中一項服務失敗時復原的應用系統,客戶是否需要知道服務 A 是否依存於服務 B?內部相依性是否會導致嚴重的關聯性故障?如果是,則客戶需要知道這類內部相依性,才能在應用系統層次建置自己的抗逆力機制時,決定要對服務 A 和服務 B 做哪些其他利用;或者,是否要改為引進不相關的服務 C 進行這些額外的案例。
  • 若 Oracle 服務發生任何關聯性故障,什麼是客戶的最佳防禦方式?

答案分為兩部分。

架構原則

我們的架構原則可大幅降低各個相依服務的關聯性故障。在某些情況下,此技術會降低關聯性故障的發生率,若從滿足可用性服務層次協議 (SLA) 的角度來看,降低到可以忽略的程度。

特別是,如本文件先前所述,我們使用服務單元。單元可協助處理此問題,因為如果內部服務 A 受到其中一個相依項目服務 B 的問題影響,則服務 B 的問題非常可能被侷限在一個單元內。其他使用服務 B 的更高層次服務 (以及客戶自己的應用系統) 可以使用其他未受影響的單元。這個可能性論點會因單元數目而異,單元數目是會變更 (增加) 的隱藏內部參數,因此除了服務 A 和服務 B 的獨立服務 SLA 之外,並不提供任何量化或保證。但實際上,這可以大幅去除服務間的故障關聯性。

我們的許多共用內部服務 (例如控制層的工作流程和描述資料服務,以及串流處理/訊息傳遞服務) 都使用服務單元,去除中斷情況關聯性,供上游服務加以運用。

相依性

以下是概要指引,因為服務的詳細導入與詳細資訊可能不時會發生變更。但針對運算、儲存、網路及認證/授權的主要觀點,我們會指出下列相依性。

就控制層而言,常見的相依性如下:

  1. 認證和授權的身分識別/平台資料層
  2. 稽核追蹤服務
  3. 提供諸如工作流程、描述資料儲存及日誌記錄的內部服務
  4. 各種類型的負載平衡器

有些控制層明顯具有服務特定相依性。例如,啟動裸機或 VM 執行處理時,運算控制層會依存於:

  • 物件儲存 (用以擷取指定的作業系統映像檔)
  • 區塊磁碟區控制層 (用於佈建和連附開機磁碟區)
  • 網路控制層 (用於佈建和連附 VNIC)

針對核心服務資料層,一般原則是每個資料層皆刻意設計成具有最小相依性,以便實現高可用性、快速診斷及快速復原。該原則的結果如下:

  • 獨立的網路資料層。
  • 獨立的區塊磁碟區資料層。
  • 運算裸機和 VM 執行處理依存於區塊磁碟區資料層 (用於開機磁碟區) 和網路資料層。
  • 物件儲存資料層依存於身分識別/平台資料層,用於認證和授權 (因為業界的期望)。物件儲存資料層不依存於區塊磁碟區或檔案儲存。
  • 所有支援備份和回復的服務都依存於物件儲存資料層,以運用該功能。

針對 IaaS 資料層,一般原則是只依存於核心或更低層次的資料層 (為了避免循環相依性)。

  • 資料庫多節點 RAC 依存於網路資料層和區塊磁碟區資料層。
  • Kubernetes 的容器引擎明顯依存於 Kubernetes 及其可轉移相依性 (例如 etcd) 和網路資料層。
  • 所有備份和回復支援都依存於物件儲存資料層。

1來自 Stanford 和 Berkeley 的公開研究計畫,由 Armando Fox 和 Dave Patterson 主持

 
×
立即撥打電話給我們
1-800-633-0738 (美國)

聯絡我們
×
立即撥打電話給我們
1-800-633-0738 (美國)


Oracle Cloud 討論論壇