探索試驗階段

  • 20 分鐘

試驗可以平行執行，以進行專案規劃與準備。 這個階段也可以用來測試規劃和準備階段中所識別的選項。 在試驗過程中，建議您設定和驗證完整 HA/DR 解決方案以及安全性設計。 在某些情況下，您也可以使用這個階段來執行可擴縮性測試或部署 SAP 沙箱系統。 若要執行試驗，客戶應該先識別想要遷移至 Azure 的非關鍵性系統，然後執行下列工作以繼續進行：

1. 將對 Azure 進行的資料傳輸最佳化

方法和結果高度依賴客戶對 Azure 的連線能力。 視資料量而定，您可能可以針對 ExpressRoute、站對站 VPN 或離線資料傳輸服務等目的來使用，例如 Azure 資料箱或 Azure 匯入/匯出服務。

2.SAP 異質平台移轉

如果是涉及匯出和匯入資料庫資料的 SAP 異質平台移轉，請對匯出和匯入階段進行測試和最佳化。 如果是以 SQL Server 為目標的大型異質移轉，請參閱 SAP OS/DB Migration to SQL Server–FAQ。 如果您不需要將移轉與發行升級或 SAP 資料庫移轉選項 (DMO) 合併，則可以使用移轉監視/SWPM。 如需詳細資訊，請參閱 Database Migration Option (DMO) of SUM – Introduction。 在任一種情況下，請使用下列步驟：

  • 測量從來源匯出、將匯出的內容上傳至 Azure 並執行匯入的時間。 將匯出與匯入之間的重疊最大化。
  • 使用來源與目標資料庫之間的比較，以適當地調整目標基礎結構的大小。
  • 對時機進行驗證和最佳化。

3. 執行技術驗證

虛擬機器類型

  • 參考 SAP 支援附註、SAP Hana 硬體目錄和 SAP 產品可用性矩陣 (PAM)，以確保有關支援的 Azure 虛擬機器 SKU、這些 Azure 虛擬機器 SKU 的支援 OS 版本，以及支援的 SAP 和 DBMS 版本的資訊準確性。
  • 驗證您在 Azure 中部署的基礎結構和應用程式元件大小。 在遷移現有的應用程式時，您應該能夠根據現有的遙測來取得必要的 SAP。 擷取 SAP 基準，並將其與 SAP 附註編號 1928533 中列出的 SAPS 編號進行比較。 此外，請參考 Azure 虛擬機器上的 SAPS 評級 – 在哪裡查看以及在哪裡可能會感到困惑中所提供的資訊。
  • 就您在規劃階段中所選擇不同虛擬機器類型的儲存體輸送量和網路輸送量上限，評估及測試您 Azure 虛擬機器的調整大小。 您可以在 Azure 中虛擬機器的大小中找到此資料。 當 Azure 虛擬機器客體作業系統為 Windows 時，請務必考慮用於調整大小的最大未快取磁碟輸送量。 如果是 Linux，考慮用於調整大小的最大未快取磁碟輸送量也很重要。

儲存體

  • 針對代表 SAP 應用程式層的虛擬機器以及非效能敏感性 DBMS 部署的虛擬機器，至少使用 Azure 標準 SSD 儲存體，並且針對效能敏感性的任何 DBMS 虛擬機器使用 Azure 進階儲存體。
  • 避免使用 Azure 標準 HDD 磁碟。
  • 使用 Azure 受控磁碟。
  • 透過 M 系列 Azure 虛擬機器將「Azure 寫入加速器」用於 DBMS 記錄磁碟機。 請留意記錄的寫入加速器限制和使用量限制。
  • 如需 DBMS 相關的儲存體資訊，請參閱適用於 SAP 工作負載的 Azure 虛擬機器 DBMS 部署考量，以及該文件所參考的 DBMS 具體文件。
  • 針對 SAP Hana 部署，請參閱 Azure 上的 SAP Hana 基礎結構設定和作業。
  • 切勿使用裝置識別碼將 Azure 資料磁碟掛接至 Azure Linux 虛擬機器。 反之，請使用全域唯一識別碼 (UUID)。 當您使用圖形工具來掛接 Azure 資料磁碟時，請務必小心。 請仔細檢查 /etc/fstab 中的項目，以確定磁碟是使用 UUID 進行掛接。 如需詳細資訊，請參閱連線到 Linux 虛擬機器以掛接新磁碟。

