プライベートな連絡先の最初の情報
送料メール:
2024-07-12
한어Русский языкEnglishFrançaisIndonesianSanskrit日本語DeutschPortuguêsΕλληνικάespañolItalianoSuomalainenLatina
目次
1. スケジューラーの構成 (test1 192.168.233.10)
3. アドレス変換 (test1 192.168.233.10)
2. メッセージが返されたとき、VIP アドレスはまだ存在します。クライアントはどのように応答を受け取ることができますか?
1. スケジューラーの構成 (test1 192.168.233.10)
2. RS 設定 (nginx1 と nginx2) [両方とも変更する必要があります]
LVS は 4 層の転送を実装し、nginx は 7 層の転送（動的）を実装します。LVS の VIP アドレスにアクセスすることで、動的と静的な分離を実現できます。
正式名称はlinux virtualserverで、Linuxカーネルレベルで負荷分散を実現するソフトウェアです。
主な機能: 複数のバックエンド サーバーを高可用性および高性能のサーバー クラスターに形成し、負荷分散アルゴリズムを通じてクライアントの要求をバックエンド サーバーに分散して、高可用性と負荷分散を実現します。
Alibaba の SLB サーバーの LOAB バランスは、lvs+keepalive を使用して実装されています。
クラスタ化および分散
システムを拡張する方法:
垂直スケーリング: より高性能なコンピューターを構築するために上方にスケーリングします。ボトルネック: コンピュータ自身の機器の制限、ハードウェア自体のパフォーマンスのボトルネック。
水平拡張：外側に拡張し、設備を追加します。複数のサービスを並行して実行し、ネットワークに依存して内部通信の問題を解決し、クラスターをクラスター化します。
クラスタ: 特定の問題を解決するために複数のコンピュータを組み合わせて形成される単一のシステム
ポンド: ロード バランシング ロード バランシング クラスタ。複数のホストで構成され、各ホストはアクセス リクエストの一部のみを処理します。
ハ : 高可用性: システムの設計時に、コンポーネントまたはシステムの一部に障害が発生した場合でも、システム全体が正常に動作できるようにするための特定の対策が講じられます。システムの可用性、信頼性、耐障害性を維持するため
高性能コンピューティング：ハイパフォーマンスコンピューティング 応答時間と処理能力に対するより高い要件を備えた高性能クラスター
MYBF：平均故障間隔 平均故障間隔
平均所要時間：Mean Time Recovery 修理が回復するまでの平均時間
A=MTBF/(MTBF+MTTR)
A インデックスは 0 から 1 の間である必要があります。A インデックスはシステムの可用性の尺度です。 0 はシステムの可用性が低いことを意味し、1 はシステムの可用性が高いことを意味します。
A 指標は限りなく 1 に近い必要があります (98% ～ 99% が適格、90% ～ 95% が不適格)
すべて時間単位です (1 年 365 日で 8760 時間)
ダウンタイムと計画時間は含まれません
計画外時間、つまり障害時間は、障害発生から障害解決までの合計時間です。計画外時間は注意が必要な指標です。
LVS が適用されるシナリオ:
小規模なクラスターでは lvs を使用する必要はなく、nginx を使用します。大規模なクラスターでは lvs を使用します。
VS: 仮想サーバーの lvs サービスの論理名。これは、lvs クラスターに外部からアクセスするときに使用する IP アドレスとポートです。
DS: ディレクター サーバー lvs クラスターのメイン サーバー、つまりスケジューラー (つまり、nginx プロキシ サーバー) はクラスターのコアであり、スケジューラーはクライアントの要求を受け入れてバックエンドに転送するために使用されます。サーバ。
RS: 実サーバー lvs クラスターの実サーバー、つまりバックエンド サーバーは、DS によって転送された要求を受け入れ、結果に応答するために使用されます。
CIP: client ip クライアントのアドレス、つまりリクエストを開始したクライアントのアドレス
VIP: 仮想 IP LVS クラスターによって使用される IP アドレス、外部クラスターへのアクセスを提供する仮想 IP アドレス
DIP: ディレクター IP はクラスター内のスケジューラーのアドレスで、RS との通信に使用されます。
RIP: real ip クラスター内のバックエンドサーバーの IP アドレス
NAT モード: スケジューラによってクライアントに応答されるモード (アドレス変換)
DR モード (ダイレクト ルーティング モード): 実サーバーがクライアントに直接応答します。
TUNモード：トンネルモード
よく使用されるモード: NAT モードと DR モード
NAT モードでは、LVS はクライアントからのリクエスト メッセージ内のターゲット IP アドレスとポートを LVS 内の IP アドレスとポートに変更し、リクエストをバックエンド サーバーに転送します。
応答結果がクライアントに返されると、応答メッセージは lvs によって処理され、ターゲット IP とポートがクライアントの IP アドレスとポートに変更されます。
原則: まず、ロード バランサーが顧客のリクエスト パケットを受信すると、スケジューリング アルゴリズムに基づいて、どのバックエンド リアル サーバー (RS) にリクエストを送信するかを決定します。
次に、ロード バランサーは、クライアントからバックエンド実サーバーの IP アドレス (RIP) に送信された要求パケットのターゲット IP アドレスとポートを変更します。
実サーバーはリクエストに応答した後、デフォルト ルートを確認し、応答パケットを受信した後、ロード バランサーに応答データ パケットを送信します。
パケットの送信元アドレスを仮想アドレス (VIP) に変更し、クライアントに送り返します。
利点: ロード バランサーに有効な IP アドレスがある限り、クラスター内のサーバーは TCP/IP をサポートする任意のオペレーティング システムを使用できます。
欠点: サーバー ノードが大きくなりすぎると、すべてのリクエストと応答がロード バランサーを通過する必要があるため、スケーラビリティが制限されます。
したがって、ロードバランサーがシステム全体のボトルネックになります。
アドレス変換が特徴
アドレス変換: 内部ネットワーク - 外部ネットワーク、送信元 IP アドレスは SNAT に変換されます
外部ネットワーク-内部ネットワーク間で宛先IPアドレスをDNAT変換
ipvsadmlvs クラスターを構成および管理するためのツール
-A は仮想サーバー vip を追加します
-D 仮想サーバーアドレスを削除します
-s は、負荷分散スケジューリング アルゴリズムを指定します。
-a 実サーバーを追加します
-d 実サーバーを削除します
-t は VIP アドレスとポートを指定します
-r は rip のアドレスとポートを指定します。
-m NAT モードを使用する
-g DR モードを使用する
-i トンネルモードを使用する
-w 重みを設定します
-p 60 は接続を 60 秒間保持します 接続保持時間を設定します
-l リストビュー
-n デジタル表示
投票RR
加重ポーリング WRR
最小接続数 lc
重み付き最小リンク WLC
nginx 1 RS1 192.168.233.20
nginx2 RS2 192.168.233.30
test1 スケジューラ ens33 192.168.233.10 ens36 12.0.0.1
test2 クライアント 12.0.0.10
yum -y ipvsadm* -y をインストールします
ens33 を構成する
systemctl ネットワークを再起動
ens36 を構成する
/etc/sysconfig/network-scripts/ をコピーします
cp ifcfg-ens33 ifcfg-ens36
vim の ifcfg-ens36
systemctl ネットワークを再起動
nginx1 192.168.233.20 の設定 ゲートウェイの変更
systemctl ネットワークを再起動
nginx2 192.168.233.30 の設定 ゲートウェイの変更
systemctl ネットワークを再起動
vim /usr/local/nginx/html/index.html
訪問したページのコンテンツを変更する
アクセスが接続されているかどうかを確認する
iptables -t nat -vnL nat テーブルにポリシーがあるかどうかを確認します
1.
iptables -t nat -A POSTROUTING -s 192.168.233.0/24 -o ens36 -j SNAT --to 12.0.0.1
デバイスアドレス 192.168.233.0/24 は 12.0.0.1 に変換されます。
2.
ipvsadm -C は元のポリシーをクリアします
ipvsadm -A -t 12.0.0.1:80 -s rr VIP アドレスとポートを指定します
まず仮想サーバーの VIP、IP、ポートを追加し、次に実サーバーを追加します。
3.
ipvsadm -a -t 12.0.0.1:80 -r 192.168.233.20:80 -m
-a 実サーバーを追加します
-t は vip アドレスを指定します
-r は実サーバーのアドレスとポートを指定します。
-m はモードを nat モードとして指定します
ipvsadm -ln ビュー
4.
ipvsadm-save 保存
ipvsadm -D -t 192.168.233.10:80 削除ポリシー
ipvsadm -d -r 192.168.233.20: -t 12.0.0.1:80 ノードサーバーを削除します
5. ルーティングおよび転送機能を有効にする
vim /etc/sysctl.conf
ネット.ipv4.ip_forward=1
4. クライアント (test2 12.0.0.10)
test2のIPアドレスとゲートウェイを変更します。
加重ポーリング
ダイレクトルーティングモードです
NAT モード: スケジューラは LVS クラスタ全体で最も重要であり、NAT モードでは、リクエストの受信、負荷分散アルゴリズムに従ってトラフィックの転送、およびクライアントへの応答の送信を担当します。
DR モード: スケジューラは引き続きリクエストの受信を担当し、負荷分散アルゴリズムに従ってトラフィックを RS に転送し、応答は RS によってクライアントに直接送信されます。
ダイレクト ルーティング: レイヤ 2 転送モードであり、レイヤ 2 はデータ フレームを転送し、データ パケットの送信元 IP と宛先 IP を変更せずに、送信元 MAC アドレスと宛先 MAC アドレスに基づいて転送します。データパケットのMACアドレスに基づいて転送します。
DR モードでは、LVS も仮想 IP アドレスを維持し、すべてのリクエストはこの VIP に送信されます。レイヤー 2 転送が使用されるため、クライアントのリクエストがスケジューラに到達すると、負荷分散アルゴリズムと VIP サーバーに従って RS が選択されます。宛先 MAC は RS の MAC アドレスになります。RS がリクエストを処理した後、スケジューラを経由せずに、メッセージ内のクライアントの送信元 MAC アドレスに従って応答をクライアントに直接送信できます。
原則: まず、ロード バランサーが顧客のリクエスト パケットを受信すると、スケジューリング アルゴリズムに基づいて、どのバックエンド リアル サーバー (RS) にリクエストを送信するかを決定します。
次にロードバランサは、クライアントから送信されたリクエストパケットの宛先MACアドレスをバックエンド実サーバのMACアドレス(R-MAC)に変更します。
実サーバーがリクエストに応答すると、デフォルト ルートをチェックし、ロード バランサーを経由せずに応答パケットをクライアントに直接送信します。
利点: ロード バランサーは要求パケットをバックエンド ノード サーバーに分散することのみを担当しますが、RS は応答パケットをユーザーに直接送信します。
したがって、ロード バランサーを通過する大量のデータ フローが軽減され、ロード バランサーがシステムのボトルネックになることがなくなり、大量のリクエストを処理できるようになります。
短所: ロードバランサーと実サーバー RS の両方が、同じ物理ネットワーク セグメントに接続されたネットワーク カードを持ち、同じ LAN 環境にある必要があります。
理由: スケジューラは VIP で構成されており、RS も VIP アドレスで構成されています。 スケジューラと RS が同じネットワーク セグメント上にあるため、VIP アドレスが競合すると、ARP 通信障害が発生します。これは LAN 全体にブロードキャストされるため、すべてのデバイスがそれを受信します。
lo のループバック応答をブロックして、本機の物理 IP アドレスのみが応答するようにする方法。
解決策: カーネルパラメータを変更します。arp_ignore=1 無視
システムの物理 IP アドレスのみが ARP 要求に応答し、lo ループバック インターフェイスは ARP 要求に応答しません。
解決：アープアナウンス=2
システムは、ARP 要求に応答するために IP パケットの送信元アドレスを使用せず、物理インターフェイスの IP アドレスを直接送信します。
nginx1 RS (実 IP) 192.168.233.20
nginx2 RS 192.168.233.30
192.168.233.100 のVIP
スケジューラ 192.168.233.10
クライアント 192.168.233.40
yum -y ipvsadm* -y をインストールします
仮想ネットワーク カード ens33:0 を追加します
スケジューラの応答パラメータを変更する
vim /etc/sysctl.conf
ネット.ipv4.ip_forward=0
net.ipv4.conf.all.send_redirects=0
net.ipv4.conf.default.send_redirects=0
net.ipv4.conf.ens33.send_redirects=0
sysctl -p
ポリシーの追加
cd /opt
ipvsadm -A -t 192.168.233.100:80 -s rr
ipvsadm -a -t 192.168.233.100:80 -r 192.168.233.20:80 -g
ipvsadm -a -t 192.168.233.100:80 -r 192.168.233.30:80 -g
ipvsadm-save >/etc/sysconfig/ipvsadm
systemctl ipvsadm を再起動します
ipvsadm -ln
固定ページの表示内容を変更する
vim /usr/local/nginx/html/index.html
systemctl nginx を再起動します
ループバックアドレスを追加する
/etc/sysconfig/network-scripts/ をコピーします
cp ifcfg-lo ifcfg-lo:0
vim ifcfg-lo:0
lo:0 インターフェースを vip として追加
ルート追加 -host 192.168.233.100 dev lo:0
IP アドレスを 192.168.233.100 に設定し、lvs の VIP としてループバック インターフェイスに追加します。これは、ルーティング モードを通じて RS に転送され、VIP が実サーバーを識別できるようになります。
RS 実サーバーのカーネル応答を変更する
vim /etc/sysctl.conf
ネット.ipv4.conf.lo.arp_ignore=1
ネット.ipv4.conf.lo.arp_announce=2
ネット.ipv4.conf.all.arp_ignore=1
ネット.ipv4.conf.all.arp_announce=2
VIPポーリングアルゴリズムを変更する
ポリシーポーリングの重みを変更する
負荷分散のための lvs と nginx の違い
LVS は、カーネル モードの IP + ポートを使用する 4 層の転送であり、4 層のプロキシとしてのみ使用できます。
nginx 4 層プロキシ、または 7 層プロキシ
lvs (DR モード)+nginx+tomcat
DR モードでの上記の実験に基づいて、動的分離と静的分離が達成されます。
1.トムキャット部分
1. tomcat1 と tomcat2 にそれぞれ動的ページを作成します
<%@ ページ言語="java" インポート="java.util.*" ページエンコーディング="UTF-8"%>
<html>
<head>
<title>JSP テスト1 ページ</title>
</head>
<body>
<% out.println("動的ページ 1、http://www.test1.com");%>
</body>
</html>
2. tomcat1 と tomcat2 にサイトをそれぞれ追加します。
cd conf
vim サーバー.xml
まず元のサイトを削除してください
<Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true" xmlValidation="false" xmlNamespaceAware="false">
<Context docBase="/usr/local/tomcat/webapps/test" path="" reloadable="true" />
ポートが開始されているかどうかを確認する
192.168.233.40:8080/index.jsp にアクセスしてください。
2.nginx部分
nginx2 と nginx3 を構成する
/usr/local/nginx/conf/ をコピーします。
nginx.conf をコピーします。
vim nginx.conf
アップストリームTomcat {
サーバー 192.168.233.40:8080 重み=1;
サーバー 192.168.233.50:8080 重み=1;
}
場所 ~ .*.jsp$ {
proxy_pass http://tomcat;
proxy_set_header HOST $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
}
次に、systemctlでnginxを再起動します
nginx1 プロキシを構成する
4 層エージェントになる
/usr/local/nginx/conf をコピーします。
vim nginx.conf
次に、systemctlでnginxを再起動します
192.168.100:81 静的ページにアクセスしてください
192.168.233.100:82/index.jsp 動的ページにアクセスします。
NAT DR タン
利点: アドレス変換、シンプルな構成、最高のパフォーマンスの WAN、より長距離のデータ パケット転送を実現可能
短所 パフォーマンスのボトルネック クロスネットワークセグメントの専用チャネルをサポートせず、VPN を開く必要がある (コストがかかる)
RS 要件: 制限はありません。非物理インターフェイスでの ARP 応答はサポートされている必要があります。
RS 数量 10-20 個 100 個 100 個
面接の質問：
1. 3 つのモードと Lv の違いを簡単に説明します
上の表
2.キープアライブのスプリットブレインを解決する方法
これは vs クラスターの高可用性アーキテクチャであり、スケジューラーの高可用性のみを目的としています。
VRP に基づいてメイン スケジューラとバックアップ スケジューラを実装する
メインスケジューラとバックアップスケジューラ（複数台）
メインスケジューラが正常に動作している場合、バックアップは完全に冗長状態（スタンバイ）となり、クラスタの動作には関与しません。プライマリ スケジューラに障害が発生した場合にのみ、バックアップ サーバーがプライマリ スケジューラの作業を引き継ぎます。メイン スケジューラがその機能を再開すると、メイン スケジューラはクラスタへの入り口として機能し続け、スタンバイは優先度に必ずしも依存しない冗長状態を継続します。
キープアライブは、vrp プロトコルに基づいて lvs 高可用性ソリューションを実装します。
1.マルチキャストアドレス
224.0.0.18 はマルチキャスト アドレスに基づいて通信し、プライマリ デバイスとセカンダリ デバイスの間でメッセージを送信します。相手が生きているかどうかを判断する
2. 優先順位に基づいてプライマリとセカンダリの位置を決定します。
3. フェイルオーバー。プライマリ サーバーに障害が発生しても、バックアップ サーバーは引き続き動作します。主は回復して待機中です
4. プライマリとセカンダリの切り替えは VIP アドレスの切り替えです
キープアライブは LVS 専用に表示されますが、LVS 専用ではありません。
コア モジュール: キープアライブのコア モジュール。メイン プロセスの起動とメンテナンス、およびグローバル設定ファイルのロードを担当します。
vrrpモジュール: vrrpプロトコルを実装するモジュールであり、主要な機能モジュールです。
チェックモジュール: ヘルスチェックを担当し、バックグラウンドで実サーバーのステータスをチェックすることもできます
test1 192.168.233.10 主
test2 192.168.233.50 備
192.168.233.100 のVIP
nginx1 192.168.233.20
nginx2 192.168.233.30
クライアント 192.168.233.40
1. プライマリ操作とセカンダリ操作の両方を同じ方法で実行する必要があります。
yum -y ipvsadm keepalived をインストールします
vim /etc/sysctl.conf
ネット.ipv4.ip_forward=0
net.ipv4.conf.all.send_redirects=0
net.ipv4.conf.default.send_redirects=0
net.ipv4.conf.ens33.send_redirects=0
sysctl -p
ipvsadm -C
ipvsadm -A -t 192.168.233.100:80 -s rr
ipvsadm -a -t 192.168.233.100:80 -r 192.168.233.20:80 -g
ipvsadm -a -t 192.168.233.100:80 -r 192.168.233.30:80 -g
ipvsadm-save >/etc/sysconfig/ipvsadm
systemctl ipvsadm を再起動します
ipvsadm -ln
/etc/keepalive をコピーする
vim キープアライブド.conf
彼は 30 年以上テクノロジーの研究に専念しており、Java、linux、javascript、php、css などのさまざまな言語に堪能であり、オープンソース分野で多くの貢献を行っています。将来の参考のために技術開発におけるいくつかの問題を共有する開発者ドキュメント ステーション。
送料メール: