記事ディレクトリ

Linux 運用保守エンジニアの面接での質問 (3)

Linux 運用保守エンジニアの面接での質問 (3)

希望の仕事が見つかるよう、皆さんの幸運を祈っています。
継続的な学習がなくなることはありません。
地球は爆発しないし、私たちは休暇も取らない。
チャンスは常に準備ができている人に与えられます。
さあ、労働者を殴ってください！

1 LVS にはいくつかの動作モードがありますが、それは何ですか?

3種類：

NAT モード: リクエストメッセージのターゲット IP、マルチターゲット IP の DNAT を変更します。
DR モード (デフォルトモード): 新しい MAC アドレスを操作します。
TUN モード: 元の要求 IP メッセージに加えて新しい IP ヘッダーを追加します。

2 LVS の構成要素とは

LVS は、ipvs と ipvsadm を含む 2 つの部分からなるプログラムで構成されています。

ipvs (ip 仮想サーバー): ipvs と呼ばれるコード部分がカーネル空間で動作します。これは、スケジューリングを実現するために実際に有効となるコードです。
ipvsadm: もう 1 つのセクションは ipvsadm と呼ばれるユーザー空間で動作し、ipvs カーネルフレームワークのルールを記述し、誰がクラスターサービスで、誰がバックエンドの実サーバー (Real Server) であるかを定義します。

3 LVS に関連する用語とは何ですか

DS: ディレクターサーバー。フロントエンドロードバランサーノードを指します。
RS: Real Server、バックエンドで実際に動作するサーバー。
VIP: ユーザーのリクエストの対象の IP アドレスとして、ユーザーのリクエストを直接外部に向ける仮想 IP。
DIP: Director Server IP、主に内部ホストとの通信に使用される IP アドレス。
RIP: 実サーバー IP、バックエンドサーバーの IP アドレス。
CIP: クライアント IP、アクセスクライアントの IP アドレス。

4 LVS クラスターの負荷スケジューリングアルゴリズムは何ですか?

ラウンドロビン (ポーリング、ラウンドロビン) スケジューリング (Round-Robin Scheduling) rr
加重ラウンドロビンスケジューリング (加重ラウンドロビンスケジューリング) wrr
最小接続スケジューリング lc
加重最小接続スケジューリング (加重最小接続スケジューリング) wlc (デフォルトのスケジューリングアルゴリズム)
地域ベースの最小接続数のスケジューリング (地域ベースの最小接続数のスケジューリング) lblc
レプリケーションスケジュール lblcr を使用したローカリティベースの最小接続数
宛先ハッシュスケジューリング dh
ソースハッシュスケジューリング (ソースハッシュスケジューリング) sh

5 LVS の使用時に iptables を無効にして削除できますか

はい、iptables を無効にしても LVS の使用には影響しません。LVS は Linux カーネルレベルで実装された負荷分散テクノロジであり、その基礎となる層はトラフィック転送に iptables に依存しません。LVS は、IP トンネリングやネットワークアドレス変換 (NAT) などのテクノロジーを使用して、iptables ルールに依存せずにクライアントからバックエンドサーバーにトラフィックを転送します。

6 haproxy スケジューリングアルゴリズムとは何ですか?

tcp は 4 層ロードを表し、http は 7 層ロードを表します。

静的アルゴリズム:

static-rr-------->tcp/http: 重みベースのラウンドロビンスケジューリング。実行時に socat を使用した重みの動的調整をサポートしません (0 と 1 のみがサポートされ、他の値はサポートされません)バックエンドサーバーが遅いバックエンドホストの数に制限はありません。これは、LVS の wrr に相当します。
first----------->tcp/http: リスト内のサーバーの位置に従って、上から下にスケジュールされますが、最初のサーバーの接続数が制限された場合のみです。上限に達すると、新しいリクエストは次のサービスに割り当てられるため、サーバーの重み設定は無視され、この方法はあまり使用されません。socat による動的重み変更はサポートされていません。0 と 1 を設定できます。その他の値は設定できますが無効です。

動的アルゴリズム:

roundrobin------>tcp/http: 重みベースのラウンドロビン動的スケジューリングアルゴリズム、重みのランタイム調整をサポート、lvs の rr ラウンドロビントレーニングモードとは異なり、haproxy のラウンドロビンはスロースタートをサポート (新しく追加されたサーバー)再投稿の数は徐々に増加します)、各バックエンドは最大 4095 の実サーバーをサポートし、実サーバーの重みの動的な調整をサポートし、ラウンドロビンは広く使用されているデフォルトのスケジューリングアルゴリズムです。
minimumconn ---------> tcp/http: 重み付き最小接続ダイナミクス。重みの実行時調整とスロースタートをサポートします。つまり、重みではなく現在の接続が最も少ないバックエンドサーバーに基づく優先スケジューリング (新しいクライアント接続)、MySQL やその他のシナリオなどの長期接続シナリオに適しています。
ランダム------------>tcp/http: ランダム負荷分散アルゴリズムはバージョン 1.9 で追加され、一貫性のあるハッシュのキーとして乱数に基づいています。ランダム負荷分散は大規模サーバーに適しています。ファームや頻繁に追加されるサーバーの削除は非常に便利です。重みの動的な調整をサポートしています。重みが大きいホストほど、新しいリクエストを取得する可能性が高くなります。

** その他のアルゴリズム: ** 次の静的アルゴリズムと動的アルゴリズムは、hash_type が一貫しているかどうかによって異なります。

source---------->tcp/http: ソースアドレスハッシュ。ユーザーのソースアドレスハッシュに基づいてリクエストをバックエンドサーバーに転送します。同じソースアドレスを持つ後続のリクエストは同じバックエンド Web に転送されます。サーバー。この方法では、バックエンドサーバーのデータ量が変化すると、多くのユーザーリクエストが新しいバックエンドサーバーに転送されます。デフォルトは静的ですが、ハッシュタイプがサポートするオプションによって変更できます。
このアルゴリズムは通常、Cookie を挿入しない TCP モードで使用され、セッション Cookie を拒否する顧客に対して最高のセッションスティッキネスを提供することもでき、セッションセッションは維持されるが、Cookie とキャッシュがサポートされていないシナリオに適しています。
クライアント要求を送信元アドレスのバックエンドサーバーに転送するためのサーバー選択計算方法には、モジュロ方式とコンシステントハッシュの 2 つがあります。
uri--------------->http: ユーザーが要求した URI の左半分のハッシュまたは URI 全体に基づいて、ハッシュ結果を総重みで剰余します。最終結果に応じて、指定されたバックエンドサーバーにリクエストを転送します。バックエンドがキャッシュサーバーであるシナリオに適しています。デフォルトは静的アルゴリズムです。また、ハッシュタイプを通じてマップベースと一貫性を指定することもできます。モジュロ方式を使用するか一貫性のあるハッシュを使用するかを定義します。
url_param---->http: url_param は、ユーザーが要求した URL の params 部分のパラメーターキーに対応する値をハッシュ計算し、サーバーの合計の重みで割った後、選択されたサーバーに配布します。同じユーザーからのリクエストが常に同じ実サーバーに送信されるように追跡ユーザーに使用されます。キーがない場合は、ラウンドロビンアルゴリズムが使用されます。
hdr-------------->http: ユーザーの各 http ヘッダー (header) リクエスト内の指定された情報をハッシュ化します。ここでは、名前で指定された http ヘッダーを取り出してハッシュ化されたハッシュ計算が行われ、サーバーの総重量の係数を取得した後、選択されたサーバーにディスパッチされます。有効な値がない場合は、デフォルトのラウンドロビンスケジューリングが使用されます。
rdp-cookie---->tcp: rdp-cookie は Windows リモートデスクトップをロードします。Cookie を使用してセッションを維持します。デフォルトは静的です。マップベースとハッシュタイプによる一貫性を指定して、モジュロ方式または - 一貫したハッシュ。

アルゴリズムの使用シナリオ

first		# 使用较少

static-rr	# 做了session共享的web集群
roundrobin
random

leastconn	# 数据库
source		# 基于客户端公网IP的会话保持

uri--------->http	# 缓存服务器，CDN服务商，蓝汛、百度、阿里云、腾讯
url_param--->http	# 可以实现session保持

hdr			# 基于客户端请求报文头部做下一步处理
rdp-cookie	# 基于windows主机,很少使用

7 負荷分散を実現するための nginx の分散戦略とは何ですか

ポーリング（デフォルト）：各リクエストを時系列順に1台ずつ異なるバックエンドサーバに振り分け、バックエンドサーバがダウンした場合、障害のあるシステムを自動的に排除できます。
重み重み：重みの値が大きいほどアクセスされる可能性が高く、主に各バックエンドサーバーの性能がアンバランスな場合に使用されます。2 つ目は、ホストのリソースを合理的かつ効果的に使用するために、マスターとスレーブの場合に異なる重みを設定することです。
ip_hash (IP バインディング): 各リクエストはアクセス IP のハッシュ結果に従って割り当てられるため、同じ IP からの訪問者はバックエンドサーバーにアクセスでき、動的 Web ページに存在するセッション共有の問題を効果的に解決できます。
url_hash (サードパーティのプラグイン): Nginx のハッシュパッケージをインストールする必要があり、アクセスされた URL のハッシュ結果に応じてリクエストが割り当てられるため、各 URL が同じバックエンドサーバーに送信され、パフォーマンスがさらに向上します。バックエンドキャッシュサーバーの効率。
Fair (サードパーティのプラグイン):upstream_fair モジュールをインストールする必要があります。よりインテリジェントな負荷分散アルゴリズムである Weight や ip_hash と比較して、Fair アルゴリズムはページサイズと読み込み時間に応じて負荷分散をインテリジェントに実行し、応答時間の短いものを優先することができます。

8 4層ロードと7層ロードの違い

レイヤ 4: IP+ポート転送
7 つの層: プロトコル + コンテンツ交換

4 つの負荷層:

4 層の負荷デバイスでは、クライアントによって送信されるメッセージのターゲットアドレス (元は負荷分散デバイスの IP アドレス)、分散デバイスによって設定された Web サーバーの選択ルールに従って、対応する Web サーバーの IP アドレスが選択されます。 , クライアントが直接通信できるようにするこのサーバーは TCP 接続を確立してデータを送信しますが、レイヤー 4 の負荷自体は接続の確立には関与しません。LVS とは異なり、haproxy は疑似レイヤー 4 の負荷分散です。これは、haproxy がフロントエンドクライアントとバックエンドサーバーとの接続をそれぞれ確立する必要があるためです。

7 つの負荷層:

7 層負荷分散サーバーはリバースプロキシサーバーとして機能します。サーバーは TCP 接続を確立するために 3 回のハンドシェイクを必要とし、クライアントは Web サーバーにアクセスする前に 7 層負荷デバイスと 3 回のハンドシェイクを実行して TCP 接続を確立する必要があります。テキスト情報は 7 層負荷分散に送信され、7 層負荷分散は設定された分散ルールに従って特定の Web サーバーを選択し、3 ウェイハンドシェイクを通じてこの Web サーバーとの TCP 接続を確立します。その後、Web サーバーは必要なデータを 7 層の負荷分散デバイスに送信し、負荷分散デバイスはデータをクライアントに送信します。したがって、7 層の負荷分散デバイスはプロキシサーバーとして機能し、7 層の負荷分散デバイスはプロキシサーバーとして機能します。レイヤプロキシは、クライアントとバックエンドサーバーとの接続をそれぞれ確立する必要があります。

簡単に言うと、レイヤー 4 はユーザーリクエストのターゲットルートを変更し、サーバーに直接転送します。レイヤー 7 はユーザーのメッセージを分割し、ユーザーの代わりに負荷分散によってサーバーに送信します。同じメッセージを返す場合、そのメッセージはまずロードバランサーに送信され、次にロードバランサーはメッセージを変更してからユーザーに送信します。したがって、表示されるログ内のユーザー IP はロードバランサーの IP アドレスであるため、x-forward を実行する必要があります。

9 ロードバランシングの機能とは何ですか

転送機能: 特定のアルゴリズム [重み付け、ラウンドロビン] に従って、クライアント要求を異なるアプリケーションサーバーに転送し、単一サーバーの負荷を軽減し、システムの同時実行性を高めます。
障害除去：ハートビート検出によりアプリケーションサーバーが正常に動作しているかを判断し、サーバーが一定時間ダウンした場合には自動的に他のアプリケーションサーバーにリクエストを送信します。
復元と追加: 障害が発生したアプリケーションサーバーが動作に戻ったことが検出されると、そのアプリケーションサーバーはユーザー要求を処理するキューに自動的に追加されます。

10 LVS、HAProxy、Nginx ロードバランシングの長所、短所、および相違点

LVS の利点:

