Linux on Azure 向け SAP BusinessObjects BI プラットフォームデプロイガイド

2023-06-15

このアーティクルでは、Azure for Linux で SAP BusinessObjects BI (BOBI) プラットフォームをデプロイする戦略について説明します。この例では、プレミアムソリッドステートドライブ (SSD) マネージドディスクを持つ 2 つの仮想マシンをインストールディレクトリとして設定します。 CMS データベースには Azure Database for MySQL を使用し、両方のサーバーでファイルリポジトリサーバーの Azure NetApp Files を共有します。両方の仮想マシンに、既定の Tomcat Java Web アプリケーションと BI プラットフォームアプリケーションを一緒にインストールします。ユーザー要求の負荷を分散するために、ネイティブな TLS/SSL オフロード機能を持つ Azure Application Gateway を使用します。

この種類のアーキテクチャは、小規模なデプロイまたは非運用環境で効果的です。大規模なデプロイまたは運用環境では、Web アプリケーション用に個別のホストを使用できます。また、複数の BOBI アプリケーションホストを使用して、サーバーがより多くの情報を処理できるようにすることもできます。

Azure for Linux での SAP BOBI のデプロイ

この例の製品バージョンとファイルシステムレイアウトを次に示します。

SAP BusinessObjects プラットフォーム 4.3
SUSE Linux Enterprise Server 12 SP5
Azure Database for MySQL (バージョン: 8.0.15)
MySQL C API コネクタ - libmysqlclient (バージョン: 6.1.11)

ファイルシステム	説明	サイズ (GB)	所有者	グループ	ストレージ
/usr/sap	SAP BOBI インスタンス、既定の Tomcat Web アプリケーションと、必要に応じてデータベースドライバをインストールするためのファイルシステムです。	SAP のサイズ設定のガイドライン	bl1adm	sapsys	マネージドプレミアムディスク - SSD
/usr/sap/frsinput	マウントディレクトリは、すべての BOBI ホストで共有されるファイルのためのディレクトリで、入力ファイルのリポジトリディレクトリとして使用されます。	ビジネスニーズ	bl1adm	sapsys	Azure NetApp Files
/usr/sap/frsoutput	マウントディレクトリは、すべての BOBI ホストで共有されるファイルのためのディレクトリで、出力ファイルのリポジトリディレクトリとして使用されます	ビジネスニーズ	bl1adm	sapsys	Azure NetApp Files

重要

SAP BusinessObjects プラットフォームのセットアップについては Azure NetApp Files を使用して説明しますが、Azure Files の NFS を入力および出力ファイルリポジトリとして使用できます。

Azure portal を使用した Linux 仮想マシンのデプロイ

このセクションでは、SAP BOBI プラットフォーム用の Linux オペレーティングシステムイメージを持つ 2 つの仮想マシンを作成します。仮想マシンを作成するための大まかな手順は以下の通りです。

リソースグループを作成します。
仮想ネットワークを作成します。
- SAP BI プラットフォームのデプロイでは、すべての Azure サービスで 1 つのサブネットを使用しないでください。 SAP BI プラットフォームのアーキテクチャに基づいて、複数のサブネットを作成する必要があります。このデプロイでは、アプリケーション、ファイルリポジトリストア、Application Gateway の 3 つのサブネットを作成します。
- Azure では、Application Gateway と Azure NetApp Files は常に別のサブネット上になければなりません。詳細については、Azure Application Gateway と Azure NetApp Files のネットワーク計画のガイドラインを参照してください。
Azure リージョン内の任意のシステム構成、複数のゾーンにまたがるか、単一のゾーン内に存在するか、またはゾーンのないリージョンで動作するかに応じて、適切な可用性オプションを選択します。
(azusbosl1) という名前の仮想マシン 1 を作成します。
- カスタムイメージを使用することも、Azure Marketplace からイメージを選択することもできます。詳細については、Azure Marketplace から SAP 用の VM をデプロイするまたは SAP 用のカスタムイメージで VM をデプロイするを参照してください。
(azusbosl2) という名前の仮想マシン 2 を作成します。
プレミアム SSD ディスクを 1 つ追加します。これは、SAP BOBI のインストールディレクトリとして使用します。

Azure NetApp Files のプロビジョニング

Azure NetApp Files の設定を続行する前に、Azure NetApp Files のドキュメントの内容をよく理解しておいてください。

Azure NetApp Files はいくつかの Azure リージョンで利用できます。選択した Azure リージョンで Azure NetApp Files が提供されているかどうかを確認してください。

Azure NetApp Files を利用できる Azure リージョンを参照して、リージョンごとの Azure NetApp Files の利用可能性を確認してください。

Azure NetApp Files リソースのデプロイ

以下の手順では、お使いの Azure 仮想ネットワークが既にデプロイされていることを前提としています。 Azure NetApp Files のリソースと、そのリソースがマウントされる VM は、同じ Azure Virtual Network 内またはピアリングされた Azure Virtual Network 内にデプロイする必要があります。

選択した Azure リージョンで、Azure NetApp Files アカウントを作成します。
Azure NetApp Files 容量プールを設定します。このアーティクルで示されている SAP BI プラットフォームアーキテクチャには、Premium サービスレベルで 1 つの Azure NetApp Files 容量プールが使用されています。 Azure の SAP BI ファイルリポジトリサーバーには、Azure NetApp Files Premium または Ultra サービスレベルを使用することをお勧めします。
サブネットを Azure NetApp Files に委任します。
「Azure NetApp Files の NFS ボリュームを作成する」の手順に従って、Azure NetApp Files のボリュームをデプロイします。

ボリュームは、NFSv3 または NFSv4.1 としてデプロイできます。これは、両方のプロトコルが SAP BOBI プラットフォームでサポートされているためです。それぞれの Azure NetApp Files サブネット内にボリュームをデプロイします。 Azure NetApp Files の IP アドレスは、自動的に割り当てられます。

Azure NetApp Files のリソースと Azure VM は、同じ Azure 仮想ネットワーク内またはピアリングされた Azure 仮想ネットワーク内に配置する必要があることに注意してください。たとえば、azusbobi-frsinput、azusbobi-frsoutput がボリューム名で、nfs://10.31.2.4/azusbobi-frsinput、nfs://10.31.2.4/azusbobi-frsoutput が Azure NetApp Files ボリュームのファイルパスです。

