JD Cloud を使用して高可用性ビジネス アーキテクチャを構築する方法

著者: Zhang Jiuzhi、JD Cloud

この記事は、2022 年の実際のプロジェクトに基づいて、JD Cloud 上で高可用性ビジネスを構築するプロセス全体を説明します。パブリック クラウドとプライベート クラウドのお客様は、JD Cloud の柔軟な IAAS および PAAS サービスを使用して、可用性、伸縮性、拡張性、セキュリティに優れたクラウド ビジネス環境を構築し、ビジネス SLA を改善し、運用と保守の自動化レベルを高め、リソース コストと運用と保守のコストを削減できます。クラウドへのビジネス移行のニーズがあり、クラウド上で高可用性ビジネス アーキテクチャを構築したいと考えているお客様、またはクラウド上で高可用性アーキテクチャを計画することに関心のある読者は、ぜひご覧ください。

顧客のビジネスは典型的な Web アプリケーションです。パブリック IP/ドメイン名を介してアクセスされる、可用性の高い Web サイトが JD Cloud 上に作成されます。アクセス層、APP 層、キャッシュ層、データベース層など、一般的なアプリケーション用の標準フレームワークが含まれています。全体的なビジネス アーキテクチャ設計により、可用性ゾーン (AZ) レベルで高可用性が実現します。

この記事で紹介するシナリオには、単一の AZ 障害によって引き起こされるホスト障害、データベース障害、キャッシュ障害が含まれており、ビジネスは継続的なアクセス機能を提供できます。また、データの整合性と一貫性も保証されます。同時に、人間の介入なしにビジネスの弾力的な拡張を実現し、ビジネスの同時実行性が高いシナリオでも良好な応答時間を確保できます。

例:

この記事のアーキテクチャはデモンストレーション アーキテクチャであり、運用環境におけるビジネス パフォーマンスとセキュリティの全体的な計画手順や要件に厳密に従うものではありません。実稼働環境では、少なくともホストと CFS のストレージ パフォーマンスをストレス テストして、実際のビジネス ニーズを満たすことができることを確認する必要があります。同時に、ドメイン名を通じてアクセスされるWebサービスについては、業務入口のセキュリティを確保するために、WAFなどのセキュリティ保護製品を使用することをお勧めします。

1. JD Cloud 高可用性アーキテクチャ設計

ビジネス アーキテクチャは、特定のユニットのビジネス ニーズに基づいて、そのビジネス実稼働環境をシミュレートし、JD Cloud 上で全体的なビジネス アーキテクチャを計画します。このうち、NAT ゲートウェイ、ロード バランシング、および要塞ホストはすべてパブリック ネットワーク アクセス サブネットに作成され、残りのホストとデータベースは内部サブネットに作成されます。

アプリケーション ホストは高可用性グループを使用して作成され、LB バックエンドは高可用性グループに直接マウントされます。

高可用性グループを使用する目的は、ビジネスのピーク時に障害が発生した場合に、コンピューティング リソースが負荷分散バックエンドに自動的に追加され、ビジネス処理機能が自動的に拡張されるようにすることです。運用および保守介入コストを削減します。

2. リソース要件（すべての IP と URL は非実際の IP と URL に調整されます）

3. アプリケーションの展開

3.1 基本的な環境の準備

典型的な WordPress ウェブサイトを例にとると、ビジネスはコンテナ化され、クラウド ホストに展開されます。高可用性は、JD Cloud のクラウド ホスト高可用性グループに依存します。 Docker がホストにインストールされ、Docker サービスが自動的に起動するように構成されています。

 #アプリケーション データ ディレクトリを作成し、ディレクトリ権限を構成し、docker をインストールします。

 mkdir -p / wp

 chmod 777 / wp

 yum で docker をインストール vim -y

 systemctl ドッカーを有効にする

 systemctl ドッカーを起動する

 #CFSファイルをアプリケーションデータディレクトリとしてマウントする

 yum インストール nfs - utils - y

 systemctl rpcbind を有効にする

 systemctl rpcbind を起動します

 マウント-t nfs -o vers = 3 -o noresvport 10.0 .0 .200 : / cfs / wp

 # rc.localを通じて実装される自動 CFS マウントおよびサービス起動を構成します。

 # [ root@wpha0 wp ] # cat / etc / rc .local

 # !/ bin / bash

 # このファイルは互換性のために追加されました

