實體距離

當應用程式向 COS 提出要求時，它需要跨越一些實體距離。  當此距離增加時，要求的延遲也會增加。 為了減少實體距離所強制的延遲，在可能的情況下，最好將計算資源和物件儲存體並置。 如果您的應用程式在 us-south 地區的 IBM Cloud 中執行，則為了最佳化效能，最好讀取資料並將資料寫入也位於 us-south 地區的儲存區。

使用 IBM Aspera可能會對需要在遙遠的地方存取資料的工作負載有所助益，尤其是在封包流失嚴重的情況下。  如需使用 IBM Aspera High-Speed Transfer 及 COS 的相關資訊，請參閱 Aspera 手冊。

具有全球範圍的應用程式將受益於使用 Content Delivery Network 來將儲存在 COS 中的資產快取到更接近其一般使用者的位置。  原始檔案會繼續在其儲存區中管理，但副本可以快取在全球使用者起始要求的不同位置。

備援需求

部分工作負載可能需要將資料寫入「跨區域」儲存區所隨附的額外備援層次，而其他工作負載則可能依賴在「單一資料中心」儲存區中找到增加的邊際效能。  每一個應用程式都需要在更高可用性與更快效能之間取得平衡。

使用「跨區域」端點時，可以將入埠資料流量導向至特定存取點，同時仍將資料分散在所有三個區域中。 將要求傳送至個別存取點時， 如果該地區變成無法使用，則不會自動失效接手。 將資料流量導向存取點而非 geo 端點的應用程式 必須 在內部實作適當的失效接手邏輯，以達到跨地區儲存體的可用性優點。

使用存取點的一個原因是控制資料進入和輸出的位置，同時仍將資料分散在最廣泛的可能區域。 假設在 us-south 地區中執行的應用程式，想要將資料儲存在美國跨地區儲存區中，但想要確保所有讀取及寫入要求都保留在達拉斯區域中:

1. 應用程式會使用 https://s3.private.dal.us.cloud-object-storage.appdomain.cloud 端點來建立用戶端。
2. 達拉斯的 COS 服務中斷。
3. 應用程式偵測到嘗試使用存取點時持續失敗。
4. 應用程式會辨識需要失效接手至不同的存取點 (例如聖荷西)。
5. 應用程式會使用 https://s3.private.sjc.us.cloud-object-storage.appdomain.cloud 端點來建立新的用戶端。
6. 連線功能已回復，且在服務還原時可以重新遞送存取權至達拉斯。

相反，請想像另一個使用一般美國跨地區端點的應用程式:

1. 應用程式會使用 https://s3.us.cloud-object-storage.appdomain.cloud 端點來建立用戶端。
2. 達拉斯的 COS 服務中斷。
3. 所有 COS 要求都會自動重新遞送至 San Jose 或 Washington ，直到服務還原為止。

網路類型

導向至 COS 的資料流量可以來自下列三個網路之一:「公用」、「專用」或「直接」。 目標網路是由用來存取儲存區的 COS 服務端點所定義。 當儲存區建立在單一位置 (例如跨區域、區域或單一站台) 時，仍然可以透過說明的三種網路類型中的任何一種來存取該相同的儲存區。

公用資料流量會遍訪公用網際網路，直到它到達 IBM Cloud ，並遞送至將資料流量導向至 COS 分散式儲存網路的負載平衡器。 專用資料流量源自 IBM Cloud ，且永不接觸公用網際網路。  直接資料流量源自可同時包含本端資料中心及 IBM Cloud 資源的 Virtual Private Cloud。 此架構需要 IBM Direct Link，並容許使用者從使用者的資料中心 (使用反向 Proxy) 直接連接至 Private IBM Cloud 網路，而無需接觸公用網際網路。

因為「專用網路」會消除在「公用網際網路」中找到的任何變異、壅塞或漏洞，所以建議所有工作負載盡可能使用「專用網路」。