網路

測試和評估您的虛擬網路基礎結構，並在 Azure 虛擬網路中散發您的 SAP 應用程式。

  1. 根據下列準則，評估單一 Azure 虛擬網路內，中樞與輪輻虛擬網路架構或微分割的方法：

    • 對等互連 Azure 虛擬網路之間的資料交換費用 (如需詳細資訊，請參閱 Azure 虛擬網路定價)。
    • 當虛擬網路的子網路中裝載的應用程式或虛擬機器變成安全性風險時，比較終止 Azure 虛擬網路與使用 NSG 之間的對等互連，與在虛擬網路內隔離子網路之間的能力。
    • 集中記錄和稽核內部部署、網際網路和 Azure 虛擬資料中心之間的網路流量。

  2. 評估和測試 SAP 應用程式層與 SAP DBMS 層之間的資料路徑。 在您的評估過程中，請考量下列項目：

    • 不支援在 SAP NetWeaver、Hybris 或 S/4HANA 型 SAP 系統的 SAP 應用程式與 DBMS 層之間的通訊路徑中放置任何網路虛擬設備。
    • 不支援將 SAP 應用程式層與 SAP DBMS 放置在未對等互連的不同 Azure 虛擬網路中。
    • 支援使用 Azure 應用程式安全性群組 (ASG) 和網路安全性群組 (NSG)，來控制 SAP 應用程式層和 SAP DBMS 層之間的流量流動。

  3. 請確保在 SAP 應用程式層和 SAP DBMS 層所使用的虛擬機器上已啟用 Azure 加速網路。 請記住，在 Azure 中支援加速網路的 OS 需求：

    • Windows Server 2012 R2 或更新版本
    • SUSE Linux 12 SP3 或更新版本
    • RHEL 7.4 或更新版本
    • Oracle Linux 7.5。 RHCKL 核心需要 3.10.0-862.13.1.el7 版。 Oracle UEK 核心需要第 5 版。

  4. 請根據 SAP 附註編號 500235 和 SAP 附註編號 1100926，測試和評估 SAP 應用層虛擬機器與 DBMS 虛擬機器之間的網路延遲。 依據 SAP 附註編號 1100926 的網路延遲指引來評估結果。 網路延遲應該在適中到良好的範圍內。

  5. 確定將 Azure 內部負載平衡器 (ILB) 部署設定成使用「伺服器直接回傳」。 當 ILB 用於 DBMS 層的高可用性設定時，此設定會減少延遲。

  6. 如果您將 Azure Load Balancer 和 Linux 客體作業系統結合使用，請確認 Linux 網路參數 net.ipv4.tcp_timestamps 設定為 0。 請注意，這與 SAP 附註編號 2382421 的一般建議衝突。 SAP 附註已更新，以反映參數必須設定為 0 才能與 Azure 負載平衡器搭配運作的事實。

高可用性和災害復原部署

  • 如果您部署 SAP 應用程式層，但是未以特定 Azure 可用性區域為目標，請確定所有執行 SAP 對話執行個體的虛擬機器或相同 SAP 系統的中介軟體執行個體都部署在相同的可用性設定組中。

    • 如果您不需要 SAP Central Services 和 DBMS 的高可用性，則可以將這些虛擬機器部署至與 SAP 應用程式層相同的「可用性設定組」中。

  • 如果您需要保護 SAP 中央服務和 DBMS 層以使用被動複本取得高可用性，請在一個可用性設定組中部署 SAP 中央服務的兩個節點，並在另一個可用性設定組中部署兩個 DBMS 節點。

  • 如果您部署至「Azure 可用性區域」，則無法使用「可用性設定組」。 反之，您應該確保將主動和被動中央服務節點部署至兩個不同的可用性區域，以提供區域之間的最小延遲。

  • 請記住，為跨可用性區域的 DBMS 和 SAP 中央服務層建立 Windows Server 或 Pacemaker 型容錯移轉叢集時，您需要使用 Azure Standard Load Balancer。 基本負載平衡器不支援區域部署。

