物理的なアクセスの組織の形成の夜明けにある若い開発プロバイダーで。 次のネットワークアーキテクチャが個人に採用されました。
- IPoE
- IPポートバインディング
- DHCPを介したアドレスの発行（オプション82）
- Linuxルーティングサーバー（CentOS）
加入者ベースが成長するにつれて、最初の3つのポイントのすべての問題は正常に解決されました。 後者では、小さな問題が予測されました。
- サーバーの再起動（更新プログラムのインストールまたは障害）中のダウンタイムは約15分でした。 サーバーでは、vlanが数百のオーダーで終了し、vlanの各インターフェイスを持ち上げるのに約5〜7秒かかり、合計でサーバーが完全にロードするのに印象的な時間を与えました。 この時点で、サーバーはpingを実行しましたが、sshが存在しなかったため、少し緊張しました。
- サーバーの負荷を増やすことは、鉄の電力を増やすことで解決できますが、鉄の無限のアップグレードを実行しないでください。
- そして主な問題。 冗長性の欠如。 テクニカルサポートへの呼び出し回数を減らし、通信不足に気づいた加入者の数を減らすために、深夜または朝に再起動時間を計画する必要がありました。 ラッシュアワーの夕方に起きた失敗が頭に白髪の房を追加したという事実については、すでに沈黙しています。
テクノロジーがPPPoEまたはPPTP / L2TPである場合、サーバー（PPPoE）を追加し、PPTP / L2TPサーバーのラウンドロビンDNSレコードを設定するだけですべてが解決されます（このトピックでは少し弱いため、混乱している可能性があります）。
アクセステクノロジーでは、VRRPが唯一のオプションでした。
ここで取ることができ
ます 。 インストールについては説明しません。具体的なものはありません。
VRRPについて簡単に説明します。
各サーバーに仮想インターフェースが作成されます。 サーバーの1つがMASTERになり、もう1つがBACKUPになり、すべてのトラフィックがMASTERサーバーを通過します。 MASTERサーバーはarp要求に応答し、BACKUPサーバーはサイレントです。 2つのサーバーは、どちらがMASTERであり、その可用性を決定する特別なパッケージを交換します。そのため、MASTERサーバーが利用できない場合、BACKUPサーバーはMASTER状態に切り替わります。
VRRPページでは、2つの仮想インターフェイスが発生し、DHCPを介して異なるゲートウェイアドレスが指定されると、負荷分散方法が示されます。
別の方法を使用することにしました。 なぜなら これらのサーバーでvlanを終了する必要があります。次に、vlan-sごとに1つのウイルスインターフェイスがあり、奇数個のvlan MASTERのみがサーバー番号1で、サーバー番号2がBACKUPになります。 VLAN番号が偶数の場合、すべてが正反対になります。サーバー1がバックアップになり、2がマスターになります。 なぜなら 多数のインターフェイスがある場合、ルーティングされたトラフィックはほぼ均等に分割されます。
したがって、完成したソリューション：
サーバー＃1インターフェース（VLAN番号、インターフェースIPアドレス、VRRPのステータス）：
1 10.0.1.2 MASTER
2 10.0.2.2 BACKUP
3 10.0.3.2 MASTER
...
254 10.0.254.2 BACKUP
255 10.0.255.2 MASTERサーバー＃2（VLAN番号、インターフェイスIPアドレス、VRRPのステータス）：
1 10.0.1.3 BACKUP
2 10.0.2.3 MASTER
3 10.0.3.3 BACKUP
...
254 10.0.254.3 MASTER
255 10.0.255.3 BACKUP仮想インターフェイスにはアドレス（VLAN番号、IPアドレス）があります。
1 10.0.1.1
2 10.0.2.1
3 10.0.3.1
...
254 10.0.254.1
255 10.0.255.1物理インターフェイスの構成方法については説明しません。このトピックには多くの資料があります。
/etc/init.d/でシステムを起動するときにvrrpを自動的にロードするには、起動スクリプトを作成します（独自のテンプレートを作成するか、インターネット上で既製のテンプレートを使用できます。 一番下の行は、インターフェイスごとに1つのプロセスを開始することです。 bashでは、サーバー1に類似したものを生成する簡単なスクリプトが作成されました。
/bin/vrrpd -i eth1.1 -v 1 10.0.1.1 -p 255
/bin/vrrpd -i eth1.2 -v 2 10.0.2.1 -p 100
/bin/vrrpd -i eth1.3 -v 3 10.0.3.1 -p 255
...
/bin/vrrpd -i eth1.254 -v 254 10.0.254.1 -p 100
/bin/vrrpd -i eth1.255 -v 255 10.0.255.1 -p 255サーバー番号2の場合：
/bin/vrrpd -i eth1.1 -v 1 10.0.1.1 -p 100
/bin/vrrpd -i eth1.2 -v 2 10.0.2.1 -p 255
/bin/vrrpd -i eth1.3 -v 3 10.0.3.1 -p 100
...
/bin/vrrpd -i eth1.254 -v 254 10.0.254.1 -p 255
/bin/vrrpd -i eth1.255 -v 255 10.0.255.1 -p 100これらの例では：
/ bin / vrrpd-実行可能ファイルのパス
-i eth1.1-仮想
マシンが接続されている物理インターフェース
-v 1 -vrrpグループのID（255個を超えるグループは使用できません）
10.0.1.1-仮想インターフェースのIPアドレス
-p 255-サーバーの優先順位、より高い優先順位。 デフォルトでは、マスターであるサーバーの優先順位は255であると想定されています。
vrrpの起動後、仮想インターフェイスのMACアドレスは00：00：5E：00：01：xxになります。ここで、xxはVRRPグループのIDです。 ルーターは、ステータスを宣言するパケットの交換も開始します。 これらのパッケージはマルチキャストです。これらの2つのサーバーが接続されているスイッチで、アドレス224.0.0.18にマルチキャストがフィルターされないようにする必要があります。
そして、サーバー自体が必要なパケットをフィルタリングしないようにiptablesを構成します。 / etc / sysconfig / iptablesファイルに次の行を追加します。
:allow_vrrp - [0:0] # vrrp
-A RH-Firewall-1-INPUT -p 112 -j allow_vrrp # 112 ( vrrp)
-A allow_vrrp -s 10.0.1.0/30 -j ACCEPT #
-A allow_vrrp -s 10.0.2.0/30 -j ACCEPT
-A allow_vrrp -s 10.0.3.0/30 -j ACCEPT
...
-A allow_vrrp -s 10.0.254.0/30 -j ACCEPT
-A allow_vrrp -s 10.0.255.0/30 -j ACCEPT
-A allow_vrrp -j LOG --log-level notice #
-A allow_vrrp -j DROP #それだけです
結果：
- バックアップサーバーへの切り替えは1秒未満で行われ、より正確には測定されませんでした。 サブスクライバーの場合、すべてが透過的に行われ、現在のセッションのみが中断し、（グレーのipを持つNATの背後にあるサブスクライバーの場合）-さまようIPが変更されます。
- サーバーの再起動は、すべてのユーザーが自動的にリザーブに転送されることを認識して、営業時間中に静かに実行できます。 障害が発生しても、特にパニックは発生しません。
- 控えめですが、2台のサーバーは1台よりも生産性が高く、特別な希望があればその数を安全に増やすことができます。
特に細心の注意を払っている加入者は、リモートホストをトレースするときに奇妙さだけに気付きました。 奇妙さは次のようになります。
tracert ya.ru
0 10.0.34.35 # ip
1 10.0.34.3 # ip .3, .1PS実際に、このサーバーのペアを実稼働環境に導入するとき、以前はビジネスに携わっていなかった他のテクノロジー（LACP、OSPF）も習得しましたが、何よりもVRRPを扱うのは興味深いものでした。