SAP HANA を Compute Engine ベアメタル インスタンスに移行する

このドキュメントでは、SAP HANA ワークロードを Compute Engine ベアメタル マシンタイプ(X4 と C3 で使用可能)に移行する手順の概要について説明します。また、Google Cloud で推奨される移行方法についても説明します。

このドキュメントは、SAP HANA の実行に精通しており、SAP HANA ワークロードを Google Cloud の Bare Metal インスタンスに移行する SAP Basis 管理者と SAP システム管理者を対象としています。

Google Cloud で SAP HANA を実行するために SAP が認定しているベアメタルマシンタイプについては、SAP HANA のベアメタルマシンタイプをご覧ください。

移行手順の概要

オンプレミス、他のクラウド プロバイダ、Compute Engine のメモリ最適化 VM、Bare Metal Solution サーバーで実行されている SAP HANA ワークロードを移行できます。

SAP HANA ワークロードを C3 または X4 ベアメタル マシンタイプに移行するには、以下の手順を行います。

  1. SAP HANA ワークロードの移行の準備状況を評価します。これには、OS バージョン、SAP HANA バージョン、システム構成、ワークロードで使用されるサードパーティ製プロダクトまたはサービスの互換性、高可用性(HA)と障害復旧(DR)の構成などの要素の評価が含まれます。

  2. 移行方法を選択します。SAP HANA ワークロードの要件と、使用しているインフラストラクチャに基づいて、最適な移行方法を選択する必要があります。詳細については、移行方法を選択するをご覧ください。

  3. 非本番環境で移行をテストして検証します。SAP HANA ワークロードの移行がワークロードのパフォーマンスやデータの完全性に悪影響を与えないようにするには、選択した移行方法を本番環境以外で徹底的にテストして検証する必要があります。

  4. ワークロードの移行を準備します。これには、データベースのバックアップの作成、ダウンタイムの計画、必要なすべてのライセンスとツールがあることの確認、ターゲット システムのライセンス キーの更新などのタスクが含まれます。

  5. ワークロードを移行します。選択した移行方法を使用して、SAP HANA ワークロードを必要なタイプのベアメタル インスタンスに移行します。このステップでは、システムのレプリケーション、データ転送、カットオーバー アクティビティを実行できます。

  6. ワークロードをテストして検証します。SAP HANA ワークロードがベアメタル インスタンスに正常に移行されたら、ワークロードをテストして検証し、想定どおりに実行されていることを確認します。

移行方法を選択する

SAP HANA ワークロードに選択する移行方法は、ワークロードの要件、ワークロードが Google Cloud で実行されているかどうか、使用しているインフラストラクチャ、システム構成(スケールアップまたはスケールアウト)などの要因によって異なります。

次のフローチャートは、SAP HANA ワークロードに最適な移行方法を見つけるために検討する一連の質問を示しています。

SAP HANA の Compute Engine ベアメタル マシンタイプへの移行方法を選択する方法を示すフローチャート

移行方法を選択する方法

  • 次のいずれかの条件に該当する場合は、移行方法の設計について Google Cloud の担当者に問い合わせることを強くおすすめします。
    • Google Cloud を初めて利用する場合。
    • SAP HANA ワークロードはスケールアウト構成を使用します。
    • SAP HANA ワークロードに複雑な要件がある場合(次に例を示します)。
      • 移行とカットオーバーの期間が非常に短い場合。
      • 高度なネットワーク要件がある場合(特に、移行に適した有効な帯域幅で移行元の環境から接続する必要がある場合)。
      • ワークロードの負荷プロファイルを変更している場合。たとえば、新しい機能をロールアウトする場合や、新しいユーザーを追加する場合です。
      • 追加のアプリケーション サーバーのデプロイやインターフェースの変更など、複数のインフラストラクチャの側面を変更する場合。
      • 複数のシステムを同時に移行する場合。
  • マシンタイプを変更して移行します。SAP HANA 環境が次のすべての条件を満たしている場合は、Google ツールを使用してワークロードを移行できます。
    • ワークロードが Compute Engine VM インスタンスで実行されている場合。
    • VM が、必要なベアメタル マシンタイプと互換性のある OS バージョンを実行している場合。マシンタイプと OS バージョンの互換性については、SAP HANA の認定オペレーティング システムをご覧ください。
    • VM に、必要なタイプの Hyperdisk と互換性がある場合。これは VM ブート ボリュームにも適用されます。マシンタイプとディスクタイプの互換性については、SSD ベースの永続ディスクと Hyperdisk ボリュームの最小サイズの [Hyperdisk Extreme] タブと [Hyperdisk Balanced] タブをご覧ください。

    ソースシステムのマシンタイプに OS バージョンまたは Hyperdisk タイプとの互換性がない場合は、SAP HANA システム レプリケーションまたはバックアップ / 復元を使用してワークロードを移行できます。

  • SAP ツールを使用して移行します。SAP HANA ワークロードが Bare Metal Solution サーバーで実行されている場合は、SAP HANA システム レプリケーションやデータベースのバックアップと復元などの SAP ツールを使用してワークロードを移行できます。アプリケーション サーバーが同じリージョンで実行されている場合は、引き続き使用できます。詳細については、移行方法を確認するをご覧ください。
  • 完全な移行。SAP HANA ワークロードが独自のオンプレミス サーバーまたは別のクラウドで実行されている場合は、SAP HANA、アプリケーション サーバー、場合によってはインターフェース システムの移行を含む完全な移行です。

移行方法を確認する

次の表に、SAP または Google Cloud が提供する機能を使用した移行方法を示します。表内の比較情報は、特定の移行方法のコンテキストで示されています。

方法 説明
SAP HANA システム レプリケーション
  • 利点:
    • 最短のカットオーバー期間
    • ロールバックと負荷テスト用の並列環境を提供する
  • 考慮事項:
    • ホスト名と IP アドレスの変更により、インテグレーション テストの回数が増える
    • ハードウェアのフットプリントの重複により、コストが増加する
  • 推奨する用途:
    • 停止期間を短くする必要があるハイブリッド システム、オンプレミス システム、Bare Metal Solution システム
    • マシンタイプの変更により移行できないシステム
SAP HANA のバックアップと復元
  • 利点:
    • 暗黙的データ整合性チェック
    • ソースシステムとターゲットシステムの間の直接接続は不要
    • これは、Google Cloud の SAP 用エージェントやその他の標準の SAP ツールを使用すると、より簡単に実行できるオペレーションです。
  • 考慮事項:
    • 移行とカットオーバーに要する最長時間
  • 推奨する用途:
    • 長時間の停止期間を許容できるハイブリッド システム、オンプレミス システム、Bare Metal Solution システム
マシンタイプの変更
  • 利点:
    • 要件を満たしている場合の最も簡単なプロセス
    • 追加のインフラストラクチャは不要
    • 高可用性(HA)構成を利用して段階的なカットオーバーを可能にする
  • 考慮事項:
    • OS とディスクの互換性に関する前提条件が満たされている場合に使用できます
    • 移行中のロールバックは、並列環境を使用する場合と比較して複雑になる可能性があります
    • どの移行方法にも適用できる機能とパフォーマンスを確認するには、ある程度の負荷テストとインテグレーション テストが必要です
  • 推奨する用途:
    • OS とディスクタイプの互換性の要件を満たす Compute Engine VM で実行されているシステム

方法に固有の大まかな移行手順

選択した移行方法の大まかな移行手順については、以下をご覧ください。

これらの移行方法がシナリオに適していない場合は、完全移行を行うか、シナリオに応じた移行を設計する必要があります。この場合、Google Cloud Professional Services Organization(PSO)などの専門家からサポートを受けることができます。このエンゲージメントの詳細については、PSO の支援を受けるをご覧ください。

SAP HANA システム レプリケーションを使用して移行する

SAP HANA システム レプリケーション(HSR)は、SAP HANA の高可用性と障害復旧の基盤となる要素です。HSR は、データベースの移行をオペレーティング システムやその他のインフラストラクチャの依存関係から分離します。SAP HANA マルチターゲット レプリケーションを活用することで、本番環境システムのカットオーバーまで既存の HA と DR の構成を維持しながら、HSR を新しい Compute Engine ベアメタル インスタンスに拡張できます。

SAP HANA HSR を使用して SAP HANA ワークロードを Compute Engine ベアメタル インスタンスに移行するには、次の大まかな手順に従います。

  1. SAP 環境での変更と同様に、SAP HANA データベースの有効なバックアップを使用できることを確認します。

  2. 必要なタイプのベアメタル インスタンスをデプロイし、必要な HA と DR の構成で SAP HANA をインストールします。

    このデプロイを自動化するには、Google Cloud が提供する Terraform 構成を使用します。詳細については、SAP HANA シナリオのデプロイガイドをご覧ください。

    Google Cloud で SAP HANA を実行するために使用できるベアメタル マシンタイプ、使用可能な OS バージョン、推奨されるブロック ストレージ構成の詳細については、SAP HANA のベアメタル マシンタイプをご覧ください。

  3. ベアメタル インスタンスに Google Cloud の SAP 用エージェント バージョン 3.4(最新)をインストールします。

    エージェントのインストール方法については、Google Cloud の SAP 用エージェントをコンピューティング インスタンスにインストールして構成するをご覧ください。Google Cloud が提供する Terraform 構成を使用してベアメタル インスタンスをデプロイした場合、エージェントは自動的にインストールされます。

  4. Google Cloud の SAP 用エージェントを使用して、SAP ワークロードを最適な形で実行するために、ベアメタル インスタンスでゲスト OS を構成します。

    ゲスト OS の構成方法については、ベアメタル インスタンスでゲスト OS を構成するをご覧ください。

  5. ソースシステムとベアメタル インスタンスの間に必要なネットワーク接続を構成します。想定されるトランザクション ログの量に対応するには、十分なネットワーク帯域幅で接続を構成します。

  6. レプリケーションのベースラインを提供するには、バックアップから初期データをベアメタル インスタンスで実行されている SAP HANA データベースに読み込むか、次のステップの一部として完全同期を開始します。

  7. ソースシステムからベアメタル インスタンスにデプロイされた SAP HANA システムへのマルチターゲット レプリケーションを構成します。

  8. カットオーバーを推定するには、パフォーマンス テストや負荷テストなど、新しいシステムに対するドライランを少なくとも 1 回実施します。

  9. 新しいシステムでデータが完全に同期されていることを確認してから、カットオーバーを計画して開始します。

    • ソースシステムが Compute Engine VM インスタンスで実行されている場合は、内部ロードバランサを変更して、バックエンドをベアメタル インスタンスにリダイレクトします。これは、問題が発生した場合にソースシステムに戻すためにも使用できます。
    • ソースシステムが別の場所で実行されている場合は、ルートまたは DNS 更新を使用して、ソースシステムがベアメタル インスタンスへの接続に使用していた外部 IP アドレスをリダイレクトすることを検討してください。

この方法を使用すると、カットオーバーの開始前に、移行先のベアメタル インスタンスの SAP HANA システムをソースシステムと同期できます。適切な計画と実行により、この移行方法ではダウンタイムを大幅に短縮し、リスクを回避できます。また、移行中に予期しない事態が発生した場合のロールバックも大幅に簡素化できます。ただし、2 つの SAP HANA システムを並列で実行すると、コストが増加します。

データベースのバックアップと復元を使用して移行する

この移行方法では、ソースシステムのバックアップを取得し、ベアメタル インスタンスに復元します。

この方法のカットオーバー ダウンタイムを最小限に抑えるには、まず必要な HA と DR の構成で SAP HANA をベアメタル インスタンスにデプロイしてから、復元オペレーションを実行することをおすすめします。この移行方法は、非本番環境でよく使用され、ダウンタイムが大きな問題にならない場合に適しています。