逾時設定

  • 查看 SAP 執行個體的 SAP NetWeaver 開發人員追蹤，並確定當中未指出排入佇列伺服器與 SAP 工作程序之間有發生任何連線中斷情況。 您可以透過設定下列兩個登錄參數，來避免這些連線中斷情況。

    • HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveTime = 120000. 如需詳細資訊，請參閱 KeepAliveTime。
    • HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\KeepAliveInterval = 120000。 如需詳細資訊，請參閱 KeepAliveInterval。

  • 為了避免內部部署 SAP GUI 介面與部署在 Azure 中的 SAP 應用程式層之間發生 GUI 逾時，請在 default.pfl 或執行個體設定檔中設定下列參數：

    • rdisp/keepalive_timeout = 3600
    • rdisp/keepalive = 20

  • 如果您使用 Windows 容錯移轉叢集，請確定已正確設定用來判斷未回應節點所觸發容錯移轉的參數。 Microsoft TechCommunity 的 Tuning Failover Cluster Network Thresholds 一文中列出了各種參數，以及這些參數對容錯移轉行為的影響。 例如，假設叢集節點位於相同的子網路中，請務必以下列方式設定容錯移轉參數：

    • SameSubNetDelay = 2000

    • SameSubNetThreshold = 15

    • RoutingHistorylength = 30

    • 測試高可用性和災害復原程序：

      • 藉由關閉 Azure 虛擬機器 (Windows 客體作業系統) 或讓作業系統進入異常模式 (Linux 客體作業系統) 來模擬容錯移轉。

      • 測量完成容錯移轉所需的時間。 如果花費的時間太長，請考慮：

        • 針對 SUSE Linux，使用 SBD 裝置 (而不是 Azure 隔離代理程式) 來加速容錯移轉。
        • 針對 SAP Hana，如果重新載入資料花費的時間太長，請考慮改善儲存體效能。

      • 測試備份/還原順序和時間及微調 (視需要)。 請不只確定備份時間是否足夠。 也請測試還原，並了解還原活動的時間。 請確保還原時間在您的 RTO SLA 內，其中 RTO 會取決於資料庫或虛擬機器流程。

      • 測試 DR 功能和架構。

4. 執行安全性檢查

  • 測試您所實作 Azure 角色型存取 (RBAC) 方法的有效性。 目標是要對委派給不同小組的存取和權限進行區分和限制。 舉例來說，SAP 基礎小組成員應該要能夠將 Azure 虛擬機器部署到指定 Azure 虛擬網路，並將磁碟指派給這些 Azure 虛擬機器。 不過，SAP 基礎小組不應該能夠建立新的虛擬網路，或變更現有虛擬網路的設定。 相反地，網路小組的成員則不應該能夠將 Azure 虛擬機器部署至 SAP 應用程式和 DBMS 虛擬機器執行所在的虛擬網路中。 網路小組的成員也不能變更虛擬機器的屬性，或刪除虛擬機器及其磁碟。
  • 確認 NSG 規則如預期般運作，並防護受保護的資源。
  • 確認待用加密和傳輸中加密。 定義和實作備份、儲存和存取憑證的程序，以及驗證加密實體的還原程序。
  • 針對 OS 磁碟使用 Azure 磁碟加密。
  • 在決定是否要實作加密機制時，請考慮使用實用的方法。 例如，評估是否需要同時套用 Azure 磁碟加密和 DBMS 透明資料庫加密。

5. 測試效能

在移轉案例中，請使用 SAP 追蹤和測量，以根據下列項目來比較試驗與目前的實作：

  • 前 10 個線上報告
  • 前 10 個批次作業
  • 透過介面將資料傳輸到 SAP 系統，著重於跨單位流量