#

 # 独自のsystemdサービスまたはudevルールを作成することを強くお勧めします

# このファイルを使用する代わりに、起動時にスクリプトを実行します。

 #

 # 以前のバージョンとは異なり、起動時の並列実行により

# このスクリプトは他のすべてのサービスの後には実行されません。

 #

 # 'chmod +x /etc/rc.d/rc.local'を実行して、

 # このスクリプトは起動時に実行されます。

タッチ/ var /ロック/ subsys /ローカル

マウント-t nfs -o vers = 3 -o noresvport 10.0 .0 .200 : / cfs / wp

 # (注: 本番環境は/ etc / fstab にマウントできます)

 bash / root / .shを起動する

.shを起動し、次のコードを参照してください

[ root@wpha0 wp ] # cat / root / start .sh

 docker 停止 wordpress

睡眠3

 docker rm ワードプレス

睡眠3

 docker run -d --name=wordpress --restart=unless-stopped -p 443:443 -p 80:80 -v /wp:/var/www/html wordpress

 # [ root@wpha0 wp ] #

 #起動スクリプトを編集してrc.localに書き込んだ後、 rc.local は実行可能に調整され、ホストを起動してスクリプトを実行します。 rc.local は、ホストの起動後に指定されたディレクトリに CFS を自動的にマウントし、 start.shを通じて古いデータを自動的にクリアして、WordPress サービスを再起動します。

 chmod + x /etc/rc.d/rc.local

 #アプリケーションに必要なイメージを取得する

 docker プル ワードプレス

#イメージをプルした後、サービスを実行します。

 docker run -d --name=wordpress --restart=unless-stopped -p 443:443 -p 80:80 -v /wp:/var/www/html wordpress

このシナリオでは、主にいくつかのポジションが調整されることに注意してください。

1. WordPress の作業ディレクトリとして CFS をマウントします。この方法では、ページ コンテンツを調整して新しいホストを起動した後も、Web サイトのコンテンツの一貫性が維持されます。関連する自動マウント方法は、/etc/rc.local にマウント コマンドを追加し、chmod +x /etc/rc.d/rc.local によってこのファイルに実行権限を追加することです。

2. wp ディレクトリの権限を 777 (または docker 内の 33 テープなど。バージョンによって異なる場合がありますが、777 に変更するのは比較的安全です) に変更する必要があります。そうしないと、マウント後に docker 内の wordpress はディレクトリの読み取りおよび書き込み権限を取得できなくなります。

3. NFS マウントには、nfs プラグイン yum install nfs-utils -y をインストールし、rpc サービス systemctl enable rpcbind systemctl start rpcbind を開始する必要があります。

WPディレクトリには777の権限があります

この時点で、基本的なホスト環境は準備完了です。

次のステップは、高可用性の視覚的なデモンストレーション効果を実現するように WordPress アプリケーションを構成することです。

3.2 ビジネスサイドのWordPress設定

Web アプリケーションは WordPress を使用してデプロイされます。 Docker を介してデプロイすることで、高可用性グループ ホストの自動スケーリングと自動プルアップを実現できます。

docker 経由で WordPress をプルする

docker プル ワードプレス

画像をプルした後

docker run -d --name=wordpress --restart=unless-stopped -p 443:443 -p 80:80 -v /wp:/var/www/html wordpress

/wp はマウントされた CFS であり、複数のアプリケーション ホストによって一緒にマウントされ、WordPress アプリケーションのアプリケーション ファイル ディレクトリとして機能します。

wordpress コンテナを起動し、CFS ディレクトリを WP アプリケーション ディレクトリとしてマウントします。

上記の展開は3.1で完了しました。

事前準備 - 負荷分散:

パブリック IP を使用してロード バランサーを構成し、リスナーを構成します。リスナー バックエンドは、すでに Docker を起動しているホストで一時的に構成されます。

事前準備 - データベース:

ウェブサイトを構成する前に、まずクラウド コンソールの RDS に WordPress のアカウント (wordpress) を作成し、パスワードを設定し、ライブラリ (wordpress) を作成し (その後のデモ プランが調整されたため、新しいライブラリ wordpressbackup を作成しましたが、実際にはライブラリは 1 つで十分です)、wordpress ユーザーに wordpress ライブラリを承認する必要があります。

事前準備 - redis:

コンソールで Redis を購入し、Redis の URL を記録して、その後の Redis キャッシュの構成の準備をします。

これで基本的なアプリケーション環境が整いました。

ブラウザから負荷分散 IP の 80 ポートにアクセスし (ホストに直接アクセスするのではなく、LB にアクセスする必要があることに注意してください)、WordPress 構成ページに入ります。 WordPress の設定には、主にデータベース アドレスとデータベース プレフィックスの設定が含まれます。正しいデータベース ホスト アドレスとパスワードを入力し、残りはデフォルトのままにします。デフォルト設定を維持するには、公式 Web サイトのマニュアルに従ってください。

設定が完了すると、WordPress は Web サイトに関連するテーブルを自動的に作成し、WordPress 管理者と管理パスワードを設定するように要求します。

インストールが完了したら、データベースにログインして作成されたテーブルを表示できます。後続の MySQL 高可用性デモンストレーション中に、高可用性スイッチの影響を受けずにデータベースにログインしていくつかの日常的な操作を実行することもできます。

この時点で、基本的なアプリケーションのインストールは完了です。

Redis 動的キャッシュ アクセラレーションを設定します。

Redis の役割。この場合、redis は WordPress の動的加速キャッシュとして使用され、Web サイトへのアクセスを高速化し、データベースの負荷を軽減する役割を果たします。

WordPress 用の redis プラグイン redis-cache をダウンロードします。

ダウンロード後、WordPress管理ページ - plugin --addnew から直接アップロードし、プラグインのマニュアルに従ってインストールおよび設定してください。

redis-cache をインストールすると、/wp/wp-content/plugins ディレクトリに redis-cache ディレクトリが生成されます。同時に、/wp/wp-content の下に object-cache.php ファイルを生成する必要があります。通常、パラメータ host を redis のドメイン名に調整する必要があります。パスワードが設定されている場合は、これと redis-cache ディレクトリ内の設定ファイルを調整してパスワードを設定する必要があります。これはデモ環境であり、redis はパスワードなしで設定されているためです。運用環境ではパスワードを設定する必要があります。

インストールと設定が完了すると、管理インターフェースの設定に Redis 設定オプションが表示されます。これはバージョンに関係します。一部のバージョンでは、ここでパラメータの設定が必要になる場合があります。ファイルパラメータを直接変更しても同じ効果が得られます。

mysql および redis の管理と関連するログイン方法の紹介:

• MySQL ログイン、クライアントはインストールされていない、mysql docker を使用
• 関連コマンド:
• docker run --name mysql -p 3306:3306 --restart=unless-stopped -v /root/dbackup/:/db -e MYSQL_ROOT_PASSWORD=123456 -d mysql:5.7
• mysql docker を入力します:
• docker exec -it mysql bash
• wordpress が使用するデータベースに接続します。
• mysql -h mysql-xxxea04fc4c52.jdcloud.com -u wordpress -p
• wordpressbackup を使用します。
• テーブルを表示します。
• wpbackup_posts から ID を選択します。
• -- 多くの訓練とデータベースの切り替えを行ったため、WordPress データベースのエクスポートとインポート操作も行いました。
• mysql データベースをエクスポートします (すべてのコマンドは mysql docker コンテナ内で実行されます)。
• mysqldump -h mysql-xxxa04fc4c52.jdcloud.com -uwordpress -p --databases wordpressbackup >/db/wordpressbackup-0322.sql
• データのインポート:
• データベースに入り、
• wordpressbackup を使用します。
• ソース /db/wordpressbackup-0322.sql;
• ----redis 検証
• Redis の検証では、クライアントをインストールせずに、docker のコマンドラインから接続します。
• docker run -d --name redis --memory=1G -p 7379:6379 redis
• docker exec -it redis bash
• redis-cli -h redis-j49rpxxx.jdcloud.com
• ログイン後、情報を表示します:
• キー *