データベースのバックアップと復元を使用して SAP HANA ワークロードを Compute Engine ベアメタル インスタンスに移行するには、次の大まかな手順に従います。

  1. 必要なタイプのベアメタル インスタンスをデプロイし、必要な HA と DR の構成で SAP HANA をインストールします。

    このデプロイを自動化するには、Google Cloud が提供する Terraform 構成を使用します。詳細については、SAP HANA シナリオのデプロイガイドをご覧ください。

    Google Cloud で SAP HANA を実行するために使用できるベアメタル マシンタイプ、使用可能な OS バージョン、推奨されるブロック ストレージ構成の詳細については、SAP HANA のベアメタル マシンタイプをご覧ください。

  2. ベアメタル インスタンスに Google Cloud の SAP 用エージェント バージョン 3.4(最新)をインストールします。

    エージェントのインストール方法については、Google Cloud の SAP 用エージェントをコンピューティング インスタンスにインストールして構成するをご覧ください。Google Cloud が提供する Terraform 構成を使用してベアメタル インスタンスをデプロイした場合、エージェントは自動的にインストールされます。

  3. Google Cloud の SAP 用エージェントを使用して、SAP ワークロードを最適な形で実行するために、ベアメタル インスタンスでゲスト OS を構成します。

    ゲスト OS の構成方法については、ベアメタル インスタンスでゲスト OS を構成するをご覧ください。

  4. カットオーバーを推定するには、パフォーマンス テストや負荷テストなど、新しいシステムに対するドライランを少なくとも 1 回実施します。

  5. 任意のバックアップ ツールを使用して最初のフル バックアップを作成し、カットオーバーの準備としてバックアップを移行先の環境に転送します。

  6. ソース SAP HANA データベースへの SAP アプリケーションとデータベースの接続を停止します。

  7. 目的のツールまたはファイル システム ダンプを使用して、ソース SAP HANA データベースの差分バックアップを作成します。または、停止期間が許容できる場合はフル バックアップを使用できます。この場合、ステップ 5 をスキップできます。

  8. ベアメタル インスタンスにインストールした SAP HANA データベースにバックアップを復元して、データをソースと同期します。

  9. 必要に応じて、レプリケーションを有効にして、ベアメタル インスタンスで HA クラスタを構成します。

  10. データが完全に復元されたことを確認してから、本番稼働前のアクティビティを計画して開始します。

    • ソースシステムが Compute Engine VM インスタンスで実行されている場合は、内部ロードバランサを変更して、バックエンドをベアメタル インスタンスにリダイレクトします。
    • ソースシステムが別の場所で実行されている場合は、ルートまたは DNS 更新を使用して、ソースシステムがベアメタル インスタンスへの接続に使用していた外部 IP アドレスをリダイレクトすることを検討してください。

バックアップと復元を使用してマルチテラバイト SAP HANA データベースを移行する場合、バックアップと復元の実行中にシステムをオフラインにする必要があります。そのため、プロセス中にダウンタイムが長くなる可能性があります。ソースシステムからターゲット システムに最後の変更が転送されたら、ソースシステムでのそれ以上の変更を防ぐようにしてください。

マシンタイプを変更して移行する

この移行方法は、Compute Engine VM インスタンスで実行されている SAP HANA ワークロードに適用できます。これには、基盤となる VM インスタンスのマシンタイプを、必要な Compute Engine ベアメタル マシンタイプに変更する必要があります。この方法は、次のような場合に最適です。

  • ソース SAP HANA システムが、互換性の要件を満たす VM インスタンスで実行されている。
  • 新しいコンピューティング インスタンスに SAP HANA をデプロイするのではなく、インスタンス名、IP アドレスなどのメタデータを保持する必要がある。
  • リスク許容度が既存のシステムと構成への変更に対応している。移行中に問題が発生した場合は、このような変更を元に戻して、移行前の正常な状態に戻す必要があります。このアプローチは、高可用性構成で運用する環境に最適です。

