タグ付けされた質問 「lvs」

主に大規模なWebアプリケーション向けに、負荷分散とフェールオーバー戦略のソリューションを探しています。Web、MySQL、および他の多くのHTTPまたはTCPベースのサービスなど、バランスを取るべき多くのサービスがあります。しかし、彼らの長所と短所が何であり、どちらを選択すべきかはわかりません。

21 load-balancing  failover  haproxy  lvs 

私はVMを使用してホストされるアプリを設定しています（おそらくAmazonですが、それは石では設定されていません）。これは、HTTP負荷分散と多数の（可能な場合50k程度）永続的なTCP接続の負荷分散の両方を必要とします データ量はそれほど多くありませんが、更新は頻繁に行われます。 現在、ロードバランサーを評価していますが、HAProxyのアーキテクチャについて少し混乱しています。HAProxyを使用してTCP接続のバランスを取る場合、結果のトラフィックはすべてロードバランサーを通過する必要がありますか？もしそうなら、別のソリューション（LVSやnginx_tcp_proxy_moduleなど）がより適していますか？

19 load-balancing  haproxy  lvs 

データセンターで負荷分散インフラストラクチャを再構築するように依頼されました。 元の要求は、FTPサーバーの負荷を分散することでした。現在のロードバランサー（Piranha / LVS）を使用してそれを実行しようとしましたが、起動して実行できませんでした。このソフトウェアのドキュメントがほとんどないからというだけではありません。以来Piranha非推奨とみなされ、私はに渡ったHAProxy上で費やした時間の割合で仕事をしたしようとして数日後Piranha。 そのため、FTP負荷分散（パッシブモード）を用意しています。次に、データセンターのピラニアロードバランサー全体を交換するように依頼されました。現在のピラニア構成では、いくつかのWebサーバー、IISサーバー.... aaaおよびDNSがあります。 いいえ HAProxy、これは問題ではありませんUDP load balancing。一般的に使用されているLBのようですが、処理できません。HAProxy動作が好きなので、これは残念です。それで、私はたくさんググって、いくつかのものに出くわしました。ほとんどの人はLVSDNS（TCP / UDP）のLBとして使用しているようです。一部の用途dlbDNS、一部の用途lbnamed、一部の用途netfilter / iptables。 HAProxyFTP、HTTP、IISサーバーを使い続けたいので、と並べて使用することに混乱しましたLVS。 要件： フェイルオーバーのある 2 つのLBインスタンスフェイルオーバーのある2つのDNSサーバー（すでに存在） 複数のバックエンドサーバー（http、アプリケーションなど） 質問： これは可能ですか？DNSサーバーでのUDP負荷分散は必要ですか？それを始める方法を教えてくれるリソースはありますか？または、TCP / HTTPだけでなくUDP負荷分散も処理できるLBソリューションはありますか？ PS： LBソリューションは、ハードウェアではなく、オープンソース/ GPLライセンス/無料である必要があります。 助けやそれぞれのリソースにつながることは大歓迎です！

10 domain-name-system  load-balancing  haproxy  udp  lvs 

AWSがElasticBeanstalkにDockerの「シンプール」を設定する方法と、それがどのように満たされるかを理解できません。Dockerシンプールが何らかの理由でいっぱいになり、アプリがディスクに書き込もうとするとクラッシュします。 これはコンテナの中からです： >df -h > /dev/xvda1 25G 1.4G 24G 6% 実際、EBSには25GBのディスクが割り当てられています。1.6 GBがdu -sh /戻ります。 EC2の外では、それは無害に十分に始まります...（を介してlvs） LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert docker-pool docker twi-aot--- 11.86g 37.50 14.65 ただし、ファイルシステムはすぐに読み取り専用として再マウントされます。dmesg経由： [2077620.433382] Buffer I/O error on device dm-4, logical block 2501385 [2077620.437372] EXT4-fs warning (device dm-4): ext4_end_bio:329: …

9 amazon-web-services  filesystems  docker  lvs 

ますます多くのクライアントにWeb APIを提供するWebアプリケーションを実行しています。はじめに、クライアントは通常、家庭、オフィス、またはその他のワイヤレスネットワークであり、チャンクされたhttpアップロードをAPIに送信しました。これで、より多くのモバイルクライアントの処理に分岐しました。数kから数ギグの範囲のファイルは、小さなチャンクに分割され、APIで再構成されます。 現在の負荷分散は2つの層で実行されます。最初にラウンドロビンDNSを使用して、api.company.comアドレスの複数のAレコードをアドバタイズします。各IPでは、Linux LVS：http : //www.linuxvirtualserver.org/をホストします。ロードバランサーは、リクエストのソースIPアドレスを確認して、接続をどのAPIサーバーに渡すかを決定します。このLVSボックスは、外部VIPと内部ゲートウェイIPを相互に引き継ぐようにハートビートで構成されています。 最近、2つの新しいエラー状態が発生しました。 最初のエラーは、クライアントが1つのLVSから別のLVSにアップロード途中で発振または移行している場合です。これにより、ロードバランサーは永続的な接続を追跡できなくなり、トラフィックを新しいAPIサーバーに送信するため、2つ以上のサーバー間でチャンクされたアップロードが中断されます。私たちの意図は、api.company.comのラウンドロビンDNS TTL値（1時間に設定）が、ダウンストリームキャッシングネームサーバー、OSキャッシングレイヤー、およびクライアントアプリケーションレイヤーで尊重されることです。このエラーは、アップロードの約15％で発生します。 あまり一般的ではない2番目のエラー。クライアントはLVSボックスへのトラフィックを開始し、その背後にある実サーバーAにルーティングされます。その後、クライアントは、LVSボックスが認識しない新しいソースIPアドレスを介して着信します。これにより、進行中のトラフィックがそのLVSの背後にある実サーバーBにルーティングされます。 上記で説明したアーキテクチャを前提として、上記の各エラーケースをより適切に処理できるようにする、より良いアプローチを使用した人々の経験を教えてください。 2010年5月3日を編集： これは私たちが必要としているもののように見えます。送信元IPアドレスの重み付けされたGSLBハッシュ。 http://www.brocade.com/support/Product_Manuals/ServerIron_ADXGlobalServer_LoadBalancingGuide/gslb.2.11.html#271674

8 domain-name-system  load-balancing  lvs  round-robin