WordPressはホームページにホスト名とソースIPを表示するように設定します

--- WordPress にホスト名を取得させてページに表示させ、訪問者のアドレスを取得してデモンストレーション効果を高め、訪問した実際のホストの場所を明確に確認します。

訪問者がどの IP アドレスにアクセスしているかを確認できるようにするには (高可用性グループの自動拡張とビジネスの自動起動を確認するため)、使用するテーマ ディレクトリの機能に関連コードを追加する必要があります。 /wp/wp-content/themes/twentytwentytwo/function.php

[root@AG-wordpress- HA-group1-c8705-2 twentytwo]# vim /wp/wp-content/themes/twentytwentytwo/function.php

そこに次のコードを追加します。1 つは show_ip 関数で、もう 1 つは show_hostname 関数です。

関数 get_the_user_ip ( ) {
 if ( !空( $_SERVER [ "HTTP_CLIENT_IP" ] ) ) {
 //共有インターネットからIP をチェック
$ip = $_SERVER [ "HTTP_CLIENT_IP" ] ;
 } elseif ( !空( $_SERVER [ "HTTP_X_FORWARDED_FOR" ] ) ) {
 //プロキシからIP が渡されているか確認する
$ip = $_SERVER [ "HTTP_X_FORWARDED_FOR" ] ;
 }それ以外{
 $ip = $_SERVER [ "REMOTE_ADDR" ] ;
 }
 apply_filters ( "wpb_get_ip " 、 $ip )を返します。
 }
ショートコードを追加します( "show_ip" 、 "get_the_user_ip" ) ;

関数 get_hostname ( )
 {
 $hostname = gethostname ( ) ;
 echo "$hostname\n" ;
 apply_filters ( "hostname" 、 $hostname )を返します。
 }

ショートコードを追加します( 「show_hostname」 、 「get_hostname」 ) ;

次に、WordPress サイトにショートコードを追加します。

保存すると、ページに関連する IP とホスト名の情報が表示されることがわかります。

この時点で、WordPress アプリケーション環境の構成は完了です。

次のステップは、ビジネス用の高可用性環境を構成し、AZ 間の高可用性グループとホストの自動エラスティック スケーリングを実装することです。

3.3 インスタンステンプレート、高可用性グループ、LB 構成

単一のホストを構成した後、それを再起動するとアプリケーションが自動的に起動します。確認後、既存のホストがミラーリングされます。高可用性グループのインスタンスのテンプレートとして機能します。後続の LB バックエンド高可用性グループは、このテンプレートを使用してホストを作成します。

データベース構成、Web サイト データ、Redis キャッシュ構成など、残りのすべてでサービスとデータの分離が実現されます。そのため、後期に動的エラスティック拡張を実行する場合、このテンプレートを使用する高可用性グループはサービスを直接プルアップし、動的エラスティックスケーリングを実現できます。

テンプレートの例:

高可用性グループ:

高可用性グループは、WordPress が構築されているアプリケーション ホストのイメージを使用します。高可用性グループは、新しいホストを自動的かつ弾力的にスケールアウトできます。新しいホストは WordPress アプリケーションを自動的に起動し、新しいホストはビジネス トラフィックを受信するために LB に自動的にマウントされます。

LB 構成。

LB リスナーは、バックエンド サービスを高可用性グループとして選択し、ヘルス チェックを構成します。

高可用性グループが LB バックエンドにマウントされると、アプリケーション環境が構築されます。

LB の入り口にアクセスしたり、Web サイトにアクセスしたり、さまざまなサーバーをポーリングしたりできます。同時に、単一サーバーの外部 IP にアクセスして Web サイト ビジネスにアクセスすることもできます。

LB アクセス スクリーンショット (2 枚の写真、それぞれ 2 つのホストにアクセス)

単一ホスト アクセスのスクリーンショット (単一ホスト IP に直接アクセスします。更新後にホストはポーリングされません):

デモ環境が準備できました。

次のステップは、破壊的な訓練を実施して高可用性環境の有効性をテストすることです。

4. アプリケーションのデモンストレーション

高可用性デモ スクリプト:

高可用性グループの情報。現在、LB バックエンドは高可用性グループとしてマウントされています。

テスト ページ情報 (すべての IP が実際の IP ではありません):

ビジネスポータル（LB）：http://100.126.35.4/

高可用性グループ内の単一ホストのアクセス エントリは現在次のとおりです。

http://100.126.38.13/

http://100.126.38.16

ホストの高可用性と自動スケーリング:

デモに必要なスクリプト:

1つは、本番環境をシミュレートし、メイン業務入口のLBに継続的にアクセスすることです。テスト中は中断することなくいつでもアクセスできます。

 # !/ bin / bash
 #for ( ( i = 1 ; i <= 10 ; i ++ ) )
 i が{ 1 .. 15000 }の場合
 する
カール100.126.35.4
 $iをエコーする
エコー $ (日付+% T )
睡眠3
 終わり

1 つは、単一マシン環境をシミュレートし、メインマシンの入り口への継続的なアクセスを提供することです。テスト中に単一のマシンがシャットダウンされると、アクセスが停止します。

 # !/ bin / bash

 #for ( ( i = 1 ; i <= 10 ; i ++ ) )

 i が{ 1 .. 15000 }の場合

 する

カール100.126.38.16

 $iをエコーする

エコー $ (日付+% T )

睡眠3

 終わり

デモンストレーション中、高可用性グループの自動スケーリング機能により、新しいホストの容量を正常に拡張し、ビジネス アクセスを提供できます。

• 高可用性グループの自動スケーリング、ストレスによるストレスのシミュレーション
• stress をインストールした後、直接実行します (ホストは 2C)。
• ストレス --CPU 2
• top コマンドは、CPU が完全に使用されていることを示します。
• 2 分後 (高可用性グループのスケーリング ポリシーで構成された時間)、高可用性グループはホストを自動的に拡張し、高可用性グループのホストとして LB バックエンドに自動的にマウントします。自動的に拡張されたホストは、LB およびホスト インターフェイスに表示されます。

コンソールで、高可用性グループ内のホストをシャットダウンします。その後、LB バックエンド サービスのヘルス チェックにより、マウントされた高可用性グループ内のサーバーが異常であることが検出されました。高可用性グループが最小数のホストで構成されている場合、高可用性グループは自動的にホストを拡張してサービスを継続的に提供します。この期間中、トラフィックは正常なバックエンド ホストに転送され、ヘルス チェックが異常なホストはトラフィックを受信しなくなり、ビジネス アクセスは引き続き正常になります。

PAAS サービスの高可用性:

このデモでは、MySQL と redis を使用して開発し、最下層で docker を直接 kill することで、業務アクセスが中断されないようにします。コンソールにマスター/スレーブ切り替え現象が表示され、このプロセス中にビジネスへのアクセスが中断されることはありません。

クラウド データベースおよびキャッシュに対する破壊的な操作。基礎となる操作は R&D によって実行されます。

基盤レイヤーでは RDS マスター/スレーブ切り替え (RDS マスター データベースの強制終了) が実行され、ビジネス アクセスが中断されることはありません。 R&D 部門は、マスターとスレーブの切り替えプロセスを示すスクリーンショットを提供します。

この記事の実際の導入環境は、JD が顧客向けに構築したプライベート クラウド環境 (JDSTACK) です。パブリック クラウドとプライベート クラウドは同じテクノロジー スタックを使用し、構築および検証のプロセスも同様です。スペースの制限により、Redis 検証部分とホスト アクセシビリティ スクリプトの結果はスクリーンショットにキャプチャされません。興味のある読者は、この記事の指示に従って、クラウド上で自分で検証を構築できます。