マシンタイプを変更して SAP HANA を Compute Engine VM から Compute Engine ベアメタル インスタンスに移行するには、次の大まかな手順に従います。

  1. 次の前提条件を満たしていることを確認します。

    • VM インスタンスが、移行先のベアメタル マシンタイプと互換性のある OS バージョンを使用している。そうでない場合は、互換性のあるバージョンにアップグレードします。マシンタイプと OS バージョンの互換性については、SAP HANA の認定オペレーティング システムをご覧ください。
    • VM インスタンスに、必要なタイプの Hyperdisk と互換性がある。これは、ブート ボリュームを含む、接続されているすべてのブロック ストレージ デバイスに適用されます。マシンタイプとディスクタイプの互換性については、SSD ベースの永続ディスクと Hyperdisk ボリュームの最小サイズの [Hyperdisk Extreme] タブと [Hyperdisk Balanced] タブをご覧ください。
  2. VM が高可用性(HA)クラスタの一部である場合は、次の点を確認してください。

    1. プライマリ サービス データベース インスタンスが、クラスタ内の他のノードでアクティブである。
    2. 自動フェイルオーバーを防ぐため、クラスタがメンテナンス モードになっている。
  3. SAP HANA インスタンスを停止します。

  4. VM インスタンスを停止します。

  5. 移行が失敗した場合にシステムを保護し、ロールバックを有効にするには、次の操作を行います。

    • SAP HANA データベースの有効で最新のフル バックアップがあることを確認します。
    • 変更するディスク(ブートディスクを含む)のスナップショットを作成します。
  6. VM で使用される Persistent Disk ボリュームごとに、前の手順で作成したディスク スナップショットを使用して、必要なタイプの Hyperdisk ボリュームを作成します。

    この方法については、ディスクタイプを変更するをご覧ください。ブートディスクの接続解除と接続方法については、ブートディスクの接続解除と接続をご覧ください。ベアメタル マシンタイプに対して Google Cloud が推奨するストレージ構成については、サポートされているブロック ストレージをご覧ください。

  7. Persistent Disk ボリュームを VM から切断します。

  8. 作成した Hyperdisk ボリュームを VM にアタッチします。

  9. VM のマシンタイプを、必要な Compute Engine ベアメタル マシンタイプに編集します。

    インスタンスのマシンタイプを編集する方法については、コンピューティング インスタンスのマシンタイプを編集するをご覧ください。SAP HANA での使用が SAP によって認定されている Compute Engine ベアメタル マシンタイプについては、SAP HANA のベアメタル マシンタイプをご覧ください。

  10. ベアメタル インスタンスを起動します。

  11. Google Cloud の SAP 用エージェントを使用して、SAP ワークロードを最適な形で実行するために、ベアメタル インスタンスでゲスト OS を構成します。

    ゲスト OS の構成方法については、ベアメタル インスタンスでゲスト OS を構成するをご覧ください。

  12. SAP HANA データベースを起動します。

  13. SAP HANA がベアメタル インスタンスで想定どおりに実行されていることを確認します。

  14. ベアメタル インスタンスが HA クラスタの一部である場合は、次の操作を行います。

    1. HA クラスタ内の他のノードに対して手順 3~13 を繰り返します。
    2. クラスタのメンテナンス モードを解除します。
  15. データが最新であることを確認してから、本番稼働前のアクティビティを計画して開始します。

この方法は、並列環境を必要とせずにマシンタイプを変更してインプレース アップデートを実行する場合に適しています。OS バージョンとディスクタイプに、必要なベアメタル マシンタイプとの互換性がない場合は、影響を受けるインスタンスを復元する必要がある場合にダウンタイム期間とロールバック時間が大幅に長くなる可能性があります。フェーズ別の変更アプローチを使用すると、ダウンタイムを短縮できます。これには、HA クラスタの使用と、ベアメタル マシンタイプへの計画された移行前に VM を Hyperdisk ボリュームに移行することが含まれます。

完全な移行

SAP HANA ワークロードが独自のオンプレミス サーバーまたは別のクラウドで実行されている場合は、SAP HANA、アプリケーション サーバー、場合によってはインターフェース システムの移行を含む完全な移行です。

Google Cloud の専門家やパートナーに移行の手助けを依頼できます。詳細については、PSO の支援を受けるをご覧ください。

PSO の支援を受ける

複雑な SAP HANA システムを X4 または C3 ベアメタル インスタンスに移行するには、Google Cloud Professional Services Organization(PSO)またはシステム インテグレータ(SI)を利用するのが効果的です。SAP HANA と Google Cloud の専門知識、実績のある方法論、ベスト プラクティスにより、移行をスムーズに成功させて、中断を最小限に抑え、システム パフォーマンスを最適化できます。