Azure Hana ラージ インスタンスでの Hana システム レプリケーションのセットアップ


執筆者: Cameron (MSFT SAP Program Manager)

このポストは、2018 年 2 月 10 日に投稿された Setting Up Hana System Replication on Azure Hana Large Instances の翻訳です。

 

今回は、先日 Cognizant SAP Cloud チーム (英語)HANA ラージ インスタンスで構築したお客様の事例をご紹介します。HANA ラージ インスタンス (HLI) の構造上、異なる2つの Azure リージョンにある HLI 間の災害復旧機能として HANA システム レプリケーション (HSR) を使用できません。その理由は、別の Azure リージョン上の HLI 間のトランジット ルーティングをネットワーク アーキテクチャがサポートしていないためです。その代わりに、HLI では同じ地理的地域内のリージョン間でストレージ レプリケーションを実行することができます。詳しくはこちらの記事を参照してください。しかしながら、既存環境で災害復旧用にHANA システム レプリケーションを使用しており、Azure HANA ラージ インスタンスでもHANA システム レプリケーションを継続利用したいというお客様も多くいらっしゃいます。この要望にお応えするため、Cognizant チームは、異なる Azure リージョンの 2 つの HLI 間のトランジット ルーティングの問題に取り組んできました。その結果、Linux の IPTables 機能を使用することでこの問題を解決できることがわかりました。Linux のネットワーク アドレス変換に基づく方法で、異なる Azure データセンターの HLI での SAP HSR の実行が可能です。
本来Azure ExpressRoute 及び VPN はトランジット ルーティングに対応していないため、異なる Azure データセンターの HLI 間を直接ネットワーク接続することはできません。

しかし、小規模な VM を作成し、2 つの HLI 間のトラフィックを転送させることで、HSR を実行できるようになります。

この方法のメリットとしては、SMT サーバーと NTP サーバーにアクセスして修正プログラムの適用や時刻の同期を行うことができるということもあります。

今回ご紹介するソリューションは、ネイティブ Azure VM 上の Hana システムでは不要です。最大 20 TB のベア メタルのテーラード データセンター統合 (TDI) 認定インフラストラクチャで提供される Azure ラージ インスタンス向けのソリューションです。

以下のソリューションは、HLI アーキテクチャに含まれないことをご承知ください。そのため、構成、デプロイ、管理、運用に関するサポートがLinuxベンダーから提供され、IPTables ベースの災害復旧ソリューションをデプロイおよび運用する必要があります。

 

概要

SAP Hana データベースでは、Hana システム レプリケーション、ホスト自動フェイルオーバー、ストレージ レプリケーション (英語) という 3 つの HA/DR テクノロジを使用することができます。

下の図は、地理的に分散された災害復旧ソリューションの典型的な HLI シナリオです。Azure HLI ソリューションにはストレージ ベースの DR レプリケーションが組み込まれていますが、DBMS ソフトウェア ベースの HA/DR ソリューションである HSR を使用することもできます。

HSR は、標準の HSR ドキュメントに従って同じ Azure データセンター内で構成することが可能です。

プライマリ Azure データセンターと DR 用の Azure データセンター間にネットワーク ルートがないため、HSR を IPTables ソリューションなしで構成することはできません。2 つの ExpressRoute 接続を結ぶネットワーク トラフィックは、「トランジット ルーティング」と呼ばれます。2 つの異なるデータセンター間で HSR を構成するために、SAP のシステム インテグレーターまたは Azure IaaS のコンサルティング企業が次のようなソリューションを実装する必要があります。

主要コンポーネントと概念は以下のとおりです。

1. 任意の小規模な Linux VM を、各データセンターの HLI に接続された VNET 上の Azure に設置します。

2. ExpressRoute 回線は、各データセンター内で HLI から VNET にクロス接続されます。

3. プライマリ HLI とセカンダリ HLI 間のトラフィックは、Linux の標準機能である IPTables を使用して Azure の IP 転送用 VM 経由で転送されます。

4. 以下の例のように、お客様によってデプロイ シナリオは異なります。

a. プライマリ データセンターに 2 つの HLI をデプロイし、ローカル HLI 間で同期 HSR をセットアップします。オプションとしてフェールオーバーの高速化と可視性向上のために Suse Pacemaker を構成しますが、3 つ目の DR ノードには通常 Suse Pacemaker は構成しません。

b. Azure 内にプロキシ サーバーを置き、直接インターネットにトラフィックを送信することを許可する場合もあれば、すべての http(s) トラフィックがオンプレミスのファイアウォールおよびプロキシ インフラストラクチャに戻るように構成する場合もあります。

c. Azure 上の VM で Azure Automation やスクリプトを使用して HLI からバックアップを「プル」し、Azure Blob ストレージに保存する場合もあります。この場合、HLI でプロキシを使用してバックアップを Blob ストレージに「プッシュ」する必要がなくなります。

上記の様々な違いにより、IPTables ルールの構成が異なるため、すべてのシナリオに対応できる一つの構成を提供することはできません。

https://blogs.sap.com/2017/02/01/enterprise-readiness-with-sap-hana-host-auto-failover-system-replication-storage-replication/ (英語)

https://blogs.sap.com/2017/04/12/revealing-the-differences-between-hana-host-auto-failover-and-system-replication/ (英語)

以下の図は、ハブ & スポーク型のネットワーク トポロジとクロス接続された Azure ExpressRoute を表しており、一般的に推奨されるデプロイ モデルです。

https://docs.microsoft.com/ja-jp/azure/architecture/reference-architectures/hybrid-networking/hub-spoke

https://docs.microsoft.com/ja-jp/azure/expressroute/expressroute-faqs

図 1. 図では、プライマリ HLI からセカンダリ HLI への直接のネットワーク ルートないことがわかります。IP 転送ソリューションを追加することで、HLI で TCP 接続がを確立できます。


注: ExpressRoute のクロス接続は、リージョン内 vnet ピアリングにGA後変更可能
https://docs.microsoft.com/ja-jp/azure/virtual-network/virtual-network-peering-overview

 

IPTables のルールの構成例 1

Cognizant SAP Cloud チームが最近 Suse 12.x にデプロイしたソリューションの例を以下に示します。

プライマリ HLI 10.16.0.4

IPTables 用 VM 10.1.0.5

DR 用 HLI 10.17.0.4

プライマリ HLI の構成内容

IPTables -N input_ext

IPTables -t nat -A OUTPUT -d 10.17.0.0/24 -j DNAT –to-destination 10.1.0.5

IPTables の構成内容

## プライマリ HLI から DR 用 HLI へ

echo 1 > /proc/sys/net/ipv4/ip_forward

IPTables -t nat -A PREROUTING -s 10.16.0.0/24 -d 10.1.0.0/24 -j DNAT –to-destination 10.17.0.4

IPTables -t nat -A POSTROUTING -s 10.16.0.0/24 -d 10.17.0.0/24 -j SNAT –to-source 10.1.0.5

## DR 用 HLI からプライマリ HLI へ

IPTables -t nat -A PREROUTING -s 10.17.0.0/24 -d 10.1.0.0/24 -j DNAT –to-destination 10.16.0.4

IPTables -t nat -A POSTROUTING -s 10.17.0.0/24 -d 10.16.0.0/24 -j SNAT –to-source 10.1.0.5

DR 用 HLI

IPTables -N input_ext

IPTables -t nat -A OUTPUT -d 10.16.0.0/24 -j DNAT –to-destination 10.1.0.5

この構成は永続的なものではなく、Linux サーバーの再起動時に無効になります。

すべてのノードを正しく構成したら次を実行

IPTables-save > /etc/IPTables.local

"IPTables-restore -c /etc/IPTables.local" /etc/init.d/boot.local に追加

IPTables 用 VM で次のコマンドを実行し IP 転送設定を永続化

vi /etc/sysctl.conf

"net.ipv4.ip_forward = 1" を追加

上記の例では CIDR ネットワークを 10.16.0.0/24 としていますが、10.16.0.4 のように特定のホストを指定することもできます。

 

IPTables のルールの構成例 2

IPTables 用 VM に IP アドレスを追加して、転送先 HLI の IP アドレスに転送する方法もあります。

これには、以下のようなメリットがあります。

1. オンプレミスでの Hana Studio から HLI への接続など、受信の接続がサポートされる

2. IPTables は IPTables 用 VM 上のみで構成でき、HLI 側の構成の必要がない

実装手順は以下のとおりです。

1. 転送先 HLI の IP アドレスを指定します。ここでは、DR 用 HLI は 10.17.0.4 としています。

2. IPTables 用 VM に静的 IP アドレスを追加します。ここでは 10.1.0.6 です。


注: 構成後に、YaST に IP アドレスを追加する必要はありません。この IP アドレスは ifconfig には表示されません。

3. IPTables 用 VM で以下のコマンドを実行します。

IPTables -t nat -A PREROUTING -d 10.1.0.6 -j DNAT –to 10.17.0.4

IPTables -t nat -A PREROUTING -d <<IPTables VM に新たに割り当てられた一意の IP>> -j DNAT –to <<他の HLI IP または MDC テナントの IP>>

IPTables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

4. IPTables 用 VM に /proc/sys/net/ipv4/ip_forward = 1 となっていることを確認し、構成を保存します。

5. IPTables 用 VM の新しい IP アドレスをポイントする DNS やホスト ファイルを保持します。ここでは、DR 用 HLI の参照先はすべて 10.1.0.6 (実際の IP アドレス 10.17.0.4 とは異なります) としています。

6. この手順で逆方向 (DR 用 HLI からプライマリ HLI) や他の (MDC テナントの) HLI へのルーティングも構成します。

7. IPTables 用 VM の静的 IP アドレスを ILB に追加して、高可用性の構成にすることも可能です。

8. 以下のコマンドを実行して、構成をテストします。

ssh 10.1.0.6 -l <ユーザー名> (10.1.0.6 へのトラフィックは NAT 経由で 10.17.0.4 に転送されます)

ログイン後、ssh セッションが DR 用 HLI (10.17.0.4) に接続されていることを確認します。

重要: SAP アプリケーション サーバーでは実際の HLI の IP アドレス (10.17.0.4) を使用する必要があります。また、IPTables 用 VM から接続する構成は使用できません


IPTables のルールを削除する場合、以下のコマンドを実行します。

IPTables -t nat -F

IPTables -F

IPTables のルールをリスト表示する場合、以下のコマンドを実行します。

IPTables -t nat -L

IPTables -L

ip route list

ip route del

http://www.netfilter.org/documentation/index.html (英語)

https://www.systutorials.com/816/port-forwarding-using-IPTables/ (英語)

https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/Security_Guide/s1-firewall-ipt-fwd.html (英語)

https://www.howtogeek.com/177621/the-beginners-guide-to-IPTables-the-linux-firewall/ (英語)

https://www.tecmint.com/linux-IPTables-firewall-rules-examples-commands/ (英語)

https://www.tecmint.com/basic-guide-on-IPTables-linux-firewall-tips-commands/ (英語)

 

IP 転送用 VM のサイズ

Hana DB の初期同期処理におけるテストでは、ピーク時のネットワーク トラフィックは 15 ~ 25 MB/秒でした。このため、最初は 2 基以上の CPU を搭載した VM を使用することを推奨します。さらに規模が大きい場合は、D12v2 などの VM で Accelerated Networking を有効化し、ネットワーク処理のオーバーヘッドを軽減することをお勧めします。

以下は推奨される監視項目です。

1. HSR の同期中および同期後の IP 転送用 VM の CPU 使用率

2. IP 転送用 VM のネットワーク使用率

3. プライマリ ノードとセカンダリ ノードの間の HSR の遅延

"HANA_Replication_SystemReplication_KeyFigures" という SQL で、ログ リプレイのバックログ (REPLAY_BACKLOG_MB) を表示することができます。

フォールバック オプションとして、M_SERVICE_REPLICATION システム ビューでセカンダリ サイトでのログ リプレイの遅延を確認できます。

SELECT SHIPPED_LOG_POSITION, REPLAYED_LOG_POSITION FROM M_SERVICE_REPLICATION

この差分をログ ポジションのサイズである 64 バイトで乗じます。

(SHIPPED_LOG_POSITION – REPLAYED_LOG_POSITION) * 64 = <replay_backlog_byte>

1969700 – SQL Statement Collection for SAP HANA

こちらの SAP Note は、HSR の主要な数値の監視に役立つスクリプトのリファレンスです。HANA_Replication_SystemReplication_KeyFigures_1.00.120+_MDC

CPU やネットワークの使用率が高い場合は、Accelerated Networking に対応した VM にアップグレードすることをお勧めします。

 

重要な資料、ドキュメント、ヒント

テスト デプロイに基づくソリューション セットアップ時の推奨事項をまとめました。

1. 経験の豊富な Linux エンジニアと SAP Basis コンサルタントが共同でセットアップを行うことを強くお勧めします。テスト デプロイでは、HSR 接続を保証するために IPTables のルールのテストを何度も実施しなければなりませんでした。また、Linux エンジニアが HSR に不慣れなことや、Basis コンサルタントが Linux ネットワークに詳しくないことが原因で、トラブルシューティングに時間がかかることもありました。

