Clever Geek Handbook

WindowsドメインのSquidベースのフェールオーバープロキシ

UPD：私の構成と否定的なコメントの作成者が使用する構成との間のメモリ消費の違いは、ドメインユーザーがドメイングループに属する標準スクリプトwbinfo_group.plに加えて、Squidを使用して、決定するスクリプトが使用されるという事実によって引き起こされますsquidがユーザーに、自分のグループに付与されている権限とは異なる権限を提供できるようにするためのユーザーログイン。



画像 雨の降る灰色の夜に、プロキシサーバーを実装する必要がありましたが、単純なものではなく、次の機能を持つプロキシサーバーを実装する必要がありました。





当然、ntlmssp認証を使用してSquidに目を向けました。 Webインターフェースを介してSquidを構成するためのユーティリティー、SAMSがありました。 しかし、どういうわけか私は彼と一緒に成長しませんでした：PHPバージョンを5.3から5.2にロールバックする必要があり、その後ドメインに固執せず、ユーザーが表示されませんでした。 決してこれが悪い製品だとは言いたくありません。私の友人はそれを展開してセットアップしました（そのため、ソースは信頼できます）。星の位置だけではSAMSの支持者になれませんでした。

Google、さまざまな製品、およびソリューションにかなり悩まされ、「設定の本質はsquid.confファイルを生成することです。どういうわけかphpに書きましたが、Webインターフェースを自分で実装してみませんか？」 すぐに、バッグが走り出し、ユーザーがscり、インターネットリソースへのアクセスを開く際のサービスノートを持ってきました。

人生には他に何が必要ですか？ しかし、しばらくして、ソリューションインフラストラクチャのいくつかの欠点が表面に現れました。

  1. ドメインコントローラーが誤動作し、ドメインコントローラーとの接続が失われた場合、ユーザーがログインできなかったため、インターネット（およびメインは企業メール）である外部とのバックアップ通信チャネルは機能しなくなりました。
  2. ユーザーは、ヘルパー（オイルオイル）ntlm_authを使用するntlmsspプロトコルを使用してプロキシにログインします。このインスタンスの1つのインスタンスはRAMで約60メガバイトを占有します。



    ご覧のとおり、同じ量のメモリを消費するwinbinddプロセスも承認に関与しています。 リクエストあたり合計120メガバイト。 承認のためのスレッドの数を示すauth_param ntlm childrenパラメーターは、ユーザーの数を約10％超える必要があることが実験的に見つかりました。 auth_param ntlm children = 200の場合 、プロキシサーバーで 600メガバイトのメモリが使用されます。



    メールエージェントなどのいたずらをしている150人のユーザーがプロキシで作業している場合、サーバーは予期せず動作することがあります。たとえば、フリーズ、ドメインコントローラーとの接続の切断などです。 繰り返しになりますが、これはおそらく私の曲率ですが、この作品のトピックを理解するように促したのは彼女でした。
  3. CPUリソースは実質的に関与していませんが、膨大な量のRAMが予約されています。


したがって、新しいウィッシュリストが登場しました。

  1. プロキシサーバーの負荷を減らし、手首を軽く振るだけでプロキシサーバーの構成を拡張する機会を得ます。
  2. 承認に問題がある場合は、非ドメイン構成に切り替え、問題が消える場合は、ドメイン構成に切り替えます。 途中で、出現および消滅する問題を管理者に通知できます。


プロキシサーバーの負荷とスケーラビリティの削減


ソリューションの出発点は、iptablesの負荷分散機能です。 

# iptables -t nat -A PREROUTING --dst $GW_IP -p tcp --dport 3128 -m state --state NEW -m statistic --mode nth --every 3 --packet 0 -j DNAT --to-destination $PROXY1 #iptables -t nat -A PREROUTING --dst $GW_IP -p tcp --dport 3128 -m state --state NEW -m statistic --mode nth --every 3 --packet 1 -j DNAT --to-destination $PROXY2 #iptables -t nat -A PREROUTING --dst $GW_IP -p tcp --dport 3128 -m state --state NEW -m statistic --mode nth --every 3 --packet 2 -j DNAT --to-destination $PROXY3


このリストのコードにより、3つのプロキシサーバー間で負荷を均等に分散できます。 ここで、1つのIPアドレスの背後に隠れている3つのプロキシが必要です。 私の解決策を下の図に示します。



指定：



この場合、ユーザーに表示される「プロキシサーバー」は、実際には、必要な数のプロキシサーバーとそれらを管理するためのインターフェイスが展開されている仮想マシンのハイパーバイザーです。



この構造により、以下を簡単に提供できます。



Squidの構成はすべてのプロキシで同じであるため、squid.confファイルはPROXY_CONFコンピューターのnfsボールに保存されます。



このスキームを実装するために、次のハードウェアおよびソフトウェアコンポーネントが使用されました。



コンピューターのオン/オフ時に仮想マシンを自動的に起動および停止するために、すべての仮想マシンをオン/オフするvmstartおよびvmstopスクリプトが作成されました。 pingと共にVBoxHeadlessコマンドとVBoxManageコマンドを使用してマシンのステータスを確認するだけなので、コンテンツは提供しません。

したがって、いくつかのタスクが解決されました。



ドメイン構成と非ドメイン構成間の自動切り替え


障害が発生した場合、ドメインコントローラーへの接続ですべてが正常であるかどうかをプロキシサーバーが判断できれば、コントローラーに依存しない構成を適用し、コントローラーを復元するときに、その機能に戻ることができればいいと時間は示していますこれはすべて構想されています。

少ない言葉で、より多くのアクションを！ 

 #!/bin/bash # ,        /bin/ls -la /etc/squid/squid.conf | /bin/grep 'local' LOCAL=$? echo Local configuration - $LOCAL # ,     /usr/bin/ntlm_auth --username=ad_user --password=ad_pass 2>/dev/null 1>/dev/null if [ $? != 0 ]; then #     echo No connection with domain if [ $LOCAL -eq 1 ]; then #       #      echo Reconfigure to local /bin/rm /etc/squid/squid.conf /bin/ln -s /etc/squid/squid.conf.local /etc/squid/squid.conf /usr/sbin/squid -k reconfigure #     ,   /usr/bin/php5 /home/squiduser/mail/mail.php 'from' 'Proxy XX - Gone to non-domain mode' '=(' fi #     /etc/init.d/joindomain else #       echo OK connection to domain if [ $LOCAL -eq 0 ]; then #       #      echo Reconfigure to domain /bin/rm /etc/squid/squid.conf /bin/ln -s /var/www/squid/squid.conf /etc/squid/squid.conf /usr/sbin/squid -k reconfigure #    ,       /usr/bin/php5 /home/squiduser/mail/mail.php 'from' 'Gone to domain mode' '=)' fi fi


注：



スクリプトのロジックを次の図に示します。



今後すべてのプロキシサーバーでスクリプトを同期しないようにするには、PROXY_CONFIGマシンのネットワークボールにドロップし、すべてのプロキシにマウントして、スクリプトを毎分cronに追加します。 したがって、ドメインとの接続が失われた場合、ダウンタイムは1分に短縮されます。つまり、怒っている会計士は電話をかける時間も時間もありませんが、すぐに喜びます。

まあ、それがすべてです。 すべてが機能し、問題はありません。 説明した構成に関するよくある質問にすぐに回答したいと思います。

質問1
仮想マシンを使用するよりも、優れたハードウェアプラットフォームに1つの実際のプロキシサーバーを展開する方が簡単ではありませんか？

答え
拡張-はい、管理しやすい-いいえ。 もちろん、組織が小さく、プロキシとコントローラーの両方に責任がある場合、そのような庭をフェンスすることは意味がありません。 ブランチ、ブランチの分散ネットワークが存在する場合、管理者の職務と責任が分割されると、そのようなシステムは、最高のインフラストラクチャを「期待する」ことが頭に浮かびます。 以前に、2つの新しいブランチの鋭い接続が行われた場合、ハードウェアに展開されたOSのひどいブレーキを通り抜けて、コンフィギュレーションに入り、認証フローの数を増やす必要があり、CDが失敗した場合、ネットワークケーブルをプロキシから切断します。たるみを待つのに数十分かかりましたが、このすべてが展開されているシステムユニットの外観を忘れてしまいました。

質問2
ドメインへの接続のステータスを確認する理由は、コントローラーのトラブルシューティングが簡単ではないですか？

答え
権限の分離に関する質問1の回答を参照してください。


More articles:


All Articles