ボリューム azusbobi-frsinput (nfs://10.31.2.4/azusbobi-frsinput)
ボリューム azusbobi-frsoutput (nfs://10.31.2.4/azusbobi-frsoutput)

重要な考慮事項

SAP BOBI プラットフォームファイルリポジトリサーバー用の Azure NetApp Files を作成するときは、次の考慮事項にご注意ください。

最小容量のプールは 4 テビバイト (TiB) です。容量プールのサイズは、1 TiB 単位で増やすことができます。
最小ボリュームサイズは 100 ギビバイト (GiB) です。
Azure NetApp Files と、Azure NetApp Files のボリュームがマウントされるすべての仮想マシンは、同じ Azure 仮想ネットワーク内、または同じリージョン内のピアリングされた仮想ネットワーク内に存在する必要があります。同一リージョン内の仮想ネットワークピアリングを介した Azure NetApp Files のアクセスがサポートされています。グローバルピアリングによる Azure NetApp Files へのアクセスは現在サポートされていません。
選択した仮想ネットワークには、Azure NetApp Files に委任されているサブネットがある必要があります。
Azure NetApp Files ボリュームのスループットおよびパフォーマンス特性は、「Azure NetApp Files のサービスレベル」に記載されているように、ボリュームクォータとサービスレベルの機能です。 SAP Azure NetApp ボリュームのサイズを設定するときは、結果として得られるスループットがアプリケーション要件を満たしていることを確認してください。
Azure NetApp Files のエクスポートポリシーでは、許可するクライアント、アクセスタイプ (例えば、読み書きや読み取り専用など) を制御することができます。
Azure NetApp Files 機能は、ゾーンにはまだ対応していません。現在、その機能は、Azure リージョン内のすべての可用性ゾーンにはデプロイされていません。 Azure リージョンによっては、待ち時間が発生する可能性があることに注意してください。
Azure NetApp Files ボリュームは、NFSv3 または NFSv4.1 ボリュームとしてデプロイできます。両方のプロトコルが SAP BI プラットフォームアプリケーション用にサポートされています。

Linux サーバーでのファイルシステムの構成

このセクションの手順では、次のプレフィックスを使用します。

[A] :この手順はすべてのホストに適用されます。

SAP ファイルシステムのフォーマットとマウント

[A] すべてのアタッチされたディスクを一覧表示します。

sudo lsblk
NAME   MAJ:MIN RM  SIZE RO TYPE MOUNTPOINT
sda      8:0    0   30G  0 disk
├─sda1   8:1    0    2M  0 part
├─sda2   8:2    0  512M  0 part /boot/efi
├─sda3   8:3    0    1G  0 part /boot
└─sda4   8:4    0 28.5G  0 part /
sdb      8:16   0   32G  0 disk
└─sdb1   8:17   0   32G  0 part /mnt
sdc      8:32   0  128G  0 disk
sr0     11:0    1  628K  0 rom  
# Premium SSD of 128 GB is attached to virtual machine, whose device name is sdc

[A] /usr/sap のブロックデバイスをフォーマットします。
```
sudo mkfs.xfs /dev/sdc
```
[A] マウントディレクトリを作成します。
```
sudo mkdir -p /usr/sap
```

[A] ブロックデバイスの UUID を取得します。

sudo blkid

# It will display information about block device. Copy UUID of the formatted block device

/dev/sdc: UUID="0eb5f6f8-fa77-42a6-b22d-7a9472b4dd1b" TYPE="xfs"

[A] /etc/fstab にファイルシステムのマウントエントリを維持します。

sudo echo "UUID=0eb5f6f8-fa77-42a6-b22d-7a9472b4dd1b /usr/sap xfs defaults,nofail 0 2" >> /etc/fstab

[A] ファイルシステムをマウントします。

sudo mount -a

sudo df -h

Filesystem                     Size  Used Avail Use% Mounted on
devtmpfs                       7.9G  8.0K  7.9G   1% /dev
tmpfs                          7.9G   82M  7.8G   2% /run
tmpfs                          7.9G     0  7.9G   0% /sys/fs/cgroup
/dev/sda4                       29G  1.8G   27G   6% /
tmpfs                          1.6G     0  1.6G   0% /run/user/1000
/dev/sda3                     1014M   87M  928M   9% /boot
/dev/sda2                      512M  1.1M  511M   1% /boot/efi
/dev/sdb1                       32G   49M   30G   1% /mnt
/dev/sdc                       128G   29G  100G  23% /usr/sap

Azure NetApp Files ボリュームのマウント

[A] マウントディレクトリを作成します。

sudo mkdir -p /usr/sap/frsinput
sudo mkdir -p /usr/sap/frsoutput

[A] NFSv4.1 マウントをサポートするようにクライアントの OS を構成します (NFSv4.1 を使用する場合のみ適用)。

NFSv4.1 プロトコルの Azure NetApp Files ボリュームを使用している場合は、Azure NetApp Files NFSv4.1 ボリュームをマウントする必要があるすべての VM で次の構成を実行します。

この手順では、NFS ドメイン設定を確認する必要があります。ドメインが既定の Azure NetApp Files ドメイン (defaultv4iddomain.com) として設定されており、マッピングが nobody に設定されていることを確認します。
```
sudo cat /etc/idmapd.conf
# Example
[General]
Domain = defaultv4iddomain.com
[Mapping]
Nobody-User = nobody
Nobody-Group = nobody
```
重要

VM 上の /etc/idmapd.conf で NFS ドメインを設定し、Azure NetApp Files のデフォルトのドメイン設定と一致させてください (defaultv4iddomain.com)。不一致がある場合、VM にマウントされている Azure NetApp Files ボリューム上のファイルのパーミッションが nobody と表示されます。

nfs4_disable_idmapping を確認します。これは Y に設定する必要があります。 nfs4_disable_idmapping が配置されるディレクトリ構造を作成するには、mount コマンドを実行します。アクセスがカーネル/ドライバー用に予約されるため、/sys/modules の下に手動でディレクトリを作成することはできなくなります。
```
# Check nfs4_disable_idmapping
cat /sys/module/nfs/parameters/nfs4_disable_idmapping

# If you need to set nfs4_disable_idmapping to Y
mkdir /mnt/tmp
mount -t nfs -o sec=sys,vers=4.1 10.31.2.4:/azusbobi-frsinput /mnt/tmp
umount /mnt/tmp

echo "Y" > /sys/module/nfs/parameters/nfs4_disable_idmapping

# Make the configuration permanent
echo "options nfs nfs4_disable_idmapping=Y" >> /etc/modprobe.d/nfs.conf
```

[A] マウントエントリを追加します。

NFSv3 を使用している場合:

sudo echo "10.31.2.4:/azusbobi-frsinput /usr/sap/frsinput  nfs   rw,hard,rsize=65536,wsize=65536,vers=3" >> /etc/fstab
sudo echo "10.31.2.4:/azusbobi-frsoutput /usr/sap/frsoutput  nfs   rw,hard,rsize=65536,wsize=65536,vers=3" >> /etc/fstab

NFSv4.1 を使用している場合:

sudo echo "10.31.2.4:/azusbobi-frsinput /usr/sap/frsinput  nfs   rw,hard,rsize=65536,wsize=65536,vers=4.1,sec=sys" >> /etc/fstab
sudo echo "10.31.2.4:/azusbobi-frsoutput /usr/sap/frsoutput  nfs   rw,hard,rsize=65536,wsize=65536,vers=4.1,sec=sys" >> /etc/fstab

[A] NFS ボリュームをマウントします。

sudo mount -a

sudo df -h

Filesystem                     Size  Used Avail Use% Mounted on
devtmpfs                       7.9G  8.0K  7.9G   1% /dev
tmpfs                          7.9G   82M  7.8G   2% /run
tmpfs                          7.9G     0  7.9G   0% /sys/fs/cgroup
/dev/sda4                       29G  1.8G   27G   6% /
tmpfs                          1.6G     0  1.6G   0% /run/user/1000
/dev/sda3                     1014M   87M  928M   9% /boot
/dev/sda2                      512M  1.1M  511M   1% /boot/efi
/dev/sdb1                       32G   49M   30G   1% /mnt
/dev/sdc                       128G   29G  100G  23% /usr/sap
10.31.2.4:/azusbobi-frsinput   101T   18G  100T   1% /usr/sap/frsinput
10.31.2.4:/azusbobi-frsoutput  100T  512K  100T   1% /usr/sap/frsoutput

Azure Database for MySQL の構成

このセクションでは、Azure portal を使用して Azure Database for MySQL をプロビジョニングする方法について詳しく説明します。また、SAP BOBI プラットフォーム用の CMS データベースと監査データベースの作成方法や、データベースにアクセスするためのユーザーアカウントについても説明しています。

このガイドラインは、Azure DB for MySQL を使用している場合にのみ適用されます。その他のデータベースの場合、手順については、SAP またはデータベース固有のドキュメントを参照してください。

データベースを作成する

Azure portal にサインインし、クイックスタート: Azure ポータルを使用して Azure Database for MySQL サーバーを作成するの手順に従います。ここでは、Azure Database for MySQL をプロビジョニングする際に注意すべき点をいくつか紹介します。

Azure Database for MySQL には、SAP BI プラットフォームアプリケーションサーバーが実行されているのと同じリージョンを選択します。
SAP BI の製品出荷マトリックス (PAM) に基づいて、お使いの SAP BOBI バージョンに固有のサポートされているデータベースバージョンを選択します。
[compute+storage (コンピューティングとストレージ)] で、 [Configure server (サーバーの構成)] を選択し、出力のサイズに応じて適切な価格レベルを選択します。
[ストレージの自動拡張] が既定で有効になります。ストレージはスケールアップのみ可能で、スケールダウンはできないことにご注意ください。
既定では、バックアップのリテンション期間は 7 日です。必要に応じて最大 35 日に設定できます。
既定では、Azure Database for MySQL のバックアップはローカルに冗長化されています。サーバーのバックアップを地理的に冗長なストレージに保存したい場合は、 [Backup Redundancy Options (バックアップ冗長オプション)] から [Geographically Redundant (地理冗長)] を選択します。

重要

サーバー作成後の [Backup Redundancy Options (バックアップ冗長オプション)] の変更はサポートされていません。

Note

プライベートリンク機能は、General Purpose または Memory Optimized のいずれかの価格レベルの Azure Database for MySQL サーバーにのみ使用可能です。データベースサーバーがこれらの価格レベルのいずれかであることを確認します。

Azure Private Link を構成する

このセクションでは、SAP BOBI 仮想マシンがプライベートエンドポイントを介して Azure Database for MySQL に接続するためのプライベートリンクを作成します。 Azure Private Link により、プライベート仮想ネットワーク内に Azure サービスが導入されます。

前のセクションで作成したデータベースを選択します。
[Security (セキュリティ)]>[プライベートエンドポイント接続] に移動します。
[プライベートエンドポイント接続] セクションで、 [プライベートエンドポイント] を選択します。
[サブスクリプション]>[リソースグループ]>[場所] を選択します。
プライベートエンドポイントの [名前] を入力します。
[リソース] セクションで、次を指定します。
- リソースの種類 - Microsoft.DBforMySQL/servers
- リソース: 前のセクションで作成した MySQL データベース
- 対象サブリソース - mysqlServer
[ネットワーク] セクションで、SAP BOBI アプリケーションをデプロイする [仮想ネットワーク] と [サブネット] を選択します。

Note

サブネットで有効なネットワークセキュリティグループ (NSG) がある場合、それはこのサブネットのプライベートエンドポイントに対してのみ無効になります。このサブネット上の他のリソースには引き続き NSG が強制されます。
[Integrate with private DNS zone (プライベート DNS ゾーンと統合する)] では、既定値 (はい) を使用します。
ドロップダウンリストからお使いの [プライベート DNS ゾーン] を選択します。
[Review+Create (確認と作成)] を選択して、プライベートエンドポイントを作成します。

詳細については、Azure Database for MySQL 用のプライベートリンクを参照してください。

CMS および監査データベースの作成

MySQL の Web サイトから MySQL Workbench をダウンロードしてインストールします。 MySQL Workbench は、必ず Azure Database for MySQL にアクセスできるサーバーにインストールします。
MySQL Workbench を使用したサーバーへの接続「接続情報を取得する」の手順に従います。接続テストが成功すると、次のメッセージが表示されます。

[SQL クエリ] タブで、次のクエリを実行して、CMS と監査データベースのスキーマを作成します。

# Here cmsbl1 is the database name of CMS database. You can provide the name you want for CMS database.
CREATE SCHEMA `cmsbl1` DEFAULT CHARACTER SET utf8;

# auditbl1 is the database name of Audit database. You can provide the name you want for CMS database.
CREATE SCHEMA `auditbl1` DEFAULT CHARACTER SET utf8;

スキーマに接続するためのユーザーアカウントを作成します。

# Create a user that can connect from any host, use the '%' wildcard as a host part
CREATE USER 'cmsadmin'@'%' IDENTIFIED BY 'password';
CREATE USER 'auditadmin'@'%' IDENTIFIED BY 'password';

# Grant all privileges to a user account over a specific database:
GRANT ALL PRIVILEGES ON cmsbl1.* TO 'cmsadmin'@'%' WITH GRANT OPTION;
GRANT ALL PRIVILEGES ON auditbl1.* TO 'auditadmin'@'%' WITH GRANT OPTION;

# Following any updates to the user privileges, be sure to save the changes by issuing the FLUSH PRIVILEGES
FLUSH PRIVILEGES;

MySQL ユーザーアカウントの権限とロールを確認するには

USE sys;
SHOW GRANTS for 'cmsadmin'@'%';
+------------------------------------------------------------------------+
| Grants for cmsadmin@%                                                  |
+------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO `cmsadmin`@`%`                                   |
| GRANT ALL PRIVILEGES ON `cmsbl1`.* TO `cmsadmin`@`%` WITH GRANT OPTION |
+------------------------------------------------------------------------+

USE sys;
SHOW GRANTS FOR 'auditadmin'@'%';
+----------------------------------------------------------------------------+
| Grants for auditadmin@%                                                    |
+----------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO `auditadmin`@`%`                                     |
| GRANT ALL PRIVILEGES ON `auditbl1`.* TO `auditadmin`@`%` WITH GRANT OPTION |
+----------------------------------------------------------------------------+

Linux サーバーへの MySQL C API コネクタのインストール

SAP BOBI アプリケーションサーバーからデータベースへのアクセスには、データベースクライアントドライバーが必要です。 CMS と監査データベースにアクセスするには、Linux 用の MySQL C API コネクタを使用する必要があります。 CMS データベースへの ODBC 接続はサポートされていません。このセクションでは、Linux で MySQL C API コネクタを設定する方法について説明します。

Azure Database for MySQL に対する MySQL ドライバーと管理ツールの互換性を参照してください。そのアーティクルで MySQL コネクタ/C (libmysqlclient) ドライバーについて確認します。
ドライバーをダウンロードするには MySQL 製品アーカイブを参照してください。
オペレーティングシステムを選択し、MySQL コネクタの共有コンポーネント rpm パッケージをダウンロードします。この例では、mysql-connector-c-shared-6.1.11 コネクタバージョンが使用されています。
すべての SAP BOBI アプリケーションインスタンスにコネクタをインストールします。
```
# Install rpm package
SLES: sudo zypper install <package>.rpm
RHEL: sudo yum install <package>.rpm
```

libmysqlclient.so のパスを確認します。

# Find the location of libmysqlclient.so file
whereis libmysqlclient

# sample output
libmysqlclient: /usr/lib64/libmysqlclient.so

LD_LIBRARY_PATH には、インストールに使用するユーザーアカウントの /usr/lib64 ディレクトリを指定します。

# This configuration is for bash shell. If you are using any other shell for sidadm, kindly set environment variable accordingly.
vi /home/bl1adm/.bashrc

export LD_LIBRARY_PATH=/usr/lib64

サーバーの準備

このセクションの手順では、次のプレフィックスを使用します。

[A] :この手順はすべてのホストに適用されます。

[A] Linux のフレーバー (SLES または RHEL) に基づいて、カーネルパラメーターを設定し、必要なライブラリをインストールする必要があります。 Business Intelligence プラットフォームインストールガイド (UNIX)のシステム要件のセクションを参照してください。
[A] コンピューターのタイムゾーンを適切に設定してください。インストールガイドの UNIX、Linux の追加要件のセクションを参照してください。
[A] ソフトウェアのバックグラウンドプロセスを実行できるユーザーアカウント (bl1adm) とグループ (sap sys) を作成します。このアカウントを使用してインストールを実行し、ソフトウェアを実行します。このアカウントにルート特権は必要ありません。
[A] ユーザーアカウント (bl1adm) の環境で、サポートされている UTF-8 のロケールを使用するように設定し、コンソールソフトウェアが UTF-8 の文字セットをサポートしていることを確認してください。オペレーティングシステムで正しいロケールが使用されるようにするには、(bl1adm) ユーザー環境で、LC_ALL と LANG 環境変数を優先ロケールに設定します。
```
# This configuration is for bash shell. If you are using any other shell for sidadm, kindly set environment variable accordingly.
vi /home/bl1adm/.bashrc

export LANG=en_US.utf8
export LC_ALL=en_US.utf8
```

[A] ユーザーアカウント (bl1adm) を構成します。

# Set ulimit for bl1adm to unlimited
root@azusbosl1:~> ulimit -f unlimited bl1adm
root@azusbosl1:~> ulimit -u unlimited bl1adm

root@azusbosl1:~> su - bl1adm
bl1adm@azusbosl1:~> ulimit -a

core file size          (blocks, -c) unlimited
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 63936
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

SAP サービスマーケットプレースから SAP BusinessObjects BI プラットフォームのメディアをダウンロードして抽出します。

インストール

サーバー上のユーザーアカウント bl1adm のロケールを確認します。

bl1adm@azusbosl1:~> locale
LANG=en_US.utf8
LC_ALL=en_US.utf8

SAP BOBI プラットフォームのメディアにアクセスし、bl1adm ユーザーで以下のコマンドを実行してください。

./setup.sh -InstallDir /usr/sap/BL1

SAP BOBI プラットフォームインストールガイド (UNIX) に従います。 SAP BOBI プラットフォームをインストールするときの注意点を次に示します。

[Configure Product Registration (製品登録の設定)] で、SAP ノート 1288121 にある SAP BusinessObjects ソリューションの一時ライセンスキーを使用するか、SAP サービスマーケットプレースでライセンスキーを生成することができます。
[Select Install Type (インストールの種類を選択)] で、 [Full (フル)] を選択し、最初のサーバーにインストールします (azusbosl1)。もう一方のサーバー (azusbosl2) では、 [Custom / Expand (カスタム/拡張)] を選択すると、既存の BOBI の設定が拡張されます。
[Select Default or Existing Database (デフォルトデータベースまたは既存データベースの選択)] で、 [configure an existing database (既存のデータベースの設定)] を選択します。これにより、CMS および監査データベースを選択するよう求められます。これらのデータベースの種類に対して [MySQL] を選択します。

インストール中に監査を構成しない場合は、 [No auditing database (監査データベースなし)] を選択することもできます。
[Select Java Web Application Server (Java Web アプリケーションサーバーの選択)] 画面で、使用している SAP BOBI アーキテクチャに基づいて適切なオプションを選択します。この例では、オプション 1 を選択しました。これにより、同じ SAP BOBI プラットフォームに Tomcat サーバーがインストールされます。
[CMS リポジトリデータベースの設定 - MySQL] に CMS データベースの情報を入力します。次は、Linux をインストールした場合の CMS データベース情報の入力例です。 Azure Database for MySQL には既定のポート 3306 が使用されます。
(オプション) 監査データベースの情報を [Configure Audit Repository Database - MySQL (監査リポジトリデータベースの設定 - MySQL)] に入力します。次の例では、Linux インストール向けの監査データベース情報の入力を示しています。
手順に従って必要な情報を入力し、インストールを完了させます。

複数インスタンスデプロイの場合は、2 台目のホスト (azusbosl2) でインストールセットアップを実行してください。 [Select Install Type]\(インストールの種類の選択\) で、[Custom / Expand]\(カスタム/拡張) を選択します。これにより、既存の BOBI セットアップを拡張します。

Azure Database for MySQL では、ゲートウェイを使用してサーバーインスタンスに接続をリダイレクトします。接続が確立すると、MySQL には、MySQL サーバーインスタンスで実行されている実際のバージョンではなく、ゲートウェイに設定されている MySQL のバージョンが表示されます。 MySQL サーバーインスタンスのバージョンを判断するには、MySQL プロンプトで SELECT VERSION(); コマンドを使用します。詳細については、サポートされている Azure Database for MySQL サーバーバージョンを参照してください。

LINUX 上の SAP BOBI デプロイ - CMC 設定を示すスクリーンショット。

# Run direct query to the database using MySQL Workbench

select version();

+-----------+
| version() |
+-----------+
| 8.0.15    |
+-----------+

インストール後

SAP BOBI プラットフォームの複数インスタンスのインストール後、アプリケーションの高可用性をサポートするために、設定後の追加手順を実行する必要があります。

クラスター名を構成します

SAP BOBI プラットフォームの複数インスタンスのデプロイでは、1 つのクラスターで複数の CMS サーバーを同時に実行する必要があります。クラスターは、共通の CMS システムデータベースに対して連携する 2 つ以上の CMS サーバーで構成されます。 CMS で実行されているノードで障害が発生した場合、別の CMS があるノードで BI プラットフォームの要求の処理が続けられます。 SAP BOBI プラットフォームの既定の設定では、クラスター名に、インストールした最初の CMS のホスト名が反映されます。

Linux でクラスター名を構成するには、SAP Business Intelligence プラットフォーム管理者ガイドの手順に従います。クラスター名を構成した後、SAP Note 1660440 に従って、CMC または BI ラウンチパッドのサインインページで既定のシステムエントリを設定します。

Azure NetApp Files に対する入力と出力の Filestore の場所を構成する

Filestore とは、実際の SAP BusinessObjects ファイルが存在するディスクディレクトリのことです。 SAP BOBI プラットフォーム用のファイルリポジトリサーバーの既定の場所は、ローカルインストールディレクトリ内にあります。複数インスタンスデプロイでは、Azure NetApp Files などの共有ストレージにファイルストアを設定することが重要です。これにより、すべてのストレージ層サーバーからファイルストアにアクセスできます。

NFS ボリュームをまだ作成していない場合は、次の手順で Azure NetApp Files に作成します。 (前述の「Azure NetApp Files のプロビジョニング」の手順に従ってください)
NFS ボリュームをマウントします。 (前述の「Azure NetApp Files ボリュームのマウント」の手順に従ってください)
SAP ノート 2512660 に従って、ファイルリポジトリ (入力と出力の両方) のパスを変更します。

Tomcat クラスタリングでのセッションレプリケーション

Tomcat を使用すると、セッションレプリケーションとフェールオーバーのために、2 つ以上のアプリケーションサーバーのクラスタリングがサポートされます。 SAP BOBI プラットフォームセッションはシリアル化されています。アプリケーションサーバーで障害が発生した場合でも、Tomcat の別のインスタンスへのユーザーセッションのシームレスなフェールオーバーが可能です。

たとえば、ユーザーが SAP BI アプリケーションでフォルダ階層をナビゲートしているときに、Web サーバーに障害が発生したとします。正しく構成されたクラスターでは、ユーザーはサインインページにリダイレクトされることなく、フォルダー階層内を移動できます。

SAP ノート 2808640 には、マルチキャストを使用して Tomcat クラスタリングを構成する手順が示されています。ただし、Azure ではマルチキャストはサポートされていません。そのため、Tomcat クラスターを Azure で機能させるには、StaticMembershipInterceptor を使用する必要があります (SAP ノート 2764907)。詳細については、ブログ記事 SAP BusinessObjects BI Platform の静的メンバーシップを使用した Tomcat クラスタリングを参照してください。

SAP BI プラットフォームの Web 層の負荷分散

SAP BOBI の複数インスタンスデプロイの場合、Java Web アプリケーションサーバー (Web 層) が 2 つ以上のホストで実行されています。 Web サーバー間でユーザー負荷を均等に分散するために、エンドユーザーと Web サーバーの間にロードバランサーを使用できます。 Azure で Azure Load Balancer または Azure Application Gateway を使用して、Web アプリケーションサーバーへのトラフィックを管理できます。各オファリングの詳細について次のセクションで説明します。

Azure Load Balancer

Azure Load Balancer は、ハイパフォーマンスかつ低レイテンシーのレイヤー4 (TCP、UDP) ロードバランサーです。正常な仮想マシン (VM) 間でトラフィックが分散されます。ロードバランサーの正常性プローブは、各 VM の特定のポートを監視し、稼働している VM にのみトラフィックを分散します。 SAP BI プラットフォームをインターネットからアクセスできるようにするかどうかに応じて、パブリックロードバランサーまたは内部ロードバランサーのいずれかを選択できます。ゾーン冗長であるため、可用性ゾーン全体で高可用性が確保されます。

以下の図では、内部 Azure Load Balancer のセクションを参照しています。 Web アプリケーションサーバーは、ポート 8080 (既定の Tomcat HTTP ポート) で実行され、正常性プローブによって監視されます。エンドユーザーから送信された受信要求は、Web アプリケーションサーバー (azusbosl1 または azusbosl2) にリダイレクトされます。 Azure Load Balancer で TLS/SSL 終端 (TLS/SSL オフロードとも呼ばれます) はサポートされていません。ロードバランサーを使用して Web サーバー間でトラフィックを分散する場合は、Standard Load Balancer を使用することを推奨します。

Note

パブリック IP アドレスのない VM が、内部の (パブリック IP アドレスのない) Standard Load Balancer のプール内に配置されている場合、パブリックエンドポイントへのルーティングを許可するように追加の構成が実行されない限り、送信インターネット接続はありません。詳細は、SAP の高可用性シナリオにおける Azure Standard Load Balancer を使用した仮想マシンのパブリックエンドポイント接続を参照してください。

Azure Load Balancer による Web サーバー間でのトラフィック分散を示した図。

Azure Application Gateway

Azure Application Gateway は、アプリケーションデリバリーコントローラー (ADC) をサービスとして提供します。このサービスは、アプリケーションがユーザーのトラフィックを 1 つまたは複数の Web アプリケーションサーバーに誘導するために使用されます。 TLS/SSL オフロード、Web Application Firewall (WAF)、Cookie ベースのセッションアフィニティなど、様々なレイヤー 7 の負荷分散機能を提供します。

Application Gateway によって、SAP BI プラットフォームはアプリケーション Web トラフィックを azusbosl1 または azusbos2 の指定されたリソースに誘導します。ユーザーはリスナーをポートに割り当て、ルールを作成し、リソースをプールに追加します。次の図では、Application Gateway には、ユーザーのエントリポイントとして機能するプライベート IP アドレス (10.31.3.20) があります。また、受信 TLS/SSL (HTTPS - TCP/443) 接続を処理し、TLS/SSL を復号化し、暗号化されていない要求 (HTTP - TCP/8080) をサーバーに渡します。 Application Gateway 上の TLS/SSL 証明書を 1 つだけ維持することで、運用が簡素化されます。

Application Gateway による Web サーバー間のトラフィック分散を示した図。

SAP BOBI Web サーバー用に Application Gateway を構成するには、ブログ記事 Azure Application Gateway を使用した SAP BOBI Web サーバーの負荷分散を参照してください。

Note

Web サーバーへのトラフィックをロードバランスするには、Azure Application Gateway が適しています。 SSL オフロード、サーバー上の暗号化と復号化のオーバーヘッドを削減するための一元的な SSL 管理、トラフィックを分散するためのラウンドロビンアルゴリズム、WAF 機能、高可用性などの便利な機能が提供されます。

Azure での SAP BOBI プラットフォームの信頼性

SAP BOBI プラットフォームには、特定のタスクと操作用に最適化されたさまざまな階層が含まれています。いずれかのレベルのコンポーネントが使用できなくなった場合、SAP BOBI アプリケーションは、その機能にアクセスできなくなるか、制限されます。ビジネスの中断なくアプリケーションが稼働し続けるには、各層が高い信頼性を持つように設計されている必要があります。

このガイドでは、Azure のネイティブ機能と SAP BOBI プラットフォームの構成の組み合わせにより、SAP デプロイの可用性を向上させる方法について説明します。ここでは、以下のオプションを中心に説明しています。

バックアップと復元: データとアプリケーションのコピーを別の場所に定期的に作成するプロセスです。元のデータやアプリケーションが失われたり破損したりした場合に、以前の状態に復元、復旧できます。
高可用性: 高可用性プラットフォームには、Azure リージョン内のあらゆるものが少なくとも 2 つずつ存在し、いずれかのサーバーが使用できなくなった場合でもアプリケーションが稼働し続けます。
ディザスターリカバリー: 自然災害により Azure のリージョン全体が利用できなくなるなど、壊滅的な損失が発生した場合に、アプリケーションの機能を回復させるプロセスです。

このソリューションの実装は、Azure のシステム設定の種類によって異なります。ビジネス要件に応じて、バックアップ/復元、高可用性、ディザスターリカバリーソリューションを調整します。

バックアップと復元

バックアップと復元はビジネスディザスターリカバリー戦略の不可欠な要素です。 SAP BOBI プラットフォームの包括的な戦略を策定するには、アプリケーションのシステムダウンタイムや中断につながるコンポーネントを特定します。 SAP BOBI プラットフォームでは、アプリケーションを保護するために、次のコンポーネントのバックアップが不可欠です。

SAP BOBI インストールディレクトリ (マネージド Premium ディスク)
ファイルリポジトリサーバー (Azure NetApp Files または Azure Premium Files)
CMS データベース (Azure Database for MySQL、または Azure Virtual Machines 上のデータベース)

次のセクションでは、これらのコンポーネントごとにバックアップと復元の戦略を実装する方法を説明します。

SAP BOBI インストールディレクトリのバックアップと復元

Azure において、アプリケーションサーバーおよび接続されているすべてのディスクをバックアップする最も簡単な方法は、Azure Backup を使用することです。 Azure Backup では、VM 上のデータが誤って破壊されることを防ぐために、独立して分離されたバックアップを提供しています。バックアップは、復旧ポイントの管理機能が組み込まれた Recovery Services コンテナーに格納されます。構成とスケーリングは単純で、バックアップは最適化され、必要に応じて簡単に復元することができます。

バックアッププロセスの一環として、スナップショットが取得され、運用環境のワークロードに影響を与えることなく、データがコンテナーに転送されます。詳細については、スナップショットの一貫性に関するページを参照してください。また、選択的なディスクバックアップと復元の機能を使用して、VM 内のデータディスクのサブセットをバックアップすることもできます。詳細については、Azure VM バックアップのドキュメントと、よくあるご質問 - Azure VM のバックアップを参照してください。

ファイルリポジトリサーバーのバックアップと復元

SAP BOBI を Linux でデプロイしている場合、SAP BOBI プラットフォームのファイルストアとして Azure NetApp Files を使用できます。 Filestore に使用するストレージに基づいて、バックアップと復元に関する次のオプションを選択します。

Azure NetApp Files の場合、スナップショットポリシーを使用して、オンデマンドのスナップショットを作成したり、自動スナップショットをスケジュールできます。スナップショットコピーによって、ボリュームの特定時点のコピーが提供されます。詳細については、「Azure NetApp Files を使用して、スナップショットを管理する」を参照してください。
NFS サーバーを別に作成した場合は、同じサーバーに対してバックアップと復元の戦略を実施してください。

CMS、監査データベースのバックアップと復元

Linux VM では、サポートされている任意のデータベースで CMS と監査データベースを実行できます。詳細については、サポートマトリックスに関するページをご覧ください。そのため、CMS と監査データストアに使用されているデータベースに基づいて、バックアップと復元の戦略を採用することが重要です。

Azure Database for MySQL は、サーバーのバックアップを自動的に作成し、ユーザーが構成したローカル冗長または geo 冗長ストレージに保存します。 Azure Database for MySQL では、データファイルとトランザクションログのバックアップが作成されます。サポートされている最大ストレージサイズに応じて、完全および差分バックアップ (最大 4 TB のストレージサーバー) またはスナップショットバックアップ (最大 16 TB のストレージサーバー) が作成されます。これらのバックアップを使用すると、サーバーを、構成済みのバックアップ保有期間内の任意の時点に復元できます。既定のバックアップ保持期間は 7 日間です。これは最大 3 日間まで必要に応じて構成できます。すべてのバックアップが、AES 256 ビット暗号化を使用して暗号化されます。これらのバックアップファイルはユーザーに公開されておらず、エクスポートできません。これらのバックアップは、Azure Database for MySQL の復元操作にのみ使用できます。 mysqldump を使用して、データベースをコピーできます。詳細については、「Azure Database for MySQL でのバックアップと復元」を参照してください。
Azure 仮想マシンにインストールされているデータベースの場合、サポートされているデータベース用の、標準のバックアップツールまたは Azure Backup を使用できます。また、すべての SAP BOBI プラットフォームコンポーネントのバックアップと復旧のためのエージェントが用意されている、サードパーティ製のバックアップツールを使用できます。

高可用性

高可用性とは、アプリケーションとサービスのビジネス継続性を提供することで、IT の中断を最小限に抑える一連のテクノロジを指します。これは、同じデータセンター内の冗長、フォールトトレラント、またはフェールオーバーで保護されたコンポーネントを介して行われます。今回の場合、データセンターは 1 つの Azure リージョン内にあります。詳細については、SAP のための高可用性のアーキテクチャとシナリオを参照してください。

SAP BOBI プラットフォームのサイズ設定の結果に基づいて、ランドスケープを設計し、Azure Virtual Machines およびサブネット全体での BI コンポーネントの分散を決定する必要があります。分散アーキテクチャの冗長性レベルは、ビジネスに必要な目標復旧時間 (RTO) と目標復旧時点 (RPO) によって異なります。 SAP BOBI プラットフォームには異なる複数の層が含まれており、各層のコンポーネントを、冗長性を実現するように設計する必要があります。次に例を示します。

BI アプリケーションサーバーや Web サーバーなどの冗長アプリケーションサーバー
CMS データベース、ファイルリポジトリサーバー、ロードバランサーなどの固有のコンポーネント。

次のセクションでは、SAP BOBI プラットフォームの各コンポーネントで高可用性を実現する方法について説明します。

アプリケーションサーバーの高可用性

冗長性を採用することで、アプリケーションサーバーの高可用性を実現できます。これを行うには、さまざまな Azure VM で BI サーバーと Web サーバーの複数のインスタンスを構成します。

計画された、および計画外のイベントによるダウンタイムの影響を軽減するには、高可用性アーキテクチャのガイダンスに従うことをお勧めします。

詳細については、Linux 仮想マシンの可用性の管理を参照してください。

重要

Azure Availability Zones と Azure 可用性セットの概念は、相互に排他的です。つまり、2つまたはそれ以上の VM を、特定の可用性ゾーンまたは Azure 可用性セットのいずれかにデプロイすることができますが、両方にはデプロイできません。
可用性ゾーン間でのデプロイを計画している場合は、標準の可用性ゾーンのデプロイよりも、FD=1 の柔軟性の高いスケールセットを使用することをお勧めします。

CMS データベースの高可用性

CMS や監査データベースに、Azure Database for MySQL を使用している場合、既定ではローカル冗長の高可用性フレームワークがあります。ユーザーは、高可用性、冗長性、回復性の各機能が最初から備わっているリージョンとサービスを選択するだけで済み、追加のコンポーネントを構成する必要がありません。 SAP BOBI プラットフォームのデプロイ戦略が可用性ゾーンをまたがっている場合は、CMS および監査データベースに対してゾーン冗長を実現する必要があります。詳細については、Azure Database for MySQL での高可用性と、Azure SQL Database での高可用性を参照してください。

CMS データベースのその他のデプロイについては、SAP Workload 用の DBMS 導入ガイドの高可用性に関する情報を参照してください。

Filestore の高可用性

Filestore とは、レポート、ユニバース、接続などの内容が格納されているディスクディレクトリのことです。それは、そのシステムのすべてのアプリケーションサーバー間で共有されます。そのため、他の SAP BOBI プラットフォームコンポーネントと共に、高可用性が確保されるようにする必要があります。

Linux 上で実行されている SAP BOBI プラットフォームの場合、高可用性と高い耐久性を実現するように設計された Azure Premium Files または Azure NetApp Files をファイル共有のために選択できます。詳細については、Azure Files の冗長性を参照してください。

なお、このファイル共有サービスは一部のリージョンでは利用できません。詳細については、リージョン別の利用可能な製品を参照してください。お使いのリージョンでサービスを利用できない場合は、NFS サーバーを作成し、そのファイルシステムを SAP BOBI アプリケーションと共有できます。しかし、高可用性を考慮する必要もあります。

ロードバランサーの高可用性

Web サーバー全体でトラフィックを分散するには、Azure Load Balancer または Azure Application Gateway のいずれかを使用できます。デプロイ用に選択した SKU に基づいて、どちらの冗長性も実現できます。

Azure Load Balancer の場合、Standard Load Balancer をゾーン冗長として構成することで冗長性を実現できます。詳細については、「Standard Load Balancer と可用性ゾーン」をご覧ください。
Application Gateway の場合、デプロイ中に選択した層の種類に基づいて高可用性を実現できます。
- v1 SKU を使用すると、2 つ以上のインスタンスをデプロイした場合に高可用性シナリオがサポートされます。 Azure は、これらのインスタンスを更新ドメインと障害ドメインに分散させ、全インスタンスで同時に障害が発生しないようにします。ゾーン内で冗長性を実現します。
- v2 SKU を使用すると、新しいインスタンスが障害ドメインと更新ドメインに自動的に分散されます。ゾーン冗長を選択した場合は、ゾーン障害回復性を提供するために、最新のインスタンスが可用性ゾーンにも分散されます。詳細については、自動スケーリングとゾーン冗長 Application Gateway v2を参照してください。

SAP BOBI プラットフォームのリファレンス高可用性アーキテクチャ

次の図は、Linux サーバーで実行されている SAP BOBI プラットフォームのセットアップを示しています。このアーキテクチャでは、Azure Application Gateway、Azure NetApp Files、Azure Database for MySQL など、さまざまなサービスの利用を紹介しています。これらのサービスでは、組み込みのゾーン冗長性が提供されるため、異なる複数の高可用性ソリューションを管理する複雑さが軽減されます。

受信トラフィック (HTTPS) は、2 つ以上のインスタンスにデプロイされた場合に高可用性を提供する Azure Application Gateway v1 または v2 SKU を使用して負荷分散されていることに注目してください。冗長性を確保するために、Web サーバー、管理サーバー、処理サーバーの複数のインスタンスが別々の VM にデプロイされます。 Azure NetApp Files では、データセンター内に冗長性が組み込まれているため、ファイルリポジトリサーバー用の Azure NetApp Files ボリュームは高可用性が確保されます。 CMS データベースは、高可用性が最初から備わっている Azure Database for MySQL 上にプロビジョニングされます。詳細については、Azure Database for MySQL での高可用性を参照してください。

可用性セットを使用した SAP BusinessObjects BI プラットフォームの冗長性を示す図。

上記のアーキテクチャから、Azure での SAP BOBI デプロイの実行方法に関する洞察が得られます。ただし、すべての構成オプションを網羅しているわけではありません。ビジネス要件に基づいて、デプロイをカスタマイズできます。

複数の Azure リージョンでは、可用性ゾーンを使用できます。これは、独立した電源、冷却装置、およびネットワークを利用できることを意味します。これにより、お客様は 2 つまたは 3 つの可用性ゾーンにまたがってアプリケーションをデプロイできます。可用性ゾーンをまたいで高可用性を実現したい場合は、アプリケーションの各コンポーネントがゾーン冗長化されていることを確認した上で、SAP BOBI プラットフォームをこれらのゾーンにデプロイできます。

障害復旧

ここでは、Linux 上で動作する SAP BOBI プラットフォームのディザスターリカバリー対策を説明します。それにより、SAP のディザスターリカバリーアプローチ全体の主要なリソースを表す SAP のディザスターリカバリードキュメントを補完します。 SAP BOBI プラットフォームについては、SAP ノート 2056228 を参照し、ディザスターリカバリー環境を安全に導入するための以下の方法を説明しています。

プライマリシステムからコンテンツを昇格または配布するための、ライフサイクル管理またはフェデレーションの完全または選択的な使用。
CMS、ファイルリポジトリサーバーのコンテンツを定期的にコピーする。

このガイドでは、2 番目のオプションについて説明します。ここでは、ディザスターリカバリーのためのすべての可能な構成オプションを網羅しませんが、ネイティブな Azure サービスと SAP BOBI プラットフォームの構成を組み合わせたソリューションを取り上げています。

重要

SAP BOBI プラットフォームの各コンポーネントの可用性をセカンダリリージョンに織り込んで、ディザスターリカバリー戦略全体を徹底的にテストする必要があります。
SAP BI プラットフォームが FD=1 のフレキシブルスケールセットで構成されている場合は、PowerShell を使用してディザスターリカバリー用に Azure Site Recovery を設定する必要があります。現時点では、それが、スケールセットにデプロイされた VM のディザスターリカバリーの構成に使用できる唯一の方法です。

SAP BOBI プラットフォームのディザスターリカバリーの参照アーキテクチャ

この参照アーキテクチャでは、冗長なアプリケーションサーバーを使用した SAP BOBI プラットフォームの複数インスタンスデプロイが実行されています。ディザスターリカバリーの場合、SAP BOBI プラットフォームのすべてのコンポーネントをセカンダリリージョンにフェールオーバーする必要があります。次の図では、Azure NetApp Files を、CMS と監査リポジトリとしての filestore、Azure Database for MySQL として使用し、ロードバランサーとして Azure Application Gateway を使用しています。各コンポーネントのディザスターリカバリー保護を実現する方法は異なります。詳細については、次のセクションで説明します。

SAP BusinessObjects BI プラットフォームのディザスターリカバリーを示した図。

Load Balancer

ロードバランサーは、SAP BOBI プラットフォームの Web アプリケーションサーバー間でトラフィックを分散するために使用されます。 Azure では、この目的のために、Azure Load Balancer か Azure Application Gateway を使用できます。ロードバランサーサービスのディザスターリカバリーを実現するには、セカンダリリージョンに別の Azure Load Balancer または Azure Application Gateway を実装する必要があります。ディザスターリカバリーフェールオーバー後に同じ URL を保持するには、セカンダリリージョンで実行されている負荷分散サービスを指すように、DNS のエントリを変更する必要があります。

Web および BI アプリケーションサーバーを実行している VM

Azure Site Recovery を使用して、Web および BI アプリケーションサーバーを実行している VM をセカンダリリージョン上でレプリケートできます。災害や障害が発生したときに、レプリケートされた環境に簡単にフェールオーバーして作業を続けることができるように、サーバーとそれにアタッチされているすべてのマネージドディスクがセカンダリリージョンにレプリケートされます。 Azure ディザスターリカバリーデータセンターへのすべての SAP アプリケーション VM のレプリケートを開始するには、「仮想マシンを Azure にレプリケートする」の手順に従います。

ファイルリポジトリサーバー

ファイルストアは、レポートや BI ドキュメントなどの実際のファイルが格納されているディスクディレクトリです。ファイルストア内のすべてのファイルがディザスターリカバリーリージョンと同期されていることが重要です。 Linux で実行されている SAP BOBI プラットフォームに使用しているファイル共有サービスの種類に基づいて、コンテンツを同期するために必要なディザスターリカバリー戦略を採用する必要があります。

Azure NetApp Files によって NFS および SMB ボリュームが提供されるため、ファイルベースの任意のコピーツールを使用して、Azure リージョン間でデータをレプリケートできます。別のリージョンにあるボリュームをコピーする方法の詳細については、Azure NetApp Files に関するよくあるご質問を参照してください。

Azure NetApp Files リージョン間レプリケーションを使用できます。これは現在プレビュー段階です。変更されたブロックだけが、圧縮された効率的な形式でネットワーク経由で送信されます。これにより、リージョン間でのレプリケーションに必要なデータ量が最小限に抑えられるため、データ転送コストが削減されます。また、レプリケーションにかかる時間が短縮されるため、より小さい RPO を実現できます。詳細については、「リージョン間レプリケーションを使用するための要件と考慮事項」を参照してください。
Azure Premium Files を使用する場合、ローカル冗長 (LRS) およびゾーン冗長ストレージ (ZRS) のみがサポートされます。ディザスターリカバリー戦略を使用する場合、AzCopy または Azure PowerShell を使用して、異なるリージョンの別のストレージアカウントにファイルをコピーすることができます。詳細については、「ディザスターリカバリーとストレージアカウントのフェールオーバー」を参照してください。

重要

Azure Files の SMB プロトコルは一般公開されていますが、Azure Files の NFS プロトコルサポートは現在プレビューの段階です。詳細については、Azure Files での NFS 4.1 サポートのプレビューが開始されましたを参照してください。

CMS データベース

ディザスターリカバリーリージョンの CMS や監査データベースは、プライマリリージョンで実行されているデータベースのコピーである必要があります。データベースの種類によっては、ビジネスで必要とされる RTO と RPO に基づいて、データベースをディザスターリカバリーリージョンにコピーすることが重要です。

Azure Database for MySQL

Azure Database for MySQL には、障害が発生した場合にデータベースを復旧するための複数のオプションが用意されています。ご自身のビジネスに適したオプションを選択してください。

事業継続とディザスターリカバリーの計画を強化するには、リージョンにまたがる読み取りレプリカを有効にします。ソースサーバーから最大 5 つのレプリカにレプリケートできます。読み取りレプリカは、MySQL のバイナリログレプリケーションテクノロジを使用して非同期的に更新されます。レプリカは、通常の Azure Database for MySQL 内のサーバーと同様に管理する新しいサーバーです。詳細については、Azure Database for MySQL での読み取りレプリカを参照してください。
geo-restore 機能では、geo 冗長バックアップを使用してサーバーを復元します。これらのバックアップは、サーバーがホストされているリージョンがオフラインのときでもアクセスできます。これらのバックアップから他の任意のリージョンに復元し、サーバーをオンラインに戻すことができます。

Note

geo リストアは、geo 冗長バックアップストレージでサーバーをプロビジョニングした場合にのみ可能です。サーバー作成後の [Backup Redundancy Options (バックアップ冗長オプション)] の変更はサポートされていません。詳細については、バックアップの冗長性に関する記事をご覧ください。

次の表は、この例で使用した各階層のディザスターリカバリーに関する推奨事項です。

SAP BOBI プラットフォームの層	推奨
Azure Application Gateway	セカンダリリージョンでの Application Gateway の並列セットアップ。
Web アプリケーションサーバー	Azure Site Recovery を使ったレプリケーション。
BI アプリケーションサーバー	Site Recovery を使ったレプリケーション。
Azure NetApp Files	ファイルベースのコピーツールで、セカンダリリージョンにデータを複製したり、クロスリージョンレプリケーションを使用します。
Azure Database for MySQL	クロスリージョンでの読み取りレプリカや、geo-redundant バックアップからの復元が可能です。

次の方法で共有

Linux on Azure 向け SAP BusinessObjects BI プラットフォーム デプロイ ガイド

Azure portal を使用した Linux 仮想マシンのデプロイ

Azure NetApp Files のプロビジョニング

Azure NetApp Files リソースのデプロイ

重要な考慮事項

Linux サーバーでのファイル システムの構成

SAP ファイル システムのフォーマットとマウント

Azure NetApp Files ボリュームのマウント

Azure Database for MySQL の構成

データベースを作成する

Azure Private Link を構成する

CMS および監査データベースの作成

Linux サーバーへの MySQL C API コネクタのインストール

サーバーの準備

インストール

インストール後

クラスター名を構成します

Azure NetApp Files に対する入力と出力の Filestore の場所を構成する

Tomcat クラスタリングでのセッション レプリケーション

SAP BI プラットフォームの Web 層の負荷分散

Azure Load Balancer

Azure Application Gateway

Azure での SAP BOBI プラットフォームの信頼性

バックアップと復元

SAP BOBI インストール ディレクトリのバックアップと復元

ファイル リポジトリ サーバーのバックアップと復元

CMS、監査データベースのバックアップと復元

高可用性

アプリケーション サーバーの高可用性

CMS データベースの高可用性

Filestore の高可用性

ロード バランサーの高可用性

SAP BOBI プラットフォームのリファレンス高可用性アーキテクチャ

障害復旧

SAP BOBI プラットフォームのディザスター リカバリーの参照アーキテクチャ

Load Balancer

Web および BI アプリケーション サーバーを実行している VM

ファイル リポジトリ サーバー

CMS データベース

Azure Database for MySQL

次の手順

フィードバック

その他のリソース

Linux on Azure 向け SAP BusinessObjects BI プラットフォームデプロイガイド

Linux サーバーでのファイルシステムの構成

SAP ファイルシステムのフォーマットとマウント

Tomcat クラスタリングでのセッションレプリケーション

SAP BOBI インストールディレクトリのバックアップと復元

ファイルリポジトリサーバーのバックアップと復元

アプリケーションサーバーの高可用性

ロードバランサーの高可用性

SAP BOBI プラットフォームのディザスターリカバリーの参照アーキテクチャ

Web および BI アプリケーションサーバーを実行している VM

ファイルリポジトリサーバー