2. ポートの状況や構成を確認するには、特定のポートで HLI に対して ssh コマンドを実行するのが簡単です。たとえば、プライマリ HLI で
ssh <セカンダリ HLI>:3<システム番号>15
というコマンドを実行します。これがタイムアウトした場合、構成が誤っている可能性があります。正しい構成であれば、ssh セッションが即座に接続されます。

3. IP 転送用 VM の NSG やファイアウォールに関しては、HLI との間の HSR ポートを開いておく必要があります。

4. 詳しくは、SAP HANA システム レプリケーションのネットワーク構成 (英語) を参照してください。

5. SAP HANA でシステム レプリケーションを実行する方法 (英語)

6. IPTables 用 VM の不具合は、他のネットワーク切断や中断と同様に処理されます。VM が再び使用可能になると (またはネットワーク接続が回復すると)、キューにたまった DR サイトへの HSR レプリケーション トラフィックが大量に発生します。

7. 今回の IPTables ソリューションは、非同期 DR レプリケーション専用です。インメモリ同期や同期レプリケーションなど、他の種類の HSR レプリケーションには推奨されません。電源などのインフラストラクチャが異なる地理的に離れた非同期レプリケーションでは、RPO が 0 にならないため、データ損失の可能性があります。このことは、IPTables などの IP 転送メカニズムを使用するかどうかにかかわらず、あらゆる DBMS の DR ソリューションに共通します。IPTables 用 VM の CPU とネットワークに余裕がある限り、IPTables が RPO に与える影響はほとんどありません。
https://help.sap.com/viewer/6b94445c94ae495c83a19646e7c3fd56/2.0.02/en-US/c039a1a5b8824ecfa754b55e0caffc01.html (英語)

8. 次の SAP OSS Note の推奨事項もご確認ください。

2142892 – SAP HANA System Replication sr_register hangs at "collecting information" (重要)

また、IPTables 用 VM で次のコマンドを実行することもできます。
IPTables -t mangle -A POSTROUTING -p tcp –tcp-flags SYN,RST SYN -o eth0 -j TCPMSS –set-mss 1500

2222200 – FAQ: SAP HANA Network

2484128 – hdbnsutil hangs while registering secondary site

2382421 – Optimizing the Network Configuration on HANA- and OS-Level

2081065 – Troubleshooting SAP HANA Network

2407186 – How-To Guides & Whitepapers For SAP HANA High Availability

9. 「SAP Note 1999880 – FAQ: SAP HANA System Replication」に記されているとおり、小規模で低価格の VM も多層 HSR シナリオに対応しています。レプリケーション先へのバッファーは、最低でも 64GB または 20GB 以上の行ストア (いずれか多い方) が必要になります (データは事前に読み込まれません)。

10. HSR の制限事項やストレージ ベースのスナップショット バックアップ条件と MDC については、既存の SAP Note とドキュメントを参照してください。

11. 今回の IPTables のルールは、CIDR ネットワーク全体を転送するものですが、ホストを個別に指定することもできます。

 

サンプル ネットワーク図

以下の 2 つの図は、ハブ & スポーク ネットワーク トポロジによる HLI 接続を表しています。

2 つ目の図は、HLI を VNET のスポーク部分に接続しています。この接続は、IDS や IPS の調査、仮想アプライアンスの監視などに役立ちます。また、ハブ ネットワークやハブ ネットワークからオンプレミスへのトラフィックを保護するメカニズムなどにも有効です。

注: 一般的なハブ & スポーク ネットワークの環境でルーティングにネットワーク アプライアンスを使用している場合、ネットワーク ルーティング アプライアンスを経由するすべてのトラフィックに対して、ExpressRoute ゲートウェイのサブネットのユーザー定義ルーティングを適用する必要があります。この場合、HLI ExpressRoute からの受信トラフィックに適用されるため、DBMS サーバーと SAP アプリケーション サーバーとの間のレイテンシが大幅に大きくなる可能性があります。ユーザー定義ルーティングを追加するときは、HLI からアプリケーション サーバーへのトラフィックがネットワーク アプライアンスを通過せず直接ルーティングされるように構成します。

 



協力者:

Rakesh Patil (Azure CAT チーム Linux エキスパート) には多大な支援をいただきました。

Peter Lopez (Microsoft CSA)

ソリューションの詳細:

Sivakumar Varadananjayan 氏 (Cognizant Global SAP Cloud 担当、テクノロジ コンサルタント責任者)
https://www.linkedin.com/in/sivakumarvaradananjayan/detail/recent-activity/posts/ (英語)

Content from third party websites, SAP and other sources reproduced in accordance with Fair Use criticism, comment, news reporting, teaching, scholarship, and research

 

Comments (0)

Skip to main content