強力な耐負荷能力、分散のためのみ 4 層で動作し、トラフィック生成なし。この機能は、負荷分散ソフトウェアで最も強力なパフォーマンスを持つことも決定します。トラフィックがなく、同時にバランサー IO のパフォーマンスも保証します。高トラフィックの影響を受けません。
動作は安定しており、LVS+Keepalived や LVS+Heartbeat などの完全なデュアルシステムホットバックアップソリューションを備えています。
アプリケーションの範囲は比較的広く、すべてのアプリケーションの負荷分散を行うことができます。
構成可能性は比較的低いですが、これは欠点でもあり利点でもあります。構成できる項目がそれほど多くないため、あまり多くの連絡を必要とせず、人的エラーの可能性が大幅に減少します。

LVS の欠点:

ソフトウェア自体は通常の処理をサポートしておらず、動的と静的を分離できないため、Nginx/HAProxy+Keepalived の利点が強調されます。
Web サイトのアプリケーションが比較的大きい場合、LVS/DR+Keepalived はより複雑になり、特に Windows Server アプリケーションが背後にあるマシンの場合、実装、構成、メンテナンスのプロセスがより面倒になります。よりシンプルに。

Nginx の利点:

OSI レイヤー 7 で動作し、http アプリケーションのいくつかのシャント戦略を実行できます。たとえば、ドメイン名やディレクトリ構造などです。その正規化は、HAProxy よりも強力かつ柔軟です。
Nginx はネットワークへの依存性がほとんどないため、理論上、ping が可能であればロード機能を実行できます。これは Nginx の利点でもあります。
Nginx はインストールと構成が比較的簡単で、テストにも便利です。
高い負荷圧力に耐えることができ、安定しており、通常は数万を超える同時実行をサポートできます。
Nginx は、Web ページを処理するサーバーから返されるステータスコードやタイムアウトなど、ポートを通じてサーバーの内部障害を検出でき、間違ったリクエストを別のノードに再送信します。
Nginx は、優れたロードバランサー/リバースプロキシソフトウェアであるだけでなく、強力な Web アプリケーションサーバーでもあります。LNMP も現在非常に人気のある Web 環境であり、LAMP 環境と競合する可能性があります。Nginx は静的ページの処理、特に高同時実行性の処理において Apache よりも優れています。
Nginx は現在、Web リバースアクセラレーションキャッシュとしてますます成熟しており、その速度は従来の Squid サーバーよりも高速です。必要な場合は、リバースプロキシアクセラレータとしての使用を検討できます。

Nginx の欠点:

Nginx は URL の検出をサポートしていません。
Nginx は http と Email しかサポートできませんが、これが Nginx の弱点です。
Nginx のセッション保持と Cookie のガイド機能は比較的不足しています。

HAProxy の利点:

HAProxy は仮想ホストをサポートし、レイヤー 4 および 7 で動作できます (複数のネットワークセグメントをサポートします)。
セッションの維持、Cookie ガイダンスなど、Nginx のいくつかの欠点を補うことができます。
URL検出バックエンドサーバーをサポート;
LVS と同様、これはロードバランシングソフトウェアにすぎません。純粋に効率という点では、HAProxy は Nginx よりもロードバランシング速度が優れており、同時処理においても Nginx よりも優れています。
HAProxy は、Mysql 読み取りの負荷分散、バックエンド MySQL ノードの検出および負荷分散を行うことができますが、バックエンド MySQL スレーブの数が 10 を超えると、パフォーマンスは LVS ほど良くありません。
HAProxy には多くのアルゴリズムがあり、8 種類に達します。

LVS：4層で転送する
HAproxy：4層と7層で転送する、専門的なプロキシサーバーです
Nginx：WEBサーバー、キャッシュサーバー、リバースプロキシサーバーで、7つのことができます転送のレイヤー

違い: LVS は 4 層転送に基づいているため、ポート転送のみを行うことができますが、URL ベースおよびディレクトリベースの転送 LVS はこれを行うことができません。

作業の選択: HAproxy と Nginx は 7 層の転送ができるため、URL とディレクトリの両方の転送が可能です。大量の同時実行がある場合は、LVS を選択する必要があります。中小企業の場合、同時実行がそれほど大規模ではないため、HAproxy を選択するか、Nginx で十分です。HAproxy はシンプルな構成の専門的なプロキシサーバーであるため、中小企業には HAproxy の使用をお勧めします。

上記の面接の質問は個人的な要約です。順序に関係なく、思いついたことを自由に書いてください。文章に何か問題がある場合は、コメントしてメッセージを残してください。すぐに修正します。

元のリンク: Linux 運用保守エンジニアの面接の質問 (3)