CLBインスタンスのクイック作成
ダウンロード
フォーカスモード
フォントサイズ
本稿では、ロードバランシングインスタンスの作成方法について説明します。
注意：
シナリオ例
例えば、現在お客様が加速ドメイン
www.example.com と、3つのオリジンサーバー 1.2.3.4、2.3.4.5、3.4.5.6 をお持ちであるとします。通常は 1.2.3.4 と 2.3.4.5 を同時にプライマリオリジンとしてオリジンサーバーへアクセスし、現在は オリジンサーバーグループ操作ガイド を参照してオリジンサーバーグループ primary_origins として設定済みです。プライマリオリジンサーバーに障害が発生した場合にのみ、3.4.5.6 をバックアップオリジンとしてオリジンサーバーへアクセスし、オリジンサーバーグループ backup_origins として設定します。実際の業務リクエストが失敗した場合、同じグループ内の他の正常なオリジンサーバーに再試行します。同時に、定期的な能動的ヘルスチェックを実施し、正常でないオリジンサーバーを能動的に遮断する必要があります。操作手順
1. EdgeOneコンソールにログインし、左側のメニューバーで「サービス概要」に入り、「Webサイト安全な加速」内で設定が必要なサイトをクリックします。
2. サイト詳細ページで、オリジンサーバー設定 > ロードバランシングをクリックします。
3. ロードバランシングページで、インスタンスの作成をクリックします。
4. 最初のステップであるオリジンサーバーの選択では、インスタンス名を入力し、インスタンスタイプを選択し、オリジンサーバーグループを追加する必要があります。
このシナリオを例にとると、オリジンサーバーグループ primary_origins を優先度1のオリジンサーバーグループとして追加し、オリジンサーバーグループ backup_origins を優先度2のオリジンサーバーグループとして追加して、次へをクリックします。
パラメータ | 説明 |
インスタンス名称 | 1～200文字に制限され、使用できる文字はa-z、A-Z、0-9、_、-です。 |
インスタンスタイプ | HTTP専用型：HTTP専用型および汎用型オリジンサーバーグループの追加をサポートします。サイトアクセラレーション関連サービス（ドメイン名サービスやルールエンジンなど）からの参照のみをサポートします。 汎用型：汎用型オリジンサーバーグループのみ追加できます。サイトアクセラレーションサービス（ドメイン名サービスやルールエンジンなど）およびレイヤー4プロキシから参照されます。 |
オリジンサーバーグループを追加 | ロードバランシングインスタンスにおけるオリジンサーバーの最小設定単位はオリジンサーバーグループです。オリジンサーバーをオリジンサーバーグループとして設定し、ここに追加する必要があります。詳細については、オリジンサーバーグループ操作ガイドをご参照ください。 追加したオリジンサーバーグループに優先度を設定できます。高優先度オリジンサーバーグループに正常なオリジンサーバーが存在する場合、トラフィックは低優先度オリジンサーバーグループのオリジンサーバーに割り当てられません。最大10個のオリジンサーバーグループを設定できます。優先度の数字が小さいほど、優先度が高くなります。 |
5. 第二步のヘルスチェックポリシーに進みます。ICMP Ping、HTTPS/HTTP、TCP、UDPの4種類の検出方法をサポートしています。EdgeOneはお客様のオリジンサーバーに能動的に検出リクエストを送信し、オリジンサーバーの遅延とヘルス状態を検出します。お客様はオリジンサーバーの負荷状況に応じて適切な検出頻度を選択できます。ここでは要件に基づき、検出ポリシーとしてICMP Pingを選択します。詳細な検出ポリシー設定の紹介については、ヘルスチェックポリシーの紹介をご参照ください。設定完了後、次へをクリックします。
説明：
EdgeOneのノードがオリジンサーバーに対して検出リクエストを一切送信しないようにする場合は、無効を選択できます。この場合、ロードバランシングインスタンスはデフォルトで最初のステップのオリジンサーバーグループの優先度順にトラフィックをスケジューリングします。60秒以内に特定のオリジンサーバーへのリクエストが5回失敗した場合、該当するオリジンサーバーはデフォルトポリシーに従って10分間ブロックされます。
このポリシーを使用すると、障害が発生したオリジンサーバーを事前に切り離すことができず、オリジンサーバーが正常に復旧した後も、トラフィックのスケジューリングを自動的かつ迅速に復旧できません。そのため、オリジンサーバーに障害が発生している間、能動的検出を有効にした場合と比較して、より多くのリクエストが失敗する可能性があります。したがって、ビジネスの可用性をより高めたい場合は、能動的検出を有効にすることをお勧めします。
6. 第三步のトラフィックスケジューリングポリシーでは、現在のトラフィックスケジューリングポリシーはデフォルトで能動的検出の結果に基づき、優先度順にフェイルオーバーを実行します。実際の業務リクエストがオリジンサーバーにアクセスする際にリクエストが失敗した場合、リクエストの再試行をサポートします。リクエスト再試行ポリシーには以下の2種類があります。詳細については、リクエスト再試行ポリシーの紹介をご参照ください。
ポリシー1：実際のビジネスリクエストが特定のオリジンサーバーへのアクセスに失敗した場合、直接次の優先順位のオリジンサーバーグループ内のオリジンサーバーへ再試行します。オリジンサーバーグループ1とオリジンサーバーグループ2の性能が近いシナリオに適しています。
ポリシー2：実際のビジネスリクエストが特定のオリジンサーバーへのアクセスに失敗した場合、直接現在の優先順位のオリジンサーバーグループ内の他のオリジンサーバーへ再試行します。オリジンサーバーグループ1の性能がオリジンサーバーグループ2よりはるかに高いシナリオに適しています。
7. この例のシナリオを例にとると、ポリシー2を選択できます。完了をクリックすると、インスタンスの作成が完了します。
フィードバック