非常に大規模なデータベースの移行のベスト プラクティスを確認する

• 11 分

以下のガイドラインは、お客様の実際のプロジェクトと、これらのプロジェクトから得られたことに基づいて行います。 ガイドラインでは、過去に失敗したシナリオが明らかにされています。 たとえば、R3load エクスポート サーバーとして UNIX サーバーまたは仮想化されたサーバーを使用しないという推奨事項があります。

• 多くの場合、エクスポートのパフォーマンスは、全体的なダウンタイムを制限する要素です。 多くの場合、現在のハードウェアは 4 から 5 年経ったものであり、アップグレードするには非常にコストがかかります。
• そのため、実際に実現できる最大のエクスポート パフォーマンスを得ることが重要です。
• 以前のプロジェクトでは、何人週または何人月もかけて UNIX または仮想化されたプラットフォームでの R3load エクスポートのパフォーマンスをチューニングしようとしたあげく、あきらめて Intel R3load サーバーを使用したことがあります。
• デュアルソケットの市販 Intel サーバーは安価であり、大幅なパフォーマンス向上を実現できます。場合によっては、UNIX または仮想化サーバーで可能な小さなチューニングの改善より、桁違いによくなることがあります。
• 多くの場合、お客様は既存の仮想マシン ファームを持っていますが、ほとんどの場合、それらでは最新のオフロードも SR-IOV テクノロジもサポートされていません。 VMware は、バージョンが古い場合、パッチが適用されていない場合、または高いネットワーク スループットと低遅延になるように構成されていない場合がよくあります。 R3load エクスポート サーバーには、高速なスレッド パフォーマンスと、極めて高いネットワーク スループットが必要です。 R3load エクスポート サーバーは、CPU とネットワークの使用率がほぼ 100% の状態で、10 から 15 時間実行する場合があります。 これは、ほとんどの VMware ファームの一般的なユース ケースではなく、ほとんどの VMware のデプロイは、R3load のようなワークロードを処理するようには設計されていません。

ベスト プラクティス

• 現在の SAP ランドスケープを調査してインベントリを作成します。 SAP サポート パックのレベルを確認し、ターゲット DBMS をサポートするためにパッチの適用が必要かどうかを判断します。 一般に、オペレーティング システムの互換性は SAP カーネルによって決まり、DBMS の互換性は SAP_BASIS のパッチ レベルによって決まります。
• SMIGR_CREATE_DDL の更新など、ソース システムで適用する必要がある SAP OSS Note の一覧を作成します。 Azure への移行中に大きな変更が発生しないように、ソース システムでの SAP カーネルのアップグレードを検討します (例: システムで前の 7.41 カーネルが実行されている場合は、移行中に大きな変更が発生しないように、ソース システムで最新の 7.45 に更新します)。
• 高可用性とディザスター リカバリー ソリューションを開発して文書化します。 このドキュメントでは、ソリューションを DB 層、ASCS 層、および SAP アプリケーション サーバー層に分ける必要があります。 TREX や liveCache などのスタンドアロン ソリューションには、個別のソリューションが必要になる場合があります。
• Azure 仮想マシンの種類とストレージ構成について詳しく書かれている、サイズ設定と構成に関するドキュメントを作成します。 Premium ディスクの数、データ ファイルの数、ディスク間のデータ ファイルの分散方法、記憶域スペースの使用状況、NTFS 形式のサイズ = 64 kb。 また、メモリ設定、並列処理の最大次数、トレース フラグなど、バックアップと復元および DBMS の構成も文書化します。
• 仮想ネットワーク、サブネット、NSG、UDR 構成などのネットワーク設計ドキュメントを作成します。
• セキュリティとセキュリティ強化の概念を文書化して実装します。 Internet Explorer を削除し、SAP サービス アカウントとサーバー用の Active Directory コンテナーを作成し、限られた数の必要なポート以外のすべてのポートをブロックするファイアウォール ポリシーを適用します。
• パッケージとテーブルの分割の概念、R3load の数、SQL Server のトレース フラグ、並べ替え済みと未並べ替えの Oracle RowID の設定、SMIGR_CREATE_DDL の設定、Perfmon カウンター (BCP 行数/秒や BCP スループット KB/秒、CPU、メモリなど)、RSS の設定、高速ネットワークの設定、ログ ファイルの構成、BPE の設定、TDE の構成が詳しく記述されている、OS と DB の移行設計ドキュメントを作成します。
• 各テスト サイクルでの R3load のエクスポートとインポートの進行状況を示す "フライト プラン" グラフを作成します。 これにより、移行チームは、チューニングと変更によって R3load のエクスポートまたはインポートのパフォーマンスが向上するかどうかを検証できます。 X 軸は完了したパッケージの数で、Y 軸は経過時間を示します。 また、このフライトプランは、運用移行の間にも重要であり、計画された進行状況を、実際の進行状況や早期に特定された問題と比較することができます。
• パフォーマンス テスト計画を作成します。 上位 20 までのオンライン レポート、バッチ ジョブ、インターフェイスを明らかにします。 元のソース システムでの入力パラメーター (日付範囲、営業オフィス、プラント、会社コードなど) と実行時間を文書化します。 Azure での実行時間と比較します。 パフォーマンスに違いがある場合は、SAT、ST05、その他の SAP ツールを実行して、非効率的なステートメントを特定します。
• デプロイと構成を監査し、クラスターのタイムアウト、カーネル、ネットワークの設定、NTFS 形式のサイズがすべて、設計ドキュメントと一致していることを確認します。 重要なサーバーで perfmon カウンターを設定し、90 秒ごとに基本的な正常性パラメーターを記録します。 SAP サーバーが別の AD コンテナーにあり、ファイアウォールの構成によってグループ ポリシーがコンテナーに適用されていることを確認します。
• OS と DB の移行コンサルタントのリーダーがライセンスを所有していることを確認します。 コンサルタント名、s ユーザー、および証明書の日付を要求します。 BC-INS-MIG に対する OSS メッセージを開き、コンサルタントが認められていてライセンスを持っていることを SAP に確認します。
• 可能であれば、プロジェクト チーム全体を 1 つの物理的な場所の VLDB 移行プロジェクトに関連付け、複数の大陸やタイム ゾーンに地理的に分散しないようにします。
• 適切なフォールバック プランが設けられていること、および全体的なスケジュールに組み込まれていることを確認します。
• R3load エクスポート サーバーには高速スレッド カウント Intel CPU モデルを選択します。 "エネルギー節約" CPU モデルはパフォーマンスが低下するので使わないでください。また、4 ソケット サーバーは使わないでください。 Intel Xeon E5 Platinum 8158 がよい例です。

問題を回避するためのベスト プラクティス

• エクスポートとインポートの作業の下請けを、異なるコンサルティング組織と契約しないでください。 お客様が、ソース システムの管理を 1 つのコンサルティング組織またはパートナーにアウトソーシングし、Azure への移行を別のパートナーに切り替えることを望む場合があります。 エクスポートとインポートのチューニングと構成の間には密接な結び付きがあるため、これらのタスクを異なる組織に割り当ててよい結果が得られることはほとんどありません。
• 移行を行って運用を開始するまでの間、Azure のハードウェア リソースについて倹約しないでください。 Azure 仮想マシンは分単位で課金され、サイズを簡単に縮小できます。 VLDB の移行中は、使用できる最も強力な仮想マシンを使ってください。 お客様は、200 から 250% オーバーサイズのシステムで稼働を成功させた後、オーバーサイズのシステムを実行している間に安定させています。 システムの使用状況を 4 週間から 6 週間監視してから、余剰容量がある仮想マシンはサイズを小さくするかシャットダウンしてコストを下げます。